| |
| RFC 35 | Network Meeting |
| |
| Authors: | S.D. Crocker. |
| Date: | March 1970 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 0035 |
|
|
|
| |
| RFC 96 | An Interactive Network Experiment to Study Modes of Access the Network Information Center |
| |
| Authors: | R.W. Watson. |
| Date: | February 1971 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 0096 |
|
|
|
| |
| RFC 699 | Request For Comments summary notes: 600-699 |
| |
| Authors: | J. Postel, J. Vernon. |
| Date: | November 1982 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 0699 |
|
|
|
| |
| RFC 700 | Protocol experiment |
| |
| Authors: | E. Mader, W.W. Plummer, R.S. Tomlinson. |
| Date: | August 1974 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 0700 |
|
|
|
| |
| RFC 794 | Pre-emption |
| |
| Authors: | V.G. Cerf. |
| Date: | September 1981 |
| Formats: | txt html json |
| Updates: | IEN125 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 0794 |
|
|
|
| |
| RFC 800 | Request For Comments summary notes: 700-799 |
| |
| Authors: | J. Postel, J. Vernon. |
| Date: | November 1982 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 0800 |
|
This RFC is a slightly annotated list of the 100 RFCs from RFC 700 through RFC 799. This is a status report on these RFCs. |
|
| |
| RFC 814 | Name, addresses, ports, and routes |
| |
| Authors: | D.D. Clark. |
| Date: | July 1982 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 0814 |
|
This RFC gives suggestions and guidance for the design of the tables and algorithms necessary to keep track of these various sorts of identifiers inside a host implementation of TCP/IP. |
|
| |
| RFC 817 | Modularity and efficiency in protocol implementation |
| |
| Authors: | D.D. Clark. |
| Date: | July 1982 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 0817 |
|
This RFC will discuss some of the commonly encountered reasons why protocol implementations seem to run slowly. |
|
| |
| RFC 872 | TCP-on-a-LAN |
| |
| Authors: | M.A. Padlipsky. |
| Date: | September 1982 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 0872 |
|
This memo attacks the notion that TCP cannot be appropriate for use on a Local Area Network. Originally published as M82-48 by the MITRE Corporation, Bedford Massachusetts. |
|
| |
| RFC 889 | Internet Delay Experiments |
| |
| Authors: | D.L. Mills. |
| Date: | December 1983 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 0889 |
|
This memo reports on some measurements of round-trip times in the Internet and suggests some possible improvements to the TCP retransmission timeout calculation. This memo is both a status report on the Internet and advice to TCP implementers. |
|
| |
| RFC 899 | Request For Comments summary notes: 800-899 |
| |
| Authors: | J. Postel, A. Westine. |
| Date: | May 1984 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 0899 |
|
|
|
| |
| RFC 964 | Some problems with the specification of the Military Standard Transmission Control Protocol |
| |
| Authors: | D.P. Sidhu, T. Blumer. |
| Date: | November 1985 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 0964 |
|
The purpose of this RFC is to provide helpful information on the Military Standard Transmission Control Protocol (MIL-STD-1778) so that one can obtain a reliable implementation of this protocol standard. This note points out three errors with this specification. This note also proposes solutions to these problems. |
|
| |
| RFC 1012 | Bibliography of Request For Comments 1 through 999 |
| |
| Authors: | J.K. Reynolds, J. Postel. |
| Date: | June 1987 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1012 |
|
This RFC is a reference guide for the Internet community which provides a bibliographic summary of the Request for Comments numbers 1 through 999 issued between the years 1969-1987. |
|
| |
| RFC 1056 | 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. |
|
| |
| RFC 1057 | 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. |
|
| |
| RFC 1071 | Computing the Internet checksum |
| |
| Authors: | R.T. Braden, D.A. Borman, C. Partridge. |
| Date: | September 1988 |
| Formats: | txt json html |
| Updated by: | RFC 1141 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1071 |
|
This RFC summarizes techniques and algorithms for efficiently computing the Internet checksum. It is not a standard, but a set of useful implementation techniques. |
|
| |
| RFC 1094 | 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. |
|
| |
| RFC 1099 | Request for Comments Summary: RFC Numbers 1000-1099 |
| |
| Authors: | J. Reynolds. |
| Date: | December 1991 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1099 |
|
|
|
| |
| RFC 1107 | Plan for Internet directory services |
| |
| Authors: | K.R. Sollins. |
| Date: | July 1989 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1107 |
|
This memo proposes a program to develop a directory service for the Internet. It reports the results of a meeting held in February 1989, which was convened to review requirements and options for such a service. This proposal is offered for comment, and does not represent a committed research activity of the Internet community. |
|
| |
| RFC 1111 | Request for comments on Request for Comments: Instructions to RFC authors |
| |
|
|
This RFC specifies a standard for the Internet community. Authors of RFCs are expected to adopt and implement this standard. |
|
| |
| RFC 1117 | Internet numbers |
| |
|
|
This memo is an official status report on the network numbers and the autonomous system numbers used in the Internet community. |
|
| |
| RFC 1118 | Hitchhikers guide to the Internet |
| |
| Authors: | E. Krol. |
| Date: | September 1989 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1118 |
|
This RFC is being distributed to members of the Internet community in order to make available some "hints" which will allow new network participants to understand how the direction of the Internet is set, how to acquire online information and how to be a good Internet neighbor. While the information discussed may not be relevant to the research problems of the Internet, it may be interesting to a number of researchers and implementors. No standards are defined or specified in this memo. |
|
| |
| RFC 1120 | Internet Activities Board |
| |
|
|
This RFC provides a history and description of the Internet Activities Board (IAB) and its subsidiary organizations. This memo is for informational use and does not constitute a standard. |
|
| |
| RFC 1121 | Act one - the poems |
| |
| Authors: | J. Postel, L. Kleinrock, V.G. Cerf, B. Boehm. |
| Date: | September 1989 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1121 |
|
This RFC presents a collection of poems that were presented at "Act One", a symposium held partially in celebration of the 20th anniversary of the ARPANET. |
|
| |
| RFC 1127 | Perspective on the Host Requirements RFCs |
| |
| Authors: | R.T. Braden. |
| Date: | October 1989 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1127 |
|
This RFC is for information only; it does not constitute a standard, draft standard, or proposed standard, and it does not define a protocol. |
|
| |
| RFC 1129 | 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. |
|
| |
| RFC 1133 | Routing between the NSFNET and the DDN |
| |
| Authors: | J.Y. Yu, H.W. Braun. |
| Date: | November 1989 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1133 |
|
This document is a case study of the implementation of routing between the NSFNET and the DDN components (the MILNET and the ARPANET). We hope that it can be used to expand towards interconnection of other Administrative Domains. We would welcome discussion and suggestions about the methods employed for the interconnections. No standards are specified in this memo. |
|
| |
| RFC 1135 | Helminthiasis of the Internet |
| |
| Authors: | J.K. Reynolds. |
| Date: | December 1989 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1135 |
|
This memo takes a look back at the helminthiasis (infestation with, or disease caused by parasitic worms) of the Internet that was unleashed the evening of 2 November 1988. This RFC provides information about an event that occurred in the life of the Internet. This memo does not specify any standard. This document provides a glimpse at the infection, its festering, and cure. The impact of the worm on the Internet community, ethics statements, the role of the news media, crime in the computer world, and future prevention is discussed. A documentation review presents four publications that describe in detail this particular parasitic computer program. Reference and bibliography sections are also included. |
|
| |
| RFC 1136 | Administrative Domains and Routing Domains: A model for routing in the Internet |
| |
| Authors: | S. Hares, D. Katz. |
| Date: | December 1989 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1136 |
|
This RFC proposes a model for describing routing within the Internet. The model is an adaptation of the "OSI Routeing Framework". This memo does not specify an Internet standard. |
|
| |
| RFC 1141 | 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. |
|
| |
| RFC 1147 | FYI on a Network Management Tool Catalog: Tools for Monitoring and Debugging TCP/IP Internets and Interconnected Devices |
| |
|
|
The goal of this FYI memo is to provide practical information to site administrators and network managers. This memo provides information for the Internet community. It does not specify any standard. It is not a statement of IAB policy or recommendations. [Also FYI 2.] This catalog contains descriptions of several tools available to assist network managers in debugging and maintaining TCP/IP internets and interconnected communications resources. Entries in the catalog tell what a tool does, how it works, and how it can be obtained. |
|
| |
| RFC 1152 | Workshop report: Internet research steering group workshop on very-high-speed networks |
| |
| Authors: | C. Partridge. |
| Date: | April 1990 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1152 |
|
This memo is a report on a workshop sponsored by the Internet Research Steering Group. This memo is for information only. This RFC does not specify an Internet standard. |
|
| |
| RFC 1160 | 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. |
|
| |
| RFC 1166 | Internet numbers |
| |
|
|
This memo is a status report on the network numbers and autonomous system numbers used in the Internet community. |
|
| |
| RFC 1167 | Thoughts on the National Research and Education Network |
| |
| Authors: | V.G. Cerf. |
| Date: | July 1990 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1167 |
|
The memo provides a brief outline of a National Research and Education Network (NREN). This memo provides information for the Internet community. It does not specify any standard. It is not a statement of IAB policy or recommendations. |
|
| |
| RFC 1168 | Intermail and Commercial Mail Relay services |
| |
| Authors: | A. Westine, A.L. DeSchon, J. Postel, C.E. Ward. |
| Date: | July 1990 |
| Formats: | txt html ps pdf json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1168 |
|
This RFC discusses the history and evolution of the Intermail and Commercial mail systems. The problems encountered in operating a store-and-forward mail relay between commercial systems such as Telemail, MCI Mail and Dialcom are also discussed. This RFC provides information for the Internet community, and does not specify any standard. |
|
| |
| RFC 1169 | Explaining the role of GOSIP |
| |
| Authors: | V.G. Cerf, K.L. Mills. |
| Date: | August 1990 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1169 |
|
This informational RFC represents the official view of the Internet Activities Board (IAB), after coordination with the Federal Networking Council (FNC). This RFC does not specify a standard. |
|
| |
| RFC 1170 | Public key standards and licenses |
| |
| Authors: | R.B. Fougner. |
| Date: | January 1991 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1170 |
|
This RFC is a public statement by Public Key Partners regarding Public Key Standards and Licenses. This memo is for informational use only, and does not constitute an Internet standard. |
|
| |
| RFC 1173 | Responsibilities of host and network managers: A summary of the "oral tradition" of the Internet |
| |
| Authors: | J. VanBokkelen. |
| Date: | August 1990 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1173 |
|
This informational RFC describes the conventions to be followed by those in charge of networks and hosts in the Internet. It is a summary of the "oral tradition" of the Internet on this subject. [RFC Editor's note: This memo is a contribution by the author of his view of these conventions. It is expected that this RFC will provide a basis for the development of official policies in the future.] These conventions may be supplemented or amended by the policies of specific local and regional components of the Internet. This RFC does not specify a standard, or a policy of the IAB. |
|
| |
| RFC 1174 | IAB recommended policy on distributing internet identifier assignment and IAB recommended policy change to internet "connected" status |
| |
| Authors: | V.G. Cerf. |
| Date: | August 1990 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1174 |
|
This informational RFC represents the official view of the Internet Activities Board (IAB), and describes the recommended policies and procedures on distributing Internet identifier assignments and dropping the connected status requirement. This RFC does not specify a standard. |
|
| |
| RFC 1175 | FYI on where to start: A bibliography of internetworking information |
| |
| Authors: | K.L. Bowers, T.L. LaQuey, J.K. Reynolds, K. Roubicek, M.K. Stahl, A. Yuan. |
| Date: | August 1990 |
| Formats: | txt html json |
| Also: | FYI 0003 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1175 |
|
The intent of this bibliography is to offer a representative collection of resources of information that will help the reader become familiar with the concepts of internetworking. It is meant to be a starting place for further research. There are references to other sources of information for those users wishing to pursue, in greater depth, the issues and complexities of the current networking environment. |
|
| |
| RFC 1177 | FYI on Questions and Answers: Answers to commonly asked "new internet user" questions |
| |
| Authors: | G.S. Malkin, A.N. Marine, J.K. Reynolds. |
| Date: | August 1990 |
| Formats: | txt json html |
| Obsoleted by: | RFC 1206 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1177 |
|
This FYI RFC is one of three FYI's called, "Questions and Answers" (Q/A), produced by the User Services Working Group (USWG) of the Internet Engineering Task Force (IETF). The goal is to document the most commonly asked questions and answers in the Internet. This memo provides information for the Internet community. It does not specify any standard. [Also FYI 4.] |
|
| |
| RFC 1178 | Choosing a name for your computer |
| |
|
|
In order to easily distinguish between multiple computers, we give them names. Experience has taught us that it is as easy to choose bad names as it is to choose good ones. This essay presents guidelines for deciding what makes a name good or bad.
Keywords: domain name system, naming conventions, computer administration, computer network management |
|
| |
| RFC 1179 | Line printer daemon protocol |
| |
| Authors: | L. McLaughlin. |
| Date: | August 1990 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1179 |
|
This RFC describes an existing print server protocol widely used on the Internet for communicating between line printer daemons (both clients and servers). This memo is for informational purposes only, and does not specify an Internet standard. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. |
|
| |
| RFC 1180 | TCP/IP tutorial |
| |
| Authors: | T.J. Socolofsky, C.J. Kale. |
| Date: | January 1991 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1180 |
|
This RFC is a tutorial on the TCP-IP protocol suite, focusing particularly on the steps in forwarding an IP datagram from source host to destination host through a router. It does not specify an Internet standard. |
|
| |
| RFC 1181 | RIPE Terms of Reference |
| |
| Authors: | R. Blokzijl. |
| Date: | September 1990 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1181 |
|
This RFC describes the Terms of Reference of RIPE (Reseaux IP Europeens), the cooperation of European IP networks. This memo provides information for the Internet community. It does not specify any standard. |
|
| |
| RFC 1186 | MD4 Message Digest Algorithm |
| |
|
|
This RFC is the specification of the MD4 Digest Algorithm. If you are going to implement MD4, it is suggested you do it this way. This memo is for informational use and does not constitute a standard. |
|
| |
| RFC 1192 | Commercialization of the Internet summary report |
| |
| Authors: | B. Kahin. |
| Date: | November 1990 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1192 |
|
This memo is based on a workshop held by the Science, Technology and Public Policy Program of the John F. Kennedy School of Government, Harvard University, March 1-3, 1990. This memo provides information for the Internet community. It does not specify any standard. |
|
| |
| RFC 1193 | Client requirements for real-time communication services |
| |
| Authors: | D. Ferrari. |
| Date: | November 1990 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1193 |
|
A real-time communication service provides its clients with the ability to specify their performance requirements and to obtain guarantees about the satisfaction of those requirements. In this paper, we propose a set of performance specifications that seem appropriate for such services; they include various types of delay bounds, throughput bounds, and reliability bounds. We also describe other requirements and desirable properties from a client's viewpoint, and the ways in which each requirement is to be translated to make it suitable for lower levels in the protocol hierarchy.Finally, we present some examples of requirements specification, and discuss some of the possible objections to our approach.
This research has been supported in part by AT&T Bell Laboratories, the University of California under a MICRO grant, and theInternational Computer Science Institute. The views and conclusions in this document are those of the author and should not be interpreted as representing official policies, either expressed or implied, of any of the sponsoring organizations. |
|
| |
| RFC 1197 | Using ODA for translating multimedia information |
| |
| Authors: | M. Sherman. |
| Date: | December 1990 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1197 |
|
The purpose of this RFC is to inform implementors of multimedia systems about our experiences using ISO 8613: Office Document Architecture (ODA). Because ODA is being proposed as an encoding format for use in multimedia mail and file exchange, implementors wishing to use ODA in an open systems environment may profit from our experiences. This memo provides information for the Internet community. It does not specify any standard. |
|
| |
| RFC 1198 | FYI on the X window system |
| |
|
|
This FYI RFC provides pointers to the published standards of the MIT X Consortium. This memo provides information for the Internet community. It does not specify any Internet standard. |
|
| |
| RFC 1199 | Request for Comments Summary Notes: 1100-1199 |
| |
| Authors: | J. Reynolds. |
| Date: | December 1991 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1199 |
|
|
|
| |
| RFC 1202 | Directory Assistance service |
| |
| Authors: | M.T. Rose. |
| Date: | February 1991 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1202 |
|
This document defines a mechanism by which a user-interface may access a textual DAP-like interface over a TCP/IP connection. This is a local mechanism. This memo provides information for the Internet community. It does not specify any standard. |
|
| |
| RFC 1205 | 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. |
|
| |
| RFC 1206 | FYI on Questions and Answers: Answers to commonly asked "new Internet user" questions |
| |
|
|
This FYI RFC is one of two FYI's called, "Questions and Answers" (Q/A). The goal is to document the most commonly asked questions and answers in the Internet. This memo provides information for the Internet community. It does not specify any standard. [FYI 4] |
|
| |
| RFC 1207 | FYI on Questions and Answers: Answers to commonly asked "experienced Internet user" questions |
| |
| Authors: | G.S. Malkin, A.N. Marine, J.K. Reynolds. |
| Date: | February 1991 |
| Formats: | txt json html |
| Also: | FYI 0007 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1207 |
|
This FYI RFC is one of two FYI's called, "Questions and Answers" (Q/A), produced by the User Services Working Group of the Internet Engineering Task Force (IETF). The goal is to document the most commonly asked questions and answers in the Internet. This memo provides information for the Internet community. It does not specify any standard. |
|
| |
| RFC 1208 | A Glossary of Networking Terms |
| |
| Authors: | O.J. Jacobsen, D.C. Lynch. |
| Date: | March 1991 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1208 |
|
This RFC is a glossary adapted from "The INTEROP Pocket Glossary of Networking Terms" distributed at Interop '90. This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1210 | Network and infrastructure user requirements for transatlantic research collaboration: Brussels, July 16-18, and Washington July 24-25, 1990 |
| |
| Authors: | V.G. Cerf, P.T. Kirstein, B. Randell. |
| Date: | March 1991 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1210 |
|
This report summarises user requirements for networking and related infrastructure facilities needed to enable effective cooperation between US and European research teams participating in the plannedESPRIT-DARPA/NSF programme of collaborative research in InformationScience and Technology. It analyses the problems and disparities of the current facilities, and suggests appropriate one and three year targets for improvements. It proposes a number of initial actions aimed at achieving these targets. Finally, the workshop has identified a non-exhaustive set of important issues upon which support of future research will depend. These issues could be studied in the short term, with the aim of initiating a programme of joint research in collaboration technology within the next year. |
|
| |
| RFC 1211 | Problems with the maintenance of large mailing lists |
| |
| Authors: | A. Westine, J. Postel. |
| Date: | March 1991 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1211 |
|
This RFC discusses problems with maintaining large mailing lists, especially the processing of error reports. This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1215 | Convention for defining traps for use with the SNMP |
| |
| Authors: | M.T. Rose. |
| Date: | March 1991 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1215 |
|
This memo suggests a straight-forward approach towards defining traps used with the SNMP. This memo provides information for the Internet community. It does not specify any standard. |
|
| |
| RFC 1216 | Gigabit network economics and paradigm shifts |
| |
| Authors: | P. Richard, P. Kynikos. |
| Date: | 1 April 1991 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1216 |
|
This memo proposes a new standard paradigm for the Internet Activities Board (IAB) standardization track. [STANDARDS-TRACK] |
|
| |
| RFC 1217 | Memo from the Consortium for Slow Commotion Research (CSCR) |
| |
| Authors: | V.G. Cerf. |
| Date: | 1 April 1991 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1217 |
|
This RFC is in response to RFC 1216, "Gigabit Network Economics and Paradigm Shifts". This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1218 | Naming scheme for c=US |
| |
|
|
This RFC is a near-verbatim copy of a document, known as NADF-123, which has been produced by the North American Directory Forum (NADF). As a part of its charter, the NADF must reach agreement as to how entries are named in the public portions of the North American Directory. This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1219 | On the assignment of subnet numbers |
| |
| Authors: | P.F. Tsuchiya. |
| Date: | April 1991 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1219 |
|
This memo suggests a new procedure for assigning subnet numbers. Use of this assignment technique within a network would be a purely local matter, and would not effect other networks. This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1221 | 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. |
|
| |
| RFC 1222 | Advancing the NSFNET routing architecture |
| |
| Authors: | H.W. Braun, Y. Rekhter. |
| Date: | May 1991 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1222 |
|
This RFC suggests improvements in the NSFNET routing architecture to accommodate a more flexible interface to the Backbone clients. This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1223 | OSI CLNS and LLC1 protocols on Network Systems HYPERchannel |
| |
| Authors: | J.M. Halpern. |
| Date: | May 1991 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1223 |
|
The intent of this document is to provide a complete discussion of the protocols and techniques used to transmit OSI CLNS and LLC1 datagrams (and any associated higher level protocols) on Network Systems Corporation's HYPERchannel equipment.This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1236 | IP to X.121 address mapping for DDN |
| |
| Authors: | L. Morales, P. Hasse. |
| Date: | June 1991 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1236 |
|
This memo defines a standard way of converting IP addresses to CCITT X.121 addresses and is the recommended standard for use on the Internet, specifically for the Defense Data Network (DDN). This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1242 | Benchmarking Terminology for Network Interconnection Devices |
| |
|
|
This memo discusses and defines a number of terms that are used in describing performance benchmarking tests and the results of such tests. The terms defined in this memo will be used in additional memos to define specific benchmarking tests and the suggested format to be used in reporting the results of each of the tests. This memo is a product of the Benchmarking Methodology Working Group (BMWG) of the Internet Engineering Task Force (IETF). |
|
| |
| RFC 1244 | Site Security Handbook |
| |
| Authors: | J.P. Holbrook, J.K. Reynolds. |
| Date: | July 1991 |
| Formats: | txt json html |
| Obsoleted by: | RFC 2196 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1244 |
|
This FYI RFC is a first attempt at providing Internet users guidance on how to deal with security issues in the Internet. This FYI RFC provides information for the Internet community. It does not specify an Internet standard. [FYI 8] |
|
| |
| RFC 1245 | OSPF Protocol Analysis |
| |
|
|
This report attempts to summarize the key features of OSPF V2. It also attempts to analyze how the protocol will perform and scale in the Internet. This memo provides information for the Internet community. It does not specify any Internet standard. |
|
| |
| RFC 1246 | Experience with the OSPF Protocol |
| |
|
|
This report documents experience with OSPF V2. This includes reports on interoperability testing, field experience, simulations and the current state of OSPF implementations. This memo provides information for the Internet community. It does not specify any Internet standard. |
|
| |
| RFC 1249 | DIXIE Protocol Specification |
| |
| Authors: | T. Howes, M. Smith, B. Beecher. |
| Date: | August 1991 |
| Formats: | txt json html |
| Also: | RFC 1202 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1249 |
|
This RFC defines a mechanism by which TCP/UDP based clients can access OSI Directory Service without the overhead of the ISO transport and presentation protocols required to implement full-blown DAP. This memo provides information for the Internet community. It does not specify any standard. |
|
| |
| RFC 1251 | Who's Who in the Internet: Biographies of IAB, IESG and IRSG Members |
| |
|
|
This FYI RFC contains biographical information about members of the Internet Activities Board (IAB), the Internet Engineering Steering Group (IESG) of the Internet Engineering Task Force (IETF), and the the Internet Research Steering Group (IRSG) of the Internet Research Task Force (IRTF). This memo provides information for the Internet community. It does not specify an Internet standard. [FYI 9] |
|
| |
| RFC 1254 | Gateway Congestion Control Survey |
| |
| Authors: | A. Mankin, K. Ramakrishnan. |
| Date: | August 1991 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1254 |
|
The growth of network intensive Internet applications has made gateway congestion control a high priority. The IETF Performance andCongestion Control Working Group surveyed and reviewed gateway congestion control and avoidance approaches. The purpose of this paper is to present our review of the congestion control approaches, as a way of encouraging new discussion and experimentation. Included in the survey are Source Quench, Random Drop, Congestion Indication(DEC Bit), and Fair Queueing. The task remains for Internet implementors to determine and agree on the most effective mechanisms for controlling gateway congestion. |
|
| |
| RFC 1255 | A Naming Scheme for c=US |
| |
|
|
This memo documents the NADF's agreement as to how entries are named in the public portions of the North American Directory. This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1257 | Isochronous applications do not require jitter-controlled networks |
| |
| Authors: | C. Partridge. |
| Date: | September 1991 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1257 |
|
This memo argues that jitter control is not required for networks to support isochronous applications. A network providing bandwidth and bounds delay is sufficient. The implications for gigabit internetworking protocols are briefly considered. |
|
| |
| RFC 1258 | BSD Rlogin |
| |
|
|
The rlogin facility provides a remote-echoed, locally flow-controlled virtual terminal with proper flushing of output.This memo documents an existing protocol and common implementation that is extensively used on the Internet. This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1259 | Building the open road: The NREN as test-bed for the national public network |
| |
| Authors: | M. Kapor. |
| Date: | September 1991 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1259 |
|
This memo discusses the background and importance of NREN. This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1261 | Transition of Nic Services |
| |
| Authors: | S. Williamson, L. Nobile. |
| Date: | September 1991 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1261 |
|
This memo outlines the transition of NIC Services. This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1262 | Guidelines for Internet Measurement Activities |
| |
| Authors: | V.G. Cerf. |
| Date: | October 1991 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1262 |
|
This RFC represents IAB guidance for researchers considering measurement experiments on the Internet. This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1263 | TCP Extensions Considered Harmful |
| |
| Authors: | S. O'Malley, L.L. Peterson. |
| Date: | October 1991 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1263 |
|
This RFC comments on recent proposals to extend TCP. It argues that the backward compatible extensions proposed in RFC's 1072 and 1185 should not be pursued, and proposes an alternative way to evolve theInternet protocol suite. Its purpose is to stimulate discussion in the Internet community. |
|
| |
| RFC 1265 | BGP Protocol Analysis |
| |
| Authors: | Y. Rekhter. |
| Date: | October 1991 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1265 |
|
This report summarizes the key feature of BGP, and analyzes the protocol with respect to scaling and performance. This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1266 | Experience with the BGP Protocol |
| |
| Authors: | Y. Rekhter. |
| Date: | October 1991 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1266 |
|
The purpose of this memo is to document how the requirements for advancing a routing protocol to Draft Standard have been satisfied by Border Gateway Protocol (BGP). This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1270 | SNMP Communications Services |
| |
| Authors: | F. Kastenholz. |
| Date: | October 1991 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1270 |
|
This document discusses various issues to be considered when determining the underlying communications services to be used by an SNMP implementation. This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1272 | Internet Accounting: Background |
| |
| Authors: | C. Mills, D. Hirsh, G.R. Ruth. |
| Date: | November 1991 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1272 |
|
This document provides background information for the "Internet Accounting Architecture". This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1273 | Measurement Study of Changes in Service-Level Reachability in the Global TCP/IP Internet: Goals, Experimental Design, Implementation, and Policy Considerations |
| |
| Authors: | M.F. Schwartz. |
| Date: | November 1991 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1273 |
|
In this report we discuss plans to carry out a longitudinal measurement study of changes in service-level reachability in the global TCP/IP Internet. We overview our experimental design, considerations of network and remote site load, mechanisms used to control the measurement collection process, and network appropriate use and privacy issues, including our efforts to inform sites measured by this study. A list of references and information on how to contact the Principal Investigator are included. |
|
| |
| RFC 1275 | Replication Requirements to provide an Internet Directory using X.500 |
| |
| Authors: | S.E. Hardcastle-Kille. |
| Date: | November 1991 |
| Formats: | txt ps json pdf html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1275 |
|
This RFCconsiders certain deficiencies of the 1988 X.500 standard, which need to be addressed before an effective openInternet Directory can be established using these protocols and services [CCI88]. The only areas considered are primary problems, to which solutions must be found before a pilot can be deployed. This RFCconcerns itself with deficiencies which can only be addressed by use of additional protocol or procedures for distributed operation. |
|
| |
| RFC 1278 | A string encoding of Presentation Address |
| |
| Authors: | S.E. Hardcastle-Kille. |
| Date: | November 1991 |
| Formats: | txt json ps html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1278 |
|
There are a number of environments where a simple string encoding of Presentation Address is desirable. This specification defines such a representation. |
|
| |
| RFC 1281 | Guidelines for the Secure Operation of the Internet |
| |
| Authors: | R. Pethia, S. Crocker, B. Fraser. |
| Date: | November 1991 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1281 |
|
The purpose of this document is to provide a set of guidelines to aid in the secure operation of the Internet. This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1282 | BSD Rlogin |
| |
|
|
This memo documents an existing protocol and common implementation that is extensively used on the Internet. This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1287 | Towards the Future Internet Architecture |
| |
| Authors: | D. Clark, L. Chapin, V. Cerf, R. Braden, R. Hobby. |
| Date: | December 1991 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1287 |
|
This informational RFC discusses important directions for possible future evolution of the Internet architecture, and suggests steps towards the desired goals. This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1290 | There's Gold in them thar Networks! or Searching for Treasure in all the Wrong Places |
| |
|
|
This document was presented at the 1991 ACM SIGUCCS User ServicesConference. It appears here in its updated form.
There is a wealth of information on the network. In fact, so much information, that you could spend your entire life browsing. This paper will present some of the "gold nuggets" of information and file repositories on the network that could be of use to end users.
The ultimate goal is to make the route to these sources of information invisible to the user. At present, this is not easy to do. I will explain some of the techniques that can be used to make these nuggets easier to pick up so that we can all be richer. |
|
| |
| RFC 1291 | Mid-Level Networks Potential Technical Services |
| |
| Authors: | V. Aggarwal. |
| Date: | December 1991 |
| Formats: | txt json ps html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1291 |
|
This document proposes a set of technical services that each Internet mid-level network can offer within the mid-level network itself and and to its peer networks. The term "mid-level" is used as a generic term to represent all regional and similar networks, which, due to continuous evolutions and transitions, can no longer be termed"regional" [MAN]. It discusses the pros and cons of offering these services, as well as areas in which mid-level networks can work together.
A large portion of the ideas stem from discussions at the IETFOperational Statistics (OPstat), User Connectivity Problems (UCP) andNetwork Joint Management (NJM) working groups. |
|
| |
| RFC 1292 | A Catalog of Available X.500 Implementations |
| |
|
|
The goal of this document is to provide information regarding the availability and capability of implementations of X.500. Comments and critiques of this document, and new or updated descriptions ofX.500 implementations are welcome. Send them to the DirectoryInformation Services Infrastructure (DISI) Working Group(disi@merit.edu) or to the editors. |
|
| |
| RFC 1295 | User Bill of Rights for entries and listings in the Public Directory |
| |
| Authors: | The North American Directory Forum. |
| Date: | January 1992 |
| Formats: | txt json html |
| Obsoleted by: | RFC 1417 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1295 |
|
This RFC is a near-verbatim copy of a document, known as NADF-265, which has been produced by the North American Directory Forum (NADF).
User Bill of Rights for entries and listings in the Public Directory
The mission of the North American Directory Forum is to provide interconnected electronic directories which empower users with unprecedented access to public information. To address significant security and privacy issues, the North American Directory Forum introduces the following "User Bill of Rights" for entries in thePublic Directory. As a user, you have:
I. The right not to be listed.
II. The right to have you or your agent informed when your entry is created.
III. The right to examine your entry.
IV. The right to correct inaccurate information in your entry.
V. The right to remove specific information from your entry.
VI. The right to be assured that your listing in thePublic Directory will comply with US or Canadian law regulating privacy or access information.
VII. The right to expect timely fulfillment of these rights. |
|
| |
| RFC 1296 | Internet Growth (1981-1991) |
| |
| Authors: | M. Lottor. |
| Date: | January 1992 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1296 |
|
This document illustrates the growth of the Internet by examination of entries in the Domain Name System (DNS) and pre-DNS host tables.DNS entries are collected by a program called ZONE, which searches the Internet and retrieves data from all known domains. Pre-DNS host table data were retrieved from system archive tapes. Various statistics are presented on the number of hosts and domains. |
|
| |
| RFC 1297 | NOC Internal Integrated Trouble Ticket System Functional Specification Wishlist ("NOC TT REQUIREMENTS") |
| |
| Authors: | D. Johnson. |
| Date: | January 1992 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1297 |
|
Professional quality handling of network problems requires some kind of problem tracking system, herein referred to as a "trouble ticket" system. A basic trouble ticket system acts like a hospital chart, coordinating the work of multiple people who may need to work on the problem.
Once the basic trouble ticket system is in place, however, there are many extensions that can aid Network Operations efficiency.Information in the tickets can be used to produce statistical reports. Operator efficiency and accuracy may be increased by automating trouble ticket entry with information from the networkAlert system. The Alert system may be used to monitor trouble ticket progress. Trouble tickets may be also used to communicate network health information between NOCs, to telcom vendors, and to other internal sales and engineering audiences.
This document explores competing uses, architectures, and desirable features of integrated internal trouble ticket systems for Network and other Operations Centers. |
|
| |
| RFC 1298 | SNMP over IPX |
| |
| Authors: | R. Wormley, S. Bostock. |
| Date: | February 1992 |
| Formats: | txt json html |
| Obsoleted by: | RFC 1420 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1298 |
|
This memo defines a convention for encapsulating Simple NetworkManagement Protocol (SNMP) [1] packets over the transport mechanism provided via the Internetwork Packet Exchange (IPX) protocol [2]. |
|
| |
| RFC 1299 | Summary of 1200-1299 |
| |
| Authors: | M. Kennedy. |
| Date: | January 1997 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1299 |
|
|
|
| |
| RFC 1300 | Remembrances of Things Past |
| |
| Authors: | S. Greenfield. |
| Date: | February 1992 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1300 |
|
Poem. This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1301 | Multicast Transport Protocol |
| |
| Authors: | S. Armstrong, A. Freier, K. Marzullo. |
| Date: | February 1992 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1301 |
|
This memo describes a protocol for reliable transport that utilizes the multicast capability of applicable lower layer networking architectures. The transport definition permits an arbitrary number of transport providers to perform realtime collaborations without requiring networking clients (aka, applications) to possess detailed knowledge of the population or geographical dispersion of the participating members. It is not network architectural specific, but does implicitly require some form of multicasting (or broadcasting) at the data link level, as well as some means of communicating that capability up through the layers to the transport. This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1302 | Building a Network Information Services Infrastructure |
| |
| Authors: | D. Sitzler, P. Smith, A. Marine. |
| Date: | February 1992 |
| Formats: | txt html json |
| Also: | FYI 0012 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1302 |
|
This FYI RFC document is intended for existing Internet NetworkInformation Center (NIC) personnel, people interested in establishing a new NIC, Internet Network Operations Centers (NOCs), and funding agencies interested in contributing to user support facilities. The document strives to:
- Define a basic set of essential services that NetworkInformation Centers (NICs) will provide to Internet users, including new mechanisms that will facilitate the timely dissemination of information to the Internet community and encourage cooperation among NICs.
- Describe existing NIC services as an aid to Internet users and as a model for organizations establishing new NICs. |
|
| |
| RFC 1303 | A Convention for Describing SNMP-based Agents |
| |
|
|
This memo suggests a straight-forward approach towards describingSNMP-based agents. |
|
| |
| RFC 1306 | Experiences Supporting By-Request Circuit-Switched T3 Networks |
| |
| Authors: | A. Nicholson, J. Young. |
| Date: | March 1992 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1306 |
|
This memo describes the experiences of a project team at CrayResearch, Inc., in implementing support for circuit-switched T3 services. While the issues discussed may not be directly relevant to the research problems of the Internet, they may be interesting to a number of researchers and implementers.
Developers at Cray Research, Inc. were presented with an opportunity to use a circuit-switched T3 network for wide area networking. They devised an architectural model for using this new resource. This involves activating the circuit-switched connection when an application program engages in a bulk data transfer, and releasing the connection when the transfer is complete.
Three software implementations for this feature have been tested, and the results documented here. A variety of issues are involved, and further research is necessary. Network users are beginning to recognize the value of this service, and are planning to make use of by-request circuit-switched networks. A standard method of access will be needed to ensure interoperability among vendors of circuit- switched network support products. |
|
| |
| RFC 1308 | Executive Introduction to Directory Services Using the X.500 Protocol |
| |
|
|
This document is an Executive Introduction to Directory Services using the X.500 protocol. It briefly discusses the deficiencies in currently deployed Internet Directory Services, and then illustrates the solutions provided by X.500.
This FYI RFC is a product of the Directory Information Services(pilot) Infrastructure Working Group (DISI). A combined effort of the User Services and the OSI Integration Areas of the InternetEngineering Task Force (IETF). |
|
| |
| RFC 1309 | Technical Overview of Directory Services Using the X.500 Protocol |
| |
| Authors: | C. Weider, J. Reynolds, S. Heker. |
| Date: | March 1992 |
| Formats: | txt json html |
| Also: | FYI 0014 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1309 |
|
This document is an overview of the X.500 standard for people not familiar with the technology. It compares and contrasts DirectoryServices based on X.500 with several of the other Directory services currently in use in the Internet. This paper also describes the status of the standard and provides references for further information on X.500 implementations and technical information.
A primary purpose of this paper is to illustrate the vast functionality of the X.500 protocol and to show how it can be used to provide a global directory for human use, and can support other applications which would benefit from directory services, such as main programs.
This FYI RFC is a product of the Directory Information Services(pilot) Infrastructure Working Group (DISI). A combined effort of the User Services and the OSI Integration Areas of the InternetEngineering Task Force (IETF). |
|
| |
| RFC 1310 | The Internet Standards Process |
| |
|
|
This memo documents the process currently used for the standardization of Internet protocols and procedures. [STANDARDS-TRACK] |
|
| |
| RFC 1311 | Introduction to the STD Notes |
| |
| Authors: | J. Postel. |
| Date: | March 1992 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1311 |
|
The STDs are a subseries of notes within the RFC series that are the Internet standards. The intent is to identify clearly for the Internet community those RFCs which document Internet standards. [STANDARDS- TRACK] |
|
| |
| RFC 1313 | Today's Programming for KRFC AM 1313 Internet Talk Radio |
| |
| Authors: | C. Partridge. |
| Date: | 1 April 1992 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1313 |
|
Hi and welcome to KRFC Internet Talk Radio, your place on the AM dial for lively talk and just-breaking news on internetworking. This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1321 | The MD5 Message-Digest Algorithm |
| |
|
|
This document describes the MD5 message-digest algorithm. The algorithm takes as input a message of arbitrary length and produces as output a 128-bit "fingerprint" or "message digest" of the input. This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1322 | A Unified Approach to Inter-Domain Routing |
| |
| Authors: | D. Estrin, Y. Rekhter, S. Hotz. |
| Date: | May 1992 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1322 |
|
This memo is an informational RFC which outlines one potential approach for inter-domain routing in future global internets. The focus is on scalability to very large networks and functionality, as well as scalability, to support routing in an environment of heterogeneous services, requirements, and route selection criteria.
Note: The work of D. Estrin and S. Hotz was supported by the NationalScience Foundation under contract number NCR-9011279, with matching funds from GTE Laboratories. The work of Y. Rekhter was supported by the Defense Advanced Research Projects Agency, under contractDABT63-91-C-0019. Views and conclusions expressed in this paper are not necessarily those of the Defense Advanced Research ProjectsAgency and National Science Foundation. |
|
| |
| RFC 1324 | A Discussion on Computer Network Conferencing |
| |
| Authors: | D. Reed. |
| Date: | May 1992 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1324 |
|
This memo is intended to make more people aware of the present developments in the Computer Conferencing field as well as put forward ideas on what should be done to formalize this work so that there is a common standard for programmers and others who are involved in this field to work with. It is also the intention of this memo to stimulate the computer community and generate some useful discussion about the merits of this field. |
|
| |
| RFC 1325 | FYI on Questions and Answers Answers to Commonly asked "New Internet User" Questions |
| |
|
|
This FYI RFC is one of two FYI's called, "Questions and Answers"(Q/A), produced by the User Services Working Group of the InternetEngineering Task Force (IETF). The goal is to document the most commonly asked questions and answers in the Internet. |
|
| |
| RFC 1326 | Mutual Encapsulation Considered Dangerous |
| |
| Authors: | P. Tsuchiya. |
| Date: | May 1992 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1326 |
|
This memo describes a packet explosion problem that can occur with mutual encapsulation of protocols (A encapsulates B and B encapsulates A). |
|
| |
| RFC 1329 | 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. |
|
| |
| RFC 1330 | Recommendations for the Phase I Deployment of OSI Directory Services (X.500) and OSI Message Handling Services (X.400) within the ESNET Community |
| |
| Authors: | ESCC X.500/X.400 Task Force, ESnet Site Coordinating Comittee (ESCC), Energy Sciences Network (ESnet). |
| Date: | May 1992 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1330 |
|
This RFC is a near verbatim copy of the whitepaper produced by the ESnet Site Coordinating Committee's X.500/X.400 Task Force. This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1335 | A Two-Tier Address Structure for the Internet: A Solution to the Problem of Address Space Exhaustion |
| |
| Authors: | Z. Wang, J. Crowcroft. |
| Date: | May 1992 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1335 |
|
This RFC presents a solution to problem of address space exhaustion in the Internet. It proposes a two-tier address structure for theInternet. This is an "idea" paper and discussion is strongly encouraged. |
|
| |
| RFC 1336 | Who's Who in the Internet: Biographies of IAB, IESG and IRSG Members |
| |
|
|
This FYI RFC contains biographical information about members of theInternet Activities Board (IAB), the Internet Engineering SteeringGroup (IESG) of the Internet Engineering Task Force (IETF), and the the Internet Research Steering Group (IRSG) of the Internet ResearchTask Force (IRTF). |
|
| |
| RFC 1337 | TIME-WAIT Assassination Hazards in TCP |
| |
| Authors: | R. Braden. |
| Date: | May 1992 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1337 |
|
This note describes some theoretically-possible failure modes for TCP connections and discusses possible remedies. In particular, one very simple fix is identified. |
|
| |
| RFC 1338 | Supernetting: an Address Assignment and Aggregation Strategy |
| |
| Authors: | V. Fuller, T. Li, J. Yu, K. Varadhan. |
| Date: | June 1992 |
| Formats: | txt json html |
| Obsoleted by: | RFC 1519 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1338 |
|
This memo discusses strategies for address assignment of the existingIP address space with a view to conserve the address space and stem the explosive growth of routing tables in default-route-free routers run by transit routing domain providers. |
|
| |
| RFC 1343 | 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. |
|
| |
| RFC 1344 | 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. |
|
| |
| RFC 1345 | Character Mnemonics and Character Sets |
| |
| Authors: | K. Simonsen. |
| Date: | June 1992 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1345 |
|
This memo lists a selection of characters and their presence in some coded character sets. This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1346 | Resource Allocation, Control, and Accounting for the Use of Network Resources |
| |
| Authors: | P. Jones. |
| Date: | June 1992 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1346 |
|
The purpose of this RFC is to focus discussion on particular challenges in large service networks in general, and the International IP Internet in particular. No solution discussed in this document is intended as a standard. Rather, it is hoped that a general consensus will emerge as to the appropriate solutions, leading eventually to the adoption of standards. This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1355 | Privacy and Accuracy Issues in Network Information Center Databases |
| |
|
|
This document provides a set of guidelines for the administration and operation of public Network Information Center (NIC) databases. The purpose is to formalize procedures for the responsible handling of the personal and organizational information maintained by NICs in publically accessible databases, and to improve the accuracy and accessibility of such data where appropriate. |
|
| |
| RFC 1357 | A Format for E-mailing Bibliographic Records |
| |
|
|
This memo defines a format for E-mailing bibliographic records of technical reports. It is intended to accelerate the dissemination of information about new Computer Science Technical Reports (CS-TR). |
|
| |
| RFC 1358 | Charter of the Internet Architecture Board (IAB) |
| |
|
|
The Internet Architecture Board (IAB) shall be constituted and shall operate as a technical advisory group of the Internet Society. This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1359 | 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 theInternet.
In order to provide clarity to the reader, some specific information has been detailed. In doing so, the document has been directed toward U.S. academic institutions that have not yet connected to theInternet.
However, the issues for which specific information has been provided can be generalized for any organization that wishes to participate in the world-wide Internet community. It will be necessary for those organizations to obtain the correct and detailed information from their local or national IP service providers. In addition, this document may be used as an evaluation checklist for organizations that are currently connected. Readers are expected to have general familiarity with networking concepts and terminology. |
|
| |
| RFC 1361 | Simple Network Time Protocol (SNTP) |
| |
|
|
This memorandum describes the Simple Network Time Protocol (SNTP), which is an adaptation of the Network Time Protocol (NTP) used to synchronize computer clocks in the Internet. SNTP can be used when the ultimate performance of the full NTP implementation described inRFC-1305 is not needed or justified. It involves no change to the current or previous NTP specification versions or known implementations, but rather a clarification of certain design features of NTP which allow operation in a simple, stateless RPC mode with accuracy and reliability expectations similar to the UDP/TIME protocol described in RFC-868.
This memorandum does not obsolete or update any RFC. A working knowledge of RFC-1305 is not required for an implementation of SNTP. |
|
| |
| RFC 1362 | Novell IPX over Various WAN Media (IPXWAN) |
| |
|
|
This document describes how Novell IPX operates over various WAN media. Specifically, it describes the common "IPX WAN" protocolNovell uses to exchange necessary router to router information prior to exchanging standard IPX routing information and traffic over WAN datalinks. |
|
| |
| RFC 1363 | A Proposed Flow Specification |
| |
| Authors: | C. Partridge. |
| Date: | September 1992 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1363 |
|
A flow specification (or "flow spec") is a data structure used by internetwork hosts to request special services of the internetwork, often guarantees about how the internetwork will handle some of the hosts' traffic. In the future, hosts are expected to have to request such services on behalf of distributed applications such as multimedia conferencing.
The flow specification defined in this memo is intended for information and possible experimentation (i.e., experimental use by consenting routers and applications only). This RFC is a product of the Internet Research Task Force (IRTF). |
|
| |
| RFC 1365 | An IP Address Extension Proposal |
| |
| Authors: | K. Siyan. |
| Date: | September 1992 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1365 |
|
This RFC suggests an extension to the IP protocol to solve the shortage of IP address problem, and requests discussion and suggestions for improvements. |
|
| |
| RFC 1366 | Guidelines for Management of IP Address Space |
| |
|
|
This document has been reviewed by the Federal Engineering Task Force(FEPG) on behalf of the Federal Networking Council (FNC), the co- chairs of the International Engineering Planning Group (IEPG), and the Reseaux IP Europeens (RIPE). There was general consensus by those groups to support the recommendations proposed in this document for management of the IP address space. |
|
| |
| RFC 1367 | Schedule for IP Address Space Management Guidelines |
| |
|
|
This memo suggests a schedule for the implementation of the IP network number allocation plan described in RFC 1366. This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1369 | Implementation Notes and Experience for the Internet Ethernet MIB |
| |
| Authors: | F. Kastenholz. |
| Date: | October 1992 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1369 |
|
This document reflects the currently known status of 11 different implementations of the MIB by 7 different vendors on 7 different Ethernet interface chips. This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1371 | Choosing a Common IGP for the IP Internet |
| |
| Authors: | P. Gross. |
| Date: | October 1992 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1371 |
|
This memo presents motivation, rationale and other surrounding background information leading to the IESG's recommendation to theIAB for a single "common IGP" for the IP portions of the Internet.
In this memo, the term "common IGP" is defined, the need for a commonIGP is explained, the relation of this issue to other ongoingInternet Engineering Task Force (IETF) routing protocol development is provided, and the relation of this issue to the goal for multi- protocol integration in the Internet is explored.
Finally, a specific IGP is recommended as the "common IGP" for IP portions of the Internet -- the Open Shortest Path First (OSPF) routing protocol.
The goal of this recommendation is for all vendors of Internet IP routers to make OSPF available as one of the IGP's provided with their routers. |
|
| |
| RFC 1373 | Portable DUAs |
| |
| Authors: | T. Tignor. |
| Date: | October 1992 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1373 |
|
This document comes in two parts. The first part is for regular people who wish to set up their own DUAs (Directory User Interfaces) to access the Directory. The second part is for ISODE-maintainers wishing to provide portable DUAs to users. This part gives instructions in a similar but longer, step-by-step format. This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1375 | Suggestion for New Classes of IP Addresses |
| |
| Authors: | P. Robinson. |
| Date: | October 1992 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1375 |
|
This RFC suggests a change in the method of specifying the IP address to add new classes of networks to be called F, G, H, and K, to reduce the amount of wasted address space, and to increase the available IP address number space, especially for smaller organizations or classes of connectors that do not need or do not want a full Class C IP address. |
|
| |
| RFC 1380 | IESG Deliberations on Routing and Addressing |
| |
| Authors: | P. Gross, P. Almquist. |
| Date: | November 1992 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1380 |
|
This memo summarizes issues surrounding the routing and addressing scaling problems in the IP architecture, and it provides a brief background of the ROAD group and related activities in the InternetEngineering Task Force (IETF).
It also provides a preliminary report of the Internet EngineeringSteering Group (IESG) deliberations on how these routing and addressing issues should be pursued in the Internet ArchitectureBoard (IAB)/IETF. |
|
| |
| RFC 1384 | Naming Guidelines for Directory Pilots |
| |
| Authors: | P. Barker, S.E. Hardcastle-Kille. |
| Date: | January 1993 |
| Formats: | txt ps html pdf json |
| Obsoleted by: | RFC 1617, RTR_0011 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1384 |
|
Deployment of a Directory will benefit from following certain guidelines. This document defines a number of naming guidelines.Alignment to these guidelines is recommended for directory pilots. |
|
| |
| RFC 1386 | The US Domain |
| |
| Authors: | A. Cooper, J. Postel. |
| Date: | December 1992 |
| Formats: | txt json html |
| Obsoleted by: | RFC 1480 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1386 |
|
This is a description of the US Top Level Domains on the Internet. This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1387 | RIP Version 2 Protocol Analysis |
| |
|
|
As required by Routing Protocol Criteria (RFC 1264), this report documents the key features of the RIP-2 protocol and the current implementation experience. |
|
| |
| RFC 1391 | The Tao of the IETF: A Guide for New Attendees of the Internet Engineering Task Force |
| |
|
|
Over the last two years, the attendance at Internet Engineering TaskForce (IETF) Plenary meetings has grown phenomenally. Approximately38% of the attendees are new to the IETF at each meeting. About 33% of those go on to become regular attendees. When the meetings were smaller, it wasn't very difficult for a newcomer to get to know people and get into the swing of things. Today, however, a newcomer meets many more new people, some previously known only as the authors of Request For Comments (RFC) documents or thought provoking email messages.
The purpose of this For Your Information (FYI) RFC is to explain to the newcomers how the IETF works. This will give them a warm, fuzzy feeling and enable them to make the meeting more productive for everyone. This FYI will also provide the mundane bits of information which everyone who attends an IETF meeting should know. |
|
| |
| RFC 1392 | Internet Users' Glossary |
| |
| Authors: | G. Malkin, T. LaQuey Parker. |
| Date: | January 1993 |
| Formats: | txt json html |
| Obsoleted by: | RFC 1983 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1392 |
|
There are many networking glossaries in existence. This glossary concentrates on terms which are specific to the Internet. Naturally, there are entries for some basic terms and acronyms because other entries refer to them. |
|
| |
| RFC 1394 | Relationship of Telex Answerback Codes to Internet Domains |
| |
| Authors: | P. Robinson. |
| Date: | January 1993 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1394 |
|
This RFC gives the list, as best known, of all common Internet domains and the conversion between specific country telex answerback codes and Internet country domain identifiers. It also lists the telex code and international dialing code, wherever it is available.It will also list major Internet "Public" E-Mail addresses.
This list is designed to show the corresponding codes for Fax and voice messages, telex country codes, telex answerbacks and Internet domains. It is an attempt to place all of the information into one list and all the connections for each country. |
|
| |
| RFC 1396 | The Process for Organization of Internet Standards Working Group (POISED) |
| |
| Authors: | S. Crocker. |
| Date: | January 1993 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1396 |
|
This report provides a summary of the POISED Working Group (WG), starting from the events leading to the formation of the WG to the end of 1992. Necessarily, this synopsis represents my own perception, particularly for the "prehistory" period. Quite a few people hold strong views about both the overall sequence and specific events. My intent here is to convey as neutral a point of view as possible. |
|
| |
| RFC 1399 | Summary of 1300-1399 |
| |
| Authors: | J. Elliott. |
| Date: | January 1997 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1399 |
|
|
|
| |
| RFC 1400 | Transition and Modernization of the Internet Registration Service |
| |
| Authors: | S. Williamson. |
| Date: | March 1993 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1400 |
|
As a result of the NREN NIS award by National Science Foundation, non- DDN registration services will soon be transferred from the DDN NIC to the new Internet Registration Service, which is a part of an entity referred to as the InterNIC. This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1401 | Correspondence between the IAB and DISA on the use of DNS |
| |
| Authors: | Internet Architecture Board. |
| Date: | January 1993 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1401 |
|
This memo reproduces three letters exchanged between the InternetActivities Board (IAB) and the Defense Information Systems Agency(DISA) regarding the importance of using the Domain Name System (DNS) throughout the Internet, and phasing out the use of older host name to address tables, such as "hosts.txt". |
|
| |
| RFC 1402 | There's Gold in them thar Networks! or Searching for Treasure in all the Wrong Places |
| |
|
|
A wealth of information exists on the network. In fact, there is so much information that you could spend your entire life browsing. This paper will present some of the "gold nuggets" of information and file repositories on the network that could be useful.
The ultimate goal is to make the route to these sources of information invisible to you. At present, this is not easy to do. I will explain some of the techniques that can be used to make these nuggets easier to pick up so that we all can be richer. |
|
| |
| RFC 1404 | A Model for Common Operational Statistics |
| |
|
|
This memo describes a model for operational statistics in theInternet. It gives recommendations for metrics, measurements, polling periods, storage formats and presentation formats. |
|
| |
| RFC 1417 | NADF Standing Documents: A Brief Overview |
| |
|
|
The purpose of this document is to provide a brief overview of the NADF's Standing Document series. This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1428 | Transition of Internet Mail from Just-Send-8 to 8bit-SMTP/MIME |
| |
| Authors: | G. Vaudreuil. |
| Date: | February 1993 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1428 |
|
Protocols for extending SMTP to pass 8bit characters have been defined [3] [4]. These protocols require that messages transported by the extended SMTP are to be encoded in MIME [1] [2]. Before work began on these protocols, several SMTP implementations adopted ad-hoc mechanisms for sending 8bit data. It is desirable for the extendedSMTP environment and these ad hoc mechanisms interoperate. This document outlines the problems in this environment and an approach to minimizing the cost of transition from current usage of non-MIME 8bit messages to MIME. |
|
| |
| RFC 1429 | Listserv Distribute Protocol |
| |
| Authors: | E. Thomas. |
| Date: | February 1993 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1429 |
|
This memo specifies a subset of the distribution protocol used by theBITNET LISTSERV to deliver mail messages to large amounts of recipients. This protocol, known as DISTRIBUTE, optimizes the distribution by sending a single copy of the message over heavily loaded links, insofar as topological information is available to guide such decisions, and reduces the average turnaround time for large mailing lists to 5-15 minutes on the average. This memo describes a simple interface allowing non-BITNET mailing list exploders (or other bulk-delivery scripts) to take advantage of this service by letting the BITNET distribution network take care of the delivery. |
|
| |
| RFC 1430 | A Strategic Plan for Deploying an Internet X.500 Directory Service |
| |
| Authors: | S. Hardcastle-Kille, E. Huizer, V. Cerf, R. Hobby, S. Kent. |
| Date: | February 1993 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1430 |
|
There are a number of reasons why a new Internet Directory Service is required. This document describes an overall strategy for deploying a Directory Service on the Internet, based on the OSI X.500 DirectoryService. It then describes in more detail the initial steps which need to be taken in order to achieve these goals, and how work already undertaken by Internet Engineering Task Force Working Groups(IETF WGs) is working towards these goals. |
|
| |
| RFC 1431 | DUA Metrics (OSI-DS 33 (v2)) |
| |
| Authors: | P. Barker. |
| Date: | February 1993 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1431 |
|
This RFC is being distributed to members of the Internet community in order to solicit their reactions to the proposals contained in it.While the issues discussed may not be directly relevant to the research problems of the Internet, they may be interesting to a number of researchers and implementers.
This document defines a set of criteria by which a DUA implementation, or more precisely a Directory user interface, may be judged. Particular issues covered include terminal requirements; style of interface; target user; default object classes and attribute types; use of DAP; error handling. The focus of the note is on"white pages" DUAs: this is a reflection of the current information base. Nevertheless much of the document will be applicable to DUAs developed for other types of Directory usage.
Please send comments to the author or to the discussion group <osi- ds@CS.UCL.AC.UK&rt;. |
|
| |
| RFC 1432 | Recent Internet Books |
| |
| Authors: | J. Quarterman. |
| Date: | March 1993 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1432 |
|
This article originally appeared in Volume 2 Number 12, (December1992) of Matrix News, the monthly newsletter of Matrix Information and Directory Services, Inc. (MIDS). |
|
| |
| RFC 1434 | Data Link Switching: Switch-to-Switch Protocol |
| |
|
|
This RFC describes IBM's support of Data Link Switching over TCP/IP.The RFC is being distributed to members of the Internet community in order to solicit their reactions to the proposals contained in it.While the issues discussed may not be directly relevant to the research problems of the Internet, they may be interesting to a number of researchers and implementors.
Any questions or comments relative to the contents of this RFC should be sent to the following Internet address: dlsw@ralvma.vnet.ibm.com. |
|
| |
| RFC 1435 | IESG Advice from Experience with Path MTU Discovery |
| |
| Authors: | S. Knowles. |
| Date: | March 1993 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1435 |
|
In the course of reviewing the MTU Discovery protocol for possible elevation to Draft Standard, a specific operational problem was uncovered. The problem results from the optional suppression of ICMP messages implemented in some routers. This memo outlines a modification to this practice to allow the correct functioning of MTUDiscovery. |
|
| |
| RFC 1436 | The Internet Gopher Protocol (a distributed document search and retrieval protocol) |
| |
| Authors: | F. Anklesaria, M. McCahill, P. Lindner, D. Johnson, D. Torrey, B. Alberti. |
| Date: | March 1993 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1436 |
|
The Internet Gopher protocol is designed for distributed document search and retrieval. This document describes the protocol, lists some of the implementations currently available, and has an overview of how to implement new client and server applications. This document is adapted from the basic Internet Gopher protocol document first issued by the Microcomputer Center at the University ofMinnesota in 1991. |
|
| |
| RFC 1437 | The Extension of MIME Content-Types to a New Medium |
| |
| Authors: | N. Borenstein, M. Linimon. |
| Date: | 1 April 1993 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1437 |
|
A previous document, RFC 1341, defines a format and general framework for the representation of a wide variety of data types in Internet mail. This document defines one particular type of MIME data, the matter-transport/sentient-life-form type. The matter- transport/sentient-life-form MIME type is intended to facilitate the wider interoperation of electronic mail messages that include entire sentient life forms, such as human beings.
Other informally proposed subtypes, such as "non-sentient-life-form","non-sentient-non-life-form", and the orthogonally necessary but nevertheless puzzling "sentient-non-life-form", are not described in this memo. |
|
| |
| RFC 1438 | Internet Engineering Task Force Statements Of Boredom (SOBs) |
| |
| Authors: | A. Lyman Chapin, C. Huitema. |
| Date: | 1 April 1993 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1438 |
|
This document creates a new subseries of RFCs, entitled, IETF Statements Of Boredom (SOBs). This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1439 | The Uniqueness of Unique Identifiers |
| |
| Authors: | C. Finseth. |
| Date: | March 1993 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1439 |
|
This RFC provides information that may be useful when selecting a method to use for assigning unique identifiers to people. |
|
| |
| RFC 1453 | A Comment on Packet Video Remote Conferencing and the Transport/Network Layers |
| |
| Authors: | W. Chimiak. |
| Date: | April 1993 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1453 |
|
The new generation of multimedia applications demands new features and new mechanisms for proper performance. ATM technology has moved from concept to reality, delivering very high bandwidths and new capabilities to the data link layer user. In an effort to anticipate the high bandwidth-delay data link layer, Delta-t [Delta-t], NETBLT[RFC 988], and VMTP [RFC 1045] were developed. The excellent insights and mechanisms pioneered by the creators of these experimental Internet protocols were used in the design of XpressTransfer Protocol (XTP) [XTP92] with the goal of eventually delivering ATM bandwidths to a user process. This RFC is a vehicle to inform the Internet community about XTP as it benefits from pastInternet activity and targets general-purpose applications and multimedia applications with the emerging ATM networks in mind. |
|
| |
| RFC 1454 | Comparison of Proposals for Next Version of IP |
| |
| Authors: | T. Dixon. |
| Date: | May 1993 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1454 |
|
This is a slightly edited reprint of RARE Technical Report(RTC(93)004).
The following is a brief summary of the characteristics of the three main proposals for replacing the current Internet Protocol. It is not intended to be exhaustive or definitive (a brief bibliography at the end points to sources of more information), but to serve as input to the European discussions on these proposals, to be co-ordinated byRARE and RIPE. It should be recognised that the proposals are themselves "moving targets", and in so far as this paper is accurate at all, it reflects the position at the 25th IETF meeting inWashington, DC. Comments from Ross Callon and Paul Tsuchiya on the original draft have been incorporated. Note that for a time the term"IPv7" was use to mean the eventual next version of IP, but that the same term was closely associated with a particilar proposal, so the term "IPng" is now used to identify the eventual next generation ofIP.
The paper begins with a "generic" discussion of the mechanisms for solving problems and achieving particular goals, before discussing the proposals invidually. |
|
| |
| RFC 1456 | Conventions for Encoding the Vietnamese Language VISCII: VIetnamese Standard Code for Information Interchange VIQR: VIetnamese Quoted-Readable Specification |
| |
| Authors: | Vietnamese Standardization Working Group. |
| Date: | May 1993 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1456 |
|
This document provides information to the Internet community on the currently used conventions for encoding Vietnamese characters into7-bit US ASCII and in an 8-bit form. These conventions are widely used by the overseas Vietnamese who are on the Internet and are active in USENET. This document only provides information and specifies no level of standard. |
|
| |
| RFC 1457 | Security Label Framework for the Internet |
| |
| Authors: | R. Housley. |
| Date: | May 1993 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1457 |
|
This memo presents a security labeling framework for the Internet. The framework is intended to help protocol designers determine what, if any, security labeling should be supported by their protocols. This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1458 | Requirements for Multicast Protocols |
| |
| Authors: | R. Braudes, S. Zabele. |
| Date: | May 1993 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1458 |
|
This memo discusses some of these unresolved issues, and provides a high-level design for a new multicast transport protocol, group address and membership authority, and modifications to existing routing protocols. This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1462 | FYI on "What is the Internet?" |
| |
|
|
This FYI RFC answers the question, "What is the Internet?" and is produced by the User Services Working Group of the InternetEngineering Task Force (IETF). Containing a modified chapter from EdKrol's 1992 book, "The Whole Internet User's Guide and Catalog," the paper covers the Internet's definition, history, administration, protocols, financing, and current issues such as growth, commercialization, and privatization. |
|
| |
| RFC 1463 | FYI on Introducing the Internet-- A Short Bibliography of Introductory Internetworking Readings |
| |
|
|
This bibliography offers a short list of recent information resources that will help the network novice become familiar with the Internet, including its associated networks, resources, protocols, and history.This FYI RFC includes references to free sources of information available on-line as well as traditional publications. A short section at the end includes information for accessing the on-line files. This FYI is intentionally brief so it can be easily used as a handout by user services personnel. |
|
| |
| RFC 1466 | Guidelines for Management of IP Address Space |
| |
|
|
This document has been reviewed by the Federal Engineering PlanningGroup (FEPG) on behalf of the Federal Networking Council (FNC), the co-chairs of the Intercontinental Engineering Planning Group (IEPG), and the Reseaux IP Europeens (RIPE). There was general consensus by those groups to support the recommendations proposed in this document for management of the IP address space. |
|
| |
| RFC 1468 | Japanese Character Encoding for Internet Messages |
| |
| Authors: | J. Murai, M. Crispin, E. van der Poel. |
| Date: | June 1993 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1468 |
|
This document describes the encoding used in electronic mail [RFC822] and network news [RFC1036] messages in several Japanese networks. This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1470 | FYI on a Network Management Tool Catalog: Tools for Monitoring and Debugging TCP/IP Internets and Interconnected Devices |
| |
|
|
The goal of this FYI memo is to provide an update to FYI 2, RFC 1147[1], which provided practical information to site administrators and network managers. New and/or updated tools are listed in this RFC.Additonal descriptions are welcome, and should be sent to: noctools- entries@merit.edu. |
|
| |
| RFC 1477 | IDPR as a Proposed Standard |
| |
| Authors: | M. Steenstrup. |
| Date: | July 1993 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1477 |
|
This document contains a discussion of inter-domain policy routing (IDPR), including an overview of functionality and a discussion of experiments. This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1480 | 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. |
|
| |
| RFC 1489 | Registration of a Cyrillic Character Set |
| |
| Authors: | A. Chernov. |
| Date: | July 1993 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1489 |
|
Though the proposed character set "koi8-r" is not currently an international standard, there is very large user community (including Relcom Net) supporting it. Factually, "koi8-r" is de-facto standard for Unix and global network applications in the former Soviet Union. This is the reason the Society of Unix User Groups (SUUG) believes "koi8-r" should be registered. This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1491 | A Survey of Advanced Usages of X.500 |
| |
|
|
This document is the result of a survey asking people to detail their advanced usages of X.500. It is intended to show how various organizations are using X.500 in ways which extend the view of X.500 as a "White Pages" service. This RFC is a product of the IntegratedDirectory Services Working Group of the Application and User ServicesAreas of the IETF. |
|
| |
| RFC 1492 | An Access Control Protocol, Sometimes Called TACACS |
| |
| Authors: | C. Finseth. |
| Date: | July 1993 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1492 |
|
This RFC documents the extended TACACS protocol use by the Cisco Systems terminal servers. This same protocol is used by the University of Minnesota's distributed authentication system. This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1498 | On the Naming and Binding of Network Destinations |
| |
| Authors: | J. Saltzer. |
| Date: | August 1993 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1498 |
|
This brief paper offers a perspective on the subject of names of destinations in data communication networks. It suggests two ideas:First, it is helpful to distinguish among four different kinds of objects that may be named as the destination of a packet in a network. Second, the operating system concept of binding is a useful way to describe the relations among the four kinds of objects. To illustrate the usefulness of this approach, the paper interprets some more subtle and confusing properties of two real-world network systems for naming destinations. |
|
| |
| RFC 1499 | Summary of 1400-1499 |
| |
| Authors: | J. Elliott. |
| Date: | January 1997 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1499 |
|
|
|
| |
| RFC 1501 | OS/2 User Group |
| |
| Authors: | E. Brunsen. |
| Date: | August 1993 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1501 |
|
Memo soliciting reactions to the proposal of a OS/2 User Group. This memo provides information for the Internet community. This memo does not specify an IAB standard of any kind. |
|
| |
| RFC 1503 | Algorithms for Automating Administration in SNMPv2 Managers |
| |
| Authors: | K. McCloghrie, M. Rose. |
| Date: | August 1993 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1503 |
|
When a user invokes an SNMPv2 management application, it may be desirable for the user to specify the minimum amount of information necessary to establish and maintain SNMPv2 communications. This memo suggests an approach to achieve this goal. This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1504 | Appletalk Update-Based Routing Protocol: Enhanced Appletalk Routing |
| |
| Authors: | A. Oppenheimer. |
| Date: | August 1993 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1504 |
|
This document provides detailed information about the AppleTalk Update- based Routing Protocol (AURP) and wide area routing. AURP provides wide area routing enhancements to the AppleTalk routing protocols and is fully compatible with AppleTalk Phase 2. This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1506 | A Tutorial on Gatewaying between X.400 and Internet Mail |
| |
| Authors: | J. Houttuin. |
| Date: | August 1993 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1506 |
|
This tutorial was produced especially to help new gateway managers find their way into the complicated subject of mail gatewaying according to RFC 1327. This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1511 | Common Authentication Technology Overview |
| |
| Authors: | J. Linn. |
| Date: | September 1993 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1511 |
|
This memo provides information for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1523 | The text/enriched MIME Content-type |
| |
|
|
MIME [RFC-1341, RFC-1521] defines a format and general framework for the representation of a wide variety of data types in Internet mail.This document defines one particular type of MIME data, the text/enriched type, a refinement of the "text/richtext" type defined in RFC 1341. The text/enriched MIME type is intended to facilitate the wider interoperation of simple enriched text across a wide variety of hardware and software platforms. |
|
| |
| RFC 1524 | A User Agent Configuration Mechanism For Multimedia Mail Format Information |
| |
| Authors: | N. Borenstein. |
| Date: | September 1993 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1524 |
|
This memo suggests a file format to be used to inform multiple mail reading user agent programs about the locally-installed facilities for handling mail in various formats. The mechanism is explicitly designed to work with mail systems based Internet mail as defined byRFC's 821 (STD 10), 822 (STD 11), 934, 1049 (STD 11), 1113, and theMultipurpose Internet Mail Extensions, known as MIME. However, with some extensions it could probably be made to work for X.400-based mail systems as well. The format and mechanism are proposed in a manner that is generally operating-system independent. However, certain implementation details will inevitably reflect operating system differences, some of which will have to be handled in a uniform manner for each operating system. This memo makes such situations explicit, and, in an appendix, suggests a standard behavior under the UNIX operating system. |
|
| |
| RFC 1526 | Assignment of System Identifiers for TUBA/CLNP Hosts |
| |
| Authors: | D. Piscitello. |
| Date: | September 1993 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1526 |
|
This document describes conventions whereby the system identifier portion of an RFC 1237 style NSAP address may be guaranteed uniqueness within a routing domain for the purpose of autoconfiguration in TUBA/CLNP internets. The mechanism is extensible and can provide a basis for assigning system identifiers in a globally unique fashion. |
|
| |
| RFC 1527 | What Should We Plan Given the Dilemma of the Network? |
| |
| Authors: | G. Cook. |
| Date: | September 1993 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1527 |
|
Early last year, as the concluding effort of an 18 month appointment at the US Congress Office of Technology Assessment (OTA), I drafted a potential policy framework for Congressional action on the NationalResearch and Education Network (NREN).
The Internet community needs to be asking what the most important policy issues facing the network are. And given agreement on any particular set of policy issues, the next thing we should be asking is, what would be some of the political choices that would follow forCongress to make?
It is unfortunate that this was never officially done for or by theCongress by OTA. What we have as a result is network policy making being carried out now by the Science Subcommittee on the House side in consultation with a relatively small group of interested parties.The debate seems to be more focused on preserving turf than on any sweeping understanding of what the legislation is doing. That is unfortunate.
In the hope that it may contain some useful ideas, I offer a shortened version of the suggested policy draft as information for the Internet community. |
|
| |
| RFC 1529 | 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. |
|
| |
| RFC 1530 | Principles of Operation for the TPC.INT Subdomain: General Principles and Policy |
| |
| Authors: | C. Malamud, M. Rose. |
| Date: | October 1993 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1530 |
|
This document defines the initial principles of operation for the tpc.int subdomain, a collection of service listings accessible over the Internet infrastructure through an administered namespace contained within the Domain Name System [1,2].
This document is informational and applies only to those Internet sites that choose to register themselves within the tpc.int subdomain. The tpc.int subdomain is organized as a cooperative of the sites that provide access within the context of the subdomain.Policy for the subdomain is set by a board responsible to the cooperative.
The primary purpose of the tpc.int subdomain is to provide transparent mapping between general-purpose computers on the Internet and special-purpose devices directly connected to the telephone network. Initially, a remote printing service is defined [3,4] which ties together G3-compatible facsimile devices on the telephone network with users of electronic mail in the Internet and associated message-handling domains connected to the Internet by application- layer gateways.
It should be noted that remote printer gateways have long been technically feasible and have become an integral part of many individual networks. The tpc.int subdomain integrates individual sites into a common namespace, transforming remote printing from a single-site, value-added service into an integral transparent service in the global Internet. |
|
| |
| RFC 1535 | A Security Problem and Proposed Correction With Widely Deployed DNS Software |
| |
| Authors: | E. Gavron. |
| Date: | October 1993 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1535 |
|
This document discusses a flaw in some of the currently distributed name resolver clients. The flaw exposes a security weakness related to the search heuristic invoked by these same resolvers when users provide a partial domain name, and which is easy to exploit (although not by the masses). This document points out the flaw, a case in point, and a solution. |
|
| |
| RFC 1536 | Common DNS Implementation Errors and Suggested Fixes |
| |
| Authors: | A. Kumar, J. Postel, C. Neuman, P. Danzig, S. Miller. |
| Date: | October 1993 |
| Formats: | txt html json |
| Updated by: | RFC 9210 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1536 |
|
This memo describes common errors seen in DNS implementations and suggests some fixes. Where applicable, violations of recommendations from STD 13, RFC 1034 and STD 13, RFC 1035 are mentioned. The memo also describes, where relevant, the algorithms followed in BIND(versions 4.8.3 and 4.9 which the authors referred to) to serve as an example. |
|
| |
| RFC 1537 | Common DNS Data File Configuration Errors |
| |
|
|
This memo describes errors often found in DNS data files. It points out common mistakes system administrators tend to make and why they often go unnoticed for long periods of time. |
|
| |
| RFC 1538 | Advanced SNA/IP : A Simple SNA Transport Protocol |
| |
| Authors: | W. Behl, B. Sterling, W. Teskey. |
| Date: | October 1993 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1538 |
|
This RFC provides information for the Internet community about a method for establishing and maintaining SNA sessions over an IP internet. While the issues discussed may not be directly relevant to the research problems of the Internet, they may be interesting to a number of researchers and implementors. Any questions or comments relative to the contents of this RFC may be sent to the followingInternet address: snaip@mcdata.com. |
|
| |
| RFC 1539 | The Tao of IETF - A Guide for New Attendees of the Internet Engineering Task Force |
| |
|
|
Over the last two years, the attendance at Internet Engineering TaskForce (IETF) Plenary meetings has grown phenomenally. Approximately38% of the attendees are new to the IETF at each meeting. About 33% of those go on to become regular attendees. When the meetings were smaller, it wasn't very difficult for a newcomer to get to know people and get into the swing of things. Today, however, a newcomer meets many more new people, some previously known only as the authors of Request For Comments (RFC) documents or thought provoking email messages.
The purpose of this For Your Information (FYI) RFC is to explain to the newcomers how the IETF works. This will give them a warm, fuzzy feeling and enable them to make the meeting more productive for everyone. This FYI will also provide the mundane bits of information which everyone who attends an IETF meeting should know. |
|
| |
| RFC 1543 | Instructions to RFC Authors |
| |
|
|
This Request for Comments (RFC) provides information about the preparation of RFCs, and certain policies relating to the publication of RFCs. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1546 | Host Anycasting Service |
| |
| Authors: | C. Partridge, T. Mendez, W. Milliken. |
| Date: | November 1993 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1546 |
|
This RFC describes an internet anycasting service for IP. The primary purpose of this memo is to establish the semantics of an anycasting service within an IP internet. Insofar as is possible, this memo tries to be agnostic about how the service is actually provided by the internetwork. This memo describes an experimental service and does not propose a protocol. This memo is produced by the Internet Research Task Force (IRTF). |
|
| |
| RFC 1547 | Requirements for an Internet Standard Point-to-Point Protocol |
| |
| Authors: | D. Perkins. |
| Date: | December 1993 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1547 |
|
This document discusses the evaluation criteria for an InternetStandard Data Link Layer protocol to be used with point-to-point links. Although many industry standard protocols and ad hoc protocols already exist for the data link layer, none are both complete and sufficiently versatile to be accepted as an InternetStandard. In preparation to designing such a protocol, the features necessary to qualify a point-to-point protocol as an InternetStandard are discussed in detail. An analysis of the strengths and weaknesses of several existing protocols on the basis of these requirements demonstrates the failure of each to address key issues.
Historical Note: This was the design requirements document datedJune 1989, which was followed for RFC-1134 through the present.It is now published for completeness and future guidance. |
|
| |
| RFC 1550 | IP: Next Generation (IPng) White Paper Solicitation |
| |
| Authors: | S. Bradner, A. Mankin. |
| Date: | December 1993 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1550 |
|
This memo solicits white papers on topics related to the IPng requirements and selection criteria. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1551 | Novell IPX Over Various WAN Media (IPXWAN) |
| |
|
|
This document describes how Novell IPX operates over various WAN media. Specifically, it describes the common "IPX WAN" protocolNovell uses to exchange necessary router to router information prior to exchanging standard IPX routing information and traffic over WAN datalinks. This document supercedes RFC 1362 and adds capability forUnnumbered RIP links, On-demand statically routed links and client to router connectivity. |
|
| |
| RFC 1554 | ISO-2022-JP-2: Multilingual Extension of ISO-2022-JP |
| |
| Authors: | M. Ohta, K. Handa. |
| Date: | December 1993 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1554 |
|
This memo describes a text encoding scheme: "ISO-2022-JP-2", which is used experimentally for electronic mail [RFC822] and network news [RFC1036] messages in several Japanese networks. The encoding is a multilingual extension of "ISO-2022-JP", the existing encoding for Japanese [2022JP]. The encoding is supported by an Emacs based multilingual text editor: MULE [MULE]. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1555 | Hebrew Character Encoding for Internet Messages |
| |
| Authors: | H. Nussbacher, Y. Bourvine. |
| Date: | December 1993 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1555 |
|
This document describes the encoding used in electronic mail [RFC822] for transferring Hebrew. The standard devised makes use of MIME[RFC1521] and ISO-8859-8. |
|
| |
| RFC 1556 | Handling of Bi-directional Texts in MIME |
| |
| Authors: | H. Nussbacher. |
| Date: | December 1993 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1556 |
|
This document describes the format and syntax of the "direction" keyword to be used with bi-directional texts in MIME. |
|
| |
| RFC 1557 | Korean Character Encoding for Internet Messages |
| |
| Authors: | U. Choi, K. Chon, H. Park. |
| Date: | December 1993 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1557 |
|
This document describes the encoding method being used to represent Korean characters in both header and body part of the Internet mail messages [RFC822]. This encoding method was specified in 1991, and has since then been used. It has now widely being used in Korean IP networks. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1558 | A String Representation of LDAP Search Filters |
| |
|
|
The Lightweight Directory Access Protocol (LDAP) [1] defines a network representation of a search filter transmitted to an LDAP server. Some applications may find it useful to have a common way of representing these search filters in a human-readable form. This document defines a human-readable string format for representing LDAP search filters. |
|
| |
| RFC 1560 | The MultiProtocol Internet |
| |
| Authors: | B. Leiner, Y. Rekhter. |
| Date: | December 1993 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1560 |
|
This document was prepared by the authors on behalf of the InternetArchitecture Board (IAB). It is offered by the IAB to stimulate discussion.
There has recently been considerable discussion on two topics:MultiProtocol approaches in the Internet and the selection of a next generation Internet Protocol. This document suggests a strawman position for goals and approaches for the IETF/IESG/IAB in these areas. It takes the view that these two topics are related, and proposes directions for the IETF/IESG/IAB to pursue.
In particular, it recommends that the IETF/IESG/IAB should continue to be a force for consensus on a single protocol suite and internet layer protocol. The IETF/IESG/IAB should:
- maintain its focus on the TCP/IP protocol suite,
- work to select a single next-generation internet protocol and develop mechanisms to aid in transition from the current IPv4, and
- continue to explore mechanisms to interoperate and share resources with other protocol suites within the Internet. |
|
| |
| RFC 1562 | Naming Guidelines for the AARNet X.500 Directory Service |
| |
| Authors: | G. Michaelson, M. Prior. |
| Date: | December 1993 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1562 |
|
AARNet is a member network of the global Internet and participates in the global Internet X.500 based Directory Service. A number of RFC's have been issued that make recommendations that alter or supplement the OSI/ETU standards for X.500 [1]. In general, these RFCs will be followed by the AARNet Directory Service. However, in certain cases we wish to align ourselves with our national ISO body (StandardsAustralia) rather than the Internet where they conflict. In naming, we have chosen to align ourselves with Standards Australia and this document notes the difference in our approach to the Internet guidelines suggested in RFC 1384 [2]. |
|
| |
| RFC 1563 | The text/enriched MIME Content-type |
| |
|
|
MIME [RFC-1341, RFC-1521] defines a format and general framework for the representation of a wide variety of data types in Internet mail.This document defines one particular type of MIME data, the text/enriched type, a refinement of the "text/richtext" type defined in RFC 1341. The text/enriched MIME type is intended to facilitate the wider interoperation of simple enriched text across a wide variety of hardware and software platforms. |
|
| |
| RFC 1564 | DSA Metrics (OSI-DS 34 (v3)) |
| |
| Authors: | P. Barker, R. Hedberg. |
| Date: | January 1994 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1564 |
|
This document defines a set of criteria by which a DSA implementation may be judged. Particular issues covered include conformance to standards; performance; demonstrated interoperability. The intention is that the replies to the questions posed provide a fairly full description of a DSA. Some of the questions will yield answers which are purely descriptive; others, however, are intended to elicit answers which give some measure of the utility of the DSA. The marks awarded for a DSA in each particular area should give a good indication of the DSA's capabilities, and its suitability for particular uses.
Please send comments to the authors or to the discussion group<osi-ds@CS.UCL.AC.UK&rt;. |
|
| |
| RFC 1568 | Simple Network Paging Protocol - Version 1(b) |
| |
|
|
This RFC suggests a simple way for delivering both alphanumeric and numeric pages (one-way) to radio paging terminals. Gateways supporting this protocol, as well as SMTP, have been in use for several months in one nationwide paging firm. One other paging firm is in the process of adopting it.
Earlier versions of this specification were reviewed by IESG members and the IETF's "822 Extensions" Working Group. They preferred an alternate strategy, as discussed under "Relationship to Other IETFWork", below. |
|
| |
| RFC 1569 | Principles of Operation for the TPC.INT Subdomain: Radio Paging -- Technical Procedures |
| |
|
|
This memo describes a technique for radio paging using the Internet mail infrastructure. In particular, this memo focuses on the case in which radio pagers are identified via the international telephone network. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1571 | Telnet Environment Option Interoperability Issues |
| |
|
|
This document describes a method for allowing implementors to ensure that their implementation of the Environment option will be interoperable with as many other implementations as possible, by providing a set of heuristics that can be used to help identify which definitions for VAR and VALUE are being used by the other side of the connection. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1574 | Essential Tools for the OSI Internet |
| |
|
|
This document specifies the following three necessary tools to debug problems in the deployment and maintenance of networks using ISO 8473(CLNP):
- ping or OSI Echo function- traceroute function which uses the OSI Echo function- routing table dump function
These CLNS tools are the basics required for hosts and routers forCLNS network support. It is intended that this document specify the most basic support level required for CLNS hosts and routers.
To support some of the needed tools (ping and traceroute) this memo specifies the mechanism specified in RFC 1575 [3]. |
|
| |
| RFC 1576 | TN3270 Current Practices |
| |
| Authors: | J. Penner. |
| Date: | January 1994 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1576 |
|
This document describes the existing implementation of transferring3270 display terminal data using currently available telnet capabilities. The name traditionally associated with this implementation is TN3270.
Information is provided to aid in the implementation of TN3270 servers as well as client terminal emulators.
The following areas pertaining to TN3270 implementations are covered in this document:
1. the telnet options negotiated to transition from a NVT ASCII state to a TN3270 state ready to process incoming 3270 data stream commands
2. the method for sending and receiving 3270 data
3. the method of handling some special keys known as SYSREQ andATTN using current available telnet commands
4. the events that will transition a TN3270 session back to an NVT session |
|
| |
| RFC 1578 | FYI on Questions and Answers - Answers to Commonly Asked "Primary and Secondary School Internet User" Questions |
| |
|
|
The goal of this FYI RFC, produced by the Internet School Networking(ISN) group in the User Services Area of the Internet EngineeringTask Force (IETF), is to document the questions most commonly asked about the Internet by those in the primary and secondary school community, and to provide pointers to sources which answer those questions. It is directed at educators, school media specialists, and school administrators who are recently connected to the Internet, who are accessing the Internet via dial-up or another means which is not a direct connection, or who are considering an Internet connection as a resource for their schools. |
|
| |
| RFC 1579 | Firewall-Friendly FTP |
| |
| Authors: | S. Bellovin. |
| Date: | February 1994 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1579 |
|
This memo describes a suggested change to the behavior of FTP client programs. No protocol modifications are required, though we outline some that might be useful. |
|
| |
| RFC 1580 | Guide to Network Resource Tools |
| |
|
|
The purpose of this guide is to supply the basic information that anyone on the network needs to try out and begin using tools. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. [FYI 23] |
|
| |
| RFC 1581 | Protocol Analysis for Extensions to RIP to Support Demand Circuits |
| |
| Authors: | G. Meyer. |
| Date: | February 1994 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1581 |
|
As required by Routing Protocol Criteria [1], this report documents the key features of Routing over Demand Circuits on Wide AreaNetworks - RIP [2] and the current implementation experience. |
|
| |
| RFC 1585 | MOSPF: Analysis and Experience |
| |
| Authors: | J. Moy. |
| Date: | March 1994 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1585 |
|
This memo documents how the MOSPF protocol satisfies the requirements imposed on Internet routing protocols by "Internet Engineering TaskForce internet routing protocol standardization criteria" ([RFC1264]).
Please send comments to mospf@gated.cornell.edu. |
|
| |
| RFC 1586 | Guidelines for Running OSPF Over Frame Relay Networks |
| |
| Authors: | O. deSouza, M. Rodrigues. |
| Date: | March 1994 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1586 |
|
This memo specifies guidelines for implementors and users of the OpenShortest Path First (OSPF) routing protocol to bring about improvements in how the protocol runs over frame relay networks. We show how to configure frame relay interfaces in a way that obviates the "full-mesh" connectivity required by current OSPF implementations. This allows for simpler, more economic network designs. These guidelines do not require any protocol changes; they only provide recommendations for how OSPF should be implemented and configured to use frame relay networks efficiently. |
|
| |
| RFC 1588 | White Pages Meeting Report |
| |
| Authors: | J. Postel, C. Anderson. |
| Date: | February 1994 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1588 |
|
This report describes the results of a meeting held at the November IETF (Internet Engineering Task Force) in Houston, TX, on November 2, 1993, to discuss the future of and approaches to a white pages directory services for the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1589 | A Kernel Model for Precision Timekeeping |
| |
| Authors: | D. Mills. |
| Date: | March 1994 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1589 |
|
This memorandum describes an engineering model which implements a precision time-of-day function for a generic operating system. The model is based on the principles of disciplined oscillators and phase-lock loops (PLL) often found in the engineering literature. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1590 | Media Type Registration Procedure |
| |
|
|
Several protocols allow the use of data representing different"media" such as text, images, audio, and video, and within such media different encoding styles, such as (in video) jpeg, gif, ief, and tiff. The Multimedia Internet Message Extensions (MIME) protocol [1] defined several initial types of multimedia data objects, and a procedure for registering additional types with the Internet AssignedNumbers Authority (IANA). Several questions have been raised about the requirements and administrative procedure for registering MIME content-type and subtypes, and the use of these Media Types for other applications. This document addresses these issues and specifies a procedure for the registration of new Media Types (content- type/subtypes). It also generalizes the scope of use of these MediaTypes to make it appropriate to use the same registrations and specifications with other applications. |
|
| |
| RFC 1591 | Domain Name System Structure and Delegation |
| |
| Authors: | J. Postel. |
| Date: | March 1994 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1591 |
|
This memo provides some information on the structure of the names in the Domain Name System (DNS), specifically the top-level domain names; and on the administration of domains. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1593 | SNA APPN Node MIB |
| |
| Authors: | W. McKenzie, J. Cheng. |
| Date: | March 1994 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1593 |
|
This RFC describes IBM's SNMP support for SNA Advanced Peer-to-PeerNetworking (APPN) nodes. |
|
| |
| RFC 1594 | FYI on Questions and Answers - Answers to Commonly asked "New Internet User" Questions |
| |
|
|
This FYI RFC is one of two FYI's called, "Questions and Answers"(Q/A), produced by the User Services Working Group of the InternetEngineering Task Force (IETF). The goal is to document the most commonly asked questions and answers in the Internet. |
|
| |
| RFC 1597 | Address Allocation for Private Internets |
| |
| Authors: | Y. Rekhter, B. Moskowitz, D. Karrenberg, G. de Groot. |
| Date: | March 1994 |
| Formats: | txt json html |
| Obsoleted by: | RFC 1918 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1597 |
|
This RFC describes methods to preserve IP address space by not allocating globally unique IP addresses to hosts private to an enterprise while still permitting full network layer connectivity between all hosts inside an enterprise as well as between all public hosts of different enterprises. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1599 | Summary of 1500-1599 |
| |
| Authors: | M. Kennedy. |
| Date: | January 1997 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1599 |
|
|
|
| |
| RFC 1601 | Charter of the Internet Architecture Board (IAB) |
| |
|
|
This memo documents the composition, selection, roles, and organization of the Internet Architecture Board and its subsidiary organizations. |
|
| |
| RFC 1602 | The Internet Standards Process -- Revision 2 |
| |
| Authors: | Internet Architecture Board, Internet Engineering Steering Group. |
| Date: | March 1994 |
| Formats: | txt json html |
| Obsoletes: | RFC 1310 |
| Obsoleted by: | RFC 2026 |
| Updated by: | RFC 1871 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1602 |
|
This document is a revision of RFC 1310, which defined the official procedures for creating and documenting Internet Standards.
This revision (revision 2) includes the following major changes:
(a) The new management structure arising from the POISED WorkingGroup is reflected. These changes were agreed to by the IETF plenary and by the IAB and IESG in November 1992 and accepted by the ISOC Board of Trustees at their December 1992 meeting.
(b) Prototype status is added to the non-standards track maturity levels (Section 2.4.1).
(c) The Intellectual Property Rights section is completely revised, in accordance with legal advice. Section 5 of this document replaces Sections 5 and 6 of RFC-1310. The new section 5 has been reviewed by legal counsel to the Internet Society.
(d) An appeals procedure is added (Section 3.6).
(e) The wording of sections 1 and 1.2 has been changed to clarify the relationships that exist between the Internet Society and the IAB, the IESG, the IETF, and the Internet Standards process.
(f) An Appendix B has been added, listing the contact points for theRFC editor, the IANA, the IESG, the IAB and the ISOC. The"future issues" are now listed in Appendix C. |
|
| |
| RFC 1603 | IETF Working Group Guidelines and Procedures |
| |
|
|
The Internet Engineering Task Force (IETF) has responsibility for developing and reviewing specifications intended as InternetStandards. IETF activities are organized into working groups (WGs).This document describes the guidelines and procedures for formation and operation of IETF working groups. It describes the formal relationship between IETF participants WG and the InternetEngineering Steering Group (IESG). The basic duties of IETF participants, including WG Chair and IESG Area Directors are defined. |
|
| |
| RFC 1605 | SONET to Sonnet Translation |
| |
| Authors: | W. Shakespeare. |
| Date: | 1 April 1994 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1605 |
|
Because Synchronous Optical Network (SONET) transmits data in frames of bytes, it is fairly easy to envision ways to compress SONET frames to yield higher bandwidth over a given fiber optic link. This memo describes a particular method, SONET Over Novel English Translation(SONNET). |
|
| |
| RFC 1606 | A Historical Perspective On The Usage Of IP Version 9 |
| |
| Authors: | J. Onions. |
| Date: | 1 April 1994 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1606 |
|
This paper reviews the usages of the old IP version protocol. It considers some of its successes and its failures. |
|
| |
| RFC 1607 | A VIEW FROM THE 21ST CENTURY |
| |
| Authors: | V. Cerf. |
| Date: | 1 April 1994 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1607 |
|
This document is a composition of letters discussing a possible future. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1613 | cisco Systems X.25 over TCP (XOT) |
| |
| Authors: | J. Forster, G. Satz, G. Glick, R. Day. |
| Date: | May 1994 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1613 |
|
This memo documents a method of sending X.25 packets over IP internets by encapsulating the X.25 Packet Level in TCP packets. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1614 | Network Access to Multimedia Information |
| |
| Authors: | C. Adie. |
| Date: | May 1994 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1614 |
|
This report summarises the requirements of research and academic network users for network access to multimedia information. It does this by investigating some of the projects planned or currently underway in the community. Existing information systems such asGopher, WAIS and World-Wide Web are examined from the point of view of multimedia support, and some interesting hypermedia systems emerging from the research community are also studied. Relevant existing and developing standards in this area are discussed. The report identifies the gaps between the capabilities of currentlydeployed systems and the user requirements, and proposes further work centred on the World-Wide Web system to rectify this.
The report is in some places very detailed, so it is preceded by an extended summary, which outlines the findings of the report. |
|
| |
| RFC 1615 | Migrating from X.400(84) to X.400(88) |
| |
| Authors: | J. Houttuin, J. Craigie. |
| Date: | May 1994 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1615 |
|
This document compares X.400(88) to X.400(84) and describes what problems can be anticipated in the migration, especially considering the migration from the existing X.400(84) infrastructure created by the COSINE MHS project to an X.400(88) infrastructure. It not only describes the technical complications, but also the effect the transition will have on the end users, especially concerning interworking between end users of the 84 and the 88 services. |
|
| |
| RFC 1616 | X.400(1988) for the Academic and Research Community in Europe |
| |
| Authors: | RARE WG-MSG Task Force 88, E. Huizer, Ed., J. Romaguera, Ed.. |
| Date: | May 1994 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1616 |
|
The report documents the results of a task force on X.400(1988) deployment of the RARE Mails and Messaging Work Group during the period from November 1992 until October 1993. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1617 | Naming and Structuring Guidelines for X.500 Directory Pilots |
| |
| Authors: | P. Barker, S. Kille, T. Lenggenhager. |
| Date: | May 1994 |
| Formats: | txt json html |
| Obsoletes: | RFC 1384 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1617 |
|
Deployment of a Directory will benefit from following certain guidelines. This document defines a number of naming and structuring guidelines focused on White Pages usage. Alignment to these guidelines is recommended for directory pilots. The final version of this document will replace RFC 1384. |
|
| |
| RFC 1620 | Internet Architecture Extensions for Shared Media |
| |
| Authors: | B. Braden, J. Postel, Y. Rekhter. |
| Date: | May 1994 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1620 |
|
The original Internet architecture assumed that each network is labeled with a single IP network number. This assumption may be violated for shared media, including "large public data networks"(LPDNs). The architecture still works if this assumption is violated, but it does not have a means to prevent multiple host- router and router-router hops through the shared medium. This memo discusses alternative approaches to extending the Internet architecture to eliminate some or all unnecessary hops. |
|
| |
| RFC 1624 | 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. |
|
| |
| RFC 1625 | WAIS over Z39.50-1988 |
| |
| Authors: | M. St. Pierre, J. Fullton, K. Gamiel, J. Goldman, B. Kahle, J. Kunze, H. Morris, F. Schiettecatte. |
| Date: | June 1994 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1625 |
|
The purpose of this memo is to initiate a discussion for a migration path of the WAIS technology from Z39.50-1988 Information Retrieval Service Definitions and Protocol Specification for Library Applications [1] to Z39.50-1992 [2] and then to Z39.50-1994 [3]. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1627 | Network 10 Considered Harmful (Some Practices Shouldn't be Codified) |
| |
| Authors: | E. Lear, E. Fair, D. Crocker, T. Kessler. |
| Date: | July 1994 |
| Formats: | txt json html |
| Obsoleted by: | RFC 1918 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1627 |
|
This document restates the arguments for maintaining a unique address space. Concerns for Internet architecture and operations, as well as IETF procedure, are explored. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1628 | UPS Management Information Base |
| |
| Authors: | J. Case, Ed.. |
| Date: | May 1994 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1628 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing uninterruptible power supply (UPS) systems. [STANDARDS-TRACK] |
|
| |
| RFC 1630 | Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web |
| |
| Authors: | T. Berners-Lee. |
| Date: | June 1994 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1630 |
|
This document defines the syntax used by the World-Wide Web initiative to encode the names and addresses of objects on the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1631 | The IP Network Address Translator (NAT) |
| |
|
|
The two most compelling problems facing the IP Internet are IP address depletion and scaling in routing. Long-term and short-term solutions to these problems are being developed. The short-term solution is CIDR (Classless InterDomain Routing). The long-term solutions consist of various proposals for new internet protocols with larger addresses.
It is possible that CIDR will not be adequate to maintain the IPInternet until the long-term solutions are in place. This memo proposes another short-term solution, address reuse, that complementsCIDR or even makes it unnecessary. The address reuse solution is to place Network Address Translators (NAT) at the borders of stub domains. Each NAT box has a table consisting of pairs of local IP addresses and globally unique addresses. The IP addresses inside the stub domain are not globally unique. They are reused in other domains, thus solving the address depletion problem. The globally unique IP addresses are assigned according to current CIDR address allocation schemes. CIDR solves the scaling problem. The main advantage of NAT is that it can be installed without changes to routers or hosts. This memo presents a preliminary design for NAT, and discusses its pros and cons. |
|
| |
| RFC 1632 | A Revised Catalog of Available X.500 Implementations |
| |
|
|
This document is the result of a survey that gathered new or updated descriptions of currently available implementations of X.500, including commercial products and openly available offerings. This document is a revision of RFC 1292. We contacted each contributor inRFC 1292 and requested an update and published the survey template in several mailing lists and obtained new product descriptions.
This document contains detailed description of twenty six (26) X.500 implementations - DSAs, DUAs, and DUA interfaces. |
|
| |
| RFC 1633 | Integrated Services in the Internet Architecture: an Overview |
| |
| Authors: | R. Braden, D. Clark, S. Shenker. |
| Date: | June 1994 |
| Formats: | txt json ps html pdf |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1633 |
|
This memo discusses a proposed extension to the Internet architecture and protocols to provide integrated services, i.e., to support real- time as well as the current non-real-time service of IP. This extension is necessary to meet the growing need for real-time service for a variety of new applications, including teleconferencing, remote seminars, telescience, and distributed simulation.
This memo represents the direct product of recent work by Dave Clark,Scott Shenker, Lixia Zhang, Deborah Estrin, Sugih Jamin, JohnWroclawski, Shai Herzog, and Bob Braden, and indirectly draws upon the work of many others. |
|
| |
| RFC 1634 | Novell IPX Over Various WAN Media (IPXWAN) |
| |
|
|
This document describes how Novell IPX operates over various WAN media. Specifically, it describes the common "IPX WAN" protocolNovell uses to exchange necessary router to router information prior to exchanging standard IPX routing information and traffic over WAN datalinks. This document supercedes RFC 1362 and RFC 1551. The changes from RFC 1551 are to correct a problem in the wording when anRFC 1362 router talks to an RFC 1551 router and to allow numbers to be specified in a Router Name. |
|
| |
| RFC 1635 | How to Use Anonymous FTP |
| |
|
|
This document provides information for the novice Internet user about using the File Transfer Protocol (FTP). It explains what FTP is, what anonymous FTP is, and what an anonymous FTP archive site is. It shows a sample anonymous FTP session. It also discusses common ways files are packaged for efficient storage and transmission. |
|
| |
| RFC 1636 | Report of IAB Workshop on Security in the Internet Architecture - February 8-10, 1994 |
| |
| Authors: | R. Braden, D. Clark, S. Crocker, C. Huitema. |
| Date: | June 1994 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1636 |
|
This document is a report on an Internet architecture workshop, initiated by the IAB and held at USC Information Sciences Institute on February 8-10, 1994. This workshop generally focused on security issues in the Internet architecture.
This document should be regarded as a set of working notes containing ideas about security that were developed by Internet experts in a broad spectrum of areas, including routing, mobility, realtime service, and provider requirements, as well as security. It contains some significant diversity of opinions on some important issues.This memo is offered as one input in the process of developing viable security mechanisms and procedures for the Internet. |
|
| |
| RFC 1640 | The Process for Organization of Internet Standards Working Group (POISED) |
| |
| Authors: | S. Crocker. |
| Date: | June 1994 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1640 |
|
This report, originally prepared in January 1993 provides a summary of the POISED WG, starting from the events leading to the formation of the WG to the end of 1992. Necessarily, this synopsis represents my own perception, particularly for the "prehistory" period. Quite a few people hold strong views about both the overall sequence and specific events. My intent here is to convey as neutral a point of view as possible. |
|
| |
| RFC 1645 | Simple Network Paging Protocol - Version 2 |
| |
|
|
This RFC suggests a simple way for delivering both alphanumeric and numeric pages (one-way) to radio paging terminals. Gateways supporting this protocol, as well as SMTP, have been in use for several months for nationwide paging and messaging. In addition, email filters and SNPP client software for Unix and Windows are available at no cost. Please contact the author for more information.
Earlier versions of this specification were reviewed by IESG members and the "822 Extensions" Working Group. They preferred an alternate strategy, as discussed under "Relationship to Other IETF Work", below. |
|
| |
| RFC 1646 | TN3270 Extensions for LUname and Printer Selection |
| |
| Authors: | C. Graves, T. Butts, M. Angel. |
| Date: | July 1994 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1646 |
|
This document describes protocol extensions to TN3270. There are two extensions outlined in this document. The first defines a way by which a TN3270 client can request a specific device (LUname) from aTN3270 server. The second extension specifies how a TN3270 printer device can be requested by a TN3270 client and the manner in which the 3270 printer status information can be sent to the TN3270 server.Discussions and suggestions for improvements to these enhancements should be sent to the TN3270E Working Group mailing listTN3270E@list.nih.gov . These extensions will be called TN3287 in this document. This information is being provided to members of theInternet community that want to support the 3287 data stream within the TELNET protocol. |
|
| |
| RFC 1649 | Operational Requirements for X.400 Management Domains in the GO-MHS Community |
| |
| Authors: | R. Hagens, A. Hansen. |
| Date: | July 1994 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1649 |
|
The goal of this document is to unite regionally operated X.400 services on the various continents into one GO-MHS Community (as seen from an end-user's point of view). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1656 | BGP-4 Protocol Document Roadmap and Implementation Experience |
| |
|
|
Border Gateway Protocol v4 (BGP-4) [1] is an inter-Autonomous System routing protocol. It is built on experience gained with BGP as defined in RFC-1267 [2] and BGP usage in the connected Internet as described in RFC-1268 [3]. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1667 | Modeling and Simulation Requirements for IPng |
| |
| Authors: | S. Symington, D. Wood, M. Pullen. |
| Date: | August 1994 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1667 |
|
This document was submitted to the IETF IPng area in response to RFC1550. Publication of this document does not imply acceptance by theIPng area of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list. |
|
| |
| RFC 1668 | Unified Routing Requirements for IPng |
| |
| Authors: | D. Estrin, T. Li, Y. Rekhter. |
| Date: | August 1994 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1668 |
|
This document was submitted to the IETF IPng area in response to RFC1550. Publication of this document does not imply acceptance by theIPng area of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list. |
|
| |
| RFC 1669 | Market Viability as a IPng Criteria |
| |
| Authors: | J. Curran. |
| Date: | August 1994 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1669 |
|
This document was submitted to the IETF IPng area in response to RFC1550. Publication of this document does not imply acceptance by theIPng area of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list. |
|
| |
| RFC 1670 | Input to IPng Engineering Considerations |
| |
| Authors: | D. Heagerty. |
| Date: | August 1994 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1670 |
|
This document was submitted to the IETF IPng area in response to RFC1550. Publication of this document does not imply acceptance by theIPng area of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list. |
|
| |
| RFC 1671 | IPng White Paper on Transition and Other Considerations |
| |
| Authors: | B. Carpenter. |
| Date: | August 1994 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1671 |
|
This document was submitted to the IETF IPng area in response to RFC1550. Publication of this document does not imply acceptance by theIPng area of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list. |
|
| |
| RFC 1672 | Accounting Requirements for IPng |
| |
| Authors: | N. Brownlee. |
| Date: | August 1994 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1672 |
|
This document was submitted to the IETF IPng area in response to RFC1550. Publication of this document does not imply acceptance by theIPng area of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list. |
|
| |
| RFC 1673 | Electric Power Research Institute Comments on IPng |
| |
| Authors: | R. Skelton. |
| Date: | August 1994 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1673 |
|
This document was submitted to the IETF IPng area in response to RFC1550. Publication of this document does not imply acceptance by theIPng area of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list. |
|
| |
| RFC 1674 | A Cellular Industry View of IPng |
| |
| Authors: | M. Taylor. |
| Date: | August 1994 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1674 |
|
This memo is a response to RFC 1550, "IP: Next Generation (IPng)White Paper Solicitation". The statements in this paper are intended as input to the technical discussions within IETF, and do not represent any endorsement or commitment on the part of the cellular industry, the Cellular Digital Packet Data (CDPD) consortium of service providers or any of its constituent companies. |
|
| |
| RFC 1675 | Security Concerns for IPng |
| |
| Authors: | S. Bellovin. |
| Date: | August 1994 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1675 |
|
This document was submitted to the IETF IPng area in response to RFC1550. Publication of this document does not imply acceptance by theIPng area of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list. |
|
| |
| RFC 1676 | INFN Requirements for an IPng |
| |
| Authors: | A. Ghiselli, D. Salomoni, C. Vistoli. |
| Date: | August 1994 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1676 |
|
This white paper is sent by INFN network team, the Italian NationalInstitute for nuclear physics, whose network, named INFNet, is a nationwide network founded to provide the access to existing national and international HEP laboratory and to facilitate communications between the researchers. With this paper we would like to emphasize the key points that we would to consider if charged with IPng plan.We do not really expect to add original items to the selection, but we think that it could be useful to submit the opinions and ideas that come from our network experience. |
|
| |
| RFC 1677 | Tactical Radio Frequency Communication Requirements for IPng |
| |
| Authors: | B. Adamson. |
| Date: | August 1994 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1677 |
|
This document was submitted to the IETF IPng area in response to RFC1550. Publication of this document does not imply acceptance by theIPng area of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list. |
|
| |
| RFC 1678 | IPng Requirements of Large Corporate Networks |
| |
| Authors: | E. Britton, J. Tavs. |
| Date: | August 1994 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1678 |
|
This document was submitted to the IETF IPng area in response to RFC1550. Publication of this document does not imply acceptance by theIPng area of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list. This draft summarizes some of the requirements of large corporate networks for the next generation of the Internet protcol suite. |
|
| |
| RFC 1679 | HPN Working Group Input to the IPng Requirements Solicitation |
| |
| Authors: | D. Green, P. Irey, D. Marlow, K. O'Donoghue. |
| Date: | August 1994 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1679 |
|
This document was submitted to the IETF IPng area in response to RFC1550. Publication of this document does not imply acceptance by theIPng area of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list. |
|
| |
| RFC 1680 | IPng Support for ATM Services |
| |
| Authors: | C. Brazdziunas. |
| Date: | August 1994 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1680 |
|
This document was submitted to the IETF IPng area in response to RFC1550. Publication of this document does not imply acceptance by theIPng area of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list. |
|
| |
| RFC 1681 | On Many Addresses per Host |
| |
| Authors: | S. Bellovin. |
| Date: | August 1994 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1681 |
|
This document was submitted to the IETF IPng area in response to RFC1550. Publication of this document does not imply acceptance by theIPng area of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list. |
|
| |
| RFC 1682 | IPng BSD Host Implementation Analysis |
| |
| Authors: | J. Bound. |
| Date: | August 1994 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1682 |
|
This document was submitted to the IETF IPng area in response to RFC1550. Publication of this document does not imply acceptance by theIPng area of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list. |
|
| |
| RFC 1683 | Multiprotocol Interoperability In IPng |
| |
| Authors: | R. Clark, M. Ammar, K. Calvert. |
| Date: | August 1994 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1683 |
|
This document was submitted to the IETF IPng area in response to RFC1550. Publication of this document does not imply acceptance by theIPng area of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list. |
|
| |
| RFC 1684 | Introduction to White Pages Services based on X.500 |
| |
| Authors: | P. Jurg. |
| Date: | August 1994 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1684 |
|
This document aims at organisations who are using local and global electronic communication on a day to day basis and for whom using an electronic White Pages Service is therefore indispensable.
The document provides an introduction to the international ITU-T(formerly CCITT) X.500 and ISO 9594 standard, which is particularly suited for providing an integrated local and global electronic WhitePages Service.
In addition a short overview of the experience gained from theParadise X.500 pilot is given. References to more detailed information are included.
The document should be useful for managers of the above mentioned organisations who need to get the necessary executive commitment for making the address information of their organisation available by means of X.500. |
|
| |
| RFC 1685 | Writing X.400 O/R Names |
| |
| Authors: | H. Alvestrand. |
| Date: | August 1994 |
| Formats: | txt json html |
| Also: | RTR_0012 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1685 |
|
There is a need for human beings who use X.400 systems to be able to write down O/R names in a uniform way. This memo is a discussion of this topic. This memo provides information for the Internet Community. It does not specify an Internet Standard of any kind. |
|
| |
| RFC 1686 | IPng Requirements: A Cable Television Industry Viewpoint |
| |
| Authors: | M. Vecchi. |
| Date: | August 1994 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1686 |
|
This document was submitted to the IETF IPng area in response to RFC1550. Publication of this document does not imply acceptance by theIPng area of any ideas expressed within. The statements in this paper are intended as input to the technical discussions within IETF, and do not represent any endorsement or commitment on the part of the cable television industry or any of its companies. Comments should be submitted to the big-internet@munnari.oz.au mailing list. |
|
| |
| RFC 1687 | A Large Corporate User's View of IPng |
| |
| Authors: | E. Fleischman. |
| Date: | August 1994 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1687 |
|
This document was submitted to the IETF IPng area in response to RFC1550. Publication of this document does not imply acceptance by theIPng area of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list. |
|
| |
| RFC 1688 | IPng Mobility Considerations |
| |
| Authors: | W. Simpson. |
| Date: | August 1994 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1688 |
|
This document was submitted to the IPng Area in response to RFC 1550.Publication of this document does not imply acceptance by the IPngArea of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list. This RFC specifies criteria related to mobility for consideration in design and selection of the Next Generation of IP. |
|
| |
| RFC 1689 | A Status Report on Networked Information Retrieval: Tools and Groups |
| |
|
|
The purpose of this report is to increase the awareness of NetworkedInformation Retrieval by bringing together in one place information about the various networked information retrieval tools, their developers, interested organisations, and other activities that relate to the production, dissemination, and support of NIR tools.NIR Tools covered include Archie, WAIS, gopher and World Wide Web. |
|
| |
| RFC 1690 | Introducing the Internet Engineering and Planning Group (IEPG) |
| |
| Authors: | G. Huston. |
| Date: | August 1994 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1690 |
|
This memo introduces the IEPG to the Internet Community. The IEPG is an Internet Service Operators' forum, intended to assist ServiceOperators to coordinate in operational aspects of managing Internet services. |
|
| |
| RFC 1691 | The Document Architecture for the Cornell Digital Library |
| |
| Authors: | W. Turner. |
| Date: | August 1994 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1691 |
|
This memo defines an architecture for the storage and retrieval of the digital representations for books, journals, photographic images, etc., which are collected in a large organized digital library.
Two unique features of this architecture are the ability to generate reference documents and the ability to create multiple views of a document. |
|
| |
| RFC 1698 | Octet Sequences for Upper-Layer OSI to Support Basic Communications Applications |
| |
| Authors: | P. Furniss. |
| Date: | October 1994 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1698 |
|
This document states particular octet sequences that comprise the OSI upper-layer protocols (Session, Presentation and ACSE) when used to support applications with "basic communications requirements". These include OSI application protocols such as X.400 P7 and DirectoryAccess Protocol, and "migrant" protocols, originally defined for use over other transports.
As well as the octet sequences which are the supporting layer headers(and trailers) around the application data, this document includes some tutorial material on the OSI upper layers.
An implementation that sends the octet sequences given here, and interprets the equivalent protocol received, will be able to interwork with an implementation based on the base standard, when both are being used to support an appropriate application protocol. |
|
| |
| RFC 1699 | Summary of 1600-1699 |
| |
| Authors: | J. Elliott. |
| Date: | January 1997 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1699 |
|
|
|
| |
| RFC 1701 | Generic Routing Encapsulation (GRE) |
| |
| Authors: | S. Hanks, T. Li, D. Farinacci, P. Traina. |
| Date: | October 1994 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1701 |
|
This document specifies a protocol for performing encapsulation of an arbitrary network layer protocol over another arbitrary network layer protocol. |
|
| |
| RFC 1702 | Generic Routing Encapsulation over IPv4 networks |
| |
| Authors: | S. Hanks, T. Li, D. Farinacci, P. Traina. |
| Date: | October 1994 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1702 |
|
This memo addresses the case of using IP as the delivery protocol or the payload protocol and the special case of IP as both the delivery and payload. This memo also describes using IP addresses and autonomous system numbers as part of a GRE source route. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1703 | Principles of Operation for the TPC.INT Subdomain: Radio Paging -- Technical Procedures |
| |
|
|
This memo describes a technique for radio paging using the Internet mail infrastructure. In particular, this memo focuses on the case in which radio pagers are identified via the international telephone network. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1704 | On Internet Authentication |
| |
| Authors: | N. Haller, R. Atkinson. |
| Date: | October 1994 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1704 |
|
This document describes a spectrum of authentication technologies and provides suggestions to protocol developers on what kinds of authentication might be suitable for some kinds of protocols and applications used in the Internet. This document provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1705 | Six Virtual Inches to the Left: The Problem with IPng |
| |
| Authors: | R. Carlson, D. Ficarella. |
| Date: | October 1994 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1705 |
|
This document was submitted to the IETF IPng area in response to RFC1550. Publication of this document does not imply acceptance by theIPng area of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list. |
|
| |
| RFC 1708 | NTP PICS PROFORMA - For the Network Time Protocol Version 3 |
| |
| Authors: | D. Gowin. |
| Date: | October 1994 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1708 |
|
This RFC describes a PICS Proforma translated into an Internet acceptable form. The Original document was developed according toISO 9646 for conformance test purposes. This document is intended for both developers and users of the NTP (Network Time Protocol).This document contains specific information and performance characteristics for the use of NTP within the context of Internet usage. It is suggested, that users wishing to use the synchronization capabilities of the Internet abide by the characteristics set within this document.
For more information please contact Dr. David Mills at Mills@udel.edu or review RFC 1305 for more information. |
|
| |
| RFC 1709 | K-12 Internetworking Guidelines |
| |
|
|
The K-12 community traditionally has not had this level of staffing available for telecommunications planning. This document is intended to bridge that gap and provides a recommended technical direction, an introduction to the role the Internet now plays in K-12 education and technical guidelines for building a campus data communications infrastructure that provides internetworking services and connections to the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1710 | Simple Internet Protocol Plus White Paper |
| |
| Authors: | R. Hinden. |
| Date: | October 1994 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1710 |
|
This document was submitted to the IETF IPng area in response to RFC1550. Publication of this document does not imply acceptance by theIPng area of any ideas expressed within. Comments should be submitted to the author and/or the sipp@sunroof.eng.sun.com mailing list. |
|
| |
| RFC 1711 | Classifications in E-mail Routing |
| |
| Authors: | J. Houttuin. |
| Date: | October 1994 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1711 |
|
This paper presents a classification for e-mail routing issues. It clearly defines commonly used terminology such as static routing, store-and-forward routing, source routing and others. Real life examples show which routing options are used in existing projects.
The goal is to define all terminology in one reference paper. This will also help relatively new mail system managers to understand the issues and make the right choices. The reader is expected to already have a solid understanding of general networking terminology.
In this paper, the word Message Transfer Agent (MTA) is used to describe a routing entity, which can be an X.400 MTA, a UNIX mailer, or any other piece of software performing mail routing functions. AnMTA processes the so called envelope information of a message. The term User Agent (UA) is used to describe a piece of software performing user related mail functions. It processes the contents of a message's envelope, i.e., the header fields and body parts. |
|
| |
| RFC 1713 | Tools for DNS debugging |
| |
|
|
Although widely used (and most of the times unnoticed), DNS (DomainName System) is too much overlooked, in the sense that people, especially administrators, tend to ignore possible anomalies as long as applications that need name-to-address mapping continue to work.This document presents some tools available for domain administrators to detect and correct those anomalies. |
|
| |
| RFC 1714 | Referral Whois Protocol (RWhois) |
| |
|
|
This memo describes version 1.0 of the client/server interaction ofRWhois. RWhois provides a distributed system for the display of hierarchical information. This system is hierarchical by design, allowing for the reduction of a query, and the referral of the user closer to the maintainer of the information. |
|
| |
| RFC 1715 | The H Ratio for Address Assignment Efficiency |
| |
|
|
This document was submitted to the IETF IPng area in response to RFC1550. Publication of this document does not imply acceptance by theIPng area of any ideas expressed within. Comments should be submitted to the author and/or the sipp@sunroof.eng.sun.com mailing list. |
|
| |
| RFC 1716 | Towards Requirements for IP Routers |
| |
| Authors: | P. Almquist, F. Kastenholz. |
| Date: | November 1994 |
| Formats: | txt html json |
| Obsoleted by: | RFC 1812 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1716 |
|
The goal of this work is to replace RFC-1009, Requirements for Internet Gateways ([INTRO:1]) with a new document. It defines and discusses requirements for devices which perform the network layer forwarding function of the Internet protocol suite. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1718 | The Tao of IETF - A Guide for New Attendees of the Internet Engineering Task Force |
| |
|
|
Over the last two years, the attendance at Internet Engineering TaskForce (IETF) plenary meetings has grown phenomenally. Approximately one third of the attendees are new to the IETF at each meeting, and many of those go on to become regular attendees. When the meetings were smaller, it wasn't very difficult for a newcomer to get into the swing of things. Today, however, a newcomer meets many more new people, some previously known only as the authors of documents or thought provoking e-mail messages.
The purpose of this For Your Information (FYI) RFC is to explain to the newcomers how the IETF works. This will give them a warm, fuzzy feeling and enable them to make the meeting more productive for everyone. This FYI will also provide the mundane bits of information which everyone who attends an IETF meeting should know. |
|
| |
| RFC 1719 | A Direction for IPng |
| |
| Authors: | P. Gross. |
| Date: | December 1994 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1719 |
|
This document was submitted to the IPng Area in response to RFC 1550.Publication of this document does not imply acceptance by the IPngArea of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list. This RFC specifies criteria related to mobility for consideration in design and selection of the Next Generation of IP. |
|
| |
| RFC 1721 | RIP Version 2 Protocol Analysis |
| |
|
|
As required by Routing Protocol Criteria (RFC 1264), this report documents the key features of the RIP-2 protocol and the current implementation experience. This report is a prerequisite to advancing RIP-2 on the standards track. |
|
| |
| RFC 1726 | Technical Criteria for Choosing IP The Next Generation (IPng) |
| |
| Authors: | C. Partridge, F. Kastenholz. |
| Date: | December 1994 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1726 |
|
This document was submitted to the IPng Area in response to RFC 1550.Publication of this document does not imply acceptance by the IPngArea of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list. This RFC specifies criteria related to mobility for consideration in design and selection of the Next Generation of IP. |
|
| |
| RFC 1727 | A Vision of an Integrated Internet Information Service |
| |
| Authors: | C. Weider, P. Deutsch. |
| Date: | December 1994 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1727 |
|
This paper lays out a vision of how Internet information services might be integrated over the next few years, and discusses in some detail what steps will be needed to achieve this integration. |
|
| |
| RFC 1728 | Resource Transponders |
| |
| Authors: | C. Weider. |
| Date: | December 1994 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1728 |
|
Although a number of systems have been created in the last several years to provide resource location and navigation on the Internet, the information contained in these systems must be maintained and updated by hand. This paper describes an automatic mechanism, the resource transponder, for maintaining resource location information. |
|
| |
| RFC 1729 | Using the Z39.50 Information Retrieval Protocol |
| |
| Authors: | C. Lynch. |
| Date: | December 1994 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1729 |
|
This memo describes an approach to the implementation of the ANSI/NISO Z39.50-1992 Standard for Information Retrieval in the TCP/IP environment which is currently in wide use by the Z39.50 implementor community. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1732 | IMAP4 Compatibility with IMAP2 and IMAP2bis |
| |
| Authors: | M. Crispin. |
| Date: | December 1994 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1732 |
|
This is a summary of hints and recommendations to enable an IMAP4 implementation to interoperate with implementations that conform to earlier specifications. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1733 | Distributed Electronic Mail Models in IMAP4 |
| |
| Authors: | M. Crispin. |
| Date: | December 1994 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1733 |
|
There are three fundamental models of client/server email: offline, online, and disconnected use. IMAP4 can be used in any one of these three models. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1736 | Functional Recommendations for Internet Resource Locators |
| |
| Authors: | J. Kunze. |
| Date: | February 1995 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1736 |
|
This document specifies a minimum set of requirements for Internet resource locators, which convey location and access information for resources. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1737 | Functional Requirements for Uniform Resource Names |
| |
| Authors: | K. Sollins, L. Masinter. |
| Date: | December 1994 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1737 |
|
This document specifies a minimum set of requirements for a kind of Internet resource identifier known as Uniform Resource Names (URNs). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1739 | A Primer On Internet and TCP/IP Tools |
| |
| Authors: | G. Kessler, S. Shepard. |
| Date: | December 1994 |
| Formats: | txt json html |
| Obsoleted by: | RFC 2151 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1739 |
|
This memo is an introductory guide to some of the TCP/IP and Internet tools and utilities that allow users to access the wide variety of information on the network, from determining if a particular host is up to viewing a multimedia thesis on foreign policy. It also describes discussion lists accessible from the Internet, ways to obtain Internet documents, and resources that help users weave their way through the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1741 | MIME Content Type for BinHex Encoded Files |
| |
| Authors: | P. Faltstrom, D. Crocker, E. Fair. |
| Date: | December 1994 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1741 |
|
This memo describes the format to use when sending BinHex4.0 files via MIME [BORE93]. The format is compatible with existing mechanisms for distributing Macintosh files. Only when available software and/or user practice dictates, should this method be employed. It is recommended to use application/applefile [FALT94] for maximum interoperability. |
|
| |
| RFC 1744 | Observations on the Management of the Internet Address Space |
| |
| Authors: | G. Huston. |
| Date: | December 1994 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1744 |
|
This memo examines some of the issues associated with the current management practices of the Internet IPv4 address space, and examines the potential outcomes of these practices as the unallocated address pool shrinks in size. Possible modifications to the management practices are examined, and potential outcomes considered. Some general conclusions are drawn, and the relevance of these conclusions to the matter of formulation of address management policies for IPv6 are noted. |
|
| |
| RFC 1746 | Ways to Define User Expectations |
| |
| Authors: | B. Manning, D. Perkins. |
| Date: | December 1994 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1746 |
|
This paper covers basic fundamentals that must be understood when one defines, interprets, or implements methods to control user expectations on or over the Internet. |
|
| |
| RFC 1750 | Randomness Recommendations for Security |
| |
| Authors: | D. Eastlake 3rd, S. Crocker, J. Schiller. |
| Date: | December 1994 |
| Formats: | txt html json |
| Obsoleted by: | RFC 4086 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1750 |
|
Security systems today are built on increasingly strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. The sophisticated attacker of these security systems may find it easier to reproduce the environment that produced the secret quantities, searching the resulting small set of possibilities, than to locate the quantities in the whole of the number space.
Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This paper points out many pitfalls in using traditional pseudo-random number generation techniques for choosing such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available. And it gives examples of how large such quantities need to be for some particular applications. |
|
| |
| RFC 1751 | A Convention for Human-Readable 128-bit Keys |
| |
| Authors: | D. McDonald. |
| Date: | December 1994 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1751 |
|
This memo proposes a convention for use with Internet applications & protocols using 128-bit cryptographic keys. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1753 | IPng Technical Requirements Of the Nimrod Routing and Addressing Architecture |
| |
| Authors: | N. Chiappa. |
| Date: | December 1994 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1753 |
|
This document was submitted to the IETF IPng area in response to RFC1550. Publication of this document does not imply acceptance by theIPng area of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list.
This document presents the requirements that the Nimrod routing and addressing architecture has upon the internetwork layer protocol. To be most useful to Nimrod, any protocol selected as the IPng should satisfy these requirements. Also presented is some background information, consisting of i) information about architectural and design principles which might apply to the design of a new internetworking layer, and ii) some details of the logic and reasoning behind particular requirements. |
|
| |
| RFC 1754 | IP over ATM Working Group's Recommendations for the ATM Forum's Multiprotocol BOF Version 1 |
| |
| Authors: | M. Laubach. |
| Date: | January 1995 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1754 |
|
This document represents an initial list of requirements submitted to the ATM Forum's Multiprotocol BOF for the operation of IP over ATM networks as determined by the IETF IP over ATM Working Group and other working groups. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1758 | NADF Standing Documents: A Brief Overview |
| |
| Authors: | The North American Directory Forum. |
| Date: | February 1995 |
| Formats: | txt html json |
| Obsoletes: | RFC 1417 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1758 |
|
The purpose of this document is to provide a brief overview of the NADF's Standing Document series. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1760 | The S/KEY One-Time Password System |
| |
| Authors: | N. Haller. |
| Date: | February 1995 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1760 |
|
This document describes the S/KEY* One-Time Password system as released for public use by Bellcore and as described in reference[3]. A reference implementation and documentation are available by anonymous ftp from ftp.bellcore.com in the directories pub/nmh/... |
|
| |
| RFC 1761 | Snoop Version 2 Packet Capture File Format |
| |
| Authors: | B. Callaghan, R. Gilligan. |
| Date: | February 1995 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1761 |
|
This paper describes the file format used by "snoop", a packet monitoring and capture program developed by Sun. This paper is provided so that people can write compatible programs to generate and interpret snoop packet capture files. |
|
| |
| RFC 1769 | Simple Network Time Protocol (SNTP) |
| |
|
|
This memorandum describes the Simple Network Time Protocol (SNTP), which is an adaptation of the Network Time Protocol (NTP) used to synchronize computer clocks in the Internet. SNTP can be used when the ultimate performance of the full NTP implementation described inRFC-1305 is not needed or justified. It can operate in both unicast modes (point to point) and broadcast modes (point to multipoint). It can also operate in IP multicast mode where this service is available. SNTP involves no change to the current or previous NTP specification versions or known implementations, but rather a clarification of certain design features of NTP which allow operation in a simple, stateless remote-procedure call (RPC) mode with accuracy and reliability expectations similar to the UDP/TIME protocol described in RFC-868.
This memorandum obsoletes RFC-1361 of the same title. Its purpose is to explain the protocol model for operation in broadcast mode, to provide additional clarification in some places and to correct a few typographical errors. A working knowledge of the NTP Version 3 specification RFC-1305 is not required for an implementation of SNTP.Distribution of this memorandum is unlimited. |
|
| |
| RFC 1773 | Experience with the BGP-4 protocol |
| |
|
|
The purpose of this memo is to document how the requirements for advancing a routing protocol to Draft Standard have been satisfied by Border Gateway Protocol version 4 (BGP-4). This report documents experience with BGP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1774 | BGP-4 Protocol Analysis |
| |
| Authors: | P. Traina, Ed.. |
| Date: | March 1995 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1774 |
|
The purpose of this report is to document how the requirements for advancing a routing protocol to Draft Standard have been satisfied by the Border Gateway Protocol version 4 (BGP-4). This report summarizes the key features of BGP, and analyzes the protocol with respect to scaling and performance. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1775 | To Be "On" the Internet |
| |
| Authors: | D. Crocker. |
| Date: | March 1995 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1775 |
|
The Internet permits different levels of access for consumers and providers of service. The nature of those differences is quite important in the capabilities They afford. Hence, it is appropriate to provide terminology that distinguishes among the range, so that the Internet community can gain some clarity when distinguishing whether a user (or an organization) is "on" the Internet. This document suggests four terms, for distinguishing the major classes of access. |
|
| |
| RFC 1776 | The Address is the Message |
| |
| Authors: | S. Crocker. |
| Date: | 1 April 1995 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1776 |
|
Declaring that the address is the message, the IPng WG has selected a packet format which includes 1696 bytes of address space. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1785 | TFTP Option Negotiation Analysis |
| |
|
|
The TFTP option negotiation mechanism, proposed in [1], is a backward-compatible extension to the TFTP protocol, defined in [2].It allows file transfer options to be negotiated prior to the transfer using a mechanism which is consistent with TFTP's RequestPacket format. The mechanism is kept simple by enforcing a request- respond-acknowledge sequence, similar to the lock-step approach taken by TFTP itself.
This document was written to allay concerns that the presence of options in a TFTP Request packet might cause pathological behavior on servers which do not support TFTP option negotiation. |
|
| |
| RFC 1786 | Representation of IP Routing Policies in a Routing Registry (ripe-81++) |
| |
| Authors: | T. Bates, E. Gerich, L. Joncheray, J-M. Jouanigot, D. Karrenberg, M. Terpstra, J. Yu. |
| Date: | March 1995 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1786 |
|
This document was originally published as a RIPE document known as ripe-181 but is also being published as an Informational RFC to reach a larger audience than its original scope. It has received community wide interest and acknowledgment throughout the Internet service provider community and will be used as the basic starting point for future work on Internet Routing Registries and routing policy representation. It can also be referred to as ripe-81++. This document is an update to the original `ripe-81'[1] proposal for representing and storing routing polices within the RIPE database. It incorporates several extensions proposed by Merit Inc.[2] and gives details of a generalized IP routing policy representation to be used by all Internet routing registries. It acts as both tutorial and provides details of database objects and attributes that use and make up a routing registry. |
|
| |
| RFC 1787 | Routing in a Multi-provider Internet |
| |
| Authors: | Y. Rekhter. |
| Date: | April 1995 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1787 |
|
This document was prepared by the author on behalf of the InternetArchitecture Board (IAB). It is offered by the IAB to stimulate discussion.
Over the past few years the Internet has undergone significant changes. Among them is the emergence of multiple Network ServiceProviders, where resources that provide Internet-wide IP connectivity(routers, links) are controlled by different organizations. This document presents some of the issues related to network layer routing in a multi-provider Internet, and specifically to the unicast routing. |
|
| |
| RFC 1789 | INETPhone: Telephone Services and Servers on Internet |
| |
| Authors: | C. Yang. |
| Date: | April 1995 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1789 |
|
INETPhone is a true telephone service through the Internet. It integrates the local telephone networks and the Internet usingINETPhone servers. Thus a long distance call can be split into two local calls and an Internet connection, which is transparent to end users. Such a phone service through Internet will be a major step towards integrated services on Internet. In order to support theINETPhone and lay down the ground rules of the service, a scheme of"open partnership" is proposed, so that the entire Internet community can have the equal opportunity and benefits from the INETPhone service. |
|
| |
| RFC 1790 | An Agreement between the Internet Society and Sun Microsystems, Inc |
| |
| Authors: | in the Matter of ONC RPC and XDR Protocols. V. Cerf. |
| Date: | April 1995 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1790 |
|
This RFC is an official public record of an agreement between SUN Microsystems and the Internet Society. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. |
|
| |
| RFC 1794 | DNS Support for Load Balancing |
| |
| Authors: | T. Brisco. |
| Date: | April 1995 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1794 |
|
This RFC is meant to first chronicle a foray into the IETF DNS Working Group, discuss other possible alternatives to provide/simulate load balancing support for DNS, and to provide an ultimate, flexible solution for providing DNS support for balancing loads of many types. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1795 | Data Link Switching: Switch-to-Switch Protocol AIW DLSw RIG: DLSw Closed Pages, DLSw Standard Version 1 |
| |
|
|
This RFC describes use of Data Link Switching over TCP/IP. The RFC is being distributed to members of the Internet community in order to solicit their reactions to the proposals contained in it. While the issues discussed may not be directly relevant to the research problems of the Internet, they may be interesting to a number of researchers and Implementers.
This RFC was created as a joint effort of the Advanced Peer-to-PeerNetworking (APPN) Implementers Workshop (AIW) Data Link Switching(DLSw) Related Interest Group (RIG). The APPN Implementers Workshop is a group sponsored by IBM and consists of representatives of member companies implementing current and future IBM Networking interoperable products. The DLSw Related Interest Group was formed in this forum in order to produce a single version of the Switch toSwitch Protocol (SSP) which could be implemented by all vendors, which would fix documentation problems with the existing RFC 1434, and which would enhance and evolve the protocol to add new functions and features.
This document is based on RFC 1434. This document contains significant changes to RFC 1434 and therefore obsoletes that document.
Any questions or comments relative to the contents of this RFC should be sent to the following Internet address: aiw-dlsw@networking.raleigh.ibm.com.
NOTE 1: This is a widely subscribed mailing list and messages sent to this address will be sent to all members of the DLSw mailing list.For specific questions relating to subscribing to the AIW and any of it's working groups send email to: appn@vnet.ibm.com
Information regarding all of the AIW working groups and the work they are producing can be obtained by copying, via anonymous ftp, the file aiwinfo.psbin or aiwinfo.txt from the Internet host networking.raleigh.ibm.com, located in directory aiw.
NOTE 2: These mailing lists and addresses are subject to change. |
|
| |
| RFC 1796 | Not All RFCs are Standards |
| |
| Authors: | C. Huitema, J. Postel, S. Crocker. |
| Date: | April 1995 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1796 |
|
This document discusses the relationship of the Request for Comments(RFCs) notes to Internet Standards. |
|
| |
| RFC 1799 | Request for Comments Summary RFC Numbers 1700-1799 |
| |
| Authors: | M. Kennedy. |
| Date: | January 1997 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1799 |
|
|
|
| |
| RFC 1802 | Introducing Project Long Bud: Internet Pilot Project for the Deployment of X.500 Directory Information in Support of X.400 Routing |
| |
| Authors: | H. Alvestrand, K. Jordan, S. Langlois, J. Romaguera. |
| Date: | June 1995 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1802 |
|
The Internet X.400 community (i.e., GO-MHS) currently lacks a distributed mechanism providing dynamic updating and management of message routing information. The IETF MHS-DS Working Group has specified an approach for X.400 Message Handling Systems to perform message routing using OSI Directory Services. The MHS-DS approach has been successfully tested in a number of local environments.
This memo describes a proposed Internet Pilot Project that seeks to prove the MHS-DS approach on a larger scale. The results of this pilot will then be used to draw up recommendations for a global deployment. |
|
| |
| RFC 1803 | Recommendations for an X.500 Production Directory Service |
| |
| Authors: | R. Wright, A. Getchell, T. Howes, S. Sataluri, P. Yee, W. Yeong. |
| Date: | June 1995 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1803 |
|
This document contains a set of basic recommendations for a country- level X.500 DSA. These recommendations can only be considered a starting point in the quest to create a global production qualityX.500 infrastructure. For there to be a true "production quality"X.500 infrastructure more work must be done, including a transition from the 1988 X.500 (plus some Internet extensions) to the 1993 X.500 standard (including the '93 replication and knowledge model). This document does not discuss this transition. |
|
| |
| RFC 1805 | Location-Independent Data/Software Integrity Protocol |
| |
| Authors: | A. Rubin. |
| Date: | June 1995 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1805 |
|
This memo describes a protocol for adding integrity assurance to files that are distributed across the Internet. This protocol is intended for the distribution of software, data, documents, and any other file that is subject to malicious modification. The protocol described here is intended to provide assurances of integrity and time. A trusted third party is required. |
|
| |
| RFC 1807 | A Format for Bibliographic Records |
| |
|
|
This RFC defines a format for bibliographic records describing technical reports. This format is used by the Cornell UniversityDienst protocol and the Stanford University SIFT system. The original RFC (RFC 1357) was written by D. Cohen, ISI, July 1992.This is a revision of RFC 1357. New fields include handle, other_access, keyword, and withdraw. |
|
| |
| RFC 1809 | Using the Flow Label Field in IPv6 |
| |
| Authors: | C. Partridge. |
| Date: | June 1995 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1809 |
|
The purpose of this memo is to distill various opinions and suggestions of the End-to-End Research Group regarding the handling of Flow Labels into a set of suggestions for IPv6. This memo is for information purposes only and is not one of the IPv6 specifications.Distribution of this memo is unlimited. |
|
| |
| RFC 1810 | Report on MD5 Performance |
| |
| Authors: | J. Touch. |
| Date: | June 1995 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1810 |
|
MD5 is an authentication algorithm, which has been proposed as the default authentication option in IPv6. When enabled, the MD5 algorithm operates over the entire data packet, including header.This RFC addresses how fast MD5 can be implemented in software and hardware, and whether it supports currently available IP bandwidth.MD5 can be implemented in existing hardware technology at 256 Mbps, and in software at 87 Mbps. These rates cannot support current IP rates, e.g., 100 Mbps TCP and 130 Mbps UDP over ATM. If MD5 cannot support existing network bandwidth using existing technology, it will not scale as network speeds increase in the future. This RFC is intended to alert the IP community about the performance limitations of MD5, and to suggest that alternatives be considered for use in high speed IP implementations. |
|
| |
| RFC 1811 | U.S |
| |
| Authors: | Government Internet Domain Names. Federal Networking Council. |
| Date: | June 1995 |
| Formats: | txt json html |
| Obsoleted by: | RFC 1816 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1811 |
|
This document describes the registration policies for the top-level domain ".GOV". Thus far, Federal Agencies and their subsidiaries have registered without any guidance. This has resulted in multiple registrations for Federal Agencies and naming schemes that do not facilitate responsiveness to the public. This document fixes this by restricting registrations to coincide with the approved structure of the US government. The document cited, FIPS 95-1, provides a standard recognized structure into which domain registrations for top-level domains. The IANA requires that an organization/country apply for and get a 2 letter code from ISO/ITU (e.g., US for UnitedStates) for additional top-level registration.
As a side effect, this reduces the number of .GOV level registrations and reduces the workload on the Internic. |
|
| |
| RFC 1813 | NFS Version 3 Protocol Specification |
| |
| Authors: | B. Callaghan, B. Pawlowski, P. Staubach. |
| Date: | June 1995 |
| Formats: | txt html json |
| Also: | RFC 1094 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1813 |
|
This paper describes the NFS version 3 protocol. This paper is provided so that people can write compatible implementations. |
|
| |
| RFC 1814 | Unique Addresses are Good |
| |
| Authors: | E. Gerich. |
| Date: | June 1995 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1814 |
|
The IAB suggests that while RFC 1597 establishes reserved IP address space for the use of private networks which are isolated and will remain isolated from the Internet, any enterprise which anticipates external connectivity to the Internet should apply for a globally unique address from an Internet registry or service provider. |
|
| |
| RFC 1815 | Character Sets ISO-10646 and ISO-10646-J-1 |
| |
| Authors: | M. Ohta. |
| Date: | July 1995 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1815 |
|
Though the ISO character set standard of ISO 10646 is specified reasonably well about European characters, it is not so useful in an fully internationalized environment.
For the practical use of ISO 10646, a lot of external profiling such as restriction of characters, restriction of combination of characters and addition of language information is necessary.
This memo provides information on such profiling, along with charset names to each profiled instance.
Though all the effort is done to make the resulting charset as useful10646 based charset as possible, the result is not so good. So, the charsets defined in this memo are only for reference purpose and its use for practical purpose is strongly discouraged. |
|
| |
| RFC 1816 | U.S |
| |
| Authors: | Government Internet Domain Names. Federal Networking Council. |
| Date: | August 1995 |
| Formats: | txt html json |
| Obsoletes: | RFC 1811 |
| Obsoleted by: | RFC 2146 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1816 |
|
This memo provides an update and clarification to RFC 1811. This document describes the registration policies for the top-level domain".GOV". Thus far, Federal Agencies and their subsidiaries have registered without any guidance. This has resulted in multiple registrations for Federal Agencies and naming schemes that do not facilitate responsiveness to the public. This document fixes this by restricting registrations to coincide with the approved structure of the US government. The document cited, FIPS 95-1, provides a standard recognized structure into which domain registrations for.GOV can be fit. This policy is exactly comparable to that for the top-level domains. The IANA requires that an organization/country apply for and get a 2 letter code from ISO/ITU (e.g., US for UnitedStates) for additional top-level registration.
As a side effect, this reduces the number of .GOV level registrations and reduces the workload on the Internic. |
|
| |
| RFC 1820 | Multimedia E-mail (MIME) User Agent Checklist |
| |
|
|
This document presents a checklist to facilitate evaluation of MIME capable User Agents. Access to a MIME test-responder, that generates test-messages is described. |
|
| |
| RFC 1821 | Integration of Real-time Services in an IP-ATM Network Architecture |
| |
| Authors: | M. Borden, E. Crawley, B. Davie, S. Batsell. |
| Date: | August 1995 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1821 |
|
The IETF is currently developing an integrated service model which is designed to support real-time services on the Internet.Concurrently, the ATM Forum is developing Asynchronous Transfer Mode networking which similarly provides real-time networking support. The use of ATM in the Internet as a link layer protocol is already occurring, and both the IETF and the ATM Forum are producing specifications for IP over ATM. The purpose of this paper is to provide a clear statement of what issues need to be addressed in interfacing the IP integrated services environment with an ATM service environment so as to create a seamless interface between the two in support of end users desiring real-time networking services. |
|
| |
| RFC 1822 | A Grant of Rights to Use a Specific IBM patent with Photuris |
| |
| Authors: | J. Lowe. |
| Date: | August 1995 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1822 |
|
This Request for Comments records a grant by IBM Corporation to permit the conditional free use of one of its patents. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1823 | The LDAP Application Program Interface |
| |
| Authors: | T. Howes, M. Smith. |
| Date: | August 1995 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1823 |
|
This document defines a C language application program interface to the lightweight directory access protocol (LDAP). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1824 | The Exponential Security System TESS: An Identity-Based Cryptographic Protocol for Authenticated Key-Exchange (E.I.S.S.-Report 1995/4) |
| |
| Authors: | H. Danisch. |
| Date: | August 1995 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1824 |
|
This informational RFC describes the basic mechanisms and functions of an identity based system for the secure authenticated exchange of cryptographic keys, the generation of signatures, and the authentic distribution of public keys. |
|
| |
| RFC 1834 | Whois and Network Information Lookup Service, Whois++ |
| |
| Authors: | J. Gargano, K. Weiss. |
| Date: | August 1995 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1834 |
|
This memo describes new features for WHOIS. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1841 | PPP Network Control Protocol for LAN Extension |
| |
| Authors: | J. Chapman, D. Coli, A. Harvey, B. Jensen, K. Rowett. |
| Date: | September 1995 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1841 |
|
Telecommunications infrastructure is improving to offer higher bandwidth connections at lower cost. Access to the network is changing from modems to more intelligent devices. This informationalRFC discusses a PPP Network Control Protocol for one such intelligent device. The protocol is the LAN extension interface protocol. |
|
| |
| RFC 1842 | ASCII Printable Characters-Based Chinese Character Encoding for Internet Messages |
| |
| Authors: | Y. Wei, Y. Zhang, J. Li, J. Ding, Y. Jiang. |
| Date: | August 1995 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1842 |
|
This document describes the encoding used in electronic mail [RFC822] and network news [RFC1036] messages over the Internet. The 7-bit representation of GB 2312 Chinese text was specified by Fung Fung Lee of Stanford University [Lee89] and implemented in various software packages under different platforms (see appendix for a partial list of the available software packages that support this encoding method). It is further tested and used in the usenet newsgroups alt.chinese.text and chinese.* as well as various other network forums with considerable success. Future extensions of this encoding method can accommodate additional GB character sets and other east asian language character sets [Wei94].
The name given to this encoding is "HZ-GB-2312", which is intended to be used in the "charset" parameter field of MIME headers (see [MIME1] and [MIME2]). |
|
| |
| RFC 1843 | HZ - A Data Format for Exchanging Files of Arbitrarily Mixed Chinese and ASCII characters |
| |
| Authors: | F. Lee. |
| Date: | August 1995 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1843 |
|
The content of this memo is identical to an article of the same title written by the author on September 4, 1989. In this memo, GB stands for GB2312-80. Note that the title is kept only for historical reasons. HZ has been widely used for purposes other than "file exchange". |
|
| |
| RFC 1844 | Multimedia E-mail (MIME) User Agent Checklist |
| |
|
|
This document presents a checklist to facilitate evaluation of MIME capable User Agents. Access to a MIME test-responder, that generates test-messages is described. |
|
| |
| RFC 1853 | IP in IP Tunneling |
| |
| Authors: | W. Simpson. |
| Date: | October 1995 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1853 |
|
This document discusses implementation techniques for using IPProtocol/Payload number 4 Encapsulation for tunneling with IPSecurity and other protocols. |
|
| |
| RFC 1855 | Netiquette Guidelines |
| |
|
|
This document provides a minimum set of guidelines for NetworkEtiquette (Netiquette) which organizations may take and adapt for their own use. As such, it is deliberately written in a bulleted format to make adaptation easier and to make any particular item easy(or easier) to find. It also functions as a minimum set of guidelines for individuals, both users and administrators. This memo is the product of the Responsible Use of the Network (RUN) WorkingGroup of the IETF. |
|
| |
| RFC 1856 | The Opstat Client-Server Model for Statistics Retrieval |
| |
| Authors: | H. Clark. |
| Date: | September 1995 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1856 |
|
Network administrators gather data related to the performance, utilization, usability and growth of their data network. The amount of raw data gathered is usually quite large, typically ranging somewhere between several megabytes to several gigabytes of data each month. Few (if any) tools exist today for the sharing of that raw data among network operators or between a network service provider(NSP) and its customers. This document defines a model and protocol for a set of tools which could be used by NSPs and Network OperationCenters (NOCs) to share data among themselves and with customers. |
|
| |
| RFC 1857 | A Model for Common Operational Statistics |
| |
|
|
This memo describes a model for operational statistics in theInternet. It gives recommendations for metrics, measurements, polling periods and presentation formats and defines a format for the exchange of operational statistics. |
|
| |
| RFC 1858 | Security Considerations for IP Fragment Filtering |
| |
| Authors: | G. Ziemba, D. Reed, P. Traina. |
| Date: | October 1995 |
| Formats: | txt html json |
| Updated by: | RFC 3128 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1858 |
|
IP fragmentation can be used to disguise TCP packets from IP filters used in routers and hosts. This document describes two methods of attack as well as remedies to prevent them. |
|
| |
| RFC 1859 | ISO Transport Class 2 Non-use of Explicit Flow Control over TCP RFC1006 extension |
| |
| Authors: | Y. Pouffary. |
| Date: | October 1995 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1859 |
|
This document is an extension to STD35, RFC1006, a standard for the Internet community. The document does not duplicate the protocol definitions contained in RFC1006 and in International Standard ISO 8073. It supplements that information with the description of how to implement ISO Transport Class 2 Non-use of Explicit Flow Control on top of TCP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1860 | Variable Length Subnet Table For IPv4 |
| |
| Authors: | T. Pummill, B. Manning. |
| Date: | October 1995 |
| Formats: | txt html json |
| Obsoleted by: | RFC 1878 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1860 |
|
This document itemizes the potential values for IPv4 subnets.Additional information is provided for Hex and Decmial values, classfull equivalents, and number of addresses available within the indicated block. We appreciate inputs from Bruce Pinsky (cisco) andDaniel Karrenberg (RIPE). |
|
| |
| RFC 1861 | Simple Network Paging Protocol - Version 3 -Two-Way Enhanced |
| |
|
|
This RFC suggests a simple way for delivering wireless messages, both one and two-way, to appropriate receiving devices. In its simplest form, SNPP provides a simple way to implement a "shim" between theInternet and a TAP/IXO paging terminal. In its level 3 form, it provides an easy-to-use (and build) method for communicating and receiving end-to-end acknowledgments and replies from two-way messaging devices (such as ReFLEX units).
Gateways supporting this protocol, as well as SMTP, have been in use for well over a year at several commercial paging companies, and private businesses. Client software supporting this protocol has become widespread, and is being integrated into many of the new paging and messaging products being built. In addition to commercial software, email filters and SNPP client software for Unix and Windows(WikiPage) are available at no cost. Please contact the author for more information.
Earlier versions of this specification were reviewed by IESG members and the "822 Extensions" Working Group. They preferred an alternate strategy, as discussed under "Relationship to Other IETF Work", below. |
|
| |
| RFC 1862 | Report of the IAB Workshop on Internet Information Infrastructure, October 12-14, 1994 |
| |
| Authors: | M. McCahill, J. Romkey, M. Schwartz, K. Sollins, T. Verschuren, C. Weider. |
| Date: | November 1995 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1862 |
|
This document is a report on an Internet architecture workshop, initiated by the IAB and held at MCI on October 12-14, 1994. This workshop generally focused on aspects of the information infrastructure on the Internet. |
|
| |
| RFC 1865 | EDI Meets the Internet Frequently Asked Questions about Electronic Data Interchange (EDI) on the Internet |
| |
| Authors: | W. Houser, J. Griffin, C. Hage. |
| Date: | January 1996 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1865 |
|
This memo is targeted towards the EDI community that is unfamiliar with the Internet, including EDI software developers, users, and service providers. The memo introduces the Internet and assumes a basic knowledge of EDI. |
|
| |
| RFC 1875 | UNINETT PCA Policy Statements |
| |
| Authors: | N. Berge. |
| Date: | December 1995 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1875 |
|
This document provides information about policy statements submitted by the UNINETT Policy Certification Authority (UNINETT PCA). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1877 | PPP Internet Protocol Control Protocol Extensions for Name Server Addresses |
| |
| Authors: | S. Cobb. |
| Date: | December 1995 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1877 |
|
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol and a family of NetworkControl Protocols (NCPs) for establishing and configuring different network-layer protocols.
This document extends the NCP for establishing and configuring theInternet Protocol over PPP [2], defining the negotiation of primary and secondary Domain Name System (DNS) [3] and NetBIOS Name Server(NBNS) [4] addresses. |
|
| |
| RFC 1879 | Class A Subnet Experiment Results and Recommendations |
| |
| Authors: | B. Manning, Ed.. |
| Date: | January 1996 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1879 |
|
This memo documents some experiences with the RFC 1797 [1] subnet A experiment (performed by the Net39 Test Group (see credits)) and provides a number of recommendations on future direction for both the Internet Registries and the Operations community. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1881 | IPv6 Address Allocation Management |
| |
| Authors: | IAB, IESG. |
| Date: | December 1995 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1881 |
|
The IPv6 address space will be managed by the IANA for the good of the Internet community, with advice from the IAB and the IESG, by delegation to the regional registries. |
|
| |
| RFC 1882 | The 12-Days of Technology Before Christmas |
| |
| Authors: | B. Hancock. |
| Date: | December 1995 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1882 |
|
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1887 | An Architecture for IPv6 Unicast Address Allocation |
| |
| Authors: | Y. Rekhter, Ed., T. Li, Ed.. |
| Date: | December 1995 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1887 |
|
This document provides an architecture for allocating IPv6 [1] unicast addresses in the Internet. The overall IPv6 addressing architecture is defined in [2]. This document does not go into the details of an addressing plan. |
|
| |
| RFC 1895 | The Application/CALS-1840 Content-type |
| |
| Authors: | E. Levinson. |
| Date: | February 1996 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1895 |
|
This memorandum provides guidelines for using the United StatesDepartment of Defense Military Standard MIL-STD-1840, "AutomatedInterchange of Technical Information," with the Internet electronic mail standards, RFC 822 and RFC 1521. Electronic mail provides a more convenient mechanism that delivery via physical media for certain types and quantities of data. Software already exists to support data exchanges based on MIL-STD-1840 and it can continue to be used in conjunction with electronic mail exchanges defined in this document. This document defines a new media type and a MIME message structure for exchanging data in conformance with MIL-STD-1840. |
|
| |
| RFC 1896 | The text/enriched MIME Content-type |
| |
|
|
MIME [RFC-1521] defines a format and general framework for the representation of a wide variety of data types in Internet mail. This document defines one particular type of MIME data, the text/enrichedMIME type. The text/enriched MIME type is intended to facilitate the wider interoperation of simple enriched text across a wide variety of hardware and software platforms. This document is only a minor revision to the text/enriched MIME type that was first described in[RFC-1523] and [RFC-1563], and is only intended to be used in the short term until other MIME types for text formatting in Internet mail are developed and deployed. |
|
| |
| RFC 1898 | CyberCash Credit Card Protocol Version 0.8 |
| |
| Authors: | D. Eastlake 3rd, B. Boesch, S. Crocker, M. Yesil. |
| Date: | February 1996 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1898 |
|
CyberCash is developing a general payments system for use over theInternet. The structure and communications protocols of version 0.8 are described. This version includes credit card payments only.Additional capabilities are planned for future versions.
This document covers only the current CyberCash system which is one of the few operational systems in the rapidly evolving area ofInternet payments. CyberCash is committed to the further development of its system and to cooperation with the Internet Engineering TaskForce and other standards organizations. |
|
| |
| RFC 1899 | Request for Comments Summary RFC Numbers 1800-1899 |
| |
| Authors: | J. Elliott. |
| Date: | January 1997 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1899 |
|
|
|
| |
| RFC 1900 | Renumbering Needs Work |
| |
| Authors: | B. Carpenter, Y. Rekhter. |
| Date: | February 1996 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1900 |
|
Renumbering, i.e., changes in the IP addressing information of various network components, is likely to become more and more widespread and common. The Internet Architecture Board (IAB) would like to stress the need to develop and deploy solutions that would facilitate such changes. |
|
| |
| RFC 1912 | Common DNS Operational and Configuration Errors |
| |
|
|
This memo describes errors often found in both the operation ofDomain Name System (DNS) servers, and in the data that these DNS servers contain. This memo tries to summarize current Internet requirements as well as common practice in the operation and configuration of the DNS. This memo also tries to summarize or expand upon issues raised in [RFC 1537]. |
|
| |
| RFC 1916 | Enterprise Renumbering: Experience and Information Solicitation |
| |
| Authors: | H. Berkowitz, P. Ferguson, W. Leland, P. Nesser. |
| Date: | February 1996 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1916 |
|
Because of the urgent need for, and substantial difficulty in, renumbering IP networks, the PIER working group is compiling a series of documents to assist sites in their renumbering efforts. The intent of these documents is to provide both educational and practical information to the Internet community. To this end the working group is soliciting information from organizations that already have gone through, or are in the process of going through, renumbering efforts. Case studies, tools, and lists of applications that require special attention are sought. |
|
| |
| RFC 1919 | Classical versus Transparent IP Proxies |
| |
| Authors: | M. Chatel. |
| Date: | March 1996 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1919 |
|
Many modern IP security systems (also called "firewalls" in the trade) make use of proxy technology to achieve access control. This document explains "classical" and "transparent" proxy techniques and attempts to provide rules to help determine when each proxy system may be used without causing problems. |
|
| |
| RFC 1921 | TNVIP Protocol |
| |
| Authors: | J. Dujonc. |
| Date: | March 1996 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1921 |
|
The goal of this document specifies a Telnet profile to support VIP terminal emulation allowing the access to the BULL hosts applications through a TCP/IP network. |
|
| |
| RFC 1922 | Chinese Character Encoding for Internet Messages |
| |
| Authors: | HF. Zhu, DY. Hu, ZG. Wang, TC. Kao, WCH. Chang, M. Crispin. |
| Date: | March 1996 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1922 |
|
This memo describes methods of transporting Chinese characters inInternet services which transport text, such as electronic mail[RFC-822], network news [RFC-1036], telnet [RFC-854] and the WorldWide Web [RFC-1866]. |
|
| |
| RFC 1923 | RIPv1 Applicability Statement for Historic Status |
| |
| Authors: | J. Halpern, S. Bradner. |
| Date: | March 1996 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1923 |
|
RIP Version 1 [RFC-1058] has been declared an historic document.This Applicability statement provides the supporting motivation for that declaration. The primary reason, as described below, is theClassful nature of RIPv1. |
|
| |
| RFC 1924 | A Compact Representation of IPv6 Addresses |
| |
| Authors: | R. Elz. |
| Date: | 1 April 1996 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1924 |
|
This document specifies a more compact representation of IPv6 addresses, which permits encoding in a mere 20 bytes. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1925 | The Twelve Networking Truths |
| |
| Authors: | R. Callon. |
| Date: | 1 April 1996 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1925 |
|
This memo documents the fundamental truths of networking for theInternet community. This memo does not specify a standard, except in the sense that all standards must implicitly follow the fundamental truths. |
|
| |
| RFC 1926 | An Experimental Encapsulation of IP Datagrams on Top of ATM |
| |
| Authors: | J. Eriksson. |
| Date: | 1 April 1996 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1926 |
|
This RFC describes a method of encapsulating IP datagrams on top ofAcoustical Transmission Media (ATM). This is a non-recommended standard. Distribution of this memo is unnecessary. |
|
| |
| RFC 1927 | Suggested Additional MIME Types for Associating Documents |
| |
| Authors: | C. Rogers. |
| Date: | 1 April 1996 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1927 |
|
Seven new types of MIME types are suggested in this document. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1931 | Dynamic RARP Extensions for Automatic Network Address Acquisition |
| |
| Authors: | D. Brownell. |
| Date: | April 1996 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1931 |
|
This memo describes extensions to the Reverse Address Resolution Protocol (RARP [2]) and called Dynamic RARP (DRARP, pronounced D-RARP). This memo provides information for the Internet community. This memo does not define an Internet standard of any kind. |
|
| |
| RFC 1932 | IP over ATM: A Framework Document |
| |
| Authors: | R. Cole, D. Shur, C. Villamizar. |
| Date: | April 1996 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1932 |
|
It is hoped that this document, in classifying ATM approaches and issues will help to focus the IP over ATM working group's direction.This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1934 | Ascend's Multilink Protocol Plus (MP+) |
| |
| Authors: | K. Smith. |
| Date: | April 1996 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1934 |
|
This document proposes an extension to the PPP Multilink Protocol(MP) [1]. Multilink Protocol Plus (MP+) is a new control protocol for managing multiple data links that are bundled by MP. |
|
| |
| RFC 1935 | What is the Internet, Anyway? |
| |
| Authors: | J. Quarterman, S. Carl-Mitchell. |
| Date: | April 1996 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1935 |
|
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1936 | Implementing the Internet Checksum in Hardware |
| |
| Authors: | J. Touch, B. Parham. |
| Date: | April 1996 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1936 |
|
This memo presents a techniques for efficiently implementing theInternet Checksum in hardware. It includes PLD code for programming a single, low cost part to perform checksumming at 1.26 Gbps. |
|
| |
| RFC 1937 | "Local/Remote" Forwarding Decision in Switched Data Link Subnetworks |
| |
| Authors: | Y. Rekhter, D. Kandlur. |
| Date: | May 1996 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1937 |
|
The IP architecture assumes that each Data Link subnetwork is labeled with a single IP subnet number. A pair of hosts with the same subnet number communicate directly (with no routers); a pair of hosts with different subnet numbers always communicate through one or more routers. As indicated in RFC1620, these assumptions may be too restrictive for large data networks, and specifically for networks based on switched virtual circuit (SVC) based technologies (e.g. ATM,Frame Relay, X.25), as these assumptions impose constraints on communication among hosts and routers through a network. The restrictions may preclude full utilization of the capabilities provided by the underlying SVC-based Data Link subnetwork. This document describes extensions to the IP architecture that relaxes these constraints, thus enabling the full utilization of the services provided by SVC-based Data Link subnetworks. |
|
| |
| RFC 1940 | Source Demand Routing: Packet Format and Forwarding Specification (Version 1) |
| |
| Authors: | D. Estrin, T. Li, Y. Rekhter, K. Varadhan, D. Zappala. |
| Date: | May 1996 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1940 |
|
The purpose of SDRP is to support source-initiated selection of routes to complement the route selection provided by existing routing protocols for both inter-domain and intra-domain routes. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1941 | Frequently Asked Questions for Schools |
| |
|
|
The goal of this FYI document, produced by the Internet SchoolNetworking (ISN) group in the User Services Area of the InternetEngineering Task Force (IETF), is to act as an introduction to theInternet for faculty, administration, and other school personnel in primary and secondary schools. The intended audience is educators who are recently connected to the Internet, who are accessing theInternet by some means other than a direct connection, or who are just beginning to consider Internet access as a resource for their schools. Although the Internet Engineering Task Force is an international organization and this paper will be valuable to educators in many countries, it is limited in focus to internetworking in the United States. |
|
| |
| RFC 1943 | Building an X.500 Directory Service in the US |
| |
| Authors: | B. Jennings. |
| Date: | May 1996 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1943 |
|
This document provides definition and recommends considerations that must be undertaken to operate a X.500 Directory Service in the UnitedStates. This project is the work performed for the IntegratedDirectory Services Working Group within the Internet Engineering TaskForce, for establishing an electronic White Pages Directory Service within an organization in the US and for connecting it to a wide-areaDirectory infrastructure.
Establishing a successful White Pages Directory Service within an organization requires a collaborative effort between the technical, legal and data management components of an organization. It also helps if there is a strong commitment from the higher management to participate in a wide-area Directory Service.
The recommendations presented in the document are the result of experience from participating in the Internet White Pages project. |
|
| |
| RFC 1944 | Benchmarking Methodology for Network Interconnect Devices |
| |
|
|
This document discusses and defines a number of tests that may be used to describe the performance characteristics of a network interconnecting device. In addition to defining the tests this document also describes specific formats for reporting the results of the tests. Appendix A lists the tests and conditions that we believe should be included for specific cases and gives additional information about testing practices. Appendix B is a reference listing of maximum frame rates to be used with specific frame sizes on various media and Appendix C gives some examples of frame formats to be used in testing. |
|
| |
| RFC 1945 | Hypertext Transfer Protocol -- HTTP/1.0 |
| |
| Authors: | T. Berners-Lee, R. Fielding, H. Frystyk. |
| Date: | May 1996 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1945 |
|
The Hypertext Transfer Protocol (HTTP) is an application-level protocol with the lightness and speed necessary for distributed, collaborative, hypermedia information systems. It is a generic, stateless, object-oriented protocol which can be used for many tasks, such as name servers and distributed object management systems, through extension of its request methods (commands). A feature ofHTTP is the typing of data representation, allowing systems to be built independently of the data being transferred.
HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification reflects common usage of the protocol referred to as "HTTP/1.0". |
|
| |
| RFC 1946 | Native ATM Support for ST2+ |
| |
| Authors: | S. Jackowski. |
| Date: | May 1996 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1946 |
|
As the demand for networked realtime services grows, so does the need for shared networks to provide deterministic delivery services. Such deterministic delivery services demand that both the source application and the network infrastructure have capabilities to request, setup, and enforce the delivery of the data. Collectively these services are referred to as bandwidth reservation and Quality of Service (QoS).
The IETF is currently working on an integrated services model to support realtime services on the Internet The IETF has not yet focused on the integration of ATM and its inherent QoS and bandwidth allocation mechanisms for delivery of realtime traffic over shared wires. (ATM hardware and interfaces provide the network infrastructure for the determinitic data delivery, however the host resident protocol stacks and applications need more attention.)
Current IETF efforts underway in the IP over ATM (ipatm) working group rely on intserv, rsvp and ST2 to address QoS issues for ATM. As such, RFC 1577 and the ATM Forum's Lan Emulation do not provide direct QoS and bandwidth allocation capabilities to network applications. Without providing a mapping of reservations-style QoS to ATM signalling, ATM will remain a 'wire' rather than a shared media infrastructure component.
This memo describes a working implementation which enables applications to directly invoke ATM services in the following environments:
- ATM to internet,- internet to ATM, and- internet to internet across ATM. |
|
| |
| RFC 1947 | Greek Character Encoding for Electronic Mail Messages |
| |
| Authors: | D. Spinellis. |
| Date: | May 1996 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1947 |
|
This document describes a standard encoding for electronic mail [RFC822] containing Greek text and provides implementation guide-lines. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1948 | Defending Against Sequence Number Attacks |
| |
|
|
IP spoofing attacks based on sequence number spoofing have become a serious threat on the Internet (CERT Advisory CA-95:01). While ubiquitous crypgraphic authentication is the right answer, we propose a simple modification to TCP implementations that should be a very substantial block to the current wave of attacks. |
|
| |
| RFC 1950 | ZLIB Compressed Data Format Specification version 3.3 |
| |
|
|
This specification defines a lossless compressed data format. The data can be produced or consumed, even for an arbitrarily long sequentially presented input data stream, using only an a priori bounded amount of intermediate storage. The format presently uses the DEFLATE compression method but can be easily extended to use other compression methods. It can be implemented readily in a manner not covered by patents. This specification also defines the ADLER-32 checksum (an extension and improvement of the Fletcher checksum), used for detection of data corruption, and provides an algorithm for computing it. |
|
| |
| RFC 1951 | DEFLATE Compressed Data Format Specification version 1.3 |
| |
|
|
This specification defines a lossless compressed data format that compresses data using a combination of the LZ77 algorithm and Huffman coding, with efficiency comparable to the best currently available general-purpose compression methods. The data can be produced or consumed, even for an arbitrarily long sequentially presented input data stream, using only an a priori bounded amount of intermediate storage. The format can be implemented readily in a manner not covered by patents. |
|
| |
| RFC 1952 | GZIP file format specification version 4.3 |
| |
|
|
This specification defines a lossless compressed data format that is compatible with the widely used GZIP utility. The format includes a cyclic redundancy check value for detecting data corruption. The format presently uses the DEFLATE method of compression but can be easily extended to use other compression methods. The format can be implemented readily in a manner not covered by patents. |
|
| |
| RFC 1953 | Ipsilon Flow Management Protocol Specification for IPv4 Version 1.0 |
| |
| Authors: | P. Newman, W. Edwards, R. Hinden, E. Hoffman, F. Ching Liaw, T. Lyon, G. Minshall. |
| Date: | May 1996 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1953 |
|
The Ipsilon Flow Management Protocol (IFMP), is a protocol for allowing a node to instruct an adjacent node to attach a layer 2 label to a specified IP flow. The label allows more efficient access to cached routing information for that flow. The label can also enable a node to switch further packets belonging to the specified flow at layer 2 rather than forwarding them at layer 3. |
|
| |
| RFC 1954 | Transmission of Flow Labelled IPv4 on ATM Data Links Ipsilon Version 1.0 |
| |
| Authors: | P. Newman, W. Edwards, R. Hinden, E. Hoffman, F. Ching Liaw, T. Lyon, G. Minshall. |
| Date: | May 1996 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1954 |
|
This document specifies the manner for transmitting IPv4 datagrams over an ATM data link, both in a default manner and in the presence of flow labelling via Ipsilon Flow Management Protocol [IFMP]. |
|
| |
| RFC 1955 | New Scheme for Internet Routing and Addressing (ENCAPS) for IPNG |
| |
| Authors: | R. Hinden. |
| Date: | June 1996 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1955 |
|
This document was submitted to the IETF IPng area in response to RFC1550. Publication of this document does not imply acceptance by theIPng area of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list.
This memo describes a proposal made to to the Routing and Addressing group [ROAD] January 1992 by Robert Hinden. It was originally sent as an email message. It proposes a medium term solution to theInternet's routing and addressing problems. |
|
| |
| RFC 1956 | Registration in the MIL Domain |
| |
| Authors: | D. Engebretson, R. Plzak. |
| Date: | June 1996 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1956 |
|
This RFC describes the policy for the registration of second level domains under the ".MIL" domain. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1957 | Some Observations on Implementations of the Post Office Protocol (POP3) |
| |
|
|
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1958 | Architectural Principles of the Internet |
| |
|
|
The Internet and its architecture have grown in evolutionary fashion from modest beginnings, rather than from a Grand Plan. While this process of evolution is one of the main reasons for the technology's success, it nevertheless seems useful to record a snapshot of the current principles of the Internet architecture. This is intended for general guidance and general interest, and is in no way intended to be a formal or invariant reference model. |
|
| |
| RFC 1963 | PPP Serial Data Transport Protocol (SDTP) |
| |
| Authors: | K. Schneider, S. Venters. |
| Date: | August 1996 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1963 |
|
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol, and proposes a family ofNetwork Control Protocols for establishing and configuring different network-layer protocols.
This document describes a new Network level protocol (from the PPP point of view), PPP Serial Data Transport Protocol, that provides encapsulation and an associated control protocol for transporting serial data streams over a PPP link. This protocol was developed for the purpose of using PPP's many features to provide a standard method for synchronous data compression. The encapsulation uses a header structure based on that of the ITU-T Recommendation V.120 [2]. |
|
| |
| RFC 1967 | PPP LZS-DCP Compression Protocol (LZS-DCP) |
| |
| Authors: | K. Schneider, R. Friend. |
| Date: | August 1996 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1967 |
|
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.
The PPP Compression Control Protocol [2] provides a method to negotiate and utilize compression protocols over PPP encapsulated links.
This document describes the use of the Stac LZS data compression algorithm for compressing PPP encapsulated packets, using a DCP header [6]. This protocol is an enhanced version of the non-DCP(Option 17) PPP Stac LZS compression protocol [5], and will be referred to as the LZS-DCP Compression Protocol. |
|
| |
| RFC 1969 | The PPP DES Encryption Protocol (DESE) |
| |
|
|
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.
The PPP Encryption Control Protocol (ECP) [2] provides a method to negotiate and utilize encryption protocols over PPP encapsulated links.
This document provides specific details for the use of the DES standard [5, 6] for encrypting PPP encapsulated packets. |
|
| |
| RFC 1974 | PPP Stac LZS Compression Protocol |
| |
| Authors: | R. Friend, W. Simpson. |
| Date: | August 1996 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1974 |
|
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.
The PPP Compression Control Protocol [2] provides a method to negotiate and utilize compression protocols over PPP encapsulated links.
This document describes the use of the Stac LZS data compression algorithm, with single or multiple compression histories, for compressing PPP encapsulated packets. |
|
| |
| RFC 1975 | PPP Magnalink Variable Resource Compression |
| |
| Authors: | D. Schremp, J. Black, J. Weiss. |
| Date: | August 1996 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1975 |
|
The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating multiple protocol datagrams over point-to-point links.The PPP Compression Control Protocol [2] provides a method for negotiating data compression over PPP links.
The Magnalink Variable Resource Compression Algorithm (MVRCA) allows a wide range of interoperable compression implementations whose performance characteristics are a function of available CPU and memory resources. |
|
| |
| RFC 1976 | PPP for Data Compression in Data Circuit-Terminating Equipment (DCE) |
| |
| Authors: | K. Schneider, S. Venters. |
| Date: | August 1996 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1976 |
|
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol, and proposes a family ofNetwork Control Protocols for establishing and configuring different network-layer protocols.
The PPP Serial Data Transport Protocol (PPP-SDTP) [2] provides a standard method for encapsulating and transporting serial data over aPPP link. The PPP Compression Control Protocol [3] provides a standard method for selecting and using a compression protocol to provide for data compression on a PPP link.
This document defines a specific set of parameters for these protocols and an LCP extension to define a standard way of using PPP for data compression of serial data in Data Circuit-TerminatingEquipment (DCE). |
|
| |
| RFC 1977 | PPP BSD Compression Protocol |
| |
| Authors: | V. Schryver. |
| Date: | August 1996 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1977 |
|
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.
The PPP Compression Control Protocol [2] provides a method to negotiate and utilize compression protocols over PPP encapsulated links.
This document describes the use of the Unix Compress compression protocol for compressing PPP encapsulated packets. |
|
| |
| RFC 1978 | PPP Predictor Compression Protocol |
| |
| Authors: | D. Rand. |
| Date: | August 1996 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1978 |
|
The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating multiple protocol datagrams over point-to-point links.
The PPP Compression Control Protocol [2] provides a method for transporting multi-protocol datagrams over PPP encapsulated links.
This document describes the use of the Predictor data compression algorithm for compressing PPP encapsulated packets. |
|
| |
| RFC 1979 | PPP Deflate Protocol |
| |
| Authors: | J. Woods. |
| Date: | August 1996 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1979 |
|
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.
The PPP Compression Control Protocol [2] provides a method to negotiate and utilize compression protocols over PPP encapsulated links.
This document describes the use of the PPP Deflate compression protocol for compressing PPP encapsulated packets. |
|
| |
| RFC 1983 | Internet Users' Glossary |
| |
|
|
There are many networking glossaries in existence. This glossary concentrates on terms which are specific to the Internet. Naturally, there are entries for some basic terms and acronyms because other entries refer to them. |
|
| |
| RFC 1987 | Ipsilon's General Switch Management Protocol Specification Version 1.1 |
| |
| Authors: | P. Newman, W. Edwards, R. Hinden, E. Hoffman, F. Ching Liaw, T. Lyon, G. Minshall. |
| Date: | August 1996 |
| Formats: | txt html json |
| Updated by: | RFC 2297 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1987 |
|
The General Switch Management Protocol (GSMP), is a general purpose protocol to control an ATM switch. GSMP allows a controller to establish and release connections across the switch; add and delete leaves on a point-to-multipoint connection; manage switch ports; request configuration information; and request statistics. |
|
| |
| RFC 1988 | Conditional Grant of Rights to Specific Hewlett-Packard Patents In Conjunction With the Internet Engineering Task Force's Internet-Standard Network Management Framework |
| |
| Authors: | G. McAnally, D. Gilbert, J. Flick. |
| Date: | August 1996 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1988 |
|
This grant is made to help facilitate inclusion of certain patented search address technology covering network device mapping in IETF standards-track Management Information Base (MIB) modules. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1991 | PGP Message Exchange Formats |
| |
| Authors: | D. Atkins, W. Stallings, P. Zimmermann. |
| Date: | August 1996 |
| Formats: | txt json html |
| Obsoleted by: | RFC 4880 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1991 |
|
This document describes the format of "PGP files", i.e., messages that have been encrypted and/or signed with PGP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1992 | The Nimrod Routing Architecture |
| |
| Authors: | I. Castineyra, N. Chiappa, M. Steenstrup. |
| Date: | August 1996 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1992 |
|
We present a scalable internetwork routing architecture, calledNimrod. The Nimrod architecture is designed to accommodate a dynamic internetwork of arbitrary size with heterogeneous service requirements and restrictions and to admit incremental deployment throughout an internetwork. The key to Nimrod's scalability is its ability to represent and manipulate routing-related information at multiple levels of abstraction. |
|
| |
| RFC 1993 | PPP Gandalf FZA Compression Protocol |
| |
| Authors: | A. Barbir, D. Carr, W. Simpson. |
| Date: | August 1996 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1993 |
|
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.
The PPP Compression Control Protocol [2] provides a method to negotiate and utilize compression protocols over PPP encapsulated links.
This document describes the use of the Gandalf FZA data compression algorithm [3] for compressing PPP encapsulated packets. |
|
| |
| RFC 1998 | An Application of the BGP Community Attribute in Multi-home Routing |
| |
| Authors: | E. Chen, T. Bates. |
| Date: | August 1996 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1998 |
|
This document presents an application of the BGP community attribute[2] in simplifying the implementation and configuration of routing policies in the multi-provider Internet. It shows how the community based configuration can be used to replace the AS-based customization of the BGP "LOCAL_PREF" attribute, a common method used today. Not only does the technique presented simplifies configuration and management at the provider level, it also represents a paradigm shift in that it gives the potential for the customer to control its own routing policy with respect to its service provider, as well as providing the ability for policy configuration to be done at a prefix based granularity rather than the more common AS based granularity. |
|
| |
| RFC 1999 | Request for Comments Summary RFC Numbers 1900-1999 |
| |
| Authors: | J. Elliott. |
| Date: | January 1997 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 1999 |
|
|
|
| |
| RFC 2007 | Catalogue of Network Training Materials |
| |
| Authors: | J. Foster, M. Isaacs, M. Prior. |
| Date: | October 1996 |
| Formats: | txt html json |
| Also: | FYI 0029 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2007 |
|
The purpose of this document is to provide a catalogue of qualityNetwork Training Materials for use by Internet trainers in training their users. By providing such a collection of pointers to useful resources, it is hoped that trainers will be relieved of much of the load of producing current training materials. |
|
| |
| RFC 2010 | Operational Criteria for Root Name Servers |
| |
|
|
This document specifies the operational requirements of root name servers, including host hardware capacities, name server software revisions, network connectivity, and physical environment. |
|
| |
| RFC 2027 | IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees |
| |
|
|
The process by which the members of the IAB and IESG are selected, confirmed, and recalled has been exercised four times since its formal creation. The evolution of the process has relied principally on oral tradition as a means by which the lessons learned could be passed on to successive committees. This document is a self- consistent, organized compilation of the process as it is known today. |
|
| |
| RFC 2030 | Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI |
| |
|
|
This memorandum describes the Simple Network Time Protocol (SNTP)Version 4, which is an adaptation of the Network Time Protocol (NTP) used to synchronize computer clocks in the Internet. SNTP can be used when the ultimate performance of the full NTP implementation described in RFC-1305 is not needed or justified. When operating with current and previous NTP and SNTP versions, SNTP Version 4 involves no changes to the NTP specification or known implementations, but rather a clarification of certain design features of NTP which allow operation in a simple, stateless remote-procedure call (RPC) mode with accuracy and reliability expectations similar to the UDP/TIME protocol described in RFC-868.
The only significant protocol change in SNTP Version 4 over previous versions of NTP and SNTP is a modified header interpretation to accommodate Internet Protocol Version 6 (IPv6) [DEE96] and OSI[COL94] addressing. However, SNTP Version 4 includes certain optional extensions to the basic Version 3 model, including an anycast mode and an authentication scheme designed specifically for multicast and anycast modes. While the anycast mode extension is described in this document, the authentication scheme extension will be described in another document to be published later. Until such time that a definitive specification is published, these extensions should be considered provisional.
This memorandum obsoletes RFC-1769, which describes SNTP Version 3.Its purpose is to correct certain inconsistencies in the previous document and to clarify header formats and protocol operations for current NTP Version 3 (IPv4) and proposed NTP Version 4 (IPv6 andOSI), which are also used for SNTP. A working knowledge of the NTPVersion 3 specification RFC-1305 is not required for an implementation of SNTP. |
|
| |
| RFC 2031 | IETF-ISOC relationship |
| |
|
|
This memo summarises the issues on IETF - ISOC relationships as the have been discussed by the Poised Working Group. The purpose of the document is to gauge consensus on these issues. And to allow further discussions where necessary. |
|
| |
| RFC 2033 | Local Mail Transfer Protocol |
| |
| Authors: | J. Myers. |
| Date: | October 1996 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2033 |
|
SMTP [SMTP] [HOST-REQ] and its service extensions [ESMTP] provide a mechanism for transferring mail reliably and efficiently. The design of the SMTP protocol effectively requires the server to manage a mail delivery queue. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 2039 | Applicability of Standards Track MIBs to Management of World Wide Web Servers |
| |
| Authors: | C. Kalbfleisch. |
| Date: | November 1996 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2039 |
|
This document was produced at the request of the Network Management Area Director following the HTTP-MIB BOF at the 35th IETF meeting to report on the applicability of the existing standards track MIBs to management of WWW servers. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 2040 | The RC5, RC5-CBC, RC5-CBC-Pad, and RC5-CTS Algorithms |
| |
| Authors: | R. Baldwin, R. Rivest. |
| Date: | October 1996 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2040 |
|
This document defines four ciphers with enough detail to ensure interoperability between different implementations. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 2041 | Mobile Network Tracing |
| |
| Authors: | B. Noble, G. Nguyen, M. Satyanarayanan, R. Katz. |
| Date: | October 1996 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2041 |
|
Mobile networks are both poorly understood and difficult to experiment with. This RFC argues that mobile network tracing provides both tools to improve our understanding of wireless channels, as well as to build realistic, repeatable testbeds for mobile software and systems. The RFC is a status report on our work tracing mobile networks. Our goal is to begin discussion on a standard format for mobile network tracing as well as a testbed for mobile systems research. We present our format for collecting mobile network traces, and tools to produce from such traces analytical models of mobile network behavior.
We also describe a set of tools to provide network modulation based on collected traces. Modulation allows the emulation of wireless channel latency, bandwidth, loss, and error rates on private, wired networks. This allows system designers to test systems in a realistic yet repeatable manner. |
|
| |
| RFC 2042 | Registering New BGP Attribute Types |
| |
| Authors: | B. Manning. |
| Date: | January 1997 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2042 |
|
This document describes the process for creating new BGP attribute type codes. Basic attribute type codes are described in RFC 1771, pages 12 through 15. These, and new attribute type codes that are used in the Internet are registered with the IANA. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 2044 | UTF-8, a transformation format of Unicode and ISO 10646 |
| |
|
|
The Unicode Standard, version 1.1, and ISO/IEC 10646-1:1993 jointly define a 16 bit character set which encompasses most of the world's writing systems. 16-bit characters, however, are not compatible with many current applications and protocols, and this has led to the development of a few so-called UCS transformation formats (UTF), each with different characteristics. UTF-8, the object of this memo, has the characteristic of preserving the full US-ASCII range: US-ASCII characters are encoded in one octet having the usual US-ASCII value, and any octet with such a value can only be an US-ASCII character.This provides compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. |
|
| |
| RFC 2053 | The AM (Armenia) Domain |
| |
| Authors: | E. Der-Danieliantz. |
| Date: | October 1996 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2053 |
|
The AM Domain is an official Internet top-level domain of Armenia. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 2054 | WebNFS Client Specification |
| |
| Authors: | B. Callaghan. |
| Date: | October 1996 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2054 |
|
This document describes a lightweight binding mechanism that allowsNFS clients to obtain service from WebNFS-enabled servers with a minimum of protocol overhead. In removing this overhead, WebNFS clients see benefits in faster response to requests, easy transit of packet filter firewalls and TCP-based proxies, and better server scalability. |
|
| |
| RFC 2055 | WebNFS Server Specification |
| |
| Authors: | B. Callaghan. |
| Date: | October 1996 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2055 |
|
This document describes the specifications for a server of WebNFS clients. WebNFS extends the semantics of versions 2 and 3 of the NFS protocols to allow clients to obtain filehandles more easily, without recourse to the portmap or MOUNT protocols. In removing the need for these protocols, WebNFS clients see benefits in faster response to requests, easy transit of firewalls and better server scalabilityThis description is provided to facilitate compatible implementations of WebNFS servers. |
|
| |
| RFC 2057 | Source Directed Access Control on the Internet |
| |
| Authors: | S. Bradner. |
| Date: | November 1996 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2057 |
|
This memo was developed from a deposition that I submitted as part of a challenge to the Communications Decency Act of 1996, part of the Telecommunications Reform Act of 1996. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 2059 | RADIUS Accounting |
| |
|
|
This document describes a protocol for carrying accounting information between a Network Access Server and a shared AccountingServer. |
|
| |
| RFC 2061 | 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. |
|
| |
| RFC 2062 | Internet Message Access Protocol - Obsolete Syntax |
| |
| Authors: | M. Crispin. |
| Date: | December 1996 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2062 |
|
This document describes obsolete syntax which may be encountered byIMAP4 implementations which deal with older versions of the InternetMail Access Protocol. IMAP4 implementations MAY implement this syntax in order to maximize interoperability with older implementations.
This document repeats information from earlier documents, most notably RFC 1176 and RFC 1730. |
|
| |
| RFC 2071 | Network Renumbering Overview: Why would I want it and what is it anyway? |
| |
| Authors: | P. Ferguson, H. Berkowitz. |
| Date: | January 1997 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2071 |
|
The PIER [Procedures for Internet/Enterprise Renumbering] working group is compiling a series of documents to assist and instruct organizations in their efforts to renumber. However, it is becoming apparent that, with the increasing number of new Internet ServiceProviders (ISP's) and organizations getting connected to the Internet for the first time, the concept of network renumbering needs to be further defined. This document attempts to clearly define the concept of network renumbering and discuss some of the more pertinent reasons why an organization would have a need to do so. |
|
| |
| RFC 2072 | Router Renumbering Guide |
| |
|
|
IP addresses currently used by organizations are likely to undergo changes in the near to moderate term. Change can become necessary for a variety of reasons, including enterprise reorganization, physical moves of equipment, new strategic relationships, changes inInternet Service Providers (ISP), new applications, and the needs of global Internet connectivity. Good IP address management may in general simplify continuing system administration; a good renumbering plan is also a good numbering plan. Most actions taken to ease future renumbering will ease routine network administration.
Routers are the components that interconnect parts of the IP address space identified by unique prefixes. Obviously, they will be impacted by renumbering. Other interconnection devices, such as bridges, layer 2 switches (i.e., specialized bridges), and ATM switches may be affected by renumbering. The interactions of these lower-layer interconnection devices with routers must be considered as part of a renumbering effort.
Routers interact with numerous network infrastructure servers, including DNS and SNMP. These interactions, not just the pure addressing and routing structure, must be considered as part of router renumbering. |
|
| |
| RFC 2076 | Common Internet Message Headers |
| |
| Authors: | J. Palme. |
| Date: | February 1997 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2076 |
|
This memo contains a table of commonly occurring headers in headings of e-mail messages. The document compiles information from other RFCs such as RFC 822, RFC 1036, RFC 1123, RFC 1327, RFC 1496, RFC 1521,RFC 1766, RFC 1806, RFC 1864 and RFC 1911. A few commonly occurring headers which are not defined in RFCs are also included. For each header, the memo gives a short description and a reference to the RFC in which the header is defined. |
|
| |
| RFC 2081 | RIPng Protocol Applicability Statement |
| |
| Authors: | G. Malkin. |
| Date: | January 1997 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2081 |
|
As required by Routing Protocol Criteria (RFC 1264), this report defines the applicability of the RIPng protocol within the Internet.This report is a prerequisite to advancing RIPng on the standards track. |
|
| |
| RFC 2083 | PNG (Portable Network Graphics) Specification Version 1.0 |
| |
| Authors: | T. Boutell. |
| Date: | March 1997 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2083 |
|
This document describes PNG (Portable Network Graphics), an extensible file format for the lossless, portable, well-compressed storage of raster images. PNG provides a patent-free replacement forGIF and can also replace many common uses of TIFF. Indexed-color, grayscale, and truecolor images are supported, plus an optional alpha channel. Sample depths range from 1 to 16 bits.
PNG is designed to work well in online viewing applications, such as the World Wide Web, so it is fully streamable with a progressive display option. PNG is robust, providing both full file integrity checking and simple detection of common transmission errors. Also,PNG can store gamma and chromaticity data for improved color matching on heterogeneous platforms.
This specification defines the Internet Media Type image/png. |
|
| |
| RFC 2084 | Considerations for Web Transaction Security |
| |
| Authors: | G. Bossert, S. Cooper, W. Drummond. |
| Date: | January 1997 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2084 |
|
This document specifies the requirements for the provision of security services to the HyperText Transport Protocol. These services include confidentiality, integrity, user authentication, and authentication of servers/services, including proxied or gatewayed services. Such services may be provided as extensions to HTTP, or as an encapsulating security protocol. Secondary requirements include ease of integration and support of multiple mechanisms for providing these services. |
|
| |
| RFC 2089 | V2ToV1 Mapping SNMPv2 onto SNMPv1 within a bi-lingual SNMP agent |
| |
|
|
The goal of this memo is to document a common way of mapping anSNMPv2 response into an SNMPv1 response within a bi-lingual SNMP agent (one that supports both SNMPv1 and SNMPv2). |
|
| |
| RFC 2092 | Protocol Analysis for Triggered RIP |
| |
| Authors: | S. Sherry, G. Meyer. |
| Date: | January 1997 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2092 |
|
As required by Routing Protocol Criteria [1], this report documents the key features of Triggered Extensions to RIP to Support DemandCircuits [2] and the current implementation experience.
As a result of the improved characteristics of Triggered RIP, it is proposed that Demand RIP [5] be obsoleted. |
|
| |
| RFC 2098 | Toshiba's Router Architecture Extensions for ATM : Overview |
| |
| Authors: | Y. Katsube, K. Nagami, H. Esaki. |
| Date: | February 1997 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2098 |
|
This memo describes a new internetworking architecture which makes better use of the property of ATM. IP datagrams are transferred along hop-by-hop path via routers, but datagram assembly/disassembly and IP header processing are not necessarily carried out at individual routers in the proposed architecture. A concept of "CellSwitch Router (CSR)" is introduced as a new internetworking equipment, which has ATM cell switching capabilities in addition to conventional IP datagram forwarding. Proposed architecture can provide applications with high-throughput and low-latency ATM pipes while retaining current router-based internetworking concept. It also provides applications with specific QoS/bandwidth by cooperating with internetworking level resource reservation protocols such asRSVP. |
|
| |
| RFC 2099 | Request for Comments Summary RFC Numbers 2000-2099 |
| |
| Authors: | J. Elliott. |
| Date: | March 1997 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2099 |
|
|
|
| |
| RFC 2100 | The Naming of Hosts |
| |
| Authors: | J. Ashworth. |
| Date: | 1 April 1997 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2100 |
|
This RFC is a commentary on the difficulty of deciding upon an acceptably distinctive hostname for one's computer, a problem which grows in direct proportion to the logarithmically increasing size of the Internet. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 2101 | IPv4 Address Behaviour Today |
| |
| Authors: | B. Carpenter, J. Crowcroft, Y. Rekhter. |
| Date: | February 1997 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2101 |
|
The main purpose of this note is to clarify the current interpretation of the 32-bit IP version 4 address space, whose significance has changed substantially since it was originally defined. A short section on IPv6 addresses mentions the main points of similarity with, and difference from, IPv4. |
|
| |
| RFC 2102 | Multicast Support for Nimrod : Requirements and Solution Approaches |
| |
| Authors: | R. Ramanathan. |
| Date: | February 1997 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2102 |
|
Nimrod does not specify a particular solution for multicasting.Rather, Nimrod may use any of a number of emerging multicast techniques. We identify the requirements that Nimrod has of a solution for multicast support. We compare existing approaches for multicasting within an internetwork and discuss their advantages and disadvantages. Finally, as an example, we outline the mechanisms to support multicast in Nimrod using the scheme currently being developed within the IETF - namely, the Protocol Indpendent Multicast(PIM) protocol. |
|
| |
| RFC 2103 | Mobility Support for Nimrod : Challenges and Solution Approaches |
| |
| Authors: | R. Ramanathan. |
| Date: | February 1997 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2103 |
|
We discuss the issue of mobility in Nimrod. While a mobility solution is not part of the Nimrod architecture, Nimrod does require that the solution have certain characteristics. We identify the requirements that Nimrod has of any solution for mobility support.We also classify and compare existing approaches for supporting mobility within an internetwork and discuss their advantages and disadvantages. Finally, as an example, we outline the mechanisms to support mobility in Nimrod using the scheme currently being developed within the IETF - namely, the Mobile-IP protocol. |
|
| |
| RFC 2104 | HMAC: Keyed-Hashing for Message Authentication |
| |
| Authors: | H. Krawczyk, M. Bellare, R. Canetti. |
| Date: | February 1997 |
| Formats: | txt html json |
| Updated by: | RFC 6151 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2104 |
|
This document describes HMAC, a mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA-1, in combination with a secret shared key. The cryptographic strength ofHMAC depends on the properties of the underlying hash function. |
|
| |
| RFC 2105 | Cisco Systems' Tag Switching Architecture Overview |
| |
| Authors: | Y. Rekhter, B. Davie, D. Katz, E. Rosen, G. Swallow. |
| Date: | February 1997 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2105 |
|
This document provides an overview of a novel approach to network layer packet forwarding, called tag switching. The two main components of the tag switching architecture - forwarding and control - are described. Forwarding is accomplished using simple label-swapping techniques, while the existing network layer routing protocols plus mechanisms for binding and distributing tags are used for control. Tag switching can retain the scaling properties of IP, and can help improve the scalability of IP networks. While tag switching does not rely on ATM, it can straightforwardly be applied to ATM switches. A range of tag switching applications and deployment scenarios are described. |
|
| |
| RFC 2106 | Data Link Switching Remote Access Protocol |
| |
| Authors: | S. Chiang, J. Lee, H. Yasuda. |
| Date: | February 1997 |
| Formats: | txt json html |
| Obsoleted by: | RFC 2114 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2106 |
|
This memo describes the Data Link Switching Remote Access Protocol that is used between workstations and routers to transport SNA/NetBIOS traffic over TCP sessions. Any questions or comments should be sent to drap@cisco.com. |
|
| |
| RFC 2107 | Ascend Tunnel Management Protocol - ATMP |
| |
| Authors: | K. Hamzeh. |
| Date: | February 1997 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2107 |
|
This document specifies a generic tunnel management protocol that allows remote dial-in users to access their home network as if they were directly attached to the home network. The user's client software uses an address contained in the home network address space for the remote access. Packets to and from the home network are tunneled by the Network Access Server (NAS) to which the user connects and a Home Agent (HA) on the user's home network. This allows for the support of access to Virtual Private Networks and also allows for the use of protocols other than IP to be carried over the tunnel. An example of how the RADIUS (Remote Authentication Dial InUser Service) can be used to provide the necessary configuration information to support this service is also provided. |
|
| |
| RFC 2114 | Data Link Switching Client Access Protocol |
| |
| Authors: | S. Chiang, J. Lee, H. Yasuda. |
| Date: | February 1997 |
| Formats: | txt html json |
| Obsoletes: | RFC 2106 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2114 |
|
This memo describes the Data Link Switching Client Access Protocol that is used between workstations and routers to transport SNA/NetBIOS traffic over TCP sessions. Any questions or comments should be sent to dcap@cisco.com. |
|
| |
| RFC 2116 | X.500 Implementations Catalog-96 |
| |
|
|
This document is a revision to [RFC 1632]: A Revised Catalog ofAvailable X.500 Implementations and is based on the results of data collection via a WWW home page that enabled implementors to submit new or updated descriptions of currently available implementations ofX.500, including commercial products and openly available offerings.[RFC 1632] is a revision of [RFC 1292]. We contacted each contributor to [RFC 1632] to request an update and published the URL of the WWW home page survey template in several mailing lists to encourage the submission of new product descriptions.
This document contains detailed description of 31 X.500 implementations - DSAs, DUAs, and DUA interfaces. |
|
| |
| RFC 2118 | Microsoft Point-To-Point Compression (MPPC) Protocol |
| |
| Authors: | G. Pall. |
| Date: | March 1997 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2118 |
|
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.
The PPP Compression Control Protocol [2] provides a method to negotiate and utilize compression protocols over PPP encapsulated links.
This document describes the use of the Microsoft Point to PointCompression protocol (also referred to as MPPC in this document) for compressing PPP encapsulated packets. |
|
| |
| RFC 2121 | Issues affecting MARS Cluster Size |
| |
| Authors: | G. Armitage. |
| Date: | March 1997 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2121 |
|
IP multicast over ATM currently uses the MARS model [1] to manage the use of ATM pt-mpt SVCs for IP multicast packet forwarding. The scope of any given MARS services is the MARS Cluster - typically the same as an IPv4 Logical IP Subnet (LIS). Current IP/ATM networks are usually architected with unicast routing and forwarding issues dictating the sizes of individual LISes. However, as IP multicast is deployed as a service, the size of a LIS will only be as big as aMARS Cluster can be. This document provides a qualitative look at the issues constraining a MARS Cluster's size, including the impact of VC limits in switches and NICs, geographical distribution of cluster members, and the use of VC Mesh or MCS modes to support multicast groups. |
|
| |
| RFC 2123 | Traffic Flow Measurement: Experiences with NeTraMet |
| |
| Authors: | N. Brownlee. |
| Date: | March 1997 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2123 |
|
This memo records experiences in implementing and using the TrafficFlow Measurement Architecture and Meter MIB. It discusses the implementation of NeTraMet (a traffic meter) and NeMaC (a combined manager and meter reader), considers the writing of meter rule sets and gives some guidance on setting up a traffic flow measurement system using NeTraMet. |
|
| |
| RFC 2124 | Cabletron's Light-weight Flow Admission Protocol Specification Version 1.0 |
| |
| Authors: | P. Amsden, J. Amweg, P. Calato, S. Bensley, G. Lyons. |
| Date: | March 1997 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2124 |
|
Light-weight Flow Admission Protocol, LFAP, allows an external FlowAdmission Service (FAS) to manage flow admission at the switch, allowing flexible Flow Admission Services to be deployed by a vendor or customer without changes to, or undue burden on, the switch.
Specifically, this document specifies the protocol between the switchConnection Control Entity (CCE) and the external FAS. Using LFAP, aFlow Admission Service can: allow or disallow flows, define the parameters under which a given flow is to operate (operating policy) or, redirect the flow to an alternate destination. The FAS may also maintain details of current or historical flows for billing, capacity planning and other purposes. |
|
| |
| RFC 2129 | Toshiba's Flow Attribute Notification Protocol (FANP) Specification |
| |
| Authors: | K. Nagami, Y. Katsube, Y. Shobatake, A. Mogi, S. Matsuzawa, T. Jinmei, H. Esaki. |
| Date: | April 1997 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2129 |
|
This memo discusses Flow Attribute Notification Protocol (FANP), which is a protocol between neighbor nodes for the management of cut-through packet forwarding functionalities. In cut-through packet forwarding, a router doesn't have to perform conventional IP packet processing for received packets. FANP indicates mapping information between a datalink connection and a packet flow to the neighbor node and helps a pair of nodes manage the mapping information. By usingFANP, routers (e.g., CSR; Cell Switch Router) can forward incoming packets based on their datalink-level connection identifiers, bypassing usual IP packet processing. The design policy of the FANP is;
(1) soft-state cut-through path (Dedicated-VC) management(2) protocol between neighbor nodes instead of end-to-end(3) applicable to any connection oriented datalink platform |
|
| |
| RFC 2130 | The Report of the IAB Character Set Workshop held 29 February - 1 March, 1996 |
| |
| Authors: | C. Weider, C. Preston, K. Simonsen, H. Alvestrand, R. Atkinson, M. Crispin, P. Svanberg. |
| Date: | April 1997 |
| Formats: | txt html json |
| Updated by: | RFC 6055 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2130 |
|
This report details the conclusions of an IAB-sponsored invitational workshop held 29 February - 1 March, 1996, to discuss the use of character sets on the Internet. It motivates the need to have character set handling in Internet protocols which transmit text, provides a conceptual framework for specifying character sets, recommends the use of MIME tagging for transmitted text, recommends a default character set *without* stating that there is no need for other character sets, and makes a series of recommendations to theIAB, IANA, and the IESG for furthering the integration of the character set framework into text transmission protocols. |
|
| |
| RFC 2133 | Basic Socket Interface Extensions for IPv6 |
| |
| Authors: | R. Gilligan, S. Thomson, J. Bound, W. Stevens. |
| Date: | April 1997 |
| Formats: | txt json html |
| Obsoleted by: | RFC 2553 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2133 |
|
The de facto standard application program interface (API) for TCP/IP applications is the "sockets" interface. Although this API was developed for Unix in the early 1980s it has also been implemented on a wide variety of non-Unix systems. TCP/IP applications written using the sockets API have in the past enjoyed a high degree of portability and we would like the same portability with IPv6 applications. But changes are required to the sockets API to supportIPv6 and this memo describes these changes. These include a new socket address structure to carry IPv6 addresses, new address conversion functions, and some new socket options. These extensions are designed to provide access to the basic IPv6 features required byTCP and UDP applications, including multicasting, while introducing a minimum of change into the system and providing complete compatibility for existing IPv4 applications. Additional extensions for advanced IPv6 features (raw sockets and access to the IPv6 extension headers) are defined in another document [5]. |
|
| |
| RFC 2134 | Articles of Incorporation of Internet Society |
| |
| Authors: | ISOC Board of Trustees. |
| Date: | April 1997 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2134 |
|
These are the articles of incorporation of the Internet Society.They are published for the information of the IETF community at the request of the poisson working group. |
|
| |
| RFC 2135 | Internet Society By-Laws |
| |
| Authors: | ISOC Board of Trustees. |
| Date: | April 1997 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2135 |
|
These are the by-laws of the Internet Society, as amended, as of June1996. They are published for the information of the IETF community at the request of the poisson working group. Please refer to the ISOC web page (www.isoc.org) for the current version of the by-laws. |
|
| |
| RFC 2139 | RADIUS Accounting |
| |
|
|
This document describes a protocol for carrying accounting information between a Network Access Server and a shared AccountingServer. |
|
| |
| RFC 2140 | TCP Control Block Interdependence |
| |
|
|
This memo makes the case for interdependent TCP control blocks, where part of the TCP state is shared among similar concurrent connections, or across similar connection instances. TCP state includes a combination of parameters, such as connection state, current round- trip time estimates, congestion control information, and process information. This state is currently maintained on a per-connection basis in the TCP control block, but should be shared across connections to the same host. The goal is to improve transient transport performance, while maintaining backward-compatibility with existing implementations.
This document is a product of the LSAM project at ISI. |
|
| |
| RFC 2144 | The CAST-128 Encryption Algorithm |
| |
| Authors: | C. Adams. |
| Date: | May 1997 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2144 |
|
There is a need in the Internet community for an unencumbered encryption algorithm with a range of key sizes that can provide security for a variety of cryptographic applications and protocols.
This document describes an existing algorithm that can be used to satisfy this requirement. Included are a description of the cipher and the key scheduling algorithm (Section 2), the s-boxes (AppendixA), and a set of test vectors (Appendix B). |
|
| |
| RFC 2145 | Use and Interpretation of HTTP Version Numbers |
| |
| Authors: | J. C. Mogul, R. Fielding, J. Gettys, H. Frystyk. |
| Date: | May 1997 |
| Formats: | txt json html |
| Obsoleted by: | RFC 7230 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2145 |
|
HTTP request and response messages include an HTTP protocol version number. Some confusion exists concerning the proper use and interpretation of HTTP version numbers, and concerning interoperability of HTTP implementations of different protocol versions. This document is an attempt to clarify the situation. It is not a modification of the intended meaning of the existingHTTP/1.0 and HTTP/1.1 documents, but it does describe the intention of the authors of those documents, and can be considered definitive when there is any ambiguity in those documents concerning HTTP version numbers, for all versions of HTTP. |
|
| |
| RFC 2146 | U.S |
| |
| Authors: | Government Internet Domain Names. Federal Networking Council. |
| Date: | May 1997 |
| Formats: | txt html json |
| Obsoletes: | RFC 1816 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2146 |
|
This memo provides an update and clarification to RFC 1816. This document describes the registration policies for the top-level domain".GOV". The purpose of the domain is to provide naming conventions that identify US Federal government agencies in order to facilitate access to their electronic resources. This memo provides guidance for registrations by Federal Agencies that avoids name duplication and facilitates responsiveness to the public. It restricts registrations to coincide with the approved structure of the US government and the advice of its Chief Information Officers. Two documents are recognized as constituting documentation on the US government structure: FIPS 95-1 provides a standard recognized structure into which domain registrations for .GOV and FED.US can fit; and, the US Government Manual [3], a special publication of theFederal Register, provides official documentation of the government structure. The latter document may be subject to more timely updates than the former. Either document is suitable for determining which entities qualify for second-level domain registration within .GOV andFED.US.
As a side effect, this RFC reduces the number of .GOV and FED.US level registrations and reduces the workload on the registration authority. Previous versions of this document did not address theFED.US domain. This document anticipates the migration of the .GOV domain into the FED.US domain, in keeping with common practice on theInternet today. |
|
| |
| RFC 2149 | Multicast Server Architectures for MARS-based ATM multicasting |
| |
| Authors: | R. Talpade, M. Ammar. |
| Date: | May 1997 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2149 |
|
A mechanism to support the multicast needs of layer 3 protocols in general, and IP in particular, over UNI 3.0/3.1 based ATM networks has been described in RFC 2022. Two basic approaches exist for the intra-subnet (intra-cluster) multicasting of IP packets. One makes use of a mesh of point to multipoint VCs (the 'VC Mesh' approach), while the other uses a shared point to multipoint tree rooted on aMulticast Server (MCS). This memo provides details on the design and implementation of an MCS, building on the core mechanisms defined inRFC 2022. It also provides a mechanism for using multiple MCSs per group for providing fault tolerance. This approach can be used withRFC 2022 based MARS server and clients, without needing any change in their functionality. |
|
| |
| RFC 2150 | Humanities and Arts: Sharing Center Stage on the Internet |
| |
|
|
This document is designed primarily for individuals who have limited knowledge of, or experience with, the Internet.
The purpose of this document is to provide members of the Arts andHumanities communities with an introduction to the Internet as a valuable tool, resource, and medium for the creation, presentation, and preservation of Arts and Humanities-based content.
The intended audience is practicing artists, scholars, related professionals, and others whose knowledge, expertise and support is important to ensuring that the Arts and Humanities are well-placed in the global information infrastructure. |
|
| |
| RFC 2151 | A Primer On Internet and TCP/IP Tools and Utilities |
| |
|
|
This memo is an introductory guide to many of the most commonly- available TCP/IP and Internet tools and utilities. It also describes discussion lists accessible from the Internet, ways to obtainInternet and TCP/IP documents, and some resources that help users weave their way through the Internet. |
|
| |
| RFC 2152 | UTF-7 A Mail-Safe Transformation Format of Unicode |
| |
|
|
The Unicode Standard, version 2.0, and ISO/IEC 10646-1:1993(E) (as amended) jointly define a character set (hereafter referred to asUnicode) which encompasses most of the world's writing systems.However, Internet mail (STD 11, RFC 822) currently supports only 7- bit US ASCII as a character set. MIME (RFC 2045 through 2049) extendsInternet mail to support different media types and character sets, and thus could support Unicode in mail messages. MIME neither definesUnicode as a permitted character set nor specifies how it would be encoded, although it does provide for the registration of additional character sets over time.
This document describes a transformation format of Unicode that contains only 7-bit ASCII octets and is intended to be readable by humans in the limiting case that the document consists of characters from the US-ASCII repertoire. It also specifies how this transformation format is used in the context of MIME and RFC 1641,"Using Unicode with MIME". |
|
| |
| RFC 2153 | PPP Vendor Extensions |
| |
|
|
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection; and a family ofNetwork Control Protocols (NCPs) for establishing and configuring different network-layer protocols.
This document defines a general mechanism for proprietary vendor extensions. |
|
| |
| RFC 2166 | APPN Implementer's Workshop Closed Pages Document DLSw v2.0 Enhancements |
| |
| Authors: | D. Bryant, P. Brittain. |
| Date: | June 1997 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2166 |
|
This document specifies
- a set of extensions to RFC 1795 designed to improve the scalability of DLSw- clarifications to RFC 1795 in the light of the implementation experience to-date.
It is assumed that the reader is familiar with DLSw and RFC 1795. No effort has been made to explain these existing protocols or associated terminology.
This document was developed in the DLSw Related Interest Group (RIG) of the APPN Implementers Workshop (AIW). If you would like to participate in future DLSw discussions, please subscribe to the DLSwRIG mailing lists by sending a mail to majordomo@raleigh.ibm.com specifying 'subscribe aiw-dlsw' as the body of the message. |
|
| |
| RFC 2167 | Referral Whois (RWhois) Protocol V1.5 |
| |
| Authors: | S. Williamson, M. Kosters, D. Blacka, J. Singh, K. Zeilstra. |
| Date: | June 1997 |
| Formats: | txt html json |
| Obsoletes: | RFC 1714 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2167 |
|
This memo describes Version 1.5 of the client/server interaction ofRWhois. RWhois provides a distributed system for the discovery, retrieval, and maintenance of directory information. This system is primarily hierarchical by design. It allows for the deterministic routing of a query based on hierarchical tags, referring the user closer to the maintainer of the information. While RWhois can be considered a generic directory services protocol, it distinguishes itself from other protocols by providing an integrated, hierarchical architecture and query routing mechanism. |
|
| |
| RFC 2170 | Application REQuested IP over ATM (AREQUIPA) |
| |
| Authors: | W. Almesberger, J. Le Boudec, P. Oechslin. |
| Date: | July 1997 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2170 |
|
This document specifies a method for allowing ATM-attached hosts that have direct ATM connectivity to set up end-to-end IP over ATM connections within the reachable ATM cloud, on request from applications, and for the exclusive use by the requesting applications. This allows the requesting applications to benefit in a straightforward way from ATM's inherent ability to guarantee the quality of service (QoS).
Given a mapping from service classes, as defined by INTSERV[6], toATM traffic descriptors, Arequipa can be used to implement integrated services over ATM link layers. Usage of Arequipa to provide integrated services even if ATM is only available for intermediate links is not discussed in this document but should be straight- forward.
The major advantage of using an approach like Arequipa is that it needs to be implemented only on the hosts using it. It requires no extra service (eg. NHRP or RSVP) to be deployed on the switches or routers of the ATM cloud.
We discuss the implementation of Arequipa for hosts running IPv4 andIPv6. As an illustration, we also discuss how World-Wide-Web applications can use Arequipa to deliver documents with a guaranteed quality of service.
In particular we show how
- Arequipa can be implemented in IPv4 by slightly modifying the- Arequipa can be implemented in IPv6[3] by the appropriate use of flow labels and the extension of the neighbour cache,- Arequipa can be used in the Web by adding extra information in the headers of HTTP requests and responses.
Finally, we address safety and security implications. |
|
| |
| RFC 2171 | MAPOS - Multiple Access Protocol over SONET/SDH Version 1 |
| |
| Authors: | K. Murakami, M. Maruyama. |
| Date: | June 1997 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2171 |
|
This document describes the protocol MAPOS, Multiple Access Protocol over SONET/SDH, for transmitting network-protocol datagrams overSONET/SDH. It focuses on the core protocol -- other documents listed in the bibliography may be referenced in conjunction with this document to provide support and services for protocols at higher layers. |
|
| |
| RFC 2172 | MAPOS Version 1 Assigned Numbers |
| |
| Authors: | M. Maruyama, K. Murakami. |
| Date: | June 1997 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2172 |
|
This document describes the protocol parameters used in the MultipleAccess Over SONET/SDH (MAPOS) version 1. MAPOS is a link layer protocol and provides multiple access capability over SONET/SDH links. |
|
| |
| RFC 2173 | A MAPOS version 1 Extension - Node Switch Protocol |
| |
| Authors: | K. Murakami, M. Maruyama. |
| Date: | June 1997 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2173 |
|
This document describes a MAPOS extension, Node Switch Protocol, for automatic node address assignment. MAPOS is a multiple access protocol for transmission of network-protocol datagrams, encapsulated in High-Level Data Link Control (HDLC) frames, over SONET/SDH. NSP automates the HDLC address configuration of each node. Using NSP, a node retrieves its HDLC address from the switch to which it is connected. |
|
| |
| RFC 2174 | A MAPOS version 1 Extension - Switch-Switch Protocol |
| |
| Authors: | K. Murakami, M. Maruyama. |
| Date: | June 1997 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2174 |
|
This document describes a MAPOS version 1 extension, SSP (SwitchSwitch Protocol). MAPOS is a multiple access protocol for transmission of network-protocol packets, encapsulated in High-LevelData Link Control (HDLC) frames, over SONET/SDH. In MAPOS network, aSONET switch provides the multiple access capability to end nodes.SSP is a protocol of Distance Vector family and provides unicast and broadcast/multicast routing for multiple SONET switch environment. |
|
| |
| RFC 2175 | MAPOS 16 - Multiple Access Protocol over SONET/SDH with 16 Bit Addressing |
| |
| Authors: | K. Murakami, M. Maruyama. |
| Date: | June 1997 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2175 |
|
This document describes the protocol MAPOS 16, Multiple AccessProtocol over SONET/SDH with 16 Bit Addressing, for transmitting network-protocol datagrams over SONET/SDH. The primary difference with MAPOS version 1 is that it has 16 bit address field that offers significant wide address space. It first describes the major differences between MAPOS and MAPOS 16 briefly. Then, it explains the header format and its 16 bit address format. |
|
| |
| RFC 2176 | IPv4 over MAPOS Version 1 |
| |
|
|
This document describes a protocol for transmission of the InternetProtocol Version 4 (IPv4) over Multiple Access Over SONET/SDH (MAPOS) version 1. MAPOS is a link layer protocol and provides multiple access capability over SONET/SDH links. IP runs on top of MAPOS. This document explains IP datagram encapsulation in HDLC frame of MAPOS, and the Address Resolution Protocol (ARP). |
|
| |
| RFC 2179 | Network Security For Trade Shows |
| |
| Authors: | A. Gwinn. |
| Date: | July 1997 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2179 |
|
This document is designed to assist vendors and other participants in trade shows, such as Networld+Interop, in designing effective protection against network and system attacks by unauthorized individuals. Generally, it has been observed that many system administrators and trade show coordinators tend to overlook the importance of system security at trade shows. In fact, systems at trade shows are at least as prone to attack as office-based platforms. Trade show systems should be treated as seriously as an office computer. A breach of security of a trade show system can render -- and has rendered -- an exhibitor's demonstrations inoperable -- sometimes for the entire event!
This document is not intended to replace the multitudes of comprehensive books on the subject of Internet security. Rather, its purpose is to provide a checklist-style collection of frequently overlooked, simple ways to minimize the chance of a costly attack.We encourage exhibitors to pay special attention to this document and share it with all associated representatives. |
|
| |
| RFC 2180 | IMAP4 Multi-Accessed Mailbox Practice |
| |
| Authors: | M. Gahrns. |
| Date: | July 1997 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2180 |
|
The behavior described in this document reflects the practice of some existing servers or behavior that the consensus of the IMAP mailing list has deemed to be reasonable. The behavior described within this document is believed to be [RFC-2060] compliant. However, this document is not meant to define IMAP4 compliance, nor is it an exhaustive list of valid IMAP4 behavior. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 2185 | Routing Aspects of IPv6 Transition |
| |
| Authors: | R. Callon, D. Haskin. |
| Date: | September 1997 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2185 |
|
This document gives an overview of the routing aspects of the IPv6 transition. It is based on the protocols defined in the document"Transition Mechanisms for IPv6 Hosts and Routers" [1]. Readers should be familiar with the transition mechanisms before reading this document.
The proposals contained in this document are based on the work of theNgtrans working group. |
|
| |
| RFC 2186 | Internet Cache Protocol (ICP), version 2 |
| |
| Authors: | D. Wessels, K. Claffy. |
| Date: | September 1997 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2186 |
|
This document describes version 2 of the Internet Cache Protocol(ICPv2) as currently implemented in two World-Wide Web proxy cache packages[3,5]. ICP is a lightweight message format used for communicating among Web caches. ICP is used to exchange hints about the existence of URLs in neighbor caches. Caches exchange ICP queries and replies to gather information to use in selecting the most appropriate location from which to retrieve an object.
This document describes only the format and fields of ICP messages.A companion document (RFC2187) describes the application of ICP toWeb caches. Several independent caching implementations now use ICP, and we consider it important to codify the existing practical uses ofICP for those trying to implement, deploy, and extend its use for their own purposes. |
|
| |
| RFC 2187 | Application of Internet Cache Protocol (ICP), version 2 |
| |
| Authors: | D. Wessels, K. Claffy. |
| Date: | September 1997 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2187 |
|
This document describes the application of ICPv2 (Internet CacheProtocol version 2, RFC2186) to Web caching. ICPv2 is a lightweight message format used for communication among Web caches. Several independent caching implementations now use ICP[3,5], making it important to codify the existing practical uses of ICP for those trying to implement, deploy, and extend its use.
ICP queries and replies refer to the existence of URLs (or objects) in neighbor caches. Caches exchange ICP messages and use the gathered information to select the most appropriate location from which to retrieve an object. A companion document (RFC2186) describes the format and syntax of the protocol itself. In this document we focus on issues of ICP deployment, efficiency, security, and interaction with other aspects of Web traffic behavior. |
|
| |
| RFC 2188 | AT&T/Neda's Efficient Short Remote Operations (ESRO) Protocol Specification Version 1.2 |
| |
| Authors: | M. Banan, M. Taylor, J. Cheng. |
| Date: | September 1997 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2188 |
|
This document specifies the service model, the notation and protocol for Efficient Short Remote Operations (ESRO). The ESRO service is similar to and is consistent with other Remote Procedure Call services. The emphasis of ESRO service definition and the ESRO protocol is on efficiency. ESRO is designed specifically with wireless network (e.g., CDPD) usage in mind.
ESRO protocol provides reliable connectionless remote operation services on top of UDP (or any other non-reliable connectionless transport service) with minimum overhead. ESRO protocol supports segmentation and reassembly, concatenation and separation as well as multiplexing for service users (applications).
ESRO allows for trade-offs between efficiency and reliability by specifying both 2-way hand-shake and 3-way hand-shake based protocols.
Encoding mechanisms for presentation of the parameters of remote operations are outside the scope of this document. But, identification (tagging) of the encoding mechanism in use (e.g., XDR,
BER, PER) is supported by ESRO protocol.
A variety of applications can use the ESRO protocol. Some early applications using ESRO include efficient short message submission and delivery, credit card authorization and white pages lookup. |
|
| |
| RFC 2191 | VENUS - Very Extensive Non-Unicast Service |
| |
| Authors: | G. Armitage. |
| Date: | September 1997 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2191 |
|
The MARS model (RFC2022) provides a solution to intra-LIS IP multicasting over ATM, establishing and managing the use of ATM pt- mpt SVCs for IP multicast packet forwarding. Inter-LIS multicast forwarding is achieved using Mrouters, in a similar manner to which the "Classical IP over ATM" model uses Routers to inter-connect LISes for unicast traffic. The development of unicast IP shortcut mechanisms (e.g. NHRP) has led some people to request the development of a Multicast equivalent. There are a number of different approaches. This document focuses exclusively on the problems associated with extending the MARS model to cover multiple clusters or clusters spanning more than one subnet. It describes a hypothetical solution, dubbed "Very Extensive NonUnicast Service"(VENUS), and shows how complex such a service would be. It is also noted that VENUS ultimately has the look and feel of a single, large cluster using a distributed MARS. This document is being issued to help focus ION efforts towards alternative solutions for establishingATM level multicast connections between LISes. |
|
| |
| RFC 2194 | Review of Roaming Implementations |
| |
| Authors: | B. Aboba, J. Lu, J. Alsop, J. Ding, W. Wang. |
| Date: | September 1997 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2194 |
|
This document reviews the design and functionality of existing roaming implementations. Examples of cases where roaming capability might be required include ISP "confederations" and ISP-provided corporate network access support. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 2196 | Site Security Handbook |
| |
|
|
This handbook is a guide to developing computer security policies and procedures for sites that have systems on the Internet. The purpose of this handbook is to provide practical guidance to administrators trying to secure their information and services. The subjects covered include policy content and formation, a broad range of technical system and network security topics, and security incident response. |
|
| |
| RFC 2199 | Request for Comments Summary RFC Numbers 2100-2199 |
| |
| Authors: | A. Ramos. |
| Date: | January 1998 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2199 |
|
|
|
| |
| RFC 2202 | Test Cases for HMAC-MD5 and HMAC-SHA-1 |
| |
| Authors: | P. Cheng, R. Glenn. |
| Date: | September 1997 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2202 |
|
This document provides two sets of test cases for HMAC-MD5 and HMAC-SHA-1, respectively. HMAC-MD5 and HMAC-SHA-1 are two constructs of the HMAC [HMAC] message authentication function using the MD5 [MD5] hash function and the SHA-1 [SHA] hash function. Both constructs are used by IPSEC [OG,CG] and other protocols to authenticate messages.The test cases and results provided in this document are meant to be used as a conformance test for HMAC-MD5 and HMAC-SHA-1 implementations. |
|
| |
| RFC 2204 | ODETTE File Transfer Protocol |
| |
|
|
This memo describes a file transfer protocol to facilitate electronic data interchange between trading partners.
The protocol, denoted the ODETTE File Transfer Protocol, supports both direct communication between installations and indirect communication via a third party clearing centre. It was developed by the Organisation for Data Exchange by Tele Transmission in Europe to facilitate communication within the European motor industry and is presented here to allow for wider use within the Internet community. |
|
| |
| RFC 2208 | Resource ReSerVation Protocol (RSVP) -- Version 1 Applicability Statement Some Guidelines on Deployment |
| |
| Authors: | A. Mankin, Ed., F. Baker, B. Braden, S. Bradner, M. O'Dell, A. Romanow, A. Weinrib, L. Zhang. |
| Date: | September 1997 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2208 |
|
This document describes the applicability of RSVP along with theIntegrated Services protocols and other components of resource reservation and offers guidelines for deployment of resource reservation at this time. This document accompanies the first submission of RSVP and integrated services specifications onto theInternet standards track. |
|
| |
| RFC 2209 | Resource ReSerVation Protocol (RSVP) -- Version 1 Message Processing Rules |
| |
| Authors: | R. Braden, L. Zhang. |
| Date: | September 1997 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2209 |
|
This memo contains an algorithmic description of the rules used by anRSVP implementation for processing messages. It is intended to clarify the version 1 RSVP protocol specification.
This memo provides a generic description of the rules for the operation of Version 1 of RSVP [RFC 2205]. It is intended to outline a set of algorithms that will accomplish the needed function, omitting many details. |
|
| |
| RFC 2216 | Network Element Service Specification Template |
| |
| Authors: | S. Shenker, J. Wroclawski. |
| Date: | September 1997 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2216 |
|
This document defines a framework for specifying services provided by network elements, and available to applications, in an internetwork which offers multiple qualities of service. The document first provides some necessary context -- including relevant definitions and suggested data formats -- and then specifies a "template" which service specification documents should follow. The specification template includes per-element requirements such as the service's packet handling behavior, parameters required and made available by the service, traffic specification and policing requirements, and traffic ordering relationships. It also includes evaluation criteria for elements providing the service, and examples of how the service might be implemented (by network elements) and used (by applications). |
|
| |
| RFC 2220 | The Application/MARC Content-type |
| |
| Authors: | R. Guenther. |
| Date: | October 1997 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2220 |
|
This memorandum provides a mechanism for representing objects which are files of Machine-Readable Cataloging records (MARC). The MARC formats are standards for the representation and communication of bibliographic and related information. A MARC record contains metadata for an information resource following MARC format specifications. |
|
| |
| RFC 2223 | Instructions to RFC Authors |
| |
|
|
This Request for Comments (RFC) provides information about the preparation of RFCs, and certain policies relating to the publication of RFCs. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 2224 | NFS URL Scheme |
| |
| Authors: | B. Callaghan. |
| Date: | October 1997 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2224 |
|
A new URL scheme, 'nfs' is defined. It is used to refer to files and directories on NFS servers using the general URL syntax defined inRFC 1738, "Uniform Resource Locators (URL)".
This scheme uses the public filehandle and multi-component lookup[RFC2054, RFC2055] to access server data with a minimum of protocol overhead.
The NFS protocol provides access to shared filesystems across networks. It is designed to be machine, operating system, network architecture, and transport protocol independent. The protocol currently exists in two versions: version 2 [RFC1094] and version 3[RFC1813], both built on ONC RPC [RFC1831] at its associated eXternalData Representation (XDR) [RFC1832] and Binding Protocol [RFC1833]. |
|
| |
| RFC 2229 | A Dictionary Server Protocol |
| |
| Authors: | R. Faith, B. Martin. |
| Date: | October 1997 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2229 |
|
The Dictionary Server Protocol (DICT) is a TCP transaction based query/response protocol that allows a client to access dictionary definitions from a set of natural language dictionary databases. |
|
| |
| RFC 2230 | Key Exchange Delegation Record for the DNS |
| |
| Authors: | R. Atkinson. |
| Date: | November 1997 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2230 |
|
This note describes a mechanism whereby authorisation for one node to act as key exchanger for a second node is delegated and made available via the Secure DNS. This mechanism is intended to be used only with the Secure DNS. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. |
|
| |
| RFC 2235 | 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. |
|
| |
| RFC 2237 | Japanese Character Encoding for Internet Messages |
| |
| Authors: | K. Tamaru. |
| Date: | November 1997 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2237 |
|
This memo defines an encoding scheme for the Japanese Characters, describes "ISO-2022-JP-1", which is used in electronic mail [RFC-822], and network news [RFC 1036]. Also this memo provides a listing of the Japanese Character Set that can be used in this encoding scheme. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. |
|
| |
| RFC 2240 | A Legal Basis for Domain Name Allocation |
| |
|
|
The purpose of this memo is to focus discussion on the particular problems with the exhaustion of the top level domain space in the Internet and the possible conflicts that can occur when multiple organisations are vying for the same name. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. |
|
| |
| RFC 2258 | Internet Nomenclator Project |
| |
| Authors: | J. Ordille. |
| Date: | January 1998 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2258 |
|
The goal of the Internet Nomenclator Project is to integrate the hundreds of publicly available CCSO servers from around the world.Each CCSO server has a database schema that is tailored to the needs of the organization that owns it. The project is integrating the different database schema into one query service. The InternetNomenclator Project will provide fast cross-server searches for locating people on the Internet. It augments existing CCSO services by supplying schema integration, more extensive indexing, and two kinds of caching -- all this in a system that scales as the number ofCCSO servers grows. One of the best things about the system is that administrators can incorporate their CCSO servers into Nomenclator without changing the servers. All Nomenclator needs is basic information about the server.
This document provides an overview of the Nomenclator system, describes how to register a CCSO server in the Internet NomenclatorProject, and how to use the Nomenclator search engine to find people on the Internet. |
|
| |
| RFC 2259 | Simple Nomenclator Query Protocol (SNQP) |
| |
| Authors: | J. Elliott, J. Ordille. |
| Date: | January 1998 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2259 |
|
The Simple Nomenclator Query Protocol (SNQP) allows a client to communicate with a descriptive name service or other relational-style query service. The protocol is useful to services that search many data repositories for query responses. Clients can pose queries on relations, list descriptions of relations, and obtain advice on reducing the search time and cost of their queries. Clients are informed of the age of information in caches, and may request more recent information. SNQP provides support for graphical user interfaces. It also supports different types of comparison operators, so services can use SNQP with a variety of back-end servers, e.g. relational database servers, CCSO servers, and servers providing relational views of X.500.
SNQP is an ASCII protocol in the request-reply style of SMTP. It was specifically designed for use with the Nomenclator name and information service, and has been useful elsewhere. |
|
| |
| RFC 2260 | Scalable Support for Multi-homed Multi-provider Connectivity |
| |
| Authors: | T. Bates, Y. Rekhter. |
| Date: | January 1998 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2260 |
|
This document describes addressing and routing strategies for multi- homed enterprises attached to multiple Internet Service Providers (ISPs) that are intended to reduce the routing overhead due to these enterprises in the global Internet routing system. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. |
|
| |
| RFC 2267 | Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing |
| |
| Authors: | P. Ferguson, D. Senie. |
| Date: | January 1998 |
| Formats: | txt json html |
| Obsoleted by: | RFC 2827 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2267 |
|
Recent occurrences of various Denial of Service (DoS) attacks which have employed forged source addresses have proven to be a troublesome issue for Internet Service Providers and the Internet community overall. This paper discusses a simple, effective, and straightforward method for using ingress traffic filtering to prohibit DoS attacks which use forged IP addresses to be propagated from 'behind' an Internet Service Provider's (ISP) aggregation point. |
|
| |
| RFC 2268 | A Description of the RC2(r) Encryption Algorithm |
| |
| Authors: | R. Rivest. |
| Date: | March 1998 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2268 |
|
This memo describes a conventional (secret-key) block encryption algorithm, called RC2, which may be considered as a proposal for a DES replacement. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. |
|
| |
| RFC 2269 | Using the MARS Model in non-ATM NBMA Networks |
| |
| Authors: | G. Armitage. |
| Date: | January 1998 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2269 |
|
Initially developed for IP over ATM, the RFC 2022 (MARS) model is also applicable to other NBMA networks that provide the equivalent of switched, point to multipoint connections. This short document is intended to state the obvious equivalences, and explain the less obvious implications. No changes to the MARS model per se are suggested or required. RFC 2022 is not required over NBMA networks that offer Ethernet-like group addressing functionality. |
|
| |
| RFC 2270 | Using a Dedicated AS for Sites Homed to a Single Provider |
| |
| Authors: | J. Stewart, T. Bates, R. Chandra, E. Chen. |
| Date: | January 1998 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2270 |
|
With the increased growth of the Internet, the number of customers using BGP4 has grown significantly. RFC1930 outlines a set of guidelines for when one needs and should use an AS. However, the customer and service provider (ISP) are left with a problem as a result of this in that while there is no need for an allocated AS under the guidelines, certain conditions make the use of BGP4 a very pragmatic and perhaps only way to connect a customer homed to a single ISP. This paper proposes a solution to this problem in line with recommendations set forth in RFC1930. |
|
| |
| RFC 2276 | Architectural Principles of Uniform Resource Name Resolution |
| |
|
|
This document addresses the issues of the discovery of URN (UniformResource Name) resolver services that in turn will directly translateURNs into URLs (Uniform Resource Locators) and URCs (Uniform ResourceCharacteristics). The document falls into three major parts, the assumptions underlying the work, the guidelines in order to be a viable Resolver Discovery Service or RDS, and a framework for designing RDSs. The guidelines fall into three principle areas: evolvability, usability, and security and privacy. An RDS that is compliant with the framework will not necessarily be compliant with the guidelines. Compliance with the guidelines will need to be validated separately. |
|
| |
| RFC 2278 | IANA Charset Registration Procedures |
| |
|
|
MIME [RFC-2045, RFC-2046, RFC-2047, RFC-2184] and various other modern Internet protocols are capable of using many different charsets. This in turn means that the ability to label different charsets is essential. This registration procedure exists solely to associate a specific name or names with a given charset and to give an indication of whether or not a given charset can be used in MIME text objects. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. |
|
| |
| RFC 2281 | Cisco Hot Standby Router Protocol (HSRP) |
| |
| Authors: | T. Li, B. Cole, P. Morton, D. Li. |
| Date: | March 1998 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2281 |
|
The memo specifies the Hot Standby Router Protocol (HSRP). The goal of the protocol is to allow hosts to appear to use a single router and to maintain connectivity even if the actual first hop router they are using fails. Multiple routers participate in this protocol and in concert create the illusion of a single virtual router. The protocol insures that one and only one of the routers is forwarding packets on behalf of the virtual router. End hosts forward their packets to the virtual router.
The router forwarding packets is known as the active router. A standby router is selected to replace the active router should it fail. The protocol provides a mechanism for determining active and standby routers, using the IP addresses on the participating routers.If an active router fails a standby router can take over without a major interruption in the host's connectivity. This memo also discusses the ARP, MAC address, and security issues with this protocol. |
|
| |
| RFC 2282 | IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees |
| |
|
|
The process by which the members of the IAB and IESG are selected, confirmed, and recalled is specified. The evolution of the process has relied principally on oral tradition as a means by which the lessons learned could be passed on to successive committees. This document is a self-consistent, organized compilation of the process as it is known today. |
|
| |
| RFC 2285 | Benchmarking Terminology for LAN Switching Devices |
| |
| Authors: | R. Mandeville. |
| Date: | February 1998 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2285 |
|
This document is intended to provide terminology for the benchmarking of local area network (LAN) switching devices. It extends the terminology already defined for benchmarking network interconnect devices in RFCs 1242 and 1944 to switching devices. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. |
|
| |
| RFC 2286 | Test Cases for HMAC-RIPEMD160 and HMAC-RIPEMD128 |
| |
| Authors: | J. Kapp. |
| Date: | February 1998 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2286 |
|
This document provides two sets of test cases for HMAC-RIPEMD160 andHMAC-RIPEMD128, respectively. HMAC-RIPEMD160 and HMAC-RIPEMD128 are two constructs of the HMAC [HMAC] message authentication function using the RIPEMD-160 and RIPEMD-128 [RIPE] hash functions. The test cases and results provided in this document are meant to be used as a conformance test for HMAC-RIPEMD160 and HMAC-RIPEMD128 implementations. |
|
| |
| RFC 2288 | Using Existing Bibliographic Identifiers as Uniform Resource Names |
| |
| Authors: | C. Lynch, C. Preston, R. Daniel. |
| Date: | February 1998 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2288 |
|
A system for Uniform Resource Names (URNs) must be capable of supporting identifiers from existing widely-used naming systems.This document discusses how three major bibliographic identifiers(the ISBN, ISSN and SICI) can be supported within the URN framework and the currently proposed syntax for URNs. |
|
| |
| RFC 2291 | Requirements for a Distributed Authoring and Versioning Protocol for the World Wide Web |
| |
| Authors: | J. Slein, F. Vitali, E. Whitehead, D. Durand. |
| Date: | February 1998 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2291 |
|
Current World Wide Web (WWW or Web) standards provide simple support for applications which allow remote editing of typed data. In practice, the existing capabilities of the WWW have proven inadequate to support efficient, scalable remote editing free of overwriting conflicts. This document presents a list of features in the form of requirements for a Web Distributed Authoring and Versioning protocol which, if implemented, would improve the efficiency of common remote editing operations, provide a locking mechanism to prevent overwrite conflicts, improve link management support between non-HTML data types, provide a simple attribute-value metadata facility, provide for the creation and reading of container data types, and integrate versioning into the WWW. |
|
| |
| RFC 2292 | Advanced Sockets API for IPv6 |
| |
| Authors: | W. Stevens, M. Thomas. |
| Date: | February 1998 |
| Formats: | txt json html |
| Obsoleted by: | RFC 3542 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2292 |
|
Specifications are in progress for changes to the sockets API to support IP version 6 [RFC-2133]. These changes are for TCP and UDP- based applications and will support most end-user applications in use today: Telnet and FTP clients and servers, HTTP clients and servers, and the like.
But another class of applications exists that will also be run underIPv6. We call these "advanced" applications and today this includes programs such as Ping, Traceroute, routing daemons, multicast routing daemons, router discovery daemons, and the like. The API feature typically used by these programs that make them "advanced" is a raw socket to access ICMPv4, IGMPv4, or IPv4, along with some knowledge of the packet header formats used by these protocols. To provide portability for applications that use raw sockets under IPv6, some standardization is needed for the advanced API features.
There are other features of IPv6 that some applications will need to access: interface identification (specifying the outgoing interface and determining the incoming interface) and IPv6 extension headers that are not addressed in [RFC-2133]: Hop-by-Hop options, Destination options, and the Routing header (source routing). This document provides API access to these features too. |
|
| |
| RFC 2297 | Ipsilon's General Switch Management Protocol Specification Version 2.0 |
| |
| Authors: | P. Newman, W. Edwards, R. Hinden, E. Hoffman, F. Ching Liaw, T. Lyon, G. Minshall. |
| Date: | March 1998 |
| Formats: | txt json html |
| Updates: | RFC 1987 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2297 |
|
This memo specifies enhancements to the General Switch ManagementProtocol (GSMP) [RFC1987]. The major enhancement is the addition ofQuality of Service (QoS) messages. Other improvements have been made to the protocol resulting from operational experience. GSMP is a general purpose protocol to control an ATM switch. It allows a controller to establish and release connections across the switch; add and delete leaves on a multicast connection; manage switch ports; request configuration information; and request statistics. |
|
| |
| RFC 2299 | Request for Comments Summary |
| |
| Authors: | A. Ramos. |
| Date: | January 1999 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2299 |
|
|
|
| |
| RFC 2306 | Tag Image File Format (TIFF) - F Profile for Facsimile |
| |
| Authors: | G. Parsons, J. Rafferty. |
| Date: | March 1998 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2306 |
|
This document describes in detail the definition of TIFF-F that is used to store facsimile images. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. |
|
| |
| RFC 2309 | Recommendations on Queue Management and Congestion Avoidance in the Internet |
| |
| Authors: | B. Braden, D. Clark, J. Crowcroft, B. Davie, S. Deering, D. Estrin, S. Floyd, V. Jacobson, G. Minshall, C. Partridge, L. Peterson, K. Ramakrishnan, S. Shenker, J. Wroclawski, L. Zhang. |
| Date: | April 1998 |
| Formats: | txt html json |
| Obsoleted by: | RFC 7567 |
| Updated by: | RFC 7141 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2309 |
|
This memo presents two recommendations to the Internet community concerning measures to improve and preserve Internet performance.It presents a strong recommendation for testing, standardization, and widespread deployment of active queue management in routers, to improve the performance of today's Internet. It also urges a concerted effort of research, measurement, and ultimate deployment of router mechanisms to protect the Internet from flows that are not sufficiently responsive to congestion notification. |
|
| |
| RFC 2313 | PKCS #1: RSA Encryption Version 1.5 |
| |
|
|
This document describes a method for encrypting data using the RSA public-key cryptosystem. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. |
|
| |
| RFC 2314 | PKCS #10: Certification Request Syntax Version 1.5 |
| |
|
|
This document describes a syntax for certification requests. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. |
|
| |
| RFC 2315 | PKCS #7: Cryptographic Message Syntax Version 1.5 |
| |
| Authors: | B. Kaliski. |
| Date: | March 1998 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2315 |
|
This document describes a general syntax for data that may have cryptography applied to it, such as digital signatures and digital envelopes. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. |
|
| |
| RFC 2316 | Report of the IAB Security Architecture Workshop |
| |
| Authors: | S. Bellovin. |
| Date: | April 1998 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2316 |
|
On 3-5 March 1997, the IAB held a security architecture workshop at Bell Labs in Murray Hill, NJ. We identified the core security components of the architecture, and specified several documents that need to be written. Most importantly, we agreed that security was not optional, and that it needed to be designed in from the beginning. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. |
|
| |
| RFC 2318 | The text/css Media Type |
| |
| Authors: | H. Lie, B. Bos, C. Lilley. |
| Date: | March 1998 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2318 |
|
Cascading Style Sheets (CSS) is a style sheet language for the WorldWide Web. CSS style sheets have been in use since October 1995 using the Media Type text/css without registration; this memo seeks to regularize that position. |
|
| |
| RFC 2319 | Ukrainian Character Set KOI8-U |
| |
| Authors: | KOI8-U Working Group. |
| Date: | April 1998 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2319 |
|
This document provides information about character encoding KOI8-U(KOI8 Ukrainian) wich is a de-facto standard in Ukrainian Internet community. KOI8-U is compatible with KOI8-R (RFC 1489) in allRussian letters and extends it with four Ukrainian letters which locations are compliant with ISO-IR-111. The official site of KOI8-UWorking Group is http://www.net.ua. |
|
| |
| RFC 2321 | RITA -- The Reliable Internetwork Troubleshooting Agent |
| |
| Authors: | A. Bressen. |
| Date: | 1 April 1998 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2321 |
|
A Description of the usage of Nondeterministic Troubleshooting andDiagnostic Methodologies as applied to today's complex nondeterministic networks and environments. |
|
| |
| RFC 2322 | Management of IP numbers by peg-dhcp |
| |
| Authors: | K. van den Hout, A. Koopal, R. van Mook. |
| Date: | 1 April 1998 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2322 |
|
This RFC describes a protocol to dynamically hand out ip-numbers on field networks and small events that don't necessarily have a clear organisational body. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. |
|
| |
| RFC 2323 | IETF Identification and Security Guidelines |
| |
| Authors: | A. Ramos. |
| Date: | 1 April 1998 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2323 |
|
This RFC is meant to represent a guideline by which the IETF conferences may run more effeciently with regards to identification and security protocols, with specific attention paid to a particular sub-group within the IETF: "facial hairius extremis". This memo provides information for the Internet community. It does not specify an Internet standard of any kind. |
|
| |
| RFC 2324 | Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0) |
| |
|
|
This document describes HTCPCP, a protocol for controlling, monitoring, and diagnosing coffee pots. |
|
| |
| RFC 2325 | Definitions of Managed Objects for Drip-Type Heated Beverage Hardware Devices using SMIv2 |
| |
| Authors: | M. Slavitch. |
| Date: | 1 April 1998 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2325 |
|
This memo defines an extension to the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for the management of coffee-brewing and maintenance devices. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. |
|
| |
| RFC 2329 | OSPF Standardization Report |
| |
| Authors: | J. Moy. |
| Date: | April 1998 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2329 |
|
This memo documents how the requirements for advancing a routing protocol to Full Standard, set out in [Ref2], have been met forOSPFv2.
Please send comments to ospf@gated.cornell.edu. |
|
| |
| RFC 2330 | Framework for IP Performance Metrics |
| |
|
|
The purpose of this memo is to define a general framework for particular metrics to be developed by the IETF's IP Performance Metrics effort. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. |
|
| |
| RFC 2336 | Classical IP and ARP over ATM to NHRP Transition |
| |
| Authors: | J. Luciani. |
| Date: | July 1998 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2336 |
|
This document describes methods and procedures for the graceful transition from an ATMARP LIS[1] to an NHRP LIS[2] network model overATM. |
|
| |
| RFC 2339 | An Agreement Between the Internet Society, the IETF, and Sun Microsystems, Inc |
| |
| Authors: | in the matter of NFS V.4 Protocols. The Internet Society, Sun Microsystems. |
| Date: | May 1998 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2339 |
|
This Request for Comments records an agreement between SunMicrosystems, Inc. and the Internet Society to permit the flow ofSun's Network File System specifications into the Internet Standards process conducted by the Internet Engineering Task Force. |
|
| |
| RFC 2340 | Nortel's Virtual Network Switching (VNS) Overview |
| |
| Authors: | B. Jamoussi, D. Jamieson, D. Williston, S. Gabe. |
| Date: | May 1998 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2340 |
|
This document provides an overview of Virtual Network Switching(VNS).
VNS is a multi-protocol switching architecture that provides COS- sensitive packet switching, reduces the complexity of operating protocols like PPP and frame relay, provides logical networks and traffic segregation for Virtual Private Networks (VPNs), security and traffic engineering, enables efficient WAN broadcasting and multicasting, and reduces address space requirements. VNS reduces the number of routing hops over the WAN by switching packets based on labels.
VNS has been proven in production networks for several years. |
|
| |
| RFC 2346 | Making Postscript and PDF International |
| |
| Authors: | J. Palme. |
| Date: | May 1998 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2346 |
|
Certain text formats, for example Postscript (MIME-Type: application/postscript; file extension .ps) and Portable DocumentFormat (MIME-Type: application/pdf; file extension .pdf) specify exactly the page layout of the printed document. The commonly used paper format is different in North America and the rest of the world.North America uses the 'Letter' format, while the rest of the world mostly uses the ISO-standard 'A4' format. This means that documents formatted on one continent may not be easily printable on another continent. This memo gives advice on how to produce documents which are equally well printable with the Letter and the A4 formats. By using the advice in this document, you can put up a document on theInternet, which recipients can print without problem both in and outside North America.
A very short summary of the advice in this document: If you are usingU.S. Letter paper format, ensure that both the left and right margins are at least 21 mm (0.8 in). If you are using A4 paper format, ensure that both the top and bottom margins are at least 33 mm (1.3 in). |
|
| |
| RFC 2351 | Mapping of Airline Reservation, Ticketing, and Messaging Traffic over IP |
| |
| Authors: | A. Robert. |
| Date: | May 1998 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2351 |
|
This memo specifies a protocol for the encapsulation of the airline specific protocol over IP. |
|
| |
| RFC 2352 | A Convention For Using Legal Names as Domain Names |
| |
|
|
The purpose of this memo is to focus discussion on the particular problems with the exhaustion of the top level domain space in the Internet and the possible conflicts that can occur when multiple organisations are vying for the same name. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. |
|
| |
| RFC 2353 | APPN/HPR in IP Networks APPN Implementers' Workshop Closed Pages Document |
| |
| Authors: | G. Dudley. |
| Date: | May 1998 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2353 |
|
This memo defines a method with which HPR nodes can use IP networks for communication, and the enhancements to APPN required by this method. This memo also describes an option set that allows the use of the APPN connection network model to allow HPR nodes to use IP networks for communication without having to predefine link connections. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. |
|
| |
| RFC 2354 | Options for Repair of Streaming Media |
| |
| Authors: | C. Perkins, O. Hodson. |
| Date: | June 1998 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2354 |
|
This document summarizes a range of possible techniques for the repair of continuous media streams subject to packet loss. The techniques discussed include redundant transmission, retransmission, interleaving and forward error correction. The range of applicability of these techniques is noted, together with the protocol requirements and dependencies. |
|
| |
| RFC 2356 | Sun's SKIP Firewall Traversal for Mobile IP |
| |
| Authors: | G. Montenegro, V. Gupta. |
| Date: | June 1998 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2356 |
|
The Mobile IP specification establishes the mechanisms that enable a mobile host to maintain and use the same IP address as it changes its point of attachment to the network. Mobility implies higher security risks than static operation, because the traffic may at times take unforeseen network paths with unknown or unpredictable security characteristics. The Mobile IP specification makes no provisions for securing data traffic. The mechanisms described in this document allow a mobile node out on a public sector of the internet to negotiate access past a SKIP firewall, and construct a secure channel into its home network.
In addition to securing traffic, our mechanisms allow a mobile node to roam into regions that (1) impose ingress filtering, and (2) use a different address space. |
|
| |
| RFC 2357 | IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols |
| |
| Authors: | A. Mankin, A. Romanow, S. Bradner, V. Paxson. |
| Date: | June 1998 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2357 |
|
This memo describes the procedures and criteria for reviewing reliable multicast protocols within the Transport Area (TSV) of theIETF. Within today's Internet, important applications exist for a reliable multicast service. Some examples that are driving reliable multicast technology are collaborative workspaces (such as whiteboard), data and software distribution, and (more speculatively) web caching protocols. Due to the nature of the technical issues, a single commonly accepted technical solution that solves all the demands for reliable multicast is likely to be infeasible [RMMinutes1997].
A number of reliable multicast protocols have already been developed to solve a variety of problems for various types of applications.[Floyd97] describes one widely deployed example. How should these protocols be treated within the IETF and how should the IETF guide the development of reliable multicast in a direction beneficial for the general Internet?
The TSV Area Directors and their Directorate have outlined a set of review procedures that address these questions and set criteria and processes for the publication as RFCs of Internet-Drafts on reliable multicast transport protocols. |
|
| |
| RFC 2361 | WAVE and AVI Codec Registries |
| |
| Authors: | E. Fleischman. |
| Date: | June 1998 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2361 |
|
Internet applications may reference specific codecs within the WAVE and AVI registries as follows:* video/vnd.avi; codec=XXX identifies a specific video codec (i.e.,XXX) within the AVI Registry.* audio/vnd.wave; codec=YYY identifies a specific audio codec(i.e., YYY) within the WAVE Registry.
Appendix A and Appendix B provides an authoritative reference for the interpretation of the required "codec" parameter. That is, the current set of audio codecs that are registered within the WAVERegistry are enumerated in Appendix A. Appendix B enumerates the current set of video codecs that have been registered to date within the AVI Registry. |
|
| |
| RFC 2367 | PF_KEY Key Management API, Version 2 |
| |
| Authors: | D. McDonald, C. Metz, B. Phan. |
| Date: | July 1998 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2367 |
|
A generic key management API that can be used not only for IPSecurity [Atk95a] [Atk95b] [Atk95c] but also for other network security services is presented in this document. Version 1 of thisAPI was implemented inside 4.4-Lite BSD as part of the U. S. NavalResearch Laboratory's freely distributable and usable IPv6 and IPsec implementation[AMPMC96]. It is documented here for the benefit of others who might also adopt and use the API, thus providing increased portability of key management applications (e.g. a manual keying application, an ISAKMP daemon, a GKMP daemon [HM97a][HM97b], aPhoturis daemon, or a SKIP certificate discovery protocol daemon). |
|
| |
| RFC 2372 | Transaction Internet Protocol - Requirements and Supplemental Information |
| |
| Authors: | K. Evans, J. Klein, J. Lyon. |
| Date: | July 1998 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2372 |
|
This document describes the purpose (usage scenarios), and requirements for the Transaction Internet Protocol [1]. It is intended to help qualify the necessary features and functions of the protocol. It also provides supplemental information to aid understanding and facilitate implementation of the TIP protocol. |
|
| |
| RFC 2375 | IPv6 Multicast Address Assignments |
| |
| Authors: | R. Hinden, S. Deering. |
| Date: | July 1998 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2375 |
|
This document defines the initial assignment of IPv6 multicast addresses. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. |
|
| |
| RFC 2376 | XML Media Types |
| |
|
|
This document proposes two new media subtypes, text/xml and application/xml, for use in exchanging network entities which are conforming Extensible Markup Language (XML). XML entities are currently exchanged via the HyperText Transfer Protocol on the WorldWide Web, are an integral part of the WebDAV protocol for remote web authoring, and are expected to have utility in many domains. |
|
| |
| RFC 2377 | Naming Plan for Internet Directory-Enabled Applications |
| |
| Authors: | A. Grimstad, R. Huber, S. Sataluri, M. Wahl. |
| Date: | September 1998 |
| Formats: | txt html json |
| Updated by: | RFC 4519 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2377 |
|
Application of the conventional X.500 approach to naming has heretofore, in the experience of the authors, proven to be an obstacle to the wide deployment of directory-enabled applications on the Internet. We propose a new directory naming plan that leverages the strengths of the most popular and successful Internet naming schemes for naming objects in a hierarchical directory. This plan can, we believe, by extending the X.500 approach to naming, facilitate the creation of an Internet White Pages Service (IWPS) and other directory-enabled applications by overcoming the problems encountered by those using the conventional X.500 approach. |
|
| |
| RFC 2378 | The CCSO Nameserver (Ph) Architecture |
| |
| Authors: | R. Hedberg, P. Pomes. |
| Date: | September 1998 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2378 |
|
The Ph Nameserver from the Computing and Communications ServicesOffice (CCSO), University of Illinois at Urbana-Champaign has for some time now been used by several organizations as their choice of publicly available database for information about people as well as other things. This document provides a formal definition of the client-server protocol. The Ph service as specified in this document is built around an information model, a client command language and the server responses. |
|
| |
| RFC 2382 | A Framework for Integrated Services and RSVP over ATM |
| |
| Authors: | E. Crawley, Ed., L. Berger, S. Berson, F. Baker, M. Borden, J. Krawczyk. |
| Date: | August 1998 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2382 |
|
This document outlines the issues and framework related to providingIP Integrated Services with RSVP over ATM. It provides an overall approach to the problem(s) and related issues. These issues and problems are to be addressed in further documents from the ISATM subgroup of the ISSLL working group. |
|
| |
| RFC 2383 | ST2+ over ATM Protocol Specification - UNI 3.1 Version |
| |
| Authors: | M. Suzuki. |
| Date: | August 1998 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2383 |
|
This document specifies an ATM-based protocol for communication between ST2+ agents. The ST2+ over ATM protocol supports the matching of one hop in an ST2+ tree-structure stream with one ATM connection.In this document, ATM is a subnet technology for the ST2+ stream.
The ST2+ over ATM protocol is designed to achieve resource- reservation communications across ATM and non-ATM networks, to extend the UNI 3.1/4.0 signaling functions, and to reduce the UNI 4.0 LIJ signaling limitations.
The specifications of the ST2+ over ATM protocol consist of a revision of RFC 1819 ST2+ and specifications of protocol interaction between ST2+ and ATM on the user plane, management plane, and control plane which correspond to the three planes of the B-ISDN protocol reference model. |
|
| |
| RFC 2386 | A Framework for QoS-based Routing in the Internet |
| |
| Authors: | E. Crawley, R. Nair, B. Rajagopalan, H. Sandick. |
| Date: | August 1998 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2386 |
|
This document describes some of the QoS-based routing issues and requirements, and proposes a framework for QoS-based routing in the Internet. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. |
|
| |
| RFC 2391 | Load Sharing using IP Network Address Translation (LSNAT) |
| |
| Authors: | P. Srisuresh, D. Gan. |
| Date: | August 1998 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2391 |
|
Network Address Translators (NATs) translate IP addresses in a datagram, transparent to end nodes, while routing the datagram. NATs have traditionally been been used to allow private network domains to connect to Global networks using as few as one globally unique IP address. In this document, we extend the use of NATs to offer Load share feature, where session load can be distributed across a pool of servers, instead of directing to a single server. Load sharing is beneficial to service providers and system administrators alike in grappling with scalability of servers with increasing session load. |
|
| |
| RFC 2394 | IP Payload Compression Using DEFLATE |
| |
| Authors: | R. Pereira. |
| Date: | December 1998 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2394 |
|
This document describes a compression method based on the DEFLATE compression algorithm. This document defines the application of theDEFLATE algorithm to the IP Payload Compression Protocol. |
|
| |
| RFC 2395 | IP Payload Compression Using LZS |
| |
| Authors: | R. Friend, R. Monsour. |
| Date: | December 1998 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2395 |
|
This document describes a compression method based on the LZS compression algorithm. This document defines the application of theLZS algorithm to the IP Payload Compression Protocol [IPCOMP].[IPCOMP] defines a method for applying lossless compression to the payloads of Internet Protocol datagrams. |
|
| |
| RFC 2398 | Some Testing Tools for TCP Implementors |
| |
|
|
This document lists only tools which can evaluate one or more TCP implementations, or which can privde some specific results which describe or evaluate the TCP being tested. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. |
|
| |
| RFC 2399 | Request for Comments Summary |
| |
| Authors: | A. Ramos. |
| Date: | January 1999 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2399 |
|
|
|
| |
| RFC 2411 | IP Security Document Roadmap |
| |
| Authors: | R. Thayer, N. Doraswamy, R. Glenn. |
| Date: | November 1998 |
| Formats: | txt json html |
| Obsoleted by: | RFC 6071 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2411 |
|
The IPsec protocol suite is used to provide privacy and authentication services at the IP layer. Several documents are used to describe this protocol suite. The interrelationship and organization of the various documents covering the IPsec protocol are discussed here. An explanation of what to find in which document, and what to include in new Encryption Algorithm and AuthenticationAlgorithm documents are described. |
|
| |
| RFC 2412 | The OAKLEY Key Determination Protocol |
| |
| Authors: | H. Orman. |
| Date: | November 1998 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2412 |
|
This document describes a protocol, named OAKLEY, by which two authenticated parties can agree on secure and secret keying material.The basic mechanism is the Diffie-Hellman key exchange algorithm.
The OAKLEY protocol supports Perfect Forward Secrecy, compatibility with the ISAKMP protocol for managing security associations, user- defined abstract group structures for use with the Diffie-Hellman algorithm, key updates, and incorporation of keys distributed via out-of-band mechanisms. |
|
| |
| RFC 2413 | Dublin Core Metadata for Resource Discovery |
| |
| Authors: | S. Weibel, J. Kunze, C. Lagoze, M. Wolf. |
| Date: | September 1998 |
| Formats: | txt html json |
| Obsoleted by: | RFC 5013 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2413 |
|
This is the first of a set of Informational RFCs describing the Dublin Core. Its purpose is to introduce the Dublin Core and to describe the consensus reached on the semantics of each of the 15 elements. This memo provides information for the Internet community. |
|
| |
| RFC 2415 | Simulation Studies of Increased Initial TCP Window Size |
| |
| Authors: | K. Poduri, K. Nichols. |
| Date: | September 1998 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2415 |
|
An increase in the permissible initial window size of a TCP connection, from one segment to three or four segments, has been under discussion in the tcp-impl working group. This document covers some simulation studies of the effects of increasing the initial window size of TCP. Both long-lived TCP connections (file transfers) and short-lived web-browsing style connections were modeled. The simulations were performed using the publicly available ns-2 simulator and our custom models and files are also available. |
|
| |
| RFC 2416 | When TCP Starts Up With Four Packets Into Only Three Buffers |
| |
| Authors: | T. Shepard, C. Partridge. |
| Date: | September 1998 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2416 |
|
This memo is to document a simple experiment. The experiment showed that in the case of a TCP receiver behind a 9600 bps modem link at the edge of a fast Internet where there are only 3 buffers before the modem (and the fourth packet of a four-packet start will surely be dropped), no significant degradation in performance is experienced by a TCP sending with a four-packet start when compared with a normal slow start (which starts with just one packet). |
|
| |
| RFC 2430 | A Provider Architecture for Differentiated Services and Traffic Engineering (PASTE) |
| |
| Authors: | T. Li, Y. Rekhter. |
| Date: | October 1998 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2430 |
|
This document describes the Provider Architecture for Differentiated Services and Traffic Engineering (PASTE) for Internet Service Providers (ISPs). This memo provides information for the Internet community. |
|
| |
| RFC 2432 | Terminology for IP Multicast Benchmarking |
| |
| Authors: | K. Dubray. |
| Date: | October 1998 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2432 |
|
The purpose of this document is to define terminology specific to the benchmarking of multicast IP forwarding devices. It builds upon the tenets set forth in RFC 1242, RFC 2285, and other IETF BenchmarkingMethodology Working Group (BMWG) efforts. This document seeks to extend these efforts to the multicast paradigm.
The BMWG produces two major classes of documents: BenchmarkingTerminology documents and Benchmarking Methodology documents. TheTerminology documents present the benchmarks and other related terms.The Methodology documents define the procedures required to collect the benchmarks cited in the corresponding Terminology documents. |
|
| |
| RFC 2433 | Microsoft PPP CHAP Extensions |
| |
| Authors: | G. Zorn, S. Cobb. |
| Date: | October 1998 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2433 |
|
The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol and a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. This memo provides information for the Internet community. |
|
| |
| RFC 2436 | Collaboration between ISOC/IETF and ITU-T |
| |
| Authors: | R. Brett, S. Bradner, G. Parsons. |
| Date: | October 1998 |
| Formats: | txt html json |
| Obsoleted by: | RFC 3356 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2436 |
|
This document describes the collaboration process between the ITU-T and ISOC/IETF. This memo provides information for the Internet community. |
|
| |
| RFC 2437 | PKCS #1: RSA Cryptography Specifications Version 2.0 |
| |
|
|
This memo is the successor to RFC 2313. This document provides recommendations for the implementation of public-key cryptography based on the RSA algorithm. This memo provides information for the Internet community. |
|
| |
| RFC 2441 | Working with Jon, Tribute delivered at UCLA, October 30, 1998 |
| |
| Authors: | D. Cohen. |
| Date: | November 1998 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2441 |
|
This memo provides information for the Internet community. |
|
| |
| RFC 2442 | The Batch SMTP Media Type |
| |
| Authors: | N. Freed, D. Newman, J. Belissent, M. Hoy. |
| Date: | November 1998 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2442 |
|
This document defines a MIME content type suitable for tunneling anESMTP [RFC-821, RFC-1869] transaction through any MIME-capable transport. This type can be used for a variety of purposes, including: Extending end-to-end MIME-based security services (e.g.,[RFC-1847]) to cover message envelope information as well as message content. Making it possible to use specific SMTP extensions such asNOTARY [RFC-1891] over unextended SMTP transport infrastructure.Enabling the transfer of multiple separate messages in a single transactional unit. |
|
| |
| RFC 2448 | AT&T's Error Resilient Video Transmission Technique |
| |
| Authors: | M. Civanlar, G. Cash, B. Haskell. |
| Date: | November 1998 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2448 |
|
This document describes a set of techniques for packet loss resilient transmission of compressed video bitstreams based on reliable delivery of their vital information-carrying segments. The described techniques can be used over packet networks without packet prioritization. These techniques are related to AT&T/Lucent patents[1, 2]. |
|
| |
| RFC 2450 | Proposed TLA and NLA Assignment Rule |
| |
| Authors: | R. Hinden. |
| Date: | December 1998 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2450 |
|
This document proposes rules for Top-Level Aggregation Identifiers (TLA ID) and Next-Level Aggregation Identifiers (NLA ID). This memo provides information for the Internet community. |
|
| |
| RFC 2458 | Toward the PSTN/Internet Inter-Networking--Pre-PINT Implementations |
| |
| Authors: | H. Lu, M. Krishnaswamy, L. Conroy, S. Bellovin, F. Burg, A. DeSimone, K. Tewani, P. Davidson, H. Schulzrinne, K. Vishwanathan. |
| Date: | November 1998 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2458 |
|
This document contains the information relevant to the development of the inter-networking interfaces underway in the Public SwitchedTelephone Network (PSTN)/Internet Inter-Networking (PINT) WorkingGroup. It addresses technologies, architectures, and several (but by no means all) existing pre-PINT implementations of the arrangements through which Internet applications can request and enrich PSTN telecommunications services. The common denominator of the enriched services (a.k.a. PINT services) is that they combine the Internet andPSTN services in such a way that the Internet is used for non-voice interactions, while the voice (and fax) are carried entirely over thePSTN. One key observation is that the pre-PINT implementations, being developed independently, do not inter-operate. It is a task of thePINT Working Group to define the inter-networking interfaces that will support inter-operation of the future implementations of PINT services. |
|
| |
| RFC 2468 | I REMEMBER IANA |
| |
| Authors: | V. Cerf. |
| Date: | October 1998 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2468 |
|
A long time ago, in a network, far far away, a great adventure took place!. This memo provides information for the Internet community. |
|
| |
| RFC 2469 | A Caution On The Canonical Ordering Of Link-Layer Addresses |
| |
| Authors: | T. Narten, C. Burton. |
| Date: | December 1998 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2469 |
|
Protocols such as ARP and Neighbor Discovery have data fields that contain link-layer addresses. In order to interoperate properly, a sender setting such a field must insure that the receiver extracts those bits and interprets them correctly. In most cases, such fields must be in "canonical form". Unfortunately, not all LAN adaptors are consistent in their use of canonical form, and implementations may need to explicitly bit swap individual bytes in order to obtain the correct format. This document provides information to implementors to help them avoid the pitfall of using non-canonical forms when canonical forms are required. |
|
| |
| RFC 2475 | An Architecture for Differentiated Services |
| |
| Authors: | S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss. |
| Date: | December 1998 |
| Formats: | txt html json |
| Updated by: | RFC 3260 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2475 |
|
This document defines an architecture for implementing scalable service differentiation in the Internet. This architecture achieves scalability by aggregating traffic classification state which is conveyed by means of IP-layer packet marking using the DS field[DSFIELD]. Packets are classified and marked to receive a particular per-hop forwarding behavior on nodes along their path. Sophisticated classification, marking, policing, and shaping operations need only be implemented at network boundaries or hosts. Network resources are allocated to traffic streams by service provisioning policies which govern how traffic is marked and conditioned upon entry to a differentiated services-capable network, and how that traffic is forwarded within that network. A wide variety of services can be implemented on top of these building blocks. |
|
| |
| RFC 2477 | Criteria for Evaluating Roaming Protocols |
| |
| Authors: | B. Aboba, G. Zorn. |
| Date: | January 1999 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2477 |
|
This document describes requirements for the provisioning of "roaming capability" for dialup Internet users. "Roaming capability" is defined as the ability to use multiple Internet service providers (ISPs), while maintaining a formal, customer-vendor relationship with only one. This memo provides information for the Internet community. |
|
| |
| RFC 2479 | Independent Data Unit Protection Generic Security Service Application Program Interface (IDUP-GSS-API) |
| |
| Authors: | C. Adams. |
| Date: | December 1998 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2479 |
|
The IDUP-GSS-API extends the GSS-API for applications requiring protection of a generic data unit (such as a file or message) in a way which is independent of the protection of any other data unit and independent of any concurrent contact with designated "receivers" of the data unit. This memo provides information for the Internet community. |
|
| |
| RFC 2490 | A Simulation Model for IP Multicast with RSVP |
| |
| Authors: | M. Pullen, R. Malghan, L. Lavu, G. Duan, J. Ma, H. Nah. |
| Date: | January 1999 |
| Formats: | txt pdf html json ps |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2490 |
|
This document describes a detailed model of IPv4 multicast with RSVP that has been developed using the OPNET simulation package [4], with protocol procedures defined in the C language. The model was developed to allow investigation of performance constraints on routing but should have wide applicability in the Internet multicast/resource reservation community. We are making this model publicly available with the intention that it can be used to provide expanded studies of resource-reserved multicasting. |
|
| |
| RFC 2499 | Request for Comments Summary |
| |
| Authors: | A. Ramos. |
| Date: | July 1999 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2499 |
|
|
|
| |
| RFC 2501 | Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations |
| |
| Authors: | S. Corson, J. Macker. |
| Date: | January 1999 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2501 |
|
This memo first describes the characteristics of Mobile Ad hocNetworks (MANETs), and their idiosyncrasies with respect to traditional, hardwired packet networks. It then discusses the effect these differences have on the design and evaluation of network control protocols with an emphasis on routing performance evaluation considerations. |
|
| |
| RFC 2502 | Limitations of Internet Protocol Suite for Distributed Simulation the Large Multicast Environment |
| |
| Authors: | M. Pullen, M. Myjak, C. Bouwens. |
| Date: | February 1999 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2502 |
|
The Large-Scale Multicast Applications (LSMA) working group was chartered to produce documents aimed at a consensus based development of the Internet protocols to support large scale multicast applications including real-time distributed simulation. This memo defines services that LSMA has found to be required, and aspects of the Internet protocols that LSMA has found to need further development in order to meet these requirements. |
|
| |
| RFC 2503 | MIME Types for Use with the ISO ILL Protocol |
| |
| Authors: | R. Moulton, M. Needleman. |
| Date: | February 1999 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2503 |
|
This memorandum describes a set of MIME types for use with the ISOInterlibrary Loan Protocol (ISO 10160/10161). Two MIME types are specified below.
The first is a media type to carry objects which are BER [BER] encoded ISO ILL Protocol Data Units (PDU's). BER are the basicEncoding Rules used to encode PDU's which have been described usingASN.1 (Abstract Syntax Notation 1) [ASN.1] .
The second is for use with the associated document delivery instructions. Document Delivery Instructions (DDI) is an emerging protocol which enables automatic electronic delivery of items. It allows a request management system (which might have received a request for an item via the ISO Interlibrary Loan Protocol (ISO10160/10161)) to pass details of the request, item, and delivery, to a delivery module, and to receive back reports on the delivery process or arrival of an item. It is currently being submitted to theISO TC46/SC4/WG4 committee for approval as an ISO standard. |
|
| |
| RFC 2504 | Users' Security Handbook |
| |
| Authors: | E. Guttman, L. Leong, G. Malkin. |
| Date: | February 1999 |
| Formats: | txt html json |
| Also: | FYI 0034 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2504 |
|
The Users' Security Handbook is the companion to the Site SecurityHandbook (SSH). It is intended to provide users with the information they need to help keep their networks and systems secure. |
|
| |
| RFC 2516 | A Method for Transmitting PPP Over Ethernet (PPPoE) |
| |
| Authors: | L. Mamakos, K. Lidl, J. Evarts, D. Carrel, D. Simone, R. Wheeler. |
| Date: | February 1999 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2516 |
|
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.
This document describes how to build PPP sessions and encapsulate PPP packets over Ethernet. |
|
| |
| RFC 2517 | Building Directories from DNS: Experiences from WWWSeeker |
| |
| Authors: | R. Moats, R. Huber. |
| Date: | February 1999 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2517 |
|
There has been much discussion and several documents written about the need for an Internet Directory. Recently, this discussion has focused on ways to discover an organization's domain name without relying on use of DNS as a directory service. This memo discusses lessons that were learned during InterNIC Directory and DatabaseServices' development and operation of WWWSeeker, an application that finds a web site given information about the name and location of an organization. The back end database that drives this application was built from information obtained from domain registries via WHOIS and other protocols. We present this information to help future implementors avoid some of the blind alleys that we have already explored. This work builds on the Netfind system that was created byMike Schwartz and his team at the University of Colorado at Boulder[1]. |
|
| |
| RFC 2519 | A Framework for Inter-Domain Route Aggregation |
| |
| Authors: | E. Chen, J. Stewart. |
| Date: | February 1999 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2519 |
|
This document presents a framework for inter-domain route aggregation and shows an example router configuration which 'implements' this framework. This framework is flexible and scales well as it emphasizes the philosophy of aggregation by the source, both within routing domains as well as towards upstream providers, and it also strongly encourages the use of the 'no-export' BGP community to balance the provider-subscriber need for more granular routing information with the Internet's need for scalable inter-domain routing. |
|
| |
| RFC 2524 | Neda's Efficient Mail Submission and Delivery (EMSD) Protocol Specification Version 1.3 |
| |
| Authors: | M. Banan. |
| Date: | February 1999 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2524 |
|
This specification narrowly focuses on submission and delivery of short mail messages with a clear emphasis on efficiency. This memo provides information for the Internet community. |
|
| |
| RFC 2525 | Known TCP Implementation Problems |
| |
| Authors: | V. Paxson, M. Allman, S. Dawson, W. Fenner, J. Griner, I. Heavens, K. Lahey, J. Semke, B. Volz. |
| Date: | March 1999 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2525 |
|
This memo catalogs a number of known TCP implementation problems. This memo provides information for the Internet community. |
|
| |
| RFC 2527 | Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework |
| |
|
|
This document presents a framework to assist the writers of certificate policies or certification practice statements for certification authorities and public key infrastructures. In particular, the framework provides a comprehensive list of topics that potentially (at the writer's discretion) need to be covered in a certificate policy definition or a certification practice statement. |
|
| |
| RFC 2528 | Internet X.509 Public Key Infrastructure Representation of Key Exchange Algorithm (KEA) Keys in Internet X.509 Public Key Infrastructure Certificates |
| |
| Authors: | R. Housley, W. Polk. |
| Date: | March 1999 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2528 |
|
The Key Exchange Algorithm (KEA) is a classified algorithm for exchanging keys. This specification profiles the format and semantics of fields in X.509 V3 certificates containing KEA keys. The specification addresses the subjectPublicKeyInfo field and the keyUsage extension. |
|
| |
| RFC 2541 | DNS Security Operational Considerations |
| |
|
|
Secure DNS is based on cryptographic techniques. A necessary part of the strength of these techniques is careful attention to the operational aspects of key and signature generation, lifetime, size, and storage. In addition, special attention must be paid to the security of the high level zones, particularly the root zone. This document discusses these operational aspects for keys and signatures used in connection with the KEY and SIG DNS resource records. |
|
| |
| RFC 2542 | Terminology and Goals for Internet Fax |
| |
| Authors: | L. Masinter. |
| Date: | March 1999 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2542 |
|
This document defines a number of terms useful for the discussion ofInternet Fax. In addition, it describes the goals of the Internet Fax working group and establishes a baseline of desired functionality against which protocols for Internet Fax can be judged. It encompasses the goals for all modes of facsimile delivery, including'real-time', 'session', and 'store and forward'. Different levels of desirability are indicated throughout the document. |
|
| |
| RFC 2544 | Benchmarking Methodology for Network Interconnect Devices |
| |
|
|
This document discusses and defines a number of tests that may be used to describe the performance characteristics of a network interconnecting device. In addition to defining the tests this document also describes specific formats for reporting the results of the tests. Appendix A lists the tests and conditions that we believe should be included for specific cases and gives additional information about testing practices. Appendix B is a reference listing of maximum frame rates to be used with specific frame sizes on various media and Appendix C gives some examples of frame formats to be used in testing. |
|
| |
| RFC 2546 | 6Bone Routing Practice |
| |
|
|
This memo identifies guidelines on how 6Bone sites might operate, so that the 6Bone can remain a quality experimentation environment and to avoid pathological situations that have been encountered in the past. It defines the 'best current practice' acceptable in the 6Bone for the configuration of both Interior Gateway Protocols and Exterior Gateway Protocols. This memo provides information for the Internet community. |
|
| |
| RFC 2547 | BGP/MPLS VPNs |
| |
|
|
This document describes a method by which a Service Provider with anIP backbone may provide VPNs (Virtual Private Networks) for its customers. MPLS (Multiprotocol Label Switching) is used for forwarding packets over the backbone, and BGP (Border GatewayProtocol) is used for distributing routes over the backbone. The primary goal of this method is to support the outsourcing of IP backbone services for enterprise networks. It does so in a manner which is simple for the enterprise, while still scalable and flexible for the Service Provider, and while allowing the Service Provider to add value. These techniques can also be used to provide a VPN which itself provides IP service to customers. |
|
| |
| RFC 2548 | Microsoft Vendor-specific RADIUS Attributes |
| |
| Authors: | G. Zorn. |
| Date: | March 1999 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2548 |
|
This document describes the set of Microsoft vendor-specific RADIUS attributes. These attributes are designed to support Microsoft proprietary dial-up protocols and/or provide support for features which is not provided by the standard RADIUS attribute set [3]. It is expected that this memo will be updated whenever Microsoft defines a new vendor-specific attribute, since its primary purpose is to provide an open, easily accessible reference for third-parties wishing to interoperate with Microsoft products. |
|
| |
| RFC 2549 | IP over Avian Carriers with Quality of Service |
| |
|
|
This memo amends RFC 1149, "A Standard for the Transmission of IPDatagrams on Avian Carriers", with Quality of Service information.This is an experimental, not recommended standard. |
|
| |
| RFC 2550 | Y10K and Beyond |
| |
| Authors: | S. Glassman, M. Manasse, J. Mogul. |
| Date: | 1 April 1999 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2550 |
|
As we approach the end of the millennium, much attention has been paid to the so-called "Y2K" problem. Nearly everyone now regrets the short-sightedness of the programmers of yore who wrote programs designed to fail in the year 2000. Unfortunately, the current fixes for Y2K lead inevitably to a crisis in the year 10,000 when the programs are again designed to fail.
This specification provides a solution to the "Y10K" problem which has also been called the "YAK" problem (hex) and the "YXK" problem(Roman numerals). |
|
| |
| RFC 2551 | The Roman Standards Process -- Revision III |
| |
| Authors: | S. Bradner. |
| Date: | 1 April 1999 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2551 |
|
This memo documents the process used by the Roman community for the standardization of protocols and procedures. It defines the stages in the standardization process, the requirements for moving a document between stages and the types of documents used during this process. It also addresses the intellectual property rights and copyright issues associated with the standards process. |
|
| |
| RFC 2552 | Architecture for the Information Brokerage in the ACTS Project GAIA |
| |
| Authors: | M. Blinov, M. Bessonov, C. Clissmann. |
| Date: | April 1999 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2552 |
|
This memo introduces a domain and supplier independent generic architecture for information brokerage, designed as part of the ACTS project GAIA (Generic Architecture for Information Availability). |
|
| |
| RFC 2553 | Basic Socket Interface Extensions for IPv6 |
| |
|
|
The de facto standard application program interface (API) for TCP/IP applications is the "sockets" interface. Although this API was developed for Unix in the early 1980s it has also been implemented on a wide variety of non-Unix systems. TCP/IP applications written using the sockets API have in the past enjoyed a high degree of portability and we would like the same portability with IPv6 applications. But changes are required to the sockets API to supportIPv6 and this memo describes these changes. These include a new socket address structure to carry IPv6 addresses, new address conversion functions, and some new socket options. These extensions are designed to provide access to the basic IPv6 features required byTCP and UDP applications, including multicasting, while introducing a minimum of change into the system and providing complete compatibility for existing IPv4 applications. Additional extensions for advanced IPv6 features (raw sockets and access to the IPv6 extension headers) are defined in another document [4]. |
|
| |
| RFC 2555 | 30 Years of RFCs |
| |
|
|
The rest of this document contains a brief recollection from the present RFC Editor Joyce K. Reynolds, followed by recollections from three pioneers: Steve Crocker who wrote RFC 1, Vint Cerf whose long-range vision continues to guide us, and Jake Feinler who played a key role in the middle years of the RFC series. This memo provides information for the Internet community. |
|
| |
| RFC 2556 | OSI connectionless transport services on top of UDP Applicability Statement for Historic Status |
| |
| Authors: | S. Bradner. |
| Date: | March 1999 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2556 |
|
RFC 1240, "OSI connectionless transport services on top of UDP", was published as a Proposed Standard in June 1991 but at this time there do not seem to be any implementations which follow RFC 1240. In addition there is a growing concern over using UDP-based transport protocols in environments where congestion is a possibility. |
|
| |
| RFC 2570 | Introduction to Version 3 of the Internet-standard Network Management Framework |
| |
| Authors: | J. Case, R. Mundy, D. Partain, B. Stewart. |
| Date: | April 1999 |
| Formats: | txt json html |
| Obsoleted by: | RFC 3410 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2570 |
|
The purpose of this document is to provide an overview of the third version of the Internet-standard Management Framework, termed theSNMP version 3 Framework (SNMPv3). This Framework is derived from and builds upon both the original Internet-standard ManagementFramework (SNMPv1) and the second Internet-standard ManagementFramework (SNMPv2).
The architecture is designed to be modular to allow the evolution of the Framework over time. |
|
| |
| RFC 2577 | FTP Security Considerations |
| |
| Authors: | M. Allman, S. Ostermann. |
| Date: | May 1999 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2577 |
|
The specification for the File Transfer Protocol (FTP) contains a number of mechanisms that can be used to compromise network security.The FTP specification allows a client to instruct a server to transfer files to a third machine. This third-party mechanism, known as proxy FTP, causes a well known security problem. The FTP specification also allows an unlimited number of attempts at entering a user's password. This allows brute force "password guessing" attacks. This document provides suggestions for system administrators and those implementing FTP servers that will decrease the security problems associated with FTP. |
|
| |
| RFC 2583 | Guidelines for Next Hop Client (NHC) Developers |
| |
| Authors: | R. Carlson, L. Winkler. |
| Date: | May 1999 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2583 |
|
This document provides guidelines for developers of the Next Hop Resolution Protocol Clients (NHC). The intent is to define the interaction between the NHC code and the TCP/IP protocol stack of the local host operating system. This memo provides information for the Internet community. |
|
| |
| RFC 2586 | The Audio/L16 MIME content type |
| |
| Authors: | J. Salsman, H. Alvestrand. |
| Date: | May 1999 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2586 |
|
This document defines the audio/L16 MIME type, a reasonable quality audio format for use in Internet applications. This memo provides information for the Internet community. |
|
| |
| RFC 2588 | IP Multicast and Firewalls |
| |
| Authors: | R. Finlayson. |
| Date: | May 1999 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2588 |
|
In this document, we discuss the issues surrounding the traversal of IP multicast traffic across a firewall, and describe possible ways in which a firewall can implement and control this traversal. We also explain why some firewall mechanisms - such as SOCKS - that were designed specifically for unicast traffic, are less appropriate for multicast. This memo provides information for the Internet community. |
|
| |
| RFC 2599 | Request for Comments Summary RFC Numbers 2500-2599 |
| |
| Authors: | A. DeLaCruz. |
| Date: | March 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2599 |
|
|
|
| |
| RFC 2604 | Wireless Device Configuration (OTASP/OTAPA) via ACAP |
| |
|
|
Wireless carriers today are faced with creating more efficient distribution channels, increasing customer satisfaction, while also improving margin and profitability. Industry trends are pushing the sale of handsets further into the retail channel. The cost and effort of provisioning handsets, activating users, and updating handset parameters can be greatly reduced by using over-the-air activation mechanisms. A comprehensive and extensible means for over-the-air provisioning and handset parameter updating is required.
One approach is to purchase EIA/TIA/IS-683A (Over-the-air ServiceProvisioning of Mobile Stations in Spread Spectrum Systems) equipment. The cost of this has led carriers to seek alternative solutions. A very viable means for providing over-the-air (OTA) provisioning is to leverage the rollout of IS-707 data services equipment, which most carriers are in the process of deploying. This paper presents an approach to OTA provisioning that utilizes the deployment of IS-707 to deliver OTA provisioning and parameter upgrading.
IS-707 data services makes available several methods of providing over-the-air provisioning and parameter updating. A well thought-out approach utilizing Internet-based open standard mechanisms can provide an extensible platform for further carrier service offerings, enhanced interoperability among back-end services, and vendor independence.
This paper describes a viable and attractive means to provideOTASP/OTAPA via IS-707, using the ACAP [ACAP] protocol. |
|
| |
| RFC 2607 | Proxy Chaining and Policy Implementation in Roaming |
| |
| Authors: | B. Aboba, J. Vollbrecht. |
| Date: | June 1999 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2607 |
|
This document describes how proxy chaining and policy implementation can be supported in roaming systems. This memo provides information for the Internet community. |
|
| |
| RFC 2612 | The CAST-256 Encryption Algorithm |
| |
| Authors: | C. Adams, J. Gilchrist. |
| Date: | June 1999 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2612 |
|
There is always a desire in the Internet community for unencumbered encryption algorithms with a range of key sizes that can provide security for a variety of cryptographic applications and protocols.
This document describes an existing algorithm that can be used to satisfy this requirement. Included are a description of the cipher and the key scheduling algorithm, the s-boxes, and a set of test vectors (Appendix A). |
|
| |
| RFC 2614 | An API for Service Location |
| |
| Authors: | J. Kempf, E. Guttman. |
| Date: | June 1999 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2614 |
|
The Service Location Protocol (SLP) provides a new way for clients to dynamically discovery network services. With SLP, it is simple to offer highly available services that require no user configuration or assistance from network administrators prior to use. This document describes standardized APIs for SLP in C and Java. The APIs are modular and are designed to allow implementations to offer just the feature set needed. In addition, standardized file formats for configuration and serialized registrations are defined, allowing SLP agents to set network and other parameters in a portable way. The serialized file format allows legacy services to be registered withSLP directory agents in cases where modifying the legacy service program code is difficult or impossible, and to portably exchange a registration database. |
|
| |
| RFC 2620 | RADIUS Accounting Client MIB |
| |
|
|
This memo defines a set of extensions which instrument RADIUS accounting client functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions IP-based management stations can manage RADIUS accounting clients. |
|
| |
| RFC 2621 | RADIUS Accounting Server MIB |
| |
|
|
This memo defines a set of extensions which instrument RADIUS accounting server functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions IP-based management stations can manage RADIUS accounting servers. |
|
| |
| RFC 2624 | NFS Version 4 Design Considerations |
| |
| Authors: | S. Shepler. |
| Date: | June 1999 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2624 |
|
The main task of the NFS version 4 working group is to create a protocol definition for a distributed file system that focuses on the following items: improved access and good performance on theInternet, strong security with negotiation built into the protocol, better cross-platform interoperability, and designed for protocol extensions. NFS version 4 will owe its general design to the previous versions of NFS. It is expected, however, that many features will be quite different in NFS version 4 than previous versions to facilitate the goals of the working group and to address areas that NFS version 2 and 3 have not.
This design considerations document is meant to present more detail than the working group charter. Specifically, it presents the areas that the working group will investigate and consider while developing a protocol specification for NFS version 4. Based on this investigation the working group will decide the features of the new protocol based on the cost and benefits within the specific feature areas. |
|
| |
| RFC 2626 | The Internet and the Millennium Problem (Year 2000) |
| |
| Authors: | P. Nesser II. |
| Date: | June 1999 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2626 |
|
The Year 2000 Working Group (WG) has conducted an investigation into the millennium problem as it regards Internet related protocols.This investigation only targeted the protocols as documented in theRequest For Comments Series (RFCs). This investigation discovered little reason for concern with regards to the functionality of the protocols. A few minor cases of older implementations still using two digit years (ala RFC 850) were discovered, but almost allInternet protocols were given a clean bill of health. Several cases of "period" problems were discovered, where a time field would "roll over" as the size of field was reached. In particular, there are several protocols, which have 32 bit, signed integer representations of the number of seconds since January 1, 1970 which will turn negative at Tue Jan 19 03:14:07 GMT 2038. Areas whose protocols will be effected by such problems have been notified so that new revisions will remove this limitation. |
|
| |
| RFC 2627 | Key Management for Multicast: Issues and Architectures |
| |
| Authors: | D. Wallner, E. Harder, R. Agee. |
| Date: | June 1999 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2627 |
|
This report contains a discussion of the difficult problem of key management for multicast communication sessions. It focuses on two main areas of concern with respect to key management, which are, initializing the multicast group with a common net key and rekeying the multicast group. A rekey may be necessary upon the compromise of a user or for other reasons (e.g., periodic rekey). In particular, this report identifies a technique which allows for secure compromise recovery, while also being robust against collusion of excluded users. This is one important feature of multicast key management which has not been addressed in detail by most other multicast key management proposals [1,2,4]. The benefits of this proposed technique are that it minimizes the number of transmissions required to rekey the multicast group and it imposes minimal storage requirements on the multicast group. |
|
| |
| RFC 2628 | Simple Cryptographic Program Interface (Crypto API) |
| |
| Authors: | V. Smyslov. |
| Date: | June 1999 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2628 |
|
This document describes a simple Application Program Interface to cryptographic functions. The main purpose of such an interface is to separate cryptographic libraries from internet applications, thus allowing an independent development of both. It can be used in various internet applications such as [IPsec], [ISAKMP], [IKE],[TLS]. |
|
| |
| RFC 2629 | Writing I-Ds and RFCs using XML |
| |
|
|
This memo presents a technique for using XML (Extensible MarkupLanguage) as a source format for documents in the Internet-Drafts(I-Ds) and Request for Comments (RFC) series. |
|
| |
| RFC 2635 | DON'T SPEW A Set of Guidelines for Mass Unsolicited Mailings and Postings (spam*) |
| |
|
|
This document explains why mass unsolicited electronic mail messages are harmful in the Internetworking community. It gives a set of guidelines for dealing with unsolicited mail for users, for system administrators, news administrators, and mailing list managers. It also makes suggestions Internet Service Providers might follow. |
|
| |
| RFC 2636 | Wireless Device Configuration (OTASP/OTAPA) via ACAP |
| |
|
|
Wireless carriers today are faced with creating more efficient distribution channels, increasing customer satisfaction, while also improving margin and profitability. Industry trends are pushing the sale of handsets further into the retail channel. The cost and effort of provisioning handsets, activating users, and updating handset parameters can be greatly reduced by using over-the-air activation mechanisms. A comprehensive and extensible means for over-the-air provisioning and handset parameter updating is required.
One approach is to purchase EIA/TIA/IS-683A (Over-the-air ServiceProvisioning of Mobile Stations in Spread Spectrum Systems) equipment. The cost of this has led carriers to seek alternative solutions. A very viable means for providing over-the-air (OTA) provisioning is to leverage the rollout of IS-707 data services equipment, which most carriers are in the process of deploying. This paper presents an approach to OTA provisioning that utilizes the deployment of IS-707 to deliver OTA provisioning and parameter upgrading.
IS-707 data services makes available several methods of providing over-the-air provisioning and parameter updating. A well thought-out approach utilizing Internet-based open standard mechanisms can provide an extensible platform for further carrier service offerings, enhanced interoperability among back-end services, and vendor independence.
This paper describes a viable and attractive means to provideOTASP/OTAPA via IS-707, using the ACAP [ACAP] protocol. |
|
| |
| RFC 2637 | Point-to-Point Tunneling Protocol (PPTP) |
| |
| Authors: | K. Hamzeh, G. Pall, W. Verthein, J. Taarud, W. Little, G. Zorn. |
| Date: | July 1999 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2637 |
|
This document specifies a protocol which allows the Point to PointProtocol (PPP) to be tunneled through an IP network. PPTP does not specify any changes to the PPP protocol but rather describes a new vehicle for carrying PPP. A client-server architecture is defined in order to decouple functions which exist in current Network AccessServers (NAS) and support Virtual Private Networks (VPNs). The PPTPNetwork Server (PNS) is envisioned to run on a general purpose operating system while the client, referred to as a PPTP AccessConcentrator (PAC) operates on a dial access platform. PPTP specifies a call-control and management protocol which allows the server to control access for dial-in circuit switched calls originating from a PSTN or ISDN or to initiate outbound circuit- switched connections. PPTP uses an enhanced GRE (Generic RoutingEncapsulation) mechanism to provide a flow- and congestion-controlled encapsulated datagram service for carrying PPP packets. |
|
| |
| RFC 2638 | A Two-bit Differentiated Services Architecture for the Internet |
| |
| Authors: | K. Nichols, V. Jacobson, L. Zhang. |
| Date: | July 1999 |
| Formats: | txt ps json html pdf |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2638 |
|
This document was originally submitted as an internet draft inNovember of 1997. As one of the documents predating the formation of the IETF's Differentiated Services Working Group, many of the ideas presented here, in concert with Dave Clark's subsequent presentation to the December 1997 meeting of the IETF Integrated Services WorkingGroup, were key to the work which led to RFCs 2474 and 2475 and the section on allocation remains a timely proposal. For this reason, and to provide a reference, it is being submitted in its original form.The forwarding path portion of this document is intended as a record of where we were at in late 1997 and not as an indication of future direction.
The postscript version of this document includes Clark's slides as an appendix. The postscript version of this document also includes many figures that aid greatly in its readability. |
|
| |
| RFC 2639 | Internet Printing Protocol/1.0: Implementer's Guide |
| |
|
|
This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing using Internet tools and technologies. This document contains information that supplements the IPP Model and Semantics [RFC2566] and the IPP Transport and Encoding [RFC2565] documents. It is intended to help implementers understand IPP/1.0 and some of the considerations that may assist them in the design of their client and/or IPP object implementations. For example, a typical order of processing requests is given, including error checking. Motivation for some of the specification decisions is also included.
The full set of IPP documents includes:
Design Goals for an Internet Printing Protocol [RFC2567]Rationale for the Structure and Model and Protocol for the InternetPrinting Protocol [RFC2568]Internet Printing Protocol/1.0: Model and Semantics [RFC2566]Internet Printing Protocol/1.0: Encoding and Transport [RFC2565]Mapping between LPD and IPP Protocols [RFC2569]
The document, "Design Goals for an Internet Printing Protocol", takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. The design goals document calls out a subset of end user requirements that are satisfied in IPP/1.0. Operator and administrator requirements are out of scope for version 1.0.
The document, "Rationale for the Structure and Model and Protocol for the Internet Printing Protocol", describes IPP from a high level view, defines a roadmap for the various documents that form the suite of IPP specifications, and gives background and rationale for theIETF working group's major decisions.
The document, "Internet Printing Protocol/1.0: Model and Semantics", describes a simplified model with abstract objects, their attributes, and their operations. The model introduces a Printer and a Job. TheJob supports multiple documents per Job. The model document also addresses how security, internationalization, and directory issues are addressed.
The document, "Internet Printing Protocol/1.0: Encoding andTransport", is a formal mapping of the abstract operations and attributes defined in the model document onto HTTP/1.1. It also defines the encoding rules for a new Internet media type called"application/ipp".
The document, "Mapping between LPD and IPP Protocols", gives some advice to implementers of gateways between IPP and LPD (Line PrinterDaemon) implementations. |
|
| |
| RFC 2641 | Cabletron's VlanHello Protocol Specification Version 4 |
| |
| Authors: | D. Hamilton, D. Ruffen. |
| Date: | August 1999 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2641 |
|
The VlanHello protocol is part of the InterSwitch Message Protocol(ISMP) which provides interswitch communication between switches running Cabletron's SecureFast VLAN (SFVLAN) product. Switches use the VlanHello protocol to discover their neighboring switches and establish the topology of the switch fabric. |
|
| |
| RFC 2642 | Cabletron's VLS Protocol Specification |
| |
| Authors: | L. Kane. |
| Date: | August 1999 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2642 |
|
The Virtual LAN Link State Protocol (VLSP) is part of the InterSwitchMessage Protocol (ISMP) which provides interswitch communication between switches running Cabletron's SecureFast VLAN (SFVLAN) product. VLSP is used to determine and maintain a fully connected mesh topology graph of the switch fabric. Each switch maintains an identical database describing the topology. Call-originating switches use the topology database to determine the path over which to route a call connection.
VLSP provides support for equal-cost multipath routing, and recalculates routes quickly in the face of topological changes, utilizing a minimum of routing protocol traffic. |
|
| |
| RFC 2643 | Cabletron's SecureFast VLAN Operational Model |
| |
| Authors: | D. Ruffen, T. Len, J. Yanacek. |
| Date: | August 1999 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2643 |
|
Cabletron's SecureFast VLAN (SFVLAN) product implements a distributed connection-oriented switching protocol that provides fast forwarding of data packets at the MAC layer. The product uses the concept of virtual LANs (VLANs) to determine the validity of call connection requests and to scope the broadcast of certain flooded messages. |
|
| |
| RFC 2647 | Benchmarking Terminology for Firewall Performance |
| |
| Authors: | D. Newman. |
| Date: | August 1999 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2647 |
|
This document defines terms used in measuring the performance of firewalls. It extends the terminology already used for benchmarking routers and switches with definitions specific to firewalls. [STANDARDS-TRACK] |
|
| |
| RFC 2648 | A URN Namespace for IETF Documents |
| |
|
|
A system for Uniform Resource Names (URNs) must be capable of supporting new naming systems. As an example of proposing a new namespace, this document proposes the "ietf" namespace. This namespace consists of the RFC family of documents (RFCs, STDs, FYIs, and BCPs) developed by the IETF and published by the RFC Editor, the minutes of working groups (WG) and birds of a feather (BOF) meetings that occur during IETF conferences, and the Internet Drafts published by the Internet Drafts Editor. Both the current URN framework andURN syntax support this namespace. |
|
| |
| RFC 2650 | Using RPSL in Practice |
| |
| Authors: | D. Meyer, J. Schmitz, C. Orange, M. Prior, C. Alaettinoglu. |
| Date: | August 1999 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2650 |
|
This document is a tutorial on using the Routing Policy SpecificationLanguage (RPSL) to describe routing policies in the Internet RoutingRegistry (IRR). We explain how to specify various routing policies and configurations using RPSL, how to register these policies in theIRR, and how to analyze them using the routing policy analysis tools, for example to generate vendor specific router configurations. |
|
| |
| RFC 2663 | IP Network Address Translator (NAT) Terminology and Considerations |
| |
| Authors: | P. Srisuresh, M. Holdrege. |
| Date: | August 1999 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2663 |
|
Network Address Translation is a method by which IP addresses are mapped from one realm to another, in an attempt to provide transparent routing to hosts. Traditionally, NAT devices are used to connect an isolated address realm with private unregistered addresses to an external realm with globally unique registered addresses. This document attempts to describe the operation of NAT devices and the associated considerations in general, and to define the terminology used to identify various flavors of NAT. |
|
| |
| RFC 2664 | FYI on Questions and Answers - Answers to Commonly Asked "New Internet User" Questions |
| |
|
|
This memo provides an overview to the new Internet User. The intended audience is the common Internet user of today, thus it attempts to provide a more consumer oriented approach to the Internet rather than going into any depth about a topic. Unlike its predecessors, this edition seeks to answer the general questions that an unsophisticated consumer would ask as opposed to the more pointed questions of a more technically sophisticated Internet user. Those desiring a more in-depth discussion are directed to FYI 7 that deals with intermediate and advanced Q/A topics. A conscious effort has been made to keep this memo brief but at the same time provide the new user with enough information to generally understand theInternet. |
|
| |
| RFC 2666 | Definitions of Object Identifiers for Identifying Ethernet Chip Sets |
| |
| Authors: | J. Flick. |
| Date: | August 1999 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2666 |
|
This memo defines OBJECT IDENTIFIER values for use with network management protocols in the Internet community. In particular, it contains registered OID values for use with the dot3StatsEtherChipSet object in the EtherLike-MIB [16]. These registrations have been split from [16] into a separate document for maintenance purposes. |
|
| |
| RFC 2682 | Performance Issues in VC-Merge Capable ATM LSRs |
| |
| Authors: | I. Widjaja, A. Elwalid. |
| Date: | September 1999 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2682 |
|
VC merging allows many routes to be mapped to the same VC label, thereby providing a scalable mapping method that can support thousands of edge routers. VC merging requires reassembly buffers so that cells belonging to different packets intended for the same destination do not interleave with each other. This document investigates the impact of VC merging on the additional buffer required for the reassembly buffers and other buffers. The main result indicates that VC merging incurs a minimal overhead compared to non-VC merging in terms of additional buffering. Moreover, the overhead decreases as utilization increases, or as the traffic becomes more bursty. |
|
| |
| RFC 2683 | IMAP4 Implementation Recommendations |
| |
|
|
The IMAP4 specification describes a rich protocol for use in building clients and servers for storage, retrieval, and manipulation of electronic mail. Because the protocol is so rich and has so many implementation choices, there are often trade-offs that must be made and issues that must be considered when designing such clients and servers. This document attempts to outline these issues and to make recommendations in order to make the end products as interoperable as possible. This memo provides information for the Internet community. |
|
| |
| RFC 2689 | Providing Integrated Services over Low-bitrate Links |
| |
| Authors: | C. Bormann. |
| Date: | September 1999 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2689 |
|
This document describes an architecture for providing integrated services over low-bitrate links, such as modem lines, ISDN B- channels, and sub-T1 links. It covers only the lower parts of theInternet Multimedia Conferencing Architecture [1]; additional components required for application services such as InternetTelephony (e.g., a session initiation protocol) are outside the scope of this document. The main components of the architecture are: a real-time encapsulation format for asynchronous and synchronous low- bitrate links, a header compression architecture optimized for real- time flows, elements of negotiation protocols used between routers(or between hosts and routers), and announcement protocols used by applications to allow this negotiation to take place. |
|
| |
| RFC 2690 | A Proposal for an MOU-Based ICANN Protocol Support Organization |
| |
| Authors: | S. Bradner. |
| Date: | September 1999 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2690 |
|
This is a copy of the proposal for an MOU-based Protocol Supporting Organization that was submitted to ICANN on April 23, 1999. This memo provides information for the Internet community. |
|
| |
| RFC 2691 | A Memorandum of Understanding for an ICANN Protocol Support Organization |
| |
| Authors: | S. Bradner. |
| Date: | September 1999 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2691 |
|
This is the text of the Memorandum of Understanding (MoU) that was signed by ICANN, the IETF, the ITU-T, W3C and ETSI on July 14, 1999 in Oslo. This MoU creates the Protocol Support Organization (PSO) within the Internet Corporation for Assigned Names and Numbers(ICANN). This MoU was developed by representatives of the IETF, ITU,W3C, ETSI, and ICANN with the help of Jorge Contreras of Hale andDorr.
MEMORANDUM OF UNDERSTANDING
July 14, 1999
ICANN Protocol Supporting Organization
(1) Purpose and Scope
(a) The Protocol Support Organization (PSO) will be a consensus- based advisory body within the ICANN framework.
(b) The PSO will establish a "Protocol Council" and host an annual open meeting (the "General Assembly").
(c) The purpose of this Memorandum of Understanding (MOU) is to establish a set of principles that ICANN and the StandardsDevelopment Organizations who have signed below (the SigningSDOs) will use in forming and operating the PSO
(2) Composition and Action of Protocol Council
(a) Size. Each Signing SDO will appoint two (2) members to theProtocol Council, each such member to serve for a time period determined by such Signing SDO.
(b) Each Signing SDO shall be responsible for choosing its members of the Protocol Council in a manner of its own choosing, and in accordance with its own open procedures.Each Signing SDO may remove or replace one or both of its members on the Protocol Council in its discretion. EachSigning SDO must notify the Protocol Council Secretary andICANN when it changes its members and, in addition, must ratify its choices at least annually.
(c) Selection and Appointment. Concurrently with the posting of notice of the date of the annual meeting of the PSO GeneralAssembly on the PSO Web Site, ICANN and the Protocol Council shall make an open call for nominations to any potential vacancies on the Protocol Council. Any nominations received will be forwarded to the Signing SDOs eligible to appoint members (i.e., they do not already have two members on theProtocol Council) for their consideration.
(d) Action by Protocol Council. Unless otherwise specified in this MOU, all actions of the Protocol Council shall be taken by majority vote of the total number of members. Action may be taken at any meeting of the Protocol Council, which may be by telephone conference in which all participants can hear the others. Meetings of the Protocol Council may be called by request of any three members of the Protocol Council, with at least 45 days for physical meetings or fifteen (15) days for telephonic or other electronic meetings prior written notice to each of the other members. In order to conduct business at any meeting of the Protocol Council, at least a quorum of members must be present; a quorum shall be present when at least majority of the members of the Protocol Council are present, and when such members represent at least 3/4ths of the Signing SDOs.
(e) Web Site. The Protocol Council will arrange for the establishment and maintenance of a Web site devoted to PSO activities and news.
(f) Secretary. The Protocol Council will have a Secretary to coordinate administrative matters relating to the PSO andProtocol Council. The Secretary's term of office shall be one year. The position of Secretary will rotate among the
Signing SDOs, with the initial Secretary to be selected by the IETF, and subsequent Secretaries to be appointed by a randomly selected Signing SDO that has not appointed theSecretary in the current rotation.
(g) No Compensation. Neither the Secretary, nor any ProtocolCouncil member or designated ICANN Board member shall be entitled to any compensation or reimbursement of expenses from the PSO. The PSO shall not be required to obtain insurance coverage for, or to indemnify, the members of theProtocol Council or persons acting in any other capacity by or for the PSO.
(3) ICANN Directors
(a) The Protocol Council will appoint Directors to the ICANNBoard of Directors in accordance with the By-laws of ICANN, for such terms as are specified by such By-laws. ICANN will notify the Protocol Council of any vacancies on the ICANNBoard which may be filled by the Protocol Council.
(b) The Protocol Council will conduct an open call for nominations for any open PSO seats on the ICANN Board. EachSigning SDO is entitled to nominate candidates by procedures of its own choosing. Additionally, nominations from the public at large will be allowed under conditions to be defined by the Protocol Council. The Protocol Council will select the PSO nominees to the ICANN Board from among these nominees. ICANN Directors selected by the Protocol Council may, but need not, be members of the Protocol Council or anySDO.
(c) No more than 2 PSO-nominated Directors may be residents of the same Geographic Region (as defined in the ICANN By-laws).
(d) The ICANN Directors appointed by the Protocol Council will not represent the PSO on the ICANN Board, but will function as full Directors of ICANN.
(4) Duties of Protocol Council
(a) Advisory Role. The Protocol Council will advise the ICANNBoard on matters referred to the Protocol Council by theICANN Board relating to the assignment of parameters forInternet protocols.
(b) Policy Development
(i) In the tradition of the Internet, standards development policies and conflict resolution mechanisms should be created and utilized by those institutions most directly involved, without undue interference from centralized bodies.
(ii) The ICANN By-laws vest in the PSO the primary responsibility for developing and recommending substantive policies in the area of protocol parameter assignment.
(iii) The PSO is committed to the proposition that policies for parameter assignments for particular protocols are the responsibility of the individual Signing SDO that developed the protocol.
(iv) The Protocol Council, and, when requested, ICANN, will be available as needed by the Signing SDOs to develop policies and procedures for conflict resolution betweenSigning SDOs.
(v) Any such policies and procedures will be adopted only with the agreement of all SDOs.
(5) Annual Open Meeting
(a) The Protocol Council will periodically convene an open meeting ("General Assembly") for promoting discussion and receiving input regarding the work of the PSO.(b) A General Assembly will be held at least once per year, and will permit open participation by all interested individuals.(c) Each annual General Assembly will be hosted by a Signing SDO in conjunction with one of its major meetings, as determined by the Protocol Council (with an effort to hold no 2 consecutive General Assemblies in the same GeographicRegion.)(d) It is expected that the major organizations within theInternet protocol standards development community will provide the constituency of the General Assembly.
(6) Open Proceedings and Documents
(a) Communications between ICANN and the Protocol Council. All official communications between ICANN and the ProtocolCouncil will be made public on the PSO web site. In the event that ICANN requests that a communication be kept confidential, the Protocol Council will honor this request for a fixed period of time not to exceed one year, and then make the communication public.
(b) Protocol Council Proceedings. All meetings of the ProtocolCouncil and official discussions of Protocol Council business will be conducted or reported on a publicly-archived mailing list accessible through the PSO web site.
(c) Meeting Announcements. The schedule and agenda for the PSOGeneral Assembly will be posted on the PSO Web Site at least90 days in advance of the meeting date. Notice of ProtocolCouncil meetings will be posted on the PSO Web at least 45 days before each physical meeting or fifteen (15) days before any telephonic or other electronic meeting, or such shorter time period agreed upon by each of the Signing SDOs. The minutes from all PSO meetings will be publicly posted on thePSO web site within 30 days of the meeting.
(7) Review and Modification of MOU. ICANN and the Signing SDOs will periodically review the results and consequences of their cooperation under this MOU. When appropriate, the signatories will consider the need for improvements in the MOU and make suitable proposals for modifying and updating the arrangements and scope of the MOU. Any modification to the MOU must be approved by all signatories.
(8) Standards Development Organizations
(a) The initial signatories to this MOU shall include ICANN and the Signing SDOs who have signed below. Each Signing SDO must be an international, Internet-related standards development organization that establishes that it meets the criteria for SDOs set forth below.
(i) SDOs must be open, international, voluntary technical standard and technical specification development organizations which:
(A) Develop standards and/or specifications for use over the public Internet.
(B) Can demonstrate active membership in the IP-related standards and/or specification development process of more than 800 individuals, if individual memberships are used by the organization, or 80 companies, if corporate memberships are used by the organization.
(C) Has been in operation for 3 or more years at the time of their application.
(D) Can demonstrate that there is significant deployment of its standards on the Internet.
(E) The significant protocols controlled by the organization can be implemented without paying a licensing fee to the organization.
(ii) Open, international, voluntary standards organizations are defined as international organizations that plan, develop or establish voluntary standards. An organization shall be considered open and international if its standards and/or specifications development process is open to any person or organization of any nationality on equitable terms. An organization shall be considered voluntary if it makes no claim to compel use of its standards and specifications. Additionally, to be considered 'international', an organization's voting (or other "full") membership must include individuals or companies primarily located in at least three different Geographic Regions and at least two different countries within each of those GeographicRegions.
(b) New Signatories
(i) Any organization that believes it satisfies the SDO qualifications set forth above may apply in writing to the Protocol Council to become a party to this MOU.In order for an organization to become a party to thisMOU, all then-existing MOU signatories must agree that such organization qualifies as an SDO.
(ii) Rejected applicants can appeal to the ICANN Board, which may override such a rejection if the ICANN Board finds, by at least a two-thirds vote, that the organization meets the SDO criteria set forth above.
(iii) Any organization that is accepted as an SDO under thisMOU must execute a copy of this MOU, and agree to be bound by all of its terms and conditions, upon which it shall be considered a Signing SDO for all purposes under this MOU.
(9) General. This MOU does not constitute any of the parties as a partner, joint venture, agent, principal or franchisee of any other party. The waiver of any provision of this MOU on any occasion shall not constitute a waiver for purposes of any other occasion. No party may transfer or assign any interest, right or obligation arising under this MOU without the prior written consent of each other party to this MOU.
IN WITNESS WHEREOF, this Memorandum of Understanding is executed this 14 day of July 1999 by the undersigned, acting through their duly authorized representatives:
INTERNET CORPORATION FOR ASSIGNED NAMES AND NUMBERSBy: (signature)Name: Michael W. RobertsTitle: Interim President / CEO
INTERNET ENGINEERING TASK FORCEBy: (signature)Name: Fredrick J. BakerTitle: Chair, IETF
INTERNATIONAL TELECOMMUNATIONS UNIONBy: (signature)Name: Houlin Zhao, on behalf of Secretary-General of ITUTitle: Director, TSB
WORLD WIDE WEB CONSORTIUMBy: (signature)Name: Henrik Frystyk NielsenTitle: HTTP Activity Lead
EUROPEAN TELECOMMUNICATIONS STANDARDS INSITITUTEBy: (signature)Name: Bridget CosgraveTitle: Deputy Director General |
|
| |
| RFC 2694 | DNS extensions to Network Address Translators (DNS_ALG) |
| |
| Authors: | P. Srisuresh, G. Tsirtsis, P. Akkiraju, A. Heffernan. |
| Date: | September 1999 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2694 |
|
Domain Name Service (DNS) provides name to address mapping within a routing class (ex: IP). Network Address Translators (NATs) attempt to provide transparent routing between hosts in disparate address realms of the same routing class. Typically, NATs exist at the border of a stub domain, hiding private addresses from external addresses. This document identifies the need for DNS extensions to NATs and outlines how a DNS Application Level Gateway (DNS_ALG) can meet the need.DNS_ALG modifies payload transparently to alter address mapping of hosts as DNS packets cross one address realm into another. The document also illustrates the operation of DNS_ALG with specific examples. |
|
| |
| RFC 2695 | Authentication Mechanisms for ONC RPC |
| |
| Authors: | A. Chiu. |
| Date: | September 1999 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2695 |
|
This document describes two authentication mechanisms created by Sun Microsystems that are commonly used in conjunction with the ONC Remote Procedure Call (ONC RPC Version 2) protocol. This memo provides information for the Internet community. |
|
| |
| RFC 2696 | LDAP Control Extension for Simple Paged Results Manipulation |
| |
| Authors: | C. Weider, A. Herron, A. Anantha, T. Howes. |
| Date: | September 1999 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2696 |
|
This document describes an LDAPv3 control extension for simple paging of search results. This memo provides information for the Internet community. |
|
| |
| RFC 2697 | A Single Rate Three Color Marker |
| |
| Authors: | J. Heinanen, R. Guerin. |
| Date: | September 1999 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2697 |
|
This document defines a Single Rate Three Color Marker (srTCM), which can be used as component in a Diffserv traffic conditioner [RFC2475,RFC2474]. The srTCM meters a traffic stream and marks its packets according to three traffic parameters, Committed Information Rate(CIR), Committed Burst Size (CBS), and Excess Burst Size (EBS), to be either green, yellow, or red. A packet is marked green if it doesn't exceed the CBS, yellow if it does exceed the CBS, but not the EBS, and red otherwise. |
|
| |
| RFC 2698 | A Two Rate Three Color Marker |
| |
| Authors: | J. Heinanen, R. Guerin. |
| Date: | September 1999 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2698 |
|
This document defines a Two Rate Three Color Marker (trTCM), which can be used as a component in a Diffserv traffic conditioner[RFC2475, RFC2474]. The trTCM meters an IP packet stream and marks its packets based on two rates, Peak Information Rate (PIR) andCommitted Information Rate (CIR), and their associated burst sizes to be either green, yellow, or red. A packet is marked red if it exceeds the PIR. Otherwise it is marked either yellow or green depending on whether it exceeds or doesn't exceed the CIR. |
|
| |
| RFC 2699 | Request for Comments Summary RFC Numbers 2600-2699 |
| |
| Authors: | S. Ginoza. |
| Date: | May 2000 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2699 |
|
|
|
| |
| RFC 2701 | Nortel Networks Multi-link Multi-node PPP Bundle Discovery Protocol |
| |
| Authors: | G. Malkin. |
| Date: | September 1999 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2701 |
|
This document specifies a standard way for Multi-link PPP to operate across multiple nodes. Both the mechanism by which the Bundle Head is discovered and the PPP fragment encapsulation are specified. |
|
| |
| RFC 2702 | Requirements for Traffic Engineering Over MPLS |
| |
| Authors: | D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, J. McManus. |
| Date: | September 1999 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2702 |
|
This document presents a set of requirements for Traffic Engineering over Multiprotocol Label Switching (MPLS). It identifies the functional capabilities required to implement policies that facilitate efficient and reliable network operations in an MPLS domain. These capabilities can be used to optimize the utilization of network resources and to enhance traffic oriented performance characteristics. |
|
| |
| RFC 2703 | Protocol-independent Content Negotiation Framework |
| |
| Authors: | G. Klyne. |
| Date: | September 1999 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2703 |
|
A number of Internet application protocols have a need to provide content negotiation for the resources with which they interact. MIME media types [1,2] provide a standard method for handling one major axis of variation, but resources also vary in ways which cannot be expressed using currently available MIME headers.
This memo sets out terminology, an abstract framework and goals for protocol-independent content negotiation, and identifies some technical issues which may need to be addressed.
The abstract framework does not attempt to specify the content negotiation process, but gives an indication of the anticipated scope and form of any such specification. The goals set out the desired properties of a content negotiation mechanism. |
|
| |
| RFC 2704 | The KeyNote Trust-Management System Version 2 |
| |
| Authors: | M. Blaze, J. Feigenbaum, J. Ioannidis, A. Keromytis. |
| Date: | September 1999 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2704 |
|
This memo describes version 2 of the KeyNote trust-management system.It specifies the syntax and semantics of KeyNote `assertions', describes `action attribute' processing, and outlines the application architecture into which a KeyNote implementation can be fit. TheKeyNote architecture and language are useful as building blocks for the trust management aspects of a variety of Internet protocols and services. |
|
| |
| RFC 2705 | Media Gateway Control Protocol (MGCP) Version 1.0 |
| |
| Authors: | M. Arango, A. Dugan, I. Elliott, C. Huitema, S. Pickett. |
| Date: | October 1999 |
| Formats: | txt html json |
| Obsoleted by: | RFC 3435 |
| Updated by: | RFC 3660 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2705 |
|
This document describes an application programming interface and a corresponding protocol (MGCP) for controlling Voice over IP (VoIP)Gateways from external call control elements. MGCP assumes a call control architecture where the call control "intelligence" is outside the gateways and handled by external call control elements.
The document is structured in 6 main sections:
* The introduction presents the basic assumptions and the relation to other protocols such as H.323, RTSP, SAP or SIP.
* The interface section presents a conceptual overview of the MGCP, presenting the naming conventions, the usage of the session description protocol SDP, and the procedures that compose MGCP:Notifications Request, Notification, Create Connection, ModifyConnection, Delete Connection, AuditEndpoint, AuditConnection andRestartInProgress.
* The protocol description section presents the MGCP encodings, which are based on simple text formats, and the transmission procedure over UDP.
* The security section presents the security requirement of MGCP, and its usage of IP security services (IPSEC).
* The event packages section provides an initial definition of packages and event names.
* The description of the changes made in combining SGCP 1.1 and IPDC to create MGCP 1.0. |
|
| |
| RFC 2706 | ECML v1: Field Names for E-Commerce |
| |
| Authors: | D. Eastlake 3rd, T. Goldstein. |
| Date: | October 1999 |
| Formats: | txt json html |
| Obsoleted by: | RFC 3106 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2706 |
|
Customers are frequently required to enter substantial amounts of information at an Internet merchant site in order to complete a purchase or other transaction, especially the first time they go there. A standard set of information fields is defined as the first version of an Electronic Commerce Modeling Language (ECML) so that this task can be more easily automated, for example by wallet software that could fill in fields. Even for the manual data entry case, customers will be less confused by varying merchant sites if a substantial number adopt these standard fields. |
|
| |
| RFC 2707 | Job Monitoring MIB - V1.0 |
| |
| Authors: | R. Bergman, T. Hastings, S. Isaacson, H. Lewis. |
| Date: | November 1999 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2707 |
|
This document provides a printer industry standard SNMP MIB for (1) monitoring the status and progress of print jobs (2) obtaining resource requirements before a job is processed, (3) monitoring resource consumption while a job is being processed and (4) collecting resource accounting data after the completion of a job.This MIB is intended to be implemented (1) in a printer or (2) in a server that supports one or more printers. Use of the object set is not limited to printing. However, support for services other than printing is outside the scope of this Job Monitoring MIB. Future extensions to this MIB may include, but are not limited to, fax machines and scanners. |
|
| |
| RFC 2708 | Job Submission Protocol Mapping Recommendations for the Job Monitoring MIB |
| |
| Authors: | R. Bergman. |
| Date: | November 1999 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2708 |
|
This document defines the recommended mapping for many currently popular Job submission protocols to objects and attributes in the JobMonitoring MIB. |
|
| |
| RFC 2709 | Security Model with Tunnel-mode IPsec for NAT Domains |
| |
| Authors: | P. Srisuresh. |
| Date: | October 1999 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2709 |
|
There are a variety of NAT flavors, as described in [Ref 1]. Of the domains supported by NATs, only Realm-Specific IP clients are able to pursue end-to-end IPsec secure sessions. However, all flavors of NAT are capable of offering tunnel-mode IPsec security to private domain hosts peering with nodes in external realm. This document describes a security model by which tunnel-mode IPsec security can be architected on NAT devices. A section is devoted to describing how security policies may be transparently communicated to IKE (for automated KEY exchange) during Quick Mode. Also outlined are applications that can benefit from the Security Model described. |
|
| |
| RFC 2713 | Schema for Representing Java(tm) Objects in an LDAP Directory |
| |
| Authors: | V. Ryan, S. Seligman, R. Lee. |
| Date: | October 1999 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2713 |
|
This document defines the schema for representing Java(tm) objects in an LDAP directory [LDAPv3]. It defines schema elements to represent a Java serialized object [Serial], a Java marshalled object [RMI], aJava remote object [RMI], and a JNDI reference [JNDI]. |
|
| |
| RFC 2714 | Schema for Representing CORBA Object References in an LDAP Directory |
| |
| Authors: | V. Ryan, R. Lee, S. Seligman. |
| Date: | October 1999 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2714 |
|
CORBA [CORBA] is the Common Object Request Broker Architecture defined by the Object Management Group. This document defines the schema for representing CORBA object references in an LDAP directory[LDAPv3]. |
|
| |
| RFC 2715 | Interoperability Rules for Multicast Routing Protocols |
| |
| Authors: | D. Thaler. |
| Date: | October 1999 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2715 |
|
The rules described in this document will allow efficient interoperation among multiple independent multicast routing domains.Specific instantiations of these rules are given for the DVMRP,MOSPF, PIM-DM, PIM-SM, and CBT multicast routing protocols, as well as for IGMP-only links. Future versions of these protocols, and any other multicast routing protocols, may describe their interoperability procedure by stating how the rules described herein apply to them. |
|
| |
| RFC 2718 | Guidelines for new URL Schemes |
| |
| Authors: | L. Masinter, H. Alvestrand, D. Zigmond, R. Petke. |
| Date: | November 1999 |
| Formats: | txt html json |
| Obsoleted by: | RFC 4395 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2718 |
|
A Uniform Resource Locator (URL) is a compact string representation of the location for a resource that is available via the Internet.This document provides guidelines for the definition of new URL schemes. |
|
| |
| RFC 2719 | Framework Architecture for Signaling Transport |
| |
| Authors: | L. Ong, I. Rytina, M. Garcia, H. Schwarzbauer, L. Coene, H. Lin, I. Juhasz, M. Holdrege, C. Sharp. |
| Date: | October 1999 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2719 |
|
This document defines an architecture framework and functional requirements for transport of signaling information over IP. The framework describes relationships between functional and physical entities exchanging signaling information, such as Signaling Gateways and Media Gateway Controllers. It identifies interfaces where signaling transport may be used and the functional and performance requirements that apply from existing Switched Circuit Network (SCN) signaling protocols. |
|
| |
| RFC 2721 | RTFM: Applicability Statement |
| |
| Authors: | N. Brownlee. |
| Date: | October 1999 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2721 |
|
This document provides an overview covering all aspects of RealtimeTraffic Flow Measurement, including its area of applicability and its limitations. |
|
| |
| RFC 2722 | Traffic Flow Measurement: Architecture |
| |
| Authors: | N. Brownlee, C. Mills, G. Ruth. |
| Date: | October 1999 |
| Formats: | txt json html |
| Obsoletes: | RFC 2063 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2722 |
|
This document provides a general framework for describing network traffic flows, presents an architecture for traffic flow measurement and reporting, discusses how this relates to an overall network traffic flow architecture and indicates how it can be used within theInternet. |
|
| |
| RFC 2723 | SRL: A Language for Describing Traffic Flows and Specifying Actions for Flow Groups |
| |
| Authors: | N. Brownlee. |
| Date: | October 1999 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2723 |
|
This document describes a language for specifying rulesets, i.e. configuration files which may be loaded into a traffic flow meter so as to specify which traffic flows are measured by the meter, and the information it will store for each flow. |
|
| |
| RFC 2729 | Taxonomy of Communication Requirements for Large-scale Multicast Applications |
| |
| Authors: | P. Bagnall, R. Briscoe, A. Poppitt. |
| Date: | December 1999 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2729 |
|
The intention of this memo is to define a classification system for the communication requirements of any large-scale multicast application (LSMA). It is very unlikely one protocol can achieve a compromise between the diverse requirements of all the parties involved in any LSMA. It is therefore necessary to understand the worst-case scenarios in order to minimize the range of protocols needed. Dynamic protocol adaptation is likely to be necessary which will require logic to map particular combinations of requirements to particular mechanisms. Standardizing the way that applications define their requirements is a necessary step towards this.Classification is a first step towards standardization. |
|
| |
| RFC 2731 | Encoding Dublin Core Metadata in HTML |
| |
|
|
The Dublin Core is a small set of metadata elements for describing information resources. This document explains how these elements are expressed using the META and LINK tags of HTML. This memo provides information for the Internet community. |
|
| |
| RFC 2753 | A Framework for Policy-based Admission Control |
| |
| Authors: | R. Yavatkar, D. Pendarakis, R. Guerin. |
| Date: | January 2000 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2753 |
|
This document is concerned with specifying a framework for providing policy-based control over admission control decisions. This memo provides information for the Internet community. |
|
| |
| RFC 2755 | Security Negotiation for WebNFS |
| |
| Authors: | A. Chiu, M. Eisler, B. Callaghan. |
| Date: | January 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2755 |
|
This document describes a protocol for a WebNFS client [RFC2054] to negotiate the desired security mechanism with a WebNFS server[RFC2055] before the WebNFS client falls back to the MOUNT v3 protocol [RFC1813]. This document is provided so that people can write compatible implementations. |
|
| |
| RFC 2757 | Long Thin Networks |
| |
| Authors: | G. Montenegro, S. Dawkins, M. Kojo, V. Magret, N. Vaidya. |
| Date: | January 2000 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2757 |
|
In view of the unpredictable and problematic nature of long thin networks (for example, wireless WANs), arriving at an optimized transport is a daunting task. We have reviewed the existing proposals along with future research items. Based on this overview, we also recommend mechanisms for implementation in long thin networks.
Our goal is to identify a TCP that works for all users, including users of long thin networks. We started from the working recommendations of the IETF TCP Over Satellite Links (tcpsat) working group with this end in mind.
We recognize that not every tcpsat recommendation will be required for long thin networks as well, and work toward a set of TCP recommendations that are 'benign' in environments that do not require them. |
|
| |
| RFC 2759 | Microsoft PPP CHAP Extensions, Version 2 |
| |
| Authors: | G. Zorn. |
| Date: | January 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2759 |
|
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol and a family of NetworkControl Protocols (NCPs) for establishing and configuring different network-layer protocols.
This document describes version two of Microsoft's PPP CHAP dialect(MS-CHAP-V2). MS-CHAP-V2 is similar to, but incompatible with, MS-CHAP version one (MS-CHAP-V1, described in [9]). In particular, certain protocol fields have been deleted or reused but with different semantics. In addition, MS-CHAP-V2 features mutual authentication.
The algorithms used in the generation of various MS-CHAP-V2 protocol fields are described in section 8. Negotiation and hash generation examples are provided in section 9. |
|
| |
| RFC 2760 | Ongoing TCP Research Related to Satellites |
| |
| Authors: | M. Allman, Ed., S. Dawkins, D. Glover, J. Griner, D. Tran, T. Henderson, J. Heidemann, J. Touch, H. Kruse, S. Ostermann, K. Scott, J. Semke. |
| Date: | February 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2760 |
|
This document outlines possible TCP enhancements that may allow TCP to better utilize the available bandwidth provided by networks containing satellite links. The algorithms and mechanisms outlined have not been judged to be mature enough to be recommended by theIETF. The goal of this document is to educate researchers as to the current work and progress being done in TCP research related to satellite networks. |
|
| |
| RFC 2761 | Terminology for ATM Benchmarking |
| |
| Authors: | J. Dunn, C. Martin. |
| Date: | February 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2761 |
|
This memo discusses and defines terms associated with performance benchmarking tests and the results of these tests in the context ofAsynchronous Transfer Mode (ATM) based switching devices. The terms defined in this memo will be used in addition to terms defined inRFCs 1242, 2285, and 2544. This memo is a product of the BenchmarkingMethodology Working Group (BMWG) of the Internet Engineering TaskForce (IETF). |
|
| |
| RFC 2763 | Dynamic Hostname Exchange Mechanism for IS-IS |
| |
|
|
Currently, there does not exist a simple and dynamic mechanism for routers running IS-IS to learn about symbolic hostnames. This document defines a new TLV which allows the IS-IS routers to flood their name to system ID mapping information across the IS-IS network. |
|
| |
| RFC 2764 | A Framework for IP Based Virtual Private Networks |
| |
| Authors: | B. Gleeson, A. Lin, J. Heinanen, G. Armitage, A. Malis. |
| Date: | February 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2764 |
|
This document describes a framework for Virtual Private Networks(VPNs) running across IP backbones. It discusses the various different types of VPNs, their respective requirements, and proposes specific mechanisms that could be used to implement each type of VPN using existing or proposed specifications. The objective of this document is to serve as a framework for related protocol development in order to develop the full set of specifications required for widespread deployment of interoperable VPN solutions. |
|
| |
| RFC 2767 | Dual Stack Hosts using the "Bump-In-the-Stack" Technique (BIS) |
| |
| Authors: | K. Tsuchiya, H. Higuchi, Y. Atarashi. |
| Date: | February 2000 |
| Formats: | txt html json |
| Obsoleted by: | RFC 6535 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2767 |
|
In the especially initial stage of the transition from IPv4 to IPv6, it is hard to provide a complete set of IPv6 applications. This memo proposes a mechanism of dual stack hosts using the technique called"Bump-in-the-Stack" in the IP security area. The mechanism allows the hosts to communicate with other IPv6 hosts using existing IPv4 applications. |
|
| |
| RFC 2768 | Network Policy and Services: A Report of a Workshop on Middleware |
| |
| Authors: | B. Aiken, J. Strassner, B. Carpenter, I. Foster, C. Lynch, J. Mambretti, R. Moore, B. Teitelbaum. |
| Date: | February 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2768 |
|
An ad hoc middleware workshop was held at the International Center for Advanced Internet Research in December 1998. The Workshop was organized and sponsored by Cisco, Northwestern University'sInternational Center for Advanced Internet Research (iCAIR), IBM, and the National Science Foundation (NSF). The goal of the workshop was to identify existing middleware services that could be leveraged for new capabilities as well as identifying additional middleware services requiring research and development. The workshop participants discussed the definition of middleware in general, examined the applications perspective, detailed underlying network transport capabilities relevant to middleware services, and then covered various specific examples of middleware components. These included APIs, authentication, authorization, and accounting (AAA) issues, policy framework, directories, resource management, networked information discovery and retrieval services, quality of service, security, and operational tools. The need for a more organized framework for middleware R&D was recognized, and a list of specific topics needing further work was identified. |
|
| |
| RFC 2771 | An Abstract API for Multicast Address Allocation |
| |
| Authors: | R. Finlayson. |
| Date: | February 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2771 |
|
This document describes the "abstract service interface" for the dynamic multicast address allocation service, as seen by applications. While it does not describe a concrete API (i.e., for a specific programming language), it describes - in abstract terms - the semantics of this service, including the guarantees that it makes to applications.
Additional documents (not necessarily products of the IETF) would describe concrete APIs for this service. |
|
| |
| RFC 2772 | 6Bone Backbone Routing Guidelines |
| |
|
|
The 6Bone is an Ipv6 testbed to assist in the evolution and deployment of IPv6. Because of this, it is important that the core backbone of the IPv6 network maintain stability, and that all operators have a common set of rules and guidelines by which to deploy IPv6 routing equipment.
This document provides a set of guidelines for all 6bone routing equipment operators to use as a reference for efficient and stable deployment of 6bone routing systems. As the complexity of the 6Bone grows,the adherence to a common set of rules becomes increasingly important in order for an efficient, scalable backbone to exist. |
|
| |
| RFC 2775 | Internet Transparency |
| |
| Authors: | B. Carpenter. |
| Date: | February 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2775 |
|
This document describes the current state of the Internet from the architectural viewpoint, concentrating on issues of end-to-end connectivity and transparency. It concludes with a summary of some major architectural alternatives facing the Internet network layer.
This document was used as input to the IAB workshop on the future of the network layer held in July 1999. For this reason, it does not claim to be complete and definitive, and it refrains from making recommendations. |
|
| |
| RFC 2777 | Publicly Verifiable Nomcom Random Selection |
| |
|
|
This document describes a method for making random selections in such a way that the unbiased nature of the choice is publicly verifiable.As an example, the selection of the voting members of the IETFNominations Committee from the pool of eligible volunteers is used.Similar techniques would be applicable to other cases. |
|
| |
| RFC 2778 | A Model for Presence and Instant Messaging |
| |
| Authors: | M. Day, J. Rosenberg, H. Sugano. |
| Date: | February 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2778 |
|
This document defines an abstract model for a presence and instant messaging system. It defines the various entities involved, defines terminology, and outlines the services provided by the system. The goal is to provide a common vocabulary for further work on requirements for protocols and markup for presence and instant messaging. |
|
| |
| RFC 2779 | Instant Messaging / Presence Protocol Requirements |
| |
| Authors: | M. Day, S. Aggarwal, G. Mohr, J. Vincent. |
| Date: | February 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2779 |
|
Presence and Instant Messaging have recently emerged as a new medium of communications over the Internet. Presence is a means for finding, retrieving, and subscribing to changes in the presence information (e.g. "online" or "offline") of other users. Instant messaging is a means for sending small, simple messages that are delivered immediately to online users.
Applications of presence and instant messaging currently use independent, non-standard and non-interoperable protocols developed by various vendors. The goal of the Instant Messaging and PresenceProtocol (IMPP) Working Group is to define a standard protocol so that independently developed applications of instant messaging and/or presence can interoperate across the Internet. This document defines a minimal set of requirements that IMPP must meet. |
|
| |
| RFC 2781 | UTF-16, an encoding of ISO 10646 |
| |
| Authors: | P. Hoffman, F. Yergeau. |
| Date: | February 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2781 |
|
This document describes the UTF-16 encoding of Unicode/ISO-10646, addresses the issues of serializing UTF-16 as an octet stream for transmission over the Internet, discusses MIME charset naming as described in [CHARSET-REG], and contains the registration for three MIME charset parameter values: UTF-16BE (big-endian), UTF-16LE (little- endian), and UTF-16. This memo provides information for the Internet community. |
|
| |
| RFC 2783 | Pulse-Per-Second API for UNIX-like Operating Systems, Version 1.0 |
| |
| Authors: | J. Mogul, D. Mills, J. Brittenson, J. Stone, U. Windl. |
| Date: | March 2000 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2783 |
|
RFC 1589 describes a UNIX kernel implementation model for high- precision time-keeping. This model is meant for use in conjunction with the Network Time Protocol (NTP, RFC 1305), or similar time synchronization protocols. One aspect of this model is an accurate interface to the high-accuracy, one pulse-per-second (PPS) output typically available from precise time sources (such as a GPS or GOES receiver). RFC 1589 did not define an API for managing the PPS facility, leaving implementors without a portable means for using PPS sources. This document specifies such an API. |
|
| |
| RFC 2785 | Methods for Avoiding the "Small-Subgroup" Attacks on the Diffie-Hellman Key Agreement Method for S/MIME |
| |
| Authors: | R. Zuccherato. |
| Date: | March 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2785 |
|
In some circumstances the use of the Diffie-Hellman key agreement scheme in a prime order subgroup of a large prime p is vulnerable to certain attacks known as "small-subgroup" attacks. Methods exist, however, to prevent these attacks. This document will describe the situations relevant to implementations of S/MIME version 3 in which protection is necessary and the methods that can be used to prevent these attacks. |
|
| |
| RFC 2791 | Scalable Routing Design Principles |
| |
|
|
Routing is essential to a network. Routing scalability is essential to a large network. When routing does not scale, there is a direct impact on the stability and performance of a network. Therefore, routing scalability is an important issue, especially for a large network. This document identifies major factors affecting routing scalability as well as basic principles of designing scalable routing for large networks. |
|
| |
| RFC 2792 | DSA and RSA Key and Signature Encoding for the KeyNote Trust Management System |
| |
| Authors: | M. Blaze, J. Ioannidis, A. Keromytis. |
| Date: | March 2000 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2792 |
|
This memo describes RSA and DSA key and signature encoding, and binary key encoding for version 2 of the KeyNote trust-management system. |
|
| |
| RFC 2795 | The Infinite Monkey Protocol Suite (IMPS) |
| |
| Authors: | S. Christey. |
| Date: | 1 April 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2795 |
|
This memo describes a protocol suite which supports an infinite number of monkeys that sit at an infinite number of typewriters in order to determine when they have either produced the entire works ofWilliam Shakespeare or a good television show. The suite includes communications and control protocols for monkeys and the organizations that interact with them. |
|
| |
| RFC 2798 | Definition of the inetOrgPerson LDAP Object Class |
| |
|
|
While the X.500 standards define many useful attribute types [X520] and object classes [X521], they do not define a person object class that meets the requirements found in today's Internet and Intranet directory service deployments. We define a new object class called inetOrgPerson for use in LDAP and X.500 directory services that extends the X.521 standard organizationalPerson class to meet these needs. |
|
| |
| RFC 2799 | Request for Comments Summary RFC Numbers 2700-2799 |
| |
| Authors: | S. Ginoza. |
| Date: | September 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2799 |
|
|
|
| |
| RFC 2801 | Internet Open Trading Protocol - IOTP Version 1.0 |
| |
| Authors: | D. Burdett. |
| Date: | April 2000 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2801 |
|
The Internet Open Trading Protocol (IOTP) provides an interoperable framework for Internet commerce. It is payment system independent and encapsulates payment systems such as SET, Secure ChannelCredit/Debit, Mondex, CyberCoin, GeldKarte, etc. IOTP is able to handle cases where such merchant roles as the shopping site, thePayment Handler, the Delivery Handler of goods or services, and the provider of customer support are performed by different parties or by one party. |
|
| |
| RFC 2802 | Digital Signatures for the v1.0 Internet Open Trading Protocol (IOTP) |
| |
| Authors: | K. Davidson, Y. Kawatsura. |
| Date: | April 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2802 |
|
A syntax and procedures are described for the computation and verification of digital signatures for use within Version 1.0 of theInternet Open Trading Protocol (IOTP). |
|
| |
| RFC 2803 | Digest Values for DOM (DOMHASH) |
| |
| Authors: | H. Maruyama, K. Tamura, N. Uramoto. |
| Date: | April 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2803 |
|
This memo defines a clear and unambiguous definition of digest (hash) values of the XML objects regardless of the surface string variation of XML. This definition can be used for XML digital signature as well efficient replication of XML objects. |
|
| |
| RFC 2804 | IETF Policy on Wiretapping |
| |
| Authors: | IAB, IESG. |
| Date: | May 2000 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2804 |
|
The Internet Engineering Task Force (IETF) has been asked to take a position on the inclusion into IETF standards-track documents of functionality designed to facilitate wiretapping.
This memo explains what the IETF thinks the question means, why its answer is "no", and what that answer means. |
|
| |
| RFC 2805 | Media Gateway Control Protocol Architecture and Requirements |
| |
| Authors: | N. Greene, M. Ramalho, B. Rosen. |
| Date: | April 2000 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2805 |
|
This document describes protocol requirements for the Media GatewayControl Protocol between a Media Gateway Controller and a MediaGateway. |
|
| |
| RFC 2807 | XML Signature Requirements |
| |
| Authors: | J. Reagle. |
| Date: | July 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2807 |
|
This document lists the design principles, scope, and requirements for the XML Digital Signature specification. It includes requirements as they relate to the signature syntax, data model, format, cryptographic processing, and external requirements and coordination. |
|
| |
| RFC 2808 | The SecurID(r) SASL Mechanism |
| |
| Authors: | M. Nystrom. |
| Date: | April 2000 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2808 |
|
SecurID is a hardware token card product (or software emulation thereof) produced by RSA Security Inc., which is used for end-user authentication. This document defines a SASL [RFC2222] authentication mechanism using these tokens, thereby providing a means for such tokens to be used in SASL environments. This mechanism is only for authentication, and has no effect on the protocol encoding and is not designed to provide integrity or confidentiality services.
This memo assumes the reader has basic familiarity with the SecurID token, its associated authentication protocol and SASL. |
|
| |
| RFC 2809 | Implementation of L2TP Compulsory Tunneling via RADIUS |
| |
| Authors: | B. Aboba, G. Zorn. |
| Date: | April 2000 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2809 |
|
This document discusses implementation issues arising in the provisioning of compulsory tunneling in dial-up networks using theL2TP protocol. This provisioning can be accomplished via the integration of RADIUS and tunneling protocols. Implementation issues encountered with other tunneling protocols are left to separate documents. |
|
| |
| RFC 2810 | Internet Relay Chat: Architecture |
| |
|
|
The IRC (Internet Relay Chat) protocol is for use with text based conferencing. It has been developed since 1989 when it was originally implemented as a mean for users on a BBS to chat amongst themselves.
First formally documented in May 1993 by RFC 1459 [IRC], the protocol has kept evolving. This document is an update describing the architecture of the current IRC protocol and the role of its different components. Other documents describe in detail the protocol used between the various components defined here. |
|
| |
| RFC 2811 | Internet Relay Chat: Channel Management |
| |
|
|
One of the most notable characteristics of the IRC (Internet RelayChat) protocol is to allow for users to be grouped in forums, called channels, providing a mean for multiple users to communicate together.
There was originally a unique type of channels, but with the years, new types appeared either as a response to a need, or for experimental purposes.
This document specifies how channels, their characteristics and properties are managed by IRC servers. |
|
| |
| RFC 2812 | Internet Relay Chat: Client Protocol |
| |
|
|
The IRC (Internet Relay Chat) protocol is for use with text based conferencing; the simplest client being any socket program capable of connecting to the server.
This document defines the Client Protocol, and assumes that the reader is familiar with the IRC Architecture [IRC-ARCH]. |
|
| |
| RFC 2813 | Internet Relay Chat: Server Protocol |
| |
|
|
While based on the client-server model, the IRC (Internet Relay Chat) protocol allows servers to connect to each other effectively forming a network.
This document defines the protocol used by servers to talk to each other. It was originally a superset of the client protocol but has evolved differently.
First formally documented in May 1993 as part of RFC 1459 [IRC], most of the changes brought since then can be found in this document as development was focused on making the protocol scale better. Better scalability has allowed existing world-wide networks to keep growing and reach sizes which defy the old specification. |
|
| |
| RFC 2816 | A Framework for Integrated Services Over Shared and Switched IEEE 802 LAN Technologies |
| |
| Authors: | A. Ghanwani, J. Pace, V. Srinivasan, A. Smith, M. Seaman. |
| Date: | May 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2816 |
|
This memo describes a framework for supporting IETF IntegratedServices on shared and switched LAN infrastructure. It includes background material on the capabilities of IEEE 802 like networks with regard to parameters that affect Integrated Services such as access latency, delay variation and queuing support in LAN switches.It discusses aspects of IETF's Integrated Services model that cannot easily be accommodated in different LAN environments. It outlines a functional model for supporting the Resource Reservation Protocol(RSVP) in such LAN environments. Details of extensions to RSVP for use over LANs are described in an accompanying memo [14]. Mappings of the various Integrated Services onto IEEE 802 LANs are described in another memo [13]. |
|
| |
| RFC 2818 | HTTP Over TLS |
| |
|
|
This memo describes how to use TLS to secure HTTP connections over the Internet. Current practice is to layer HTTP over SSL (the predecessor to TLS), distinguishing secured traffic from insecure traffic by the use of a different server port. This document documents that practice using TLS. A companion document describes a method for using HTTP/TLS over the same port as normal HTTP[RFC2817]. |
|
| |
| RFC 2820 | Access Control Requirements for LDAP |
| |
| Authors: | E. Stokes, D. Byrne, B. Blakley, P. Behera. |
| Date: | May 2000 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2820 |
|
This document describes the fundamental requirements of an access control list (ACL) model for the Lightweight Directory ApplicationProtocol (LDAP) directory service. It is intended to be a gathering place for access control requirements needed to provide authorized access to and interoperability between directories.
The keywords "MUST", "SHOULD", and "MAY" used in this document are to be interpreted as described in [bradner97]. |
|
| |
| RFC 2824 | Call Processing Language Framework and Requirements |
| |
| Authors: | J. Lennox, H. Schulzrinne. |
| Date: | May 2000 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2824 |
|
A large number of the services we wish to make possible for Internet telephony require fairly elaborate combinations of signalling operations, often in network devices, to complete. We want a simple and standardized way to create such services to make them easier to implement and deploy. This document describes an architectural framework for such a mechanism, which we call a call processing language. It also outlines requirements for such a language. |
|
| |
| RFC 2825 | A Tangled Web: Issues of I18N, Domain Names, and the Other Internet protocols |
| |
| Authors: | IAB, L. Daigle, Ed.. |
| Date: | May 2000 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2825 |
|
The goals of the work to "internationalize" Internet protocols include providing all users of the Internet with the capability of using their own language and its standard character set to express themselves, write names, and to navigate the network. This impacts the domain names visible in e-mail addresses and so many of today'sURLs used to locate information on the World Wide Web, etc. However, domain names are used by Internet protocols that are used across national boundaries. These services must interoperate worldwide, or we risk isolating components of the network from each other along locale boundaries. This type of isolation could impede not only communications among people, but opportunities of the areas involved to participate effectively in e-commerce, distance learning, and other activities at an international scale, thereby retarding economic development.
There are several proposals for internationalizing domain names, however it it is still to be determined whether any of them will ensure this interoperability and global reach while addressing visible-name representation. Some of them obviously do not. This document does not attempt to review any specific proposals, as that is the work of the Internationalized Domain Name (IDN) Working Group of the IETF, which is tasked with evaluating them in consideration of the continued global network interoperation that is the deserved expectation of all Internet users.
This document is a statement by the Internet Architecture Board. It is not a protocol specification, but an attempt to clarify the range of architectural issues that the internationalization of domain names faces. |
|
| |
| RFC 2826 | IAB Technical Comment on the Unique DNS Root |
| |
| Authors: | Internet Architecture Board. |
| Date: | May 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2826 |
|
This document discusses the existence of a globally unique public name space in the Internet called the DNS (Domain Name System). This name space is a hierarchical name space derived from a single, globally unique root. It is a technical constraint inherent in the design of the DNS. One root must be supported by a set of coordinated root servers administered by a unique naming authority. It is not technically feasible for there to be more than one root in the public DNS. This memo provides information for the Internet community. |
|
| |
| RFC 2828 | Internet Security Glossary |
| |
|
|
This Glossary (191 pages of definitions and 13 pages of references) provides abbreviations, explanations, and recommendations for use of information system security terminology. The intent is to improve the comprehensibility of writing that deals with Internet security, particularly Internet Standards documents (ISDs). To avoid confusion,ISDs should use the same term or definition whenever the same concept is mentioned. To improve international understanding, ISDs should use terms in their plainest, dictionary sense. ISDs should use terms established in standards documents and other well-founded publications and should avoid substituting private or newly made-up terms. ISDs should avoid terms that are proprietary or otherwise favor a particular vendor, or that create a bias toward a particular security technology or mechanism versus other, competing techniques that already exist or might be developed in the future. |
|
| |
| RFC 2832 | NSI Registry Registrar Protocol (RRP) Version 1.1.0 |
| |
| Authors: | S. Hollenbeck, M. Srivastava. |
| Date: | May 2000 |
| Formats: | txt json html |
| Updated by: | RFC 3632 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2832 |
|
This document describes a protocol for the registration and management of second level domain names and associated name servers in both generic Top Level Domains (gTLDs) and country code Top LevelDomains (ccTLDs). This protocol was developed by the NetworkSolutions Registry for use within the Shared Registration System and is being published "as-is" to document the protocol implementation developed by the Network Solutions, Inc. Registry.
Internet domain name registration typically involves three entities: a registrant who wishes to register a domain name, a registrar who provides services to the registrant, and a registry that provides services to the registrar while serving as the authoritative repository of all functional information required to resolve names registered in the registry's TLDs. This document describes a protocol for registry-registrar communication only. The protocol does not provide any registrant services.
This document is being discussed on the "rrp" mailing list. To join the list, send a message to <majordomo@NSIRegistry.com&rt; with the words "subscribe rrp" in the body of the message. There is also a web site for the mailing list archives at<http://www.NSIRegistry.net/maillist/rrp&rt;. |
|
| |
| RFC 2838 | Uniform Resource Identifiers for Television Broadcasts |
| |
| Authors: | D. Zigmond, M. Vickers. |
| Date: | May 2000 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2838 |
|
This document describes a widely-implemented URI scheme, as World-Wide Web browsers are starting to appear on a variety of consumer electronic devices, such as television sets and television set-top boxes, which are capable of receiving television programming from either terrestrial broadcast, satellite broadcast, or cable. In this context there is a need to reference television broadcasts using the URI format described in RFC 2396. This memo provides information for the Internet community. |
|
| |
| RFC 2839 | Internet Kermit Service |
| |
| Authors: | F. da Cruz, J. Altman. |
| Date: | May 2000 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2839 |
|
This document describes a new file transfer service for the Internet based on Telnet Protocol for option negotiation and Kermit Protocol for file transfer and management. This memo provides information for the Internet community. |
|
| |
| RFC 2840 | TELNET KERMIT OPTION |
| |
| Authors: | J. Altman, F. da Cruz. |
| Date: | May 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2840 |
|
This document describes an extension to the Telnet protocol to allow the negotiation, coordination, and use of the Kermit file transfer and management protocol over an existing Telnet protocol connection. This memo provides information for the Internet community. |
|
| |
| RFC 2843 | Proxy-PAR |
| |
| Authors: | P. Droz, T. Przygienda. |
| Date: | May 2000 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2843 |
|
Proxy-PAR is a minimal version of PAR (PNNI Augmented Routing) that gives ATM-attached devices the ability to interact with PNNI devices without the necessity to fully support PAR. Proxy-PAR is designed as a client/server interaction, of which the client side is much simpler than the server side to allow fast implementation and deployment.
The purpose of Proxy-PAR is to allow non-ATM devices to use the flooding mechanisms provided by PNNI for registration and automatic discovery of services offered by ATM attached devices. The first version of PAR primarily addresses protocols available in IPv4. But it also contains a generic interface to access the flooding of PNNI.In addition, Proxy-PAR-capable servers provide filtering based on VPNIDs [1], IP protocols and address prefixes. This enables, for instance, routers in a certain VPN running OSPF to find OSPF neighbors on the same subnet. The protocol is built using a registration/query approach where devices can register their services and query for services and protocols registered by other clients. |
|
| |
| RFC 2854 | 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; it is intended to obsolete the previous IETF documents defining HTML, including RFC 1866, RFC 1867, RFC 1980, RFC1942 and RFC 2070, and to remove HTML from IETF Standards Track.
This document was prepared at the request of the W3C HTML working group. Please send comments to www-html@w3.org, a public mailing list with archive at <http://lists.w3.org/Archives/Public/www-html/&rt;. |
|
| |
| RFC 2860 | Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority |
| |
| Authors: | B. Carpenter, F. Baker, M. Roberts. |
| Date: | June 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2860 |
|
This document places on record the text of the Memorandum ofUnderstanding concerning the technical work of the IANA that was signed on March 1, 2000 between the IETF and ICANN, and ratified by the ICANN Board on March 10, 2000. |
|
| |
| RFC 2866 | RADIUS Accounting |
| |
|
|
This document describes a protocol for carrying accounting information between a Network Access Server and a shared AccountingServer. |
|
| |
| RFC 2867 | RADIUS Accounting Modifications for Tunnel Protocol Support |
| |
|
|
This document defines new RADIUS accounting Attributes and new values for the existing Acct-Status-Type Attribute [1] designed to support the provision of compulsory tunneling in dial-up networks. |
|
| |
| RFC 2868 | RADIUS Attributes for Tunnel Protocol Support |
| |
| Authors: | G. Zorn, D. Leifer, A. Rubens, J. Shriver, M. Holdrege, I. Goyret. |
| Date: | June 2000 |
| Formats: | txt json html |
| Updates: | RFC 2865 |
| Updated by: | RFC 3575 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2868 |
|
This document defines a set of RADIUS attributes designed to support the provision of compulsory tunneling in dial-up networks. |
|
| |
| RFC 2869 | RADIUS Extensions |
| |
|
|
This document describes additional attributes for carrying authentication, authorization and accounting information between aNetwork Access Server (NAS) and a shared Accounting Server using theRemote Authentication Dial In User Service (RADIUS) protocol described in RFC 2865 [1] and RFC 2866 [2]. |
|
| |
| RFC 2871 | A Framework for Telephony Routing over IP |
| |
| Authors: | J. Rosenberg, H. Schulzrinne. |
| Date: | June 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2871 |
|
This document serves as a framework for Telephony Routing over IP(TRIP), which supports the discovery and exchange of IP telephony gateway routing tables between providers. The document defines the problem of telephony routing exchange, and motivates the need for the protocol. It presents an architectural framework for TRIP, defines terminology, specifies the various protocol elements and their functions, overviews the services provided by the protocol, and discusses how it fits into the broader context of Internet telephony. |
|
| |
| RFC 2876 | Use of the KEA and SKIPJACK Algorithms in CMS |
| |
| Authors: | J. Pawling. |
| Date: | July 2000 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2876 |
|
This document describes the conventions for using the Key ExchangeAlgorithm (KEA) and SKIPJACK encryption algorithm in conjunction with the Cryptographic Message Syntax [CMS] enveloped-data and encrypted- data content types. |
|
| |
| RFC 2877 | 5250 Telnet Enhancements |
| |
|
|
This memo describes the interface to the IBM 5250 Telnet server that allows client Telnet to request a Telnet terminal or printer session using a specific device name. If a requested device name is not available, a method to retry the request using a new device name is described. Methods to request specific Telnet session settings and auto-signon function are also described.
By allowing a Telnet client to select the device name, the 5250Telnet server opens the door for applications to set and/or extract useful information about the Telnet client. Some possibilities are1) selecting a customized device name associated with a particular user profile name for National Language Support or subsystem routing,2) connecting PC and network printers as clients and 3) auto-signon using clear-text or DES-encrypted password exchange.
Applications may need to use system API's on the AS/400 in order to extract Telnet session settings from the device name description.Refer to the Retrieve Device Description (QDCRDEVD) API described in the AS/400 System API book [3] on how to extract information using the DEVD0600 and DEVD1100 templates.
This memo describes how the IBM 5250 Telnet server supports WorkStation Function (WSF) printers using 5250 Display Station Pass-Through. A response code is returned by the Telnet server to indicate success or failure of the WSF printer session. |
|
| |
| RFC 2880 | Internet Fax T.30 Feature Mapping |
| |
| Authors: | L. McIntyre, G. Klyne. |
| Date: | August 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2880 |
|
This document describes how to map Group 3 fax capability identification bits, described in ITU T.30 [6], into the Internet fax feature schema described in "Content feature schema for Internet fax"[4].
This is a companion to the fax feature schema document [4], which itself defines a profile of the media feature registration mechanisms[1,2,3], for use in performing capability identification between extended Internet fax systems [5]. |
|
| |
| RFC 2881 | Network Access Server Requirements Next Generation (NASREQNG) NAS Model |
| |
| Authors: | D. Mitton, M. Beadles. |
| Date: | July 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2881 |
|
This document describes the terminology and gives a model of typicalNetwork Access Server (NAS). The purpose of this effort is to set the reference space for describing and evaluating NAS service protocols, such as RADIUS (RFCs 2865, 2866) [1], [2] and follow-on efforts like AAA Working Group, and the Diameter protocol [3]. These are protocols for carrying user service information for authentication, authorization, accounting, and auditing, between aNetwork Access Server which desires to authenticate its incoming calls and a shared authentication server. |
|
| |
| RFC 2882 | Network Access Servers Requirements: Extended RADIUS Practices |
| |
| Authors: | D. Mitton. |
| Date: | July 2000 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2882 |
|
This document describes current practices implemented in NAS products that go beyond the scope of the RADIUS RFCs 2138, 2139 [1,2]. The purpose of this effort is to give examples that show the need for addressing and standardizing these types of ad-hoc functions. Since many of these features require a matching server support component, the ability to deploy and manage interoperable NAS and AAA server products is severely hindered.
These practices are documented here to show functions that are obviously desired in developing future AAA protocols for NAS deployment. |
|
| |
| RFC 2884 | Performance Evaluation of Explicit Congestion Notification (ECN) in IP Networks |
| |
| Authors: | J. Hadi Salim, U. Ahmed. |
| Date: | July 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2884 |
|
This memo presents a performance study of the Explicit CongestionNotification (ECN) mechanism in the TCP/IP protocol using our implementation on the Linux Operating System. ECN is an end-to-end congestion avoidance mechanism proposed by [6] and incorporated intoRFC 2481[7]. We study the behavior of ECN for both bulk and transactional transfers. Our experiments show that there is improvement in throughput over NON ECN (TCP employing any of Reno,SACK/FACK or NewReno congestion control) in the case of bulk transfers and substantial improvement for transactional transfers.
A more complete pdf version of this document is available at: http://www7.nortel.com:8080/CTL/ecnperf.pdf
This memo in its current revision is missing a lot of the visual representations and experimental results found in the pdf version. |
|
| |
| RFC 2887 | The Reliable Multicast Design Space for Bulk Data Transfer |
| |
| Authors: | M. Handley, S. Floyd, B. Whetten, R. Kermode, L. Vicisano, M. Luby. |
| Date: | August 2000 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2887 |
|
The design space for reliable multicast is rich, with many possible solutions having been devised. However, application requirements serve to constrain this design space to a relatively small solution space. This document provides an overview of the design space and the ways in which application constraints affect possible solutions. |
|
| |
| RFC 2888 | Secure Remote Access with L2TP |
| |
| Authors: | P. Srisuresh. |
| Date: | August 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2888 |
|
L2TP protocol is a virtual extension of PPP across IP network infrastructure. L2TP makes possible for an access concentrator (LAC) to be near remote clients, while allowing PPP termination server(LNS) to be located in enterprise premises. L2TP allows an enterprise to retain control of RADIUS data base, which is used to controlAuthentication, Authorization and Accountability (AAA) of dial-in users. The objective of this document is to extend security characteristics of IPsec to remote access users, as they dial-in through the Internet. This is accomplished without creating new protocols and using the existing practices of Remote Access andIPsec. Specifically, the document proposes three new RADIUS parameters for use by the LNS node, acting as Secure Remote AccessServer (SRAS) to mandate network level security between remote clients and the enterprise. The document also discusses limitations of the approach. |
|
| |
| RFC 2889 | Benchmarking Methodology for LAN Switching Devices |
| |
| Authors: | R. Mandeville, J. Perser. |
| Date: | August 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2889 |
|
This document is intended to provide methodology for the benchmarking of local area network (LAN) switching devices. This memo provides information for the Internet community. |
|
| |
| RFC 2892 | The Cisco SRP MAC Layer Protocol |
| |
| Authors: | D. Tsiang, G. Suwala. |
| Date: | August 2000 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2892 |
|
This document specifies the MAC layer protocol, "Spatial ReuseProtocol" (SRP) for use with ring based media. This is a second version of the protocol (V2).
The primary requirements for SRP are as follows:
- Efficient use of bandwidth using: spatial reuse of bandwidth local reuse of bandwidth minimal protocol overhead- Support for priority traffic- Scalability across a large number of nodes or stations attached to a ring- "Plug and play" design without a software based station management transfer (SMT) protocol or ring master negotiation as seen in other ring based MAC protocols [1][2]- Fairness among nodes using the ring- Support for ring based redundancy (error detection, ring wrap, etc.) similar to that found in SONET BLSR specifications.- Independence of physical layer (layer 1) media type.
This document defines the terminology used with SRP, packet formats, the protocol format, protocol operation and associated protocol finite state machines. |
|
| |
| RFC 2896 | Remote Network Monitoring MIB Protocol Identifier Macros |
| |
| Authors: | A. Bierman, C. Bucci, R. Iddon. |
| Date: | August 2000 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2896 |
|
This memo contains various protocol identifier examples, which can be used to produce valid protocolDirTable INDEX encodings, as defined by the Remote Network Monitoring MIB (Management Information Base)Version 2 [RFC2021] and the RMON Protocol Identifier Reference[RFC2895].
This document contains protocol identifier macros for well-known protocols. A conformant implementation of the RMON-2 MIB [RFC2021] can be accomplished without the use of these protocol identifiers, and accordingly, this document does not specify any IETF standard.It is published to encourage better interoperability between RMON-2 agent implementations, by providing a great deal of RMON related protocol information in one document.
The first version of the RMON Protocol Identifiers Document [RFC2074] has been split into a standards-track Reference portion [RFC2895], and an "RMON Protocol Identifier Macros", document (this document) which contains the non-normative portion of that specification. |
|
| |
| RFC 2897 | Proposal for an MGCP Advanced Audio Package |
| |
| Authors: | D. Cromwell. |
| Date: | August 2000 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2897 |
|
This document is a proposal to add a new event/signal package to theMGCP (Media Gateway Control Protocol) protocol to control an ARF(Audio Resource Function) which may reside on a Media Gateway or specialized Audio Server.
This event package provides support for the standard IVR (InteractiveVoice Response) operations of PlayAnnouncement, PlayCollect, andPlayRecord. It supports direct references to simple audio as well as indirect references to simple and complex audio. It provides audio variables, control of audio interruptibility, digit buffer control, special key sequences, and support for reprompting during data collection. It also provides an arbitrary number of user defined qualifiers to be used in resolving complex audio structures. For example, the user could define qualifiers for any or all of the following: language, accent, audio file format, gender, speaker, or customer. |
|
| |
| RFC 2898 | PKCS #5: Password-Based Cryptography Specification Version 2.0 |
| |
|
|
This memo represents a republication of PKCS #5 v2.0 from RSALaboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document, except for the security considerations section, is taken directly from that specification.
This document provides recommendations for the implementation of password-based cryptography, covering key derivation functions, encryption schemes, message-authentication schemes, and ASN.1 syntax identifying the techniques.
The recommendations are intended for general application within computer and communications systems, and as such include a fair amount of flexibility. They are particularly intended for the protection of sensitive information such as private keys, as in PKCS#8 [25]. It is expected that application standards and implementation profiles based on these specifications may include additional constraints.
Other cryptographic techniques based on passwords, such as password- based key entity authentication and key establishment protocols[4][5][26] are outside the scope of this document. Guidelines for the selection of passwords are also outside the scope. |
|
| |
| RFC 2899 | Request for Comments Summary RFC Numbers 2800-2899 |
| |
| Authors: | S. Ginoza. |
| Date: | May 2001 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2899 |
|
|
|
| |
| RFC 2901 | Guide to Administrative Procedures of the Internet Infrastructure |
| |
| Authors: | Z. Wenzel, J. Klensin, R. Bush, S. Huter. |
| Date: | August 2000 |
| Formats: | txt json html |
| Also: | FYI 0037 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2901 |
|
This document describes the administrative procedures for networks seeking to connect to the global Internet. This includes the steps and operations necessary for address space allocation and registration, routing database registration, and domain name registration. The document also contains information about the required forms and how to obtain them. |
|
| |
| RFC 2902 | Overview of the 1998 IAB Routing Workshop |
| |
| Authors: | S. Deering, S. Hares, C. Perkins, R. Perlman. |
| Date: | August 2000 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2902 |
|
This document is an overview of a Routing workshop held by theInternet Architecture Board (IAB) during March 25-27, 1998. The major points of discussion are listed, along with some conclusions and action items for many of the points of discussion. |
|
| |
| RFC 2904 | AAA Authorization Framework |
| |
| Authors: | J. Vollbrecht, P. Calhoun, S. Farrell, L. Gommans, G. Gross, B. de Bruijn, C. de Laat, M. Holdrege, D. Spence. |
| Date: | August 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2904 |
|
This memo serves as the base requirements for Authorization ofInternet Resources and Services (AIRS). It presents an architectural framework for understanding the authorization of Internet resources and services and derives requirements for authorization protocols. |
|
| |
| RFC 2905 | AAA Authorization Application Examples |
| |
| Authors: | J. Vollbrecht, P. Calhoun, S. Farrell, L. Gommans, G. Gross, B. de Bruijn, C. de Laat, M. Holdrege, D. Spence. |
| Date: | August 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2905 |
|
This memo describes several examples of applications requiring authorization. Each application is described in terms of a consistent framework, and specific authorization requirements of each application are given. This material was not contributed by the working groups responsible for the applications and should not be considered prescriptive for how the applications will meet their authorization needs. Rather the intent is to explore the fundamental needs of a variety of different applications with the view of compiling a set of requirements that an authorization protocol will need to meet in order to be generally useful. |
|
| |
| RFC 2906 | AAA Authorization Requirements |
| |
| Authors: | S. Farrell, J. Vollbrecht, P. Calhoun, L. Gommans, G. Gross, B. de Bruijn, C. de Laat, M. Holdrege, D. Spence. |
| Date: | August 2000 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2906 |
|
This document specifies the requirements that AuthenticationAuthorization Accounting (AAA) protocols must meet in order to support authorization services in the Internet. The requirements have been elicited from a study of a range of applications including mobile-IP, roamops and others. |
|
| |
| RFC 2917 | A Core MPLS IP VPN Architecture |
| |
| Authors: | K. Muthukrishnan, A. Malis. |
| Date: | September 2000 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2917 |
|
This memo presents an approach for building core Virtual PrivateNetwork (VPN) services in a service provider's MPLS backbone. This approach uses Multiprotocol Label Switching (MPLS) running in the backbone to provide premium services in addition to best effort services. The central vision is for the service provider to provide a virtual router service to their customers. The keystones of this architecture are ease of configuration, user security, network security, dynamic neighbor discovery, scaling and the use of existing routing protocols as they exist today without any modifications. |
|
| |
| RFC 2921 | 6BONE pTLA and pNLA Formats (pTLA) |
| |
| Authors: | B. Fink. |
| Date: | September 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2921 |
|
This memo defines how the 6bone uses the 3FFE::/16 IPv6 address prefix, allocated in RFC 2471, "IPv6 Testing Address Allocation",[6BONE-TLA], to create pseudo Top-Level Aggregation Identifiers(pTLA's) and pseudo Next-Level Aggregation Identifiers (pNLA's). |
|
| |
| RFC 2922 | Physical Topology MIB |
| |
| Authors: | A. Bierman, K. Jones. |
| Date: | September 2000 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2922 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes managed objects used for managing physical topology identification and discovery. |
|
| |
| RFC 2923 | TCP Problems with Path MTU Discovery |
| |
| Authors: | K. Lahey. |
| Date: | September 2000 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2923 |
|
This memo catalogs several known Transmission Control Protocol (TCP) implementation problems dealing with Path Maximum Transmission UnitDiscovery (PMTUD), including the long-standing black hole problem, stretch acknowlegements (ACKs) due to confusion between MaximumSegment Size (MSS) and segment size, and MSS advertisement based onPMTU. |
|
| |
| RFC 2924 | Accounting Attributes and Record Formats |
| |
| Authors: | N. Brownlee, A. Blount. |
| Date: | September 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2924 |
|
This document summarises Internet Engineering Task Force (IETF) andInternational Telecommunication Union (ITU-T) documents related toAccounting. A classification scheme for the Accounting Attributes in the summarised documents is presented. Exchange formats forAccounting data records are discussed, as are advantages and disadvantages of integrated versus separate record formats and transport protocols. This document discusses service definition independence, extensibility, and versioning. Compound service definition capabilities are described. |
|
| |
| RFC 2926 | Conversion of LDAP Schemas to and from SLP Templates |
| |
| Authors: | J. Kempf, R. Moats, P. St. Pierre. |
| Date: | September 2000 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2926 |
|
This document describes a procedure for mapping between ServiceLocation Protocol (SLP) service advertisements and lightweight directory access protocol (LDAP) descriptions of services. The document covers two aspects of the mapping. One aspect is mapping between SLP service type templates and LDAP directory schema.Because the SLP service type template grammar is relatively simple, mapping from service type templates to LDAP types is straightforward.Mapping in the other direction is straightforward if the attributes are restricted to use just a few of the syntaxes defined in RFC 2252.If arbitrary ASN.1 types occur in the schema, then the mapping is more complex and may even be impossible. The second aspect is representation of service information in an LDAP directory. The recommended representation simplifies interoperability with SLP by allowing SLP directory agents to backend into LDAP directory servers.The resulting system allows service advertisements to propagate easily between SLP and LDAP. |
|
| |
| RFC 2927 | MIME Directory Profile for LDAP Schema |
| |
| Authors: | M. Wahl. |
| Date: | September 2000 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2927 |
|
This document defines a multipurpose internet mail extensions (MIME) directory profile for holding a lightweight directory access protocol(LDAP) schema. It is intended for communication with the Internet schema listing service. |
|
| |
| RFC 2928 | Initial IPv6 Sub-TLA ID Assignments |
| |
| Authors: | R. Hinden, S. Deering, R. Fink, T. Hain. |
| Date: | September 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2928 |
|
This document defines initial assignments of IPv6 Sub-Top-LevelAggregation Identifiers (Sub-TLA ID) to the Address Registries. It is intended as technical input to the Internet Assigned NumbersAuthority (IANA) from the Internet Engineering Task Force (IETF)Internet Protocol Next Generation (IPNG) and Next GenerationTransition (NGTRANS) working groups, as an input to the process of developing guidelines for the allocation of IPv6 addresses.
This document was originally developed to provide advice to IANA in the fall of 1998 and is being published at this time for the historical record. The Internet Architecture Board (IAB) subsequently requested that the IANA delegate these assignments to the Address Registries. The IANA did this and the Address Registries are now using them to assign IPv6 addresses. |
|
| |
| RFC 2936 | HTTP MIME Type Handler Detection |
| |
| Authors: | D. Eastlake 3rd, C. Smith, D. Soroka. |
| Date: | September 2000 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2936 |
|
Entities composing web pages to provide services over the HypertextTransfer Protocol (HTTP) frequently have the problem of not knowing what Multipurpose Internet Mail Extensions (MIME) types have handlers installed at a user's browser. For example, whether an Internet OpenTrading Protocol (IOTP) or VRML or SET or some streaming media handler is available. In some cases they would want to display different web pages or content depending on a MIME handler's availability. This document summarizes reasonable techniques to solve this problem for most of the browsers actually deployed on theInternet as of early 2000. It is intended to be of practical use to implementors during the period before the wide deployment of superior standards based techniques which may be developed. |
|
| |
| RFC 2951 | TELNET Authentication Using KEA and SKIPJACK |
| |
| Authors: | R. Housley, T. Horting, P. Yee. |
| Date: | September 2000 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2951 |
|
This document defines a method to authenticate TELNET using the KeyExchange Algorithm (KEA), and encryption of the TELNET stream usingSKIPJACK. Two encryption modes are specified; one provides data integrity and the other does not. The method relies on the TELNETAuthentication Option. |
|
| |
| RFC 2952 | Telnet Encryption: DES 64 bit Cipher Feedback |
| |
| Authors: | T. Ts'o. |
| Date: | September 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2952 |
|
This document specifies how to use the DES encryption algorithm in cipher feedback mode with the telnet encryption option. |
|
| |
| RFC 2953 | Telnet Encryption: DES 64 bit Output Feedback |
| |
| Authors: | T. Ts'o. |
| Date: | September 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2953 |
|
This document specifies how to use the data encryption standard (DES) encryption algorithm in output feedback mode with the telnet encryption option. |
|
| |
| RFC 2956 | Overview of 1999 IAB Network Layer Workshop |
| |
| Authors: | M. Kaat. |
| Date: | October 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2956 |
|
This document is an overview of a workshop held by the InternetArchitecture Board (IAB) on the Internet Network Layer architecture hosted by SURFnet in Utrecht, the Netherlands on 7-9 July 1999. The goal of the workshop was to understand the state of the network layer and its impact on continued growth and usage of the Internet.Different technical scenarios for the (foreseeable) future and the impact of external influences were studied. This report lists the conclusions and recommendations to the Internet Engineering TaskForce (IETF) community. |
|
| |
| RFC 2957 | The application/whoispp-query Content-Type |
| |
| Authors: | L. Daigle, P. Faltstrom. |
| Date: | October 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2957 |
|
This document defines the expression of Whois++ protocol (RFC 1835) queries within MIME (Multipurpose Internet Mail Extensions) (RFC2046) media types. The intention of this document, in conjunction with RFC 2958 is to enable MIME-enabled mail software, and other systems using Internet media types, to carry out Whois++ transactions. |
|
| |
| RFC 2958 | The application/whoispp-response Content-type |
| |
| Authors: | L. Daigle, P. Faltstrom. |
| Date: | October 2000 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2958 |
|
This document defines the expression of Whois++ protocol (RFC1835) responses within MIME (Multipurpose Internet Mail Extensions)(RFC2046) media types. The intention of this document, in conjunction with RFC 2957 is to enable MIME-enabled mail software, and other systems using Internet media types, to carry out Whois++ transactions. |
|
| |
| RFC 2962 | An SNMP Application Level Gateway for Payload Address Translation |
| |
| Authors: | D. Raz, J. Schoenwaelder, B. Sugla. |
| Date: | October 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2962 |
|
This document describes the ALG (Application Level Gateway) for theSNMP (Simple Network Management Protocol) by which IP (InternetProtocol) addresses in the payload of SNMP packets are statically mapped from one group to another. The SNMP ALG is a specific case of an Application Level Gateway as described in [15].
An SNMP ALG allows network management stations to manage multiple networks that use conflicting IP addresses. This can be important in environments where there is a need to use SNMP with NAT (NetworkAddress Translator) in order to manage several potentially overlapping addressing realms.
This document includes a detailed description of the requirements and limitations for an implementation of an SNMP Application LevelGateway. It also discusses other approaches to exchange SNMP packets across conflicting addressing realms. |
|
| |
| RFC 2963 | A Rate Adaptive Shaper for Differentiated Services |
| |
| Authors: | O. Bonaventure, S. De Cnodder. |
| Date: | October 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2963 |
|
This memo describes several Rate Adaptive Shapers (RAS) that can be used in combination with the single rate Three Color Markers (srTCM) and the two rate Three Color Marker (trTCM) described in RFC2697 andRFC2698, respectively. These RAS improve the performance of TCP when a TCM is used at the ingress of a diffserv network by reducing the burstiness of the traffic. With TCP traffic, this reduction of the burstiness is accompanied by a reduction of the number of marked packets and by an improved TCP goodput. The proposed RAS can be used at the ingress of Diffserv networks providing the Assured ForwardingPer Hop Behavior (AF PHB). They are especially useful when a TCM is used to mark traffic composed of a small number of TCP connections. |
|
| |
| RFC 2966 | Domain-wide Prefix Distribution with Two-Level IS-IS |
| |
| Authors: | T. Li, T. Przygienda, H. Smit. |
| Date: | October 2000 |
| Formats: | txt json html |
| Obsoleted by: | RFC 5302 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2966 |
|
This document describes extensions to the Intermediate System toIntermediate System (IS-IS) protocol to support optimal routing within a two-level domain. The IS-IS protocol is specified in ISO10589, with extensions for supporting IPv4 (Internet Protocol) specified in RFC 1195 [2].
This document extends the semantics presented in RFC 1195 so that a routing domain running with both level 1 and level 2 IntermediateSystems (IS) [routers] can distribute IP prefixes between level 1 and level 2 and vice versa. This distribution requires certain restrictions to insure that persistent forwarding loops do not form.The goal of this domain-wide prefix distribution is to increase the granularity of the routing information within the domain. |
|
| |
| RFC 2967 | TISDAG - Technical Infrastructure for Swedish Directory Access Gateways |
| |
| Authors: | L. Daigle, R. Hedberg. |
| Date: | October 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2967 |
|
The strength of the TISDAG (Technical Infrastructure for SwedishDirectory Access Gateways) project's DAG proposal is that it defines the necessary technical infrastructure to provide a single-access- point service for information on Swedish Internet users. The resulting service will provide uniform access for all information -- the same level of access to information (7x24 service), and the same information made available, irrespective of the service provider responsible for maintaining that information, their directory service protocols, or the end-user's client access protocol. |
|
| |
| RFC 2968 | Mesh of Multiple DAG servers - Results from TISDAG |
| |
| Authors: | L. Daigle, T. Eklof. |
| Date: | October 2000 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2968 |
|
The Common Indexing Protocol ([CIP1]) is designed to facilitate the creation not only of query referral indexes, but also of meshes of(loosely) affiliated referral indexes. The purpose of such a mesh of servers is to implement some kind of distributed sharing of indexing and/or searching tasks across different servers. So far, the TISDAG(Technical Infrastructure for Swedish Directory Access Gateways) project ([TISDAG], [DAGEXP]) has focused on creating a single referral index; the obvious next step is to integrate that into a larger set of interoperating services. |
|
| |
| RFC 2969 | Wide Area Directory Deployment - Experiences from TISDAG |
| |
| Authors: | T. Eklof, L. Daigle. |
| Date: | October 2000 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2969 |
|
The TISDAG (Technical Infrastructure for Swedish Directory AccessGateway) project provided valuable insight into the current reality of deploying a wide-scale directory service. This document catalogues some of the experiences gained in developing the necessary infrastructure for a national (i.e., multi-organizational) directory service and pilot deployment of the service in an environment with off-the-shelf directory service products. A perspective on the project's relationship to other directory deployment projects is provided, along with some proposals for future extensions of the work(larger scale deployment, other application areas).
These are our own observations, based on work done and general project discussions. No doubt, other project participants have their own list of project experiences; we don't claim this document is exhaustive! |
|
| |
| RFC 2970 | Architecture for Integrated Directory Services - Result from TISDAG |
| |
| Authors: | L. Daigle, T. Eklof. |
| Date: | October 2000 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2970 |
|
A single, unified, global whitepages directory service remains elusive. Nonetheless, there is increasing call for participation of widely-dispersed directory servers (i.e., across multiple organizations) in large-scale directory services. These services range from national whitepages services, to multi-national indexes ofWWW resources, and beyond. Drawing from experiences with the TISDAG(Technical Infrastructure for Swedish Directory Access Gateways)([TISDAG]) project, this document outlines an approach to providing the necessary infrastructure for integrating such widely-scattered servers into a single service, rather than attempting to mandate a single protocol and schema set for all participating servers to use. |
|
| |
| RFC 2972 | Context and Goals for Common Name Resolution |
| |
| Authors: | N. Popp, M. Mealling, L. Masinter, K. Sollins. |
| Date: | October 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2972 |
|
This document establishes the context and goals for a Common NameResolution Protocol. It defines the terminology used concerning a"Common Name" and how one might be "resolved", and establishes the distinction between "resolution" and more elaborate search mechanisms. It establishes some expected contexts for use of CommonName Resolution, and the criteria for evaluating a successful protocol. It also analyzes the various motivations that would cause services to provide Common Name resolution for both public, private and commercial use.
This document is intended as input to the formation of a Common NameResolution Protocol working group. Please send any comments to cnrp-ietf@lists.internic.net. To review the mail archives, see<http://lists.internic.net/archives/cnrp-ietf.html&rt; |
|
| |
| RFC 2973 | IS-IS Mesh Groups |
| |
| Authors: | R. Balay, D. Katz, J. Parker. |
| Date: | October 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2973 |
|
This document describes a mechanism to reduce redundant packet transmissions for the Intermediate System to Intermediate System(IS-IS) Routing protocol, as described in ISO 10589. The described mechanism can be used to reduce the flooding of Link State PDUs(Protocol Data Units) (LSPs) in IS-IS topologies. The net effect is to engineer a flooding topology for LSPs which is a subset of the physical topology. This document serves to document the existing behavior in deployed implementations.
The document describes behaviors that are backwards compatible with implementations that do not support this feature. |
|
| |
| RFC 2975 | Introduction to Accounting Management |
| |
| Authors: | B. Aboba, J. Arkko, D. Harrington. |
| Date: | October 2000 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2975 |
|
The field of Accounting Management is concerned with the collection of resource consumption data for the purposes of capacity and trend analysis, cost allocation, auditing, and billing. This document describes each of these problems, and discusses the issues involved in design of modern accounting systems.
Since accounting applications do not have uniform security and reliability requirements, it is not possible to devise a single accounting protocol and set of security services that will meet all needs. Thus the goal of accounting management is to provide a set of tools that can be used to meet the requirements of each application.This document describes the currently available tools as well as the state of the art in accounting protocol design. A companion document, RFC 2924, reviews the state of the art in accounting attributes and record formats. |
|
| |
| RFC 2977 | Mobile IP Authentication, Authorization, and Accounting Requirements |
| |
| Authors: | S. Glass, T. Hiller, S. Jacobs, C. Perkins. |
| Date: | October 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2977 |
|
The Mobile IP and Authentication, Authorization, Accounting (AAA) working groups are currently looking at defining the requirements forAuthentication, Authorization, and Accounting. This document contains the requirements which would have to be supported by a AAA service to aid in providing Mobile IP services. |
|
| |
| RFC 2979 | Behavior of and Requirements for Internet Firewalls |
| |
| Authors: | N. Freed. |
| Date: | October 2000 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2979 |
|
This memo defines behavioral characteristics of and interoperability requirements for Internet firewalls. While most of these things may seem obvious, current firewall behavior is often either unspecified or underspecified and this lack of specificity often causes problems in practice. This requirement is intended to be a necessary first step in making the behavior of firewalls more consistent across implementations and in line with accepted IP protocol practices. |
|
| |
| RFC 2980 | Common NNTP Extensions |
| |
|
|
In this document, a number of popular extensions to the Network NewsTransfer Protocol (NNTP) protocol defined in RFC 977 are documented and discussed. While this document is not intended to serve as a standard of any kind, it will hopefully serve as a reference document for future implementers of the NNTP protocol. In the role, this document would hopefully create the possibility for some level of interoperability among implementations that make use of extensions. |
|
| |
| RFC 2983 | Differentiated Services and Tunnels |
| |
| Authors: | D. Black. |
| Date: | October 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2983 |
|
This document considers the interaction of Differentiated Services(diffserv) (RFC 2474, RFC 2475) with IP tunnels of various forms.The discussion of tunnels in the diffserv architecture (RFC 2475) provides insufficient guidance to tunnel designers and implementers.This document describes two conceptual models for the interaction of diffserv with Internet Protocol (IP) tunnels and employs them to explore the resulting configurations and combinations of functionality. An important consideration is how and where it is appropriate to perform diffserv traffic conditioning in the presence of tunnel encapsulation and decapsulation. A few simple mechanisms are also proposed that limit the complexity that tunnels would otherwise add to the diffserv traffic conditioning model. Security considerations for IPSec tunnels limit the possible functionality in some circumstances. |
|
| |
| RFC 2985 | PKCS #9: Selected Object Classes and Attribute Types Version 2.0 |
| |
| Authors: | M. Nystrom, B. Kaliski. |
| Date: | November 2000 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2985 |
|
This memo represents a republication of PKCS #9 v2.0 from RSALaboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document, except for the security considerations section, is taken directly from that specification.
This memo provides a selection of object classes and attribute types for use in conjunction with public-key cryptography and LightweightDirectory Access Protocol (LDAP) accessible directories. It also includes ASN.1 syntax for all constructs. |
|
| |
| RFC 2986 | PKCS #10: Certification Request Syntax Specification Version 1.7 |
| |
|
|
This memo represents a republication of PKCS #10 v1.7 from RSALaboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document, except for the security considerations section, is taken directly from the PKCS #9 v2.0 or the PKCS #10 v1.7 document.
This memo describes a syntax for certification requests. |
|
| |
| RFC 2989 | Criteria for Evaluating AAA Protocols for Network Access |
| |
| Authors: | B. Aboba, P. Calhoun, S. Glass, T. Hiller, P. McCann, H. Shiino, P. Walsh, G. Zorn, G. Dommety, C. Perkins, B. Patil, D. Mitton, S. Manning, M. Beadles, X. Chen, S. Sivalingham, A. Hameed, M. Munson, S. Jacobs, B. Lim, B. Hirschman, R. Hsu, H. Koo, M. Lipford, E. Campbell, Y. Xu, S. Baba, E. Jaques. |
| Date: | November 2000 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2989 |
|
This document represents a summary of Authentication, Authorization,Accounting (AAA) protocol requirements for network access. In creating this document, inputs were taken from documents produced by the Network Access Server Requirements Next Generation (NASREQ),Roaming Operations (ROAMOPS), and MOBILEIP working groups, as well as from TIA 45.6.
This document summarizes the requirements collected from those sources, separating requirements for authentication, authorization and accounting. Details on the requirements are available in the original documents. |
|
| |
| RFC 2990 | Next Steps for the IP QoS Architecture |
| |
| Authors: | G. Huston. |
| Date: | November 2000 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2990 |
|
While there has been significant progress in the definition ofQuality of Service (QoS) architectures for internet networks, there are a number of aspects of QoS that appear to need further elaboration as they relate to translating a set of tools into a coherent platform for end-to-end service delivery. This document highlights the outstanding architectural issues relating to the deployment and use of QoS mechanisms within internet networks, noting those areas where further standards work may assist with the deployment of QoS internets.
This document is the outcome of a collaborative exercise on the part of the Internet Architecture Board. |
|
| |
| RFC 2991 | Multipath Issues in Unicast and Multicast Next-Hop Selection |
| |
| Authors: | D. Thaler, C. Hopps. |
| Date: | November 2000 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2991 |
|
Various routing protocols, including Open Shortest Path First (OSPF) and Intermediate System to Intermediate System (ISIS), explicitly allow "Equal-Cost Multipath" (ECMP) routing. Some router implementations also allow equal-cost multipath usage with RIP and other routing protocols. The effect of multipath routing on a forwarder is that the forwarder potentially has several next-hops for any given destination and must use some method to choose which next- hop should be used for a given data packet. |
|
| |
| RFC 2992 | Analysis of an Equal-Cost Multi-Path Algorithm |
| |
| Authors: | C. Hopps. |
| Date: | November 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2992 |
|
Equal-cost multi-path (ECMP) is a routing technique for routing packets along multiple paths of equal cost. The forwarding engine identifies paths by next-hop. When forwarding a packet the router must decide which next-hop (path) to use. This document gives an analysis of one method for making that decision. The analysis includes the performance of the algorithm and the disruption caused by changes to the set of next-hops. |
|
| |
| RFC 2993 | Architectural Implications of NAT |
| |
| Authors: | T. Hain. |
| Date: | November 2000 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2993 |
|
In light of the growing interest in, and deployment of network address translation (NAT) RFC-1631, this paper will discuss some of the architectural implications and guidelines for implementations. It is assumed the reader is familiar with the address translation concepts presented in RFC-1631. |
|
| |
| RFC 2994 | A Description of the MISTY1 Encryption Algorithm |
| |
| Authors: | H. Ohta, M. Matsui. |
| Date: | November 2000 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2994 |
|
This document describes a secret-key cryptosystem MISTY1, which is block cipher with a 128-bit key, a 64-bit block and a variable number of rounds. It documents the algorithm description including key scheduling part and data randomizing part. |
|
| |
| RFC 2995 | Pre-Spirits Implementations of PSTN-initiated Services |
| |
| Authors: | H. Lu, Ed., I. Faynberg, J. Voelker, M. Weissman, W. Zhang, S. Rhim, J. Hwang, S. Ago, S. Moeenuddin, S. Hadvani, S. Nyckelgard, J. Yoakum, L. Robart. |
| Date: | November 2000 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2995 |
|
This document contains information relevant to the work underway inThe Services in the PSTN/IN Requesting InTernet Services (SPIRITS)Working Group. It describes four existing implementations ofSPIRITS-like services from Korea Telecom, Lucent Technologies, NEC, and Telia in cooperation with Nortel Networks. SPIRITS-like services are those originating in the Public Switched Telephone Network (PSTN) and necessitating the interactions of the Internet and PSTN.
Surveying the implementations, we can make the following observations: o The ICW service plays the role of a benchmark service. All four implementations can support ICW, with three specifically designed for it. o Session Initiation Protocol (SIP) is used in most of the implementations as the base communications protocol between thePSTN and Internet. (NEC's implementation is the only exception that uses a proprietary protocol. Nevertheless, NEC has a plan to support SIP together with the extensions for SPIRITS services.) o All implementations use IN-based solutions for the PSTN part.
It is clear that not all pre-SPIRITS implementations inter-operate with each other. It is also clear that not all SIP-based implementations inter-operate with each other given that they do not support the same version of SIP. It is a task of the SPIRITS WorkingGroup to define the inter-networking interfaces that will support interoperation of the future implementations of SPIRITS services. |
|
| |
| RFC 2998 | A Framework for Integrated Services Operation over Diffserv Networks |
| |
| Authors: | Y. Bernet, P. Ford, R. Yavatkar, F. Baker, L. Zhang, M. Speer, R. Braden, B. Davie, J. Wroclawski, E. Felstaine. |
| Date: | November 2000 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2998 |
|
The Integrated Services (Intserv) architecture provides a means for the delivery of end-to-end Quality of Service (QoS) to applications over heterogeneous networks. To support this end-to-end model, theIntserv architecture must be supported over a wide variety of different types of network elements. In this context, a network that supports Differentiated Services (Diffserv) may be viewed as a network element in the total end-to-end path. This document describes a framework by which Integrated Services may be supported over Diffserv networks. |
|
| |
| RFC 2999 | Request for Comments Summary RFC Numbers 2900-2999 |
| |
| Authors: | S. Ginoza. |
| Date: | August 2001 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 2999 |
|
|
|
| |
| RFC 3001 | A URN Namespace of Object Identifiers |
| |
|
|
This document describes a Uniform Resource Names (URN) namespace that contains Object Identifiers (OIDs). |
|
| |
| RFC 3002 | Overview of 2000 IAB Wireless Internetworking Workshop |
| |
| Authors: | D. Mitzel. |
| Date: | December 2000 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3002 |
|
This document provides an overview of a workshop held by the InternetArchitecture Board (IAB) on wireless internetworking. The workshop was hosted by Nokia in Mountain View, CA, USA on February 29 thruMarch 2, 2000. The goal of the workshop was to assess current and future uses of Internet technology in wireless environments, to make recommendations on research and standardization tasks to improve acceptance of Internet network and transport protocols in wireless environments, and to evaluate methods to improve communication and collaboration among Internet standards working groups and those of the telephony and wireless sectors. This report summarizes the conclusions and recommendations of the IAB on behalf of the IETF community.
Comments should be submitted to the IAB-Wireless-Workshop@ietf.org mailing list. |
|
| |
| RFC 3022 | Traditional IP Network Address Translator (Traditional NAT) |
| |
| Authors: | P. Srisuresh, K. Egevang. |
| Date: | January 2001 |
| Formats: | txt html json |
| Obsoletes: | RFC 1631 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3022 |
|
Basic Network Address Translation or Basic NAT is a method by whichIP addresses are mapped from one group to another, transparent to end users. Network Address Port Translation, or NAPT is a method by which many network addresses and their TCP/UDP (Transmission ControlProtocol/User Datagram Protocol) ports are translated into a single network address and its TCP/UDP ports. Together, these two operations, referred to as traditional NAT, provide a mechanism to connect a realm with private addresses to an external realm with globally unique registered addresses. |
|
| |
| RFC 3026 | Liaison to IETF/ISOC on ENUM |
| |
| Authors: | R. Blane. |
| Date: | January 2001 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3026 |
|
Working Party 1/2, of the International Telecommunication UnionTelecommunication Standardization Sector (ITU-T) held a meeting of its collaborators in Berlin Germany 19-26 October 2000. The agenda of the meeting contained several contributions regarding RFC 2916:"E.164 Number and DNS" from the Internet Engineering Task Force's(IETF) ENUM Working Group - more specifically, the method for administering and maintaining the E.164-based resources in the DomainName System (DNS) as related to the ENUM protocol. Consequently, in addition to the WP1/2 collaborators, there were several members of the IETF present to assist with the discussion of issues contained in the aforementioned contributions.
This liaison from WP1/2 to the IETF/ISOC conveys the understandings of the WP1/2 collaborators resulting from the discussions. |
|
| |
| RFC 3027 | Protocol Complications with the IP Network Address Translator |
| |
| Authors: | M. Holdrege, P. Srisuresh. |
| Date: | January 2001 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3027 |
|
Many internet applications can be adversely affected when end nodes are not in the same address realm and seek the assistance of an IPNetwork Address Translator (NAT) enroute to bridge the realms. TheNAT device alone cannot provide the necessary application/protocol transparency in all cases and seeks the assistance of ApplicationLevel Gateways (ALGs) where possible, to provide transparency. The purpose of this document is to identify the protocols and applications that break with NAT enroute. The document also attempts to identify any known workarounds. It is not possible to capture all applications that break with NAT in a single document. This document attempts to capture as much information as possible, but is by no means a comprehensive coverage. We hope the coverage provides sufficient clues for applications not covered. |
|
| |
| RFC 3037 | LDP Applicability |
| |
| Authors: | B. Thomas, E. Gray. |
| Date: | January 2001 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3037 |
|
Multiprotocol Label Switching (MPLS) is a method for forwarding packets that uses short, fixed-length values carried by packets, called labels, to determine packet nexthops. A fundamental concept in MPLS is that two Label Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using a set of procedures, called a label distribution protocol, by which one LSR informs another of label bindings it has made. This document describes the applicability of a set of such procedures called LDP(for Label Distribution Protocol) by which LSRs distribute labels to support MPLS forwarding along normally routed paths. |
|
| |
| RFC 3040 | Internet Web Replication and Caching Taxonomy |
| |
| Authors: | I. Cooper, I. Melve, G. Tomlinson. |
| Date: | January 2001 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3040 |
|
This memo specifies standard terminology and the taxonomy of web replication and caching infrastructure as deployed today. It introduces standard concepts, and protocols used today within this application domain. Currently deployed solutions employing these technologies are presented to establish a standard taxonomy. Known problems with caching proxies are covered in the document titled"Known HTTP Proxy/Caching Problems", and are not part of this document. This document presents open protocols and points to published material for each protocol. |
|
| |
| RFC 3043 | The Network Solutions Personal Internet Name (PIN): A URN Namespace for People and Organizations |
| |
| Authors: | M. Mealling. |
| Date: | January 2001 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3043 |
|
This document describes a Uniform Resource Name (URN) namespace that is engineered by Network Solutions, Inc. for naming people and organizations. |
|
| |
| RFC 3045 | Storing Vendor Information in the LDAP root DSE |
| |
| Authors: | M. Meredith. |
| Date: | January 2001 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3045 |
|
This document specifies two Lightweight Directory Access Protocol(LDAP) attributes, vendorName and vendorVersion that MAY be included in the root DSA-specific Entry (DSE) to advertise vendor-specific information. These two attributes supplement the attributes defined in section 3.4 of RFC 2251.
The information held in these attributes MAY be used for display and informational purposes and MUST NOT be used for feature advertisement or discovery. |
|
| |
| RFC 3048 | Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer |
| |
| Authors: | B. Whetten, L. Vicisano, R. Kermode, M. Handley, S. Floyd, M. Luby. |
| Date: | January 2001 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3048 |
|
This document describes a framework for the standardization of bulk- data reliable multicast transport. It builds upon the experience gained during the deployment of several classes of contemporary reliable multicast transport, and attempts to pull out the commonalities between these classes of protocols into a number of building blocks. To that end, this document recommends that certain components that are common to multiple protocol classes be standardized as "building blocks". The remaining parts of the protocols, consisting of highly protocol specific, tightly intertwined functions, shall be designated as "protocol cores".Thus, each protocol can then be constructed by merging a "protocol core" with a number of "building blocks" which can be re-used across multiple protocols. |
|
| |
| RFC 3050 | Common Gateway Interface for SIP |
| |
| Authors: | J. Lennox, H. Schulzrinne, J. Rosenberg. |
| Date: | January 2001 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3050 |
|
In Internet telephony, there must be a means by which new services are created and deployed rapidly. In the World Wide Web, the CommonGateway Interface (CGI) has served as popular means towards programming web services. Due to the similarities between theSession Initiation Protocol (SIP) and the Hyper Text TransferProtocol (HTTP), CGI is a good candidate for service creation in aSIP environment. This document defines a SIP CGI interface for providing SIP services on a SIP server. |
|
| |
| RFC 3051 | IP Payload Compression Using ITU-T V.44 Packet Method |
| |
| Authors: | J. Heath, J. Border. |
| Date: | January 2001 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3051 |
|
This document describes a compression method based on the data compression algorithm described in International TelecommunicationUnion (ITU-T) Recommendation V.44. Recommendation V.44 is a modem standard but Annex B, Clause B.1, of the recommendation describes the implementation of V.44 in packet networks (e.g., V.44 Packet Method).This document defines the application of V.44 Packet Method to theInternet Protocol (IP) Payload Compression Protocol (RFC 2393). RFC2393 defines a method for applying lossless compression to the payload portion of IP datagrams.
V.44 Packet Method is based upon the LZJH data compression algorithm.Throughout the remainder of this document the terms V.44 PacketMethod and LZJH are synonymous. |
|
| |
| RFC 3052 | Service Management Architectures Issues and Review |
| |
| Authors: | M. Eder, S. Nag. |
| Date: | January 2001 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3052 |
|
Many of the support functions necessary to exploit the mechanisms by which differing levels of service can be provided are limited in scope and a complete framework is non-existent. Various efforts at such a framework have received a great deal of attention and represent a historical shift in scope for many of the organizations looking to address this problem. The purpose of this document is to explore the problems of defining a Service management framework and to examine some of the issues that still need to be resolved. |
|
| |
| RFC 3053 | IPv6 Tunnel Broker |
| |
| Authors: | A. Durand, P. Fasano, I. Guardini, D. Lento. |
| Date: | January 2001 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3053 |
|
The IPv6 global Internet as of today uses a lot of tunnels over the existing IPv4 infrastructure. Those tunnels are difficult to configure and maintain in a large scale environment. The 6bone has proven that large sites and Internet Service Providers (ISPs) can do it, but this process is too complex for the isolated end user who already has an IPv4 connection and would like to enter the IPv6 world. The motivation for the development of the tunnel broker model is to help early IPv6 adopters to hook up to an existing IPv6 network(e.g., the 6bone) and to get stable, permanent IPv6 addresses and DNS names. The concept of the tunnel broker was first presented atOrlando's IETF in December 1998. Two implementations were demonstrated during the Grenoble IPng & NGtrans interim meeting inFebruary 1999. |
|
| |
| RFC 3054 | Megaco IP Phone Media Gateway Application Profile |
| |
| Authors: | P. Blatherwick, R. Bell, P. Holland. |
| Date: | January 2001 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3054 |
|
This document specifies a particular application of the Megaco/H.248Protocol for control of Internet telephones and similar appliances: the Megaco IP Phone Media Gateway. The telephone itself is a MediaGateway (MG), controlled by the Megaco/H.248 Protocol, with application control intelligence located in the Media GatewayController (MGC). To achieve a high degree of interoperability and design efficiency in such end-user devices, a consistent architectural approach, a particular organization of Terminations andPackages, and a Protocol Profile are described. The approach makes use of existing Protocol features and user interface relatedPackages, and is thus a straight-forward application of theMegaco/H.248 Protocol. |
|
| |
| RFC 3058 | Use of the IDEA Encryption Algorithm in CMS |
| |
| Authors: | S. Teiwes, P. Hartmann, D. Kuenzi. |
| Date: | February 2001 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3058 |
|
This memo specifies how to incorporate International Data EncryptionAlgorithm (IDEA) into CMS or S/MIME as an additional strong algorithm for symmetric encryption. For organizations who make use of IDEA for data security purposes it is of high interest that IDEA is also available in S/MIME. The intention of this memo is to provide theOIDs and algorithms required that IDEA can be included in S/MIME for symmetric content and key encryption. |
|
| |
| RFC 3061 | A URN Namespace of Object Identifiers |
| |
|
|
This document describes a Uniform Resource Name (URN) namespace that contains Object Identifiers (OIDs). It obsoletes RFC 3001. |
|
| |
| RFC 3064 | MGCP CAS Packages |
| |
| Authors: | B. Foster. |
| Date: | February 2001 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3064 |
|
This document contains a collection of media gateway ChannelAssociated Signaling (CAS) packages for R1 CAS, North American CAS,CAS PBX interconnect as well as basic FXO support. Included are six packages. The "MS" package covers MF single stage dialing trunks.This includes wink start and immediate start PBX DID/DOD trunks as well as basic R1 and Feature Group D (FGD) Terminating protocol [3].The "DT "package covers immediate start and basic DTMF and dial-pulse trunks and the "BL" package covers the interface to a basic PBX(digital or FXS interface). In addition to the Terminating protocol, there are three other FGD protocols described in [3]. These includeEAIN and EANA which is covered by the enclosed "MD" package and theOperator Service Signaling protocol which is handled by the "MO" package. Support for basic FXO interconnect is provided by "DO" package. |
|
| |
| RFC 3067 | TERENA'S Incident Object Description and Exchange Format Requirements |
| |
| Authors: | J. Arvidsson, A. Cormack, Y. Demchenko, J. Meijer. |
| Date: | February 2001 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3067 |
|
The purpose of the Incident Object Description and Exchange Format is to define a common data format for the description, archiving and exchange of information about incidents between CSIRTs (ComputerSecurity Incident Response Teams) (including alert, incident in investigation, archiving, statistics, reporting, etc.). This document describes the high-level requirements for such a description and exchange format, including the reasons for those requirements.Examples are used to illustrate the requirements where necessary. |
|
| |
| RFC 3069 | VLAN Aggregation for Efficient IP Address Allocation |
| |
| Authors: | D. McPherson, B. Dykes. |
| Date: | February 2001 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3069 |
|
This document introduces the concept of Virtual Local Area Network(VLAN) aggregation as it relates to IPv4 address allocation. A mechanism is described by which hosts that reside in the same physical switched infrastructure, but separate virtual broadcast domains, are addressed from the same IPv4 subnet and share a common default gateway IP address, thereby removing the requirement of a dedicated IP subnet for each virtual Local Area Network (LAN) orMetropolitan Area Network (MAN).
Employing such a mechanism significantly decreases IPv4 address consumption in virtual LANs and MANs. It may also ease administration of IPv4 addresses within the network. |
|
| |
| RFC 3071 | Reflections on the DNS, RFC 1591, and Categories of Domains |
| |
| Authors: | J. Klensin. |
| Date: | February 2001 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3071 |
|
RFC 1591, "Domain Name System Structure and Delegation", laid out the basic administrative design and principles for the allocation and administration of domains, from the top level down. It was written before the introduction of the world wide web (WWW) and rapid growth of the Internet put significant market, social, and political pressure on domain name allocations. In recent years, 1591 has been cited by all sides in various debates, and attempts have been made by various bodies to update it or adjust its provisions, sometimes under pressures that have arguably produced policies that are less well thought out than the original. Some of those efforts have begun from misconceptions about the provisions of 1591 or the motivation for those provisions. The current directions of the Internet Corporation for Assigned Names and Numbers (ICANN) and other groups who now determine the Domain Name System (DNS) policy directions appear to be drifting away from the policies and philosophy of 1591. This document is being published primarily for historical context and comparative purposes, essentially to document some thoughts about how1591 might have been interpreted and adjusted by the InternetAssigned Numbers Authority (IANA) and ICANN to better reflect today's world while retaining characteristics and policies that have proven to be effective in supporting Internet growth and stability. An earlier variation of this memo was submitted to ICANN as a comment on its evolving Top-level Domain (TLD) policies. |
|
| |
| RFC 3072 | Structured Data Exchange Format (SDXF) |
| |
| Authors: | M. Wildgrube. |
| Date: | March 2001 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3072 |
|
This specification describes an all-purpose interchange format for use as a file format or for net-working. Data is organized in chunks which can be ordered in hierarchical structures. This format is self-describing and CPU-independent. |
|
| |
| RFC 3073 | Portable Font Resource (PFR) - application/font-tdpfr MIME Sub-type Registration |
| |
| Authors: | J. Collins. |
| Date: | March 2001 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3073 |
|
This document describes the registration of the Multipurpose InternetMail Extensions (MIME) sub-type application/font-tdpfr. The encoding is defined by the PFR Specification.
A Portable Font Resource (PFR) contains a set of glyph shapes. Each glyph shape is associated with a character code. The PFR format is designed to be both compact and platform-independent. It is intended to facilitate accurate rendering of fonts in all environments whether or not they have the required fonts already installed. |
|
| |
| RFC 3076 | Canonical XML Version 1.0 |
| |
| Authors: | J. Boyer. |
| Date: | March 2001 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3076 |
|
Any XML (Extensible Markup Language) document is part of a set of XML documents that are logically equivalent within an application context, but which vary in physical representation based on syntactic changes permitted by XML 1.0 and Namespaces in XML. This specification describes a method for generating a physical representation, the canonical form, of an XML document that accounts for the permissible changes. Except for limitations regarding a few unusual cases, if two documents have the same canonical form, then the two documents are logically equivalent within the given application context. Note that two documents may have differing canonical forms yet still be equivalent in a given context based on application-specific equivalence rules for which no generalized XML specification could account. |
|
| |
| RFC 3078 | Microsoft Point-To-Point Encryption (MPPE) Protocol |
| |
| Authors: | G. Pall, G. Zorn. |
| Date: | March 2001 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3078 |
|
The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links.
The PPP Compression Control Protocol provides a method to negotiate and utilize compression protocols over PPP encapsulated links.
This document describes the use of the Microsoft Point to PointEncryption (MPPE) to enhance the confidentiality of PPP-encapsulated packets. |
|
| |
| RFC 3079 | Deriving Keys for use with Microsoft Point-to-Point Encryption (MPPE) |
| |
| Authors: | G. Zorn. |
| Date: | March 2001 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3079 |
|
The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links.
The PPP Compression Control Protocol provides a method to negotiate and utilize compression protocols over PPP encapsulated links.
Microsoft Point to Point Encryption (MPPE) is a means of representingPPP packets in an encrypted form. MPPE uses the RSA RC4 algorithm to provide data confidentiality. The length of the session key to be used for initializing encryption tables can be negotiated. MPPE currently supports 40-bit, 56-bit and 128-bit session keys. MPPE session keys are changed frequently; the exact frequency depends upon the options negotiated, but may be every packet. MPPE is negotiated within option 18 in the Compression Control Protocol.
This document describes the method used to derive initial MPPE session keys from a variety of credential types. It is expected that this memo will be updated whenever Microsoft defines a new key derivation method for MPPE, since its primary purpose is to provide an open, easily accessible reference for third-parties wishing to interoperate with Microsoft products.
MPPE itself (including the protocol used to negotiate its use, the details of the encryption method used and the algorithm used to change session keys during a session) is described in RFC 3078. |
|
| |
| RFC 3083 | Baseline Privacy Interface Management Information Base for DOCSIS Compliant Cable Modems and Cable Modem Termination Systems |
| |
|
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it defines a basic set of managed objects for SNMP- based (Simple Network Management Protocol) management of the BaselinePrivacy Interface (BPI), which provides data privacy for DOCSIS 1.0(Data-Over-Cable Service Interface Specifications) compliant CableModems and Cable Modem Termination Systems. This MIB is defined as an extension to the DOCSIS Radio Frequency Interface MIB, RFC 2670.
This memo specifies a MIB module in a manner that is compliant to theSMIv2 (Structure of Management Information Version 2). The set of objects is consistent with the SNMP framework and existing SNMP standards.
CableLabs requires the implementation of this MIB in DOCSIS 1.0 cable modems that implement the Baseline Privacy Interface, as a prerequisite for DOCSIS 1.0 certification. |
|
| |
| RFC 3085 | URN Namespace for NewsML Resources |
| |
| Authors: | A. Coates, D. Allen, D. Rivers-Moore. |
| Date: | March 2001 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3085 |
|
This document describes a URN (Uniform Resource Name) namespace for identifying NewsML NewsItems. A NewsItem is an information resource that is expressible as a NewsML element within a NewsML document conforming to the NewsML Document Type Declaration (DTD) as defined by the International Press Telecommunications Council (IPTC). |
|
| |
| RFC 3086 | Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification |
| |
| Authors: | K. Nichols, B. Carpenter. |
| Date: | April 2001 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3086 |
|
The differentiated services framework enables quality-of-service provisioning within a network domain by applying rules at the edges to create traffic aggregates and coupling each of these with a specific forwarding path treatment in the domain through use of a codepoint in the IP header. The diffserv WG has defined the general architecture for differentiated services and has focused on the forwarding path behavior required in routers, known as "per-hop forwarding behaviors" (or PHBs). The WG has also discussed functionality required at diffserv (DS) domain edges to select(classifiers) and condition (e.g., policing and shaping) traffic according to the rules. Short-term changes in the QoS goals for a DS domain are implemented by changing only the configuration of these edge behaviors without necessarily reconfiguring the behavior of interior network nodes.
The next step is to formulate examples of how forwarding path components (PHBs, classifiers, and traffic conditioners) can be used to compose traffic aggregates whose packets experience specific forwarding characteristics as they transit a differentiated services domain. The WG has decided to use the term per-domain behavior, orPDB, to describe the behavior experienced by a particular set of packets as they cross a DS domain. A PDB is characterized by specific metrics that quantify the treatment a set of packets with a particular DSCP (or set of DSCPs) will receive as it crosses a DS domain. A PDB specifies a forwarding path treatment for a traffic aggregate and, due to the role that particular choices of edge and
PHB configuration play in its resulting attributes, it is where the forwarding path and the control plane interact. The measurable parameters of a PDB should be suitable for use in Service LevelSpecifications at the network edge.
This document defines and discusses Per-Domain Behaviors in detail and lays out the format and required content for contributions to theDiffserv WG on PDBs and the procedure that will be applied for individual PDB specifications to advance as WG products. This format is specified to expedite working group review of PDB submissions. |
|
| |
| RFC 3087 | Control of Service Context using SIP Request-URI |
| |
| Authors: | B. Campbell, R. Sparks. |
| Date: | April 2001 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3087 |
|
This memo provides information for the Internet community. It describes a useful way to conceptualize the use of the standard SIP(Session Initiation Protocol) Request-URI (Uniform ResourceIdentifier) that the authors and many members of the SIP community think is suitable as a convention. It does not define any new protocol with respect to RFC 2543.
In a conventional telephony environment, extended service applications often use call state information, such as calling party, called party, reason for forward, etc, to infer application context.In a SIP/2.0 call, much of this information may be either non- existent or unreliable. This document proposes a mechanism to communicate context information to an application. Under this proposal, a client or proxy can communicate context through the use of a distinctive Request-URI. This document continues with examples of how this mechanism could be used in a voice mail application. |
|
| |
| RFC 3089 | A SOCKS-based IPv6/IPv4 Gateway Mechanism |
| |
| Authors: | H. Kitamura. |
| Date: | April 2001 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3089 |
|
This document describes a SOCKS-based IPv6/IPv4 gateway mechanism that enables smooth heterogeneous communications between the IPv6 nodes and IPv4 nodes.
It is based on the SOCKS protocol [SOCKSv5]. By applying the SOCKS mechanism to the heterogeneous communications and relaying two"terminated" IPv4 and IPv6 connections at the "application layer"(the SOCKS server), the SOCKS-based IPv6/IPv4 gateway mechanism is accomplished.
Since it is accomplished without introducing new protocols, it provides the same communication environment that is provided by theSOCKS mechanism. The same appearance is provided to the heterogeneous communications. No conveniences or functionalities of current communications are sacrificed. |
|
| |
| RFC 3091 | Pi Digit Generation Protocol |
| |
| Authors: | H. Kennedy. |
| Date: | 1 April 2001 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3091 |
|
This memo defines a protocol to provide the Pi digit generation service (PIgen) used between clients and servers on host computers. |
|
| |
| RFC 3092 | Etymology of "Foo" |
| |
| Authors: | D. Eastlake 3rd, C. Manros, E. Raymond. |
| Date: | 1 April 2001 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3092 |
|
Approximately 212 RFCs so far, starting with RFC 269, contain the terms `foo', `bar', or `foobar' as metasyntactic variables without any proper explanation or definition. This document rectifies that deficiency. |
|
| |
| RFC 3093 | Firewall Enhancement Protocol (FEP) |
| |
| Authors: | M. Gaynor, S. Bradner. |
| Date: | 1 April 2001 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3093 |
|
Internet Transparency via the end-to-end architecture of the Internet has allowed vast innovation of new technologies and services [1].However, recent developments in Firewall technology have altered this model and have been shown to inhibit innovation. We propose theFirewall Enhancement Protocol (FEP) to allow innovation, without violating the security model of a Firewall. With no cooperation from a firewall operator, the FEP allows ANY application to traverse aFirewall. Our methodology is to layer any application layerTransmission Control Protocol/User Datagram Protocol (TCP/UDP) packets over the HyperText Transfer Protocol (HTTP) protocol, sinceHTTP packets are typically able to transit Firewalls. This scheme does not violate the actual security usefulness of a Firewall, sinceFirewalls are designed to thwart attacks from the outside and to ignore threats from within. The use of FEP is compatible with the current Firewall security model because it requires cooperation from a host inside the Firewall. FEP allows the best of both worlds: the security of a firewall, and transparent tunneling thought the firewall. |
|
| |
| RFC 3094 | Tekelec's Transport Adapter Layer Interface |
| |
| Authors: | D. Sprague, R. Benedyk, D. Brendes, J. Keller. |
| Date: | April 2001 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3094 |
|
This document proposes the interfaces of a Signaling Gateway, which provides interworking between the Switched Circuit Network (SCN) and an IP network. Since the Gateway is the central point of signaling information, not only does it provide transportation of signaling from one network to another, but it can also provide additional functions such as protocol translation, security screening, routing information, and seamless access to Intelligent Network (IN) services on both networks.
The Transport Adapter Layer Interface (TALI) is the proposed interface, which provides TCAP (Transaction Capability ApplicationPart), ISUP (ISDN User Part), and MTP (Mail Transport Protocol) messaging over TCP/IP. In addition, TALI provides SCCP (SignallingConnection Control Part) Management (SCMG), MTP Primitives, dynamic registration of circuits, and routing of call control messages based on circuit location. |
|
| |
| RFC 3096 | Requirements for robust IP/UDP/RTP header compression |
| |
| Authors: | M. Degermark, Ed.. |
| Date: | July 2001 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3096 |
|
This document contains requirements for robust IP/UDP/RTP (InternetProtocol/User Datagram Protocol/Real-Time Transport Protocol) header compression to be developed by the ROHC (Robust Header Compression)WG. It is based on the ROHC charter, discussions in the WG, the 3GPP document "3GPP TR 23.922", version 1.0.0 of October 1999, as well as contributions from 3G.IP. |
|
| |
| RFC 3098 | How to Advertise Responsibly Using E-Mail and Newsgroups or - how NOT to $$$$$ MAKE ENEMIES FAST! $$$$$ |
| |
| Authors: | T. Gavin, D. Eastlake 3rd, S. Hambridge. |
| Date: | April 2001 |
| Formats: | txt html json |
| Also: | FYI 0038 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3098 |
|
This memo offers useful suggestions for responsible advertising techniques that can be used via the internet in an environment where the advertiser, recipients, and the Internet Community can coexist in a productive and mutually respectful fashion. Some measure of clarity will also be added to the definitions, dangers, and details inherent to Internet Marketing. |
|
| |
| RFC 3099 | Request for Comments Summary RFC Numbers 3000-3099 |
| |
| Authors: | S. Ginoza. |
| Date: | November 2001 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3099 |
|
|
|
| |
| RFC 3106 | 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. |
|
| |
| RFC 3109 | Request to Move STD 39 to Historic Status |
| |
| Authors: | R. Braden, R. Bush, J. Klensin. |
| Date: | May 2001 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3109 |
|
This memo changes the status of STD 39, BBN Report 1822,"Specification of the Interconnection of a Host and an IMP", fromStandard to Historic. |
|
| |
| RFC 3112 | LDAP Authentication Password Schema |
| |
| Authors: | K. Zeilenga. |
| Date: | May 2001 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3112 |
|
This document describes schema in support of user/password authentication in a LDAP (Lightweight Directory Access Protocol) directory including the authPassword attribute type. This attribute type holds values derived from the user's password(s) (commonly using cryptographic strength one-way hash). authPassword is intended to used instead of userPassword. |
|
| |
| RFC 3113 | 3GPP-IETF Standardization Collaboration |
| |
| Authors: | K. Rosenbrock, R. Sanmugam, S. Bradner, J. Klensin. |
| Date: | June 2001 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3113 |
|
This document describes the standardization collaboration between3GPP and IETF. |
|
| |
| RFC 3114 | Implementing Company Classification Policy with the S/MIME Security Label |
| |
| Authors: | W. Nicolls. |
| Date: | May 2002 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3114 |
|
This document discusses how company security policy for data classification can be mapped to the S/MIME security label. Actual policies from three companies provide worked examples. |
|
| |
| RFC 3116 | Methodology for ATM Benchmarking |
| |
| Authors: | J. Dunn, C. Martin. |
| Date: | June 2001 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3116 |
|
This document discusses and defines a number of tests that may be used to describe the performance characteristics of ATM (AsynchronousTransfer Mode) based switching devices. In addition to defining the tests this document also describes specific formats for reporting the results of the tests.
This memo is a product of the Benchmarking Methodology Working Group(BMWG) of the Internet Engineering Task Force (IETF). |
|
| |
| RFC 3117 | On the Design of Application Protocols |
| |
| Authors: | M. Rose. |
| Date: | November 2001 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3117 |
|
This memo describes the design principles for the Blocks eXtensible eXchange Protocol (BXXP). BXXP is a generic application protocol framework for connection-oriented, asynchronous interactions. The framework permits simultaneous and independent exchanges within the context of a single application user-identity, supporting both textual and binary messages. |
|
| |
| RFC 3120 | A URN Namespace for XML.org |
| |
| Authors: | K. Best, N. Walsh. |
| Date: | June 2001 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3120 |
|
This document describes a URN (Uniform Resource Name) namespace that is engineered by the Organization for the Advancement of StructuredInformation Standards (OASIS) for naming persistent resources stored in the XML.org repository (such as XML (Extensible Markup Language)Document Type Definitions, XML Schemas, Namespaces, Stylesheets, and other documents). |
|
| |
| RFC 3121 | A URN Namespace for OASIS |
| |
| Authors: | K. Best, N. Walsh. |
| Date: | June 2001 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3121 |
|
This document describes a URN (Uniform Resource Name) namespace that is engineered by the Organization for the Advancement of StructuredInformation Standards (OASIS) for naming persistent resources published by OASIS (such as OASIS Standards, XML (Extensible MarkupLanguage) Document Type Definitions, XML Schemas, Namespaces,Stylesheets, and other documents). |
|
| |
| RFC 3126 | Electronic Signature Formats for long term electronic signatures |
| |
| Authors: | D. Pinkas, J. Ross, N. Pope. |
| Date: | September 2001 |
| Formats: | txt json html |
| Obsoleted by: | RFC 5126 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3126 |
|
This document defines the format of an electronic signature that can remain valid over long periods. This includes evidence as to its validity even if the signer or verifying party later attempts to deny(i.e., repudiates the validity of the signature).
The format can be considered as an extension to RFC 2630 and RFC2634, where, when appropriate additional signed and unsigned attributes have been defined.
The contents of this Informational RFC is technically equivalent toETSI TS 101 733 V.1.2.2. The ETSI TS is under the ETSI Copyright (C).Individual copies of this ETSI deliverable can be downloaded from http://www.etsi.org |
|
| |
| RFC 3127 | Authentication, Authorization, and Accounting: Protocol Evaluation |
| |
| Authors: | D. Mitton, M. St.Johns, S. Barkley, D. Nelson, B. Patil, M. Stevens, B. Wolff. |
| Date: | June 2001 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3127 |
|
This memo represents the process and findings of the Authentication,Authorization, and Accounting Working Group (AAA WG) panel evaluating protocols proposed against the AAA Network Access Requirements, RFC2989. Due to time constraints of this report, this document is not as fully polished as it might have been desired. But it remains mostly in this state to document the results as presented. |
|
| |
| RFC 3128 | Protection Against a Variant of the Tiny Fragment Attack (RFC 1858) |
| |
|
|
This document discusses how RFC 1858 compliant filters can be vulnerable to a variant of the "Tiny Fragment Attack" described in section 3.1 of the RFC. This document describes the attack and recommends corrective action. |
|
| |
| RFC 3129 | Requirements for Kerberized Internet Negotiation of Keys |
| |
| Authors: | M. Thomas. |
| Date: | June 2001 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3129 |
|
The goal of this document is to produce a streamlined, fast, easily managed, and cryptographically sound protocol without requiring public key. |
|
| |
| RFC 3130 | Notes from the State-Of-The-Technology: DNSSEC |
| |
| Authors: | E. Lewis. |
| Date: | June 2001 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3130 |
|
This is a memo of a DNSSEC (Domain Name System Security Extensions) status meeting. |
|
| |
| RFC 3131 | 3GPP2-IETF Standardization Collaboration |
| |
| Authors: | S. Bradner, P. Calhoun, H. Cuschieri, S. Dennett, G. Flynn, M. Lipford, M. McPheters. |
| Date: | June 2001 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3131 |
|
This document describes the standardization collaboration between3GPP2 and IETF. |
|
| |
| RFC 3132 | Dormant Mode Host Alerting ("IP Paging") Problem Statement |
| |
| Authors: | J. Kempf. |
| Date: | June 2001 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3132 |
|
This memo describes paging, assesses the need for IP paging, and presents a list of recommendations for Seamoby charter items regarding work on paging. The results are specifically directed toward the task undertaken by the design team, and are not meant to be the definitive word on paging for all time, nor to be binding onSeamoby or other working groups, should the situation with regard toIP mobility protocols or radio link support undergo a major change. |
|
| |
| RFC 3133 | Terminology for Frame Relay Benchmarking |
| |
| Authors: | J. Dunn, C. Martin. |
| Date: | June 2001 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3133 |
|
This memo discusses and defines terms associated with performance benchmarking tests and the results of these tests in the context of frame relay switching devices. |
|
| |
| RFC 3134 | Terminology for ATM ABR Benchmarking |
| |
| Authors: | J. Dunn, C. Martin. |
| Date: | June 2001 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3134 |
|
This memo discusses and defines terms associated with performance benchmarking tests and the results of these tests in the context ofAsynchronous Transfer Mode (ATM) based switching devices supportingABR (Available Bit Rate). The terms defined in this memo will be used in addition to terms defined in RFCs 1242, 2285, and 2544 and2761. This memo is a product of the Benchmarking Methodology WorkingGroup (BMWG) of the Internet Engineering Task Force (IETF). |
|
| |
| RFC 3135 | Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations |
| |
| Authors: | J. Border, M. Kojo, J. Griner, G. Montenegro, Z. Shelby. |
| Date: | June 2001 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3135 |
|
This document is a survey of Performance Enhancing Proxies (PEPs) often employed to improve degraded TCP performance caused by characteristics of specific link environments, for example, in satellite, wireless WAN, and wireless LAN environments. Different types of Performance Enhancing Proxies are described as well as the mechanisms used to improve performance. Emphasis is put on proxies operating with TCP. In addition, motivations for their development and use are described along with some of the consequences of using them, especially in the context of the Internet. |
|
| |
| RFC 3136 | The SPIRITS Architecture |
| |
| Authors: | L. Slutsman, Ed., I. Faynberg, H. Lu, M. Weissman. |
| Date: | June 2001 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3136 |
|
This document describes the architecture for supporting SPIRITS services, which are those originating in the PSTN (Public SwitchedTelephone Network)and necessitating the interactions between the PSTN and the Internet. (Internet Call Waiting, Internet Caller-IDDelivery, and Internet Call Forwarding are examples of SPIRIT services.) Specifically, it defines the components constituting the architecture and the interfaces between the components. |
|
| |
| RFC 3137 | OSPF Stub Router Advertisement |
| |
| Authors: | A. Retana, L. Nguyen, R. White, A. Zinin, D. McPherson. |
| Date: | June 2001 |
| Formats: | txt json html |
| Obsoleted by: | RFC 6987 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3137 |
|
This memo describes a backward-compatible technique that may be used by OSPF (Open Shortest Path First) implementations to advertise unavailability to forward transit traffic or to lower the preference level for the paths through such a router. In some cases, it is desirable not to route transit traffic via a specific OSPF router.However, OSPF does not specify a standard way to accomplish this. |
|
| |
| RFC 3138 | Extended Assignments in 233/8 |
| |
|
|
This memo provides describes the mapping of the GLOP addresses corresponding to the private AS space. |
|
| |
| RFC 3139 | Requirements for Configuration Management of IP-based Networks |
| |
| Authors: | L. Sanchez, K. McCloghrie, J. Saperia. |
| Date: | June 2001 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3139 |
|
This memo discusses different approaches to configure networks and identifies a set of configuration management requirements for IP- based networks. |
|
| |
| RFC 3141 | CDMA2000 Wireless Data Requirements for AAA |
| |
| Authors: | T. Hiller, P. Walsh, X. Chen, M. Munson, G. Dommety, S. Sivalingham, B. Lim, P. McCann, H. Shiino, B. Hirschman, S. Manning, R. Hsu, H. Koo, M. Lipford, P. Calhoun, C. Lo, E. Jaques, E. Campbell, Y. Xu, S. Baba, T. Ayaki, T. Seki, A. Hameed. |
| Date: | June 2001 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3141 |
|
This memo specifies cdma2000 wireless data AAA (Authentication,Authorization, Accounting) requirements associated with third generation wireless architecture that supports roaming among service providers for traditional PPP and Mobile IP services. |
|
| |
| RFC 3142 | An IPv6-to-IPv4 Transport Relay Translator |
| |
| Authors: | J. Hagino, K. Yamamoto. |
| Date: | June 2001 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3142 |
|
The document describes an IPv6-to-IPv4 transport relay translator(TRT). It enables IPv6-only hosts to exchange {TCP,UDP} traffic withIPv4-only hosts. A TRT system, which locates in the middle, translates {TCP,UDP}/IPv6 to {TCP,UDP}/IPv4, or vice versa.
The memo talks about how to implement a TRT system using existing technologies. It does not define any new protocols. |
|
| |
| RFC 3143 | Known HTTP Proxy/Caching Problems |
| |
| Authors: | I. Cooper, J. Dilley. |
| Date: | June 2001 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3143 |
|
This document catalogs a number of known problems with World Wide Web(WWW) (caching) proxies and cache servers. The goal of the document is to provide a discussion of the problems and proposed workarounds, and ultimately to improve conditions by illustrating problems. The construction of this document is a joint effort of the Web caching community. |
|
| |
| RFC 3147 | Generic Routing Encapsulation over CLNS Networks |
| |
| Authors: | P. Christian. |
| Date: | July 2001 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3147 |
|
This document proposes a method for transporting an arbitrary protocol over a CLNS (Connectionless Network Service) network usingGRE (Generic Routing Encapsulation). This may then be used as a method to tunnel IPv4 or IPv6 over CLNS. |
|
| |
| RFC 3148 | A Framework for Defining Empirical Bulk Transfer Capacity Metrics |
| |
| Authors: | M. Mathis, M. Allman. |
| Date: | July 2001 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3148 |
|
This document defines a framework for standardizing multiple BTC(Bulk Transport Capacity) metrics that parallel the permitted transport diversity. |
|
| |
| RFC 3149 | MGCP Business Phone Packages |
| |
| Authors: | A. Srinath, G. Levendel, K. Fritz, R. Kalyanaram. |
| Date: | September 2001 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3149 |
|
This document describes a collection of MGCP (Media Gateway ControlProtocol) packages that can be used to take advantage of the feature keys and displays on digital business phones and IP-Phones. |
|
| |
| RFC 3151 | A URN Namespace for Public Identifiers |
| |
| Authors: | N. Walsh, J. Cowan, P. Grosso. |
| Date: | August 2001 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3151 |
|
This document describes a URN (Uniform Resource Name) namespace that is designed to allow Public Identifiers to be expressed in URI(Uniform Resource Identifiers) syntax. |
|
| |
| RFC 3154 | Requirements and Functional Architecture for an IP Host Alerting Protocol |
| |
| Authors: | J. Kempf, C. Castelluccia, P. Mutaf, N. Nakajima, Y. Ohba, R. Ramjee, Y. Saifullah, B. Sarikaya, X. Xu. |
| Date: | August 2001 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3154 |
|
This document develops an architecture and a set of requirements needed to support alerting of hosts that are in dormant mode. The architecture and requirements are designed to guide development of anIP protocol for alerting dormant IP mobile hosts, commonly called paging. |
|
| |
| RFC 3157 | Securely Available Credentials - Requirements |
| |
| Authors: | A. Arsenault, S. Farrell. |
| Date: | August 2001 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3157 |
|
This document describes requirements to be placed on SecurelyAvailable Credentials (SACRED) protocols. |
|
| |
| RFC 3158 | RTP Testing Strategies |
| |
| Authors: | C. Perkins, J. Rosenberg, H. Schulzrinne. |
| Date: | August 2001 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3158 |
|
This memo describes a possible testing strategy for RTP (real-time transport protocol) implementations. |
|
| |
| RFC 3160 | The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force |
| |
|
|
This document describes the inner workings of IETF meetings andWorking Groups, discusses organizations related to the IETF, and introduces the standards process. |
|
| |
| RFC 3164 | The BSD Syslog Protocol |
| |
|
|
This document describes the observed behavior of the syslog protocol.This protocol has been used for the transmission of event notification messages across networks for many years. While this protocol was originally developed on the University of CaliforniaBerkeley Software Distribution (BSD) TCP/IP system implementations, its value to operations and management has led it to be ported to many other operating systems as well as being embedded into many other networked devices. |
|
| |
| RFC 3166 | Request to Move RFC 1403 to Historic Status |
| |
| Authors: | D. Meyer, J. Scudder. |
| Date: | August 2001 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3166 |
|
RFC 1403, "BGP OSPF Interaction", describes technology which is no longer used. This document requests that RFC 1403 be moved toHistoric status. |
|
| |
| RFC 3167 | Request to Move RFC 1745 to Historic Status |
| |
| Authors: | D. Meyer, J. Scudder. |
| Date: | August 2001 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3167 |
|
RFC 1745, "BGP4/IDRP for IP---OSPF Interaction", describes technology which was never deployed in the public internet. This document requests that RFC 1745 be moved to Historic status. |
|
| |
| RFC 3169 | Criteria for Evaluating Network Access Server Protocols |
| |
| Authors: | M. Beadles, D. Mitton. |
| Date: | September 2001 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3169 |
|
This document defines requirements for protocols used by NetworkAccess Servers (NAS). |
|
| |
| RFC 3170 | IP Multicast Applications: Challenges and Solutions |
| |
| Authors: | B. Quinn, K. Almeroth. |
| Date: | September 2001 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3170 |
|
This document describes the challenges involved with designing and implementing multicast applications. It is an introductory guide for application developers that highlights the unique considerations of multicast applications as compared to unicast applications.
To this end, the document presents a taxonomy of multicast application I/O models and examples of the services they can support.It then describes the service requirements of these multicast applications, and the recent and ongoing efforts to build protocol solutions to support these services. |
|
| |
| RFC 3174 | US Secure Hash Algorithm 1 (SHA1) |
| |
|
|
The purpose of this document is to make the SHA-1 (Secure HashAlgorithm 1) hash algorithm conveniently available to the Internet community. The United States of America has adopted the SHA-1 hash algorithm described herein as a Federal Information ProcessingStandard. Most of the text herein was taken by the authors from FIPS180-1. Only the C code implementation is "original". |
|
| |
| RFC 3176 | InMon Corporation's sFlow: A Method for Monitoring Traffic in Switched and Routed Networks |
| |
| Authors: | P. Phaal, S. Panchen, N. McKee. |
| Date: | September 2001 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3176 |
|
This memo defines InMon Coporation's sFlow system. sFlow is a technology for monitoring traffic in data networks containing switches and routers. In particular, it defines the sampling mechanisms implemented in an sFlow Agent for monitoring traffic, the sFlow MIB for controlling the sFlow Agent, and the format of sample data used by the sFlow Agent when forwarding data to a central data collector. |
|
| |
| RFC 3177 | IAB/IESG Recommendations on IPv6 Address Allocations to Sites |
| |
|
|
This document provides recommendations to the addressing registries(APNIC, ARIN and RIPE-NCC) on policies for assigning IPv6 address blocks to end sites. In particular, it recommends the assignment of/48 in the general case, /64 when it is known that one and only one subnet is needed and /128 when it is absolutely known that one and only one device is connecting.
The original recommendations were made in an IAB/IESG statement mailed to the registries on September 1, 2000. This document refines the original recommendation and documents it for the historical record. |
|
| |
| RFC 3178 | IPv6 Multihoming Support at Site Exit Routers |
| |
| Authors: | J. Hagino, H. Snyder. |
| Date: | October 2001 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3178 |
|
The document describes a mechanism for basic IPv6 multihoming support, and its operational requirements. Unlike currently- practiced IPv4 multihoming, the technique does not impact the worldwide routing table size, nor IGP (Interior Gateway Protocol) routing table size in upstream ISPs. The mechanism can be combined with more sophisticated (or complex) multihoming support mechanisms, and can be used as a foundation for other mechanisms. The document is largely based on RFC 2260 by Tony Bates. |
|
| |
| RFC 3186 | MAPOS/PPP Tunneling mode |
| |
| Authors: | S. Shimizu, T. Kawano, K. Murakami, E. Beier. |
| Date: | December 2001 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3186 |
|
This document specifies tunneling configuration over MAPOS (MultipleAccess Protocol over SONET/SDH) networks. Using this mode, a MAPOS network can provide transparent point-to-point link for PPP overSONET/SDH (Packet over SONET/SDH, POS) without any additional overhead. |
|
| |
| RFC 3188 | Using National Bibliography Numbers as Uniform Resource Names |
| |
|
|
This document discusses how national bibliography numbers (persistent and unique identifiers assigned by the national libraries) can be supported within the URN (Uniform Resource Names) framework and the syntax for URNs defined in RFC 2141. Much of the discussion is based on the ideas expressed in RFC 2288. |
|
| |
| RFC 3194 | 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 RFC1715. It defines a new ratio which the authors claim is easier to understand. |
|
| |
| RFC 3196 | Internet Printing Protocol/1.1: Implementor's Guide |
| |
| Authors: | T. Hastings, C. Manros, P. Zehler, C. Kugler, H. Holst. |
| Date: | November 2001 |
| Formats: | txt html json |
| Obsoletes: | RFC 2639 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3196 |
|
This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). |
|
| |
| RFC 3197 | Applicability Statement for DNS MIB Extensions |
| |
| Authors: | R. Austein. |
| Date: | November 2001 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3197 |
|
This document explains why, after more than six years as proposed standards, the DNS Server and Resolver MIB extensions were never deployed, and recommends retiring these MIB extensions by moving them to Historical status. |
|
| |
| RFC 3198 | Terminology for Policy-Based Management |
| |
| Authors: | A. Westerinen, J. Schnizlein, J. Strassner, M. Scherling, B. Quinn, S. Herzog, A. Huynh, M. Carlson, J. Perry, S. Waldbusser. |
| Date: | November 2001 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3198 |
|
This document is a glossary of policy-related terms. It provides abbreviations, explanations, and recommendations for use of these terms. The document takes the approach and format of RFC 2828, which defines an Internet Security Glossary. The intent is to improve the comprehensibility and consistency of writing that deals with network policy, particularly Internet Standards documents (ISDs). |
|
| |
| RFC 3199 | Request for Comments Summary RFC Numbers 3100-3199 |
| |
| Authors: | S. Ginoza. |
| Date: | February 2003 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3199 |
|
|
|
| |
| RFC 3210 | Applicability Statement for Extensions to RSVP for LSP-Tunnels |
| |
| Authors: | D. Awduche, A. Hannan, X. Xiao. |
| Date: | December 2001 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3210 |
|
This memo discusses the applicability of "Extensions to RSVP(Resource ReSerVation Protocol) for LSP Tunnels". It highlights the protocol's principles of operation and describes the network context for which it was designed. Guidelines for deployment are offered and known protocol limitations are indicated. This document is intended to accompany the submission of "Extensions to RSVP for LSP Tunnels" onto the Internet standards track. |
|
| |
| RFC 3213 | Applicability Statement for CR-LDP |
| |
| Authors: | J. Ash, M. Girish, E. Gray, B. Jamoussi, G. Wright. |
| Date: | January 2002 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3213 |
|
This document discusses the applicability of Constraint-Based LSPSetup using LDP. It discusses possible network applications, extensions to Label Distribution Protocol (LDP) required to implement constraint-based routing, guidelines for deployment and known limitations of the protocol. This document is a prerequisite to advancing CR-LDP on the standards track. |
|
| |
| RFC 3215 | LDP State Machine |
| |
| Authors: | C. Boscher, P. Cheval, L. Wu, E. Gray. |
| Date: | January 2002 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3215 |
|
This document provides state machine tables for ATM (AsynchronousTransfer Mode) switch LSRs. In the current LDP specification, there is no state machine specified for processing LDP messages. We think that defining a common state machine is very important for interoperability between different LDP and CR-LDP implementations.
We begin in section 1 by defining a list of terminologies. Then in section 2, we propose two sets of state machine tables for ATM switchLSRs that use downstream-on-demand mode, one method can be used for non-vc merge capable ATM LSRs, while the other one can be used for the vc-merge capable ATM LSRs. In section 3, we provides a state machine for downstream unsolicited mode ATM LSRs.
We focus on the LDP state machines and the associated control blocks used for establishing and maintaining LSPs. We do not describe state machines for the "LDP controller" that is in charge of LDP session initialization, address mapping messages management, routing interface, etc. that is defined in the LDP specification.
Even though the state machines in this document are specific forATM-LSR, they can be easily adapted for other types of LSRs. |
|
| |
| RFC 3216 | SMIng Objectives |
| |
| Authors: | C. Elliott, D. Harrington, J. Jason, J. Schoenwaelder, F. Strauss, W. Weiss. |
| Date: | December 2001 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3216 |
|
This document describes the objectives for a new data definition language, suitable for the modeling of network management constructs, that can be directly mapped into SNMP and COPS-PR protocol operations.
The purpose of this document is to serve as a set of objectives that a subsequent language specification should try to address. It captures the results of the working group discussions towards consensus on the SMIng objectives. |
|
| |
| RFC 3217 | Triple-DES and RC2 Key Wrapping |
| |
| Authors: | R. Housley. |
| Date: | December 2001 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3217 |
|
This document specifies the algorithm for wrapping one Triple-DES key with another Triple-DES key and the algorithm for wrapping one RC2 key with another RC2 key. These key wrap algorithms were originally published in section 12.6 of RFC 2630. They are republished since these key wrap algorithms have been found to be useful in contexts beyond those supported by RFC 2630. |
|
| |
| RFC 3218 | Preventing the Million Message Attack on Cryptographic Message Syntax |
| |
| Authors: | E. Rescorla. |
| Date: | January 2002 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3218 |
|
This memo describes a strategy for resisting the Million MessageAttack. |
|
| |
| RFC 3221 | Commentary on Inter-Domain Routing in the Internet |
| |
| Authors: | G. Huston. |
| Date: | December 2001 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3221 |
|
This document examines the various longer term trends visible within the characteristics of the Internet's BGP table and identifies a number of operational practices and protocol factors that contribute to these trends. The potential impacts of these practices and protocol properties on the scaling properties of the inter-domain routing space are examined.
This document is the outcome of a collaborative exercise on the part of the Internet Architecture Board. |
|
| |
| RFC 3222 | Terminology for Forwarding Information Base (FIB) based Router Performance |
| |
| Authors: | G. Trotter. |
| Date: | December 2001 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3222 |
|
This document describes the terms to be used in a methodology that determines the IP packet forwarding performance of IP routers as a function of the forwarding information base installed within a router. The forwarding performance of an IP router may be dependent upon or may be linked to the composition and size of the forwarding information base installed within a router. |
|
| |
| RFC 3232 | 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. |
|
| |
| RFC 3234 | Middleboxes: Taxonomy and Issues |
| |
| Authors: | B. Carpenter, S. Brim. |
| Date: | February 2002 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3234 |
|
This document is intended as part of an IETF discussion about"middleboxes" - defined as any intermediary box performing functions apart from normal, standard functions of an IP router on the data path between a source host and destination host. This document establishes a catalogue or taxonomy of middleboxes, cites previous and current IETF work concerning middleboxes, and attempts to identify some preliminary conclusions. It does not, however, claim to be definitive. |
|
| |
| RFC 3235 | Network Address Translator (NAT)-Friendly Application Design Guidelines |
| |
| Authors: | D. Senie. |
| Date: | January 2002 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3235 |
|
This document discusses those things that application designers might wish to consider when designing new protocols. While many commonInternet applications will operate cleanly in the presence of NetworkAddress Translators, others suffer from a variety of problems when crossing these devices. Guidelines are presented herein to help ensure new protocols and applications will, to the extent possible, be compatible with NAT (Network Address Translation). |
|
| |
| RFC 3236 | The 'application/xhtml+xml' Media Type |
| |
| Authors: | M. Baker, P. Stark. |
| Date: | January 2002 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3236 |
|
This document defines the 'application/xhtml+xml' MIME media type forXHTML based markup languages; it is not intended to obsolete any previous IETF documents, in particular RFC 2854 which registers'text/html'. |
|
| |
| RFC 3237 | Requirements for Reliable Server Pooling |
| |
| Authors: | M. Tuexen, Q. Xie, R. Stewart, M. Shore, L. Ong, J. Loughney, M. Stillman. |
| Date: | January 2002 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3237 |
|
This document defines a basic set of requirements for reliable server pooling.
The goal of Reliable Server Pooling (RSerPool) is to develop an architecture and protocols for the management and operation of server pools supporting highly reliable applications, and for client access mechanisms to a server pool. |
|
| |
| RFC 3238 | IAB Architectural and Policy Considerations for Open Pluggable Edge Services |
| |
| Authors: | S. Floyd, L. Daigle. |
| Date: | January 2002 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3238 |
|
This document includes comments and recommendations by the IAB on some architectural and policy issues related to the chartering ofOpen Pluggable Edge Services (OPES) in the IETF. OPES are services that would be deployed at application-level intermediaries in the network, for example, at a web proxy cache between the origin server and the client. These intermediaries would transform or filter content, with the explicit consent of either the content provider or the end user. |
|
| |
| RFC 3239 | Internet Printing Protocol (IPP): Requirements for Job, Printer, and Device Administrative Operations |
| |
| Authors: | C. Kugler, H. Lewis, T. Hastings. |
| Date: | February 2002 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3239 |
|
This document specifies the requirements and uses cases for some optional administrative operations for use with the Internet PrintingProtocol (IPP) version 1.0 and version 1.1. Some of these administrative operations operate on the IPP Job and Printer objects.The remaining operations operate on a new Device object that more closely models a single output device. |
|
| |
| RFC 3240 | Digital Imaging and Communications in Medicine (DICOM) - Application/dicom MIME Sub-type Registration |
| |
| Authors: | D. Clunie, E. Cordonnier. |
| Date: | February 2002 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3240 |
|
This document describes the registration of the MIME sub-type application/dicom (Digital Imaging and Communications in Medicine).The baseline encoding is defined by the DICOM Standards Committee in"Digital Imaging and Communications in Medicine". |
|
| |
| RFC 3243 | RObust Header Compression (ROHC): Requirements and Assumptions for 0-byte IP/UDP/RTP Compression |
| |
| Authors: | L-E. Jonsson. |
| Date: | April 2002 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3243 |
|
This document contains requirements for the 0-byte IP/UDP/RTP(Internet Protocol/User Datagram Protocol/Real-Time TransportProtocol) header compression scheme to be developed by the RobustHeader Compression (ROHC) Working Group. It also includes the basic assumptions for the typical link layers over which 0-byte compression may be implemented, and assumptions about its usage in general. |
|
| |
| RFC 3244 | Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols |
| |
| Authors: | M. Swift, J. Trostle, J. Brezak. |
| Date: | February 2002 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3244 |
|
This memo specifies Microsoft's Windows 2000 Kerberos change password and set password protocols. The Windows 2000 Kerberos change password protocol interoperates with the original Kerberos change password protocol. Change password is a request reply protocol that includes a KRB_PRIV message that contains the new password for the user. |
|
| |
| RFC 3245 | The History and Context of Telephone Number Mapping (ENUM) Operational Decisions: Informational Documents Contributed to ITU-T Study Group 2 (SG2) |
| |
| Authors: | J. Klensin, Ed., IAB. |
| Date: | March 2002 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3245 |
|
RFC 2916 assigned responsibility for a number of administrative and operational details of Telephone Number Mapping (ENUM) to the IAB.It also anticipated that ITU would take responsibility for determining the legitimacy and appropriateness of applicants for delegation of "country code"-level subdomains of the top-level ENUM domain. Recently, three memos have been prepared for the ITU-T StudyGroup 2 (SG2) to explain the background of, and reasoning for, the relevant decisions. The IAB has also supplied a set of procedural instructions to the RIPE NCC for implementation of their part of the model. The content of the three memos is provided in this document for the information of the IETF community. |
|
| |
| RFC 3247 | Supplemental Information for the New Definition of the EF PHB (Expedited Forwarding Per-Hop Behavior) |
| |
| Authors: | A. Charny, J. Bennet, K. Benson, J. Boudec, A. Chiu, W. Courtney, S. Davari, V. Firoiu, C. Kalmanek, K. Ramakrishnan. |
| Date: | March 2002 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3247 |
|
This document was written during the process of clarification ofRFC2598 "An Expedited Forwarding PHB" that led to the publication of revised specification of EF "An Expedited Forwarding PHB". Its primary motivation is providing additional explanation to the revisedEF definition and its properties. The document also provides additional implementation examples and gives some guidance for computation of the numerical parameters of the new definition for several well known schedulers and router architectures. |
|
| |
| RFC 3248 | A Delay Bound alternative revision of RFC 2598 |
| |
| Authors: | G. Armitage, B. Carpenter, A. Casati, J. Crowcroft, J. Halpern, B. Kumar, J. Schnizlein. |
| Date: | March 2002 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3248 |
|
For historical interest, this document captures the EF Design Team's proposed solution, preferred by the original authors of RFC 2598 but not adopted by the working group in December 2000. The original definition of EF was based on comparison of forwarding on an unloaded network. This experimental Delay Bound (DB) PHB requires a bound on the delay of packets due to other traffic in the network. At thePittsburgh IETF meeting in August 2000, the Differentiated Services working group faced serious questions regarding RFC 2598 - the group's standards track definition of the Expedited Forwarding (EF)Per Hop Behavior (PHB). An 'EF Design Team' volunteered to develop a re-expression of RFC 2598, bearing in mind the issues raised in theDiffServ group. At the San Diego IETF meeting in December 2000 theDiffServ working group decided to pursue an alternative re-expression of the EF PHB. |
|
| |
| RFC 3249 | Implementers Guide for Facsimile Using Internet Mail |
| |
| Authors: | V. Cancio, M. Moldovan, H. Tamura, D. Wing. |
| Date: | September 2002 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3249 |
|
This document is intended for the implementers of software that use email to send to facsimiles using RFC 2305 and 2532. This is an informational document and its guidelines do not supersede the referenced documents. |
|
| |
| RFC 3251 | Electricity over IP |
| |
| Authors: | B. Rajagopalan. |
| Date: | 1 April 2002 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3251 |
|
Mostly Pointless Lamp Switching (MPLampS) is an architecture for carrying electricity over IP (with an MPLS control plane). According to our marketing department, MPLampS has the potential to dramatically lower the price, ease the distribution and usage, and improve the manageability of delivering electricity. This document is motivated by such work as SONET/SDH over IP/MPLS (with apologies to the authors). Readers of the previous work have been observed scratching their heads and muttering, "What next?". This document answers that question.
This document has also been written as a public service. The "Sub-IP" area has been formed to give equal opportunity to those working on technologies outside of traditional IP networking to write complicated IETF documents. There are possibly many who are wondering how to exploit this opportunity and attain high visibility.Towards this goal, we see the topics of "foo-over-MPLS" (or MPLS control for random technologies) as highly amenable for producing a countless number of unimplementable documents. This document illustrates the key ingredients that go into producing any "foo- over-MPLS" document and may be used as a template for all such work. |
|
| |
| RFC 3252 | Binary Lexical Octet Ad-hoc Transport |
| |
| Authors: | H. Kennedy. |
| Date: | 1 April 2002 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3252 |
|
This document defines a reformulation of IP and two transport layer protocols (TCP and UDP) as XML applications. |
|
| |
| RFC 3254 | Definitions for talking about directories |
| |
| Authors: | H. Alvestrand. |
| Date: | April 2002 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3254 |
|
When discussing systems for making information accessible through theInternet in standardized ways, it may be useful if the people who are discussing it have a common understanding of the terms they use.
For example, a reference to this document would give one the power to agree that the DNS (Domain Name System) is a global lookup repository with perimeter integrity and loose, converging consistency. On the other hand, a LDAP (Lightweight Directory Access Protocol) directory server is a local, centralized repository with both lookup and search capability.
This document discusses one group of such systems which is known under the term, "directories". |
|
| |
| RFC 3257 | Stream Control Transmission Protocol Applicability Statement |
| |
| Authors: | L. Coene. |
| Date: | April 2002 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3257 |
|
This document describes the applicability of the Stream ControlTransmission Protocol (SCTP). It also contrasts SCTP with the two dominant transport protocols, User Datagram Protocol (UDP) &Transmission Control Protocol (TCP), and gives some guidelines for when best to use SCTP and when not best to use SCTP. |
|
| |
| RFC 3258 | Distributing Authoritative Name Servers via Shared Unicast Addresses |
| |
| Authors: | T. Hardie. |
| Date: | April 2002 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3258 |
|
This memo describes a set of practices intended to enable an authoritative name server operator to provide access to a single named server in multiple locations. The primary motivation for the development and deployment of these practices is to increase the distribution of Domain Name System (DNS) servers to previously under-served areas of the network topology and to reduce the latency for DNS query responses in those areas. |
|
| |
| RFC 3259 | A Message Bus for Local Coordination |
| |
| Authors: | J. Ott, C. Perkins, D. Kutscher. |
| Date: | April 2002 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3259 |
|
The local Message Bus (Mbus) is a light-weight message-oriented coordination protocol for group communication between application components. The Mbus provides automatic location of communication peers, subject based addressing, reliable message transfer and different types of communication schemes. The protocol is layered on top of IP multicast and is specified for IPv4 and IPv6. The IP multicast scope is limited to link-local multicast. This document specifies the Mbus protocol, i.e., message syntax, addressing and transport mechanisms. |
|
| |
| RFC 3260 | New Terminology and Clarifications for Diffserv |
| |
|
|
This memo captures Diffserv working group agreements concerning new and improved terminology, and provides minor technical clarifications. It is intended to update RFC 2474, RFC 2475 and RFC2597. When RFCs 2474 and 2597 advance on the standards track, andRFC 2475 is updated, it is intended that the revisions in this memo will be incorporated, and that this memo will be obsoleted by the newRFCs. |
|
| |
| RFC 3269 | Author Guidelines for Reliable Multicast Transport (RMT) Building Blocks and Protocol Instantiation documents |
| |
| Authors: | R. Kermode, L. Vicisano. |
| Date: | April 2002 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3269 |
|
This document provides general guidelines to assist the authors ofReliable Multicast Transport (RMT) building block and protocol instantiation definitions. The purpose of these guidelines is to ensure that any building block and protocol instantiation definitions produced contain sufficient information to fully explain their operation and use. In addition these guidelines provide directions to specify modular and clearly defined RMT building blocks and protocol instantiations that can be refined and augmented to safely create new protocols for use in new scenarios for which any existing protocols were not designed. |
|
| |
| RFC 3271 | The Internet is for Everyone |
| |
| Authors: | V. Cerf. |
| Date: | April 2002 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3271 |
|
This document expresses the Internet Society's ideology that theInternet really is for everyone. However, it will only be such if we make it so. |
|
| |
| RFC 3272 | Overview and Principles of Internet Traffic Engineering |
| |
| Authors: | D. Awduche, A. Chiu, A. Elwalid, I. Widjaja, X. Xiao. |
| Date: | May 2002 |
| Formats: | txt json html |
| Obsoleted by: | RFC 9522 |
| Updated by: | RFC 5462 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3272 |
|
This memo describes the principles of Traffic Engineering (TE) in theInternet. The document is intended to promote better understanding of the issues surrounding traffic engineering in IP networks, and to provide a common basis for the development of traffic engineering capabilities for the Internet. The principles, architectures, and methodologies for performance evaluation and performance optimization of operational IP networks are discussed throughout this document. |
|
| |
| RFC 3277 | Intermediate System to Intermediate System (IS-IS) Transient Blackhole Avoidance |
| |
| Authors: | D. McPherson. |
| Date: | April 2002 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3277 |
|
This document describes a simple, interoperable mechanism that can be employed in Intermediate System to Intermediate System (IS-IS) networks in order to decrease the data loss associated with deterministic blackholing of packets during transient network conditions. The mechanism proposed here requires no IS-IS protocol changes and is completely interoperable with the existing IS-IS specification. |
|
| |
| RFC 3278 | Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS) |
| |
| Authors: | S. Blake-Wilson, D. Brown, P. Lambert. |
| Date: | April 2002 |
| Formats: | txt html json |
| Obsoleted by: | RFC 5753 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3278 |
|
This document describes how to use Elliptic Curve Cryptography (ECC) public-key algorithms in the Cryptographic Message Syntax (CMS). TheECC algorithms support the creation of digital signatures and the exchange of keys to encrypt or authenticate content. The definition of the algorithm processing is based on the ANSI X9.62 standard, developed by the ANSI X9F1 working group, the IEEE 1363 standard, and the SEC 1 standard.
The readers attention is called to the Intellectual Property Rights section at the end of this document. |
|
| |
| RFC 3283 | Guide to Internet Calendaring |
| |
| Authors: | B. Mahoney, G. Babics, A. Taler. |
| Date: | June 2002 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3283 |
|
This document describes the various Internet calendaring and scheduling standards and works in progress, and the relationships between them. Its intent is to provide a context for these documents, assist in their understanding, and potentially aid in the design of standards-based calendaring and scheduling systems. The standards addressed are RFC 2445 (iCalendar), RFC 2446 (iTIP), andRFC 2447 (iMIP). The work in progress addressed is "Calendar AccessProtocol" (CAP). This document also describes issues and problems that are not solved by these protocols, and that could be targets for future work. |
|
| |
| RFC 3285 | Using Microsoft Word to create Internet Drafts and RFCs |
| |
|
|
This document describes the steps to configure the Microsoft Word application to produce documents in Internet Draft and RFC format. |
|
| |
| RFC 3286 | An Introduction to the Stream Control Transmission Protocol (SCTP) |
| |
| Authors: | L. Ong, J. Yoakum. |
| Date: | May 2002 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3286 |
|
This document provides a high level introduction to the capabilities supported by the Stream Control Transmission Protocol (SCTP). It is intended as a guide for potential users of SCTP as a general purpose transport protocol. |
|
| |
| RFC 3290 | An Informal Management Model for Diffserv Routers |
| |
| Authors: | Y. Bernet, S. Blake, D. Grossman, A. Smith. |
| Date: | May 2002 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3290 |
|
This document proposes an informal management model of DifferentiatedServices (Diffserv) routers for use in their management and configuration. This model defines functional datapath elements(e.g., classifiers, meters, actions, marking, absolute dropping, counting, multiplexing), algorithmic droppers, queues and schedulers.It describes possible configuration parameters for these elements and how they might be interconnected to realize the range of traffic conditioning and per-hop behavior (PHB) functionalities described in the Diffserv Architecture. |
|
| |
| RFC 3294 | General Switch Management Protocol (GSMP) Applicability |
| |
| Authors: | A. Doria, K. Sundell. |
| Date: | June 2002 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3294 |
|
This memo provides an overview of the GSMP (General Switch ManagementProtocol) and includes information relating to its deployment in a IP network in an MPLS environment. It does not discuss deployment in anATM (Asynchronous Transfer Mode) network or in a raw ethernet configuration. |
|
| |
| RFC 3298 | Service in the Public Switched Telephone Network/Intelligent Network (PSTN/IN) Requesting InTernet Service (SPIRITS) Protocol Requirements |
| |
| Authors: | I. Faynberg, J. Gato, H. Lu, L. Slutsman. |
| Date: | August 2002 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3298 |
|
This document describes the SPIRITS protocol requirements, based on the architecture presented in RFC 3136. (SPIRITS stands for "Service in the PSTN/IN Requesting InTernet Service".) The purpose of the protocol is to support services that originate in the Public SwitchedTelephone Network (PSTN) and necessitate the interactions between thePSTN and the Internet. Similarly, such services are called SPIRITS services. (Internet Call Waiting, Internet Caller-ID Delivery, andInternet Call Forwarding are examples of SPIRIT services, but the protocol is to define the building blocks from which many other services can be built.) On the PSTN side, the SPIRITS services are initiated from the Intelligent Network (IN) entities; the earlierIETF work on the PSTN/Internet Interworking (PINT) resulted in the protocol (RFC 2848) in support of the services initiated the other way around--from the Internet to PSTN.
To this end, this document lists general requirements for the SPIRITS protocol as well as those pertinent to IN, Wireless IN, and PINT building blocks. The document also presents the SPIRITS WG consensus on the choice of the SPIRITS signaling protocol. |
|
| |
| RFC 3299 | Request for Comments Summary RFC Numbers 3200-3299 |
| |
| Authors: | S. Ginoza. |
| Date: | December 2003 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3299 |
|
|
|
| |
| RFC 3303 | Middlebox communication architecture and framework |
| |
| Authors: | P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, A. Rayhan. |
| Date: | August 2002 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3303 |
|
A principal objective of this document is to describe the underlying framework of middlebox communications (MIDCOM) to enable complex applications through the middleboxes, seamlessly using a trusted third party. This document and a companion document on MIDCOM requirements ([REQMTS]) have been created as a precursor to rechartering the MIDCOM working group.
There are a variety of intermediate devices in the Internet today that require application intelligence for their operation. Datagrams pertaining to real-time streaming applications, such as SIP andH.323, and peer-to-peer applications, such as Napster and NetMeeting, cannot be identified by merely examining packet headers. Middleboxes implementing Firewall and Network Address Translator services typically embed application intelligence within the device for their operation. The document specifies an architecture and framework in which trusted third parties can be delegated to assist the middleboxes to perform their operation, without resorting to embedding application intelligence. Doing this will allow a middlebox to continue to provide the services, while keeping the middlebox application agnostic. |
|
| |
| RFC 3304 | Middlebox Communications (midcom) Protocol Requirements |
| |
| Authors: | R. P. Swale, P. A. Mart, P. Sijben, S. Brim, M. Shore. |
| Date: | August 2002 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3304 |
|
This document specifies the requirements that the MiddleboxCommunication (midcom) protocol must satisfy in order to meet the needs of applications wishing to influence the middlebox function.These requirements were developed with a specific focus on network address translation and firewall middleboxes. |
|
| |
| RFC 3305 | Report from the Joint W3C/IETF URI Planning Interest Group: Uniform Resource Identifiers (URIs), URLs, and Uniform Resource Names (URNs): Clarifications and Recommendations |
| |
| Authors: | M. Mealling, Ed., R. Denenberg, Ed.. |
| Date: | August 2002 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3305 |
|
This document, a product of the W3C Uniform Resource Identifier (URI)Interest Group, addresses and attempts to clarify issues pertaining to URIs. This document addresses how URI space is partitioned and the relationship between URIs, URLs, and URNs, describes how URI schemes and URN namespaces ids are registered, and presents recommendations for continued work on this subject. |
|
| |
| RFC 3310 | Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA) |
| |
| Authors: | A. Niemi, J. Arkko, V. Torvinen. |
| Date: | September 2002 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3310 |
|
This memo specifies an Authentication and Key Agreement (AKA) based one-time password generation mechanism for Hypertext TransferProtocol (HTTP) Digest access authentication. The HTTPAuthentication Framework includes two authentication schemes: Basic and Digest. Both schemes employ a shared secret based mechanism for access authentication. The AKA mechanism performs user authentication and session key distribution in Universal MobileTelecommunications System (UMTS) networks. AKA is a challenge- response based mechanism that uses symmetric cryptography. |
|
| |
| RFC 3313 | Private Session Initiation Protocol (SIP) Extensions for Media Authorization |
| |
| Authors: | W. Marshall, Ed.. |
| Date: | January 2003 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3313 |
|
This document describes the need for Quality of Service (QoS) and media authorization and defines a Session Initiation Protocol (SIP) extension that can be used to integrate QoS admission control with call signaling and help guard against denial of service attacks. The use of this extension is only applicable in administrative domains, or among federations of administrative domains with previously agreed-upon policies, where both the SIP proxy authorizing the QoS, and the policy control of the underlying network providing the QoS, belong to that administrative domain or federation of domains. |
|
| |
| RFC 3314 | Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards |
| |
| Authors: | M. Wasserman, Ed.. |
| Date: | September 2002 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3314 |
|
This document contains recommendations from the Internet EngineeringTask Force (IETF) IPv6 Working Group to the Third GenerationPartnership Project (3GPP) community regarding the use of IPv6 in the3GPP standards. Specifically, this document recommends that the 3GPP specify that multiple prefixes may be assigned to each primary PDP context, require that a given prefix must not be assigned to more than one primary PDP context, and allow 3GPP nodes to use multiple identifiers within those prefixes, including randomly generated identifiers.
The IPv6 Working Group supports the use of IPv6 within 3GPP and offers these recommendations in a spirit of open cooperation between the IPv6 Working Group and the 3GPP community. Since the original publication of this document as an Internet-Draft, the 3GPP has adopted the primary recommendations of this document. |
|
| |
| RFC 3316 | Internet Protocol Version 6 (IPv6) for Some Second and Third Generation Cellular Hosts |
| |
| Authors: | J. Arkko, G. Kuijpers, H. Soliman, J. Loughney, J. Wiljakka. |
| Date: | April 2003 |
| Formats: | txt json html |
| Obsoleted by: | RFC 7066 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3316 |
|
As the deployment of second and third generation cellular networks progresses, a large number of cellular hosts are being connected to the Internet. Standardization organizations are making InternetProtocol version 6 (IPv6) mandatory in their specifications.However, the concept of IPv6 covers many aspects and numerous specifications. In addition, the characteristics of cellular links in terms of bandwidth, cost and delay put special requirements on howIPv6 is used. This document considers IPv6 for cellular hosts that attach to the General Packet Radio Service (GPRS), or UniversalMobile Telecommunications System (UMTS) networks. This document also lists basic components of IPv6 functionality and discusses some issues relating to the use of these components when operating in these networks. |
|
| |
| RFC 3322 | Signaling Compression (SigComp) Requirements & Assumptions |
| |
| Authors: | H. Hannu. |
| Date: | January 2003 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3322 |
|
The purpose of this document is to outline requirements and motivations for the development of a scheme for compression and decompression of messages from signaling protocols. In wireless environments and especially in cellular systems, e.g., GSM (GlobalSystem for Mobile communications) and UMTS (Universal MobileTelecommunications System), there is a need to maximize the transport efficiency for data over the radio interface. With the introduction of SIP/SDP (Session Initiation Protocol/Session Description Protocol) to cellular devices, compression of the signaling messages should be considered in order to improve both service availability and quality, mainly by reducing the user idle time, e.g., at call setup. |
|
| |
| RFC 3324 | Short Term Requirements for Network Asserted Identity |
| |
| Authors: | M. Watson. |
| Date: | November 2002 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3324 |
|
A Network Asserted Identity is an identity initially derived by aSession Initiation Protocol (SIP) network intermediary as a result of an authentication process. This document describes short term requirements for the exchange of Network Asserted Identities within networks of securely interconnected trusted nodes and to User Agents securely connected to such networks.
There is no requirement for identities asserted by a UA in a SIP message to be anything other than the user's desired alias. |
|
| |
| RFC 3325 | Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks |
| |
|
|
This document describes private extensions to the Session InitiationProtocol (SIP) that enable a network of trusted SIP servers to assert the identity of authenticated users, and the application of existing privacy mechanisms to the identity problem. The use of these extensions is only applicable inside an administrative domain with previously agreed-upon policies for generation, transport and usage of such information. This document does NOT offer a general privacy or identity model suitable for use between different trust domains, or use in the Internet at large. |
|
| |
| RFC 3330 | Special-Use IPv4 Addresses |
| |
|
|
This document describes the global and other specialized IPv4 address blocks that have been assigned by the Internet Assigned NumbersAuthority (IANA). It does not address IPv4 address space assigned to operators and users through the Regional Internet Registries. It also does not address allocations or assignments of IPv6 addresses or autonomous system numbers. |
|
| |
| RFC 3345 | Border Gateway Protocol (BGP) Persistent Route Oscillation Condition |
| |
| Authors: | D. McPherson, V. Gill, D. Walton, A. Retana. |
| Date: | August 2002 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3345 |
|
In particular configurations, the BGP scaling mechanisms defined in"BGP Route Reflection - An Alternative to Full Mesh IBGP" and"Autonomous System Confederations for BGP" will introduce persistentBGP route oscillation. This document discusses the two types of persistent route oscillation that have been identified, describes when these conditions will occur, and provides some network design guidelines to avoid introducing such occurrences. |
|
| |
| RFC 3346 | Applicability Statement for Traffic Engineering with MPLS |
| |
| Authors: | J. Boyle, V. Gill, A. Hannan, D. Cooper, D. Awduche, B. Christian, W.S. Lai. |
| Date: | August 2002 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3346 |
|
This document describes the applicability of Multiprotocol LabelSwitching (MPLS) to traffic engineering in IP networks. Special considerations for deployment of MPLS for traffic engineering in operational contexts are discussed and the limitations of the MPLS approach to traffic engineering are highlighted. |
|
| |
| RFC 3348 | The Internet Message Action Protocol (IMAP4) Child Mailbox Extension |
| |
| Authors: | M. Gahrns, R. Cheng. |
| Date: | July 2002 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3348 |
|
The Internet Message Action Protocol (IMAP4) CHILDREN extension provides a mechanism for a client to efficiently determine if a particular mailbox has children, without issuing a LIST "" * or aLIST "" % for each mailbox. |
|
| |
| RFC 3351 | User Requirements for the Session Initiation Protocol (SIP) in Support of Deaf, Hard of Hearing and Speech-impaired Individuals |
| |
| Authors: | N. Charlton, M. Gasson, G. Gybels, M. Spanner, A. van Wijk. |
| Date: | August 2002 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3351 |
|
This document presents a set of Session Initiation Protocol(SIP) user requirements that support communications for deaf, hard of hearing and speech-impaired individuals. These user requirements address the current difficulties of deaf, hard of hearing and speech-impaired individuals in using communications facilities, while acknowledging the multi-functional potential of SIP-based communications.
A number of issues related to these user requirements are further raised in this document.
Also included are some real world scenarios and some technical requirements to show the robustness of these requirements on a concept-level. |
|
| |
| RFC 3352 | Connection-less Lightweight Directory Access Protocol (CLDAP) to Historic Status |
| |
|
|
The Connection-less Lightweight Directory Access Protocol (CLDAP) technical specification, RFC 1798, was published in 1995 as aProposed Standard. This document discusses the reasons why the CLDAP technical specification has not been furthered on the Standard Track.This document recommends that RFC 1798 be moved to Historic status. |
|
| |
| RFC 3353 | Overview of IP Multicast in a Multi-Protocol Label Switching (MPLS) Environment |
| |
| Authors: | D. Ooms, B. Sales, W. Livens, A. Acharya, F. Griffoul, F. Ansari. |
| Date: | August 2002 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3353 |
|
This document offers a framework for IP multicast deployment in anMPLS environment. Issues arising when MPLS techniques are applied toIP multicast are overviewed. The pros and cons of existing IP multicast routing protocols in the context of MPLS are described and the relation to the different trigger methods and label distribution modes are discussed. The consequences of various layer 2 (L2) technologies are listed. Both point-to-point and multi-access networks are considered. |
|
| |
| RFC 3354 | Internet Open Trading Protocol Version 2 Requirements |
| |
| Authors: | D. Eastlake 3rd. |
| Date: | August 2002 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3354 |
|
This document gives requirements for the Internet Open TradingProtocol (IOTP) Version 2 by describing design principles and scope and dividing features into those which will, may, or will not be included.
Version 2 of the IOTP will extend the interoperable framework forInternet commerce capabilities of Version 1 while replacing the XML messaging and digital signature part of IOTP v1 with standards based mechanisms. |
|
| |
| RFC 3356 | Internet Engineering Task Force and International Telecommunication Union - Telecommunications Standardization Sector Collaboration Guidelines |
| |
|
|
This document provides guidance to aid in the understanding of collaboration on standards development between the InternationalTelecommunication Union -- Telecommunication Standardization Sector(ITU-T) and the Internet Society (ISOC) / Internet Engineering TaskForce (IETF). It is an update of and obsoletes RFC 2436. The updates reflect changes in the IETF and ITU-T since RFC 2436 was written. The bulk of this document is common text with ITU-TSupplement 3 to the ITU-T A-Series Recommendations.
Note: This was approved by ITU-T TSAG on 30 November 2001 as aSupplement to the ITU-T A-Series of Recommendations (will be numbered as A-Series Supplement 3). |
|
| |
| RFC 3357 | One-way Loss Pattern Sample Metrics |
| |
| Authors: | R. Koodli, R. Ravikanth. |
| Date: | August 2002 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3357 |
|
Using the base loss metric defined in RFC 2680, this document defines two derived metrics "loss distance" and "loss period", and the associated statistics that together capture loss patterns experienced by packet streams on the Internet. The Internet exhibits certain specific types of behavior (e.g., bursty packet loss) that can affect the performance seen by the users as well as the operators. The loss pattern or loss distribution is a key parameter that determines the performance observed by the users for certain real-time applications such as packet voice and video. For the same loss rate, two different loss distributions could potentially produce widely different perceptions of performance. |
|
| |
| RFC 3358 | Optional Checksums in Intermediate System to Intermediate System (ISIS) |
| |
| Authors: | T. Przygienda. |
| Date: | August 2002 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3358 |
|
This document describes an optional extension to the IntermediateSystem to Intermediate System (ISIS) protocol, used today by severalInternet Service Proviers (ISPs) for routing within their clouds.ISIS is an interior gateway routing protocol developed originally byOSI and used with IP extensions as Interior Gateway Protocol (IGP).ISIS originally does not provide Complete Sequence Numbers ProtocolData (CSNP) and Partial Sequence Numbers Protocol Data Unit (PSNP) checksums, relying on the underlying layers to verify the integrity of information provided. Experience with the protocol shows that this precondition does not always hold and scenarios can be imagined that impact protocol functionality. This document introduces a new optional Type, Length and Value (TLV) providing checksums. |
|
| |
| RFC 3359 | Reserved Type, Length and Value (TLV) Codepoints in Intermediate System to Intermediate System |
| |
| Authors: | T. Przygienda. |
| Date: | August 2002 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3359 |
|
This document describes implementation codepoints within IntermediateSystem to Intermediate System (IS-IS) used today by several ISPs for routing within their clouds. IS-IS is an interior gateway routing protocol developed originally by OSI and used with IP extensions asInterior Gateway Protocol (IGP). This document summarizes all Table,Length and Value (TLV) codepoints that are being used by the protocol and its pending extensions. |
|
| |
| RFC 3363 | Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS) |
| |
|
|
This document clarifies and updates the standards status of RFCs that define direct and reverse map of IPv6 addresses in DNS. This document moves the A6 and Bit label specifications to experimental status. |
|
| |
| RFC 3364 | Tradeoffs in Domain Name System (DNS) Support for Internet Protocol version 6 (IPv6) |
| |
|
|
The IETF has two different proposals on the table for how to do DNS support for IPv6, and has thus far failed to reach a clear consensus on which approach is better. This note attempts to examine the pros and cons of each approach, in the hope of clarifying the debate so that we can reach closure and move on. |
|
| |
| RFC 3373 | Three-Way Handshake for Intermediate System to Intermediate System (IS-IS) Point-to-Point Adjacencies |
| |
|
|
The IS-IS routing protocol (ISO 10589) requires reliable protocols at the link layer for point-to-point links. As a result, it does not use a three-way handshake when establishing adjacencies on point-to- point media. This paper defines a backward-compatible extension to the protocol that provides for a three-way handshake. It is fully interoperable with systems that do not support the extension.
Additionally, the extension allows the robust operation of more than256 point-to-point links on a single router.
This extension has been implemented by multiple router vendors; this paper is provided as information to the Internet community in order to allow interoperable implementations to be built by other vendors. |
|
| |
| RFC 3374 | Problem Description: Reasons For Performing Context Transfers Between Nodes in an IP Access Network |
| |
| Authors: | J. Kempf, Ed.. |
| Date: | September 2002 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3374 |
|
In IP access networks that support host mobility, the routing paths between the host and the network may change frequently and rapidly.In some cases, the host may establish certain context transfer candidate services on subnets that are left behind when the host moves. Examples of such services are Authentication, Authorization, and Accounting (AAA), header compression, and Quality of Service(QoS). In order for the host to obtain those services on the new subnet, the host must explicitly re-establish the service by performing the necessary signaling flows from scratch. In some cases, this process would considerably slow the process of establishing the mobile host on the new subnet. An alternative is to transfer information on the existing state associated with these services, or context, to the new subnet, a process called "context transfer". This document discusses the desirability of context transfer for facilitating seamless IP mobility. |
|
| |
| RFC 3375 | Generic Registry-Registrar Protocol Requirements |
| |
| Authors: | S. Hollenbeck. |
| Date: | September 2002 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3375 |
|
This document describes high-level functional and interface requirements for a client-server protocol for the registration and management of Internet domain names in shared registries. Specific technical requirements detailed for protocol design are not presented here. Instead, this document focuses on the basic functions and interfaces required of a protocol to support multiple registry and registrar operational models. |
|
| |
| RFC 3378 | EtherIP: Tunneling Ethernet Frames in IP Datagrams |
| |
| Authors: | R. Housley, S. Hollenbeck. |
| Date: | September 2002 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3378 |
|
This document describes the EtherIP, an early tunneling protocol, to provide informational and historical context for the assignment of IP protocol 97. EtherIP tunnels Ethernet and IEEE 802.3 media access control frames in IP datagrams so that non-IP traffic can traverse anIP internet. The protocol is very lightweight, and it does not provide protection against infinite loops. |
|
| |
| RFC 3379 | Delegated Path Validation and Delegated Path Discovery Protocol Requirements |
| |
| Authors: | D. Pinkas, R. Housley. |
| Date: | September 2002 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3379 |
|
This document specifies the requirements for Delegated PathValidation (DPV) and Delegated Path Discovery (DPD) for Public KeyCertificates. It also specifies the requirements for DPV and DPD policy management. |
|
| |
| RFC 3384 | Lightweight Directory Access Protocol (version 3) Replication Requirements |
| |
| Authors: | E. Stokes, R. Weiser, R. Moats, R. Huber. |
| Date: | October 2002 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3384 |
|
This document discusses the fundamental requirements for replication of data accessible via the Lightweight Directory Access Protocol(version 3) (LDAPv3). It is intended to be a gathering place for general replication requirements needed to provide interoperability between informational directories. |
|
| |
| RFC 3385 | Internet Protocol Small Computer System Interface (iSCSI) Cyclic Redundancy Check (CRC)/Checksum Considerations |
| |
| Authors: | D. Sheinwald, J. Satran, P. Thaler, V. Cavanna. |
| Date: | September 2002 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3385 |
|
In this memo, we attempt to give some estimates for the probability of undetected errors to facilitate the selection of an error detection code for the Internet Protocol Small Computer SystemInterface (iSCSI).
We will also attempt to compare Cyclic Redundancy Checks (CRCs) with other checksum forms (e.g., Fletcher, Adler, weighted checksums), as permitted by available data. |
|
| |
| RFC 3386 | Network Hierarchy and Multilayer Survivability |
| |
| Authors: | W. Lai, Ed., D. McDysan, Ed.. |
| Date: | November 2002 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3386 |
|
This document presents a proposal of the near-term and practical requirements for network survivability and hierarchy in current service provider environments. |
|
| |
| RFC 3387 | Considerations from the Service Management Research Group (SMRG) on Quality of Service (QoS) in the IP Network |
| |
| Authors: | M. Eder, H. Chaskar, S. Nag. |
| Date: | September 2002 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3387 |
|
The guiding principles in the design of IP network management were simplicity and no centralized control. The best effort service paradigm was a result of the original management principles and the other way around. New methods to distinguish the service given to one set of packets or flows relative to another are well underway.However, as IP networks evolve the management approach of the past may not apply to the Quality of Service (QoS)-capable network envisioned by some for the future. This document examines some of the areas of impact that QoS is likely to have on management and look at some questions that remain to be addressed. |
|
| |
| RFC 3391 | The MIME Application/Vnd.pwg-multiplexed Content-Type |
| |
| Authors: | R. Herriot. |
| Date: | December 2002 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3391 |
|
The Application/Vnd.pwg-multiplexed content-type, like theMultipart/Related content-type, provides a mechanism for representing objects that consist of multiple components. AnApplication/Vnd.pwg-multiplexed entity contains a sequence of chunks.Each chunk contains a MIME message or a part of a MIME message. EachMIME message represents a component of the compound object, just as a body part of a Multipart/Related entity represents a component. With a Multipart/Related entity, a body part and its reference in some other body part may be separated by many octets. With anApplication/Vnd.pwg-multiplexed entity, a message and its reference in some other message can be made quite close by chunking the message containing the reference. For example, if a long message contains references to images and the producer does not know of the need for each image until it generates the reference, thenApplication/Vnd.pwg-multiplexed allows the consumer to process the reference to the image and the image before it consumes the entire long message. This ability is important in printing and scanning applications. This document defines the Application/Vnd.pwg- multiplexed content-type. It also provides examples of its use. |
|
| |
| RFC 3394 | Advanced Encryption Standard (AES) Key Wrap Algorithm |
| |
| Authors: | J. Schaad, R. Housley. |
| Date: | September 2002 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3394 |
|
The purpose of this document is to make the Advanced EncryptionStandard (AES) Key Wrap algorithm conveniently available to theInternet community. The United States of America has adopted AES as the new encryption standard. The AES Key Wrap algorithm will probably be adopted by the USA for encryption of AES keys. The authors took most of the text in this document from the draft AES KeyWrap posted by NIST. |
|
| |
| RFC 3401 | Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS |
| |
|
|
This document specifies the exact documents that make up the completeDynamic Delegation Discovery System (DDDS). DDDS is an abstract algorithm for applying dynamically retrieved string transformation rules to an application-unique string.
This document along with RFC 3402, RFC 3403 and RFC 3404 obsolete RFC2168 and RFC 2915, as well as updates RFC 2276. |
|
| |
| RFC 3409 | Lower Layer Guidelines for Robust RTP/UDP/IP Header Compression |
| |
| Authors: | K. Svanbro. |
| Date: | December 2002 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3409 |
|
This document describes lower layer guidelines for robust header compression (ROHC) and the requirements ROHC puts on lower layers.The purpose of this document is to support the incorporation of robust header compression algorithms, as specified in the ROHC working group, into different systems such as those specified byThird Generation Partnership Project (3GPP), 3GPP Project 2 (3GPP2),European Technical Standards Institute (ETSI), etc. This document covers only lower layer guidelines for compression of RTP/UDP/IP andUDP/IP headers as specified in [RFC3095]. Both general guidelines and guidelines specific for cellular systems are discussed in this document. |
|
| |
| RFC 3410 | Introduction and Applicability Statements for Internet-Standard Management Framework |
| |
| Authors: | J. Case, R. Mundy, D. Partain, B. Stewart. |
| Date: | December 2002 |
| Formats: | txt json html |
| Obsoletes: | RFC 2570 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3410 |
|
The purpose of this document is to provide an overview of the third version of the Internet-Standard Management Framework, termed theSNMP version 3 Framework (SNMPv3). This Framework is derived from and builds upon both the original Internet-Standard ManagementFramework (SNMPv1) and the second Internet-Standard ManagementFramework (SNMPv2).
The architecture is designed to be modular to allow the evolution of the Framework over time.
The document explains why using SNMPv3 instead of SNMPv1 or SNMPv2 is strongly recommended. The document also recommends that RFCs 1157,1441, 1901, 1909 and 1910 be retired by moving them to Historic status. This document obsoletes RFC 2570. |
|
| |
| RFC 3422 | Forwarding Media Access Control (MAC) Frames over Multiple Access Protocol over Synchronous Optical Network/Synchronous Digital Hierarchy (MAPOS) |
| |
| Authors: | O. Okamoto, M. Maruyama, T. Sajima. |
| Date: | November 2002 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3422 |
|
This memo describes a method for forwarding media access control(MAC) frames over Multiple Access Protocol over Synchronous OpticalNetwork/Synchronous Digital Hierarchy (MAPOS), thus providing a way to unify MAPOS network environment and MAC-based Local Area Network(LAN) environment. |
|
| |
| RFC 3423 | XACCT's Common Reliable Accounting for Network Element (CRANE) Protocol Specification Version 1.0 |
| |
| Authors: | K. Zhang, E. Elkin. |
| Date: | November 2002 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3423 |
|
This document defines the Common Reliable Accounting for NetworkElement (CRANE) protocol that enables efficient and reliable delivery of any data, mainly accounting data from Network Elements to any systems, such as mediation systems and Business Support Systems(BSS)/ Operations Support Systems (OSS). The protocol is developed to address the critical needs for exporting high volume of accounting data from NE's with efficient use of network, storage, and processing resources.
This document specifies the architecture of the protocol and the message format, which MUST be supported by all CRANE protocol implementations. |
|
| |
| RFC 3424 | IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation |
| |
| Authors: | L. Daigle, Ed., IAB. |
| Date: | November 2002 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3424 |
|
As a result of the nature of Network Address Translation (NAT)Middleboxes, communicating endpoints that are separated by one or more NATs do not know how to refer to themselves using addresses that are valid in the addressing realms of their (current and future) peers. Various proposals have been made for "UNilateral Self-AddressFixing (UNSAF)" processes. These are processes whereby some originating endpoint attempts to determine or fix the address (and port) by which it is known to another endpoint - e.g. to be able to use address data in the protocol exchange, or to advertise a public address from which it will receive connections.
This document outlines the reasons for which these proposals can be considered at best as short term fixes to specific problems and the specific issues to be carefully evaluated before creating an UNSAF proposal. |
|
| |
| RFC 3426 | General Architectural and Policy Considerations |
| |
| Authors: | S. Floyd. |
| Date: | November 2002 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3426 |
|
This document suggests general architectural and policy questions that the IETF community has to address when working on new standards and protocols. We note that this document contains questions to be addressed, as opposed to guidelines or architectural principles to be followed. |
|
| |
| RFC 3429 | Assignment of the 'OAM Alert Label' for Multiprotocol Label Switching Architecture (MPLS) Operation and Maintenance (OAM) Functions |
| |
| Authors: | H. Ohta. |
| Date: | November 2002 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3429 |
|
This document describes the assignment of one of the reserved label values defined in RFC 3032 (MPLS label stack encoding) to the'Operation and Maintenance (OAM) Alert Label' that is used by user- plane Multiprotocol Label Switching Architecture (MPLS) OAM functions for identification of MPLS OAM packets. |
|
| |
| RFC 3435 | Media Gateway Control Protocol (MGCP) Version 1.0 |
| |
|
|
This document describes an application programming interface and a corresponding protocol (MGCP) which is used between elements of a decomposed multimedia gateway. The decomposed multimedia gateway consists of a Call Agent, which contains the call control"intelligence", and a media gateway which contains the media functions, e.g., conversion from TDM voice to Voice over IP.
Media gateways contain endpoints on which the Call Agent can create, modify and delete connections in order to establish and control media sessions with other multimedia endpoints. Also, the Call Agent can instruct the endpoints to detect certain events and generate signals.The endpoints automatically communicate changes in service state to the Call Agent. Furthermore, the Call Agent can audit endpoints as well as the connections on endpoints.
The basic and general MGCP protocol is defined in this document, however most media gateways will need to implement one or more MGCP packages, which define extensions to the protocol suitable for use with specific types of media gateways. Such packages are defined in separate documents. |
|
| |
| RFC 3439 | Some Internet Architectural Guidelines and Philosophy |
| |
|
|
This document extends RFC 1958 by outlining some of the philosophical guidelines to which architects and designers of Internet backbone networks should adhere. We describe the Simplicity Principle, which states that complexity is the primary mechanism that impedes efficient scaling, and discuss its implications on the architecture, design and engineering issues found in large scale Internet backbones. |
|
| |
| RFC 3441 | Asynchronous Transfer Mode (ATM) Package for the Media Gateway Control Protocol (MGCP) |
| |
| Authors: | R. Kumar. |
| Date: | January 2003 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3441 |
|
This document describes an Asynchronous Transfer Mode (ATM) package for the Media Gateway Control Protocol (MGCP). This package includes new Local Connection Options, ATM-specific events and signals, andATM connection parameters. Also included is a description of codec and profile negotiation. It extends the MGCP that is currently being deployed in a number of products. Implementers should be aware of developments in the IETF Megaco Working Group and ITU SG16, which are currently working on a potential successor to this protocol. |
|
| |
| RFC 3444 | On the Difference between Information Models and Data Models |
| |
| Authors: | A. Pras, J. Schoenwaelder. |
| Date: | January 2003 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3444 |
|
There has been ongoing confusion about the differences betweenInformation Models and Data Models for defining managed objects in network management. This document explains the differences between these terms by analyzing how existing network management model specifications (from the IETF and other bodies such as theInternational Telecommunication Union (ITU) or the DistributedManagement Task Force (DMTF)) fit into the universe of InformationModels and Data Models.
This memo documents the main results of the 8th workshop of theNetwork Management Research Group (NMRG) of the Internet ResearchTask Force (IRTF) hosted by the University of Texas at Austin. |
|
| |
| RFC 3446 | Anycast Rendevous Point (RP) mechanism using Protocol Independent Multicast (PIM) and Multicast Source Discovery Protocol (MSDP) |
| |
| Authors: | D. Kim, D. Meyer, H. Kilmer, D. Farinacci. |
| Date: | January 2003 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3446 |
|
This document describes a mechanism to allow for an arbitrary number of Rendevous Points (RPs) per group in a single shared-tree ProtocolIndependent Multicast-Sparse Mode (PIM-SM) domain. |
|
| |
| RFC 3447 | Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1 |
| |
|
|
This memo represents a republication of PKCS #1 v2.1 from RSALaboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document is taken directly from the PKCS #1 v2.1 document, with certain corrections made during the publication process. |
|
| |
| RFC 3453 | The Use of Forward Error Correction (FEC) in Reliable Multicast |
| |
| Authors: | M. Luby, L. Vicisano, J. Gemmell, L. Rizzo, M. Handley, J. Crowcroft. |
| Date: | December 2002 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3453 |
|
This memo describes the use of Forward Error Correction (FEC) codes to efficiently provide and/or augment reliability for one-to-many reliable data transport using IP multicast. One of the key properties of FEC codes in this context is the ability to use the same packets containing FEC data to simultaneously repair different packet loss patterns at multiple receivers. Different classes of FEC codes and some of their basic properties are described and terminology relevant to implementing FEC in a reliable multicast protocol is introduced. Examples are provided of possible abstract formats for packets carrying FEC. |
|
| |
| RFC 3455 | Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP) |
| |
| Authors: | M. Garcia-Martin, E. Henrikson, D. Mills. |
| Date: | January 2003 |
| Formats: | txt html json |
| Obsoleted by: | RFC 7315 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3455 |
|
This document describes a set of private Session Initiation Protocol(SIP) headers (P-headers) used by the 3rd-Generation PartnershipProject (3GPP), along with their applicability, which is limited to particular environments. The P-headers are for a variety of purposes within the networks that the partners use, including charging and information about the networks a call traverses. |
|
| |
| RFC 3457 | Requirements for IPsec Remote Access Scenarios |
| |
| Authors: | S. Kelly, S. Ramamoorthi. |
| Date: | January 2003 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3457 |
|
IPsec offers much promise as a secure remote access mechanism.However, there are a number of differing remote access scenarios, each having some shared and some unique requirements. A thorough understanding of these requirements is necessary in order to effectively evaluate the suitability of a specific set of mechanisms for any particular remote access scenario. This document enumerates the requirements for a number of common remote access scenarios. |
|
| |
| RFC 3466 | A Model for Content Internetworking (CDI) |
| |
| Authors: | M. Day, B. Cain, G. Tomlinson, P. Rzewski. |
| Date: | February 2003 |
| Formats: | txt json html |
| Obsoleted by: | RFC 7336 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3466 |
|
Content (distribution) internetworking (CDI) is the technology for interconnecting content networks, sometimes previously called"content peering" or "CDN peering". A common vocabulary helps the process of discussing such interconnection and interoperation. This document introduces content networks and content internetworking, and defines elements for such a common vocabulary. |
|
| |
| RFC 3467 | Role of the Domain Name System (DNS) |
| |
| Authors: | J. Klensin. |
| Date: | February 2003 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3467 |
|
This document reviews the original function and purpose of the domain name system (DNS). It contrasts that history with some of the purposes for which the DNS has recently been applied and some of the newer demands being placed upon it or suggested for it. A framework for an alternative to placing these additional stresses on the DNS is then outlined. This document and that framework are not a proposed solution, only a strong suggestion that the time has come to begin thinking more broadly about the problems we are encountering and possible approaches to solving them. |
|
| |
| RFC 3468 | The Multiprotocol Label Switching (MPLS) Working Group decision on MPLS signaling protocols |
| |
|
|
This document documents the consensus reached by the MultiprotocolLabel Switching (MPLS) Working Group within the IETF to focus its efforts on "Resource Reservation Protocol (RSVP)-TE: Extensions toRSVP for Label-Switched Paths (LSP) Tunnels" (RFC 3209) as the MPLS signalling protocol for traffic engineering applications and to undertake no new efforts relating to "Constraint-Based LSP Setup using Label Distribution Protocol (LDP)" (RFC 3212). The recommendations of section 6 have been accepted by the IESG. |
|
| |
| RFC 3469 | Framework for Multi-Protocol Label Switching (MPLS)-based Recovery |
| |
| Authors: | V. Sharma, Ed., F. Hellstrand, Ed.. |
| Date: | February 2003 |
| Formats: | txt html json |
| Updated by: | RFC 5462 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3469 |
|
Multi-protocol label switching (MPLS) integrates the label swapping forwarding paradigm with network layer routing. To deliver reliable service, MPLS requires a set of procedures to provide protection of the traffic carried on different paths. This requires that the label switching routers (LSRs) support fault detection, fault notification, and fault recovery mechanisms, and that MPLS signaling support the configuration of recovery. With these objectives in mind, this document specifies a framework for MPLS based recovery. Restart issues are not included in this framework. |
|
| |
| RFC 3474 | Documentation of IANA assignments for Generalized MultiProtocol Label Switching (GMPLS) Resource Reservation Protocol - Traffic Engineering (RSVP-TE) Usage and Extensions for Automatically Switched Optical Network (ASON) |
| |
| Authors: | Z. Lin, D. Pendarakis. |
| Date: | March 2003 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3474 |
|
The Generalized MultiProtocol Label Switching (GMPLS) suite of protocol specifications has been defined to provide support for different technologies as well as different applications. These include support for requesting TDM connections based on SynchronousOptical NETwork/Synchronous Digital Hierarchy (SONET/SDH) as well asOptical Transport Networks (OTNs).
This document concentrates on the signaling aspects of the GMPLS suite of protocols, specifically GMPLS signaling using ResourceReservation Protocol - Traffic Engineering (RSVP-TE). It proposes additional extensions to these signaling protocols to support the capabilities of an ASON network.
This document proposes appropriate extensions towards the resolution of additional requirements identified and communicated by the ITU-TStudy Group 15 in support of ITU's ASON standardization effort. |
|
| |
| RFC 3475 | Documentation of IANA assignments for Constraint-Based LSP setup using LDP (CR-LDP) Extensions for Automatic Switched Optical Network (ASON) |
| |
|
|
Automatic Switched Optical Network (ASON) is an architecture, specified by ITU-T Study Group 15, for the introduction of a control plane for optical networks. The ASON architecture specifies a set of reference points that defines the relationship between the ASON architectural entities. Signaling over interfaces defined in those reference points can make use of protocols that are defined by theIETF in the context of Generalized Multi-Protocol Label Switching(GMPLS) work. This document describes Constraint-Based LSP setup using LDP (CR-LDP) extensions for signaling over the interfaces defined in the ASON reference points. The purpose of the document is to request that the IANA assigns code points necessary for the CR-LDP extensions. The protocol specifications for the use of the CR-LDP extensions are found in ITU-T documents. |
|
| |
| RFC 3476 | Documentation of IANA Assignments for Label Distribution Protocol (LDP), Resource ReSerVation Protocol (RSVP), and Resource ReSerVation Protocol-Traffic Engineering (RSVP-TE) Extensions for Optical UNI Signaling |
| |
|
|
The Optical Interworking Forum (OIF) has defined extensions to theLabel Distribution Protocol (LDP) and the Resource ReSerVationProtocol (RSVP) for optical User Network Interface (UNI) signaling.These extensions consist of a set of new data objects and error codes. This document describes these extensions. |
|
| |
| RFC 3482 | Number Portability in the Global Switched Telephone Network (GSTN): An Overview |
| |
| Authors: | M. Foster, T. McGarry, J. Yu. |
| Date: | February 2003 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3482 |
|
This document provides an overview of E.164 telephone number portability (NP) in the Global Switched Telephone Network (GSTN).NP is a regulatory imperative seeking to liberalize local telephony service competition, by enabling end-users to retain telephone numbers while changing service providers. NP changes the fundamental nature of a dialed E.164 number from a hierarchical physical routing address to a virtual address, thereby requiring the transparent translation of the later to the former. In addition, there are various regulatory constraints that establish relevant parameters forNP implementation, most of which are not network technology specific.Consequently, the implementation of NP behavior consistent with applicable regulatory constraints, as well as the need for interoperation with the existing GSTN NP implementations, are relevant topics for numerous areas of IP telephony works-in-progress with the IETF. |
|
| |
| RFC 3483 | Framework for Policy Usage Feedback for Common Open Policy Service with Policy Provisioning (COPS-PR) |
| |
| Authors: | D. Rawlins, A. Kulkarni, M. Bokaemper, K. Chan. |
| Date: | March 2003 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3483 |
|
Common Open Policy Services (COPS) Protocol (RFC 2748), defines the capability of reporting information to the Policy Decision Point(PDP). The types of report information are success, failure and accounting of an installed state. This document focuses on the COPSReport Type of Accounting and the necessary framework for the monitoring and reporting of usage feedback for an installed state. |
|
| |
| RFC 3487 | Requirements for Resource Priority Mechanisms for the Session Initiation Protocol (SIP) |
| |
| Authors: | H. Schulzrinne. |
| Date: | February 2003 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3487 |
|
This document summarizes requirements for prioritizing access to circuit-switched network, end system and proxy resources for emergency preparedness communications using the Session InitiationProtocol (SIP). |
|
| |
| RFC 3488 | Cisco Systems Router-port Group Management Protocol (RGMP) |
| |
| Authors: | I. Wu, T. Eckert. |
| Date: | February 2003 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3488 |
|
This document describes the Router-port Group Management Protocol(RGMP). This protocol was developed by Cisco Systems and is used between multicast routers and switches to restrict multicast packet forwarding in switches to those routers where the packets may be needed.
RGMP is designed for backbone switched networks where multiple, high speed routers are interconnected. |
|
| |
| RFC 3493 | Basic Socket Interface Extensions for IPv6 |
| |
| Authors: | R. Gilligan, S. Thomson, J. Bound, J. McCann, W. Stevens. |
| Date: | February 2003 |
| Formats: | txt json html |
| Obsoletes: | RFC 2553 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3493 |
|
The de facto standard Application Program Interface (API) for TCP/IP applications is the "sockets" interface. Although this API was developed for Unix in the early 1980s it has also been implemented on a wide variety of non-Unix systems. TCP/IP applications written using the sockets API have in the past enjoyed a high degree of portability and we would like the same portability with IPv6 applications. But changes are required to the sockets API to supportIPv6 and this memo describes these changes. These include a new socket address structure to carry IPv6 addresses, new address conversion functions, and some new socket options. These extensions are designed to provide access to the basic IPv6 features required byTCP and UDP applications, including multicasting, while introducing a minimum of change into the system and providing complete compatibility for existing IPv4 applications. Additional extensions for advanced IPv6 features (raw sockets and access to the IPv6 extension headers) are defined in another document. |
|
| |
| RFC 3494 | Lightweight Directory Access Protocol version 2 (LDAPv2) to Historic Status |
| |
|
|
This document recommends the retirement of version 2 of theLightweight Directory Access Protocol (LDAPv2) and other dependent specifications, and discusses the reasons for doing so. This document recommends RFC 1777, 1778, 1779, 1781, and 2559 (as well as documents they superseded) be moved to Historic status. |
|
| |
| RFC 3496 | Protocol Extension for Support of Asynchronous Transfer Mode (ATM) Service Class-aware Multiprotocol Label Switching (MPLS) Traffic Engineering |
| |
| Authors: | A. G. Malis, T. Hsiao. |
| Date: | March 2003 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3496 |
|
This document specifies a Resource ReSerVation Protocol-TrafficEngineering (RSVP-TE) signaling extension for support of AsynchronousTransfer Mode (ATM) Service Class-aware Multiprotocol Label Switching(MPLS) Traffic Engineering. |
|
| |
| RFC 3499 | Request for Comments Summary RFC Numbers 3400-3499 |
| |
| Authors: | S. Ginoza. |
| Date: | December 2003 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3499 |
|
|
|
| |
| RFC 3504 | Internet Open Trading Protocol (IOTP) Version 1, Errata |
| |
| Authors: | D. Eastlake. |
| Date: | March 2003 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3504 |
|
Since the publication of the RFCs specifying Version 1.0 of theInternet Open Trading Protocol (IOTP), some errors have been noted.This informational document lists these errors and provides corrections for them. |
|
| |
| RFC 3505 | Electronic Commerce Modeling Language (ECML): Version 2 Requirements |
| |
| Authors: | D. Eastlake. |
| Date: | March 2003 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3505 |
|
This document lists the design principles, scope, and requirements for the Electronic Commerce Modeling Language (ECML) version 2 specification. It includes requirements as they relate to ExtensibleMarkup Language (XML) syntax, data model, format, and payment processing. |
|
| |
| RFC 3506 | Requirements and Design for Voucher Trading System (VTS) |
| |
| Authors: | K. Fujimura, D. Eastlake. |
| Date: | March 2003 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3506 |
|
Crediting loyalty points and collecting digital coupons or gift certificates are common functions in purchasing and trading transactions. These activities can be generalized using the concept of a "voucher", which is a digital representation of the right to claim goods or services. This document presents a Voucher TradingSystem (VTS) that circulates vouchers securely and its terminology; it lists design principles and requirements for VTS and the GenericVoucher Language (GVL), with which diverse types of vouchers can be described. |
|
| |
| RFC 3507 | Internet Content Adaptation Protocol (ICAP) |
| |
| Authors: | J. Elson, A. Cerpa. |
| Date: | April 2003 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3507 |
|
ICAP, the Internet Content Adaption Protocol, is a protocol aimed at providing simple object-based content vectoring for HTTP services.ICAP is, in essence, a lightweight protocol for executing a "remote procedure call" on HTTP messages. It allows ICAP clients to passHTTP messages to ICAP servers for some sort of transformation or other processing ("adaptation"). The server executes its transformation service on messages and sends back responses to the client, usually with modified messages. Typically, the adapted messages are either HTTP requests or HTTP responses. |
|
| |
| RFC 3508 | H.323 Uniform Resource Locator (URL) Scheme Registration |
| |
| Authors: | O. Levin. |
| Date: | April 2003 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3508 |
|
ITU-T Recommendation H.323 version 4 introduced an H.323-specificUniform Resource Locator (URL). This document reproduces the H323-URL definition found in H.323, and is published as an RFC for ease of access and registration with the Internet Assigned Numbers Authority(IANA). |
|
| |
| RFC 3509 | Alternative Implementations of OSPF Area Border Routers |
| |
| Authors: | A. Zinin, A. Lindem, D. Yeung. |
| Date: | April 2003 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3509 |
|
Open Shortest Path First (OSPF) is a link-state intra-domain routing protocol used for routing in IP networks. Though the definition of the Area Border Router (ABR) in the OSPF specification does not require a router with multiple attached areas to have a backbone connection, it is actually necessary to provide successful routing to the inter-area and external destinations. If this requirement is not met, all traffic destined for the areas not connected to such an ABR or out of the OSPF domain, is dropped. This document describes alternative ABR behaviors implemented in Cisco and IBM routers. |
|
| |
| RFC 3511 | Benchmarking Methodology for Firewall Performance |
| |
| Authors: | B. Hickman, D. Newman, S. Tadjudin, T. Martin. |
| Date: | April 2003 |
| Formats: | txt html json |
| Obsoleted by: | RFC 9411 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3511 |
|
This document discusses and defines a number of tests that may be used to describe the performance characteristics of firewalls. In addition to defining the tests, this document also describes specific formats for reporting the results of the tests.
This document is a product of the Benchmarking Methodology WorkingGroup (BMWG) of the Internet Engineering Task Force (IETF). |
|
| |
| RFC 3512 | Configuring Networks and Devices with Simple Network Management Protocol (SNMP) |
| |
| Authors: | M. MacFaden, D. Partain, J. Saperia, W. Tackabury. |
| Date: | April 2003 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3512 |
|
This document is written for readers interested in the InternetStandard Management Framework and its protocol, the Simple NetworkManagement Protocol (SNMP). In particular, it offers guidance in the effective use of SNMP for configuration management. This information is relevant to vendors that build network elements, management application developers, and those that acquire and deploy this technology in their networks. |
|
| |
| RFC 3514 | The Security Flag in the IPv4 Header |
| |
| Authors: | S. Bellovin. |
| Date: | 1 April 2003 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3514 |
|
Firewalls, packet filters, intrusion detection systems, and the like often have difficulty distinguishing between packets that have malicious intent and those that are merely unusual. We define a security flag in the IPv4 header as a means of distinguishing the two cases. |
|
| |
| RFC 3521 | Framework for Session Set-up with Media Authorization |
| |
| Authors: | L-N. Hamer, B. Gage, H. Shieh. |
| Date: | April 2003 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3521 |
|
Establishing multimedia streams must take into account requirements for end-to-end QoS, authorization of network resource usage and accurate accounting for resources used. During session set up, policies may be enforced to ensure that the media streams being requested lie within the bounds of the service profile established for the requesting host. Similarly, when a host requests resources to provide a certain QoS for a packet flow, policies may be enforced to ensure that the required resources lie within the bounds of the resource profile established for the requesting host.
To prevent fraud and to ensure accurate billing, this document describes various scenarios and mechanisms that provide the linkage required to verify that the resources being used to provide a requested QoS are in-line with the media streams requested (and authorized) for the session. |
|
| |
| RFC 3523 | Internet Emergency Preparedness (IEPREP) Telephony Topology Terminology |
| |
| Authors: | J. Polk. |
| Date: | April 2003 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3523 |
|
This document defines the topology naming conventions that are to be used in reference to Internet Emergency Preparedness (IEPREP) phone calls. These naming conventions should be used to focus the IEPREPWorking Group during discussions and when writing requirements, gap analysis and other solutions documents. |
|
| |
| RFC 3531 | A Flexible Method for Managing the Assignment of Bits of an IPv6 Address Block |
| |
| Authors: | M. Blanchet. |
| Date: | April 2003 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3531 |
|
This document proposes a method to manage the assignment of bits of an IPv6 address block or range. When an organisation needs to make an address plan for its subnets or when an ISP needs to make an address plan for its customers, this method enables the organisation to postpone the final decision on the number of bits to partition in the address space they have. It does it by keeping the bits around the borders of the partition to be free as long as possible. This scheme is applicable to any bits addressing scheme using bits with partitions in the space, but its first intended use is for IPv6. It is a generalization of RFC 1219 and can be used for IPv6 assignments. |
|
| |
| RFC 3532 | Requirements for the Dynamic Partitioning of Switching Elements |
| |
| Authors: | T. Anderson, J. Buerkle. |
| Date: | May 2003 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3532 |
|
This document identifies a set of requirements for the mechanisms used to dynamically reallocate the resources of a switching element(e.g., an ATM switch) to its partitions. These requirements are particularly critical in the case of an operator creating a switch partition and then leasing control of that partition to a third party. |
|
| |
| RFC 3533 | The Ogg Encapsulation Format Version 0 |
| |
| Authors: | S. Pfeiffer. |
| Date: | May 2003 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3533 |
|
This document describes the Ogg bitstream format version 0, which is a general, freely-available encapsulation format for media streams.It is able to encapsulate any kind and number of video and audio encoding formats as well as other data streams in a single bitstream. |
|
| |
| RFC 3535 | Overview of the 2002 IAB Network Management Workshop |
| |
| Authors: | J. Schoenwaelder. |
| Date: | May 2003 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3535 |
|
This document provides an overview of a workshop held by the InternetArchitecture Board (IAB) on Network Management. The workshop was hosted by CNRI in Reston, VA, USA on June 4 thru June 6, 2002. The goal of the workshop was to continue the important dialog started between network operators and protocol developers, and to guide theIETFs focus on future work regarding network management. This report summarizes the discussions and lists the conclusions and recommendations to the Internet Engineering Task Force (IETF) community. |
|
| |
| RFC 3536 | Terminology Used in Internationalization in the IETF |
| |
|
|
This document provides a glossary of terms used in the IETF when discussing internationalization. The purpose is to help frame discussions of internationalization in the various areas of the IETF and to help introduce the main concepts to IETF participants. |
|
| |
| RFC 3538 | Secure Electronic Transaction (SET) Supplement for the v1.0 Internet Open Trading Protocol (IOTP) |
| |
| Authors: | Y. Kawatsura. |
| Date: | June 2003 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3538 |
|
This document describes detailed Input/Output parameters for theInternet Open Trading Protocol (IOTP) Payment Application ProgrammingInterface (API). It also describes procedures in the Payment Bridge for the use of SET (SET Secure Electronic Transaction) as the payment protocol within Version 1.0 of the IOTP. |
|
| |
| RFC 3541 | A Uniform Resource Name (URN) Namespace for the Web3D Consortium (Web3D) |
| |
| Authors: | A. Walsh. |
| Date: | May 2003 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3541 |
|
This document describes a Uniform Resource Name (URN) namespace for the Web3D Consortium (Web3D) for naming persistent resources such as technical documents and specifications, Virtual Reality ModelingLanguage (VRML) and Extensible 3D (X3D) files and resources,Extensible Markup Language (XML) Document Type Definitions (DTDs),XML Schemas, namespaces, style sheets, media assets, and other resources produced or managed by Web3D. |
|
| |
| RFC 3542 | Advanced Sockets Application Program Interface (API) for IPv6 |
| |
| Authors: | W. Stevens, M. Thomas, E. Nordmark, T. Jinmei. |
| Date: | May 2003 |
| Formats: | txt html json |
| Obsoletes: | RFC 2292 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3542 |
|
This document provides sockets Application Program Interface (API) to support "advanced" IPv6 applications, as a supplement to a separate specification, RFC 3493. The expected applications include Ping,Traceroute, routing daemons and the like, which typically use raw sockets to access IPv6 or ICMPv6 header fields. This document proposes some portable interfaces for applications that use raw sockets under IPv6. There are other features of IPv6 that some applications will need to access: interface identification(specifying the outgoing interface and determining the incoming interface), IPv6 extension headers, and path Maximum TransmissionUnit (MTU) information. This document provides API access to these features too. Additionally, some extended interfaces to libraries for the "r" commands are defined. The extension will provide better backward compatibility to existing implementations that are notIPv6-capable. |
|
| |
| RFC 3548 | The Base16, Base32, and Base64 Data Encodings |
| |
|
|
This document describes the commonly used base 64, base 32, and base16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, and use of different encoding alphabets. |
|
| |
| RFC 3549 | Linux Netlink as an IP Services Protocol |
| |
| Authors: | J. Salim, H. Khosravi, A. Kleen, A. Kuznetsov. |
| Date: | July 2003 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3549 |
|
This document describes Linux Netlink, which is used in Linux both as an intra-kernel messaging system as well as between kernel and user space. The focus of this document is to describe Netlink's functionality as a protocol between a Forwarding Engine Component(FEC) and a Control Plane Component (CPC), the two components that define an IP service. As a result of this focus, this document ignores other uses of Netlink, including its use as a intra-kernel messaging system, as an inter-process communication scheme (IPC), or as a configuration tool for other non-networking or non-IP network services (such as decnet, etc.).
This document is intended as informational in the context of prior art for the ForCES IETF working group. |
|
| |
| RFC 3562 | Key Management Considerations for the TCP MD5 Signature Option |
| |
| Authors: | M. Leech. |
| Date: | July 2003 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3562 |
|
The TCP MD5 Signature Option (RFC 2385), used predominantly by BGP, has seen significant deployment in critical areas of Internet infrastructure. The security of this option relies heavily on the quality of the keying material used to compute the MD5 signature.This document addresses the security requirements of that keying material. |
|
| |
| RFC 3563 | Cooperative Agreement Between the ISOC/IETF and ISO/IEC Joint Technical Committee 1/Sub Committee 6 (JTC1/SC6) on IS-IS Routing Protocol Development |
| |
|
|
This document contains the text of the agreement signed betweenISOC/IETF and ISO/IEC JTC1/SC6 regarding cooperative development of the IS-IS routing protocol. The agreement includes definitions of the related work scopes for the two organizations, request for creation and maintenance of an IS-IS registry by IANA, as well as collaboration guidelines. |
|
| |
| RFC 3564 | Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering |
| |
|
|
This document presents Service Provider requirements for support ofDifferentiated Services (Diff-Serv)-aware MPLS Traffic Engineering(DS-TE).
Its objective is to provide guidance for the definition, selection and specification of a technical solution addressing these requirements. Specification for this solution itself is outside the scope of this document.
A problem statement is first provided. Then, the document describes example applications scenarios identified by Service Providers where existing MPLS Traffic Engineering mechanisms fall short andDiff-Serv-aware Traffic Engineering can address the needs. The detailed requirements that need to be addressed by the technical solution are also reviewed. Finally, the document identifies the evaluation criteria that should be considered for selection and definition of the technical solution. |
|
| |
| RFC 3567 | Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication |
| |
|
|
This document describes the authentication of Intermediate System toIntermediate System (IS-IS) Protocol Data Units (PDUs) using theHashed Message Authentication Codes - Message Digest 5 (HMAC-MD5) algorithm as found in RFC 2104. IS-IS is specified in InternationalStandards Organization (ISO) 10589, with extensions to supportInternet Protocol version 4 (IPv4) described in RFC 1195. The base specification includes an authentication mechanism that allows for multiple authentication algorithms. The base specification only specifies the algorithm for cleartext passwords.
This document proposes an extension to that specification that allows the use of the HMAC-MD5 authentication algorithm to be used in conjunction with the existing authentication mechanisms. |
|
| |
| RFC 3568 | Known Content Network (CN) Request-Routing Mechanisms |
| |
| Authors: | A. Barbir, B. Cain, R. Nair, O. Spatscheck. |
| Date: | July 2003 |
| Formats: | txt json html |
| Updated by: | RFC 8996 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3568 |
|
This document presents a summary of Request-Routing techniques that are used to direct client requests to surrogates based on various policies and a possible set of metrics. The document covers techniques that were commonly used in the industry on or beforeDecember 2000. In this memo, the term Request-Routing represents techniques that is commonly called content routing or content redirection. In principle, Request-Routing techniques can be classified under: DNS Request-Routing, Transport-layerRequest-Routing, and Application-layer Request-Routing. |
|
| |
| RFC 3569 | An Overview of Source-Specific Multicast (SSM) |
| |
| Authors: | S. Bhattacharyya, Ed.. |
| Date: | July 2003 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3569 |
|
The purpose of this document is to provide an overview ofSource-Specific Multicast (SSM) and issues related to its deployment.It discusses how the SSM service model addresses the challenges faced in inter-domain multicast deployment, changes needed to routing protocols and applications to deploy SSM and interoperability issues with current multicast service models. |
|
| |
| RFC 3570 | Content Internetworking (CDI) Scenarios |
| |
| Authors: | P. Rzewski, M. Day, D. Gilletti. |
| Date: | July 2003 |
| Formats: | txt json html |
| Obsoleted by: | RFC 6770 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3570 |
|
In describing content internetworking as a technology targeted for use in production networks, it is useful to provide examples of the sequence of events that may occur when two content networks decide to interconnect. The scenarios presented here seek to provide some concrete examples of what content internetworking is, and also to provide a basis for evaluating content internetworking proposals. |
|
| |
| RFC 3572 | Internet Protocol Version 6 over MAPOS (Multiple Access Protocol Over SONET/SDH) |
| |
| Authors: | T. Ogura, M. Maruyama, T. Yoshida. |
| Date: | July 2003 |
| Formats: | txt html json |
| Updated by: | RFC 8064 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3572 |
|
Multiple Access Protocol over SONET/SDH (MAPOS) is a high-speed link-layer protocol that provides multiple access capability over aSynchronous Optical NETwork/Synchronous Digital Hierarchy(SONET/SDH).
This document specifies the frame format for encapsulating an IPv6 datagram in a MAPOS frame. It also specifies the method of formingIPv6 interface identifiers, the method of detecting duplicate addresses, and the format of the Source/Target Link-layer Addresses option field used in IPv6 Neighbor Discovery messages. |
|
| |
| RFC 3574 | Transition Scenarios for 3GPP Networks |
| |
| Authors: | J. Soininen, Ed.. |
| Date: | August 2003 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3574 |
|
This document describes different scenarios in Third GenerationPartnership Project (3GPP) defined packet network, i.e., GeneralPacket Radio Service (GPRS) that would need IP version 6 and IP version 4 transition. The focus of this document is on the scenarios where the User Equipment (UE) connects to nodes in other networks, e.g., in the Internet. GPRS network internal transition scenarios, i.e., between different GPRS elements in the network, are out of scope. The purpose of the document is to list the scenarios for further discussion and study. |
|
| |
| RFC 3576 | Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS) |
| |
| Authors: | M. Chiba, G. Dommety, M. Eklund, D. Mitton, B. Aboba. |
| Date: | July 2003 |
| Formats: | txt html json |
| Obsoleted by: | RFC 5176 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3576 |
|
This document describes a currently deployed extension to the RemoteAuthentication Dial In User Service (RADIUS) protocol, allowing dynamic changes to a user session, as implemented by network access server products. This includes support for disconnecting users and changing authorizations applicable to a user session. |
|
| |
| RFC 3577 | Introduction to the Remote Monitoring (RMON) Family of MIB Modules |
| |
| Authors: | S. Waldbusser, R. Cole, C. Kalbfleisch, D. Romascanu. |
| Date: | August 2003 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3577 |
|
The Remote Monitoring (RMON) Framework consists of a number of interrelated documents. This memo describes these documents and how they relate to one another. |
|
| |
| RFC 3579 | RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP) |
| |
|
|
This document defines Remote Authentication Dial In User Service(RADIUS) support for the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication mechanisms. In the proposed scheme, the Network Access Server (NAS) forwards EAP packets to and from the RADIUS server, encapsulated within EAP-Message attributes. This has the advantage of allowing the NAS to support any EAP authentication method, without the need for method-specific code, which resides on the RADIUS server. WhileEAP was originally developed for use with PPP, it is now also in use with IEEE 802.
This document updates RFC 2869. |
|
| |
| RFC 3580 | IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines |
| |
| Authors: | P. Congdon, B. Aboba, A. Smith, G. Zorn, J. Roese. |
| Date: | September 2003 |
| Formats: | txt json html |
| Updated by: | RFC 7268 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3580 |
|
This document provides suggestions on Remote Authentication Dial InUser Service (RADIUS) usage by IEEE 802.1X Authenticators. The material in this document is also included within a non-normativeAppendix within the IEEE 802.1X specification, and is being presented as an IETF RFC for informational purposes. |
|
| |
| RFC 3582 | Goals for IPv6 Site-Multihoming Architectures |
| |
| Authors: | J. Abley, B. Black, V. Gill. |
| Date: | August 2003 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3582 |
|
This document outlines a set of goals for proposed new IPv6 site- multihoming architectures. It is recognised that this set of goals is ambitious and that some goals may conflict with others. The solution or solutions adopted may only be able to satisfy some of the goals presented here. |
|
| |
| RFC 3583 | Requirements of a Quality of Service (QoS) Solution for Mobile IP |
| |
| Authors: | H. Chaskar, Ed.. |
| Date: | September 2003 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3583 |
|
Mobile IP ensures correct routing of packets to a mobile node as the mobile node changes its point of attachment to the Internet.However, it is also required to provide proper Quality of Service(QoS) forwarding treatment to the mobile node's packet stream at the intermediate nodes in the network, so that QoS-sensitive IP services can be supported over Mobile IP. This document describes requirements for an IP QoS mechanism for its satisfactory operation with Mobile IP. |
|
| |
| RFC 3587 | IPv6 Global Unicast Address Format |
| |
| Authors: | R. Hinden, S. Deering, E. Nordmark. |
| Date: | August 2003 |
| Formats: | txt html json |
| Obsoletes: | RFC 2374 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3587 |
|
This document obsoletes RFC 2374, "An IPv6 Aggregatable GlobalUnicast Address Format". It defined an IPv6 address allocation structure that includes Top Level Aggregator (TLA) and Next LevelAggregator (NLA). This document makes RFC 2374 and the TLA/NLA structure historic. |
|
| |
| RFC 3589 | Diameter Command Codes for Third Generation Partnership Project (3GPP) Release 5 |
| |
| Authors: | J. Loughney. |
| Date: | September 2003 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3589 |
|
This document describes the IANA's allocation of a block of DiameterCommand Codes for the Third Generation Partnership Project (3GPP)Release 5. This document does not pass judgment on the usage of these command codes. Further more, these command codes are for use for Release 5. For future releases, these codes cannot be reused, but must be allocated according to the Diameter Base specification. |
|
| |
| RFC 3599 | Request for Comments Summary RFC Numbers 3500-3599 |
| |
| Authors: | S. Ginoza. |
| Date: | December 2003 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3599 |
|
This RFC is a slightly annotated list of the 100 RFCs from RFC 3500 through RFC 3599. This is a status report on these RFCs |
|
| |
| RFC 3603 | Private Session Initiation Protocol (SIP) Proxy-to-Proxy Extensions for Supporting the PacketCable Distributed Call Signaling Architecture |
| |
| Authors: | W. Marshall, Ed., F. Andreasen, Ed.. |
| Date: | October 2003 |
| Formats: | txt html json |
| Obsoleted by: | RFC 5503 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3603 |
|
In order to deploy a residential telephone service at very large scale across different domains, it is necessary for trusted elements owned by different service providers to exchange trusted information that conveys customer-specific information and expectations about the parties involved in the call. This document describes private extensions to the Session Initiation Protocol (SIP) (RFC3261) for supporting the exchange of customer information and billing information between trusted entities in the PacketCable DistributedCall Signaling Architecture. These extensions provide mechanisms for access network coordination to prevent theft of service, customer originated trace of harassing calls, support for operator services and emergency services, and support for various other regulatory issues. The use of the extensions is only applicable within closed administrative domains, or among federations of administrative domains with previously agreed-upon policies where coordination of charging and other functions is required. |
|
| |
| RFC 3604 | Requirements for Adding Optical Support to the General Switch Management Protocol version 3 (GSMPv3) |
| |
| Authors: | H. Khosravi, G. Kullgren, S. Shew, J. Sadler, A. Watanabe. |
| Date: | October 2003 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3604 |
|
This memo provides requirements for adding optical switching support to the General Switch Management Protocol (GSMP). It also contains clarifications and suggested changes to the GSMPv3 specification. |
|
| |
| RFC 3607 | Chinese Lottery Cryptanalysis Revisited: The Internet as a Codebreaking Tool |
| |
| Authors: | M. Leech. |
| Date: | September 2003 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3607 |
|
This document revisits the so-called Chinese Lottery massively-parallel cryptanalytic attack. It explores Internet-based analogues to the Chinese Lottery, and their potentially-serious consequences. |
|
| |
| RFC 3609 | Tracing Requirements for Generic Tunnels |
| |
| Authors: | R. Bonica, K. Kompella, D. Meyer. |
| Date: | September 2003 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3609 |
|
This document specifies requirements for a generic route-tracing application. It also specifies requirements for a protocol that will support that application. Network operators will use the generic route-tracing application to verify proper operation of the IP forwarding plane. They will also use the application to discover details regarding tunnels that support IP forwarding.
The generic route-tracing application, specified herein, supports a superset of the functionality that "traceroute" currently offers.Like traceroute, the generic route-tracing application can discover the forwarding path between two interfaces that are contained by anIP network. Unlike traceroute, this application can reveal details regarding tunnels that support the IP forwarding path. |
|
| |
| RFC 3610 | Counter with CBC-MAC (CCM) |
| |
| Authors: | D. Whiting, R. Housley, N. Ferguson. |
| Date: | September 2003 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3610 |
|
Counter with CBC-MAC (CCM) is a generic authenticated encryption block cipher mode. CCM is defined for use with 128-bit block ciphers, such as the Advanced Encryption Standard (AES). |
|
| |
| RFC 3612 | Applicability Statement for Restart Mechanisms for the Label Distribution Protocol (LDP) |
| |
| Authors: | A. Farrel. |
| Date: | September 2003 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3612 |
|
This document provides guidance on when it is advisable to implement some form of Label Distribution Protocol (LDP) restart mechanism and which approach might be more suitable. The issues and extensions described in this document are equally applicable to RFC 3212,"Constraint-Based LSP Setup Using LDP". |
|
| |
| RFC 3613 | Definition of a Uniform Resource Name (URN) Namespace for the Middleware Architecture Committee for Education (MACE) |
| |
| Authors: | R. Morgan, K. Hazelton. |
| Date: | October 2003 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3613 |
|
This document describes a Uniform Resource Name (URN) namespace for the Internet2 Middleware Architecture Committee for Education (MACE).This namespace is for naming persistent resources defined by MACE, its working groups and other designated subordinates. |
|
| |
| RFC 3614 | A Uniform Resource Name (URN) Namespace for the Motion Picture Experts Group (MPEG) |
| |
| Authors: | J. Smith. |
| Date: | September 2003 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3614 |
|
This document describes a Uniform Resource Name (URN) namespace for the Motion Picture Experts Group (MPEG) for naming persistent resources as part of the MPEG standards. Example resources include technical documents and specifications, eXtensible Markup Language(XML) Schemas, classification schemes, XML Document Type Definitions(DTDs), namespaces, style sheets, media assets, and other types of resources produced or managed by MPEG. |
|
| |
| RFC 3615 | A Uniform Resource Name (URN) Namespace for SWIFT Financial Messaging |
| |
| Authors: | J. Gustin, A. Goyens. |
| Date: | September 2003 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3615 |
|
This document describes a Uniform Resource Name (URN) namespace that is managed by SWIFT for usage within messages standardized by SWIFT. |
|
| |
| RFC 3616 | A Uniform Resource Name (URN) Namespace for Foundation for Intelligent Physical Agents (FIPA) |
| |
| Authors: | F. Bellifemine, I. Constantinescu, S. Willmott. |
| Date: | September 2003 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3616 |
|
This document describes a Uniform Resource Name NamespaceIdentification (URN NID) for the Foundation for Intelligent PhysicalAgents (FIPA). This URN NID will be used for identification of standard components published by the FIPA standards body in the area of Agent technology. |
|
| |
| RFC 3617 | Uniform Resource Identifier (URI) Scheme and Applicability Statement for the Trivial File Transfer Protocol (TFTP) |
| |
| Authors: | E. Lear. |
| Date: | October 2003 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3617 |
|
The Trivial File Transfer Protocol (TFTP) is a very simple TRIVIAL protocol that has been in use on the Internet for quite a long time.While this document discourages its continued use, largely due to security concerns, we do define a Uniform Resource Identifier (URI) scheme, as well as discuss the protocol's applicability. |
|
| |
| RFC 3619 | Extreme Networks' Ethernet Automatic Protection Switching (EAPS) Version 1 |
| |
| Authors: | S. Shah, M. Yip. |
| Date: | October 2003 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3619 |
|
This document describes the Ethernet Automatic Protection Switching(EAPS) (tm) technology invented by Extreme Networks to increase the availability and robustness of Ethernet rings. An Ethernet ring built using EAPS can have resilience comparable to that provided bySONET rings, at a lower cost and with fewer constraints (e.g., ring size). |
|
| |
| RFC 3622 | A Uniform Resource Name (URN) Namespace for the Liberty Alliance Project |
| |
| Authors: | M. Mealling. |
| Date: | February 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3622 |
|
This document describes a Uniform Resource Name (URN) namespace that will identify various objects within the Liberty Architecture for federated network identity. |
|
| |
| RFC 3624 | The Media Gateway Control Protocol (MGCP) Bulk Audit Package |
| |
| Authors: | B. Foster, D. Auerbach, F. Andreasen. |
| Date: | November 2003 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3624 |
|
The base Media Gateway Control Protocol (MGCP) includes audit commands that only allow a Call Agent to audit endpoint and/or connection state one endpoint at a time. This document describes a new MGCP package for bulk auditing of a group of gateway endpoints.It allows a Call Agent to determine the endpoint naming convention, the list of instantiated endpoints as well connection and endpoint state for the group of endpoints. |
|
| |
| RFC 3625 | The QCP File Format and Media Types for Speech Data |
| |
| Authors: | R. Gellens, H. Garudadri. |
| Date: | September 2003 |
| Formats: | txt json html |
| Updates: | RFC 3555 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3625 |
|
RFC 2658 specifies the streaming format for 3GPP2 13K vocoder (HighRate Speech Service Option 17 for Wideband Spread SpectrumCommunications Systems, also known as QCELP 13K vocoder) data, but does not specify a storage format. Many implementations have been using the "QCP" file format (named for its file extension) for exchanging QCELP 13K data as well as Enhanced Variable Rate Coder(EVRC) and Selectable Mode Vocoders (SMV) data. (For example,Eudora(r), QuickTime(r), and cmda2000(r) handsets).
This document specifies the QCP file format and updates the audio/qcelp media registration to specify this format for storage, and registers the audio/evrc-qcp and audio/smv-qcp media types forEVRC and SMV (respectively) data stored in this format. |
|
| |
| RFC 3628 | Policy Requirements for Time-Stamping Authorities (TSAs) |
| |
| Authors: | D. Pinkas, N. Pope, J. Ross. |
| Date: | November 2003 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3628 |
|
This document defines requirements for a baseline time-stamp policy for Time-Stamping Authorities (TSAs) issuing time-stamp tokens, supported by public key certificates, with an accuracy of one second or better. A TSA may define its own policy which enhances the policy defined in this document. Such a policy shall incorporate or further constrain the requirements identified in this document. |
|
| |
| RFC 3631 | Security Mechanisms for the Internet |
| |
| Authors: | S. Bellovin, Ed., J. Schiller, Ed., C. Kaufman, Ed.. |
| Date: | December 2003 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3631 |
|
Security must be built into Internet Protocols for those protocols to offer their services securely. Many security problems can be traced to improper implementations. However, even a proper implementation will have security problems if the fundamental protocol is itself exploitable. Exactly how security should be implemented in a protocol will vary, because of the structure of the protocol itself.However, there are many protocols for which standard Internet security mechanisms, already developed, may be applicable. The precise one that is appropriate in any given situation can vary. We review a number of different choices, explaining the properties of each. |
|
| |
| RFC 3632 | VeriSign Registry Registrar Protocol (RRP) Version 2.0.0 |
| |
| Authors: | S. Hollenbeck, S. Veeramachaneni, S. Yalamanchilli. |
| Date: | November 2003 |
| Formats: | txt html json |
| Updates: | RFC 2832 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3632 |
|
This document updates version 1.1.0 of the Network Solutions Inc.(NSI) Registry Registrar Protocol (RRP) specified in RFC 2832. The changes described in this document combined with the base specification documented in RFC 2832 specify version 2.0.0 of theVeriSign Registry Registrar Protocol. |
|
| |
| RFC 3638 | Applicability Statement for Reclassification of RFC 1643 to Historic Status |
| |
|
|
This memo recommends that RFC 1643 be reclassified as an Historic document and provides the supporting motivation for that recommendation. |
|
| |
| RFC 3639 | Considerations on the use of a Service Identifier in Packet Headers |
| |
| Authors: | M. St. Johns, Ed., G. Huston, Ed., IAB. |
| Date: | October 2003 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3639 |
|
This memo describes some considerations relating to the use of IP protocol number fields and payload protocol (e.g., TCP) port fields to identify particular services that may be associated with that port number or protocol number. |
|
| |
| RFC 3642 | Common Elements of Generic String Encoding Rules (GSER) Encodings |
| |
| Authors: | S. Legg. |
| Date: | October 2003 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3642 |
|
The Generic String Encoding Rules (GSER) describe a human readable text encoding for an Abstract Syntax Notation One (ASN.1) value of any ASN.1 type. Specifications making use of GSER may wish to provide an equivalent Augmented Backus-Naur Form (ABNF) description of the GSER encoding for a particular ASN.1 type as a convenience for implementors. This document supports such specifications by providing equivalent ABNF for the GSER encodings for ASN.1 types that commonly occur in Lightweight Directory Access Protocol (LDAP) syntaxes. |
|
| |
| RFC 3647 | Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework |
| |
| Authors: | S. Chokhani, W. Ford, R. Sabett, C. Merrill, S. Wu. |
| Date: | November 2003 |
| Formats: | txt json html |
| Obsoletes: | RFC 2527 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3647 |
|
This document presents a framework to assist the writers of certificate policies or certification practice statements for participants within public key infrastructures, such as certification authorities, policy authorities, and communities of interest that wish to rely on certificates. In particular, the framework provides a comprehensive list of topics that potentially (at the writer's discretion) need to be covered in a certificate policy or a certification practice statement. This document supersedes RFC 2527. |
|
| |
| RFC 3650 | Handle System Overview |
| |
| Authors: | S. Sun, L. Lannom, B. Boesch. |
| Date: | November 2003 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3650 |
|
This document provides an overview of the Handle System in terms of its namespace and service architecture, as well as its relationship to other Internet services such as DNS, LDAP/X.500, and URNs. TheHandle System is a general-purpose global name service that allows secured name resolution and administration over networks such as theInternet. The Handle System manages handles, which are unique names for digital objects and other Internet resources. |
|
| |
| RFC 3651 | Handle System Namespace and Service Definition |
| |
| Authors: | S. Sun, S. Reilly, L. Lannom. |
| Date: | November 2003 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3651 |
|
The Handle System is a general-purpose global name service that allows secured name resolution and administration over the publicInternet. This document provides a detailed description of theHandle System namespace, and its data, service, and operation models.The namespace definition specifies the handle syntax and its semantic structure. The data model defines the data structures used by theHandle System protocol and any pre-defined data types for carrying out the handle service. The service model provides definitions of various Handle System components and explains how they work together over the network. Finally, the Handle System operation model describes its service operation in terms of messages transmitted between client and server, and the client authentication process based on the Handle System authentication protocol. |
|
| |
| RFC 3652 | Handle System Protocol (ver 2.1) Specification |
| |
| Authors: | S. Sun, S. Reilly, L. Lannom, J. Petrone. |
| Date: | November 2003 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3652 |
|
The Handle System is a general-purpose global name service that allows secured name resolution and administration over the publicInternet. This document describes the protocol used for client software to access the Handle System for both handle resolution and administration. The protocol specifies the procedure for a client software to locate the responsible handle server of any given handle.It also defines the messages exchanged between the client and server for any handle operation. |
|
| |
| RFC 3653 | XML-Signature XPath Filter 2.0 |
| |
| Authors: | J. Boyer, M. Hughes, J. Reagle. |
| Date: | December 2003 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3653 |
|
XML Signature recommends a standard means for specifying information content to be digitally signed and for representing the resulting digital signatures in XML. Some applications require the ability to specify a subset of a given XML document as the information content to be signed. The XML Signature specification meets this requirement with the XPath transform. However, this transform can be difficult to implement efficiently with existing technologies. This specification defines a new XML Signature transform to facilitate the development of efficient document subsetting implementations that interoperate under similar performance profiles.
This document is the W3C XML Signature XPath-Filter 2.0Recommendation. This document has been reviewed by W3C Members and other interested parties and has been endorsed by the Director as aW3C Recommendation. It is a stable document and may be used as reference material or cited as a normative reference from another document. W3C's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment. This enhances the functionality and interoperability of the Web. |
|
| |
| RFC 3654 | Requirements for Separation of IP Control and Forwarding |
| |
| Authors: | H. Khosravi, Ed., T. Anderson, Ed.. |
| Date: | November 2003 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3654 |
|
This document introduces the Forwarding and Control ElementSeparation (ForCES) architecture and defines a set of associated terminology. This document also defines a set of architectural, modeling, and protocol requirements to logically separate the control and data forwarding planes of an IP (IPv4, IPv6, etc.) networking device. |
|
| |
| RFC 3660 | 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 (DualTone Multifrequency), announcement server and script packages are updates of packages from RFC 2705 with additional explanation and in some cases new versions of these packages. In addition to these, five new packages are defined here. These are the signal list, resource reservation, media format, supplementary services and digit map extension packages. |
|
| |
| RFC 3661 | Media Gateway Control Protocol (MGCP) Return Code Usage |
| |
| Authors: | B. Foster, C. Sivachelvan. |
| Date: | December 2003 |
| Formats: | txt html json |
| Updates: | RFC 3435 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3661 |
|
This document provides implementation guidelines for the use of return codes in RFC 3435, Media Gateway Control Protocol (MGCP)Version 1.0. Return codes in RFC 3435 do not cover all possible specific situations that may ever occur in a gateway. That is not possible and not necessary. What is important is to ensure that theCall Agent that receives a return code behaves appropriately and consistently for the given situation. The purpose of this document is to provide implementation guidelines to ensure that consistency. |
|
| |
| RFC 3662 | A Lower Effort Per-Domain Behavior (PDB) for Differentiated Services |
| |
| Authors: | R. Bless, K. Nichols, K. Wehrle. |
| Date: | December 2003 |
| Formats: | txt json html |
| Obsoleted by: | RFC 8622 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3662 |
|
This document proposes a differentiated services per-domain behavior(PDB) whose traffic may be "starved" (although starvation is not strictly required) in a properly functioning network. This is in contrast to the Internet's "best-effort" or "normal Internet traffic" model, where prolonged starvation indicates network problems. In this sense, the proposed PDB's traffic is forwarded with a "lower" priority than the normal "best-effort" Internet traffic, thus the PDB is called "Lower Effort" (LE). Use of this PDB permits a network operator to strictly limit the effect of its traffic on "best- effort"/"normal" or all other Internet traffic. This document gives some example uses, but does not propose constraining the PDB's use to any particular type of traffic. |
|
| |
| RFC 3669 | Guidelines for Working Groups on Intellectual Property Issues |
| |
| Authors: | S. Brim. |
| Date: | February 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3669 |
|
This memo lays out a conceptual framework and rules of thumb useful for working groups dealing with Intellectual Property Rights (IPR) issues. It documents specific examples of how IPR issues have been dealt with in the IETF. |
|
| |
| RFC 3675 | .sex Considered Dangerous |
| |
| Authors: | D. Eastlake 3rd. |
| Date: | February 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3675 |
|
Periodically there are proposals to mandate the use of a special top level name or an IP address bit to flag "adult" or "unsafe" material or the like. This document explains why this is an ill considered idea from the legal, philosophical, and particularly, the technical points of view. |
|
| |
| RFC 3678 | Socket Interface Extensions for Multicast Source Filters |
| |
| Authors: | D. Thaler, B. Fenner, B. Quinn. |
| Date: | January 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3678 |
|
The Internet Group Management Protocol (IGMPv3) for IPv4 and theMulticast Listener Discovery (MLDv2) for IPv6 add the capability for applications to express source filters on multicast group memberships, which allows receiver applications to determine the set of senders (sources) from which to accept multicast traffic. This capability also simplifies support of one-to-many type multicast applications.
This document specifies new socket options and functions to manage source filters for IP Multicast group memberships. It also defines the socket structures to provide input and output arguments to these new application program interfaces (APIs). These extensions are designed to provide access to the source filtering features, while introducing a minimum of change into the system and providing complete compatibility for existing multicast applications. |
|
| |
| RFC 3679 | Unused Dynamic Host Configuration Protocol (DHCP) Option Codes |
| |
|
|
Prior to the publication of RFC 2489 (which was updated by RFC 2939), several option codes were assigned to proposed Dynamic HostConfiguration Protocol (DHCP) options that were subsequently never used. This document lists those unused option codes and directs IANA to make these option codes available for assignment to other DHCP options in the future.
The document also lists several option codes that are not currently documented in an RFC but should not be made available for reassignment to future DHCP options. |
|
| |
| RFC 3689 | General Requirements for Emergency Telecommunication Service (ETS) |
| |
| Authors: | K. Carlberg, R. Atkinson. |
| Date: | February 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3689 |
|
This document presents a list of general requirements in support ofEmergency Telecommunications Service (ETS). Solutions to these requirements are not presented in this document. Additional requirements pertaining to specific applications, or types of applications, are to be specified in separate document(s). |
|
| |
| RFC 3690 | IP Telephony Requirements for Emergency Telecommunication Service (ETS) |
| |
| Authors: | K. Carlberg, R. Atkinson. |
| Date: | February 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3690 |
|
This document presents a list of requirements in support of EmergencyTelecommunications Service (ETS) within the context of IP telephony.It is an extension to the general requirements presented in RFC 3689.Solutions to these requirements are not presented in this document. |
|
| |
| RFC 3693 | Geopriv Requirements |
| |
| Authors: | J. Cuellar, J. Morris, D. Mulligan, J. Peterson, J. Polk. |
| Date: | February 2004 |
| Formats: | txt json html |
| Updated by: | RFC 6280, RFC 7459 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3693 |
|
Location-based services, navigation applications, emergency services, management of equipment in the field, and other location-dependent services need geographic location information about a Target (such as a user, resource or other entity). There is a need to securely gather and transfer location information for location services, while at the same time protect the privacy of the individuals involved.
This document focuses on the authorization, security and privacy requirements for such location-dependent services. Specifically, it describes the requirements for the Geopriv Location Object (LO) and for the protocols that use this Location Object. This LO is envisioned to be the primary data structure used in all Geopriv protocol exchanges to securely transfer location data. |
|
| |
| RFC 3694 | Threat Analysis of the Geopriv Protocol |
| |
| Authors: | M. Danley, D. Mulligan, J. Morris, J. Peterson. |
| Date: | February 2004 |
| Formats: | txt html json |
| Updated by: | RFC 6280 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3694 |
|
This document provides some analysis of threats against the Geopriv protocol architecture. It focuses on protocol threats, threats that result from the storage of data by entities in the architecture, and threats posed by the abuse of information yielded by Geopriv. Some security properties that meet these threats are enumerated as a reference for Geopriv requirements. |
|
| |
| RFC 3696 | Application Techniques for Checking and Transformation of Names |
| |
| Authors: | J. Klensin. |
| Date: | February 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3696 |
|
Many Internet applications have been designed to deduce top-level domains (or other domain name labels) from partial information. The introduction of new top-level domains, especially non-country-code ones, has exposed flaws in some of the methods used by these applications. These flaws make it more difficult, or impossible, for users of the applications to access the full Internet. This memo discusses some of the techniques that have been used and gives some guidance for minimizing their negative impact as the domain name environment evolves. This document draws summaries of the applicable rules together in one place and supplies references to the actual standards. |
|
| |
| RFC 3701 | 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. |
|
| |
| RFC 3702 | Authentication, Authorization, and Accounting Requirements for the Session Initiation Protocol (SIP) |
| |
| Authors: | J. Loughney, G. Camarillo. |
| Date: | February 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3702 |
|
As Session Initiation Protocol (SIP) services are deployed on theInternet, there is a need for authentication, authorization, and accounting of SIP sessions. This document sets out the basic requirements for this work. |
|
| |
| RFC 3706 | A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers |
| |
| Authors: | G. Huang, S. Beaulieu, D. Rochefort. |
| Date: | February 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3706 |
|
This document describes the method detecting a dead Internet KeyExchange (IKE) peer that is presently in use by a number of vendors.The method, called Dead Peer Detection (DPD) uses IPSec traffic patterns to minimize the number of IKE messages that are needed to confirm liveness. DPD, like other keepalive mechanisms, is needed to determine when to perform IKE peer failover, and to reclaim lost resources. |
|
| |
| RFC 3707 | Cross Registry Internet Service Protocol (CRISP) Requirements |
| |
| Authors: | A. Newton. |
| Date: | February 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3707 |
|
Internet registries expose administrative and operational data via varying directory services. This document defines functional requirements for the directory services of domain registries and the common base requirements for extending the use of these services for other types of Internet registries. |
|
| |
| RFC 3710 | An IESG charter |
| |
|
|
This memo provides a charter for the Internet Engineering SteeringGroup (IESG), a management function of the Internet Engineering TaskForce (IETF). It is meant to document the charter of the IESG as it is presently understood. |
|
| |
| RFC 3712 | Lightweight Directory Access Protocol (LDAP): Schema for Printer Services |
| |
| Authors: | P. Fleming, I. McDonald. |
| Date: | February 2004 |
| Formats: | txt json html |
| Obsoleted by: | RFC 7612 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3712 |
|
This document defines a schema, object classes and attributes, for printers and printer services, for use with directories that supportLightweight Directory Access Protocol v3 (LDAP-TS). This document is based on the printer attributes listed in Appendix E of InternetPrinting Protocol/1.1 (IPP) (RFC 2911). A few additional printer attributes are based on definitions in the Printer MIB (RFC 1759). |
|
| |
| RFC 3713 | A Description of the Camellia Encryption Algorithm |
| |
| Authors: | M. Matsui, J. Nakajima, S. Moriai. |
| Date: | April 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3713 |
|
This document describes the Camellia encryption algorithm. Camellia is a block cipher with 128-bit block size and 128-, 192-, and 256-bit keys. The algorithm description is presented together with key scheduling part and data randomizing part. |
|
| |
| RFC 3714 | IAB Concerns Regarding Congestion Control for Voice Traffic in the Internet |
| |
| Authors: | S. Floyd, Ed., J. Kempf, Ed.. |
| Date: | March 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3714 |
|
This document discusses IAB concerns about effective end-to-end congestion control for best-effort voice traffic in the Internet.These concerns have to do with fairness, user quality, and with the dangers of congestion collapse. The concerns are particularly relevant in light of the absence of a widespread Quality of Service(QoS) deployment in the Internet, and the likelihood that this situation will not change much in the near term. This document is not making any recommendations about deployment paths for Voice overInternet Protocol (VoIP) in terms of QoS support, and is not claiming that best-effort service can be relied upon to give acceptable performance for VoIP. We are merely observing that voice traffic is occasionally deployed as best-effort traffic over some links in theInternet, that we expect this occasional deployment to continue, and that we have concerns about the lack of effective end-to-end congestion control for this best-effort voice traffic. |
|
| |
| RFC 3715 | IPsec-Network Address Translation (NAT) Compatibility Requirements |
| |
| Authors: | B. Aboba, W. Dixon. |
| Date: | March 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3715 |
|
This document describes known incompatibilities between NetworkAddress Translation (NAT) and IPsec, and describes the requirements for addressing them. Perhaps the most common use of IPsec is in providing virtual private networking capabilities. One very popular use of Virtual Private Networks (VPNs) is to provide telecommuter access to the corporate Intranet. Today, NATs are widely deployed in home gateways, as well as in other locations likely to be used by telecommuters, such as hotels. The result is that IPsec-NAT incompatibilities have become a major barrier in the deployment ofIPsec in one of its principal uses. |
|
| |
| RFC 3717 | IP over Optical Networks: A Framework |
| |
| Authors: | B. Rajagopalan, J. Luciani, D. Awduche. |
| Date: | March 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3717 |
|
The Internet transport infrastructure is moving towards a model of high-speed routers interconnected by optical core networks. The architectural choices for the interaction between IP and optical network layers, specifically, the routing and signaling aspects, are maturing. At the same time, a consensus has emerged in the industry on utilizing IP-based protocols for the optical control plane. This document defines a framework for IP over Optical networks, considering both the IP-based control plane for optical networks as well as IP-optical network interactions (together referred to as "IP over optical networks"). |
|
| |
| RFC 3718 | A Summary of Unicode Consortium Procedures, Policies, Stability, and Public Access |
| |
| Authors: | R. McGowan. |
| Date: | February 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3718 |
|
This memo describes various internal workings of the UnicodeConsortium for the benefit of participants in the IETF. It is intended solely for informational purposes. Included are discussions of how the decision-making bodies of the Consortium work and their procedures, as well as information on public access to the character encoding & standardization processes. |
|
| |
| RFC 3719 | Recommendations for Interoperable Networks using Intermediate System to Intermediate System (IS-IS) |
| |
| Authors: | J. Parker, Ed.. |
| Date: | February 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3719 |
|
This document discusses a number of differences between theIntermediate System to Intermediate System (IS-IS) protocol as described in ISO 10589 and the protocol as it is deployed today.These differences are discussed as a service to those implementing, testing, and deploying the IS-IS Protocol. A companion document discusses differences between the protocol described in RFC 1195 and the protocol as it is deployed today for routing IP traffic. |
|
| |
| RFC 3721 | Internet Small Computer Systems Interface (iSCSI) Naming and Discovery |
| |
| Authors: | M. Bakke, J. Hafner, J. Hufferd, K. Voruganti, M. Krueger. |
| Date: | April 2004 |
| Formats: | txt html json |
| Updated by: | RFC 7143 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3721 |
|
This document provides examples of the Internet Small ComputerSystems Interface (iSCSI; or SCSI over TCP) name construction and discussion of discovery of iSCSI resources (targets) by iSCSI initiators. This document complements the iSCSI protocol document.Flexibility is the key guiding principle behind this document. That is, an effort has been made to satisfy the needs of both small isolated environments, as well as large environments requiring secure/scalable solutions. |
|
| |
| RFC 3724 | The Rise of the Middle and the Future of End-to-End: Reflections on the Evolution of the Internet Architecture |
| |
| Authors: | J. Kempf, Ed., R. Austein, Ed., IAB. |
| Date: | March 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3724 |
|
The end-to-end principle is the core architectural guideline of theInternet. In this document, we briefly examine the development of the end-to-end principle as it has been applied to the Internet architecture over the years. We discuss current trends in the evolution of the Internet architecture in relation to the end-to-end principle, and try to draw some conclusion about the evolution of the end-to-end principle, and thus for the Internet architecture which it supports, in light of these current trends. |
|
| |
| RFC 3726 | Requirements for Signaling Protocols |
| |
| Authors: | M. Brunner, Ed.. |
| Date: | April 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3726 |
|
This document defines requirements for signaling across different network environments, such as across administrative and/or technology domains. Signaling is mainly considered for Quality of Service (Qos) such as the Resource Reservation Protocol (RSVP). However, in recent years, several other applications of signaling have been defined.For example, signaling for label distribution in Multiprotocol LabelSwitching (MPLS) or signaling to middleboxes. To achieve wide applicability of the requirements, the starting point is a diverse set of scenarios/use cases concerning various types of networks and application interactions. This document presents the assumptions before listing the requirements. The requirements are grouped according to areas such as architecture and design goals, signaling flows, layering, performance, flexibility, security, and mobility. |
|
| |
| RFC 3735 | Guidelines for Extending the Extensible Provisioning Protocol (EPP) |
| |
| Authors: | S. Hollenbeck. |
| Date: | March 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3735 |
|
The Extensible Provisioning Protocol (EPP) is an application layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. This document presents guidelines for use of EPP's extension mechanisms to define new features and object management capabilities. |
|
| |
| RFC 3740 | The Multicast Group Security Architecture |
| |
| Authors: | T. Hardjono, B. Weis. |
| Date: | March 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3740 |
|
This document provides an overview and rationale of the multicast security architecture used to secure data packets of large multicast groups. The document begins by introducing a Multicast SecurityReference Framework, and proceeds to identify the security services that may be part of a secure multicast solution. |
|
| |
| RFC 3741 | Exclusive XML Canonicalization, Version 1.0 |
| |
| Authors: | J. Boyer, D. Eastlake 3rd, J. Reagle. |
| Date: | March 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3741 |
|
Canonical XML specifies a standard serialization of XML that, when applied to a subdocument, includes the subdocument's ancestor context including all of the namespace declarations and attributes in the"xml:" namespace. However, some applications require a method which, to the extent practical, excludes ancestor context from a canonicalized subdocument. For example, one might require a digital signature over an XML payload (subdocument) in an XML message that will not break when that subdocument is removed from its original message and/or inserted into a different context. This requirement is satisfied by Exclusive XML Canonicalization. |
|
| |
| RFC 3743 | Joint Engineering Team (JET) Guidelines for Internationalized Domain Names (IDN) Registration and Administration for Chinese, Japanese, and Korean |
| |
| Authors: | K. Konishi, K. Huang, H. Qian, Y. Ko. |
| Date: | April 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3743 |
|
Achieving internationalized access to domain names raises many complex issues. These are associated not only with basic protocol design, such as how names are represented on the network, compared, and converted to appropriate forms, but also with issues and options for deployment, transition, registration, and administration.
The IETF Standards for Internationalized Domain Names, known as"IDNA", focuses on access to domain names in a range of scripts that is broader in scope than the original ASCII. The development process made it clear that use of characters with similar appearances and/or interpretations created potential for confusion, as well as difficulties in deployment and transition. The conclusion was that, while those issues were important, they could best be addressed administratively rather than through restrictions embedded in the protocols. This document defines a set of guidelines for applying restrictions of that type for Chinese, Japanese and Korean (CJK) scripts and the zones that use them and, perhaps, the beginning of a framework for thinking about other zones, languages, and scripts. |
|
| |
| RFC 3746 | Forwarding and Control Element Separation (ForCES) Framework |
| |
| Authors: | L. Yang, R. Dantu, T. Anderson, R. Gopal. |
| Date: | April 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3746 |
|
This document defines the architectural framework for the ForCES(Forwarding and Control Element Separation) network elements, and identifies the associated entities and their interactions. |
|
| |
| RFC 3750 | Unmanaged Networks IPv6 Transition Scenarios |
| |
| Authors: | C. Huitema, R. Austein, S. Satapati, R. van der Pol. |
| Date: | April 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3750 |
|
This document defines the scenarios in which IPv6 transition mechanisms are to be used in unmanaged networks. In order to evaluate the suitability of these mechanisms, we need to define the scenarios in which these mechanisms have to be used. One specific scope is the "unmanaged network", which typically corresponds to a home or small office network. The scenarios are specific to a single subnet, and are defined in terms of IP connectivity supported by the gateway and the Internet Service Provider (ISP). We first examine the generic requirements of four classes of applications: local, client, peer to peer and server. Then, for each scenario, we infer transition requirements by analyzing the needs for smooth migration of applications from IPv4 to IPv6. |
|
| |
| RFC 3751 | Omniscience Protocol Requirements |
| |
| Authors: | S. Bradner. |
| Date: | 1 April 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3751 |
|
There have been a number of legislative initiatives in the U.S. and elsewhere over the past few years to use the Internet to actively interfere with allegedly illegal activities of Internet users. This memo proposes a number of requirements for a new protocol, theOmniscience Protocol, that could be used to enable such efforts. |
|
| |
| RFC 3752 | Open Pluggable Edge Services (OPES) Use Cases and Deployment Scenarios |
| |
| Authors: | A. Barbir, E. Burger, R. Chen, S. McHenry, H. Orman, R. Penno. |
| Date: | April 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3752 |
|
This memo provides a discussion of use cases and deployment scenarios for Open Pluggable Edge Services (OPES). The work examines services that could be performed to requests and/or responses. |
|
| |
| RFC 3753 | Mobility Related Terminology |
| |
| Authors: | J. Manner, Ed., M. Kojo, Ed.. |
| Date: | June 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3753 |
|
There is a need for common definitions of terminology in the work to be done around IP mobility. This document defines terms for mobility related terminology. The document originated out of work done in theSeamoby Working Group but has broader applicability for terminology used in IETF-wide discourse on technology for mobility and IP networks. Other working groups dealing with mobility may want to take advantage of this terminology. |
|
| |
| RFC 3754 | IP Multicast in Differentiated Services (DS) Networks |
| |
| Authors: | R. Bless, K. Wehrle. |
| Date: | April 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3754 |
|
This document discusses the problems of IP Multicast use inDifferentiated Services (DS) networks, expanding on the discussion inRFC 2475 ("An Architecture of Differentiated Services"). It also suggests possible solutions to these problems, describes a potential implementation model, and presents simulation results. |
|
| |
| RFC 3756 | IPv6 Neighbor Discovery (ND) Trust Models and Threats |
| |
| Authors: | P. Nikander, Ed., J. Kempf, E. Nordmark. |
| Date: | May 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3756 |
|
The existing IETF standards specify that IPv6 Neighbor Discovery (ND) and Address Autoconfiguration mechanisms may be protected with IPsecAuthentication Header (AH). However, the current specifications limit the security solutions to manual keying due to practical problems faced with automatic key management. This document specifies three different trust models and discusses the threats pertinent to IPv6 Neighbor Discovery. The purpose of this discussion is to define the requirements for Securing IPv6 Neighbor Discovery. |
|
| |
| RFC 3759 | RObust Header Compression (ROHC): Terminology and Channel Mapping Examples |
| |
|
|
This document aims to clarify terms and concepts presented in RFC3095. RFC 3095 defines a Proposed Standard framework with profiles for RObust Header Compression (ROHC). The standard introduces various concepts which might be difficult to understand and especially to relate correctly to the surrounding environments where header compression may be used. This document aims at clarifying these aspects of ROHC, discussing terms such as ROHC instances, ROHC channels, ROHC feedback, and ROHC contexts, and how these terms relate to other terms, like network elements and IP interfaces, commonly used, for example, when addressing MIB issues. |
|
| |
| RFC 3760 | Securely Available Credentials (SACRED) - Credential Server Framework |
| |
| Authors: | D. Gustafson, M. Just, M. Nystrom. |
| Date: | April 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3760 |
|
As the number, and more particularly the number of different types, of devices connecting to the Internet increases, credential mobility becomes an issue for IETF standardization. This document responds to the requirements on protocols for secure exchange of credentials listed in RFC 3157, by presenting an abstract protocol framework. |
|
| |
| RFC 3763 | One-way Active Measurement Protocol (OWAMP) Requirements |
| |
| Authors: | S. Shalunov, B. Teitelbaum. |
| Date: | April 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3763 |
|
With growing availability of good time sources to network nodes, it becomes increasingly possible to measure one-way IP performance metrics with high precision. To do so in an interoperable manner, a common protocol for such measurements is required. This document specifies requirements for a one-way active measurement protocol(OWAMP) standard. The protocol can measure one-way delay, as well as other unidirectional characteristics, such as one-way loss. |
|
| |
| RFC 3765 | NOPEER Community for Border Gateway Protocol (BGP) Route Scope Control |
| |
| Authors: | G. Huston. |
| Date: | April 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3765 |
|
This document describes the use of a scope control Border GatewayProtocol (BGP) community. This well-known advisory transitive community allows an origin AS to specify the extent to which a specific route should be externally propagated. In particular this community, NOPEER, allows an origin AS to specify that a route with this attribute need not be advertised across bilateral peer connections. |
|
| |
| RFC 3769 | Requirements for IPv6 Prefix Delegation |
| |
| Authors: | S. Miyakawa, R. Droms. |
| Date: | June 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3769 |
|
This document describes requirements for how IPv6 address prefixes should be delegated to an IPv6 subscriber's network (or "site"). |
|
| |
| RFC 3773 | High-Level Requirements for Internet Voice Mail |
| |
| Authors: | E. Candell. |
| Date: | June 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3773 |
|
This document describes the high-level requirements for InternetVoice Mail (IVM) and establishes a baseline of desired functionality against which proposed MIME profiles for Internet Voice Messaging can be judged. IVM is an extension of the Voice Profile for InternetMail (VPIM) version 2 designed to support interoperability with desktop clients. Other goals for this version of VPIM include expanded interoperability with unified messaging systems, conformance to Internet standards, and backward compatibility with voice messaging systems currently running in a VPIM enabled environment.This document does not include goals that were met fully by VPIM version 2. |
|
| |
| RFC 3774 | IETF Problem Statement |
| |
| Authors: | E. Davies, Ed.. |
| Date: | May 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3774 |
|
This memo summarizes perceived problems in the structure, function, and processes of the Internet Engineering Task Force (IETF). We are attempting to identify these problems, so that they can be addressed and corrected by the IETF community.
The problems have been digested and categorized from an extensive discussion which took place on the 'problem-statement' mailing list from November 2002 to September 2003. The problem list has been further analyzed in an attempt to determine the root causes at the heart of the perceived problems: The result will be used to guide the next stage of the process in the Problem Statement working group which is to recommend the structures and processes that will carry out the corrections. |
|
| |
| RFC 3778 | The application/pdf Media Type |
| |
| Authors: | E. Taft, J. Pravetz, S. Zilles, L. Masinter. |
| Date: | May 2004 |
| Formats: | txt json html |
| Obsoleted by: | RFC 8118 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3778 |
|
PDF, the 'Portable Document Format', is a general document representation language that has been in use for document exchange on the Internet since 1993. This document provides an overview of thePDF format, explains the mechanisms for digital signatures and encryption within PDF files, and updates the media type registration of 'application/pdf'. |
|
| |
| RFC 3783 | Small Computer Systems Interface (SCSI) Command Ordering Considerations with iSCSI |
| |
| Authors: | M. Chadalapaka, R. Elliott. |
| Date: | May 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3783 |
|
Internet Small Computer Systems Interface (iSCSI) is a Small ComputerSystems Interface (SCSI) transport protocol designed to run on top ofTCP. The iSCSI session abstraction is equivalent to the classic SCSI"I_T nexus", which represents the logical relationship between anInitiator and a Target (I and T) required in order to communicate via the SCSI family of protocols. The iSCSI session provides an ordered command delivery from the SCSI initiator to the SCSI target. This document goes into the design considerations that led to the iSCSI session model as it is defined today, relates the SCSI command ordering features defined in T10 specifications to the iSCSI concepts, and finally provides guidance to system designers on how true command ordering solutions can be built based on iSCSI. |
|
| |
| RFC 3784 | Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE) |
| |
|
|
This document describes extensions to the Intermediate System toIntermediate System (IS-IS) protocol to support Traffic Engineering(TE). This document extends the IS-IS protocol by specifying new information that an Intermediate System (router) can place in LinkState Protocol (LSP) Data Units. This information describes additional details regarding the state of the network that are useful for traffic engineering computations. |
|
| |
| RFC 3786 | Extending the Number of Intermediate System to Intermediate System (IS-IS) Link State PDU (LSP) Fragments Beyond the 256 Limit |
| |
| Authors: | A. Hermelin, S. Previdi, M. Shand. |
| Date: | May 2004 |
| Formats: | txt html json |
| Obsoleted by: | RFC 5311 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3786 |
|
This document describes a mechanism that allows a system to originate more than 256 Link State PDU (LSP) fragments, a limit set by the original Intermediate System to Intermediate System (IS-IS) Routing protocol, as described in ISO/IEC 10589. This mechanism can be used in IP-only, OSI-only, and dual routers. |
|
| |
| RFC 3787 | Recommendations for Interoperable IP Networks using Intermediate System to Intermediate System (IS-IS) |
| |
| Authors: | J. Parker, Ed.. |
| Date: | May 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3787 |
|
This document discusses a number of differences between theIntermediate System to Intermediate System (IS-IS) protocol used to route IP traffic as described in RFC 1195 and the protocol as it is deployed today. These differences are discussed as a service to those implementing, testing, and deploying the IS-IS Protocol to route IP traffic. A companion document describes the differences between the protocol described in ISO 10589 and current practice. |
|
| |
| RFC 3789 | Introduction to the Survey of IPv4 Addresses in Currently Deployed IETF Standards Track and Experimental Documents |
| |
| Authors: | P. Nesser, II, A. Bergstrom, Ed.. |
| Date: | June 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3789 |
|
This document is a general overview and introduction to the v6opsIETF workgroup project of documenting all usage of IPv4 addresses inIETF standards track and experimental RFCs. It is broken into seven documents conforming to the current IETF areas. It also describes the methodology used during documentation, which types of RFCs have been documented, and provides a concatenated summary of results. |
|
| |
| RFC 3790 | Survey of IPv4 Addresses in Currently Deployed IETF Internet Area Standards Track and Experimental Documents |
| |
| Authors: | C. Mickles, Ed., P. Nesser, II. |
| Date: | June 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3790 |
|
This document seeks to document all usage of IPv4 addresses in currently deployed IETF Internet Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards(Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. |
|
| |
| RFC 3791 | Survey of IPv4 Addresses in Currently Deployed IETF Routing Area Standards Track and Experimental Documents |
| |
| Authors: | C. Olvera, P. Nesser, II. |
| Date: | June 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3791 |
|
This investigation work seeks to document all usage of IPv4 addresses in currently deployed IETF Routing Area documented standards. In order to successfully transition from an all IPv4 Internet to an allIPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies.It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards(Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. |
|
| |
| RFC 3792 | Survey of IPv4 Addresses in Currently Deployed IETF Security Area Standards Track and Experimental Documents |
| |
| Authors: | P. Nesser, II, A. Bergstrom, Ed.. |
| Date: | June 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3792 |
|
This document seeks to document all usage of IPv4 addresses in currently deployed IETF Security Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards(Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. |
|
| |
| RFC 3793 | Survey of IPv4 Addresses in Currently Deployed IETF Sub-IP Area Standards Track and Experimental Documents |
| |
| Authors: | P. Nesser, II, A. Bergstrom, Ed.. |
| Date: | June 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3793 |
|
This document seeks to document all usage of IPv4 addresses in currently deployed IETF Sub-IP Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards(Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. |
|
| |
| RFC 3794 | Survey of IPv4 Addresses in Currently Deployed IETF Transport Area Standards Track and Experimental Documents |
| |
| Authors: | P. Nesser, II, A. Bergstrom, Ed.. |
| Date: | June 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3794 |
|
This document seeks to document all usage of IPv4 addresses in currently deployed IETF Transport Area documented standards. In order to successfully transition from an all IPv4 Internet to an allIPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies.It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards(Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented. |
|
| |
| RFC 3795 | Survey of IPv4 Addresses in Currently Deployed IETF Application Area Standards Track and Experimental Documents |
| |
| Authors: | R. Sofia, P. Nesser, II. |
| Date: | June 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3795 |
|
This document describes IPv4 addressing dependencies in an attempt to clarify the necessary steps in re-designing and re-implementing specifications to become network address independent, or at least, to dually support IPv4 and IPv6. This transition requires several interim steps, one of them being the evolution of current IPv4 dependent specifications to a format independent of the type of IP addressing schema used. Hence, it is hoped that specifications will be re-designed and re-implemented to become network address independent, or at least to dually support IPv4 and IPv6.
To achieve that step, it is necessary to survey and document all IPv4 dependencies experienced by current standards (Full, Draft, andProposed) as well as Experimental RFCs. Hence, this document describes IPv4 addressing dependencies that deployed IETF ApplicationArea documented Standards may experience. |
|
| |
| RFC 3796 | Survey of IPv4 Addresses in Currently Deployed IETF Operations & Management Area Standards Track and Experimental Documents |
| |
| Authors: | P. Nesser, II, A. Bergstrom, Ed.. |
| Date: | June 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3796 |
|
This document seeks to record all usage of IPv4 addresses in currently deployed IETF Operations & Management Area accepted standards. In order to successfully transition from an all IPv4Internet to an all IPv6 Internet, many interim steps will be taken.One of these steps is the evolution of current protocols that haveIPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 andIPv6. To this end, all Standards (Full, Draft, and Proposed), as well as Experimental RFCs, will be surveyed and any dependencies will be documented. |
|
| |
| RFC 3797 | Publicly Verifiable Nominations Committee (NomCom) Random Selection |
| |
|
|
This document describes a method for making random selections in such a way that the unbiased nature of the choice is publicly verifiable.As an example, the selection of the voting members of the IETFNominations Committee (NomCom) from the pool of eligible volunteers is used. Similar techniques would be applicable to other cases. |
|
| |
| RFC 3806 | Printer Finishing MIB |
| |
| Authors: | R. Bergman, H. Lewis, I. McDonald. |
| Date: | June 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3806 |
|
This document defines a MIB module for the management of printer finishing device subunits. The finishing device subunits applicable to this MIB are an integral part of the Printer System. This MIB applies only to a Finisher Device that is connected to a PrinterSystem. |
|
| |
| RFC 3808 | IANA Charset MIB |
| |
| Authors: | I. McDonald. |
| Date: | June 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3808 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.This IANA Charset MIB is now an IANA registry. In particular, a single textual convention 'IANACharset' is defined that may be used to specify charset labels in MIB objects. 'IANACharset' was extracted from Printer MIB v2 (RFC 3805). 'IANACharset' was originally defined (and mis-named) as 'CodedCharSet' in Printer MIB v1 (RFC 1759). A tool has been written in C, that may be used byIANA to regenerate this IANA Charset MIB, when future charsets are registered in accordance with the IANA Charset RegistrationProcedures (RFC 2978). |
|
| |
| RFC 3809 | Generic Requirements for Provider Provisioned Virtual Private Networks (PPVPN) |
| |
| Authors: | A. Nagarajan, Ed.. |
| Date: | June 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3809 |
|
This document describes generic requirements for Provider ProvisionedVirtual Private Networks (PPVPN). The requirements are categorized into service requirements, provider requirements and engineering requirements. These requirements are not specific to any particular type of PPVPN technology, but rather apply to all PPVPN technologies.All PPVPN technologies are expected to meet the umbrella set of requirements described in this document. |
|
| |
| RFC 3817 | Layer 2 Tunneling Protocol (L2TP) Active Discovery Relay for PPP over Ethernet (PPPoE) |
| |
| Authors: | W. Townsley, R. da Silva. |
| Date: | June 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3817 |
|
The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links.Layer Two Tunneling Protocol (L2TP), facilitates the tunneling of PPP packets across an intervening packet-switched network. And yet a third protocol, PPP over Ethernet (PPPoE) describes how to build PPP sessions and to encapsulate PPP packets over Ethernet.
L2TP Active Discovery Relay for PPPoE describes a method to relayActive Discovery and Service Selection functionality from PPPoE over the reliable control channel within L2TP. Two new L2TP control message types and associated PPPoE-specific Attribute Value Pairs(AVPs) for L2TP are defined. This relay mechanism provides enhanced integration of a specific feature in the PPPoE tunneling protocol with L2TP. |
|
| |
| RFC 3823 | MIME Media Type for the Systems Biology Markup Language (SBML) |
| |
| Authors: | B. Kovitz. |
| Date: | June 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3823 |
|
This document registers the MIME sub-type application/sbml+xml, a media type for SBML, the Systems Biology Markup Language. SBML is defined by The SBML Team at the California Institute of Technology and interested members of the systems biology community. |
|
| |
| RFC 3824 | Using E.164 numbers with the Session Initiation Protocol (SIP) |
| |
| Authors: | J. Peterson, H. Liu, J. Yu, B. Campbell. |
| Date: | June 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3824 |
|
There are a number of contexts in which telephone numbers are employed by Session Initiation Protocol (SIP) applications, many of which can be addressed by ENUM. Although SIP was one of the primary applications for which ENUM was created, there is nevertheless a need to define procedures for integrating ENUM with SIP implementations.This document illustrates how the two protocols might work in concert, and clarifies the authoring and processing of ENUM records for SIP applications. It also provides guidelines for instances in which ENUM, for whatever reason, cannot be used to resolve a telephone number. |
|
| |
| RFC 3827 | Additional Snoop Datalink Types |
| |
| Authors: | K. Sarcar. |
| Date: | June 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3827 |
|
The snoop file format provides a way to store and exchange datalink layer packet traces. This document describes extensions to this file format to support new media. |
|
| |
| RFC 3829 | Lightweight Directory Access Protocol (LDAP) Authorization Identity Request and Response Controls |
| |
| Authors: | R. Weltman, M. Smith, M. Wahl. |
| Date: | July 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3829 |
|
This document extends the Lightweight Directory Access Protocol(LDAP) bind operation with a mechanism for requesting and returning the authorization identity it establishes. Specifically, this document defines the Authorization Identity Request and Response controls for use with the Bind operation. |
|
| |
| RFC 3833 | Threat Analysis of the Domain Name System (DNS) |
| |
| Authors: | D. Atkins, R. Austein. |
| Date: | August 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3833 |
|
Although the DNS Security Extensions (DNSSEC) have been under development for most of the last decade, the IETF has never written down the specific set of threats against which DNSSEC is designed to protect. Among other drawbacks, this cart-before-the-horse situation has made it difficult to determine whether DNSSEC meets its design goals, since its design goals are not well specified. This note attempts to document some of the known threats to the DNS, and, in doing so, attempts to measure to what extent (if any) DNSSEC is a useful tool in defending against these threats. |
|
| |
| RFC 3835 | An Architecture for Open Pluggable Edge Services (OPES) |
| |
| Authors: | A. Barbir, R. Penno, R. Chen, M. Hofmann, H. Orman. |
| Date: | August 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3835 |
|
This memo defines an architecture that enables the creation of an application service in which a data provider, a data consumer, and zero or more application entities cooperatively implement a data stream service. |
|
| |
| RFC 3836 | Requirements for Open Pluggable Edge Services (OPES) Callout Protocols |
| |
| Authors: | A. Beck, M. Hofmann, H. Orman, R. Penno, A. Terzis. |
| Date: | August 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3836 |
|
This document specifies the requirements that the OPES (OpenPluggable Edge Services) callout protocol must satisfy in order to support the remote execution of OPES services. The requirements are intended to help evaluate possible protocol candidates, as well as to guide the development of such protocols. |
|
| |
| RFC 3837 | Security Threats and Risks for Open Pluggable Edge Services (OPES) |
| |
| Authors: | A. Barbir, O. Batuner, B. Srinivas, M. Hofmann, H. Orman. |
| Date: | August 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3837 |
|
The document investigates the security threats associated with theOpen Pluggable Edge Services (OPES) and discusses the effects of security threats on the underlying architecture. The main goal of this document is threat discovery and analysis. The document does not specify or recommend any solutions. |
|
| |
| RFC 3838 | Policy, Authorization, and Enforcement Requirements of the Open Pluggable Edge Services (OPES) |
| |
| Authors: | A. Barbir, O. Batuner, A. Beck, T. Chan, H. Orman. |
| Date: | August 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3838 |
|
This document describes policy, authorization, and enforcement requirements for the selection of the services to be applied to a given Open Pluggable Edge Services (OPES) flow. |
|
| |
| RFC 3844 | IETF Problem Resolution Process |
| |
| Authors: | E. Davies, Ed., J. Hofmann, Ed.. |
| Date: | August 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3844 |
|
This Informational document records the history of discussions in theProblem WG during 2003 of how to resolve the problems described in the IETF Problem Statement. It decomposes each of the problems described into a few areas for improvement and categorizes them as either problems affecting the routine processes used to create standards or problems affecting the fundamental structure and practices of the IETF. Expeditious and non-disruptive solutions are proposed for the problems affecting routine processes.
The document also lists suggested ways to handle the development of solutions for the structure and practices problems proposed in IETF discussions. Neither the working group nor the wider IETF has reached consensus on a recommendation for any of the proposals. This document therefore has no alternative but to suggest that the search for structure and practices solutions be handed back to the control of the IESG.
While there was working group consensus on the processes for short- term and medium term improvements, there was no working group consensus on the proposals for longer-term improvements. This document therefore includes longer-term improvement proposals only as a matter of record; they must not be regarded as recommendations from the working group. |
|
| |
| RFC 3847 | Restart Signaling for Intermediate System to Intermediate System (IS-IS) |
| |
|
|
This document describes a mechanism for a restarting router to signal to its neighbors that it is restarting, allowing them to reestablish their adjacencies without cycling through the down state, while still correctly initiating database synchronization.
This document additionally describes a mechanism for a restarting router to determine when it has achieved LSP database synchronization with its neighbors and a mechanism to optimize LSP database synchronization, while minimizing transient routing disruption when a router starts. |
|
| |
| RFC 3849 | IPv6 Address Prefix Reserved for Documentation |
| |
| Authors: | G. Huston, A. Lord, P. Smith. |
| Date: | July 2004 |
| Formats: | txt json html |
| Updated by: | RFC 9637 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3849 |
|
To reduce the likelihood of conflict and confusion when relating documented examples to deployed systems, an IPv6 unicast address prefix is reserved for use in examples in RFCs, books, documentation, and the like. Since site-local and link-local unicast addresses have special meaning in IPv6, these addresses cannot be used in many example situations. The document describes the use of the IPv6 address prefix 2001:DB8::/32 as a reserved prefix for use in documentation. |
|
| |
| RFC 3867 | Payment Application Programmers Interface (API) for v1.0 Internet Open Trading Protocol (IOTP) |
| |
| Authors: | Y. Kawatsura, M. Hiroya, H. Beykirch. |
| Date: | November 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3867 |
|
The Internet Open Trading Protocol (IOTP) provides a data exchange format for trading purposes while integrating existing pure payment protocols seamlessly. This motivates the multiple layered system architecture which consists of at least some generic IOTP application core and multiple specific payment modules.
This document addresses a common interface between the IOTP application core and the payment modules, enabling the interoperability between these kinds of modules. Furthermore, such an interface provides the foundations for a plug-in-mechanism in actual implementations of IOTP application cores.
Such interfaces exist at the Consumers', the Merchants' and thePayment Handlers' installations connecting the IOTP application core and the payment software components/legacy systems. |
|
| |
| RFC 3869 | IAB Concerns and Recommendations Regarding Internet Research and Evolution |
| |
| Authors: | R. Atkinson, Ed., S. Floyd, Ed., Internet Architecture Board. |
| Date: | August 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3869 |
|
This document discusses IAB concerns that ongoing research is needed to further the evolution of the Internet infrastructure, and that consistent, sufficient non-commercial funding is needed to enable such research. |
|
| |
| RFC 3870 | application/rdf+xml Media Type Registration |
| |
| Authors: | A. Swartz. |
| Date: | September 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3870 |
|
This document describes a media type (application/rdf+xml) for use with the Extensible Markup Language (XML) serialization of theResource Description Framework (RDF). RDF is a language designed to support the Semantic Web, by facilitating resource description and data exchange on the Web. RDF provides common structures that can be used for interoperable data exchange and follows the World Wide WebConsortium (W3C) design principles of interoperability, evolution, and decentralization. |
|
| |
| RFC 3871 | Operational Security Requirements for Large Internet Service Provider (ISP) IP Network Infrastructure |
| |
|
|
This document defines a list of operational security requirements for the infrastructure of large Internet Service Provider (ISP) IP networks (routers and switches). A framework is defined for specifying "profiles", which are collections of requirements applicable to certain network topology contexts (all, core-only, edge-only...). The goal is to provide network operators a clear, concise way of communicating their security requirements to vendors. |
|
| |
| RFC 3874 | A 224-bit One-way Hash Function: SHA-224 |
| |
| Authors: | R. Housley. |
| Date: | September 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3874 |
|
This document specifies a 224-bit one-way hash function, calledSHA-224. SHA-224 is based on SHA-256, but it uses a different initial value and the result is truncated to 224 bits. |
|
| |
| RFC 3875 | The Common Gateway Interface (CGI) Version 1.1 |
| |
| Authors: | D. Robinson, K. Coar. |
| Date: | October 2004 |
| Formats: | txt json pdf html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3875 |
|
The Common Gateway Interface (CGI) is a simple interface for running external programs, software or gateways under an information server in a platform-independent manner. Currently, the supported information servers are HTTP servers.
The interface has been in use by the World-Wide Web (WWW) since 1993.This specification defines the 'current practice' parameters of the'CGI/1.1' interface developed and documented at the U.S. NationalCentre for Supercomputing Applications. This document also defines the use of the CGI/1.1 interface on UNIX(R) and other, similar systems. |
|
| |
| RFC 3881 | Security Audit and Access Accountability Message XML Data Definitions for Healthcare Applications |
| |
| Authors: | G. Marshall. |
| Date: | September 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3881 |
|
This document defines the format of data to be collected and minimum set of attributes that need to be captured for security auditing in healthcare application systems. The format is defined as an XML schema, which is intended as a reference for healthcare standards developers and application designers. It consolidates several previous documents on security auditing of healthcare data. |
|
| |
| RFC 3882 | Configuring BGP to Block Denial-of-Service Attacks |
| |
| Authors: | D. Turk. |
| Date: | September 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3882 |
|
This document describes an operational technique that uses BGP communities to remotely trigger black-holing of a particular destination network to block denial-of-service attacks. Black-holing can be applied on a selection of routers rather than all BGP-speaking routers in the network. The document also describes a sinkhole tunnel technique using BGP communities and tunnels to pull traffic into a sinkhole router for analysis. |
|
| |
| RFC 3884 | Use of IPsec Transport Mode for Dynamic Routing |
| |
| Authors: | J. Touch, L. Eggert, Y. Wang. |
| Date: | September 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3884 |
|
IPsec can secure the links of a multihop network to protect communication between trusted components, e.g., for a secure virtual network (VN), overlay, or virtual private network (VPN). Virtual links established by IPsec tunnel mode can conflict with routing and forwarding inside VNs because IP routing depends on references to interfaces and next-hop IP addresses. The IPsec tunnel mode specification is ambiguous on this issue, so even compliant implementations cannot be trusted to avoid conflicts. An alternative to tunnel mode uses non-IPsec IPIP encapsulation together with IPsec transport mode, which we call IIPtran. IPIP encapsulation occurs as a separate initial step, as the result of a forwarding lookup of theVN packet. IPsec transport mode processes the resulting (tunneled) IP packet with an SA determined through a security association database(SAD) match on the tunnel header. IIPtran supports dynamic routing inside the VN without changes to the current IPsec architecture.IIPtran demonstrates how to configure any compliant IPsec implementation to avoid the aforementioned conflicts. IIPtran is also compared to several alternative mechanisms for VN routing and their respective impact on IPsec, routing, policy enforcement, and interactions with the Internet Key Exchange (IKE). |
|
| |
| RFC 3888 | Message Tracking Model and Requirements |
| |
| Authors: | T. Hansen. |
| Date: | September 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3888 |
|
Customers buying enterprise message systems often ask: Can I track the messages? Message tracking is the ability to find out the path that a particular message has taken through a messaging system and the current routing status of that message. This document provides a model of message tracking that can be used for understanding theInternet-wide message infrastructure and to further enhance those capabilities to include message tracking, as well as requirements for proposed message tracking solutions. |
|
| |
| RFC 3897 | Open Pluggable Edge Services (OPES) Entities and End Points Communication |
| |
| Authors: | A. Barbir. |
| Date: | September 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3897 |
|
This memo documents tracing and non-blocking (bypass) requirements for Open Pluggable Edge Services (OPES). |
|
| |
| RFC 3902 | The "application/soap+xml" media type |
| |
| Authors: | M. Baker, M. Nottingham. |
| Date: | September 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3902 |
|
This document defines the "application/soap+xml" media type which can be used to describe SOAP 1.2 messages serialized as XML 1.0. |
|
| |
| RFC 3904 | Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks |
| |
| Authors: | C. Huitema, R. Austein, S. Satapati, R. van der Pol. |
| Date: | September 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3904 |
|
This document analyzes issues involved in the transition of"unmanaged networks" from IPv4 to IPv6. Unmanaged networks typically correspond to home networks or small office networks. A companion paper analyzes out the requirements for mechanisms needed in various transition scenarios of these networks to IPv6. Starting from this analysis, we evaluate the suitability of mechanisms that have already been specified, proposed, or deployed. |
|
| |
| RFC 3905 | A Template for IETF Patent Disclosures and Licensing Declarations |
| |
| Authors: | V. See, Ed.. |
| Date: | September 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3905 |
|
This document describes a proposal for one form of a template forIETF patent disclosures and licensing declarations. The optional use of this template is meant to simplify the process of such disclosures and licensing declarations and to assist disclosers in providing the necessary information to meet the obligations documented in RFC 3668. |
|
| |
| RFC 3906 | Calculating Interior Gateway Protocol (IGP) Routes Over Traffic Engineering Tunnels |
| |
| Authors: | N. Shen, H. Smit. |
| Date: | October 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3906 |
|
This document describes how conventional hop-by-hop link-state routing protocols interact with new Traffic Engineering capabilities to create Interior Gateway Protocol (IGP) shortcuts. In particular, this document describes how Dijkstra's Shortest Path First (SPF) algorithm can be adapted so that link-state IGPs will calculate IP routes to forward traffic over tunnels that are set up by TrafficEngineering. |
|
| |
| RFC 3914 | Open Pluggable Edge Services (OPES) Treatment of IAB Considerations |
| |
| Authors: | A. Barbir, A. Rousskov. |
| Date: | October 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3914 |
|
IETF Internet Architecture Board (IAB) expressed nine architecture- level considerations for the Open Pluggable Edge Services (OPES) framework. This document describes how OPES addresses those considerations. |
|
| |
| RFC 3916 | Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3) |
| |
| Authors: | X. Xiao, Ed., D. McPherson, Ed., P. Pate, Ed.. |
| Date: | September 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3916 |
|
This document describes base requirements for the Pseudo-WireEmulation Edge to Edge Working Group (PWE3 WG). It provides guidelines for other working group documents that will define mechanisms for providing pseudo-wire emulation of Ethernet, ATM, andFrame Relay. Requirements for pseudo-wire emulation of TDM (i.e.,"synchronous bit streams at rates defined by ITU G.702") are defined in another document. It should be noted that the PWE3 WG standardizes mechanisms that can be used to provide PWE3 services, but not the services themselves. |
|
| |
| RFC 3917 | Requirements for IP Flow Information Export (IPFIX) |
| |
| Authors: | J. Quittek, T. Zseby, B. Claise, S. Zander. |
| Date: | October 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3917 |
|
This memo defines requirements for the export of measured IP flow information out of routers, traffic measurement probes, and middleboxes. |
|
| |
| RFC 3918 | Methodology for IP Multicast Benchmarking |
| |
| Authors: | D. Stopp, B. Hickman. |
| Date: | October 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3918 |
|
The purpose of this document is to describe methodology specific to the benchmarking of multicast IP forwarding devices. It builds upon the tenets set forth in RFC 2544, RFC 2432 and other IETFBenchmarking Methodology Working Group (BMWG) efforts. This document seeks to extend these efforts to the multicast paradigm.
The BMWG produces two major classes of documents: BenchmarkingTerminology documents and Benchmarking Methodology documents. TheTerminology documents present the benchmarks and other related terms.The Methodology documents define the procedures required to collect the benchmarks cited in the corresponding Terminology documents. |
|
| |
| RFC 3919 | Remote Network Monitoring (RMON) Protocol Identifiers for IPv6 and Multi Protocol Label Switching (MPLS) |
| |
| Authors: | E. Stephan, J. Palet. |
| Date: | October 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3919 |
|
This memo defines additional (to those in RFC 2896) protocol identifier examples for IP version 6 and MPLS protocols. These can be used to produce valid protocolDirTable INDEX encodings, as defined by the Remote Network Monitoring MIB (Management Information Base)Version 2 [RFC2021] and the RMON Protocol Identifier Reference[RFC2895].
This document contains additional (to those in RFC 2896) protocol identifier macros for well-known protocols. A conformant implementation of the RMON-2 MIB [RFC2021] can be accomplished without the use of these protocol identifiers, and accordingly, this document does not specify any IETF standard. It is published to encourage better interoperability between RMON-2 agent implementations, by providing RMON related IPv6 and MPLS protocol information. |
|
| |
| RFC 3924 | Cisco Architecture for Lawful Intercept in IP Networks |
| |
| Authors: | F. Baker, B. Foster, C. Sharp. |
| Date: | October 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3924 |
|
For the purposes of this document, lawful intercept is the lawfully authorized interception and monitoring of communications. Service providers are being asked to meet legal and regulatory requirements for the interception of voice as well as data communications in IP networks in a variety of countries worldwide. Although requirements vary from country to country, some requirements remain common even though details such as delivery formats may differ. This document describes Cisco's Architecture for supporting lawful intercept in IP networks. It provides a general solution that has a minimum set of common interfaces. This document does not attempt to address any of the specific legal requirements or obligations that may exist in a particular country. |
|
| |
| RFC 3930 | The Protocol versus Document Points of View in Computer Protocols |
| |
| Authors: | D. Eastlake 3rd. |
| Date: | October 2004 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3930 |
|
This document contrasts two points of view: the "document" point of view, where digital objects of interest are like pieces of paper written and viewed by people, and the "protocol" point of view where objects of interest are composite dynamic network messages. Although each point of view has a place, adherence to a document point of view can be damaging to protocol design. By understanding both points of view, conflicts between them may be clarified and reduced. |
|
| |
| RFC 3937 | A Uniform Resource Name (URN) Namespace for the International Press Telecommunications Council (IPTC) |
| |
| Authors: | M. Steidl. |
| Date: | October 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3937 |
|
This document describes a URN (Uniform Resource Name) namespace for identifying persistent resources published by the International PressTelecommunications Council (IPTC). These resources include XML DataType Definition files (DTD), XML Schema, Namespaces in XML, XSL stylesheets, other XML based document and documents of other data formats like PDF documents, Microsoft Office documents and others. |
|
| |
| RFC 3943 | Transport Layer Security (TLS) Protocol Compression Using Lempel-Ziv-Stac (LZS) |
| |
|
|
The Transport Layer Security (TLS) protocol (RFC 2246) includes features to negotiate selection of a lossless data compression method as part of the TLS Handshake Protocol and then to apply the algorithm associated with the selected method as part of the TLS RecordProtocol. TLS defines one standard compression method, which specifies that data exchanged via the record protocol will not be compressed. This document describes an additional compression method associated with the Lempel-Ziv-Stac (LZS) lossless data compression algorithm for use with TLS. This document also defines the application of the LZS algorithm to the TLS Record Protocol. |
|
| |
| RFC 3944 | H.350 Directory Services |
| |
| Authors: | T. Johnson, S. Okubo, S. Campos. |
| Date: | December 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3944 |
|
The International Telecommunications Union Standardization Sector(ITU-T) has created the H.350 series of Recommendations that specify directory services architectures in support of multimedia conferencing protocols. The goal of the architecture is to'directory enable' multimedia conferencing so that these services can leverage existing identity management and enterprise directories. A particular goal is to enable an enterprise or service provider to maintain a canonical source of users and their multimedia conferencing systems, so that multiple call servers from multiple vendors, supporting multiple protocols, can all access the same data store.
Because SIP is an IETF standard, the contents of H.350 and H.350.4 are made available via this document to the IETF community. This document contains the entire normative text of ITU-T RecommendationsH.350 and H.350.4 in sections 4 and 5, respectively. The remaining sections are included only in this document, not in the ITU-T version. |
|
| |
| RFC 3954 | Cisco Systems NetFlow Services Export Version 9 |
| |
| Authors: | B. Claise, Ed.. |
| Date: | October 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3954 |
|
This document specifies the data export format for version 9 of CiscoSystems' NetFlow services, for use by implementations on the network elements and/or matching collector programs. The version 9 export format uses templates to provide access to observations of IP packet flows in a flexible and extensible manner. A template defines a collection of fields, with corresponding descriptions of structure and semantics. |
|
| |
| RFC 3955 | Evaluation of Candidate Protocols for IP Flow Information Export (IPFIX) |
| |
| Authors: | S. Leinen. |
| Date: | October 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3955 |
|
This document contains an evaluation of the five candidate protocols for an IP Flow Information Export (IPFIX) protocol, based on the requirements document produced by the IPFIX Working Group. The protocols are characterized and grouped in broad categories, and evaluated against specific requirements. Finally, a recommendation is made to select the NetFlow v9 protocol as the basis for the IPFIX specification. |
|
| |
| RFC 3960 | Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP) |
| |
| Authors: | G. Camarillo, H. Schulzrinne. |
| Date: | December 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3960 |
|
This document describes how to manage early media in the SessionInitiation Protocol (SIP) using two models: the gateway model and the application server model. It also describes the inputs one needs to consider in defining local policies for ringing tone generation. |
|
| |
| RFC 3964 | Security Considerations for 6to4 |
| |
| Authors: | P. Savola, C. Patel. |
| Date: | December 2004 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3964 |
|
The IPv6 interim mechanism 6to4 (RFC3056) uses automaticIPv6-over-IPv4 tunneling to interconnect IPv6 networks. The architecture includes 6to4 routers and 6to4 relay routers, which accept and decapsulate IPv4 protocol-41 ("IPv6-in-IPv4") traffic from any node in the IPv4 internet. This characteristic enables a number of security threats, mainly Denial of Service. It also makes it easier for nodes to spoof IPv6 addresses. This document discusses these issues in more detail and suggests enhancements to alleviate the problems. |
|
| |
| RFC 3974 | SMTP Operational Experience in Mixed IPv4/v6 Environments |
| |
| Authors: | M. Nakamura, J. Hagino. |
| Date: | January 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3974 |
|
This document discusses SMTP operational experiences in IPv4/v6 dual stack environments. As IPv6-capable SMTP servers are deployed, it has become apparent that certain configurations of MX records are necessary for stable dual-stack (IPv4 and IPv6) SMTP operation. This document clarifies the existing problems in the transition period between IPv4 SMTP and IPv6 SMTP. It also defines operational requirements for stable IPv4/v6 SMTP operation.
This document does not define any new protocol. |
|
| |
| RFC 3975 | OMA-IETF Standardization Collaboration |
| |
| Authors: | G. Huston, Ed., I. Leuca, Ed.. |
| Date: | January 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3975 |
|
This document describes the standardization collaboration between theOpen Mobile Alliance (OMA) and the Internet Engineering Task Force(IETF). |
|
| |
| RFC 3976 | Interworking SIP and Intelligent Network (IN) Applications |
| |
| Authors: | V. K. Gurbani, F. Haerens, V. Rastogi. |
| Date: | January 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3976 |
|
Public Switched Telephone Network (PSTN) services such as 800-number routing (freephone), time-and-day routing, credit-card calling, and virtual private network (mapping a private network number into a public number) are realized by the Intelligent Network (IN). This document addresses means to support existing IN services from SessionInitiation Protocol (SIP) endpoints for an IP-host-to-phone call.The call request is originated on a SIP endpoint, but the services to the call are provided by the data and procedures resident in thePSTN/IN. To provide IN services in a transparent manner to SIP endpoints, this document describes the mechanism for interworking SIP and Intelligent Network Application Part (INAP). |
|
| |
| RFC 3985 | Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture |
| |
| Authors: | S. Bryant, Ed., P. Pate, Ed.. |
| Date: | March 2005 |
| Formats: | txt html json |
| Updated by: | RFC 5462 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3985 |
|
This document describes an architecture for Pseudo Wire EmulationEdge-to-Edge (PWE3). It discusses the emulation of services such asFrame Relay, ATM, Ethernet, TDM, and SONET/SDH over packet switched networks (PSNs) using IP or MPLS. It presents the architectural framework for pseudo wires (PWs), defines terminology, and specifies the various protocol elements and their functions. |
|
| |
| RFC 3989 | Middlebox Communications (MIDCOM) Protocol Semantics |
| |
| Authors: | M. Stiemerling, J. Quittek, T. Taylor. |
| Date: | February 2005 |
| Formats: | txt html json |
| Obsoleted by: | RFC 5189 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3989 |
|
This memo specifies semantics for a Middlebox Communication (MIDCOM) protocol to be used by MIDCOM agents for interacting with middleboxes such as firewalls and Network Address Translators (NATs). The semantics discussion does not include any specification of a concrete syntax or a transport protocol. However, a concrete protocol is expected to implement the specified semantics or, more likely, a superset of it. The MIDCOM protocol semantics is derived from theMIDCOM requirements, from the MIDCOM framework, and from working group decisions. |
|
| |
| RFC 3990 | Configuration and Provisioning for Wireless Access Points (CAPWAP) Problem Statement |
| |
| Authors: | B. O'Hara, P. Calhoun, J. Kempf. |
| Date: | February 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3990 |
|
This document describes the Configuration and Provisioning forWireless Access Points (CAPWAP) problem statement. |
|
| |
| RFC 3991 | Media Gateway Control Protocol (MGCP) Redirect and Reset Package |
| |
| Authors: | B. Foster, F. Andreasen. |
| Date: | February 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3991 |
|
The base Media Gateway Control Protocol (MGCP) specification (RFC3435) allows endpoints to be redirected one endpoint at a time. This document provides extensions in the form of a new MGCP package that provides mechanisms for redirecting and resetting a group of endpoints. It also includes the ability to more accurately redirect endpoints by allowing a list of Call Agents to be specified in a preferred order. |
|
| |
| RFC 3992 | Media Gateway Control Protocol (MGCP) Lockstep State Reporting Mechanism |
| |
| Authors: | B. Foster, F. Andreasen. |
| Date: | February 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3992 |
|
A Media Gateway Control Protocol (MGCP) endpoint that has encountered an adverse failure condition (such as being involved in a transient call when a Call Agent failover occurred) could be left in a lockstep state whereby events are quarantined but not notified. The MGCP package described in this document provides a mechanism for reporting these situations so that the new Call Agent can take the necessary fault recovery procedures. |
|
| |
| RFC 3997 | Internet Printing Protocol (IPP): Requirements for IPP Notifications |
| |
| Authors: | T. Hastings, Ed., R. K. deBry, H. Lewis. |
| Date: | March 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 3997 |
|
This document is one of a set of documents that together describe all aspects of the Internet Printing Protocol (IPP). IPP is an application-level protocol that can be used for distributed printing on the Internet. There are multiple parts to IPP, but the primary architectural components are the Model, the Protocol, and an interface to Directory Services. This document provides a statement of the requirements for notifications as an optional part of an IPPService. |
|
| |
| RFC 4009 | The SEED Encryption Algorithm |
| |
| Authors: | J. Park, S. Lee, J. Kim, J. Lee. |
| Date: | February 2005 |
| Formats: | txt html json |
| Obsoleted by: | RFC 4269 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4009 |
|
This document describes the SEED encryption algorithm, which has been adopted by most of the security systems in the Republic of Korea.Included are a description of the cipher and the key scheduling algorithm (Section 2), the S-boxes (Appendix A), and a set of test vectors (Appendix B). |
|
| |
| RFC 4016 | Protocol for Carrying Authentication and Network Access (PANA) Threat Analysis and Security Requirements |
| |
| Authors: | M. Parthasarathy. |
| Date: | March 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4016 |
|
This document discusses the threats to protocols used to carry authentication for network access. The security requirements arising from these threats will be used as additional input to the Protocol for Carrying Authentication for Network Access (PANA) Working Group for designing the IP based network access authentication protocol. |
|
| |
| RFC 4017 | Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs |
| |
| Authors: | D. Stanley, J. Walker, B. Aboba. |
| Date: | March 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4017 |
|
The IEEE 802.11i MAC Security Enhancements Amendment makes use ofIEEE 802.1X, which in turn relies on the Extensible AuthenticationProtocol (EAP). This document defines requirements for EAP methods used in IEEE 802.11 wireless LAN deployments. The material in this document has been approved by IEEE 802.11 and is being presented as an IETF RFC for informational purposes. |
|
| |
| RFC 4024 | Voice Messaging Client Behaviour |
| |
| Authors: | G. Parsons, J. Maruszak. |
| Date: | July 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4024 |
|
This document defines the expected behaviour of a client to various aspects of a Voice Profile for Internet Mail (VPIM) message or any voice and/or fax message. |
|
| |
| RFC 4026 | Provider Provisioned Virtual Private Network (VPN) Terminology |
| |
| Authors: | L. Andersson, T. Madsen. |
| Date: | March 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4026 |
|
The widespread interest in provider-provisioned Virtual PrivateNetwork (VPN) solutions lead to memos proposing different and overlapping solutions. The IETF working groups (first ProviderProvisioned VPNs and later Layer 2 VPNs and Layer 3 VPNs) have discussed these proposals and documented specifications. This has lead to the development of a partially new set of concepts used to describe the set of VPN services.
To a certain extent, more than one term covers the same concept, and sometimes the same term covers more than one concept. This document seeks to make the terminology in the area clearer and more intuitive. |
|
| |
| RFC 4027 | Domain Name System Media Types |
| |
| Authors: | S. Josefsson. |
| Date: | April 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4027 |
|
This document registers the media types application/dns and text/dns in accordance with RFC 2048. The application/dns media type is used to identify data on the detached Domain Name System (DNS) format described in RFC 2540. The text/dns media type is used to identify master files as described in RFC 1035. |
|
| |
| RFC 4029 | Scenarios and Analysis for Introducing IPv6 into ISP Networks |
| |
| Authors: | M. Lind, V. Ksinant, S. Park, A. Baudot, P. Savola. |
| Date: | March 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4029 |
|
This document describes different scenarios for the introduction ofIPv6 into an ISP's existing IPv4 network without disrupting the IPv4 service. The scenarios for introducing IPv6 are analyzed, and the relevance of already defined transition mechanisms are evaluated.Known challenges are also identified. |
|
| |
| RFC 4031 | Service Requirements for Layer 3 Provider Provisioned Virtual Private Networks (PPVPNs) |
| |
| Authors: | M. Carugi, Ed., D. McDysan, Ed.. |
| Date: | April 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4031 |
|
This document provides requirements for Layer 3 Virtual PrivateNetworks (L3VPNs). It identifies requirements applicable to a number of individual approaches that a Service Provider may use to provision a Virtual Private Network (VPN) service. This document expresses a service provider perspective, based upon past experience with IP- based service offerings and the ever-evolving needs of the customers of such services. Toward this end, it first defines terminology and states general requirements. Detailed requirements are expressed from a customer perspective as well as that of a service provider. |
|
| |
| RFC 4038 | Application Aspects of IPv6 Transition |
| |
| Authors: | M-K. Shin, Ed., Y-G. Hong, J. Hagino, P. Savola, E. M. Castro. |
| Date: | March 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4038 |
|
As IPv6 networks are deployed and the network transition is discussed, one should also consider how to enable IPv6 support in applications running on IPv6 hosts, and the best strategy to developIP protocol support in applications. This document specifies scenarios and aspects of application transition. It also proposes guidelines on how to develop IP version-independent applications during the transition period. |
|
| |
| RFC 4041 | Requirements for Morality Sections in Routing Area Drafts |
| |
| Authors: | A. Farrel. |
| Date: | 1 April 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4041 |
|
It has often been the case that morality has not been given proper consideration in the design and specification of protocols produced within the Routing Area. This has led to a decline in the moral values within the Internet and attempts to retrofit a suitable moral code to implemented and deployed protocols has been shown to be sub-optimal.
This document specifies a requirement for all new Routing AreaInternet-Drafts to include a "Morality Considerations" section, and gives guidance on what that section should contain. |
|
| |
| RFC 4042 | UTF-9 and UTF-18 Efficient Transformation Formats of Unicode |
| |
| Authors: | M. Crispin. |
| Date: | 1 April 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4042 |
|
ISO-10646 defines a large character set called the UniversalCharacter Set (UCS), which encompasses most of the world's writing systems. The same set of codepoints is defined by Unicode, which further defines additional character properties and other implementation details. By policy of the relevant standardization committees, changes to Unicode and amendments and additions toISO/IEC 10646 track each other, so that the character repertoires and code point assignments remain in synchronization.
The current representation formats for Unicode (UTF-7, UTF-8, UTF-16) are not storage and computation efficient on platforms that utilize the 9 bit nonet as a natural storage unit instead of the 8 bit octet.
This document describes a transformation format of Unicode that takes advantage of the nonet so that the format will be storage and computation efficient. |
|
| |
| RFC 4046 | Multicast Security (MSEC) Group Key Management Architecture |
| |
| Authors: | M. Baugher, R. Canetti, L. Dondeti, F. Lindholm. |
| Date: | April 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4046 |
|
This document defines the common architecture for Multicast Security(MSEC) key management protocols to support a variety of application, transport, and network layer security protocols. It also defines the group security association (GSA), and describes the key management protocols that help establish a GSA. The framework and guidelines described in this document permit a modular and flexible design of group key management protocols for a variety of different settings that are specialized to applications needs. MSEC key management protocols may be used to facilitate secure one-to-many, many-to-many, or one-to-one communication. |
|
| |
| RFC 4047 | MIME Sub-type Registrations for Flexible Image Transport System (FITS) |
| |
| Authors: | S. Allen, D. Wells. |
| Date: | April 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4047 |
|
This document describes the registration of the Multipurpose InternetMail Extensions (MIME) sub-types to be used by the international astronomical community for the interchange of Flexible ImageTransport System (FITS) files. The encoding is defined by the published FITS standard documents. The FITS format has been in use since 1979, and almost all data from astronomical observations are interchanged by using FITS. |
|
| |
| RFC 4048 | RFC 1888 Is Obsolete |
| |
|
|
This document recommends that RFC 1888, on Open SystemsInterconnection (OSI) Network Service Access Points (NSAPs) and IPv6, be reclassified as Historic, as most of it has no further value, apart from one section, which is faulty. |
|
| |
| RFC 4050 | Using the Elliptic Curve Signature Algorithm (ECDSA) for XML Digital Signatures |
| |
| Authors: | S. Blake-Wilson, G. Karlinger, T. Kobayashi, Y. Wang. |
| Date: | April 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4050 |
|
This document specifies how to use Elliptic Curve Digital SignatureAlgorithm (ECDSA) with XML Signatures. The mechanism specified provides integrity, message authentication, and/or signer authentication services for data of any type, whether located within the XML that includes the signature or included by reference. |
|
| |
| RFC 4054 | Impairments and Other Constraints on Optical Layer Routing |
| |
| Authors: | J. Strand, Ed., A. Chiu, Ed.. |
| Date: | May 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4054 |
|
Optical networking poses a number challenges for Generalized Multi-Protocol Label Switching (GMPLS). Fundamentally, optical technology is an analog rather than digital technology whereby the optical layer is lowest in the transport hierarchy and hence has an intimate relationship with the physical geography of the network. This contribution surveys some of the aspects of optical networks that impact routing and identifies possible GMPLS responses for each: (1)Constraints arising from the design of new software controllable network elements, (2) Constraints in a single all-optical domain without wavelength conversion, (3) Complications arising in more complex networks incorporating both all-optical and opaque architectures, and (4) Impacts of diversity constraints. |
|
| |
| RFC 4057 | IPv6 Enterprise Network Scenarios |
| |
| Authors: | J. Bound, Ed.. |
| Date: | June 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4057 |
|
This document describes the scenarios for IPv6 deployment within enterprise networks. It defines a small set of basic enterprise scenarios and includes pertinent questions to allow enterprise administrators to further refine their deployment scenarios.Enterprise deployment requirements are discussed in terms of coexistence with IPv4 nodes, networks and applications, and in terms of basic network infrastructure requirements for IPv6 deployment.The scenarios and requirements described in this document will be the basis for further analysis to determine what coexistence techniques and mechanisms are needed for enterprise IPv6 deployment. The results of that analysis will be published in a separate document. |
|
| |
| RFC 4058 | Protocol for Carrying Authentication for Network Access (PANA) Requirements |
| |
| Authors: | A. Yegin, Ed., Y. Ohba, R. Penno, G. Tsirtsis, C. Wang. |
| Date: | May 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4058 |
|
It is expected that future IP devices will have a variety of access technologies to gain network connectivity. Currently there are access-specific mechanisms for providing client information to the network for authentication and authorization purposes. In addition to being limited to specific access media (e.g., 802.1X for IEEE 802 links), some of these protocols are limited to specific network topologies (e.g., PPP for point-to-point links). The goal of this document is to identify the requirements for a link-layer agnostic protocol that allows a host and a network to authenticate each other for network access. This protocol will run between a client's device and an agent in the network where the agent might be a client of theAAA infrastructure. |
|
| |
| RFC 4059 | Internet X.509 Public Key Infrastructure Warranty Certificate Extension |
| |
| Authors: | D. Linsenbardt, S. Pontius, A. Sturgeon. |
| Date: | May 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4059 |
|
This document describes a certificate extension to explicitly state the warranty offered by a Certificate Authority (CA) for the certificate containing the extension. |
|
| |
| RFC 4061 | Benchmarking Basic OSPF Single Router Control Plane Convergence |
| |
| Authors: | V. Manral, R. White, A. Shaikh. |
| Date: | April 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4061 |
|
This document provides suggestions for measuring OSPF single router control plane convergence. Its initial emphasis is on the control plane of a single OSPF router. We do not address forwarding plane performance.
NOTE: In this document, the word "convergence" relates to single router control plane convergence only. |
|
| |
| RFC 4062 | OSPF Benchmarking Terminology and Concepts |
| |
| Authors: | V. Manral, R. White, A. Shaikh. |
| Date: | April 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4062 |
|
This document explains the terminology and concepts used in OSPF benchmarking. Although some of these terms may be defined elsewhere(and we will refer the reader to those definitions in some cases) we include discussions concerning these terms, as they relate specifically to the tasks involved in benchmarking the OSPF protocol. |
|
| |
| RFC 4063 | Considerations When Using Basic OSPF Convergence Benchmarks |
| |
| Authors: | V. Manral, R. White, A. Shaikh. |
| Date: | April 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4063 |
|
This document discusses the applicability of various tests for measuring single router control plane convergence, specifically in regard to the Open Shortest First (OSPF) protocol. There are two general sections in this document, the first discusses advantages and limitations of specific OSPF convergence tests, and the second discusses more general pitfalls to be considered when routing protocol convergence is tested. |
|
| |
| RFC 4074 | Common Misbehavior Against DNS Queries for IPv6 Addresses |
| |
| Authors: | Y. Morishita, T. Jinmei. |
| Date: | May 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4074 |
|
There is some known misbehavior of DNS authoritative servers when they are queried for AAAA resource records. Such behavior can blockIPv4 communication that should actually be available, cause a significant delay in name resolution, or even make a denial of service attack. This memo describes details of known cases and discusses their effects. |
|
| |
| RFC 4076 | Renumbering Requirements for Stateless Dynamic Host Configuration Protocol for IPv6 (DHCPv6) |
| |
| Authors: | T. Chown, S. Venaas, A. Vijayabhaskar. |
| Date: | May 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4076 |
|
IPv6 hosts using Stateless Address Autoconfiguration are able to configure their IPv6 address and default router settings automatically. However, further settings are not available. If these hosts wish to configure their DNS, NTP, or other specific settings automatically, the stateless variant of the Dynamic HostConfiguration Protocol for IPv6 (DHCPv6) could be used. This combination of Stateless Address Autoconfiguration and statelessDHCPv6 could be used quite commonly in IPv6 networks. However, hosts using this combination currently have no means by which to be informed of changes in stateless DHCPv6 option settings; e.g., the addition of a new NTP server address, a change in DNS search paths, or full site renumbering. This document is presented as a problem statement from which a solution should be proposed in a subsequent document. |
|
| |
| RFC 4078 | The TV-Anytime Content Reference Identifier (CRID) |
| |
| Authors: | N. Earnshaw, S. Aoki, A. Ashley, W. Kameyama. |
| Date: | May 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4078 |
|
The Uniform Resource Locator (URL) scheme "CRID:" has been devised to allow references to current or future scheduled publications of broadcast media content over television distribution platforms and the Internet.
The initial intended application is as an embedded link within scheduled programme description metadata that can be used by the home user or agent to associate a programme selection with the corresponding programme location information for subsequent automatic acquisition.
This document reproduces the TV-Anytime CRID definition found in theTV-Anytime content referencing specification, and is published as anRFC for ease of access and registration with the Internet AssignedNumbers Authority (IANA). |
|
| |
| RFC 4079 | A Presence Architecture for the Distribution of GEOPRIV Location Objects |
| |
| Authors: | J. Peterson. |
| Date: | July 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4079 |
|
GEOPRIV defines the concept of a 'using protocol' -- a protocol that carries GEOPRIV location objects. GEOPRIV also defines various scenarios for the distribution of location objects that require the concepts of subscriptions and asynchronous notifications. This document examines some existing IETF work on the concept of presence, shows how presence architectures map onto GEOPRIV architectures, and moreover demonstrates that tools already developed for presence could be reused to simplify the standardization and implementation ofGEOPRIV. |
|
| |
| RFC 4080 | Next Steps in Signaling (NSIS): Framework |
| |
| Authors: | R. Hancock, G. Karagiannis, J. Loughney, S. Van den Bosch. |
| Date: | June 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4080 |
|
The Next Steps in Signaling (NSIS) working group is considering protocols for signaling information about a data flow along its path in the network. The NSIS suite of protocols is envisioned to support various signaling applications that need to install and/or manipulate such state in the network. Based on existing work on signaling requirements, this document proposes an architectural framework for these signaling protocols.
This document provides a model for the network entities that take part in such signaling, and for the relationship between signaling and the rest of network operation. We decompose the overall signaling protocol suite into a generic (lower) layer, with separate upper layers for each specific signaling application. |
|
| |
| RFC 4081 | Security Threats for Next Steps in Signaling (NSIS) |
| |
| Authors: | H. Tschofenig, D. Kroeselberg. |
| Date: | June 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4081 |
|
This threats document provides a detailed analysis of the security threats relevant to the Next Steps in Signaling (NSIS) protocol suite. It calls attention to, and helps with the understanding of, various security considerations in the NSIS Requirements, Framework, and Protocol proposals. This document does not describe vulnerabilities of specific parts of the NSIS protocol suite. |
|
| |
| RFC 4082 | Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction |
| |
| Authors: | A. Perrig, D. Song, R. Canetti, J. D. Tygar, B. Briscoe. |
| Date: | June 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4082 |
|
This document introduces Timed Efficient Stream Loss-tolerantAuthentication (TESLA). TESLA allows all receivers to check the integrity and authenticate the source of each packet in multicast or broadcast data streams. TESLA requires no trust between receivers, uses low-cost operations per packet at both sender and receiver, can tolerate any level of loss without retransmissions, and requires no per-receiver state at the sender. TESLA can protect receivers against denial of service attacks in certain circumstances. Each receiver must be loosely time-synchronized with the source in order to verify messages, but otherwise receivers do not have to send any messages. TESLA alone cannot support non-repudiation of the data source to third parties.
This informational document is intended to assist in writing standardizable and secure specifications for protocols based on TESLA in different contexts. |
|
| |
| RFC 4083 | Input 3rd-Generation Partnership Project (3GPP) Release 5 Requirements on the Session Initiation Protocol (SIP) |
| |
| Authors: | M. Garcia-Martin. |
| Date: | May 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4083 |
|
The 3rd-Generation Partnership Project (3GPP) has selected SessionInitiation Protocol (SIP) as the session establishment protocol for the 3GPP IP Multimedia Core Network Subsystem (IMS). IMS is part ofRelease 5 of the 3GPP specifications. Although SIP is a protocol that fulfills most of the requirements for establishing a session in an IP network, SIP has never been evaluated against the specific 3GPP requirements for operation in a cellular network. In this document, we express the requirements identified by 3GPP to support SIP forRelease 5 of the 3GPP IMS in cellular networks. |
|
| |
| RFC 4089 | IAB and IESG Recommendation for IETF Administrative Restructuring |
| |
| Authors: | S. Hollenbeck, Ed., IAB and IESG. |
| Date: | May 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4089 |
|
This document describes a joint recommendation of the InternetArchitecture Board and the Internet Engineering Steering Group for administrative restructuring of the Internet Engineering Task Force.The IETF Chair declared that the IETF had consensus to follow this recommendation on November 11, 2004. Further work has been done to revise and refine the structures proposed. The recommendation is being published for the record. |
|
| |
| RFC 4093 | Problem Statement: Mobile IPv4 Traversal of Virtual Private Network (VPN) Gateways |
| |
| Authors: | F. Adrangi, Ed., H. Levkowetz, Ed.. |
| Date: | August 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4093 |
|
Deploying Mobile-IP v4 in networks that are connected to the Internet through a Virtual Private Network (VPN) gateway presents some problems that do not currently have well-described solutions. This document aims to describe and illustrate these problems, and to propose some guidelines for possible solutions. |
|
| |
| RFC 4094 | Analysis of Existing Quality-of-Service Signaling Protocols |
| |
| Authors: | J. Manner, X. Fu. |
| Date: | May 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4094 |
|
This document reviews some of the existing Quality of Service (QoS) signaling protocols for an IP network. The goal here is to learn from them and to avoid common misconceptions. Further, we need to avoid mistakes during the design and implementation of any new protocol in this area. |
|
| |
| RFC 4096 | Policy-Mandated Labels Such as "Adv:" in Email Subject Headers Considered Ineffective At Best |
| |
| Authors: | C. Malamud. |
| Date: | May 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4096 |
|
This memo discusses policies that require certain labels to be inserted in the "Subject:" header of a mail message. Such policies are difficult to specify accurately while remaining compliant with key RFCs and are likely to be ineffective at best. This memo discusses an alternate, standards-compliant approach that is significantly simpler to specify and is somewhat less likely to be ineffective. |
|
| |
| RFC 4097 | Middlebox Communications (MIDCOM) Protocol Evaluation |
| |
|
|
This document provides an evaluation of the applicability of SNMP(Simple Network Management Protocol), RSIP (Realm Specific InternetProtocol), Megaco, Diameter, and COPS (Common Open Policy Service) as the MIDCOM (Middlebox Communications) protocol. A summary of each of the proposed protocols against the MIDCOM requirements and the MIDCOM framework is provided. Compliancy of each of the protocols against each requirement is detailed. A conclusion summarizes how each of the protocols fares in the evaluation. |
|
| |
| RFC 4098 | Terminology for Benchmarking BGP Device Convergence in the Control Plane |
| |
| Authors: | H. Berkowitz, E. Davies, Ed., S. Hares, P. Krishnaswamy, M. Lepp. |
| Date: | June 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4098 |
|
This document establishes terminology to standardize the description of benchmarking methodology for measuring eBGP convergence in the control plane of a single BGP device. Future documents will address iBGP convergence, the initiation of forwarding based on converged control plane information and multiple interacting BGP devices. This terminology is applicable to both IPv4 and IPv6. Illustrative examples of each version are included where relevant. |
|
| |
| RFC 4101 | Writing Protocol Models |
| |
| Authors: | E. Rescorla, IAB. |
| Date: | June 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4101 |
|
The IETF process depends on peer review. However, IETF documents are generally written to be useful for implementors, not reviewers. In particular, while great care is generally taken to provide a complete description of the state machines and bits on the wire, this level of detail tends to get in the way of initial understanding. This document describes an approach for providing protocol "models" that allow reviewers to quickly grasp the essence of a system. |
|
| |
| RFC 4105 | Requirements for Inter-Area MPLS Traffic Engineering |
| |
| Authors: | J.-L. Le Roux, Ed., J.-P. Vasseur, Ed., J. Boyle, Ed.. |
| Date: | June 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4105 |
|
This document lists a detailed set of functional requirements for the support of inter-area MPLS Traffic Engineering (inter-area MPLS TE).It is intended that solutions that specify procedures and protocol extensions for inter-area MPLS TE satisfy these requirements. |
|
| |
| RFC 4110 | A Framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs) |
| |
| Authors: | R. Callon, M. Suzuki. |
| Date: | July 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4110 |
|
This document provides a framework for Layer 3 Provider-ProvisionedVirtual Private Networks (PPVPNs). This framework is intended to aid in the standardization of protocols and mechanisms for support of layer 3 PPVPNs. It is the intent of this document to produce a coherent description of the significant technical issues that are important in the design of layer 3 PPVPN solutions. Selection of specific approaches, making choices regarding engineering tradeoffs, and detailed protocol specification, are outside of the scope of this framework document. |
|
| |
| RFC 4111 | Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs) |
| |
|
|
This document addresses security aspects pertaining to Provider-Provisioned Virtual Private Networks (PPVPNs). First, it describes the security threats in the context of PPVPNs and defensive techniques to combat those threats. It considers security issues deriving both from malicious behavior of anyone and from negligent or incorrect behavior of the providers. It also describes how these security attacks should be detected and reported. It then discusses possible user requirements for security of a PPVPN service. These user requirements translate into corresponding provider requirements.In addition, the provider may have additional requirements to make its network infrastructure secure to a level that can meet the PPVPN customer's expectations. Finally, this document defines a template that may be used to describe and analyze the security characteristics of a specific PPVPN technology. |
|
| |
| RFC 4115 | A Differentiated Service Two-Rate, Three-Color Marker with Efficient Handling of in-Profile Traffic |
| |
| Authors: | O. Aboul-Magd, S. Rabie. |
| Date: | July 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4115 |
|
This document describes a two-rate, three-color marker that has been in use for data services including Frame Relay services. This marker can be used for metering per-flow traffic in the emerging IP and L2VPN services. The marker defined here is different from previously defined markers in the handling of the in-profile traffic.Furthermore, this marker doesn't impose peak-rate shaping requirements on customer edge (CE) devices. |
|
| |
| RFC 4116 | IPv4 Multihoming Practices and Limitations |
| |
| Authors: | J. Abley, K. Lindqvist, E. Davies, B. Black, V. Gill. |
| Date: | July 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4116 |
|
Multihoming is an essential component of service for many Internet sites. This document describes some implementation strategies for multihoming with IPv4 and enumerates features for comparison with other multihoming proposals (particularly those related to IPv6). |
|
| |
| RFC 4117 | Transcoding Services Invocation in the Session Initiation Protocol (SIP) Using Third Party Call Control (3pcc) |
| |
| Authors: | G. Camarillo, E. Burger, H. Schulzrinne, A. van Wijk. |
| Date: | June 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4117 |
|
This document describes how to invoke transcoding services usingSession Initiation Protocol (SIP) and third party call control. This way of invocation meets the requirements for SIP regarding transcoding services invocation to support deaf, hard of hearing and speech-impaired individuals. |
|
| |
| RFC 4118 | Architecture Taxonomy for Control and Provisioning of Wireless Access Points (CAPWAP) |
| |
| Authors: | L. Yang, P. Zerfos, E. Sadot. |
| Date: | June 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4118 |
|
This document provides a taxonomy of the architectures employed in the existing IEEE 802.11 products in the market, by analyzingWireless LAN (WLAN) functions and services and describing the different variants in distributing these functions and services among the architectural entities. |
|
| |
| RFC 4123 | Session Initiation Protocol (SIP)-H.323 Interworking Requirements |
| |
| Authors: | H. Schulzrinne, C. Agboh. |
| Date: | July 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4123 |
|
This document describes the requirements for the logical entity known as the Session Initiation Protocol (SIP)-H.323 Interworking Function(SIP-H.323 IWF) that will allow the interworking between SIP andH.323. |
|
| |
| RFC 4128 | Bandwidth Constraints Models for Differentiated Services (Diffserv)-aware MPLS Traffic Engineering: Performance Evaluation |
| |
|
|
"Differentiated Services (Diffserv)-aware MPLS Traffic EngineeringRequirements", RFC 3564, specifies the requirements and selection criteria for Bandwidth Constraints Models. Two such models, theMaximum Allocation and the Russian Dolls, are described therein.This document complements RFC 3564 by presenting the results of a performance evaluation of these two models under various operational conditions: normal load, overload, preemption fully or partially enabled, pure blocking, or complete sharing. |
|
| |
| RFC 4134 | Examples of S/MIME Messages |
| |
| Authors: | P. Hoffman, Ed.. |
| Date: | July 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4134 |
|
This document gives examples of message bodies formatted usingS/MIME. Specifically, it has examples of Cryptographic MessageSyntax (CMS) objects and S/MIME messages (including the MIME formatting). It includes examples of many common CMS formats. The purpose of this document is to help increase interoperability forS/MIME and other protocols that rely on CMS. |
|
| |
| RFC 4135 | Goals of Detecting Network Attachment in IPv6 |
| |
| Authors: | JH. Choi, G. Daley. |
| Date: | August 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4135 |
|
When a host establishes a new link-layer connection, it may or may not have a valid IP configuration for Internet connectivity. The host may check for link change (i.e., determine whether a link change has occurred), and then, based on the result, it can automatically decide whether its IP configuration is still valid. During link identity detection, the host may also collect necessary information to initiate a new IP configuration if the IP subnet has changed. In this memo, this procedure is called Detecting Network Attachment(DNA). DNA schemes should be precise, sufficiently fast, secure, and of limited signaling. |
|
| |
| RFC 4136 | OSPF Refresh and Flooding Reduction in Stable Topologies |
| |
| Authors: | P. Pillay-Esnault. |
| Date: | July 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4136 |
|
This document describes an extension to the OSPF protocol to reduce periodic flooding of Link State Advertisements (LSAs) in stable topologies.
Current OSPF behavior requires that all LSAs, except DoNotAge LSAs, to be refreshed every 30 minutes. This document proposes to generalize the use of DoNotAge LSAs in order to reduce protocol traffic in stable topologies. |
|
| |
| RFC 4137 | State Machines for Extensible Authentication Protocol (EAP) Peer and Authenticator |
| |
| Authors: | J. Vollbrecht, P. Eronen, N. Petroni, Y. Ohba. |
| Date: | August 2005 |
| Formats: | txt pdf html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4137 |
|
This document describes a set of state machines for ExtensibleAuthentication Protocol (EAP) peer, EAP stand-alone authenticator(non-pass-through), EAP backend authenticator (for use onAuthentication, Authorization, and Accounting (AAA) servers), and EAP full authenticator (for both local and pass-through). This set of state machines shows how EAP can be implemented to support deployment in either a peer/authenticator or peer/authenticator/AAA Server environment. The peer and stand-alone authenticator machines are illustrative of how the EAP protocol defined in RFC 3748 may be implemented. The backend and full/pass-through authenticators illustrate how EAP/AAA protocol support defined in RFC 3579 may be implemented. Where there are differences, RFC 3748 and RFC 3579 are authoritative.
The state machines are based on the EAP "Switch" model. This model includes events and actions for the interaction between the EAPSwitch and EAP methods. A brief description of the EAP "Switch" model is given in the Introduction section.
The state machine and associated model are informative only.Implementations may achieve the same results using different methods. |
|
| |
| RFC 4139 | Requirements for Generalized MPLS (GMPLS) Signaling Usage and Extensions for Automatically Switched Optical Network (ASON) |
| |
| Authors: | D. Papadimitriou, J. Drake, J. Ash, A. Farrel, L. Ong. |
| Date: | July 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4139 |
|
The Generalized Multi-Protocol Label Switching (GMPLS) suite of protocols has been defined to control different switching technologies and different applications. These include support for requesting Time Division Multiplexing (TDM) connections, includingSynchronous Optical Network (SONET)/Synchronous Digital Hierarchy(SDH) and Optical Transport Networks (OTNs).
This document concentrates on the signaling aspects of the GMPLS suite of protocols. It identifies the features to be covered by theGMPLS signaling protocol to support the capabilities of anAutomatically Switched Optical Network (ASON). This document provides a problem statement and additional requirements for theGMPLS signaling protocol to support the ASON functionality. |
|
| |
| RFC 4144 | How to Gain Prominence and Influence in Standards Organizations |
| |
| Authors: | D. Eastlake 3rd. |
| Date: | September 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4144 |
|
This document provides simple guidelines that can make it easier for you to gain prominence and influence in most standards organizations. |
|
| |
| RFC 4146 | Simple New Mail Notification |
| |
| Authors: | R. Gellens. |
| Date: | August 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4146 |
|
This memo documents a long-standing technique, supported by a large number of mail servers, which allows users to be notified of new mail. In addition to server support, there are a number of clients that support this, ranging from full email clients to specialized clients whose only purpose is to receive new mail notifications and alert a mail client.
In brief, the server sends the string "nm_notifyuser" CRLF to the finger port on the IP address (either configured or last used) of the user who has received new mail. |
|
| |
| RFC 4147 | Proposed Changes to the Format of the IANA IPv6 Registry |
| |
| Authors: | G. Huston. |
| Date: | August 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4147 |
|
This document proposes a revised format for the IANA IPv6 address registries. Rather than providing a formal definition of the format, it is described by giving examples of the (current as of preparation of this document) contents of the registries in the proposed format.The proposed format would bring the IANA IPv6 address registries into alignment with the current IPv6 Address Architecture specification, as well as update it to a more useful and generally accepted format. |
|
| |
| RFC 4151 | The 'tag' URI Scheme |
| |
| Authors: | T. Kindberg, S. Hawke. |
| Date: | October 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4151 |
|
This document describes the "tag" Uniform Resource Identifier (URI) scheme. Tag URIs (also known as "tags") are designed to be unique across space and time while being tractable to humans. They are distinct from most other URIs in that they have no authoritative resolution mechanism. A tag may be used purely as an entity identifier. Furthermore, using tags has some advantages over the common practice of using "http" URIs as identifiers for non-HTTP-accessible resources. |
|
| |
| RFC 4152 | A Uniform Resource Name (URN) Namespace for the Common Language Equipment Identifier (CLEI) Code |
| |
| Authors: | K. Tesink, R. Fox. |
| Date: | August 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4152 |
|
This document describes a Uniform Resource Name (URN) namespace(RFC 3406) for the assignment of the Common Language EquipmentIdentifier (CLEI) code, which is used in messages standardized byANSI. The URN namespace is managed by Telcordia Technologies, Inc., as the maintenance agent for ANSI T1.213. The CLEI code is a globally unique, ten-character alphanumeric intelligent code assigned by Telcordia Technologies at the request of equipment suppliers. TheCLEI code identifies communications equipment by specifying product type and features. There is a one-to-one relationship between a CLEI code and supplier's product ID (the manufacturer's name and the part number along with its version number). |
|
| |
| RFC 4153 | XML Voucher: Generic Voucher Language |
| |
| Authors: | K. Fujimura, M. Terada, D. Eastlake 3rd. |
| Date: | September 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4153 |
|
This document specifies rules for defining voucher properties in XML syntax. A voucher is a logical entity that represents a right to claim goods or services. A voucher can be used to transfer a wide range of electronic values, including coupons, tickets, loyalty points, and gift certificates, which often have to be processed in the course of payment and/or delivery transactions. |
|
| |
| RFC 4154 | Voucher Trading System Application Programming Interface (VTS-API) |
| |
| Authors: | M. Terada, K. Fujimura. |
| Date: | September 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4154 |
|
This document specifies the Voucher Trading System ApplicationProgramming Interface (VTS-API). The VTS-API allows a wallet or other application to issue, transfer, and redeem vouchers in a uniform manner independent of the VTS implementation. The VTS is a system for securely transferring vouchers; e.g., coupons, tickets, loyalty points, and gift certificates. This process is often necessary in the course of payment and/or delivery transactions. |
|
| |
| RFC 4155 | The application/mbox Media Type |
| |
| Authors: | E. Hall. |
| Date: | September 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4155 |
|
This memo requests that the application/mbox media type be authorized for allocation by the IESG, according to the terms specified in RFC2048. This memo also defines a default format for the mbox database, which must be supported by all conformant implementations. |
|
| |
| RFC 4158 | Internet X.509 Public Key Infrastructure: Certification Path Building |
| |
| Authors: | M. Cooper, Y. Dzambasow, P. Hesse, S. Joseph, R. Nicholas. |
| Date: | September 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4158 |
|
This document provides guidance and recommendations to developers building X.509 public-key certification paths within their applications. By following the guidance and recommendations defined in this document, an application developer is more likely to develop a robust X.509 certificate-enabled application that can build valid certification paths across a wide range of PKI environments. |
|
| |
| RFC 4160 | Internet Fax Gateway Requirements |
| |
| Authors: | K. Mimura, K. Yokoyama, T. Satoh, C. Kanaide, C. Allocchio. |
| Date: | August 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4160 |
|
To allow connectivity between the General Switched Telephone Network facsimile service (GSTN fax) and the e-mail-based Internet Fax service (i-fax) an "Internet Fax Gateway" is required. This document provides recommendations for the functionality of Internet FaxGateways. In this context, an "offramp gateway" provides facsimile data transmission from i-fax to GSTN fax; vice versa, an "onramp gateway" provides data transmission form GSTN fax to i-fax. The recommendations in this document apply to the integrated service including Internet Fax terminals, computers with i-fax software on the Internet, and GSTN Fax terminals on the GSTN. |
|
| |
| RFC 4161 | Guidelines for Optional Services for Internet Fax Gateways |
| |
| Authors: | K. Mimura, K. Yokoyama, T. Satoh, K. Watanabe, C. Kanaide. |
| Date: | August 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4161 |
|
To allow connectivity between the general switched telephone network facsimile service (GSTN fax) and the e-mail-based Internet Fax service (i-fax), an "Internet Fax Gateway" is required. This document provides guidelines for the optional functionality ofInternet Fax Gateways. In this context, an "offramp gateway" provides facsimile data transmission from i-fax to GSTN fax; vice versa, an "onramp gateway" provides data transmission from GSTN fax to i-fax. The recommendations in this document apply to the integrated service including Internet Fax terminals, computers with i-fax software on the Internet, and GSTN fax terminals on the GSTN.
This document supplements the recommendation for minimal features of an Internet Fax Gateway. In particular, it covers techniques for dropping duplicated fax messages, automatic fax re-transmission, error, return notice, and log handling, and possible authorization methods by DTMF (Dual Tone Multi-Frequency) for onramp gateways. |
|
| |
| RFC 4163 | RObust Header Compression (ROHC): Requirements on TCP/IP Header Compression |
| |
| Authors: | L-E. Jonsson. |
| Date: | August 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4163 |
|
This document contains requirements on the TCP/IP header compression scheme (profile) to be developed by the RObust Header Compression(ROHC) Working Group. The document discusses the scope of TCP compression, performance considerations, assumptions about the surrounding environment, as well as Intellectual Property Rights concerns. The structure of this document is inherited from RFC 3096, which defines IP/UDP/RTP requirements for ROHC. |
|
| |
| RFC 4166 | Telephony Signalling Transport over Stream Control Transmission Protocol (SCTP) Applicability Statement |
| |
| Authors: | L. Coene, J. Pastor-Balbas. |
| Date: | February 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4166 |
|
This document describes the applicability of the several protocols developed under the signalling transport framework. A description of the main issues regarding the use of the Stream Control TransmissionProtocol (SCTP) and an explanation of each adaptation layer for transport of telephony signalling information over IP infrastructure are given. |
|
| |
| RFC 4167 | Graceful OSPF Restart Implementation Report |
| |
| Authors: | A. Lindem. |
| Date: | October 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4167 |
|
Graceful OSPF Restart, as specified in RFC 3623, provides a mechanism whereby an OSPF router can stay on the forwarding path even as itsOSPF software is restarted. This document provides an implementation report for this extension to the base OSPF protocol. |
|
| |
| RFC 4169 | Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA) Version-2 |
| |
| Authors: | V. Torvinen, J. Arkko, M. Naslund. |
| Date: | November 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4169 |
|
HTTP Digest, as specified in RFC 2617, is known to be vulnerable to man-in-the-middle attacks if the client fails to authenticate the server in TLS, or if the same passwords are used for authentication in some other context without TLS. This is a general problem that exists not just with HTTP Digest, but also with other IETF protocols that use tunneled authentication. This document specifies version 2 of the HTTP Digest AKA algorithm (RFC 3310). This algorithm can be implemented in a way that it is resistant to the man-in-the-middle attack. |
|
| |
| RFC 4176 | Framework for Layer 3 Virtual Private Networks (L3VPN) Operations and Management |
| |
| Authors: | Y. El Mghazli, Ed., T. Nadeau, M. Boucadair, K. Chan, A. Gonguet. |
| Date: | October 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4176 |
|
This document provides a framework for the operation and management of Layer 3 Virtual Private Networks (L3VPNs). This framework intends to produce a coherent description of the significant technical issues that are important in the design of L3VPN management solutions. The selection of specific approaches, and making choices among information models and protocols are outside the scope of this document. |
|
| |
| RFC 4177 | Architectural Approaches to Multi-homing for IPv6 |
| |
| Authors: | G. Huston. |
| Date: | September 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4177 |
|
This memo provides an analysis of the architectural aspects of multi-homing support for the IPv6 protocol suite. The purpose of this analysis is to provide a taxonomy for classification of various proposed approaches to multi-homing. It is also an objective of this exercise to identify common aspects of this domain of study, and also to provide a framework that can allow exploration of some of the further implications of various architectural extensions that are intended to support multi-homing. |
|
| |
| RFC 4179 | Using Universal Content Identifier (UCI) as Uniform Resource Names (URN) |
| |
| Authors: | S. Kang. |
| Date: | October 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4179 |
|
This document describes a Uniform Resource Name (URN) namespace for the National Computerization Agency (NCA) for naming persistent digital resources such as music, videos, texts, images, e-books, and other types of digital resources produced or managed by NCA. |
|
| |
| RFC 4180 | Common Format and MIME Type for Comma-Separated Values (CSV) Files |
| |
|
|
This RFC documents the format used for Comma-Separated Values (CSV) files and registers the associated MIME type "text/csv". |
|
| |
| RFC 4183 | A Suggested Scheme for DNS Resolution of Networks and Gateways |
| |
| Authors: | E. Warnicke. |
| Date: | September 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4183 |
|
This document suggests a method of using DNS to determine the network that contains a specified IP address, the netmask of that network, and the address(es) of first-hop routers(s) on that network. This method supports variable-length subnet masks, delegation of subnets on non-octet boundaries, and multiple routers per subnet. |
|
| |
| RFC 4185 | National and Local Characters for DNS Top Level Domain (TLD) Names |
| |
| Authors: | J. Klensin. |
| Date: | October 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4185 |
|
In the context of work on internationalizing the Domain Name System(DNS), there have been extensive discussions about "multilingual" or"internationalized" top level domain names (TLDs), especially for countries whose predominant language is not written in a Roman-based script. This document reviews some of the motivations for such domains, several suggestions that have been made to provide needed functionality, and the constraints that the DNS imposes. It then suggests an alternative, local translation, that may solve a superset of the problem while avoiding protocol changes, serious deployment delays, and other difficulties. The suggestion utilizes a localization technique in applications to permit any TLD to be accessed using the vocabulary and characters of any language. It is not restricted to language- or country-specific "multilingual" TLDs in the language(s) and script(s) of that country. |
|
| |
| RFC 4186 | Extensible Authentication Protocol Method for Global System for Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM) |
| |
| Authors: | H. Haverinen, Ed., J. Salowey, Ed.. |
| Date: | January 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4186 |
|
This document specifies an Extensible Authentication Protocol (EAP) mechanism for authentication and session key distribution using theGlobal System for Mobile Communications (GSM) Subscriber IdentityModule (SIM). GSM is a second generation mobile network standard.The EAP-SIM mechanism specifies enhancements to GSM authentication and key agreement whereby multiple authentication triplets can be combined to create authentication responses and session keys of greater strength than the individual GSM triplets. The mechanism also includes network authentication, user anonymity support, result indications, and a fast re-authentication procedure. |
|
| |
| RFC 4187 | Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA) |
| |
|
|
This document specifies an Extensible Authentication Protocol (EAP) mechanism for authentication and session key distribution that uses the Authentication and Key Agreement (AKA) mechanism. AKA is used in the 3rd generation mobile networks Universal MobileTelecommunications System (UMTS) and CDMA2000. AKA is based on symmetric keys, and typically runs in a Subscriber Identity Module, which is a UMTS Subscriber Identity Module, USIM, or a (Removable)User Identity Module, (R)UIM, similar to a smart card.
EAP-AKA includes optional identity privacy support, optional result indications, and an optional fast re-authentication procedure. |
|
| |
| RFC 4189 | Requirements for End-to-Middle Security for the Session Initiation Protocol (SIP) |
| |
| Authors: | K. Ono, S. Tachimoto. |
| Date: | October 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4189 |
|
A Session Initiation Protocol (SIP) User Agent (UA) does not always trust all intermediaries in its request path to inspect its message bodies and/or headers contained in its message. The UA might want to protect the message bodies and/or headers from intermediaries, except those that provide services based on its content. This situation requires a mechanism called "end-to-middle security" to secure the information passed between the UA and intermediaries, which does not interfere with end-to-end security. This document defines a set of requirements for a mechanism to achieve end-to-middle security. |
|
| |
| RFC 4190 | Framework for Supporting Emergency Telecommunications Service (ETS) in IP Telephony |
| |
| Authors: | K. Carlberg, I. Brown, C. Beard. |
| Date: | November 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4190 |
|
This document presents a framework for supporting authorized, emergency-related communication within the context of IP telephony.We present a series of objectives that reflect a general view of how authorized emergency service, in line with the EmergencyTelecommunications Service (ETS), should be realized within today'sIP architecture and service models. From these objectives, we present a corresponding set of protocols and capabilities, which provide a more specific set of recommendations regarding existingIETF protocols. Finally, we present two scenarios that act as guiding models for the objectives and functions listed in this document. These models, coupled with an example of an existing service in the Public Switched Telephone Network (PSTN), contribute to a constrained solution space. |
|
| |
| RFC 4192 | Procedures for Renumbering an IPv6 Network without a Flag Day |
| |
| Authors: | F. Baker, E. Lear, R. Droms. |
| Date: | September 2005 |
| Formats: | txt json html |
| Updates: | RFC 2072 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4192 |
|
This document describes a procedure that can be used to renumber a network from one prefix to another. It uses IPv6's intrinsic ability to assign multiple addresses to a network interface to provide continuity of network service through a "make-before-break" transition, as well as addresses naming and configuration management issues. It also uses other IPv6 features to minimize the effort and time required to complete the transition from the old prefix to the new prefix. |
|
| |
| RFC 4195 | A Uniform Resource Name (URN) Namespace for the TV-Anytime Forum |
| |
| Authors: | W. Kameyama. |
| Date: | October 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4195 |
|
This document describes a Uniform Resource Name (URN) namespace that is engineered by the TV-Anytime Forum for naming persistent resources published by the TV-Anytime Forum including the TV-Anytime ForumStandards, XML (Extensible Markup Language) Document TypeDefinitions, XML Schemas, Namespaces, and other documents. |
|
| |
| RFC 4197 | Requirements for Edge-to-Edge Emulation of Time Division Multiplexed (TDM) Circuits over Packet Switching Networks |
| |
| Authors: | M. Riegel, Ed.. |
| Date: | October 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4197 |
|
This document defines the specific requirements for edge-to-edge emulation of circuits carrying Time Division Multiplexed (TDM) digital signals of the Plesiochronous Digital Hierarchy as well as the Synchronous Optical NETwork/Synchronous Digital Hierarchy over packet-switched networks. It is aligned to the common architecture for Pseudo Wire Emulation Edge-to-Edge (PWE3). It makes references to the generic requirements for PWE3 where applicable and complements them by defining requirements originating from specifics of TDM circuits. |
|
| |
| RFC 4198 | A Uniform Resource Name (URN) Namespace for Federated Content |
| |
| Authors: | D. Tessman. |
| Date: | November 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4198 |
|
This document describes a URN (Uniform Resource Name) namespace for identifying content resources within federated content collections.A federated content collection often does not have a strong centralized authority but relies upon shared naming, metadata, and access conventions to provide interoperability among its members. |
|
| |
| RFC 4205 | Intermediate System to Intermediate System (IS-IS) Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) |
| |
|
|
This document specifies encoding of extensions to the IS-IS routing protocol in support of Generalized Multi-Protocol Label Switching(GMPLS). |
|
| |
| RFC 4212 | Alternative Certificate Formats for the Public-Key Infrastructure Using X.509 (PKIX) Certificate Management Protocols |
| |
| Authors: | M. Blinov, C. Adams. |
| Date: | October 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4212 |
|
The Public-Key Infrastructure using X.509 (PKIX) Working Group of theInternet Engineering Task Force (IETF) has defined a number of certificate management protocols. These protocols are primarily focused on X.509v3 public-key certificates. However, it is sometimes desirable to manage certificates in alternative formats as well.This document specifies how such certificates may be requested using the Certificate Request Message Format (CRMF) syntax that is used by several different protocols. It also explains how alternative certificate formats may be incorporated into such popular protocols as PKIX Certificate Management Protocol (PKIX-CMP) and CertificateManagement Messages over CMS (CMC). |
|
| |
| RFC 4215 | Analysis on IPv6 Transition in Third Generation Partnership Project (3GPP) Networks |
| |
| Authors: | J. Wiljakka, Ed.. |
| Date: | October 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4215 |
|
This document analyzes the transition to IPv6 in Third GenerationPartnership Project (3GPP) packet networks. These networks are based on General Packet Radio Service (GPRS) technology, and the radio network architecture is based on Global System for MobileCommunications (GSM) or Universal Mobile Telecommunications System(UMTS)/Wideband Code Division Multiple Access (WCDMA) technology.
The focus is on analyzing different transition scenarios and applicable transition mechanisms and finding solutions for those transition scenarios. In these scenarios, the User Equipment (UE) connects to other nodes, e.g., in the Internet, and IPv6/IPv4 transition mechanisms are needed. |
|
| |
| RFC 4216 | MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements |
| |
| Authors: | R. Zhang, Ed., J.-P. Vasseur, Ed.. |
| Date: | November 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4216 |
|
This document discusses requirements for the support of inter-AS MPLSTraffic Engineering (MPLS TE). Its main objective is to present a set of requirements and scenarios which would result in general guidelines for the definition, selection, and specification development for any technical solution(s) meeting these requirements and supporting the scenarios. |
|
| |
| RFC 4218 | Threats Relating to IPv6 Multihoming Solutions |
| |
| Authors: | E. Nordmark, T. Li. |
| Date: | October 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4218 |
|
This document lists security threats related to IPv6 multihoming.Multihoming can introduce new opportunities to redirect packets to different, unintended IP addresses.
The intent is to look at how IPv6 multihoming solutions might make the Internet less secure; we examine threats that are inherent to allIPv6 multihoming solutions rather than study any specific proposed solution. The threats in this document build upon the threats discovered and discussed as part of the Mobile IPv6 work. |
|
| |
| RFC 4219 | Things Multihoming in IPv6 (MULTI6) Developers Should Think About |
| |
| Authors: | E. Lear. |
| Date: | October 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4219 |
|
This document specifies a set of questions that authors should be prepared to answer as part of a solution to multihoming with IPv6.The questions do not assume that multihoming is the only problem of interest, nor do they demand a more general solution. |
|
| |
| RFC 4221 | Multiprotocol Label Switching (MPLS) Management Overview |
| |
| Authors: | T. Nadeau, C. Srinivasan, A. Farrel. |
| Date: | November 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4221 |
|
A range of Management Information Base (MIB) modules has been developed to help model and manage the various aspects ofMultiprotocol Label Switching (MPLS) networks. These MIB modules are defined in separate documents that focus on the specific areas of responsibility of the modules that they describe.
This document describes the management architecture for MPLS and indicates the interrelationships between the different MIB modules used for MPLS network management. |
|
| |
| RFC 4223 | Reclassification of RFC 1863 to Historic |
| |
|
|
This memo reclassifies RFC 1863, A BGP/IDRP Route Server alternative to a full mesh routing, to Historic status. This memo also obsoletesRFC 1863. |
|
| |
| RFC 4224 | RObust Header Compression (ROHC): ROHC over Channels That Can Reorder Packets |
| |
| Authors: | G. Pelletier, L-E. Jonsson, K. Sandlund. |
| Date: | January 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4224 |
|
RObust Header Compression (ROHC), RFC 3095, defines a framework for header compression, along with a number of compression protocols(profiles). One operating assumption for the profiles defined in RFC3095 is that the channel between compressor and decompressor is required to maintain packet ordering. This document discusses aspects of using ROHC over channels that can reorder packets. It provides guidelines on how to implement existing profiles over such channels, as well as suggestions for the design of new profiles. |
|
| |
| RFC 4225 | Mobile IP Version 6 Route Optimization Security Design Background |
| |
| Authors: | P. Nikander, J. Arkko, T. Aura, G. Montenegro, E. Nordmark. |
| Date: | December 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4225 |
|
This document is an account of the rationale behind the Mobile IPv6(MIPv6) Route Optimization security design. The purpose of this document is to present the thinking and to preserve the reasoning behind the Mobile IPv6 security design in 2001 - 2002.
The document has two target audiences: (1) helping MIPv6 implementors to better understand the design choices in MIPv6 security procedures, and (2) allowing people dealing with mobility or multi-homing to avoid a number of potential security pitfalls in their designs. |
|
| |
| RFC 4226 | HOTP: An HMAC-Based One-Time Password Algorithm |
| |
| Authors: | D. M'Raihi, M. Bellare, F. Hoornaert, D. Naccache, O. Ranen. |
| Date: | December 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4226 |
|
This document describes an algorithm to generate one-time password values, based on Hashed Message Authentication Code (HMAC). A security analysis of the algorithm is presented, and important parameters related to the secure deployment of the algorithm are discussed. The proposed algorithm can be used across a wide range of network applications ranging from remote Virtual Private Network(VPN) access, Wi-Fi network logon to transaction-oriented Web applications.
This work is a joint effort by the OATH (Open AuTHentication) membership to specify an algorithm that can be freely distributed to the technical community. The authors believe that a common and shared algorithm will facilitate adoption of two-factor authentication on the Internet by enabling interoperability across commercial and open-source implementations. |
|
| |
| RFC 4228 | Requirements for an IETF Draft Submission Toolset |
| |
| Authors: | A. Rousskov. |
| Date: | December 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4228 |
|
This document specifies requirements for an IETF toolset to facilitate Internet-Draft submission, validation, and posting. |
|
| |
| RFC 4229 | HTTP Header Field Registrations |
| |
| Authors: | M. Nottingham, J. Mogul. |
| Date: | December 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4229 |
|
This document defines the initial contents of a permanent IANA registry for HTTP header fields and a provisional repository for HTTP header fields, per RFC 3864. |
|
| |
| RFC 4230 | RSVP Security Properties |
| |
| Authors: | H. Tschofenig, R. Graveman. |
| Date: | December 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4230 |
|
This document summarizes the security properties of RSVP. The goal of this analysis is to benefit from previous work done on RSVP and to capture knowledge about past activities. |
|
| |
| RFC 4240 | Basic Network Media Services with SIP |
| |
| Authors: | E. Burger, Ed., J. Van Dyke, A. Spitzer. |
| Date: | December 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4240 |
|
In SIP-based networks, there is a need to provide basic network media services. Such services include network announcements, user interaction, and conferencing services. These services are basic building blocks, from which one can construct interesting applications. In order to have interoperability between servers offering these building blocks (also known as Media Servers) and application developers, one needs to be able to locate and invoke such services in a well defined manner.
This document describes a mechanism for providing an interoperable interface between Application Servers, which provide application services to SIP-based networks, and Media Servers, which provide the basic media processing building blocks. |
|
| |
| RFC 4241 | A Model of IPv6/IPv4 Dual Stack Internet Access Service |
| |
| Authors: | Y. Shirasaki, S. Miyakawa, T. Yamasaki, A. Takenouchi. |
| Date: | December 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4241 |
|
This memo is a digest of the user network interface specification ofNTT Communications' dual stack ADSL access service, which provide aIPv6/IPv4 dual stack services to home users. In order to simplify user setup, these services have a mechanism to configure IPv6 specific parameters automatically. The memo focuses on two basic parameters: the prefix assigned to the user and the addresses ofIPv6 DNS servers, and it specifies a way to deliver these parameters to Customer Premises Equipment (CPE) automatically. |
|
| |
| RFC 4245 | High-Level Requirements for Tightly Coupled SIP Conferencing |
| |
| Authors: | O. Levin, R. Even. |
| Date: | November 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4245 |
|
This document examines a wide range of conferencing requirements for tightly coupled SIP conferences. Separate documents will map the requirements to existing protocol primitives, define new protocol extensions, and introduce new protocols as needed. Together, these documents will provide a guide for building interoperable SIP conferencing applications. |
|
| |
| RFC 4246 | International Standard Audiovisual Number (ISAN) URN Definition |
| |
| Authors: | M. Dolan. |
| Date: | February 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4246 |
|
The International Standard Audiovisual Number (ISAN) is a standard numbering system for the unique and international identification of audiovisual works. This document is the definition of the formalUniform Resource Name (URN) Namespace Identifier (NID) for ISAN. |
|
| |
| RFC 4247 | Requirements for Header Compression over MPLS |
| |
| Authors: | J. Ash, B. Goode, J. Hand, R. Zhang. |
| Date: | November 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4247 |
|
Voice over IP (VoIP) typically uses the encapsulation voice/RTP/UDP/IP. When MPLS labels are added, this becomes voice/RTP/UDP/IP/MPLS-labels. For an MPLS VPN, the packet header is typically 48 bytes, while the voice payload is often no more than 30 bytes, for example. Header compression can significantly reduce the overhead through various compression mechanisms, such as enhanced compressed RTP (ECRTP) and robust header compression (ROHC). We consider using MPLS to route compressed packets over an MPLS LabelSwitched Path (LSP) without compression/decompression cycles at each router. This approach can increase the bandwidth efficiency as well as processing scalability of the maximum number of simultaneous flows that use header compression at each router. In this document, we give a problem statement, goals and requirements, and an example scenario. |
|
| |
| RFC 4249 | Implementer-Friendly Specification of Message and MIME-Part Header Fields and Field Components |
| |
| Authors: | B. Lilly. |
| Date: | January 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4249 |
|
Implementation of generators and parsers of header fields requires certain information about those fields. Interoperability is most likely when all such information is explicitly provided by the technical specification of the fields. Lacking such explicit information, implementers may guess, and interoperability may suffer.This memo identifies information useful to implementers of header field generators and parsers. |
|
| |
| RFC 4257 | Framework for Generalized Multi-Protocol Label Switching (GMPLS)-based Control of Synchronous Digital Hierarchy/Synchronous Optical Networking (SDH/SONET) Networks |
| |
| Authors: | G. Bernstein, E. Mannie, V. Sharma, E. Gray. |
| Date: | December 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4257 |
|
Generalized Multi-Protocol Label Switching (GMPLS) is a suite of protocol extensions to MPLS to make it generally applicable, to include, for example, control of non packet-based switching, and particularly, optical switching. One consideration is to use GMPLS protocols to upgrade the control plane of optical transport networks.This document illustrates this process by describing those extensions to GMPLS protocols that are aimed at controlling Synchronous DigitalHierarchy (SDH) or Synchronous Optical Networking (SONET) networks.SDH/SONET networks make good examples of this process for a variety of reasons. This document highlights extensions to GMPLS-related routing protocols to disseminate information needed in transport path computation and network operations, together with (G)MPLS protocol extensions required for the provisioning of transport circuits. New capabilities that an GMPLS control plane would bring to SDH/SONET networks, such as new restoration methods and multi-layer circuit establishment, are also discussed. |
|
| |
| RFC 4258 | Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Routing for the Automatically Switched Optical Network (ASON) |
| |
| Authors: | D. Brungard, Ed.. |
| Date: | November 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4258 |
|
The Generalized Multi-Protocol Label Switching (GMPLS) suite of protocols has been defined to control different switching technologies as well as different applications. These include support for requesting Time Division Multiplexing (TDM) connections including Synchronous Optical Network (SONET)/Synchronous DigitalHierarchy (SDH) and Optical Transport Networks (OTNs).
This document concentrates on the routing requirements placed on theGMPLS suite of protocols in order to support the capabilities and functionalities of an Automatically Switched Optical Network (ASON) as defined by the ITU-T. |
|
| |
| RFC 4259 | A Framework for Transmission of IP Datagrams over MPEG-2 Networks |
| |
| Authors: | M.-J. Montpetit, G. Fairhurst, H. Clausen, B. Collini-Nocker, H. Linder. |
| Date: | November 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4259 |
|
This document describes an architecture for the transport of IPDatagrams over ISO MPEG-2 Transport Streams (TS). The MPEG-2 TS has been widely accepted not only for providing digital TV services but also as a subnetwork technology for building IP networks. Examples of systems using MPEG-2 include the Digital Video Broadcast (DVB) andAdvanced Television Systems Committee (ATSC) Standards for DigitalTelevision.
The document identifies the need for a set of Internet standards defining the interface between the MPEG-2 Transport Stream and an IP subnetwork. It suggests a new encapsulation method for IP datagrams and proposes protocols to perform IPv6/IPv4 address resolution, to associate IP packets with the properties of the Logical Channels provided by an MPEG-2 TS. |
|
| |
| RFC 4260 | Mobile IPv6 Fast Handovers for 802.11 Networks |
| |
| Authors: | P. McCann. |
| Date: | November 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4260 |
|
This document describes how a Mobile IPv6 Fast Handover could be implemented on link layers conforming to the 802.11 suite of specifications. |
|
| |
| RFC 4263 | Media Subtype Registration for Media Type text/troff |
| |
| Authors: | B. Lilly. |
| Date: | January 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4263 |
|
A text media subtype for tagging content consisting of juxtaposed text and formatting directives as used by the troff series of programs and for conveying information about the intended processing steps necessary to produce formatted output is described. |
|
| |
| RFC 4264 | BGP Wedgies |
| |
| Authors: | T. Griffin, G. Huston. |
| Date: | November 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4264 |
|
It has commonly been assumed that the Border Gateway Protocol (BGP) is a tool for distributing reachability information in a manner that creates forwarding paths in a deterministic manner. In this memo we will describe a class of BGP configurations for which there is more than one potential outcome, and where forwarding states other than the intended state are equally stable. Also, the stable state whereBGP converges may be selected by BGP in a non-deterministic manner.These stable, but unintended, BGP states are termed here "BGPWedgies". |
|
| |
| RFC 4267 | The W3C Speech Interface Framework Media Types: application/voicexml+xml, application/ssml+xml, application/srgs, application/srgs+xml, application/ccxml+xml, and application/pls+xml |
| |
| Authors: | M. Froumentin. |
| Date: | November 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4267 |
|
This document defines the media types for the languages of the W3CSpeech Interface Framework, as designed by the Voice Browser WorkingGroup in the following specifications: the Voice Extensible MarkupLanguage (VoiceXML), the Speech Synthesis Markup Language (SSML), theSpeech Recognition Grammar Specification (SRGS), the Call Control XML(CCXML), and the Pronunciation Lexicon Specification (PLS). |
|
| |
| RFC 4269 | The SEED Encryption Algorithm |
| |
| Authors: | H.J. Lee, S.J. Lee, J.H. Yoon, D.H. Cheon, J.I. Lee. |
| Date: | December 2005 |
| Formats: | txt json html |
| Obsoletes: | RFC 4009 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4269 |
|
This document describes the SEED encryption algorithm, which has been adopted by most of the security systems in the Republic of Korea.Included are a description of the encryption and the key scheduling algorithm (Section 2), the S-boxes (Appendix A), and a set of test vectors (Appendix B).
This document obsoletes RFC 4009. |
|
| |
| RFC 4270 | Attacks on Cryptographic Hashes in Internet Protocols |
| |
| Authors: | P. Hoffman, B. Schneier. |
| Date: | November 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4270 |
|
Recent announcements of better-than-expected collision attacks in popular hash algorithms have caused some people to question whether common Internet protocols need to be changed, and if so, how. This document summarizes the use of hashes in many protocols, discusses how the collision attacks affect and do not affect the protocols, shows how to thwart known attacks on digital certificates, and discusses future directions for protocol designers. |
|
| |
| RFC 4272 | BGP Security Vulnerabilities Analysis |
| |
| Authors: | S. Murphy. |
| Date: | January 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4272 |
|
Border Gateway Protocol 4 (BGP-4), along with a host of other infrastructure protocols designed before the Internet environment became perilous, was originally designed with little consideration for protection of the information it carries. There are no mechanisms internal to BGP that protect against attacks that modify, delete, forge, or replay data, any of which has the potential to disrupt overall network routing behavior.
This document discusses some of the security issues with BGP routing data dissemination. This document does not discuss security issues with forwarding of packets. |
|
| |
| RFC 4274 | BGP-4 Protocol Analysis |
| |
| Authors: | D. Meyer, K. Patel. |
| Date: | January 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4274 |
|
The purpose of this report is to document how the requirements for publication of a routing protocol as an Internet Draft Standard have been satisfied by Border Gateway Protocol version 4 (BGP-4).
This report satisfies the requirement for "the second report", as described in Section 6.0 of RFC 1264. In order to fulfill the requirement, this report augments RFC 1774 and summarizes the key features of BGP-4, as well as analyzes the protocol with respect to scaling and performance. |
|
| |
| RFC 4275 | BGP-4 MIB Implementation Survey |
| |
| Authors: | S. Hares, D. Hares. |
| Date: | January 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4275 |
|
This document provides a survey of implementations of BGP-4 that support RFC 1657 MIB agents according to the BGP-4 v1 MIB specification. |
|
| |
| RFC 4276 | BGP-4 Implementation Report |
| |
| Authors: | S. Hares, A. Retana. |
| Date: | January 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4276 |
|
This document reports the results of the BGP-4 implementation survey.The survey had 259 questions about implementations' support of BGP-4 as specified in RFC 4271. After a brief summary of the results, each response is listed. This document contains responses from the four implementers that completed the survey (Alcatel, Cisco, Laurel, andNextHop) and brief information from three that did not (Avici, DataConnection Ltd., and Nokia).
The editors did not use exterior means to verify the accuracy of the information submitted by the respondents. The respondents are experts with the products they reported on. |
|
| |
| RFC 4277 | Experience with the BGP-4 Protocol |
| |
| Authors: | D. McPherson, K. Patel. |
| Date: | January 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4277 |
|
The purpose of this memo is to document how the requirements for publication of a routing protocol as an Internet Draft Standard have been satisfied by Border Gateway Protocol version 4 (BGP-4).
This report satisfies the requirement for "the second report", as described in Section 6.0 of RFC 1264. In order to fulfill the requirement, this report augments RFC 1773 and describes additional knowledge and understanding gained in the time between when the protocol was made a Draft Standard and when it was submitted forStandard. |
|
| |
| RFC 4278 | Standards Maturity Variance Regarding the TCP MD5 Signature Option (RFC 2385) and the BGP-4 Specification |
| |
| Authors: | S. Bellovin, A. Zinin. |
| Date: | January 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4278 |
|
The IETF Standards Process requires that all normative references for a document be at the same or higher level of standardization. RFC2026 section 9.1 allows the IESG to grant a variance to the standard practices of the IETF. This document explains why the IESG is considering doing so for the revised version of the BGP-4 specification, which refers normatively to RFC 2385, "Protection ofBGP Sessions via the TCP MD5 Signature Option". RFC 2385 will remain at the Proposed Standard level. |
|
| |
| RFC 4284 | Identity Selection Hints for the Extensible Authentication Protocol (EAP) |
| |
| Authors: | F. Adrangi, V. Lortz, F. Bari, P. Eronen. |
| Date: | January 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4284 |
|
The Extensible Authentication Protocol (EAP) is defined in RFC 3748.This document defines a mechanism that allows an access network to provide identity selection hints to an EAP peer -- the end of the link that responds to the authenticator. The purpose is to assist the EAP peer in selecting an appropriate Network Access Identifier(NAI). This is useful in situations where the peer does not receive a lower-layer indication of what network it is connecting to, or when there is no direct roaming relationship between the access network and the peer's home network. In the latter case, authentication is typically accomplished via a mediating network such as a roaming consortium or broker.
The mechanism defined in this document is limited in its scalability.It is intended for access networks that have a small to moderate number of direct roaming partners. |
|
| |
| RFC 4285 | Authentication Protocol for Mobile IPv6 |
| |
| Authors: | A. Patel, K. Leung, M. Khalil, H. Akhtar, K. Chowdhury. |
| Date: | January 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4285 |
|
IPsec is specified as the means of securing signaling messages between the Mobile Node and Home Agent for Mobile IPv6 (MIPv6).MIPv6 signaling messages that are secured include the Binding Updates and Acknowledgement messages used for managing the bindings between aMobile Node and its Home Agent. This document proposes an alternate method for securing MIPv6 signaling messages between Mobile Nodes andHome Agents. The alternate method defined here consists of aMIPv6-specific mobility message authentication option that can be added to MIPv6 signaling messages. |
|
| |
| RFC 4290 | Suggested Practices for Registration of Internationalized Domain Names (IDN) |
| |
| Authors: | J. Klensin. |
| Date: | December 2005 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4290 |
|
This document explores the issues in the registration of internationalized domain names (IDNs). The basic IDN definition allows a very large number of possible characters in domain names, and this richness may lead to serious user confusion about similar- looking names. To avoid this confusion, the IDN registration process must impose rules that disallow some otherwise-valid name combinations. This document suggests a set of mechanisms that registries might use to define and implement such rules for a broad range of languages, including adaptation of methods developed forChinese, Japanese, and Korean domain names. |
|
| |
| RFC 4294 | IPv6 Node Requirements |
| |
|
|
This document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations.Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments. |
|
| |
| RFC 4296 | The Architecture of Direct Data Placement (DDP) and Remote Direct Memory Access (RDMA) on Internet Protocols |
| |
| Authors: | S. Bailey, T. Talpey. |
| Date: | December 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4296 |
|
This document defines an abstract architecture for Direct DataPlacement (DDP) and Remote Direct Memory Access (RDMA) protocols to run on Internet Protocol-suite transports. This architecture does not necessarily reflect the proper way to implement such protocols, but is, rather, a descriptive tool for defining and understanding the protocols. DDP allows the efficient placement of data into buffers designated by Upper Layer Protocols (e.g., RDMA). RDMA provides the semantics to enable Remote Direct Memory Access between peers in a way consistent with application requirements. |
|
| |
| RFC 4297 | Remote Direct Memory Access (RDMA) over IP Problem Statement |
| |
| Authors: | A. Romanow, J. Mogul, T. Talpey, S. Bailey. |
| Date: | December 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4297 |
|
Overhead due to the movement of user data in the end-system networkI/O processing path at high speeds is significant, and has limited the use of Internet protocols in interconnection networks, and theInternet itself -- especially where high bandwidth, low latency, and/or low overhead are required by the hosted application.
This document examines this overhead, and addresses an architectural,IP-based "copy avoidance" solution for its elimination, by enablingRemote Direct Memory Access (RDMA). |
|
| |
| RFC 4313 | Requirements for Distributed Control of Automatic Speech Recognition (ASR), Speaker Identification/Speaker Verification (SI/SV), and Text-to-Speech (TTS) Resources |
| |
| Authors: | D. Oran. |
| Date: | December 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4313 |
|
This document outlines the needs and requirements for a protocol to control distributed speech processing of audio streams. By speech processing, this document specifically means automatic speech recognition (ASR), speaker recognition -- which includes both speaker identification (SI) and speaker verification (SV) -- and text-to-speech (TTS). Other IETF protocols, such as SIP and RealTime Streaming Protocol (RTSP), address rendezvous and control for generalized media streams. However, speech processing presents additional requirements that none of the extant IETF protocols address. |
|
| |
| RFC 4317 | Session Description Protocol (SDP) Offer/Answer Examples |
| |
| Authors: | A. Johnston, R. Sparks. |
| Date: | December 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4317 |
|
This document gives examples of Session Description Protocol (SDP) offer/answer exchanges. Examples include codec negotiation and selection, hold and resume, and addition and deletion of media streams. The examples show multiple media types, bidirectional, unidirectional, inactive streams, and dynamic payload types. CommonThird Party Call Control (3pcc) examples are also given. |
|
| |
| RFC 4321 | Problems Identified Associated with the Session Initiation Protocol's (SIP) Non-INVITE Transaction |
| |
| Authors: | R. Sparks. |
| Date: | January 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4321 |
|
This document describes several problems that have been identified with the Session Initiation Protocol's (SIP) non-INVITE transaction. |
|
| |
| RFC 4322 | Opportunistic Encryption using the Internet Key Exchange (IKE) |
| |
| Authors: | M. Richardson, D.H. Redelmeier. |
| Date: | December 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4322 |
|
This document describes opportunistic encryption (OE) as designed and implemented by the Linux FreeS/WAN project. OE uses the Internet KeyExchange (IKE) and IPsec protocols. The objective is to allow encryption for secure communication without any pre-arrangement specific to the pair of systems involved. DNS is used to distribute the public keys of each system involved. This is resistant to passive attacks. The use of DNS Security (DNSSEC) secures this system against active attackers as well.
As a result, the administrative overhead is reduced from the square of the number of systems to a linear dependence, and it becomes possible to make secure communication the default even when the partner is not known in advance. |
|
| |
| RFC 4329 | Scripting Media Types |
| |
|
|
This document describes the registration of media types for theECMAScript and JavaScript programming languages and conformance requirements for implementations of these types. |
|
| |
| RFC 4330 | Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI |
| |
|
|
This memorandum describes the Simple Network Time Protocol Version 4(SNTPv4), which is a subset of the Network Time Protocol (NTP) used to synchronize computer clocks in the Internet. SNTPv4 can be used when the ultimate performance of a full NTP implementation based onRFC 1305 is neither needed nor justified. When operating with current and previous NTP and SNTP versions, SNTPv4 requires no changes to the specifications or known implementations, but rather clarifies certain design features that allow operation in a simple, stateless remote-procedure call (RPC) mode with accuracy and reliability expectations similar to the UDP/TIME protocol described in RFC 868.
This memorandum obsoletes RFC 1769, which describes SNTP Version 3(SNTPv3), and RFC 2030, which describes SNTPv4. Its purpose is to correct certain inconsistencies in the previous documents and to clarify header formats and protocol operations for NTPv3 (IPv4) andSNTPv4 (IPv4, IPv6, and OSI), which are also used for SNTP. A further purpose is to provide guidance for home and business client implementations for routers and other consumer devices to protect the server population from abuse. A working knowledge of the NTPv3 specification, RFC 1305, is not required for an implementation ofSNTP. |
|
| |
| RFC 4332 | Cisco's Mobile IPv4 Host Configuration Extensions |
| |
| Authors: | K. Leung, A. Patel, G. Tsirtsis, E. Klovning. |
| Date: | December 2005 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4332 |
|
An IP device requires basic host configuration to be able to communicate. For example, it will typically require an IP address and the address of a DNS server. This information is configured statically or obtained dynamically using Dynamic Host ConfigurationProtocol (DHCP) or Point-to-Point Protocol/IP Control Protocol(PPP/IPCP). However, both DHCP and PPP/IPCP provide host configuration based on the access network. In Mobile IPv4, the registration process boots up a Mobile Node at an access network, also known as a foreign network. The information to configure the host needs to be based on the home network. This document describes the Cisco vendor-specific extensions to Mobile IPv4 to provide the base host configuration in Registration Request and Reply messages. |
|
| |
| RFC 4336 | Problem Statement for the Datagram Congestion Control Protocol (DCCP) |
| |
| Authors: | S. Floyd, M. Handley, E. Kohler. |
| Date: | March 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4336 |
|
This document describes for the historical record the motivation behind the Datagram Congestion Control Protocol (DCCP), an unreliable transport protocol incorporating end-to-end congestion control. DCCP implements a congestion-controlled, unreliable flow of datagrams for use by applications such as streaming media or on-line games. |
|
| |
| RFC 4339 | IPv6 Host Configuration of DNS Server Information Approaches |
| |
| Authors: | J. Jeong, Ed.. |
| Date: | February 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4339 |
|
This document describes three approaches for IPv6 recursive DNS server address configuration. It details the operational attributes of three solutions: RA option, DHCPv6 option, and well-known anycast addresses for recursive DNS servers. Additionally, it suggests the deployment scenarios in four kinds of networks (ISP, enterprise,3GPP, and unmanaged networks) considering multi-solution resolution. |
|
| |
| RFC 4350 | A Uniform Resource Name (URN) Formal Namespace for the New Zealand Government |
| |
| Authors: | F. Hendrikx, C. Wallis. |
| Date: | February 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4350 |
|
This document describes a Uniform Resource Name (URN) NamespaceIdentification (NID)convention as prescribed by the World Wide WebConsortium (W3C) for identifying, naming, assigning, and managing persistent resources and XML artefacts for the New ZealandGovernment. |
|
| |
| RFC 4353 | A Framework for Conferencing with the Session Initiation Protocol (SIP) |
| |
| Authors: | J. Rosenberg. |
| Date: | February 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4353 |
|
The Session Initiation Protocol (SIP) supports the initiation, modification, and termination of media sessions between user agents.These sessions are managed by SIP dialogs, which represent a SIP relationship between a pair of user agents. Because dialogs are between pairs of user agents, SIP's usage for two-party communications (such as a phone call), is obvious. Communications sessions with multiple participants, generally known as conferencing, are more complicated. This document defines a framework for how such conferencing can occur. This framework describes the overall architecture, terminology, and protocol components needed for multi- party conferencing. |
|
| |
| RFC 4354 | A Session Initiation Protocol (SIP) Event Package and Data Format for Various Settings in Support for the Push-to-Talk over Cellular (PoC) Service |
| |
| Authors: | M. Garcia-Martin. |
| Date: | January 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4354 |
|
The Open Mobile Alliance (OMA) is defining the Push-to-talk overCellular (PoC) service where SIP is the protocol used to establish half-duplex media sessions across different participants, to send instant messages, etc. This document defines a SIP event package to support publication, subscription, and notification of additional capabilities required by the PoC service. This SIP event package is applicable to the PoC service and may not be applicable to the general Internet. |
|
| |
| RFC 4357 | Additional Cryptographic Algorithms for Use with GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms |
| |
| Authors: | V. Popov, I. Kurepkin, S. Leontiev. |
| Date: | January 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4357 |
|
This document describes the cryptographic algorithms and parameters supplementary to the original GOST specifications, GOST 28147-89,GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94, for use inInternet applications. |
|
| |
| RFC 4358 | A Uniform Resource Name (URN) Namespace for the Open Mobile Alliance (OMA) |
| |
| Authors: | D. Smith. |
| Date: | January 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4358 |
|
This document describes the Namespace Identifier (NID) for UniformResource Namespace (URN) resources published by the Open MobileAlliance (OMA). OMA defines and manages resources that utilize thisURN name model. Management activities for these and other resource types are provided by the Open Mobile Naming Authority (OMNA). |
|
| |
| RFC 4365 | Applicability Statement for BGP/MPLS IP Virtual Private Networks (VPNs) |
| |
| Authors: | E. Rosen. |
| Date: | February 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4365 |
|
This document provides an Applicability Statement for the VirtualPrivate Network (VPN) solution described in RFC 4364 and other documents listed in the References section. |
|
| |
| RFC 4367 | What's in a Name: False Assumptions about DNS Names |
| |
| Authors: | J. Rosenberg, Ed., IAB. |
| Date: | February 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4367 |
|
The Domain Name System (DNS) provides an essential service on theInternet, mapping structured names to a variety of data, usually IP addresses. These names appear in email addresses, Uniform ResourceIdentifiers (URIs), and other application-layer identifiers that are often rendered to human users. Because of this, there has been a strong demand to acquire names that have significance to people, through equivalence to registered trademarks, company names, types of services, and so on. There is a danger in this trend; the humans and automata that consume and use such names will associate specific semantics with some names and thereby make assumptions about the services that are, or should be, provided by the hosts associated with the names. Those assumptions can often be false, resulting in a variety of failure conditions. This document discusses this problem in more detail and makes recommendations on how it can be avoided. |
|
| |
| RFC 4373 | Lightweight Directory Access Protocol (LDAP) Bulk Update/Replication Protocol (LBURP) |
| |
| Authors: | R. Harrison, J. Sermersheim, Y. Dong. |
| Date: | January 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4373 |
|
The Lightweight Directory Access Protocol (LDAP) BulkUpdate/Replication Protocol (LBURP) allows an LDAP client to perform a bulk update to an LDAP server. The protocol frames a sequenced set of update operations within a pair of LDAP extended operations to notify the server that the update operations in the framed set are related in such a way that the ordering of all operations can be preserved during processing even when they are sent asynchronously by the client. Update operations can be grouped within a single protocol message to maximize the efficiency of client-server communication.
The protocol is suitable for efficiently making a substantial set of updates to the entries in an LDAP server. |
|
| |
| RFC 4374 | The application/xv+xml Media Type |
| |
| Authors: | G. McCobb. |
| Date: | January 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4374 |
|
This document describes the registration of the MIME sub-type application/xv+xml. This sub-type is intended for use as a media descriptor for XHTML+Voice multimodal language documents. |
|
| |
| RFC 4375 | Emergency Telecommunications Services (ETS) Requirements for a Single Administrative Domain |
| |
| Authors: | K. Carlberg. |
| Date: | January 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4375 |
|
This document presents a list of requirements in support of EmergencyTelecommunications Service (ETS) within a single administrative domain. This document focuses on a specific set of administrative constraints and scope. Solutions to these requirements are not presented in this document. |
|
| |
| RFC 4376 | Requirements for Floor Control Protocols |
| |
| Authors: | P. Koskelainen, J. Ott, H. Schulzrinne, X. Wu. |
| Date: | February 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4376 |
|
Floor control is a means to manage joint or exclusive access to shared resources in a (multiparty) conferencing environment. Thereby, floor control complements other functions -- such as conference and media session setup, conference policy manipulation, and media control -- that are realized by other protocols. This document defines the requirements for a floor control protocol for multiparty conferences in the context of an existing framework. |
|
| |
| RFC 4377 | Operations and Management (OAM) Requirements for Multi-Protocol Label Switched (MPLS) Networks |
| |
| Authors: | T. Nadeau, M. Morrow, G. Swallow, D. Allan, S. Matsushima. |
| Date: | February 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4377 |
|
This document specifies Operations and Management (OAM) requirements for Multi-Protocol Label Switching (MPLS), as well as for applications of MPLS, such as pseudo-wire voice and virtual private network services. These requirements have been gathered from network operators who have extensive experience deploying MPLS networks. |
|
| |
| RFC 4378 | A Framework for Multi-Protocol Label Switching (MPLS) Operations and Management (OAM) |
| |
| Authors: | D. Allan, Ed., T. Nadeau, Ed.. |
| Date: | February 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4378 |
|
This document is a framework for how data plane protocols can be applied to operations and maintenance procedures for Multi-ProtocolLabel Switching (MPLS). The document is structured to outline howOperations and Management (OAM) functionality can be used to assist in fault, configuration, accounting, performance, and security management, commonly known by the acronym FCAPS. |
|
| |
| RFC 4381 | Analysis of the Security of BGP/MPLS IP Virtual Private Networks (VPNs) |
| |
| Authors: | M. Behringer. |
| Date: | February 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4381 |
|
This document analyses the security of the BGP/MPLS IP virtual private network (VPN) architecture that is described in RFC 4364, for the benefit of service providers and VPN users.
The analysis shows that BGP/MPLS IP VPN networks can be as secure as traditional layer-2 VPN services using Asynchronous Transfer Mode(ATM) or Frame Relay. |
|
| |
| RFC 4392 | IP over InfiniBand (IPoIB) Architecture |
| |
| Authors: | V. Kashyap. |
| Date: | April 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4392 |
|
InfiniBand is a high-speed, channel-based interconnect between systems and devices.
This document presents an overview of the InfiniBand architecture.It further describes the requirements and guidelines for the transmission of IP over InfiniBand. Discussions in this document are applicable to both IPv4 and IPv6 unless explicitly specified. The encapsulation of IP over InfiniBand and the mechanism for IP address resolution on IB fabrics are covered in other documents. |
|
| |
| RFC 4394 | A Transport Network View of the Link Management Protocol (LMP) |
| |
| Authors: | D. Fedyk, O. Aboul-Magd, D. Brungard, J. Lang, D. Papadimitriou. |
| Date: | February 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4394 |
|
The Link Management Protocol (LMP) has been developed as part of theGeneralized MPLS (GMPLS) protocol suite to manage Traffic Engineering(TE) resources and links. The GMPLS control plane (routing and signaling) uses TE links for establishing Label Switched Paths(LSPs). This memo describes the relationship of the LMP procedures to 'discovery' as defined in the International TelecommunicationUnion (ITU-T), and ongoing ITU-T work. This document provides an overview of LMP in the context of the ITU-T Automatically SwitchedOptical Networks (ASON) and transport network terminology and relates it to the ITU-T discovery work to promote a common understanding for progressing the work of IETF and ITU-T. |
|
| |
| RFC 4397 | A Lexicography for the Interpretation of Generalized Multiprotocol Label Switching (GMPLS) Terminology within the Context of the ITU-T's Automatically Switched Optical Network (ASON) Architecture |
| |
| Authors: | I. Bryskin, A. Farrel. |
| Date: | February 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4397 |
|
Generalized Multiprotocol Label Switching (GMPLS) has been developed by the IETF to facilitate the establishment of Label Switched Paths(LSPs) in a variety of data plane technologies and across several architectural models. The ITU-T has specified an architecture for the control of Automatically Switched Optical Networks (ASON).
This document provides a lexicography for the interpretation of GMPLS terminology within the context of the ASON architecture.
It is important to note that GMPLS is applicable in a wider set of contexts than just ASON. The definitions presented in this document do not provide exclusive or complete interpretations of GMPLS concepts. This document simply allows the GMPLS terms to be applied within the ASON context. |
|
| |
| RFC 4403 | Lightweight Directory Access Protocol (LDAP) Schema for Universal Description, Discovery, and Integration version 3 (UDDIv3) |
| |
| Authors: | B. Bergeson, K. Boogert, V. Nanjundaswamy. |
| Date: | February 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4403 |
|
This document defines the Lightweight Directory Access Protocol(LDAPv3) schema for representing Universal Description, Discovery, and Integration (UDDI) data types in an LDAP directory. It defines the LDAP object class and attribute definitions and containment rules to model UDDI entities, defined in the UDDI version 3 information model, in an LDAPv3-compliant directory. |
|
| |
| RFC 4413 | TCP/IP Field Behavior |
| |
| Authors: | M. West, S. McCann. |
| Date: | March 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4413 |
|
This memo describes TCP/IP field behavior in the context of header compression. Header compression is possible because most header fields do not vary randomly from packet to packet. Many of the fields exhibit static behavior or change in a more or less predictable way. When a header compression scheme is designed, it is of fundamental importance to understand the behavior of the fields in detail. An example of this analysis can be seen in RFC 3095. This memo performs a similar role for the compression of TCP/IP headers. |
|
| |
| RFC 4416 | Goals for Internet Messaging to Support Diverse Service Environments |
| |
| Authors: | J. Wong, Ed.. |
| Date: | February 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4416 |
|
This document is a history capturing the background, motivation and thinking during the LEMONADE definition and design process.
The LEMONADE Working Group -- Internet email to support diverse service environments -- is chartered to provide enhancements toInternet mail to facilitate its use by more diverse clients. In particular, by clients on hosts not only operating in environments with high latency/bandwidth-limited unreliable links but also constrained to limited resources. The enhanced mail must be backwards compatible with existing Internet mail.
The primary motivation for this effort is -- by making Internet mail protocols richer and more adaptable to varied media and environments-- to allow mobile handheld devices tetherless access to Internet mail using only IETF mail protocols.
The requirements for these devices drive a discussion of the possible protocol enhancements needed to support multimedia messaging on limited-capability hosts in diverse service environments. A list of general principles to guide the design of the enhanced messaging protocols is documented. Finally, additional issues of providing seamless service between enhanced Internet mail and the existing separate mobile messaging infrastructure are briefly listed. |
|
| |
| RFC 4417 | Report of the 2004 IAB Messaging Workshop |
| |
| Authors: | P. Resnick, Ed., P. Saint-Andre, Ed.. |
| Date: | February 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4417 |
|
This document reports the outcome of a workshop held by the InternetArchitecture Board (IAB) on the future of Internet messaging. The workshop was held on 6 and 7 October 2004 in Burlingame, CA, USA.The goal of the workshop was to examine the current state of different messaging technologies on the Internet (including, but not limited to, electronic mail, instant messaging, and voice messaging), to look at their commonalities and differences, and to find engineering, research, and architectural topics on which future work could be done. This report summarizes the discussions and conclusions of the workshop and of the IAB. |
|
| |
| RFC 4418 | UMAC: Message Authentication Code using Universal Hashing |
| |
| Authors: | T. Krovetz, Ed.. |
| Date: | March 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4418 |
|
This specification describes how to generate an authentication tag using the UMAC message authentication algorithm. UMAC is designed to be very fast to compute in software on contemporary uniprocessors.Measured speeds are as low as one cycle per byte. UMAC relies on addition of 32-bit and 64-bit numbers and multiplication of 32-bit numbers, operations well-supported by contemporary machines.
To generate the authentication tag on a given message, a "universal" hash function is applied to the message and key to produce a short, fixed-length hash value, and this hash value is then xor'ed with a key-derived pseudorandom pad. UMAC enjoys a rigorous security analysis, and its only internal "cryptographic" component is a block cipher used to generate the pseudorandom pads and internal key material. |
|
| |
| RFC 4423 | Host Identity Protocol (HIP) Architecture |
| |
| Authors: | R. Moskowitz, P. Nikander. |
| Date: | May 2006 |
| Formats: | txt json html |
| Obsoleted by: | RFC 9063 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4423 |
|
This memo describes a snapshot of the reasoning behind a proposed new namespace, the Host Identity namespace, and a new protocol layer, theHost Identity Protocol (HIP), between the internetworking and transport layers. Herein are presented the basics of the current namespaces, their strengths and weaknesses, and how a new namespace will add completeness to them. The roles of this new namespace in the protocols are defined. The memo describes the thinking of the authors as of Fall 2003. The architecture may have evolved since.This document represents one stable point in that evolution of understanding. |
|
| |
| RFC 4427 | Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS) |
| |
| Authors: | E. Mannie, Ed., D. Papadimitriou, Ed.. |
| Date: | March 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4427 |
|
This document defines a common terminology for Generalized Multi-Protocol Label Switching (GMPLS)-based recovery mechanisms (i.e., protection and restoration). The terminology is independent of the underlying transport technologies covered by GMPLS. |
|
| |
| RFC 4428 | Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery Mechanisms (including Protection and Restoration) |
| |
| Authors: | D. Papadimitriou, Ed., E. Mannie, Ed.. |
| Date: | March 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4428 |
|
This document provides an analysis grid to evaluate, compare, and contrast the Generalized Multi-Protocol Label Switching (GMPLS) protocol suite capabilities with the recovery mechanisms currently proposed at the IETF CCAMP Working Group. A detailed analysis of each of the recovery phases is provided using the terminology defined in RFC 4427. This document focuses on transport plane survivability and recovery issues and not on control plane resilience and related aspects. |
|
| |
| RFC 4435 | A Framework for the Usage of Internet Media Guides (IMGs) |
| |
| Authors: | Y. Nomura, R. Walsh, J-P. Luoma, H. Asaeda, H. Schulzrinne. |
| Date: | April 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4435 |
|
This document defines a framework for the delivery of Internet MediaGuides (IMGs). An IMG is a structured collection of multimedia session descriptions expressed using the Session Description Protocol(SDP), SDPng, or some similar session description format. This document describes a generalized model for IMG delivery mechanisms, the use of existing protocols, and the need for additional work to create an IMG delivery infrastructure. |
|
| |
| RFC 4440 | IAB Thoughts on the Role of the Internet Research Task Force (IRTF) |
| |
| Authors: | S. Floyd, Ed., V. Paxson, Ed., A. Falk, Ed., IAB. |
| Date: | March 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4440 |
|
This document is an Internet Architecture Board (IAB) report on the role of the Internet Research Task Force (IRTF), both on its own and in relationship to the IETF. This document evolved from a discussion within the IAB as part of a process of appointing a new chair of theIRTF. |
|
| |
| RFC 4441 | The IEEE 802/IETF Relationship |
| |
|
|
Since the late 1980s, IEEE 802 and IETF have cooperated in the development of Simple Network Management Protocol (SNMP) MIBs andAuthentication, Authorization, and Accounting (AAA) applications.This document describes the policies and procedures that have developed in order to coordinate between the two organizations, as well as some of the relationship history. |
|
| |
| RFC 4445 | A Proposed Media Delivery Index (MDI) |
| |
| Authors: | J. Welch, J. Clark. |
| Date: | April 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4445 |
|
This memo defines a Media Delivery Index (MDI) measurement that can be used as a diagnostic tool or a quality indicator for monitoring a network intended to deliver applications such as streaming media,MPEG video, Voice over IP, or other information sensitive to arrival time and packet loss. It provides an indication of traffic jitter, a measure of deviation from nominal flow rates, and a data loss at-a-glance measure for a particular flow. For instance, the MDI may be used as a reference in characterizing and comparing networks carrying UDP streaming media.
The MDI measurement defined in this memo is intended for Information only. |
|
| |
| RFC 4450 | Getting Rid of the Cruft: Report from an Experiment in Identifying and Reclassifying Obsolete Standards Documents |
| |
| Authors: | E. Lear, H. Alvestrand. |
| Date: | March 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4450 |
|
This memo documents an experiment to review and classify ProposedStandards as not reflecting documented practice within the world today. The results identify a set of documents that were marked asProposed Standards that are now reclassified as Historic. |
|
| |
| RFC 4451 | BGP MULTI_EXIT_DISC (MED) Considerations |
| |
| Authors: | D. McPherson, V. Gill. |
| Date: | March 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4451 |
|
The BGP MULTI_EXIT_DISC (MED) attribute provides a mechanism for BGP speakers to convey to an adjacent AS the optimal entry point into the local AS. While BGP MEDs function correctly in many scenarios, a number of issues may arise when utilizing MEDs in dynamic or complex topologies.
This document discusses implementation and deployment considerations regarding BGP MEDs and provides information with which implementers and network operators should be familiar. |
|
| |
| RFC 4452 | The "info" URI Scheme for Information Assets with Identifiers in Public Namespaces |
| |
| Authors: | H. Van de Sompel, T. Hammond, E. Neylon, S. Weibel. |
| Date: | April 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4452 |
|
This document defines the "info" Uniform Resource Identifier (URI) scheme for information assets with identifiers in public namespaces.Namespaces participating in the "info" URI scheme are regulated by an"info" Registry mechanism. |
|
| |
| RFC 4453 | Requirements for Consent-Based Communications in the Session Initiation Protocol (SIP) |
| |
| Authors: | J. Rosenberg, G. Camarillo, Ed., D. Willis. |
| Date: | April 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4453 |
|
The Session Initiation Protocol (SIP) supports communications across many media types, including real-time audio, video, text, instant messaging, and presence. In its current form, it allows session invitations, instant messages, and other requests to be delivered from one party to another without requiring explicit consent of the recipient. Without such consent, it is possible for SIP to be used for malicious purposes, including spam and denial-of-service attacks.This document identifies a set of requirements for extensions to SIP that add consent-based communications. |
|
| |
| RFC 4457 | The Session Initiation Protocol (SIP) P-User-Database Private-Header (P-Header) |
| |
| Authors: | G. Camarillo, G. Blanco. |
| Date: | April 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4457 |
|
This document specifies the Session Initiation Protocol (SIP)P-User-Database Private-Header (P-header). This header field is used in the 3rd-Generation Partnership Project (3GPP) IMS (IP MultimediaSubsystem) to provide SIP registrars and SIP proxy servers with the address of the database that contains the user profile of the user that generated a particular request. |
|
| |
| RFC 4458 | Session Initiation Protocol (SIP) URIs for Applications such as Voicemail and Interactive Voice Response (IVR) |
| |
| Authors: | C. Jennings, F. Audet, J. Elwell. |
| Date: | April 2006 |
| Formats: | txt json html |
| Updated by: | RFC 8119 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4458 |
|
The Session Initiation Protocol (SIP) is often used to initiate connections to applications such as voicemail or interactive voice recognition systems. This specification describes a convention for forming SIP service URIs that request particular services based on redirecting targets from such applications. |
|
| |
| RFC 4459 | MTU and Fragmentation Issues with In-the-Network Tunneling |
| |
| Authors: | P. Savola. |
| Date: | April 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4459 |
|
Tunneling techniques such as IP-in-IP when deployed in the middle of the network, typically between routers, have certain issues regarding how large packets can be handled: whether such packets would be fragmented and reassembled (and how), whether Path MTU Discovery would be used, or how this scenario could be operationally avoided.This memo justifies why this is a common, non-trivial problem, and goes on to describe the different solutions and their characteristics at some length. |
|
| |
| RFC 4460 | Stream Control Transmission Protocol (SCTP) Specification Errata and Issues |
| |
| Authors: | R. Stewart, I. Arias-Rodriguez, K. Poon, A. Caro, M. Tuexen. |
| Date: | April 2006 |
| Formats: | txt json html |
| Obsoleted by: | RFC 9260 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4460 |
|
This document is a compilation of issues found during six interoperability events and 5 years of experience with implementing, testing, and using Stream Control Transmission Protocol (SCTP) along with the suggested fixes. This document provides deltas to RFC 2960 and is organized in a time-based way. The issues are listed in the order they were brought up. Because some text is changed several times, the last delta in the text is the one that should be applied.In addition to the delta, a description of the problem and the details of the solution are also provided. |
|
| |
| RFC 4461 | Signaling Requirements for Point-to-Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs) |
| |
| Authors: | S. Yasukawa, Ed.. |
| Date: | April 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4461 |
|
This document presents a set of requirements for the establishment and maintenance of Point-to-Multipoint (P2MP) Traffic-Engineered (TE)Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs).
There is no intent to specify solution-specific details or application-specific requirements in this document.
The requirements presented in this document not only apply to packet-switched networks under the control of MPLS protocols, but also encompass the requirements of Layer Two Switching (L2SC), TimeDivision Multiplexing (TDM), lambda, and port switching networks managed by Generalized MPLS (GMPLS) protocols. Protocol solutions developed to meet the requirements set out in this document must attempt to be equally applicable to MPLS and GMPLS. |
|
| |
| RFC 4463 | A Media Resource Control Protocol (MRCP) Developed by Cisco, Nuance, and Speechworks |
| |
| Authors: | S. Shanmugham, P. Monaco, B. Eberman. |
| Date: | April 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4463 |
|
This document describes a Media Resource Control Protocol (MRCP) that was developed jointly by Cisco Systems, Inc., Nuance Communications, and Speechworks, Inc. It is published as an RFC as input for furtherIETF development in this area.
MRCP controls media service resources like speech synthesizers, recognizers, signal generators, signal detectors, fax servers, etc., over a network. This protocol is designed to work with streaming protocols like RTSP (Real Time Streaming Protocol) or SIP (SessionInitiation Protocol), which help establish control connections to external media streaming devices, and media delivery mechanisms likeRTP (Real Time Protocol). |
|
| |
| RFC 4464 | Signaling Compression (SigComp) Users' Guide |
| |
| Authors: | A. Surtees, M. West. |
| Date: | May 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4464 |
|
This document provides an informational guide for users of theSignaling Compression (SigComp) protocol. The aim of the document is to assist users when making SigComp implementation decisions, for example, the choice of compression algorithm and the level of robustness against lost or misordered packets. |
|
| |
| RFC 4465 | Signaling Compression (SigComp) Torture Tests |
| |
| Authors: | A. Surtees, M. West. |
| Date: | June 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4465 |
|
This document provides a set of "torture tests" for implementers of the Signaling Compression (SigComp) protocol. The torture tests check each of the SigComp Universal Decompressor Virtual Machine instructions in turn, focusing in particular on the boundary and error cases that are not generally encountered when running well-behaved compression algorithms. Tests are also provided for other SigComp entities such as the dispatcher and the state handler. |
|
| |
| RFC 4472 | Operational Considerations and Issues with IPv6 DNS |
| |
| Authors: | A. Durand, J. Ihren, P. Savola. |
| Date: | April 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4472 |
|
This memo presents operational considerations and issues with IPv6Domain Name System (DNS), including a summary of special IPv6 addresses, documentation of known DNS implementation misbehavior, recommendations and considerations on how to perform DNS naming for service provisioning and for DNS resolver IPv6 support, considerations for DNS updates for both the forward and reverse trees, and miscellaneous issues. This memo is aimed to include a summary of information about IPv6 DNS considerations for those who have experience with IPv4 DNS. |
|
| |
| RFC 4473 | Requirements for Internet Media Guides (IMGs) |
| |
| Authors: | Y. Nomura, R. Walsh, J-P. Luoma, J. Ott, H. Schulzrinne. |
| Date: | May 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4473 |
|
This memo specifies requirements for a framework and protocols for accessing and updating Internet Media Guide (IMG) information for media-on-demand and multicast applications. These requirements are designed to guide choice and development of IMG protocols for efficient and scalable delivery. |
|
| |
| RFC 4475 | Session Initiation Protocol (SIP) Torture Test Messages |
| |
| Authors: | R. Sparks, Ed., A. Hawrylyshen, A. Johnston, J. Rosenberg, H. Schulzrinne. |
| Date: | May 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4475 |
|
This informational document gives examples of Session InitiationProtocol (SIP) test messages designed to exercise and "torture" a SIP implementation. |
|
| |
| RFC 4477 | Dynamic Host Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack Issues |
| |
| Authors: | T. Chown, S. Venaas, C. Strauf. |
| Date: | May 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4477 |
|
A node may have support for communications using IPv4 and/or IPv6 protocols. Such a node may wish to obtain IPv4 and/or IPv6 configuration settings via the Dynamic Host Configuration Protocol(DHCP). The original version of DHCP (RFC 2131) designed for IPv4 has now been complemented by a new DHCPv6 (RFC 3315) for IPv6. This document describes issues identified with dual IP version DHCP interactions, the most important aspect of which is how to handle potential problems in clients processing configuration information received from both DHCPv4 and DHCPv6 servers. The document makes a recommendation on the general strategy on how best to handle such issues and identifies future work to be undertaken. |
|
| |
| RFC 4484 | Trait-Based Authorization Requirements for the Session Initiation Protocol (SIP) |
| |
| Authors: | J. Peterson, J. Polk, D. Sicker, H. Tschofenig. |
| Date: | August 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4484 |
|
This document lays out a set of requirements related to trait-based authorization for the Session Initiation Protocol (SIP). While some authentication mechanisms are described in the base SIP specification, trait-based authorization provides information used to make policy decisions based on the attributes of a participant in a session. This approach provides a richer framework for authorization, as well as allows greater privacy for users of an identity system. |
|
| |
| RFC 4485 | Guidelines for Authors of Extensions to the Session Initiation Protocol (SIP) |
| |
| Authors: | J. Rosenberg, H. Schulzrinne. |
| Date: | May 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4485 |
|
The Session Initiation Protocol (SIP) is a flexible yet simple tool for establishing interactive communications sessions across theInternet. Part of this flexibility is the ease with which it can be extended. In order to facilitate effective and interoperable extensions to SIP, some guidelines need to be followed when developing SIP extensions. This document outlines a set of such guidelines for authors of SIP extensions. |
|
| |
| RFC 4487 | Mobile IPv6 and Firewalls: Problem Statement |
| |
| Authors: | F. Le, S. Faccin, B. Patil, H. Tschofenig. |
| Date: | May 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4487 |
|
This document captures the issues that may arise in the deployment ofIPv6 networks when they support Mobile IPv6 and firewalls. The issues are not only applicable to firewalls protecting enterprise networks, but are also applicable in 3G mobile networks such asGeneral Packet Radio Service / Universal Mobile TelecommunicationsSystem (GPRS/UMTS) and CDMA2000 networks.
The goal of this document is to highlight the issues with firewalls and Mobile IPv6 and act as an enabler for further discussion. Issues identified here can be solved by developing appropriate solutions. |
|
| |
| RFC 4492 | Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) |
| |
|
|
This document describes new key exchange algorithms based on EllipticCurve Cryptography (ECC) for the Transport Layer Security (TLS) protocol. In particular, it specifies the use of Elliptic CurveDiffie-Hellman (ECDH) key agreement in a TLS handshake and the use ofElliptic Curve Digital Signature Algorithm (ECDSA) as a new authentication mechanism. |
|
| |
| RFC 4493 | The AES-CMAC Algorithm |
| |
| Authors: | JH. Song, R. Poovendran, J. Lee, T. Iwata. |
| Date: | June 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4493 |
|
The National Institute of Standards and Technology (NIST) has recently specified the Cipher-based Message Authentication Code(CMAC), which is equivalent to the One-Key CBC MAC1 (OMAC1) submitted by Iwata and Kurosawa. This memo specifies an authentication algorithm based on CMAC with the 128-bit Advanced Encryption Standard(AES). This new authentication algorithm is named AES-CMAC. The purpose of this document is to make the AES-CMAC algorithm conveniently available to the Internet Community. |
|
| |
| RFC 4496 | Open Pluggable Edge Services (OPES) SMTP Use Cases |
| |
| Authors: | M. Stecher, A. Barbir. |
| Date: | May 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4496 |
|
The Open Pluggable Edge Services (OPES) framework is application agnostic. Application-specific adaptations extend that framework.This document describes OPES SMTP use cases and deployment scenarios in preparation for SMTP adaptation with OPES. |
|
| |
| RFC 4503 | A Description of the Rabbit Stream Cipher Algorithm |
| |
| Authors: | M. Boesgaard, M. Vesterager, E. Zenner. |
| Date: | May 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4503 |
|
This document describes the encryption algorithm Rabbit. It is a stream cipher algorithm with a 128-bit key and 64-bit initialization vector (IV). The method was published in 2003 and has been subject to public security and performance revision. Its high performance makes it particularly suited for the use with Internet protocols where large amounts of data have to be processed. |
|
| |
| RFC 4504 | SIP Telephony Device Requirements and Configuration |
| |
| Authors: | H. Sinnreich, Ed., S. Lass, C. Stredicke. |
| Date: | May 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4504 |
|
This document describes the requirements for SIP telephony devices, based on the deployment experience of large numbers of SIP phones andPC clients using different implementations in various networks. The objectives of the requirements are a well-defined set of interoperability and multi-vendor-supported core features, so as to enable similar ease of purchase, installation, and operation as found for PCs, PDAs, analog feature phones or mobile phones.
We present a glossary of the most common settings and some of the more widely used values for some settings. |
|
| |
| RFC 4525 | Lightweight Directory Access Protocol (LDAP) Modify-Increment Extension |
| |
| Authors: | K. Zeilenga. |
| Date: | June 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4525 |
|
This document describes an extension to the Lightweight DirectoryAccess Protocol (LDAP) Modify operation to support an increment capability. This extension is useful in provisioning applications, especially when combined with the assertion control and/or the pre- read or post-read control extension. |
|
| |
| RFC 4529 | Requesting Attributes by Object Class in the Lightweight Directory Access Protocol |
| |
| Authors: | K. Zeilenga. |
| Date: | June 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4529 |
|
The Lightweight Directory Access Protocol (LDAP) search operation provides mechanisms for clients to request all user application attributes, all operational attributes, and/or attributes selected by their description. This document extends LDAP to support a mechanism that LDAP clients may use to request the return of all attributes of an object class. |
|
| |
| RFC 4536 | The application/smil and application/smil+xml Media Types |
| |
| Authors: | P. Hoschka. |
| Date: | July 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4536 |
|
This document specifies the media type for versions 1.0, 2.0, and 2.1 of the Synchronized Multimedia Integration Language (SMIL 1.0, SMIL2.0, SMIL 2.1). SMIL allows integration of a set of independent multimedia objects into a synchronized multimedia presentation. |
|
| |
| RFC 4539 | Media Type Registration for the Society of Motion Picture and Television Engineers (SMPTE) Material Exchange Format (MXF) |
| |
| Authors: | T. Edwards. |
| Date: | May 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4539 |
|
This document serves to register a media type for the Society ofMotion Picture and Television Engineers (SMPTE) Material ExchangeFormat (MXF). MXF, defined by SMPTE 377M, is a standard wrapper format developed for the interchange of audiovisual material, including both audiovisual essence and rich metadata. |
|
| |
| RFC 4541 | Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches |
| |
| Authors: | M. Christensen, K. Kimball, F. Solensky. |
| Date: | May 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4541 |
|
This memo describes the recommendations for Internet Group ManagementProtocol (IGMP) and Multicast Listener Discovery (MLD) snooping switches. These are based on best current practices for IGMPv2, with further considerations for IGMPv3- and MLDv2-snooping. Additional areas of relevance, such as link layer topology changes andEthernet-specific encapsulation issues, are also considered. |
|
| |
| RFC 4542 | Implementing an Emergency Telecommunications Service (ETS) for Real-Time Services in the Internet Protocol Suite |
| |
|
|
RFCs 3689 and 3690 detail requirements for an EmergencyTelecommunications Service (ETS), of which an Internet EmergencyPreparedness Service (IEPS) would be a part. Some of these types of services require call preemption; others require call queuing or other mechanisms. IEPS requires a Call Admission Control (CAC) procedure and a Per Hop Behavior (PHB) for the data that meet the needs of this architecture. Such a CAC procedure and PHB is appropriate to any service that might use H.323 or SIP to set up real-time sessions. The key requirement is to guarantee an elevated probability of call completion to an authorized user in time of crisis.
This document primarily discusses supporting ETS in the context of the US Government and NATO, because it focuses on the Multi-LevelPrecedence and Preemption (MLPP) and Government EmergencyTelecommunication Service (GETS) standards. The architectures described here are applicable beyond these organizations. |
|
| |
| RFC 4549 | Synchronization Operations for Disconnected IMAP4 Clients |
| |
| Authors: | A. Melnikov, Ed.. |
| Date: | June 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4549 |
|
This document attempts to address some of the issues involved in building a disconnected IMAP4 client. In particular, it deals with the issues of what might be called the "driver" portion of the synchronization tool: the portion of the code responsible for issuing the correct set of IMAP4 commands to synchronize the disconnected client in the way that is most likely to make the human who uses the disconnected client happy.
This note describes different strategies that can be used by disconnected clients and shows how to use IMAP protocol in order to minimize the time of the synchronization process.
This note also lists IMAP extensions that a server should implement in order to provide better synchronization facilities to disconnected clients. |
|
| |
| RFC 4554 | Use of VLANs for IPv4-IPv6 Coexistence in Enterprise Networks |
| |
| Authors: | T. Chown. |
| Date: | June 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4554 |
|
Ethernet VLANs are quite commonly used in enterprise networks for the purposes of traffic segregation. This document describes how suchVLANs can be readily used to deploy IPv6 networking in an enterprise, which focuses on the scenario of early deployment prior to availability of IPv6-capable switch-router equipment. In this method, IPv6 may be routed in parallel with the existing IPv4 in the enterprise and delivered at Layer 2 via VLAN technology. The IPv6 connectivity to the enterprise may or may not enter the site via the same physical link. |
|
| |
| RFC 4559 | SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows |
| |
| Authors: | K. Jaganathan, L. Zhu, J. Brezak. |
| Date: | June 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4559 |
|
This document describes how the Microsoft Internet Explorer (MSIE) and Internet Information Services (IIS) incorporated in MicrosoftWindows 2000 use Kerberos for security enhancements of web transactions. The Hypertext Transport Protocol (HTTP) auth-scheme of"negotiate" is defined here; when the negotiation results in the selection of Kerberos, the security services of authentication and, optionally, impersonation (the IIS server assumes the windows identity of the principal that has been authenticated) are performed.This document explains how HTTP authentication utilizes the Simple and Protected GSS-API Negotiation mechanism. Details of Simple AndProtected Negotiate (SPNEGO) implementation are not provided in this document. |
|
| |
| RFC 4562 | MAC-Forced Forwarding: A Method for Subscriber Separation on an Ethernet Access Network |
| |
| Authors: | T. Melsen, S. Blake. |
| Date: | June 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4562 |
|
This document describes a mechanism to ensure layer-2 separation ofLocal Area Network (LAN) stations accessing an IPv4 gateway over a bridged Ethernet segment.
The mechanism - called "MAC-Forced Forwarding" - implements anAddress Resolution Protocol (ARP) proxy function that prohibitsEthernet Media Access Control (MAC) address resolution between hosts located within the same IPv4 subnet but at different customer premises, and in effect directs all upstream traffic to an IPv4 gateway. The IPv4 gateway provides IP-layer connectivity between these same hosts. |
|
| |
| RFC 4564 | Objectives for Control and Provisioning of Wireless Access Points (CAPWAP) |
| |
| Authors: | S. Govindan, Ed., H. Cheng, ZH. Yao, WH. Zhou, L. Yang. |
| Date: | July 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4564 |
|
This document presents objectives for an interoperable protocol for the Control and Provisioning of Wireless Access Points (CAPWAP). The document aims to establish a set of focused requirements for the development and evaluation of a CAPWAP protocol. The objectives address architecture, operation, security, and network operator requirements that are necessary to enable interoperability amongWireless Local Area Network (WLAN) devices of alternative designs. |
|
| |
| RFC 4565 | Evaluation of Candidate Control and Provisioning of Wireless Access Points (CAPWAP) Protocols |
| |
| Authors: | D. Loher, D. Nelson, O. Volinsky, B. Sarikaya. |
| Date: | July 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4565 |
|
This document is a record of the process and findings of the Control and Provisioning of Wireless Access Points Working Group (CAPWAP WG) evaluation team. The evaluation team reviewed the 4 candidate protocols as they were submitted to the working group on June 26,2005. |
|
| |
| RFC 4569 | Internet Assigned Number Authority (IANA) Registration of the Message Media Feature Tag |
| |
| Authors: | G. Camarillo. |
| Date: | July 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4569 |
|
This document registers with the IANA a new media feature tag associated with the 'message' media type. This media feature tag indicates that a particular device supports 'message' as a streaming media type. Media feature tags can be used to route calls to devices that support certain features. |
|
| |
| RFC 4578 | Dynamic Host Configuration Protocol (DHCP) Options for the Intel Preboot eXecution Environment (PXE) |
| |
| Authors: | M. Johnston, S. Venaas, Ed.. |
| Date: | November 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4578 |
|
We define Dynamic Host Configuration Protocol (DHCP) options being used by Preboot eXecution Environment (PXE) and Extensible FirmwareInterface (EFI) clients to uniquely identify booting client machines and their pre-OS runtime environment so that the DHCP and/or PXE boot server can return the correct OS bootstrap image (or pre-boot application) name and server to the client. |
|
| |
| RFC 4584 | Extension to Sockets API for Mobile IPv6 |
| |
| Authors: | S. Chakrabarti, E. Nordmark. |
| Date: | July 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4584 |
|
This document describes data structures and API support for MobileIPv6 as an extension to the Advanced Socket API for IPv6.
Just as the Advanced Sockets API for IPv6 gives access to various extension headers and the ICMPv6 protocol, this document specifies the same level of access for Mobile IPv6 components. It specifies a mechanism for applications to retrieve and set information forMobility Header messages, Home Address destination options, andRouting Header Type 2 extension headers. It also specifies the common data structures and definitions that might be used by certain advanced Mobile IPv6 socket applications. |
|
| |
| RFC 4586 | Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback: Results of the Timing Rule Simulations |
| |
| Authors: | C. Burmeister, R. Hakenberg, A. Miyazaki, J. Ott, N. Sato, S. Fukunaga. |
| Date: | July 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4586 |
|
This document describes the results achieved when simulating the timing rules of the Extended RTP Profile for Real-time TransportControl Protocol (RTCP)-Based Feedback, denoted AVPF. Unicast and multicast topologies are considered as well as several protocol and environment configurations. The results show that the timing rules result in better performance regarding feedback delay and still preserve the well-accepted RTP rules regarding allowed bit rates for control traffic. |
|
| |
| RFC 4593 | Generic Threats to Routing Protocols |
| |
| Authors: | A. Barbir, S. Murphy, Y. Yang. |
| Date: | October 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4593 |
|
Routing protocols are subject to attacks that can harm individual users or network operations as a whole. This document provides a description and a summary of generic threats that affect routing protocols in general. This work describes threats, including threat sources and capabilities, threat actions, and threat consequences, as well as a breakdown of routing functions that might be attacked separately. |
|
| |
| RFC 4594 | Configuration Guidelines for DiffServ Service Classes |
| |
|
|
This document describes service classes configured with Diffserv and recommends how they can be used and how to construct them usingDifferentiated Services Code Points (DSCPs), traffic conditioners,Per-Hop Behaviors (PHBs), and Active Queue Management (AQM) mechanisms. There is no intrinsic requirement that particular DSCPs, traffic conditioners, PHBs, and AQM be used for a certain service class, but as a policy and for interoperability it is useful to apply them consistently. |
|
| |
| RFC 4595 | Use of IKEv2 in the Fibre Channel Security Association Management Protocol |
| |
| Authors: | F. Maino, D. Black. |
| Date: | July 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4595 |
|
This document describes the use of IKEv2 to negotiate security protocols and transforms for Fibre Channel as part of the FibreChannel Security Association Management Protocol. This usage requires that IKEv2 be extended with Fibre-Channel-specific security protocols, transforms, and name types. This document specifies theseIKEv2 extensions and allocates identifiers for them. Using new IKEv2 identifiers for Fibre Channel security protocols avoids any possible confusion between IKEv2 negotiation for IP networks and IKEv2 negotiation for Fibre Channel. |
|
| |
| RFC 4596 | Guidelines for Usage of the Session Initiation Protocol (SIP) Caller Preferences Extension |
| |
| Authors: | J. Rosenberg, P. Kyzivat. |
| Date: | July 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4596 |
|
This document contains guidelines for usage of the Caller PreferencesExtension to the Session Initiation Protocol (SIP). It demonstrates the benefits of caller preferences with specific example applications, provides use cases to show proper operation, provides guidance on the applicability of the registered feature tags, and describes a straightforward implementation of the preference and capability matching algorithm specified in Section 7.2 of RFC 3841. |
|
| |
| RFC 4597 | Conferencing Scenarios |
| |
| Authors: | R. Even, N. Ismail. |
| Date: | August 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4597 |
|
This document describes multimedia conferencing scenarios. It describes both basic and advanced conferencing scenarios involving voice, video, text, and interactive text sessions. These scenarios will help with the definition and evaluation of the protocols being developed in the centralized conferencing XCON working group. |
|
| |
| RFC 4602 | Protocol Independent Multicast - Sparse Mode (PIM-SM) IETF Proposed Standard Requirements Analysis |
| |
| Authors: | T. Pusateri. |
| Date: | August 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4602 |
|
This document provides supporting documentation to advance theProtocol Independent Multicast - Sparse Mode (PIM-SM) routing protocol from IETF Experimental status to Proposed Standard. |
|
| |
| RFC 4603 | Additional Values for the NAS-Port-Type Attribute |
| |
| Authors: | G. Zorn, G. Weber, R. Foltak. |
| Date: | July 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4603 |
|
This document defines a set of values for the NAS-Port-Type RADIUSAttribute. |
|
| |
| RFC 4609 | Protocol Independent Multicast - Sparse Mode (PIM-SM) Multicast Routing Security Issues and Enhancements |
| |
| Authors: | P. Savola, R. Lehtonen, D. Meyer. |
| Date: | October 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4609 |
|
This memo describes security threats for the larger (intra-domain or inter-domain) multicast routing infrastructures. Only ProtocolIndependent Multicast - Sparse Mode (PIM-SM) is analyzed, in its three main operational modes: the traditional Any-Source Multicast(ASM) model, the source-specific multicast (SSM) model, and the ASM model enhanced by the Embedded Rendezvous Point (Embedded-RP) group-to-RP mapping mechanism. This memo also describes enhancements to the protocol operations that mitigate the identified threats. |
|
| |
| RFC 4613 | Media Type Registrations for Downloadable Sounds for Musical Instrument Digital Interface (MIDI) |
| |
| Authors: | P. Frojdh, U. Lindgren, M. Westerlund. |
| Date: | September 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4613 |
|
This document serves to register a media type for DownloadableSounds. |
|
| |
| RFC 4614 | A Roadmap for Transmission Control Protocol (TCP) Specification Documents |
| |
| Authors: | M. Duke, R. Braden, W. Eddy, E. Blanton. |
| Date: | September 2006 |
| Formats: | txt html json |
| Obsoleted by: | RFC 7414 |
| Updated by: | RFC 6247 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4614 |
|
This document contains a "roadmap" to the Requests for Comments (RFC) documents relating to the Internet's Transmission Control Protocol(TCP). This roadmap provides a brief summary of the documents defining TCP and various TCP extensions that have accumulated in theRFC series. This serves as a guide and quick reference for both TCP implementers and other parties who desire information contained in the TCP-related RFCs. |
|
| |
| RFC 4617 | A Uniform Resource Name (URN) Formal Namespace for the Latvian National Government Integration Project |
| |
| Authors: | J. Kornijenko. |
| Date: | August 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4617 |
|
This document describes a Uniform Resource Name (URN) namespace that is engineered by a consortium (general contractor, Olimps LTD, and subcontractors, ABC software LTD, Microsoft Latvia LTD, Riga Internet eXchange (RIX) Technologies LTD, and Microlink LTD) for naming information resources published and produced by the Latvian NationalGovernment Integration Project (Latvian abbreviation IVIS). |
|
| |
| RFC 4621 | Design of the IKEv2 Mobility and Multihoming (MOBIKE) Protocol |
| |
| Authors: | T. Kivinen, H. Tschofenig. |
| Date: | August 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4621 |
|
The IKEv2 Mobility and Multihoming (MOBIKE) protocol is an extension of the Internet Key Exchange Protocol version 2 (IKEv2). These extensions should enable an efficient management of IKE and IPsecSecurity Associations when a host possesses multiple IP addresses and/or where IP addresses of an IPsec host change over time (for example, due to mobility).
This document discusses the involved network entities and the relationship between IKEv2 signaling and information provided by other protocols. Design decisions for the MOBIKE protocol, background information, and discussions within the working group are recorded. |
|
| |
| RFC 4627 | The application/json Media Type for JavaScript Object Notation (JSON) |
| |
|
|
JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. |
|
| |
| RFC 4628 | RTP Payload Format for H.263 Moving RFC 2190 to Historic Status |
| |
| Authors: | R. Even. |
| Date: | January 2007 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4628 |
|
The first RFC that describes RTP payload format for ITUTelecommunication Standardization Sector (ITU-T) recommendation H.263 is RFC 2190. This specification discusses why to move RFC 2190 to historic status. |
|
| |
| RFC 4634 | US Secure Hash Algorithms (SHA and HMAC-SHA) |
| |
|
|
The United States of America has adopted a suite of Secure HashAlgorithms (SHAs), including four beyond SHA-1, as part of a FederalInformation Processing Standard (FIPS), specifically SHA-224 (RFC3874), SHA-256, SHA-384, and SHA-512. The purpose of this document is to make source code performing these hash functions conveniently available to the Internet community. The sample code supports input strings of arbitrary bit length. SHA-1's sample code from RFC 3174 has also been updated to handle input strings of arbitrary bit length. Most of the text herein was adapted by the authors from FIPS180-2.
Code to perform SHA-based HMACs, with arbitrary bit length text, is also included. |
|
| |
| RFC 4638 | Accommodating a Maximum Transit Unit/Maximum Receive Unit (MTU/MRU) Greater Than 1492 in the Point-to-Point Protocol over Ethernet (PPPoE) |
| |
| Authors: | P. Arberg, D. Kourkouzelis, M. Duckett, T. Anschutz, J. Moisand. |
| Date: | September 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4638 |
|
The Point-to-Point Protocol over Ethernet (PPPoE), as described inRFC 2516, mandates a maximum negotiated Maximum Receive Unit (MRU) of1492. This document outlines a solution that relaxes this restriction and allows a maximum negotiated MRU greater than 1492 to minimize fragmentation in next-generation broadband networks. |
|
| |
| RFC 4640 | Problem Statement for bootstrapping Mobile IPv6 (MIPv6) |
| |
| Authors: | A. Patel, Ed., G. Giaretta, Ed.. |
| Date: | September 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4640 |
|
A mobile node needs at least the following information: a home address, a home agent address, and a security association with home agent to register with the home agent. The process of obtaining this information is called bootstrapping. This document discusses issues involved with how the mobile node can be bootstrapped for Mobile IPv6(MIPv6) and various potential deployment scenarios for mobile node bootstrapping. |
|
| |
| RFC 4641 | DNSSEC Operational Practices |
| |
|
|
This document describes a set of practices for operating the DNS with security extensions (DNSSEC). The target audience is zone administrators deploying DNSSEC.
The document discusses operational aspects of using keys and signatures in the DNS. It discusses issues of key generation, key storage, signature generation, key rollover, and related policies.
This document obsoletes RFC 2541, as it covers more operational ground and gives more up-to-date requirements with respect to key sizes and the new DNSSEC specification. |
|
| |
| RFC 4645 | Initial Language Subtag Registry |
| |
| Authors: | D. Ewell. |
| Date: | September 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4645 |
|
This memo defined the initial contents of the IANA Language SubtagRegistry for use in forming tags for the identification of languages.Since the contents of this memo only served as a starting point for the registry, its actual contents have been removed before publication to avoid confusion. |
|
| |
| RFC 4651 | A Taxonomy and Analysis of Enhancements to Mobile IPv6 Route Optimization |
| |
| Authors: | C. Vogt, J. Arkko. |
| Date: | February 2007 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4651 |
|
This document describes and evaluates strategies to enhance MobileIPv6 Route Optimization, on the basis of existing proposals, in order to motivate and guide further research in this context. This document is a product of the IP Mobility Optimizations (MobOpts)Research Group. |
|
| |
| RFC 4652 | Evaluation of Existing Routing Protocols against Automatic Switched Optical Network (ASON) Routing Requirements |
| |
| Authors: | D. Papadimitriou, Ed., L. Ong, J. Sadler, S. Shew, D. Ward. |
| Date: | October 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4652 |
|
The Generalized MPLS (GMPLS) suite of protocols has been defined to control different switching technologies as well as different applications. These include support for requesting TDM connections including Synchronous Optical Network/Synchronous Digital Hierarchy(SONET/SDH) and Optical Transport Networks (OTNs).
This document provides an evaluation of the IETF Routing Protocols against the routing requirements for an Automatically SwitchedOptical Network (ASON) as defined by ITU-T. |
|
| |
| RFC 4655 | A Path Computation Element (PCE)-Based Architecture |
| |
| Authors: | A. Farrel, J.-P. Vasseur, J. Ash. |
| Date: | August 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4655 |
|
Constraint-based path computation is a fundamental building block for traffic engineering systems such as Multiprotocol Label Switching(MPLS) and Generalized Multiprotocol Label Switching (GMPLS) networks. Path computation in large, multi-domain, multi-region, or multi-layer networks is complex and may require special computational components and cooperation between the different network domains.
This document specifies the architecture for a Path ComputationElement (PCE)-based model to address this problem space. This document does not attempt to provide a detailed description of all the architectural components, but rather it describes a set of building blocks for the PCE architecture from which solutions may be constructed. |
|
| |
| RFC 4657 | Path Computation Element (PCE) Communication Protocol Generic Requirements |
| |
| Authors: | J. Ash, Ed., J.L. Le Roux, Ed.. |
| Date: | September 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4657 |
|
The PCE model is described in the "PCE Architecture" document and facilitates path computation requests from Path Computation Clients(PCCs) to Path Computation Elements (PCEs). This document specifies generic requirements for a communication protocol between PCCs andPCEs, and also between PCEs where cooperation between PCEs is desirable. Subsequent documents will specify application-specific requirements for the PCE communication protocol. |
|
| |
| RFC 4663 | Transferring MIB Work from IETF Bridge MIB WG to IEEE 802.1 WG |
| |
| Authors: | D. Harrington. |
| Date: | September 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4663 |
|
This document describes the plan to transition responsibility for bridging-related MIB modules from the IETF Bridge MIB Working Group to the IEEE 802.1 Working Group, which develops the bridging technology the MIB modules are designed to manage. |
|
| |
| RFC 4664 | Framework for Layer 2 Virtual Private Networks (L2VPNs) |
| |
| Authors: | L. Andersson, Ed., E. Rosen, Ed.. |
| Date: | September 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4664 |
|
This document provides a framework for Layer 2 Provider ProvisionedVirtual Private Networks (L2VPNs). This framework is intended to aid in standardizing protocols and mechanisms to support interoperableL2VPNs. |
|
| |
| RFC 4665 | Service Requirements for Layer 2 Provider-Provisioned Virtual Private Networks |
| |
| Authors: | W. Augustyn, Ed., Y. Serbest, Ed.. |
| Date: | September 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4665 |
|
This document provides requirements for Layer 2 Provider-ProvisionedVirtual Private Networks (L2VPNs). It first provides taxonomy and terminology and states generic and general service requirements. It covers point-to-point VPNs, referred to as Virtual Private WireService (VPWS), as well as multipoint-to-multipoint VPNs, also known as Virtual Private LAN Service (VPLS). Detailed requirements are expressed from both a customer as well as a service provider perspectives. |
|
| |
| RFC 4670 | RADIUS Accounting Client MIB for IPv6 |
| |
|
|
This memo defines a set of extensions that instrument RADIUS accounting client functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions,IP-based management stations can manage RADIUS accounting clients.
This memo obsoletes RFC 2620 by deprecating the MIB table containingIPv4-only address formats and defining a new table to add support for version-neutral IP address formats. The remaining MIB objects fromRFC 2620 are carried forward into this document. This memo also addsUNITS and REFERENCE clauses to selected objects. |
|
| |
| RFC 4671 | RADIUS Accounting Server MIB for IPv6 |
| |
|
|
This memo defines a set of extensions that instrument RADIUS accounting server functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions,IP-based management stations can manage RADIUS accounting servers.
This memo obsoletes RFC 2621 by deprecating the MIB table containingIPv4-only address formats and defining a new table to add support for version-neutral IP address formats. The remaining MIB objects fromRFC 2621 are carried forward into this document. This memo also addsUNITS and REFERENCE clauses to selected objects. |
|
| |
| RFC 4672 | RADIUS Dynamic Authorization Client MIB |
| |
| Authors: | S. De Cnodder, N. Jonnala, M. Chiba. |
| Date: | September 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4672 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes the Remote Authentication Dial-In UserService (RADIUS) (RFC2865) Dynamic Authorization Client (DAC) functions that support the dynamic authorization extensions as defined in RFC 3576. |
|
| |
| RFC 4673 | RADIUS Dynamic Authorization Server MIB |
| |
| Authors: | S. De Cnodder, N. Jonnala, M. Chiba. |
| Date: | September 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4673 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes the Remote Authentication Dial-In UserService (RADIUS) (RFC 2865) Dynamic Authorization Server (DAS) functions that support the dynamic authorization extensions as defined in RFC 3576. |
|
| |
| RFC 4674 | Requirements for Path Computation Element (PCE) Discovery |
| |
| Authors: | J.L. Le Roux, Ed.. |
| Date: | October 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4674 |
|
This document presents a set of requirements for a Path ComputationElement (PCE) discovery mechanism that would allow a Path ComputationClient (PCC) to discover dynamically and automatically a set of PCEs along with certain information relevant for PCE selection. It is intended that solutions that specify procedures and protocols or extensions to existing protocols for such PCE discovery satisfy these requirements. |
|
| |
| RFC 4677 | The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force |
| |
|
|
This document describes the inner workings of IETF meetings andWorking Groups, discusses organizations related to the IETF, and introduces the standards process. It is not a formal IETF process document but instead an informational overview. |
|
| |
| RFC 4678 | Server/Application State Protocol v1 |
| |
| Authors: | A. Bivens. |
| Date: | September 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4678 |
|
Entities responsible for distributing work across a group of systems traditionally do not know a great deal about the ability of the applications on those systems to complete the work in a satisfactory fashion. Workload management systems traditionally know a great deal about the health of applications, but have little control over the rate in which these applications receive work. TheServer/Application State Protocol (SASP) provides a mechanism for load balancers and workload management systems to communicate better ways of distributing the existing workload to the group members. |
|
| |
| RFC 4679 | DSL Forum Vendor-Specific RADIUS Attributes |
| |
| Authors: | V. Mammoliti, G. Zorn, P. Arberg, R. Rennison. |
| Date: | September 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4679 |
|
This document describes the set of Remote Authentication Dial-In UserService Vendor-Specific Attributes (RADIUS VSAs) defined by the DSLForum.
These attributes are designed to transport Digital Subscriber Line(DSL) information that is not supported by the standard RADIUS attribute set. It is expected that this document will be updated if and when the DSL Forum defines additional vendor-specific attributes, since its primary purpose is to provide a reference for DSL equipment vendors wishing to interoperate with other vendors' products. |
|
| |
| RFC 4686 | Analysis of Threats Motivating DomainKeys Identified Mail (DKIM) |
| |
| Authors: | J. Fenton. |
| Date: | September 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4686 |
|
This document provides an analysis of some threats against Internet mail that are intended to be addressed by signature-based mail authentication, in particular DomainKeys Identified Mail. It discusses the nature and location of the bad actors, what their capabilities are, and what they intend to accomplish via their attacks. |
|
| |
| RFC 4687 | Operations and Management (OAM) Requirements for Point-to-Multipoint MPLS Networks |
| |
| Authors: | S. Yasukawa, A. Farrel, D. King, T. Nadeau. |
| Date: | September 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4687 |
|
Multi-Protocol Label Switching (MPLS) has been extended to encompass point-to-multipoint (P2MP) Label Switched Paths (LSPs). As with point-to-point MPLS LSPs, the requirement to detect, handle, and diagnose control and data plane defects is critical.
For operators deploying services based on P2MP MPLS LSPs, the detection and specification of how to handle those defects are important because such defects not only may affect the fundamentals of an MPLS network, but also may impact service level specification commitments for customers of their network.
This document describes requirements for data plane operations and management for P2MP MPLS LSPs. These requirements apply to all forms of P2MP MPLS LSPs, and include P2MP Traffic Engineered (TE) LSPs and multicast LSPs. |
|
| |
| RFC 4688 | A Uniform Resource Name (URN) Namespace for Aerospace and Defence Industries Association of Europe (ASD) Specification 1000D |
| |
| Authors: | S. Rushing. |
| Date: | October 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4688 |
|
This document describes a Uniform Resource Name (URN) namespace for naming persistent resources defined by Aerospace and DefenceIndustries Association of Europe (ASD) Specification 1000D. |
|
| |
| RFC 4689 | Terminology for Benchmarking Network-layer Traffic Control Mechanisms |
| |
| Authors: | S. Poretsky, J. Perser, S. Erramilli, S. Khurana. |
| Date: | October 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4689 |
|
This document describes terminology for the benchmarking of devices that implement traffic control using packet classification based on defined criteria. The terminology is to be applied to measurements made on the data plane to evaluate IP traffic control mechanisms.Rules for packet classification can be based on any field in the IP header, such as the Differentiated Services Code Point (DSCP), or any field in the packet payload, such as port number. |
|
| |
| RFC 4690 | Review and Recommendations for Internationalized Domain Names (IDNs) |
| |
| Authors: | J. Klensin, P. Faltstrom, C. Karp, IAB. |
| Date: | September 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4690 |
|
This note describes issues raised by the deployment and use ofInternationalized Domain Names. It describes problems both at the time of registration and for use of those names in the DNS. It recommends that IETF should update the RFCs relating to IDNs and a framework to be followed in doing so, as well as summarizing and identifying some work that is required outside the IETF. In particular, it proposes that some changes be investigated for theInternationalizing Domain Names in Applications (IDNA) standard and its supporting tables, based on experience gained since those standards were completed. |
|
| |
| RFC 4691 | Guidelines for Acting as an IETF Liaison to Another Organization |
| |
| Authors: | L. Andersson, Ed.. |
| Date: | October 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4691 |
|
Whenever the IETF decides to enter into a liaison relationship with another organization, such as a Standards Development Organization(SDO), a consortium, or an industrial forum, a liaison manager is appointed. The procedures used by the IAB to establish and maintain liaison relationships between the IETF and other organizations are described in RFC 4052. This document expands on the role of liaison managers and liaison representatives, giving guidelines on their mandate and the expectations, tasks, and responsibilities placed on them. |
|
| |
| RFC 4692 | Considerations on the IPv6 Host Density Metric |
| |
| Authors: | G. Huston. |
| Date: | October 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4692 |
|
This memo provides an analysis of the Host Density metric as it is currently used to guide registry allocations of IPv6 unicast address blocks. This document contrasts the address efficiency as currently adopted in the allocation of IPv4 network addresses and that used by the IPv6 protocol. Note that for large allocations there are very significant variations in the target efficiency metric between the two approaches. |
|
| |
| RFC 4696 | An Implementation Guide for RTP MIDI |
| |
| Authors: | J. Lazzaro, J. Wawrzynek. |
| Date: | November 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4696 |
|
This memo offers non-normative implementation guidance for the Real- time Protocol (RTP) MIDI (Musical Instrument Digital Interface) payload format. The memo presents its advice in the context of a network musical performance application. In this application two musicians, located in different physical locations, interact over a network to perform as they would if located in the same room.Underlying the performances are RTP MIDI sessions over unicast UDP.Algorithms for sending and receiving recovery journals (the resiliency structure for the payload format) are described in detail.Although the memo focuses on network musical performance, the presented implementation advice is relevant to other RTP MIDI applications. |
|
| |
| RFC 4705 | GigaBeam High-Speed Radio Link Encryption |
| |
| Authors: | R. Housley, A. Corry. |
| Date: | October 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4705 |
|
This document describes the encryption and key management used byGigaBeam as part of the WiFiber(tm) family of radio link products.The security solution is documented in the hope that other wireless product development efforts will include comparable capabilities. |
|
| |
| RFC 4708 | CellML Media Type |
| |
| Authors: | A. Miller. |
| Date: | October 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4708 |
|
This document standardises a new media type -- application/cellml+xml-- for use in exchanging mathematical models represented in a CellMLUmbrella 1.0 compliant markup language. |
|
| |
| RFC 4709 | Mounting Web Distributed Authoring and Versioning (WebDAV) Servers |
| |
| Authors: | J. Reschke. |
| Date: | October 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4709 |
|
In current Web browsers, there is no uniform way to specify that a user clicking on a link will be presented with an editable view of aWeb Distinguished Authoring and Versioning (WebDAV) server. For example, it is frequently desirable to be able to click on a link and have this link open a window that can handle drag-and-drop interaction with the resources of a WebDAV server.
This document specifies a mechanism and a document format that enables WebDAV servers to send "mounting" information to a WebDAV client. The mechanism is designed to work on any platform and with any combination of browser and WebDAV client, relying solely on the well-understood dispatch of documents through their MIME type. |
|
| |
| RFC 4713 | Registration and Administration Recommendations for Chinese Domain Names |
| |
| Authors: | X. Lee, W. Mao, E. Chen, N. Hsu, J. Klensin. |
| Date: | October 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4713 |
|
Many Chinese characters in common use have variants, which makes most of the Chinese Domain Names (CDNs) have at least two different forms.The equivalence between Simplified Chinese (SC) and TraditionalChinese (TC) characters is very important for CDN registration. This memo builds on the basic concepts, general guidelines, and framework of RFC 3743 to specify proposed registration and administration procedures for Chinese domain names. The document provides the information needed for understanding and using the tables defined in the IANA table registrations for Simplified and Traditional Chinese. |
|
| |
| RFC 4714 | Requirements for IETF Technical Publication Service |
| |
| Authors: | A. Mankin, S. Hayes. |
| Date: | October 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4714 |
|
The work of the IETF is to discuss, develop, and disseminate technical specifications to support the Internet's operation.Technical publication is the process by which that output is disseminated to the community at large. As such, it is important to understand the requirements on the publication process. |
|
| |
| RFC 4715 | The Integrated Services Digital Network (ISDN) Subaddress Encoding Type for tel URI |
| |
| Authors: | M. Munakata, S. Schubert, T. Ohba. |
| Date: | November 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4715 |
|
Without a tel URI parameter to carry an encoding type of IntegratedServices Digital Network (ISDN) subaddress, interworking between ISDNUser Part (ISUP) network and a Session Initiation Protocol (SIP) network is impossible in some cases. To solve this problem, this document specifies a new optional tel URI parameter to carry the encoding type of ISDN subaddress. |
|
| |
| RFC 4716 | The Secure Shell (SSH) Public Key File Format |
| |
| Authors: | J. Galbraith, R. Thayer. |
| Date: | November 2006 |
| Formats: | txt html json |
| Updated by: | RFC 9519 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4716 |
|
This document formally documents an existing public key file format in use for exchanging public keys between different Secure Shell(SSH) implementations.
In addition, this document defines a standard textual representation for SSH public key fingerprints. |
|
| |
| RFC 4718 | IKEv2 Clarifications and Implementation Guidelines |
| |
| Authors: | P. Eronen, P. Hoffman. |
| Date: | October 2006 |
| Formats: | txt json html |
| Obsoleted by: | RFC 5996 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4718 |
|
This document clarifies many areas of the IKEv2 specification. It does not to introduce any changes to the protocol, but rather provides descriptions that are less prone to ambiguous interpretations. The purpose of this document is to encourage the development of interoperable implementations. |
|
| |
| RFC 4722 | Media Server Control Markup Language (MSCML) and Protocol |
| |
| Authors: | J. Van Dyke, E. Burger, Ed., A. Spitzer. |
| Date: | November 2006 |
| Formats: | txt html json |
| Obsoleted by: | RFC 5022 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4722 |
|
Media Server Control Markup Language (MSCML) is a markup language used in conjunction with SIP to provide advanced conferencing and interactive voice response (IVR) functions. MSCML presents an application-level control model, as opposed to device-level control models. One use of this protocol is for communications between a conference focus and mixer in the IETF SIP Conferencing Framework. |
|
| |
| RFC 4723 | Registration of Media Type audio/mobile-xmf |
| |
| Authors: | T. Kosonen, T. White. |
| Date: | December 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4723 |
|
The MIDI Manufacturers Association (MMA) and the Association ofMusical Electronics Industry (AMEI) have produced the Mobile XMF standard, which was developed particularly for mobile MIDI applications. Mobile XMF is a very compact media type providing high-quality synthetic audio content for music downloading and messaging applications that require MIME registration. This document registers the media type audio/mobile-xmf. |
|
| |
| RFC 4725 | ENUM Validation Architecture |
| |
| Authors: | A. Mayrhofer, B. Hoeneisen. |
| Date: | November 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4725 |
|
An ENUM domain name is tightly coupled with the underlying E.164 number. The process of verifying whether or not the Registrant of anENUM domain name is identical to the Assignee of the correspondingE.164 number is commonly called "validation". This document describes validation requirements and a high-level architecture for an ENUM validation infrastructure. |
|
| |
| RFC 4726 | A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering |
| |
| Authors: | A. Farrel, J.-P. Vasseur, A. Ayyangar. |
| Date: | November 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4726 |
|
This document provides a framework for establishing and controllingMultiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS)Traffic Engineered (TE) Label Switched Paths (LSPs) in multi-domain networks.
For the purposes of this document, a domain is considered to be any collection of network elements within a common sphere of address management or path computational responsibility. Examples of such domains include Interior Gateway Protocol (IGP) areas and AutonomousSystems (ASes). |
|
| |
| RFC 4729 | A Uniform Resource Name (URN) Namespace for the Near Field Communication (NFC) Forum |
| |
| Authors: | M. Abel. |
| Date: | November 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4729 |
|
This document describes the Namespace Identifier (NID) for UniformResource Name (URN) resources published by the Near FieldCommunication (NFC) Forum. The NFC Forum defines and manages resources that utilize this URN identification model. Management activities for these and other resource types are provided by the NFCForum Technical Committee. |
|
| |
| RFC 4732 | Internet Denial-of-Service Considerations |
| |
| Authors: | M. Handley, Ed., E. Rescorla, Ed., IAB. |
| Date: | December 2006 |
| Formats: | txt html json |
| Updated by: | RFC 8996 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4732 |
|
This document provides an overview of possible avenues for denial- of-service (DoS) attack on Internet systems. The aim is to encourage protocol designers and network engineers towards designs that are more robust. We discuss partial solutions that reduce the effectiveness of attacks, and how some solutions might inadvertently open up alternative vulnerabilities. |
|
| |
| RFC 4736 | Reoptimization of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Loosely Routed Label Switched Path (LSP) |
| |
| Authors: | JP. Vasseur, Ed., Y. Ikejiri, R. Zhang. |
| Date: | November 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4736 |
|
This document defines a mechanism for the reoptimization of loosely routed MPLS and GMPLS (Generalized Multiprotocol Label Switching)Traffic Engineering (TE) Label Switched Paths (LSPs) signaled withResource Reservation Protocol Traffic Engineering (RSVP-TE). This document proposes a mechanism that allows a TE LSP head-end LabelSwitching Router (LSR) to trigger a new path re-evaluation on every hop that has a next hop defined as a loose or abstract hop and a mid-point LSR to signal to the head-end LSR that a better path exists(compared to the current path) or that the TE LSP must be reoptimized(because of maintenance required on the TE LSP path). The proposed mechanism applies to the cases of intra- and inter-domain (InteriorGateway Protocol area (IGP area) or Autonomous System) packet and non-packet TE LSPs following a loosely routed path. |
|
| |
| RFC 4746 | Extensible Authentication Protocol (EAP) Password Authenticated Exchange |
| |
| Authors: | T. Clancy, W. Arbaugh. |
| Date: | November 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4746 |
|
This document defines an Extensible Authentication Protocol (EAP) method called EAP-PAX (Password Authenticated eXchange). This method is a lightweight shared-key authentication protocol with optional support for key provisioning, key management, identity protection, and authenticated data exchange. |
|
| |
| RFC 4753 | ECP Groups For IKE and IKEv2 |
| |
|
|
This document describes new Elliptic Curve Cryptography (ECC) groups for use in the Internet Key Exchange (IKE) and Internet Key Exchange version 2 (IKEv2) protocols in addition to previously defined groups.Specifically, the new curve groups are based on modular arithmetic rather than binary arithmetic. These new groups are defined to alignIKE and IKEv2 with other ECC implementations and standards, particularly NIST standards. In addition, the curves defined here can provide more efficient implementation than previously defined ECC groups. |
|
| |
| RFC 4758 | Cryptographic Token Key Initialization Protocol (CT-KIP) Version 1.0 Revision 1 |
| |
| Authors: | M. Nystroem. |
| Date: | November 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4758 |
|
This document constitutes Revision 1 of Cryptographic Token KeyInitialization Protocol (CT-KIP) Version 1.0 from RSA Laboratories'One-Time Password Specifications (OTPS) series. The body of this document, except for the intellectual property considerations section, is taken from the CT-KIP Version 1.0 document, but comments received during the IETF review are reflected; hence, the status of a revised version. As no "bits-on-the-wire" have changed, the protocol specified herein is compatible with CT-KIP Version 1.0.
CT-KIP is a client-server protocol for initialization (and configuration) of cryptographic tokens. The protocol requires neither private-key capabilities in the cryptographic tokens, nor an established public-key infrastructure. Provisioned (or generated) secrets will only be available to the server and the cryptographic token itself. |
|
| |
| RFC 4763 | Extensible Authentication Protocol Method for Shared-secret Authentication and Key Establishment (EAP-SAKE) |
| |
| Authors: | M. Vanderveen, H. Soliman. |
| Date: | November 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4763 |
|
This document specifies an Extensible Authentication Protocol (EAP) mechanism for Shared-secret Authentication and Key Establishment(SAKE). This RFC is published as documentation for the IANA assignment of an EAP Type for a vendor's EAP method per RFC 3748.The specification has passed Designated Expert review for this IANA assignment. |
|
| |
| RFC 4766 | Intrusion Detection Message Exchange Requirements |
| |
| Authors: | M. Wood, M. Erlinger. |
| Date: | March 2007 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4766 |
|
The purpose of the Intrusion Detection Exchange Format Working Group(IDWG) is to define data formats and exchange procedures for sharing information of interest to intrusion detection and response systems and to the management systems that may need to interact with them.This document describes the high-level requirements for such a communication mechanism, including the rationale for those requirements where clarification is needed. Scenarios are used to illustrate some requirements. |
|
| |
| RFC 4768 | Desired Enhancements to Generic Security Services Application Program Interface (GSS-API) Version 3 Naming |
| |
| Authors: | S. Hartman. |
| Date: | December 2006 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4768 |
|
The Generic Security Services API (GSS-API) provides a naming architecture that supports name-based authorization. GSS-API authenticates two named parties to each other. Names can be stored on access control lists (ACLs) to make authorization decisions.Advances in security mechanisms and the way implementers wish to useGSS-API require this model to be extended for the next version ofGSS-API. As people move within an organization or change their names, the name authenticated by GSS-API may change. Using some sort of constant identifier would make ACLs more stable. Some mechanisms, such as public-key mechanisms, do not have a single name to be used across all environments. Other mechanisms, such as Kerberos, may include group membership or role information as part of authentication. This document motivates extensions to GSS-API naming and describes the extensions under discussion. |
|
| |
| RFC 4772 | Security Implications of Using the Data Encryption Standard (DES) |
| |
| Authors: | S. Kelly. |
| Date: | December 2006 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4772 |
|
The Data Encryption Standard (DES) is susceptible to brute-force attacks, which are well within the reach of a modestly financed adversary. As a result, DES has been deprecated, and replaced by theAdvanced Encryption Standard (AES). Nonetheless, many applications continue to rely on DES for security, and designers and implementers continue to support it in new applications. While this is not always inappropriate, it frequently is. This note discusses DES security implications in detail, so that designers and implementers have all the information they need to make judicious decisions regarding its use. |
|
| |
| RFC 4773 | Administration of the IANA Special Purpose IPv6 Address Block |
| |
|
|
This is a direction to IANA concerning the management of the IANASpecial Purpose IPv6 address assignment registry. |
|
| |
| RFC 4777 | IBM's iSeries Telnet Enhancements |
| |
| Authors: | T. Murphy Jr., P. Rieth, J. Stevens. |
| Date: | November 2006 |
| Formats: | txt json html |
| Obsoletes: | RFC 2877 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4777 |
|
This document describes the interface to the Telnet server on IBM's iSeries line of midrange business computers. This interface allowsTelnet clients to request a Telnet terminal or printer session using specific session attributes related to device names, encryption, language support, auto-sign-on, response codes, session association, etc.
These support functions are implemented primarily using the TelnetEnvironment option negotiation RFC 1572 to define new USERVAR variables that will be recognized by iSeries Telnet server. |
|
| |
| RFC 4778 | Operational Security Current Practices in Internet Service Provider Environments |
| |
| Authors: | M. Kaeo. |
| Date: | January 2007 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4778 |
|
This document is a survey of the current practices used in today's large ISP operational networks to secure layer 2 and layer 3 infrastructure devices. The information listed here is the result of information gathered from people directly responsible for defining and implementing secure infrastructures in Internet Service Provider environments. |
|
| |
| RFC 4779 | ISP IPv6 Deployment Scenarios in Broadband Access Networks |
| |
| Authors: | S. Asadullah, A. Ahmed, C. Popoviciu, P. Savola, J. Palet. |
| Date: | January 2007 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4779 |
|
This document provides a detailed description of IPv6 deployment and integration methods and scenarios in today's Service Provider (SP)Broadband (BB) networks in coexistence with deployed IPv4 services.Cable/HFC, BB Ethernet, xDSL, and WLAN are the main BB technologies that are currently deployed, and discussed in this document. The emerging Broadband Power Line Communications (PLC/BPL) access technology is also discussed for completeness. In this document we will discuss main components of IPv6 BB networks, their differences from IPv4 BB networks, and how IPv6 is deployed and integrated in each of these networks using tunneling mechanisms and native IPv6. |
|
| |
| RFC 4784 | Verizon Wireless Dynamic Mobile IP Key Update for cdma2000(R) Networks |
| |
| Authors: | C. Carroll, F. Quick. |
| Date: | June 2007 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4784 |
|
The Verizon Wireless Dynamic Mobile IP Key Update procedure is a mechanism for distributing and updating Mobile IP (MIP) cryptographic keys in cdma2000(R) networks (including High Rate Packet Data, which is often referred to as 1xEV-DO). The Dynamic Mobile IP Key Update(DMU) procedure occurs between the MIP Mobile Node (MN) and RADIUSAuthentication, Authorization and Accounting (AAA) Server via a cdma2000(R) Packet Data Serving Node (PDSN) that is acting as aMobile IP Foreign Agent (FA). cdma2000(R) is a registered trademark of the TelecommunicationsIndustry Association (TIA). |
|
| |
| RFC 4793 | The EAP Protected One-Time Password Protocol (EAP-POTP) |
| |
| Authors: | M. Nystroem. |
| Date: | February 2007 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4793 |
|
This document describes a general Extensible Authentication Protocol(EAP) method suitable for use with One-Time Password (OTP) tokens, and offers particular advantages for tokens with direct electronic interfaces to their associated clients. The method can be used to provide unilateral or mutual authentication, and key material, in protocols utilizing EAP, such as PPP, IEEE 802.1X, and Internet KeyExchange Protocol Version 2 (IKEv2). |
|
| |
| RFC 4794 | RFC 1264 Is Obsolete |
| |
|
|
RFC 1264 was written during what was effectively a completely different time in the life of the Internet. It prescribed rules to protect the Internet against new routing protocols that may have various undesirable properties. In today's Internet, there are so many other pressures against deploying unreasonable protocols that we believe that existing controls suffice, and the RFC 1264 rules just get in the way. |
|
| |
| RFC 4795 | Link-local Multicast Name Resolution (LLMNR) |
| |
| Authors: | B. Aboba, D. Thaler, L. Esibov. |
| Date: | January 2007 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4795 |
|
The goal of Link-Local Multicast Name Resolution (LLMNR) is to enable name resolution in scenarios in which conventional DNS name resolution is not possible. LLMNR supports all current and futureDNS formats, types, and classes, while operating on a separate port from DNS, and with a distinct resolver cache. Since LLMNR only operates on the local link, it cannot be considered a substitute forDNS. |
|
| |
| RFC 4797 | Use of Provider Edge to Provider Edge (PE-PE) Generic Routing Encapsulation (GRE) or IP in BGP/MPLS IP Virtual Private Networks |
| |
| Authors: | Y. Rekhter, R. Bonica, E. Rosen. |
| Date: | January 2007 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4797 |
|
This document describes an implementation strategy for BGP/MPLS IPVirtual Private Networks (VPNs) in which the outermost MPLS label(i.e., the tunnel label) is replaced with either an IP header or anIP header with Generic Routing Encapsulation (GRE).
The implementation strategy described herein enables the deployment of BGP/MPLS IP VPN technology in networks whose edge devices are MPLS and VPN aware, but whose interior devices are not. |
|
| |
| RFC 4808 | Key Change Strategies for TCP-MD5 |
| |
| Authors: | S. Bellovin. |
| Date: | March 2007 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4808 |
|
The TCP-MD5 option is most commonly used to secure BGP sessions between routers. However, changing the long-term key is difficult, since the change needs to be synchronized between different organizations. We describe single-ended strategies that will permit(mostly) unsynchronized key changes. |
|
| |
| RFC 4809 | Requirements for an IPsec Certificate Management Profile |
| |
| Authors: | C. Bonatti, Ed., S. Turner, Ed., G. Lebovitz, Ed.. |
| Date: | February 2007 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4809 |
|
This informational document describes and identifies the requirements for transactions to handle Public Key Certificate (PKC) lifecycle transactions between Internet Protocol Security (IPsec) VirtualPrivate Network (VPN) Systems using Internet Key Exchange (IKE)(versions 1 and 2) and Public Key Infrastructure (PKI) Systems.These requirements are designed to meet the needs of enterprise-scaleIPsec VPN deployments. It is intended that a standards track profile of a management protocol will be created to address many of these requirements. |
|
| |
| RFC 4810 | Long-Term Archive Service Requirements |
| |
| Authors: | C. Wallace, U. Pordesch, R. Brandner. |
| Date: | March 2007 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4810 |
|
There are many scenarios in which users must be able to prove the existence of data at a specific point in time and be able to demonstrate the integrity of data since that time, even when the duration from time of existence to time of demonstration spans a large period of time. Additionally, users must be able to verify signatures on digitally signed data many years after the generation of the signature. This document describes a class of long-term archive services to support such scenarios and the technical requirements for interacting with such services. |
|
| |
| RFC 4811 | OSPF Out-of-Band Link State Database (LSDB) Resynchronization |
| |
| Authors: | L. Nguyen, A. Roy, A. Zinin. |
| Date: | March 2007 |
| Formats: | txt json html |
| Updated by: | RFC 9454 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4811 |
|
OSPF is a link-state intra-domain routing protocol used in IP networks. Link State Database (LSDB) synchronization in OSPF is achieved via two methods -- initial LSDB synchronization when an OSPF router has just been connected to the network and asynchronous flooding that ensures continuous LSDB synchronization in the presence of topology changes after the initial procedure was completed. It may sometime be necessary for OSPF routers to resynchronize theirLSDBs. The OSPF standard, however, does not allow routers to do so without actually changing the topology view of the network.
This memo describes a vendor-specific mechanism to perform such a form of out-of-band LSDB synchronization. The mechanism described in this document was proposed before Graceful OSPF Restart, as described in RFC 3623, came into existence. It is implemented/supported by at least one major vendor and is currently deployed in the field. The purpose of this document is to capture the details of this mechanism for public use. This mechanism is not an IETF standard. |
|
| |
| RFC 4812 | OSPF Restart Signaling |
| |
| Authors: | L. Nguyen, A. Roy, A. Zinin. |
| Date: | March 2007 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4812 |
|
OSPF is a link-state intra-domain routing protocol used in IP networks. Routers find new and detect unreachable neighbors via theHello subprotocol. Hello OSPF packets are also used to ensure two- way connectivity within time. When a router restarts its OSPF software, it may not know its neighbors. If such a router sends aHello packet on an interface, its neighbors are going to reset the adjacency, which may not be desirable in certain conditions.
This memo describes a vendor-specific mechanism that allows OSPF routers to inform their neighbors about the restart process. Note that this mechanism requires support from neighboring routers. The mechanism described in this document was proposed before GracefulOSPF Restart, as described in RFC 3623, came into existence. It is implemented/supported by at least one major vendor and is currently deployed in the field. The purpose of this document is to capture the details of this mechanism for public use. This mechanism is not an IETF standard. |
|
| |
| RFC 4814 | Hash and Stuffing: Overlooked Factors in Network Device Benchmarking |
| |
| Authors: | D. Newman, T. Player. |
| Date: | March 2007 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4814 |
|
Test engineers take pains to declare all factors that affect a given measurement, including intended load, packet length, test duration, and traffic orientation. However, current benchmarking practice overlooks two factors that have a profound impact on test results.First, existing methodologies do not require the reporting of addresses or other test traffic contents, even though these fields can affect test results. Second, "stuff" bits and bytes inserted in test traffic by some link-layer technologies add significant and variable overhead, which in turn affects test results. This document describes the effects of these factors; recommends guidelines for test traffic contents; and offers formulas for determining the probability of bit- and byte-stuffing in test traffic. |
|
| |
| RFC 4823 | FTP Transport for Secure Peer-to-Peer Business Data Interchange over the Internet |
| |
|
|
This Applicability Statement (AS) describes how to exchange structured business data securely using the File Transfer Protocol(FTP) for XML, Binary, Electronic Data Interchange (EDI - ANSI X12 orUN/EDIFACT), or other data used for business-to-business data interchange for which MIME packaging can be accomplished using standard MIME content types. Authentication and data confidentiality are obtained by using Cryptographic Message Syntax (S/MIME) security body parts. Authenticated acknowledgements employ multipart/signed replies to the original message. |
|
| |
| RFC 4824 | The Transmission of IP Datagrams over the Semaphore Flag Signaling System (SFSS) |
| |
| Authors: | J. Hofmueller, Ed., A. Bachmann, Ed., IO. zmoelnig, Ed.. |
| Date: | 1 April 2007 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4824 |
|
This document specifies a method for encapsulating and transmittingIPv4/IPv6 packets over the Semaphore Flag Signal System (SFSS). |
|
| |
| RFC 4829 | Label Switched Path (LSP) Preemption Policies for MPLS Traffic Engineering |
| |
| Authors: | J. de Oliveira, Ed., JP. Vasseur, Ed., L. Chen, C. Scoglio. |
| Date: | April 2007 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4829 |
|
When the establishment of a higher priority (Traffic EngineeringLabel Switched Path) TE LSP requires the preemption of a set of lower priority TE LSPs, a node has to make a local decision to select whichTE LSPs will be preempted. The preempted LSPs are then rerouted by their respective Head-end Label Switch Router (LSR). This document presents a flexible policy that can be used to achieve different objectives: preempt the lowest priority LSPs; preempt the minimum number of LSPs; preempt the set of TE LSPs that provide the closest amount of bandwidth to the required bandwidth for the preempting TELSPs (to minimize bandwidth wastage); preempt the LSPs that will have the maximum chance to get rerouted. Simulation results are given and a comparison among several different policies, with respect to preemption cascading, number of preempted LSPs, priority, wasted bandwidth and blocking probability is also included. |
|
| |
| RFC 4830 | Problem Statement for Network-Based Localized Mobility Management (NETLMM) |
| |
| Authors: | J. Kempf, Ed.. |
| Date: | April 2007 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4830 |
|
Localized mobility management is a well-understood concept in theIETF, with a number of solutions already available. This document looks at the principal shortcomings of the existing solutions, all of which involve the host in mobility management, and makes a case for network-based local mobility management. |
|
| |
| RFC 4831 | Goals for Network-Based Localized Mobility Management (NETLMM) |
| |
| Authors: | J. Kempf, Ed.. |
| Date: | April 2007 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4831 |
|
In this document, design goals for a network-based localized mobility management (NETLMM) protocol are discussed. |
|
| |
| RFC 4832 | Security Threats to Network-Based Localized Mobility Management (NETLMM) |
| |
| Authors: | C. Vogt, J. Kempf. |
| Date: | April 2007 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4832 |
|
This document discusses security threats to network-based localized mobility management. Threats may occur on two interfaces: the interface between a localized mobility anchor and a mobile access gateway, as well as the interface between a mobile access gateway and a mobile node. Threats to the former interface impact the localized mobility management protocol itself. |
|
| |
| RFC 4834 | Requirements for Multicast in Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs) |
| |
| Authors: | T. Morin, Ed.. |
| Date: | April 2007 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4834 |
|
This document presents a set of functional requirements for network solutions that allow the deployment of IP multicast within Layer 3(L3) Provider-Provisioned Virtual Private Networks (PPVPNs). It specifies requirements both from the end user and service provider standpoints. It is intended that potential solutions specifying the support of IP multicast within such VPNs will use these requirements as guidelines. |
|
| |
| RFC 4838 | Delay-Tolerant Networking Architecture |
| |
| Authors: | V. Cerf, S. Burleigh, A. Hooke, L. Torgerson, R. Durst, K. Scott, K. Fall, H. Weiss. |
| Date: | April 2007 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4838 |
|
This document describes an architecture for delay-tolerant and disruption-tolerant networks, and is an evolution of the architecture originally designed for the Interplanetary Internet, a communication system envisioned to provide Internet-like services across interplanetary distances in support of deep space exploration. This document describes an architecture that addresses a variety of problems with internetworks having operational and performance characteristics that make conventional (Internet-like) networking approaches either unworkable or impractical. We define a message- oriented overlay that exists above the transport (or other) layers of the networks it interconnects. The document presents a motivation for the architecture, an architectural overview, review of state management required for its operation, and a discussion of application design issues. This document represents the consensus of the IRTF DTN research group and has been widely reviewed by that group. |
|
| |
| RFC 4839 | Media Type Registrations for the Open eBook Publication Structure (OEBPS) Package File (OPF) |
| |
| Authors: | G. Conboy, J. Rivlin, J. Ferraiolo. |
| Date: | April 2007 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4839 |
|
This document serves to register a media type for the Open eBookPublication Structure (OEBPS) Package Files. |
|
| |
| RFC 4840 | Multiple Encapsulation Methods Considered Harmful |
| |
| Authors: | B. Aboba, Ed., E. Davies, D. Thaler. |
| Date: | April 2007 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4840 |
|
This document describes architectural and operational issues that arise from link-layer protocols supporting multiple Internet Protocol encapsulation methods. |
|
| |
| RFC 4844 | The RFC Series and RFC Editor |
| |
|
|
This document describes the framework for an RFC Series and an RFCEditor function that incorporate the principles of organized community involvement and accountability that has become necessary as the Internet technical community has grown, thereby enabling the RFCSeries to continue to fulfill its mandate. |
|
| |
| RFC 4845 | Process for Publication of IAB RFCs |
| |
| Authors: | L. Daigle, Ed., Internet Architecture Board. |
| Date: | July 2007 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4845 |
|
From time to time, the Internet Architecture Board (IAB) publishes documents as Requests for Comments (RFCs). This document defines the process by which those documents are produced, reviewed, and published in the RFC Series. |
|
| |
| RFC 4846 | Independent Submissions to the RFC Editor |
| |
| Authors: | J. Klensin, Ed., D. Thaler, Ed.. |
| Date: | July 2007 |
| Formats: | txt json html |
| Updated by: | RFC 5744 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4846 |
|
There is a long-standing tradition in the Internet community, predating the Internet Engineering Task Force (IETF) by many years, of use of the RFC Series to publish materials that are not rooted in the IETF standards process and its review and approval mechanisms.These documents, known as "Independent Submissions", serve a number of important functions for the Internet community, both inside and outside of the community of active IETF participants. This document discusses the Independent Submission model and some reasons why it is important. It then describes editorial and processing norms that can be used for Independent Submissions as the community goes forward into new relationships between the IETF community and its primary technical publisher. |
|
| |
| RFC 4847 | Framework and Requirements for Layer 1 Virtual Private Networks |
| |
| Authors: | T. Takeda, Ed.. |
| Date: | April 2007 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4847 |
|
This document provides a framework and service level requirements forLayer 1 Virtual Private Networks (L1VPNs). This framework is intended to aid in developing and standardizing protocols and mechanisms to support interoperable L1VPNs.
The document examines motivations for L1VPNs, high level (service level) requirements, and outlines some of the architectural models that might be used to build L1VPNs. |
|
| |
| RFC 4851 | The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST) |
| |
|
|
This document defines the Extensible Authentication Protocol (EAP) based Flexible Authentication via Secure Tunneling (EAP-FAST) protocol. EAP-FAST is an EAP method that enables secure communication between a peer and a server by using the TransportLayer Security (TLS) to establish a mutually authenticated tunnel.Within the tunnel, Type-Length-Value (TLV) objects are used to convey authentication related data between the peer and the EAP server. |
|
| |
| RFC 4852 | IPv6 Enterprise Network Analysis - IP Layer 3 Focus |
| |
| Authors: | J. Bound, Y. Pouffary, S. Klynsma, T. Chown, D. Green. |
| Date: | April 2007 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4852 |
|
This document analyzes the transition to IPv6 in enterprise networks focusing on IP Layer 3. These networks are characterized as having multiple internal links and one or more router connections to one or more Providers, and as being managed by a network operations entity.The analysis focuses on a base set of transition notational networks and requirements expanded from a previous document on enterprise scenarios. Discussion is provided on a focused set of transition analysis required for the enterprise to transition to IPv6, assuming a Dual-IP layer (IPv4 and IPv6) network and node environment within the enterprise. Then, a set of transition mechanisms are recommended for each notational network. |
|
| |
| RFC 4854 | A Uniform Resource Name (URN) Namespace for Extensions to the Extensible Messaging and Presence Protocol (XMPP) |
| |
| Authors: | P. Saint-Andre. |
| Date: | April 2007 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4854 |
|
This document describes a Uniform Resource Name (URN) namespace for uniquely identifying Extensible Markup Language (XML) formats and protocols that provide extensions to the Extensible Messaging andPresence Protocol (XMPP) and are defined in specifications published by the XMPP Standards Foundation (XSF). |
|
| |
| RFC 4858 | Document Shepherding from Working Group Last Call to Publication |
| |
| Authors: | H. Levkowetz, D. Meyer, L. Eggert, A. Mankin. |
| Date: | May 2007 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4858 |
|
This document describes methodologies that have been designed to improve and facilitate IETF document flow processing. It specifies a set of procedures under which a working group chair or secretary serves as the primary Document Shepherd for a document that has been submitted to the IESG for publication. Before this, the AreaDirector responsible for the working group has traditionally filled the shepherding role. |
|
| |
| RFC 4859 | Codepoint Registry for the Flags Field in the Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Session Attribute Object |
| |
| Authors: | A. Farrel. |
| Date: | April 2007 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4859 |
|
This document provides instructions to IANA for the creation of a new codepoint registry for the flags field in the Session Attribute object of the Resource Reservation Protocol Traffic Engineering(RSVP-TE) signaling messages used in Multiprotocol Label Switching(MPLS) and Generalized MPLS (GMPLS) signaling. |
|
| |
| RFC 4864 | Local Network Protection for IPv6 |
| |
| Authors: | G. Van de Velde, T. Hain, R. Droms, B. Carpenter, E. Klein. |
| Date: | May 2007 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4864 |
|
Although there are many perceived benefits to Network AddressTranslation (NAT), its primary benefit of "amplifying" available address space is not needed in IPv6. In addition to NAT's many serious disadvantages, there is a perception that other benefits exist, such as a variety of management and security attributes that could be useful for an Internet Protocol site. IPv6 was designed with the intention of making NAT unnecessary, and this document shows how Local Network Protection (LNP) using IPv6 can provide the same or more benefits without the need for address translation. |
|
| |
| RFC 4876 | A Configuration Profile Schema for Lightweight Directory Access Protocol (LDAP)-Based Agents |
| |
| Authors: | B. Neal-Joslin, Ed., L. Howard, M. Ansari. |
| Date: | May 2007 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4876 |
|
This document consists of two primary components, a schema for agents that make use of the Lightweight Directory Access protocol (LDAP) and a proposed use case of that schema, for distributed configuration of similar directory user agents. A set of attribute types and an object class are proposed. In the proposed use case, directory user agents (DUAs) can use this schema to determine directory data location and access parameters for specific services they support.In addition, in the proposed use case, attribute and object class mapping allows DUAs to reconfigure their expected (default) schema to match that of the end user's environment. This document is intended to be a skeleton for future documents that describe configuration of specific DUA services. |
|
| |
| RFC 4882 | IP Address Location Privacy and Mobile IPv6: Problem Statement |
| |
| Authors: | R. Koodli. |
| Date: | May 2007 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4882 |
|
In this document, we discuss location privacy as applicable to MobileIPv6. We document the concerns arising from revealing a Home Address to an onlooker and from disclosing a Care-of Address to a correspondent. |
|
| |
| RFC 4883 | Benchmarking Terminology for Resource Reservation Capable Routers |
| |
| Authors: | G. Feher, K. Nemeth, A. Korn, I. Cselenyi. |
| Date: | July 2007 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4883 |
|
The primary purpose of this document is to define terminology specific to the benchmarking of resource reservation signaling ofIntegrated Services (IntServ) IP routers. These terms can be used in additional documents that define benchmarking methodologies for routers that support resource reservation or reporting formats for the benchmarking measurements. |
|
| |
| RFC 4885 | Network Mobility Support Terminology |
| |
| Authors: | T. Ernst, H-Y. Lach. |
| Date: | July 2007 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4885 |
|
This document defines a terminology for discussing network mobility(NEMO) issues and solution requirements. |
|
| |
| RFC 4886 | Network Mobility Support Goals and Requirements |
| |
| Authors: | T. Ernst. |
| Date: | July 2007 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4886 |
|
Network mobility arises when a router connecting a network to theInternet dynamically changes its point of attachment to the Internet thereby causing the reachability of the said network to be changed in relation to the fixed Internet topology. Such a type of network is referred to as a mobile network. With appropriate mechanisms, sessions established between nodes in the mobile network and the global Internet can be maintained after the mobile router changes its point of attachment. This document outlines the goals expected from network mobility support and defines the requirements that must be met by the NEMO Basic Support solution. |
|
| |
| RFC 4887 | Network Mobility Home Network Models |
| |
| Authors: | P. Thubert, R. Wakikawa, V. Devarapalli. |
| Date: | July 2007 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4887 |
|
This paper documents some of the usage patterns and the associated issues when deploying a Home Network for Network Mobility (NEMO)- enabled Mobile Routers, conforming to the NEMO Basic Support. The aim here is specifically to provide some examples of organization of the Home Network, as they were discussed in NEMO-related mailing lists. |
|
| |
| RFC 4888 | Network Mobility Route Optimization Problem Statement |
| |
| Authors: | C. Ng, P. Thubert, M. Watari, F. Zhao. |
| Date: | July 2007 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4888 |
|
With current Network Mobility (NEMO) Basic Support, all communications to and from Mobile Network Nodes must go through the bi-directional tunnel established between the Mobile Router and HomeAgent when the mobile network is away. This sub-optimal routing results in various inefficiencies associated with packet delivery, such as increased delay and bottleneck links leading to traffic congestion, which can ultimately disrupt all communications to and from the Mobile Network Nodes. Additionally, with nesting of MobileNetworks, these inefficiencies get compounded, and stalemate conditions may occur in specific dispositions. This document investigates such problems and provides the motivation behind RouteOptimization (RO) for NEMO. |
|
| |
| RFC 4889 | Network Mobility Route Optimization Solution Space Analysis |
| |
| Authors: | C. Ng, F. Zhao, M. Watari, P. Thubert. |
| Date: | July 2007 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4889 |
|
With current Network Mobility (NEMO) Basic Support, all communications to and from Mobile Network Nodes must go through theMobile Router and Home Agent (MRHA) tunnel when the mobile network is away. This results in increased length of packet route and increased packet delay in most cases. To overcome these limitations, one might have to turn to Route Optimization (RO) for NEMO. This memo documents various types of Route Optimization in NEMO and explores the benefits and tradeoffs in different aspects of NEMO RouteOptimization. |
|
| |
| RFC 4890 | Recommendations for Filtering ICMPv6 Messages in Firewalls |
| |
| Authors: | E. Davies, J. Mohacsi. |
| Date: | May 2007 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4890 |
|
In networks supporting IPv6, the Internet Control Message Protocol version 6 (ICMPv6) plays a fundamental role with a large number of functions, and a correspondingly large number of message types and options. ICMPv6 is essential to the functioning of IPv6, but there are a number of security risks associated with uncontrolled forwarding of ICMPv6 messages. Filtering strategies designed for the corresponding protocol, ICMP, in IPv4 networks are not directly applicable, because these strategies are intended to accommodate a useful auxiliary protocol that may not be required for correct functioning.
This document provides some recommendations for ICMPv6 firewall filter configuration that will allow propagation of ICMPv6 messages that are needed to maintain the functioning of the network but drop messages that are potential security risks. |
|
| |
| RFC 4891 | Using IPsec to Secure IPv6-in-IPv4 Tunnels |
| |
| Authors: | R. Graveman, M. Parthasarathy, P. Savola, H. Tschofenig. |
| Date: | May 2007 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4891 |
|
This document gives guidance on securing manually configured IPv6-in-IPv4 tunnels using IPsec in transport mode. No additional protocol extensions are described beyond those available with the IPsec framework. |
|
| |
| RFC 4892 | Requirements for a Mechanism Identifying a Name Server Instance |
| |
| Authors: | S. Woolf, D. Conrad. |
| Date: | June 2007 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4892 |
|
With the increased use of DNS anycast, load balancing, and other mechanisms allowing more than one DNS name server to share a singleIP address, it is sometimes difficult to tell which of a pool of name servers has answered a particular query. A standardized mechanism to determine the identity of a name server responding to a particular query would be useful, particularly as a diagnostic aid for administrators. Existing ad hoc mechanisms for addressing this need have some shortcomings, not the least of which is the lack of prior analysis of exactly how such a mechanism should be designed and deployed. This document describes the existing convention used in some widely deployed implementations of the DNS protocol, including advantages and disadvantages, and discusses some attributes of an improved mechanism. |
|
| |
| RFC 4894 | Use of Hash Algorithms in Internet Key Exchange (IKE) and IPsec |
| |
| Authors: | P. Hoffman. |
| Date: | May 2007 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4894 |
|
This document describes how the IKEv1 (Internet Key Exchange version1), IKEv2, and IPsec protocols use hash functions, and explains the level of vulnerability of these protocols to the reduced collision resistance of the MD5 and SHA-1 hash algorithms. |
|
| |
| RFC 4902 | Integrity, Privacy, and Security in Open Pluggable Edge Services (OPES) for SMTP |
| |
| Authors: | M. Stecher. |
| Date: | May 2007 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4902 |
|
The Open Pluggable Edge Services (OPES) framework is application agnostic. Application-specific adaptations extend that framework.Previous work has focused on HTTP and work for SMTP is in progress.These protocols differ fundamentally in the way data flows, and it turns out that existing OPES requirements and IAB considerations forOPES need to be reviewed with regards to how well they fit for SMTP adaptation. This document analyzes aspects about the integrity ofSMTP and mail message adaptation by OPES systems and about privacy and security issues when the OPES framework is adapted to SMTP. It also lists requirements that must be considered when creating the"SMTP adaptation with OPES" document.
The intent of this document is to capture this information before the current OPES working group shuts down. This is to provide input for subsequent working groups or individual contributors that may pick up the OPES/SMTP work at a later date. |
|
| |
| RFC 4903 | Multi-Link Subnet Issues |
| |
| Authors: | D. Thaler. |
| Date: | June 2007 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4903 |
|
There have been several proposals around the notion that a subnet may span multiple links connected by routers. This memo documents the issues and potential problems that have been raised with such an approach. |
|
| |
| RFC 4907 | Architectural Implications of Link Indications |
| |
| Authors: | B. Aboba, Ed.. |
| Date: | June 2007 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4907 |
|
A link indication represents information provided by the link layer to higher layers regarding the state of the link. This document describes the role of link indications within the Internet architecture. While the judicious use of link indications can provide performance benefits, inappropriate use can degrade both robustness and performance. This document summarizes current proposals, describes the architectural issues, and provides examples of appropriate and inappropriate uses of link indications. |
|
| |
| RFC 4909 | Multimedia Internet KEYing (MIKEY) General Extension Payload for Open Mobile Alliance BCAST LTKM/STKM Transport |
| |
|
|
This document specifies a new Multimedia Internet KEYing (MIKEY)General Extension payload (RFC 3830) to transport the short-term key message (STKM) and long-term key message (LTKM) payloads defined in the Open Mobile Alliance's (OMA) Browser and Content (BAC) Broadcast(BCAST) group's Service and Content protection specification. |
|
| |
| RFC 4919 | IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals |
| |
| Authors: | N. Kushalnagar, G. Montenegro, C. Schumacher. |
| Date: | August 2007 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4919 |
|
This document describes the assumptions, problem statement, and goals for transmitting IP over IEEE 802.15.4 networks. The set of goals enumerated in this document form an initial set only. |
|
| |
| RFC 4923 | Quality of Service (QoS) Signaling in a Nested Virtual Private Network |
| |
| Authors: | F. Baker, P. Bose. |
| Date: | August 2007 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4923 |
|
Some networks require communication between an interior and exterior portion of a Virtual Private Network (VPN) or through a concatenation of such networks resulting in a nested VPN, but have sensitivities about what information is communicated across the boundary, especially while providing quality of service to communications with different precedence. This note seeks to outline the issues and the nature of the proposed solutions based on the framework forIntegrated Services operation over Diffserv networks as described inRFC 2998. |
|
| |
| RFC 4924 | Reflections on Internet Transparency |
| |
| Authors: | B. Aboba, Ed., E. Davies. |
| Date: | July 2007 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4924 |
|
This document provides a review of previous IAB statements onInternet transparency, as well a discussion of new transparency issues. Far from having lessened in relevance, technical implications of intentionally or inadvertently impeding network transparency play a critical role in the Internet's ability to support innovation and global communication. This document provides some specific illustrations of those potential impacts. |
|
| |
| RFC 4925 | Softwire Problem Statement |
| |
| Authors: | X. Li, Ed., S. Dawkins, Ed., D. Ward, Ed., A. Durand, Ed.. |
| Date: | July 2007 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4925 |
|
This document captures the problem statement for the SoftwiresWorking Group, which is developing standards for the discovery, control, and encapsulation methods for connecting IPv4 networks across IPv6-only networks as well as IPv6 networks across IPv4-only networks. The standards will encourage multiple, inter-operable vendor implementations by identifying, and extending where necessary, existing standard protocols to resolve a selected set of "IPv4/IPv6" and "IPv6/IPv4" transition problems. This document describes the specific problems ("Hubs and Spokes" and "Mesh") that will be solved by the standards developed by the Softwires Working Group. Some requirements (and non-requirements) are also identified to better describe the specific problem scope. |
|
| |
| RFC 4926 | A URN Namespace for GEANT |
| |
| Authors: | T. Kalin, M. Molina. |
| Date: | July 2007 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4926 |
|
This document describes a proposed URN (Uniform Resource Name) namespace that would be managed by DANTE, representing EuropeanResearch and academic networks, for naming persistent resources defined by GEANT, the Consortium of European Academic and ResearchNetworks, its projects, activities, working groups, and other designated subordinates. |
|
| |
| RFC 4927 | Path Computation Element Communication Protocol (PCECP) Specific Requirements for Inter-Area MPLS and GMPLS Traffic Engineering |
| |
| Authors: | J.-L. Le Roux, Ed.. |
| Date: | June 2007 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4927 |
|
For scalability purposes, a network may comprise multiple InteriorGateway Protocol (IGP) areas. An inter-area Traffic Engineered LabelSwitched Path (TE-LSP) is an LSP that transits through at least twoIGP areas. In a multi-area network, topology visibility remains local to a given area, and a head-end Label Switching Router (LSR) cannot compute an inter-area shortest constrained path. One key application of the Path Computation Element (PCE)-based architecture is the computation of inter-area TE-LSP paths. The PCE CommunicationProtocol (PCECP) is used to communicate computation requests fromPath Computation Clients (PCCs) to PCEs, and to return computed paths in responses. This document lists a detailed set of PCECP-specific requirements for support of inter-area TE-LSP path computation. It complements the generic requirements for a PCE CommunicationProtocol. |
|
| |
| RFC 4937 | IANA Considerations for PPP over Ethernet (PPPoE) |
| |
| Authors: | P. Arberg, V. Mammoliti. |
| Date: | June 2007 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4937 |
|
This document describes the IANA considerations for the PPP overEthernet (PPPoE) protocol. |
|
| |
| RFC 4938 | PPP Over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics |
| |
|
|
This document extends the Point-to-Point over Ethernet (PPPoE)Protocol with a credit-based flow control mechanism and Link QualityMetric report. This optional extension should improve the performance of PPPoE over media with variable bandwidth and limited buffering, such as mobile radio links. |
|
| |
| RFC 4942 | IPv6 Transition/Co-existence Security Considerations |
| |
| Authors: | E. Davies, S. Krishnan, P. Savola. |
| Date: | September 2007 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4942 |
|
The transition from a pure IPv4 network to a network where IPv4 andIPv6 coexist brings a number of extra security considerations that need to be taken into account when deploying IPv6 and operating the dual-protocol network and the associated transition mechanisms. This document attempts to give an overview of the various issues grouped into three categories: o issues due to the IPv6 protocol itself, o issues due to transition mechanisms, and o issues due to IPv6 deployment. |
|
| |
| RFC 4943 | IPv6 Neighbor Discovery On-Link Assumption Considered Harmful |
| |
| Authors: | S. Roy, A. Durand, J. Paugh. |
| Date: | September 2007 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4943 |
|
This document describes the historical and background information behind the removal of the "on-link assumption" from the conceptual host sending algorithm defined in Neighbor Discovery for IP Version 6(IPv6). According to the algorithm as originally described, when a host's default router list is empty, the host assumes that all destinations are on-link. This is particularly problematic withIPv6-capable nodes that do not have off-link IPv6 connectivity (e.g., no default router). This document describes how making this assumption causes problems and how these problems outweigh the benefits of this part of the conceptual sending algorithm. |
|
| |
| RFC 4947 | Address Resolution Mechanisms for IP Datagrams over MPEG-2 Networks |
| |
| Authors: | G. Fairhurst, M. Montpetit. |
| Date: | July 2007 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4947 |
|
This document describes the process of binding/associating IPv4/IPv6 addresses with MPEG-2 Transport Streams (TS). This procedure is known as Address Resolution (AR) or Neighbor Discovery (ND). Such address resolution complements the higher-layer resource discovery tools that are used to advertise IP sessions.
In MPEG-2 Networks, an IP address must be associated with a Packet ID(PID) value and a specific Transmission Multiplex. This document reviews current methods appropriate to a range of technologies (such as DVB (Digital Video Broadcasting), ATSC (Advanced TelevisionSystems Committee), DOCSIS (Data-Over-Cable Service InterfaceSpecifications), and variants). It also describes the interaction with well-known protocols for address management including DHCP, ARP, and the ND protocol. |
|
| |
| RFC 4948 | Report from the IAB workshop on Unwanted Traffic March 9-10, 2006 |
| |
| Authors: | L. Andersson, E. Davies, L. Zhang. |
| Date: | August 2007 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4948 |
|
This document reports the outcome of a workshop held by the InternetArchitecture Board (IAB) on Unwanted Internet Traffic. The workshop was held on March 9-10, 2006 at USC/ISI in Marina del Rey, CA, USA.The primary goal of the workshop was to foster interchange between the operator, standards, and research communities on the topic of unwanted traffic, as manifested in, for example, Distributed Denial of Service (DDoS) attacks, spam, and phishing, to gain understandings on the ultimate sources of these unwanted traffic, and to assess their impact and the effectiveness of existing solutions. It was also a goal of the workshop to identify engineering and research topics that could be undertaken by the IAB, the IETF, the IRTF, and the network research and development community at large to develop effective countermeasures against the unwanted traffic. |
|
| |
| RFC 4949 | Internet Security Glossary, Version 2 |
| |
|
|
This Glossary provides definitions, abbreviations, and explanations of terminology for information system security. The 334 pages of entries offer recommendations to improve the comprehensibility of written material that is generated in the Internet Standards Process(RFC 2026). The recommendations follow the principles that such writing should (a) use the same term or definition whenever the same concept is mentioned; (b) use terms in their plainest, dictionary sense; (c) use terms that are already well-established in open publications; and (d) avoid terms that either favor a particular vendor or favor a particular technology or mechanism over other, competing techniques that already exist or could be developed. |
|
| |
| RFC 4952 | Overview and Framework for Internationalized Email |
| |
|
|
Full use of electronic mail throughout the world requires that people be able to use their own names, written correctly in their own languages and scripts, as mailbox names in email addresses. This document introduces a series of specifications that define mechanisms and protocol extensions needed to fully support internationalized email addresses. These changes include an SMTP extension and extension of email header syntax to accommodate UTF-8 data. The document set also includes discussion of key assumptions and issues in deploying fully internationalized email. |
|
| |
| RFC 4953 | Defending TCP Against Spoofing Attacks |
| |
| Authors: | J. Touch. |
| Date: | July 2007 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4953 |
|
Recent analysis of potential attacks on core Internet infrastructure indicates an increased vulnerability of TCP connections to spurious resets (RSTs), sent with forged IP source addresses (spoofing). TCP has always been susceptible to such RST spoofing attacks, which were indirectly protected by checking that the RST sequence number was inside the current receive window, as well as via the obfuscation ofTCP endpoint and port numbers. For pairs of well-known endpoints often over predictable port pairs, such as BGP or between web servers and well-known large-scale caches, increases in the path bandwidth- delay product of a connection have sufficiently increased the receive window space that off-path third parties can brute-force generate a viable RST sequence number. The susceptibility to attack increases with the square of the bandwidth, and thus presents a significant vulnerability for recent high-speed networks. This document addresses this vulnerability, discussing proposed solutions at the transport level and their inherent challenges, as well as existing network level solutions and the feasibility of their deployment.This document focuses on vulnerabilities due to spoofed TCP segments, and includes a discussion of related ICMP spoofing attacks on TCP connections. |
|
| |
| RFC 4957 | Link-Layer Event Notifications for Detecting Network Attachments |
| |
| Authors: | S. Krishnan, Ed., N. Montavont, E. Njedjou, S. Veerepalli, A. Yegin, Ed.. |
| Date: | August 2007 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4957 |
|
Certain network access technologies are capable of providing various types of link-layer status information to IP. Link-layer event notifications can help IP expeditiously detect configuration changes.This document provides a non-exhaustive catalogue of information available from well-known access technologies. |
|
| |
| RFC 4958 | A Framework for Supporting Emergency Telecommunications Services (ETS) within a Single Administrative Domain |
| |
| Authors: | K. Carlberg. |
| Date: | July 2007 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4958 |
|
This document presents a framework discussing the role of various protocols and mechanisms that could be considered candidates for supporting Emergency Telecommunication Services (ETS) within a single administrative domain. Comments about their potential usage as well as their current deployment are provided to the reader. Specific solutions are not presented. |
|
| |
| RFC 4963 | IPv4 Reassembly Errors at High Data Rates |
| |
| Authors: | J. Heffner, M. Mathis, B. Chandler. |
| Date: | July 2007 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4963 |
|
IPv4 fragmentation is not sufficiently robust for use under some conditions in today's Internet. At high data rates, the 16-bit IP identification field is not large enough to prevent frequent incorrectly assembled IP fragments, and the TCP and UDP checksums are insufficient to prevent the resulting corrupted datagrams from being delivered to higher protocol layers. This note describes some easily reproduced experiments demonstrating the problem, and discusses some of the operational implications of these observations. |
|
| |
| RFC 4964 | The P-Answer-State Header Extension to the Session Initiation Protocol for the Open Mobile Alliance Push to Talk over Cellular |
| |
| Authors: | A. Allen, Ed., J. Holm, T. Hallin. |
| Date: | September 2007 |
| Formats: | txt json html |
| Updated by: | RFC 8996 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4964 |
|
This document describes a private Session Initiation Protocol (SIP) header (P-header) used by the Open Mobile Alliance (OMA) for Push to talk over Cellular (PoC) along with its applicability, which is limited to the OMA PoC application. The P-Answer-State header is used for indicating the answering mode of the handset, which is particular to the PoC application. |
|
| |
| RFC 4965 | CableLabs - IETF Standardization Collaboration |
| |
| Authors: | J-F. Mule, W. Townsley. |
| Date: | September 2007 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4965 |
|
This document describes the collaboration and liaison relationship between the Internet Engineering Task Force (IETF) and the CableTelevision Laboratories, Inc. (CableLabs). |
|
| |
| RFC 4966 | Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status |
| |
|
|
This document discusses issues with the specific form of IPv6-IPv4 protocol translation mechanism implemented by the Network AddressTranslator - Protocol Translator (NAT-PT) defined in RFC 2766. These issues are sufficiently serious that recommending RFC 2766 as a general purpose transition mechanism is no longer desirable, and this document recommends that the IETF should reclassify RFC 2766 fromProposed Standard to Historic status. |
|
| |
| RFC 4968 | Analysis of IPv6 Link Models for 802.16 Based Networks |
| |
| Authors: | S. Madanapalli, Ed.. |
| Date: | August 2007 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4968 |
|
This document provides different IPv6 link models that are suitable for IEEE 802.16 based networks and provides analysis of various considerations for each link model and the applicability of each link model under different deployment scenarios. This document is the result of a design team (DT) that was formed to analyze the IPv6 link models for IEEE 802.16 based networks. |
|
| |
| RFC 4977 | Problem Statement: Dual Stack Mobility |
| |
| Authors: | G. Tsirtsis, H. Soliman. |
| Date: | August 2007 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4977 |
|
This document discusses the issues associated with mobility management for dual stack mobile nodes. Currently, two mobility management protocols are defined for IPv4 and IPv6. Deploying both in a dual stack mobile node introduces a number of problems.Deployment and operational issues motivate the use of a single mobility management protocol. This document discusses such motivations. The document also discusses requirements for the MobileIPv4 (MIPv4) and Mobile IPv6 (MIPv6) protocol so that they can support mobility management for a dual stack node. |
|
| |
| RFC 4980 | Analysis of Multihoming in Network Mobility Support |
| |
| Authors: | C. Ng, T. Ernst, E. Paik, M. Bagnulo. |
| Date: | October 2007 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4980 |
|
This document is an analysis of multihoming in the context of network mobility (NEMO) in IPv6. As there are many situations in which mobile networks may be multihomed, a taxonomy is proposed to classify the possible configurations. The possible deployment scenarios of multihomed mobile networks are described together with the associated issues when network mobility is supported by RFC 3963 (NEMO BasicSupport). Recommendations are offered on how to address these issues. |
|
| |
| RFC 4981 | Survey of Research towards Robust Peer-to-Peer Networks: Search Methods |
| |
| Authors: | J. Risson, T. Moors. |
| Date: | September 2007 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4981 |
|
The pace of research on peer-to-peer (P2P) networking in the last five years warrants a critical survey. P2P has the makings of a disruptive technology -- it can aggregate enormous storage and processing resources while minimizing entry and scaling costs.
Failures are common amongst massive numbers of distributed peers, though the impact of individual failures may be less than in conventional architectures. Thus, the key to realizing P2P's potential in applications other than casual file sharing is robustness.
P2P search methods are first couched within an overall P2P taxonomy.P2P indexes for simple key lookup are assessed, including those based on Plaxton trees, rings, tori, butterflies, de Bruijn graphs, and skip graphs. Similarly, P2P indexes for keyword lookup, information retrieval and data management are explored. Finally, early efforts to optimize range, multi-attribute, join, and aggregation queries over P2P indexes are reviewed. Insofar as they are available in the primary literature, robustness mechanisms and metrics are highlighted throughout. However, the low-level mechanisms that most affect robustness are not well isolated in the literature. Recommendations are given for future research. |
|
| |
| RFC 4984 | Report from the IAB Workshop on Routing and Addressing |
| |
| Authors: | D. Meyer, Ed., L. Zhang, Ed., K. Fall, Ed.. |
| Date: | September 2007 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4984 |
|
This document reports the outcome of the Routing and AddressingWorkshop that was held by the Internet Architecture Board (IAB) onOctober 18-19, 2006, in Amsterdam, Netherlands. The primary goal of the workshop was to develop a shared understanding of the problems that the large backbone operators are facing regarding the scalability of today's Internet routing system. The key workshop findings include an analysis of the major factors that are driving routing table growth, constraints in router technology, and the limitations of today's Internet addressing architecture. It is hoped that these findings will serve as input to the IETF community and help identify next steps towards effective solutions.
Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and not of the IAB. Furthermore, note that work on issues related to this workshop report is continuing, and this document does not intend to reflect the increased understanding of issues nor to discuss the range of potential solutions that may be the outcome of this ongoing work. |
|
| |
| RFC 4986 | Requirements Related to DNS Security (DNSSEC) Trust Anchor Rollover |
| |
| Authors: | H. Eland, R. Mundy, S. Crocker, S. Krishnaswamy. |
| Date: | August 2007 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4986 |
|
Every DNS security-aware resolver must have at least one Trust Anchor to use as the basis for validating responses from DNS signed zones.For various reasons, most DNS security-aware resolvers are expected to have several Trust Anchors. For some operations, manual monitoring and updating of Trust Anchors may be feasible, but many operations will require automated methods for updating Trust Anchors in their security-aware resolvers. This document identifies the requirements that must be met by an automated DNS Trust Anchor rollover solution for security-aware DNS resolvers. |
|
| |
| RFC 4987 | TCP SYN Flooding Attacks and Common Mitigations |
| |
| Authors: | W. Eddy. |
| Date: | August 2007 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4987 |
|
This document describes TCP SYN flooding attacks, which have been well-known to the community for several years. Various countermeasures against these attacks, and the trade-offs of each, are described. This document archives explanations of the attack and common defense techniques for the benefit of TCP implementers and administrators of TCP servers or networks, but does not make any standards-level recommendations. |
|
| |
| RFC 4990 | Use of Addresses in Generalized Multiprotocol Label Switching (GMPLS) Networks |
| |
| Authors: | K. Shiomoto, R. Papneja, R. Rabbat. |
| Date: | September 2007 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 4990 |
|
This document clarifies the use of addresses in GeneralizedMultiprotocol Label Switching (GMPLS) networks. The aim is to facilitate interworking of GMPLS-capable Label Switching Routers(LSRs). The document is based on experience gained in implementation, interoperability testing, and deployment.
The document describes how to interpret address and identifier fields within GMPLS protocols, and how to choose which addresses to set in those fields for specific control plane usage models. It also discusses how to handle IPv6 sources and destinations in the MPLS andGMPLS Traffic Engineering (TE) Management Information Base (MIB) modules.
This document does not define new procedures or processes. Whenever this document makes requirements statements or recommendations, these are taken from normative text in the referenced RFCs. |
|
| |
| RFC 5002 | The Session Initiation Protocol (SIP) P-Profile-Key Private Header (P-Header) |
| |
|
|
This document specifies the SIP P-Profile-Key P-header. This header field is used in the 3rd-Generation Partnership Project (3GPP) IMS(IP Multimedia Subsystem) to provide SIP registrars and SIP proxy servers with the key of the profile corresponding to the destinationSIP URI of a particular SIP request. |
|
| |
| RFC 5009 | Private Header (P-Header) Extension to the Session Initiation Protocol (SIP) for Authorization of Early Media |
| |
| Authors: | R. Ejzak. |
| Date: | September 2007 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5009 |
|
This document describes a private Session Initiation Protocol (SIP) header field (P-header) to be used by the European TelecommunicationsStandards Institute (ETSI) Telecommunications and Internet-convergedServices and Protocols for Advanced Networks (TISPAN) for the purpose of authorizing early media flows in Third Generation PartnershipProject (3GPP) IP Multimedia Subsystems (IMS). This header field is useful in any SIP network that is interconnected with other SIP networks and needs to control the flow of media in the early dialog state. |
|
| |
| RFC 5012 | Requirements for Emergency Context Resolution with Internet Technologies |
| |
| Authors: | H. Schulzrinne, R. Marshall, Ed.. |
| Date: | January 2008 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5012 |
|
This document defines terminology and enumerates requirements for the context resolution of emergency calls placed by the public using voice-over-IP (VoIP) and general Internet multimedia systems, whereInternet protocols are used end to end. |
|
| |
| RFC 5013 | The Dublin Core Metadata Element Set |
| |
|
|
This document defines fifteen metadata elements for resource description in a cross-disciplinary information environment. |
|
| |
| RFC 5014 | IPv6 Socket API for Source Address Selection |
| |
| Authors: | E. Nordmark, S. Chakrabarti, J. Laganier. |
| Date: | September 2007 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5014 |
|
The IPv6 default address selection document (RFC 3484) describes the rules for selecting source and destination IPv6 addresses, and indicates that applications should be able to reverse the sense of some of the address selection rules through some unspecified API.However, no such socket API exists in the basic (RFC 3493) or advanced (RFC 3542) IPv6 socket API documents. This document fills that gap partially by specifying new socket-level options for source address selection and flags for the getaddrinfo() API to specify address selection based on the source address preference in accordance with the socket-level options that modify the default source address selection algorithm. The socket API described in this document will be particularly useful for IPv6 applications that want to choose between temporary and public addresses, and for Mobile IPv6 aware applications that want to use the care-of address for communication. It also specifies socket options and flags for selecting Cryptographically Generated Address (CGA) or non-CGA source addresses. |
|
| |
| RFC 5016 | Requirements for a DomainKeys Identified Mail (DKIM) Signing Practices Protocol |
| |
| Authors: | M. Thomas. |
| Date: | October 2007 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5016 |
|
DomainKeys Identified Mail (DKIM) provides a cryptographic mechanism for domains to assert responsibility for the messages they handle. A related mechanism will allow an administrator to publish various statements about their DKIM signing practices. This document defines requirements for this mechanism, distinguishing between those that must be satisfied (MUST), and those that are highly desirable(SHOULD). |
|
| |
| RFC 5022 | Media Server Control Markup Language (MSCML) and Protocol |
| |
| Authors: | J. Van Dyke, E. Burger, Ed., A. Spitzer. |
| Date: | September 2007 |
| Formats: | txt json html |
| Obsoletes: | RFC 4722 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5022 |
|
Media Server Control Markup Language (MSCML) is a markup language used in conjunction with SIP to provide advanced conferencing and interactive voice response (IVR) functions. MSCML presents an application-level control model, as opposed to device-level control models. One use of this protocol is for communications between a conference focus and mixer in the IETF SIP Conferencing Framework. |
|
| |
| RFC 5024 | 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 MessageSyntax, and provides signed receipts for the acknowledgement of received files.
The protocol supports both direct peer-to-peer communication and indirect communication via a Value Added Network and may be used withTCP/IP, X.25, and ISDN-based networks. |
|
| |
| RFC 5030 | Mobile IPv4 RADIUS Requirements |
| |
| Authors: | M. Nakhjiri, Ed., K. Chowdhury, A. Lior, K. Leung. |
| Date: | October 2007 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5030 |
|
This document provides an applicability statement as well as a scope definition for specifying Remote Authentication Dial-In User Service(RADIUS) extensions to support Mobile IPv4. The goal is to allow specification of RADIUS attributes to assist the Mobile IPv4 signaling procedures. |
|
| |
| RFC 5037 | Experience with the Label Distribution Protocol (LDP) |
| |
| Authors: | L. Andersson, Ed., I. Minei, Ed., B. Thomas, Ed.. |
| Date: | October 2007 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5037 |
|
The purpose of this memo is to document how some of the requirements specified in RFC 1264 for advancing protocols developed by working groups within the IETF Routing Area to Draft Standard have been satisfied by LDP (Label Distribution Protocol). Specifically, this report documents operational experience with LDP, requirement 5 of section 5.0 in RFC 1264. |
|
| |
| RFC 5038 | The Label Distribution Protocol (LDP) Implementation Survey Results |
| |
| Authors: | B. Thomas, L. Andersson. |
| Date: | October 2007 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5038 |
|
Multiprotocol Label Switching (MPLS), described in RFC 3031, is a method for forwarding packets that uses short, fixed-length values carried by packets, called labels, to determine packet next hops. A fundamental concept in MPLS is that two Label Switching Routers(LSRs) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using a set of procedures, called a Label DistributionProtocol (as described in RFC 3036) , by which one LSR informs another of label bindings it has made. One such protocol, calledLDP, is used by LSRs to distribute labels to support MPLS forwarding along normally routed paths. This document reports on a survey ofLDP implementations conducted in August 2002 as part of the process of advancing LDP from Proposed to Draft Standard. |
|
| |
| RFC 5039 | The Session Initiation Protocol (SIP) and Spam |
| |
| Authors: | J. Rosenberg, C. Jennings. |
| Date: | January 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5039 |
|
Spam, defined as the transmission of bulk unsolicited messages, has plagued Internet email. Unfortunately, spam is not limited to email.It can affect any system that enables user-to-user communications.The Session Initiation Protocol (SIP) defines a system for user-to- user multimedia communications. Therefore, it is susceptible to spam, just as email is. In this document, we analyze the problem of spam in SIP. We first identify the ways in which the problem is the same and the ways in which it is different from email. We then examine the various possible solutions that have been discussed for email and consider their applicability to SIP. |
|
| |
| RFC 5045 | Applicability of Remote Direct Memory Access Protocol (RDMA) and Direct Data Placement (DDP) |
| |
| Authors: | C. Bestler, Ed., L. Coene. |
| Date: | October 2007 |
| Formats: | txt json html |
| Updated by: | RFC 7146 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5045 |
|
This document describes the applicability of Remote Direct MemoryAccess Protocol (RDMAP) and the Direct Data Placement Protocol (DDP).It compares and contrasts the different transport options over IP that DDP can use, provides guidance to ULP developers on choosing between available transports and/or how to be indifferent to the specific transport layer used, compares use of DDP with direct use of the supporting transports, and compares DDP over IP transports with non-IP transports that support RDMA functionality. |
|
| |
| RFC 5047 | DA: Datamover Architecture for the Internet Small Computer System Interface (iSCSI) |
| |
| Authors: | M. Chadalapaka, J. Hufferd, J. Satran, H. Shah. |
| Date: | October 2007 |
| Formats: | txt html json |
| Updated by: | RFC 7146 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5047 |
|
The Internet Small Computer System Interface (iSCSI) is a SCSI transport protocol that maps the SCSI family of application protocols onto TCP/IP. Datamover Architecture for iSCSI (DA) defines an abstract model in which the movement of data between iSCSI end nodes is logically separated from the rest of the iSCSI protocol in order to allow iSCSI to adapt to innovations available in new IP transports. While DA defines the architectural functions required of the class of Datamover protocols, it does not define any specificDatamover protocols. Each such Datamover protocol, defined in a separate document, provides a reliable transport for all iSCSI PDUs, but actually moves the data required for certain iSCSI PDUs without involving the remote iSCSI layer itself. This document begins with an introduction of a few new abstractions, defines a layered architecture for iSCSI and Datamover protocols, and then models the interactions within an iSCSI end node between the iSCSI layer and theDatamover layer that happen in order to transparently perform remote data movement within an IP fabric. It is intended that this definition will help map iSCSI to generic Remote Direct Memory Access(RDMA)-capable IP fabrics in the future comprising TCP, the StreamControl Transmission Protocol (SCTP), and possibly other underlying network transport layers, such as InfiniBand. |
|
| |
| RFC 5054 | Using the Secure Remote Password (SRP) Protocol for TLS Authentication |
| |
| Authors: | D. Taylor, T. Wu, N. Mavrogiannopoulos, T. Perrin. |
| Date: | November 2007 |
| Formats: | txt json html |
| Updated by: | RFC 8996 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5054 |
|
This memo presents a technique for using the Secure Remote Password protocol as an authentication method for the Transport Layer Security protocol. |
|
| |
| RFC 5057 | Multiple Dialog Usages in the Session Initiation Protocol |
| |
| Authors: | R. Sparks. |
| Date: | November 2007 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5057 |
|
Several methods in the Session Initiation Protocol (SIP) can create an association between endpoints known as a dialog. Some of these methods can also create a different, but related, association within an existing dialog. These multiple associations, or dialog usages, require carefully coordinated processing as they have independent life-cycles, but share common dialog state. Processing multiple dialog usages correctly is not completely understood. What is understood is difficult to implement.
This memo argues that multiple dialog usages should be avoided. It discusses alternatives to their use and clarifies essential behavior for elements that cannot currently avoid them.
This is an informative document and makes no normative statements of any kind. |
|
| |
| RFC 5062 | Security Attacks Found Against the Stream Control Transmission Protocol (SCTP) and Current Countermeasures |
| |
| Authors: | R. Stewart, M. Tuexen, G. Camarillo. |
| Date: | September 2007 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5062 |
|
This document describes certain security threats to SCTP. It also describes ways to mitigate these threats, in particular by using techniques from the SCTP Specification Errata and Issues memo (RFC4460). These techniques are included in RFC 4960, which obsoletesRFC 2960. It is hoped that this information will provide some useful background information for many of the newest requirements spelled out in the SCTP Specification Errata and Issues and included in RFC4960. |
|
| |
| RFC 5067 | Infrastructure ENUM Requirements |
| |
| Authors: | S. Lind, P. Pfautz. |
| Date: | November 2007 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5067 |
|
This document provides requirements for "infrastructure" or "carrier"ENUM (E.164 Number Mapping), defined as the use of RFC 3761 technology to facilitate interconnection of networks for E.164 number addressed services, in particular but not restricted to VoIP (Voice over IP.) |
|
| |
| RFC 5069 | Security Threats and Requirements for Emergency Call Marking and Mapping |
| |
| Authors: | T. Taylor, Ed., H. Tschofenig, H. Schulzrinne, M. Shanmugam. |
| Date: | January 2008 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5069 |
|
This document reviews the security threats associated with the marking of signalling messages to indicate that they are related to an emergency, and with the process of mapping locations to UniversalResource Identifiers (URIs) that point to Public Safety AnsweringPoints (PSAPs). This mapping occurs as part of the process of routing emergency calls through the IP network.
Based on the identified threats, this document establishes a set of security requirements for the mapping protocol and for the handling of emergency-marked calls. |
|
| |
| RFC 5071 | Dynamic Host Configuration Protocol Options Used by PXELINUX |
| |
| Authors: | D. Hankins. |
| Date: | December 2007 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5071 |
|
This document describes the use by PXELINUX of some DHCP Option Codes numbering from 208-211. |
|
| |
| RFC 5078 | IAB and IESG Selection, Confirmation, and Recall Process: Revision of the Nominating and Recall Committees Timeline |
| |
|
|
RFC 3777 defines the Nominations and Recall Committee's (NomCom's) operation, and includes a sample timeline for major steps in theNomCom process that meets the minimum normative requirements for the process. Recent NomComs have been scheduling based on the sample timeline, and the chairs of the last three NomComs -- Danny McPherson(2004-2005), Ralph Droms (2005-2006), and Andrew Lange (2006-2007) -- have all reported that this timeline is very aggressive and suggested starting earlier. This document restructures the sample timeline, but makes no normative process changes. |
|
| |
| RFC 5086 | Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation Service over Packet Switched Network (CESoPSN) |
| |
| Authors: | A. Vainshtein, Ed., I. Sasson, E. Metz, T. Frost, P. Pate. |
| Date: | December 2007 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5086 |
|
This document describes a method for encapsulating structured (NxDS0)Time Division Multiplexed (TDM) signals as pseudowires over packet- switching networks (PSNs). In this regard, it complements similar work for structure-agnostic emulation of TDM bit-streams (see RFC4553). |
|
| |
| RFC 5087 | Time Division Multiplexing over IP (TDMoIP) |
| |
| Authors: | Y(J). Stein, R. Shashoua, R. Insler, M. Anavi. |
| Date: | December 2007 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5087 |
|
Time Division Multiplexing over IP (TDMoIP) is a structure-aware method for transporting Time Division Multiplexed (TDM) signals using pseudowires (PWs). Being structure-aware, TDMoIP is able to ensureTDM structure integrity, and thus withstand network degradations better than structure-agnostic transport. Structure-aware methods can distinguish individual channels, enabling packet loss concealment and bandwidth conservation. Accesibility of TDM signaling facilitates mechanisms that exploit or manipulate signaling. |
|
| |
| RFC 5091 | Identity-Based Cryptography Standard (IBCS) #1: Supersingular Curve Implementations of the BF and BB1 Cryptosystems |
| |
|
|
This document describes the algorithms that implement Boneh-Franklin(BF) and Boneh-Boyen (BB1) Identity-based Encryption. This document is in part based on IBCS #1 v2 of Voltage Security's Identity-basedCryptography Standards (IBCS) documents, from which some irrelevant sections have been removed to create the content of this document. |
|
| |
| RFC 5093 | BT's eXtended Network Quality RTP Control Protocol Extended Reports (RTCP XR XNQ) |
| |
| Authors: | G. Hunt. |
| Date: | December 2007 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5093 |
|
This document describes an RTCP XR report block, which reports packet transport parameters. The report block was developed by BT for pre- standards use in BT's next-generation network. This document has been produced to describe the report block in sufficient detail to register the block type with IANA in accordance with theSpecification Required policy of RFC 3611. This specification does not standardise the new report block for use outside BT's network. |
|
| |
| RFC 5110 | Overview of the Internet Multicast Routing Architecture |
| |
| Authors: | P. Savola. |
| Date: | January 2008 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5110 |
|
This document describes multicast routing architectures that are currently deployed on the Internet. This document briefly describes those protocols and references their specifications.
This memo also reclassifies several older RFCs to Historic. TheseRFCs describe multicast routing protocols that were never widely deployed or have fallen into disuse. |
|
| |
| RFC 5113 | Network Discovery and Selection Problem |
| |
| Authors: | J. Arkko, B. Aboba, J. Korhonen, Ed., F. Bari. |
| Date: | January 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5113 |
|
When multiple access networks are available, users may have difficulty in selecting which network to connect to and how to authenticate with that network. This document defines the network discovery and selection problem, dividing it into multiple sub- problems. Some constraints on potential solutions are outlined, and the limitations of several solutions (including existing ones) are discussed. |
|
| |
| RFC 5114 | Additional Diffie-Hellman Groups for Use with IETF Standards |
| |
| Authors: | M. Lepinski, S. Kent. |
| Date: | January 2008 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5114 |
|
This document describes eight Diffie-Hellman groups that can be used in conjunction with IETF protocols to provide security for Internet communications. The groups allow implementers to use the same groups with a variety of security protocols, e.g., SMIME, Secure SHell(SSH), Transport Layer Security (TLS), and Internet Key Exchange(IKE).
All of these groups comply in form and structure with relevant standards from ISO, ANSI, NIST, and the IEEE. These groups are compatible with all IETF standards that make use of Diffie-Hellman orElliptic Curve Diffie-Hellman cryptography.
These groups and the associated test data are defined by NIST on their web site [EX80056A], but have not yet (as of this writing) been published in a formal NIST document. Publication of these groups and associated test data, as well as describing how to use Diffie-Hellman and Elliptic Curve Diffie-Hellman for key agreement in all of the protocols cited below, in one RFC, will facilitate development of interoperable implementations and support the Federal InformationProcessing Standard (FIPS) validation of implementations that make use of these groups. |
|
| |
| RFC 5117 | RTP Topologies |
| |
| Authors: | M. Westerlund, S. Wenger. |
| Date: | January 2008 |
| Formats: | txt html json |
| Obsoleted by: | RFC 7667 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5117 |
|
This document discusses multi-endpoint topologies used in Real-timeTransport Protocol (RTP)-based environments. In particular, centralized topologies commonly employed in the video conferencing industry are mapped to the RTP terminology. |
|
| |
| RFC 5118 | Session Initiation Protocol (SIP) Torture Test Messages for Internet Protocol Version 6 (IPv6) |
| |
| Authors: | V. Gurbani, C. Boulton, R. Sparks. |
| Date: | February 2008 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5118 |
|
This document provides examples of Session Initiation Protocol (SIP) test messages designed to exercise and "torture" the code of anIPv6-enabled SIP implementation. |
|
| |
| RFC 5119 | A Uniform Resource Name (URN) Namespace for the Society of Motion Picture and Television Engineers (SMPTE) |
| |
| Authors: | T. Edwards. |
| Date: | February 2008 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5119 |
|
This document describes a Uniform Resource Name (URN) namespace for the Society of Motion Picture and Television Engineers (SMPTE) for naming persistent resources that SMPTE produces or manages. A subnamespace for Universal Labels is specifically described. |
|
| |
| RFC 5123 | Considerations in Validating the Path in BGP |
| |
| Authors: | R. White, B. Akyol. |
| Date: | February 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5123 |
|
This document examines the implications of hop-by-hop forwarding, route aggregation, and route filtering on the concept of validation within a BGP Autonomous System (AS) Path. |
|
| |
| RFC 5125 | Reclassification of RFC 3525 to Historic |
| |
|
|
This document reclassifies RFC 3525, Gateway Control Protocol Version1, to Historic Status. This memo also obsoletes RFC 3525. |
|
| |
| RFC 5126 | CMS Advanced Electronic Signatures (CAdES) |
| |
| Authors: | D. Pinkas, N. Pope, J. Ross. |
| Date: | March 2008 |
| Formats: | txt html json |
| Obsoletes: | RFC 3126 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5126 |
|
This document defines the format of an electronic signature that can remain valid over long periods. This includes evidence as to its validity even if the signer or verifying party later attempts to deny(i.e., repudiates) the validity of the signature.
The format can be considered as an extension to RFC 3852 and RFC2634, where, when appropriate, additional signed and unsigned attributes have been defined.
The contents of this Informational RFC amount to a transposition of the ETSI Technical Specification (TS) 101 733 V.1.7.4 (CMS AdvancedElectronic Signatures -- CAdES) and is technically equivalent to it.
The technical contents of this specification are maintained by ETSI.The ETSI TS and further updates are available free of charge at: http://www.etsi.org/WebSite/Standards/StandardsDownload.aspx |
|
| |
| RFC 5127 | Aggregation of Diffserv Service Classes |
| |
| Authors: | K. Chan, J. Babiarz, F. Baker. |
| Date: | February 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5127 |
|
In the core of a high-capacity network, service differentiation may still be needed to support applications' utilization of the network.Applications with similar traffic characteristics and performance requirements are mapped into Diffserv service classes based on end- to-end behavior requirements of the applications. However, some network segments may be configured in such a way that a single forwarding treatment may satisfy the traffic characteristics and performance requirements of two or more service classes. In these cases, it may be desirable to aggregate two or more Diffserv service classes into a single forwarding treatment. This document provides guidelines for the aggregation of Diffserv service classes into forwarding treatments. |
|
| |
| RFC 5128 | State of Peer-to-Peer (P2P) Communication across Network Address Translators (NATs) |
| |
| Authors: | P. Srisuresh, B. Ford, D. Kegel. |
| Date: | March 2008 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5128 |
|
This memo documents the various methods known to be in use by applications to establish direct communication in the presence ofNetwork Address Translators (NATs) at the current time. Although this memo is intended to be mainly descriptive, the SecurityConsiderations section makes some purely advisory recommendations about how to deal with security vulnerabilities the applications could inadvertently create when using the methods described. This memo covers NAT traversal approaches used by both TCP- and UDP-based applications. This memo is not an endorsement of the methods described, but merely an attempt to capture them in a document. |
|
| |
| RFC 5134 | A Uniform Resource Name Namespace for the EPCglobal Electronic Product Code (EPC) and Related Standards |
| |
| Authors: | M. Mealling. |
| Date: | January 2008 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5134 |
|
This document describes URN namespaces that will identify various objects within the EPCglobal system for identifying products within ecommerce and supply chain management applications. |
|
| |
| RFC 5136 | Defining Network Capacity |
| |
| Authors: | P. Chimento, J. Ishac. |
| Date: | February 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5136 |
|
Measuring capacity is a task that sounds simple, but in reality can be quite complex. In addition, the lack of a unified nomenclature on this subject makes it increasingly difficult to properly build, test, and use techniques and tools built around these constructs. This document provides definitions for the terms 'Capacity' and 'AvailableCapacity' related to IP traffic traveling between a source and destination in an IP network. By doing so, we hope to provide a common framework for the discussion and analysis of a diverse set of current and future estimation techniques. |
|
| |
| RFC 5138 | A Uniform Resource Name (URN) Namespace for the Commission for the Management and Application of Geoscience Information (CGI) |
| |
| Authors: | S. Cox. |
| Date: | February 2008 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5138 |
|
This document describes a URN (Uniform Resource Name) namespace that is engineered by the Commission for the Management and Application ofGeoscience Information (CGI) for naming (i) persistent resources published by the CGI and (ii) resources published by organizations that wish them to be used in the context of services conforming to protocols and agreements issued by CGI. The formal NamespaceIdentifier (NID) is "cgi". |
|
| |
| RFC 5141 | A Uniform Resource Name (URN) Namespace for the International Organization for Standardization (ISO) |
| |
| Authors: | J. Goodwin, H. Apel. |
| Date: | March 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5141 |
|
This document describes a Uniform Resource Name NamespaceIdentification (URN NID) for the International Organization forStandardization (ISO). This URN NID is intended for use for the identification of persistent resources published by the ISO standards body (including documents, document metadata, extracted resources such as standard schemata and standard value sets, and other resources). |
|
| |
| RFC 5145 | Framework for MPLS-TE to GMPLS Migration |
| |
| Authors: | K. Shiomoto, Ed.. |
| Date: | March 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5145 |
|
The migration from Multiprotocol Label Switching (MPLS) TrafficEngineering (TE) to Generalized MPLS (GMPLS) is the process of evolving an MPLS-TE control plane to a GMPLS control plane. An appropriate migration strategy will be selected based on various factors including the service provider's network deployment plan, customer demand, and operational policy.
This document presents several migration models and strategies for migrating from MPLS-TE to GMPLS. In the course of migration, MPLS-TE and GMPLS devices, or networks, may coexist that may require interworking between MPLS-TE and GMPLS protocols. Aspects of the required interworking are discussed as it will influence the choice of a migration strategy. This framework document provides a migration toolkit to aid the operator in selection of an appropriate strategy.
This framework document also lists a set of solutions that may aid in interworking, and highlights a set of potential issues. |
|
| |
| RFC 5146 | Interworking Requirements to Support Operation of MPLS-TE over GMPLS Networks |
| |
| Authors: | K. Kumaki, Ed.. |
| Date: | March 2008 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5146 |
|
Operation of a Multiprotocol Label Switching (MPLS) traffic engineering (TE) network as a client network to a Generalized MPLS(GMPLS) network has enhanced operational capabilities compared to those provided by a coexistent protocol model (i.e., operation ofMPLS-TE over an independently managed transport layer).
The GMPLS network may be a packet or a non-packet network, and may itself be a multi-layer network supporting both packet and non-packet technologies. An MPLS-TE Label Switched Path (LSP) originates and terminates on an MPLS Label Switching Router (LSR). The GMPLS network provides transparent transport for the end-to-end MPLS-TELSP.
This document describes a framework and Service Provider requirements for operating MPLS-TE networks over GMPLS networks. |
|
| |
| RFC 5148 | Jitter Considerations in Mobile Ad Hoc Networks (MANETs) |
| |
| Authors: | T. Clausen, C. Dearlove, B. Adamson. |
| Date: | February 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5148 |
|
This document provides recommendations for jittering (randomly modifying timing) of control traffic transmissions in Mobile Ad hocNETwork (MANET) routing protocols to reduce the probability of transmission collisions. |
|
| |
| RFC 5149 | Service Selection for Mobile IPv6 |
| |
| Authors: | J. Korhonen, U. Nilsson, V. Devarapalli. |
| Date: | February 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5149 |
|
In some Mobile IPv6 deployments, identifying the mobile node or the mobility service subscriber is not enough to distinguish between multiple services possibly provisioned to the said mobile node and its mobility service subscription. A capability to specify different services in addition to the mobile node identity can be leveraged to provide flexibility for mobility service providers on provisioning multiple services to one mobility service subscription. This document describes a Service Selection Mobility Option for both conventional Mobile IPv6 and Proxy Mobile IPv6 that is intended to assist home agents to make a specific service selection for the mobility service subscription during the binding registration procedure. |
|
| |
| RFC 5153 | IP Flow Information Export (IPFIX) Implementation Guidelines |
| |
| Authors: | E. Boschi, L. Mark, J. Quittek, M. Stiemerling, P. Aitken. |
| Date: | April 2008 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5153 |
|
The IP Flow Information Export (IPFIX) protocol defines how IP Flow information can be exported from routers, measurement probes, or other devices. This document provides guidelines for the implementation and use of the IPFIX protocol. Several sets of guidelines address Template management, transport-specific issues, implementation of Exporting and Collecting Processes, and IPFIX implementation on middleboxes (such as firewalls, network address translators, tunnel endpoints, packet classifiers, etc.). |
|
| |
| RFC 5154 | IP over IEEE 802.16 Problem Statement and Goals |
| |
| Authors: | J. Jee, Ed., S. Madanapalli, J. Mandin. |
| Date: | April 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5154 |
|
This document specifies problems in running IP over IEEE 802.16 networks by identifying specific gaps in the IEEE 802.16 Media AccessControl (MAC) for IPv4 and IPv6 support. This document also provides an overview of IEEE 802.16 network characteristics and convergence sublayers. Common terminology used for the base guideline while defining the solution framework is also presented. |
|
| |
| RFC 5156 | Special-Use IPv6 Addresses |
| |
|
|
This document is a compilation of special IPv6 addresses defined in other RFCs. It can be used as a checklist of invalid routing prefixes for developing filtering policies for routes and IP packets.It does not discuss addresses that are assigned to operators and users through the Regional Internet Registries. |
|
| |
| RFC 5157 | IPv6 Implications for Network Scanning |
| |
|
|
The much larger default 64-bit subnet address space of IPv6 should in principle make traditional network (port) scanning techniques used by certain network worms or scanning tools less effective. While traditional network scanning probes (whether by individuals or automated via network worms) may become less common, administrators should be aware that attackers may use other techniques to discoverIPv6 addresses on a target network, and thus they should also be aware of measures that are available to mitigate them. This informational document discusses approaches that administrators could take when planning their site address allocation and management strategies as part of a defence-in-depth approach to network security. |
|
| |
| RFC 5158 | 6to4 Reverse DNS Delegation Specification |
| |
|
|
This memo describes the service mechanism for entering a delegation of DNS servers that provide reverse lookup of 6to4 IPv6 addresses into the 6to4 reverse zone file. The mechanism is based on a conventional DNS delegation service interface, allowing the service client to enter the details of a number of DNS servers for the delegated domain. In the context of a 6to4 reverse delegation, the client is primarily authenticated by its source address used in the delegation request, and is authorized to use the function if its IPv6 address prefix corresponds to an address from within the requested6to4 delegation address block. |
|
| |
| RFC 5159 | Session Description Protocol (SDP) Attributes for Open Mobile Alliance (OMA) Broadcast (BCAST) Service and Content Protection |
| |
| Authors: | L. Dondeti, Ed., A. Jerichow. |
| Date: | March 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5159 |
|
This document provides descriptions of Session Description Protocol(SDP) attributes used by the Open Mobile Alliance's Broadcast Service and Content Protection specification. |
|
| |
| RFC 5160 | Considerations of Provider-to-Provider Agreements for Internet-Scale Quality of Service (QoS) |
| |
| Authors: | P. Levis, M. Boucadair. |
| Date: | March 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5160 |
|
This memo analyzes provider-to-provider Quality of Service (QoS) agreements suitable for a global QoS-enabled Internet. It defines terminology relevant to inter-domain QoS models. It proposes a new concept denoted by Meta-QoS-Class (MQC). This concept could potentially drive and federate the way QoS inter-domain relationships are built between providers. It opens up new perspectives for a QoS- enabled Internet that retains, as much as possible, the openness of the existing best-effort Internet. |
|
| |
| RFC 5164 | Mobility Services Transport: Problem Statement |
| |
| Authors: | T. Melia, Ed.. |
| Date: | March 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5164 |
|
There are ongoing activities in the networking community to develop solutions that aid in IP handover mechanisms between heterogeneous wired and wireless access systems including, but not limited to, IEEE802.21. Intelligent access selection, taking into account link-layer attributes, requires the delivery of a variety of different information types to the terminal from different sources within the network and vice-versa. The protocol requirements for this signalling have both transport and security issues that must be considered. The signalling must not be constrained to specific link types, so there is at least a common component to the signalling problem, which is within the scope of the IETF. This document presents a problem statement for this core problem. |
|
| |
| RFC 5165 | A Uniform Resource Name (URN) Namespace for the Open Geospatial Consortium (OGC) |
| |
| Authors: | C. Reed. |
| Date: | April 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5165 |
|
This document describes a Uniform Resource Name (URN) namespace that is engineered by the Open Geospatial Consortium (OGC) for naming persistent resources published by the OGC. The formal NamespaceIDentifier (NID) is "ogc". |
|
| |
| RFC 5166 | Metrics for the Evaluation of Congestion Control Mechanisms |
| |
| Authors: | S. Floyd, Ed.. |
| Date: | March 2008 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5166 |
|
This document discusses the metrics to be considered in an evaluation of new or modified congestion control mechanisms for the Internet.These include metrics for the evaluation of new transport protocols, of proposed modifications to TCP, of application-level congestion control, and of Active Queue Management (AQM) mechanisms in the router. This document is the first in a series of documents aimed at improving the models that we use in the evaluation of transport protocols.
This document is a product of the Transport Modeling Research Group(TMRG), and has received detailed feedback from many members of theResearch Group (RG). As the document tries to make clear, there is not necessarily a consensus within the research community (or theIETF community, the vendor community, the operations community, or any other community) about the metrics that congestion control mechanisms should be designed to optimize, in terms of trade-offs between throughput and delay, fairness between competing flows, and the like. However, we believe that there is a clear consensus that congestion control mechanisms should be evaluated in terms of trade- offs between a range of metrics, rather than in terms of optimizing for a single metric. |
|
| |
| RFC 5167 | Media Server Control Protocol Requirements |
| |
| Authors: | M. Dolly, R. Even. |
| Date: | March 2008 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5167 |
|
This document addresses the communication between an application server and media server. The current work in IETF working groups shows these logical entities, but it does not address the physical decomposition and the protocol between the entities.
This document presents the requirements for a Media Server ControlProtocol (MCP) that enables an application server to use a media server. It will address the aspects of announcements, InteractiveVoice Response, and conferencing media services. |
|
| |
| RFC 5168 | XML Schema for Media Control |
| |
| Authors: | O. Levin, R. Even, P. Hagendorf. |
| Date: | March 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5168 |
|
This document defines an Extensible Markup Language (XML) Schema for video fast update in a tightly controlled environment, developed byMicrosoft, Polycom, Radvision and used by multiple vendors. This document describes a method that has been deployed in SessionInitiation Protocol (SIP) based systems over the last three years and is being used across real-time interactive applications from different vendors in an interoperable manner. New implementations are discouraged from using the method described except for backward compatibility purposes. New implementations are required to use the new Full Intra Request command in the RTP Control Protocol (RTCP) channel. |
|
| |
| RFC 5169 | Handover Key Management and Re-Authentication Problem Statement |
| |
| Authors: | T. Clancy, M. Nakhjiri, V. Narayanan, L. Dondeti. |
| Date: | March 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5169 |
|
This document describes the Handover Keying (HOKEY) re-authentication problem statement. The current Extensible Authentication Protocol(EAP) keying framework is not designed to support re-authentication and handovers without re-executing an EAP method. This often causes unacceptable latency in various mobile wireless environments. This document details the problem and defines design goals for a generic mechanism to reuse derived EAP keying material for handover. |
|
| |
| RFC 5171 | Cisco Systems UniDirectional Link Detection (UDLD) Protocol |
| |
| Authors: | M. Foschiano. |
| Date: | April 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5171 |
|
This document describes a Cisco Systems protocol that can be used to detect and disable unidirectional Ethernet fiber or copper links caused, for instance, by mis-wiring of fiber strands, interface malfunctions, media converters' faults, etc. It operates at Layer 2 in conjunction with IEEE 802.3's existing Layer 1 fault detection mechanisms.
This document explains the protocol objectives and applications, illustrates the specific premises the protocol was based upon, and describes the protocol architecture and related deployment issues to serve as a possible base for future standardization. |
|
| |
| RFC 5174 | A Uniform Resource Name (URN) Namespace for the European Broadcasting Union (EBU) |
| |
| Authors: | J-P. Evain. |
| Date: | May 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5174 |
|
This document describes a Uniform Resource Name (URN) namespace for the European Broadcasting Union (EBU) for naming persistent resources defined within EBU technical documentation and Internet resources.Example resources include technical documents and specifications, eXtensible Markup Language (XML) Schemas, classification schemes, XMLDocument Type Definitions (DTDs), namespaces, style sheets, media assets, and other types of resources produced or managed by the EBU. |
|
| |
| RFC 5176 | Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS) |
| |
| Authors: | M. Chiba, G. Dommety, M. Eklund, D. Mitton, B. Aboba. |
| Date: | January 2008 |
| Formats: | txt json html |
| Obsoletes: | RFC 3576 |
| Updated by: | RFC 8559 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5176 |
|
This document describes a currently deployed extension to the RemoteAuthentication Dial In User Service (RADIUS) protocol, allowing dynamic changes to a user session, as implemented by network access server products. This includes support for disconnecting users and changing authorizations applicable to a user session. |
|
| |
| RFC 5180 | IPv6 Benchmarking Methodology for Network Interconnect Devices |
| |
| Authors: | C. Popoviciu, A. Hamza, G. Van de Velde, D. Dugatkin. |
| Date: | May 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5180 |
|
The benchmarking methodologies defined in RFC 2544 are IP version independent. However, RFC 2544 does not address some of the specificities of IPv6. This document provides additional benchmarking guidelines, which in conjunction with RFC 2544, lead to a more complete and realistic evaluation of the IPv6 performance of network interconnect devices. IPv6 transition mechanisms are outside the scope of this document. |
|
| |
| RFC 5181 | IPv6 Deployment Scenarios in 802.16 Networks |
| |
| Authors: | M-K. Shin, Ed., Y-H. Han, S-E. Kim, D. Premec. |
| Date: | May 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5181 |
|
This document provides a detailed description of IPv6 deployment and integration methods and scenarios in wireless broadband access networks in coexistence with deployed IPv4 services. In this document, we will discuss the main components of IPv6 IEEE 802.16 access networks and their differences from IPv4 IEEE 802.16 networks and how IPv6 is deployed and integrated in each of the IEEE 802.16 technologies. |
|
| |
| RFC 5186 | Internet Group Management Protocol Version 3 (IGMPv3) / Multicast Listener Discovery Version 2 (MLDv2) and Multicast Routing Protocol Interaction |
| |
| Authors: | B. Haberman, J. Martin. |
| Date: | May 2008 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5186 |
|
The definitions of the Internet Group Management Protocol Version 3(IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) require new behavior within the multicast routing protocols. The additional source information contained in IGMPv3 and MLDv2 messages necessitates that multicast routing protocols manage and utilize the information. This document describes how multicast routing protocols will interact with these source-filtering group management protocols. |
|
| |
| RFC 5193 | Protocol for Carrying Authentication for Network Access (PANA) Framework |
| |
| Authors: | P. Jayaraman, R. Lopez, Y. Ohba, Ed., M. Parthasarathy, A. Yegin. |
| Date: | May 2008 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5193 |
|
This document defines the general Protocol for CarryingAuthentication for Network Access (PANA) framework functional elements, high-level call flow, and deployment environments. |
|
| |
| RFC 5194 | Framework for Real-Time Text over IP Using the Session Initiation Protocol (SIP) |
| |
| Authors: | A. van Wijk, Ed., G. Gybels, Ed.. |
| Date: | June 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5194 |
|
This document lists the essential requirements for real-time Text- over-IP (ToIP) and defines a framework for implementation of all required functions based on the Session Initiation Protocol (SIP) and the Real-Time Transport Protocol (RTP). This includes interworking between Text-over-IP and existing text telephony on the PublicSwitched Telephone Network (PSTN) and other networks. |
|
| |
| RFC 5197 | On the Applicability of Various Multimedia Internet KEYing (MIKEY) Modes and Extensions |
| |
| Authors: | S. Fries, D. Ignjatic. |
| Date: | June 2008 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5197 |
|
Multimedia Internet Keying (MIKEY) is a key management protocol that can be used for real-time applications. In particular, it has been defined focusing on the support of the Secure Real-time TransportProtocol (SRTP). MIKEY itself is standardized within RFC 3830 and defines four key distribution methods. Moreover, it is defined to allow extensions of the protocol. As MIKEY becomes more and more accepted, extensions to the base protocol arise, especially in terms of additional key distribution methods but also in terms of payload enhancements.
This document provides an overview about the MIKEY base document in general as well as the existing extensions for MIKEY, which have been defined or are in the process of definition. It is intended as an additional source of information for developers or architects to provide more insight in use case scenarios and motivations as well as advantages and disadvantages for the different key distribution schemes. The use cases discussed in this document are strongly related to dedicated SIP call scenarios providing challenges for key management in general, among them media before Session DescriptionProtocol (SDP) answer, forking, and shared key conferencing. |
|
| |
| RFC 5207 | NAT and Firewall Traversal Issues of Host Identity Protocol (HIP) Communication |
| |
| Authors: | M. Stiemerling, J. Quittek, L. Eggert. |
| Date: | April 2008 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5207 |
|
The Host Identity Protocol (HIP) changes the way in which twoInternet hosts communicate. One key advantage over other schemes is that HIP does not require modifications to the traditional network- layer functionality of the Internet, i.e., its routers. In the current Internet, however, many devices other than routers modify the traditional network-layer behavior of the Internet. These"middleboxes" are intermediary devices that perform functions other than the standard functions of an IP router on the datagram path between source and destination hosts. Whereas some types of middleboxes may not interfere with HIP at all, others can affect some aspects of HIP communication, and others can render HIP communication impossible. This document discusses the problems associated with HIP communication across network paths that include specific types of middleboxes, namely, network address translators and firewalls. It identifies and discusses issues in the current HIP specifications that affect communication across these types of middleboxes. This document is a product of the IRTF HIP Research Group. |
|
| |
| RFC 5208 | Public-Key Cryptography Standards (PKCS) #8: Private-Key Information Syntax Specification Version 1.2 |
| |
|
|
This document represents a republication of PKCS #8 v1.2 from RSALaboratories' Public Key Cryptography Standard (PKCS) series. Change control is transferred to the IETF. The body of this document, except for the security considerations section, is taken directly from the PKCS #8 v1.2 specification.
This document describes a syntax for private-key information. |
|
| |
| RFC 5209 | Network Endpoint Assessment (NEA): Overview and Requirements |
| |
| Authors: | P. Sangster, H. Khosravi, M. Mani, K. Narayan, J. Tardo. |
| Date: | June 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5209 |
|
This document defines the problem statement, scope, and protocol requirements between the components of the NEA (Network EndpointAssessment) reference model. NEA provides owners of networks (e.g., an enterprise offering remote access) a mechanism to evaluate the posture of a system. This may take place during the request for network access and/or subsequently at any time while connected to the network. The learned posture information can then be applied to a variety of compliance-oriented decisions. The posture information is frequently useful for detecting systems that are lacking or have out-of-date security protection mechanisms such as: anti-virus and host-based firewall software. In order to provide context for the requirements, a reference model and terminology are introduced. |
|
| |
| RFC 5211 | An Internet Transition Plan |
| |
| Authors: | J. Curran. |
| Date: | July 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5211 |
|
This memo provides one possible plan for transitioning the Internet from a predominantly IPv4-based connectivity model to a predominantlyIPv6-based connectivity model. |
|
| |
| RFC 5212 | Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN) |
| |
| Authors: | K. Shiomoto, D. Papadimitriou, JL. Le Roux, M. Vigoureux, D. Brungard. |
| Date: | July 2008 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5212 |
|
Most of the initial efforts to utilize Generalized MPLS (GMPLS) have been related to environments hosting devices with a single switching capability. The complexity raised by the control of such data planes is similar to that seen in classical IP/MPLS networks. By extendingMPLS to support multiple switching technologies, GMPLS provides a comprehensive framework for the control of a multi-layered network of either a single switching technology or multiple switching technologies.
In GMPLS, a switching technology domain defines a region, and a network of multiple switching types is referred to in this document as a multi-region network (MRN). When referring in general to a layered network, which may consist of either single or multiple regions, this document uses the term multi-layer network (MLN). This document defines a framework for GMPLS based multi-region / multi- layer networks and lists a set of functional requirements. |
|
| |
| RFC 5214 | Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) |
| |
| Authors: | F. Templin, T. Gleeson, D. Thaler. |
| Date: | March 2008 |
| Formats: | txt html json |
| Obsoletes: | RFC 4214 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5214 |
|
The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) connects dual-stack (IPv6/IPv4) nodes over IPv4 networks. ISATAP views theIPv4 network as a link layer for IPv6 and supports an automatic tunneling abstraction similar to the Non-Broadcast Multiple Access(NBMA) model. |
|
| |
| RFC 5217 | Memorandum for Multi-Domain Public Key Infrastructure Interoperability |
| |
| Authors: | M. Shimaoka, Ed., N. Hastings, R. Nielsen. |
| Date: | July 2008 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5217 |
|
The objective of this document is to establish a terminology framework and to suggest the operational requirements of Public KeyInfrastructure (PKI) domain for interoperability of multi-domainPublic Key Infrastructure, where each PKI domain is operated under a distinct policy. This document describes the relationships betweenCertification Authorities (CAs), provides the definition and requirements for PKI domains, and discusses typical models of multi- domain PKI. |
|
| |
| RFC 5218 | What Makes for a Successful Protocol? |
| |
| Authors: | D. Thaler, B. Aboba. |
| Date: | July 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5218 |
|
The Internet community has specified a large number of protocols to date, and these protocols have achieved varying degrees of success.Based on case studies, this document attempts to ascertain factors that contribute to or hinder a protocol's success. It is hoped that these observations can serve as guidance for future protocol work. |
|
| |
| RFC 5220 | Problem Statement for Default Address Selection in Multi-Prefix Environments: Operational Issues of RFC 3484 Default Rules |
| |
| Authors: | A. Matsumoto, T. Fujisaki, R. Hiromi, K. Kanayama. |
| Date: | July 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5220 |
|
A single physical link can have multiple prefixes assigned to it. In that environment, end hosts might have multiple IP addresses and be required to use them selectively. RFC 3484 defines default source and destination address selection rules and is implemented in a variety of OSs. But, it has been too difficult to use operationally for several reasons. In some environments where multiple prefixes are assigned on a single physical link, the host using the default address selection rules will experience some trouble in communication. This document describes the possible problems that end hosts could encounter in an environment with multiple prefixes. |
|
| |
| RFC 5221 | Requirements for Address Selection Mechanisms |
| |
| Authors: | A. Matsumoto, T. Fujisaki, R. Hiromi, K. Kanayama. |
| Date: | July 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5221 |
|
There are some problematic cases when using the default address selection mechanism that RFC 3484 defines. This document describes additional requirements that operate with RFC 3484 to solve the problems. |
|
| |
| RFC 5224 | Diameter Policy Processing Application |
| |
| Authors: | M. Brenner. |
| Date: | March 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5224 |
|
This document describes the need for a new IANA Diameter Command Code to be used in a vendor-specific new application for invocation ofPolicy Processing (Policy Evaluation, or Evaluation and Enforcement).This application is needed as one of the implementations of the OpenMobile Alliance (OMA) Policy Evaluation, Enforcement and Management(PEEM) enabler, namely for the PEM-1 interface used to send a request/response for Policy Processing. |
|
| |
| RFC 5236 | Improved Packet Reordering Metrics |
| |
| Authors: | A. Jayasumana, N. Piratla, T. Banka, A. Bare, R. Whitner. |
| Date: | June 2008 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5236 |
|
This document presents two improved metrics for packet reordering, namely, Reorder Density (RD) and Reorder Buffer-occupancy Density(RBD). A threshold is used to clearly define when a packet is considered lost, to bound computational complexity at O(N), and to keep the memory requirement for evaluation independent of N, where N is the length of the packet sequence. RD is a comprehensive metric that captures the characteristics of reordering, while RBD evaluates the sequences from the point of view of recovery from reordering.
These metrics are simple to compute yet comprehensive in their characterization of packet reordering. The measures are robust and orthogonal to packet loss and duplication. |
|
| |
| RFC 5241 | Naming Rights in IETF Protocols |
| |
| Authors: | A. Falk, S. Bradner. |
| Date: | 1 April 2008 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5241 |
|
This document proposes a new revenue source for the IETF to support standardization activities: protocol field naming rights, i.e., the association of commercial brands with protocol fields. This memo describes a process for assignment of rights and explores some of the issues associated with the process. Individuals or organizations that wish to purchase naming rights for one or more protocol fields are expected to follow this process. |
|
| |
| RFC 5242 | A Generalized Unified Character Code: Western European and CJK Sections |
| |
| Authors: | J. Klensin, H. Alvestrand. |
| Date: | 1 April 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5242 |
|
Many issues have been identified with the use of general-purpose character sets for internationalized domain names and similar purposes. This memo describes a fully unified coded character set for scripts based on Latin, Greek, Cyrillic, and Chinese (CJK) characters. It is not a complete specification of that character set. |
|
| |
| RFC 5243 | OSPF Database Exchange Summary List Optimization |
| |
|
|
This document describes a backward-compatible optimization for theDatabase Exchange process in OSPFv2 and OSPFv3. In this optimization, a router does not list a Link State Advertisement (LSA) in Database Description packets sent to a neighbor, if the same or a more recent instance of the LSA was listed in a Database Description packet already received from the neighbor. This optimization reducesDatabase Description overhead by about 50% in large networks. This optimization does not affect synchronization, since it only omits unnecessary information from Database Description packets. |
|
| |
| RFC 5253 | Applicability Statement for Layer 1 Virtual Private Network (L1VPN) Basic Mode |
| |
| Authors: | T. Takeda, Ed.. |
| Date: | July 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5253 |
|
This document provides an applicability statement on the use ofGeneralized Multiprotocol Label Switching (GMPLS) protocols and mechanisms to support Basic Mode Layer 1 Virtual Private Networks(L1VPNs).
L1VPNs provide customer services and connectivity at Layer 1 overLayer 1 networks. The operation of L1VPNs is divided into the BasicMode and the Enhanced Mode, where the Basic Mode of operation does not feature any exchange of routing information between the Layer 1 network and the customer domain. This document examines how GMPLS protocols can be used to satisfy the requirements of a Basic ModeL1VPN. |
|
| |
| RFC 5254 | Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3) |
| |
| Authors: | N. Bitar, Ed., M. Bocci, Ed., L. Martini, Ed.. |
| Date: | October 2008 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5254 |
|
This document describes the necessary requirements to allow a service provider to extend the reach of pseudowires across multiple domains.These domains can be autonomous systems under one provider administrative control, IGP areas in one autonomous system, different autonomous systems under the administrative control of two or more service providers, or administratively established pseudowire domains. |
|
| |
| RFC 5270 | Mobile IPv6 Fast Handovers over IEEE 802.16e Networks |
| |
| Authors: | H. Jang, J. Jee, Y. Han, S. Park, J. Cha. |
| Date: | June 2008 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5270 |
|
This document describes how a Mobile IPv6 Fast Handover can be implemented on link layers conforming to the IEEE 802.16e suite of specifications. The proposed scheme tries to achieve seamless handover by exploiting the link-layer handover indicators and thereby synchronizing the IEEE 802.16e handover procedures with the MobileIPv6 fast handover procedures efficiently. |
|
| |
| RFC 5271 | Mobile IPv6 Fast Handovers for 3G CDMA Networks |
| |
| Authors: | H. Yokota, G. Dommety. |
| Date: | June 2008 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5271 |
|
Mobile IPv6 is designed to maintain its connectivity while moving from one network to another. It is adopted in 3G CDMA networks as a way to maintain connectivity when the mobile node (MN) moves between access routers. However, this handover procedure requires not only movement detection by the MN, but also the acquisition of a newCare-of Address and Mobile IPv6 registration with the new care-of address before the traffic can be sent or received in the target network. During this period, packets destined for the mobile node may be lost, which may not be acceptable for a real-time application such as Voice over IP (VoIP) or video telephony. This document specifies fast handover methods in the 3G CDMA networks in order to reduce latency and packet loss during handover. |
|
| |
| RFC 5279 | A Uniform Resource Name (URN) Namespace for the 3rd Generation Partnership Project (3GPP) |
| |
| Authors: | A. Monrad, S. Loreto. |
| Date: | July 2008 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5279 |
|
This document describes the Namespace Identifier (NID) for UniformResource Namespace (URN) resources published by the 3rd GenerationPartnership Project (3GPP). 3GPP defines and manages resources that utilize this URN name model. Management activities for these and other resource types are provided by the 3GPP Support Team. |
|
| |
| RFC 5281 | Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0 (EAP-TTLSv0) |
| |
|
|
EAP-TTLS is an EAP (Extensible Authentication Protocol) method that encapsulates a TLS (Transport Layer Security) session, consisting of a handshake phase and a data phase. During the handshake phase, the server is authenticated to the client (or client and server are mutually authenticated) using standard TLS procedures, and keying material is generated in order to create a cryptographically secure tunnel for information exchange in the subsequent data phase. During the data phase, the client is authenticated to the server (or client and server are mutually authenticated) using an arbitrary authentication mechanism encapsulated within the secure tunnel. The encapsulated authentication mechanism may itself be EAP, or it may be another authentication protocol such as PAP, CHAP, MS-CHAP, or MS-CHAP-V2. Thus, EAP-TTLS allows legacy password-based authentication protocols to be used against existing authentication databases, while protecting the security of these legacy protocols against eavesdropping, man-in-the-middle, and other attacks. The data phase may also be used for additional, arbitrary data exchange. |
|
| |
| RFC 5290 | Comments on the Usefulness of Simple Best-Effort Traffic |
| |
| Authors: | S. Floyd, M. Allman. |
| Date: | July 2008 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5290 |
|
This document presents some observations on "simple best-effort traffic", defined loosely for the purposes of this document asInternet traffic that is not covered by Quality of Service (QOS) mechanisms, congestion-based pricing, cost-based fairness, admissions control, or the like. One observation is that simple best-effort traffic serves a useful role in the Internet, and is worth keeping.While differential treatment of traffic can clearly be useful, we believe such mechanisms are useful as *adjuncts* to simple best- effort traffic, not as *replacements* of simple best-effort traffic.A second observation is that for simple best-effort traffic, some form of rough flow-rate fairness is a useful goal for resource allocation, where "flow-rate fairness" is defined by the goal of equal flow rates for different flows over the same path. |
|
| |
| RFC 5294 | Host Threats to Protocol Independent Multicast (PIM) |
| |
| Authors: | P. Savola, J. Lingard. |
| Date: | August 2008 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5294 |
|
This memo complements the list of multicast infrastructure security threat analysis documents by describing Protocol IndependentMulticast (PIM) threats specific to router interfaces connecting hosts. |
|
| |
| RFC 5297 | Synthetic Initialization Vector (SIV) Authenticated Encryption Using the Advanced Encryption Standard (AES) |
| |
| Authors: | D. Harkins. |
| Date: | October 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5297 |
|
This memo describes SIV (Synthetic Initialization Vector), a block cipher mode of operation. SIV takes a key, a plaintext, and multiple variable-length octet strings that will be authenticated but not encrypted. It produces a ciphertext having the same length as the plaintext and a synthetic initialization vector. Depending on how it is used, SIV achieves either the goal of deterministic authenticated encryption or the goal of nonce-based, misuse-resistant authenticated encryption. |
|
| |
| RFC 5298 | Analysis of Inter-Domain Label Switched Path (LSP) Recovery |
| |
| Authors: | T. Takeda, Ed., A. Farrel, Ed., Y. Ikejiri, JP. Vasseur. |
| Date: | August 2008 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5298 |
|
Protection and recovery are important features of service offerings in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. Increasingly, MPLS and GMPLS networks are being extended from single domain scope to multi-domain environments.
Various schemes and processes have been developed to establish LabelSwitched Paths (LSPs) in multi-domain environments. These are discussed in RFC 4726: "A Framework for Inter-Domain MultiprotocolLabel Switching Traffic Engineering".
This document analyzes the application of these techniques to protection and recovery in multi-domain networks. The main focus for this document is on establishing end-to-end diverse TrafficEngineering (TE) LSPs in multi-domain networks. |
|
| |
| RFC 5309 | Point-to-Point Operation over LAN in Link State Routing Protocols |
| |
| Authors: | N. Shen, Ed., A. Zinin, Ed.. |
| Date: | October 2008 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5309 |
|
The two predominant circuit types used by link state routing protocols are point-to-point and broadcast. It is important to identify the correct circuit type when forming adjacencies, flooding link state database packets, and representing the circuit topologically. This document describes a simple mechanism to treat the broadcast network as a point-to-point connection from the standpoint of IP routing. |
|
| |
| RFC 5317 | Joint Working Team (JWT) Report on MPLS Architectural Considerations for a Transport Profile |
| |
| Authors: | S. Bryant, Ed., L. Andersson, Ed.. |
| Date: | February 2009 |
| Formats: | txt pdf html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5317 |
|
This RFC archives the report of the IETF - ITU-T Joint Working Team(JWT) on the application of MPLS to transport networks. The JWT recommended of Option 1: The IETF and the ITU-T jointly agree to work together and bring transport requirements into the IETF and extendIETF MPLS forwarding, OAM (Operations, Administration, andManagement), survivability, network management and control plane protocols to meet those requirements through the IETF StandardsProcess. This RFC is available in ASCII (which contains a summary of the slides) and in PDF (which contains the summary and a copy of the slides). |
|
| |
| RFC 5318 | The Session Initiation Protocol (SIP) P-Refused-URI-List Private-Header (P-Header) |
| |
| Authors: | J. Hautakorpi, G. Camarillo. |
| Date: | December 2008 |
| Formats: | txt json html |
| Updated by: | RFC 8217 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5318 |
|
This document specifies the Session Initiation Protocol (SIP)P-Refused-URI-List Private-Header (P-Header). This P-Header is used in the Open Mobile Alliance's (OMA) Push to talk over Cellular (PoC) system. It enables URI-list servers to refuse the handling of incoming URI lists that have embedded URI lists. This P-Header also makes it possible for the URI-list server to inform the client about the embedded URI list that caused the rejection and the individualURIs that form such a URI list. |
|
| |
| RFC 5325 | Licklider Transmission Protocol - Motivation |
| |
| Authors: | S. Burleigh, M. Ramadas, S. Farrell. |
| Date: | September 2008 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5325 |
|
This document describes the motivation for the development of theLicklider Transmission Protocol (LTP) designed to provide retransmission-based reliability over links characterized by extremely long message round-trip times (RTTs) and/or frequent interruptions in connectivity. Since communication across interplanetary space is the most prominent example of this sort of environment, LTP is principally aimed at supporting "long-haul" reliable transmission in interplanetary space, but it has applications in other environments as well.
In an Interplanetary Internet setting deploying the Bundle protocol,LTP is intended to serve as a reliable convergence layer over single-hop deep-space radio frequency (RF) links. LTP does AutomaticRepeat reQuest (ARQ) of data transmissions by soliciting selective- acknowledgment reception reports. It is stateful and has no negotiation or handshakes.
This document is a product of the Delay Tolerant Networking ResearchGroup and has been reviewed by that group. No objections to its publication as an RFC were raised. |
|
| |
| RFC 5328 | A Uniform Resource Name (URN) Namespace for the Digital Video Broadcasting Project (DVB) |
| |
|
|
This document describes a Uniform Resource Name (URN) namespace for the Digital Video Broadcasting Project (DVB) for naming persistent resources defined within DVB standards. Example resources include technical documents and specifications, eXtensible Markup Language(XML) Schemas, classification schemes, XML Document Type Definitions(DTDs), namespaces, style sheets, media assets, and other types of resources produced or managed by DVB. |
|
| |
| RFC 5339 | Evaluation of Existing GMPLS Protocols against Multi-Layer and Multi-Region Networks (MLN/MRN) |
| |
| Authors: | JL. Le Roux, Ed., D. Papadimitriou, Ed.. |
| Date: | September 2008 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5339 |
|
This document provides an evaluation of Generalized MultiprotocolLabel Switching (GMPLS) protocols and mechanisms against the requirements for Multi-Layer Networks (MLNs) and Multi-RegionNetworks (MRNs). In addition, this document identifies areas where additional protocol extensions or procedures are needed to satisfy these requirements, and provides guidelines for potential extensions. |
|
| |
| RFC 5344 | Presence and Instant Messaging Peering Use Cases |
| |
| Authors: | A. Houri, E. Aoki, S. Parameswar. |
| Date: | October 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5344 |
|
This document describes several use cases of peering of non-VoIP(Voice over IP) services between two or more Service Providers.These Service Providers create a peering relationship between themselves, thus enabling their users to collaborate with users on the other Service Provider network. The target of this document is to drive requirements for peering between domains that provide the non-VoIP based collaboration services with presence and, in particular, Instant Messaging (IM). |
|
| |
| RFC 5345 | Simple Network Management Protocol (SNMP) Traffic Measurements and Trace Exchange Formats |
| |
| Authors: | J. Schoenwaelder. |
| Date: | October 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5345 |
|
The Simple Network Management Protocol (SNMP) is widely deployed to monitor, control, and (sometimes also) configure network elements.Even though the SNMP technology is well documented, it remains relatively unclear how SNMP is used in practice and what typical SNMP usage patterns are.
This document describes an approach to carrying out large-scale SNMP traffic measurements in order to develop a better understanding of how SNMP is used in real-world production networks. It describes the motivation, the measurement approach, and the tools and data formats needed to carry out such a study.
This document was produced within the IRTF's Network ManagementResearch Group (NMRG), and it represents the consensus of all of the active contributors to this group. |
|
| |
| RFC 5346 | Operational Requirements for ENUM-Based Softswitch Use |
| |
| Authors: | J. Lim, W. Kim, C. Park, L. Conroy. |
| Date: | October 2008 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5346 |
|
This document describes experiences of operational requirements and several considerations for ENUM-based softswitches concerning call routing between two Korean Voice over IP (VoIP) carriers, gained during the ENUM pre-commercial trial hosted by the National InternetDevelopment Agency of Korea (NIDA) in 2006.
These experiences show that an interim solution can maintain the stability of ongoing commercial softswitch system operations during the initial stage of ENUM service, where the DNS does not have sufficient data for the majority of calls. |
|
| |
| RFC 5347 | Media Gateway Control Protocol Fax Package |
| |
| Authors: | F. Andreasen, D. Hancock. |
| Date: | October 2008 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5347 |
|
This document defines a Media Gateway Control Protocol (MGCP) package to support fax calls. The package allows for fax calls to be supported in two different ways. The first one utilizes ITU-TRecommendation T.38 for fax relay under the control of the CallAgent. The second one lets the gateway decide upon a method for fax transmission as well as handle the details of the fax call withoutCall Agent involvement. |
|
| |
| RFC 5349 | Elliptic Curve Cryptography (ECC) Support for Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) |
| |
| Authors: | L. Zhu, K. Jaganathan, K. Lauter. |
| Date: | September 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5349 |
|
This document describes the use of Elliptic Curve certificates,Elliptic Curve signature schemes and Elliptic Curve Diffie-Hellman(ECDH) key agreement within the framework of PKINIT -- the KerberosVersion 5 extension that provides for the use of public key cryptography. |
|
| |
| RFC 5351 | An Overview of Reliable Server Pooling Protocols |
| |
| Authors: | P. Lei, L. Ong, M. Tuexen, T. Dreibholz. |
| Date: | September 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5351 |
|
The Reliable Server Pooling effort (abbreviated "RSerPool") provides an application-independent set of services and protocols for building fault-tolerant and highly available client/server applications. This document provides an overview of the protocols and mechanisms in theReliable Server Pooling suite. |
|
| |
| RFC 5355 | Threats Introduced by Reliable Server Pooling (RSerPool) and Requirements for Security in Response to Threats |
| |
| Authors: | M. Stillman, Ed., R. Gopal, E. Guttman, S. Sengodan, M. Holdrege. |
| Date: | September 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5355 |
|
Reliable Server Pooling (RSerPool) is an architecture and set of protocols for the management and access to server pools supporting highly reliable applications and for client access mechanisms to a server pool. This document describes security threats to theRSerPool architecture and presents requirements for security to thwart these threats. |
|
| |
| RFC 5369 | Framework for Transcoding with the Session Initiation Protocol (SIP) |
| |
| Authors: | G. Camarillo. |
| Date: | October 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5369 |
|
This document defines a framework for transcoding with SIP. This framework includes how to discover the need for transcoding services in a session and how to invoke those transcoding services. Two models for transcoding services invocation are discussed: the conference bridge model and the third-party call control model. Both models meet the requirements for SIP regarding transcoding services invocation to support deaf, hard of hearing, and speech-impaired individuals. |
|
| |
| RFC 5375 | IPv6 Unicast Address Assignment Considerations |
| |
| Authors: | G. Van de Velde, C. Popoviciu, T. Chown, O. Bonness, C. Hahn. |
| Date: | December 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5375 |
|
One fundamental aspect of any IP communications infrastructure is its addressing plan. With its new address architecture and allocation policies, the introduction of IPv6 into a network means that network designers and operators need to reconsider their existing approaches to network addressing. Lack of guidelines on handling this aspect of network design could slow down the deployment and integration ofIPv6. This document aims to provide the information and recommendations relevant to planning the addressing aspects of IPv6 deployments. The document also provides IPv6 addressing case studies for both an enterprise and an ISP network. |
|
| |
| RFC 5376 | Inter-AS Requirements for the Path Computation Element Communication Protocol (PCECP) |
| |
| Authors: | N. Bitar, R. Zhang, K. Kumaki. |
| Date: | November 2008 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5376 |
|
Multiprotocol Label Switching Traffic Engineered (MPLS TE) LabelSwitched Paths (LSPs) may be established wholly within an AutonomousSystem (AS) or may cross AS boundaries.
The Path Computation Element (PCE) is a component that is capable of computing constrained paths for (G)MPLS TE LSPs. The PCECommunication Protocol (PCECP) is defined to allow communication between Path Computation Clients (PCCs) and PCEs, as well as betweenPCEs. The PCECP is used to request constrained paths and to supply computed paths in response. Generic requirements for the PCECP are set out in "Path Computation Element (PCE) Communication ProtocolGeneric Requirements", RFC 4657. This document extends those requirements to cover the use of PCECP in support of inter-AS MPLSTE. |
|
| |
| RFC 5377 | Advice to the Trustees of the IETF Trust on Rights to Be Granted in IETF Documents |
| |
|
|
Contributors grant intellectual property rights to the IETF. TheIETF Trust holds and manages those rights on behalf of the IETF. TheTrustees of the IETF Trust are responsible for that management. This management includes granting the licenses to copy, implement, and otherwise use IETF Contributions, among them Internet-Drafts andRFCs. The Trustees of the IETF Trust accepts direction from the IETF regarding the rights to be granted. This document describes the desires of the IETF regarding outbound rights to be granted in IETFContributions. |
|
| |
| RFC 5379 | Guidelines for Using the Privacy Mechanism for SIP |
| |
| Authors: | M. Munakata, S. Schubert, T. Ohba. |
| Date: | February 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5379 |
|
This is an informational document that provides guidelines for using the privacy mechanism for the Session Initiation Protocol (SIP) that is specified in RFC 3323 and subsequently extended in RFCs 3325 and4244. It is intended to clarify the handling of the target SIP headers/parameters and the Session Description Protocol (SDP) parameters for each of the privacy header values (priv-values). |
|
| |
| RFC 5381 | Experience of Implementing NETCONF over SOAP |
| |
| Authors: | T. Iijima, Y. Atarashi, H. Kimura, M. Kitani, H. Okita. |
| Date: | October 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5381 |
|
This document describes how the authors developed a SOAP (SimpleObject Access Protocol)-based NETCONF (Network ConfigurationProtocol) client and server. It describes an alternative SOAP binding for NETCONF that does not interoperate with an RFC 4743 conformant implementation making use of cookies on top of the persistent transport connections of HTTP. When SOAP is used as a transport protocol for NETCONF, various kinds of development tools are available. By making full use of these tools, developers can significantly reduce their workload. The authors developed an NMS(Network Management System) and network equipment that can deal withNETCONF messages sent over SOAP. This document aims to provideNETCONF development guidelines gained from the experience of implementing a SOAP-based NETCONF client and server. |
|
| |
| RFC 5385 | Version 2.0 Microsoft Word Template for Creating Internet Drafts and RFCs |
| |
|
|
This document describes the properties and use of a revised MicrosoftWord template (.dot) for writing Internet Drafts and RFCs. It replaces the initial template described in RFC 3285 to more fully support Word's outline modes and to be easier to use. This template can be direct-printed and direct-viewed, where either is line-for- line identical with RFC Editor-compliant ASCII output. This version obsoletes RFC 3285.
The most recent version of this template and post-processing scripts are available at http://www.isi.edu/touch/tools. |
|
| |
| RFC 5387 | Problem and Applicability Statement for Better-Than-Nothing Security (BTNS) |
| |
| Authors: | J. Touch, D. Black, Y. Wang. |
| Date: | November 2008 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5387 |
|
The Internet network security protocol suite, IPsec, requires authentication, usually of network-layer entities, to enable access control and provide security services. This authentication can be based on mechanisms such as pre-shared symmetric keys, certificates with associated asymmetric keys, or the use of Kerberos (viaKerberized Internet Negotiation of Keys (KINK)). The need to deploy authentication information and its associated identities can be a significant obstacle to the use of IPsec.
This document explains the rationale for extending the Internet network security protocol suite to enable use of IPsec security services without authentication. These extensions are intended to protect communication, providing "better-than-nothing security"(BTNS). The extensions may be used on their own (this use is calledStand-Alone BTNS, or SAB) or may be used to provide network-layer security that can be authenticated by higher layers in the protocol stack (this use is called Channel-Bound BTNS, or CBB). The document also explains situations for which use of SAB and/or CBB extensions are applicable. |
|
| |
| RFC 5390 | Requirements for Management of Overload in the Session Initiation Protocol |
| |
| Authors: | J. Rosenberg. |
| Date: | December 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5390 |
|
Overload occurs in Session Initiation Protocol (SIP) networks when proxies and user agents have insufficient resources to complete the processing of a request. SIP provides limited support for overload handling through its 503 response code, which tells an upstream element that it is overloaded. However, numerous problems have been identified with this mechanism. This document summarizes the problems with the existing 503 mechanism, and provides some requirements for a solution. |
|
| |
| RFC 5394 | Policy-Enabled Path Computation Framework |
| |
| Authors: | I. Bryskin, D. Papadimitriou, L. Berger, J. Ash. |
| Date: | December 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5394 |
|
The Path Computation Element (PCE) architecture introduces the concept of policy in the context of path computation. This document provides additional details on policy within the PCE architecture and also provides context for the support of PCE Policy. This document introduces the use of the Policy Core Information Model (PCIM) as a framework for supporting path computation policy. This document also provides representative scenarios for the support of PCE Policy. |
|
| |
| RFC 5398 | Autonomous System (AS) Number Reservation for Documentation Use |
| |
| Authors: | G. Huston. |
| Date: | December 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5398 |
|
To reduce the likelihood of conflict and confusion when relating documented examples to deployed systems, two blocks of AutonomousSystem numbers (ASNs) are reserved for use in examples in RFCs, books, documentation, and the like. This document describes the reservation of two blocks of ASNs as reserved numbers for use in documentation. |
|
| |
| RFC 5402 | Compressed Data within an Internet Electronic Data Interchange (EDI) Message |
| |
| Authors: | T. Harding, Ed.. |
| Date: | February 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5402 |
|
This document explains the rules and procedures for utilizing compression (RFC 3274) within an Internet EDI (Electronic DataInterchange) 'AS' message, as defined in RFCs 3335, 4130, and 4823. |
|
| |
| RFC 5408 | Identity-Based Encryption Architecture and Supporting Data Structures |
| |
| Authors: | G. Appenzeller, L. Martin, M. Schertler. |
| Date: | January 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5408 |
|
This document describes the security architecture required to implement identity-based encryption, a public-key encryption technology that uses a user's identity as a public key. It also defines data structures that can be used to implement the technology. |
|
| |
| RFC 5409 | Using the Boneh-Franklin and Boneh-Boyen Identity-Based Encryption Algorithms with the Cryptographic Message Syntax (CMS) |
| |
| Authors: | L. Martin, M. Schertler. |
| Date: | January 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5409 |
|
This document describes the conventions for using the Boneh-Franklin(BF) and Boneh-Boyen (BB1) identity-based encryption algorithms in the Cryptographic Message Syntax (CMS) to encrypt content-encryption keys. Object identifiers and the convention for encoding a recipient's identity are also defined. |
|
| |
| RFC 5410 | Multimedia Internet KEYing (MIKEY) General Extension Payload for Open Mobile Alliance BCAST 1.0 |
| |
|
|
This document specifies a new Multimedia Internet KEYing (MIKEY)General Extension payload to transport the short-term key message(STKM) and long-term key message (LTKM) payloads as well as the management data LTKM reporting message and parental control message payloads defined in the Open Mobile Alliance's (OMA) Broadcast(BCAST) group's Service and Content protection specification. |
|
| |
| RFC 5411 | A Hitchhiker's Guide to the Session Initiation Protocol (SIP) |
| |
| Authors: | J. Rosenberg. |
| Date: | February 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5411 |
|
The Session Initiation Protocol (SIP) is the subject of numerous specifications that have been produced by the IETF. It can be difficult to locate the right document, or even to determine the set of Request for Comments (RFC) about SIP. This specification serves as a guide to the SIP RFC series. It lists a current snapshot of the specifications under the SIP umbrella, briefly summarizes each, and groups them into categories. |
|
| |
| RFC 5418 | Control And Provisioning of Wireless Access Points (CAPWAP) Threat Analysis for IEEE 802.11 Deployments |
| |
| Authors: | S. Kelly, T. Clancy. |
| Date: | March 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5418 |
|
Early Wireless Local Area Network (WLAN) deployments feature a "fat"Access Point (AP), which serves as a stand-alone interface between the wired and wireless network segments. However, this model raises scaling, mobility, and manageability issues, and the Control andProvisioning of Wireless Access Points (CAPWAP) protocol is meant to address these issues. CAPWAP effectively splits the fat AP functionality into two network elements, and the communication channel between these components may traverse potentially hostile hops. This document analyzes the security exposure resulting from the introduction of CAPWAP and summarizes the associated security considerations for IEEE 802.11-based CAPWAP implementations and deployments. |
|
| |
| RFC 5419 | Why the Authentication Data Suboption is Needed for Mobile IPv6 (MIPv6) |
| |
| Authors: | B. Patil, G. Dommety. |
| Date: | January 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5419 |
|
Mobile IPv6 defines a set of signaling messages that enable the mobile node (MN) to authenticate and perform registration with its home agent (HA). These authentication signaling messages between the mobile node and home agent are secured by an IPsec security association (SA) that is established between the MN and HA. The MIP6 working group has specified a mechanism to secure the Binding Update(BU) and Binding Acknowledgement (BAck) messages using an authentication option, similar to the authentication option in MobileIPv4, carried within the signaling messages that are exchanged between the MN and HA to establish a binding. This document provides the justifications as to why the authentication option mechanism is needed for Mobile IPv6 deployment in certain environments. |
|
| |
| RFC 5421 | Basic Password Exchange within the Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST) |
| |
| Authors: | N. Cam-Winget, H. Zhou. |
| Date: | March 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5421 |
|
The Flexible Authentication via Secure Tunneling ExtensibleAuthentication Protocol (EAP-FAST) method enables secure communication between a peer and a server by using Transport LayerSecurity (TLS) to establish a mutually authenticated tunnel. Within this tunnel, a basic password exchange, based on the Generic TokenCard method (EAP-GTC), may be executed to authenticate the peer. |
|
| |
| RFC 5422 | Dynamic Provisioning Using Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST) |
| |
| Authors: | N. Cam-Winget, D. McGrew, J. Salowey, H. Zhou. |
| Date: | March 2009 |
| Formats: | txt json html |
| Updated by: | RFC 8996 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5422 |
|
The Flexible Authentication via Secure Tunneling ExtensibleAuthentication Protocol (EAP-FAST) method enables secure communication between a peer and a server by using Transport LayerSecurity (TLS) to establish a mutually authenticated tunnel. EAP-FAST also enables the provisioning credentials or other information through this protected tunnel. This document describes the use ofEAP-FAST for dynamic provisioning. |
|
| |
| RFC 5431 | Diameter ITU-T Rw Policy Enforcement Interface Application |
| |
| Authors: | D. Sun. |
| Date: | March 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5431 |
|
This document describes the need for a new pair of IANA DiameterCommand Codes to be used in a vendor-specific new application, namely for the ITU-T Rec. Q.3303.3 - Rw interface used to send a request/ response for authorizing network Quality of Service (QoS) resources and policy enforcement in a network element, as one of the recommendations of the International Telecommunication Union -Telecommunication Standardization Sector (ITU-T). |
|
| |
| RFC 5434 | Considerations for Having a Successful Birds-of-a-Feather (BOF) Session |
| |
| Authors: | T. Narten. |
| Date: | February 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5434 |
|
This document discusses tactics and strategy for hosting a successfulIETF Birds-of-a-Feather (BOF) session, especially one oriented at the formation of an IETF Working Group. It is based on the experiences of having participated in numerous BOFs, both successful and unsuccessful. |
|
| |
| RFC 5439 | An Analysis of Scaling Issues in MPLS-TE Core Networks |
| |
| Authors: | S. Yasukawa, A. Farrel, O. Komolafe. |
| Date: | February 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5439 |
|
Traffic engineered Multiprotocol Label Switching (MPLS-TE) is deployed in providers' core networks. As providers plan to grow these networks, they need to understand whether existing protocols and implementations can support the network sizes that they are planning.
This document presents an analysis of some of the scaling concerns for the number of Label Switching Paths (LSPs) in MPLS-TE core networks, and examines the value of two techniques (LSP hierarchies and multipoint-to-point LSPs) for improving scaling. The intention is to motivate the development of appropriate deployment techniques and protocol extensions to enable the application of MPLS-TE in large networks.
This document only considers the question of achieving scalability for the support of point-to-point MPLS-TE LSPs. Point-to-multipointMPLS-TE LSPs are for future study. |
|
| |
| RFC 5442 | LEMONADE Architecture - Supporting Open Mobile Alliance (OMA) Mobile Email (MEM) Using Internet Mail |
| |
| Authors: | E. Burger, G. Parsons. |
| Date: | March 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5442 |
|
This document specifies the architecture for mobile email, as described by the Open Mobile Alliance (OMA), using Internet Mail protocols. This architecture was an important consideration for much of the work of the LEMONADE (Enhancements to Internet email toSupport Diverse Service Environments) working group in the IETF.This document also describes how the LEMONADE architecture meetsOMA's requirements for their Mobile Email (MEM) service. |
|
| |
| RFC 5443 | LDP IGP Synchronization |
| |
| Authors: | M. Jork, A. Atlas, L. Fang. |
| Date: | March 2009 |
| Formats: | txt html json |
| Updated by: | RFC 6138 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5443 |
|
In certain networks, there is dependency on the edge-to-edge LabelSwitched Paths (LSPs) setup by the Label Distribution Protocol (LDP), e.g., networks that are used for Multiprotocol Label Switching (MPLS)Virtual Private Network (VPN) applications. For such applications, it is not possible to rely on Internet Protocol (IP) forwarding if the MPLS LSP is not operating appropriately. Blackholing of labeled traffic can occur in situations where the Interior Gateway Protocol(IGP) is operational on a link on which LDP is not. While the link could still be used for IP forwarding, it is not useful for MPLS forwarding, for example, MPLS VPN applications or Border GatewayProtocol (BGP) route-free cores. This document describes a mechanism to avoid traffic loss due to this condition without introducing any protocol changes. |
|
| |
| RFC 5446 | Service Selection for Mobile IPv4 |
| |
| Authors: | J. Korhonen, U. Nilsson. |
| Date: | February 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5446 |
|
In some Mobile IPv4 deployments, identifying the mobile node or the mobility service subscriber is not enough to distinguish among the multiple services possibly provisioned to the mobile node. The capability to specify different services in addition to the mobile node's identity can be leveraged to provide flexibility for mobility service providers to provide multiple services within a single mobility service subscription. This document describes a ServiceSelection extension for Mobile IPv4 that is intended to assist home agents to make specific service selections for their mobility service subscriptions during the registration procedure. |
|
| |
| RFC 5448 | Improved Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA') |
| |
|
|
This specification defines a new EAP method, EAP-AKA', which is a small revision of the EAP-AKA (Extensible Authentication ProtocolMethod for 3rd Generation Authentication and Key Agreement) method.The change is a new key derivation function that binds the keys derived within the method to the name of the access network. The new key derivation mechanism has been defined in the 3rd GenerationPartnership Project (3GPP). This specification allows its use in EAP in an interoperable manner. In addition, EAP-AKA' employs SHA-256 instead of SHA-1.
This specification also updates RFC 4187, EAP-AKA, to prevent bidding down attacks from EAP-AKA'. |
|
| |
| RFC 5456 | IAX: Inter-Asterisk eXchange Version 2 |
| |
| Authors: | M. Spencer, B. Capouch, E. Guy, Ed., F. Miller, K. Shumard. |
| Date: | February 2010 |
| Formats: | txt html json |
| Updated by: | RFC 8996 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5456 |
|
This document describes IAX, the Inter-Asterisk eXchange protocol, an application-layer control and media protocol for creating, modifying, and terminating multimedia sessions over Internet Protocol (IP) networks. IAX was developed by the open source community for theAsterisk Private Branch Exchange (PBX) and is targeted primarily atVoice over Internet Protocol (VoIP) call control, but it can be used with streaming video or any other type of multimedia.
IAX is an "all in one" protocol for handling multimedia in IP networks. It combines both control and media services in the same protocol. In addition, IAX uses a single UDP data stream on a static port greatly simplifying Network Address Translation (NAT) gateway traversal, eliminating the need for other protocols to work aroundNAT, and simplifying network and firewall management. IAX employs a compact encoding that decreases bandwidth usage and is well suited for Internet telephony service. In addition, its open nature permits new payload type additions needed to support additional services. |
|
| |
| RFC 5457 | IANA Considerations for IAX: Inter-Asterisk eXchange Version 2 |
| |
| Authors: | E. Guy, Ed.. |
| Date: | February 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5457 |
|
This document establishes the IANA registries for IAX, the Inter-Asterisk eXchange protocol, an application-layer control and media protocol for creating, modifying, and terminating multimedia sessions over Internet Protocol (IP) networks. IAX was developed by the open source community for the Asterisk PBX and is targeted primarily atVoice over Internet Protocol (VoIP) call control, but it can be used with streaming video or any other type of multimedia. |
|
| |
| RFC 5458 | Security Requirements for the Unidirectional Lightweight Encapsulation (ULE) Protocol |
| |
| Authors: | H. Cruickshank, P. Pillai, M. Noisternig, S. Iyengar. |
| Date: | March 2009 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5458 |
|
The MPEG-2 standard defined by ISO 13818-1 supports a range of transmission methods for a variety of services. This document provides a threat analysis and derives the security requirements when using the Transport Stream, TS, to support an Internet network-layer using Unidirectional Lightweight Encapsulation (ULE) defined in RFC4326. The document also provides the motivation for link-layer security for a ULE Stream. A ULE Stream may be used to send IPv4 packets, IPv6 packets, and other Protocol Data Units (PDUs) to an arbitrarily large number of Receivers supporting unicast and/or multicast transmission.
The analysis also describes applicability to the Generic StreamEncapsulation (GSE) defined by the Digital Video Broadcasting (DVB)Project. |
|
| |
| RFC 5461 | TCP's Reaction to Soft Errors |
| |
| Authors: | F. Gont. |
| Date: | February 2009 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5461 |
|
This document describes a non-standard, but widely implemented, modification to TCP's handling of ICMP soft error messages that rejects pending connection-requests when those error messages are received. This behavior reduces the likelihood of long delays between connection-establishment attempts that may arise in a number of scenarios, including one in which dual-stack nodes that have IPv6 enabled by default are deployed in IPv4 or mixed IPv4 and IPv6 environments. |
|
| |
| RFC 5468 | Performance Analysis of Inter-Domain Path Computation Methodologies |
| |
| Authors: | S. Dasgupta, J. de Oliveira, JP. Vasseur. |
| Date: | April 2009 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5468 |
|
This document presents a performance comparison between the per- domain path computation method and the Path Computation Element (PCE)Architecture-based Backward Recursive Path Computation (BRPC) procedure. Metrics to capture the significant performance aspects are identified, and detailed simulations are carried out on realistic scenarios. A performance analysis for each of the path computation methods is then undertaken. |
|
| |
| RFC 5470 | Architecture for IP Flow Information Export |
| |
| Authors: | G. Sadasivan, N. Brownlee, B. Claise, J. Quittek. |
| Date: | March 2009 |
| Formats: | txt json html |
| Updated by: | RFC 6183 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5470 |
|
This memo defines the IP Flow Information eXport (IPFIX) architecture for the selective monitoring of IP Flows, and for the export of measured IP Flow information from an IPFIX Device to a Collector. |
|
| |
| RFC 5471 | Guidelines for IP Flow Information Export (IPFIX) Testing |
| |
| Authors: | C. Schmoll, P. Aitken, B. Claise. |
| Date: | March 2009 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5471 |
|
This document presents a list of tests for implementers of IP FlowInformation eXport (IPFIX) compliant Exporting Processes andCollecting Processes. This document specifies guidelines for a series of tests that can be run on the IPFIX Exporting Process andCollecting Process in order to probe the conformity and robustness of the IPFIX protocol implementations. These tests cover all important functions, in order to gain a level of confidence in the IPFIX implementation. Therefore, they allow the implementer to perform interoperability or plug tests with other IPFIX Exporting Processes and Collecting Processes. |
|
| |
| RFC 5472 | IP Flow Information Export (IPFIX) Applicability |
| |
| Authors: | T. Zseby, E. Boschi, N. Brownlee, B. Claise. |
| Date: | March 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5472 |
|
In this document, we describe the applicability of the IP FlowInformation eXport (IPFIX) protocol for a variety of applications.We show how applications can use IPFIX, describe the relevantInformation Elements (IEs) for those applications, and present opportunities and limitations of the protocol. Furthermore, we describe relations of the IPFIX framework to other architectures and frameworks. |
|
| |
| RFC 5473 | Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports |
| |
| Authors: | E. Boschi, L. Mark, B. Claise. |
| Date: | March 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5473 |
|
This document describes a bandwidth saving method for exporting Flow or packet information using the IP Flow Information eXport (IPFIX) protocol. As the Packet Sampling (PSAMP) protocol is based on IPFIX, these considerations are valid for PSAMP exports as well.
This method works by separating information common to several FlowRecords from information specific to an individual Flow Record.Common Flow information is exported only once in a Data Record defined by an Options Template, while the rest of the specific Flow information is associated with the common information via a unique identifier. |
|
| |
| RFC 5474 | A Framework for Packet Selection and Reporting |
| |
| Authors: | N. Duffield, Ed., D. Chiou, B. Claise, A. Greenberg, M. Grossglauser, J. Rexford. |
| Date: | March 2009 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5474 |
|
This document specifies a framework for the PSAMP (Packet SAMPling) protocol. The functions of this protocol are to select packets from a stream according to a set of standardized Selectors, to form a stream of reports on the selected packets, and to export the reports to a Collector. This framework details the components of this architecture, then describes some generic requirements, motivated by the dual aims of ubiquitous deployment and utility of the reports for applications. Detailed requirements for selection, reporting, and exporting are described, along with configuration requirements of thePSAMP functions. |
|
| |
| RFC 5479 | Requirements and Analysis of Media Security Management Protocols |
| |
| Authors: | D. Wing, Ed., S. Fries, H. Tschofenig, F. Audet. |
| Date: | April 2009 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5479 |
|
This document describes requirements for a protocol to negotiate a security context for SIP-signaled Secure RTP (SRTP) media. In addition to the natural security requirements, this negotiation protocol must interoperate well with SIP in certain ways. A number of proposals have been published and a summary of these proposals is in the appendix of this document. |
|
| |
| RFC 5481 | Packet Delay Variation Applicability Statement |
| |
| Authors: | A. Morton, B. Claise. |
| Date: | March 2009 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5481 |
|
Packet delay variation metrics appear in many different standards documents. The metric definition in RFC 3393 has considerable flexibility, and it allows multiple formulations of delay variation through the specification of different packet selection functions.
Although flexibility provides wide coverage and room for new ideas, it can make comparisons of independent implementations more difficult. Two different formulations of delay variation have come into wide use in the context of active measurements. This memo examines a range of circumstances for active measurements of delay variation and their uses, and recommends which of the two forms is best matched to particular conditions and tasks. |
|
| |
| RFC 5483 | ENUM Implementation Issues and Experiences |
| |
| Authors: | L. Conroy, K. Fujiwara. |
| Date: | March 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5483 |
|
This document captures experiences in implementing systems based on the ENUM protocol and experiences of ENUM data that have been created by others. As such, it clarifies the ENUM and Dynamic DelegationDiscovery System standards. Its aim is to help others by reporting both what is "out there" and potential pitfalls in interpreting the set of documents that specify the ENUM protocol. It does not revise the standards but is intended to provide technical input to future revisions of those documents. |
|
| |
| RFC 5485 | Digital Signatures on Internet-Draft Documents |
| |
|
|
This document specifies the conventions for digital signatures onInternet-Drafts. The Cryptographic Message Syntax (CMS) is used to create a detached signature, which is stored in a separate companion file so that no existing utilities are impacted by the addition of the digital signature. |
|
| |
| RFC 5486 | Session Peering for Multimedia Interconnect (SPEERMINT) Terminology |
| |
| Authors: | D. Malas, Ed., D. Meyer, Ed.. |
| Date: | March 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5486 |
|
This document defines the terminology that is to be used in describing Session PEERing for Multimedia INTerconnect (SPEERMINT). |
|
| |
| RFC 5489 | ECDHE_PSK Cipher Suites for Transport Layer Security (TLS) |
| |
| Authors: | M. Badra, I. Hajjeh. |
| Date: | March 2009 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5489 |
|
This document extends RFC 4279, RFC 4492, and RFC 4785 and specifies a set of cipher suites that use a pre-shared key (PSK) to authenticate an Elliptic Curve Diffie-Hellman exchange with Ephemeral keys (ECDHE). These cipher suites provide Perfect Forward Secrecy(PFS). |
|
| |
| RFC 5493 | Requirements for the Conversion between Permanent Connections and Switched Connections in a Generalized Multiprotocol Label Switching (GMPLS) Network |
| |
| Authors: | D. Caviglia, D. Bramanti, D. Li, D. McDysan. |
| Date: | April 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5493 |
|
From a carrier perspective, the possibility of turning a permanent connection (PC) into a soft permanent connection (SPC) and vice versa, without actually affecting data plane traffic being carried over it, is a valuable option. In other terms, such operation can be seen as a way of transferring the ownership and control of an existing and in-use data plane connection between the management plane and the control plane, leaving its data plane state untouched.
This memo sets out the requirements for such procedures within aGeneralized Multiprotocol Label Switching (GMPLS) network. |
|
| |
| RFC 5495 | Description of the Resource Reservation Protocol - Traffic-Engineered (RSVP-TE) Graceful Restart Procedures |
| |
| Authors: | D. Li, J. Gao, A. Satyanarayana, S. Bardalai. |
| Date: | March 2009 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5495 |
|
The Hello message for the Resource Reservation Protocol (RSVP) has been defined to establish and maintain basic signaling node adjacencies for Label Switching Routers (LSRs) participating in aMultiprotocol Label Switching (MPLS) traffic-engineered (TE) network.The Hello message has been extended for use in Generalized MPLS(GMPLS) networks for state recovery of control channel or nodal faults.
The GMPLS protocol definitions for RSVP also allow a restarting node to learn which label it previously allocated for use on a LabelSwitched Path (LSP).
Further RSVP protocol extensions have been defined to enable a restarting node to recover full control plane state by exchangingRSVP messages with its upstream and downstream neighbors.
This document provides an informational clarification of the control plane procedures for a GMPLS network when there are multiple node failures, and describes how full control plane state can be recovered in different scenarios where the order in which the nodes restart is different.
This document does not define any new processes or procedures. All protocol mechanisms are already defined in the referenced documents. |
|
| |
| RFC 5501 | Requirements for Multicast Support in Virtual Private LAN Services |
| |
| Authors: | Y. Kamite, Ed., Y. Wada, Y. Serbest, T. Morin, L. Fang. |
| Date: | March 2009 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5501 |
|
This document provides functional requirements for network solutions that support multicast over Virtual Private LAN Service (VPLS). It specifies requirements both from the end user and service provider standpoints. It is intended that potential solutions will use these requirements as guidelines. |
|
| |
| RFC 5502 | The SIP P-Served-User Private-Header (P-Header) for the 3GPP IP Multimedia (IM) Core Network (CN) Subsystem |
| |
|
|
This document specifies the SIP P-Served-User P-header. This header field addresses an issue that was found in the 3rd GenerationPartnership Project (3GPP) IMS (IP Multimedia Subsystem) between anS-CSCF (Serving Call Session Control Function) and an AS (ApplicationServer) on the ISC (IMS Service Control) interface. This header field conveys the identity of the served user and the session case that applies to this particular communication session and application invocation. |
|
| |
| RFC 5503 | Private Session Initiation Protocol (SIP) Proxy-to-Proxy Extensions for Supporting the PacketCable Distributed Call Signaling Architecture |
| |
| Authors: | F. Andreasen, B. McKibben, B. Marshall. |
| Date: | March 2009 |
| Formats: | txt html json |
| Obsoletes: | RFC 3603 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5503 |
|
In order to deploy a residential telephone service at a very large scale across different domains, it is necessary for trusted elements owned by different service providers to exchange trusted information that conveys customer-specific information and expectations about the parties involved in the call. This document describes private extensions to the Session Initiation Protocol, RFC 3261, for supporting the exchange of customer information and billing information between trusted entities in the PacketCable DistributedCall Signaling Architecture. These extensions provide mechanisms for access network coordination to prevent theft of service, customer originated trace of harassing calls, support for operator services and emergency services, and support for various other regulatory issues. The use of the extensions is only applicable within closed administrative domains, or among federations of administrative domains with previously agreed-upon policies where coordination of charging and other functions is required. |
|
| |
| RFC 5505 | Principles of Internet Host Configuration |
| |
| Authors: | B. Aboba, D. Thaler, L. Andersson, S. Cheshire. |
| Date: | May 2009 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5505 |
|
This document describes principles of Internet host configuration.It covers issues relating to configuration of Internet-layer parameters, as well as parameters affecting higher-layer protocols. |
|
| |
| RFC 5507 | Design Choices When Expanding the DNS |
| |
| Authors: | IAB, P. Faltstrom, Ed., R. Austein, Ed., P. Koch, Ed.. |
| Date: | April 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5507 |
|
This note discusses how to extend the DNS with new data for a new application. DNS extension discussions too often focus on reuse of the TXT Resource Record Type. This document lists different mechanisms to extend the DNS, and concludes that the use of a new DNSResource Record Type is the best solution. |
|
| |
| RFC 5513 | IANA Considerations for Three Letter Acronyms |
| |
| Authors: | A. Farrel. |
| Date: | 1 April 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5513 |
|
Three Letter Acronyms (TLAs) are commonly used to identify components of networks or protocols as designed or specified within the IETF. A common concern is that one acronym may have multiple expansions.While this may not have been an issue in the past, network convergence means that protocols that did not previously operate together are now found in close proximity. This results in contention for acronyms, and confusion in interpretation. Such confusion has the potential to degrade the performance of theInternet as misunderstandings lead to misconfiguration or other operating errors.
Given the growing use of TLAs and the relatively small number available, this document specifies a Badly Construed Proposal (BCP) for the management of a registry of TLAs within the IETF, and the procedures for the allocation of new TLAs from the registry. |
|
| |
| RFC 5515 | Layer 2 Tunneling Protocol (L2TP) Access Line Information Attribute Value Pair (AVP) Extensions |
| |
| Authors: | V. Mammoliti, C. Pignataro, P. Arberg, J. Gibbons, P. Howard. |
| Date: | May 2009 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5515 |
|
This document describes a set of Layer 2 Tunneling Protocol (L2TP)Attribute Value Pair (AVP) extensions designed to carry the subscriber Access Line identification and characterization information that arrives at the Broadband Remote Access Server (BRAS) with L2TP Access Concentrator (LAC) functionality. It also describes a mechanism to report connection speed changes, after the initial connection speeds are sent during session establishment. The primary purpose of this document is to provide a reference for DSL equipment vendors wishing to interoperate with other vendors' products. TheL2TP AVPs defined in this document are applicable to both L2TPv2 andL2TPv3. |
|
| |
| RFC 5516 | Diameter Command Code Registration for the Third Generation Partnership Project (3GPP) Evolved Packet System (EPS) |
| |
| Authors: | M. Jones, L. Morand. |
| Date: | April 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5516 |
|
This document registers a set of IANA Diameter Command Codes to be used in new vendor-specific Diameter applications defined for theThird Generation Partnership Project (3GPP) Evolved Packet System(EPS). These new Diameter applications are defined for MobileManagement Entity (MME)- and Serving GPRS (General Packet RadioService) Support Node (SGSN)-related interfaces in in the architecture for the Evolved 3GPP Packet Switched Domain, which is also known as the Evolved Packet System (EPS). |
|
| |
| RFC 5517 | Cisco Systems' Private VLANs: Scalable Security in a Multi-Client Environment |
| |
| Authors: | S. HomChaudhuri, M. Foschiano. |
| Date: | February 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5517 |
|
This document describes a mechanism to achieve device isolation through the application of special Layer 2 forwarding constraints.Such a mechanism allows end devices to share the same IP subnet while being Layer 2 isolated, which in turn allows network designers to employ larger subnets and so reduce the address management overhead.
Some of the numerous deployment scenarios of the aforementioned mechanism (which range from data center designs to Ethernet-to-the- home-basement networks) are mentioned in the following text to exemplify the mechanism's possible usages; however, this document is not intended to cover all such deployment scenarios nor delve into their details. |
|
| |
| RFC 5522 | Network Mobility Route Optimization Requirements for Operational Use in Aeronautics and Space Exploration Mobile Networks |
| |
| Authors: | W. Eddy, W. Ivancic, T. Davis. |
| Date: | October 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5522 |
|
This document describes the requirements and desired properties ofNetwork Mobility (NEMO) Route Optimization techniques for use in global-networked communications systems for aeronautics and space exploration.
Substantial input to these requirements was given by aeronautical communications experts outside the IETF, including members of theInternational Civil Aviation Organization (ICAO) and other aeronautical communications standards bodies. |
|
| |
| RFC 5526 | The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application for Infrastructure ENUM |
| |
| Authors: | J. Livingood, P. Pfautz, R. Stastny. |
| Date: | April 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5526 |
|
This document defines the use case for Infrastructure ENUM and proposes its implementation as a parallel namespace to "e164.arpa", as defined in RFC 3761, as the long-term solution to the problem of allowing carriers to provision DNS records for telephone numbers independently of those provisioned by end users (number assignees). |
|
| |
| RFC 5527 | Combined User and Infrastructure ENUM in the e164.arpa Tree |
| |
| Authors: | M. Haberler, O. Lendl, R. Stastny. |
| Date: | May 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5527 |
|
This memo defines an interim solution for Infrastructure ENUM in order to allow a combined User and Infrastructure ENUM implementation in e164.arpa as a national choice. This interim solution will be deprecated after implementation of the long-term solution. |
|
| |
| RFC 5528 | Camellia Counter Mode and Camellia Counter with CBC-MAC Mode Algorithms |
| |
| Authors: | A. Kato, M. Kanda, S. Kanno. |
| Date: | April 2009 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5528 |
|
This document describes the algorithms and presents test vectors for the Camellia block cipher algorithm in Counter mode (CTR) and Counter with Cipher Block Chaining MAC mode (CCM). The purpose of this document is to make the Camellia-CTR and Camellia-CCM algorithm conveniently available to the Internet Community. |
|
| |
| RFC 5532 | Network File System (NFS) Remote Direct Memory Access (RDMA) Problem Statement |
| |
| Authors: | T. Talpey, C. Juszczak. |
| Date: | May 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5532 |
|
This document addresses enabling the use of Remote Direct MemoryAccess (RDMA) by the Network File System (NFS) protocols. NFS implementations historically incur significant overhead due to data copies on end-host systems, as well as other processing overhead.This document explores the potential benefits of RDMA to these implementations and evaluates the reasons why RDMA is especially well-suited to NFS and network file protocols in general. |
|
| |
| RFC 5540 | 40 Years of RFCs |
| |
|
|
This RFC marks the 40th anniversary of the RFC document series. |
|
| |
| RFC 5544 | 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. |
|
| |
| RFC 5548 | Routing Requirements for Urban Low-Power and Lossy Networks |
| |
| Authors: | M. Dohler, Ed., T. Watteyne, Ed., T. Winter, Ed., D. Barthel, Ed.. |
| Date: | May 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5548 |
|
The application-specific routing requirements for Urban Low-Power andLossy Networks (U-LLNs) are presented in this document. In the near future, sensing and actuating nodes will be placed outdoors in urban environments so as to improve people's living conditions as well as to monitor compliance with increasingly strict environmental laws.These field nodes are expected to measure and report a wide gamut of data (for example, the data required by applications that perform smart-metering or that monitor meteorological, pollution, and allergy conditions). The majority of these nodes are expected to communicate wirelessly over a variety of links such as IEEE 802.15.4, low-powerIEEE 802.11, or IEEE 802.15.1 (Bluetooth), which given the limited radio range and the large number of nodes requires the use of suitable routing protocols. The design of such protocols will be mainly impacted by the limited resources of the nodes (memory, processing power, battery, etc.) and the particularities of the outdoor urban application scenarios. As such, for a wireless solution for Routing Over Low-Power and Lossy (ROLL) networks to be useful, the protocol(s) ought to be energy-efficient, scalable, and autonomous. This documents aims to specify a set of IPv6 routing requirements reflecting these and further U-LLNs' tailored characteristics. |
|
| |
| RFC 5551 | Lemonade Notifications Architecture |
| |
| Authors: | R. Gellens, Ed.. |
| Date: | August 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5551 |
|
Notification and filtering mechanisms can make email more enjoyable on mobile and other constrained devices (such as those with limited screen sizes, memory, data transfer rates, etc.). Notifications make the client aware of significant events (such as the arrival of new mail) so it can react (such as by fetching interesting mail immediately). Filtering reduces the visible mail to a set of messages that meet some criteria for "interesting". This functionality is included in the goals of the Lemonade (Enhancements to Internet email to Support Diverse Service Environments) WorkingGroup.
This document also discusses the use of server-to-server notifications, and how server to server notifications fit into an architecture that provides server to client notifications. |
|
| |
| RFC 5556 | Transparent Interconnection of Lots of Links (TRILL): Problem and Applicability Statement |
| |
| Authors: | J. Touch, R. Perlman. |
| Date: | May 2009 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5556 |
|
Current IEEE 802.1 LANs use spanning tree protocols that have a number of challenges. These protocols need to strictly avoid loops, even temporary ones, during route propagation, because of the lack of header loop detection support. Routing tends not to take full advantage of alternate paths, or even non-overlapping pairwise paths(in the case of spanning trees). This document addresses these concerns and suggests applying modern network-layer routing protocols at the link layer. This document assumes that solutions would not address issues of scalability beyond that of existing IEEE 802.1 bridged links, but that a solution would be backward compatible with802.1, including hubs, bridges, and their existing plug-and-play capabilities. |
|
| |
| RFC 5558 | Virtual Enterprise Traversal (VET) |
| |
| Authors: | F. Templin, Ed.. |
| Date: | February 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5558 |
|
Enterprise networks connect routers over various link types, and may also connect to provider networks and/or the global Internet.Enterprise network nodes require a means to automatically provisionIP addresses/prefixes and support internetworking operation in a wide variety of use cases including Small Office, Home Office (SOHO) networks, Mobile Ad hoc Networks (MANETs), multi-organizational corporate networks and the interdomain core of the global Internet itself. This document specifies a Virtual Enterprise Traversal (VET) abstraction for autoconfiguration and operation of nodes in enterprise networks. |
|
| |
| RFC 5559 | Pre-Congestion Notification (PCN) Architecture |
| |
| Authors: | P. Eardley, Ed.. |
| Date: | June 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5559 |
|
This document describes a general architecture for flow admission and termination based on pre-congestion information in order to protect the quality of service of established, inelastic flows within a single Diffserv domain. |
|
| |
| RFC 5563 | WiMAX Forum / 3GPP2 Proxy Mobile IPv4 |
| |
| Authors: | K. Leung, G. Dommety, P. Yegani, K. Chowdhury. |
| Date: | February 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5563 |
|
Mobile IPv4 is a standard mobility protocol that enables an IPv4 device to move among networks while maintaining its IP address. The mobile device has the Mobile IPv4 client function to signal its location to the routing anchor, known as the Home Agent. However, there are many IPv4 devices without such capability due to various reasons. This document describes Proxy Mobile IPv4 (PMIPv4), a scheme based on having the Mobile IPv4 client function in a network entity to provide mobility support for an unaltered and mobility- unaware IPv4 device. This document also describes a particular application of PMIPv4 as specified in the WiMAX Forum and another application that is to be adopted in 3GPP2. |
|
| |
| RFC 5564 | Linguistic Guidelines for the Use of the Arabic Language in Internet Domains |
| |
| Authors: | A. El-Sherbiny, M. Farah, I. Oueichek, A. Al-Zoman. |
| Date: | February 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5564 |
|
This document constitutes technical specifications for the use ofArabic in Internet domain names and provides linguistic guidelines for Arabic domain names. It addresses Arabic-specific linguistic issues pertaining to the use of Arabic language in domain names. |
|
| |
| RFC 5567 | An Architectural Framework for Media Server Control |
| |
| Authors: | T. Melanchuk, Ed.. |
| Date: | June 2009 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5567 |
|
This document describes an architectural framework for Media Server control. The primary focus will be to define logical entities that exist within the context of Media Server control, and define the appropriate naming conventions and interactions between them. |
|
| |
| RFC 5569 | IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) |
| |
| Authors: | R. Despres. |
| Date: | January 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5569 |
|
IPv6 rapid deployment on IPv4 infrastructures (6rd) builds upon mechanisms of 6to4 to enable a service provider to rapidly deployIPv6 unicast service to IPv4 sites to which it provides customer premise equipment. Like 6to4, it utilizes stateless IPv6 in IPv4 encapsulation in order to transit IPv4-only network infrastructure.Unlike 6to4, a 6rd service provider uses an IPv6 prefix of its own in place of the fixed 6to4 prefix. A service provider has used this mechanism for its own IPv6 "rapid deployment": five weeks from first exposure to 6rd principles to more than 1,500,000 residential sites being provided native IPv6, under the only condition that they activate it. |
|
| |
| RFC 5570 | Common Architecture Label IPv6 Security Option (CALIPSO) |
| |
| Authors: | M. StJohns, R. Atkinson, G. Thomas. |
| Date: | July 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5570 |
|
This document describes an optional method for encoding explicit packet Sensitivity Labels on IPv6 packets. It is intended for use only within Multi-Level Secure (MLS) networking environments that are both trusted and trustworthy. |
|
| |
| RFC 5578 | PPP over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics |
| |
| Authors: | B. Berry, Ed., S. Ratliff, E. Paradise, T. Kaiser, M. Adams. |
| Date: | February 2010 |
| Formats: | txt html json |
| Obsoletes: | RFC 4938 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5578 |
|
This document extends the Point-to-Point Protocol over Ethernet(PPPoE) with an optional credit-based flow control mechanism and an optional Link Quality Metric report. These optional extensions improve the performance of PPPoE over media with variable bandwidth and limited buffering, such as mobile point-to-point radio links. |
|
| |
| RFC 5579 | Transmission of IPv4 Packets over Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) Interfaces |
| |
| Authors: | F. Templin, Ed.. |
| Date: | February 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5579 |
|
The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) specifies a Non-Broadcast, Multiple Access (NBMA) interface type for the transmission of IPv6 packets over IPv4 networks using automaticIPv6-in-IPv4 encapsulation. The original specifications make no provisions for the encapsulation and transmission of IPv4 packets, however. This document specifies a method for transmitting IPv4 packets over ISATAP interfaces. |
|
| |
| RFC 5581 | The Camellia Cipher in OpenPGP |
| |
|
|
This document presents the necessary information to use the Camellia symmetric block cipher in the OpenPGP protocol. |
|
| |
| RFC 5582 | Location-to-URL Mapping Architecture and Framework |
| |
| Authors: | H. Schulzrinne. |
| Date: | September 2009 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5582 |
|
|
|
| |
| RFC 5585 | DomainKeys Identified Mail (DKIM) Service Overview |
| |
| Authors: | T. Hansen, D. Crocker, P. Hallam-Baker. |
| Date: | July 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5585 |
|
This document provides an overview of the DomainKeys Identified Mail(DKIM) service and describes how it can fit into a messaging service.It also describes how DKIM relates to other IETF message signature technologies. It is intended for those who are adopting, developing, or deploying DKIM. DKIM allows an organization to take responsibility for transmitting a message, in a way that can be verified by a recipient. The organization can be the author's, the originating sending site, an intermediary, or one of their agents. A message can contain multiple signatures from the same or different organizations involved with the message. DKIM defines a domain-level digital signature authentication framework for email, using public- key cryptography, with the domain name service as its key server technology (RFC 4871). This permits verification of a responsible organization, as well as the integrity of the message contents. DKIM also enables a mechanism that permits potential email signers to publish information about their email signing practices; this will permit email receivers to make additional assessments about messages.DKIM's authentication of email identity can assist in the global control of "spam" and "phishing". |
|
| |
| RFC 5594 | Report from the IETF Workshop on Peer-to-Peer (P2P) Infrastructure, May 28, 2008 |
| |
| Authors: | J. Peterson, A. Cooper. |
| Date: | July 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5594 |
|
This document reports the outcome of a workshop organized by theReal-time Applications and Infrastructure Area Directors of the IETF to discuss network delay and congestion issues resulting from increased Peer-to-Peer (P2P) traffic volumes. The workshop was held on May 28, 2008 at MIT in Cambridge, MA, USA. The goals of the workshop were twofold: to understand the technical problems that ISPs and end users are experiencing as a result of high volumes of P2P traffic, and to begin to understand how the IETF may be helpful in addressing these problems. Gaining an understanding of where in theIETF this work might be pursued and how to extract feasible work items were highlighted as important tasks in pursuit of the latter goal. The workshop was very well attended and produced several work items that have since been taken up by members of the IETF community. |
|
| |
| RFC 5598 | Internet Mail Architecture |
| |
|
|
Over its thirty-five-year history, Internet Mail has changed significantly in scale and complexity, as it has become a global infrastructure service. These changes have been evolutionary, rather than revolutionary, reflecting a strong desire to preserve both its installed base and its usefulness. To collaborate productively on this large and complex system, all participants need to work from a common view of it and use a common language to describe its components and the interactions among them. But the many differences in perspective currently make it difficult to know exactly what another participant means. To serve as the necessary common frame of reference, this document describes the enhanced Internet Mail architecture, reflecting the current service. |
|
| |
| RFC 5606 | Implications of 'retransmission-allowed' for SIP Location Conveyance |
| |
| Authors: | J. Peterson, T. Hardie, J. Morris. |
| Date: | August 2009 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5606 |
|
This document explores an ambiguity in the interpretation of the<retransmission-allowed&rt; element of the Presence Information DataFormat for Location Objects (PIDF-LO) in cases where PIDF-LO is conveyed by the Session Initiation Protocol (SIP). It provides recommendations for how the SIP location conveyance mechanism should adapt to this ambiguity.
Documents standardizing the SIP location conveyance mechanisms will be Standards-Track documents processed according to the usual SIP process. This document is intended primarily to provide the SIP working group with a statement of the consensus of the GEOPRIV working group on this topic. It secondarily provides tutorial information on the problem space for the general reader. |
|
| |
| RFC 5609 | State Machines for the Protocol for Carrying Authentication for Network Access (PANA) |
| |
| Authors: | V. Fajardo, Ed., Y. Ohba, R. Marin-Lopez. |
| Date: | August 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5609 |
|
This document defines the conceptual state machines for the Protocol for Carrying Authentication for Network Access (PANA). The state machines consist of the PANA Client (PaC) state machine and the PANAAuthentication Agent (PAA) state machine. The two state machines show how PANA can interface with the Extensible AuthenticationProtocol (EAP) state machines. The state machines and associated models are informative only. Implementations may achieve the same results using different methods. |
|
| |
| RFC 5612 | Enterprise Number for Documentation Use |
| |
| Authors: | P. Eronen, D. Harrington. |
| Date: | August 2009 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5612 |
|
This document describes an Enterprise Number (also known as SMINetwork Management Private Enterprise Code) for use in documentation. |
|
| |
| RFC 5616 | Streaming Internet Messaging Attachments |
| |
| Authors: | N. Cook. |
| Date: | August 2009 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5616 |
|
This document describes a method for streaming multimedia attachments received by a resource- and/or network-constrained device from anIMAP server. It allows such clients, which often have limits in storage space and bandwidth, to play video and audio email content.
The document describes a profile for making use of the URLAUTH- authorized IMAP URLs (RFC 5092), the Network Announcement SIP MediaService (RFC 4240), and the Media Server Control Markup Language (RFC5022). |
|
| |
| RFC 5620 | RFC Editor Model (Version 1) |
| |
|
|
The RFC Editor performs a number of functions that may be carried out by various persons or entities. The RFC Editor model presented in this document divides the responsibilities for the RFC Series into four functions: The RFC Series Editor, the Independent SubmissionEditor, the RFC Production Center, and the RFC Publisher. It also introduces the RFC Series Advisory Group and an (optional)Independent Submission Stream Editorial Board. The model outlined here is intended to increase flexibility and operational support options, provide for the orderly succession of the RFC Editor, and ensure the continuity of the RFC series, while maintaining RFC quality and timely processing, ensuring document accessibility, reducing costs, and increasing cost transparency. |
|
| |
| RFC 5623 | Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering |
| |
| Authors: | E. Oki, T. Takeda, JL. Le Roux, A. Farrel. |
| Date: | September 2009 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5623 |
|
A network may comprise multiple layers. It is important to globally optimize network resource utilization, taking into account all layers rather than optimizing resource utilization at each layer independently. This allows better network efficiency to be achieved through a process that we call inter-layer traffic engineering. ThePath Computation Element (PCE) can be a powerful tool to achieve inter-layer traffic engineering.
This document describes a framework for applying the PCE-based architecture to inter-layer Multiprotocol Label Switching (MPLS) andGeneralized MPLS (GMPLS) traffic engineering. It provides suggestions for the deployment of PCE in support of multi-layer networks. This document also describes network models where PCE performs inter-layer traffic engineering, and the relationship between PCE and a functional component called the Virtual NetworkTopology Manager (VNTM). |
|
| |
| RFC 5631 | Session Initiation Protocol (SIP) Session Mobility |
| |
| Authors: | R. Shacham, H. Schulzrinne, S. Thakolsri, W. Kellerer. |
| Date: | October 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5631 |
|
Session mobility is the transfer of media of an ongoing communication session from one device to another. This document describes the basic approaches and shows the signaling and media flow examples for providing this service using the Session Initiation Protocol (SIP).Service discovery is essential to locate targets for session transfer and is discussed using the Service Location Protocol (SLP) as an example. This document is an informational document. |
|
| |
| RFC 5632 | Comcast's ISP Experiences in a Proactive Network Provider Participation for P2P (P4P) Technical Trial |
| |
| Authors: | C. Griffiths, J. Livingood, L. Popkin, R. Woundy, Y. Yang. |
| Date: | September 2009 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5632 |
|
This document describes the experiences of Comcast, a large cable broadband Internet Service Provider (ISP) in the U.S., in a ProactiveNetwork Provider Participation for P2P (P4P) technical trial in July2008. This trial used P4P iTracker technology, which is being considered by the IETF as part of the Application Layer TransportOptimization (ALTO) working group. |
|
| |
| RFC 5635 | Remote Triggered Black Hole Filtering with Unicast Reverse Path Forwarding (uRPF) |
| |
| Authors: | W. Kumari, D. McPherson. |
| Date: | August 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5635 |
|
Remote Triggered Black Hole (RTBH) filtering is a popular and effective technique for the mitigation of denial-of-service attacks.This document expands upon destination-based RTBH filtering by outlining a method to enable filtering by source address as well. |
|
| |
| RFC 5637 | Authentication, Authorization, and Accounting (AAA) Goals for Mobile IPv6 |
| |
| Authors: | G. Giaretta, I. Guardini, E. Demaria, J. Bournelle, R. Lopez. |
| Date: | September 2009 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5637 |
|
In commercial and enterprise deployments, Mobile IPv6 can be a service offered by a Mobility Services Provider (MSP). In this case, all protocol operations may need to be explicitly authorized and traced, requiring the interaction between Mobile IPv6 and the AAA infrastructure. Integrating the Authentication, Authorization, andAccounting (AAA) infrastructure (e.g., Network Access Server and AAA server) also offers a solution component for Mobile IPv6 bootstrapping. This document describes various scenarios where a AAA interface for Mobile IPv6 is required. Additionally, it lists design goals and requirements for such an interface. |
|
| |
| RFC 5638 | Simple SIP Usage Scenario for Applications in the Endpoints |
| |
| Authors: | H. Sinnreich, Ed., A. Johnston, E. Shim, K. Singh. |
| Date: | September 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5638 |
|
For Internet-centric usage, the number of SIP-required standards for presence and IM and audio/video communications can be drastically smaller than what has been published by using only the rendezvous and session-initiation capabilities of SIP. The simplification is achieved by avoiding the emulation of telephony and its model of the intelligent network. 'Simple SIP' relies on powerful computing endpoints. Simple SIP desktop applications can be combined with richInternet applications (RIAs). Significant telephony features may also be implemented in the endpoints.
This approach for SIP reduces the number of SIP standards with which to comply -- from roughly 100 currently, and still growing, to about11.
References for NAT traversal and for security are also provided. |
|
| |
| RFC 5639 | Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and Curve Generation |
| |
| Authors: | M. Lochter, J. Merkle. |
| Date: | March 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5639 |
|
This memo proposes several elliptic curve domain parameters over finite prime fields for use in cryptographic applications. The domain parameters are consistent with the relevant international standards, and can be used in X.509 certificates and certificate revocation lists (CRLs), for Internet Key Exchange (IKE), TransportLayer Security (TLS), XML signatures, and all applications or protocols based on the cryptographic message syntax (CMS). |
|
| |
| RFC 5645 | Update to the Language Subtag Registry |
| |
| Authors: | D. Ewell, Ed.. |
| Date: | September 2009 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5645 |
|
This memo defines the procedure used to update the IANA LanguageSubtag Registry, in conjunction with the publication of RFC 5646, for use in forming tags for identifying languages. |
|
| |
| RFC 5647 | AES Galois Counter Mode for the Secure Shell Transport Layer Protocol |
| |
| Authors: | K. Igoe, J. Solinas. |
| Date: | August 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5647 |
|
Secure shell (SSH) is a secure remote-login protocol. SSH provides for algorithms that provide authentication, key agreement, confidentiality, and data-integrity services. The purpose of this document is to show how the AES Galois Counter Mode can be used to provide both confidentiality and data integrity to the SSH TransportLayer Protocol. |
|
| |
| RFC 5649 | Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm |
| |
| Authors: | R. Housley, M. Dworkin. |
| Date: | September 2009 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5649 |
|
This document specifies a padding convention for use with the AES KeyWrap algorithm specified in RFC 3394. This convention eliminates the requirement that the length of the key to be wrapped be a multiple of64 bits, allowing a key of any practical length to be wrapped. |
|
| |
| RFC 5659 | An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge |
| |
| Authors: | M. Bocci, S. Bryant. |
| Date: | October 2009 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5659 |
|
This document describes an architecture for extending pseudowire emulation across multiple packet switched network (PSN) segments.Scenarios are discussed where each segment of a given edge-to-edge emulated service spans a different provider's PSN, as are other scenarios where the emulated service originates and terminates on the same provider's PSN, but may pass through several PSN tunnel segments in that PSN. It presents an architectural framework for such multi- segment pseudowires, defines terminology, and specifies the various protocol elements and their functions. |
|
| |
| RFC 5671 | Applicability of the Path Computation Element (PCE) to Point-to-Multipoint (P2MP) MPLS and GMPLS Traffic Engineering (TE) |
| |
| Authors: | S. Yasukawa, A. Farrel, Ed.. |
| Date: | October 2009 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5671 |
|
The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol LabelSwitching (MPLS) and Generalized MPLS (GMPLS) networks.
Extensions to the MPLS and GMPLS signaling and routing protocols have been made in support of point-to-multipoint (P2MP) Traffic Engineered(TE) Label Switched Paths (LSPs).
This document examines the applicability of PCE to path computation for P2MP TE LSPs in MPLS and GMPLS networks. It describes the motivation for using a PCE to compute these paths and examines which of the PCE architectural models are appropriate. |
|
| |
| RFC 5673 | Industrial Routing Requirements in Low-Power and Lossy Networks |
| |
| Authors: | K. Pister, Ed., P. Thubert, Ed., S. Dwars, T. Phinney. |
| Date: | October 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5673 |
|
The wide deployment of lower-cost wireless devices will significantly improve the productivity and safety of industrial plants while increasing the efficiency of plant workers by extending the information set available about the plant operations. The aim of this document is to analyze the functional requirements for a routing protocol used in industrial Low-power and Lossy Networks (LLNs) of field devices. |
|
| |
| RFC 5683 | Password-Authenticated Key (PAK) Diffie-Hellman Exchange |
| |
| Authors: | A. Brusilovsky, I. Faynberg, Z. Zeltsan, S. Patel. |
| Date: | February 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5683 |
|
This document proposes to add mutual authentication, based on a human-memorizable password, to the basic, unauthenticated Diffie-Hellman key exchange. The proposed algorithm is called the Password-Authenticated Key (PAK) exchange. PAK allows two parties to authenticate themselves while performing the Diffie-Hellman exchange.
The protocol is secure against all passive and active attacks. In particular, it does not allow either type of attacker to obtain any information that would enable an offline dictionary attack on the password. PAK provides Forward Secrecy. |
|
| |
| RFC 5684 | Unintended Consequences of NAT Deployments with Overlapping Address Space |
| |
| Authors: | P. Srisuresh, B. Ford. |
| Date: | February 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5684 |
|
This document identifies two deployment scenarios that have arisen from the unconventional network topologies formed using NetworkAddress Translator (NAT) devices. First, the simplicity of administering networks through the combination of NAT and DHCP has increasingly lead to the deployment of multi-level inter-connected private networks involving overlapping private IP address spaces.Second, the proliferation of private networks in enterprises, hotels and conferences, and the wide-spread use of Virtual Private Networks(VPNs) to access an enterprise intranet from remote locations has increasingly lead to overlapping private IP address space between remote and corporate networks. This document does not dismiss these unconventional scenarios as invalid, but recognizes them as real and offers recommendations to help ensure these deployments can function without a meltdown. |
|
| |
| RFC 5687 | GEOPRIV Layer 7 Location Configuration Protocol: Problem Statement and Requirements |
| |
| Authors: | H. Tschofenig, H. Schulzrinne. |
| Date: | March 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5687 |
|
This document provides a problem statement, lists requirements, and captures design aspects for a GEOPRIV Layer 7 (L7) LocationConfiguration Protocol (LCP). This protocol aims to allow an end host to obtain location information, by value or by reference, from aLocation Information Server (LIS) that is located in the access network. The obtained location information can then be used for a variety of different protocols and purposes. For example, it can be used as input to the Location-to-Service Translation (LoST) Protocol or to convey location within the Session Initiation Protocol (SIP) to other entities. |
|
| |
| RFC 5690 | Adding Acknowledgement Congestion Control to TCP |
| |
| Authors: | S. Floyd, A. Arcia, D. Ros, J. Iyengar. |
| Date: | February 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5690 |
|
This document describes a possible congestion control mechanism for acknowledgement (ACKs) traffic in TCP. The document specifies an end-to-end acknowledgement congestion control mechanism for TCP that uses participation from both TCP hosts: the TCP data sender and theTCP data receiver. The TCP data sender detects lost or ExplicitCongestion Notification (ECN)-marked ACK packets, and tells the TCP data receiver the ACK Ratio R to use to respond to the congestion on the reverse path from the data receiver to the data sender. The TCP data receiver sends roughly one ACK packet for every R data packets received. This mechanism is based on the acknowledgement congestion control in the Datagram Congestion Control Protocol's (DCCP's)Congestion Control Identifier (CCID) 2. This acknowledgement congestion control mechanism is being specified for further evaluation by the network community. |
|
| |
| RFC 5693 | Application-Layer Traffic Optimization (ALTO) Problem Statement |
| |
| Authors: | J. Seedorf, E. Burger. |
| Date: | October 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5693 |
|
Distributed applications -- such as file sharing, real-time communication, and live and on-demand media streaming -- prevalent on the Internet use a significant amount of network resources. Such applications often transfer large amounts of data through connections established between nodes distributed across the Internet with little knowledge of the underlying network topology. Some applications are so designed that they choose a random subset of peers from a larger set with which to exchange data. Absent any topology information guiding such choices, or acting on suboptimal or local information obtained from measurements and statistics, these applications often make less than desirable choices.
This document discusses issues related to an information-sharing service that enables applications to perform better-than-random peer selection. |
|
| |
| RFC 5694 | Peer-to-Peer (P2P) Architecture: Definition, Taxonomies, Examples, and Applicability |
| |
| Authors: | G. Camarillo, Ed., IAB. |
| Date: | November 2009 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5694 |
|
In this document, we provide a survey of P2P (Peer-to-Peer) systems.The survey includes a definition and several taxonomies of P2P systems. This survey also includes a description of which types of applications can be built with P2P technologies and examples of P2P applications that are currently in use on the Internet. Finally, we discuss architectural trade-offs and provide guidelines for deciding whether or not a P2P architecture would be suitable to meet the requirements of a given application. |
|
| |
| RFC 5695 | MPLS Forwarding Benchmarking Methodology for IP Flows |
| |
| Authors: | A. Akhter, R. Asati, C. Pignataro. |
| Date: | November 2009 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5695 |
|
This document describes a methodology specific to the benchmarking of Multiprotocol Label Switching (MPLS) forwarding devices, limited to the most common MPLS packet forwarding scenarios and delay measurements for each, considering IP flows. It builds upon the tenets set forth in RFC 2544, RFC 1242, and other IETF BenchmarkingMethodology Working Group (BMWG) efforts. This document seeks to extend these efforts to the MPLS paradigm. |
|
| |
| RFC 5704 | Uncoordinated Protocol Development Considered Harmful |
| |
| Authors: | S. Bryant, Ed., M. Morrow, Ed., IAB. |
| Date: | November 2009 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5704 |
|
This document identifies problems that may result from the absence of formal coordination and joint development on protocols of mutual interest between standards development organizations (SDOs). Some of these problems may cause significant harm to the Internet. The document suggests that a robust procedure is required prevent this from occurring in the future. The IAB has selected a number of case studies, such as Transport MPLS (T-MPLS), as recent examples to describe the hazard to the Internet architecture that results from uncoordinated adaptation of a protocol.
This experience has resulted in a considerable improvement in the relationship between the IETF and the ITU-T. In particular, this was achieved via the establishment of the "Joint working team onMPLS-TP". In addition, the leadership of the two organizations agreed to improve inter-organizational working practices so as to avoid conflict in the future between ITU-T Recommendations and IETFRFCs.
Whilst we use ITU-T - IETF interactions in these case studies, the scope of the document extends to all SDOs that have an overlapping protocol interest with the IETF. |
|
| |
| RFC 5706 | Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions |
| |
| Authors: | D. Harrington. |
| Date: | November 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5706 |
|
New protocols or protocol extensions are best designed with due consideration of the functionality needed to operate and manage the protocols. Retrofitting operations and management is sub-optimal.The purpose of this document is to provide guidance to authors and reviewers of documents that define new protocols or protocol extensions regarding aspects of operations and management that should be considered. |
|
| |
| RFC 5707 | Media Server Markup Language (MSML) |
| |
| Authors: | A. Saleem, Y. Xin, G. Sharratt. |
| Date: | February 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5707 |
|
The Media Server Markup Language (MSML) is used to control and invoke many different types of services on IP media servers. The MSML control interface was initially driven by RadiSys with subsequent significant contributions from Intel, Dialogic, and others in the industry. Clients can use it to define how multimedia sessions interact on a media server and to apply services to individuals or groups of users. MSML can be used, for example, to control media server conferencing features such as video layout and audio mixing, create sidebar conferences or personal mixes, and set the properties of media streams. As well, clients can use MSML to define media processing dialogs, which may be used as parts of application interactions with users or conferences. Transformation of media streams to and from users or conferences as well as interactive voice response (IVR) dialogs are examples of such interactions, which are specified using MSML. MSML clients may also invoke dialogs with individual users or with groups of conference participants usingVoiceXML. |
|
| |
| RFC 5708 | X.509 Key and Signature Encoding for the KeyNote Trust Management System |
| |
| Authors: | A. Keromytis. |
| Date: | January 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5708 |
|
This memo describes X.509 key identifiers and signature encoding for version 2 of the KeyNote trust-management system (RFC 2704). X.509 certificates (RFC 5280) can be directly used in the Authorizer orLicensees field (or in both fields) in a KeyNote assertion, allowing for easy integration with protocols that already use X.509 certificates for authentication.
In addition, the document defines additional signature types that use other hash functions (beyond the MD5 and SHA1 hash functions that are defined in RFC 2792). |
|
| |
| RFC 5713 | Security Threats and Security Requirements for the Access Node Control Protocol (ANCP) |
| |
| Authors: | H. Moustafa, H. Tschofenig, S. De Cnodder. |
| Date: | January 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5713 |
|
The Access Node Control Protocol (ANCP) aims to communicate Quality of Service (QoS)-related, service-related, and subscriber-related configurations and operations between a Network Access Server (NAS) and an Access Node (e.g., a Digital Subscriber Line AccessMultiplexer (DSLAM)). The main goal of this protocol is to allow theNAS to configure, manage, and control access equipment, including the ability for the Access Nodes to report information to the NAS.
This present document investigates security threats that all ANCP nodes could encounter. This document develops a threat model forANCP security, with the aim of deciding which security functions are required. Based on this, security requirements regarding the AccessNode Control Protocol are defined. |
|
| |
| RFC 5714 | IP Fast Reroute Framework |
| |
| Authors: | M. Shand, S. Bryant. |
| Date: | January 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5714 |
|
This document provides a framework for the development of IP fast- reroute mechanisms that provide protection against link or router failure by invoking locally determined repair paths. Unlike MPLS fast-reroute, the mechanisms are applicable to a network employing conventional IP routing and forwarding. |
|
| |
| RFC 5715 | A Framework for Loop-Free Convergence |
| |
| Authors: | M. Shand, S. Bryant. |
| Date: | January 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5715 |
|
A micro-loop is a packet forwarding loop that may occur transiently among two or more routers in a hop-by-hop packet forwarding paradigm.
This framework provides a summary of the causes and consequences of micro-loops and enables the reader to form a judgement on whether micro-looping is an issue that needs to be addressed in specific networks. It also provides a survey of the currently proposed mechanisms that may be used to prevent or to suppress the formation of micro-loops when an IP or MPLS network undergoes topology change due to failure, repair, or management action. When sufficiently fast convergence is not available and the topology is susceptible to micro-loops, use of one or more of these mechanisms may be desirable. |
|
| |
| RFC 5716 | Requirements for Federated File Systems |
| |
| Authors: | J. Lentini, C. Everhart, D. Ellard, R. Tewari, M. Naik. |
| Date: | January 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5716 |
|
This document describes and lists the functional requirements of a federated file system and defines related terms. |
|
| |
| RFC 5720 | Routing and Addressing in Networks with Global Enterprise Recursion (RANGER) |
| |
| Authors: | F. Templin. |
| Date: | February 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5720 |
|
RANGER is an architectural framework for scalable routing and addressing in networks with global enterprise recursion. The term"enterprise network" within this context extends to a wide variety of use cases and deployment scenarios, where an "enterprise" can be as small as a Small Office, Home Office (SOHO) network, as dynamic as aMobile Ad Hoc Network, as complex as a multi-organizational corporation, or as large as the global Internet itself. Such networks will require an architected solution for the coordination of routing and addressing plans with accommodations for scalability, provider-independence, mobility, multihoming, and security. These considerations are particularly true for existing deployments, but the same principles apply even for clean-slate approaches. TheRANGER architecture addresses these requirements and provides a comprehensive framework for IPv6/IPv4 coexistence. |
|
| |
| RFC 5728 | The SatLabs Group DVB-RCS MIB |
| |
| Authors: | S. Combes, P. Amundsen, M. Lambert, H-P. Lexow. |
| Date: | March 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5728 |
|
This document describes the MIB module for the Digital VideoBroadcasting Return Channel via Satellite system (DVB-RCS), as defined by the SatLabs Group. It defines a set of MIB objects to characterize the behavior and performance of network-layer entities deploying DVB-RCS. |
|
| |
| RFC 5736 | IANA IPv4 Special Purpose Address Registry |
| |
| Authors: | G. Huston, M. Cotton, L. Vegoda. |
| Date: | January 2010 |
| Formats: | txt html json |
| Obsoleted by: | RFC 6890 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5736 |
|
This is a direction to IANA concerning the creation and management of the IANA IPv4 Special Purpose Address Registry. |
|
| |
| RFC 5737 | IPv4 Address Blocks Reserved for Documentation |
| |
| Authors: | J. Arkko, M. Cotton, L. Vegoda. |
| Date: | January 2010 |
| Formats: | txt html json |
| Updates: | RFC 1166 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5737 |
|
Three IPv4 unicast address blocks are reserved for use in examples in specifications and other documents. This document describes the use of these blocks. |
|
| |
| RFC 5741 | RFC Streams, Headers, and Boilerplates |
| |
|
|
RFC documents contain a number of fixed elements such as the title page header, standard boilerplates, and copyright/IPR statements.This document describes them and introduces some updates to reflect current usage and requirements of RFC publication. In particular, this updated structure is intended to communicate clearly the source of RFC creation and review. |
|
| |
| RFC 5743 | Definition of an Internet Research Task Force (IRTF) Document Stream |
| |
| Authors: | A. Falk. |
| Date: | December 2009 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5743 |
|
This memo defines the publication stream for RFCs from the InternetResearch Task Force. Most documents undergoing this process will come from IRTF Research Groups, and it is expected that they will be published as Informational or Experimental RFCs by the RFC Editor. |
|
| |
| RFC 5744 | Procedures for Rights Handling in the RFC Independent Submission Stream |
| |
|
|
This document specifies the procedures by which authors of RFCIndependent Submission documents grant the community "incoming" rights for copying and using the text. It also specifies the"outgoing" rights the community grants to readers and users of those documents, and it requests that the IETF Trust manage the outgoing rights to effect this result. |
|
| |
| RFC 5745 | Procedures for Rights Handling in the RFC IAB Stream |
| |
| Authors: | A. Malis, Ed., IAB. |
| Date: | December 2009 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5745 |
|
|
|
| |
| RFC 5748 | IANA Registry Update for Support of the SEED Cipher Algorithm in Multimedia Internet KEYing (MIKEY) |
| |
| Authors: | S. Yoon, J. Jeong, H. Kim, H. Jeong, Y. Won. |
| Date: | August 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5748 |
|
This document updates IANA registries to support the SEED block cipher algorithm for the Secure Real-time Transport Protocol (SRTP) and the secure Real-time Transport Control Protocol (SRTCP) inMultimedia Internet KEYing (MIKEY). |
|
| |
| RFC 5753 | Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS) |
| |
|
|
This document describes how to use Elliptic Curve Cryptography (ECC) public key algorithms in the Cryptographic Message Syntax (CMS). TheECC algorithms support the creation of digital signatures and the exchange of keys to encrypt or authenticate content. The definition of the algorithm processing is based on the NIST FIPS 186-3 for digital signature, NIST SP800-56A and SEC1 for key agreement, RFC3370 and RFC 3565 for key wrap and content encryption, NIST FIPS180-3 for message digest, SEC1 for key derivation, and RFC 2104 andRFC 4231 for message authentication code standards. This document obsoletes RFC 3278. |
|
| |
| RFC 5757 | Multicast Mobility in Mobile IP Version 6 (MIPv6): Problem Statement and Brief Survey |
| |
| Authors: | T. Schmidt, M. Waehlisch, G. Fairhurst. |
| Date: | February 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5757 |
|
This document discusses current mobility extensions to IP-layer multicast. It describes problems arising from mobile group communication in general, the case of multicast listener mobility, and problems for mobile senders using Any Source Multicast andSource-Specific Multicast. Characteristic aspects of multicast routing and deployment issues for fixed IPv6 networks are summarized.Specific properties and interplays with the underlying network access are surveyed with respect to the relevant technologies in the wireless domain. It outlines the principal approaches to multicast mobility, together with a comprehensive exploration of the mobile multicast problem and solution space. This document concludes with a conceptual road map for initial steps in standardization for use by future mobile multicast protocol designers. This document is a product of the IP Mobility Optimizations (MobOpts) Research Group. |
|
| |
| RFC 5765 | Security Issues and Solutions in Peer-to-Peer Systems for Realtime Communications |
| |
| Authors: | H. Schulzrinne, E. Marocco, E. Ivov. |
| Date: | February 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5765 |
|
Peer-to-peer (P2P) networks have become popular for certain applications and deployments for a variety of reasons, including fault tolerance, economics, and legal issues. It has therefore become reasonable for resource consuming and typically centralized applications like Voice over IP (VoIP) and, in general, realtime communication to adapt and exploit the benefits of P2P. Such a migration needs to address a new set of P2P-specific security problems. This document describes some of the known issues found in common P2P networks, analyzing the relevance of such issues and the applicability of existing solutions when using P2P architectures for realtime communication. This document is a product of the P2PResearch Group. |
|
| |
| RFC 5767 | User-Agent-Driven Privacy Mechanism for SIP |
| |
| Authors: | M. Munakata, S. Schubert, T. Ohba. |
| Date: | April 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5767 |
|
This document defines a guideline for a User Agent (UA) to generate an anonymous Session Initiation Protocol (SIP) message by utilizing mechanisms such as Globally Routable User Agent URIs (GRUUs) andTraversal Using Relays around NAT (TURN) without the need for a privacy service defined in RFC 3323. |
|
| |
| RFC 5769 | Test Vectors for Session Traversal Utilities for NAT (STUN) |
| |
| Authors: | R. Denis-Courmont. |
| Date: | April 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5769 |
|
The Session Traversal Utilities for NAT (STUN) protocol defines several STUN attributes. The content of some of these --FINGERPRINT, MESSAGE-INTEGRITY, and XOR-MAPPED-ADDRESS -- involve binary-logical operations (hashing, xor). This document provides test vectors for those attributes. |
|
| |
| RFC 5781 | The rsync URI Scheme |
| |
| Authors: | S. Weiler, D. Ward, R. Housley. |
| Date: | February 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5781 |
|
This document specifies the rsync Uniform Resource Identifier (URI) scheme. |
|
| |
| RFC 5782 | DNS Blacklists and Whitelists |
| |
| Authors: | J. Levine. |
| Date: | February 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5782 |
|
The rise of spam and other anti-social behavior on the Internet has led to the creation of shared blacklists and whitelists of IP addresses or domains. The DNS has become the de-facto standard method of distributing these blacklists and whitelists. This memo documents the structure and usage of DNS-based blacklists and whitelists, and the protocol used to query them. |
|
| |
| RFC 5783 | Congestion Control in the RFC Series |
| |
| Authors: | M. Welzl, W. Eddy. |
| Date: | February 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5783 |
|
This document is an informational snapshot taken by the IRTF'sInternet Congestion Control Research Group (ICCRG) in October 2008.It provides a survey of congestion control topics described by documents in the RFC series. This does not modify or update the specifications or status of the RFC documents that are discussed. It may be used as a reference or starting point for the future work of the research group, especially in noting gaps or open issues in the current IETF standards. |
|
| |
| RFC 5791 | RFC 2731 ("Encoding Dublin Core Metadata in HTML") Is Obsolete |
| |
|
|
This document obsoletes RFC 2731, "Encoding Dublin Core Metadata inHTML", as further development of this specification has moved to theDublin Core Metadata Initiative (DCMI). |
|
| |
| RFC 5794 | A Description of the ARIA Encryption Algorithm |
| |
| Authors: | J. Lee, J. Lee, J. Kim, D. Kwon, C. Kim. |
| Date: | March 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5794 |
|
This document describes the ARIA encryption algorithm. ARIA is a128-bit block cipher with 128-, 192-, and 256-bit keys. The algorithm consists of a key scheduling part and data randomizing part. |
|
| |
| RFC 5803 | Lightweight Directory Access Protocol (LDAP) Schema for Storing Salted Challenge Response Authentication Mechanism (SCRAM) Secrets |
| |
| Authors: | A. Melnikov. |
| Date: | July 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5803 |
|
This memo describes how the "authPassword" Lightweight DirectoryAccess Protocol (LDAP) attribute can be used for storing secrets used by the Salted Challenge Response Authentication Message (SCRAM) mechanism in the Simple Authentication and Security Layer (SASL) framework. |
|
| |
| RFC 5808 | Requirements for a Location-by-Reference Mechanism |
| |
| Authors: | R. Marshall, Ed.. |
| Date: | May 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5808 |
|
This document defines terminology and provides requirements relating to the Location-by-Reference approach using a location UniformResource Identifier (URI) to handle location information within signaling and other Internet messaging. |
|
| |
| RFC 5817 | Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering Networks |
| |
| Authors: | Z. Ali, JP. Vasseur, A. Zamfir, J. Newton. |
| Date: | April 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5817 |
|
MPLS-TE Graceful Shutdown is a method for explicitly notifying the nodes in a Traffic Engineering (TE) enabled network that the TE capability on a link or on an entire Label Switching Router (LSR) is going to be disabled. MPLS-TE graceful shutdown mechanisms are tailored toward addressing planned outage in the network.
This document provides requirements and protocol mechanisms to reduce or eliminate traffic disruption in the event of a planned shutdown of a network resource. These operations are equally applicable to bothMPLS-TE and its Generalized MPLS (GMPLS) extensions. |
|
| |
| RFC 5824 | Requirements for Supporting Customer Resource ReSerVation Protocol (RSVP) and RSVP Traffic Engineering (RSVP-TE) over a BGP/MPLS IP-VPN |
| |
| Authors: | K. Kumaki, Ed., R. Zhang, Y. Kamite. |
| Date: | April 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5824 |
|
Today, customers expect to run triple-play services through BGP/MPLSIP-VPNs. Some service providers will deploy services that requestQuality of Service (QoS) guarantees from a local Customer Edge (CE) to a remote CE across the network. As a result, the application(e.g., voice, video, bandwidth-guaranteed data pipe, etc.) requirements for an end-to-end QoS and reserving an adequate bandwidth continue to increase.
Service providers can use both an MPLS and an MPLS TrafficEngineering (MPLS-TE) Label Switched Path (LSP) to meet their service objectives. This document describes service-provider requirements for supporting a customer Resource ReSerVation Protocol (RSVP) andRSVP-TE over a BGP/MPLS IP-VPN. |
|
| |
| RFC 5826 | Home Automation Routing Requirements in Low-Power and Lossy Networks |
| |
| Authors: | A. Brandt, J. Buron, G. Porcu. |
| Date: | April 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5826 |
|
This document presents requirements specific to home control and automation applications for Routing Over Low power and Lossy (ROLL) networks. In the near future, many homes will contain high numbers of wireless devices for a wide set of purposes. Examples include actuators (relay, light dimmer, heating valve), sensors (wall switch, water leak, blood pressure), and advanced controllers (radio- frequency-based AV remote control, central server for light and heat control). Because such devices only cover a limited radio range, routing is often required. The aim of this document is to specify the routing requirements for networks comprising such constrained devices in a home-control and automation environment. |
|
| |
| RFC 5828 | Generalized Multiprotocol Label Switching (GMPLS) Ethernet Label Switching Architecture and Framework |
| |
| Authors: | D. Fedyk, L. Berger, L. Andersson. |
| Date: | March 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5828 |
|
There has been significant recent work in increasing the capabilities of Ethernet switches and Ethernet forwarding models. As a consequence, the role of Ethernet is rapidly expanding into"transport networks" that previously were the domain of other technologies such as Synchronous Optical Network (SONET) /Synchronous Digital Hierarchy (SDH), Time-Division Multiplexing(TDM), and Asynchronous Transfer Mode (ATM). This document defines an architecture and framework for a Generalized-MPLS-based control plane for Ethernet in this "transport network" capacity. GMPLS has already been specified for similar technologies. Some additional extensions to the GMPLS control plane are needed, and this document provides a framework for these extensions. |
|
| |
| RFC 5829 | Link Relation Types for Simple Version Navigation between Web Resources |
| |
| Authors: | A. Brown, G. Clemm, J. Reschke, Ed.. |
| Date: | April 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5829 |
|
This specification defines a set of link relation types that may be used on Web resources for navigation between a resource and other resources related to version control, such as past versions and working copies. |
|
| |
| RFC 5830 | GOST 28147-89: Encryption, Decryption, and Message Authentication Code (MAC) Algorithms |
| |
|
|
This document is intended to be a source of information about theRussian Federal standard for electronic encryption, decryption, and message authentication algorithms (GOST 28147-89), which is one of the Russian cryptographic standard algorithms called GOST algorithms). Recently, Russian cryptography is being used inInternet applications, and this document has been created as information for developers and users of GOST 28147-89 for encryption, decryption, and message authentication. |
|
| |
| RFC 5831 | GOST R 34.11-94: Hash Function Algorithm |
| |
|
|
This document is intended to be a source of information about theRussian Federal standard hash function (GOST R 34.11-94), which is one of the Russian cryptographic standard algorithms (called GOST algorithms). Recently, Russian cryptography is being used inInternet applications, and this document has been created as information for developers and users of GOST R 34.11-94 for hash computation. |
|
| |
| RFC 5832 | GOST R 34.10-2001: Digital Signature Algorithm |
| |
|
|
This document is intended to be a source of information about theRussian Federal standard for digital signatures (GOST R 34.10-2001), which is one of the Russian cryptographic standard algorithms (calledGOST algorithms). Recently, Russian cryptography is being used inInternet applications, and this document has been created as information for developers and users of GOST R 34.10-2001 for digital signature generation and verification. |
|
| |
| RFC 5833 | Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Base MIB |
| |
| Authors: | Y. Shi, Ed., D. Perkins, Ed., C. Elliott, Ed., Y. Zhang, Ed.. |
| Date: | May 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5833 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it describes the managed objects for modeling the Control AndProvisioning of Wireless Access Points (CAPWAP) Protocol. This MIB module is presented as a basis for future work on the SNMP management of the CAPWAP protocol. |
|
| |
| RFC 5834 | Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Binding MIB for IEEE 802.11 |
| |
| Authors: | Y. Shi, Ed., D. Perkins, Ed., C. Elliott, Ed., Y. Zhang, Ed.. |
| Date: | May 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5834 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it describes managed objects for modeling the Control And Provisioning of Wireless Access Points (CAPWAP) protocol for IEEE 802.11 wireless binding. This MIB module is presented as a basis for future work on the management of the CAPWAP protocol using the Simple NetworkManagement Protocol (SNMP). |
|
| |
| RFC 5835 | Framework for Metric Composition |
| |
| Authors: | A. Morton, Ed., S. Van den Berghe, Ed.. |
| Date: | April 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5835 |
|
This memo describes a detailed framework for composing and aggregating metrics (both in time and in space) originally defined by the IP Performance Metrics (IPPM), RFC 2330, and developed by theIETF. This new framework memo describes the generic composition and aggregation mechanisms. The memo provides a basis for additional documents that implement the framework to define detailed compositions and aggregations of metrics that are useful in practice. |
|
| |
| RFC 5836 | Extensible Authentication Protocol (EAP) Early Authentication Problem Statement |
| |
| Authors: | Y. Ohba, Ed., Q. Wu, Ed., G. Zorn, Ed.. |
| Date: | April 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5836 |
|
Extensible Authentication Protocol (EAP) early authentication may be defined as the use of EAP by a mobile device to establish authenticated keying material on a target attachment point prior to its arrival. This document discusses the EAP early authentication problem in detail. |
|
| |
| RFC 5841 | TCP Option to Denote Packet Mood |
| |
| Authors: | R. Hay, W. Turkal. |
| Date: | 1 April 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5841 |
|
This document proposes a new TCP option to denote packet mood. |
|
| |
| RFC 5843 | Additional Hash Algorithms for HTTP Instance Digests |
| |
| Authors: | A. Bryan. |
| Date: | April 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5843 |
|
The IANA registry named "Hypertext Transfer Protocol (HTTP) DigestAlgorithm Values" defines values for digest algorithms used byInstance Digests in HTTP. Instance Digests in HTTP provide a digest, also known as a checksum or hash, of an entire representation of the current state of a resource. This document adds new values to the registry and updates previous values. |
|
| |
| RFC 5849 | The OAuth 1.0 Protocol |
| |
|
|
OAuth provides a method for clients to access server resources on behalf of a resource owner (such as a different client or an end- user). It also provides a process for end-users to authorize third- party access to their server resources without sharing their credentials (typically, a username and password pair), using user- agent redirections. |
|
| |
| RFC 5850 | A Call Control and Multi-Party Usage Framework for the Session Initiation Protocol (SIP) |
| |
| Authors: | R. Mahy, R. Sparks, J. Rosenberg, D. Petrie, A. Johnston, Ed.. |
| Date: | May 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5850 |
|
This document defines a framework and the requirements for call control and multi-party usage of the Session Initiation Protocol(SIP). To enable discussion of multi-party features and applications, we define an abstract call model for describing the media relationships required by many of these. The model and actions described here are specifically chosen to be independent of the SIP signaling and/or mixing approach chosen to actually set up the media relationships. In addition to its dialog manipulation aspect, this framework includes requirements for communicating related information and events such as conference and session state and session history.This framework also describes other goals that embody the spirit ofSIP applications as used on the Internet such as the definition of primitives (not services), invoker and participant oriented primitives, signaling and mixing model independence, and others. |
|
| |
| RFC 5851 | Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks |
| |
| Authors: | S. Ooghe, N. Voigt, M. Platnic, T. Haag, S. Wadhwa. |
| Date: | May 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5851 |
|
The purpose of this document is to define a framework for an AccessNode Control Mechanism between a Network Access Server (NAS) and anAccess Node (e.g., a Digital Subscriber Line Access Multiplexer(DSLAM)) in a multi-service reference architecture in order to perform operations related to service, quality of service, and subscribers. The Access Node Control Mechanism will ensure that the transmission of the information does not need to go through distinct element managers but rather uses a direct device-device communication. This allows for performing access-link-related operations within those network elements, while avoiding impact on the existing Operational Support Systems.
This document first identifies a number of use cases for which theAccess Node Control Mechanism may be appropriate. It then presents the requirements for the Access Node Control Protocol (ANCP) that must be taken into account during protocol design. Finally, it describes requirements for the network elements that need to supportANCP and the described use cases. These requirements should be seen as guidelines rather than as absolute requirements. RFC 2119 therefore does not apply to the nodal requirements. |
|
| |
| RFC 5853 | Requirements from Session Initiation Protocol (SIP) Session Border Control (SBC) Deployments |
| |
| Authors: | J. Hautakorpi, Ed., G. Camarillo, R. Penfield, A. Hawrylyshen, M. Bhatia. |
| Date: | April 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5853 |
|
This document describes functions implemented in Session InitiationProtocol (SIP) intermediaries known as Session Border Controllers(SBCs). The goal of this document is to describe the commonly provided functions of SBCs. A special focus is given to those practices that are viewed to be in conflict with SIP architectural principles. This document also explores the underlying requirements of network operators that have led to the use of these functions and practices in order to identify protocol requirements and determine whether those requirements are satisfied by existing specifications or if additional standards work is required. |
|
| |
| RFC 5856 | Integration of Robust Header Compression over IPsec Security Associations |
| |
| Authors: | E. Ertekin, R. Jasani, C. Christou, C. Bormann. |
| Date: | May 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5856 |
|
IP Security (IPsec) provides various security services for IP traffic. However, the benefits of IPsec come at the cost of increased overhead. This document outlines a framework for integrating Robust Header Compression (ROHC) over IPsec (ROHCoIPsec).By compressing the inner headers of IP packets, ROHCoIPsec proposes to reduce the amount of overhead associated with the transmission of traffic over IPsec Security Associations (SAs). |
|
| |
| RFC 5859 | TFTP Server Address Option for DHCPv4 |
| |
| Authors: | R. Johnson. |
| Date: | June 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5859 |
|
This memo documents existing usage for the "TFTP Server Address" option. The option number currently in use is 150. This memo documents the current usage of the option in agreement with RFC 3942, which declares that any pre-existing usages of option numbers in the range 128-223 should be documented, and the Dynamic HostConfiguration working group will try to officially assign those numbers to those options. The option is defined for DHCPv4 and works only with IPv4 addresses. |
|
| |
| RFC 5861 | HTTP Cache-Control Extensions for Stale Content |
| |
| Authors: | M. Nottingham. |
| Date: | May 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5861 |
|
This document defines two independent HTTP Cache-Control extensions that allow control over the use of stale responses by caches. |
|
| |
| RFC 5862 | Path Computation Clients (PCC) - Path Computation Element (PCE) Requirements for Point-to-Multipoint MPLS-TE |
| |
| Authors: | S. Yasukawa, A. Farrel. |
| Date: | June 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5862 |
|
The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol LabelSwitching (MPLS) and Generalized MPLS (GMPLS) networks.
Extensions to the MPLS and GMPLS signaling and routing protocols have been made in support of point-to-multipoint (P2MP) Traffic Engineered(TE) Label Switched Paths (LSPs). The use of PCE in MPLS networks is already established, and since P2MP TE LSP routes are sometimes complex to compute, it is likely that PCE will be used for P2MP LSPs.
Generic requirements for a communication protocol between PathComputation Clients (PCCs) and PCEs are presented in RFC 4657, "PathComputation Element (PCE) Communication Protocol GenericRequirements". This document complements the generic requirements and presents a detailed set of PCC-PCE communication protocol requirements for point-to-multipoint MPLS/GMPLS traffic engineering. |
|
| |
| RFC 5863 | DomainKeys Identified Mail (DKIM) Development, Deployment, and Operations |
| |
| Authors: | T. Hansen, E. Siegel, P. Hallam-Baker, D. Crocker. |
| Date: | May 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5863 |
|
DomainKeys Identified Mail (DKIM) allows an organization to claim responsibility for transmitting a message, in a way that can be validated by a recipient. The organization can be the author's, the originating sending site, an intermediary, or one of their agents. A message can contain multiple signatures, from the same or different organizations involved with the message. DKIM defines a domain-level digital signature authentication framework for email, using public key cryptography and using the domain name service as its key server technology. This permits verification of a responsible organization, as well as the integrity of the message content. DKIM will also provide a mechanism that permits potential email signers to publish information about their email signing practices; this will permit email receivers to make additional assessments about messages.DKIM's authentication of email identity can assist in the global control of "spam" and "phishing". This document provides implementation, deployment, operational, and migration considerations for DKIM. |
|
| |
| RFC 5867 | Building Automation Routing Requirements in Low-Power and Lossy Networks |
| |
| Authors: | J. Martocci, Ed., P. De Mil, N. Riou, W. Vermeylen. |
| Date: | June 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5867 |
|
The Routing Over Low-Power and Lossy (ROLL) networks Working Group has been chartered to work on routing solutions for Low-Power andLossy Networks (LLNs) in various markets: industrial, commercial(building), home, and urban networks. Pursuant to this effort, this document defines the IPv6 routing requirements for building automation. |
|
| |
| RFC 5868 | Problem Statement on the Cross-Realm Operation of Kerberos |
| |
| Authors: | S. Sakane, K. Kamada, S. Zrelli, M. Ishiyama. |
| Date: | May 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5868 |
|
This document provides background information regarding large-scaleKerberos deployments in the industrial sector, with the aim of identifying issues in the current Kerberos cross-realm authentication model as defined in RFC 4120.
This document describes some examples of actual large-scale industrial systems, and lists requirements and restrictions regarding authentication operations in such environments. It also identifies a number of requirements derived from the industrial automation field.Although they are found in the field of industrial automation, these requirements are general enough and are applicable to the problem ofKerberos cross-realm operations. |
|
| |
| RFC 5869 | HMAC-based Extract-and-Expand Key Derivation Function (HKDF) |
| |
| Authors: | H. Krawczyk, P. Eronen. |
| Date: | May 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5869 |
|
This document specifies a simple Hashed Message Authentication Code(HMAC)-based key derivation function (HKDF), which can be used as a building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions. |
|
| |
| RFC 5876 | Updates to Asserted Identity in the Session Initiation Protocol (SIP) |
| |
|
|
The Session Initiation Protocol (SIP) has a mechanism for conveying the identity of the originator of a request by means of theP-Asserted-Identity and P-Preferred-Identity header fields. These header fields are specified for use in requests using a number of SIP methods, in particular the INVITE method. However, RFC 3325 does not specify the insertion of the P-Asserted-Identity header field by a trusted User Agent Client (UAC), does not specify the use ofP-Asserted-Identity and P-Preferred-Identity header fields with certain SIP methods such as UPDATE, REGISTER, MESSAGE, and PUBLISH, and does not specify how to handle an unexpected number of URIs or unexpected URI schemes in these header fields. This document extendsRFC 3325 to cover these situations. |
|
| |
| RFC 5877 | The application/pkix-attr-cert Media Type for Attribute Certificates |
| |
| Authors: | R. Housley. |
| Date: | May 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5877 |
|
This document specifies a MIME media type used to carry a single attribute certificate as defined in RFC 5755. |
|
| |
| RFC 5879 | Heuristics for Detecting ESP-NULL Packets |
| |
| Authors: | T. Kivinen, D. McDonald. |
| Date: | May 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5879 |
|
This document describes a set of heuristics for distinguishing IPsecESP-NULL (Encapsulating Security Payload without encryption) packets from encrypted ESP packets. These heuristics can be used on intermediate devices, like traffic analyzers, and deep-inspection engines, to quickly decide whether or not a given packet flow is encrypted, i.e., whether or not it can be inspected. Use of these heuristics does not require any changes made on existing IPsec hosts that are compliant with RFC 4303. |
|
| |
| RFC 5887 | Renumbering Still Needs Work |
| |
| Authors: | B. Carpenter, R. Atkinson, H. Flinck. |
| Date: | May 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5887 |
|
This document reviews the existing mechanisms for site renumbering for both IPv4 and IPv6, and it identifies operational issues with those mechanisms. It also summarises current technical proposals for additional mechanisms. Finally, there is a gap analysis identifying possible areas for future work. |
|
| |
| RFC 5889 | IP Addressing Model in Ad Hoc Networks |
| |
| Authors: | E. Baccelli, Ed., M. Townsley, Ed.. |
| Date: | September 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5889 |
|
This document describes a model for configuring IP addresses and subnet prefixes on the interfaces of routers which connect to links with undetermined connectivity properties. |
|
| |
| RFC 5894 | Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale |
| |
| Authors: | J. Klensin. |
| Date: | August 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5894 |
|
Several years have passed since the original protocol forInternationalized Domain Names (IDNs) was completed and deployed.During that time, a number of issues have arisen, including the need to update the system to deal with newer versions of Unicode. Some of these issues require tuning of the existing protocols and the tables on which they depend. This document provides an overview of a revised system and provides explanatory material for its components. |
|
| |
| RFC 5895 | Mapping Characters for Internationalized Domain Names in Applications (IDNA) 2008 |
| |
| Authors: | P. Resnick, P. Hoffman. |
| Date: | September 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5895 |
|
In the original version of the Internationalized Domain Names inApplications (IDNA) protocol, any Unicode code points taken from user input were mapped into a set of Unicode code points that "made sense", and then encoded and passed to the domain name system (DNS).The IDNA2008 protocol (described in RFCs 5890, 5891, 5892, and 5893) presumes that the input to the protocol comes from a set of"permitted" code points, which it then encodes and passes to the DNS, but does not specify what to do with the result of user input. This document describes the actions that can be taken by an implementation between receiving user input and passing permitted code points to the new IDNA protocol. |
|
| |
| RFC 5897 | Identification of Communications Services in the Session Initiation Protocol (SIP) |
| |
| Authors: | J. Rosenberg. |
| Date: | June 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5897 |
|
This document considers the problem of service identification in theSession Initiation Protocol (SIP). Service identification is the process of determining the user-level use case that is driving the signaling being utilized by the user agent (UA). This document discusses the uses of service identification, and outlines several architectural principles behind the process. It identifies perils when service identification is not done properly -- including fraud, interoperability failures, and stifling of innovation. It then outlines a set of recommended practices for service identification. |
|
| |
| RFC 5902 | IAB Thoughts on IPv6 Network Address Translation |
| |
| Authors: | D. Thaler, L. Zhang, G. Lebovitz. |
| Date: | July 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5902 |
|
There has been much recent discussion on the topic of whether theIETF should develop standards for IPv6 Network Address Translators(NATs). This document articulates the architectural issues raised byIPv6 NATs, the pros and cons of having IPv6 NATs, and provides theIAB's thoughts on the current open issues and the solution space. |
|
| |
| RFC 5903 | Elliptic Curve Groups modulo a Prime (ECP Groups) for IKE and IKEv2 |
| |
|
|
This document describes three Elliptic Curve Cryptography (ECC) groups for use in the Internet Key Exchange (IKE) and Internet KeyExchange version 2 (IKEv2) protocols in addition to previously defined groups. These groups are based on modular arithmetic rather than binary arithmetic. These groups are defined to align IKE andIKEv2 with other ECC implementations and standards, particularly NIST standards. In addition, the curves defined here can provide more efficient implementation than previously defined ECC groups. This document obsoletes RFC 4753. |
|
| |
| RFC 5904 | RADIUS Attributes for IEEE 802.16 Privacy Key Management Version 1 (PKMv1) Protocol Support |
| |
| Authors: | G. Zorn. |
| Date: | June 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5904 |
|
This document defines a set of Remote Authentication Dial-In UserService (RADIUS) Attributes that are designed to provide RADIUS support for IEEE 802.16 Privacy Key Management Version 1. |
|
| |
| RFC 5906 | Network Time Protocol Version 4: Autokey Specification |
| |
| Authors: | B. Haberman, Ed., D. Mills. |
| Date: | June 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5906 |
|
This memo describes the Autokey security model for authenticating servers to clients using the Network Time Protocol (NTP) and public key cryptography. Its design is based on the premise that IPsec schemes cannot be adopted intact, since that would preclude stateless servers and severely compromise timekeeping accuracy. In addition,Public Key Infrastructure (PKI) schemes presume authenticated time values are always available to enforce certificate lifetimes; however, cryptographically verified timestamps require interaction between the timekeeping and authentication functions.
This memo includes the Autokey requirements analysis, design principles, and protocol specification. A detailed description of the protocol states, events, and transition functions is included. A prototype of the Autokey design based on this memo has been implemented, tested, and documented in the NTP version 4 (NTPv4) software distribution for the Unix, Windows, and Virtual MemorySystem (VMS) operating systems at http://www.ntp.org. |
|
| |
| RFC 5909 | Securing Neighbor Discovery Proxy: Problem Statement |
| |
| Authors: | J-M. Combes, S. Krishnan, G. Daley. |
| Date: | July 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5909 |
|
Neighbor Discovery Proxies are used to provide an address presence on a link for nodes that are no longer present on the link. They allow a node to receive packets directed at its address by allowing another device to perform Neighbor Discovery operations on its behalf.
Neighbor Discovery Proxy is used in Mobile IPv6 and related protocols to provide reachability from nodes on the home network when a MobileNode is not at home, by allowing the Home Agent to act as proxy. It is also used as a mechanism to allow a global prefix to span multiple links, where proxies act as relays for Neighbor Discovery messages.
Neighbor Discovery Proxy currently cannot be secured using SecureNeighbor Discovery (SEND). Today, SEND assumes that a node advertising an address is the address owner and in possession of appropriate public and private keys for that node. This document describes how existing practice for proxy Neighbor Discovery relates to SEND. |
|
| |
| RFC 5911 | New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S/MIME |
| |
|
|
The Cryptographic Message Syntax (CMS) format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates thoseASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax. |
|
| |
| RFC 5912 | New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX) |
| |
|
|
The Public Key Infrastructure using X.509 (PKIX) certificate format, and many associated formats, are expressed using ASN.1. The currentASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1.There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax. |
|
| |
| RFC 5915 | Elliptic Curve Private Key Structure |
| |
| Authors: | S. Turner, D. Brown. |
| Date: | June 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5915 |
|
This document specifies the syntax and semantics for conveyingElliptic Curve (EC) private key information. The syntax and semantics defined herein are based on similar syntax and semantics defined by the Standards for Efficient Cryptography Group (SECG). |
|
| |
| RFC 5916 | Device Owner Attribute |
| |
| Authors: | S. Turner. |
| Date: | June 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5916 |
|
This document defines the Device Owner attribute. It indicates the entity (e.g., company, organization, department, agency) that owns the device. This attribute may be included in public key certificates and attribute certificates. |
|
| |
| RFC 5917 | Clearance Sponsor Attribute |
| |
| Authors: | S. Turner. |
| Date: | June 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5917 |
|
This document defines the clearance sponsor attribute. It indicates the entity that sponsored (i.e., granted) the clearance. This attribute is intended for use in public key certificates and attribute certificates that also include the clearance attribute. |
|
| |
| RFC 5920 | Security Framework for MPLS and GMPLS Networks |
| |
| Authors: | L. Fang, Ed.. |
| Date: | July 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5920 |
|
This document provides a security framework for Multiprotocol LabelSwitching (MPLS) and Generalized Multiprotocol Label Switching(GMPLS) Networks. This document addresses the security aspects that are relevant in the context of MPLS and GMPLS. It describes the security threats, the related defensive techniques, and the mechanisms for detection and reporting. This document emphasizesRSVP-TE and LDP security considerations, as well as inter-AS and inter-provider security considerations for building and maintainingMPLS and GMPLS networks across different domains or differentService Providers. |
|
| |
| RFC 5921 | A Framework for MPLS in Transport Networks |
| |
| Authors: | M. Bocci, Ed., S. Bryant, Ed., D. Frost, Ed., L. Levrau, L. Berger. |
| Date: | July 2010 |
| Formats: | txt html json |
| Updated by: | RFC 6215, RFC 7274 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5921 |
|
This document specifies an architectural framework for the application of Multiprotocol Label Switching (MPLS) to the construction of packet-switched transport networks. It describes a common set of protocol functions -- the MPLS Transport Profile (MPLS-TP) -- that supports the operational models and capabilities typical of such networks, including signaled or explicitly provisioned bidirectional connection-oriented paths, protection and restoration mechanisms, comprehensive Operations, Administration, and Maintenance(OAM) functions, and network operation in the absence of a dynamic control plane or IP forwarding support. Some of these functions are defined in existing MPLS specifications, while others require extensions to existing specifications to meet the requirements of theMPLS-TP.
This document defines the subset of the MPLS-TP applicable in general and to point-to-point transport paths. The remaining subset, applicable specifically to point-to-multipoint transport paths, is outside the scope of this document.
This document is a product of a joint Internet Engineering Task Force(IETF) / International Telecommunication Union TelecommunicationStandardization Sector (ITU-T) effort to include an MPLS TransportProfile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge(PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. |
|
| |
| RFC 5927 | ICMP Attacks against TCP |
| |
| Authors: | F. Gont. |
| Date: | July 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5927 |
|
This document discusses the use of the Internet Control MessageProtocol (ICMP) to perform a variety of attacks against theTransmission Control Protocol (TCP). Additionally, this document describes a number of widely implemented modifications to TCP's handling of ICMP error messages that help to mitigate these issues. |
|
| |
| RFC 5930 | Using Advanced Encryption Standard Counter Mode (AES-CTR) with the Internet Key Exchange version 02 (IKEv2) Protocol |
| |
| Authors: | S. Shen, Y. Mao, NSS. Murthy. |
| Date: | July 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5930 |
|
This document describes the usage of Advanced Encryption StandardCounter Mode (AES-CTR), with an explicit Initialization Vector, by the Internet Key Exchange version 2 (IKEv2) protocol, for encrypting the IKEv2 exchanges that follow the IKE_SA_INIT exchange. |
|
| |
| RFC 5931 | Extensible Authentication Protocol (EAP) Authentication Using Only a Password |
| |
|
|
This memo describes an Extensible Authentication Protocol (EAP) method, EAP-pwd, which uses a shared password for authentication.The password may be a low-entropy one and may be drawn from some set of possible passwords, like a dictionary, which is available to an attacker. The underlying key exchange is resistant to active attack, passive attack, and dictionary attack. |
|
| |
| RFC 5937 | Using Trust Anchor Constraints during Certification Path Processing |
| |
| Authors: | S. Ashmore, C. Wallace. |
| Date: | August 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5937 |
|
This document describes how to use information associated with a trust anchor public key when validating certification paths. This information can be used to constrain the usage of a trust anchor.Typically, constraints are used to limit the certificate policies and names that can appear in certification paths validated using a trust anchor. |
|
| |
| RFC 5941 | Sharing Transaction Fraud Data |
| |
| Authors: | D. M'Raihi, S. Boeyen, M. Grandcolas, S. Bajaj. |
| Date: | August 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5941 |
|
This document describes a document format for exchanging transaction fraud (Thraud) information. It extends the Incident Handling WorkingGroup (INCH WG) Incident Object Description Exchange Format (IODEF) incident reporting document format. |
|
| |
| RFC 5945 | Resource Reservation Protocol (RSVP) Proxy Approaches |
| |
| Authors: | F. Le Faucheur, J. Manner, D. Wing, A. Guillou. |
| Date: | October 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5945 |
|
The Resource Reservation Protocol (RSVP) can be used to make end-to- end resource reservations in an IP network in order to guarantee the quality of service required by certain flows. RSVP assumes that both the data sender and receiver of a given flow take part in RSVP signaling. Yet, there are use cases where resource reservation is required, but the receiver, the sender, or both, is not RSVP-capable.This document presents RSVP proxy behaviors allowing RSVP routers to initiate or terminate RSVP signaling on behalf of a receiver or a sender that is not RSVP-capable. This allows resource reservations to be established on a critical subset of the end-to-end path. This document reviews conceptual approaches for deploying RSVP proxies and discusses how RSVP reservations can be synchronized with application requirements, despite the sender, receiver, or both not participating in RSVP. This document also points out where extensions to RSVP (or to other protocols) may be needed for deployment of a given RSVP proxy approach. However, such extensions are outside the scope of this document. Finally, practical use cases for RSVP proxy are described. |
|
| |
| RFC 5947 | Requirements for Multiple Address of Record (AOR) Reachability Information in the Session Initiation Protocol (SIP) |
| |
| Authors: | J. Elwell, H. Kaplan. |
| Date: | September 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5947 |
|
This document states requirements for a standardized SIP registration mechanism for multiple addresses of record (AORs), the mechanism being suitable for deployment by SIP service providers on a large scale in support of small to medium sized Private Branch Exchanges(PBXs). The requirements are for a solution that can, as a minimum, support AORs based on E.164 numbers. |
|
| |
| RFC 5950 | Network Management Framework for MPLS-based Transport Networks |
| |
| Authors: | S. Mansfield, Ed., E. Gray, Ed., K. Lam, Ed.. |
| Date: | September 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5950 |
|
This document provides the network management framework for theTransport Profile for Multi-Protocol Label Switching (MPLS-TP).
This framework relies on the management terminology from the ITU-T to describe the management architecture that could be used for an MPLS-TP management network.
The management of the MPLS-TP network could be based on multi-tiered distributed management systems. This document provides a description of the network and element management architectures that could be applied and also describes heuristics associated with fault, configuration, and performance aspects of the management system.
This document is a product of a joint Internet Engineering Task Force(IETF) / International Telecommunication Union TelecommunicationStandardization Sector (ITU-T) effort to include an MPLS TransportProfile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network. |
|
| |
| RFC 5955 | The application/timestamped-data Media Type |
| |
|
|
This document defines a new media type for TimeStampedData envelopes as described in RFC 5544. |
|
| |
| RFC 5963 | IPv6 Deployment in Internet Exchange Points (IXPs) |
| |
| Authors: | R. Gagliano. |
| Date: | August 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5963 |
|
This document provides guidance on IPv6 deployment in InternetExchange Points (IXPs). It includes information regarding the switch fabric configuration, the addressing plan and general organizational tasks that need to be performed. IXPs are mainly a Layer 2 infrastructure, and, in many cases, the best recommendations suggest that the IPv6 data, control, and management plane should not be handled differently than in IPv4. |
|
| |
| RFC 5967 | The application/pkcs10 Media Type |
| |
|
|
This document specifies a media type used to carry PKCS #10 certification requests as defined in RFC 2986. It carries over the original specification from RFC 2311, which recently has been moved to Historic status, and properly links it to RFC 2986. |
|
| |
| RFC 5968 | Guidelines for Extending the RTP Control Protocol (RTCP) |
| |
| Authors: | J. Ott, C. Perkins. |
| Date: | September 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5968 |
|
The RTP Control Protocol (RTCP) is used along with the Real-timeTransport Protocol (RTP) to provide a control channel between media senders and receivers. This allows constructing a feedback loop to enable application adaptation and monitoring, among other uses. The basic reporting mechanisms offered by RTCP are generic, yet quite powerful and suffice to cover a range of uses. This document provides guidelines on extending RTCP if those basic mechanisms prove insufficient. |
|
| |
| RFC 5972 | General Internet Signaling Transport (GIST) State Machine |
| |
| Authors: | T. Tsenov, H. Tschofenig, X. Fu, Ed., C. Aoun, E. Davies. |
| Date: | October 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5972 |
|
This document describes state machines for the General InternetSignaling Transport (GIST). The states of GIST nodes for a given flow and their transitions are presented in order to illustrate howGIST may be implemented. |
|
| |
| RFC 5978 | Using and Extending the NSIS Protocol Family |
| |
| Authors: | J. Manner, R. Bless, J. Loughney, E. Davies, Ed.. |
| Date: | October 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5978 |
|
This document gives an overview of the Next Steps in Signaling (NSIS) framework and protocol suite created by the NSIS Working Group during the period of 2001-2010. It also includes suggestions on how the industry can make use of the new protocols and how the community can exploit the extensibility of both the framework and existing protocols to address future signaling needs. |
|
| |
| RFC 5980 | NSIS Protocol Operation in Mobile Environments |
| |
| Authors: | T. Sanda, Ed., X. Fu, S. Jeong, J. Manner, H. Tschofenig. |
| Date: | March 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5980 |
|
Mobility of an IP-based node affects routing paths, and as a result, can have a significant effect on the protocol operation and state management. This document discusses the effects mobility can cause to the Next Steps in Signaling (NSIS) protocol suite, and shows how the NSIS protocols operate in different scenarios with mobility management protocols. |
|
| |
| RFC 5982 | IP Flow Information Export (IPFIX) Mediation: Problem Statement |
| |
| Authors: | A. Kobayashi, Ed., B. Claise, Ed.. |
| Date: | August 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5982 |
|
Flow-based measurement is a popular method for various network monitoring usages. The sharing of flow-based information for monitoring applications having different requirements raises some open issues in terms of measurement system scalability, flow-based measurement flexibility, and export reliability that IP FlowInformation Export (IPFIX) Mediation may help resolve. This document describes some problems related to flow-based measurement that network administrators have been facing, and then it describes IPFIXMediation applicability examples along with the problems. |
|
| |
| RFC 5992 | Internationalized Domain Names Registration and Administration Guidelines for European Languages Using Cyrillic |
| |
| Authors: | S. Sharikov, D. Miloshevic, J. Klensin. |
| Date: | October 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5992 |
|
This document is a guideline for registries and registrars on registering internationalized domain names (IDNs) based on (in alphabetical order) Bosnian, Bulgarian, Byelorussian, Kildin Sami,Macedonian, Montenegrin, Russian, Serbian, and Ukrainian languages in a DNS zone. It describes appropriate characters for registration and variant considerations for characters from Greek and Latin scripts with similar appearances and/or derivations. |
|
| |
| RFC 5994 | Application of Ethernet Pseudowires to MPLS Transport Networks |
| |
| Authors: | S. Bryant, Ed., M. Morrow, G. Swallow, R. Cherukuri, T. Nadeau, N. Harrison, B. Niven-Jenkins. |
| Date: | October 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5994 |
|
Ethernet pseudowires are widely deployed to support packet transport of Ethernet services. These services in-turn provide transport for a variety of client networks, e.g., IP and MPLS. This document uses procedures defined in the existing IETF specifications of Ethernet pseudowires carried over MPLS networks.
Many of the requirements for the services provided by the mechanisms explained in this document are also recognized by the MPLS transport profile (MPLS-TP) design effort formed jointly by the IETF and ITU-T.The solution described here does not address all of the MPLS-TP requirements, but it provides a viable form of packet transport service using tools that are already available.
This document also serves as an indication that existing MPLS techniques form an appropriate basis for the design of a fully- featured packet transport solution addressing all of the requirements of MPLS-TP. |
|
| |
| RFC 5997 | Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol |
| |
|
|
This document describes a deployed extension to the RemoteAuthentication Dial In User Service (RADIUS) protocol, enabling clients to query the status of a RADIUS server. This extension utilizes the Status-Server (12) Code, which was reserved for experimental use in RFC 2865. |
|
| |
| RFC 6007 | Use of the Synchronization VECtor (SVEC) List for Synchronized Dependent Path Computations |
| |
| Authors: | I. Nishioka, D. King. |
| Date: | September 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6007 |
|
A Path Computation Element (PCE) may be required to perform dependent path computations. Dependent path computations are requests that need to be synchronized in order to meet specific objectives. An example of a dependent request would be a PCE computing a set of services that are required to be diverse (disjointed) from each other. When a PCE computes sets of dependent path computation requests concurrently, use of the Synchronization VECtor (SVEC) list is required for association among the sets of dependent path computation requests. The SVEC object is optional and carried within the Path Computation Element Communication Protocol (PCEP) PCRequest(PCReq) message.
This document does not specify the PCEP SVEC object or procedure.This informational document clarifies the use of the SVEC list for synchronized path computations when computing dependent requests.The document also describes a number of usage scenarios for SVEC lists within single-domain and multi-domain environments. |
|
| |
| RFC 6011 | Session Initiation Protocol (SIP) User Agent Configuration |
| |
| Authors: | S. Lawrence, Ed., J. Elwell. |
| Date: | October 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6011 |
|
This document defines procedures for how a SIP User Agent should locate, retrieve, and maintain current configuration information from a Configuration Service. |
|
| |
| RFC 6017 | Electronic Data Interchange - Internet Integration (EDIINT) Features Header Field |
| |
| Authors: | K. Meadors, Ed.. |
| Date: | September 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6017 |
|
With the maturity of the Electronic Data Interchange - InternetIntegration (EDIINT) standards of AS1, AS2, and AS3, applications and additional features are being built upon the basic secure transport functionality. These features are not necessarily supported by allEDIINT applications and could cause potential problems with implementations. The EDIINT-Features header field provides a means to resolve these problems and support new functionality. |
|
| |
| RFC 6018 | IPv4 and IPv6 Greynets |
| |
| Authors: | F. Baker, W. Harrop, G. Armitage. |
| Date: | September 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6018 |
|
This note discusses a feature to support building Greynets for IPv4 and IPv6. |
|
| |
| RFC 6024 | Trust Anchor Management Requirements |
| |
| Authors: | R. Reddy, C. Wallace. |
| Date: | October 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6024 |
|
A trust anchor represents an authoritative entity via a public key and associated data. The public key is used to verify digital signatures, and the associated data is used to constrain the types of information for which the trust anchor is authoritative. A relying party uses trust anchors to determine if a digitally signed object is valid by verifying a digital signature using the trust anchor's public key, and by enforcing the constraints expressed in the associated data for the trust anchor. This document describes some of the problems associated with the lack of a standard trust anchor management mechanism and defines requirements for data formats and push-based protocols designed to address these problems. |
|
| |
| RFC 6025 | ASN.1 Translation |
| |
| Authors: | C. Wallace, C. Gardiner. |
| Date: | October 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6025 |
|
Abstract Syntax Notation One (ASN.1) is widely used throughout theIETF Security Area and has been for many years. Some specifications were written using a now deprecated version of ASN.1 and some were written using the current version of ASN.1. Not all ASN.1 compilers support both older and current syntax. This document is intended to provide guidance to specification authors and to implementers converting ASN.1 modules from one version of ASN.1 to another version without causing changes to the "bits on the wire". This document does not provide a comprehensive tutorial of any version of ASN.1.Instead, it addresses ASN.1 features that are used in IETF SecurityArea specifications with a focus on items that vary with the ASN.1 version. |
|
| |
| RFC 6027 | IPsec Cluster Problem Statement |
| |
| Authors: | Y. Nir. |
| Date: | October 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6027 |
|
This document defines the terminology, problem statement, and requirements for implementing Internet Key Exchange (IKE) and IPsec on clusters. It also describes gaps in existing standards and their implementation that need to be filled in order to allow peers to interoperate with clusters from different vendors. Agreed upon terminology, problem statement, and requirements will allow IETF working groups to consider development of IPsec/IKEv2 mechanisms to simplify cluster implementations. |
|
| |
| RFC 6029 | A Survey on Research on the Application-Layer Traffic Optimization (ALTO) Problem |
| |
| Authors: | I. Rimac, V. Hilt, M. Tomsu, V. Gurbani, E. Marocco. |
| Date: | October 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6029 |
|
A significant part of the Internet traffic today is generated by peer-to-peer (P2P) applications used originally for file sharing, and more recently for real-time communications and live media streaming.Such applications discover a route to each other through an overlay network with little knowledge of the underlying network topology. As a result, they may choose peers based on information deduced from empirical measurements, which can lead to suboptimal choices. This document, a product of the P2P Research Group, presents a survey of existing literature on discovering and using network topology information for Application-Layer Traffic Optimization. |
|
| |
| RFC 6036 | Emerging Service Provider Scenarios for IPv6 Deployment |
| |
| Authors: | B. Carpenter, S. Jiang. |
| Date: | October 2010 |
| Formats: | txt html json |
| Obsoleted by: | RFC 9386 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6036 |
|
This document describes practices and plans that are emerging amongInternet Service Providers for the deployment of IPv6 services. They are based on practical experience so far, as well as current plans and requirements, reported in a survey of a number of ISPs carried out in early 2010. This document identifies a number of technology gaps, but it does not make recommendations. |
|
| |
| RFC 6039 | Issues with Existing Cryptographic Protection Methods for Routing Protocols |
| |
| Authors: | V. Manral, M. Bhatia, J. Jaeggli, R. White. |
| Date: | October 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6039 |
|
Routing protocols have been extended over time to use cryptographic mechanisms to ensure that data received from a neighboring router has not been modified in transit and actually originated from an authorized neighboring router.
The cryptographic mechanisms defined to date and described in this document rely on a digest produced with a hash algorithm applied to the payload encapsulated in the routing protocol packet.
This document outlines some of the limitations of the current mechanism, problems with manual keying of these cryptographic algorithms, and possible vectors for the exploitation of these limitations. |
|
| |
| RFC 6041 | Forwarding and Control Element Separation (ForCES) Applicability Statement |
| |
| Authors: | A. Crouch, H. Khosravi, A. Doria, Ed., X. Wang, K. Ogawa. |
| Date: | October 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6041 |
|
The Forwarding and Control Element Separation (ForCES) protocol defines a standard framework and mechanism for the interconnection between control elements and forwarding elements in IP routers and similar devices. In this document we describe the applicability of the ForCES model and protocol. We provide example deployment scenarios and functionality, as well as document applications that would be inappropriate for ForCES. |
|
| |
| RFC 6042 | Transport Layer Security (TLS) Authorization Using KeyNote |
| |
|
|
This document specifies the use of the KeyNote trust-management system as an authorization extension in the Transport Layer Security(TLS) Handshake Protocol, according to guidelines in RFC 5878.Extensions carried in the client and server hello messages confirm that both parties support the desired authorization data types.Then, if supported by both the client and the server, KeyNote credentials are exchanged in the supplemental data handshake message. |
|
| |
| RFC 6043 | MIKEY-TICKET: Ticket-Based Modes of Key Distribution in Multimedia Internet KEYing (MIKEY) |
| |
|
|
The Multimedia Internet KEYing (MIKEY) specification describes a key management scheme for real-time applications. In this document, we note that the currently defined MIKEY modes are insufficient to address deployment scenarios built around a centralized key management service. Interest in such deployments is increasing.Therefore, a set of new MIKEY modes that work well in such scenarios are defined. The new modes use a trusted key management service and a ticket concept, similar to that in Kerberos. The new modes also support features used by many existing applications, where the exact identity of the other endpoint may not be known at the start of the communication session. |
|
| |
| RFC 6044 | Mapping and Interworking of Diversion Information between Diversion and History-Info Headers in the Session Initiation Protocol (SIP) |
| |
|
|
Although the SIP History-Info header is the solution adopted in IETF, the non-standard Diversion header is nevertheless widely implemented and used for conveying call-diversion-related information in SIP signaling.
This document describes a recommended interworking guideline between the Diversion header and the History-Info header to handle call diversion information. In addition, an interworking policy is proposed to manage the headers' coexistence. The History-Info header is described in RFC 4244 and the non-standard Diversion header is described, as Historic, in RFC 5806.
Since the Diversion header is used in many existing network implementations for the transport of call diversion information, its interworking with the SIP History-Info standardized solution is needed. This work is intended to enable the migration from non- standard implementations and deployment toward IETF specification- based implementations and deployment. |
|
| |
| RFC 6045 | Real-time Inter-network Defense (RID) |
| |
|
|
Network security incidents, such as system compromises, worms, viruses, phishing incidents, and denial of service, typically result in the loss of service, data, and resources both human and system.Network providers and Computer Security Incident Response Teams need to be equipped and ready to assist in communicating and tracing security incidents with tools and procedures in place before the occurrence of an attack. Real-time Inter-network Defense (RID) outlines a proactive inter-network communication method to facilitate sharing incident handling data while integrating existing detection, tracing, source identification, and mitigation mechanisms for a complete incident handling solution. Combining these capabilities in a communication system provides a way to achieve higher security levels on networks. Policy guidelines for handling incidents are recommended and can be agreed upon by a consortium using the security recommendations and considerations.
RID has found use within the international research communities, but has not been widely adopted in other sectors. This publication provides the specification to those communities that have adopted it, and communities currently considering solutions for real-time inter- network defense. The specification may also accelerate development of solutions where different transports or message formats are required by leveraging the data elements and structures specified here. |
|
| |
| RFC 6046 | Transport of Real-time Inter-network Defense (RID) Messages |
| |
| Authors: | K. Moriarty, B. Trammell. |
| Date: | November 2010 |
| Formats: | txt json html |
| Obsoleted by: | RFC 6546 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6046 |
|
The Incident Object Description Exchange Format (IODEF) defines a common XML format for document exchange, and Real-time Inter-networkDefense (RID) defines extensions to IODEF intended for the cooperative handling of security incidents within consortia of network operators and enterprises. This document specifies a transport protocol for RID based upon the passing of RID messages over HTTP/TLS (Transport Layer Security). |
|
| |
| RFC 6050 | A Session Initiation Protocol (SIP) Extension for the Identification of Services |
| |
| Authors: | K. Drage. |
| Date: | November 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6050 |
|
This document describes private extensions to the Session InitiationProtocol (SIP) that enable a network of trusted SIP servers to assert the service of authenticated users. The use of these extensions is only applicable inside an administrative domain with previously agreed-upon policies for generation, transport, and usage of such information. This document does NOT offer a general service identification model suitable for use between different trust domains or for use in the Internet at large.
The document also defines a URN to identify both services and UserAgent (UA) applications. This URN can be used within the SIP header fields defined in this document to identify services, and also within the framework defined for caller preferences and callee capabilities to identify usage of both services and applications between end UAs. |
|
| |
| RFC 6053 | Implementation Report for Forwarding and Control Element Separation (ForCES) |
| |
| Authors: | E. Haleplidis, K. Ogawa, W. Wang, J. Hadi Salim. |
| Date: | November 2010 |
| Formats: | txt json html |
| Updated by: | RFC 6984 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6053 |
|
Forwarding and Control Element Separation (ForCES) defines an architectural framework and associated protocols to standardize information exchange between the control plane and the forwarding plane in a ForCES network element (ForCES NE). RFC 3654 has defined the ForCES requirements, and RFC 3746 has defined the ForCES framework.
This document is an implementation report for the ForCES Protocol,Model, and the Stream Control Transmission Protocol-based TransportMapping Layer (SCTP TML) documents, and includes a report on interoperability testing and the current state of ForCES implementations. |
|
| |
| RFC 6055 | IAB Thoughts on Encodings for Internationalized Domain Names |
| |
| Authors: | D. Thaler, J. Klensin, S. Cheshire. |
| Date: | February 2011 |
| Formats: | txt html json |
| Updates: | RFC 2130 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6055 |
|
This document explores issues with Internationalized Domain Names(IDNs) that result from the use of various encoding schemes such asUTF-8 and the ASCII-Compatible Encoding produced by the Punycode algorithm. It focuses on the importance of agreeing on a single encoding and how complicated the state of affairs ends up being as a result of using different encodings today. |
|
| |
| RFC 6061 | Uniform Resource Name (URN) Namespace for the National Emergency Number Association (NENA) |
| |
| Authors: | B. Rosen. |
| Date: | January 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6061 |
|
This document describes the Namespace Identifier (NID) "nena" forUniform Resource Name (URN) resources published by the NationalEmergency Number Association (NENA). NENA defines and manages resources that utilize this URN model. Management activities for these and other resource types are provided by the NENA RegistrySystem (NRS). |
|
| |
| RFC 6064 | SDP and RTSP Extensions Defined for 3GPP Packet-Switched Streaming Service and Multimedia Broadcast/Multicast Service |
| |
| Authors: | M. Westerlund, P. Frojdh. |
| Date: | January 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6064 |
|
The Packet-switched Streaming Service (PSS) and the MultimediaBroadcast/Multicast Service (MBMS) defined by 3GPP use the SessionDescription Protocol (SDP) and Real Time Streaming Protocol (RTSP) with some extensions. This document provides information about these extensions and registers the RTSP and SDP extensions with IANA. |
|
| |
| RFC 6067 | BCP 47 Extension U |
| |
| Authors: | M. Davis, A. Phillips, Y. Umaoka. |
| Date: | December 2010 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6067 |
|
This document specifies an Extension to BCP 47 that provides subtags that specify language and/or locale-based behavior or refinements to language tags, according to work done by the Unicode Consortium. |
|
| |
| RFC 6070 | PKCS #5: Password-Based Key Derivation Function 2 (PBKDF2) Test Vectors |
| |
| Authors: | S. Josefsson. |
| Date: | January 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6070 |
|
This document contains test vectors for the Public-Key CryptographyStandards (PKCS) #5 Password-Based Key Derivation Function 2 (PBKDF2) with the Hash-based Message Authentication Code (HMAC) Secure HashAlgorithm (SHA-1) pseudorandom function. |
|
| |
| RFC 6071 | IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap |
| |
| Authors: | S. Frankel, S. Krishnan. |
| Date: | February 2011 |
| Formats: | txt html json |
| Obsoletes: | RFC 2411 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6071 |
|
Over the past few years, the number of RFCs that define and use IPsec and Internet Key Exchange (IKE) has greatly proliferated. This is complicated by the fact that these RFCs originate from numerous IETF working groups: the original IPsec WG, its various spin-offs, and other WGs that use IPsec and/or IKE to protect their protocols' traffic.
This document is a snapshot of IPsec- and IKE-related RFCs. It includes a brief description of each RFC, along with background information explaining the motivation and context of IPsec's outgrowths and extensions. It obsoletes RFC 2411, the previous "IPSecurity Document Roadmap."
The obsoleted IPsec roadmap (RFC 2411) briefly described the interrelationship of the various classes of base IPsec documents.The major focus of RFC 2411 was to specify the recommended contents of documents specifying additional encryption and authentication algorithms. |
|
| |
| RFC 6077 | Open Research Issues in Internet Congestion Control |
| |
| Authors: | D. Papadimitriou, Ed., M. Welzl, M. Scharf, B. Briscoe. |
| Date: | February 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6077 |
|
This document describes some of the open problems in Internet congestion control that are known today. This includes several new challenges that are becoming important as the network grows, as well as some issues that have been known for many years. These challenges are generally considered to be open research topics that may require more study or application of innovative techniques before Internet- scale solutions can be confidently engineered and deployed. |
|
| |
| RFC 6082 | Deprecating Unicode Language Tag Characters: RFC 2482 is Historic |
| |
| Authors: | K. Whistler, G. Adams, M. Duerst, R. Presuhn, Ed., J. Klensin. |
| Date: | November 2010 |
| Formats: | txt json html |
| Obsoletes: | RFC 2482 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6082 |
|
RFC 2482, "Language Tagging in Unicode Plain Text", describes a mechanism for using special Unicode language tag characters to identify languages when needed without more general markup such as that provided by XML. The Unicode Consortium has deprecated that facility and strongly recommends against its use. RFC 2482 has been moved to Historic status to reduce the possibility that Internet implementers would consider that system an appropriate mechanism for identifying languages. |
|
| |
| RFC 6087 | Guidelines for Authors and Reviewers of YANG Data Model Documents |
| |
|
|
This memo provides guidelines for authors and reviewers of StandardsTrack specifications containing YANG data model modules. Applicable portions may be used as a basis for reviews of other YANG data model documents. Recommendations and procedures are defined, which are intended to increase interoperability and usability of NetworkConfiguration Protocol (NETCONF) implementations that utilize YANG data model modules. |
|
| |
| RFC 6090 | Fundamental Elliptic Curve Cryptography Algorithms |
| |
| Authors: | D. McGrew, K. Igoe, M. Salter. |
| Date: | February 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6090 |
|
This note describes the fundamental algorithms of Elliptic CurveCryptography (ECC) as they were defined in some seminal references from 1994 and earlier. These descriptions may be useful for implementing the fundamental algorithms without using any of the specialized methods that were developed in following years. Only elliptic curves defined over fields of characteristic greater than three are in scope; these curves are those used in Suite B. |
|
| |
| RFC 6091 | Using OpenPGP Keys for Transport Layer Security (TLS) Authentication |
| |
| Authors: | N. Mavrogiannopoulos, D. Gillmor. |
| Date: | February 2011 |
| Formats: | txt html json |
| Obsoletes: | RFC 5081 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6091 |
|
This memo defines Transport Layer Security (TLS) extensions and associated semantics that allow clients and servers to negotiate the use of OpenPGP certificates for a TLS session, and specifies how to transport OpenPGP certificates via TLS. It also defines the registry for non-X.509 certificate types. |
|
| |
| RFC 6092 | Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service |
| |
| Authors: | J. Woodyatt, Ed.. |
| Date: | January 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6092 |
|
This document identifies a set of recommendations for the makers of devices and describes how to provide for "simple security" capabilities at the perimeter of local-area IPv6 networks inInternet-enabled homes and small offices. |
|
| |
| RFC 6094 | Summary of Cryptographic Authentication Algorithm Implementation Requirements for Routing Protocols |
| |
| Authors: | M. Bhatia, V. Manral. |
| Date: | February 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6094 |
|
The routing protocols Open Shortest Path First version 2 (OSPFv2),Intermediate System to Intermediate System (IS-IS), and RoutingInformation Protocol (RIP) currently define cleartext and MD5(Message Digest 5) methods for authenticating protocol packets.Recently, effort has been made to add support for the SHA (SecureHash Algorithm) family of hash functions for the purpose of authenticating routing protocol packets for RIP, IS-IS, and OSPF.
To encourage interoperability between disparate implementations, it is imperative that we specify the expected minimal set of algorithms, thereby ensuring that there is at least one algorithm that all implementations will have in common.
Similarly, RIP for IPv6 (RIPng) and OSPFv3 support IPsec algorithms for authenticating their protocol packets.
This document examines the current set of available algorithms, with interoperability and effective cryptographic authentication protection being the principal considerations. Cryptographic authentication of these routing protocols requires the availability of the same algorithms in disparate implementations. It is desirable that newly specified algorithms should be implemented and available in routing protocol implementations because they may be promoted to requirements at some future time. |
|
| |
| RFC 6097 | Local Mobility Anchor (LMA) Discovery for Proxy Mobile IPv6 |
| |
| Authors: | J. Korhonen, V. Devarapalli. |
| Date: | February 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6097 |
|
Large Proxy Mobile IPv6 deployments would benefit from a functionality where a Mobile Access Gateway could dynamically discover a Local Mobility Anchor for a Mobile Node attaching to aProxy Mobile IPv6 domain. The purpose of the dynamic discovery functionality is to reduce the amount of static configuration in theMobile Access Gateway. This document describes several possible dynamic Local Mobility Anchor discovery solutions. |
|
| |
| RFC 6104 | Rogue IPv6 Router Advertisement Problem Statement |
| |
| Authors: | T. Chown, S. Venaas. |
| Date: | February 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6104 |
|
When deploying IPv6, whether IPv6-only or dual-stack, routers are configured to send IPv6 Router Advertisements (RAs) to convey information to nodes that enable them to autoconfigure on the network. This information includes the implied default router address taken from the observed source address of the RA message, as well as on-link prefix information. However, unintended misconfigurations by users or administrators, or possibly malicious attacks on the network, may lead to bogus RAs being present, which in turn can cause operational problems for hosts on the network. In this document, we summarise the scenarios in which rogue RAs may be observed and present a list of possible solutions to the problem. We focus on the unintended causes of rogue RAs in the text. The goal of this text is to be Informational, and as such to present a framework around which solutions can be proposed and discussed. |
|
| |
| RFC 6105 | IPv6 Router Advertisement Guard |
| |
| Authors: | E. Levy-Abegnoli, G. Van de Velde, C. Popoviciu, J. Mohacsi. |
| Date: | February 2011 |
| Formats: | txt html json |
| Updated by: | RFC 7113 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6105 |
|
Routed protocols are often susceptible to spoof attacks. The canonical solution for IPv6 is Secure Neighbor Discovery (SEND), a solution that is non-trivial to deploy. This document proposes a light-weight alternative and complement to SEND based on filtering in the layer-2 network fabric, using a variety of filtering criteria, including, for example, SEND status. |
|
| |
| RFC 6109 | La Posta Elettronica Certificata - Italian Certified Electronic Mail |
| |
| Authors: | C. Petrucci, F. Gennai, A. Shahin, A. Vinciarelli. |
| Date: | April 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6109 |
|
Since 1997, the Italian laws have recognized electronic delivery systems as legally usable. In 2005, after two years of technical tests, the characteristics of an official electronic delivery service, named certified electronic mail (in Italian "PostaElettronica Certificata") were defined, giving the system legal standing.
The design of the entire system was carried out by the NationalCenter for Informatics in the Public Administration of Italy(DigitPA), followed by efforts for the implementation and testing of the service. The DigitPA has given the Italian National ResearchCouncil (CNR), and in particular the Institute of Information Science and Technologies at the CNR (ISTI), the task of running tests on providers of the service to guarantee the correct implementation and interoperability. This document describes the certified email system adopted in Italy. It represents the system as it is at the moment of writing, following the technical regulations that were written based upon the Italian Law DPR. November 2, 2005. |
|
| |
| RFC 6114 | The 128-Bit Blockcipher CLEFIA |
| |
| Authors: | M. Katagi, S. Moriai. |
| Date: | March 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6114 |
|
This document describes the specification of the blockcipher CLEFIA.CLEFIA is a 128-bit blockcipher, with key lengths of 128, 192, and256 bits, which is compatible with the interface of the AdvancedEncryption Standard (AES). The algorithm of CLEFIA was published in2007, and its security has been scrutinized in the public community.CLEFIA is one of the new-generation lightweight blockcipher algorithms designed after AES. Among them, CLEFIA offers high performance in software and hardware as well as lightweight implementation in hardware. CLEFIA will be of benefit to theInternet, which will be connected to more distributed and constrained devices. |
|
| |
| RFC 6115 | Recommendation for a Routing Architecture |
| |
| Authors: | T. Li, Ed.. |
| Date: | February 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6115 |
|
It is commonly recognized that the Internet routing and addressing architecture is facing challenges in scalability, multihoming, and inter-domain traffic engineering. This document presents, as a recommendation of future directions for the IETF, solutions that could aid the future scalability of the Internet. To this end, this document surveys many of the proposals that were brought forward for discussion in this activity, as well as some of the subsequent analysis and the architectural recommendation of the chairs. This document is a product of the Routing Research Group. |
|
| |
| RFC 6124 | An EAP Authentication Method Based on the Encrypted Key Exchange (EKE) Protocol |
| |
| Authors: | Y. Sheffer, G. Zorn, H. Tschofenig, S. Fluhrer. |
| Date: | February 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6124 |
|
The Extensible Authentication Protocol (EAP) describes a framework that allows the use of multiple authentication mechanisms. This document defines an authentication mechanism for EAP called EAP-EKE, based on the Encrypted Key Exchange (EKE) protocol. This method provides mutual authentication through the use of a short, easy to remember password. Compared with other common authentication methods, EAP-EKE is not susceptible to dictionary attacks. Neither does it require the availability of public-key certificates. |
|
| |
| RFC 6127 | IPv4 Run-Out and IPv4-IPv6 Co-Existence Scenarios |
| |
| Authors: | J. Arkko, M. Townsley. |
| Date: | May 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6127 |
|
When IPv6 was designed, it was expected that the transition from IPv4 to IPv6 would occur more smoothly and expeditiously than experience has revealed. The growth of the IPv4 Internet and predicted depletion of the free pool of IPv4 address blocks on a foreseeable horizon has highlighted an urgent need to revisit IPv6 deployment models. This document provides an overview of deployment scenarios with the goal of helping to understand what types of additional tools the industry needs to assist in IPv4 and IPv6 co-existence and transition.
This document was originally created as input to the Montreal co- existence interim meeting in October 2008, which led to the rechartering of the Behave and Softwire working groups to take on newIPv4 and IPv6 co-existence work. This document is published as a historical record of the thinking at the time, but hopefully will also help readers understand the rationale behind current IETF tools for co-existence and transition. |
|
| |
| RFC 6129 | The 'application/tei+xml' Media Type |
| |
| Authors: | L. Romary, S. Lundberg. |
| Date: | February 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6129 |
|
This document defines the 'application/tei+xml' media type for markup languages defined in accordance with the Text Encoding andInterchange guidelines. |
|
| |
| RFC 6133 | Sieve Email Filtering: Use of Presence Information with Auto-Responder Functionality |
| |
| Authors: | R. George, B. Leiba, A. Melnikov. |
| Date: | July 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6133 |
|
This document describes how the Sieve email filtering language, along with some extensions, can be used to create automatic replies to incoming electronic mail messages based on the address book and presence information of the recipient. |
|
| |
| RFC 6136 | Layer 2 Virtual Private Network (L2VPN) Operations, Administration, and Maintenance (OAM) Requirements and Framework |
| |
| Authors: | A. Sajassi, Ed., D. Mohan, Ed.. |
| Date: | March 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6136 |
|
This document provides framework and requirements for Layer 2 VirtualPrivate Network (L2VPN) Operations, Administration, and Maintenance(OAM). The OAM framework is intended to provide OAM layering acrossL2VPN services, pseudowires (PWs), and Packet Switched Network (PSN) tunnels. This document is intended to identify OAM requirements forL2VPN services, i.e., Virtual Private LAN Service (VPLS), VirtualPrivate Wire Service (VPWS), and IP-only LAN Service (IPLS).Furthermore, if L2VPN service OAM requirements impose specific requirements on PW OAM and/or PSN OAM, those specific PW and/or PSNOAM requirements are also identified. |
|
| |
| RFC 6138 | LDP IGP Synchronization for Broadcast Networks |
| |
|
|
RFC 5443 describes a mechanism to achieve LDP IGP synchronization to prevent black-holing traffic (e.g., VPN) when an Interior GatewayProtocol (IGP) is operational on a link but Label DistributionProtocol (LDP) is not. If this mechanism is applied to broadcast links that have more than one LDP peer, the metric increase procedure can only be applied to the link as a whole but not to an individual peer. When a new LDP peer comes up on a broadcast network, this can result in loss of traffic through other established peers on that network. This document describes a mechanism to address that use- case without dropping traffic. The mechanism does not introduce any protocol message changes. |
|
| |
| RFC 6139 | Routing and Addressing in Networks with Global Enterprise Recursion (RANGER) Scenarios |
| |
| Authors: | S. Russert, Ed., E. Fleischman, Ed., F. Templin, Ed.. |
| Date: | February 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6139 |
|
"Routing and Addressing in Networks with Global Enterprise Recursion(RANGER)" (RFC 5720) provides an architectural framework for scalable routing and addressing. It provides an incrementally deployable approach for scalability, provider independence, mobility, multihoming, traffic engineering, and security. This document describes a series of use cases in order to showcase the architectural capabilities. It further shows how the RANGER architecture restores the network-within-network principles originally intended for the sustained growth of the Internet. |
|
| |
| RFC 6142 | ANSI C12.22, IEEE 1703, and MC12.22 Transport Over IP |
| |
| Authors: | A. Moise, J. Brodkin. |
| Date: | March 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6142 |
|
This RFC provides a framework for transporting ANSI C12.22/IEEE1703/MC12.22 Advanced Metering Infrastructure (AMI) Application LayerMessages on an IP network.
This document is not an official submission on behalf of the ANSIC12.19 and C12.22 working groups. It was created by participants in those groups, building on knowledge of several proprietary C12.22- over-IP implementations. The content of this document is an expression of a consensus aggregation of those implementations. |
|
| |
| RFC 6143 | The Remote Framebuffer Protocol |
| |
| Authors: | T. Richardson, J. Levine. |
| Date: | March 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6143 |
|
RFB ("remote framebuffer") is a simple protocol for remote access to graphical user interfaces that allows a client to view and control a window system on another computer. Because it works at the framebuffer level, RFB is applicable to all windowing systems and applications. This document describes the protocol used to communicate between an RFB client and RFB server. RFB is the protocol used in VNC. |
|
| |
| RFC 6144 | Framework for IPv4/IPv6 Translation |
| |
| Authors: | F. Baker, X. Li, C. Bao, K. Yin. |
| Date: | April 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6144 |
|
This note describes a framework for IPv4/IPv6 translation. This is in the context of replacing Network Address Translation - ProtocolTranslation (NAT-PT), which was deprecated by RFC 4966, and to enable networks to have IPv4 and IPv6 coexist in a somewhat rational manner while transitioning to an IPv6 network. |
|
| |
| RFC 6149 | MD2 to Historic Status |
| |
|
|
This document retires MD2 and discusses the reasons for doing so.This document moves RFC 1319 to Historic status. |
|
| |
| RFC 6150 | MD4 to Historic Status |
| |
|
|
This document retires RFC 1320, which documents the MD4 algorithm, and discusses the reasons for doing so. This document moves RFC 1320 to Historic status. |
|
| |
| RFC 6151 | Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms |
| |
|
|
This document updates the security considerations for the MD5 message digest algorithm. It also updates the security considerations forHMAC-MD5. |
|
| |
| RFC 6159 | Session-Specific Explicit Diameter Request Routing |
| |
| Authors: | T. Tsou, G. Zorn, T. Taylor, Ed.. |
| Date: | April 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6159 |
|
This document describes a mechanism to enable specific Diameter proxies to remain in the path of all message exchanges constituting aDiameter session. |
|
| |
| RFC 6163 | Framework for GMPLS and Path Computation Element (PCE) Control of Wavelength Switched Optical Networks (WSONs) |
| |
| Authors: | Y. Lee, Ed., G. Bernstein, Ed., W. Imajuku. |
| Date: | April 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6163 |
|
This document provides a framework for applying Generalized Multi-Protocol Label Switching (GMPLS) and the Path Computation Element(PCE) architecture to the control of Wavelength Switched OpticalNetworks (WSONs). In particular, it examines Routing and WavelengthAssignment (RWA) of optical paths.
This document focuses on topological elements and path selection constraints that are common across different WSON environments; as such, it does not address optical impairments in any depth. |
|
| |
| RFC 6167 | URI Scheme for Java(tm) Message Service 1.0 |
| |
| Authors: | M. Phillips, P. Adams, D. Rokicki, E. Johnson. |
| Date: | April 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6167 |
|
This document defines the format of Uniform Resource Identifiers(URIs) as defined in RFC 3986, for designating connections and destination addresses used in the Java(tm) Messaging Service (JMS).It was originally designed for particular uses, but applies generally wherever a JMS URI is needed to describe the connection to a JMS provider, and access to a JMS Destination. The syntax of this JMSURI is not compatible with previously existing, but unregistered,"jms" URI schemes. However, the expressiveness of the scheme described herein should satisfy the requirements of all existing circumstances. |
|
| |
| RFC 6168 | Requirements for Management of Name Servers for the DNS |
| |
| Authors: | W. Hardaker. |
| Date: | May 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6168 |
|
Management of name servers for the Domain Name System (DNS) has traditionally been done using vendor-specific monitoring, configuration, and control methods. Although some service monitoring platforms can test the functionality of the DNS itself, there is not an interoperable way to manage (monitor, control, and configure) the internal aspects of a name server itself.
This document discusses the requirements of a management system for name servers and can be used as a shopping list of needed features for such a system. |
|
| |
| RFC 6169 | Security Concerns with IP Tunneling |
| |
| Authors: | S. Krishnan, D. Thaler, J. Hoagland. |
| Date: | April 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6169 |
|
A number of security concerns with IP tunnels are documented in this memo. The intended audience of this document includes network administrators and future protocol developers. The primary intent of this document is to raise the awareness level regarding the security issues with IP tunnels as deployed and propose strategies for the mitigation of those issues. |
|
| |
| RFC 6174 | Definition of IETF Working Group Document States |
| |
| Authors: | E. Juskevicius. |
| Date: | March 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6174 |
|
The IETF Datatracker tool needs to be enhanced to make it possible for Working Group (WG) Chairs to provide IETF participants with more information about the status and progression of WG documents than is currently possible.
This document defines new states and status annotation tags that need to be added to the Datatracker to enable WG Chairs and theirDelegates to track the status of Internet-Drafts (I-Ds) that are associated with their WGs. This document also describes the meaning of all previously implemented I-D states and substate annotation tags currently used by IETF Area Directors to indicate the status of I-Ds that have been sent to the IESG for evaluation and publication. |
|
| |
| RFC 6175 | Requirements to Extend the Datatracker for IETF Working Group Chairs and Authors |
| |
| Authors: | E. Juskevicius. |
| Date: | March 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6175 |
|
This document specifies requirements for new functionality to be added to the IETF Datatracker tool to make it possible for WorkingGroup (WG) Chairs and their Delegates to input and update the status of the Internet-Drafts (I-Ds) associated with their WGs. After these requirements are implemented, WG Chairs will be able to use theDatatracker to provide everyone with more information about the status and progression of WG I-Ds than is currently possible. |
|
| |
| RFC 6180 | Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment |
| |
| Authors: | J. Arkko, F. Baker. |
| Date: | May 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6180 |
|
The Internet continues to grow beyond the capabilities of IPv4. An expansion in the address space is clearly required. With its increase in the number of available prefixes and addresses in a subnet, and improvements in address management, IPv6 is the only real option on the table. Yet, IPv6 deployment requires some effort, resources, and expertise. The availability of many different deployment models is one reason why expertise is required. This document discusses the IPv6 deployment models and migration tools, and it recommends ones that have been found to work well in operational networks in many common situations. |
|
| |
| RFC 6181 | Threat Analysis for TCP Extensions for Multipath Operation with Multiple Addresses |
| |
| Authors: | M. Bagnulo. |
| Date: | March 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6181 |
|
Multipath TCP (MPTCP for short) describes the extensions proposed forTCP so that endpoints of a given TCP connection can use multiple paths to exchange data. Such extensions enable the exchange of segments using different source-destination address pairs, resulting in the capability of using multiple paths in a significant number of scenarios. Some level of multihoming and mobility support can be achieved through these extensions. However, the support for multipleIP addresses per endpoint may have implications on the security of the resulting MPTCP. This note includes a threat analysis for MPTCP. |
|
| |
| RFC 6182 | Architectural Guidelines for Multipath TCP Development |
| |
| Authors: | A. Ford, C. Raiciu, M. Handley, S. Barre, J. Iyengar. |
| Date: | March 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6182 |
|
Hosts are often connected by multiple paths, but TCP restricts communications to a single path per transport connection. Resource usage within the network would be more efficient were these multiple paths able to be used concurrently. This should enhance user experience through improved resilience to network failure and higher throughput.
This document outlines architectural guidelines for the development of a Multipath Transport Protocol, with references to how these architectural components come together in the development of aMultipath TCP (MPTCP). This document lists certain high-level design decisions that provide foundations for the design of the MPTCP protocol, based upon these architectural requirements. |
|
| |
| RFC 6183 | IP Flow Information Export (IPFIX) Mediation: Framework |
| |
| Authors: | A. Kobayashi, B. Claise, G. Muenz, K. Ishibashi. |
| Date: | April 2011 |
| Formats: | txt html json |
| Updates: | RFC 5470 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6183 |
|
This document describes a framework for IP Flow Information Export(IPFIX) Mediation. This framework extends the IPFIX reference model specified in RFC 5470 by defining the IPFIX Mediator components. |
|
| |
| RFC 6189 | ZRTP: Media Path Key Agreement for Unicast Secure RTP |
| |
| Authors: | P. Zimmermann, A. Johnston, Ed., J. Callas. |
| Date: | April 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6189 |
|
This document defines ZRTP, a protocol for media path Diffie-Hellman exchange to agree on a session key and parameters for establishing unicast Secure Real-time Transport Protocol (SRTP) sessions for Voice over IP (VoIP) applications. The ZRTP protocol is media path keying because it is multiplexed on the same port as RTP and does not require support in the signaling protocol. ZRTP does not assume aPublic Key Infrastructure (PKI) or require the complexity of certificates in end devices. For the media session, ZRTP provides confidentiality, protection against man-in-the-middle (MiTM) attacks, and, in cases where the signaling protocol provides end-to-end integrity protection, authentication. ZRTP can utilize a SessionDescription Protocol (SDP) attribute to provide discovery and authentication through the signaling channel. To provide best effortSRTP, ZRTP utilizes normal RTP/AVP (Audio-Visual Profile) profiles.ZRTP secures media sessions that include a voice media stream and can also secure media sessions that do not include voice by using an optional digital signature. |
|
| |
| RFC 6192 | Protecting the Router Control Plane |
| |
| Authors: | D. Dugal, C. Pignataro, R. Dunn. |
| Date: | March 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6192 |
|
This memo provides a method for protecting a router's control plane from undesired or malicious traffic. In this approach, all legitimate router control plane traffic is identified. Once legitimate traffic has been identified, a filter is deployed in the router's forwarding plane. That filter prevents traffic not specifically identified as legitimate from reaching the router's control plane, or rate-limits such traffic to an acceptable level.
Note that the filters described in this memo are applied only to traffic that is destined for the router, and not to all traffic that is passing through the router. |
|
| |
| RFC 6193 | Media Description for the Internet Key Exchange Protocol (IKE) in the Session Description Protocol (SDP) |
| |
| Authors: | M. Saito, D. Wing, M. Toyama. |
| Date: | April 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6193 |
|
This document specifies how to establish a media session that represents a virtual private network using the Session InitiationProtocol for the purpose of on-demand media/application sharing between peers. It extends the protocol identifier of the SessionDescription Protocol (SDP) so that it can negotiate use of theInternet Key Exchange Protocol (IKE) for media sessions in the SDP offer/answer model. It also specifies a method to boot up IKE and generate IPsec security associations using a self-signed certificate. |
|
| |
| RFC 6194 | Security Considerations for the SHA-0 and SHA-1 Message-Digest Algorithms |
| |
| Authors: | T. Polk, L. Chen, S. Turner, P. Hoffman. |
| Date: | March 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6194 |
|
This document includes security considerations for the SHA-0 andSHA-1 message digest algorithm. |
|
| |
| RFC 6198 | Requirements for the Graceful Shutdown of BGP Sessions |
| |
| Authors: | B. Decraene, P. Francois, C. Pelsser, Z. Ahmad, A.J. Elizondo Armengol, T. Takeda. |
| Date: | April 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6198 |
|
The Border Gateway Protocol (BGP) is heavily used in Service Provider networks for both Internet and BGP/MPLS VPN services. For resiliency purposes, redundant routers and BGP sessions can be deployed to reduce the consequences of an Autonomous System Border Router (ASBR) or BGP session breakdown on customers' or peers' traffic. However, simply taking down or even bringing up a BGP session for maintenance purposes may still induce connectivity losses during the BGP convergence. This is no longer satisfactory for new applications(e.g., voice over IP, online gaming, VPN). Therefore, a solution is required for the graceful shutdown of a (set of) BGP session(s) in order to limit the amount of traffic loss during a planned shutdown.This document expresses requirements for such a solution. |
|
| |
| RFC 6201 | Device Reset Characterization |
| |
|
|
An operational forwarding device may need to be restarted(automatically or manually) for a variety of reasons, an event called a "reset" in this document. Since there may be an interruption in the forwarding operation during a reset, it is useful to know how long a device takes to resume the forwarding operation.
This document specifies a methodology for characterizing reset (and reset time) during benchmarking of forwarding devices and provides clarity and consistency in reset test procedures beyond what is specified in RFC 2544. Therefore, it updates RFC 2544. This document also defines the benchmarking term "reset time" and, only in this, updates RFC 1242. |
|
| |
| RFC 6202 | Known Issues and Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP |
| |
| Authors: | S. Loreto, P. Saint-Andre, S. Salsano, G. Wilkins. |
| Date: | April 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6202 |
|
On today's Internet, the Hypertext Transfer Protocol (HTTP) is often used (some would say abused) to enable asynchronous, "server- initiated" communication from a server to a client as well as communication from a client to a server. This document describes known issues and best practices related to such "bidirectional HTTP" applications, focusing on the two most common mechanisms: HTTP long polling and HTTP streaming. |
|
| |
| RFC 6204 | Basic Requirements for IPv6 Customer Edge Routers |
| |
| Authors: | H. Singh, W. Beebee, C. Donley, B. Stark, O. Troan, Ed.. |
| Date: | April 2011 |
| Formats: | txt json html |
| Obsoleted by: | RFC 7084 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6204 |
|
This document specifies requirements for an IPv6 Customer Edge (CE) router. Specifically, the current version of this document focuses on the basic provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attached to it. |
|
| |
| RFC 6207 | The Media Types application/mods+xml, application/mads+xml, application/mets+xml, application/marcxml+xml, and application/sru+xml |
| |
| Authors: | R. Denenberg, Ed.. |
| Date: | April 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6207 |
|
This document specifies media types for the following formats: MODS(Metadata Object Description Schema), MADS (Metadata AuthorityDescription Schema), METS (Metadata Encoding and TransmissionStandard), MARCXML (MARC21 XML Schema), and the SRU (Search/Retrieve via URL Response Format) protocol response XML schema. These are allXML schemas providing representations of various forms of information including metadata and search results. |
|
| |
| RFC 6208 | Cloud Data Management Interface (CDMI) Media Types |
| |
| Authors: | K. Sankar, Ed., A. Jones. |
| Date: | April 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6208 |
|
This document describes several Internet media types defined for theCloud Data Management Interface (CDMI) by the Storage NetworkingIndustry Association (SNIA). The media types are: o application/cdmi-object o application/cdmi-container o application/cdmi-domain o application/cdmi-capability o application/cdmi-queue |
|
| |
| RFC 6209 | Addition of the ARIA Cipher Suites to Transport Layer Security (TLS) |
| |
| Authors: | W. Kim, J. Lee, J. Park, D. Kwon. |
| Date: | April 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6209 |
|
This document specifies a set of cipher suites for the TransportLayer Security (TLS) protocol to support the ARIA encryption algorithm as a block cipher. |
|
| |
| RFC 6214 | 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. |
|
| |
| RFC 6215 | MPLS Transport Profile User-to-Network and Network-to-Network Interfaces |
| |
| Authors: | M. Bocci, L. Levrau, D. Frost. |
| Date: | April 2011 |
| Formats: | txt json html |
| Updates: | RFC 5921 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6215 |
|
The framework for MPLS in transport networks (RFC 5921) provides reference models for the MPLS Transport Profile (MPLS-TP) TransportService Interfaces, which are a User-to-Network Interface (UNI), and a Network-to-Network Interface (NNI). This document updates those reference models to show detailed reference points for these interfaces, along with further clarification of the functional architecture of MPLS-TP at a UNI and NNI.
This document is a product of a joint Internet Engineering Task Force(IETF) / International Telecommunication Union TelecommunicationStandardization Sector (ITU-T) effort to include an MPLS TransportProfile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge(PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. |
|
| |
| RFC 6216 | Example Call Flows Using Session Initiation Protocol (SIP) Security Mechanisms |
| |
| Authors: | C. Jennings, K. Ono, R. Sparks, B. Hibbard, Ed.. |
| Date: | April 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6216 |
|
This document shows example call flows demonstrating the use ofTransport Layer Security (TLS), and Secure/Multipurpose Internet MailExtensions (S/MIME) in Session Initiation Protocol (SIP). It also provides information that helps implementers build interoperable SIP software. To help facilitate interoperability testing, it includes certificates used in the example call flows and processes to create certificates for testing. |
|
| |
| RFC 6218 | Cisco Vendor-Specific RADIUS Attributes for the Delivery of Keying Material |
| |
| Authors: | G. Zorn, T. Zhang, J. Walker, J. Salowey. |
| Date: | April 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6218 |
|
This document defines a set of vendor-specific RADIUS Attributes designed to allow both the secure transmission of cryptographic keying material and strong authentication of any RADIUS message.These attributes have been allocated from the Cisco vendor-specific space and have been implemented by multiple vendors. |
|
| |
| RFC 6219 | The China Education and Research Network (CERNET) IVI Translation Design and Deployment for the IPv4/IPv6 Coexistence and Transition |
| |
| Authors: | X. Li, C. Bao, M. Chen, H. Zhang, J. Wu. |
| Date: | May 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6219 |
|
This document presents the China Education and Research Network(CERNET)'s IVI translation design and deployment for the IPv4/IPv6 coexistence and transition.
The IVI is a prefix-specific and stateless address mapping mechanism for "an IPv6 network to the IPv4 Internet" and "the IPv4 Internet to an IPv6 network" scenarios. In the IVI design, subsets of the ISP'sIPv4 addresses are embedded in the ISP's IPv6 addresses, and the hosts using these IPv6 addresses can therefore communicate with the global IPv6 Internet directly and can communicate with the globalIPv4 Internet via stateless translators. The communications can either be IPv6 initiated or IPv4 initiated. The IVI mechanism supports the end-to-end address transparency and incremental deployment. The IVI is an early design deployed in the CERNET as a reference for the IETF standard documents on IPv4/IPv6 stateless translation. |
|
| |
| RFC 6220 | Defining the Role and Function of IETF Protocol Parameter Registry Operators |
| |
| Authors: | D. McPherson, Ed., O. Kolkman, Ed., J. Klensin, Ed., G. Huston, Ed., Internet Architecture Board. |
| Date: | April 2011 |
| Formats: | txt json html |
| Obsoleted by: | RFC 8722 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6220 |
|
Many Internet Engineering Task Force (IETF) protocols make use of commonly defined values that are passed in messages or packets. To ensure consistent interpretation of these values between independent implementations, there is a need to ensure that the values and associated semantic intent are uniquely defined. The IETF uses registry functions to record assigned protocol parameter values and their associated semantic intentions. For each IETF protocol parameter, it is current practice for the IETF to delegate the role of Protocol Parameter Registry Operator to a nominated entity. This document provides a description of, and the requirements for, these delegated functions. |
|
| |
| RFC 6224 | Base Deployment for Multicast Listener Support in Proxy Mobile IPv6 (PMIPv6) Domains |
| |
| Authors: | T. Schmidt, M. Waehlisch, S. Krishnan. |
| Date: | April 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6224 |
|
This document describes deployment options for activating multicast listener functions in Proxy Mobile IPv6 domains without modifying mobility and multicast protocol standards. Similar to home agents inMobile IPv6, Local Mobility Anchors of Proxy Mobile IPv6 serve as multicast subscription anchor points, while Mobile Access Gateways provide Multicast Listener Discovery (MLD) proxy functions. In this scenario, mobile nodes remain agnostic of multicast mobility operations. Support for mobile multicast senders is outside the scope of this document. |
|
| |
| RFC 6227 | Design Goals for Scalable Internet Routing |
| |
| Authors: | T. Li, Ed.. |
| Date: | May 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6227 |
|
It is commonly recognized that the Internet routing and addressing architecture is facing challenges in scalability, mobility, multi- homing, and inter-domain traffic engineering. The Routing ResearchGroup is investigating an alternate architecture to meet these challenges. This document consists of a prioritized list of design goals for the target architecture. |
|
| |
| RFC 6229 | Test Vectors for the Stream Cipher RC4 |
| |
| Authors: | J. Strombergson, S. Josefsson. |
| Date: | May 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6229 |
|
This document contains test vectors for the stream cipher RC4. |
|
| |
| RFC 6234 | US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF) |
| |
|
|
The United States of America has adopted a suite of Secure HashAlgorithms (SHAs), including four beyond SHA-1, as part of a FederalInformation Processing Standard (FIPS), namely SHA-224, SHA-256,SHA-384, and SHA-512. This document makes open source code performing these SHA hash functions conveniently available to theInternet community. The sample code supports input strings of arbitrary bit length. Much of the text herein was adapted by the authors from FIPS 180-2.
This document replaces RFC 4634, fixing errata and adding code for anHMAC-based extract-and-expand Key Derivation Function, HKDF (RFC5869). As with RFC 4634, code to perform SHA-based Hashed MessageAuthentication Codes (HMACs) is also included. |
|
| |
| RFC 6238 | TOTP: Time-Based One-Time Password Algorithm |
| |
| Authors: | D. M'Raihi, S. Machani, M. Pei, J. Rydell. |
| Date: | May 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6238 |
|
This document describes an extension of the One-Time Password (OTP) algorithm, namely the HMAC-based One-Time Password (HOTP) algorithm, as defined in RFC 4226, to support the time-based moving factor. TheHOTP algorithm specifies an event-based OTP algorithm, where the moving factor is an event counter. The present work bases the moving factor on a time value. A time-based variant of the OTP algorithm provides short-lived OTP values, which are desirable for enhanced security.
The proposed algorithm can be used across a wide range of network applications, from remote Virtual Private Network (VPN) access andWi-Fi network logon to transaction-oriented Web applications. The authors believe that a common and shared algorithm will facilitate adoption of two-factor authentication on the Internet by enabling interoperability across commercial and open-source implementations. |
|
| |
| RFC 6244 | An Architecture for Network Management Using NETCONF and YANG |
| |
| Authors: | P. Shafer. |
| Date: | June 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6244 |
|
The Network Configuration Protocol (NETCONF) gives access to native capabilities of the devices within a network, defining methods for manipulating configuration databases, retrieving operational data, and invoking specific operations. YANG provides the means to define the content carried via NETCONF, both data and operations. Using both technologies, standard modules can be defined to give interoperability and commonality to devices, while still allowing devices to express their unique capabilities.
This document describes how NETCONF and YANG help build network management applications that meet the needs of network operators. |
|
| |
| RFC 6246 | Virtual Private LAN Service (VPLS) Interoperability with Customer Edge (CE) Bridges |
| |
| Authors: | A. Sajassi, Ed., F. Brockners, D. Mohan, Ed., Y. Serbest. |
| Date: | June 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6246 |
|
One of the main motivations behind Virtual Private LAN Service (VPLS) is its ability to provide connectivity not only among customer routers and servers/hosts but also among customer IEEE bridges. VPLS is expected to deliver the same level of service that current enterprise users are accustomed to from their own enterprise bridged networks or their Ethernet Service Providers.
When customer edge (CE) devices are IEEE bridges, then there are certain issues and challenges that need to be accounted for in a VPLS network. The majority of these issues have been addressed in theIEEE 802.1ad standard for provider bridges and they can be leveraged for VPLS networks. This document extends the provider edge (PE) model described in RFC 4664 based on IEEE 802.1ad bridge module, and it illustrates a clear demarcation between the IEEE bridge module andIETF LAN emulation module. By doing so, it shows that the majority of interoperability issues with CE bridges can be delegated to the802.1ad bridge module, thus removing the burden on the IETF LAN emulation module within a VPLS PE. |
|
| |
| RFC 6247 | Moving the Undeployed TCP Extensions RFC 1072, RFC 1106, RFC 1110, RFC 1145, RFC 1146, RFC 1379, RFC 1644, and RFC 1693 to Historic Status |
| |
|
|
This document reclassifies several TCP extensions that have never seen widespread use to Historic status. The affected RFCs are RFC1072, RFC 1106, RFC 1110, RFC 1145, RFC 1146, RFC 1379, RFC 1644, andRFC 1693. |
|
| |
| RFC 6248 | RFC 4148 and the IP Performance Metrics (IPPM) Registry of Metrics Are Obsolete |
| |
|
|
This memo reclassifies RFC 4148, "IP Performance Metrics (IPPM)Metrics Registry", as Obsolete, and withdraws the IANA IPPM MetricsRegistry itself from use because it is obsolete. The current registry structure has been found to be insufficiently detailed to uniquely identify IPPM metrics. Despite apparent efforts to find current or even future users, no one responded to the call for interest in the RFC 4148 registry during the second half of 2010. |
|
| |
| RFC 6250 | Evolution of the IP Model |
| |
| Authors: | D. Thaler. |
| Date: | May 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6250 |
|
This RFC attempts to document various aspects of the IP service model and how it has evolved over time. In particular, it attempts to document the properties of the IP layer as they are seen by upper- layer protocols and applications, especially properties that were(and, at times, still are) incorrectly perceived to exist as well as properties that would cause problems if changed. The discussion of these properties is organized around evaluating a set of claims, or misconceptions. Finally, this document provides some guidance to protocol designers and implementers. |
|
| |
| RFC 6251 | Using Kerberos Version 5 over the Transport Layer Security (TLS) Protocol |
| |
| Authors: | S. Josefsson. |
| Date: | May 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6251 |
|
This document specifies how the Kerberos V5 protocol can be transported over the Transport Layer Security (TLS) protocol in order to provide additional security features. |
|
| |
| RFC 6252 | A Framework of Media-Independent Pre-Authentication (MPA) for Inter-Domain Handover Optimization |
| |
| Authors: | A. Dutta, Ed., V. Fajardo, Y. Ohba, K. Taniuchi, H. Schulzrinne. |
| Date: | June 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6252 |
|
This document describes Media-independent Pre-Authentication (MPA), a new handover optimization mechanism that addresses the issues on existing mobility management protocols and mobility optimization mechanisms to support inter-domain handover. MPA is a mobile- assisted, secure handover optimization scheme that works over any link layer and with any mobility management protocol, and is most applicable to supporting optimization during inter-domain handover.MPA's pre-authentication, pre-configuration, and proactive handover techniques allow many of the handoff-related operations to take place before the mobile node has moved to the new network. We describe the details of all the associated techniques and their applicability for different scenarios involving various mobility protocols during inter-domain handover. We have implemented the MPA mechanism for various network-layer and application-layer mobility protocols, and we report a summary of experimental performance results in this document.
This document is a product of the IP Mobility Optimizations (MOBOPTS)Research Group. |
|
| |
| RFC 6254 | Request to Move RFC 2754 to Historic Status |
| |
|
|
RFC 2754 requested that each time IANA made an address assignment, it was to create appropriate inetnum and as-block objects and digitally sign them. The purpose was to distribute the IANA-held public key in software implementations of the Distributed Routing Policy System.In practice, this was never done on the public Internet. This document requests that RFC 2754 be moved to Historic status. |
|
| |
| RFC 6255 | Delay-Tolerant Networking Bundle Protocol IANA Registries |
| |
| Authors: | M. Blanchet. |
| Date: | May 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6255 |
|
The Delay-Tolerant Networking (DTN) Research Group research group has defined many protocols such as the Bundle Protocol and LickliderTransmission Protocol. The specifications of these protocols contain fields that are subject to a registry. For the purpose of its research work, the group created ad hoc registries. As the specifications are stable and have multiple interoperable implementations, the group would like to hand off the registries toIANA for official custody. This document describes the actions executed by IANA. |
|
| |
| RFC 6256 | Using Self-Delimiting Numeric Values in Protocols |
| |
| Authors: | W. Eddy, E. Davies. |
| Date: | May 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6256 |
|
Self-Delimiting Numeric Values (SDNVs) have recently been introduced as a field type in proposed Delay-Tolerant Networking protocols.SDNVs encode an arbitrary-length non-negative integer or arbitrary- length bitstring with minimum overhead. They are intended to provide protocol flexibility without sacrificing economy and to assist in future-proofing protocols under development. This document describes formats and algorithms for SDNV encoding and decoding, along with notes on implementation and usage. This document is a product of theDelay-Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. |
|
| |
| RFC 6264 | An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition |
| |
| Authors: | S. Jiang, D. Guo, B. Carpenter. |
| Date: | June 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6264 |
|
Global IPv6 deployment was slower than originally expected. As IPv4 address exhaustion approaches, IPv4 to IPv6 transition issues become more critical and less tractable. Host-based transition mechanisms used in dual-stack environments cannot meet all transition requirements. Most end users are not sufficiently expert to configure or maintain host-based transition mechanisms. Carrier-Grade NAT (CGN) devices with integrated transition mechanisms can reduce the operational changes required during the IPv4 to IPv6 migration or coexistence period.
This document proposes an incremental CGN approach for IPv6 transition. It can provide IPv6 access services for IPv6 hosts andIPv4 access services for IPv4 hosts while leaving much of a legacyISP network unchanged during the initial stage of IPv4 to IPv6 migration. Unlike CGN alone, incremental CGN also supports and encourages smooth transition towards dual-stack or IPv6-only ISP networks. An integrated configurable CGN device and an adaptive home gateway (HG) device are described. Both are reusable during different transition phases, avoiding multiple upgrades. This enables IPv6 migration to be incrementally achieved according to real user requirements. |
|
| |
| RFC 6267 | MIKEY-IBAKE: Identity-Based Authenticated Key Exchange (IBAKE) Mode of Key Distribution in Multimedia Internet KEYing (MIKEY) |
| |
| Authors: | V. Cakulev, G. Sundaram. |
| Date: | June 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6267 |
|
This document describes a key management protocol variant for theMultimedia Internet KEYing (MIKEY) protocol that relies on a trusted key management service. In particular, this variant utilizesIdentity-Based Authenticated Key Exchange (IBAKE) framework that allows the participating clients to perform mutual authentication and derive a session key in an asymmetric Identity-Based Encryption (IBE) framework. This protocol, in addition to providing mutual authentication, eliminates the key escrow problem that is common in standard IBE and provides perfect forward and backward secrecy. |
|
| |
| RFC 6268 | Additional New ASN.1 Modules for the Cryptographic Message Syntax (CMS) and the Public Key Infrastructure Using X.509 (PKIX) |
| |
|
|
The Cryptographic Message Syntax (CMS) format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates some auxiliary ASN.1 modules to conform to the 2008 version of ASN.1; the1988 ASN.1 modules remain the normative version. There are no bits- on-the-wire changes to any of the formats; this is simply a change to the syntax. |
|
| |
| RFC 6269 | Issues with IP Address Sharing |
| |
| Authors: | M. Ford, Ed., M. Boucadair, A. Durand, P. Levis, P. Roberts. |
| Date: | June 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6269 |
|
The completion of IPv4 address allocations from IANA and the RegionalInternet Registries (RIRs) is causing service providers around the world to question how they will continue providing IPv4 connectivity service to their subscribers when there are no longer sufficient IPv4 addresses to allocate them one per subscriber. Several possible solutions to this problem are now emerging based around the idea of shared IPv4 addressing. These solutions give rise to a number of issues, and this memo identifies those common to all such address sharing approaches. Such issues include application failures, additional service monitoring complexity, new security vulnerabilities, and so on. Solution-specific discussions are out of scope.
Deploying IPv6 is the only perennial way to ease pressure on the public IPv4 address pool without the need for address sharing mechanisms that give rise to the issues identified herein. |
|
| |
| RFC 6271 | Requirements for SIP-Based Session Peering |
| |
| Authors: | J-F. Mule. |
| Date: | June 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6271 |
|
This memo captures protocol requirements to enable session peering of voice, presence, instant messaging, and other types of multimedia traffic. This informational document is intended to link the various use cases described for session peering to protocol solutions. |
|
| |
| RFC 6272 | Internet Protocols for the Smart Grid |
| |
| Authors: | F. Baker, D. Meyer. |
| Date: | June 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6272 |
|
This note identifies the key infrastructure protocols of the InternetProtocol Suite for use in the Smart Grid. The target audience is those people seeking guidance on how to construct an appropriateInternet Protocol Suite profile for the Smart Grid. In practice, such a profile would consist of selecting what is needed for SmartGrid deployment from the picture presented here. |
|
| |
| RFC 6273 | The Secure Neighbor Discovery (SEND) Hash Threat Analysis |
| |
| Authors: | A. Kukec, S. Krishnan, S. Jiang. |
| Date: | June 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6273 |
|
This document analyzes the use of hashes in Secure Neighbor Discovery(SEND), the possible threats to these hashes and the impact of recent attacks on hash functions used by SEND. The SEND specification currently uses the SHA-1 hash algorithm and PKIX certificates and does not provide support for hash algorithm agility. This document provides an analysis of possible threats to the hash algorithms used in SEND. |
|
| |
| RFC 6274 | Security Assessment of the Internet Protocol Version 4 |
| |
| Authors: | F. Gont. |
| Date: | July 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6274 |
|
This document contains a security assessment of the IETF specifications of the Internet Protocol version 4 and of a number of mechanisms and policies in use by popular IPv4 implementations. It is based on the results of a project carried out by the UK's Centre for the Protection of National Infrastructure (CPNI). |
|
| |
| RFC 6278 | Use of Static-Static Elliptic Curve Diffie-Hellman Key Agreement in Cryptographic Message Syntax |
| |
| Authors: | J. Herzog, R. Khazan. |
| Date: | June 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6278 |
|
This document describes how to use the 'static-static Elliptic CurveDiffie-Hellman key-agreement scheme (i.e., Elliptic Curve Diffie-Hellman where both participants use static Diffie-Hellman values) with the Cryptographic Message Syntax. In this form of key agreement, the Diffie-Hellman values of both the sender and receiver are long-term values contained in certificates. |
|
| |
| RFC 6279 | Proxy Mobile IPv6 (PMIPv6) Localized Routing Problem Statement |
| |
| Authors: | M. Liebsch, Ed., S. Jeong, Q. Wu. |
| Date: | June 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6279 |
|
Proxy Mobile IPv6 is the IETF Standard for network-based mobility management. In Proxy Mobile IPv6, mobile nodes are topologically anchored at a Local Mobility Anchor, which forwards all data for registered mobile nodes. The setup and maintenance of localized routing, which allows forwarding of data packets between two mobile nodes' Mobility Access Gateways without involvement of their LocalMobility Anchor in forwarding, is not considered. This document describes the problem space of localized routing in Proxy MobileIPv6. |
|
| |
| RFC 6281 | Understanding Apple's Back to My Mac (BTMM) Service |
| |
| Authors: | S. Cheshire, Z. Zhu, R. Wakikawa, L. Zhang. |
| Date: | June 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6281 |
|
This document describes the implementation of Apple Inc.'s Back to MyMac (BTMM) service. BTMM provides network connectivity between devices so that a user can perform file sharing and screen sharing among multiple computers at home, at work, or on the road. The implementation of BTMM addresses the issues of single sign-on authentication, secure data communication, service discovery, and end-to-end connectivity in the face of Network Address Translators(NATs) and mobility of devices. |
|
| |
| RFC 6287 | OCRA: OATH Challenge-Response Algorithm |
| |
| Authors: | D. M'Raihi, J. Rydell, S. Bajaj, S. Machani, D. Naccache. |
| Date: | June 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6287 |
|
This document describes an algorithm for challenge-response authentication developed by the Initiative for Open Authentication(OATH). The specified mechanisms leverage the HMAC-based One-TimePassword (HOTP) algorithm and offer one-way and mutual authentication, and electronic signature capabilities. |
|
| |
| RFC 6288 | URN Namespace for the Defence Geospatial Information Working Group (DGIWG) |
| |
| Authors: | C. Reed. |
| Date: | August 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6288 |
|
This document describes the Namespace Identifier (NID) for UniformResource Name (URN) Namespace resources published by the DefenceGeospatial Information Working Group (DGIWG). The DGIWG defines and manages resources that utilize this URN name model.
Management activities for these and other resource types are provided by the DGIWG Registry System (DRS). |
|
| |
| RFC 6289 | A Uniform Resource Name (URN) Namespace for CableLabs |
| |
| Authors: | E. Cardona, S. Channabasappa, J-F. Mule. |
| Date: | June 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6289 |
|
This document describes the Namespace Identifier (NID) 'cablelabs' for Uniform Resource Names (URNs) used to identify resources published by Cable Television Laboratories, Inc. (CableLabs).CableLabs specifies and manages resources that utilize this URN identification model. Management activities for these and other resource types are handled by the manager of the CableLabs' AssignedNames and Numbers registry. |
|
| |
| RFC 6292 | Requirements for a Working Group Charter Tool |
| |
|
|
The IETF intends to provide a new tool to Area Directors for the creation, re-chartering, and closing of Working Groups. The tool will also allow the IETF community to view the status of the chartering process. This document describes the requirements for the proposed new tool, and it is intended as input to a later activity for the design and development of such a tool. |
|
| |
| RFC 6293 | Requirements for Internet-Draft Tracking by the IETF Community in the Datatracker |
| |
| Authors: | P. Hoffman. |
| Date: | June 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6293 |
|
The document gives a set of requirements for extending the IETFDatatracker to give individual IETF community members, including theIETF leadership, easy methods for tracking the progress of theInternet-Drafts and RFCs of interest to them. |
|
| |
| RFC 6294 | Survey of Proposed Use Cases for the IPv6 Flow Label |
| |
| Authors: | Q. Hu, B. Carpenter. |
| Date: | June 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6294 |
|
The IPv6 protocol includes a flow label in every packet header, but this field is not used in practice. This paper describes the flow label standard and discusses the implementation issues that it raises. It then describes various published proposals for using the flow label and shows that most of them are inconsistent with the standard. Methods to address this problem are briefly reviewed. We also question whether the standard should be revised. |
|
| |
| RFC 6297 | A Survey of Lower-than-Best-Effort Transport Protocols |
| |
| Authors: | M. Welzl, D. Ros. |
| Date: | June 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6297 |
|
This document provides a survey of transport protocols that are designed to have a smaller bandwidth and/or delay impact on standardTCP than standard TCP itself when they share a bottleneck with it.Such protocols could be used for delay-insensitive "background" traffic, as they provide what is sometimes called a "less than" (or"lower than") best-effort service. |
|
| |
| RFC 6301 | A Survey of Mobility Support in the Internet |
| |
| Authors: | Z. Zhu, R. Wakikawa, L. Zhang. |
| Date: | July 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6301 |
|
Over the last two decades, many efforts have been devoted to developing solutions for mobility support over the global Internet, resulting in a variety of proposed solutions. We conducted a systematic survey of the previous efforts to gain an overall understanding on the solution space of mobility support. This document reports our findings and identifies remaining issues in providing ubiquitous and efficient Internet mobility support on a global scale. |
|
| |
| RFC 6304 | AS112 Nameserver Operations |
| |
|
|
Many sites connected to the Internet make use of IPv4 addresses that are not globally unique. Examples are the addresses designated inRFC 1918 for private use within individual sites.
Devices in such environments may occasionally originate Domain NameSystem (DNS) queries (so-called "reverse lookups") corresponding to those private-use addresses. Since the addresses concerned have only local significance, it is good practice for site administrators to ensure that such queries are answered locally. However, it is not uncommon for such queries to follow the normal delegation path in the public DNS instead of being answered within the site.
It is not possible for public DNS servers to give useful answers to such queries. In addition, due to the wide deployment of private-use addresses and the continuing growth of the Internet, the volume of such queries is large and growing. The AS112 project aims to provide a distributed sink for such queries in order to reduce the load on the IN-ADDR.ARPA authoritative servers. The AS112 project is named after the Autonomous System Number (ASN) that was assigned to it.
This document describes the steps required to install a new AS112 node and offers advice relating to such a node's operation. |
|
| |
| RFC 6305 | I'm Being Attacked by PRISONER.IANA.ORG! |
| |
| Authors: | J. Abley, W. Maton. |
| Date: | July 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6305 |
|
Many sites connected to the Internet make use of IPv4 addresses that are not globally unique. Examples are the addresses designated inRFC 1918 for private use within individual sites.
Hosts should never normally send DNS reverse-mapping queries for those addresses on the public Internet. However, such queries are frequently observed. Authoritative servers are deployed to provide authoritative answers to such queries as part of a loosely coordinated effort known as the AS112 project.
Since queries sent to AS112 servers are usually not intentional, the replies received back from those servers are typically unexpected.Unexpected inbound traffic can trigger alarms on intrusion detection systems and firewalls, and operators of such systems often mistakenly believe that they are being attacked.
This document provides background information and technical advice to those firewall operators. |
|
| |
| RFC 6308 | Overview of the Internet Multicast Addressing Architecture |
| |
|
|
The lack of up-to-date documentation on IP multicast address allocation and assignment procedures has caused a great deal of confusion. To clarify the situation, this memo describes the allocation and assignment techniques and mechanisms currently (as of this writing) in use. |
|
| |
| RFC 6312 | Mobile Networks Considerations for IPv6 Deployment |
| |
|
|
Mobile Internet access from smartphones and other mobile devices is accelerating the exhaustion of IPv4 addresses. IPv6 is widely seen as crucial for the continued operation and growth of the Internet, and in particular, it is critical in mobile networks. This document discusses the issues that arise when deploying IPv6 in mobile networks. Hence, this document can be a useful reference for service providers and network designers. |
|
| |
| RFC 6314 | NAT Traversal Practices for Client-Server SIP |
| |
| Authors: | C. Boulton, J. Rosenberg, G. Camarillo, F. Audet. |
| Date: | July 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6314 |
|
Traversal of the Session Initiation Protocol (SIP) and the sessions it establishes through Network Address Translators (NATs) is a complex problem. Currently, there are many deployment scenarios and traversal mechanisms for media traffic. This document provides concrete recommendations and a unified method for NAT traversal as well as documents corresponding flows. |
|
| |
| RFC 6315 | IANA Registration for Enumservice 'iax' |
| |
| Authors: | E. Guy, K. Darilion. |
| Date: | July 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6315 |
|
This document registers an Enumservice for the Inter-Asterisk eXchange (IAX) protocol according to the guidelines given in RFC6117. |
|
| |
| RFC 6316 | Sockets Application Program Interface (API) for Multihoming Shim |
| |
| Authors: | M. Komu, M. Bagnulo, K. Slavov, S. Sugimoto, Ed.. |
| Date: | July 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6316 |
|
This document specifies sockets API extensions for the multihoming shim layer. The API aims to enable interactions between applications and the multihoming shim layer for advanced locator management, and access to information about failure detection and path exploration.
This document is based on an assumption that a multihomed host is equipped with a conceptual sub-layer (hereafter called "shim sub- layer") inside the IP layer that maintains mappings between identifiers and locators. Examples of the shim are Shim6 and theHost Identity Protocol (HIP). |
|
| |
| RFC 6319 | Issues Associated with Designating Additional Private IPv4 Address Space |
| |
| Authors: | M. Azinger, L. Vegoda. |
| Date: | July 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6319 |
|
When a private network or internetwork grows very large, it is sometimes not possible to address all interfaces using private IPv4 address space because there are not enough addresses. This document describes the problems faced by those networks, the available options, and the issues involved in assigning a new block of privateIPv4 address space.
While this informational document does not make a recommendation for action, it documents the issues surrounding the various options that have been considered. |
|
| |
| RFC 6322 | Datatracker States and Annotations for the IAB, IRTF, and Independent Submission Streams |
| |
| Authors: | P. Hoffman. |
| Date: | July 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6322 |
|
This document describes extending the IETF Datatracker to capture and display the progression of Internet-Drafts that are intended to be published as RFCs by the IAB, IRTF, or Independent SubmissionsEditor. The states and annotations that are to be added to theDatatracker will be applied to Internet-Drafts as soon as any of these streams identify the Internet-Draft as a potential eventualRFC, and will continue through the lifetime of the Internet-Draft.The goal of adding this information to the Datatracker is to give the whole Internet community more information about the status of theseInternet-Drafts and the streams from which they originate. |
|
| |
| RFC 6324 | Routing Loop Attack Using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations |
| |
| Authors: | G. Nakibly, F. Templin. |
| Date: | August 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6324 |
|
This document is concerned with security vulnerabilities in IPv6-in-IPv4 automatic tunnels. These vulnerabilities allow an attacker to take advantage of inconsistencies between the IPv4 routing state and the IPv6 routing state. The attack forms a routing loop that can be abused as a vehicle for traffic amplification to facilitate denial- of-service (DoS) attacks. The first aim of this document is to inform on this attack and its root causes. The second aim is to present some possible mitigation measures. It should be noted that at the time of this writing there are no known reports of malicious attacks exploiting these vulnerabilities. Nonetheless, these vulnerabilities can be activated by accidental misconfiguration. |
|
| |
| RFC 6331 | Moving DIGEST-MD5 to Historic |
| |
|
|
This memo describes problems with the DIGEST-MD5 SimpleAuthentication and Security Layer (SASL) mechanism as specified inRFC 2831. It marks DIGEST-MD5 as OBSOLETE in the IANA Registry ofSASL mechanisms and moves RFC 2831 to Historic status. |
|
| |
| RFC 6337 | Session Initiation Protocol (SIP) Usage of the Offer/Answer Model |
| |
| Authors: | S. Okumura, T. Sawada, P. Kyzivat. |
| Date: | August 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6337 |
|
The Session Initiation Protocol (SIP) utilizes the offer/answer model to establish and update multimedia sessions using the SessionDescription Protocol (SDP). The description of the offer/answer model in SIP is dispersed across multiple RFCs. This document summarizes all the current usages of the offer/answer model in SIP communication. |
|
| |
| RFC 6338 | Definition of a Uniform Resource Name (URN) Namespace for the Schema for Academia (SCHAC) |
| |
| Authors: | V. Giralt, R. McDuff. |
| Date: | August 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6338 |
|
This document describes a Uniform Resource Name (URN) namespace for the Schema for Academia (SCHAC).
The namespace described in this document is for naming persistent resources defined by the SCHAC participants internationally, their working groups, and other designated subordinates. The main use of this namespace will be for the creation of controlled vocabulary values for attributes in the SCHAC schema. These values will be associated with particular instances of persons or objects belonging to any of the SCHAC object classes. |
|
| |
| RFC 6341 | Use Cases and Requirements for SIP-Based Media Recording (SIPREC) |
| |
| Authors: | K. Rehor, Ed., L. Portman, Ed., A. Hutton, R. Jain. |
| Date: | August 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6341 |
|
Session recording is a critical requirement in many business communications environments, such as call centers and financial trading floors. In some of these environments, all calls must be recorded for regulatory and compliance reasons. In others, calls may be recorded for quality control or business analytics.
Recording is typically performed by sending a copy of the session media to the recording devices. This document specifies requirements for extensions to SIP that will manage delivery of RTP media to a recording device. This is being referred to as SIP-based MediaRecording. |
|
| |
| RFC 6342 | Mobile Networks Considerations for IPv6 Deployment |
| |
|
|
Mobile Internet access from smartphones and other mobile devices is accelerating the exhaustion of IPv4 addresses. IPv6 is widely seen as crucial for the continued operation and growth of the Internet, and in particular, it is critical in mobile networks. This document discusses the issues that arise when deploying IPv6 in mobile networks. Hence, this document can be a useful reference for service providers and network designers. |
|
| |
| RFC 6343 | Advisory Guidelines for 6to4 Deployment |
| |
| Authors: | B. Carpenter. |
| Date: | August 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6343 |
|
This document provides advice to network operators about deployment of the 6to4 technique for automatic tunneling of IPv6 over IPv4. It is principally addressed to Internet Service Providers (ISPs), including those that do not yet support IPv6, and to ContentProviders. Some advice to implementers is also included. The intention of the advice is to minimize both user dissatisfaction and help-desk calls. |
|
| |
| RFC 6349 | Framework for TCP Throughput Testing |
| |
| Authors: | B. Constantine, G. Forget, R. Geib, R. Schrage. |
| Date: | August 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6349 |
|
This framework describes a practical methodology for measuring end- to-end TCP Throughput in a managed IP network. The goal is to provide a better indication in regard to user experience. In this framework, TCP and IP parameters are specified to optimize TCPThroughput. |
|
| |
| RFC 6357 | Design Considerations for Session Initiation Protocol (SIP) Overload Control |
| |
| Authors: | V. Hilt, E. Noel, C. Shen, A. Abdelal. |
| Date: | August 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6357 |
|
Overload occurs in Session Initiation Protocol (SIP) networks whenSIP servers have insufficient resources to handle all SIP messages they receive. Even though the SIP protocol provides a limited overload control mechanism through its 503 (Service Unavailable) response code, SIP servers are still vulnerable to overload. This document discusses models and design considerations for a SIP overload control mechanism. |
|
| |
| RFC 6359 | Datatracker Extensions to Include IANA and RFC Editor Processing Information |
| |
| Authors: | S. Ginoza, M. Cotton, A. Morris. |
| Date: | September 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6359 |
|
This document captures the requirements for integrating IANA and RFCEditor state information into the Datatracker to provide the community with a unified tool to track the status of their document as it progresses from Internet-Draft (I-D) version -00 to RFC.Extending the Datatracker to hold document data from I-D version -00 to RFC allows for increased automation between the Datatracker, IANA, and RFC Editor, thus reducing manual labor, processing errors, and potential delay. Therefore, this document also describes the requirements to make such automation possible. |
|
| |
| RFC 6360 | Conclusion of FYI RFC Sub-Series |
| |
|
|
This document concludes the For Your Information (FYI) sub-series ofRFCs, established by RFC 1150 for use by the IETF User Services Area, which no longer exists. The IESG does not intend to make any further additions to this RFC sub-series, and this document provides a record of this decision. This document also obsoletes RFC 1150 and changes the status of RFC 1150 to Historic. |
|
| |
| RFC 6362 | Multiple Attachments for Electronic Data Interchange - Internet Integration (EDIINT) |
| |
| Authors: | K. Meadors, Ed.. |
| Date: | August 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6362 |
|
The Electronic Data Interchange - Internet Integration (EDIINT) AS1,AS2, and AS3 messages were designed specifically for the transport ofEDI documents. Since multiple interchanges could be placed within a single EDI document, there was not a need for sending multiple EDI documents in a single message. As adoption of EDIINT grew, other uses developed aside from single EDI document transport. Some transactions required multiple attachments to be interpreted together and stored in a single message. This Informational RFC describes how multiple documents, including non-EDI payloads, can be attached and transmitted in a single EDIINT transport message. The attachments are stored within the MIME multipart/related structure. A minimal list of content-types to be supported as attachments is provided. |
|
| |
| RFC 6366 | Requirements for an Internet Audio Codec |
| |
| Authors: | J. Valin, K. Vos. |
| Date: | August 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6366 |
|
This document provides specific requirements for an Internet audio codec. These requirements address quality, sampling rate, bit-rate, and packet-loss robustness, as well as other desirable properties. |
|
| |
| RFC 6367 | Addition of the Camellia Cipher Suites to Transport Layer Security (TLS) |
| |
|
|
This document specifies forty-two cipher suites for the TransportSecurity Layer (TLS) protocol to support the Camellia encryption algorithm as a block cipher. |
|
| |
| RFC 6369 | Forwarding and Control Element Separation (ForCES) Implementation Experience |
| |
| Authors: | E. Haleplidis, O. Koufopavlou, S. Denazis. |
| Date: | September 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6369 |
|
The Forwarding and Control Element Separation (ForCES) protocol defines a standard communication and control mechanism through which a Control Element (CE) can control the behavior of a ForwardingElement (FE). This document captures the experience of implementing the ForCES protocol and model. Its aim is to help others by providing examples and possible strategies for implementing theForCES protocol. |
|
| |
| RFC 6371 | Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks |
| |
| Authors: | I. Busi, Ed., D. Allan, Ed.. |
| Date: | September 2011 |
| Formats: | txt json html |
| Updated by: | RFC 6435 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6371 |
|
The Transport Profile of Multiprotocol Label Switching (MPLS-TP) is a packet-based transport technology based on the MPLS TrafficEngineering (MPLS-TE) and pseudowire (PW) data-plane architectures.
This document describes a framework to support a comprehensive set ofOperations, Administration, and Maintenance (OAM) procedures that fulfill the MPLS-TP OAM requirements for fault, performance, and protection-switching management and that do not rely on the presence of a control plane.
This document is a product of a joint Internet Engineering Task Force(IETF) / International Telecommunications Union TelecommunicationStandardization Sector (ITU-T) effort to include an MPLS TransportProfile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge(PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. |
|
| |
| RFC 6372 | MPLS Transport Profile (MPLS-TP) Survivability Framework |
| |
| Authors: | N. Sprecher, Ed., A. Farrel, Ed.. |
| Date: | September 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6372 |
|
Network survivability is the ability of a network to recover traffic delivery following failure or degradation of network resources.Survivability is critical for the delivery of guaranteed network services, such as those subject to strict Service Level Agreements(SLAs) that place maximum bounds on the length of time that services may be degraded or unavailable.
The Transport Profile of Multiprotocol Label Switching (MPLS-TP) is a packet-based transport technology based on the MPLS data plane that reuses many aspects of the MPLS management and control planes.
This document comprises a framework for the provision of survivability in an MPLS-TP network; it describes recovery elements, types, methods, and topological considerations. To enable data-plane recovery, survivability may be supported by the control plane, management plane, and by Operations, Administration, and Maintenance(OAM) functions. This document describes mechanisms for recoveringMPLS-TP Label Switched Paths (LSPs). A detailed description of pseudowire recovery in MPLS-TP networks is beyond the scope of this document.
This document is a product of a joint Internet Engineering Task Force(IETF) / International Telecommunication Union TelecommunicationStandardization Sector (ITU-T) effort to include an MPLS TransportProfile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge(PWE3) architectures to support the capabilities and functionalities of a packet-based transport network as defined by the ITU-T. |
|
| |
| RFC 6373 | MPLS Transport Profile (MPLS-TP) Control Plane Framework |
| |
| Authors: | L. Andersson, Ed., L. Berger, Ed., L. Fang, Ed., N. Bitar, Ed., E. Gray, Ed.. |
| Date: | September 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6373 |
|
The MPLS Transport Profile (MPLS-TP) supports static provisioning of transport paths via a Network Management System (NMS) and dynamic provisioning of transport paths via a control plane. This document provides the framework for MPLS-TP dynamic provisioning and covers control-plane addressing, routing, path computation, signaling, traffic engineering, and path recovery. MPLS-TP uses GMPLS as the control plane for MPLS-TP Label Switched Paths (LSPs). MPLS-TP also uses the pseudowire (PW) control plane for pseudowires. Management- plane functions are out of scope of this document.
This document is a product of a joint Internet Engineering Task Force(IETF) / International Telecommunication Union TelecommunicationStandardization Sector (ITU-T) effort to include an MPLS TransportProfile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge(PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. |
|
| |
| RFC 6375 | A Packet Loss and Delay Measurement Profile for MPLS-Based Transport Networks |
| |
| Authors: | D. Frost, Ed., S. Bryant, Ed.. |
| Date: | September 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6375 |
|
Procedures and protocol mechanisms to enable efficient and accurate measurement of packet loss, delay, and throughput in MPLS networks are defined in RFC 6374.
The MPLS Transport Profile (MPLS-TP) is the set of MPLS protocol functions applicable to the construction and operation of packet- switched transport networks.
This document describes a profile of the general MPLS loss, delay, and throughput measurement techniques that suffices to meet the specific requirements of MPLS-TP.
This document is a product of a joint Internet Engineering Task Force(IETF) / International Telecommunication Union TelecommunicationStandardization Sector (ITU-T) effort to include an MPLS TransportProfile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge(PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. |
|
| |
| RFC 6383 | Advice on When It Is Safe to Start Sending Data on Label Switched Paths Established Using RSVP-TE |
| |
| Authors: | K. Shiomoto, A. Farrel. |
| Date: | September 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6383 |
|
The Resource Reservation Protocol (RSVP) has been extended to supportTraffic Engineering (TE) in Multiprotocol Label Switching (MPLS) andGeneralized MPLS (GMPLS) networks. The protocol enables signaling exchanges to establish Label Switched Paths (LSPs) that traverse nodes and link to provide end-to-end data paths. Each node is programmed with "cross-connect" information as the signaling messages are processed. The cross-connection information instructs the node how to forward data that it receives.
End points of an LSP need to know when it is safe to start sending data so that it is not misdelivered, and so that safety issues specific to optical data-plane technology are satisfied. Likewise, all label switching routers along the path of the LSP need to know when to program their data planes relative to sending and receiving control-plane messages.
This document clarifies and summarizes the RSVP-TE protocol exchanges with relation to the programming of cross-connects along an LSP for both unidirectional and bidirectional LSPs. This document does not define any new procedures or protocol extensions, and defers completely to the documents that provide normative references. The clarifications set out in this document may also be used to help interpret LSP establishment performance figures for MPLS-TE and GMPLS devices. |
|
| |
| RFC 6385 | General Area Review Team (Gen-ART) Experiences |
| |
| Authors: | M. Barnes, A. Doria, H. Alvestrand, B. Carpenter. |
| Date: | October 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6385 |
|
The General Area Review Team (Gen-ART) has been doing reviews ofInternet-Drafts (I-Ds) since 2004. This document discusses the experience and the lessons learned over the past 7 years of this process. The review team initially reviewed the I-Ds before each of the IESG telechats. Since late 2005, review team members have been assigned to review I-Ds during IETF Last Call, unless no IETF LastCall is necessary for the I-D. The same reviewer then reviews any updates when the I-D is placed on an IESG telechat agenda. |
|
| |
| RFC 6386 | VP8 Data Format and Decoding Guide |
| |
| Authors: | J. Bankoski, J. Koleszar, L. Quillio, J. Salonen, P. Wilkins, Y. Xu. |
| Date: | November 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6386 |
|
This document describes the VP8 compressed video data format, together with a discussion of the decoding procedure for the format. |
|
| |
| RFC 6392 | A Survey of In-Network Storage Systems |
| |
| Authors: | R. Alimi, Ed., A. Rahman, Ed., Y. Yang, Ed.. |
| Date: | October 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6392 |
|
This document surveys deployed and experimental in-network storage systems and describes their applicability for the DECADE (DECoupledApplication Data Enroute) architecture. |
|
| |
| RFC 6393 | Moving RFC 4693 to Historic |
| |
|
|
This document moves RFC 4693 to Historic status. It also obsoletesRFC 4693. |
|
| |
| RFC 6394 | Use Cases and Requirements for DNS-Based Authentication of Named Entities (DANE) |
| |
| Authors: | R. Barnes. |
| Date: | October 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6394 |
|
Many current applications use the certificate-based authentication features in Transport Layer Security (TLS) to allow clients to verify that a connected server properly represents a desired domain name.Typically, this authentication has been based on PKIX certificate chains rooted in well-known certificate authorities (CAs), but additional information can be provided via the DNS itself. This document describes a set of use cases in which the DNS and DNSSecurity Extensions (DNSSEC) could be used to make assertions that support the TLS authentication process. The main focus of this document is TLS server authentication, but it also covers TLS client authentication for applications where TLS clients are identified by domain names. |
|
| |
| RFC 6404 | Session PEERing for Multimedia INTerconnect (SPEERMINT) Security Threats and Suggested Countermeasures |
| |
| Authors: | J. Seedorf, S. Niccolini, E. Chen, H. Scholz. |
| Date: | November 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6404 |
|
The Session PEERing for Multimedia INTerconnect (SPEERMINT) working group (WG) provides a peering framework that leverages the building blocks of existing IETF-defined protocols such as SIP and ENUM for the interconnection between SIP Service Providers (SSPs). The objective of this document is to identify and enumerate SPEERMINT- specific threat vectors and to give guidance for implementers on selecting appropriate countermeasures. Security requirements forSPEERMINT that have been derived from the threats detailed in this document can be found in RFC 6271; this document provides concrete countermeasures to meet those SPEERMINT security requirements. In this document, the different security threats related to SPEERMINT are classified into threats to the Lookup Function (LUF), theLocation Routing Function (LRF), the Signaling Function (SF), and theMedia Function (MF) of a specific SIP Service Provider. Various instances of the threats are briefly introduced inside the classification. Finally, existing security solutions for SIP andRTP/RTCP (Real-time Transport Control Protocol) are presented to describe countermeasures currently available for such threats. EachSSP may have connections to one or more remote SSPs through peering or transit contracts. A potentially compromised remote SSP that attacks other SSPs is out of the scope of this document; this document focuses on attacks on an SSP from outside the trust domain such an SSP may have with other SSPs. |
|
| |
| RFC 6405 | Voice over IP (VoIP) SIP Peering Use Cases |
| |
| Authors: | A. Uzelac, Ed., Y. Lee, Ed.. |
| Date: | November 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6405 |
|
This document depicts many common Voice over IP (VoIP) use cases forSession Initiation Protocol (SIP) peering. These use cases are categorized into static and on-demand, and then further sub- categorized into direct and indirect. These use cases are not an exhaustive set, but rather the most common use cases deployed today. |
|
| |
| RFC 6406 | Session PEERing for Multimedia INTerconnect (SPEERMINT) Architecture |
| |
| Authors: | D. Malas, Ed., J. Livingood, Ed.. |
| Date: | November 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6406 |
|
This document defines a peering architecture for the SessionInitiation Protocol (SIP) and its functional components and interfaces. It also describes the components and the steps necessary to establish a session between two SIP Service Provider (SSP) peering domains. |
|
| |
| RFC 6411 | Applicability of Keying Methods for RSVP Security |
| |
| Authors: | M. Behringer, F. Le Faucheur, B. Weis. |
| Date: | October 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6411 |
|
The Resource reSerVation Protocol (RSVP) allows hop-by-hop integrity protection of RSVP neighbors. This requires messages to be cryptographically protected using a shared secret between participating nodes. This document compares group keying for RSVP with per-neighbor or per-interface keying, and discusses the associated key provisioning methods as well as applicability and limitations of these approaches. This document also discusses applicability of encrypting RSVP messages. |
|
| |
| RFC 6412 | Terminology for Benchmarking Link-State IGP Data-Plane Route Convergence |
| |
| Authors: | S. Poretsky, B. Imhoff, K. Michielsen. |
| Date: | November 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6412 |
|
This document describes the terminology for benchmarking link-stateInterior Gateway Protocol (IGP) route convergence. The terminology is to be used for benchmarking IGP convergence time through externally observable (black-box) data-plane measurements. The terminology can be applied to any link-state IGP, such as IS-IS andOSPF. |
|
| |
| RFC 6413 | Benchmarking Methodology for Link-State IGP Data-Plane Route Convergence |
| |
| Authors: | S. Poretsky, B. Imhoff, K. Michielsen. |
| Date: | November 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6413 |
|
This document describes the methodology for benchmarking Link-StateInterior Gateway Protocol (IGP) Route Convergence. The methodology is to be used for benchmarking IGP convergence time through externally observable (black-box) data-plane measurements. The methodology can be applied to any link-state IGP, such as IS-IS andOSPF. |
|
| |
| RFC 6414 | Benchmarking Terminology for Protection Performance |
| |
| Authors: | S. Poretsky, R. Papneja, J. Karthik, S. Vapiwala. |
| Date: | November 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6414 |
|
This document provides common terminology and metrics for benchmarking the performance of sub-IP layer protection mechanisms.The performance benchmarks are measured at the IP layer; protection may be provided at the sub-IP layer. The benchmarks and terminology can be applied in methodology documents for different sub-IP layer protection mechanisms such as Automatic Protection Switching (APS),Virtual Router Redundancy Protocol (VRRP), Stateful High Availability(HA), and Multiprotocol Label Switching Fast Reroute (MPLS-FRR). |
|
| |
| RFC 6417 | How to Contribute Research Results to Internet Standardization |
| |
| Authors: | P. Eardley, L. Eggert, M. Bagnulo, R. Winter. |
| Date: | November 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6417 |
|
The development of new technology is driven by scientific research.The Internet, with its roots in the ARPANET and NSFNet, is no exception. Many of the fundamental, long-term improvements to the architecture, security, end-to-end protocols and management of theInternet originate in the related academic research communities.Even shorter-term, more commercially driven extensions are oftentimes derived from academic research. When interoperability is required, the IETF standardizes such new technology. Timely and relevant standardization benefits from continuous input and review from the academic research community.
For an individual researcher, it can however be quite puzzling how to begin to most effectively participate in the IETF and arguably to a much lesser degree, the IRTF. The interactions in the IETF are much different than those in academic conferences, and effective participation follows different rules. The goal of this document is to highlight such differences and provide a rough guideline that will hopefully enable researchers new to the IETF to become successful contributors more quickly. |
|
| |
| RFC 6418 | Multiple Interfaces and Provisioning Domains Problem Statement |
| |
| Authors: | M. Blanchet, P. Seite. |
| Date: | November 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6418 |
|
This document describes issues encountered by a node attached to multiple provisioning domains. This node receives configuration information from each of its provisioning domains, where some configuration objects are global to the node and others are local to the interface. Issues such as selecting the wrong interface to send traffic happen when conflicting node-scoped configuration objects are received and inappropriately used. Moreover, other issues are the result of simultaneous attachment to multiple networks, such as domain selection or addressing and naming space overlaps, regardless of the provisioning mechanism. While multiple provisioning domains are typically seen on nodes with multiple interfaces, this document also discusses situations involving single-interface nodes. |
|
| |
| RFC 6419 | Current Practices for Multiple-Interface Hosts |
| |
| Authors: | M. Wasserman, P. Seite. |
| Date: | November 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6419 |
|
An increasing number of hosts are operating in multiple-interface environments. This document summarizes current practices in this area and describes in detail how some common operating systems cope with challenges that ensue from this context. |
|
| |
| RFC 6421 | Crypto-Agility Requirements for Remote Authentication Dial-In User Service (RADIUS) |
| |
| Authors: | D. Nelson, Ed.. |
| Date: | November 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6421 |
|
This memo describes the requirements for a crypto-agility solution for Remote Authentication Dial-In User Service (RADIUS). |
|
| |
| RFC 6429 | TCP Sender Clarification for Persist Condition |
| |
| Authors: | M. Bashyam, M. Jethanandani, A. Ramaiah. |
| Date: | December 2011 |
| Formats: | txt json html |
| Obsoleted by: | RFC 9293 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6429 |
|
This document clarifies the Zero Window Probes (ZWPs) described inRFC 1122 ("Requirements for Internet Hosts -- Communication Layers").In particular, it clarifies the actions that can be taken on connections that are experiencing the ZWP condition. Rather than making a change to the standard, this document clarifies what has been until now a misinterpretation of the standard as specified inRFC 1122. |
|
| |
| RFC 6431 | Huawei Port Range Configuration Options for PPP IP Control Protocol (IPCP) |
| |
| Authors: | M. Boucadair, P. Levis, G. Bajko, T. Savolainen, T. Tsou. |
| Date: | November 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6431 |
|
This document defines two Huawei IPCP (IP Control Protocol) options used to convey a set of ports. These options can be used in the context of port range-based solutions or NAT-based solutions for port delegation and forwarding purposes. |
|
| |
| RFC 6433 | Requirements for a Working Group Milestones Tool |
| |
|
|
The IETF intends to provide a new tool to Working Group chairs andArea Directors for the creation and updating of milestones forWorking Group charters. This document describes the requirements for the proposed new tool, and it is intended as input to a later activity for the design and development of such a tool. This document updates RFC 6292. |
|
| |
| RFC 6434 | IPv6 Node Requirements |
| |
|
|
This document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations.Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments.
This document obsoletes RFC 4294. |
|
| |
| RFC 6436 | Rationale for Update to the IPv6 Flow Label Specification |
| |
| Authors: | S. Amante, B. Carpenter, S. Jiang. |
| Date: | November 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6436 |
|
Various published proposals for use of the IPv6 flow label are incompatible with its original specification in RFC 3697.Furthermore, very little practical use is made of the flow label, partly due to some uncertainties about the correct interpretation of the specification. This document discusses and motivates changes to the specification in order to clarify it and to introduce some additional flexibility. |
|
| |
| RFC 6443 | Framework for Emergency Calling Using Internet Multimedia |
| |
| Authors: | B. Rosen, H. Schulzrinne, J. Polk, A. Newton. |
| Date: | December 2011 |
| Formats: | txt json html |
| Updated by: | RFC 7852 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6443 |
|
The IETF has standardized various aspects of placing emergency calls.This document describes how all of those component parts are used to support emergency calls from citizens and visitors to authorities. |
|
| |
| RFC 6444 | Location Hiding: Problem Statement and Requirements |
| |
| Authors: | H. Schulzrinne, L. Liess, H. Tschofenig, B. Stark, A. Kuett. |
| Date: | January 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6444 |
|
The emergency services architecture developed in the IETF EmergencyContext Resolution with Internet Technology (ECRIT) working group describes an architecture where location information is provided by access networks to endpoints or Voice over IP (VoIP) service providers in order to determine the correct dial string and information to route the call to a Public Safety Answering Point(PSAP). To determine the PSAP Uniform Resource Identifier (URI), the usage of the Location-to-Service Translation (LoST) protocol is envisioned.
This document provides a problem statement and lists requirements for situations where the Internet Access Provider (IAP) and/or theInternet Service Provider (ISP) are only willing to disclose limited or no location information. |
|
| |
| RFC 6449 | Complaint Feedback Loop Operational Recommendations |
| |
| Authors: | J. Falk, Ed.. |
| Date: | November 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6449 |
|
Complaint Feedback Loops similar to those described herein have existed for more than a decade, resulting in many de facto standards and best practices. This document is an attempt to codify, and thus clarify, the ways that both providers and consumers of these feedback mechanisms intend to use the feedback, describing some already common industry practices.
This document is the result of cooperative efforts within theMessaging Anti-Abuse Working Group, a trade organization separate from the IETF. The original MAAWG document upon which this document is based was published in April, 2010. This document does not represent the consensus of the IETF; rather it is being published as an Informational RFC to make it widely available to the Internet community and simplify reference to this material from IETF work. |
|
| |
| RFC 6453 | A URN Namespace for the Open Grid Forum (OGF) |
| |
| Authors: | F. Dijkstra, R. Hughes-Jones. |
| Date: | December 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6453 |
|
This document describes a URN (Uniform Resource Name) namespace that is engineered by the Open Grid Forum (OGF) for naming persistent resources. |
|
| |
| RFC 6456 | Multi-Segment Pseudowires in Passive Optical Networks |
| |
| Authors: | H. Li, R. Zheng, A. Farrel. |
| Date: | November 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6456 |
|
This document describes the application of MPLS multi-segment pseudowires (MS-PWs) in a dual-technology environment comprising aPassive Optical Network (PON) and an MPLS Packet Switched Network(PSN).
PON technology may be used in mobile backhaul networks to support the end segments closest to the aggregation devices. In these cases, there may be a very large number of pseudowire (PW) TerminatingProvider Edge (T-PE) nodes. The MPLS control plane could be used to provision these end segments, but support for the necessary protocols would complicate the management of the T-PEs and would significantly increase their expense. Alternatively, static, or management plane, configuration could be used to configure the end segments, but the very large number of such segments in a PON places a very heavy burden on the network manager.
This document describes how to set up the end segment of an end-to- end MPLS PW over a Gigabit-capable Passive Optical Network (G-PON) or10 Gigabit-capable Passive Optical Network (XG-PON) using the G-PON and XG-PON management protocol, Optical Network TerminationManagement and Control Interface (OMCI). This simplifies and speeds up PW provisioning compared with manual configuration.
This document also shows how an MS-PW may be constructed from an end segment supported over a PON, and switched to one or more segments supported over an MPLS PSN. |
|
| |
| RFC 6457 | PCC-PCE Communication and PCE Discovery Requirements for Inter-Layer Traffic Engineering |
| |
| Authors: | T. Takeda, Ed., A. Farrel. |
| Date: | December 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6457 |
|
The Path Computation Element (PCE) provides functions of path computation in support of traffic engineering in networks controlled by Multi-Protocol Label Switching (MPLS) and Generalized MPLS(GMPLS).
MPLS and GMPLS networks may be constructed from layered client/server networks. It is advantageous for overall network efficiency to provide end-to-end traffic engineering across multiple network layers. PCE is a candidate solution for such requirements.
Generic requirements for a communication protocol between PathComputation Clients (PCCs) and PCEs are presented in RFC 4657, "PathComputation Element (PCE) Communication Protocol GenericRequirements". Generic requirements for a PCE discovery protocol are presented in RFC 4674, "Requirements for Path Computation Element(PCE) Discovery".
This document complements the generic requirements and presents detailed sets of PCC-PCE communication protocol requirements and PCE discovery protocol requirements for inter-layer traffic engineering. |
|
| |
| RFC 6458 | Sockets API Extensions for the Stream Control Transmission Protocol (SCTP) |
| |
| Authors: | R. Stewart, M. Tuexen, K. Poon, P. Lei, V. Yasevich. |
| Date: | December 2011 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6458 |
|
This document describes a mapping of the Stream Control TransmissionProtocol (SCTP) into a sockets API. The benefits of this mapping include compatibility for TCP applications, access to new SCTP features, and a consolidated error and event notification scheme. |
|
| |
| RFC 6459 | IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS) |
| |
| Authors: | J. Korhonen, Ed., J. Soininen, B. Patil, T. Savolainen, G. Bajko, K. Iisakkila. |
| Date: | January 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6459 |
|
The use of cellular broadband for accessing the Internet and other data services via smartphones, tablets, and notebook/netbook computers has increased rapidly as a result of high-speed packet data networks such as HSPA, HSPA+, and now Long-Term Evolution (LTE) being deployed. Operators that have deployed networks based on 3rdGeneration Partnership Project (3GPP) network architectures are facing IPv4 address shortages at the Internet registries and are feeling pressure to migrate to IPv6. This document describes the support for IPv6 in 3GPP network architectures. |
|
| |
| RFC 6461 | Data for Reachability of Inter-/Intra-NetworK SIP (DRINKS) Use Cases and Protocol Requirements |
| |
| Authors: | S. Channabasappa, Ed.. |
| Date: | January 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6461 |
|
This document captures the use cases and associated requirements for interfaces that provision session establishment data into SessionInitiation Protocol (SIP) Service Provider components to assist with session routing. Specifically, this document focuses on the provisioning of one such element termed the "registry". |
|
| |
| RFC 6462 | Report from the Internet Privacy Workshop |
| |
| Authors: | A. Cooper. |
| Date: | January 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6462 |
|
On December 8-9, 2010, the IAB co-hosted an Internet privacy workshop with the World Wide Web Consortium (W3C), the Internet Society(ISOC), and MIT's Computer Science and Artificial IntelligenceLaboratory (CSAIL). The workshop revealed some of the fundamental challenges in designing, deploying, and analyzing privacy-protectiveInternet protocols and systems. Although workshop participants and the community as a whole are still far from understanding how best to systematically address privacy within Internet standards development, workshop participants identified a number of potential next steps.For the IETF, these included the creation of a privacy directorate to review Internet-Drafts, further work on documenting privacy considerations for protocol developers, and a number of exploratory efforts concerning fingerprinting and anonymized routing. Potential action items for the W3C included investigating the formation of a privacy interest group and formulating guidance about fingerprinting, referrer headers, data minimization in APIs, usability, and general considerations for non-browser-based protocols.
Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect the views of the IAB, W3C, ISOC, or MIT CSAIL. |
|
| |
| RFC 6467 | Secure Password Framework for Internet Key Exchange Version 2 (IKEv2) |
| |
| Authors: | T. Kivinen. |
| Date: | December 2011 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6467 |
|
This document defines a generic way for Internet Key Exchange version2 (IKEv2) to use any of the symmetric secure password authentication methods. Multiple methods are already specified in other documents, and this document does not add any new one. This document specifies a way to agree on which method is to be used in the current connection. This document also provides a common way to transmit, between peers, payloads that are specific to secure password authentication methods. |
|
| |
| RFC 6471 | Overview of Best Email DNS-Based List (DNSBL) Operational Practices |
| |
| Authors: | C. Lewis, M. Sergeant. |
| Date: | January 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6471 |
|
The rise of spam and other anti-social behavior on the Internet has led to the creation of shared DNS-based lists (DNSBLs) of IP addresses or domain names intended to help guide email filtering.This memo summarizes guidelines of accepted best practice for the management of public DNSBLs by their operators as well as for the proper use of such lists by mail server administrators (DNSBL users), and it provides useful background for both parties. It is not intended to advise on the utility or efficacy of particular DNSBLs or the DNSBL concept in general, nor to assist end users with questions about spam. |
|
| |
| RFC 6477 | Registration of Military Message Handling System (MMHS) Header Fields for Use in Internet Mail |
| |
| Authors: | A. Melnikov, G. Lunt. |
| Date: | January 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6477 |
|
A Military Message Handling System (MMHS) processes formal messages ensuring release, distribution, security, and timely delivery across national and international strategic and tactical networks. The MMHSElements of Service are defined as a set of extensions to the ITU-TX.400 (1992) international standards and are specified in STANAG 4406Edition 2 and ACP 123. This document specifies message header fields and associated processing for RFC 5322 (Internet Message Format) to provide a comparable messaging service. In addition, this document provides for a STANAG 4406 / Internet Email Gateway that supports message conversion. |
|
| |
| RFC 6479 | IPsec Anti-Replay Algorithm without Bit Shifting |
| |
| Authors: | X. Zhang, T. Tsou. |
| Date: | January 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6479 |
|
This document presents an alternate method to do the anti-replay checks and updates for IP Authentication Header (AH) andEncapsulating Security Protocol (ESP). The method defined in this document obviates the need for bit shifting and it reduces the number of times an anti-replay window is adjusted. |
|
| |
| RFC 6480 | An Infrastructure to Support Secure Internet Routing |
| |
| Authors: | M. Lepinski, S. Kent. |
| Date: | February 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6480 |
|
This document describes an architecture for an infrastructure to support improved security of Internet routing. The foundation of this architecture is a Resource Public Key Infrastructure (RPKI) that represents the allocation hierarchy of IP address space andAutonomous System (AS) numbers; and a distributed repository system for storing and disseminating the data objects that comprise theRPKI, as well as other signed objects necessary for improved routing security. As an initial application of this architecture, the document describes how a legitimate holder of IP address space can explicitly and verifiably authorize one or more ASes to originate routes to that address space. Such verifiable authorizations could be used, for example, to more securely construct BGP route filters. |
|
| |
| RFC 6483 | Validation of Route Origination Using the Resource Certificate Public Key Infrastructure (PKI) and Route Origin Authorizations (ROAs) |
| |
| Authors: | G. Huston, G. Michaelson. |
| Date: | February 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6483 |
|
This document defines the semantics of a Route Origin Authorization(ROA) in terms of the context of an application of the ResourcePublic Key Infrastructure to validate the origination of routes advertised in the Border Gateway Protocol. |
|
| |
| RFC 6497 | BCP 47 Extension T - Transformed Content |
| |
| Authors: | M. Davis, A. Phillips, Y. Umaoka, C. Falk. |
| Date: | February 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6497 |
|
This document specifies an Extension to BCP 47 that provides subtags for specifying the source language or script of transformed content, including content that has been transliterated, transcribed, or translated, or in some other way influenced by the source. It also provides for additional information used for identification. |
|
| |
| RFC 6498 | Media Gateway Control Protocol (MGCP) Voiceband Data (VBD) Package and General-Purpose Media Descriptor Parameter Package |
| |
| Authors: | J. Stone, R. Kumar, F. Andreasen. |
| Date: | February 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6498 |
|
This document defines Media Gateway Control Protocol (MGCP) packages that enable a Call Agent to authorize and monitor the transition of a connection to and from Voiceband Data (VBD) with or without redundancy and FEC (forward error correction). Although the focus is on VBD, the General-Purpose Media Descriptor Parameter package can be used to authorize other modes of operation, not relevant to VBD, for a particular codec. In addition to defining these new packages, this document describes the use of the Media Format Parameter package andFax package with VBD, redundancy, and FEC. |
|
| |
| RFC 6504 | Centralized Conferencing Manipulation Protocol (CCMP) Call Flow Examples |
| |
| Authors: | M. Barnes, L. Miniero, R. Presta, S P. Romano. |
| Date: | March 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6504 |
|
This document provides detailed call flows for the scenarios documented in the Framework for Centralized Conferencing (XCON) (RFC5239) and in the XCON scenarios (RFC 4597). The call flows document the use of the interface between a conference control client and a conference control server using the Centralized ConferencingManipulation Protocol (CCMP) (RFC 6503). The objective is to provide detailed examples for reference by both protocol researchers and developers. |
|
| |
| RFC 6507 | Elliptic Curve-Based Certificateless Signatures for Identity-Based Encryption (ECCSI) |
| |
| Authors: | M. Groves. |
| Date: | February 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6507 |
|
Many signature schemes currently in use rely on certificates for authentication of identity. In Identity-based cryptography, this adds unnecessary overhead and administration. The Elliptic Curve- based Certificateless Signatures for Identity-based Encryption(ECCSI) signature scheme described in this document is certificateless. This scheme has the additional advantages of low bandwidth and low computational requirements. |
|
| |
| RFC 6508 | Sakai-Kasahara Key Encryption (SAKKE) |
| |
| Authors: | M. Groves. |
| Date: | February 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6508 |
|
In this document, the Sakai-Kasahara Key Encryption (SAKKE) algorithm is described. This uses Identity-Based Encryption to exchange a shared secret from a Sender to a Receiver. |
|
| |
| RFC 6509 | MIKEY-SAKKE: Sakai-Kasahara Key Encryption in Multimedia Internet KEYing (MIKEY) |
| |
| Authors: | M. Groves. |
| Date: | February 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6509 |
|
This document describes the Multimedia Internet KEYing-Sakai-KasaharaKey Encryption (MIKEY-SAKKE), a method of key exchange that usesIdentity-based Public Key Cryptography (IDPKC) to establish a shared secret value and certificateless signatures to provide source authentication. MIKEY-SAKKE has a number of desirable features, including simplex transmission, scalability, low-latency call setup, and support for secure deferred delivery. |
|
| |
| RFC 6517 | Mandatory Features in a Layer 3 Multicast BGP/MPLS VPN Solution |
| |
| Authors: | T. Morin, Ed., B. Niven-Jenkins, Ed., Y. Kamite, R. Zhang, N. Leymann, N. Bitar. |
| Date: | February 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6517 |
|
More that one set of mechanisms to support multicast in a layer 3BGP/MPLS VPN has been defined. These are presented in the documents that define them as optional building blocks.
To enable interoperability between implementations, this document defines a subset of features that is considered mandatory for a multicast BGP/MPLS VPN implementation. This will help implementers and deployers understand which L3VPN multicast requirements are best satisfied by each option. |
|
| |
| RFC 6518 | Keying and Authentication for Routing Protocols (KARP) Design Guidelines |
| |
| Authors: | G. Lebovitz, M. Bhatia. |
| Date: | February 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6518 |
|
This document is one of a series concerned with defining a roadmap of protocol specification work for the use of modern cryptographic mechanisms and algorithms for message authentication in routing protocols. In particular, it defines the framework for a key management protocol that may be used to create and manage session keys for message authentication and integrity. |
|
| |
| RFC 6538 | The Host Identity Protocol (HIP) Experiment Report |
| |
| Authors: | T. Henderson, A. Gurtov. |
| Date: | March 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6538 |
|
This document is a report from the IRTF Host Identity Protocol (HIP) research group documenting the collective experiences and lessons learned from studies, related experimentation, and designs completed by the research group. The document summarizes implications of adding HIP to host protocol stacks, Internet infrastructure, and applications. The perspective of a network operator, as well as a list of HIP experiments, are presented as well. Portions of this report may be relevant also to other network overlay-based architectures or to attempts to deploy alternative networking architectures. |
|
| |
| RFC 6539 | IBAKE: Identity-Based Authenticated Key Exchange |
| |
| Authors: | V. Cakulev, G. Sundaram, I. Broustis. |
| Date: | March 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6539 |
|
Cryptographic protocols based on public-key methods have been traditionally based on certificates and Public Key Infrastructure(PKI) to support certificate management. The emerging field ofIdentity-Based Encryption (IBE) protocols allows simplification of infrastructure requirements via a Private-Key Generator (PKG) while providing the same flexibility. However, one significant limitation of IBE methods is that the PKG can end up being a de facto key escrow server, with undesirable consequences. Another observed deficiency is a lack of mutual authentication of communicating parties. This document specifies the Identity-Based Authenticated Key Exchange(IBAKE) protocol. IBAKE does not suffer from the key escrow problem and in addition provides mutual authentication as well as perfect forward and backward secrecy. |
|
| |
| RFC 6547 | RFC 3627 to Historic Status |
| |
|
|
This document moves "Use of /127 Prefix Length Between RoutersConsidered Harmful" (RFC 3627) to Historic status to reflect the updated guidance contained in "Using 127-Bit IPv6 Prefixes on Inter-Router Links" (RFC 6164). A Standards Track document supersedes an informational document; therefore, guidance provided in RFC 6164 is to be followed when the two documents are in conflict. This document links the two RFCs so that the IETF's updated guidance on this topic is clearer. |
|
| |
| RFC 6548 | Independent Submission Editor Model |
| |
|
|
This document describes the function and responsibilities of the RFCIndependent Submission Editor (ISE). The Independent Submission stream is one of the stream producers that create draft RFCs, with the ISE as its stream approver. The ISE is overall responsible for activities within the Independent Submission stream, working with draft editors and reviewers, and interacts with the RFC ProductionCenter and Publisher, and the RFC Series Editor (RSE). The ISE is appointed by the IAB, and also interacts with the IETF AdministrativeOversight Committee (IAOC). |
|
| |
| RFC 6556 | Testing Eyeball Happiness |
| |
| Authors: | F. Baker. |
| Date: | April 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6556 |
|
The amount of time it takes to establish a session using common transport APIs in dual-stack networks and networks with filtering such as proposed in BCP 38 is a barrier to IPv6 deployment. This note describes a test that can be used to determine whether an application can reliably establish sessions quickly in a complex environment such as dual-stack (IPv4+IPv6) deployment or IPv6 deployment with multiple prefixes and upstream ingress filtering.This test is not a test of a specific algorithm, but of the external behavior of the system as a black box. Any algorithm that has the intended external behavior will be accepted by it. |
|
| |
| RFC 6561 | Recommendations for the Remediation of Bots in ISP Networks |
| |
| Authors: | J. Livingood, N. Mody, M. O'Reirdan. |
| Date: | March 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6561 |
|
This document contains recommendations on how Internet ServiceProviders can use various remediation techniques to manage the effects of malicious bot infestations on computers used by their subscribers. Internet users with infected computers are exposed to risks such as loss of personal data and increased susceptibility to online fraud. Such computers can also become inadvertent participants in or components of an online crime network, spam network, and/or phishing network as well as be used as a part of a distributed denial-of-service attack. Mitigating the effects of and remediating the installations of malicious bots will make it more difficult for botnets to operate and could reduce the level of online crime on the Internet in general and/or on a particular InternetService Provider's network. |
|
| |
| RFC 6563 | Moving A6 to Historic Status |
| |
| Authors: | S. Jiang, D. Conrad, B. Carpenter. |
| Date: | March 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6563 |
|
This document provides a summary of issues related to the use of A6 records, discusses the current status, and moves RFC 2874 to Historic status, providing clarity to implementers and operators. |
|
| |
| RFC 6566 | A Framework for the Control of Wavelength Switched Optical Networks (WSONs) with Impairments |
| |
| Authors: | Y. Lee, Ed., G. Bernstein, Ed., D. Li, G. Martinelli. |
| Date: | March 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6566 |
|
As an optical signal progresses along its path, it may be altered by the various physical processes in the optical fibers and devices it encounters. When such alterations result in signal degradation, these processes are usually referred to as "impairments". These physical characteristics may be important constraints to consider when using a GMPLS control plane to support path setup and maintenance in wavelength switched optical networks.
This document provides a framework for applying GMPLS protocols and the Path Computation Element (PCE) architecture to supportImpairment-Aware Routing and Wavelength Assignment (IA-RWA) in wavelength switched optical networks. Specifically, this document discusses key computing constraints, scenarios, and architectural processes: routing, wavelength assignment, and impairment validation.This document does not define optical data plane aspects; impairment parameters; or measurement of, or assessment and qualification of, a route; rather, it describes the architectural and information components for protocol solutions. |
|
| |
| RFC 6567 | Problem Statement and Requirements for Transporting User-to-User Call Control Information in SIP |
| |
| Authors: | A. Johnston, L. Liess. |
| Date: | April 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6567 |
|
This document introduces the transport of call control User-to-UserInformation (UUI) using the Session Initiation Protocol (SIP) and develops several requirements for a new SIP mechanism. Some SIP sessions are established by or related to a non-SIP application.This application may have information that needs to be transported between the SIP User Agents during session establishment. In addition to interworking with the Integrated Services Digital Network(ISDN) UUI Service, this extension will also be used for native SIP endpoints requiring application UUI. |
|
| |
| RFC 6568 | Design and Application Spaces for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) |
| |
| Authors: | E. Kim, D. Kaspar, JP. Vasseur. |
| Date: | April 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6568 |
|
This document investigates potential application scenarios and use cases for low-power wireless personal area networks (LoWPANs). This document provides dimensions of design space for LoWPAN applications.A list of use cases and market domains that may benefit and motivate the work currently done in the 6LoWPAN Working Group is provided with the characteristics of each dimension. A complete list of practical use cases is not the goal of this document. |
|
| |
| RFC 6569 | Guidelines for Development of an Audio Codec within the IETF |
| |
| Authors: | JM. Valin, S. Borilin, K. Vos, C. Montgomery, R. Chen. |
| Date: | March 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6569 |
|
This document provides general guidelines for work on developing and specifying an interactive audio codec within the IETF. These guidelines cover the development process, evaluation, requirements conformance, and intellectual property issues. |
|
| |
| RFC 6571 | Loop-Free Alternate (LFA) Applicability in Service Provider (SP) Networks |
| |
| Authors: | C. Filsfils, Ed., P. Francois, Ed., M. Shand, B. Decraene, J. Uttaro, N. Leymann, M. Horneffer. |
| Date: | June 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6571 |
|
In this document, we analyze the applicability of the Loop-FreeAlternate (LFA) method of providing IP fast reroute in both the core and access parts of Service Provider networks. We consider both the link and node failure cases, and provide guidance on the applicability of LFAs to different network topologies, with special emphasis on the access parts of the network. |
|
| |
| RFC 6573 | The Item and Collection Link Relations |
| |
| Authors: | M. Amundsen. |
| Date: | April 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6573 |
|
RFC 5988 standardized a means of indicating the relationships between resources on the Web. This specification defines a pair of reciprocal link relation types that may be used to express the relationship between a collection and its members. |
|
| |
| RFC 6574 | Report from the Smart Object Workshop |
| |
| Authors: | H. Tschofenig, J. Arkko. |
| Date: | April 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6574 |
|
This document provides an overview of a workshop held by the InternetArchitecture Board (IAB) on 'Interconnecting Smart Objects with theInternet'. The workshop took place in Prague on 25 March 2011. The main goal of the workshop was to solicit feedback from the wider community on their experience with deploying IETF protocols in constrained environments. This report summarizes the discussions and lists the conclusions and recommendations to the Internet EngineeringTask Force (IETF) community.
Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions. |
|
| |
| RFC 6579 | The 'disclosure' Link Relation Type |
| |
| Authors: | M. Yevstifeyev. |
| Date: | March 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6579 |
|
This document specifies the 'disclosure' link relation type. It designates a list of IPR disclosures made with respect to the material for which such a relation type is specified. |
|
| |
| RFC 6583 | Operational Neighbor Discovery Problems |
| |
| Authors: | I. Gashinsky, J. Jaeggli, W. Kumari. |
| Date: | March 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6583 |
|
In IPv4, subnets are generally small, made just large enough to cover the actual number of machines on the subnet. In contrast, the default IPv6 subnet size is a /64, a number so large it covers trillions of addresses, the overwhelming number of which will be unassigned. Consequently, simplistic implementations of NeighborDiscovery (ND) can be vulnerable to deliberate or accidental denial of service (DoS), whereby they attempt to perform address resolution for large numbers of unassigned addresses. Such denial-of-service attacks can be launched intentionally (by an attacker) or result from legitimate operational tools or accident conditions. As a result of these vulnerabilities, new devices may not be able to "join" a network, it may be impossible to establish new IPv6 flows, and existing IPv6 transported flows may be interrupted.
This document describes the potential for DoS in detail and suggests possible implementation improvements as well as operational mitigation techniques that can, in some cases, be used to protect against or at least alleviate the impact of such attacks. |
|
| |
| RFC 6586 | Experiences from an IPv6-Only Network |
| |
| Authors: | J. Arkko, A. Keranen. |
| Date: | April 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6586 |
|
This document discusses our experiences from moving a small number of users to an IPv6-only network, with access to the IPv4-only parts of the Internet via a NAT64 device. The document covers practical experiences as well as roadblocks and opportunities for this type of a network setup. The document also makes some recommendations about where such networks are applicable and what should be taken into account in the network design. The document also discusses further work that is needed to make IPv6-only networking applicable in all environments. |
|
| |
| RFC 6588 | A URN Namespace for ucode |
| |
| Authors: | C. Ishikawa. |
| Date: | April 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6588 |
|
This document describes a Uniform Resource Name (URN) namespace for ucode, an identifier system for objects and places. ucode technology is used in many applications, and this document provides a URN namespace for ucode to enable its use in Internet-related devices and software. |
|
| |
| RFC 6589 | Considerations for Transitioning Content to IPv6 |
| |
| Authors: | J. Livingood. |
| Date: | April 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6589 |
|
This document describes considerations for the transition of end-user content on the Internet to IPv6. While this is tailored to address end-user content, which is typically web-based, many aspects of this document may be more broadly applicable to the transition to IPv6 of other applications and services. This document explores the challenges involved in the transition to IPv6, potential migration tactics, possible migration phases, and other considerations. The audience for this document is the Internet community generally, particularly IPv6 implementers. |
|
| |
| RFC 6592 | The Null Packet |
| |
| Authors: | C. Pignataro. |
| Date: | 1 April 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6592 |
|
The ever-elusive Null Packet received numerous mentions in documents in the RFC series, but it has never been explicitly defined. This memo corrects that omission. |
|
| |
| RFC 6596 | The Canonical Link Relation |
| |
| Authors: | M. Ohye, J. Kupke. |
| Date: | April 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6596 |
|
RFC 5988 specifies a way to define relationships between links on the web. This document describes a new type of such a relationship,"canonical", to designate an Internationalized Resource Identifier(IRI) as preferred over resources with duplicative content. |
|
| |
| RFC 6606 | Problem Statement and Requirements for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing |
| |
| Authors: | E. Kim, D. Kaspar, C. Gomez, C. Bormann. |
| Date: | May 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6606 |
|
IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) are formed by devices that are compatible with the IEEE 802.15.4 standard. However, neither the IEEE 802.15.4 standard nor the6LoWPAN format specification defines how mesh topologies could be obtained and maintained. Thus, it should be considered how 6LoWPAN formation and multi-hop routing could be supported.
This document provides the problem statement and design space for6LoWPAN routing. It defines the routing requirements for 6LoWPANs, considering the low-power and other particular characteristics of the devices and links. The purpose of this document is not to recommend specific solutions but to provide general, layer-agnostic guidelines about the design of 6LoWPAN routing that can lead to further analysis and protocol design. This document is intended as input to groups working on routing protocols relevant to 6LoWPANs, such as the IETFROLL WG. |
|
| |
| RFC 6612 | Interactions between Proxy Mobile IPv6 (PMIPv6) and Mobile IPv6 (MIPv6): Scenarios and Related Issues |
| |
| Authors: | G. Giaretta, Ed.. |
| Date: | May 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6612 |
|
The use of Proxy Mobile IPv6 (PMIPv6) and Mobile IPv6 (MIPv6) in the same network requires some care. This document discusses scenarios where such mixed usage is appropriate and points out the need for interaction between the two mechanisms. Solutions and recommendations to enable these scenarios are also described. |
|
| |
| RFC 6624 | Layer 2 Virtual Private Networks Using BGP for Auto-Discovery and Signaling |
| |
| Authors: | K. Kompella, B. Kothari, R. Cherukuri. |
| Date: | May 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6624 |
|
Layer 2 Virtual Private Networks (L2VPNs) based on Frame Relay or ATM circuits have been around a long time; more recently, Ethernet VPNs, including Virtual Private LAN Service, have become popular.Traditional L2VPNs often required a separate Service Provider infrastructure for each type and yet another for the Internet and IPVPNs. In addition, L2VPN provisioning was cumbersome. This document presents a new approach to the problem of offering L2VPN services where the L2VPN customer's experience is virtually identical to that offered by traditional L2VPNs, but such that a Service Provider can maintain a single network for L2VPNs, IP VPNs, and the Internet, as well as a common provisioning methodology for all services. |
|
| |
| RFC 6627 | Overview of Pre-Congestion Notification Encoding |
| |
| Authors: | G. Karagiannis, K. Chan, T. Moncaster, M. Menth, P. Eardley, B. Briscoe. |
| Date: | July 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6627 |
|
The objective of Pre-Congestion Notification (PCN) is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain.On every link in the PCN-domain, the overall rate of PCN-traffic is metered, and PCN-packets are appropriately marked when certain configured rates are exceeded. Egress nodes provide decision points with information about the PCN-marks of PCN-packets that allows them to take decisions about whether to admit or block a new flow request, and to terminate some already admitted flows during serious pre-congestion.
The PCN working group explored a number of approaches for encoding this pre-congestion information into the IP header. This document provides details of those approaches along with an explanation of the constraints that apply to any solution. |
|
| |
| RFC 6629 | Considerations on the Application of the Level 3 Multihoming Shim Protocol for IPv6 (Shim6) |
| |
| Authors: | J. Abley, M. Bagnulo, A. Garcia-Martinez. |
| Date: | June 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6629 |
|
This document discusses some considerations on the applicability of the level 3 multihoming Shim protocol for IPv6 (Shim6) and associated support protocols and mechanisms to provide site multihoming capabilities in IPv6. |
|
| |
| RFC 6632 | An Overview of the IETF Network Management Standards |
| |
| Authors: | M. Ersue, Ed., B. Claise. |
| Date: | June 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6632 |
|
This document gives an overview of the IETF network management standards and summarizes existing and ongoing development of IETFStandards Track network management protocols and data models. The document refers to other overview documents, where they exist and classifies the standards for easy orientation. The purpose of this document is, on the one hand, to help system developers and users to select appropriate standard management protocols and data models to address relevant management needs. On the other hand, the document can be used as an overview and guideline by other StandardDevelopment Organizations or bodies planning to use IETF management technologies and data models. This document does not coverOperations, Administration, and Maintenance (OAM) technologies on the data-path, e.g., OAM of tunnels, MPLS Transport Profile (MPLS-TP)OAM, and pseudowire as well as the corresponding management models. |
|
| |
| RFC 6635 | RFC Editor Model (Version 2) |
| |
|
|
The RFC Editor model described in this document divides the responsibilities for the RFC Series into three functions: the RFCSeries Editor, the RFC Production Center, and the RFC Publisher.Internet Architecture Board (IAB) oversight via the RFC SeriesOversight Committee (RSOC) is described, as is the relationship between the IETF Administrative Oversight Committee (IAOC) and theRSOC. This document reflects the experience gained with "RFC EditorModel (Version 1)", documented in RFC 5620, and obsoletes that document. |
|
| |
| RFC 6636 | Tuning the Behavior of the Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) for Routers in Mobile and Wireless Networks |
| |
| Authors: | H. Asaeda, H. Liu, Q. Wu. |
| Date: | May 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6636 |
|
The Internet Group Management Protocol (IGMP) and Multicast ListenerDiscovery (MLD) are the protocols used by hosts and multicast routers to exchange their IP multicast group memberships with each other.This document describes ways to achieve IGMPv3 and MLDv2 protocol optimization for mobility and aims to become a guideline for the tuning of IGMPv3/MLDv2 Queries, timers, and counter values. |
|
| |
| RFC 6639 | Multiprotocol Label Switching Transport Profile (MPLS-TP) MIB-Based Management Overview |
| |
| Authors: | D. King, Ed., M. Venkatesan, Ed.. |
| Date: | June 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6639 |
|
A range of Management Information Base (MIB) modules has been developed to help model and manage the various aspects ofMultiprotocol Label Switching (MPLS) networks. These MIB modules are defined in separate documents that focus on the specific areas of responsibility of the modules that they describe.
The MPLS Transport Profile (MPLS-TP) is a profile of MPLS functionality specific to the construction of packet-switched transport networks.
This document describes the MIB-based architecture for MPLS-TP, indicates the interrelationships between different existing MIB modules that can be leveraged for MPLS-TP network management, and identifies areas where additional MIB modules are required. |
|
| |
| RFC 6640 | IETF Meeting Attendees' Frequently Asked (Travel) Questions |
| |
| Authors: | W. George. |
| Date: | June 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6640 |
|
This document attempts to provide a list of the frequently asked questions (FAQs) posed by IETF meeting attendees regarding travel logistics and local information. It is intended to assist those who are willing to provide local information, so that if they wish to pre-populate answers to some or all of these questions either in theIETF wiki or a meeting-specific site, they have a reasonably complete list of ideas to draw from. It is not meant as a list of required information that the host or Secretariat needs to provide; it merely serves as a guideline. |
|
| |
| RFC 6645 | IP Flow Information Accounting and Export Benchmarking Methodology |
| |
| Authors: | J. Novak. |
| Date: | July 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6645 |
|
This document provides a methodology and framework for quantifying the performance impact of the monitoring of IP flows on a network device and the export of this information to a Collector. It identifies the rate at which the IP flows are created, expired, and successfully exported as a new performance metric in combination with traditional throughput. The metric is only applicable to the devices compliant with RFC 5470, "Architecture for IP Flow InformationExport". The methodology quantifies the impact of the IP flow monitoring process on the network equipment. |
|
| |
| RFC 6646 | DECoupled Application Data Enroute (DECADE) Problem Statement |
| |
| Authors: | H. Song, N. Zong, Y. Yang, R. Alimi. |
| Date: | July 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6646 |
|
Peer-to-peer (P2P) applications have become widely used on theInternet today and make up a large portion of the traffic in many networks. In P2P applications, one technique for reducing the transit and uplink P2P traffic is to introduce storage capabilities within the network. Traditional caches (e.g., P2P and Web caches) provide such storage, but they can be complex (e.g., P2P caches need to explicitly support individual P2P application protocols), and do not allow users to manage resource usage policies for content in the cache. This document discusses the introduction of in-network storage for P2P applications and shows the need for a standard protocol for accessing this storage. |
|
| |
| RFC 6653 | DHCPv6 Prefix Delegation in Long-Term Evolution (LTE) Networks |
| |
| Authors: | B. Sarikaya, F. Xia, T. Lemon. |
| Date: | July 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6653 |
|
As interest in IPv6 deployment in cellular networks increases, several migration issues have been being raised; IPv6 prefix management is the issue addressed in this document. Based on the idea that DHCPv6 servers can manage prefixes, we use DHCPv6 PrefixDelegation to address such prefix management issues as an access router offloading delegation of prefixes and release tasks to aDHCPv6 server. The access router first requests a prefix for an incoming mobile node from the DHCPv6 server. The access router may next do stateless or stateful address allocation to the mobile node, e.g., with a Router Advertisement or using DHCP. We also describe prefix management using Authentication, Authorization, and Accounting(AAA) servers. |
|
| |
| RFC 6654 | Gateway-Initiated IPv6 Rapid Deployment on IPv4 Infrastructures (GI 6rd) |
| |
| Authors: | T. Tsou, C. Zhou, T. Taylor, Q. Chen. |
| Date: | July 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6654 |
|
This document proposes an alternative IPv6 Rapid Deployment on IPv4Infrastructures (6rd) deployment model to that of RFC 5969. The basic 6rd model allows IPv6 hosts to gain access to IPv6 networks across an IPv4 access network using 6-in-4 tunnels. 6rd requires support by a device (the 6rd customer edge, or 6rd-CE) on the customer site, which must also be assigned an IPv4 address. The alternative model described in this document initiates the 6-in-4 tunnels from an operator-owned Gateway collocated with the operator'sIPv4 network edge rather than from customer equipment, and hence is termed "Gateway-initiated 6rd" (GI 6rd). The advantages of this approach are that it requires no modification to customer equipment and avoids assignment of IPv4 addresses to customer equipment. The latter point means less pressure on IPv4 addresses in a high-growth environment. |
|
| |
| RFC 6656 | Description of Cisco Systems' Subnet Allocation Option for DHCPv4 |
| |
| Authors: | R. Johnson, K. Kinnear, M. Stapp. |
| Date: | July 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6656 |
|
This memo documents a DHCPv4 option that currently exists and was previously privately defined for the operation and usage of the CiscoSystems' Subnet Allocation Option for DHCPv4. The option is passed between the DHCPv4 Client and the DHCPv4 Server to request dynamic allocation of a subnet, give specifications of the subnet(s) allocated, and report usage statistics. This memo documents the current usage of the option in agreement with RFC 3942, which declares that any preexisting usages of option numbers in the range128-223 should be documented and that the working group will try to officially assign those numbers to those options. |
|
| |
| RFC 6659 | Considerations for Deploying the Rapid Acquisition of Multicast RTP Sessions (RAMS) Method |
| |
| Authors: | A. Begen. |
| Date: | July 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6659 |
|
The Rapid Acquisition of Multicast RTP Sessions (RAMS) solution is a method based on RTP and the RTP Control Protocol (RTCP) that enables an RTP receiver to rapidly acquire and start consuming the RTP multicast data. Upon a request from the RTP receiver, an auxiliary unicast RTP retransmission session is set up between a retransmission server and the RTP receiver, over which the reference information about the new multicast stream the RTP receiver is about to join is transmitted at an accelerated rate. This often precedes, but may also accompany, the multicast stream itself. When there is only one multicast stream to be acquired, the RAMS solution works in a straightforward manner. However, when there are two or more multicast streams to be acquired from the same or different multicastRTP sessions, care should be taken to configure each RAMS session appropriately. This document provides example scenarios and discusses how the RAMS solution could be used in such scenarios. |
|
| |
| RFC 6663 | Requirements for Signaling of Pre-Congestion Information in a Diffserv Domain |
| |
| Authors: | G. Karagiannis, T. Taylor, K. Chan, M. Menth, P. Eardley. |
| Date: | July 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6663 |
|
Pre-Congestion Notification (PCN) is a means for protecting quality of service for inelastic traffic admitted to a Diffserv domain. The overall PCN architecture is described in RFC 5559. This memo describes the requirements for the signaling applied within the PCN- domain: (1) PCN-feedback-information is carried from the PCN-egress- node to the Decision Point; (2) the Decision Point may ask the PCN- ingress-node to measure, and report back, the rate of sent PCN- traffic between that PCN-ingress-node and PCN-egress-node. TheDecision Point may be either collocated with the PCN-ingress-node or a centralized node (in the first case, (2) is not required). The signaling requirements pertain in particular to two edge behaviors,Controlled Load (CL) and Single Marking (SM). |
|
| |
| RFC 6664 | S/MIME Capabilities for Public Key Definitions |
| |
| Authors: | J. Schaad. |
| Date: | July 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6664 |
|
This document defines a set of Secure/Multipurpose Internet MailExtensions (S/MIME) Capability types for ASN.1 encoding for the current set of public keys defined by the PKIX working group. This facilitates the ability for a requester to specify information on the public keys and signature algorithms to be used in responses."Online Certificate Status Protocol Algorithm Agility" (RFC 6277) details an example of where this is used. |
|
| |
| RFC 6666 | A Discard Prefix for IPv6 |
| |
| Authors: | N. Hilliard, D. Freedman. |
| Date: | August 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6666 |
|
Remote triggered black hole filtering describes a method of mitigating the effects of denial-of-service attacks by selectively discarding traffic based on source or destination address. Remote triggered black hole routing describes a method of selectively re- routing traffic into a sinkhole router (for further analysis) based on destination address. This document updates the "IPv6 SpecialPurpose Address Registry" by explaining why a unique IPv6 prefix should be formally assigned by IANA for the purpose of facilitatingIPv6 remote triggered black hole filtering and routing. |
|
| |
| RFC 6669 | An Overview of the Operations, Administration, and Maintenance (OAM) Toolset for MPLS-Based Transport Networks |
| |
| Authors: | N. Sprecher, L. Fang. |
| Date: | July 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6669 |
|
This document provides an overview of the Operations, Administration, and Maintenance (OAM) toolset for MPLS-based transport networks. The toolset consists of a comprehensive set of fault management and performance monitoring capabilities (operating in the data plane) that are appropriate for transport networks as required in RFC 5860 and support the network and services at different nested levels.This overview includes a brief recap of the MPLS Transport Profile(MPLS-TP) OAM requirements and functions and the generic mechanisms created in the MPLS data plane that allow the OAM packets to run in-band and share their fate with data packets. The protocol definitions for each of the MPLS-TP OAM tools are defined in separate documents (RFCs or Working Group documents), which are referenced by this document. |
|
| |
| RFC 6670 | The Reasons for Selecting a Single Solution for MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM) |
| |
| Authors: | N. Sprecher, KY. Hong. |
| Date: | July 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6670 |
|
The MPLS Transport Profile (MPLS-TP) is a profile of the MPLS technology for use in transport network deployments. The work onMPLS-TP has extended the MPLS technology with additional architectural elements and functions that can be used in any MPLS deployment. MPLS-TP is a set of functions and features selected from the extended MPLS toolset and applied in a consistent way to meet the needs and requirements of operators of packet transport networks.
During the process of development of the profile, additions to theMPLS toolset have been made to ensure that the tools available met the requirements. These additions were motivated by MPLS-TP, but form part of the wider MPLS toolset such that any of them could be used in any MPLS deployment.
One major set of additions provides enhanced support for Operations,Administration, and Maintenance (OAM). This enables fault management and performance monitoring to the level needed in a transport network. Many solutions and protocol extensions have been proposed to address the requirements for MPLS-TP OAM, and this document sets out the reasons for selecting a single, coherent set of solutions for standardization. |
|
| |
| RFC 6671 | Allocation of a Generic Associated Channel Type for ITU-T MPLS Transport Profile Operation, Maintenance, and Administration (MPLS-TP OAM) |
| |
| Authors: | M. Betts. |
| Date: | November 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6671 |
|
This document assigns a Generic Associated Channel (G-ACh) Type for carrying ITU-T MPLS Transport Profile Operations, Administration, andManagement (MPLS-TP OAM) messages in the MPLS Generic AssociatedChannel. |
|
| |
| RFC 6676 | Multicast Addresses for Documentation |
| |
| Authors: | S. Venaas, R. Parekh, G. Van de Velde, T. Chown, M. Eubanks. |
| Date: | August 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6676 |
|
This document discusses which multicast addresses should be used for documentation purposes and reserves multicast addresses for such use.Some multicast addresses are derived from AS numbers or unicast addresses. This document also explains how these can be used for documentation purposes. |
|
| |
| RFC 6678 | Requirements for a Tunnel-Based Extensible Authentication Protocol (EAP) Method |
| |
| Authors: | K. Hoeper, S. Hanna, H. Zhou, J. Salowey, Ed.. |
| Date: | July 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6678 |
|
This memo defines the requirements for a tunnel-based ExtensibleAuthentication Protocol (EAP) Method. This tunnel method will useTransport Layer Security (TLS) to establish a secure tunnel. The tunnel will provide support for password authentication, EAP authentication, and the transport of additional data for other purposes. |
|
| |
| RFC 6683 | Guidelines for Implementing Digital Video Broadcasting - IPTV (DVB-IPTV) Application-Layer Hybrid Forward Error Correction (FEC) Protection |
| |
| Authors: | A. Begen, T. Stockhammer. |
| Date: | August 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6683 |
|
Annex E of the Digital Video Broadcasting - IPTV (DVB-IPTV) technical specification defines an optional Application-Layer Forward ErrorCorrection (AL-FEC) protocol to protect the streaming media transported using RTP. The DVB-IPTV AL-FEC protocol uses two layers for FEC protection. The first (base) layer is based on the 1-D interleaved parity code. The second (enhancement) layer is based on the Raptor code. By offering a layered approach, the DVB-IPTV AL-FEC protocol offers good protection against both bursty and random packet losses at a cost of decent complexity. This document describes how one can implement the DVB-IPTV AL-FEC protocol by using the 1-D interleaved parity code and Raptor code that have already been specified in separate documents. |
|
| |
| RFC 6684 | Guidelines and Template for Defining Extensions to the Incident Object Description Exchange Format (IODEF) |
| |
| Authors: | B. Trammell. |
| Date: | July 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6684 |
|
This document provides guidelines for extensions to the IncidentObject Description Exchange Format (IODEF) described in RFC 5070 for exchange of incident management data, and it contains a template forInternet-Drafts describing those extensions, in order to ease the work and improve the quality of extension descriptions. |
|
| |
| RFC 6686 | Resolution of the Sender Policy Framework (SPF) and Sender ID Experiments |
| |
| Authors: | M. Kucherawy. |
| Date: | July 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6686 |
|
In 2006, the IETF published a suite of protocol documents comprising the Sender Policy Framework (SPF) and Sender ID: two proposed email authentication protocols. Both of these protocols enable one to publish, via the Domain Name System, a policy declaring which mail servers were authorized to send email on behalf of the domain name being queried. There was concern that the two would conflict in some significant operational situations, interfering with message delivery.
The IESG required all of these documents (RFC 4405, RFC 4406, RFC4407, and RFC 4408) to be published as Experimental RFCs and requested that the community observe deployment and operation of the protocols over a period of two years from the date of publication to determine a reasonable path forward.
After six years, sufficient experience and evidence have been collected that the experiments thus created can be considered concluded. This document presents those findings. |
|
| |
| RFC 6687 | Performance Evaluation of the Routing Protocol for Low-Power and Lossy Networks (RPL) |
| |
| Authors: | J. Tripathi, Ed., J. de Oliveira, Ed., JP. Vasseur, Ed.. |
| Date: | October 2012 |
| Formats: | txt json pdf html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6687 |
|
This document presents a performance evaluation of the RoutingProtocol for Low-Power and Lossy Networks (RPL) for a small outdoor deployment of sensor nodes and for a large-scale smart meter network.Detailed simulations are carried out to produce several routing performance metrics using these real-life deployment scenarios.Please refer to the PDF version of this document, which includes several plots for the performance metrics not shown in the plain-text version. |
|
| |
| RFC 6689 | Usage of the RSVP ASSOCIATION Object |
| |
| Authors: | L. Berger. |
| Date: | July 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6689 |
|
The Resource Reservation Protocol (RSVP) ASSOCIATION object is defined in the context of GMPLS-controlled label switched paths(LSPs). In this context, the object is used to associate recoveryLSPs with the LSP they are protecting. This document reviews how the association is to be provided in the context of GMPLS recovery. No new procedures or mechanisms are defined by this document, and it is strictly informative in nature. |
|
| |
| RFC 6691 | TCP Options and Maximum Segment Size (MSS) |
| |
|
|
This memo discusses what value to use with the TCP Maximum SegmentSize (MSS) option, and updates RFC 879 and RFC 2385. |
|
| |
| RFC 6694 | The "about" URI Scheme |
| |
| Authors: | S. Moonesamy, Ed.. |
| Date: | August 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6694 |
|
This document describes the "about" URI scheme, which is widely used by Web browsers and some other applications to designate access to their internal resources, such as settings, application information, hidden built-in functionality, and so on. |
|
| |
| RFC 6695 | Methods to Convey Forward Error Correction (FEC) Framework Configuration Information |
| |
| Authors: | R. Asati. |
| Date: | August 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6695 |
|
The Forward Error Correction (FEC) Framework document (RFC 6363) defines the FEC Framework Configuration Information necessary for theFEC Framework operation. This document describes how to use signaling protocols such as the Session Announcement Protocol (SAP), the Session Initiation Protocol (SIP), the Real Time StreamingProtocol (RTSP), etc. for determining and communicating the configuration information between sender(s) and receiver(s).
This document doesn't define any new signaling protocol. |
|
| |
| RFC 6697 | Handover Keying (HOKEY) Architecture Design |
| |
| Authors: | G. Zorn, Ed., Q. Wu, T. Taylor, Y. Nir, K. Hoeper, S. Decugis. |
| Date: | July 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6697 |
|
The Handover Keying (HOKEY) Working Group seeks to minimize handover delay due to authentication when a peer moves from one point of attachment to another. Work has progressed on two different approaches to reduce handover delay: early authentication (so that authentication does not need to be performed during handover), and reuse of cryptographic material generated during an initial authentication to save time during re-authentication. A basic assumption is that the mobile host or "peer" is initially authenticated using the Extensible Authentication Protocol (EAP), executed between the peer and an EAP server as defined in RFC 3748.
This document defines the HOKEY architecture. Specifically, it describes design objectives, the functional environment within which handover keying operates, the functions to be performed by the HOKEY architecture itself, and the assignment of those functions to architectural components. It goes on to illustrate the operation of the architecture within various deployment scenarios that are described more fully in other documents produced by the HOKEY WorkingGroup. |
|
| |
| RFC 6701 | Sanctions Available for Application to Violators of IETF IPR Policy |
| |
| Authors: | A. Farrel, P. Resnick. |
| Date: | August 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6701 |
|
The IETF has developed and documented policies that govern the behavior of all IETF participants with respect to IntellectualProperty Rights (IPR) about which they might reasonably be aware.
The IETF takes conformance to these IPR policies very seriously.However, there has been some ambiguity as to what the appropriate sanctions are for the violation of these policies, and how and by whom those sanctions are to be applied.
This document discusses these issues and provides a suite of potential actions that can be taken within the IETF community in cases related to patents. |
|
| |
| RFC 6702 | Promoting Compliance with Intellectual Property Rights (IPR) Disclosure Rules |
| |
|
|
The disclosure process for intellectual property rights (IPR) in documents produced within the IETF stream is essential to the accurate development of community consensus. However, this process is not always followed by IETF participants. Regardless of the cause or motivation, noncompliance with IPR disclosure rules can delay or even derail completion of IETF specifications. This document describes some strategies for promoting compliance with the IPR disclosure rules. These strategies are primarily intended for use by area directors, working group chairs, and working group secretaries. |
|
| |
| RFC 6703 | Reporting IP Network Performance Metrics: Different Points of View |
| |
| Authors: | A. Morton, G. Ramachandran, G. Maguluri. |
| Date: | August 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6703 |
|
Consumers of IP network performance metrics have many different uses in mind. This memo provides "long-term" reporting considerations(e.g., hours, days, weeks, or months, as opposed to 10 seconds), based on analysis of the points of view of two key audiences. It describes how these audience categories affect the selection of metric parameters and options when seeking information that serves their needs. |
|
| |
| RFC 6707 | Content Distribution Network Interconnection (CDNI) Problem Statement |
| |
| Authors: | B. Niven-Jenkins, F. Le Faucheur, N. Bitar. |
| Date: | September 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6707 |
|
Content Delivery Networks (CDNs) provide numerous benefits for cacheable content: reduced delivery cost, improved quality of experience for End Users, and increased robustness of delivery. For these reasons, they are frequently used for large-scale content delivery. As a result, existing CDN Providers are scaling up their infrastructure, and many Network Service Providers (NSPs) are deploying their own CDNs. It is generally desirable that a given content item can be delivered to an End User regardless of that EndUser's location or attachment network. This is the motivation for interconnecting standalone CDNs so they can interoperate as an open content delivery infrastructure for the end-to-end delivery of content from Content Service Providers (CSPs) to End Users. However, no standards or open specifications currently exist to facilitate such CDN Interconnection.
The goal of this document is to outline the problem area of CDNInterconnection for the IETF CDNI (CDN Interconnection) working group. |
|
| |
| RFC 6708 | Application-Layer Traffic Optimization (ALTO) Requirements |
| |
| Authors: | S. Kiesel, Ed., S. Previdi, M. Stiemerling, R. Woundy, Y. Yang. |
| Date: | September 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6708 |
|
Many Internet applications are used to access resources, such as pieces of information or server processes that are available in several equivalent replicas on different hosts. This includes, but is not limited to, peer-to-peer file sharing applications. The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications that have to select one or several hosts from a set of candidates capable of providing a desired resource.This guidance shall be based on parameters that affect performance and efficiency of the data transmission between the hosts, e.g., the topological distance. The ultimate goal is to improve performance orQuality of Experience in the application while reducing the utilization of the underlying network infrastructure.
This document enumerates requirements for specifying, assessing, or comparing protocols and implementations. |
|
| |
| RFC 6709 | Design Considerations for Protocol Extensions |
| |
| Authors: | B. Carpenter, B. Aboba, Ed., S. Cheshire. |
| Date: | September 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6709 |
|
This document discusses architectural issues related to the extensibility of Internet protocols, with a focus on design considerations. It is intended to assist designers of both base protocols and extensions. Case studies are included. A companion document, RFC 4775 (BCP 125), discusses procedures relating to the extensibility of IETF protocols. |
|
| |
| RFC 6711 | An IANA Registry for Level of Assurance (LoA) Profiles |
| |
| Authors: | L. Johansson. |
| Date: | August 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6711 |
|
This document establishes an IANA registry for Level of Assurance(LoA) Profiles. The registry is intended to be used as an aid to discovering such LoA definitions in protocols that use an LoA concept, including Security Assertion Markup Language (SAML) 2.0 andOpenID Connect. |
|
| |
| RFC 6713 | The 'application/zlib' and 'application/gzip' Media Types |
| |
| Authors: | J. Levine. |
| Date: | August 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6713 |
|
This document defines the 'application/gzip' and 'application/zlib' media types for compressed data using the gzip and zlib compression formats. |
|
| |
| RFC 6717 | kx509 Kerberized Certificate Issuance Protocol in Use in 2012 |
| |
| Authors: | H. Hotz, R. Allbery. |
| Date: | August 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6717 |
|
This document describes a protocol, called kx509, for using Kerberos tickets to acquire X.509 certificates. These certificates may be used for many of the same purposes as X.509 certificates acquired by other means, but if a Kerberos infrastructure already exists, then the overhead of using kx509 may be much less.
While not standardized, this protocol is already in use at several large organizations, and certificates issued with this protocol are recognized by the International Grid Trust Federation. |
|
| |
| RFC 6718 | Pseudowire Redundancy |
| |
| Authors: | P. Muley, M. Aissaoui, M. Bocci. |
| Date: | August 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6718 |
|
This document describes a framework comprised of a number of scenarios and associated requirements for pseudowire (PW) redundancy.A set of redundant PWs is configured between provider edge (PE) nodes in single-segment PW applications or between terminating PE (T-PE) nodes in multi-segment PW applications. In order for the PE/T-PE nodes to indicate the preferred PW to use for forwarding PW packets to one another, a new PW status is required to indicate the preferential forwarding status of active or standby for each PW in the redundant set. |
|
| |
| RFC 6722 | Publishing the "Tao of the IETF" as a Web Page |
| |
|
|
This document describes how the "Tao of the IETF", which has been published as a series of RFCs in the past, is instead being published as a web page. It also contains the procedure for publishing and editing that web page. |
|
| |
| RFC 6730 | Requirements for IETF Nominations Committee Tools |
| |
| Authors: | S. Krishnan, J. Halpern. |
| Date: | September 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6730 |
|
This document defines the requirements for a set of tools for use by the IETF Nominations Committee. |
|
| |
| RFC 6752 | Issues with Private IP Addressing in the Internet |
| |
| Authors: | A. Kirkham. |
| Date: | September 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6752 |
|
The purpose of this document is to provide a discussion of the potential problems of using private, RFC 1918, or non-globally routable addressing within the core of a Service Provider (SP) network. The discussion focuses on link addresses and, to a small extent, loopback addresses. While many of the issues are well recognised within the ISP community, there appears to be no document that collectively describes the issues. |
|
| |
| RFC 6755 | An IETF URN Sub-Namespace for OAuth |
| |
| Authors: | B. Campbell, H. Tschofenig. |
| Date: | October 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6755 |
|
This document establishes an IETF URN Sub-namespace for use withOAuth-related specifications. |
|
| |
| RFC 6756 | Internet Engineering Task Force and International Telecommunication Union - Telecommunication Standardization Sector Collaboration Guidelines |
| |
| Authors: | S. Trowbridge, Ed., E. Lear, Ed., G. Fishman, Ed., S. Bradner, Ed.. |
| Date: | September 2012 |
| Formats: | txt html json |
| Obsoletes: | RFC 3356 |
| Updated by: | RFC 9141 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6756 |
|
This document provides guidance to aid in the understanding of collaboration on standards development between the TelecommunicationStandardization Sector of the International Telecommunication Union(ITU-T) and the Internet Engineering Task Force (IETF) of theInternet Society (ISOC). It is an update of and obsoletes RFC 3356.The updates reflect changes in the IETF and ITU-T since RFC 3356 was written. The bulk of this document is common text with ITU-T ASeries Supplement 3 (07/2012).
Note: This was approved by TSAG on 4 July 2012 as Supplement 3 to theITU-T A-Series of Recommendations. |
|
| |
| RFC 6758 | Tunneling of SMTP Message Transfer Priorities |
| |
| Authors: | A. Melnikov, K. Carlberg. |
| Date: | October 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6758 |
|
This memo defines a mechanism for tunneling of SMTP (Simple MailTransfer Protocol) Message Transfer Priority values through MTAs(Message Transfer Agents) that don't support the MT-PRIORITY SMTP extension. |
|
| |
| RFC 6759 | Cisco Systems Export of Application Information in IP Flow Information Export (IPFIX) |
| |
| Authors: | B. Claise, P. Aitken, N. Ben-Dvora. |
| Date: | November 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6759 |
|
This document specifies a Cisco Systems extension to the IPFIX information model specified in RFC 5102 to export application information. |
|
| |
| RFC 6760 | Requirements for a Protocol to Replace the AppleTalk Name Binding Protocol (NBP) |
| |
| Authors: | S. Cheshire, M. Krochmal. |
| Date: | February 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6760 |
|
One of the goals of the authors of Multicast DNS (mDNS) and DNS-BasedService Discovery (DNS-SD) was to retire AppleTalk and the AppleTalkName Binding Protocol (NBP) and to replace them with an IP-based solution. This document presents a brief overview of the capabilities of AppleTalk NBP and outlines the properties required of an IP-based replacement. |
|
| |
| RFC 6769 | Simple Virtual Aggregation (S-VA) |
| |
| Authors: | R. Raszuk, J. Heitz, A. Lo, L. Zhang, X. Xu. |
| Date: | October 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6769 |
|
All BGP routers in the Default-Free Zone (DFZ) are required to carry all routes in the Default-Free Routing Table (DFRT). This document describes a technique, Simple Virtual Aggregation (S-VA), that allows some BGP routers not to install all of those routes into theForwarding Information Base (FIB).
Some routers in an Autonomous System (AS) announce an aggregate (theVA prefix) in addition to the routes they already announce. This enables other routers not to install the routes covered by the VA prefix into the FIB as long as those routes have the same next-hop as the VA prefix.
The VA prefixes that are announced within an AS are not announced to any other AS. The described functionality is of very low operational complexity, as it proposes a confined BGP speaker solution without any dependency on network-wide configuration or requirement for any form of intra-domain tunneling. |
|
| |
| RFC 6770 | Use Cases for Content Delivery Network Interconnection |
| |
| Authors: | G. Bertrand, Ed., E. Stephan, T. Burbridge, P. Eardley, K. Ma, G. Watson. |
| Date: | November 2012 |
| Formats: | txt json html |
| Obsoletes: | RFC 3570 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6770 |
|
Content Delivery Networks (CDNs) are commonly used for improving theEnd User experience of a content delivery service while keeping cost at a reasonable level. This document focuses on use cases that correspond to identified industry needs and that are expected to be realized once open interfaces and protocols supporting the interconnection of CDNs are specified and implemented. This document can be used to motivate the definition of the requirements to be supported by CDN Interconnection (CDNI) interfaces. It obsoletes RFC3570. |
|
| |
| RFC 6771 | Considerations for Having a Successful "Bar BOF" Side Meeting |
| |
| Authors: | L. Eggert, G. Camarillo. |
| Date: | October 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6771 |
|
New work is typically brought to the IETF by a group of interested individuals. IETF meetings are a convenient place for such groups to hold informal get-togethers to discuss and develop their ideas. Such side meetings, which are not reflected in the IETF meeting agenda and have no official status, are often half-jokingly referred to as "barBOF" sessions to acknowledge that some of them may eventually lead to a proposal for an official IETF BOF ("birds of a feather" session) on a given topic.
During recent IETF meetings, many such "bar BOF" get-togethers have been organized and moderated in ways that made them increasingly indistinguishable from official IETF BOFs or sometimes even IETF working group meetings.
This document argues that this recent trend is not helpful in reaching the ultimate goal of many of these get-togethers, i.e., to efficiently discuss and develop ideas for new IETF work. It encourages the organizers to consider the benefits of holding them in much less formal settings and to also consider alternative means to develop their ideas. This document also recommends that the community abandon the term "bar BOF" and instead use other terms such as "side meeting", in order to stress the unofficial nature of these get-togethers. |
|
| |
| RFC 6774 | Distribution of Diverse BGP Paths |
| |
| Authors: | R. Raszuk, Ed., R. Fernando, K. Patel, D. McPherson, K. Kumaki. |
| Date: | November 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6774 |
|
The BGP4 protocol specifies the selection and propagation of a single best path for each prefix. As defined and widely deployed today, BGP has no mechanisms to distribute alternate paths that are not considered best path between its speakers. This behavior results in a number of disadvantages for new applications and services.
The main objective of this document is to observe that by simply adding a new session between a route reflector and its client, theNth best path can be distributed. This document also compares existing solutions and proposed ideas that enable distribution of more paths than just the best path.
This proposal does not specify any changes to the BGP protocol definition. It does not require a software upgrade of provider edge(PE) routers acting as route reflector clients. |
|
| |
| RFC 6778 | Requirements for Archiving IETF Email Lists and for Providing Web-Based Browsing and Searching |
| |
| Authors: | R. Sparks. |
| Date: | October 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6778 |
|
The IETF makes heavy use of email lists to conduct its work.Participants frequently need to search and browse the archives of these lists and have asked for improved search capabilities. The current archive mechanism could also be made more efficient. This memo captures the requirements for improved email list archiving and searching systems. |
|
| |
| RFC 6781 | DNSSEC Operational Practices, Version 2 |
| |
| Authors: | O. Kolkman, W. Mekking, R. Gieben. |
| Date: | December 2012 |
| Formats: | txt json html |
| Obsoletes: | RFC 4641 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6781 |
|
This document describes a set of practices for operating the DNS with security extensions (DNSSEC). The target audience is zone administrators deploying DNSSEC.
The document discusses operational aspects of using keys and signatures in the DNS. It discusses issues of key generation, key storage, signature generation, key rollover, and related policies.
This document obsoletes RFC 4641, as it covers more operational ground and gives more up-to-date requirements with respect to key sizes and the DNSSEC operations. |
|
| |
| RFC 6782 | Wireline Incremental IPv6 |
| |
| Authors: | V. Kuarsingh, Ed., L. Howard. |
| Date: | November 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6782 |
|
Operators worldwide are in various stages of preparing for or deploying IPv6 in their networks. These operators often face difficult challenges related to IPv6 introduction, along with those related to IPv4 run-out. Operators will need to meet the simultaneous needs of IPv6 connectivity and continue support for IPv4 connectivity for legacy devices with a stagnant supply of IPv4 addresses. The IPv6 transition will take most networks from an IPv4- only environment to an IPv6-dominant environment with long transition periods varying by operator. This document helps provide a framework for wireline providers who are faced with the challenges of introducing IPv6 along with meeting the legacy needs of IPv4 connectivity, utilizing well-defined and commercially available IPv6 transition technologies. |
|
| |
| RFC 6783 | Mailing Lists and Non-ASCII Addresses |
| |
|
|
This document describes considerations for mailing lists with the introduction of non-ASCII UTF-8 email addresses. It outlines some possible scenarios for handling lists with mixtures of non-ASCII and traditional addresses but does not specify protocol changes or offer implementation or deployment advice. |
|
| |
| RFC 6789 | Congestion Exposure (ConEx) Concepts and Use Cases |
| |
| Authors: | B. Briscoe, Ed., R. Woundy, Ed., A. Cooper, Ed.. |
| Date: | December 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6789 |
|
This document provides the entry point to the set of documentation about the Congestion Exposure (ConEx) protocol. It explains the motivation for including a ConEx marking at the IP layer: to expose information about congestion to network nodes. Although such information may have a number of uses, this document focuses on how the information communicated by the ConEx marking can serve as the basis for significantly more efficient and effective traffic management than what exists on the Internet today. |
|
| |
| RFC 6792 | Guidelines for Use of the RTP Monitoring Framework |
| |
| Authors: | Q. Wu, Ed., G. Hunt, P. Arden. |
| Date: | November 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6792 |
|
This memo proposes an extensible Real-time Transport Protocol (RTP) monitoring framework for extending the RTP Control Protocol (RTCP) with a new RTCP Extended Reports (XR) block type to report new metrics regarding media transmission or reception quality. In this framework, a new XR block should contain a single metric or a small number of metrics relevant to a single parameter of interest or concern, rather than containing a number of metrics that attempt to provide full coverage of all those parameters of concern to a specific application. Applications may then "mix and match" to create a set of blocks that cover their set of concerns. Where possible, a specific block should be designed to be reusable across more than one application, for example, for all of voice, streaming audio, and video. |
|
| |
| RFC 6801 | Pseudo Content Delivery Protocol (CDP) for Protecting Multiple Source Flows in the Forward Error Correction (FEC) Framework |
| |
| Authors: | U. Kozat, A. Begen. |
| Date: | November 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6801 |
|
This document provides a pseudo Content Delivery Protocol (CDP) to protect multiple source flows with one or more repair flows based on the Forward Error Correction (FEC) Framework and the SessionDescription Protocol (SDP) elements defined for the framework. The purpose of the document is not to provide a full-fledged protocol but to show how the defined framework and SDP elements can be combined together to implement a CDP. |
|
| |
| RFC 6802 | Ericsson Two-Way Active Measurement Protocol (TWAMP) Value-Added Octets |
| |
| Authors: | S. Baillargeon, C. Flinta, A. Johnsson. |
| Date: | November 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6802 |
|
This memo describes an extension to the Two-Way Active MeasurementProtocol (TWAMP). Specifically, it extends the TWAMP-Test protocol, which identifies and manages packet trains, in order to measure capacity metrics like the available path capacity, tight section capacity, and UDP delivery rate in the forward and reverse path directions. |
|
| |
| RFC 6803 | Camellia Encryption for Kerberos 5 |
| |
| Authors: | G. Hudson. |
| Date: | November 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6803 |
|
This document specifies two encryption types and two corresponding checksum types for the Kerberos cryptosystem framework defined in RFC3961. The new types use the Camellia block cipher in CBC mode with ciphertext stealing and the CMAC algorithm for integrity protection. |
|
| |
| RFC 6805 | The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS and GMPLS |
| |
| Authors: | D. King, Ed., A. Farrel, Ed.. |
| Date: | November 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6805 |
|
Computing optimum routes for Label Switched Paths (LSPs) across multiple domains in MPLS Traffic Engineering (MPLS-TE) and GMPLS networks presents a problem because no single point of path computation is aware of all of the links and resources in each domain. A solution may be achieved using the Path ComputationElement (PCE) architecture.
Where the sequence of domains is known a priori, various techniques can be employed to derive an optimum path. If the domains are simply connected, or if the preferred points of interconnection are also known, the Per-Domain Path Computation technique can be used. Where there are multiple connections between domains and there is no preference for the choice of points of interconnection, the Backward-Recursive PCE-based Computation (BRPC) procedure can be used to derive an optimal path.
This document examines techniques to establish the optimum path when the sequence of domains is not known in advance. The document shows how the PCE architecture can be extended to allow the optimum sequence of domains to be selected, and the optimum end-to-end path to be derived through the use of a hierarchical relationship between domains. |
|
| |
| RFC 6808 | Test Plan and Results Supporting Advancement of RFC 2679 on the Standards Track |
| |
| Authors: | L. Ciavattone, R. Geib, A. Morton, M. Wieser. |
| Date: | December 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6808 |
|
This memo provides the supporting test plan and results to advanceRFC 2679 on one-way delay metrics along the Standards Track, following the process in RFC 6576. Observing that the metric definitions themselves should be the primary focus rather than the implementations of metrics, this memo describes the test procedures to evaluate specific metric requirement clauses to determine if the requirement has been interpreted and implemented as intended. Two completely independent implementations have been tested against the key specifications of RFC 2679. This memo also provides direct input for development of a revision of RFC 2679. |
|
| |
| RFC 6812 | Cisco Service-Level Assurance Protocol |
| |
| Authors: | M. Chiba, A. Clemm, S. Medley, J. Salowey, S. Thombare, E. Yedavalli. |
| Date: | January 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6812 |
|
Cisco's Service-Level Assurance Protocol (Cisco's SLA Protocol) is aPerformance Measurement protocol that has been widely deployed. The protocol is used to measure service-level parameters such as network latency, delay variation, and packet/frame loss. This document describes the Cisco SLA Protocol Measurement-Type UDP-Measurement, to enable vendor interoperability. |
|
| |
| RFC 6813 | The Network Endpoint Assessment (NEA) Asokan Attack Analysis |
| |
| Authors: | J. Salowey, S. Hanna. |
| Date: | December 2012 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6813 |
|
The Network Endpoint Assessment (NEA) protocols are subject to a subtle forwarding attack that has become known as the NEA AsokanAttack. This document describes the attack and countermeasures that may be mounted. |
|
| |
| RFC 6815 | Applicability Statement for RFC 2544: Use on Production Networks Considered Harmful |
| |
| Authors: | S. Bradner, K. Dubray, J. McQuaid, A. Morton. |
| Date: | November 2012 |
| Formats: | txt html json |
| Updates: | RFC 2544 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6815 |
|
The Benchmarking Methodology Working Group (BMWG) has been developing key performance metrics and laboratory test methods since 1990, and continues this work at present. The methods described in RFC 2544 are intended to generate traffic that overloads network device resources in order to assess their capacity. Overload of shared resources would likely be harmful to user traffic performance on a production network, and there are further negative consequences identified with production application of the methods. This memo clarifies the scope of RFC 2544 and other IETF BMWG benchmarking work for isolated test environments only, and it encourages new standards activity for measurement methods applicable outside that scope. |
|
| |
| RFC 6819 | OAuth 2.0 Threat Model and Security Considerations |
| |
| Authors: | T. Lodderstedt, Ed., M. McGloin, P. Hunt. |
| Date: | January 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6819 |
|
This document gives additional security considerations for OAuth, beyond those in the OAuth 2.0 specification, based on a comprehensive threat model for the OAuth 2.0 protocol. |
|
| |
| RFC 6820 | Address Resolution Problems in Large Data Center Networks |
| |
| Authors: | T. Narten, M. Karir, I. Foo. |
| Date: | January 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6820 |
|
This document examines address resolution issues related to the scaling of data centers with a very large number of hosts. The scope of this document is relatively narrow, focusing on address resolution(the Address Resolution Protocol (ARP) in IPv4 and Neighbor Discovery(ND) in IPv6) within a data center. |
|
| |
| RFC 6821 | Improving Peer Selection in Peer-to-peer Applications: Myths vs |
| |
| Authors: | Reality. E. Marocco, A. Fusco, I. Rimac, V. Gurbani. |
| Date: | December 2012 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6821 |
|
Peer-to-peer (P2P) traffic optimization techniques that aim at improving locality in the peer selection process have attracted great interest in the research community and have been the subject of much discussion. Some of this discussion has produced controversial myths, some rooted in reality while others remain unfounded. This document evaluates the most prominent myths attributed to P2P optimization techniques by referencing the most relevant study or studies that have addressed facts pertaining to the myth. Using these studies, the authors hope to either confirm or refute each specific myth.
This document is a product of the IRTF P2PRG (Peer-to-Peer ResearchGroup). |
|
| |
| RFC 6828 | Content Splicing for RTP Sessions |
| |
| Authors: | J. Xia. |
| Date: | January 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6828 |
|
Content splicing is a process that replaces the content of a main multimedia stream with other multimedia content and delivers the substitutive multimedia content to the receivers for a period of time. Splicing is commonly used for insertion of local advertisements by cable operators, whereby national advertisement content is replaced with a local advertisement.
This memo describes some use cases for content splicing and a set of requirements for splicing content delivered by RTP. It provides concrete guidelines for how an RTP mixer can be used to handle content splicing. |
|
| |
| RFC 6835 | The Locator/ID Separation Protocol Internet Groper (LIG) |
| |
| Authors: | D. Farinacci, D. Meyer. |
| Date: | January 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6835 |
|
A simple tool called the Locator/ID Separation Protocol (LISP)Internet Groper or 'lig' can be used to query the LISP mapping database. This document describes how it works. |
|
| |
| RFC 6839 | Additional Media Type Structured Syntax Suffixes |
| |
|
|
A content media type name sometimes includes partitioned meta- information distinguished by a structured syntax to permit noting an attribute of the media as a suffix to the name. This document defines several structured syntax suffixes for use with media type registrations. In particular, it defines and registers the "+json","+ber", "+der", "+fastinfoset", "+wbxml" and "+zip" structured syntax suffixes, and provides a media type structured syntax suffix registration form for the "+xml" structured syntax suffix. |
|
| |
| RFC 6841 | A Framework for DNSSEC Policies and DNSSEC Practice Statements |
| |
| Authors: | F. Ljunggren, AM. Eklund Lowinder, T. Okubo. |
| Date: | January 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6841 |
|
This document presents a framework to assist writers of DNS SecurityExtensions (DNSSEC) Policies and DNSSEC Practice Statements, such as domain managers and zone operators on both the top level and secondary level, who are managing and operating a DNS zone withSecurity Extensions implemented.
In particular, the framework provides a comprehensive list of topics that should be considered for inclusion into a DNSSEC Policy definition and Practice Statement. |
|
| |
| RFC 6847 | Fibre Channel over Ethernet (FCoE) over Transparent Interconnection of Lots of Links (TRILL) |
| |
| Authors: | D. Melman, T. Mizrahi, D. Eastlake 3rd. |
| Date: | January 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6847 |
|
Fibre Channel over Ethernet (FCoE) and Transparent Interconnection ofLots of Links (TRILL) are two emerging standards in the data center environment. While these two protocols are seemingly unrelated, they have a very similar behavior in the forwarding plane, as both perform hop-by-hop forwarding over Ethernet, modifying the packet's MediaAccess Control (MAC) addresses at each hop. This document describes an architecture for the integrated deployment of these two protocols. |
|
| |
| RFC 6852 | Affirmation of the Modern Paradigm for Standards |
| |
| Authors: | R. Housley, S. Mills, J. Jaffe, B. Aboba, L. St.Amour. |
| Date: | January 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6852 |
|
On 29 August 2012, the leaders of the IEEE Standards Association, theIAB, the IETF, the Internet Society, and the W3C signed a statement affirming the importance of a jointly developed set of principles establishing a modern paradigm for global, open standards. These principles have become known as the "OpenStand" principles. This document contains the text of the affirmation that was signed. |
|
| |
| RFC 6861 | The "create-form" and "edit-form" Link Relations |
| |
| Authors: | I. Dzmanashvili. |
| Date: | January 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6861 |
|
RFC 5988 standardized a means of indicating the relationships between resources on the Web. This specification defines link relation types that may be used to express the relationships between a resource and an input form for constructing data submissions. |
|
| |
| RFC 6862 | Keying and Authentication for Routing Protocols (KARP) Overview, Threats, and Requirements |
| |
| Authors: | G. Lebovitz, M. Bhatia, B. Weis. |
| Date: | March 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6862 |
|
Different routing protocols employ different mechanisms for securing protocol packets on the wire. While most already have some method for accomplishing cryptographic message authentication, in many cases the existing methods are dated, vulnerable to attack, and employ cryptographic algorithms that have been deprecated. The "Keying andAuthentication for Routing Protocols" (KARP) effort aims to overhaul and improve these mechanisms. This document does not contain protocol specifications. Instead, it defines the areas where protocol specification work is needed. This document is a companion document to RFC 6518, "Keying and Authentication for RoutingProtocols (KARP) Design Guidelines"; together they form the guidance and instruction KARP design teams will use to review and overhaul routing protocol transport security. |
|
| |
| RFC 6863 | Analysis of OSPF Security According to the Keying and Authentication for Routing Protocols (KARP) Design Guide |
| |
| Authors: | S. Hartman, D. Zhang. |
| Date: | March 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6863 |
|
This document analyzes OSPFv2 and OSPFv3 according to the guidelines set forth in Section 4.2 of the "Keying and Authentication forRouting Protocols (KARP) Design Guidelines" (RFC 6518). Key components of solutions to gaps identified in this document are already underway. |
|
| |
| RFC 6866 | Problem Statement for Renumbering IPv6 Hosts with Static Addresses in Enterprise Networks |
| |
| Authors: | B. Carpenter, S. Jiang. |
| Date: | February 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6866 |
|
This document analyses the problems of updating the IPv6 addresses of hosts in enterprise networks that, for operational reasons, require static addresses. |
|
| |
| RFC 6875 | The P2P Network Experiment Council's Activities and Experiments with Application-Layer Traffic Optimization (ALTO) in Japan |
| |
| Authors: | S. Kamei, T. Momose, T. Inoue, T. Nishitani. |
| Date: | February 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6875 |
|
This document describes experiments that clarify how an approach similar to Application-Layer Traffic Optimization (ALTO) was effective in reducing network traffic. These experiments were performed in Japan by the P2P Network Experiment Council in an attempt to harmonize peer-to-peer (P2P) technology with network infrastructure. Based on what was learned from these experiments, this document provides some suggestions that might be useful for theALTO architecture and especially for application-independent ALTO- like server operation. |
|
| |
| RFC 6877 | 464XLAT: Combination of Stateful and Stateless Translation |
| |
| Authors: | M. Mawatari, M. Kawashima, C. Byrne. |
| Date: | April 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6877 |
|
This document describes an architecture (464XLAT) for providing limited IPv4 connectivity across an IPv6-only network by combining existing and well-known stateful protocol translation (as described in RFC 6146) in the core and stateless protocol translation (as described in RFC 6145) at the edge. 464XLAT is a simple and scalable technique to quickly deploy limited IPv4 access service to IPv6-only edge networks without encapsulation. |
|
| |
| RFC 6879 | IPv6 Enterprise Network Renumbering Scenarios, Considerations, and Methods |
| |
| Authors: | S. Jiang, B. Liu, B. Carpenter. |
| Date: | February 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6879 |
|
This document analyzes events that cause renumbering and describes the current renumbering methods. These are described in three categories: those applicable during network design, those applicable during preparation for renumbering, and those applicable during the renumbering operation. |
|
| |
| RFC 6883 | IPv6 Guidance for Internet Content Providers and Application Service Providers |
| |
| Authors: | B. Carpenter, S. Jiang. |
| Date: | March 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6883 |
|
This document provides guidance and suggestions for Internet ContentProviders and Application Service Providers who wish to offer their service to both IPv6 and IPv4 customers. Many of the points will also apply to hosting providers or to any enterprise network preparing for IPv6 users. |
|
| |
| RFC 6885 | Stringprep Revision and Problem Statement for the Preparation and Comparison of Internationalized Strings (PRECIS) |
| |
| Authors: | M. Blanchet, A. Sullivan. |
| Date: | March 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6885 |
|
If a protocol expects to compare two strings and is prepared only for those strings to be ASCII, then using Unicode code points in those strings requires they be prepared somehow. Internationalizing DomainNames in Applications (here called IDNA2003) defined and usedStringprep and Nameprep. Other protocols subsequently definedStringprep profiles. A new approach different from Stringprep andNameprep is used for a revision of IDNA2003 (called IDNA2008). OtherStringprep profiles need to be similarly updated, or a replacement ofStringprep needs to be designed. This document outlines the issues to be faced by those designing a Stringprep replacement. |
|
| |
| RFC 6886 | NAT Port Mapping Protocol (NAT-PMP) |
| |
| Authors: | S. Cheshire, M. Krochmal. |
| Date: | April 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6886 |
|
This document describes a protocol for automating the process of creating Network Address Translation (NAT) port mappings. Included in the protocol is a method for retrieving the external IPv4 address of a NAT gateway, thus allowing a client to make its external IPv4 address and port known to peers that may wish to communicate with it.From 2005 onwards, this protocol was implemented in Apple products including Mac OS X, Bonjour for Windows, and AirPort wireless base stations. In 2013, NAT Port Mapping Protocol (NAT-PMP) was superseded by the IETF Standards Track RFC "Port Control Protocol(PCP)", which builds on NAT-PMP and uses a compatible packet format, but adds a number of significant enhancements. |
|
| |
| RFC 6889 | Analysis of Stateful 64 Translation |
| |
| Authors: | R. Penno, T. Saxena, M. Boucadair, S. Sivakumar. |
| Date: | April 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6889 |
|
Due to specific problems, Network Address Translation - ProtocolTranslation (NAT-PT) was deprecated by the IETF as a mechanism to perform IPv6-IPv4 translation. Since then, new efforts have been undertaken within IETF to standardize alternative mechanisms to perform IPv6-IPv4 translation. This document analyzes to what extent the new stateful translation mechanisms avoid the problems that caused the IETF to deprecate NAT-PT. |
|
| |
| RFC 6892 | The 'describes' Link Relation Type |
| |
| Authors: | E. Wilde. |
| Date: | March 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6892 |
|
This specification defines the 'describes' link relation type that allows resource representations to indicate that they are describing another resource. In contexts where applications want to associate described resources and description resources, and want to build services based on these associations, the 'describes' link relation type provides the opposite direction of the 'describedby' link relation type, which already is a registered link relation type. |
|
| |
| RFC 6893 | A Uniform Resource Name (URN) Namespace for the Open IPTV Forum (OIPF) |
| |
| Authors: | P. Higgs, P. Szucs. |
| Date: | March 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6893 |
|
This document describes a Uniform Resource Name (URN) namespace for the Open IPTV Forum (OIPF) for naming persistent resources defined within OIPF specifications. Example resources include technical documents and specifications, eXtensible Markup Language (XML) schemas, classification schemes, XML Document Type Definitions(DTDs), namespaces, style sheets, media assets, and other types of resources produced or managed by the OIPF. |
|
| |
| RFC 6894 | Methodology for Benchmarking MPLS Traffic Engineered (MPLS-TE) Fast Reroute Protection |
| |
| Authors: | R. Papneja, S. Vapiwala, J. Karthik, S. Poretsky, S. Rao, JL. Le Roux. |
| Date: | March 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6894 |
|
This document describes the methodology for benchmarking MPLS FastReroute (FRR) protection mechanisms for link and node protection.This document provides test methodologies and testbed setup for measuring failover times of Fast Reroute techniques while considering factors (such as underlying links) that might impact recovery times for real-time applications bound to MPLS TrafficEngineered (MPLS-TE) tunnels. |
|
| |
| RFC 6896 | SCS: KoanLogic's Secure Cookie Sessions for HTTP |
| |
| Authors: | S. Barbato, S. Dorigotti, T. Fossati, Ed.. |
| Date: | March 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6896 |
|
This memo defines a generic URI and HTTP-header-friendly envelope for carrying symmetrically encrypted, authenticated, and origin- timestamped tokens. It also describes one possible usage of such tokens via a simple protocol based on HTTP cookies.
Secure Cookie Session (SCS) use cases cover a wide spectrum of applications, ranging from distribution of authorized content viaHTTP (e.g., with out-of-band signed URIs) to securing browser sessions with diskless embedded devices (e.g., Small Office, HomeOffice (SOHO) routers) or web servers with high availability or load- balancing requirements that may want to delegate the handling of the application state to clients instead of using shared storage or forced peering. |
|
| |
| RFC 6897 | Multipath TCP (MPTCP) Application Interface Considerations |
| |
| Authors: | M. Scharf, A. Ford. |
| Date: | March 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6897 |
|
Multipath TCP (MPTCP) adds the capability of using multiple paths to a regular TCP session. Even though it is designed to be totally backward compatible to applications, the data transport differs compared to regular TCP, and there are several additional degrees of freedom that applications may wish to exploit. This document summarizes the impact that MPTCP may have on applications, such as changes in performance. Furthermore, it discusses compatibility issues of MPTCP in combination with non-MPTCP-aware applications.Finally, the document describes a basic application interface that is a simple extension of TCP's interface for MPTCP-aware applications. |
|
| |
| RFC 6903 | Additional Link Relation Types |
| |
| Authors: | J. Snell. |
| Date: | March 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6903 |
|
This specification defines a number of additional link relation types that can used for a range of purposes in a variety of applications types. |
|
| |
| RFC 6905 | Requirements for Operations, Administration, and Maintenance (OAM) in Transparent Interconnection of Lots of Links (TRILL) |
| |
| Authors: | T. Senevirathne, D. Bond, S. Aldrin, Y. Li, R. Watve. |
| Date: | March 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6905 |
|
Operations, Administration, and Maintenance (OAM) is a general term used to identify functions and toolsets to troubleshoot and monitor networks. This document presents OAM requirements applicable to theTransparent Interconnection of Lots of Links (TRILL). |
|
| |
| RFC 6906 | The 'profile' Link Relation Type |
| |
| Authors: | E. Wilde. |
| Date: | March 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6906 |
|
This specification defines the 'profile' link relation type that allows resource representations to indicate that they are following one or more profiles. A profile is defined not to alter the semantics of the resource representation itself, but to allow clients to learn about additional semantics (constraints, conventions, extensions) that are associated with the resource representation, in addition to those defined by the media type and possibly other mechanisms. |
|
| |
| RFC 6907 | Use Cases and Interpretations of Resource Public Key Infrastructure (RPKI) Objects for Issuers and Relying Parties |
| |
| Authors: | T. Manderson, K. Sriram, R. White. |
| Date: | March 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6907 |
|
This document describes a number of use cases together with directions and interpretations for organizations and relying parties when creating or encountering Resource Public Key Infrastructure(RPKI) object scenarios in the public RPKI. All of these items are discussed here in relation to the Internet routing system. |
|
| |
| RFC 6908 | Deployment Considerations for Dual-Stack Lite |
| |
| Authors: | Y. Lee, R. Maglione, C. Williams, C. Jacquenet, M. Boucadair. |
| Date: | March 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6908 |
|
This document discusses the deployment issues of and the requirements for the deployment and operation of Dual-Stack Lite (DS-Lite). This document describes the various deployment considerations and applicability of the DS-Lite architecture. |
|
| |
| RFC 6912 | Principles for Unicode Code Point Inclusion in Labels in the DNS |
| |
| Authors: | A. Sullivan, D. Thaler, J. Klensin, O. Kolkman. |
| Date: | April 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6912 |
|
Internationalized Domain Names in Applications (IDNA) makes available to DNS zone administrators a very wide range of Unicode code points.Most operators of zones should probably not permit registration ofU-labels using the entire range. This is especially true of zones that accept registrations across organizational boundaries, such as top-level domains and, most importantly, the root. It is unfortunately not possible to generate algorithms to determine whether permitting a code point presents a low risk. This memo presents a set of principles that can be used to guide the decision of whether a Unicode code point may be wisely included in the repertoire of permissible code points in a U-label in a zone. |
|
| |
| RFC 6914 | SIMPLE Made Simple: An Overview of the IETF Specifications for Instant Messaging and Presence Using the Session Initiation Protocol (SIP) |
| |
| Authors: | J. Rosenberg. |
| Date: | April 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6914 |
|
The IETF has produced many specifications related to Presence andInstant Messaging with the Session Initiation Protocol (SIP).Collectively, these specifications are known as SIP for InstantMessaging and Presence Leveraging Extensions (SIMPLE). This document serves as a guide to the SIMPLE suite of specifications. It categorizes the specifications, explains what each is for, and how they relate to each other. |
|
| |
| RFC 6921 | Design Considerations for Faster-Than-Light (FTL) Communication |
| |
| Authors: | R. Hinden. |
| Date: | 1 April 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6921 |
|
We are approaching the time when we will be able to communicate faster than the speed of light. It is well known that as we approach the speed of light, time slows down. Logically, it is reasonable to assume that as we go faster than the speed of light, time will reverse. The major consequence of this for Internet protocols is that packets will arrive before they are sent. This will have a major impact on the way we design Internet protocols. This paper outlines some of the issues and suggests some directions for additional analysis of these issues. |
|
| |
| RFC 6922 | The application/sql Media Type |
| |
| Authors: | Y. Shafranovich. |
| Date: | April 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6922 |
|
This document registers the application/sql media type to be used for the Structured Query Language (SQL). |
|
| |
| RFC 6924 | Registration of Second-Level URN Namespaces under "ietf" |
| |
|
|
RFC 2648 defines the "ietf" URN namespace and a number of sub- namespaces. RFC 3553 defines an additional sub-namespace, "params", and creates a registry to document allocations under that. But there is no registry that lists, in one place, all sub-namespaces of"ietf". This document creates and populates such a registry, thereby changing the mechanism defined in RFC 2648 for adding new sub- namespaces of "ietf". |
|
| |
| RFC 6927 | Variants in Second-Level Names Registered in Top-Level Domains |
| |
| Authors: | J. Levine, P. Hoffman. |
| Date: | May 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6927 |
|
Internationalized Domain Names for Applications (IDNA) provides a method to map a subset of names written in Unicode into the DNS.Because of Unicode decisions, appearance, language and writing system conventions, and historical reasons, it often has been asserted that there is more than one way to write what competent readers and writers think of as the same host name; these different ways of writing are often called "variants". (The authors note that there are many conflicting definitions for the term "variant" in the IDNA community.) This document surveys the approaches that top-level domains have taken to the registration and provisioning of domain names that have variants. This document is not a product of theIETF, does not propose any method to make variants work "correctly", and is not an introduction to internationalization or IDNA. |
|
| |
| RFC 6932 | Brainpool Elliptic Curves for the Internet Key Exchange (IKE) Group Description Registry |
| |
| Authors: | D. Harkins, Ed.. |
| Date: | May 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6932 |
|
This memo allocates code points for four new elliptic curve domain parameter sets over finite prime fields into a registry that was established by the Internet Key Exchange (IKE) but is used by other protocols. |
|
| |
| RFC 6934 | Applicability of the Access Node Control Mechanism to Broadband Networks Based on Passive Optical Networks (PONs) |
| |
| Authors: | N. Bitar, Ed., S. Wadhwa, Ed., T. Haag, H. Li. |
| Date: | June 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6934 |
|
The purpose of this document is to provide applicability of theAccess Node Control Mechanism to broadband access based on PassiveOptical Networks (PONs). The need for an Access Node ControlMechanism between a Network Access Server (NAS) and an Access NodeComplex, composed of a combination of Optical Line Termination (OLT) and Optical Network Termination (ONT) elements, is described in a multi-service reference architecture in order to perform QoS-related, service-related, and subscriber-related operations. The Access NodeControl Mechanism is also extended for interaction between components of the Access Node Complex (OLT and ONT). The Access Node ControlMechanism will ensure that the transmission of information between the NAS and Access Node Complex (ANX) and between the OLT and ONT within an ANX does not need to go through distinct element managers but rather uses direct device-to-device communication and stays on net. This allows for performing access-link-related operations within those network elements to meet performance objectives. |
|
| |
| RFC 6941 | MPLS Transport Profile (MPLS-TP) Security Framework |
| |
| Authors: | L. Fang, Ed., B. Niven-Jenkins, Ed., S. Mansfield, Ed., R. Graveman, Ed.. |
| Date: | April 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6941 |
|
This document provides a security framework for the MPLS TransportProfile (MPLS-TP). MPLS-TP extends MPLS technologies and introduces new Operations, Administration, and Maintenance (OAM) capabilities, a transport-oriented path protection mechanism, and strong emphasis on static provisioning supported by network management systems. This document addresses the security aspects relevant in the context ofMPLS-TP specifically. It describes potential security threats as well as mitigation procedures related to MPLS-TP networks and toMPLS-TP interconnection to other MPLS and GMPLS networks. This document is built on RFC 5920 ("Security Framework for MPLS and GMPLSNetworks") by providing additional security considerations that are applicable to the MPLS-TP extensions. All the security considerations from RFC 5920 are assumed to apply.
This document is a product of a joint Internet Engineering Task Force(IETF) / International Telecommunication Union TelecommunicationStandardization Sector (ITU-T) effort to include an MPLS TransportProfile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge(PWE3) architectures to support the capabilities and functionality of a packet transport network. |
|
| |
| RFC 6943 | Issues in Identifier Comparison for Security Purposes |
| |
| Authors: | D. Thaler, Ed.. |
| Date: | May 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6943 |
|
Identifiers such as hostnames, URIs, IP addresses, and email addresses are often used in security contexts to identify security principals and resources. In such contexts, an identifier presented via some protocol is often compared using some policy to make security decisions such as whether the security principal may access the resource, what level of authentication or encryption is required, etc. If the parties involved in a security decision use different algorithms to compare identifiers, then failure scenarios ranging from denial of service to elevation of privilege can result. This document provides a discussion of these issues that designers should consider when defining identifiers and protocols, and when constructing architectures that use multiple protocols. |
|
| |
| RFC 6947 | The Session Description Protocol (SDP) Alternate Connectivity (ALTC) Attribute |
| |
| Authors: | M. Boucadair, H. Kaplan, R. Gilman, S. Veikkolainen. |
| Date: | May 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6947 |
|
This document proposes a mechanism that allows the same SDP offer to carry multiple IP addresses of different address families (e.g., IPv4 and IPv6). The proposed attribute, the "altc" attribute, solves the backward-compatibility problem that plagued Alternative NetworkAddress Types (ANAT) due to their syntax.
The proposed solution is applicable to scenarios where connectivity checks are not required. If connectivity checks are required,Interactive Connectivity Establishment (ICE), as specified in RFC5245, provides such a solution. |
|
| |
| RFC 6948 | Some Measurements on World IPv6 Day from an End-User Perspective |
| |
| Authors: | A. Keranen, J. Arkko. |
| Date: | July 2013 |
| Formats: | txt html pdf json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6948 |
|
During World IPv6 Day on June 8, 2011, several key content providers enabled their networks to offer both IPv4 and IPv6 services.Hundreds of organizations participated in this effort, and in the months and weeks leading up to the event worked hard on preparing their networks to support this event. The event was largely unnoticed by the general public, which is a good thing since it means that no major problems were detected. For the Internet, however, there was a major change on a short timescale. This memo discusses measurements that the authors made from the perspective of an end user with good IPv4 and IPv6 connectivity. Our measurements include the number of most popular networks providing AAAA records for their service, as well as delay and connection failure statistics. |
|
| |
| RFC 6949 | RFC Series Format Requirements and Future Development |
| |
|
|
This document describes the current requirements and requests for enhancements for the format of the canonical version of RFCs. Terms are defined to help clarify exactly which stages of document production are under discussion for format changes. The requirements described in this document will determine what changes will be made to RFC format. This document updates RFC 2223. |
|
| |
| RFC 6950 | Architectural Considerations on Application Features in the DNS |
| |
| Authors: | J. Peterson, O. Kolkman, H. Tschofenig, B. Aboba. |
| Date: | October 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6950 |
|
A number of Internet applications rely on the Domain Name System(DNS) to support their operations. Many applications use the DNS to locate services for a domain; some, for example, transform identifiers other than domain names into formats that the DNS can process, and then fetch application data or service location data from the DNS. Proposals incorporating sophisticated application behavior using DNS as a substrate have raised questions about the role of the DNS as an application platform. This document explores the architectural consequences of using the DNS to implement certain application features, and it provides guidance to future application designers as to the limitations of the DNS as a substrate and the situations in which alternative designs should be considered. |
|
| |
| RFC 6952 | Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide |
| |
| Authors: | M. Jethanandani, K. Patel, L. Zheng. |
| Date: | May 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6952 |
|
This document analyzes TCP-based routing protocols, the BorderGateway Protocol (BGP), the Label Distribution Protocol (LDP), thePath Computation Element Communication Protocol (PCEP), and theMulticast Source Distribution Protocol (MSDP), according to guidelines set forth in Section 4.2 of "Keying and Authentication forRouting Protocols Design Guidelines", RFC 6518. |
|
| |
| RFC 6953 | Protocol to Access White-Space (PAWS) Databases: Use Cases and Requirements |
| |
| Authors: | A. Mancuso, Ed., S. Probasco, B. Patil. |
| Date: | May 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6953 |
|
Portions of the radio spectrum that are assigned to a particular use but are unused or unoccupied at specific locations and times are defined as "white space". The concept of allowing additional transmissions (which may or may not be licensed) in white space is a technique to "unlock" existing spectrum for new use. This document includes the problem statement for the development of a protocol to access a database of white-space information followed by use cases and requirements for that protocol. Finally, requirements associated with the protocol are presented. |
|
| |
| RFC 6954 | Using the Elliptic Curve Cryptography (ECC) Brainpool Curves for the Internet Key Exchange Protocol Version 2 (IKEv2) |
| |
| Authors: | J. Merkle, M. Lochter. |
| Date: | July 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6954 |
|
This document specifies use of the Elliptic Curve Cryptography (ECC)Brainpool elliptic curve groups for key exchange in the Internet KeyExchange Protocol version 2 (IKEv2). |
|
| |
| RFC 6959 | Source Address Validation Improvement (SAVI) Threat Scope |
| |
| Authors: | D. McPherson, F. Baker, J. Halpern. |
| Date: | May 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6959 |
|
The Source Address Validation Improvement (SAVI) effort aims to complement ingress filtering with finer-grained, standardized IP source address validation. This document describes threats enabled by IP source address spoofing both in the global and finer-grained context, describes currently available solutions and challenges, and provides a starting point analysis for finer-grained (host granularity) anti-spoofing work. |
|
| |
| RFC 6964 | Operational Guidance for IPv6 Deployment in IPv4 Sites Using the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) |
| |
| Authors: | F. Templin. |
| Date: | May 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6964 |
|
Many end-user sites in the Internet today still have predominantlyIPv4 internal infrastructures. These sites range in size from small home/office networks to large corporate enterprise networks, but share the commonality that IPv4 provides satisfactory internal routing and addressing services for most applications. As more and more IPv6-only services are deployed, however, end-user devices within such sites will increasingly require at least basic IPv6 functionality. This document therefore provides operational guidance for deployment of IPv6 within predominantly IPv4 sites using theIntra-Site Automatic Tunnel Addressing Protocol (ISATAP). |
|
| |
| RFC 6965 | MPLS Transport Profile (MPLS-TP) Applicability: Use Cases and Design |
| |
| Authors: | L. Fang, Ed., N. Bitar, R. Zhang, M. Daikoku, P. Pan. |
| Date: | August 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6965 |
|
This document describes the applicability of the MPLS TransportProfile (MPLS-TP) with use case studies and network design considerations. The use cases include Metro Ethernet access and aggregation transport, mobile backhaul, and packet optical transport. |
|
| |
| RFC 6967 | Analysis of Potential Solutions for Revealing a Host Identifier (HOST_ID) in Shared Address Deployments |
| |
| Authors: | M. Boucadair, J. Touch, P. Levis, R. Penno. |
| Date: | June 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6967 |
|
This document is a collection of potential solutions for revealing a host identifier (denoted as HOST_ID) when a Carrier Grade NAT (CGN) or application proxies are involved in the path. This host identifier could be used by a remote server to sort packets according to the sending host. The host identifier must be unique to each host under the same shared IP address.
This document analyzes a set of potential solutions for revealing a host identifier and does not recommend a particular solution, although it does highlight the hazards of some approaches. |
|
| |
| RFC 6972 | Problem Statement and Requirements of the Peer-to-Peer Streaming Protocol (PPSP) |
| |
| Authors: | Y. Zhang, N. Zong. |
| Date: | July 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6972 |
|
Peer-to-Peer (P2P) streaming systems becoming more and more popular on the Internet, and most of them are using proprietary protocols.This document identifies problems associated with proprietary protocols; proposes the development of the Peer-to-Peer StreamingProtocol (PPSP), which includes the tracker and peer protocols; and discusses the scope, requirements, and use cases of PPSP. |
|
| |
| RFC 6973 | Privacy Considerations for Internet Protocols |
| |
| Authors: | A. Cooper, H. Tschofenig, B. Aboba, J. Peterson, J. Morris, M. Hansen, R. Smith. |
| Date: | July 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6973 |
|
This document offers guidance for developing privacy considerations for inclusion in protocol specifications. It aims to make designers, implementers, and users of Internet protocols aware of privacy- related design choices. It suggests that whether any individual RFC warrants a specific privacy considerations section will depend on the document's content. |
|
| |
| RFC 6974 | Applicability of MPLS Transport Profile for Ring Topologies |
| |
| Authors: | Y. Weingarten, S. Bryant, D. Ceccarelli, D. Caviglia, F. Fondelli, M. Corsi, B. Wu, X. Dai. |
| Date: | July 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6974 |
|
This document presents an applicability of existing MPLS protection mechanisms, both local and end-to-end, to the MPLS Transport Profile(MPLS-TP) in ring topologies. This document does not propose any new mechanisms or protocols. Requirements for MPLS-TP protection especially for protection in ring topologies are discussed in"Requirements of an MPLS Transport Profile" (RFC 5654) and "MPLSTransport Profile (MPLS-TP) Survivability Framework" (RFC 6372).This document discusses how most of the requirements are met by applying linear protection as defined in RFC 6378 in a ring topology. |
|
| |
| RFC 6976 | Framework for Loop-Free Convergence Using the Ordered Forwarding Information Base (oFIB) Approach |
| |
| Authors: | M. Shand, S. Bryant, S. Previdi, C. Filsfils, P. Francois, O. Bonaventure. |
| Date: | July 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6976 |
|
This document describes an illustrative framework of a mechanism for use in conjunction with link-state routing protocols that prevents the transient loops that would otherwise occur during topology changes. It does this by correctly sequencing the forwarding information base (FIB) updates on the routers.
This mechanism can be used in the case of non-urgent (management action) link or node shutdowns and restarts or link metric changes.It can also be used in conjunction with a fast reroute mechanism that converts a sudden link or node failure into a non-urgent topology change. This is possible where a complete repair path is provided for all affected destinations.
After a non-urgent topology change, each router computes a rank that defines the time at which it can safely update its FIB. A method for accelerating this loop-free convergence process by the use of completion messages is also described.
The technology described in this document has been subject to extensive simulation using pathological convergence behavior and real network topologies and costs. However, the mechanisms described in this document are purely illustrative of the general approach and do not constitute a protocol specification. This document represents a snapshot of the work of the Routing Area Working Group at the time of publication and is published as a document of record. Further work is needed before implementation or deployment. |
|
| |
| RFC 6979 | Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) |
| |
| Authors: | T. Pornin. |
| Date: | August 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6979 |
|
This document defines a deterministic digital signature generation procedure. Such signatures are compatible with standard DigitalSignature Algorithm (DSA) and Elliptic Curve Digital SignatureAlgorithm (ECDSA) digital signatures and can be processed with unmodified verifiers, which need not be aware of the procedure described therein. Deterministic signatures retain the cryptographic security features associated with digital signatures but can be more easily implemented in various environments, since they do not need access to a source of high-quality randomness. |
|
| |
| RFC 6981 | A Framework for IP and MPLS Fast Reroute Using Not-Via Addresses |
| |
| Authors: | S. Bryant, S. Previdi, M. Shand. |
| Date: | August 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6981 |
|
This document presents an illustrative framework for providing fast reroute in an IP or MPLS network through encapsulation and forwarding to "not-via" addresses. The general approach described here uses a single level of encapsulation and could be used to protect unicast, multicast, and LDP traffic against link, router, and shared risk group failure, regardless of network topology and metrics.
The mechanisms presented in this document are purely illustrative of the general approach and do not constitute a protocol specification.The document represents a snapshot of the work of the Routing AreaWorking Group at the time of publication and is published as a document of record. Further work is needed before implementation or deployment. |
|
| |
| RFC 6983 | Models for HTTP-Adaptive-Streaming-Aware Content Distribution Network Interconnection (CDNI) |
| |
| Authors: | R. van Brandenburg, O. van Deventer, F. Le Faucheur, K. Leung. |
| Date: | July 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6983 |
|
This document presents thoughts on the potential impact of supportingHTTP Adaptive Streaming (HAS) technologies in Content DistributionNetwork Interconnection (CDNI) scenarios. The intent is to present the authors' analysis of the CDNI-HAS problem space and discuss different options put forward by the authors (and by others during informal discussions) on how to deal with HAS in the context of CDNI.This document has been used as input information during the CDNI working group process for making a decision regarding support forHAS. |
|
| |
| RFC 6984 | Interoperability Report for Forwarding and Control Element Separation (ForCES) |
| |
| Authors: | W. Wang, K. Ogawa, E. Haleplidis, M. Gao, J. Hadi Salim. |
| Date: | August 2013 |
| Formats: | txt html json |
| Updates: | RFC 6053 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6984 |
|
This document captures the results of the second Forwarding andControl Element Separation (ForCES) interoperability test that took place on February 24-25, 2011, in the Internet Technology Lab (ITL) at Zhejiang Gongshang University, China. The results of the firstForCES interoperability test were reported in RFC 6053, and this document updates RFC 6053 by providing further interoperability results. |
|
| |
| RFC 6985 | IMIX Genome: Specification of Variable Packet Sizes for Additional Testing |
| |
| Authors: | A. Morton. |
| Date: | July 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6985 |
|
Benchmarking methodologies have always relied on test conditions with constant packet sizes, with the goal of understanding what network device capability has been tested. Tests with a constant packet size reveal device capabilities but differ significantly from the conditions encountered in operational deployment, so additional tests are sometimes conducted with a mixture of packet sizes, or "IMIX"("Internet Mix"). The mixture of sizes a networking device will encounter is highly variable and depends on many factors. An IMIX suited for one networking device and deployment will not be appropriate for another. However, the mix of sizes may be known, and the tester may be asked to augment the fixed-size tests. To address this need and the perpetual goal of specifying repeatable test conditions, this document defines a way to specify the exact repeating sequence of packet sizes from the usual set of fixed sizes and from other forms of mixed-size specification. |
|
| |
| RFC 6986 | GOST R 34.11-2012: Hash Function |
| |
| Authors: | V. Dolmatov, Ed., A. Degtyarev. |
| Date: | August 2013 |
| Formats: | txt json html |
| Updates: | RFC 5831 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6986 |
|
This document is intended to be a source of information about theRussian Federal standard hash function (GOST R 34.11-2012), which is one of the Russian cryptographic standard algorithms (called GOST algorithms). This document updates RFC 5831. |
|
| |
| RFC 6987 | OSPF Stub Router Advertisement |
| |
| Authors: | A. Retana, L. Nguyen, A. Zinin, R. White, D. McPherson. |
| Date: | September 2013 |
| Formats: | txt json html |
| Obsoletes: | RFC 3137 |
| Updated by: | RFC 8770 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6987 |
|
This document describes a backward-compatible technique that may be used by OSPF (Open Shortest Path First) implementations to advertise a router's unavailability to forward transit traffic or to lower the preference level for the paths through such a router.
This document obsoletes RFC 3137. |
|
| |
| RFC 6988 | Requirements for Energy Management |
| |
| Authors: | J. Quittek, Ed., M. Chandramouli, R. Winter, T. Dietz, B. Claise. |
| Date: | September 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6988 |
|
This document defines requirements for standards specifications forEnergy Management. The requirements defined in this document are concerned with monitoring functions as well as control functions.Monitoring functions include identifying energy-managed devices and their components, as well as monitoring their Power States, PowerInlets, Power Outlets, actual power, Power Attributes, received energy, provided energy, and contained batteries. Control functions include such functions as controlling power supply and Power State of energy-managed devices and their components.
This document does not specify the features that must be implemented by compliant implementations but rather lists features that must be supported by standards for Energy Management. |
|
| |
| RFC 6992 | Routing for IPv4-Embedded IPv6 Packets |
| |
| Authors: | D. Cheng, M. Boucadair, A. Retana. |
| Date: | July 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6992 |
|
This document describes a routing scenario where IPv4 packets are transported over an IPv6 network, based on the methods described inRFCs 6145 and 6052, along with a separate OSPFv3 routing table forIPv4-embedded IPv6 routes in the IPv6 network. |
|
| |
| RFC 6993 | Instant Messaging and Presence Purpose for the Call-Info Header Field in the Session Initiation Protocol (SIP) |
| |
| Authors: | P. Saint-Andre. |
| Date: | July 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 6993 |
|
This document defines and registers a value of "impp" ("instant messaging and presence protocol") for the "purpose" header field parameter of the Call-Info header field in the Session InitiationProtocol (SIP). |
|
| |
| RFC 7008 | A Description of the KCipher-2 Encryption Algorithm |
| |
| Authors: | S. Kiyomoto, W. Shin. |
| Date: | August 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7008 |
|
This document describes the KCipher-2 encryption algorithm.KCipher-2 is a stream cipher with a 128-bit key and a 128-bit initialization vector. Since the algorithm for KCipher-2 was published in 2007, security and efficiency have been rigorously evaluated through academic and industrial studies. As of the publication of this document, no security vulnerabilities have been found. KCipher-2 offers fast encryption and decryption by means of simple operations that enable efficient implementation. KCipher-2 has been used for industrial applications, especially for mobile health monitoring and diagnostic services in Japan. |
|
| |
| RFC 7010 | IPv6 Site Renumbering Gap Analysis |
| |
| Authors: | B. Liu, S. Jiang, B. Carpenter, S. Venaas, W. George. |
| Date: | September 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7010 |
|
This document briefly introduces the existing mechanisms that could be utilized for IPv6 site renumbering and tries to cover most of the explicit issues and requirements associated with IPv6 renumbering.The content is mainly a gap analysis that provides a basis for future works to identify and develop solutions or to stimulate such development as appropriate. The gap analysis is organized by the main steps of a renumbering process. |
|
| |
| RFC 7016 | Adobe's Secure Real-Time Media Flow Protocol |
| |
| Authors: | M. Thornburgh. |
| Date: | November 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7016 |
|
This memo describes Adobe's Secure Real-Time Media Flow Protocol(RTMFP), an endpoint-to-endpoint communication protocol designed to securely transport parallel flows of real-time video, audio, and data messages, as well as bulk data, over IP networks. RTMFP has features that make it effective for peer-to-peer (P2P) as well as client- server communications, even when Network Address Translators (NATs) are used. |
|
| |
| RFC 7017 | IMAP Access to IETF Email List Archives |
| |
| Authors: | R. Sparks. |
| Date: | August 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7017 |
|
The IETF makes heavy use of email lists to conduct its work. This often involves accessing the archived history of those email lists.Participants would like to have the ability to browse and search those archives using standard IMAP clients. This memo captures the requirements for providing a service that would allow such browsing and searching, and it is intended as input to a later activity for the design and development of such a service. |
|
| |
| RFC 7018 | Auto-Discovery VPN Problem Statement and Requirements |
| |
| Authors: | V. Manral, S. Hanna. |
| Date: | September 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7018 |
|
This document describes the problem of enabling a large number of systems to communicate directly using IPsec to protect the traffic between them. It then expands on the requirements for such a solution.
Manual configuration of all possible tunnels is too cumbersome in many such cases. In other cases, the IP addresses of endpoints change, or the endpoints may be behind NAT gateways, making static configuration impossible. The Auto-Discovery VPN solution will address these requirements. |
|
| |
| RFC 7020 | The Internet Numbers Registry System |
| |
| Authors: | R. Housley, J. Curran, G. Huston, D. Conrad. |
| Date: | August 2013 |
| Formats: | txt json html |
| Obsoletes: | RFC 2050 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7020 |
|
This document provides information about the current Internet NumbersRegistry System used in the distribution of globally unique InternetProtocol (IP) address space and autonomous system (AS) numbers.
This document also provides information about the processes for further evolution of the Internet Numbers Registry System.
This document replaces RFC 2050.
This document does not propose any changes to the current InternetNumbers Registry System. Rather, it documents the Internet NumbersRegistry System as it works today. |
|
| |
| RFC 7021 | Assessing the Impact of Carrier-Grade NAT on Network Applications |
| |
| Authors: | C. Donley, Ed., L. Howard, V. Kuarsingh, J. Berg, J. Doshi. |
| Date: | September 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7021 |
|
NAT444 is an IPv4 extension technology being considered by ServiceProviders as a means to continue offering IPv4 service to customers while transitioning to IPv6. This technology adds an extra Carrier-Grade NAT (CGN) in the Service Provider network, often resulting in two NATs. CableLabs, Time Warner Cable, and Rogers Communications independently tested the impacts of NAT444 on many popular Internet services using a variety of test scenarios, network topologies, and vendor equipment. This document identifies areas where adding a second layer of NAT disrupts the communication channel for commonInternet applications. This document was updated to include theDual-Stack Lite (DS-Lite) impacts also. |
|
| |
| RFC 7025 | Requirements for GMPLS Applications of PCE |
| |
| Authors: | T. Otani, K. Ogaki, D. Caviglia, F. Zhang, C. Margaria. |
| Date: | September 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7025 |
|
The initial effort of the PCE (Path Computation Element) WG focused mainly on MPLS. As a next step, this document describes functional requirements for GMPLS applications of PCE. |
|
| |
| RFC 7027 | Elliptic Curve Cryptography (ECC) Brainpool Curves for Transport Layer Security (TLS) |
| |
|
|
This document specifies the use of several Elliptic CurveCryptography (ECC) Brainpool curves for authentication and key exchange in the Transport Layer Security (TLS) protocol. |
|
| |
| RFC 7029 | Extensible Authentication Protocol (EAP) Mutual Cryptographic Binding |
| |
| Authors: | S. Hartman, M. Wasserman, D. Zhang. |
| Date: | October 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7029 |
|
As the Extensible Authentication Protocol (EAP) evolves, EAP peers rely increasingly on information received from the EAP server. EAP extensions such as channel binding or network posture information are often carried in tunnel methods; peers are likely to rely on this information. Cryptographic binding is a facility described in RFC3748 that protects tunnel methods against man-in-the-middle attacks.However, cryptographic binding focuses on protecting the server rather than the peer. This memo explores attacks possible when the peer is not protected from man-in-the-middle attacks and recommends cryptographic binding based on an Extended Master Session Key, a new form of cryptographic binding that protects both peer and server along with other mitigations. |
|
| |
| RFC 7031 | DHCPv6 Failover Requirements |
| |
| Authors: | T. Mrugalski, K. Kinnear. |
| Date: | September 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7031 |
|
The DHCPv6 protocol, defined in RFC 3315, allows for multiple servers to operate on a single network; however, it does not define any way the servers could share information about currently active clients and their leases. Some sites are interested in running multiple servers in such a way as to provide increased availability in case of server failure. In order for this to work reliably, the cooperating primary and secondary servers must maintain a consistent database of the lease information. RFC 3315 allows for, but does not define, any redundancy or failover mechanisms. This document outlines requirements for DHCPv6 failover, enumerates related problems, and discusses the proposed scope of work to be conducted. This document does not define a DHCPv6 failover protocol. |
|
| |
| RFC 7034 | HTTP Header Field X-Frame-Options |
| |
| Authors: | D. Ross, T. Gondrom. |
| Date: | October 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7034 |
|
To improve the protection of web applications against clickjacking, this document describes the X-Frame-Options HTTP header field, which declares a policy, communicated from the server to the client browser, regarding whether the browser may display the transmitted content in frames that are part of other web pages. |
|
| |
| RFC 7036 | Object Identifier Registry for the Long-Term Archive and Notary Services (LTANS) Working Group |
| |
| Authors: | R. Housley. |
| Date: | October 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7036 |
|
When the Long-Term Archive and Notary Services (LTANS) working group was chartered, an object identifier arc was set aside for use by that working group. This document describes the object identifiers that were assigned, and it establishes IANA allocation policies for any future assignments within that arc. |
|
| |
| RFC 7039 | Source Address Validation Improvement (SAVI) Framework |
| |
| Authors: | J. Wu, J. Bi, M. Bagnulo, F. Baker, C. Vogt, Ed.. |
| Date: | October 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7039 |
|
Source Address Validation Improvement (SAVI) methods were developed to prevent nodes attached to the same IP link from spoofing each other's IP addresses, so as to complement ingress filtering with finer-grained, standardized IP source address validation. This document is a framework document that describes and motivates the design of the SAVI methods. Particular SAVI methods are described in other documents. |
|
| |
| RFC 7040 | Public IPv4-over-IPv6 Access Network |
| |
| Authors: | Y. Cui, J. Wu, P. Wu, O. Vautrin, Y. Lee. |
| Date: | November 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7040 |
|
This document describes a mechanism called Public 4over6, which is designed to provide IPv4 Internet connectivity over an IPv6 access network using global IPv4 addresses. Public 4over6 was developed in the IETF and is in use in some existing deployments but is not recommended for new deployments. Future deployments of similar scenarios should use Lightweight 4over6. Public 4over6 follows theHub and Spoke softwire model and uses an IPv4-in-IPv6 tunnel to forward IPv4 packets over an IPv6 access network. The bidirectionality of the IPv4 communication is achieved by explicitly allocating global non-shared IPv4 addresses to end users and by maintaining IPv4-IPv6 address binding on the border relay. Public4over6 aims to provide uninterrupted IPv4 services to users, likeInternet Content Providers (ICPs), etc., while an operator makes the access network transition to an IPv6-only access network. |
|
| |
| RFC 7041 | Extensions to the Virtual Private LAN Service (VPLS) Provider Edge (PE) Model for Provider Backbone Bridging |
| |
| Authors: | F. Balus, Ed., A. Sajassi, Ed., N. Bitar, Ed.. |
| Date: | November 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7041 |
|
The IEEE 802.1 Provider Backbone Bridges (PBBs) specification defines an architecture and bridge protocols for interconnection of multipleProvider Bridged Networks (PBNs). Provider backbone bridging was defined by IEEE as a connectionless technology based on multipointVLAN tunnels. PBB can be used to attain better scalability thanProvider Bridges (PBs) in terms of the number of customer MediaAccess Control addresses and the number of service instances that can be supported.
The Virtual Private LAN Service (VPLS) provides a framework for extending Ethernet LAN services, using MPLS tunneling capabilities, through a routed MPLS backbone without running the Rapid SpanningTree Protocol (RSTP) or the Multiple Spanning Tree Protocol (MSTP) across the backbone. As a result, VPLS has been deployed on a large scale in service provider networks.
This document discusses extensions to the VPLS Provider Edge (PE) model required to incorporate desirable PBB components while maintaining the service provider fit of the initial model. |
|
| |
| RFC 7043 | Resource Records for EUI-48 and EUI-64 Addresses in the DNS |
| |
| Authors: | J. Abley. |
| Date: | October 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7043 |
|
48-bit Extended Unique Identifier (EUI-48) and 64-bit Extended UniqueIdentifier (EUI-64) are address formats specified by the IEEE for use in various layer-2 networks, e.g., Ethernet.
This document describes two new DNS resource record types, EUI48 andEUI64, for encoding Ethernet addresses in the DNS.
This document describes potentially severe privacy implications resulting from indiscriminate publication of link-layer addresses in the DNS. EUI-48 or EUI-64 addresses SHOULD NOT be published in the public DNS. This document specifies an interoperable encoding of these address types for use in private DNS namespaces, where the privacy concerns can be constrained and mitigated. |
|
| |
| RFC 7047 | The Open vSwitch Database Management Protocol |
| |
| Authors: | B. Pfaff, B. Davie, Ed.. |
| Date: | December 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7047 |
|
Open vSwitch is an open-source software switch designed to be used as a vswitch (virtual switch) in virtualized server environments. A vswitch forwards traffic between different virtual machines (VMs) on the same physical host and also forwards traffic between VMs and the physical network. Open vSwitch is open to programmatic extension and control using OpenFlow and the OVSDB (Open vSwitch Database) management protocol. This document defines the OVSDB management protocol. The Open vSwitch project includes open-source OVSDB client and server implementations. |
|
| |
| RFC 7051 | Analysis of Solution Proposals for Hosts to Learn NAT64 Prefix |
| |
| Authors: | J. Korhonen, Ed., T. Savolainen, Ed.. |
| Date: | November 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7051 |
|
Hosts and applications may benefit from learning if an IPv6 address is synthesized and if NAT64 and DNS64 are present in a network. This document analyzes all proposed solutions (known at the time of writing) for communicating whether the synthesis is taking place, what address format was used, and what IPv6 prefix was used by theNAT64 and DNS64. These solutions enable both NAT64 avoidance and local IPv6 address synthesis. The document concludes by recommending the standardization of the approach based on heuristic discovery. |
|
| |
| RFC 7054 | Addressing Requirements and Design Considerations for Per-Interface Maintenance Entity Group Intermediate Points (MIPs) |
| |
| Authors: | A. Farrel, H. Endo, R. Winter, Y. Koike, M. Paul. |
| Date: | November 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7054 |
|
The framework for Operations, Administration and Maintenance (OAM) within the MPLS Transport Profile (MPLS-TP) describes how theMaintenance Entity Group Intermediate Points (MIPs) may be situated within network nodes at incoming and outgoing interfaces.
This document elaborates on important considerations for internal MIP addressing. More precisely, it describes important restrictions for any mechanism that specifies a way of forming OAM messages so that they can be targeted at MIPs on either incoming or outgoing interfaces and forwarded correctly through the forwarding engine.Furthermore, the document includes considerations for node implementations where there is no distinction between the incoming and outgoing MIP. |
|
| |
| RFC 7058 | Media Control Channel Framework (CFW) Call Flow Examples |
| |
| Authors: | A. Amirante, T. Castaldi, L. Miniero, S P. Romano. |
| Date: | November 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7058 |
|
This document provides a list of typical Media Control ChannelFramework call flows. It aims at being a simple guide to the use of the interface between Application Servers and MEDIACTRL-based MediaServers, as well as a base reference document for both implementors and protocol researchers. |
|
| |
| RFC 7059 | A Comparison of IPv6-over-IPv4 Tunnel Mechanisms |
| |
| Authors: | S. Steffann, I. van Beijnum, R. van Rein. |
| Date: | November 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7059 |
|
This document provides an overview of various ways to tunnel IPv6 packets over IPv4 networks. It covers mechanisms in current use, touches on several mechanisms that are now only of historic interest, and discusses some newer tunnel mechanisms that are not widely used at the time of publication. The goal of the document is helping people with an IPv6-in-IPv4 tunneling need to select the mechanisms that may apply to them. |
|
| |
| RFC 7061 | eXtensible Access Control Markup Language (XACML) XML Media Type |
| |
| Authors: | R. Sinnema, E. Wilde. |
| Date: | November 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7061 |
|
This specification registers an XML-based media type for the eXtensible Access Control Markup Language (XACML). |
|
| |
| RFC 7062 | Framework for GMPLS and PCE Control of G.709 Optical Transport Networks |
| |
| Authors: | F. Zhang, Ed., D. Li, H. Li, S. Belotti, D. Ceccarelli. |
| Date: | November 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7062 |
|
This document provides a framework to allow the development of protocol extensions to support Generalized Multi-Protocol LabelSwitching (GMPLS) and Path Computation Element (PCE) control ofOptical Transport Networks (OTNs) as specified in ITU-TRecommendation G.709 as published in 2012. |
|
| |
| RFC 7063 | Survey Report on Protocol Independent Multicast - Sparse Mode (PIM-SM) Implementations and Deployments |
| |
| Authors: | L. Zheng, J. Zhang, R. Parekh. |
| Date: | December 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7063 |
|
This document provides supporting documentation to advance the IETF stream's Protocol Independent Multicast - Sparse Mode (PIM-SM) protocol from Proposed Standard to Internet Standard. |
|
| |
| RFC 7066 | IPv6 for Third Generation Partnership Project (3GPP) Cellular Hosts |
| |
| Authors: | J. Korhonen, Ed., J. Arkko, Ed., T. Savolainen, S. Krishnan. |
| Date: | November 2013 |
| Formats: | txt json html |
| Obsoletes: | RFC 3316 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7066 |
|
As the deployment of third and fourth generation cellular networks progresses, a large number of cellular hosts are being connected to the Internet. Standardization organizations have made the InternetProtocol version 6 (IPv6) mandatory in their specifications.However, the concept of IPv6 covers many aspects and numerous specifications. In addition, the characteristics of cellular links in terms of bandwidth, cost, and delay put special requirements on how IPv6 is used. This document considers IPv6 for cellular hosts that attach to the General Packet Radio Service (GPRS), UniversalMobile Telecommunications System (UMTS), or Evolved Packet System(EPS) networks (hereafter collectively referred to as ThirdGeneration Partnership Project (3GPP) networks). This document also lists specific IPv6 functionalities that need to be implemented in addition to what is already prescribed in the IPv6 Node Requirements document (RFC 6434). It also discusses some issues related to the use of these components when operating in these networks. This document obsoletes RFC 3316. |
|
| |
| RFC 7067 | Directory Assistance Problem and High-Level Design Proposal |
| |
| Authors: | L. Dunbar, D. Eastlake 3rd, R. Perlman, I. Gashinsky. |
| Date: | November 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7067 |
|
Edge TRILL (Transparent Interconnection of Lots of Links) switches currently learn the mapping between MAC (Media Access Control) addresses and their egress TRILL switch by observing the data packets they ingress or egress or by the TRILL ESADI (End-Station AddressDistribution Information) protocol. When an ingress TRILL switch receives a data frame for a destination address (MAC&Label) that the switch does not know, the data frame is flooded within the frame'sData Label across the TRILL campus.
This document describes the framework for using directory services to assist edge TRILL switches in reducing multi-destination frames, particularly unknown unicast frames flooding, and ARP/ND (AddressResolution Protocol / Neighbor Discovery), thus improving TRILL network scalability and security. |
|
| |
| RFC 7068 | Diameter Overload Control Requirements |
| |
| Authors: | E. McMurry, B. Campbell. |
| Date: | November 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7068 |
|
When a Diameter server or agent becomes overloaded, it needs to be able to gracefully reduce its load, typically by advising clients to reduce traffic for some period of time. Otherwise, it must continue to expend resources parsing and responding to Diameter messages, possibly resulting in a progressively severe overload condition. The existing Diameter mechanisms are not sufficient for managing overload conditions. This document describes the limitations of the existing mechanisms. Requirements for new overload management mechanisms are also provided. |
|
| |
| RFC 7069 | DECoupled Application Data Enroute (DECADE) |
| |
| Authors: | R. Alimi, A. Rahman, D. Kutscher, Y. Yang, H. Song, K. Pentikousis. |
| Date: | November 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7069 |
|
Content distribution applications, such as those employing peer-to- peer (P2P) technologies, are widely used on the Internet and make up a large portion of the traffic in many networks. Often, however, content distribution applications use network resources inefficiently. One way to improve efficiency is to introduce storage capabilities within the network and enable cooperation between end- host and in-network content distribution mechanisms. This is the capability provided by a DECoupled Application Data Enroute (DECADE) system, which is introduced in this document. DECADE enables applications to take advantage of in-network storage when distributing data objects as opposed to using solely end-to-end resources. This document presents the underlying principles and key functionalities of such a system and illustrates operation through a set of examples. |
|
| |
| RFC 7076 | P6R's Secure Shell Public Key Subsystem |
| |
| Authors: | M. Joseph, J. Susoy. |
| Date: | November 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7076 |
|
The Secure Shell (SSH) Public Key Subsystem protocol defines a key distribution protocol that is limited to provisioning an SSH server with a user's public keys. This document describes a new protocol that builds on the protocol defined in RFC 4819 to allow the provisioning of keys and certificates to a server using the SSH transport.
The new protocol allows the calling client to organize keys and certificates in different namespaces on a server. These namespaces can be used by the server to allow a client to configure any application running on the server (e.g., SSH, Key ManagementInteroperability Protocol (KMIP), Simple Network Management Protocol(SNMP)).
The new protocol provides a server-independent mechanism for clients to add public keys, remove public keys, add certificates, remove certificates, and list the current set of keys and certificates known by the server by namespace (e.g., list all public keys in the SSH namespace).
Rights to manage keys and certificates in a particular namespace are specific and limited to the authorized user and are defined as part of the server's implementation. The described protocol is backward compatible to version 2 defined by RFC 4819. |
|
| |
| RFC 7079 | The Pseudowire (PW) and Virtual Circuit Connectivity Verification (VCCV) Implementation Survey Results |
| |
| Authors: | N. Del Regno, Ed., A. Malis, Ed.. |
| Date: | November 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7079 |
|
The IETF Pseudowire Emulation Edge-to-Edge (PWE3) working group has defined many encapsulations of various layer 1 and layer 2 service- specific PDUs and circuit data. In most of these encapsulations, use of the Pseudowire (PW) Control Word is required. However, there are several encapsulations for which the Control Word is optional, and this optionality has been seen in practice to possibly introduce interoperability concerns between multiple implementations of those encapsulations. This survey of the Pseudowire / Virtual CircuitConnectivity Verification (VCCV) user community was conducted to determine implementation trends and the possibility of always mandating the Control Word. |
|
| |
| RFC 7080 | Virtual Private LAN Service (VPLS) Interoperability with Provider Backbone Bridges |
| |
| Authors: | A. Sajassi, S. Salam, N. Bitar, F. Balus. |
| Date: | December 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7080 |
|
The scalability of Hierarchical Virtual Private LAN Service (H-VPLS) with Ethernet access networks (RFC 4762) can be improved by incorporating Provider Backbone Bridge functionality in the VPLS access. Provider Backbone Bridging has been standardized as IEEE802.1ah-2008. It aims to improve the scalability of Media AccessControl (MAC) addresses and service instances in Provider Ethernet networks. This document describes different interoperability scenarios where Provider Backbone Bridge functionality is used inH-VPLS with Ethernet or MPLS access network to attain better scalability in terms of number of customer MAC addresses and number of service instances. The document also describes the scenarios and the mechanisms for incorporating Provider Backbone Bridge functionality within H-VPLS with existing Ethernet access and interoperability among them. Furthermore, the document discusses the migration mechanisms and scenarios by which Provider Backbone Bridge functionality can be incorporated into H-VPLS with existing MPLS access. |
|
| |
| RFC 7081 | CUSAX: Combined Use of the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP) |
| |
| Authors: | E. Ivov, P. Saint-Andre, E. Marocco. |
| Date: | November 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7081 |
|
This document suggests some strategies for the combined use of theSession Initiation Protocol (SIP) and the Extensible Messaging andPresence Protocol (XMPP) both in user-oriented clients and in deployed servers. Such strategies, which mainly consist of configuration changes and minimal software modifications to existing clients and servers, aim to provide a single, full-featured, real- time communication service by using complementary subsets of features from SIP and from XMPP. Typically, such subsets consist of telephony capabilities from SIP and instant messaging and presence capabilities from XMPP. This document does not define any new protocols or syntax for either SIP or XMPP and, by intent, does not attempt to standardize "best current practices". Instead, it merely aims to provide practical guidance to those who are interested in the combined use of SIP and XMPP for real-time communication. |
|
| |
| RFC 7082 | Indication of Conference Focus Support for the Centralized Conferencing Manipulation Protocol (CCMP) |
| |
| Authors: | R. Shekh-Yusef, M. Barnes. |
| Date: | December 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7082 |
|
The Centralized Conferencing Manipulation Protocol (CCMP) document(RFC 6503) defines a way for a client to discover a conference control server that supports CCMP. However, it does not define a way for a client involved in a conference to determine if the conference focus supports CCMP. This information would allow a CCMP-enabled client that joins a conference using SIP to also register for theCentralized Conferencing (XCON) conference event package and take advantage of CCMP operations on the conference.
This document describes two mechanisms, depending upon the need of the User Agent (UA), to address the above limitation. The first mechanism uses the Call-Info header field, and the second mechanism defines a new value for the "purpose" header field parameter in the<service-uris&rt; element in the SIP conferencing event package. |
|
| |
| RFC 7084 | Basic Requirements for IPv6 Customer Edge Routers |
| |
|
|
This document specifies requirements for an IPv6 Customer Edge (CE) router. Specifically, the current version of this document focuses on the basic provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attached to it. The document also covers IP transition technologies. Two transition technologies in RFC 5969's IPv6 RapidDeployment on IPv4 Infrastructures (6rd) and RFC 6333's Dual-StackLite (DS-Lite) are covered in the document. The document obsoletesRFC 6204. |
|
| |
| RFC 7085 | Top-Level Domains That Are Already Dotless |
| |
| Authors: | J. Levine, P. Hoffman. |
| Date: | December 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7085 |
|
Recent statements from the Internet Architecture Board (IAB) and theInternet Corporation of Assigned Names and Numbers (ICANN) Security and Stability Advisory Committee have focused on the problems that the DNS is likely to experience with top-level domains (TLDs) that contain address records (so-called "dotless domains"). In order to help researchers determine the extent of the issues with dotless domains, this document lists the current dotless TLDs and gives a script for finding them. This document lists data about dotless TLDs but does not address the policy and technology issues other than to point to the statements of others. |
|
| |
| RFC 7087 | A Thesaurus for the Interpretation of Terminology Used in MPLS Transport Profile (MPLS-TP) Internet-Drafts and RFCs in the Context of the ITU-T's Transport Network Recommendations |
| |
| Authors: | H. van Helvoort, Ed., L. Andersson, Ed., N. Sprecher, Ed.. |
| Date: | December 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7087 |
|
The MPLS Transport Profile (MPLS-TP) is based on a profile of theMPLS and Pseudowire (PW) procedures as specified in the MPLS TrafficEngineering (MPLS-TE), PW, and Multi-Segment Pseudowire (MS-PW) architectures developed by the Internet Engineering Task Force(IETF). The International Telecommunication Union TelecommunicationStandardization Sector (ITU-T) has specified a Transport Network architecture.
This document provides a thesaurus for the interpretation of MPLS-TP terminology within the context of the ITU-T Transport NetworkRecommendations.
It is important to note that MPLS-TP is applicable in a wider set of contexts than just Transport Networks. The definitions presented in this document do not provide exclusive or complete interpretations ofMPLS-TP concepts. This document simply allows the MPLS-TP terms to be applied within the Transport Network context. |
|
| |
| RFC 7088 | Session Initiation Protocol Service Example -- Music on Hold |
| |
| Authors: | D. Worley. |
| Date: | February 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7088 |
|
"Music on hold" is one of the features of telephone systems that is most desired by buyers of business telephone systems. Music on hold means that when one party to a call has the call "on hold", that party's telephone provides an audio stream (often music) to be heard by the other party. Architectural features of SIP make it difficult to implement music on hold in a way that is fully standards- compliant. The implementation of music on hold described in this document is fully effective, is standards-compliant, and has a number of advantages over the methods previously documented. In particular, it is less likely to produce peculiar user interface effects and more likely to work in systems that perform authentication than the music- on-hold method described in Section 2.3 of RFC 5359. |
|
| |
| RFC 7089 | HTTP Framework for Time-Based Access to Resource States -- Memento |
| |
| Authors: | H. Van de Sompel, M. Nelson, R. Sanderson. |
| Date: | December 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7089 |
|
The HTTP-based Memento framework bridges the present and past Web.It facilitates obtaining representations of prior states of a given resource by introducing datetime negotiation and TimeMaps. Datetime negotiation is a variation on content negotiation that leverages the given resource's URI and a user agent's preferred datetime. TimeMaps are lists that enumerate URIs of resources that encapsulate prior states of the given resource. The framework also facilitates recognizing a resource that encapsulates a frozen prior state of another resource. |
|
| |
| RFC 7091 | GOST R 34.10-2012: Digital Signature Algorithm |
| |
| Authors: | V. Dolmatov, Ed., A. Degtyarev. |
| Date: | December 2013 |
| Formats: | txt html json |
| Updates: | RFC 5832 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7091 |
|
This document provides information about the Russian Federal standard for digital signatures (GOST R 34.10-2012), which is one of theRussian cryptographic standard algorithms (called GOST algorithms).Recently, Russian cryptography is being used in Internet applications, and this document provides information for developers and users of GOST R 34.10-2012 regarding digital signature generation and verification. This document updates RFC 5832. |
|
| |
| RFC 7092 | A Taxonomy of Session Initiation Protocol (SIP) Back-to-Back User Agents |
| |
| Authors: | H. Kaplan, V. Pascual. |
| Date: | December 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7092 |
|
In many SIP deployments, SIP entities exist in the SIP signaling path between the originating and final terminating endpoints, which go beyond the definition of a SIP proxy, performing functions not defined in Standards Track RFCs. The only term for such devices provided in RFC 3261 is for a Back-to-Back User Agent (B2BUA), which is defined as the logical concatenation of a SIP User Agent Server(UAS) and User Agent Client (UAC).
There are numerous types of SIP B2BUAs performing different roles in different ways; for example, IP Private Branch Exchanges (IPBXs),Session Border Controllers (SBCs), and Application Servers (ASs).This document identifies several common B2BUA roles in order to provide taxonomy other documents can use and reference. |
|
| |
| RFC 7093 | Additional Methods for Generating Key Identifiers Values |
| |
| Authors: | S. Turner, S. Kent, J. Manger. |
| Date: | December 2013 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7093 |
|
This document specifies additional example methods for generating KeyIdentifier values for use in the AKI (Authority Key Identifier) andSKI (Subject Key Identifier) certificate extensions. |
|
| |
| RFC 7094 | Architectural Considerations of IP Anycast |
| |
| Authors: | D. McPherson, D. Oran, D. Thaler, E. Osterweil. |
| Date: | January 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7094 |
|
This memo discusses architectural implications of IP anycast and provides some historical analysis of anycast use by various IETF protocols. |
|
| |
| RFC 7096 | Evaluation of Existing GMPLS Encoding against G.709v3 Optical Transport Networks (OTNs) |
| |
| Authors: | S. Belotti, Ed., P. Grandi, D. Ceccarelli, Ed., D. Caviglia, F. Zhang, D. Li. |
| Date: | January 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7096 |
|
ITU-T recommendation G.709-2012 has introduced new fixed and flexibleOptical channel Data Unit (ODU) containers in Optical TransportNetworks (OTNs).
This document provides an evaluation of existing GeneralizedMultiprotocol Label Switching (GMPLS) routing and signaling protocols against the G.709 OTNs. |
|
| |
| RFC 7098 | Using the IPv6 Flow Label for Load Balancing in Server Farms |
| |
| Authors: | B. Carpenter, S. Jiang, W. Tarreau. |
| Date: | January 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7098 |
|
This document describes how the currently specified IPv6 flow label can be used to enhance layer 3/4 (L3/4) load distribution and balancing for large server farms. |
|
| |
| RFC 7101 | List of Internet Official Protocol Standards: Replaced by a Web Page |
| |
| Authors: | S. Ginoza. |
| Date: | December 2013 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7101 |
|
At one time, the RFC Editor published snapshots of the "InternetOfficial Protocol Standards". These documents were known as xx00 documents, the last of which was published in May 2008. These snapshots have been replaced by a web page, so the RFC Editor will no longer be publishing these snapshots as RFCs. As a result, the RFCEditor will classify unpublished RFC xx00 numbers through 7000 as never issued. Starting with the RFC number 7100, xx00 numbers will be available for assignment. |
|
| |
| RFC 7102 | Terms Used in Routing for Low-Power and Lossy Networks |
| |
| Authors: | JP. Vasseur. |
| Date: | January 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7102 |
|
This document provides a glossary of terminology used in routing requirements and solutions for networks referred to as Low-Power andLossy Networks (LLNs). An LLN is typically composed of many embedded devices with limited power, memory, and processing resources interconnected by a variety of links. There is a wide scope of application areas for LLNs, including industrial monitoring, building automation (e.g., heating, ventilation, air conditioning, lighting, access control, fire), connected home, health care, environmental monitoring, urban sensor networks, energy management, assets tracking, and refrigeration. |
|
| |
| RFC 7103 | Advice for Safe Handling of Malformed Messages |
| |
| Authors: | M. Kucherawy, G. Shapiro, N. Freed. |
| Date: | January 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7103 |
|
Although Internet message formats have been precisely defined since the 1970s, authoring and handling software often shows only mild conformance to the specifications. The malformed messages that result are non-standard. Nonetheless, decades of experience have shown that using some tolerance in the handling of the malformations that result is often an acceptable approach and is better than rejecting the messages outright as nonconformant. This document includes a collection of the best advice available regarding a variety of common malformed mail situations; it is to be used as implementation guidance. |
|
| |
| RFC 7106 | A Group Text Chat Purpose for Conference and Service URIs in the SIP Event Package for Conference State |
| |
| Authors: | E. Ivov. |
| Date: | January 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7106 |
|
This document defines and registers a value of "grouptextchat"("Group Text Chat") for the URI <purpose&rt; element of SIP's ConferenceEvent Package. |
|
| |
| RFC 7107 | Object Identifier Registry for the S/MIME Mail Security Working Group |
| |
| Authors: | R. Housley. |
| Date: | January 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7107 |
|
When the S/MIME Mail Security Working Group was chartered, an object identifier arc was donated by RSA Data Security for use by that working group. This document describes the object identifiers that were assigned in that donated arc, transfers control of that arc toIANA, and establishes IANA allocation policies for any future assignments within that arc. |
|
| |
| RFC 7108 | A Summary of Various Mechanisms Deployed at L-Root for the Identification of Anycast Nodes |
| |
| Authors: | J. Abley, T. Manderson. |
| Date: | January 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7108 |
|
Anycast is a deployment technique commonly employed for authoritative-only servers in the Domain Name System (DNS). L-Root, one of the thirteen root servers, is deployed in this fashion.
Various techniques have been used to map deployed anycast infrastructure externally, i.e., without reference to inside knowledge about where and how such infrastructure has been deployed.Motivations for performing such measurement exercises include operational troubleshooting and infrastructure risk assessment. In the specific case of L-Root, the ability to measure and map anycast infrastructure using the techniques mentioned in this document is provided for reasons of operational transparency.
This document describes all facilities deployed at L-Root to facilitate mapping of its infrastructure and serves as documentation for L-Root as a measurable service. |
|
| |
| RFC 7111 | URI Fragment Identifiers for the text/csv Media Type |
| |
| Authors: | M. Hausenblas, E. Wilde, J. Tennison. |
| Date: | January 2014 |
| Formats: | txt html json |
| Updates: | RFC 4180 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7111 |
|
This memo defines URI fragment identifiers for text/csv MIME entities. These fragment identifiers make it possible to refer to parts of a text/csv MIME entity identified by row, column, or cell.Fragment identification can use single items or ranges. |
|
| |
| RFC 7113 | Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard) |
| |
|
|
The IPv6 Router Advertisement Guard (RA-Guard) mechanism is commonly employed to mitigate attack vectors based on forged ICMPv6 RouterAdvertisement messages. Many existing IPv6 deployments rely onRA-Guard as the first line of defense against the aforementioned attack vectors. However, some implementations of RA-Guard have been found to be prone to circumvention by employing IPv6 ExtensionHeaders. This document describes the evasion techniques that affect the aforementioned implementations and formally updates RFC 6105, such that the aforementioned RA-Guard evasion vectors are eliminated. |
|
| |
| RFC 7116 | Licklider Transmission Protocol (LTP), Compressed Bundle Header Encoding (CBHE), and Bundle Protocol IANA Registries |
| |
| Authors: | K. Scott, M. Blanchet. |
| Date: | February 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7116 |
|
The DTNRG Research Group has defined the experimental LickliderTransmission Protocol (LTP) and the Compressed Bundle Header Encoding(CBHE) mechanism for the InterPlanetary Network ('ipn' URI scheme).Moreover, RFC 5050 defines values for the Bundle Protocol administrative record type. All of these fields are subject to a registry. For the purpose of its research work, the group has created ad hoc registries. As the specifications are stable and have multiple interoperable implementations, the group would like to hand off the registries to IANA for official management. This document describes the necessary IANA actions. |
|
| |
| RFC 7123 | Security Implications of IPv6 on IPv4 Networks |
| |
| Authors: | F. Gont, W. Liu. |
| Date: | February 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7123 |
|
This document discusses the security implications of native IPv6 support and IPv6 transition/coexistence technologies on "IPv4-only" networks and describes possible mitigations for the aforementioned issues. |
|
| |
| RFC 7125 | Revision of the tcpControlBits IP Flow Information Export (IPFIX) Information Element |
| |
| Authors: | B. Trammell, P. Aitken. |
| Date: | February 2014 |
| Formats: | txt html json |
| Obsoleted by: | RFC 9565 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7125 |
|
This document revises the tcpControlBits IP Flow Information Export(IPFIX) Information Element as originally defined in RFC 5102 to reflect changes to the TCP Flags header field since RFC 793. |
|
| |
| RFC 7128 | Resource Public Key Infrastructure (RPKI) Router Implementation Report |
| |
| Authors: | R. Bush, R. Austein, K. Patel, H. Gredler, M. Waehlisch. |
| Date: | February 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7128 |
|
This document is an implementation report for the Resource Public KeyInfrastructure (RPKI) Router protocol as defined in RFC 6810. The authors did not verify the accuracy of the information provided by respondents. The respondents are experts with the implementations they reported on, and their responses are considered authoritative for the implementations for which their responses represent. The respondents were asked to only use the "YES" answer if the feature had at least been tested in the lab. |
|
| |
| RFC 7129 | Authenticated Denial of Existence in the DNS |
| |
| Authors: | R. Gieben, W. Mekking. |
| Date: | February 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7129 |
|
Authenticated denial of existence allows a resolver to validate that a certain domain name does not exist. It is also used to signal that a domain name exists but does not have the specific resource record(RR) type you were asking for. When returning a negative DNSSecurity Extensions (DNSSEC) response, a name server usually includes up to two NSEC records. With NSEC version 3 (NSEC3), this amount is three.
This document provides additional background commentary and some context for the NSEC and NSEC3 mechanisms used by DNSSEC to provide authenticated denial-of-existence responses. |
|
| |
| RFC 7131 | Session Initiation Protocol (SIP) History-Info Header Call Flow Examples |
| |
| Authors: | M. Barnes, F. Audet, S. Schubert, H. van Elburg, C. Holmberg. |
| Date: | March 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7131 |
|
This document describes use cases and documents call flows that require the History-Info header field to capture the Request-URIs as a Session Initiation Protocol (SIP) Request is retargeted. The use cases are described along with the corresponding call flow diagrams and messaging details. |
|
| |
| RFC 7132 | Threat Model for BGP Path Security |
| |
| Authors: | S. Kent, A. Chi. |
| Date: | February 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7132 |
|
This document describes a threat model for the context in whichExternal Border Gateway Protocol (EBGP) path security mechanisms will be developed. The threat model includes an analysis of the ResourcePublic Key Infrastructure (RPKI) and focuses on the ability of anAutonomous System (AS) to verify the authenticity of the AS path info received in a BGP update. We use the term "PATHSEC" to refer to anyBGP path security technology that makes use of the RPKI. PATHSEC will secure BGP, consistent with the inter-AS security focus of theRPKI.
The document characterizes classes of potential adversaries that are considered to be threats and examines classes of attacks that might be launched against PATHSEC. It does not revisit attacks against unprotected BGP, as that topic has already been addressed in theBGP-4 standard. It concludes with a brief discussion of residual vulnerabilities. |
|
| |
| RFC 7135 | Registering a SIP Resource Priority Header Field Namespace for Local Emergency Communications |
| |
| Authors: | J. Polk. |
| Date: | May 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7135 |
|
This document creates the new Session Initiation Protocol (SIP)Resource Priority header field namespace 'esnet' and registers this namespace with IANA. The new header field namespace allows for local emergency session establishment to a public safety answering point(PSAP), between PSAPs, and between a PSAP and first responders and their organizations. |
|
| |
| RFC 7142 | Reclassification of RFC 1142 to Historic |
| |
|
|
This memo reclassifies RFC 1142, "OSI IS-IS Intra-domain RoutingProtocol", to Historic status. This memo also obsoletes RFC 1142. |
|
| |
| RFC 7149 | Software-Defined Networking: A Perspective from within a Service Provider Environment |
| |
| Authors: | M. Boucadair, C. Jacquenet. |
| Date: | March 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7149 |
|
Software-Defined Networking (SDN) has been one of the major buzz words of the networking industry for the past couple of years. And yet, no clear definition of what SDN actually covers has been broadly admitted so far. This document aims to clarify the SDN landscape by providing a perspective on requirements, issues, and other considerations about SDN, as seen from within a service provider environment.
It is not meant to endlessly discuss what SDN truly means but rather to suggest a functional taxonomy of the techniques that can be used under an SDN umbrella and to elaborate on the various pending issues the combined activation of such techniques inevitably raises. As such, a definition of SDN is only mentioned for the sake of clarification. |
|
| |
| RFC 7152 | Requirements for Metro Ethernet Forum (MEF) Ethernet-Tree (E-Tree) Support in Layer 2 Virtual Private Network (L2VPN) |
| |
| Authors: | R. Key, Ed., S. DeLord, F. Jounay, L. Huang, Z. Liu, M. Paul. |
| Date: | March 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7152 |
|
This document provides functional requirements for the support ofMetro Ethernet Forum (MEF) Ethernet Tree (E-Tree) in multipoint Layer2 Virtual Private Network solutions (referred to as simply "L2VPN").It is intended that potential solutions will use these requirements as guidelines. |
|
| |
| RFC 7157 | IPv6 Multihoming without Network Address Translation |
| |
| Authors: | O. Troan, Ed., D. Miles, S. Matsushima, T. Okimoto, D. Wing. |
| Date: | March 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7157 |
|
Network Address and Port Translation (NAPT) works well for conserving global addresses and addressing multihoming requirements because anIPv4 NAPT router implements three functions: source address selection, next-hop resolution, and (optionally) DNS resolution. ForIPv6 hosts, one approach could be the use of IPv6-to-IPv6 NetworkPrefix Translation (NPTv6). However, NAT and NPTv6 should be avoided, if at all possible, to permit transparent end-to-end connectivity. In this document, we analyze the use cases of multihoming. We also describe functional requirements and possible solutions for multihoming without the use of NAT in IPv6 for hosts and small IPv6 networks that would otherwise be unable to meet minimum IPv6-allocation criteria. We conclude that DHCPv6-based solutions are suitable to solve the multihoming issues described in this document, but NPTv6 may be required as an intermediate solution. |
|
| |
| RFC 7165 | Use Cases and Requirements for JSON Object Signing and Encryption (JOSE) |
| |
| Authors: | R. Barnes. |
| Date: | April 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7165 |
|
Many Internet applications have a need for object-based security mechanisms in addition to security mechanisms at the network layer or transport layer. For many years, the Cryptographic Message Syntax(CMS) has provided a binary secure object format based on ASN.1.Over time, binary object encodings such as ASN.1 have become less common than text-based encodings, such as the JavaScript ObjectNotation (JSON). This document defines a set of use cases and requirements for a secure object format encoded using JSON, drawn from a variety of application security mechanisms currently in development. |
|
| |
| RFC 7167 | A Framework for Point-to-Multipoint MPLS in Transport Networks |
| |
| Authors: | D. Frost, S. Bryant, M. Bocci, L. Berger. |
| Date: | April 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7167 |
|
The Multiprotocol Label Switching Transport Profile (MPLS-TP) is the common set of MPLS protocol functions defined to enable the construction and operation of packet transport networks. The MPLS-TP supports both point-to-point and point-to-multipoint transport paths.This document defines the elements and functions of the MPLS-TP architecture that are applicable specifically to supporting point-to- multipoint transport paths. |
|
| |
| RFC 7168 | The Hyper Text Coffee Pot Control Protocol for Tea Efflux Appliances (HTCPCP-TEA) |
| |
|
|
The Hyper Text Coffee Pot Control Protocol (HTCPCP) specification does not allow for the brewing of tea, in all its variety and complexity. This paper outlines an extension to HTCPCP to allow for pots to provide networked tea-brewing facilities. |
|
| |
| RFC 7169 | The NSA (No Secrecy Afforded) Certificate Extension |
| |
| Authors: | S. Turner. |
| Date: | 1 April 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7169 |
|
This document defines the NSA (No Secrecy Afforded) certificate extension appropriate for use in certain PKIX (X.509 Pubic KeyCertificates) digital certificates. Historically, clients and servers strived to maintain the privacy of their keys; however, the secrecy of their private keys cannot always be maintained. In certain circumstances, a client or a server might feel that they will be compelled in the future to share their keys with a third party.Some clients and servers also have been compelled to share their keys and wish to indicate to relying parties upon certificate renewal that their keys have in fact been shared with a third party. |
|
| |
| RFC 7174 | Transparent Interconnection of Lots of Links (TRILL) Operations, Administration, and Maintenance (OAM) Framework |
| |
| Authors: | S. Salam, T. Senevirathne, S. Aldrin, D. Eastlake 3rd. |
| Date: | May 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7174 |
|
This document specifies a reference framework for Operations,Administration, and Maintenance (OAM) in Transparent Interconnection of Lots of Links (TRILL) networks. The focus of the document is on the fault and performance management aspects of TRILL OAM. |
|
| |
| RFC 7185 | Link Metrics for the Mobile Ad Hoc Network (MANET) Routing Protocol OLSRv2 - Rationale |
| |
| Authors: | C. Dearlove, T. Clausen, P. Jacquet. |
| Date: | April 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7185 |
|
The Optimized Link State Routing Protocol version 2 (OLSRv2) includes the ability to assign metrics to links and to use those metrics to allow routing by other than minimum hop count routes. This document provides a historic record of the rationale for, and design considerations behind, how link metrics were included in OLSRv2. |
|
| |
| RFC 7186 | Security Threats for the Neighborhood Discovery Protocol (NHDP) |
| |
| Authors: | J. Yi, U. Herberg, T. Clausen. |
| Date: | April 2014 |
| Formats: | txt html json |
| Updated by: | RFC 7985 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7186 |
|
This document analyzes common security threats of the NeighborhoodDiscovery Protocol (NHDP) and describes their potential impacts onMobile Ad Hoc Network (MANET) routing protocols using NHDP. This document is not intended to propose solutions to the threats described. |
|
| |
| RFC 7190 | Use of Multipath with MPLS and MPLS Transport Profile (MPLS-TP) |
| |
| Authors: | C. Villamizar. |
| Date: | March 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7190 |
|
Many MPLS implementations have supported multipath techniques, and many MPLS deployments have used multipath techniques, particularly in very high-bandwidth applications, such as provider IP/MPLS core networks. MPLS Transport Profile (MPLS-TP) has strongly discouraged the use of multipath techniques. Some degradation of MPLS-TPOperations, Administration, and Maintenance (OAM) performance cannot be avoided when operating over many types of multipath implementations.
Using MPLS Entropy Labels (RFC 6790), MPLS Label Switched Paths(LSPs) can be carried over multipath links while also providing a fully MPLS-TP-compliant server layer for MPLS-TP LSPs. This document describes the means of supporting MPLS as a server layer for MPLS-TP.The use of MPLS-TP LSPs as a server layer for MPLS LSPs is also discussed. |
|
| |
| RFC 7193 | The application/cms Media Type |
| |
| Authors: | S. Turner, R. Housley, J. Schaad. |
| Date: | April 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7193 |
|
This document registers the application/cms media type for use with the corresponding CMS (Cryptographic Message Syntax) content types. |
|
| |
| RFC 7194 | Default Port for Internet Relay Chat (IRC) via TLS/SSL |
| |
|
|
This document describes the commonly accepted practice of listening on TCP port 6697 for incoming Internet Relay Chat (IRC) connections encrypted via TLS/SSL. |
|
| |
| RFC 7201 | Options for Securing RTP Sessions |
| |
| Authors: | M. Westerlund, C. Perkins. |
| Date: | April 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7201 |
|
The Real-time Transport Protocol (RTP) is used in a large number of different application domains and environments. This heterogeneity implies that different security mechanisms are needed to provide services such as confidentiality, integrity, and source authentication of RTP and RTP Control Protocol (RTCP) packets suitable for the various environments. The range of solutions makes it difficult for RTP-based application developers to pick the most suitable mechanism. This document provides an overview of a number of security solutions for RTP and gives guidance for developers on how to choose the appropriate security mechanism. |
|
| |
| RFC 7202 | Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution |
| |
| Authors: | C. Perkins, M. Westerlund. |
| Date: | April 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7202 |
|
This memo discusses the problem of securing real-time multimedia sessions. It also explains why the Real-time Transport Protocol(RTP) and the associated RTP Control Protocol (RTCP) do not mandate a single media security mechanism. This is relevant for designers and reviewers of future RTP extensions to ensure that appropriate security mechanisms are mandated and that any such mechanisms are specified in a manner that conforms with the RTP architecture. |
|
| |
| RFC 7204 | Requirements for Labeled NFS |
| |
| Authors: | T. Haynes. |
| Date: | April 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7204 |
|
This memo outlines high-level requirements for the integration of flexible Mandatory Access Control (MAC) functionality into theNetwork File System (NFS) version 4.2 (NFSv4.2). It describes the level of protections that should be provided over protocol components and the basic structure of the proposed system. The intent here is not to present the protocol changes but to describe the environment in which they reside. |
|
| |
| RFC 7205 | Use Cases for Telepresence Multistreams |
| |
| Authors: | A. Romanow, S. Botzko, M. Duckworth, R. Even, Ed.. |
| Date: | April 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7205 |
|
Telepresence conferencing systems seek to create an environment that gives users (or user groups) that are not co-located a feeling of co- located presence through multimedia communication that includes at least audio and video signals of high fidelity. A number of techniques for handling audio and video streams are used to create this experience. When these techniques are not similar, interoperability between different systems is difficult at best, and often not possible. Conveying information about the relationships between multiple streams of media would enable senders and receivers to make choices to allow telepresence systems to interwork. This memo describes the most typical and important use cases for sending multiple streams in a telepresence conference. |
|
| |
| RFC 7206 | Requirements for an End-to-End Session Identification in IP-Based Multimedia Communication Networks |
| |
| Authors: | P. Jones, G. Salgueiro, J. Polk, L. Liess, H. Kaplan. |
| Date: | May 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7206 |
|
This document specifies the requirements for an end-to-end session identifier in IP-based multimedia communication networks. This identifier would enable endpoints, intermediate devices, and management and monitoring systems to identify a session end-to-end across multiple SIP devices, hops, and administrative domains. |
|
| |
| RFC 7207 | A Uniform Resource Name (URN) Namespace for Eurosystem Messaging |
| |
| Authors: | M. Ortseifen, G. Dickfeld. |
| Date: | April 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7207 |
|
This document defines and registers with IANA a Uniform Resource Name(URN) namespace for usage within messages standardized by theEurosystem. The URN namespace is managed by Deutsche Bundesbank, which is a member of the European System of Central Banks (ESCB). |
|
| |
| RFC 7209 | Requirements for Ethernet VPN (EVPN) |
| |
| Authors: | A. Sajassi, R. Aggarwal, J. Uttaro, N. Bitar, W. Henderickx, A. Isaac. |
| Date: | May 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7209 |
|
The widespread adoption of Ethernet L2VPN services and the advent of new applications for the technology (e.g., data center interconnect) have culminated in a new set of requirements that are not readily addressable by the current Virtual Private LAN Service (VPLS) solution. In particular, multihoming with all-active forwarding is not supported, and there's no existing solution to leverageMultipoint-to-Multipoint (MP2MP) Label Switched Paths (LSPs) for optimizing the delivery of multi-destination frames. Furthermore, the provisioning of VPLS, even in the context of BGP-based auto- discovery, requires network operators to specify various network parameters on top of the access configuration. This document specifies the requirements for an Ethernet VPN (EVPN) solution, which addresses the above issues. |
|
| |
| RFC 7211 | Operations Model for Router Keying |
| |
| Authors: | S. Hartman, D. Zhang. |
| Date: | June 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7211 |
|
The IETF is engaged in an effort to analyze the security of routing protocol authentication according to design guidelines discussed inRFC 6518, "Keying and Authentication for Routing Protocols (KARP)Design Guidelines". Developing an operational and management model for routing protocol security that works with all the routing protocols will be critical to the deployability of these efforts.This document gives recommendations to operators and implementors regarding management and operation of router authentication. These recommendations will also assist protocol designers in understanding management issues they will face. |
|
| |
| RFC 7221 | Handling of Internet-Drafts by IETF Working Groups |
| |
| Authors: | A. Farrel, D. Crocker, Ed.. |
| Date: | April 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7221 |
|
The productive output of an IETF working group is documents, as mandated by the working group's charter. When a working group is ready to develop a particular document, the most common mechanism is for it to "adopt" an existing document as a starting point. The document that a working group adopts and then develops further is based on initial input at varying levels of maturity. An initial working group draft might be a document already in wide use, or it might be a blank sheet, wholly created by the working group, or it might represent any level of maturity in between. This document discusses how a working group typically handles the formal documents that it targets for publication. |
|
| |
| RFC 7226 | Requirements for Advanced Multipath in MPLS Networks |
| |
| Authors: | C. Villamizar, Ed., D. McDysan, Ed., S. Ning, A. Malis, L. Yong. |
| Date: | May 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7226 |
|
This document provides a set of requirements for Advanced Multipath in MPLS networks.
Advanced Multipath is a formalization of multipath techniques currently in use in IP and MPLS networks and a set of extensions to existing multipath techniques. |
|
| |
| RFC 7228 | Terminology for Constrained-Node Networks |
| |
| Authors: | C. Bormann, M. Ersue, A. Keranen. |
| Date: | May 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7228 |
|
The Internet Protocol Suite is increasingly used on small devices with severe constraints on power, memory, and processing resources, creating constrained-node networks. This document provides a number of basic terms that have been useful in the standardization work for constrained-node networks. |
|
| |
| RFC 7229 | Object Identifiers for Test Certificate Policies |
| |
| Authors: | R. Housley. |
| Date: | May 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7229 |
|
This document provides several certificate policy identifiers for testing certificate handling software. |
|
| |
| RFC 7236 | Initial Hypertext Transfer Protocol (HTTP) Authentication Scheme Registrations |
| |
| Authors: | J. Reschke. |
| Date: | June 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7236 |
|
This document registers Hypertext Transfer Protocol (HTTP) authentication schemes that have been defined in RFCs before the IANAHTTP Authentication Scheme Registry was established. |
|
| |
| RFC 7237 | Initial Hypertext Transfer Protocol (HTTP) Method Registrations |
| |
| Authors: | J. Reschke. |
| Date: | June 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7237 |
|
This document registers those Hypertext Transfer Protocol (HTTP) methods that have been defined in RFCs before the IANA HTTP MethodRegistry was established. |
|
| |
| RFC 7241 | The IEEE 802/IETF Relationship |
| |
| Authors: | S. Dawkins, P. Thaler, D. Romascanu, B. Aboba, Ed.. |
| Date: | July 2014 |
| Formats: | txt html json |
| Obsoletes: | RFC 4441 |
| Updated by: | RFC 9141 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7241 |
|
This document describes the standardization cooperation betweenProject 802 of the Institute of Electrical and Electronics Engineers(IEEE) and the Internet Engineering Task Force (IETF). This document obsoletes RFC 4441.
Note: This document was collaboratively developed by authors from both the IEEE 802 and IETF leadership and was reviewed and approved by the IEEE 802 Executive Committee prior to publication. |
|
| |
| RFC 7245 | An Architecture for Media Recording Using the Session Initiation Protocol |
| |
| Authors: | A. Hutton, Ed., L. Portman, Ed., R. Jain, K. Rehor. |
| Date: | May 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7245 |
|
Session recording is a critical requirement in many communications environments such as call centers and financial trading. In some of these environments, all calls must be recorded for regulatory, compliance, and consumer protection reasons. Recording of a session is typically performed by sending a copy of a media stream to a recording device. This document describes architectures for deploying session recording solutions in an environment that is based on the Session Initiation Protocol (SIP). |
|
| |
| RFC 7249 | Internet Numbers Registries |
| |
| Authors: | R. Housley. |
| Date: | May 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7249 |
|
RFC 7020 provides information about the Internet Numbers RegistrySystem and how it is used in the distribution of autonomous system(AS) numbers and globally unique unicast Internet Protocol (IP) address space.
This companion document identifies the IANA registries that are part of the Internet Numbers Registry System at this time. |
|
| |
| RFC 7251 | AES-CCM Elliptic Curve Cryptography (ECC) Cipher Suites for TLS |
| |
| Authors: | D. McGrew, D. Bailey, M. Campagna, R. Dugal. |
| Date: | June 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7251 |
|
This memo describes the use of the Advanced Encryption Standard (AES) in the Counter and CBC-MAC Mode (CCM) of operation within TransportLayer Security (TLS) to provide confidentiality and data-origin authentication. The AES-CCM algorithm is amenable to compact implementations, making it suitable for constrained environments, while at the same time providing a high level of security. The cipher suites defined in this document use Elliptic CurveCryptography (ECC) and are advantageous in networks with limited bandwidth. |
|
| |
| RFC 7253 | The OCB Authenticated-Encryption Algorithm |
| |
| Authors: | T. Krovetz, P. Rogaway. |
| Date: | May 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7253 |
|
This document specifies OCB, a shared-key blockcipher-based encryption scheme that provides confidentiality and authenticity for plaintexts and authenticity for associated data. This document is a product of the Crypto Forum Research Group (CFRG). |
|
| |
| RFC 7254 | A Uniform Resource Name Namespace for the Global System for Mobile Communications Association (GSMA) and the International Mobile station Equipment Identity (IMEI) |
| |
| Authors: | M. Montemurro, Ed., A. Allen, D. McDonald, P. Gosden. |
| Date: | May 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7254 |
|
This specification defines a Uniform Resource Name (URN) namespace for the Global System for Mobile Communications Association (GSMA) and a Namespace Specific String (NSS) for the International Mobile station Equipment Identity (IMEI), as well as an associated parameter for the International Mobile station Equipment Identity and SoftwareVersion number (IMEISV). The IMEI and IMEISV were introduced as part of the specification for the GSM and are also now incorporated by the3rd Generation Partnership Project (3GPP) as part of the 3GPP specification for GSM, Universal Mobile Telecommunications System(UMTS), and 3GPP Long Term Evolution (LTE) networks. The IMEI andIMEISV are used to uniquely identify Mobile Equipment within these systems and are managed by the GSMA. URNs from this namespace almost always contain personally identifiable information and need to be treated accordingly. |
|
| |
| RFC 7255 | Using the International Mobile station Equipment Identity (IMEI) Uniform Resource Name (URN) as an Instance ID |
| |
| Authors: | A. Allen, Ed.. |
| Date: | May 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7255 |
|
This specification defines how the Uniform Resource Name (URN) reserved for the Global System for Mobile Communications Association(GSMA) identities and its sub-namespace for the International Mobile station Equipment Identity (IMEI) can be used as an instance-id. Its purpose is to fulfill the requirements for defining how a specificURN needs to be constructed and used in the '+sip.instance' Contact header field parameter for outbound behavior. |
|
| |
| RFC 7259 | The Jabber-ID Header Field |
| |
| Authors: | P. Saint-Andre. |
| Date: | May 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7259 |
|
This document defines a header field that enables the author of an email or netnews message to include a Jabber ID in the message header block for the purpose of associating the author with a particularExtensible Messaging and Presence Protocol (XMPP) address. |
|
| |
| RFC 7262 | Requirements for Telepresence Multistreams |
| |
| Authors: | A. Romanow, S. Botzko, M. Barnes. |
| Date: | June 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7262 |
|
This memo discusses the requirements for specifications that enable telepresence interoperability by describing behaviors and protocols for Controlling Multiple Streams for Telepresence (CLUE). In addition, the problem statement and related definitions are also covered herein. |
|
| |
| RFC 7269 | NAT64 Deployment Options and Experience |
| |
| Authors: | G. Chen, Z. Cao, C. Xie, D. Binet. |
| Date: | June 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7269 |
|
This document summarizes NAT64 function deployment scenarios and operational experience. Both NAT64 Carrier-Grade NAT (NAT64-CGN) andNAT64 server Front End (NAT64-FE) are considered in this document. |
|
| |
| RFC 7270 | Cisco-Specific Information Elements Reused in IP Flow Information Export (IPFIX) |
| |
| Authors: | A. Yourtchenko, P. Aitken, B. Claise. |
| Date: | June 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7270 |
|
This document describes some additional IP Flow Information Export(IPFIX) Information Elements in the range of 1-127, which is the range compatible with field types used by NetFlow version 9 in RFC3954, as specified in the IPFIX Information Model in RFC 7012. |
|
| |
| RFC 7276 | An Overview of Operations, Administration, and Maintenance (OAM) Tools |
| |
| Authors: | T. Mizrahi, N. Sprecher, E. Bellagamba, Y. Weingarten. |
| Date: | June 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7276 |
|
Operations, Administration, and Maintenance (OAM) is a general term that refers to a toolset for fault detection and isolation, and for performance measurement. Over the years, various OAM tools have been defined for various layers in the protocol stack.
This document summarizes some of the OAM tools defined in the IETF in the context of IP unicast, MPLS, MPLS Transport Profile (MPLS-TP), pseudowires, and Transparent Interconnection of Lots of Links(TRILL). This document focuses on tools for detecting and isolating failures in networks and for performance monitoring. Control and management aspects of OAM are outside the scope of this document.Network repair functions such as Fast Reroute (FRR) and protection switching, which are often triggered by OAM protocols, are also out of the scope of this document.
The target audience of this document includes network equipment vendors, network operators, and standards development organizations.This document can be used as an index to some of the main OAM tools defined in the IETF. At the end of the document, a list of the OAM toolsets and a list of the OAM functions are presented as a summary. |
|
| |
| RFC 7278 | Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link |
| |
| Authors: | C. Byrne, D. Drown, A. Vizdal. |
| Date: | June 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7278 |
|
This document describes requirements for extending an IPv6 /64 prefix from a User Equipment Third Generation Partnership Project (3GPP) radio interface to a LAN link and describes two implementation examples. |
|
| |
| RFC 7281 | Authentication-Results Registration for S/MIME Signature Verification |
| |
| Authors: | A. Melnikov. |
| Date: | June 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7281 |
|
RFC 7001 specifies the Authentication-Results header field for conveying results of message authentication checks. This document defines a new authentication method to be used in the Authentication-Results header field for S/MIME-related signature checks. |
|
| |
| RFC 7282 | On Consensus and Humming in the IETF |
| |
| Authors: | P. Resnick. |
| Date: | June 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7282 |
|
The IETF has had a long tradition of doing its technical work through a consensus process, taking into account the different views amongIETF participants and coming to (at least rough) consensus on technical matters. In particular, the IETF is supposed not to be run by a "majority rule" philosophy. This is why we engage in rituals like "humming" instead of voting. However, more and more of our actions are now indistinguishable from voting, and quite often we are letting the majority win the day without consideration of minority concerns. This document explains some features of rough consensus, what is not rough consensus, how we have gotten away from it, how we might think about it differently, and the things we can do in order to really achieve rough consensus.
Note: This document is quite consciously being put forward asInformational. It does not propose to change any IETF processes and is therefore not a BCP. It is simply a collection of principles, hopefully around which the IETF can come to (at least rough) consensus. |
|
| |
| RFC 7284 | The Profile URI Registry |
| |
| Authors: | M. Lanthaler. |
| Date: | June 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7284 |
|
This document defines a registry for profile URIs to be used in specifications standardizing profiles. |
|
| |
| RFC 7288 | Reflections on Host Firewalls |
| |
| Authors: | D. Thaler. |
| Date: | June 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7288 |
|
In today's Internet, the need for firewalls is generally accepted in the industry, and indeed firewalls are widely deployed in practice.Unlike traditional firewalls that protect network links, host firewalls run in end-user systems. Often the result is that software may be running and potentially consuming resources, but then communication is blocked by a host firewall. It's taken for granted that this end state is either desirable or the best that can be achieved in practice, rather than (for example) an end state where the relevant software is not running or is running in a way that would not result in unwanted communication. In this document, we explore the issues behind these assumptions and provide suggestions on improving the architecture going forward. |
|
| |
| RFC 7289 | Carrier-Grade NAT (CGN) Deployment with BGP/MPLS IP VPNs |
| |
| Authors: | V. Kuarsingh, Ed., J. Cianfarani. |
| Date: | June 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7289 |
|
This document specifies a framework to integrate a Network AddressTranslation (NAT) layer into an operator's network to function as aCarrier-Grade NAT (also known as CGN or Large-Scale NAT). The CGN infrastructure will often form a NAT444 environment as the subscriber home network will likely also maintain a subscriber-side NAT function. Exhaustion of the IPv4 address pool is a major driver compelling some operators to implement CGN. Although operators may wish to deploy IPv6 to strategically overcome IPv4 exhaustion, near- term needs may not be satisfied with an IPv6 deployment alone. This document provides a practical integration model that allows the CGN platform to be integrated into the network, meeting the connectivity needs of the subscriber while being mindful of not disrupting existing services and meeting the technical challenges that CGN brings. The model included in this document utilizes BGP/MPLS IPVPNs, which allow for virtual routing separation, helping ease theCGN's impact on the network. This document does not intend to defend the merits of CGN. |
|
| |
| RFC 7290 | Test Plan and Results for Advancing RFC 2680 on the Standards Track |
| |
| Authors: | L. Ciavattone, R. Geib, A. Morton, M. Wieser. |
| Date: | July 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7290 |
|
This memo provides the supporting test plan and results to advanceRFC 2680, a performance metric RFC defining one-way packet loss metrics, along the Standards Track. Observing that the metric definitions themselves should be the primary focus rather than the implementations of metrics, this memo describes the test procedures to evaluate specific metric requirement clauses to determine if the requirement has been interpreted and implemented as intended. Two completely independent implementations have been tested against the key specifications of RFC 2680. |
|
| |
| RFC 7292 | PKCS #12: Personal Information Exchange Syntax v1.1 |
| |
| Authors: | K. Moriarty, Ed., M. Nystrom, S. Parkinson, A. Rusch, M. Scott. |
| Date: | July 2014 |
| Formats: | txt json html |
| Updated by: | RFC 9579 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7292 |
|
PKCS #12 v1.1 describes a transfer syntax for personal identity information, including private keys, certificates, miscellaneous secrets, and extensions. Machines, applications, browsers, Internet kiosks, and so on, that support this standard will allow a user to import, export, and exercise a single set of personal identity information. This standard supports direct transfer of personal information under several privacy and integrity modes.
This document represents a republication of PKCS #12 v1.1 from RSALaboratories' Public Key Cryptography Standard (PKCS) series. By publishing this RFC, change control is transferred to the IETF. |
|
| |
| RFC 7295 | Report from the IAB/IRTF Workshop on Congestion Control for Interactive Real-Time Communication |
| |
| Authors: | H. Tschofenig, L. Eggert, Z. Sarker. |
| Date: | July 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7295 |
|
This document provides a summary of the IAB/IRTF Workshop on'Congestion Control for Interactive Real-Time Communication', which took place in Vancouver, Canada, on July 28, 2012. The main goal of the workshop was to foster a discussion on congestion control mechanisms for interactive real-time communication. This report summarizes the discussions and lists recommendations to the InternetEngineering Task Force (IETF) community.
The views and positions in this report are those of the workshop participants and do not necessarily reflect the views and positions of the authors, the Internet Architecture Board (IAB), or theInternet Research Task Force (IRTF). |
|
| |
| RFC 7297 | IP Connectivity Provisioning Profile (CPP) |
| |
| Authors: | M. Boucadair, C. Jacquenet, N. Wang. |
| Date: | July 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7297 |
|
This document describes the Connectivity Provisioning Profile (CPP) and proposes a CPP template to capture IP/MPLS connectivity requirements to be met within a service delivery context (e.g., Voice over IP or IP TV). The CPP defines the set of IP transfer parameters to be supported by the underlying transport network together with a reachability scope and bandwidth/capacity needs. Appropriate performance metrics, such as one-way delay or one-way delay variation, are used to characterize an IP transfer service. Both global and restricted reachability scopes can be captured in the CPP.
Such a generic CPP template is meant to (1) facilitate the automation of the service negotiation and activation procedures, thus accelerating service provisioning, (2) set (traffic) objectives ofTraffic Engineering functions and service management functions, and(3) improve service and network management systems with 'decision- making' capabilities based upon negotiated/offered CPPs. |
|
| |
| RFC 7299 | Object Identifier Registry for the PKIX Working Group |
| |
|
|
When the Public-Key Infrastructure using X.509 (PKIX) Working Group was chartered, an object identifier arc was allocated by IANA for use by that working group. This document describes the object identifiers that were assigned in that arc, returns control of that arc to IANA, and establishes IANA allocation policies for any future assignments within that arc. |
|
| |
| RFC 7302 | Entertainment Identifier Registry (EIDR) URN Namespace Definition |
| |
|
|
Entertainment Identifier Registry (EIDR) Identifiers are used for the globally unique identification of motion picture and television content. This document defines the formal Uniform Resource Name(URN) Namespace Identifier (NID) for EIDR Identifiers. |
|
| |
| RFC 7304 | A Method for Mitigating Namespace Collisions |
| |
| Authors: | W. Kumari. |
| Date: | July 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7304 |
|
This document outlines a possible, but not recommended, method to mitigate the effect of collisions in the DNS namespace by providing a means for end users to disambiguate the conflict. |
|
| |
| RFC 7305 | Report from the IAB Workshop on Internet Technology Adoption and Transition (ITAT) |
| |
| Authors: | E. Lear, Ed.. |
| Date: | July 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7305 |
|
This document provides an overview of a workshop held by the InternetArchitecture Board (IAB) on Internet Technology Adoption andTransition (ITAT). The workshop was hosted by the University ofCambridge on December 4th and 5th of 2013 in Cambridge, UK. The goal of the workshop was to facilitate adoption of Internet protocols, through examination of a variety of economic models, with particular emphasis at the waist of the hourglass (e.g., the middle of the protocol stack). This report summarizes contributions and discussions. As the topics were wide ranging, there is no single set of recommendations for IETF participants to pursue at this time.Instead, in the classic sense of early research, the workshop noted areas that deserve further exploration.
Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions. |
|
| |
| RFC 7312 | Advanced Stream and Sampling Framework for IP Performance Metrics (IPPM) |
| |
|
|
To obtain repeatable results in modern networks, test descriptions need an expanded stream parameter framework that also augments aspects specified as Type-P for test packets. This memo updates theIP Performance Metrics (IPPM) Framework, RFC 2330, with advanced considerations for measurement methodology and testing. The existing framework mostly assumes deterministic connectivity, and that a single test stream will represent the characteristics of the path when it is aggregated with other flows. Networks have evolved and test stream descriptions must evolve with them; otherwise, unexpected network features may dominate the measured performance. This memo describes new stream parameters for both network characterization and support of application design using IPPM metrics. |
|
| |
| RFC 7315 | Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3GPP |
| |
|
|
This document describes a set of private header (P-header) SessionInitiation Protocol (SIP) fields used by the 3GPP, along with their applicability, which is limited to particular environments. TheP-header fields are used for a variety of purposes within the networks that the partners implement, including charging and information about the networks a call traverses. This document obsoletes RFC 3455. |
|
| |
| RFC 7316 | The Session Initiation Protocol (SIP) P-Private-Network-Indication Private Header (P-Header) |
| |
| Authors: | J. van Elburg, K. Drage, M. Ohsugi, S. Schubert, K. Arai. |
| Date: | July 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7316 |
|
This document specifies the SIP P-Private-Network-Indication P-header used by the 3GPP. The P-Private-Network-Indication indicates that the message is part of the message traffic of a private network and identifies that private network. A private network indication allows nodes to treat private network traffic according to a different set of rules than the set applicable to public network traffic. |
|
| |
| RFC 7322 | 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". |
|
| |
| RFC 7325 | MPLS Forwarding Compliance and Performance Requirements |
| |
| Authors: | C. Villamizar, Ed., K. Kompella, S. Amante, A. Malis, C. Pignataro. |
| Date: | August 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7325 |
|
This document provides guidelines for implementers regarding MPLS forwarding and a basis for evaluations of forwarding implementations.Guidelines cover many aspects of MPLS forwarding. Topics are highlighted where implementers might otherwise overlook practical requirements that are unstated or underemphasized, or that are optional for conformance to RFCs but often considered mandatory by providers. |
|
| |
| RFC 7326 | Energy Management Framework |
| |
| Authors: | J. Parello, B. Claise, B. Schoening, J. Quittek. |
| Date: | September 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7326 |
|
This document defines a framework for Energy Management (EMAN) for devices and device components within, or connected to, communication networks. The framework presents a physical reference model and information model. The information model consists of an EnergyManagement Domain as a set of Energy Objects. Each Energy Object can be attributed with identity, classification, and context. EnergyObjects can be monitored and controlled with respect to power, PowerState, energy, demand, Power Attributes, and battery. Additionally, the framework models relationships and capabilities between EnergyObjects. |
|
| |
| RFC 7328 | Writing I-Ds and RFCs Using Pandoc and a Bit of XML |
| |
| Authors: | R. Gieben. |
| Date: | August 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7328 |
|
This document presents a technique for using a Markdown syntax variant, called Pandoc, and a bit of XML (as defined in RFC 2629) as a source format for documents that are Internet-Drafts (I-Ds) orRFCs.
The goal of this technique (which is called Pandoc2rfc) is to let an author of an I-D focus on the main body of text without being distracted too much by XML tags; however, it does not alleviate the need to typeset some files in XML. |
|
| |
| RFC 7329 | A Session Identifier for the Session Initiation Protocol (SIP) |
| |
|
|
There is a need for having a globally unique session identifier for the same SIP session that can be consistently maintained across SIPProxies, Back-to-Back User Agents (B2BUAs), and other SIP middleboxes, for the purpose of troubleshooting. This document proposes a new SIP header to carry such a value: Session-ID.
The mechanism defined in this document has been widely deployed, and is being followed in a backward-compatible fashion for a newStandards Track document produced by the INSIPID Working Group. |
|
| |
| RFC 7333 | Requirements for Distributed Mobility Management |
| |
| Authors: | H. Chan, Ed., D. Liu, P. Seite, H. Yokota, J. Korhonen. |
| Date: | August 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7333 |
|
This document defines the requirements for Distributed MobilityManagement (DMM) at the network layer. The hierarchical structure in traditional wireless networks has led primarily to centrally deployed mobility anchors. As some wireless networks are evolving away from the hierarchical structure, it can be useful to have a distributed model for mobility management in which traffic does not need to traverse centrally deployed mobility anchors far from the optimal route. The motivation and the problems addressed by each requirement are also described. |
|
| |
| RFC 7336 | Framework for Content Distribution Network Interconnection (CDNI) |
| |
| Authors: | L. Peterson, B. Davie, R. van Brandenburg, Ed.. |
| Date: | August 2014 |
| Formats: | txt json html |
| Obsoletes: | RFC 3466 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7336 |
|
This document presents a framework for Content Distribution NetworkInterconnection (CDNI). The purpose of the framework is to provide an overall picture of the problem space of CDNI and to describe the relationships among the various components necessary to interconnectCDNs. CDNI requires the specification of interfaces and mechanisms to address issues such as request routing, distribution metadata exchange, and logging information exchange across CDNs. The intent of this document is to outline what each interface needs to accomplish and to describe how these interfaces and mechanisms fit together, while leaving their detailed specification to other documents. This document, in combination with RFC 6707, obsoletesRFC 3466. |
|
| |
| RFC 7337 | Content Distribution Network Interconnection (CDNI) Requirements |
| |
| Authors: | K. Leung, Ed., Y. Lee, Ed.. |
| Date: | August 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7337 |
|
Content delivery is frequently provided by specifically architected and provisioned Content Delivery Networks (CDNs). As a result of significant growth in content delivered over IP networks, existingCDN providers are scaling up their infrastructure. Many NetworkService Providers (NSPs) and Enterprise Service Providers (ESPs) are also deploying their own CDNs. To deliver contents from the ContentService Provider (CSP) to end users, the contents may traverse across multiple CDNs. This creates a need for interconnecting (previously) standalone CDNs so that they can collectively act as a single delivery platform from the CSP to the end users.
The goal of the present document is to outline the requirements for the solution and interfaces to be specified by the CDNI working group. |
|
| |
| RFC 7338 | Requirements and Framework for Point-to-Multipoint Pseudowires over MPLS Packet Switched Networks |
| |
| Authors: | F. Jounay, Ed., Y. Kamite, Ed., G. Heron, M. Bocci. |
| Date: | September 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7338 |
|
This document presents a set of requirements and a framework for providing a point-to-multipoint pseudowire (PW) over MPLS PacketSwitched Networks. The requirements identified in this document are related to architecture, signaling, and maintenance aspects of point- to-multipoint PW operation. They are proposed as guidelines for the standardization of such mechanisms. Among other potential applications, point-to-multipoint PWs can be used to optimize the support of multicast Layer 2 services (Virtual Private LAN Service and Virtual Private Multicast Service). |
|
| |
| RFC 7340 | Secure Telephone Identity Problem Statement and Requirements |
| |
| Authors: | J. Peterson, H. Schulzrinne, H. Tschofenig. |
| Date: | September 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7340 |
|
Over the past decade, Voice over IP (VoIP) systems based on SIP have replaced many traditional telephony deployments. Interworking VoIP systems with the traditional telephone network has reduced the overall level of calling party number and Caller ID assurances by granting attackers new and inexpensive tools to impersonate or obscure calling party numbers when orchestrating bulk commercial calling schemes, hacking voicemail boxes, or even circumventing multi-factor authentication systems trusted by banks. Despite previous attempts to provide a secure assurance of the origin of SIP communications, we still lack effective standards for identifying the calling party in a VoIP session. This document examines the reasons why providing identity for telephone numbers on the Internet has proven so difficult and shows how changes in the last decade may provide us with new strategies for attaching a secure identity to SIP sessions. It also gives high-level requirements for a solution in this space. |
|
| |
| RFC 7342 | Practices for Scaling ARP and Neighbor Discovery (ND) in Large Data Centers |
| |
| Authors: | L. Dunbar, W. Kumari, I. Gashinsky. |
| Date: | August 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7342 |
|
This memo documents some operational practices that allow ARP andNeighbor Discovery (ND) to scale in data center environments. |
|
| |
| RFC 7347 | Pre-standard Linear Protection Switching in MPLS Transport Profile (MPLS-TP) |
| |
| Authors: | H. van Helvoort, Ed., J. Ryoo, Ed., H. Zhang, F. Huang, H. Li, A. D'Alessandro. |
| Date: | September 2014 |
| Formats: | txt html pdf json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7347 |
|
The IETF Standards Track solution for MPLS Transport Profile(MPLS-TP) Linear Protection is provided in RFCs 6378, 7271, and 7324.
This document describes the pre-standard implementation of MPLS-TPLinear Protection that has been deployed by several network operators using equipment from multiple vendors. At the time of publication, these pre-standard implementations were still in operation carrying live traffic.
The specified mechanism supports 1+1 unidirectional/bidirectional protection switching and 1:1 bidirectional protection switching. It is purely supported by the MPLS-TP data plane and can work without any control plane. |
|
| |
| RFC 7348 | Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks |
| |
| Authors: | M. Mahalingam, D. Dutt, K. Duda, P. Agarwal, L. Kreeger, T. Sridhar, M. Bursell, C. Wright. |
| Date: | August 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7348 |
|
This document describes Virtual eXtensible Local Area Network(VXLAN), which is used to address the need for overlay networks within virtualized data centers accommodating multiple tenants. The scheme and the related protocols can be used in networks for cloud service providers and enterprise data centers. This memo documents the deployed VXLAN protocol for the benefit of the Internet community. |
|
| |
| RFC 7351 | A Media Type for XML Patch Operations |
| |
| Authors: | E. Wilde. |
| Date: | August 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7351 |
|
The XML patch document format defines an XML document structure for expressing a sequence of patch operations to be applied to an XML document. The XML patch document format builds on the foundations defined in RFC 5261. This specification also provides the media type registration "application/xml-patch+xml", to allow the use of XML patch documents in, for example, HTTP conversations. |
|
| |
| RFC 7353 | Security Requirements for BGP Path Validation |
| |
| Authors: | S. Bellovin, R. Bush, D. Ward. |
| Date: | August 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7353 |
|
This document describes requirements for a BGP security protocol design to provide cryptographic assurance that the origin AutonomousSystem (AS) has the right to announce the prefix and to provide assurance of the AS Path of the announcement. |
|
| |
| RFC 7354 | Update to the Registrant Information for the Digital Video Broadcasting Project (DVB) Uniform Resource Name (URN) Namespace |
| |
|
|
RFC 5328 registered the Uniform Resource Name (URN) namespace "dvb" for the Digital Video Broadcasting Project. This document updatesRFC 5328 with new registrant information. |
|
| |
| RFC 7355 | Indicating WebSocket Protocol as a Transport in the Session Initiation Protocol (SIP) Common Log Format (CLF) |
| |
| Authors: | G. Salgueiro, V. Pascual, A. Roman, S. Garcia. |
| Date: | September 2014 |
| Formats: | txt json html |
| Updates: | RFC 6873 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7355 |
|
RFC 7118 specifies a WebSocket subprotocol as a reliable real-time transport mechanism between Session Initiation Protocol (SIP) entities to enable usage of SIP in web-oriented deployments. This document updates the SIP Common Log Format (CLF), defined in RFC6873, with a new "Transport Flag" for such SIP WebSocket transport. |
|
| |
| RFC 7359 | Layer 3 Virtual Private Network (VPN) Tunnel Traffic Leakages in Dual-Stack Hosts/Networks |
| |
| Authors: | F. Gont. |
| Date: | August 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7359 |
|
The subtle way in which the IPv6 and IPv4 protocols coexist in typical networks, together with the lack of proper IPv6 support in popular Virtual Private Network (VPN) tunnel products, may inadvertently result in VPN tunnel traffic leakages. That is, traffic meant to be transferred over an encrypted and integrity- protected VPN tunnel may leak out of such a tunnel and be sent in the clear on the local network towards the final destination. This document discusses some scenarios in which such VPN tunnel traffic leakages may occur as a result of employing IPv6-unaware VPN software. Additionally, this document offers possible mitigations for this issue. |
|
| |
| RFC 7362 | Latching: Hosted NAT Traversal (HNT) for Media in Real-Time Communication |
| |
| Authors: | E. Ivov, H. Kaplan, D. Wing. |
| Date: | September 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7362 |
|
This document describes the behavior of signaling intermediaries inReal-Time Communication (RTC) deployments, sometimes referred to asSession Border Controllers (SBCs), when performing Hosted NATTraversal (HNT). HNT is a set of mechanisms, such as media relaying and latching, that such intermediaries use to enable other RTC devices behind NATs to communicate with each other.
This document is non-normative and is only written to explain HNT in order to provide a reference to the Internet community and an informative description to manufacturers and users.
Latching, which is one of the HNT components, has a number of security issues covered here. Because of those, and unless all security considerations explained here are taken into account and solved, the IETF advises against use of the latching mechanism over the Internet and recommends other solutions, such as the InteractiveConnectivity Establishment (ICE) protocol. |
|
| |
| RFC 7364 | Problem Statement: Overlays for Network Virtualization |
| |
| Authors: | T. Narten, Ed., E. Gray, Ed., D. Black, L. Fang, L. Kreeger, M. Napierala. |
| Date: | October 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7364 |
|
This document describes issues associated with providing multi- tenancy in large data center networks and how these issues may be addressed using an overlay-based network virtualization approach. A key multi-tenancy requirement is traffic isolation so that one tenant's traffic is not visible to any other tenant. Another requirement is address space isolation so that different tenants can use the same address space within different virtual networks.Traffic and address space isolation is achieved by assigning one or more virtual networks to each tenant, where traffic within a virtual network can only cross into another virtual network in a controlled fashion (e.g., via a configured router and/or a security gateway).Additional functionality is required to provision virtual networks, associating a virtual machine's network interface(s) with the appropriate virtual network and maintaining that association as the virtual machine is activated, migrated, and/or deactivated. Use of an overlay-based approach enables scalable deployment on large network infrastructures. |
|
| |
| RFC 7365 | Framework for Data Center (DC) Network Virtualization |
| |
| Authors: | M. Lasserre, F. Balus, T. Morin, N. Bitar, Y. Rekhter. |
| Date: | October 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7365 |
|
This document provides a framework for Data Center (DC) NetworkVirtualization over Layer 3 (NVO3) and defines a reference model along with logical components required to design a solution. |
|
| |
| RFC 7368 | IPv6 Home Networking Architecture Principles |
| |
| Authors: | T. Chown, Ed., J. Arkko, A. Brandt, O. Troan, J. Weil. |
| Date: | October 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7368 |
|
This text describes evolving networking technology within residential home networks with increasing numbers of devices and a trend towards increased internal routing. The goal of this document is to define a general architecture for IPv6-based home networking, describing the associated principles, considerations, and requirements. The text briefly highlights specific implications of the introduction of IPv6 for home networking, discusses the elements of the architecture, and suggests how standard IPv6 mechanisms and addressing can be employed in home networking. The architecture describes the need for specific protocol extensions for certain additional functionality. It is assumed that the IPv6 home network is not actively managed and runs as an IPv6-only or dual-stack network. There are no recommendations in this text for the IPv4 part of the network. |
|
| |
| RFC 7375 | Secure Telephone Identity Threat Model |
| |
| Authors: | J. Peterson. |
| Date: | October 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7375 |
|
As the Internet and the telephone network have become increasingly interconnected and interdependent, attackers can impersonate or obscure calling party numbers when orchestrating bulk commercial calling schemes, hacking voicemail boxes, or even circumventing multi-factor authentication systems trusted by banks. This document analyzes threats in the resulting system, enumerating actors, reviewing the capabilities available to and used by attackers, and describing scenarios in which attacks are launched. |
|
| |
| RFC 7376 | Problems with Session Traversal Utilities for NAT (STUN) Long-Term Authentication for Traversal Using Relays around NAT (TURN) |
| |
| Authors: | T. Reddy, R. Ravindranath, M. Perumal, A. Yegin. |
| Date: | September 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7376 |
|
This document discusses some of the security problems and practical problems with the current Session Traversal Utilities for NAT (STUN) authentication for Traversal Using Relays around NAT (TURN) messages. |
|
| |
| RFC 7378 | Trustworthy Location |
| |
| Authors: | H. Tschofenig, H. Schulzrinne, B. Aboba, Ed.. |
| Date: | December 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7378 |
|
The trustworthiness of location information is critically important for some location-based applications, such as emergency calling or roadside assistance.
This document describes threats to conveying location, particularly for emergency calls, and describes techniques that improve the reliability and security of location information. It also provides guidelines for assessing the trustworthiness of location information. |
|
| |
| RFC 7379 | Problem Statement and Goals for Active-Active Connection at the Transparent Interconnection of Lots of Links (TRILL) Edge |
| |
| Authors: | Y. Li, W. Hao, R. Perlman, J. Hudson, H. Zhai. |
| Date: | October 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7379 |
|
The IETF TRILL (Transparent Interconnection of Lots of Links) protocol provides support for flow-level multipathing with rapid failover for both unicast and multi-destination traffic in networks with arbitrary topology. Active-active connection at the TRILL edge is the extension of these characteristics to end stations that are multiply connected to a TRILL campus. This informational document discusses the high-level problems and goals when providing active- active connection at the TRILL edge. |
|
| |
| RFC 7381 | Enterprise IPv6 Deployment Guidelines |
| |
| Authors: | K. Chittimaneni, T. Chown, L. Howard, V. Kuarsingh, Y. Pouffary, E. Vyncke. |
| Date: | October 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7381 |
|
Enterprise network administrators worldwide are in various stages of preparing for or deploying IPv6 into their networks. The administrators face different challenges than operators of Internet access providers and have reasons for different priorities. The overall problem for many administrators will be to offer Internet- facing services over IPv6 while continuing to support IPv4, and while introducing IPv6 access within the enterprise IT network. The overall transition will take most networks from an IPv4-only environment to a dual-stack network environment and eventually anIPv6-only operating mode. This document helps provide a framework for enterprise network architects or administrators who may be faced with many of these challenges as they consider their IPv6 support strategies. |
|
| |
| RFC 7384 | Security Requirements of Time Protocols in Packet Switched Networks |
| |
| Authors: | T. Mizrahi. |
| Date: | October 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7384 |
|
As time and frequency distribution protocols are becoming increasingly common and widely deployed, concern about their exposure to various security threats is increasing. This document defines a set of security requirements for time protocols, focusing on thePrecision Time Protocol (PTP) and the Network Time Protocol (NTP).This document also discusses the security impacts of time protocol practices, the performance implications of external security practices on time protocols, and the dependencies between other security services and time synchronization. |
|
| |
| RFC 7387 | A Framework for Ethernet Tree (E-Tree) Service over a Multiprotocol Label Switching (MPLS) Network |
| |
| Authors: | R. Key, Ed., L. Yong, Ed., S. Delord, F. Jounay, L. Jin. |
| Date: | October 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7387 |
|
This document describes an Ethernet-Tree (E-Tree) solution framework for supporting the Metro Ethernet Forum (MEF) E-Tree service over aMultiprotocol Label Switching (MPLS) network. The objective is to provide a simple and effective approach to emulate E-Tree services in addition to Ethernet LAN (E-LAN) services on an existing MPLS network. |
|
| |
| RFC 7393 | Using the Port Control Protocol (PCP) to Update Dynamic DNS |
| |
| Authors: | X. Deng, M. Boucadair, Q. Zhao, J. Huang, C. Zhou. |
| Date: | November 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7393 |
|
This document focuses on the problems encountered when using dynamicDNS in address-sharing contexts (e.g., Dual-Stack Lite (DS-Lite) andNetwork Address and Protocol Translation from IPv6 Clients to IPv4Servers (NAT64)) during IPv6 transition. Both issues and possible solutions are documented in this memo. |
|
| |
| RFC 7397 | Report from the Smart Object Security Workshop |
| |
| Authors: | J. Gilger, H. Tschofenig. |
| Date: | December 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7397 |
|
This document provides a summary of a workshop on 'Smart ObjectSecurity' that took place in Paris on March 23, 2012. The main goal of the workshop was to allow participants to share their thoughts about the ability to utilize existing and widely deployed security mechanisms for smart objects.
This report summarizes the discussions and lists the conclusions and recommendations to the Internet Engineering Task Force (IETF) community. |
|
| |
| RFC 7398 | A Reference Path and Measurement Points for Large-Scale Measurement of Broadband Performance |
| |
| Authors: | M. Bagnulo, T. Burbridge, S. Crawford, P. Eardley, A. Morton. |
| Date: | February 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7398 |
|
This document defines a reference path for Large-scale Measurement ofBroadband Access Performance (LMAP) and measurement points for commonly used performance metrics. Other similar measurement projects may also be able to use the extensions described here for measurement point location. The purpose is to create an efficient way to describe the location of the measurement point(s) used to conduct a particular measurement. |
|
| |
| RFC 7399 | Unanswered Questions in the Path Computation Element Architecture |
| |
| Authors: | A. Farrel, D. King. |
| Date: | October 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7399 |
|
The Path Computation Element (PCE) architecture is set out in RFC4655. The architecture is extended for multi-layer networking with the introduction of the Virtual Network Topology Manager (VNTM) inRFC 5623 and generalized to Hierarchical PCE (H-PCE) in RFC 6805.
These three architectural views of PCE deliberately leave some key questions unanswered, especially with respect to the interactions between architectural components. This document draws out those questions and discusses them in an architectural context with reference to other architectural components, existing protocols, and recent IETF efforts.
This document does not update the architecture documents and does not define how protocols or components must be used. It does, however, suggest how the architectural components might be combined to provide advanced PCE function. |
|
| |
| RFC 7404 | Using Only Link-Local Addressing inside an IPv6 Network |
| |
| Authors: | M. Behringer, E. Vyncke. |
| Date: | November 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7404 |
|
In an IPv6 network, it is possible to use only link-local addresses on infrastructure links between routers. This document discusses the advantages and disadvantages of this approach to facilitate the decision process for a given network. |
|
| |
| RFC 7406 | Extensions to the Emergency Services Architecture for Dealing With Unauthenticated and Unauthorized Devices |
| |
| Authors: | H. Schulzrinne, S. McCann, G. Bajko, H. Tschofenig, D. Kroeselberg. |
| Date: | December 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7406 |
|
This document provides a problem statement, introduces terminology, and describes an extension for the base IETF emergency services architecture to address cases where an emergency caller is not authenticated, has no identifiable service provider, or has no remaining credit with which to pay for access to the network. |
|
| |
| RFC 7412 | Requirements for MPLS Transport Profile (MPLS-TP) Shared Mesh Protection |
| |
| Authors: | Y. Weingarten, S. Aldrin, P. Pan, J. Ryoo, G. Mirsky. |
| Date: | December 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7412 |
|
This document presents the basic network objectives for the behavior of Shared Mesh Protection (SMP) that are not based on control-plane support. This document provides an expansion of the basic requirements presented in RFC 5654 ("Requirements of an MPLSTransport Profile") and RFC 6372 ("MPLS Transport Profile (MPLS-TP)Survivability Framework"). This document provides requirements for any mechanism that would be used to implement SMP for MPLS-TP data paths, in networks that delegate protection switch coordination to the data plane. |
|
| |
| RFC 7414 | A Roadmap for Transmission Control Protocol (TCP) Specification Documents |
| |
| Authors: | M. Duke, R. Braden, W. Eddy, E. Blanton, A. Zimmermann. |
| Date: | February 2015 |
| Formats: | txt json html |
| Obsoletes: | RFC 4614 |
| Updated by: | RFC 7805 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7414 |
|
This document contains a roadmap to the Request for Comments (RFC) documents relating to the Internet's Transmission Control Protocol(TCP). This roadmap provides a brief summary of the documents defining TCP and various TCP extensions that have accumulated in theRFC series. This serves as a guide and quick reference for both TCP implementers and other parties who desire information contained in the TCP-related RFCs.
This document obsoletes RFC 4614. |
|
| |
| RFC 7416 | A Security Threat Analysis for the Routing Protocol for Low-Power and Lossy Networks (RPLs) |
| |
| Authors: | T. Tsao, R. Alexander, M. Dohler, V. Daza, A. Lozano, M. Richardson, Ed.. |
| Date: | January 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7416 |
|
This document presents a security threat analysis for the RoutingProtocol for Low-Power and Lossy Networks (RPLs). The development builds upon previous work on routing security and adapts the assessments to the issues and constraints specific to low-power and lossy networks. A systematic approach is used in defining and evaluating the security threats. Applicable countermeasures are application specific and are addressed in relevant applicability statements. |
|
| |
| RFC 7418 | An IRTF Primer for IETF Participants |
| |
| Authors: | S. Dawkins, Ed.. |
| Date: | December 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7418 |
|
This document provides a high-level description of things forInternet Engineering Task Force (IETF) participants to consider when bringing proposals for new research groups (RGs) into the InternetResearch Task Force (IRTF). This document emphasizes differences in expectations between the two organizations. |
|
| |
| RFC 7419 | Common Interval Support in Bidirectional Forwarding Detection |
| |
| Authors: | N. Akiya, M. Binderberger, G. Mirsky. |
| Date: | December 2014 |
| Formats: | txt json html |
| Updates: | RFC 5880 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7419 |
|
Bidirectional Forwarding Detection (BFD) requires that messages be transmitted at regular intervals and provides a way to negotiate the interval used by BFD peers. Some BFD implementations may be restricted to only support several interval values. When such BFD implementations speak to each other, there is a possibility of two sides not being able to find a common value for the interval to runBFD sessions.
This document updates RFC 5880 by defining a small set of interval values for BFD that we call "Common Intervals" and recommends implementations to support the defined intervals. This solves the problem of finding an interval value that both BFD speakers can support while allowing a simplified implementation as seen for hardware-based BFD. It does not restrict an implementation from supporting more intervals in addition to the Common Intervals. |
|
| |
| RFC 7421 | Analysis of the 64-bit Boundary in IPv6 Addressing |
| |
| Authors: | B. Carpenter, Ed., T. Chown, F. Gont, S. Jiang, A. Petrescu, A. Yourtchenko. |
| Date: | January 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7421 |
|
The IPv6 unicast addressing format includes a separation between the prefix used to route packets to a subnet and the interface identifier used to specify a given interface connected to that subnet.Currently, the interface identifier is defined as 64 bits long for almost every case, leaving 64 bits for the subnet prefix. This document describes the advantages of this fixed boundary and analyzes the issues that would be involved in treating it as a variable boundary. |
|
| |
| RFC 7422 | Deterministic Address Mapping to Reduce Logging in Carrier-Grade NAT Deployments |
| |
| Authors: | C. Donley, C. Grundemann, V. Sarawat, K. Sundaresan, O. Vautrin. |
| Date: | December 2014 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7422 |
|
In some instances, Service Providers (SPs) have a legal logging requirement to be able to map a subscriber's inside address with the address used on the public Internet (e.g., for abuse response).Unfortunately, many logging solutions for Carrier-Grade NATs (CGNs) require active logging of dynamic translations. CGN port assignments are often per connection, but they could optionally use port ranges.Research indicates that per-connection logging is not scalable in many residential broadband services. This document suggests a way to manage CGN translations in such a way as to significantly reduce the amount of logging required while providing traceability for abuse response. IPv6 is, of course, the preferred solution. While deployment is in progress, SPs are forced by business imperatives to maintain support for IPv4. This note addresses the IPv4 part of the network when a CGN solution is in use. |
|
| |
| RFC 7424 | Mechanisms for Optimizing Link Aggregation Group (LAG) and Equal-Cost Multipath (ECMP) Component Link Utilization in Networks |
| |
| Authors: | R. Krishnan, L. Yong, A. Ghanwani, N. So, B. Khasnabish. |
| Date: | January 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7424 |
|
Demands on networking infrastructure are growing exponentially due to bandwidth-hungry applications such as rich media applications and inter-data-center communications. In this context, it is important to optimally use the bandwidth in wired networks that extensively use link aggregation groups and equal-cost multipaths as techniques for bandwidth scaling. This document explores some of the mechanisms useful for achieving this. |
|
| |
| RFC 7425 | Adobe's RTMFP Profile for Flash Communication |
| |
| Authors: | M. Thornburgh. |
| Date: | December 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7425 |
|
This memo describes how to use Adobe's Secure Real-Time Media FlowProtocol (RTMFP) to transport the video, audio, and data messages ofAdobe Flash platform communications. Aspects of this application profile include cryptographic methods and data formats, flow metadata formats, and protocol details for client-server and peer-to-peer communication. |
|
| |
| RFC 7426 | Software-Defined Networking (SDN): Layers and Architecture Terminology |
| |
| Authors: | E. Haleplidis, Ed., K. Pentikousis, Ed., S. Denazis, J. Hadi Salim, D. Meyer, O. Koufopavlou. |
| Date: | January 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7426 |
|
Software-Defined Networking (SDN) refers to a new approach for network programmability, that is, the capacity to initialize, control, change, and manage network behavior dynamically via open interfaces. SDN emphasizes the role of software in running networks through the introduction of an abstraction for the data forwarding plane and, by doing so, separates it from the control plane. This separation allows faster innovation cycles at both planes as experience has already shown. However, there is increasing confusion as to what exactly SDN is, what the layer structure is in an SDN architecture, and how layers interface with each other. This document, a product of the IRTF Software-Defined Networking ResearchGroup (SDNRG), addresses these questions and provides a concise reference for the SDN research community based on relevant peer- reviewed literature, the RFC series, and relevant documents by other standards organizations. |
|
| |
| RFC 7429 | Distributed Mobility Management: Current Practices and Gap Analysis |
| |
| Authors: | D. Liu, Ed., JC. Zuniga, Ed., P. Seite, H. Chan, CJ. Bernardos. |
| Date: | January 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7429 |
|
This document analyzes deployment practices of existing IP mobility protocols in a distributed mobility management environment. It then identifies existing limitations when compared to the requirements defined for a distributed mobility management solution. |
|
| |
| RFC 7430 | Analysis of Residual Threats and Possible Fixes for Multipath TCP (MPTCP) |
| |
| Authors: | M. Bagnulo, C. Paasch, F. Gont, O. Bonaventure, C. Raiciu. |
| Date: | July 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7430 |
|
This document analyzes the residual threats for Multipath TCP (MPTCP) and explores possible solutions to address them. |
|
| |
| RFC 7431 | Multicast-Only Fast Reroute |
| |
| Authors: | A. Karan, C. Filsfils, IJ. Wijnands, Ed., B. Decraene. |
| Date: | August 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7431 |
|
As IPTV deployments grow in number and size, service providers are looking for solutions that minimize the service disruption due to faults in the IP network carrying the packets for these services.This document describes a mechanism for minimizing packet loss in a network when node or link failures occur. Multicast-only FastReroute (MoFRR) works by making simple enhancements to multicast routing protocols such as Protocol Independent Multicast (PIM) andMultipoint LDP (mLDP). |
|
| |
| RFC 7435 | Opportunistic Security: Some Protection Most of the Time |
| |
| Authors: | V. Dukhovni. |
| Date: | December 2014 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7435 |
|
This document defines the concept "Opportunistic Security" in the context of communications protocols. Protocol designs based onOpportunistic Security use encryption even when authentication is not available, and use authentication when possible, thereby removing barriers to the widespread use of encryption on the Internet. |
|
| |
| RFC 7439 | Gap Analysis for Operating IPv6-Only MPLS Networks |
| |
| Authors: | W. George, Ed., C. Pignataro, Ed.. |
| Date: | January 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7439 |
|
This document reviews the Multiprotocol Label Switching (MPLS) protocol suite in the context of IPv6 and identifies gaps that must be addressed in order to allow MPLS-related protocols and applications to be used with IPv6-only networks. This document is intended to focus on gaps in the standards defining the MPLS suite, and is not intended to highlight particular vendor implementations(or lack thereof) in the context of IPv6-only MPLS functionality.
In the data plane, MPLS fully supports IPv6, and MPLS labeled packets can be carried over IPv6 packets in a variety of encapsulations.However, support for IPv6 among MPLS control-plane protocols, MPLS applications, MPLS Operations, Administration, and Maintenance (OAM), and MIB modules is mixed, with some protocols having major gaps. For most major gaps, work is in progress to upgrade the relevant protocols. |
|
| |
| RFC 7443 | Application-Layer Protocol Negotiation (ALPN) Labels for Session Traversal Utilities for NAT (STUN) Usages |
| |
| Authors: | P. Patil, T. Reddy, G. Salgueiro, M. Petit-Huguenin. |
| Date: | January 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7443 |
|
Application-Layer Protocol Negotiation (ALPN) labels for SessionTraversal Utilities for NAT (STUN) usages, such as Traversal UsingRelays around NAT (TURN) and NAT discovery, are defined in this document to allow an application layer to negotiate STUN usages within the Transport Layer Security (TLS) connection. ALPN protocol identifiers defined in this document apply to both TLS and DatagramTransport Layer Security (DTLS). |
|
| |
| RFC 7444 | Security Labels in Internet Email |
| |
| Authors: | K. Zeilenga, A. Melnikov. |
| Date: | February 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7444 |
|
This document describes a header field, SIO-Label, for use inInternet email to convey the sensitivity of the message. This header field may carry a textual representation (a display marking) and/or a structural representation (a security label) of the sensitivity of the message. This document also describes a header field, SIO-Label-History, for recording changes in the message's label. |
|
| |
| RFC 7445 | Analysis of Failure Cases in IPv6 Roaming Scenarios |
| |
| Authors: | G. Chen, H. Deng, D. Michaud, J. Korhonen, M. Boucadair. |
| Date: | March 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7445 |
|
This document identifies a set of failure cases that may be encountered by IPv6-enabled mobile customers in roaming scenarios.The analysis reveals that the failure causes include improper configurations, incomplete functionality support in equipment, and inconsistent IPv6 deployment strategies between the home and the visited networks. |
|
| |
| RFC 7446 | Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks |
| |
| Authors: | Y. Lee, Ed., G. Bernstein, Ed., D. Li, W. Imajuku. |
| Date: | February 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7446 |
|
This document provides a model of information needed by the Routing and Wavelength Assignment (RWA) process in Wavelength SwitchedOptical Networks (WSONs). The purpose of the information described in this model is to facilitate constrained optical path computation in WSONs. This model takes into account compatibility constraints between WSON signal attributes and network elements but does not include constraints due to optical impairments. Aspects of this information that may be of use to other technologies utilizing aGMPLS control plane are discussed. |
|
| |
| RFC 7448 | MIB Transfer from the IETF to the IEEE 802.3 WG |
| |
| Authors: | T. Taylor, Ed., D. Romascanu. |
| Date: | February 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7448 |
|
This document records the transfer of responsibility for theEthernet-related MIB modules DOT3-OAM-MIB, SNMP-REPEATER-MIB,POWER-ETHERNET-MIB, DOT3-EPON-MIB, EtherLike-MIB, EFM-CU-MIB,ETHER-WIS, and MAU-MIB from the IETF to the IEEE 802.3 Working Group(WG). This document also describes the procedures associated with the transfer in a similar way to how RFC 4663 records the transfer of the IETF Bridge MIB work to the IEEE 802.1 WG. |
|
| |
| RFC 7449 | Path Computation Element Communication Protocol (PCEP) Requirements for Wavelength Switched Optical Network (WSON) Routing and Wavelength Assignment |
| |
| Authors: | Y. Lee, Ed., G. Bernstein, Ed., J. Martensson, T. Takeda, T. Tsuritani, O. Gonzalez de Dios. |
| Date: | February 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7449 |
|
This memo provides application-specific requirements for the PathComputation Element Communication Protocol (PCEP) for the support ofWavelength Switched Optical Networks (WSONs). Lightpath provisioning in WSONs requires a Routing and Wavelength Assignment (RWA) process.From a path computation perspective, wavelength assignment is the process of determining which wavelength can be used on each hop of a path and forms an additional routing constraint to optical light path computation. Requirements for PCEP extensions in support of optical impairments will be addressed in a separate document. |
|
| |
| RFC 7451 | Extension Registry for the Extensible Provisioning Protocol |
| |
| Authors: | S. Hollenbeck. |
| Date: | February 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7451 |
|
The Extensible Provisioning Protocol (EPP) includes features to add functionality by extending the protocol. It does not, however, describe how those extensions are managed. This document describes a procedure for the registration and management of extensions to EPP, and it specifies a format for an IANA registry to record those extensions. |
|
| |
| RFC 7452 | Architectural Considerations in Smart Object Networking |
| |
| Authors: | H. Tschofenig, J. Arkko, D. Thaler, D. McPherson. |
| Date: | March 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7452 |
|
The term "Internet of Things" (IoT) denotes a trend where a large number of embedded devices employ communication services offered byInternet protocols. Many of these devices, often called "smart objects", are not directly operated by humans but exist as components in buildings or vehicles, or are spread out in the environment.Following the theme "Everything that can be connected will be connected", engineers and researchers designing smart object networks need to decide how to achieve this in practice.
This document offers guidance to engineers designing Internet- connected smart objects. |
|
| |
| RFC 7457 | Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS) |
| |
| Authors: | Y. Sheffer, R. Holz, P. Saint-Andre. |
| Date: | February 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7457 |
|
Over the last few years, there have been several serious attacks onTransport Layer Security (TLS), including attacks on its most commonly used ciphers and modes of operation. This document summarizes these attacks, with the goal of motivating generic and protocol-specific recommendations on the usage of TLS and DatagramTLS (DTLS). |
|
| |
| RFC 7458 | Extensible Authentication Protocol (EAP) Attributes for Wi-Fi Integration with the Evolved Packet Core |
| |
| Authors: | R. Valmikam, R. Koodli. |
| Date: | February 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7458 |
|
With Wi-Fi emerging as a crucial access network for mobile service providers, it has become important to provide functions commonly available in 3G and 4G networks in Wi-Fi access networks as well.Such functions include Access Point Name (APN) Selection, multiplePacket Data Network (PDN) connections, and seamless mobility betweenWi-Fi and 3G/4G networks.
The EAP Authentication and Key Agreement (EAP-AKA), and EAP-AKA', protocol is required for mobile devices to access the mobile EvolvedPacket Core (EPC) via Wi-Fi networks. This document defines a few new EAP attributes to enable the above-mentioned functions in such networks. The attributes are exchanged between a client (such as aMobile Node (MN)) and its network counterpart (such as anAuthentication, Authorization, and Accounting (AAA) server) in the service provider's infrastructure. |
|
| |
| RFC 7467 | URN Namespace for the North Atlantic Treaty Organization (NATO) |
| |
| Authors: | A. Murdock. |
| Date: | April 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7467 |
|
This document allocates a formal Uniform Resource Name (URN) namespace for assignment by the North Atlantic Treaty Organization(NATO), as specified in RFC 3406. At this time, the URN will be used primarily to uniquely identify Extensible Markup Language (XML) artefacts that provide information about NATO message text formats and service specifications as described in various NATO standards, instructions, and publications. |
|
| |
| RFC 7476 | Information-Centric Networking: Baseline Scenarios |
| |
| Authors: | K. Pentikousis, Ed., B. Ohlman, D. Corujo, G. Boggia, G. Tyson, E. Davies, A. Molinaro, S. Eum. |
| Date: | March 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7476 |
|
This document aims at establishing a common understanding about a set of scenarios that can be used as a base for the evaluation of different information-centric networking (ICN) approaches so that they can be tested and compared against each other while showcasing their own advantages. Towards this end, we review the ICN literature and document scenarios which have been considered in previous performance evaluation studies. We discuss a variety of aspects that an ICN solution can address. This includes general aspects, such as, network efficiency, reduced complexity, increased scalability and reliability, mobility support, multicast and caching performance, real-time communication efficiency, energy consumption frugality, and disruption and delay tolerance. We detail ICN-specific aspects as well, such as information security and trust, persistence, availability, provenance, and location independence.
This document is a product of the IRTF Information-Centric NetworkingResearch Group (ICNRG). |
|
| |
| RFC 7478 | Web Real-Time Communication Use Cases and Requirements |
| |
| Authors: | C. Holmberg, S. Hakansson, G. Eriksson. |
| Date: | March 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7478 |
|
This document describes web-based real-time communication use cases.Requirements on the browser functionality are derived from the use cases.
This document was developed in an initial phase of the work with rather minor updates at later stages. It has not really served as a tool in deciding features or scope for the WG's efforts so far. It is being published to record the early conclusions of the WG. It will not be used as a set of rigid guidelines that specifications and implementations will be held to in the future. |
|
| |
| RFC 7479 | Using Ed25519 in SSHFP Resource Records |
| |
| Authors: | S. Moonesamy. |
| Date: | March 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7479 |
|
The Ed25519 signature algorithm has been implemented in OpenSSH.This document updates the IANA "SSHFP RR Types for public key algorithms" registry by adding an algorithm number for Ed25519. |
|
| |
| RFC 7485 | Inventory and Analysis of WHOIS Registration Objects |
| |
| Authors: | L. Zhou, N. Kong, S. Shen, S. Sheng, A. Servin. |
| Date: | March 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7485 |
|
WHOIS output objects from registries, including both RegionalInternet Registries (RIRs) and Domain Name Registries (DNRs), were collected and analyzed. This document describes the process and results of the statistical analysis of existing WHOIS information.The purpose of this document is to build an object inventory to facilitate discussions of data objects included in Registration DataAccess Protocol (RDAP) responses. |
|
| |
| RFC 7489 | 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. |
|
| |
| RFC 7491 | A PCE-Based Architecture for Application-Based Network Operations |
| |
| Authors: | D. King, A. Farrel. |
| Date: | March 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7491 |
|
Services such as content distribution, distributed databases, or inter-data center connectivity place a set of new requirements on the operation of networks. They need on-demand and application-specific reservation of network connectivity, reliability, and resources (such as bandwidth) in a variety of network applications (such as point-to- point connectivity, network virtualization, or mobile back-haul) and in a range of network technologies from packet (IP/MPLS) down to optical. An environment that operates to meet these types of requirements is said to have Application-Based Network Operations(ABNO). ABNO brings together many existing technologies and may be seen as the use of a toolbox of existing components enhanced with a few new elements.
This document describes an architecture and framework for ABNO, showing how these components fit together. It provides a cookbook of existing technologies to satisfy the architecture and meet the needs of the applications. |
|
| |
| RFC 7492 | Analysis of Bidirectional Forwarding Detection (BFD) Security According to the Keying and Authentication for Routing Protocols (KARP) Design Guidelines |
| |
| Authors: | M. Bhatia, D. Zhang, M. Jethanandani. |
| Date: | March 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7492 |
|
This document analyzes the Bidirectional Forwarding Detection (BFD) protocol according to the guidelines set forth in Section 4.2 of RFC6518, "Keying and Authentication for Routing Protocols (KARP) DesignGuidelines". |
|
| |
| RFC 7497 | Rate Measurement Test Protocol Problem Statement and Requirements |
| |
| Authors: | A. Morton. |
| Date: | April 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7497 |
|
This memo presents a problem statement for access rate measurement for test protocols to measure IP Performance Metrics (IPPM). Key rate measurement test protocol aspects include the ability to control packet characteristics on the tested path, such as asymmetric rate and asymmetric packet size. |
|
| |
| RFC 7498 | Problem Statement for Service Function Chaining |
| |
| Authors: | P. Quinn, Ed., T. Nadeau, Ed.. |
| Date: | April 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7498 |
|
This document provides an overview of the issues associated with the deployment of service functions (such as firewalls, load balancers, etc.) in large-scale environments. The term "service function chaining" is used to describe the definition and instantiation of an ordered list of instances of such service functions, and the subsequent "steering" of traffic flows through those service functions.
The set of enabled service function chains reflects operator service offerings and is designed in conjunction with application delivery and service and network policy.
This document also identifies several key areas that the ServiceFunction Chaining (SFC) working group will investigate to guide its architectural and protocol work and associated documents. |
|
| |
| RFC 7500 | Principles for Operation of Internet Assigned Numbers Authority (IANA) Registries |
| |
| Authors: | R. Housley, Ed., O. Kolkman, Ed.. |
| Date: | April 2015 |
| Formats: | txt html json |
| Obsoleted by: | RFC 8720 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7500 |
|
This document provides principles for the operation of InternetAssigned Numbers Authority (IANA) registries. |
|
| |
| RFC 7501 | Terminology for Benchmarking Session Initiation Protocol (SIP) Devices: Basic Session Setup and Registration |
| |
| Authors: | C. Davids, V. Gurbani, S. Poretsky. |
| Date: | April 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7501 |
|
This document provides a terminology for benchmarking the SessionInitiation Protocol (SIP) performance of devices. Methodology related to benchmarking SIP devices is described in the companion methodology document (RFC 7502). Using these two documents, benchmarks can be obtained and compared for different types of devices such as SIP Proxy Servers, Registrars, and Session BorderControllers. The term "performance" in this context means the capacity of the Device Under Test (DUT) to process SIP messages.Media streams are used only to study how they impact the signaling behavior. The intent of the two documents is to provide a normalized set of tests that will enable an objective comparison of the capacity of SIP devices. Test setup parameters and a methodology are necessary because SIP allows a wide range of configurations and operational conditions that can influence performance benchmark measurements. A standard terminology and methodology will ensure that benchmarks have consistent definitions and were obtained following the same procedures. |
|
| |
| RFC 7502 | Methodology for Benchmarking Session Initiation Protocol (SIP) Devices: Basic Session Setup and Registration |
| |
| Authors: | C. Davids, V. Gurbani, S. Poretsky. |
| Date: | April 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7502 |
|
This document provides a methodology for benchmarking the SessionInitiation Protocol (SIP) performance of devices. Terminology related to benchmarking SIP devices is described in the companion terminology document (RFC 7501). Using these two documents, benchmarks can be obtained and compared for different types of devices such as SIP Proxy Servers, Registrars, and Session BorderControllers. The term "performance" in this context means the capacity of the Device Under Test (DUT) to process SIP messages.Media streams are used only to study how they impact the signaling behavior. The intent of the two documents is to provide a normalized set of tests that will enable an objective comparison of the capacity of SIP devices. Test setup parameters and a methodology are necessary because SIP allows a wide range of configurations and operational conditions that can influence performance benchmark measurements. |
|
| |
| RFC 7511 | Scenic Routing for IPv6 |
| |
| Authors: | M. Wilhelm. |
| Date: | 1 April 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7511 |
|
This document specifies a new routing scheme for the current version of the Internet Protocol version 6 (IPv6) in the spirit of "GreenIT", whereby packets will be routed to get as much fresh-air time as possible. |
|
| |
| RFC 7520 | Examples of Protecting Content Using JSON Object Signing and Encryption (JOSE) |
| |
| Authors: | M. Miller. |
| Date: | May 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7520 |
|
This document contains a set of examples using JSON Object Signing and Encryption (JOSE) technology to protect data. These examples present a representative sampling of JSON Web Key (JWK) objects as well as various JSON Web Signature (JWS) and JSON Web Encryption(JWE) results given similar inputs. |
|
| |
| RFC 7528 | A Uniform Resource Name (URN) Namespace for the Hybrid Broadcast Broadband TV (HbbTV) Association |
| |
| Authors: | P. Higgs, J. Piesing. |
| Date: | April 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7528 |
|
This document describes a Uniform Resource Name (URN) namespace for the Hybrid Broadcast Broadband TV (HbbTV) Association for naming persistent resources defined within HbbTV specifications. Example resources include technical documents and specifications, ExtensibleMarkup Language (XML) Schemas, classification schemes, XML DocumentType Definitions (DTDs), namespaces, style sheets, media assets, and other types of resources produced or managed by HbbTV. |
|
| |
| RFC 7534 | AS112 Nameserver Operations |
| |
|
|
Many sites connected to the Internet make use of IPv4 addresses that are not globally unique. Examples are the addresses designated inRFC 1918 for private use within individual sites.
Devices in such environments may occasionally originate Domain NameSystem (DNS) queries (so-called "reverse lookups") corresponding to those private-use addresses. Since the addresses concerned have only local significance, it is good practice for site administrators to ensure that such queries are answered locally. However, it is not uncommon for such queries to follow the normal delegation path in the public DNS instead of being answered within the site.
It is not possible for public DNS servers to give useful answers to such queries. In addition, due to the wide deployment of private-use addresses and the continuing growth of the Internet, the volume of such queries is large and growing. The AS112 project aims to provide a distributed sink for such queries in order to reduce the load on the corresponding authoritative servers. The AS112 project is named after the Autonomous System Number (ASN) that was assigned to it.
This document describes the steps required to install a new AS112 node and offers advice relating to such a node's operation.
This document obsoletes RFC 6304. |
|
| |
| RFC 7535 | AS112 Redirection Using DNAME |
| |
| Authors: | J. Abley, B. Dickson, W. Kumari, G. Michaelson. |
| Date: | May 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7535 |
|
AS112 provides a mechanism for handling reverse lookups on IP addresses that are not unique (e.g., RFC 1918 addresses). This document describes modifications to the deployment and use of AS112 infrastructure that will allow zones to be added and dropped much more easily, using DNAME resource records.
This approach makes it possible for any DNS zone administrator to sink traffic relating to parts of the global DNS namespace under their control to the AS112 infrastructure without coordination with the operators of AS112 infrastructure. |
|
| |
| RFC 7536 | Large-Scale Broadband Measurement Use Cases |
| |
| Authors: | M. Linsner, P. Eardley, T. Burbridge, F. Sorensen. |
| Date: | May 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7536 |
|
Measuring broadband performance on a large scale is important for network diagnostics by providers and users, as well as for public policy. Understanding the various scenarios and users of measuring broadband performance is essential to development of the Large-scaleMeasurement of Broadband Performance (LMAP) framework, information model, and protocol. This document details two use cases that can assist in developing that framework. The details of the measurement metrics themselves are beyond the scope of this document. |
|
| |
| RFC 7539 | ChaCha20 and Poly1305 for IETF Protocols |
| |
|
|
This document defines the ChaCha20 stream cipher as well as the use of the Poly1305 authenticator, both as stand-alone algorithms and as a "combined mode", or Authenticated Encryption with Associated Data(AEAD) algorithm.
This document does not introduce any new crypto, but is meant to serve as a stable reference and an implementation guide. It is a product of the Crypto Forum Research Group (CFRG). |
|
| |
| RFC 7544 | 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. |
|
| |
| RFC 7546 | Structure of the Generic Security Service (GSS) Negotiation Loop |
| |
| Authors: | B. Kaduk. |
| Date: | May 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7546 |
|
This document specifies the generic structure of the negotiation loop to establish a Generic Security Service (GSS) security context between initiator and acceptor. The control flow of the loop is indicated for both parties, including error conditions, and indications are given for where application-specific behavior must be specified. |
|
| |
| RFC 7547 | Management of Networks with Constrained Devices: Problem Statement and Requirements |
| |
| Authors: | M. Ersue, Ed., D. Romascanu, J. Schoenwaelder, U. Herberg. |
| Date: | May 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7547 |
|
This document provides a problem statement, deployment and management topology options, as well as requirements addressing the different use cases of the management of networks where constrained devices are involved. |
|
| |
| RFC 7548 | Management of Networks with Constrained Devices: Use Cases |
| |
| Authors: | M. Ersue, Ed., D. Romascanu, J. Schoenwaelder, A. Sehgal. |
| Date: | May 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7548 |
|
This document discusses use cases concerning the management of networks in which constrained devices are involved. A problem statement, deployment options, and the requirements on the networks with constrained devices can be found in the companion document on"Management of Networks with Constrained Devices: Problem Statement and Requirements" (RFC 7547). |
|
| |
| RFC 7553 | The Uniform Resource Identifier (URI) DNS Resource Record |
| |
| Authors: | P. Faltstrom, O. Kolkman. |
| Date: | June 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7553 |
|
This document describes the already registered DNS resource record(RR) type, called the Uniform Resource Identifier (URI) RR, that is used for publishing mappings from hostnames to URIs. |
|
| |
| RFC 7554 | Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the Internet of Things (IoT): Problem Statement |
| |
| Authors: | T. Watteyne, Ed., M. Palattella, L. Grieco. |
| Date: | May 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7554 |
|
This document describes the environment, problem statement, and goals for using the Time-Slotted Channel Hopping (TSCH) Medium AccessControl (MAC) protocol of IEEE 802.14.4e in the context of Low-Power and Lossy Networks (LLNs). The set of goals enumerated in this document form an initial set only. |
|
| |
| RFC 7556 | Multiple Provisioning Domain Architecture |
| |
| Authors: | D. Anipko, Ed.. |
| Date: | June 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7556 |
|
This document is a product of the work of the Multiple InterfacesArchitecture Design team. It outlines a solution framework for some of the issues experienced by nodes that can be attached to multiple networks simultaneously. The framework defines the concept of aProvisioning Domain (PvD), which is a consistent set of network configuration information. PvD-aware nodes learn PvD-specific information from the networks they are attached to and/or other sources. PvDs are used to enable separation and configuration consistency in the presence of multiple concurrent connections. |
|
| |
| RFC 7558 | Requirements for Scalable DNS-Based Service Discovery (DNS-SD) / Multicast DNS (mDNS) Extensions |
| |
| Authors: | K. Lynn, S. Cheshire, M. Blanchet, D. Migault. |
| Date: | July 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7558 |
|
DNS-based Service Discovery (DNS-SD) over Multicast DNS (mDNS) is widely used today for discovery and resolution of services and names on a local link, but there are use cases to extend DNS-SD/mDNS to enable service discovery beyond the local link. This document provides a problem statement and a list of requirements for scalableDNS-SD. |
|
| |
| RFC 7560 | Problem Statement and Requirements for Increased Accuracy in Explicit Congestion Notification (ECN) Feedback |
| |
| Authors: | M. Kuehlewind, Ed., R. Scheffenegger, B. Briscoe. |
| Date: | August 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7560 |
|
Explicit Congestion Notification (ECN) is a mechanism where network nodes can mark IP packets, instead of dropping them, to indicate congestion to the endpoints. An ECN-capable receiver will feed this information back to the sender. ECN is specified for TCP in such a way that it can only feed back one congestion signal per Round-TripTime (RTT). In contrast, ECN for other transport protocols, such asRTP/UDP and SCTP, is specified with more accurate ECN feedback.Recent new TCP mechanisms (like Congestion Exposure (ConEx) or DataCenter TCP (DCTCP)) need more accurate ECN feedback in the case where more than one marking is received in one RTT. This document specifies requirements for an update to the TCP protocol to provide more accurate ECN feedback. |
|
| |
| RFC 7561 | Mapping Quality of Service (QoS) Procedures of Proxy Mobile IPv6 (PMIPv6) and WLAN |
| |
| Authors: | J. Kaippallimalil, R. Pazhyannur, P. Yegani. |
| Date: | June 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7561 |
|
This document provides guidelines for achieving end-to-end Quality ofService (QoS) in a Proxy Mobile IPv6 (PMIPv6) domain where the access network is based on IEEE 802.11. RFC 7222 describes QoS negotiation between a Mobile Access Gateway (MAG) and Local Mobility Anchor (LMA) in a PMIPv6 mobility domain. The negotiated QoS parameters can be used for QoS policing and marking of packets to enforce QoS differentiation on the path between the MAG and LMA. IEEE 802.11 andWi-Fi Multimedia - Admission Control (WMM-AC) describe methods forQoS negotiation between a Wi-Fi Station (MN in PMIPv6 terminology) and an Access Point. This document provides a mapping between the above two sets of QoS procedures and the associated QoS parameters.This document is intended to be used as a companion document to RFC7222 to enable implementation of end-to-end QoS. |
|
| |
| RFC 7562 | Transport Layer Security (TLS) Authorization Using Digital Transmission Content Protection (DTCP) Certificates |
| |
|
|
This document specifies the use of Digital Transmission ContentProtection (DTCP) certificates as an authorization data type in the authorization extension for the Transport Layer Security (TLS) protocol. This is in accordance with the guidelines for authorization extensions as specified in RFC 5878. As with other TLS extensions, this authorization data can be included in the client and server hello messages to confirm that both parties support the desired authorization data types. If supported by both the client and the server, DTCP certificates are exchanged in the supplemental data TLS handshake message as specified in RFC 4680. This authorization data type extension is in support of devices containingDTCP certificates issued by the Digital Transmission LicensingAdministrator (DTLA). |
|
| |
| RFC 7575 | Autonomic Networking: Definitions and Design Goals |
| |
| Authors: | M. Behringer, M. Pritikin, S. Bjarnason, A. Clemm, B. Carpenter, S. Jiang, L. Ciavaglia. |
| Date: | June 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7575 |
|
Autonomic systems were first described in 2001. The fundamental goal is self-management, including self-configuration, self-optimization, self-healing, and self-protection. This is achieved by an autonomic function having minimal dependencies on human administrators or centralized management systems. It usually implies distribution across network elements.
This document defines common language and outlines design goals (and what are not design goals) for autonomic functions. A high-level reference model illustrates how functional elements in an AutonomicNetwork interact. This document is a product of the IRTF's NetworkManagement Research Group. |
|
| |
| RFC 7576 | General Gap Analysis for Autonomic Networking |
| |
| Authors: | S. Jiang, B. Carpenter, M. Behringer. |
| Date: | June 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7576 |
|
This document provides a problem statement and general gap analysis for an IP-based Autonomic Network that is mainly based on distributed network devices. The document provides background by reviewing the current status of autonomic aspects of IP networks and the extent to which current network management depends on centralization and human administrators. Finally, the document outlines the general features that are missing from current network abilities and are needed in the ideal Autonomic Network concept.
This document is a product of the IRTF's Network Management ResearchGroup. |
|
| |
| RFC 7583 | DNSSEC Key Rollover Timing Considerations |
| |
| Authors: | S. Morris, J. Ihren, J. Dickinson, W. Mekking. |
| Date: | October 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7583 |
|
This document describes the issues surrounding the timing of events in the rolling of a key in a DNSSEC-secured zone. It presents timelines for the key rollover and explicitly identifies the relationships between the various parameters affecting the process. |
|
| |
| RFC 7588 | A Widely Deployed Solution to the Generic Routing Encapsulation (GRE) Fragmentation Problem |
| |
| Authors: | R. Bonica, C. Pignataro, J. Touch. |
| Date: | July 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7588 |
|
This memo describes how many vendors have solved the Generic RoutingEncapsulation (GRE) fragmentation problem. The solution described herein is configurable. It is widely deployed on the Internet in its default configuration. |
|
| |
| RFC 7593 | The eduroam Architecture for Network Roaming |
| |
| Authors: | K. Wierenga, S. Winter, T. Wolniewicz. |
| Date: | September 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7593 |
|
This document describes the architecture of the eduroam service for federated (wireless) network access in academia. The combination ofIEEE 802.1X, the Extensible Authentication Protocol (EAP), and RADIUS that is used in eduroam provides a secure, scalable, and deployable service for roaming network access. The successful deployment of eduroam over the last decade in the educational sector may serve as an example for other sectors, hence this document. In particular, the initial architectural choices and selection of standards are described, along with the changes that were prompted by operational experience. |
|
| |
| RFC 7594 | A Framework for Large-Scale Measurement of Broadband Performance (LMAP) |
| |
| Authors: | P. Eardley, A. Morton, M. Bagnulo, T. Burbridge, P. Aitken, A. Akhter. |
| Date: | September 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7594 |
|
Measuring broadband service on a large scale requires a description of the logical architecture and standardisation of the key protocols that coordinate interactions between the components. This document presents an overall framework for large-scale measurements. It also defines terminology for LMAP (Large-Scale Measurement of BroadbandPerformance). |
|
| |
| RFC 7604 | Comparison of Different NAT Traversal Techniques for Media Controlled by the Real-Time Streaming Protocol (RTSP) |
| |
| Authors: | M. Westerlund, T. Zeng. |
| Date: | September 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7604 |
|
This document describes several Network Address Translator (NAT) traversal techniques that were considered to be used for establishing the RTP media flows controlled by the Real-Time Streaming Protocol(RTSP). Each technique includes a description of how it would be used, the security implications of using it, and any other deployment considerations it has. There are also discussions on how NAT traversal techniques relate to firewalls and how each technique can be applied in different use cases. These findings were used when selecting the NAT traversal for RTSP 2.0, which is specified in a separate document. |
|
| |
| RFC 7609 | IBM's Shared Memory Communications over RDMA (SMC-R) Protocol |
| |
| Authors: | M. Fox, C. Kassimis, J. Stevens. |
| Date: | August 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7609 |
|
This document describes IBM's Shared Memory Communications over RDMA(SMC-R) protocol. This protocol provides Remote Direct Memory Access(RDMA) communications to TCP endpoints in a manner that is transparent to socket applications. It further provides for dynamic discovery of partner RDMA capabilities and dynamic setup of RDMA connections, as well as transparent high availability and load balancing when redundant RDMA network paths are available. It maintains many of the traditional TCP/IP qualities of service such as filtering that enterprise users demand, as well as TCP socket semantics such as urgent data. |
|
| |
| RFC 7612 | Lightweight Directory Access Protocol (LDAP): Schema for Printer Services |
| |
|
|
This document defines a schema, object classes, and attributes, forPrinters and print services, for use with directories that support the Lightweight Directory Access Protocol (RFC 4510). This document is based on the Printer attributes listed in Appendix E of "InternetPrinting Protocol/1.1: Model and Semantics" (RFC 2911). AdditionalPrinter attributes are based on definitions in "Printer MIB v2" (RFC3805), "PWG Command Set Format for IEEE 1284 Device ID v1.0" (PWG5107.2), "IPP Job and Printer Extensions - Set 3 (JPS3)" (PWG5100.13), and "IPP Everywhere" (PWG 5100.14).
This memo is an Independent Submission to the RFC Editor by theInternet Printing Protocol (IPP) Working Group of the IEEE-ISTOPrinter Working Group (PWG), as part of their PWG "IPP Everywhere"(PWG 5100.14) project for secure mobile printing with vendor-neutralClient software.
This document obsoletes RFC 3712. |
|
| |
| RFC 7620 | Scenarios with Host Identification Complications |
| |
| Authors: | M. Boucadair, Ed., B. Chatras, T. Reddy, B. Williams, B. Sarikaya. |
| Date: | August 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7620 |
|
This document describes a set of scenarios in which complications when identifying which policy to apply for a host are encountered.This problem is abstracted as "host identification". Describing these scenarios allows commonalities between scenarios to be identified, which is helpful during the solution design phase.
This document does not include any solution-specific discussions. |
|
| |
| RFC 7624 | Confidentiality in the Face of Pervasive Surveillance: A Threat Model and Problem Statement |
| |
| Authors: | R. Barnes, B. Schneier, C. Jennings, T. Hardie, B. Trammell, C. Huitema, D. Borkmann. |
| Date: | August 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7624 |
|
Since the initial revelations of pervasive surveillance in 2013, several classes of attacks on Internet communications have been discovered. In this document, we develop a threat model that describes these attacks on Internet confidentiality. We assume an attacker that is interested in undetected, indiscriminate eavesdropping. The threat model is based on published, verified attacks. |
|
| |
| RFC 7625 | Architecture of an IP/MPLS Network with Hardened Pipes |
| |
| Authors: | J. T. Hao, P. Maheshwari, R. Huang, L. Andersson, M. Chen. |
| Date: | August 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7625 |
|
This document describes an IP/MPLS network that has an infrastructure that can be separated into two or more strata. For the implementation described in this document, the infrastructure has been separated into two strata: one for the "Hard Pipes", called the"Hard Pipe Stratum", and one for the normal IP/MPLS traffic, called the "Normal IP/MPLS Stratum".
This document introduces the concept of a Hard Pipe -- an MPLS LabelSwitched Path (LSP) or a pseudowire (PW) with a bandwidth that is guaranteed and can neither be exceeded nor infringed upon.
The Hard Pipe stratum does not use statistical multiplexing; for theLSPs and PWs set up within this stratum, the bandwidth is guaranteed end to end.
The document does not specify any new protocol or procedures. It does explain how the MPLS standards implementation has been deployed and operated to meet the requirements from operators that offer traditional Virtual Leased Line (VLL) services. |
|
| |
| RFC 7626 | DNS Privacy Considerations |
| |
|
|
This document describes the privacy issues associated with the use of the DNS by Internet users. It is intended to be an analysis of the present situation and does not prescribe solutions. |
|
| |
| RFC 7632 | Endpoint Security Posture Assessment: Enterprise Use Cases |
| |
| Authors: | D. Waltermire, D. Harrington. |
| Date: | September 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7632 |
|
This memo documents a sampling of use cases for securely aggregating configuration and operational data and evaluating that data to determine an organization's security posture. From these operational use cases, we can derive common functional capabilities and requirements to guide development of vendor-neutral, interoperable standards for aggregating and evaluating data relevant to security posture. |
|
| |
| RFC 7637 | NVGRE: Network Virtualization Using Generic Routing Encapsulation |
| |
| Authors: | P. Garg, Ed., Y. Wang, Ed.. |
| Date: | September 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7637 |
|
This document describes the usage of the Generic RoutingEncapsulation (GRE) header for Network Virtualization (NVGRE) in multi-tenant data centers. Network Virtualization decouples virtual networks and addresses from physical network infrastructure, providing isolation and concurrency between multiple virtual networks on the same physical network infrastructure. This document also introduces a Network Virtualization framework to illustrate the use cases, but the focus is on specifying the data-plane aspect of NVGRE. |
|
| |
| RFC 7640 | Traffic Management Benchmarking |
| |
| Authors: | B. Constantine, R. Krishnan. |
| Date: | September 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7640 |
|
This framework describes a practical methodology for benchmarking the traffic management capabilities of networking devices (i.e., policing, shaping, etc.). The goals are to provide a repeatable test method that objectively compares performance of the device's traffic management capabilities and to specify the means to benchmark traffic management with representative application traffic. |
|
| |
| RFC 7642 | System for Cross-domain Identity Management: Definitions, Overview, Concepts, and Requirements |
| |
| Authors: | K. LI, Ed., P. Hunt, B. Khasnabish, A. Nadalin, Z. Zeltsan. |
| Date: | September 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7642 |
|
This document provides definitions and an overview of the System forCross-domain Identity Management (SCIM). It lays out the system's concepts, models, and flows, and it includes user scenarios, use cases, and requirements. |
|
| |
| RFC 7645 | The Keying and Authentication for Routing Protocol (KARP) IS-IS Security Analysis |
| |
| Authors: | U. Chunduri, A. Tian, W. Lu. |
| Date: | September 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7645 |
|
This document analyzes the current state of the Intermediate System to Intermediate System (IS-IS) protocol according to the requirements set forth in "Keying and Authentication for Routing Protocols (KARP)Design Guidelines" (RFC 6518) for both manual and automated key management protocols. |
|
| |
| RFC 7646 | Definition and Use of DNSSEC Negative Trust Anchors |
| |
| Authors: | P. Ebersman, W. Kumari, C. Griffiths, J. Livingood, R. Weber. |
| Date: | September 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7646 |
|
DNS Security Extensions (DNSSEC) is now entering widespread deployment. However, domain signing tools and processes are not yet as mature and reliable as those for non-DNSSEC-related domain administration tools and processes. This document defines NegativeTrust Anchors (NTAs), which can be used to mitigate DNSSEC validation failures by disabling DNSSEC validation at specified domains. |
|
| |
| RFC 7649 | The Jabber Scribe Role at IETF Meetings |
| |
| Authors: | P. Saint-Andre, D. York. |
| Date: | September 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7649 |
|
During IETF meetings, individual volunteers often help sessions run more smoothly by relaying information back and forth between the physical meeting room and an associated textual chatroom. Such volunteers are commonly called "Jabber scribes". This document summarizes experience with the Jabber scribe role and provides some suggestions for fulfilling the role at IETF meetings. |
|
| |
| RFC 7651 | 3GPP IP Multimedia Subsystems (IMS) Option for the Internet Key Exchange Protocol Version 2 (IKEv2) |
| |
| Authors: | A. Dodd-Noble, S. Gundavelli, J. Korhonen, F. Baboescu, B. Weis. |
| Date: | September 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7651 |
|
This document defines two new configuration attributes for theInternet Key Exchange Protocol version 2 (IKEv2). These attributes can be used for carrying the IPv4 address and IPv6 address of theProxy-Call Session Control Function (P-CSCF). When an IPsec gateway delivers these attributes to an IPsec client, the IPsec client can obtain the IPv4 and/or IPv6 address of the P-CSCF server located in the 3GPP network. |
|
| |
| RFC 7654 | Benchmarking Methodology for In-Service Software Upgrade (ISSU) |
| |
| Authors: | S. Banks, F. Calabria, G. Czirjak, R. Machat. |
| Date: | October 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7654 |
|
Modern forwarding devices attempt to minimize any control- and data- plane disruptions while performing planned software changes by implementing a technique commonly known as In-Service SoftwareUpgrade (ISSU). This document specifies a set of common methodologies and procedures designed to characterize the overall behavior of a Device Under Test (DUT), subject to an ISSU event. |
|
| |
| RFC 7656 | A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources |
| |
| Authors: | J. Lennox, K. Gross, S. Nandakumar, G. Salgueiro, B. Burman, Ed.. |
| Date: | November 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7656 |
|
The terminology about, and associations among, Real-time TransportProtocol (RTP) sources can be complex and somewhat opaque. This document describes a number of existing and proposed properties and relationships among RTP sources and defines common terminology for discussing protocol entities and their relationships. |
|
| |
| RFC 7657 | Differentiated Services (Diffserv) and Real-Time Communication |
| |
| Authors: | D. Black, Ed., P. Jones. |
| Date: | November 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7657 |
|
This memo describes the interaction between Differentiated Services(Diffserv) network quality-of-service (QoS) functionality and real- time network communication, including communication based on theReal-time Transport Protocol (RTP). Diffserv is based on network nodes applying different forwarding treatments to packets whose IP headers are marked with different Diffserv Codepoints (DSCPs).WebRTC applications, as well as some conferencing applications, have begun using the Session Description Protocol (SDP) bundle negotiation mechanism to send multiple traffic streams with different QoS requirements using the same network 5-tuple. The results of using multiple DSCPs to obtain different QoS treatments within a single network 5-tuple have transport protocol interactions, particularly with congestion control functionality (e.g., reordering). In addition, DSCP markings may be changed or removed between the traffic source and destination. This memo covers the implications of theseDiffserv aspects for real-time network communication, includingWebRTC. |
|
| |
| RFC 7663 | Report from the IAB Workshop on Stack Evolution in a Middlebox Internet (SEMI) |
| |
| Authors: | B. Trammell, Ed., M. Kuehlewind, Ed.. |
| Date: | October 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7663 |
|
The Internet Architecture Board (IAB) through its IP Stack Evolution program, the Internet Society, and the Swiss Federal Institute ofTechnology (ETH) Zurich hosted the Stack Evolution in a MiddleboxInternet (SEMI) workshop in Zurich on 26-27 January 2015 to explore the ability to evolve the transport layer in the presence of middlebox- and interface-related ossification of the stack. The goal of the workshop was to produce architectural and engineering guidance on future work to break the logjam, focusing on incrementally deployable approaches with clear incentives to deployment both on the endpoints (in new transport layers and applications) as well as on middleboxes (run by network operators). This document summarizes the contributions to the workshop and provides an overview of the discussion at the workshop, as well as the outcomes and next steps identified by the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions. |
|
| |
| RFC 7664 | Dragonfly Key Exchange |
| |
| Authors: | D. Harkins, Ed.. |
| Date: | November 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7664 |
|
This document specifies a key exchange using discrete logarithm cryptography that is authenticated using a password or passphrase.It is resistant to active attack, passive attack, and offline dictionary attack. This document is a product of the Crypto ForumResearch Group (CFRG). |
|
| |
| RFC 7665 | Service Function Chaining (SFC) Architecture |
| |
| Authors: | J. Halpern, Ed., C. Pignataro, Ed.. |
| Date: | October 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7665 |
|
This document describes an architecture for the specification, creation, and ongoing maintenance of Service Function Chains (SFCs) in a network. It includes architectural concepts, principles, and components used in the construction of composite services through deployment of SFCs, with a focus on those to be standardized in theIETF. This document does not propose solutions, protocols, or extensions to existing protocols. |
|
| |
| RFC 7667 | RTP Topologies |
| |
| Authors: | M. Westerlund, S. Wenger. |
| Date: | November 2015 |
| Formats: | txt json html |
| Obsoletes: | RFC 5117 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7667 |
|
This document discusses point-to-point and multi-endpoint topologies used in environments based on the Real-time Transport Protocol (RTP).In particular, centralized topologies commonly employed in the video conferencing industry are mapped to the RTP terminology.
This document is updated with additional topologies and replaces RFC5117. |
|
| |
| RFC 7669 | Assigning Digital Object Identifiers to RFCs |
| |
| Authors: | J. Levine. |
| Date: | October 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7669 |
|
This document describes the way that Digital Object Identifiers(DOIs) are assigned to past and future RFCs. The DOI is a widely used system that assigns unique identifiers to digital documents that can be queried and managed in a consistent fashion. |
|
| |
| RFC 7681 | Email Exchange of Secondary School Transcripts |
| |
| Authors: | J. Davin. |
| Date: | October 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7681 |
|
A common format simplifies exchange of secondary school academic transcripts via electronic mail. Existing standards are applied to prevent unauthorized alteration of transcript content and to deliver transcripts directly and securely from each student to his or her chosen recipients. By eliminating third-party intervention and surveillance, the defined protocol better protects student privacy and independence than does current practice. |
|
| |
| RFC 7682 | Considerations for Internet Routing Registries (IRRs) and Routing Policy Configuration |
| |
| Authors: | D. McPherson, S. Amante, E. Osterweil, L. Blunk, D. Mitchell. |
| Date: | December 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7682 |
|
The purpose of this document is to catalog issues that influenced the efficacy of Internet Routing Registries (IRRs) for inter-domain routing policy specification and application in the global routing system over the past two decades. Additionally, it provides a discussion regarding which of these issues are still problematic in practice, and which are simply artifacts that are no longer applicable but continue to stifle inter-provider policy-based filtering adoption and IRR utility to this day. |
|
| |
| RFC 7687 | Report from the Strengthening the Internet (STRINT) Workshop |
| |
| Authors: | S. Farrell, R. Wenning, B. Bos, M. Blanchet, H. Tschofenig. |
| Date: | December 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7687 |
|
The Strengthening the Internet (STRINT) workshop assembled one hundred participants in London for two days in early 2014 to discuss how the technical community, and in particular the IETF and the W3C, should react to Pervasive Monitoring and more generally how to strengthen the Internet in the face of such attacks. The discussions covered issues of terminology, the role of user interfaces, classes of mitigation, some specific use cases, transition strategies(including opportunistic encryption), and more. The workshop ended with a few high-level recommendations, that it is believed could be implemented and could help strengthen the Internet. This is the report of that workshop.
Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions. |
|
| |
| RFC 7690 | Close Encounters of the ICMP Type 2 Kind (Near Misses with ICMPv6 Packet Too Big (PTB)) |
| |
| Authors: | M. Byerly, M. Hite, J. Jaeggli. |
| Date: | January 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7690 |
|
This document calls attention to the problem of delivering ICMPv6 type 2 "Packet Too Big" (PTB) messages to the intended destination(typically the server) in ECMP load-balanced or anycast network architectures. It discusses operational mitigations that can be employed to address this class of failures. |
|
| |
| RFC 7693 | The BLAKE2 Cryptographic Hash and Message Authentication Code (MAC) |
| |
| Authors: | M-J. Saarinen, Ed., J-P. Aumasson. |
| Date: | November 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7693 |
|
This document describes the cryptographic hash function BLAKE2 and makes the algorithm specification and C source code conveniently available to the Internet community. BLAKE2 comes in two main flavors: BLAKE2b is optimized for 64-bit platforms and BLAKE2s for smaller architectures. BLAKE2 can be directly keyed, making it functionally equivalent to a Message Authentication Code (MAC). |
|
| |
| RFC 7698 | Framework and Requirements for GMPLS-Based Control of Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks |
| |
| Authors: | O. Gonzalez de Dios, Ed., R. Casellas, Ed., F. Zhang, X. Fu, D. Ceccarelli, I. Hussain. |
| Date: | November 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7698 |
|
To allow efficient allocation of optical spectral bandwidth for systems that have high bit-rates, the International TelecommunicationUnion Telecommunication Standardization Sector (ITU-T) has extended its Recommendations G.694.1 and G.872 to include a new DenseWavelength Division Multiplexing (DWDM) grid by defining a set of nominal central frequencies, channel spacings, and the concept of the"frequency slot". In such an environment, a data-plane connection is switched based on allocated, variable-sized frequency ranges within the optical spectrum, creating what is known as a flexible grid(flexi-grid).
Given the specific characteristics of flexi-grid optical networks and their associated technology, this document defines a framework and the associated control-plane requirements for the application of the existing GMPLS architecture and control-plane protocols to the control of flexi-grid DWDM networks. The actual extensions to theGMPLS protocols will be defined in companion documents. |
|
| |
| RFC 7703 | Experience with Testing of Mapping of Address and Port Using Translation (MAP-T) |
| |
| Authors: | E. Cordeiro, R. Carnier, A. Moreiras. |
| Date: | November 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7703 |
|
This document describes the testing result of a network utilizing aMapping of Address and Port using Translation (MAP-T) double translation solution; it provides an overview of user applications' behavior with a shared IPv4 address.
The MAP-T software is from CERNET Center and the test environment is on the NIC.br network with real and virtualized machines. |
|
| |
| RFC 7704 | An IETF with Much Diversity and Professional Conduct |
| |
| Authors: | D. Crocker, N. Clark. |
| Date: | November 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7704 |
|
The process of producing today's Internet technologies through a culture of open participation and diverse collaboration has proved strikingly efficient and effective, and it is distinctive among standards organizations. During the early years of the IETF and its antecedent, participation was almost entirely composed of a small group of well-funded, American, white, male technicians, demonstrating a distinctive and challenging group dynamic, both in management and in personal interactions. In the case of the IETF, interaction style can often contain singularly aggressive behavior, often including singularly hostile tone and content. Groups with greater diversity make better decisions. Obtaining meaningful diversity requires more than generic good will and statements of principle. Many different behaviors can serve to reduce participant diversity or participation diversity. This document discusses IETF participation in terms of the nature of diversity and practical issues that can increase or decrease it. The document represents the authors' assessments and recommendations, following general discussions of the issues in the IETF. |
|
| |
| RFC 7706 | Decreasing Access Time to Root Servers by Running One on Loopback |
| |
| Authors: | W. Kumari, P. Hoffman. |
| Date: | November 2015 |
| Formats: | txt json html |
| Obsoleted by: | RFC 8806 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7706 |
|
Some DNS recursive resolvers have longer-than-desired round-trip times to the closest DNS root server. Some DNS recursive resolver operators want to prevent snooping of requests sent to DNS root servers by third parties. Such resolvers can greatly decrease the round-trip time and prevent observation of requests by running a copy of the full root zone on a loopback address (such as 127.0.0.1).This document shows how to start and maintain such a copy of the root zone that does not pose a threat to other users of the DNS, at the cost of adding some operational fragility for the operator. |
|
| |
| RFC 7707 | Network Reconnaissance in IPv6 Networks |
| |
|
|
IPv6 offers a much larger address space than that of its IPv4 counterpart. An IPv6 subnet of size /64 can (in theory) accommodate approximately 1.844 * 10^19 hosts, thus resulting in a much lower host density (#hosts/#addresses) than is typical in IPv4 networks, where a site typically has 65,000 or fewer unique addresses. As a result, it is widely assumed that it would take a tremendous effort to perform address-scanning attacks against IPv6 networks; therefore,IPv6 address-scanning attacks have been considered unfeasible. This document formally obsoletes RFC 5157, which first discussed this assumption, by providing further analysis on how traditional address- scanning techniques apply to IPv6 networks and exploring some additional techniques that can be employed for IPv6 network reconnaissance. |
|
| |
| RFC 7709 | Requirements for Very Fast Setup of GMPLS Label Switched Paths (LSPs) |
| |
| Authors: | A. Malis, Ed., B. Wilson, G. Clapp, V. Shukla. |
| Date: | November 2015 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7709 |
|
Establishment and control of Label Switch Paths (LSPs) have become mainstream tools of commercial and government network providers. One of the elements of further evolving such networks is scaling their performance in terms of LSP bandwidth and traffic loads, LSP intensity (e.g., rate of LSP creation, deletion, and modification),LSP set up delay, quality-of-service differentiation, and different levels of resilience.
The goal of this document is to present target scaling objectives and the related protocol requirements for Generalized Multi-ProtocolLabel Switching (GMPLS). |
|
| |
| RFC 7713 | Congestion Exposure (ConEx) Concepts, Abstract Mechanism, and Requirements |
| |
| Authors: | M. Mathis, B. Briscoe. |
| Date: | December 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7713 |
|
This document describes an abstract mechanism by which senders inform the network about the congestion recently encountered by packets in the same flow. Today, network elements at any layer may signal congestion to the receiver by dropping packets or by ExplicitCongestion Notification (ECN) markings, and the receiver passes this information back to the sender in transport-layer feedback. The mechanism described here enables the sender to also relay this congestion information back into the network in-band at the IP layer, such that the total amount of congestion from all elements on the path is revealed to all IP elements along the path, where it could, for example, be used to provide input to traffic management. This mechanism is called Congestion Exposure, or ConEx. The companion document, "Congestion Exposure (ConEx) Concepts and Use Cases"(RFC 6789), provides the entry point to the set of ConEx documentation. |
|
| |
| RFC 7719 | DNS Terminology |
| |
| Authors: | P. Hoffman, A. Sullivan, K. Fujiwara. |
| Date: | December 2015 |
| Formats: | txt html json |
| Obsoleted by: | RFC 8499 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7719 |
|
The DNS is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has sometimes changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document. |
|
| |
| RFC 7721 | Security and Privacy Considerations for IPv6 Address Generation Mechanisms |
| |
| Authors: | A. Cooper, F. Gont, D. Thaler. |
| Date: | March 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7721 |
|
This document discusses privacy and security considerations for several IPv6 address generation mechanisms, both standardized and non-standardized. It evaluates how different mechanisms mitigate different threats and the trade-offs that implementors, developers, and users face in choosing different addresses or address generation mechanisms. |
|
| |
| RFC 7732 | Forwarder Policy for Multicast with Admin-Local Scope in the Multicast Protocol for Low-Power and Lossy Networks (MPL) |
| |
| Authors: | P. van der Stok, R. Cragie. |
| Date: | February 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7732 |
|
The purpose of this document is to specify an automated policy for the routing of Multicast Protocol for Low-Power and Lossy Networks(MPL) multicast messages with Admin-Local scope in a border router. |
|
| |
| RFC 7735 | Tracking Reviews of Documents |
| |
| Authors: | R. Sparks, T. Kivinen. |
| Date: | January 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7735 |
|
Several review teams ensure specific types of review are performed onInternet-Drafts as they progress towards becoming RFCs. The tools used by these teams to assign and track reviews would benefit from tighter integration to the Datatracker. This document discusses requirements for improving those tools without disrupting current work flows. |
|
| |
| RFC 7736 | Content Delivery Network Interconnection (CDNI) Media Type Registration |
| |
| Authors: | K. Ma. |
| Date: | December 2015 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7736 |
|
This document defines the standard media type used by the ContentDelivery Network Interconnection (CDNI) protocol suite, including the registration procedure and recommended usage of the required payload- type parameter. |
|
| |
| RFC 7738 | A Uniform Resource Name (URN) Namespace for the Consultative Committee for Space Data Systems (CCSDS) |
| |
| Authors: | M. Blanchet, A. Schiltknecht, P. Shames. |
| Date: | January 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7738 |
|
This document describes a Uniform Resource Name (URN) namespace intended for persistently and uniquely naming resources published by the Consultative Committee for Space Data Systems (CCSDS). |
|
| |
| RFC 7739 | Security Implications of Predictable Fragment Identification Values |
| |
| Authors: | F. Gont. |
| Date: | February 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7739 |
|
IPv6 specifies the Fragment Header, which is employed for the fragmentation and reassembly mechanisms. The Fragment Header contains an "Identification" field that, together with the IPv6Source Address and the IPv6 Destination Address of a packet, identifies fragments that correspond to the same original datagram, such that they can be reassembled together by the receiving host.The only requirement for setting the Identification field is that the corresponding value must be different than that employed for any other fragmented datagram sent recently with the same Source Address and Destination Address. Some implementations use a simple global counter for setting the Identification field, thus leading to predictable Identification values. This document analyzes the security implications of predictable Identification values, and provides implementation guidance for setting the Identification field of the Fragment Header, such that the aforementioned security implications are mitigated. |
|
| |
| RFC 7744 | Use Cases for Authentication and Authorization in Constrained Environments |
| |
| Authors: | L. Seitz, Ed., S. Gerdes, Ed., G. Selander, M. Mani, S. Kumar. |
| Date: | January 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7744 |
|
Constrained devices are nodes with limited processing power, storage space, and transmission capacities. In many cases, these devices do not provide user interfaces, and they are often intended to interact without human intervention.
This document includes a collection of representative use cases for authentication and authorization in constrained environments. These use cases aim at identifying authorization problems that arise during the life cycle of a constrained device and are intended to provide a guideline for developing a comprehensive authentication and authorization solution for this class of scenarios.
Where specific details are relevant, it is assumed that the devices use the Constrained Application Protocol (CoAP) as a communication protocol. However, most conclusions apply generally. |
|
| |
| RFC 7745 | XML Schemas for Reverse DNS Management |
| |
| Authors: | T. Manderson. |
| Date: | January 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7745 |
|
This document defines an Extensible Markup Language (XML) schema for reverse DNS management in a tightly controlled Representational StateTransfer (REST) environment. This document describes a schema that has been developed and deployed by ICANN in a "RESTful" system since2011 and is being used by the registries responsible for reverse DNS(rDNS) delegations underneath IN-ADDR.ARPA and IP6.ARPA through anHTTPS transaction that is mediated by an X.509 certificate. |
|
| |
| RFC 7747 | Basic BGP Convergence Benchmarking Methodology for Data-Plane Convergence |
| |
| Authors: | R. Papneja, B. Parise, S. Hares, D. Lee, I. Varlashkin. |
| Date: | April 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7747 |
|
BGP is widely deployed and used by several service providers as the default inter-AS (Autonomous System) routing protocol. It is of utmost importance to ensure that when a BGP peer or a downstream link of a BGP peer fails, the alternate paths are rapidly used and routes via these alternate paths are installed. This document provides the basic BGP benchmarking methodology using existing BGP convergence terminology as defined in RFC 4098. |
|
| |
| RFC 7748 | Elliptic Curves for Security |
| |
| Authors: | A. Langley, M. Hamburg, S. Turner. |
| Date: | January 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7748 |
|
This memo specifies two elliptic curves over prime fields that offer a high level of practical security in cryptographic applications, including Transport Layer Security (TLS). These curves are intended to operate at the ~128-bit and ~224-bit security level, respectively, and are generated deterministically based on a list of required properties. |
|
| |
| RFC 7749 | The "xml2rfc" Version 2 Vocabulary |
| |
|
|
This document defines the "xml2rfc" version 2 vocabulary: an XML- based language used for writing RFCs and Internet-Drafts.
Version 2 represents the state of the vocabulary (as implemented by several tools and as used by the RFC Editor) around 2014.
This document obsoletes RFC 2629. |
|
| |
| RFC 7754 | Technical Considerations for Internet Service Blocking and Filtering |
| |
| Authors: | R. Barnes, A. Cooper, O. Kolkman, D. Thaler, E. Nordmark. |
| Date: | March 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7754 |
|
The Internet is structured to be an open communications medium. This openness is one of the key underpinnings of Internet innovation, but it can also allow communications that may be viewed as undesirable by certain parties. Thus, as the Internet has grown, so have mechanisms to limit the extent and impact of abusive or objectionable communications. Recently, there has been an increasing emphasis on"blocking" and "filtering", the active prevention of such communications. This document examines several technical approaches to Internet blocking and filtering in terms of their alignment with the overall Internet architecture. When it is possible to do so, the approach to blocking and filtering that is most coherent with theInternet architecture is to inform endpoints about potentially undesirable services, so that the communicants can avoid engaging in abusive or objectionable communications. We observe that certain filtering and blocking approaches can cause unintended consequences to third parties, and we discuss the limits of efficacy of various approaches. |
|
| |
| RFC 7755 | SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Center Environments |
| |
| Authors: | T. Anderson. |
| Date: | February 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7755 |
|
This document describes the use of the Stateless IP/ICMP TranslationAlgorithm (SIIT) in an IPv6 Internet Data Center (IDC). In this deployment model, traffic from legacy IPv4-only clients on theInternet is translated to IPv6 upon reaching the IDC operator's network infrastructure. From that point on, it may be treated the same as traffic from native IPv6 end users. The IPv6 endpoints may be numbered using arbitrary (non-IPv4-translatable) IPv6 addresses.This facilitates a single-stack IPv6-only network infrastructure, as well as efficient utilization of public IPv4 addresses.
The primary audience is IDC operators who are deploying IPv6, running out of available IPv4 addresses, and/or feeling that dual stack causes undesirable operational complexity. |
|
| |
| RFC 7756 | Stateless IP/ICMP Translation for IPv6 Internet Data Center Environments (SIIT-DC): Dual Translation Mode |
| |
| Authors: | T. Anderson, S. Steffann. |
| Date: | February 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7756 |
|
This document describes an extension of the Stateless IP/ICMPTranslation for IPv6 Internet Data Center Environments (SIIT-DC) architecture, which allows applications, protocols, or nodes that are incompatible with IPv6 and/or Network Address Translation to operate correctly with SIIT-DC. This is accomplished by introducing a new component called an SIIT-DC Edge Relay, which reverses the translations made by an SIIT-DC Border Relay. The application and/or node is thus provided with seemingly native IPv4 connectivity that provides end-to-end address transparency.
The reader is expected to be familiar with the SIIT-DC architecture described in RFC 7755. |
|
| |
| RFC 7760 | Statement of Work for Extensions to the IETF Datatracker for Author Statistics |
| |
| Authors: | R. Housley. |
| Date: | January 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7760 |
|
This is the Statement of Work (SOW) for extensions to the IETFDatatracker to provide statistics about RFCs and Internet-Drafts and their authors. |
|
| |
| RFC 7762 | Initial Assignment for the Content Security Policy Directives Registry |
| |
| Authors: | M. West. |
| Date: | January 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7762 |
|
This document establishes an Internet Assigned Number Authority(IANA) registry for Content Security Policy directives and populates that registry with the directives defined in the Content SecurityPolicy Level 2 specification. |
|
| |
| RFC 7763 | The text/markdown Media Type |
| |
| Authors: | S. Leonard. |
| Date: | March 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7763 |
|
This document registers the text/markdown media type for use withMarkdown, a family of plain-text formatting syntaxes that optionally can be converted to formal markup languages such as HTML. |
|
| |
| RFC 7764 | Guidance on Markdown: Design Philosophies, Stability Strategies, and Select Registrations |
| |
| Authors: | S. Leonard. |
| Date: | March 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7764 |
|
This document elaborates upon the text/markdown media type for use with Markdown, a family of plain-text formatting syntaxes that optionally can be converted to formal markup languages such as HTML.Background information, local storage strategies, and additional syntax registrations are supplied. |
|
| |
| RFC 7767 | Application-Initiated Check-Pointing via the Port Control Protocol (PCP) |
| |
| Authors: | S. Vinapamula, S. Sivakumar, M. Boucadair, T. Reddy. |
| Date: | February 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7767 |
|
This document specifies a mechanism for a host to indicate via thePort Control Protocol (PCP) which connections should be protected against network failures. These connections will then be subject to high-availability mechanisms enabled on the network side.
This approach assumes that applications and/or users have more visibility about sensitive connections than any heuristic that can be enabled on the network side to guess which connections should be check-pointed. |
|
| |
| RFC 7768 | Port Management to Reduce Logging in Large-Scale NATs |
| |
| Authors: | T. Tsou, W. Li, T. Taylor, J. Huang. |
| Date: | January 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7768 |
|
Various IPv6 transition strategies require the introduction of large- scale NATs (e.g., AFTR and NAT64) to share the limited supply of IPv4 addresses available in the network until transition is complete.There has recently been debate over how to manage the sharing of ports between different subscribers sharing the same IPv4 address.One factor in the discussion is the operational requirement to log the assignment of transport addresses to subscribers. It has been argued that dynamic assignment of individual ports between subscribers requires the generation of an excessive volume of logs.This document suggests a way to achieve dynamic port sharing while keeping log volumes low. |
|
| |
| RFC 7778 | Mobile Communication Congestion Exposure Scenario |
| |
| Authors: | D. Kutscher, F. Mir, R. Winter, S. Krishnan, Y. Zhang, CJ. Bernardos. |
| Date: | March 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7778 |
|
This memo describes a mobile communications use case for congestion exposure (ConEx) with a particular focus on those mobile communication networks that are architecturally similar to the 3GPPEvolved Packet System (EPS). This memo provides a brief overview of the architecture of these networks (both access and core networks) and current QoS mechanisms and then discusses how congestion exposure concepts could be applied. Based on this discussion, this memo suggests a set of requirements for ConEx mechanisms that particularly apply to these mobile networks. |
|
| |
| RFC 7785 | Recommendations for Prefix Binding in the Context of Softwire Dual-Stack Lite |
| |
| Authors: | S. Vinapamula, M. Boucadair. |
| Date: | February 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7785 |
|
This document discusses issues induced by the change of the Dual-Stack Lite (DS-Lite) Basic Bridging BroadBand (B4) IPv6 address and sketches a set of recommendations to solve those issues. |
|
| |
| RFC 7789 | Impact of BGP Filtering on Inter-Domain Routing Policies |
| |
| Authors: | C. Cardona, P. Francois, P. Lucente. |
| Date: | April 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7789 |
|
This document describes how unexpected traffic flows can emerge across an autonomous system as the result of other autonomous systems filtering or restricting the propagation of more-specific prefixes.We provide a review of the techniques to detect the occurrence of this issue and defend against it. |
|
| |
| RFC 7790 | Mapping Characters for Classes of the Preparation, Enforcement, and Comparison of Internationalized Strings (PRECIS) |
| |
| Authors: | Y. Yoneya, T. Nemoto. |
| Date: | February 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7790 |
|
The framework for the preparation, enforcement, and comparison of internationalized strings (PRECIS) defines several classes of strings for use in application protocols. Because many protocols perform case-sensitive or case-insensitive string comparison, it is necessary to define methods for case mapping. In addition, both theInternationalized Domain Names in Applications (IDNA) and the PRECIS problem statement describe mappings for internationalized strings that are not limited to case, but include width mapping and mapping of delimiters and other special characters that can be taken into consideration. This document provides guidelines for designers ofPRECIS profiles and describes several mappings that can be applied between receiving user input and passing permitted code points to internationalized protocols. In particular, this document describes both locale-dependent and context-depending case mappings as well as additional mappings for delimiters and special characters. |
|
| |
| RFC 7799 | Active and Passive Metrics and Methods (with Hybrid Types In-Between) |
| |
| Authors: | A. Morton. |
| Date: | May 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7799 |
|
This memo provides clear definitions for Active and Passive performance assessment. The construction of Metrics and Methods can be described as either "Active" or "Passive". Some methods may use a subset of both Active and Passive attributes, and we refer to these as "Hybrid Methods". This memo also describes multiple dimensions to help evaluate new methods as they emerge. |
|
| |
| RFC 7801 | GOST R 34.12-2015: Block Cipher "Kuznyechik" |
| |
| Authors: | V. Dolmatov, Ed.. |
| Date: | March 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7801 |
|
This document is intended to be a source of information about theRussian Federal standard GOST R 34.12-2015 describing the block cipher with a block length of n=128 bits and a key length of k=256 bits, which is also referred to as "Kuznyechik". This algorithm is one of the set of Russian cryptographic standard algorithms (calledGOST algorithms). |
|
| |
| RFC 7805 | Moving Outdated TCP Extensions and TCP-Related Documents to Historic or Informational Status |
| |
| Authors: | A. Zimmermann, W. Eddy, L. Eggert. |
| Date: | April 2016 |
| Formats: | txt html json |
| Obsoletes: | RFC 0675, RFC 0721, RFC 0761, RFC 0813, RFC 0816, RFC 0879, RFC 0896, RFC 1078, RFC 6013 |
| Updates: | RFC 7414 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7805 |
|
This document reclassifies several TCP extensions and TCP-related documents that either have been superseded, have never seen widespread use, or are no longer recommended for use to "Historic" status. The affected documents are RFCs 675, 721, 761, 813, 816,879, 896, 1078, and 6013. Additionally, this document reclassifiesRFCs 700, 794, 814, 817, 872, 889, 964, and 1071 to "Informational" status. |
|
| |
| RFC 7806 | On Queuing, Marking, and Dropping |
| |
| Authors: | F. Baker, R. Pan. |
| Date: | April 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7806 |
|
This note discusses queuing and marking/dropping algorithms. While these algorithms may be implemented in a coupled manner, this note argues that specifications, measurements, and comparisons should decouple the different algorithms and their contributions to system behavior. |
|
| |
| RFC 7814 | Virtual Subnet: A BGP/MPLS IP VPN-Based Subnet Extension Solution |
| |
| Authors: | X. Xu, C. Jacquenet, R. Raszuk, T. Boyes, B. Fee. |
| Date: | March 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7814 |
|
This document describes a BGP/MPLS IP VPN-based subnet extension solution referred to as "Virtual Subnet", which can be used for building Layer 3 network virtualization overlays within and/or between data centers. |
|
| |
| RFC 7815 | Minimal Internet Key Exchange Version 2 (IKEv2) Initiator Implementation |
| |
| Authors: | T. Kivinen. |
| Date: | March 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7815 |
|
This document describes a minimal initiator version of the InternetKey Exchange version 2 (IKEv2) protocol for constrained nodes. IKEv2 is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs). IKEv2 includes several optional features, which are not needed in minimal implementations. This document describes what is required from the minimal implementation and also describes various optimizations that can be done. The protocol described here is interoperable with a full IKEv2 implementation using shared secret authentication (IKEv2 does not require the use of certificate authentication). This minimal initiator implementation can only talk to a full IKEv2 implementation acting as the responder; thus, two minimal initiator implementations cannot talk to each other.
This document does not update or modify RFC 7296 but provides a more compact description of the minimal version of the protocol. If this document and RFC 7296 conflict, then RFC 7296 is the authoritative description. |
|
| |
| RFC 7818 | URN Namespace for MEF Documents |
| |
| Authors: | M. Jethanandani. |
| Date: | March 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7818 |
|
This document describes the Namespace Identifier (NID) "mef" forUniform Resource Names (URNs) used to identify resources published byMEF Forum (https://www.mef.net). MEF specifies and manages resources that utilize this URN identification model. Management activities for these and other resources types are handled by the manager of theMEF Assigned Names and Numbers (MANN) registry. |
|
| |
| RFC 7819 | Privacy Considerations for DHCP |
| |
| Authors: | S. Jiang, S. Krishnan, T. Mrugalski. |
| Date: | April 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7819 |
|
DHCP is a protocol that is used to provide addressing and configuration information to IPv4 hosts. This document discusses the various identifiers used by DHCP and the potential privacy issues. |
|
| |
| RFC 7823 | Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions |
| |
| Authors: | A. Atlas, J. Drake, S. Giacalone, S. Previdi. |
| Date: | May 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7823 |
|
In certain networks, it is critical to consider network performance criteria when selecting the path for an explicitly routed RSVP-TELabel Switched Path (LSP). Such performance criteria can include latency, jitter, and loss or other indications such as the conformance to link performance objectives and non-RSVP TE traffic load. This specification describes how a path computation function may use network performance data, such as is advertised via the OSPF and IS-IS TE metric extensions (defined outside the scope of this document) to perform such path selections. |
|
| |
| RFC 7824 | Privacy Considerations for DHCPv6 |
| |
| Authors: | S. Krishnan, T. Mrugalski, S. Jiang. |
| Date: | May 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7824 |
|
DHCPv6 is a protocol that is used to provide addressing and configuration information to IPv6 hosts. This document describes the privacy issues associated with the use of DHCPv6 by Internet users.It is intended to be an analysis of the present situation and does not propose any solutions. |
|
| |
| RFC 7827 | The Role of the IRTF Chair |
| |
| Authors: | L. Eggert. |
| Date: | March 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7827 |
|
This document briefly describes the role of the Chair of the InternetResearch Task Force (IRTF), discusses its duties, and outlines the skill set a candidate for the role should ideally have. |
|
| |
| RFC 7831 | Application Bridging for Federated Access Beyond Web (ABFAB) Architecture |
| |
| Authors: | J. Howlett, S. Hartman, H. Tschofenig, J. Schaad. |
| Date: | May 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7831 |
|
Over the last decade, a substantial amount of work has occurred in the space of federated access management. Most of this effort has focused on two use cases: network access and web-based access.However, the solutions to these use cases that have been proposed and deployed tend to have few building blocks in common.
This memo describes an architecture that makes use of extensions to the commonly used security mechanisms for both federated and non- federated access management, including the Remote AuthenticationDial-In User Service (RADIUS), the Generic Security ServiceApplication Program Interface (GSS-API), the ExtensibleAuthentication Protocol (EAP), and the Security Assertion MarkupLanguage (SAML). The architecture addresses the problem of federated access management to primarily non-web-based services, in a manner that will scale to large numbers of Identity Providers, RelyingParties, and federations. |
|
| |
| RFC 7832 | Application Bridging for Federated Access Beyond Web (ABFAB) Use Cases |
| |
| Authors: | R. Smith, Ed.. |
| Date: | May 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7832 |
|
Federated identity is typically associated with web-based services at present, but there is growing interest in its application in non-web- based contexts. The goal of this memo is to document a selection of the wide variety of these contexts whose user experience could be improved through the use of technologies based on the ApplicationBridging for Federated Access Beyond web (ABFAB) architecture and specifications. |
|
| |
| RFC 7834 | Locator/ID Separation Protocol (LISP) Impact |
| |
| Authors: | D. Saucez, L. Iannone, A. Cabellos, F. Coras. |
| Date: | April 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7834 |
|
The Locator/ID Separation Protocol (LISP) aims to improve theInternet routing scalability properties by leveraging three principles: address role separation, encapsulation, and mapping. In this document, based on implementation work, deployment experiences, and theoretical studies, we discuss the impact that the deployment ofLISP can have on both the routing infrastructure and the end user. |
|
| |
| RFC 7835 | Locator/ID Separation Protocol (LISP) Threat Analysis |
| |
| Authors: | D. Saucez, L. Iannone, O. Bonaventure. |
| Date: | April 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7835 |
|
This document provides a threat analysis of the Locator/ID SeparationProtocol (LISP). |
|
| |
| RFC 7836 | Guidelines on the Cryptographic Algorithms to Accompany the Usage of Standards GOST R 34.10-2012 and GOST R 34.11-2012 |
| |
| Authors: | S. Smyshlyaev, Ed., E. Alekseev, I. Oshkin, V. Popov, S. Leontiev, V. Podobaev, D. Belyavsky. |
| Date: | March 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7836 |
|
The purpose of this document is to make the specifications of the cryptographic algorithms defined by the Russian national standardsGOST R 34.10-2012 and GOST R 34.11-2012 available to the Internet community for their implementation in the cryptographic protocols based on the accompanying algorithms.
These specifications define the pseudorandom functions, the key agreement algorithm based on the Diffie-Hellman algorithm and a hash function, the parameters of elliptic curves, the key derivation functions, and the key export functions. |
|
| |
| RFC 7841 | RFC Streams, Headers, and Boilerplates |
| |
| Authors: | J. Halpern, Ed., L. Daigle, Ed., O. Kolkman, Ed.. |
| Date: | May 2016 |
| Formats: | txt json html |
| Obsoletes: | RFC 5741 |
| Updated by: | RFC 9280 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7841 |
|
RFC documents contain a number of fixed elements such as the title page header, standard boilerplates, and copyright/IPR statements.This document describes them and introduces some updates to reflect current usage and requirements of RFC publication. In particular, this updated structure is intended to communicate clearly the source of RFC creation and review. This document obsoletes RFC 5741, moving detailed content to an IAB web page and preparing for more flexible output formats. |
|
| |
| RFC 7842 | Requirements for Improvements to the IETF Email List Archiving, Web-Based Browsing, and Search Tool |
| |
| Authors: | R. Sparks. |
| Date: | April 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7842 |
|
The web-based IETF email archive search tool based on the requirements captured in RFC 6778 was deployed in January 2014. This memo captures the requirements for a set of improvements that have been identified during its initial years of community use. |
|
| |
| RFC 7847 | Logical-Interface Support for IP Hosts with Multi-Access Support |
| |
| Authors: | T. Melia, Ed., S. Gundavelli, Ed.. |
| Date: | May 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7847 |
|
A logical interface is a software semantic internal to the host operating system. This semantic is available in all popular operating systems and is used in various protocol implementations.Logical-interface support is required on the mobile node attached to a Proxy Mobile IPv6 domain for leveraging various network-based mobility management features such as inter-technology handoffs, multihoming, and flow mobility support. This document explains the operational details of the logical-interface construct and the specifics on how link-layer implementations hide the physical interfaces from the IP stack and from the network nodes on the attached access networks. Furthermore, this document identifies the applicability of this approach to various link-layer technologies and analyzes the issues around it when used in conjunction with various mobility management features. |
|
| |
| RFC 7849 | An IPv6 Profile for 3GPP Mobile Devices |
| |
| Authors: | D. Binet, M. Boucadair, A. Vizdal, G. Chen, N. Heatley, R. Chandler, D. Michaud, D. Lopez, W. Haeffner. |
| Date: | May 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7849 |
|
This document defines a profile that is a superset of the connection to IPv6 cellular networks defined in the IPv6 for Third GenerationPartnership Project (3GPP) Cellular Hosts document. This document defines a profile that is a superset of the connections to IPv6 cellular networks defined in "IPv6 for Third Generation PartnershipProject (3GPP) Cellular Hosts" (RFC 7066).
Both mobile hosts and mobile devices with the capability to share their 3GPP mobile connectivity are in scope. |
|
| |
| RFC 7853 | A URN Namespace for Globus |
| |
| Authors: | S. Martin, S. Tuecke, B. McCollam, M. Lidman. |
| Date: | May 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7853 |
|
This document describes a URN (Uniform Resource Name) namespace to be used by Globus for naming persistent resources. |
|
| |
| RFC 7855 | Source Packet Routing in Networking (SPRING) Problem Statement and Requirements |
| |
| Authors: | S. Previdi, Ed., C. Filsfils, Ed., B. Decraene, S. Litkowski, M. Horneffer, R. Shakir. |
| Date: | May 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7855 |
|
The ability for a node to specify a forwarding path, other than the normal shortest path, that a particular packet will traverse, benefits a number of network functions. Source-based routing mechanisms have previously been specified for network protocols but have not seen widespread adoption. In this context, the term"source" means "the point at which the explicit route is imposed"; therefore, it is not limited to the originator of the packet (i.e., the node imposing the explicit route may be the ingress node of an operator's network).
This document outlines various use cases, with their requirements, that need to be taken into account by the Source Packet Routing inNetworking (SPRING) architecture for unicast traffic. Multicast use cases and requirements are out of scope for this document. |
|
| |
| RFC 7868 | Cisco's Enhanced Interior Gateway Routing Protocol (EIGRP) |
| |
| Authors: | D. Savage, J. Ng, S. Moore, D. Slice, P. Paluch, R. White. |
| Date: | May 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7868 |
|
This document describes the protocol design and architecture forEnhanced Interior Gateway Routing Protocol (EIGRP). EIGRP is a routing protocol based on Distance Vector technology. The specific algorithm used is called "DUAL", a Diffusing Update Algorithm as referenced in "Loop-Free Routing Using Diffusing Computations"(Garcia-Luna-Aceves 1993). The algorithm and procedures were researched, developed, and simulated by SRI International. |
|
| |
| RFC 7869 | The "vnc" URI Scheme |
| |
| Authors: | D. Warden, I. Iordanov. |
| Date: | May 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7869 |
|
Virtual Network Computing (VNC) software provides remote desktop functionality. This document describes a Uniform Resource Identifier(URI) scheme enabling the launch of VNC clients from other applications. The scheme specifies parameters useful in securely connecting clients with remote hosts. |
|
| |
| RFC 7871 | Client Subnet in DNS Queries |
| |
| Authors: | C. Contavalli, W. van der Gaast, D. Lawrence, W. Kumari. |
| Date: | May 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7871 |
|
This document describes an Extension Mechanisms for DNS (EDNS0) option that is in active use to carry information about the network that originated a DNS query and the network for which the subsequent response can be cached. Since it has some known operational and privacy shortcomings, a revision will be worked through the IETF for improvement. |
|
| |
| RFC 7872 | Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World |
| |
| Authors: | F. Gont, J. Linkova, T. Chown, W. Liu. |
| Date: | June 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7872 |
|
This document presents real-world data regarding the extent to which packets with IPv6 Extension Headers (EHs) are dropped in the Internet(as originally measured in August 2014 and later in June 2015, with similar results) and where in the network such dropping occurs. The aforementioned results serve as a problem statement that is expected to trigger operational advice on the filtering of IPv6 packets carrying IPv6 EHs so that the situation improves over time. This document also explains how the results were obtained, such that the corresponding measurements can be reproduced by other members of the community and repeated over time to observe changes in the handling of packets with IPv6 EHs. |
|
| |
| RFC 7875 | Additional WebRTC Audio Codecs for Interoperability |
| |
| Authors: | S. Proust, Ed.. |
| Date: | May 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7875 |
|
To ensure a baseline of interoperability between WebRTC endpoints, a minimum set of required codecs is specified. However, to maximize the possibility of establishing the session without the need for audio transcoding, it is also recommended to include in the offer other suitable audio codecs that are available to the browser.
This document provides some guidelines on the suitable codecs to be considered for WebRTC endpoints to address the use cases most relevant to interoperability. |
|
| |
| RFC 7882 | Seamless Bidirectional Forwarding Detection (S-BFD) Use Cases |
| |
| Authors: | S. Aldrin, C. Pignataro, G. Mirsky, N. Kumar. |
| Date: | July 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7882 |
|
This document describes various use cases for Seamless BidirectionalForwarding Detection (S-BFD) and provides requirements such that protocol mechanisms allow for simplified detection of forwarding failures.
These use cases support S-BFD, which is a simplified mechanism for using BFD with a large proportion of negotiation aspects eliminated, accelerating the establishment of a BFD session. The benefits ofS-BFD include quick provisioning, as well as improved control and flexibility for network nodes initiating path monitoring. |
|
| |
| RFC 7890 | Concepts and Terminology for Peer-to-Peer SIP (P2PSIP) |
| |
| Authors: | D. Bryan, P. Matthews, E. Shim, D. Willis, S. Dawkins. |
| Date: | June 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7890 |
|
This document defines concepts and terminology for using the SessionInitiation Protocol in a peer-to-peer environment where the traditional proxy-registrar and message-routing functions are replaced by a distributed mechanism. These mechanisms may be implemented using a Distributed Hash Table or other distributed data mechanism with similar external properties. This document includes a high-level view of the functional relationships between the network elements defined herein, a conceptual model of operations, and an outline of the related problems addressed by the P2PSIP working group, the REsource LOcation And Discovery (RELOAD) protocol, and theSIP usage document defined by the working group. |
|
| |
| RFC 7893 | Pseudowire Congestion Considerations |
| |
| Authors: | Y(J) Stein, D. Black, B. Briscoe. |
| Date: | June 2016 |
| Formats: | txt html pdf json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7893 |
|
Pseudowires (PWs) have become a common mechanism for tunneling traffic and may be found in unmanaged scenarios competing for network resources both with other PWs and with non-PW traffic, such as TCP/IP flows. Thus, it is worthwhile specifying under what conditions such competition is acceptable, i.e., the PW traffic does not significantly harm other traffic or contribute more than it should to congestion. We conclude that PWs transporting responsive traffic behave as desired without the need for additional mechanisms. For inelastic PWs (such as Time Division Multiplexing (TDM) PWs), we derive a bound under which such PWs consume no more network capacity than a TCP flow. For TDM PWs, we find that the level of congestion at which the PW can no longer deliver acceptable TDM service is never significantly greater, and is typically much lower, than this bound.Therefore, as long as the PW is shut down when it can no longer deliver acceptable TDM service, it will never do significantly more harm than even a single TCP flow. If the TDM service does not automatically shut down, a mechanism to block persistently unacceptable TDM pseudowires is required. |
|
| |
| RFC 7903 | Windows Image Media Types |
| |
| Authors: | S. Leonard. |
| Date: | September 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7903 |
|
This document registers media types for certain image formats promulgated in Microsoft Windows, namely image/wmf, image/x-wmf, image/emf, image/x-emf, and image/bmp for use with Windows Metafile,Enhanced Metafile, and Windows Bitmap formats. Originally designed for Microsoft Windows 2.0 and 3.0, these image files are intended to be portable between applications and devices, and they may contain both vector and raster graphics. |
|
| |
| RFC 7906 | NSA's Cryptographic Message Syntax (CMS) Key Management Attributes |
| |
| Authors: | P. Timmel, R. Housley, S. Turner. |
| Date: | June 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7906 |
|
This document defines key management attributes used by the NationalSecurity Agency (NSA). The attributes can appear in asymmetric and/or symmetric key packages as well as the Cryptographic MessageSyntax (CMS) content types that subsequently envelope the key packages. Key packages described in RFCs 5958 and 6031 are examples of where these attributes can be used. |
|
| |
| RFC 7908 | Problem Definition and Classification of BGP Route Leaks |
| |
| Authors: | K. Sriram, D. Montgomery, D. McPherson, E. Osterweil, B. Dickson. |
| Date: | June 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7908 |
|
A systemic vulnerability of the Border Gateway Protocol routing system, known as "route leaks", has received significant attention in recent years. Frequent incidents that result in significant disruptions to Internet routing are labeled route leaks, but to date a common definition of the term has been lacking. This document provides a working definition of route leaks while keeping in mind the real occurrences that have received significant attention.Further, this document attempts to enumerate (though not exhaustively) different types of route leaks based on observed events on the Internet. The aim is to provide a taxonomy that covers several forms of route leaks that have been observed and are of concern to the Internet user community as well as the network operator community. |
|
| |
| RFC 7910 | Interoperability between the Virtual Router Redundancy Protocol and PIM |
| |
| Authors: | W. Zhou. |
| Date: | June 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7910 |
|
This document introduces VRRP-aware PIM, a redundancy mechanism for the Protocol Independent Multicast (PIM) to interoperate with theVirtual Router Redundancy Protocol (VRRP). It allows PIM to trackVRRP state and to preserve multicast traffic upon failover in a redundant network with virtual routing groups enabled. The mechanism described in this document is based on Cisco IOS software implementation. |
|
| |
| RFC 7912 | Message Authorizing Email Header Field and Its Use for the Draft and Release Procedure |
| |
| Authors: | A. Melnikov. |
| Date: | June 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7912 |
|
This document describes a procedure for when a Military MessageHandling System (MMHS) message is composed by one user and is only released to the mail transfer system when one or more AuthorizingUsers authorize release of the message by adding theMMHS-Authorizing-Users header field. The resulting message can be optionally signed by the sender and/or reviewer, allowing recipients to verify both the original signature (if any) and the review signatures. |
|
| |
| RFC 7913 | P-Access-Network-Info ABNF Update |
| |
|
|
This document updates RFC 7315, by modifying the extension-access- info part of the P-Access-Network-Info header field Augmented Backus-Naur Form (ABNF), and by adding the following 'access-info' header field parameter values to the list of 'access-info' header field parameter values in the ABNF: 'operator-specific-GI' and'utran-sai-3gpp'. The values are defined in the ABNF but are not included in the list. |
|
| |
| RFC 7914 | The scrypt Password-Based Key Derivation Function |
| |
| Authors: | C. Percival, S. Josefsson. |
| Date: | August 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7914 |
|
This document specifies the password-based key derivation function scrypt. The function derives one or more secret keys from a secret string. It is based on memory-hard functions, which offer added protection against attacks using custom hardware. The document also provides an ASN.1 schema. |
|
| |
| RFC 7918 | Transport Layer Security (TLS) False Start |
| |
| Authors: | A. Langley, N. Modadugu, B. Moeller. |
| Date: | August 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7918 |
|
This document specifies an optional behavior of Transport LayerSecurity (TLS) client implementations, dubbed "False Start". It affects only protocol timing, not on-the-wire protocol data, and can be implemented unilaterally. A TLS False Start reduces handshake latency to one round trip. |
|
| |
| RFC 7920 | Problem Statement for the Interface to the Routing System |
| |
| Authors: | A. Atlas, Ed., T. Nadeau, Ed., D. Ward. |
| Date: | June 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7920 |
|
Traditionally, routing systems have implemented routing and signaling(e.g., MPLS) to control traffic forwarding in a network. Route computation has been controlled by relatively static policies that define link cost, route cost, or import and export routing policies.Requirements have emerged to more dynamically manage and program routing systems due to the advent of highly dynamic data-center networking, on-demand WAN services, dynamic policy-driven traffic steering and service chaining, the need for real-time security threat responsiveness via traffic control, and a paradigm of separating policy-based decision-making from the router itself. These requirements should allow controlling routing information and traffic paths and extracting network topology information, traffic statistics, and other network analytics from routing systems.
This document proposes meeting this need via an Interface to theRouting System (I2RS). |
|
| |
| RFC 7921 | An Architecture for the Interface to the Routing System |
| |
| Authors: | A. Atlas, J. Halpern, S. Hares, D. Ward, T. Nadeau. |
| Date: | June 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7921 |
|
This document describes the IETF architecture for a standard, programmatic interface for state transfer in and out of the Internet routing system. It describes the high-level architecture, the building blocks of this high-level architecture, and their interfaces, with particular focus on those to be standardized as part of the Interface to the Routing System (I2RS). |
|
| |
| RFC 7922 | Interface to the Routing System (I2RS) Traceability: Framework and Information Model |
| |
| Authors: | J. Clarke, G. Salgueiro, C. Pignataro. |
| Date: | June 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7922 |
|
This document describes a framework for traceability in the Interface to the Routing System (I2RS) and the information model for that framework. It specifies the motivation, requirements, and use cases, and defines an information model for recording interactions between elements implementing the I2RS protocol. This framework provides a consistent tracing interface for components implementing the I2RS architecture to record what was done, by which component, and when.It aims to improve the management of I2RS implementations, and can be used for troubleshooting, auditing, forensics, and accounting purposes. |
|
| |
| RFC 7923 | Requirements for Subscription to YANG Datastores |
| |
| Authors: | E. Voit, A. Clemm, A. Gonzalez Prieto. |
| Date: | June 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7923 |
|
This document provides requirements for a service that allows client applications to subscribe to updates of a YANG datastore. Based on criteria negotiated as part of a subscription, updates will be pushed to targeted recipients. Such a capability eliminates the need for periodic polling of YANG datastores by applications and fills a functional gap in existing YANG transports (i.e., NetworkConfiguration Protocol (NETCONF) and RESTCONF). Such a service can be summarized as a "pub/sub" service for YANG datastore updates.Beyond a set of basic requirements for the service, various refinements are addressed. These refinements include: periodicity of object updates, filtering out of objects underneath a requested a subtree, and delivery QoS guarantees. |
|
| |
| RFC 7927 | Information-Centric Networking (ICN) Research Challenges |
| |
| Authors: | D. Kutscher, Ed., S. Eum, K. Pentikousis, I. Psaras, D. Corujo, D. Saucez, T. Schmidt, M. Waehlisch. |
| Date: | July 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7927 |
|
This memo describes research challenges for Information-CentricNetworking (ICN), an approach to evolve the Internet infrastructure to directly support information distribution by introducing uniquely named data as a core Internet principle. Data becomes independent from location, application, storage, and means of transportation, enabling or enhancing a number of desirable features, such as security, user mobility, multicast, and in-network caching.Mechanisms for realizing these benefits is the subject of ongoing research in the IRTF and elsewhere. This document describes current research challenges in ICN, including naming, security, routing, system scalability, mobility management, wireless networking, transport services, in-network caching, and network management.
This document is a product of the IRTF Information-Centric NetworkingResearch Group (ICNRG). |
|
| |
| RFC 7928 | Characterization Guidelines for Active Queue Management (AQM) |
| |
| Authors: | N. Kuhn, Ed., P. Natarajan, Ed., N. Khademi, Ed., D. Ros. |
| Date: | July 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7928 |
|
Unmanaged large buffers in today's networks have given rise to a slew of performance issues. These performance issues can be addressed by some form of Active Queue Management (AQM) mechanism, optionally in combination with a packet-scheduling scheme such as fair queuing.This document describes various criteria for performing characterizations of AQM schemes that can be used in lab testing during development, prior to deployment. |
|
| |
| RFC 7932 | Brotli Compressed Data Format |
| |
| Authors: | J. Alakuijala, Z. Szabadka. |
| Date: | July 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7932 |
|
This specification defines a lossless compressed data format that compresses data using a combination of the LZ77 algorithm and Huffman coding, with efficiency comparable to the best currently available general-purpose compression methods. |
|
| |
| RFC 7933 | Adaptive Video Streaming over Information-Centric Networking (ICN) |
| |
| Authors: | C. Westphal, Ed., S. Lederer, D. Posch, C. Timmerer, A. Azgin, W. Liu, C. Mueller, A. Detti, D. Corujo, J. Wang, M. Montpetit, N. Murray. |
| Date: | August 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7933 |
|
This document considers the consequences of moving the underlying network architecture from the current Internet to an Information-Centric Networking (ICN) architecture on video distribution. As most of the traffic in future networks is expected to be video, we consider how to modify the existing video streaming mechanisms.Several important topics related to video distribution over ICN are presented. The wide range of scenarios covered includes the following: evolving Dynamic Adaptive Streaming over HTTP (DASH) to work over ICN and leverage the recent ISO/IEC Moving Picture ExpertsGroup (MPEG) standard, layering encoding over ICN, introducing distinct requirements for video using Peer-to-Peer (P2P) mechanisms, adapting the Peer-to-Peer Streaming Protocol (PPSP) for ICN, creating more stringent requirements over ICN because of delay constraints added by Internet Protocol Television (IPTV), and managing digital rights in ICN. Finally, in addition to considering how existing mechanisms would be impacted by ICN, this document lists some research issues to design ICN-specific video streaming mechanisms. |
|
| |
| RFC 7938 | Use of BGP for Routing in Large-Scale Data Centers |
| |
| Authors: | P. Lapukhov, A. Premji, J. Mitchell, Ed.. |
| Date: | August 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7938 |
|
Some network operators build and operate data centers that support over one hundred thousand servers. In this document, such data centers are referred to as "large-scale" to differentiate them from smaller infrastructures. Environments of this scale have a unique set of network requirements with an emphasis on operational simplicity and network stability. This document summarizes operational experience in designing and operating large-scale data centers using BGP as the only routing protocol. The intent is to report on a proven and stable routing design that could be leveraged by others in the industry. |
|
| |
| RFC 7943 | A Method for Generating Semantically Opaque Interface Identifiers (IIDs) with the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) |
| |
| Authors: | F. Gont, W. Liu. |
| Date: | September 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7943 |
|
This document describes a method for selecting IPv6 InterfaceIdentifiers that can be employed by Dynamic Host ConfigurationProtocol for IPv6 (DHCPv6) servers when leasing non-temporary IPv6 addresses to DHCPv6 clients. This method is a DHCPv6 server-side algorithm that does not require any updates to the existing DHCPv6 specifications. The aforementioned method results in stable addresses within each subnet, even in the presence of multiple DHCPv6 servers or DHCPv6 server reinstallments. It is a DHCPv6 variant of the method specified in RFC 7217 for IPv6 Stateless AddressAutoconfiguration. |
|
| |
| RFC 7945 | Information-Centric Networking: Evaluation and Security Considerations |
| |
| Authors: | K. Pentikousis, Ed., B. Ohlman, E. Davies, S. Spirou, G. Boggia. |
| Date: | September 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7945 |
|
This document presents a number of considerations regarding evaluating Information-Centric Networking (ICN) and sheds some light on the impact of ICN on network security. It also surveys the evaluation tools currently available to researchers in the ICN area and provides suggestions regarding methodology and metrics. |
|
| |
| RFC 7948 | Internet Exchange BGP Route Server Operations |
| |
| Authors: | N. Hilliard, E. Jasinska, R. Raszuk, N. Bakker. |
| Date: | September 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7948 |
|
The popularity of Internet Exchange Points (IXPs) brings new challenges to interconnecting networks. While bilateral External BGP(EBGP) sessions between exchange participants were historically the most common means of exchanging reachability information over an IXP, the overhead associated with this interconnection method causes serious operational and administrative scaling problems for IXP participants.
Multilateral interconnection using Internet route servers can dramatically reduce the administrative and operational overhead associated with connecting to IXPs; in some cases, route servers are used by IXP participants as their preferred means of exchanging routing information.
This document describes operational considerations for multilateral interconnections at IXPs. |
|
| |
| RFC 7958 | DNSSEC Trust Anchor Publication for the Root Zone |
| |
| Authors: | J. Abley, J. Schlyter, G. Bailey, P. Hoffman. |
| Date: | August 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7958 |
|
The root zone of the Domain Name System (DNS) has been cryptographically signed using DNS Security Extensions (DNSSEC).
In order to obtain secure answers from the root zone of the DNS usingDNSSEC, a client must configure a suitable trust anchor. This document describes the format and publication mechanisms IANA has used to distribute the DNSSEC trust anchors. |
|
| |
| RFC 7960 | Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email Flows |
| |
| Authors: | F. Martin, Ed., E. Lear, Ed., T. Draegen, Ed., E. Zwicky, Ed., K. Andersen, Ed.. |
| Date: | September 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7960 |
|
Domain-based Message Authentication, Reporting, and Conformance(DMARC) introduces a mechanism for expressing domain-level policies and preferences for email message validation, disposition, and reporting. However, the DMARC mechanism enables potentially disruptive interoperability issues when messages do not flow directly from the author's administrative domain to the final Recipients.Collectively, these email flows are referred to as "indirect email flows". This document describes these interoperability issues and presents possible methods for addressing them. |
|
| |
| RFC 7962 | Alternative Network Deployments: Taxonomy, Characterization, Technologies, and Architectures |
| |
| Authors: | J. Saldana, Ed., A. Arcia-Moret, B. Braem, E. Pietrosemoli, A. Sathiaseelan, M. Zennaro. |
| Date: | August 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7962 |
|
This document presents a taxonomy of a set of "Alternative NetworkDeployments" that emerged in the last decade with the aim of bringingInternet connectivity to people or providing a local communication infrastructure to serve various complementary needs and objectives.They employ architectures and topologies different from those of mainstream networks and rely on alternative governance and business models.
The document also surveys the technologies deployed in these networks, and their differing architectural characteristics, including a set of definitions and shared properties.
The classification considers models such as Community Networks,Wireless Internet Service Providers (WISPs), networks owned by individuals but leased out to network operators who use them as a low-cost medium to reach the underserved population, networks that provide connectivity by sharing wireless resources of the users, and rural utility cooperatives. |
|
| |
| RFC 7963 | RSVP-TE Extension for Additional Signal Types in G.709 Optical Transport Networks (OTNs) |
| |
| Authors: | Z. Ali, A. Bonfanti, M. Hartley, F. Zhang. |
| Date: | August 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7963 |
|
RFCs 4328 and 7139 provide signaling extensions in ResourceReserVation Protocol - Traffic Engineering (RSVP-TE) to control the full set of Optical Transport Network (OTN) features. However, these specifications do not cover the additional Optical channel Data Unit(ODU) containers defined in G.Sup43 (ODU1e, ODU3e1, and ODU3e2).This document defines new Signal Types for these additional containers. |
|
| |
| RFC 7966 | Security at the Attribute-Value Pair (AVP) Level for Non-neighboring Diameter Nodes: Scenarios and Requirements |
| |
| Authors: | H. Tschofenig, J. Korhonen, Ed., G. Zorn, K. Pillay. |
| Date: | September 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7966 |
|
This specification specifies requirements for providing Diameter security at the level of individual Attribute-Value Pairs (AVPs). |
|
| |
| RFC 7967 | Constrained Application Protocol (CoAP) Option for No Server Response |
| |
| Authors: | A. Bhattacharyya, S. Bandyopadhyay, A. Pal, T. Bose. |
| Date: | August 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7967 |
|
There can be machine-to-machine (M2M) scenarios where server responses to client requests are redundant. This kind of open-loop exchange (with no response path from the server to the client) may be desired to minimize resource consumption in constrained systems while updating many resources simultaneously or performing high-frequency updates. CoAP already provides Non-confirmable (NON) messages that are not acknowledged by the recipient. However, the request/response semantics still require the server to respond with a status code indicating "the result of the attempt to understand and satisfy the request", per RFC 7252.
This specification introduces a CoAP option called 'No-Response'.Using this option, the client can explicitly express to the server its disinterest in all responses against the particular request.This option also provides granular control to enable expression of disinterest to a particular response class or a combination of response classes. The server MAY decide to suppress the response by not transmitting it back to the client according to the value of theNo-Response option in the request. This option may be effective for both unicast and multicast requests. This document also discusses a few examples of applications that benefit from this option. |
|
| |
| RFC 7969 | Customizing DHCP Configuration on the Basis of Network Topology |
| |
| Authors: | T. Lemon, T. Mrugalski. |
| Date: | October 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7969 |
|
DHCP servers have evolved over the years to provide significant functionality beyond that described in the DHCP base specifications.One aspect of this functionality is support for context-specific configuration information. This memo describes some such features and explains their operation. |
|
| |
| RFC 7971 | Application-Layer Traffic Optimization (ALTO) Deployment Considerations |
| |
| Authors: | M. Stiemerling, S. Kiesel, M. Scharf, H. Seidel, S. Previdi. |
| Date: | October 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7971 |
|
Many Internet applications are used to access resources such as pieces of information or server processes that are available in several equivalent replicas on different hosts. This includes, but is not limited to, peer-to-peer file sharing applications. The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications that have to select one or several hosts from a set of candidates capable of providing a desired resource.This memo discusses deployment-related issues of ALTO. It addresses different use cases of ALTO such as peer-to-peer file sharing andContent Delivery Networks (CDNs) and presents corresponding examples.The document also includes recommendations for network administrators and application designers planning to deploy ALTO, such as recommendations on how to generate ALTO map information. |
|
| |
| RFC 7972 | Entertainment Identifier Registry (EIDR) URN Namespace Definition |
| |
|
|
Entertainment Identifier Registry (EIDR) Identifiers are used for the globally unique identification of motion picture and television content. This document defines the formal Uniform Resource Name(URN) Namespace Identifier (NID) for EIDR Identifiers.
This document obsoletes RFC 7302. |
|
| |
| RFC 7973 | Assignment of an Ethertype for IPv6 with Low-Power Wireless Personal Area Network (LoWPAN) Encapsulation |
| |
| Authors: | R. Droms, P. Duffy. |
| Date: | November 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7973 |
|
When carried over Layer 2 technologies such as Ethernet, IPv6 datagrams using Low-Power Wireless Personal Area Network (LoWPAN) encapsulation as defined in RFC 4944 must be identified so the receiver can correctly interpret the encoded IPv6 datagram. The IETF officially requested the assignment of an Ethertype for that purpose and this document reports that assignment. |
|
| |
| RFC 7976 | Updates to Private Header (P-Header) Extension Usage in Session Initiation Protocol (SIP) Requests and Responses |
| |
| Authors: | C. Holmberg, N. Biondic, G. Salgueiro. |
| Date: | September 2016 |
| Formats: | txt json html |
| Updates: | RFC 7315 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7976 |
|
The Third Generation Partnership Project (3GPP) has identified cases where different SIP private header extensions referred to as "P-" header fields, and defined in RFC 7315, need to be included in SIP requests and responses currently not allowed according to RFC 7315.This document updates RFC 7315, in order to allow inclusion of the affected "P-" header fields in such requests and responses.
This document also makes updates for RFC 7315 in order to fix misalignments that occurred when RFC 3455 was updated and obsoleted by RFC 7315. |
|
| |
| RFC 7979 | Response to the IANA Stewardship Transition Coordination Group (ICG) Request for Proposals on the IANA Protocol Parameters Registries |
| |
| Authors: | E. Lear, Ed., R. Housley, Ed.. |
| Date: | August 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7979 |
|
The U.S. National Telecommunications and Information Administration(NTIA) solicited a request from the Internet Corporation for AssignedNames and Numbers (ICANN) to propose how the NTIA should end its oversight of the Internet Assigned Numbers Authority (IANA) functions. After broad consultations, ICANN in turn created the IANAStewardship Transition Coordination Group. That group solicited proposals for the three major IANA functions: names, numbers, and protocol parameters. This document contains the IETF response to that solicitation for protocol parameters. It was included in an aggregate response to the NTIA alongside those for names and numbering resources that are being developed by their respective operational communities. A reference to that response may be found in the introduction, and additional correspondence is included in theAppendix. |
|
| |
| RFC 7980 | A Framework for Defining Network Complexity |
| |
| Authors: | M. Behringer, A. Retana, R. White, G. Huston. |
| Date: | October 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7980 |
|
Complexity is a widely used parameter in network design, yet there is no generally accepted definition of the term. Complexity metrics exist in a wide range of research papers, but most of these address only a particular aspect of a network, for example, the complexity of a graph or software. While it may be impossible to define a metric for overall network complexity, there is a desire to better understand the complexity of a network as a whole, as deployed today to provide Internet services. This document provides a framework to guide research on the topic of network complexity as well as some practical examples for trade-offs in networking.
This document summarizes the work of the IRTF's Network ComplexityResearch Group (NCRG) at the time of its closure. It does not present final results, but a snapshot of an ongoing activity, as a basis for future work. |
|
| |
| RFC 7985 | Security Threats to Simplified Multicast Forwarding (SMF) |
| |
| Authors: | J. Yi, T. Clausen, U. Herberg. |
| Date: | November 2016 |
| Formats: | txt html json |
| Updates: | RFC 7186 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7985 |
|
This document analyzes security threats to Simplified MulticastForwarding (SMF), including vulnerabilities of duplicate packet detection and relay set selection mechanisms. This document is not intended to propose solutions to the threats described.
In addition, this document updates RFC 7186 regarding threats to the relay set selection mechanisms using the Mobile Ad Hoc Network(MANET) Neighborhood Discovery Protocol (NHDP) (RFC 6130). |
|
| |
| RFC 7990 | RFC Format Framework |
| |
| Authors: | H. Flanagan. |
| Date: | December 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7990 |
|
In order to improve the readability of RFCs while supporting their archivability, the canonical format of the RFC Series will be transitioning from plain-text ASCII to XML using the xml2rfc version3 vocabulary; different publication formats will be rendered from that base document. With these changes comes an increase in complexity for authors, consumers, and the publisher of RFCs. This document serves as the framework that provides the problem statement, lays out a road map of the documents that capture the specific requirements, and describes the transition plan. |
|
| |
| RFC 7991 | The "xml2rfc" Version 3 Vocabulary |
| |
|
|
This document defines the "xml2rfc" version 3 vocabulary: anXML-based language used for writing RFCs and Internet-Drafts. It is heavily derived from the version 2 vocabulary that is also under discussion. This document obsoletes the v2 grammar described inRFC 7749. |
|
| |
| RFC 7992 | HTML Format for RFCs |
| |
| Authors: | J. Hildebrand, Ed., P. Hoffman. |
| Date: | December 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7992 |
|
In order to meet the evolving needs of the Internet community, the canonical format for RFCs is changing from a plain-text, ASCII-only format to an XML format that will, in turn, be rendered into several publication formats. This document defines the HTML format that will be rendered for an RFC or Internet-Draft. |
|
| |
| RFC 7993 | Cascading Style Sheets (CSS) Requirements for RFCs |
| |
| Authors: | H. Flanagan. |
| Date: | December 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7993 |
|
The HTML format for RFCs assigns style guidance to a Cascading StyleSheet (CSS) specifically defined for the RFC Series. The embedded, default CSS as included by the RFC Editor is expected to take into account accessibility needs and to be built along a responsive design model. This document describes the requirements for the default CSS used by the RFC Editor. The class names are based on the classes defined in "HTML for RFCs" (RFC 7992). |
|
| |
| RFC 7994 | Requirements for Plain-Text RFCs |
| |
| Authors: | H. Flanagan. |
| Date: | December 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7994 |
|
In 2013, after a great deal of community discussion, the decision was made to shift from the plain-text, ASCII-only canonical format forRFCs to XML as the canonical format with more human-readable formats rendered from that XML. The high-level requirements that informed this change were defined in RFC 6949, "RFC Series Format Requirements and Future Development". Plain text remains an important format for many in the IETF community, and it will be one of the publication formats rendered from the XML. This document outlines the rendering requirements for the plain-text RFC publication format. These requirements do not apply to plain-text RFCs published before the format transition. |
|
| |
| RFC 7995 | PDF Format for RFCs |
| |
| Authors: | T. Hansen, Ed., L. Masinter, M. Hardy. |
| Date: | December 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7995 |
|
This document discusses options and requirements for the PDF rendering of RFCs in the RFC Series, as outlined in RFC 6949. It also discusses the use of PDF for Internet-Drafts, and available or needed software tools for producing and working with PDF. |
|
| |
| RFC 7996 | SVG Drawings for RFCs: SVG 1.2 RFC |
| |
| Authors: | N. Brownlee. |
| Date: | December 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7996 |
|
This document specifies SVG 1.2 RFC -- an SVG profile for use in diagrams that may appear in RFCs -- and considers some of the issues concerning the creation and use of such diagrams. |
|
| |
| RFC 7997 | The Use of Non-ASCII Characters in RFCs |
| |
|
|
In order to support the internationalization of protocols and a more diverse Internet community, the RFC Series must evolve to allow for the use of non-ASCII characters in RFCs. While English remains the required language of the Series, the encoding of future RFCs will be in UTF-8, allowing for a broader range of characters than typically used in the English language. This document describes the RFC Editor requirements and gives guidance regarding the use of non-ASCII characters in RFCs.
This document updates RFC 7322. Please view this document in PDF form to see the full text. |
|
| |
| RFC 7998 | "xml2rfc" Version 3 Preparation Tool Description |
| |
| Authors: | P. Hoffman, J. Hildebrand. |
| Date: | December 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7998 |
|
This document describes some aspects of the "prep tool" that is expected to be created when the new xml2rfc version 3 specification is deployed. |
|
| |
| RFC 7999 | BLACKHOLE Community |
| |
| Authors: | T. King, C. Dietzel, J. Snijders, G. Doering, G. Hankins. |
| Date: | October 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 7999 |
|
This document describes the use of a well-known Border GatewayProtocol (BGP) community for destination-based blackholing in IP networks. This well-known advisory transitive BGP community named"BLACKHOLE" allows an origin Autonomous System (AS) to specify that a neighboring network should discard any traffic destined towards the tagged IP prefix. |
|
| |
| RFC 8009 | AES Encryption with HMAC-SHA2 for Kerberos 5 |
| |
| Authors: | M. Jenkins, M. Peck, K. Burgin. |
| Date: | October 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8009 |
|
This document specifies two encryption types and two corresponding checksum types for Kerberos 5. The new types use AES in CTS mode(CBC mode with ciphertext stealing) for confidentiality and HMAC with a SHA-2 hash for integrity. |
|
| |
| RFC 8014 | An Architecture for Data-Center Network Virtualization over Layer 3 (NVO3) |
| |
| Authors: | D. Black, J. Hudson, L. Kreeger, M. Lasserre, T. Narten. |
| Date: | December 2016 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8014 |
|
This document presents a high-level overview architecture for building data-center Network Virtualization over Layer 3 (NVO3) networks. The architecture is given at a high level, showing the major components of an overall system. An important goal is to divide the space into individual smaller components that can be implemented independently with clear inter-component interfaces and interactions. It should be possible to build and implement individual components in isolation and have them interoperate with other independently implemented components. That way, implementers have flexibility in implementing individual components and can optimize and innovate within their respective components without requiring changes to other components. |
|
| |
| RFC 8017 | PKCS #1: RSA Cryptography Specifications Version 2.2 |
| |
| Authors: | K. Moriarty, Ed., B. Kaliski, J. Jonsson, A. Rusch. |
| Date: | November 2016 |
| Formats: | txt json html |
| Obsoletes: | RFC 3447 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8017 |
|
This document provides recommendations for the implementation of public-key cryptography based on the RSA algorithm, covering cryptographic primitives, encryption schemes, signature schemes with appendix, and ASN.1 syntax for representing keys and for identifying the schemes.
This document represents a republication of PKCS #1 v2.2 from RSALaboratories' Public-Key Cryptography Standards (PKCS) series. By publishing this RFC, change control is transferred to the IETF.
This document also obsoletes RFC 3447. |
|
| |
| RFC 8018 | PKCS #5: Password-Based Cryptography Specification Version 2.1 |
| |
|
|
This document provides recommendations for the implementation of password-based cryptography, covering key derivation functions, encryption schemes, message authentication schemes, and ASN.1 syntax identifying the techniques.
This document represents a republication of PKCS #5 v2.1 from RSALaboratories' Public-Key Cryptography Standards (PKCS) series. By publishing this RFC, change control is transferred to the IETF.
This document also obsoletes RFC 2898. |
|
| |
| RFC 8021 | Generation of IPv6 Atomic Fragments Considered Harmful |
| |
| Authors: | F. Gont, W. Liu, T. Anderson. |
| Date: | January 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8021 |
|
This document discusses the security implications of the generation of IPv6 atomic fragments and a number of interoperability issues associated with IPv6 atomic fragments. It concludes that the aforementioned functionality is undesirable and thus documents the motivation for removing this functionality from an upcoming revision of the core IPv6 protocol specification (RFC 2460). |
|
| |
| RFC 8023 | Report from the Workshop and Prize on Root Causes and Mitigation of Name Collisions |
| |
| Authors: | M. Thomas, A. Mankin, L. Zhang. |
| Date: | November 2016 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8023 |
|
This document provides context and a report on the workshop on "RootCauses and Mitigation of Name Collisions", which took place inLondon, United Kingdom, from March 8 to 10, 2014. The main goal of the workshop was to foster a discussion on the causes and potential mitigations of domain name collisions. This report provides a small amount of background and context; then, it provides a summary of the workshop's discussions. |
|
| |
| RFC 8032 | Edwards-Curve Digital Signature Algorithm (EdDSA) |
| |
| Authors: | S. Josefsson, I. Liusvaara. |
| Date: | January 2017 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8032 |
|
This document describes elliptic curve signature scheme Edwards-curveDigital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided. |
|
| |
| RFC 8034 | Active Queue Management (AQM) Based on Proportional Integral Controller Enhanced (PIE) for Data-Over-Cable Service Interface Specifications (DOCSIS) Cable Modems |
| |
| Authors: | G. White, R. Pan. |
| Date: | February 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8034 |
|
Cable modems based on Data-Over-Cable Service InterfaceSpecifications (DOCSIS) provide broadband Internet access to over one hundred million users worldwide. In some cases, the cable modem connection is the bottleneck (lowest speed) link between the customer and the Internet. As a result, the impact of buffering and bufferbloat in the cable modem can have a significant effect on user experience. The CableLabs DOCSIS 3.1 specification introduces requirements for cable modems to support an Active Queue Management(AQM) algorithm that is intended to alleviate the impact that buffering has on latency-sensitive traffic, while preserving bulk throughput performance. In addition, the CableLabs DOCSIS 3.0 specifications have also been amended to contain similar requirements. This document describes the requirements on AQM that apply to DOCSIS equipment, including a description of the"DOCSIS-PIE" algorithm that is required on DOCSIS 3.1 cable modems. |
|
| |
| RFC 8041 | Use Cases and Operational Experience with Multipath TCP |
| |
| Authors: | O. Bonaventure, C. Paasch, G. Detal. |
| Date: | January 2017 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8041 |
|
This document discusses both use cases and operational experience with Multipath TCP (MPTCP) in real networks. It lists several prominent use cases where Multipath TCP has been considered and is being used. It also gives insight to some heuristics and decisions that have helped to realize these use cases and suggests possible improvements. |
|
| |
| RFC 8043 | Source-Address-Dependent Routing and Source Address Selection for IPv6 Hosts: Overview of the Problem Space |
| |
| Authors: | B. Sarikaya, M. Boucadair. |
| Date: | January 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8043 |
|
This document presents the source-address-dependent routing (SADR) problem space from the host's perspective. Both multihomed hosts and hosts with multiple interfaces are considered. Several network architectures are presented to illustrate why source address selection and next-hop resolution are needed in view of source-address-dependent routing.
The document is scoped on identifying a set of scenarios for source-address-dependent routing from the host's perspective and analyzing a set of solutions to mitigate encountered issues. The document does not make any solution recommendations. |
|
| |
| RFC 8051 | Applicability of a Stateful Path Computation Element (PCE) |
| |
| Authors: | X. Zhang, Ed., I. Minei, Ed.. |
| Date: | January 2017 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8051 |
|
A stateful Path Computation Element (PCE) maintains information aboutLabel Switched Path (LSP) characteristics and resource usage within a network in order to provide traffic-engineering calculations for its associated Path Computation Clients (PCCs). This document describes general considerations for a stateful PCE deployment and examines its applicability and benefits, as well as its challenges and limitations, through a number of use cases. PCE CommunicationProtocol (PCEP) extensions required for stateful PCE usage are covered in separate documents. |
|
| |
| RFC 8057 | Uniform Resource Name (URN) Namespaces for Broadband Forum |
| |
| Authors: | B. Stark, D. Sinicrope, W. Lupton. |
| Date: | January 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8057 |
|
This document describes the Namespace Identifiers (NIDs) "bbf","broadband-forum-org", and "dslforum-org" for Uniform Resource Names(URNs) used to identify resources published by Broadband Forum (BBF).BBF specifies and manages resources that utilize these three URN identification models. Management activities for these and other resource types are handled by BBF. |
|
| |
| RFC 8065 | Privacy Considerations for IPv6 Adaptation-Layer Mechanisms |
| |
| Authors: | D. Thaler. |
| Date: | February 2017 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8065 |
|
This document discusses how a number of privacy threats apply to technologies designed for IPv6 over various link-layer protocols, and it provides advice to protocol designers on how to address such threats in adaptation-layer specifications for IPv6 over such links. |
|
| |
| RFC 8068 | Session Initiation Protocol (SIP) Recording Call Flows |
| |
| Authors: | R. Ravindranath, P. Ravindran, P. Kyzivat. |
| Date: | February 2017 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8068 |
|
Session recording is a critical requirement in many communications environments, such as call centers and financial trading organizations. In some of these environments, all calls must be recorded for regulatory, compliance, and consumer-protection reasons.The recording of a session is typically performed by sending a copy of a media stream to a recording device. This document lists call flows with metadata snapshots sent from a Session Recording Client(SRC) to a Session Recording Server (SRS). |
|
| |
| RFC 8069 | URN Namespace for IEEE |
| |
| Authors: | A. Thomas. |
| Date: | February 2017 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8069 |
|
This document describes the Namespace Identifier (NID) 'ieee' forUniform Resource Names (URNs) used to identify resources published by the Institute of Electrical and Electronics Engineers (IEEE). IEEE specifies and manages resources that utilize this URN identification model. Management activities for these and other resources types are handled by the manager of the IEEE Registration Authority. |
|
| |
| RFC 8073 | Coordinating Attack Response at Internet Scale (CARIS) Workshop Report |
| |
| Authors: | K. Moriarty, M. Ford. |
| Date: | March 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8073 |
|
This report documents the discussions and conclusions from theCoordinating Attack Response at Internet Scale (CARIS) workshop that took place in Berlin, Germany on 18 June 2015. The purpose of this workshop was to improve mutual awareness, understanding, and coordination among the diverse participating organizations and their representatives.
Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions. |
|
| |
| RFC 8087 | The Benefits of Using Explicit Congestion Notification (ECN) |
| |
| Authors: | G. Fairhurst, M. Welzl. |
| Date: | March 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8087 |
|
The goal of this document is to describe the potential benefits of applications using a transport that enables Explicit CongestionNotification (ECN). The document outlines the principal gains in terms of increased throughput, reduced delay, and other benefits whenECN is used over a network path that includes equipment that supportsCongestion Experienced (CE) marking. It also discusses challenges for successful deployment of ECN. It does not propose new algorithms to use ECN nor does it describe the details of implementation of ECN in endpoint devices (Internet hosts), routers, or other network devices. |
|
| |
| RFC 8088 | How to Write an RTP Payload Format |
| |
|
|
This document contains information on how best to write an RTP payload format specification. It provides reading tips, design practices, and practical tips on how to produce an RTP payload format specification quickly and with good results. A template is also included with instructions. |
|
| |
| RFC 8090 | Appointment Procedures for the IETF Representatives to the Community Coordination Group (CCG) |
| |
| Authors: | R. Housley. |
| Date: | February 2017 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8090 |
|
This document outlines the procedures by which the IETF makes appointments to the Community Coordination Group (CCG), which provides advice and guidance to the IETF Trust in matters related to the IANA trademarks and the IANA domain names. |
|
| |
| RFC 8091 | A Media Type Structured Syntax Suffix for JSON Text Sequences |
| |
| Authors: | E. Wilde. |
| Date: | February 2017 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8091 |
|
Structured syntax suffixes for media types allow other media types to build on them and make it explicit that they are built on an existing media type as their foundation. This specification defines and registers "+json-seq" as a structured syntax suffix for JSON text sequences. |
|
| |
| RFC 8095 | Services Provided by IETF Transport Protocols and Congestion Control Mechanisms |
| |
| Authors: | G. Fairhurst, Ed., B. Trammell, Ed., M. Kuehlewind, Ed.. |
| Date: | March 2017 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8095 |
|
This document describes, surveys, and classifies the protocol mechanisms provided by existing IETF protocols, as background for determining a common set of transport services. It examines theTransmission Control Protocol (TCP), Multipath TCP, the StreamControl Transmission Protocol (SCTP), the User Datagram Protocol(UDP), UDP-Lite, the Datagram Congestion Control Protocol (DCCP), theInternet Control Message Protocol (ICMP), the Real-Time TransportProtocol (RTP), File Delivery over Unidirectional Transport /Asynchronous Layered Coding (FLUTE/ALC) for Reliable Multicast, NACK-Oriented Reliable Multicast (NORM), Transport Layer Security (TLS),Datagram TLS (DTLS), and the Hypertext Transport Protocol (HTTP), when HTTP is used as a pseudotransport. This survey provides background for the definition of transport services within the TAPS working group. |
|
| |
| RFC 8096 | The IPv6-Specific MIB Modules Are Obsolete |
| |
|
|
In 2005-2006, the IPv6 MIB update group published updated versions of the IP-MIB, UDP-MIB, TCP-MIB, and IP-FORWARD-MIB modules, which use the InetAddressType/InetAddress construct to handle IPv4 and IPv6 in the same table. This document contains versions of the obsoletedIPV6-MIB, IPV6-TC, IPV6-ICMP-MIB, IPV6-TCP-MIB, and IPV6-UDP-MIB modules for the purpose of updating MIB module repositories. This document obsoletes RFCs 2452, 2454, 2465, and 2466 (i.e., the RFCs containing these MIBs) and reclassifies them as Historic. |
|
| |
| RFC 8100 | Diffserv-Interconnection Classes and Practice |
| |
| Authors: | R. Geib, Ed., D. Black. |
| Date: | March 2017 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8100 |
|
This document defines a limited common set of Diffserv Per-HopBehaviors (PHBs) and Diffserv Codepoints (DSCPs) to be applied at(inter)connections of two separately administered and operated networks, and it explains how this approach can simplify network configuration and operation. Many network providers operateMultiprotocol Label Switching (MPLS) using Treatment Aggregates for traffic marked with different Diffserv Per-Hop Behaviors and use MPLS for interconnection with other networks. This document offers a simple interconnection approach that may simplify operation ofDiffserv for network interconnection among providers that use MPLS and apply the Short Pipe Model. While motivated by the requirements of MPLS network operators that use Short Pipe Model tunnels, this document is applicable to other networks, both MPLS and non-MPLS. |
|
| |
| RFC 8101 | IANA Registration of New Session Initiation Protocol (SIP) Resource-Priority Namespace for Mission Critical Push To Talk Service |
| |
| Authors: | C. Holmberg, J. Axell. |
| Date: | March 2017 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8101 |
|
This document creates additional Session Initiation Protocol (SIP)Resource-Priority namespaces to meet the requirements of the3GPP-defined Mission Critical Push To Talk (MCPTT) and places these namespaces in the corresponding IANA registry. |
|
| |
| RFC 8107 | Advertising Digital Identifier (Ad-ID) URN Namespace Definition |
| |
| Authors: | J. Wold. |
| Date: | March 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8107 |
|
Advertising Digital Identifiers (Ad-IDs) are used to identify advertising assets across all media platforms. This document defines the formal Uniform Resource Name (URN) Namespace Identifier (NID)"adid" for Ad-IDs. |
|
| |
| RFC 8110 | Opportunistic Wireless Encryption |
| |
| Authors: | D. Harkins, Ed., W. Kumari, Ed.. |
| Date: | March 2017 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8110 |
|
This memo specifies an extension to IEEE Std 802.11 to provide for opportunistic (unauthenticated) encryption to the wireless media. |
|
| |
| RFC 8112 | Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT) Referral Internet Groper (RIG) |
| |
| Authors: | D. Farinacci, A. Jain, I. Kouvelas, D. Lewis. |
| Date: | May 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8112 |
|
A simple tool called the Locator/ID Separation Protocol DelegatedDatabase Tree (LISP-DDT) Referral Internet Groper (RIG), also referred to in this document as "rig", can be used to query the LISP-DDT hierarchy. This document describes how the "rig" tool works. |
|
| |
| RFC 8116 | Security Threats to the Optimized Link State Routing Protocol Version 2 (OLSRv2) |
| |
| Authors: | T. Clausen, U. Herberg, J. Yi. |
| Date: | May 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8116 |
|
This document analyzes common security threats to the Optimized LinkState Routing Protocol version 2 (OLSRv2) and describes their potential impacts on Mobile Ad Hoc Network (MANET) operations. It also analyzes which of these security vulnerabilities can be mitigated when using the mandatory-to-implement security mechanisms for OLSRv2 and how the vulnerabilities are mitigated. |
|
| |
| RFC 8117 | Current Hostname Practice Considered Harmful |
| |
| Authors: | C. Huitema, D. Thaler, R. Winter. |
| Date: | March 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8117 |
|
Giving a hostname to your computer and publishing it as you roam from one network to another is the Internet's equivalent of walking around with a name tag affixed to your lapel. This current practice can significantly compromise your privacy, and something should change in order to mitigate these privacy threats.
There are several possible remedies, such as fixing a variety of protocols or avoiding disclosing a hostname at all. This document describes some of the protocols that reveal hostnames today and sketches another possible remedy, which is to replace static hostnames by frequently changing randomized values. |
|
| |
| RFC 8118 | The application/pdf Media Type |
| |
| Authors: | M. Hardy, L. Masinter, D. Markovic, D. Johnson, M. Bailey. |
| Date: | March 2017 |
| Formats: | txt json html |
| Obsoletes: | RFC 3778 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8118 |
|
The Portable Document Format (PDF) is an ISO standard (ISO32000-1:2008) defining a final-form document representation language in use for document exchange, including on the Internet, since 1993.This document provides an overview of the PDF format and updates the media type registration of "application/pdf". It obsoletes RFC 3778. |
|
| |
| RFC 8119 | SIP "cause" URI Parameter for Service Number Translation |
| |
|
|
RFC 4458 (regarding SIP URIs for applications) defines a "cause" URI parameter, which may appear in the Request-URI of a SIP request, that is used to indicate a reason why the request arrived to the UserAgent Server (UAS) receiving the message. This document updates RFC4458 by creating a new predefined value for the "cause" URI parameter to cover service number translation for cases of retargeting due to specific service action leading to the translation of a called service access number. This document also provides guidance, which was missing in RFC 4458, for using the "cause" URI parameter within the History-Info header field, since this use is mandatory in some IP networks' implementations. |
|
| |
| RFC 8123 | Requirements for Marking SIP Messages to be Logged |
| |
| Authors: | P. Dawes, C. Arunachalam. |
| Date: | March 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8123 |
|
SIP networks use signaling monitoring tools to debug customer- reported problems and for regression testing if network or client software is upgraded. As networks grow and become interconnected, including connection via transit networks, it becomes impractical to predict the path that SIP signaling will take between clients and, therefore, impractical to monitor SIP signaling end-to-end.
This document describes the requirements for adding an indicator to the SIP Protocol Data Unit (PDU) or a SIP message that marks the PDU as a candidate for logging. Such a marking will typically be applied as part of network testing controlled by the network operator and not used in regular client signaling. However, such a marking can be carried end-to-end, including the SIP terminals, even if a session originates and terminates in different networks. |
|
| |
| RFC 8125 | Requirements for Password-Authenticated Key Agreement (PAKE) Schemes |
| |
| Authors: | J. Schmidt. |
| Date: | April 2017 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8125 |
|
Password-Authenticated Key Agreement (PAKE) schemes are interactive protocols that allow the participants to authenticate each other and derive shared cryptographic keys using a (weaker) shared password.This document reviews different types of PAKE schemes. Furthermore, it presents requirements and gives recommendations to designers of new schemes. It is a product of the Crypto Forum Research Group(CFRG). |
|
| |
| RFC 8128 | IETF Appointment Procedures for the ICANN Root Zone Evolution Review Committee |
| |
| Authors: | C. Morgan. |
| Date: | March 2017 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8128 |
|
This memo outlines the process by which the IETF makes an appointment to the ICANN Root Zone Evolution Review Committee (RZERC). |
|
| |
| RFC 8131 | RSVP-TE Signaling Procedure for End-to-End GMPLS Restoration and Resource Sharing |
| |
| Authors: | X. Zhang, H. Zheng, Ed., R. Gandhi, Ed., Z. Ali, P. Brzozowski. |
| Date: | March 2017 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8131 |
|
In non-packet transport networks, there are requirements where theGeneralized Multiprotocol Label Switching (GMPLS) end-to-end recovery scheme needs to employ a restoration Label Switched Path (LSP) while keeping resources for the working and/or protecting LSPs reserved in the network after the failure occurs.
This document reviews how the LSP association is to be provided usingResource Reservation Protocol - Traffic Engineering (RSVP-TE) signaling in the context of a GMPLS end-to-end recovery scheme when using restoration LSP where failed LSP is not torn down. In addition, this document discusses resource sharing-based setup and teardown of LSPs as well as LSP reversion procedures. No new signaling extensions are defined by this document, and it is strictly informative in nature. |
|
| |
| RFC 8133 | The Security Evaluated Standardized Password-Authenticated Key Exchange (SESPAKE) Protocol |
| |
| Authors: | S. Smyshlyaev, Ed., E. Alekseev, I. Oshkin, V. Popov. |
| Date: | March 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8133 |
|
This document describes the Security Evaluated Standardized Password-Authenticated Key Exchange (SESPAKE) protocol. The SESPAKE protocol provides password-authenticated key exchange for usage in systems for protection of sensitive information. The security proofs of the protocol were made for situations involving an active adversary in the channel, including man-in-the-middle (MitM) attacks and attacks based on the impersonation of one of the subjects. |
|
| |
| RFC 8134 | Management Incident Lightweight Exchange (MILE) Implementation Report |
| |
| Authors: | C. Inacio, D. Miyamoto. |
| Date: | May 2017 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8134 |
|
This document is a collection of implementation reports from vendors, consortiums, and researchers who have implemented one or more of the standards published from the IETF INCident Handling (INCH) andManagement Incident Lightweight Exchange (MILE) working groups. |
|
| |
| RFC 8136 | Additional Transition Functionality for IPv6 |
| |
| Authors: | B. Carpenter, R. Hinden. |
| Date: | 1 April 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8136 |
|
This document proposes an additional mechanism intended to both facilitate transition from IPv4 to IPv6 and improve the latter's security and privacy. |
|
| |
| RFC 8137 | IEEE 802.15.4 Information Element for the IETF |
| |
| Authors: | T. Kivinen, P. Kinney. |
| Date: | May 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8137 |
|
IEEE Std 802.15.4 defines Information Elements (IEs) that can be used to extend 802.15.4 in an interoperable manner. The IEEE 802.15Assigned Numbers Authority (ANA) manages the registry of theInformation Elements. This document formulates a request for ANA to allocate a number from that registry for the IETF and describes how the IE is formatted to provide subtypes. |
|
| |
| RFC 8140 | The Arte of ASCII: Or, An True and Accurate Representation of an Menagerie of Thynges Fabulous and Wonderful in Ye Forme of Character |
| |
| Authors: | A. Farrel. |
| Date: | 1 April 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8140 |
|
Ever since Gutenberg discovered and patented ASCII and the corresponding "Courier New" font with its now-famous "ten" point size, artisans and artificers have striven to represent their views of the world in print.
Similarly, starting from Darwin's discovery of the hippogriff and his subsequent registration of the creature as an International TradeMark, men (and some women) have struggled to catalog the fabulous variety that is called "nature".
This document supplies a number of representations of all manner of things (both elemental and hypothetical) supplied by some of our best collectors of curios and delivered in a manner that may well be reused by the cunning document author. |
|
| |
| RFC 8146 | Adding Support for Salted Password Databases to EAP-pwd |
| |
|
|
EAP-pwd is an Extensible Authentication Protocol (EAP) method that utilizes a shared password for authentication using a technique that is resistant to dictionary attacks. It includes support for raw keys and double hashing of a password in the style of Microsoft ChallengeHandshake Authentication Protocol version 2 (MSCHAPv2), but it does not include support for salted passwords. There are many existing databases of salted passwords, and it is desirable to allow their use with EAP-pwd. |
|
| |
| RFC 8151 | Use Cases for Data Center Network Virtualization Overlay Networks |
| |
| Authors: | L. Yong, L. Dunbar, M. Toy, A. Isaac, V. Manral. |
| Date: | May 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8151 |
|
This document describes Network Virtualization over Layer 3 (NVO3) use cases that can be deployed in various data centers and serve different data-center applications. |
|
| |
| RFC 8153 | Digital Preservation Considerations for the RFC Series |
| |
| Authors: | H. Flanagan. |
| Date: | April 2017 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8153 |
|
The RFC Editor is both the publisher and the archivist for the RFCSeries. This document applies specifically to the archivist role of the RFC Editor. It provides guidance on when and how to preserveRFCs and describes the tools required to view or re-create RFCs as necessary. This document also highlights gaps in the current process and suggests compromises to balance cost with best practice. |
|
| |
| RFC 8157 | Huawei's GRE Tunnel Bonding Protocol |
| |
| Authors: | N. Leymann, C. Heidemann, M. Zhang, B. Sarikaya, M. Cullen. |
| Date: | May 2017 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8157 |
|
There is an emerging demand for solutions that provide redundancy and load-sharing across wired and cellular links from a single ServiceProvider, so that a single subscriber is provided with bonded access to heterogeneous connections at the same time.
In this document, GRE (Generic Routing Encapsulation) Tunnel Bonding is specified as an enabling approach for bonded access to a wired and a wireless network in customer premises, e.g., homes. In GRE TunnelBonding, two GRE tunnels, one per network connection, are set up and bonded together to form a single GRE tunnel for a subscriber.Compared with each subconnection, the bonded connections promise increased access capacity and improved reliability. The solution described in this document is currently implemented by Huawei and deployed by Deutsche Telekom AG. This document will enable other developers to build interoperable implementations. |
|
| |
| RFC 8161 | Benchmarking the Neighbor Discovery Protocol |
| |
| Authors: | W. Cerveny, R. Bonica, R. Thomas. |
| Date: | May 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8161 |
|
This document provides benchmarking procedures for the NeighborDiscovery Protocol (NDP). It also proposes metrics by which an NDP implementation's scaling capabilities can be measured. |
|
| |
| RFC 8165 | Design Considerations for Metadata Insertion |
| |
| Authors: | T. Hardie. |
| Date: | May 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8165 |
|
The IAB published RFC 7624 in response to several revelations of pervasive attacks on Internet communications. This document considers the implications of protocol designs that associate metadata with encrypted flows. In particular, it asserts that designs that share metadata only by explicit actions at the host are preferable to designs in which middleboxes insert metadata. |
|
| |
| RFC 8170 | Planning for Protocol Adoption and Subsequent Transitions |
| |
| Authors: | D. Thaler, Ed.. |
| Date: | May 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8170 |
|
Over the many years since the introduction of the Internet Protocol, we have seen a number of transitions throughout the protocol stack, such as deploying a new protocol, or updating or replacing an existing protocol. Many protocols and technologies were not designed to enable smooth transition to alternatives or to easily deploy extensions; thus, some transitions, such as the introduction of IPv6, have been difficult. This document attempts to summarize some basic principles to enable future transitions, and it also summarizes what makes for a good transition plan. |
|
| |
| RFC 8172 | Considerations for Benchmarking Virtual Network Functions and Their Infrastructure |
| |
| Authors: | A. Morton. |
| Date: | July 2017 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8172 |
|
The Benchmarking Methodology Working Group has traditionally conducted laboratory characterization of dedicated physical implementations of internetworking functions. This memo investigates additional considerations when network functions are virtualized and performed in general-purpose hardware. |
|
| |
| RFC 8184 | Dual-Homing Protection for MPLS and the MPLS Transport Profile (MPLS-TP) Pseudowires |
| |
| Authors: | W. Cheng, L. Wang, H. Li, S. Davari, J. Dong. |
| Date: | June 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8184 |
|
This document describes a framework and several scenarios for a pseudowire (PW) dual-homing local protection mechanism that avoids unnecessary switchovers and does not depend on whether a control plane is used. A Dual-Node Interconnection (DNI) PW is used to carry traffic between the dual-homing Provider Edge (PE) nodes when a failure occurs in one of the Attachment Circuits (AC) or PWs. ThisPW dual-homing local protection mechanism is complementary to existing PW protection mechanisms. |
|
| |
| RFC 8192 | Interface to Network Security Functions (I2NSF): Problem Statement and Use Cases |
| |
| Authors: | S. Hares, D. Lopez, M. Zarny, C. Jacquenet, R. Kumar, J. Jeong. |
| Date: | July 2017 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8192 |
|
This document sets out the problem statement for Interface to NetworkSecurity Functions (I2NSF) and outlines some companion use cases. |
|
| |
| RFC 8195 | Use of BGP Large Communities |
| |
| Authors: | J. Snijders, J. Heasley, M. Schmidt. |
| Date: | June 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8195 |
|
This document presents examples and inspiration for operator application of BGP Large Communities. Based on operational experience with BGP Communities, this document suggests logical categories of BGP Large Communities and demonstrates an orderly manner of organizing community values within them to achieve typical goals in routing policy. Any operator can consider using the concepts presented as the basis for their own BGP Large Communities repertoire. |
|
| |
| RFC 8199 | YANG Module Classification |
| |
| Authors: | D. Bogdanovic, B. Claise, C. Moberg. |
| Date: | July 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8199 |
|
The YANG data modeling language is currently being considered for a wide variety of applications throughout the networking industry at large. Many standards development organizations (SDOs), open-source software projects, vendors, and users are using YANG to develop and publish YANG modules for a wide variety of applications. At the same time, there is currently no well-known terminology to categorize various types of YANG modules.
A consistent terminology would help with the categorization of YANG modules, assist in the analysis of the YANG data modeling efforts in the IETF and other organizations, and bring clarity to the YANG- related discussions between the different groups.
This document describes a set of concepts and associated terms to support consistent classification of YANG modules. |
|
| |
| RFC 8204 | Benchmarking Virtual Switches in the Open Platform for NFV (OPNFV) |
| |
| Authors: | M. Tahhan, B. O'Mahony, A. Morton. |
| Date: | September 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8204 |
|
This memo describes the contributions of the Open Platform for NFV(OPNFV) project on Virtual Switch Performance (VSPERF), particularly in the areas of test setups and configuration parameters for the system under test. This project has extended the current and completed work of the Benchmarking Methodology Working Group in theIETF and references existing literature. The BenchmarkingMethodology Working Group has traditionally conducted laboratory characterization of dedicated physical implementations of internetworking functions. Therefore, this memo describes the additional considerations when virtual switches are implemented on general-purpose hardware. The expanded tests and benchmarks are also influenced by the OPNFV mission to support virtualization of the"telco" infrastructure. |
|
| |
| RFC 8211 | Adverse Actions by a Certification Authority (CA) or Repository Manager in the Resource Public Key Infrastructure (RPKI) |
| |
| Authors: | S. Kent, D. Ma. |
| Date: | September 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8211 |
|
This document analyzes actions by or against a CertificationAuthority (CA) or an independent repository manager in the RPKI that can adversely affect the Internet Number Resources (INRs) associated with that CA or its subordinate CAs. The analysis is done from the perspective of an affected INR holder. The analysis is based on examination of the data items in the RPKI repository, as controlled by a CA (or an independent repository manager) and fetched by RelyingParties (RPs). The analysis does not purport to be comprehensive; it does represent an orderly way to analyze a number of ways that errors by or attacks against a CA or repository manager can affect the RPKI and routing decisions based on RPKI data. |
|
| |
| RFC 8216 | HTTP Live Streaming |
| |
| Authors: | R. Pantos, Ed., W. May. |
| Date: | August 2017 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8216 |
|
This document describes a protocol for transferring unbounded streams of multimedia data. It specifies the data format of the files and the actions to be taken by the server (sender) and the clients(receivers) of the streams. It describes version 7 of this protocol. |
|
| |
| RFC 8219 | Benchmarking Methodology for IPv6 Transition Technologies |
| |
| Authors: | M. Georgescu, L. Pislaru, G. Lencse. |
| Date: | August 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8219 |
|
Benchmarking methodologies that address the performance of network interconnect devices that are IPv4- or IPv6-capable exist, but theIPv6 transition technologies are outside of their scope. This document provides complementary guidelines for evaluating the performance of IPv6 transition technologies. More specifically, this document targets IPv6 transition technologies that employ encapsulation or translation mechanisms, as dual-stack nodes can be tested using the recommendations of RFCs 2544 and 5180. The methodology also includes a metric for benchmarking load scalability. |
|
| |
| RFC 8220 | Protocol Independent Multicast (PIM) over Virtual Private LAN Service (VPLS) |
| |
| Authors: | O. Dornon, J. Kotalwar, V. Hemige, R. Qiu, Z. Zhang. |
| Date: | September 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8220 |
|
This document describes the procedures and recommendations forVirtual Private LAN Service (VPLS) Provider Edges (PEs) to facilitate replication of multicast traffic to only certain ports (behind which there are interested Protocol Independent Multicast (PIM) routers and/or Internet Group Management Protocol (IGMP) hosts) via PIM snooping and proxying.
With PIM snooping, PEs passively listen to certain PIM control messages to build control and forwarding states while transparently flooding those messages. With PIM proxying, PEs do not flood PIMJoin/Prune messages but only generate their own and send them out of certain ports, based on the control states built from downstreamJoin/Prune messages. PIM proxying is required when PIM Join suppression is enabled on the Customer Edge (CE) devices and is useful for reducing PIM control traffic in a VPLS domain.
This document also describes PIM relay, which can be viewed as lightweight proxying, where all downstream Join/Prune messages are simply forwarded out of certain ports and are not flooded, thereby avoiding the triggering of PIM Join suppression on CE devices. |
|
| |
| RFC 8222 | Selecting Labels for Use with Conventional DNS and Other Resolution Systems in DNS-Based Service Discovery |
| |
| Authors: | A. Sullivan. |
| Date: | September 2017 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8222 |
|
Despite its name, DNS-Based Service Discovery (DNS-SD) can use naming systems other than DNS when looking for services. Moreover, when it uses DNS, DNS-SD uses the full capability of DNS, rather than using a subset of available octets. This is of particular relevance where some environments use DNS labels that conform to InternationalizedDomain Names for Applications (IDNA), and other environments use labels containing Unicode characters (such as containing octets corresponding to characters encoded as UTF-8). In order for DNS-SD to be used effectively in environments where multiple different name systems and conventions for their operation are in use, it is important to attend to differences in the underlying technology and operational environment. This memo presents an outline of the requirements for the selection of labels for conventional DNS and other resolution systems when they are expected to interoperate in this manner. |
|
| |
| RFC 8228 | Guidance on Designing Label Generation Rulesets (LGRs) Supporting Variant Labels |
| |
| Authors: | A. Freytag. |
| Date: | August 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8228 |
|
Rules for validating identifier labels and alternate representations of those labels (variants) are known as Label Generation Rulesets(LGRs); they are used for the implementation of identifier systems such as Internationalized Domain Names (IDNs). This document describes ways to design LGRs to support variant labels. In designing LGRs, it is important to ensure that the label generation rules are consistent and well behaved in the presence of variants.The design decisions can then be expressed using the XML representation of LGRs that is defined in RFC 7940. |
|
| |
| RFC 8235 | Schnorr Non-interactive Zero-Knowledge Proof |
| |
| Authors: | F. Hao, Ed.. |
| Date: | September 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8235 |
|
This document describes the Schnorr non-interactive zero-knowledge(NIZK) proof, a non-interactive variant of the three-pass Schnorr identification scheme. The Schnorr NIZK proof allows one to prove the knowledge of a discrete logarithm without leaking any information about its value. It can serve as a useful building block for many cryptographic protocols to ensure that participants follow the protocol specification honestly. This document specifies the SchnorrNIZK proof in both the finite field and the elliptic curve settings. |
|
| |
| RFC 8236 | J-PAKE: Password-Authenticated Key Exchange by Juggling |
| |
| Authors: | F. Hao, Ed.. |
| Date: | September 2017 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8236 |
|
This document specifies a Password-Authenticated Key Exchange byJuggling (J-PAKE) protocol. This protocol allows the establishment of a secure end-to-end communication channel between two remote parties over an insecure network solely based on a shared password, without requiring a Public Key Infrastructure (PKI) or any trusted third party. |
|
| |
| RFC 8238 | Data Center Benchmarking Terminology |
| |
| Authors: | L. Avramov, J. Rapp. |
| Date: | August 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8238 |
|
The purposes of this informational document are to establish definitions and describe measurement techniques for data center benchmarking, as well as to introduce new terminology applicable to performance evaluations of data center network equipment. This document establishes the important concepts for benchmarking network switches and routers in the data center and is a prerequisite for the test methodology document (RFC 8239). Many of these terms and methods may be applicable to network equipment beyond the scope of this document as the technologies originally applied in the data center are deployed elsewhere. |
|
| |
| RFC 8239 | Data Center Benchmarking Methodology |
| |
| Authors: | L. Avramov, J. Rapp. |
| Date: | August 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8239 |
|
The purpose of this informational document is to establish test and evaluation methodology and measurement techniques for physical network equipment in the data center. RFC 8238 is a prerequisite for this document, as it contains terminology that is considered normative. Many of these terms and methods may be applicable beyond the scope of this document as the technologies originally applied in the data center are deployed elsewhere. |
|
| |
| RFC 8240 | Report from the Internet of Things Software Update (IoTSU) Workshop 2016 |
| |
| Authors: | H. Tschofenig, S. Farrell. |
| Date: | September 2017 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8240 |
|
This document provides a summary of the Internet of Things SoftwareUpdate (IoTSU) Workshop that took place at Trinity College Dublin,Ireland on the 13th and 14th of June, 2016. The main goal of the workshop was to foster a discussion on requirements, challenges, and solutions for bringing software and firmware updates to IoT devices.This report summarizes the discussions and lists recommendations to the standards community.
Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions. |
|
| |
| RFC 8241 | Interface to the Routing System (I2RS) Security-Related Requirements |
| |
| Authors: | S. Hares, D. Migault, J. Halpern. |
| Date: | September 2017 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8241 |
|
This document presents security-related requirements for theInterface to the Routing System (I2RS) protocol, which provides a new interface to the routing system described in the I2RS architecture document (RFC 7921). The I2RS protocol is implemented by reusing portions of existing IETF protocols and adding new features to them.One such reuse is of the security features of a secure transport(e.g., Transport Layer Security (TLS), Secure SHell (SSH) Protocol,Datagram TLS (DTLS)) such as encryption, message integrity, mutual peer authentication, and anti-replay protection. The new I2RS features to consider from a security perspective are as follows: a priority mechanism to handle multi-headed write transactions, an opaque secondary identifier that identifies an application using theI2RS client, and an extremely constrained read-only non-secure transport. |
|
| |
| RFC 8242 | Interface to the Routing System (I2RS) Ephemeral State Requirements |
| |
| Authors: | J. Haas, S. Hares. |
| Date: | September 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8242 |
|
"An Architecture for the Interface to the Routing System" (RFC 7921) abstractly describes a number of requirements for ephemeral state (in terms of capabilities and behaviors) that any protocol suite attempting to meet the needs of the Interface to the Routing System(I2RS) protocol has to provide. This document describes, in detail, requirements for ephemeral state for those implementing the I2RS protocol. |
|
| |
| RFC 8243 | Alternatives for Multilevel Transparent Interconnection of Lots of Links (TRILL) |
| |
| Authors: | R. Perlman, D. Eastlake 3rd, M. Zhang, A. Ghanwani, H. Zhai. |
| Date: | September 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8243 |
|
Although TRILL is based on IS-IS, which supports multilevel unicast routing, extending TRILL to multiple levels has challenges that are not addressed by the already-existing capabilities of IS-IS. One issue is with the handling of multi-destination packet distribution trees. Other issues are with TRILL switch nicknames. How are such nicknames allocated across a multilevel TRILL network? Do nicknames need to be unique across an entire multilevel TRILL network? Or can they merely be unique within each multilevel area?
This informational document enumerates and examines alternatives based on a number of factors including backward compatibility, simplicity, and scalability; it makes recommendations in some cases. |
|
| |
| RFC 8244 | Special-Use Domain Names Problem Statement |
| |
| Authors: | T. Lemon, R. Droms, W. Kumari. |
| Date: | October 2017 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8244 |
|
The policy defined in RFC 6761 for IANA registrations in the"Special-Use Domain Names" registry has been shown, through experience, to present challenges that were not anticipated when RFC6761 was written. This memo presents a list, intended to be comprehensive, of the problems that have since been identified. In addition, it reviews the history of domain names and summarizes current IETF publications and some publications from other organizations relating to Special-Use Domain Names.
This document should be considered required reading for IETF participants who wish to express an informed opinion on the topic ofSpecial-Use Domain Names. |
|
| |
| RFC 8248 | Security Automation and Continuous Monitoring (SACM) Requirements |
| |
| Authors: | N. Cam-Winget, L. Lorenzin. |
| Date: | September 2017 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8248 |
|
This document defines the scope and set of requirements for theSecurity Automation and Continuous Monitoring (SACM) architecture, data model, and transfer protocols. The requirements and scope are based on the agreed-upon use cases described in RFC 7632. |
|
| |
| RFC 8256 | Requirements for Hitless MPLS Path Segment Monitoring |
| |
| Authors: | A. D'Alessandro, L. Andersson, S. Ueno, K. Arai, Y. Koike. |
| Date: | October 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8256 |
|
One of the most important Operations, Administration, and Maintenance(OAM) capabilities for transport-network operation is fault localization. An in-service, on-demand path segment monitoring function of a transport path is indispensable, particularly when the service monitoring function is activated only between endpoints.However, the current segment monitoring approach defined for MPLS(including the MPLS Transport Profile (MPLS-TP)) in RFC 6371"Operations, Administration, and Maintenance Framework for MPLS-BasedTransport Networks" has drawbacks. This document provides an analysis of the existing MPLS-TP OAM mechanisms for the path segment monitoring and provides requirements to guide the development of newOAM tools to support Hitless Path Segment Monitoring (HPSM). |
|
| |
| RFC 8257 | Data Center TCP (DCTCP): TCP Congestion Control for Data Centers |
| |
| Authors: | S. Bensley, D. Thaler, P. Balasubramanian, L. Eggert, G. Judd. |
| Date: | October 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8257 |
|
This Informational RFC describes Data Center TCP (DCTCP): a TCP congestion control scheme for data-center traffic. DCTCP extends theExplicit Congestion Notification (ECN) processing to estimate the fraction of bytes that encounter congestion rather than simply detecting that some congestion has occurred. DCTCP then scales theTCP congestion window based on this estimate. This method achieves high-burst tolerance, low latency, and high throughput with shallow- buffered switches. This memo also discusses deployment issues related to the coexistence of DCTCP and conventional TCP, discusses the lack of a negotiating mechanism between sender and receiver, and presents some possible mitigations. This memo documents DCTCP as currently implemented by several major operating systems. DCTCP, as described in this specification, is applicable to deployments in controlled environments like data centers, but it must not be deployed over the public Internet without additional measures. |
|
| |
| RFC 8269 | The ARIA Algorithm and Its Use with the Secure Real-Time Transport Protocol (SRTP) |
| |
| Authors: | W. Kim, J. Lee, J. Park, D. Kwon, D. Kim. |
| Date: | October 2017 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8269 |
|
This document defines the use of the ARIA block cipher algorithm within the Secure Real-time Transport Protocol (SRTP). It details two modes of operation (CTR and GCM) and the SRTP key derivation functions for ARIA. Additionally, this document defines DTLS-SRTP protection profiles and Multimedia Internet KEYing (MIKEY) parameter sets for use with ARIA. |
|
| |
| RFC 8272 | TinyIPFIX for Smart Meters in Constrained Networks |
| |
| Authors: | C. Schmitt, B. Stiller, B. Trammell. |
| Date: | November 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8272 |
|
This document specifies the TinyIPFIX protocol that is used for transmitting smart-metering data in constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPAN, RFC 4944).TinyIPFIX is derived from IP Flow Information Export (RFC 7011) and adopted to the needs of constrained networks. This document specifies how the TinyIPFIX Data and Template Records are transmitted in constrained networks such as 6LoWPAN and how TinyIPFIX data can be converted into data that is not TinyIPFIX in a proxy device. |
|
| |
| RFC 8273 | Unique IPv6 Prefix per Host |
| |
| Authors: | J. Brzozowski, G. Van de Velde. |
| Date: | December 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8273 |
|
This document outlines an approach utilizing existing IPv6 protocols to allow hosts to be assigned a unique IPv6 prefix (instead of a unique IPv6 address from a shared IPv6 prefix). Benefits of using a unique IPv6 prefix over a unique service-provider IPv6 address include improved host isolation and enhanced subscriber management on shared network segments. |
|
| |
| RFC 8274 | Incident Object Description Exchange Format Usage Guidance |
| |
| Authors: | P. Kampanakis, M. Suzuki. |
| Date: | November 2017 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8274 |
|
The Incident Object Description Exchange Format (IODEF) v2 (RFC 7970) defines a data representation that provides a framework for sharing information about computer security incidents commonly exchanged byComputer Security Incident Response Teams (CSIRTs). Since the IODEF model includes a wealth of available options that can be used to describe a security incident or issue, it can be challenging for security practitioners to develop tools that leverage IODEF for incident sharing. This document provides guidelines for IODEF implementers. It addresses how common security indicators can be represented in IODEF and provides use cases of how IODEF is being used. This document aims to make IODEF's adoption by vendors easier and to encourage faster and wider adoption of the model by CSIRTs around the world. |
|
| |
| RFC 8280 | 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 ProtocolConsiderations (HRPC) Research Group and also by individuals from outside the research group. |
|
| |
| RFC 8283 | An Architecture for Use of PCE and the PCE Communication Protocol (PCEP) in a Network with Central Control |
| |
| Authors: | A. Farrel, Ed., Q. Zhao, Ed., Z. Li, C. Zhou. |
| Date: | December 2017 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8283 |
|
The Path Computation Element (PCE) is a core component of Software-Defined Networking (SDN) systems. It can compute optimal paths for traffic across a network and can also update the paths to reflect changes in the network or traffic demands.
PCE was developed to derive paths for MPLS Label Switched Paths(LSPs), which are supplied to the head end of the LSP using the PathComputation Element Communication Protocol (PCEP).
SDN has a broader applicability than signaled MPLS traffic-engineered(TE) networks, and the PCE may be used to determine paths in a range of use cases including static LSPs, segment routing, Service FunctionChaining (SFC), and most forms of a routed or switched network. It is, therefore, reasonable to consider PCEP as a control protocol for use in these environments to allow the PCE to be fully enabled as a central controller.
This document briefly introduces the architecture for PCE as a central controller, examines the motivations and applicability forPCEP as a control protocol in this environment, and introduces the implications for the protocol. A PCE-based central controller can simplify the processing of a distributed control plane by blending it with elements of SDN and without necessarily completely replacing it.
This document does not describe use cases in detail and does not define protocol extensions: that work is left for other documents. |
|
| |
| RFC 8284 | Lightweight Directory Access Protocol (LDAP) Schema for Supporting the Extensible Messaging and Presence Protocol (XMPP) in White Pages |
| |
| Authors: | S. Kille. |
| Date: | November 2017 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8284 |
|
The Extensible Messaging and Presence Protocol (XMPP) identifies users by use of Jabber IDs (JIDs). The Lightweight Directory AccessProtocol (LDAP) enables provision of a white pages service with a schema relating to users and support for Internet protocols. This specification defines a schema to enable XMPP JIDs to be associated with objects in an LDAP directory so that this information can be used with white pages applications. |
|
| |
| RFC 8293 | A Framework for Multicast in Network Virtualization over Layer 3 |
| |
| Authors: | A. Ghanwani, L. Dunbar, M. McBride, V. Bannai, R. Krishnan. |
| Date: | January 2018 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8293 |
|
This document provides a framework for supporting multicast traffic in a network that uses Network Virtualization over Layer 3 (NVO3).Both infrastructure multicast and application-specific multicast are discussed. It describes the various mechanisms that can be used for delivering such traffic as well as the data plane and control plane considerations for each of the mechanisms. |
|
| |
| RFC 8303 | On the Usage of Transport Features Provided by IETF Transport Protocols |
| |
| Authors: | M. Welzl, M. Tuexen, N. Khademi. |
| Date: | February 2018 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8303 |
|
This document describes how the transport protocols TransmissionControl Protocol (TCP), MultiPath TCP (MPTCP), Stream ControlTransmission Protocol (SCTP), User Datagram Protocol (UDP), andLightweight User Datagram Protocol (UDP-Lite) expose services to applications and how an application can configure and use the features that make up these services. It also discusses the service provided by the Low Extra Delay Background Transport (LEDBAT) congestion control mechanism. The description results in a set of transport abstractions that can be exported in a transport services(TAPS) API. |
|
| |
| RFC 8304 | Transport Features of the User Datagram Protocol (UDP) and Lightweight UDP (UDP-Lite) |
| |
| Authors: | G. Fairhurst, T. Jones. |
| Date: | February 2018 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8304 |
|
This is an informational document that describes the transport protocol interface primitives provided by the User Datagram Protocol(UDP) and the Lightweight User Datagram Protocol (UDP-Lite) transport protocols. It identifies the datagram services exposed to applications and how an application can configure and use the features offered by the Internet datagram transport service. RFC8303 documents the usage of transport features provided by IETF transport protocols, describing the way UDP, UDP-Lite, and other transport protocols expose their services to applications and how an application can configure and use the features that make up these services. This document provides input to and context for that document, as well as offers a road map to documentation that may help users of the UDP and UDP-Lite protocols. |
|
| |
| RFC 8309 | Service Models Explained |
| |
| Authors: | Q. Wu, W. Liu, A. Farrel. |
| Date: | January 2018 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8309 |
|
The IETF has produced many modules in the YANG modeling language.The majority of these modules are used to construct data models to model devices or monolithic functions.
A small number of YANG modules have been defined to model services(for example, the Layer 3 Virtual Private Network Service Model(L3SM) produced by the L3SM working group and documented in RFC8049).
This document describes service models as used within the IETF and also shows where a service model might fit into a software-defined networking architecture. Note that service models do not make any assumption of how a service is actually engineered and delivered for a customer; details of how network protocols and devices are engineered to deliver a service are captured in other modules that are not exposed through the interface between the customer and the provider. |
|
| |
| RFC 8312 | CUBIC for Fast Long-Distance Networks |
| |
| Authors: | I. Rhee, L. Xu, S. Ha, A. Zimmermann, L. Eggert, R. Scheffenegger. |
| Date: | February 2018 |
| Formats: | txt html json |
| Obsoleted by: | RFC 9438 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8312 |
|
CUBIC is an extension to the current TCP standards. It differs from the current TCP standards only in the congestion control algorithm on the sender side. In particular, it uses a cubic function instead of a linear window increase function of the current TCP standards to improve scalability and stability under fast and long-distance networks. CUBIC and its predecessor algorithm have been adopted as defaults by Linux and have been used for many years. This document provides a specification of CUBIC to enable third-party implementations and to solicit community feedback through experimentation on the performance of CUBIC. |
|
| |
| RFC 8316 | Autonomic Networking Use Case for Distributed Detection of Service Level Agreement (SLA) Violations |
| |
| Authors: | J. Nobre, L. Granville, A. Clemm, A. Gonzalez Prieto. |
| Date: | February 2018 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8316 |
|
This document describes an experimental use case that employs autonomic networking for the monitoring of Service Level Agreements(SLAs). The use case is for detecting violations of SLAs in a distributed fashion. It strives to optimize and dynamically adapt the autonomic deployment of active measurement probes in a way that maximizes the likelihood of detecting service-level violations with a given resource budget to perform active measurements. This optimization and adaptation should be done without any outside guidance or intervention.
This document is a product of the IRTF Network Management ResearchGroup (NMRG). It is published for informational purposes. |
|
| |
| RFC 8324 | DNS Privacy, Authorization, Special Uses, Encoding, Characters, Matching, and Root Structure: Time for Another Look? |
| |
| Authors: | J. Klensin. |
| Date: | February 2018 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8324 |
|
The basic design of the Domain Name System was completed almost 30 years ago. The last half of that period has been characterized by significant changes in requirements and expectations, some of which either require changes to how the DNS is used or can be accommodated only poorly or not at all. This document asks the question of whether it is time to either redesign and replace the DNS to match contemporary requirements and expectations (rather than continuing to try to design and implement incremental patches that are not fully satisfactory) or draw some clear lines about functionality that is not really needed or that should be performed in some other way. |
|
| |
| RFC 8328 | Policy-Based Management Framework for the Simplified Use of Policy Abstractions (SUPA) |
| |
| Authors: | W. Liu, C. Xie, J. Strassner, G. Karagiannis, M. Klyus, J. Bi, Y. Cheng, D. Zhang. |
| Date: | March 2018 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8328 |
|
The Simplified Use of Policy Abstractions (SUPA) policy-based management framework defines base YANG data models to encode policy.These models point to device-, technology-, and service-specific YANG data models developed elsewhere. Policy rules within an operator's environment can be used to express high-level, possibly network-wide, policies to a network management function (within a controller, an orchestrator, or a network element). The network management function can then control the configuration and/or monitoring of network elements and services. This document describes the SUPA basic framework, its elements, and interfaces. |
|
| |
| RFC 8329 | Framework for Interface to Network Security Functions |
| |
| Authors: | D. Lopez, E. Lopez, L. Dunbar, J. Strassner, R. Kumar. |
| Date: | February 2018 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8329 |
|
This document describes the framework for Interface to NetworkSecurity Functions (I2NSF) and defines a reference model (including major functional components) for I2NSF. Network Security Functions(NSFs) are packet-processing engines that inspect and optionally modify packets traversing networks, either directly or in the context of sessions to which the packet is associated. |
|
| |
| RFC 8351 | The PKCS #8 EncryptedPrivateKeyInfo Media Type |
| |
| Authors: | S. Leonard. |
| Date: | June 2018 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8351 |
|
This document registers the application/pkcs8-encrypted media type for the EncryptedPrivateKeyInfo type of PKCS #8. An instance of this media type carries a single encrypted private key, BER-encoded as a single EncryptedPrivateKeyInfo value. |
|
| |
| RFC 8352 | Energy-Efficient Features of Internet of Things Protocols |
| |
| Authors: | C. Gomez, M. Kovatsch, H. Tian, Z. Cao, Ed.. |
| Date: | April 2018 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8352 |
|
This document describes the challenges for energy-efficient protocol operation on constrained devices and the current practices used to overcome those challenges. It summarizes the main link-layer techniques used for energy-efficient networking, and it highlights the impact of such techniques on the upper-layer protocols so that they can together achieve an energy-efficient behavior. The document also provides an overview of energy-efficient mechanisms available at each layer of the IETF protocol suite specified for constrained-node networks. |
|
| |
| RFC 8354 | Use Cases for IPv6 Source Packet Routing in Networking (SPRING) |
| |
| Authors: | J. Brzozowski, J. Leddy, C. Filsfils, R. Maglione, Ed., M. Townsley. |
| Date: | March 2018 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8354 |
|
The Source Packet Routing in Networking (SPRING) architecture describes how Segment Routing can be used to steer packets through anIPv6 or MPLS network using the source routing paradigm. This document illustrates some use cases for Segment Routing in anIPv6-only environment. |
|
| |
| RFC 8355 | Resiliency Use Cases in Source Packet Routing in Networking (SPRING) Networks |
| |
| Authors: | C. Filsfils, Ed., S. Previdi, Ed., B. Decraene, R. Shakir. |
| Date: | March 2018 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8355 |
|
This document identifies and describes the requirements for a set of use cases related to Segment Routing network resiliency on SourcePacket Routing in Networking (SPRING) networks. |
|
| |
| RFC 8358 | Update to Digital Signatures on Internet-Draft Documents |
| |
|
|
RFC 5485 specifies the conventions for digital signatures onInternet-Drafts. The Cryptographic Message Syntax (CMS) is used to create a detached signature, which is stored in a separate companion file so that no existing utilities are impacted by the addition of the digital signature.
The RFC Editor recently published the first RFC that includes non-ASCII characters in a text file. The conventions specified in RFC7997 were followed. We assume that non-ASCII characters will soon start appearing in Internet-Drafts as well. This document updates the handling of digital signatures on Internet-Drafts that contain non-ASCII characters in a text file.
This document updates RFC 5485. |
|
| |
| RFC 8367 | Wrongful Termination of Internet Protocol (IP) Packets |
| |
| Authors: | T. Mizrahi, J. Yallouz. |
| Date: | 1 April 2018 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8367 |
|
Routers and middleboxes terminate packets for various reasons. In some cases, these packets are wrongfully terminated. This memo describes some of the most common scenarios of wrongful termination of Internet Protocol (IP) packets and presents recommendations for mitigating them. |
|
| |
| RFC 8368 | Using an Autonomic Control Plane for Stable Connectivity of Network Operations, Administration, and Maintenance (OAM) |
| |
| Authors: | T. Eckert, Ed., M. Behringer. |
| Date: | May 2018 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8368 |
|
Operations, Administration, and Maintenance (OAM), as per BCP 161, for data networks is often subject to the problem of circular dependencies when relying on connectivity provided by the network to be managed for the OAM purposes.
Provisioning while bringing up devices and networks tends to be more difficult to automate than service provisioning later on. Changes in core network functions impacting reachability cannot be automated because of ongoing connectivity requirements for the OAM equipment itself, and widely used OAM protocols are not secure enough to be carried across the network without security concerns.
This document describes how to integrate OAM processes with an autonomic control plane in order to provide stable and secure connectivity for those OAM processes. This connectivity is not subject to the aforementioned circular dependencies. |
|
| |
| RFC 8369 | Internationalizing IPv6 Using 128-Bit Unicode |
| |
| Authors: | H. Kaplan. |
| Date: | 1 April 2018 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8369 |
|
It is clear that Unicode will eventually exhaust its supply of code points, and more will be needed. Assuming ISO and the UnicodeConsortium follow the practices of the IETF, the next Unicode code point size will be 128 bits. This document describes how this future128-bit Unicode can be leveraged to improve IPv6 adoption and finally bring internationalization support to IPv6. |
|
| |
| RFC 8372 | MPLS Flow Identification Considerations |
| |
| Authors: | S. Bryant, C. Pignataro, M. Chen, Z. Li, G. Mirsky. |
| Date: | May 2018 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8372 |
|
This document discusses aspects to consider when developing a solution for MPLS flow identification. The key application that needs this solution is in-band performance monitoring of MPLS flows when MPLS is used to encapsulate user data packets. |
|
| |
| RFC 8374 | BGPsec Design Choices and Summary of Supporting Discussions |
| |
| Authors: | K. Sriram, Ed.. |
| Date: | April 2018 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8374 |
|
This document captures the design rationale of the initial draft version of what became RFC 8205 (the BGPsec protocol specification).The designers needed to balance many competing factors, and this document lists the decisions that were made in favor of or against each design choice. This document also presents brief summaries of the arguments that aided the decision process. Where appropriate, this document also provides brief notes on design decisions that changed as the specification was reviewed and updated by the IETFSIDR Working Group and that resulted in RFC 8205. These notes highlight the differences and provide pointers to details and rationale regarding those design changes. |
|
| |
| RFC 8376 | Low-Power Wide Area Network (LPWAN) Overview |
| |
| Authors: | S. Farrell, Ed.. |
| Date: | May 2018 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8376 |
|
Low-Power Wide Area Networks (LPWANs) are wireless technologies with characteristics such as large coverage areas, low bandwidth, possibly very small packet and application-layer data sizes, and long battery life operation. This memo is an informational overview of the set ofLPWAN technologies being considered in the IETF and of the gaps that exist between the needs of those technologies and the goal of runningIP in LPWANs. |
|
| |
| RFC 8385 | Transparent Interconnection of Lots of Links (TRILL) Transparent Transport over MPLS |
| |
| Authors: | M. Umair, S. Kingston Smiler, D. Eastlake 3rd, L. Yong. |
| Date: | June 2018 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8385 |
|
This document specifies methods to interconnect multiple TRILL(Transparent Interconnection of Lots of Links) sites with an intervening MPLS network using existing TRILL and VPLS (VirtualPrivate LAN Service) standards. This document addresses two problems: 1) providing connection between more than two TRILL sites that are separated by an MPLS provider network and 2) providing a single logical virtualized TRILL network for different tenants that are separated by an MPLS provider network. |
|
| |
| RFC 8386 | Privacy Considerations for Protocols Relying on IP Broadcast or Multicast |
| |
| Authors: | R. Winter, M. Faath, F. Weisshaar. |
| Date: | May 2018 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8386 |
|
A number of application-layer protocols make use of IP broadcast or multicast messages for functions such as local service discovery or name resolution. Some of these functions can only be implemented efficiently using such mechanisms. When using broadcast or multicast messages, a passive observer in the same broadcast or multicast domain can trivially record these messages and analyze their content.Therefore, designers of protocols that make use of broadcast or multicast messages need to take special care when designing their protocols. |
|
| |
| RFC 8387 | Practical Considerations and Implementation Experiences in Securing Smart Object Networks |
| |
| Authors: | M. Sethi, J. Arkko, A. Keranen, H. Back. |
| Date: | May 2018 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8387 |
|
This memo describes challenges associated with securing resource- constrained smart object devices. The memo describes a possible deployment model where resource-constrained devices sign message objects, discusses the availability of cryptographic libraries for resource-constrained devices, and presents some preliminary experiences with those libraries for message signing on resource- constrained devices. Lastly, the memo discusses trade-offs involving different types of security approaches. |
|
| |
| RFC 8388 | Usage and Applicability of BGP MPLS-Based Ethernet VPN |
| |
| Authors: | J. Rabadan, Ed., S. Palislamovic, W. Henderickx, A. Sajassi, J. Uttaro. |
| Date: | May 2018 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8388 |
|
This document discusses the usage and applicability of BGP MPLS-basedEthernet VPN (EVPN) in a simple and fairly common deployment scenario. The different EVPN procedures are explained in the example scenario along with the benefits and trade-offs of each option. This document is intended to provide a simplified guide for the deployment of EVPN networks. |
|
| |
| RFC 8391 | XMSS: eXtended Merkle Signature Scheme |
| |
| Authors: | A. Huelsing, D. Butin, S. Gazdag, J. Rijneveld, A. Mohaisen. |
| Date: | May 2018 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8391 |
|
This note describes the eXtended Merkle Signature Scheme (XMSS), a hash-based digital signature system that is based on existing descriptions in scientific literature. This note specifiesWinternitz One-Time Signature Plus (WOTS+), a one-time signature scheme; XMSS, a single-tree scheme; and XMSS^MT, a multi-tree variant of XMSS. Both XMSS and XMSS^MT use WOTS+ as a main building block.XMSS provides cryptographic digital signatures without relying on the conjectured hardness of mathematical problems. Instead, it is proven that it only relies on the properties of cryptographic hash functions. XMSS provides strong security guarantees and is even secure when the collision resistance of the underlying hash function is broken. It is suitable for compact implementations, is relatively simple to implement, and naturally resists side-channel attacks.Unlike most other signature systems, hash-based signatures can so far withstand known attacks using quantum computers. |
|
| |
| RFC 8394 | Split Network Virtualization Edge (Split-NVE) Control-Plane Requirements |
| |
| Authors: | Y. Li, D. Eastlake 3rd, L. Kreeger, T. Narten, D. Black. |
| Date: | May 2018 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8394 |
|
In the Split Network Virtualization Edge (Split-NVE) architecture, the functions of the NVE are split across a server and a piece of external network equipment that is called an "External NVE". The server-resident control-plane functionality resides in control software, which may be part of hypervisor or container-management software; for simplicity, this document refers to the hypervisor as the "location" of this software.
One or more control-plane protocols between a hypervisor and its associated External NVE(s) are used by the hypervisor to distribute its virtual-machine networking state to the External NVE(s) for further handling. This document illustrates the functionality required by this type of control-plane signaling protocol and outlines the high-level requirements. Virtual-machine states as well as state transitioning are summarized to help clarify the protocol requirements. |
|
| |
| RFC 8396 | Managing, Ordering, Distributing, Exposing, and Registering Telephone Numbers (MODERN): Problem Statement, Use Cases, and Framework |
| |
| Authors: | J. Peterson, T. McGarry. |
| Date: | July 2018 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8396 |
|
The functions of the Public Switched Telephone Network (PSTN) are rapidly migrating to the Internet. This is generating new requirements for many traditional elements of the PSTN, includingTelephone Numbers (TNs). TNs no longer serve simply as telephone routing addresses: they are now identifiers that may be used byInternet-based services for a variety of purposes including session establishment, identity verification, and service enablement. This problem statement examines how the existing tools for allocating and managing telephone numbers do not align with the use cases of theInternet environment and proposes a framework for Internet-based services relying on TNs. |
|
| |
| RFC 8403 | A Scalable and Topology-Aware MPLS Data-Plane Monitoring System |
| |
| Authors: | R. Geib, Ed., C. Filsfils, C. Pignataro, Ed., N. Kumar. |
| Date: | July 2018 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8403 |
|
This document describes features of an MPLS path monitoring system and related use cases. Segment-based routing enables a scalable and simple method to monitor data-plane liveliness of the complete set of paths belonging to a single domain. The MPLS monitoring system adds features to the traditional MPLS ping and Label Switched Path (LSP) trace, in a very complementary way. MPLS topology awareness reduces management and control-plane involvement of Operations,Administration, and Maintenance (OAM) measurements while enabling newOAM features. |
|
| |
| RFC 8404 | Effects of Pervasive Encryption on Operators |
| |
| Authors: | K. Moriarty, Ed., A. Morton, Ed.. |
| Date: | July 2018 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8404 |
|
Pervasive monitoring attacks on the privacy of Internet users are of serious concern to both user and operator communities. RFC 7258 discusses the critical need to protect users' privacy when developingIETF specifications and also recognizes that making networks unmanageable to mitigate pervasive monitoring is not an acceptable outcome: an appropriate balance is needed. This document discusses current security and network operations as well as management practices that may be impacted by the shift to increased use of encryption to help guide protocol development in support of manageable and secure networks. |
|
| |
| RFC 8406 | Taxonomy of Coding Techniques for Efficient Network Communications |
| |
| Authors: | B. Adamson, C. Adjih, J. Bilbao, V. Firoiu, F. Fitzek, S. Ghanem, E. Lochin, A. Masucci, M-J. Montpetit, M. Pedersen, G. Peralta, V. Roca, Ed., P. Saxena, S. Sivakumar. |
| Date: | June 2018 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8406 |
|
This document summarizes recommended terminology for Network Coding concepts and constructs. It provides a comprehensive set of terms in order to avoid ambiguities in future IRTF and IETF documents onNetwork Coding. This document is the product of the Coding forEfficient Network Communications Research Group (NWCRG), and it is in line with the terminology used by the RFCs produced by the ReliableMulticast Transport (RMT) and FEC Framework (FECFRAME) IETF working groups. |
|
| |
| RFC 8409 | The Entity Category Security Assertion Markup Language (SAML) Attribute Types |
| |
| Authors: | I. Young, Ed., L. Johansson, S. Cantor. |
| Date: | August 2018 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8409 |
|
This document describes two SAML entity attributes: one that can be used to assign category membership semantics to an entity and another for use in claiming interoperation with or support for entities in such categories.
This document is a product of the working group process of theResearch and Education FEDerations (REFEDS) group. |
|
| |
| RFC 8411 | IANA Registration for the Cryptographic Algorithm Object Identifier Range |
| |
| Authors: | J. Schaad, R. Andrews. |
| Date: | August 2018 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8411 |
|
When the Curdle Security Working Group was chartered, a range of object identifiers was donated by DigiCert, Inc. for the purpose of registering the Edwards Elliptic Curve key agreement and signature algorithms. This donated set of OIDs allowed for shorter values than would be possible using the existing S/MIME or PKIX arcs. This document describes the donated range and the identifiers that were assigned from that range, transfers control of that range to IANA, and establishes IANA allocation policies for any future assignments within that range. |
|
| |
| RFC 8413 | Framework for Scheduled Use of Resources |
| |
| Authors: | Y. Zhuang, Q. Wu, H. Chen, A. Farrel. |
| Date: | July 2018 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8413 |
|
Time-Scheduled (TS) reservation of Traffic Engineering (TE) resources can be used to provide resource booking for TE Label Switched Paths so as to better guarantee services for customers and to improve the efficiency of network resource usage at any moment in time, including network usage that is planned for the future. This document provides a framework that describes and discusses the architecture for supporting scheduled reservation of TE resources. This document does not describe specific protocols or protocol extensions needed to realize this service. |
|
| |
| RFC 8423 | Reclassification of Suite B Documents to Historic Status |
| |
| Authors: | R. Housley, L. Zieglar. |
| Date: | July 2018 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8423 |
|
This document reclassifies the RFCs related to the United StatesNational Security Agency (NSA) Suite B cryptographic algorithms asHistoric, and it discusses the reasons for doing so. This document moves seven Informational RFCs to Historic status: RFCs 5759, 6239,6318, 6379, 6380, 6403, and 6460. In addition, it moves three obsolete Informational RFCs to Historic status: RFCs 4869, 5008, and5430. |
|
| |
| RFC 8426 | Recommendations for RSVP-TE and Segment Routing (SR) Label Switched Path (LSP) Coexistence |
| |
| Authors: | H. Sitaraman, Ed., V. Beeram, I. Minei, S. Sivabalan. |
| Date: | July 2018 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8426 |
|
Operators are looking to introduce services over Segment Routing (SR)Label Switched Paths (LSPs) in networks running Resource ReservationProtocol - Traffic Engineering (RSVP-TE) LSPs. In some instances, operators are also migrating existing services from RSVP-TE to SRLSPs. For example, there might be certain services that are well suited for SR and need to coexist with RSVP-TE in the same network.Such introduction or migration of traffic to SR might require coexistence with RSVP-TE in the same network for an extended period of time, depending on the operator's intent. The following document provides solution options for keeping the traffic engineering database consistent across the network, accounting for the different bandwidth utilization between SR and RSVP-TE. |
|
| |
| RFC 8427 | Representing DNS Messages in JSON |
| |
| Authors: | P. Hoffman. |
| Date: | July 2018 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8427 |
|
Some applications use DNS messages, or parts of DNS messages, as data. For example, a system that captures DNS queries and responses might want to be able to easily search them without having to decode the messages each time. Another example is a system that puts together DNS queries and responses from message parts. This document describes a general format for DNS message data in JSON. Specific profiles of the format in this document can be described in other documents for specific applications and usage scenarios. |
|
| |
| RFC 8430 | RIB Information Model |
| |
| Authors: | N. Bahadur, Ed., S. Kini, Ed., J. Medved. |
| Date: | September 2018 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8430 |
|
Routing and routing functions in enterprise and carrier networks are typically performed by network devices (routers and switches) using aRouting Information Base (RIB). Protocols and configurations push data into the RIB, and the RIB manager installs state into the hardware for packet forwarding. This document specifies an information model for the RIB to enable defining a standardized data model. The IETF's I2RS WG used this document to design the I2RS RIB data model. This document is being published to record the higher- level information model decisions for RIBs so that other developers of RIBs may benefit from the design concepts. |
|
| |
| RFC 8432 | A Framework for Management and Control of Microwave and Millimeter Wave Interface Parameters |
| |
| Authors: | J. Ahlberg, Ed., M. Ye, Ed., X. Li, LM. Contreras, CJ. Bernardos. |
| Date: | October 2018 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8432 |
|
The unification of control and management of microwave radio link interfaces is a precondition for seamless multi-layer networking and automated network provisioning and operation.
This document describes the required characteristics and use cases for control and management of radio link interface parameters using aYANG data model.
The purpose is to create a framework to identify the necessary information elements and define a YANG data model for control and management of the radio link interfaces in a microwave node. Some parts of the resulting model may be generic and could also be used by other technologies, e.g., Ethernet technology. |
|
| |
| RFC 8433 | A Simpler Method for Resolving Alert-Info URNs |
| |
| Authors: | D. Worley. |
| Date: | August 2018 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8433 |
|
The "alert" namespace of Uniform Resource Names (URNs) can be used in the Alert-Info header field of Session Initiation Protocol (SIP) requests and responses to inform a voice over IP (VoIP) telephone(user agent) of the characteristics of the call that the user agent has originated or terminated. The user agent must resolve the URNs into a signal; that is, it must select the best available signal to present to its user to indicate the characteristics of the call.
RFC 7462 describes a non-normative algorithm for signal selection.This document describes a more efficient alternative algorithm: a user agent's designer can, based on the user agent's signals and their meanings, construct a finite state machine (FSM) to process theURNs to select a signal in a way that obeys the restrictions given in the definition of the "alert" URN namespace. |
|
| |
| RFC 8439 | 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 SecurityConsiderations section. |
|
| |
| RFC 8448 | Example Handshake Traces for TLS 1.3 |
| |
| Authors: | M. Thomson. |
| Date: | January 2019 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8448 |
|
This document includes examples of TLS 1.3 handshakes. Private keys and inputs are provided so that these handshakes might be reproduced.Intermediate values, including secrets, traffic keys, and IVs, are shown so that implementations might be checked incrementally against these values. |
|
| |
| RFC 8451 | Considerations for Selecting RTP Control Protocol (RTCP) Extended Report (XR) Metrics for the WebRTC Statistics API |
| |
| Authors: | V. Singh, R. Huang, R. Even, D. Romascanu, L. Deng. |
| Date: | September 2018 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8451 |
|
This document describes monitoring features related to media streams in Web real-time communication (WebRTC). It provides a list of RTPControl Protocol (RTCP) Sender Report (SR), Receiver Report (RR), andExtended Report (XR) metrics, which may need to be supported by RTP implementations in some diverse environments. It lists a set of identifiers for the WebRTC's statistics API. These identifiers are a set of RTCP SR, RR, and XR metrics related to the transport of multimedia flows. |
|
| |
| RFC 8452 | AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption |
| |
| Authors: | S. Gueron, A. Langley, Y. Lindell. |
| Date: | April 2019 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8452 |
|
This memo specifies two authenticated encryption algorithms that are nonce misuse resistant -- that is, they do not fail catastrophically if a nonce is repeated.
This document is the product of the Crypto Forum Research Group. |
|
| |
| RFC 8453 | Framework for Abstraction and Control of TE Networks (ACTN) |
| |
| Authors: | D. Ceccarelli, Ed., Y. Lee, Ed.. |
| Date: | August 2018 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8453 |
|
Traffic Engineered (TE) networks have a variety of mechanisms to facilitate the separation of the data plane and control plane. They also have a range of management and provisioning protocols to configure and activate network resources. These mechanisms represent key technologies for enabling flexible and dynamic networking. The term "Traffic Engineered network" refers to a network that uses any connection-oriented technology under the control of a distributed or centralized control plane to support dynamic provisioning of end-to- end connectivity.
Abstraction of network resources is a technique that can be applied to a single network domain or across multiple domains to create a single virtualized network that is under the control of a network operator or the customer of the operator that actually owns the network resources.
This document provides a framework for Abstraction and Control of TENetworks (ACTN) to support virtual network services and connectivity services. |
|
| |
| RFC 8454 | Information Model for Abstraction and Control of TE Networks (ACTN) |
| |
| Authors: | Y. Lee, S. Belotti, D. Dhody, D. Ceccarelli, B. Yoon. |
| Date: | September 2018 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8454 |
|
This document provides an information model for Abstraction andControl of TE Networks (ACTN). |
|
| |
| RFC 8455 | Terminology for Benchmarking Software-Defined Networking (SDN) Controller Performance |
| |
| Authors: | V. Bhuvaneswaran, A. Basil, M. Tassinari, V. Manral, S. Banks. |
| Date: | October 2018 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8455 |
|
This document defines terminology for benchmarking a Software-DefinedNetworking (SDN) controller's control-plane performance. It extends the terminology already defined in RFC 7426 for the purpose of benchmarking SDN Controllers. The terms provided in this document help to benchmark an SDN Controller's performance independently of the controller's supported protocols and/or network services. |
|
| |
| RFC 8456 | Benchmarking Methodology for Software-Defined Networking (SDN) Controller Performance |
| |
| Authors: | V. Bhuvaneswaran, A. Basil, M. Tassinari, V. Manral, S. Banks. |
| Date: | October 2018 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8456 |
|
This document defines methodologies for benchmarking the control- plane performance of Software-Defined Networking (SDN) Controllers.The SDN Controller is a core component in the SDN architecture that controls the behavior of the network. SDN Controllers have been implemented with many varying designs in order to achieve their intended network functionality. Hence, the authors of this document have taken the approach of considering an SDN Controller to be a black box, defining the methodology in a manner that is agnostic to protocols and network services supported by controllers. This document provides a method for measuring the performance of all controller implementations. |
|
| |
| RFC 8458 | Using National Bibliography Numbers as Uniform Resource Names |
| |
|
|
National Bibliography Numbers (NBNs) are used by national libraries and other organizations in order to identify resources in their collections. NBNs are usually applied to resources that are not catered for by established (standard) identifier systems such asInternational Standard Book Number (ISBN).
A Uniform Resource Name (URN) namespace for NBNs was established in2001 in RFC 3188. Since then, a number of European national libraries have implemented URN:NBN-based systems.
This document replaces RFC 3188 and defines how NBNs can be supported within the updated URN framework. A revised namespace registration(version 4) compliant to RFC 8141 is included. |
|
| |
| RFC 8462 | Report from the IAB Workshop on Managing Radio Networks in an Encrypted World (MaRNEW) |
| |
| Authors: | N. Rooney, S. Dawkins, Ed.. |
| Date: | October 2018 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8462 |
|
The Internet Architecture Board (IAB) and GSM Association (GSMA) held a joint workshop on Managing Radio Networks in an Encrypted World(MaRNEW), on September 24-25, 2015. This workshop aimed to discuss solutions for bandwidth optimization on mobile networks for encrypted content, as current solutions rely on unencrypted content, which is not indicative of the security needs of today's Internet users. The workshop gathered IETF attendees, IAB members, and participants from various organizations involved in the telecommunications industry including original equipment manufacturers, content providers, and mobile network operators.
The group discussed Internet encryption trends and deployment issues identified within the IETF and the privacy needs of users that should be adhered to. Solutions designed around sharing data from the network to the endpoints and vice versa were then discussed; in addition, issues experienced when using current transport-layer protocols were also discussed. Content providers and ContentDelivery Networks (CDNs) gave their own views of their experiences delivering their content with mobile network operators. Finally, technical responses to regulation were discussed to help the regulated industries relay the issues of impossible-to-implement or bad-for-privacy technologies back to regulators.
A group of suggested solutions were devised, which will be discussed in various IETF groups moving forward. |
|
| |
| RFC 8464 | A URN Namespace for Device Identity and Mobile Equipment Identity (MEID) |
| |
| Authors: | R. Atarius. |
| Date: | September 2018 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8464 |
|
This document defines a Uniform Resource Name (URN) namespace for theThird Generation Partnership Project 2 (3GPP2) and a NamespaceSpecific String (NSS) for the Mobile Equipment Identity (MEID). The structure of an MEID is 15 hexadecimal digits long and is defined in the 3GPP2 to uniquely identify each individual mobile equipment(e.g., a handset or mobile phone). The 3GPP2 has a requirement to be able to use an MEID as a URN. This document fulfills that requirement. |
|
| |
| RFC 8465 | Using the Mobile Equipment Identity (MEID) URN as an Instance ID |
| |
| Authors: | R. Atarius, Ed.. |
| Date: | September 2018 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8465 |
|
This document specifies how the Uniform Resource Name (URN) namespace reserved for the Third Generation Partnership Project 2 (3GPP2) identities and its Namespace Specific String (NSS) for the MobileEquipment Identity (MEID) can be used as an Instance ID. The purpose of this Instance ID is to fulfill the requirements for defining how a specific URN needs to be constructed and used in the "+sip.instance"Contact header field parameter for outbound behavior. |
|
| |
| RFC 8468 | IPv4, IPv6, and IPv4-IPv6 Coexistence: Updates for the IP Performance Metrics (IPPM) Framework |
| |
| Authors: | A. Morton, J. Fabini, N. Elkins, M. Ackermann, V. Hegde. |
| Date: | November 2018 |
| Formats: | txt json html |
| Updates: | RFC 2330 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8468 |
|
This memo updates the IP Performance Metrics (IPPM) framework defined by RFC 2330 with new considerations for measurement methodology and testing. It updates the definition of standard-formed packets to include IPv6 packets, deprecates the definition of minimal IP packet, and augments distinguishing aspects, referred to as Type-P, for test packets in RFC 2330. This memo identifies that IPv4-IPv6 coexistence can challenge measurements within the scope of the IPPM framework.Example use cases include, but are not limited to, IPv4-IPv6 translation, NAT, and protocol encapsulation. IPv6 header compression and use of IPv6 over Low-Power Wireless Area Networks(6LoWPAN) are considered and excluded from the standard-formed packet evaluation. |
|
| |
| RFC 8475 | Using Conditional Router Advertisements for Enterprise Multihoming |
| |
| Authors: | J. Linkova, M. Stucchi. |
| Date: | October 2018 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8475 |
|
This document discusses the most common scenarios of connecting an enterprise network to multiple ISPs using an address space assigned by an ISP and how the approach proposed in "Enterprise Multihoming using Provider-Assigned Addresses without Network Prefix Translation:Requirements and Solution" could be applied in those scenarios. The problem of enterprise multihoming without address translation of any form has not been solved yet as it requires both the network to select the correct egress ISP based on the packet source address and hosts to select the correct source address based on the desired egress ISP for that traffic. The aforementioned document proposes a solution to this problem by introducing a new routing functionality(Source Address Dependent Routing) to solve the uplink selection issue. It also proposes using Router Advertisements to influence the host source address selection. It focuses on solving the general problem and covering various complex use cases, and this document adopts its proposed approach to provide a solution for a limited number of common use cases. In particular, the focus of this document is on scenarios in which an enterprise network has twoInternet uplinks used either in primary/backup mode or simultaneously and hosts in that network might not yet properly support multihoming as described in RFC 8028. |
|
| |
| RFC 8477 | Report from the Internet of Things (IoT) Semantic Interoperability (IOTSI) Workshop 2016 |
| |
| Authors: | J. Jimenez, H. Tschofenig, D. Thaler. |
| Date: | October 2018 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8477 |
|
This document provides a summary of the "Workshop on Internet ofThings (IoT) Semantic Interoperability (IOTSI)", which took place inSanta Clara, California March 17-18, 2016. The main goal of the workshop was to foster a discussion on the different approaches used by companies and Standards Developing Organizations (SDOs) to accomplish interoperability at the application layer. This report summarizes the discussions and lists recommendations to the standards community. The views and positions in this report are those of the workshop participants and do not necessarily reflect those of the authors or the Internet Architecture Board (IAB), which organized the workshop. Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions. |
|
| |
| RFC 8478 | Zstandard Compression and the application/zstd Media Type |
| |
| Authors: | Y. Collet, M. Kucherawy, Ed.. |
| Date: | October 2018 |
| Formats: | txt json html |
| Obsoleted by: | RFC 8878 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8478 |
|
Zstandard, or "zstd" (pronounced "zee standard"), is a data compression mechanism. This document describes the mechanism and registers a media type and content encoding to be used when transporting zstd-compressed content via Multipurpose Internet MailExtensions (MIME).
Despite use of the word "standard" as part of its name, readers are advised that this document is not an Internet Standards Track specification; it is being published for informational purposes only. |
|
| |
| RFC 8479 | Storing Validation Parameters in PKCS#8 |
| |
| Authors: | N. Mavrogiannopoulos. |
| Date: | September 2018 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8479 |
|
This memo describes a method of storing parameters needed for private-key validation in the Private-Key Information SyntaxSpecification as defined in PKCS#8 format (RFC 5208). It is equally applicable to the alternative implementation of the Private-KeyInformation Syntax Specification as defined in RFC 5958.
The approach described in this document encodes the parameters under a private enterprise extension and does not form part of a formal standard. |
|
| |
| RFC 8483 | Yeti DNS Testbed |
| |
| Authors: | L. Song, Ed., D. Liu, P. Vixie, A. Kato, S. Kerr. |
| Date: | October 2018 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8483 |
|
Yeti DNS is an experimental, non-production root server testbed that provides an environment where technical and operational experiments can safely be performed without risk to production root server infrastructure. This document aims solely to document the technical and operational experience of deploying a system that is similar to but different from the Root Server system (on which the Internet'sDomain Name System is designed and built). |
|
| |
| RFC 8488 | RIPE NCC's Implementation of Resource Public Key Infrastructure (RPKI) Certificate Tree Validation |
| |
| Authors: | O. Muravskiy, T. Bruijnzeels. |
| Date: | December 2018 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8488 |
|
This document describes an approach to validating the content of theResource Public Key Infrastructure (RPKI) certificate tree, as it is implemented in the RIPE NCC RPKI Validator. This approach is independent of a particular object retrieval mechanism, which allows it to be used with repositories available over the rsync protocol, the RPKI Repository Delta Protocol (RRDP), and repositories that use a mix of both. |
|
| |
| RFC 8492 | Secure Password Ciphersuites for Transport Layer Security (TLS) |
| |
| Authors: | D. Harkins, Ed.. |
| Date: | February 2019 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8492 |
|
This memo defines several new ciphersuites for the Transport LayerSecurity (TLS) protocol to support certificateless, secure authentication using only a simple, low-entropy password. The exchange is called "TLS-PWD". The ciphersuites are all based on an authentication and key exchange protocol, named "dragonfly", that is resistant to offline dictionary attacks. |
|
| |
| RFC 8493 | The BagIt File Packaging Format (V1.0) |
| |
| Authors: | J. Kunze, J. Littman, E. Madden, J. Scancella, C. Adams. |
| Date: | October 2018 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8493 |
|
This document describes BagIt, a set of hierarchical file layout conventions for storage and transfer of arbitrary digital content. A"bag" has just enough structure to enclose descriptive metadata"tags" and a file "payload" but does not require knowledge of the payload's internal semantics. This BagIt format is suitable for reliable storage and transfer. |
|
| |
| RFC 8494 | Multicast Email (MULE) over Allied Communications Publication (ACP) 142 |
| |
| Authors: | D. Wilson, A. Melnikov, Ed.. |
| Date: | November 2018 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8494 |
|
Allied Communications Publication (ACP) 142 defines P_MUL, which is a protocol for reliable multicast suitable for bandwidth-constrained and delayed acknowledgement (Emissions Control or "EMCON") environments running over UDP. This document defines MULE (MulticastEmail), an application protocol for transferring Internet Mail messages (as described in RFC 5322) over P_MUL (as defined in ACP142). MULE enables transfer between Message Transfer Agents (MTAs).It doesn't provide a service similar to SMTP Submission (as described in RFC 6409).
This document explains how MULE can be used in conjunction with SMTP(RFC 5321), including some common SMTP extensions, to provide an alternate MTA-to-MTA transfer mechanism.
This is not an IETF specification; it describes an existing implementation. It is provided in order to facilitate interoperable implementations and third-party diagnostics. |
|
| |
| RFC 8496 | P-Charge-Info: A Private Header Field (P-Header) Extension to the Session Initiation Protocol (SIP) |
| |
| Authors: | D. York, T. Asveren. |
| Date: | October 2018 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8496 |
|
This text documents the current usage of P-Charge-Info, an existingSession Initiation Protocol (SIP) private header field (P-Header) used to convey billing information about the party to be charged.This P-Header is currently used in production by several equipment vendors and carriers and has been in use since at least 2007. This document details the registration of this header field with IANA. |
|
| |
| RFC 8498 | A P-Served-User Header Field Parameter for an Originating Call Diversion (CDIV) Session Case in the Session Initiation Protocol (SIP) |
| |
|
|
The P-Served-User header field was defined based on a requirement from the 3rd Generation Partnership Project (3GPP) IMS (IP MultimediaSubsystem) in order to convey the identity of the served user, his/ her registration state, and the session case that applies to that particular communication session and application invocation. A session case is metadata that captures the status of the session of a served user regardless of whether or not the served user is registered or the session originates or terminates with the served user. This document updates RFC 5502 by defining a new P-Served-User header field parameter, "orig-cdiv". The parameter conveys the session case used by a proxy when handling an originating session after Call Diversion (CDIV) services have been invoked for the served user. This document also fixes the ABNF in RFC 5502 and provides more guidance for using the P-Served-User header field in IP networks. |
|
| |
| RFC 8501 | Reverse DNS in IPv6 for Internet Service Providers |
| |
| Authors: | L. Howard. |
| Date: | November 2018 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8501 |
|
In IPv4, Internet Service Providers (ISPs) commonly provideIN-ADDR.ARPA information for their customers by prepopulating the zone with one PTR record for every available address. This practice does not scale in IPv6. This document analyzes different approaches and considerations for ISPs in managing the IP6.ARPA zone. |
|
| |
| RFC 8515 | URN Namespace for ETSI Documents |
| |
| Authors: | M. Jethanandani, M.A. Reina Ortega. |
| Date: | February 2019 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8515 |
|
This document describes the Namespace Identifier (NID) "etsi" forUniform Resource Names (URNs) used to identify resources published by the European Telecommunications Standards Institute(http://etsi.org). ETSI specifies and manages resources that utilize this URN identification model. Management activities for these and other resource types are handled by the manager of the ETSI ProtocolNaming and Numbering Service (PNNS). |
|
| |
| RFC 8517 | An Inventory of Transport-Centric Functions Provided by Middleboxes: An Operator Perspective |
| |
| Authors: | D. Dolson, Ed., J. Snellman, M. Boucadair, Ed., C. Jacquenet. |
| Date: | February 2019 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8517 |
|
This document summarizes an operator's perception of the benefits that may be provided by intermediary devices that execute functions beyond normal IP forwarding. Such intermediary devices are often called "middleboxes".
RFC 3234 defines a taxonomy of middleboxes and issues in theInternet. Most of those middleboxes utilize or modify application- layer data. This document primarily focuses on devices that observe and act on information carried in the transport layer, and especially information carried in TCP packets. |
|
| |
| RFC 8522 | Looking Glass Command Set |
| |
| Authors: | M. Stubbig. |
| Date: | February 2019 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8522 |
|
This document introduces a command set standard to the web-based"Network Looking Glass" software. Its purpose is to provide application programmers uniform access to the Looking Glass service and to analyze a standardized response.
The interface is supposed to provide the same level of information as web-based interfaces, but in a computer-readable format. |
|
| |
| RFC 8540 | Stream Control Transmission Protocol: Errata and Issues in RFC 4960 |
| |
| Authors: | R. Stewart, M. Tuexen, M. Proshin. |
| Date: | February 2019 |
| Formats: | txt html json |
| Obsoleted by: | RFC 9260 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8540 |
|
This document is a compilation of issues found since the publication of RFC 4960 in September 2007, based on experience with implementing, testing, and using the Stream Control Transmission Protocol (SCTP) along with the suggested fixes. This document provides deltas to RFC4960 and is organized in a time-ordered way. The issues are listed in the order in which they were brought up. Because some text is changed several times, the last delta in the text is the one that should be applied. In addition to the deltas, a description of each problem and the details of the solution for each are also provided. |
|
| |
| RFC 8541 | Impact of Shortest Path First (SPF) Trigger and Delay Strategies on IGP Micro-loops |
| |
| Authors: | S. Litkowski, B. Decraene, M. Horneffer. |
| Date: | March 2019 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8541 |
|
A micro-loop is a packet-forwarding loop that may occur transiently among two or more routers in a hop-by-hop packet-forwarding paradigm.
This document analyzes the impact of using different link state IGP implementations in a single network with respect to micro-loops. The analysis is focused on the Shortest Path First (SPF) delay algorithm but also mentions the impact of SPF trigger strategies. |
|
| |
| RFC 8546 | The Wire Image of a Network Protocol |
| |
| Authors: | B. Trammell, M. Kuehlewind. |
| Date: | April 2019 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8546 |
|
This document defines the wire image, an abstraction of the information available to an on-path non-participant in a networking protocol. This abstraction is intended to shed light on the implications that increased encryption has for network functions that use the wire image. |
|
| |
| RFC 8554 | Leighton-Micali Hash-Based Signatures |
| |
| Authors: | D. McGrew, M. Curcio, S. Fluhrer. |
| Date: | April 2019 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8554 |
|
This note describes a digital-signature system based on cryptographic hash functions, following the seminal work in this area of Lamport,Diffie, Winternitz, and Merkle, as adapted by Leighton and Micali in1995. It specifies a one-time signature scheme and a general signature scheme. These systems provide asymmetric authentication without using large integer mathematics and can achieve a high security level. They are suitable for compact implementations, are relatively simple to implement, and are naturally resistant to side- channel attacks. Unlike many other signature systems, hash-based signatures would still be secure even if it proves feasible for an attacker to build a quantum computer.
This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. This has been reviewed by many researchers, both in the research group and outside of it. The Acknowledgements section lists many of them. |
|
| |
| RFC 8557 | Deterministic Networking Problem Statement |
| |
| Authors: | N. Finn, P. Thubert. |
| Date: | May 2019 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8557 |
|
This paper documents the needs in various industries to establish multi-hop paths for characterized flows with deterministic properties. |
|
| |
| RFC 8558 | Transport Protocol Path Signals |
| |
| Authors: | T. Hardie, Ed.. |
| Date: | April 2019 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8558 |
|
This document discusses the nature of signals seen by on-path elements examining transport protocols, contrasting implicit and explicit signals. For example, TCP's state machine uses a series of well-known messages that are exchanged in the clear. Because these are visible to network elements on the path between the two nodes setting up the transport connection, they are often used as signals by those network elements. In transports that do not exchange these messages in the clear, on-path network elements lack those signals.Often, the removal of those signals is intended by those moving the messages to confidential channels. Where the endpoints desire that network elements along the path receive these signals, this document recommends explicit signals be used. |
|
| |
| RFC 8565 | Hypertext Jeopardy Protocol (HTJP/1.0) |
| |
| Authors: | E. Fokschaner. |
| Date: | 1 April 2019 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8565 |
|
The Hypertext Jeopardy Protocol (HTJP) inverts the request/response semantics of the Hypertext Transfer Protocol (HTTP). Using conventional HTTP, one connects to a server, asks a question, and expects a correct answer. Using HTJP, one connects to a server, sends an answer, and expects a correct question. This document specifies the semantics of HTJP. |
|
| |
| RFC 8567 | Customer Management DNS Resource Records |
| |
| Authors: | E. Rye, R. Beverly. |
| Date: | 1 April 2019 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8567 |
|
Maintaining high Quality of Experience (QoE) increasingly requires end-to-end, holistic network management, including managed CustomerPremises Equipment (CPE). Because customer management is a shared global responsibility, the Domain Name System (DNS) provides an ideal existing infrastructure for maintaining authoritative customer information that must be readily, reliably, and publicly accessible.
This document describes four new DNS resource record types for encoding customer information in the DNS. These records are intended to better facilitate high customer QoE via inter-provider cooperation and management of customer data. |
|
| |
| RFC 8568 | Network Virtualization Research Challenges |
| |
| Authors: | CJ. Bernardos, A. Rahman, JC. Zuniga, LM. Contreras, P. Aranda, P. Lynch. |
| Date: | April 2019 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8568 |
|
This document describes open research challenges for network virtualization. Network virtualization is following a similar path as previously taken by cloud computing. Specifically, cloud computing popularized migration of computing functions (e.g., applications) and storage from local, dedicated, physical resources to remote virtual functions accessible through the Internet. In a similar manner, network virtualization is encouraging migration of networking functions from dedicated physical hardware nodes to a virtualized pool of resources. However, network virtualization can be considered to be a more complex problem than cloud computing as it not only involves virtualization of computing and storage functions but also involves abstraction of the network itself. This document describes current research and engineering challenges in network virtualization including the guarantee of quality of service, performance improvement, support for multiple domains, network slicing, service composition, device virtualization, privacy and security, separation of control concerns, network function placement, and testing. In addition, some proposals are made for new activities in the IETF and IRTF that could address some of these challenges.This document is a product of the Network Function VirtualizationResearch Group (NFVRG). |
|
| |
| RFC 8574 | cite-as: A Link Relation to Convey a Preferred URI for Referencing |
| |
| Authors: | H. Van de Sompel, M. Nelson, G. Bilder, J. Kunze, S. Warner. |
| Date: | April 2019 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8574 |
|
A web resource is routinely referenced by means of the URI with which it is directly accessed. But cases exist where referencing a resource by means of a different URI is preferred. This specification defines a link relation type that can be used to convey such a preference. |
|
| |
| RFC 8576 | Internet of Things (IoT) Security: State of the Art and Challenges |
| |
| Authors: | O. Garcia-Morchon, S. Kumar, M. Sethi. |
| Date: | April 2019 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8576 |
|
The Internet of Things (IoT) concept refers to the usage of standardInternet protocols to allow for human-to-thing and thing-to-thing communication. The security needs for IoT systems are well recognized, and many standardization steps to provide security have been taken -- for example, the specification of the ConstrainedApplication Protocol (CoAP) secured with Datagram Transport LayerSecurity (DTLS). However, security challenges still exist, not only because there are some use cases that lack a suitable solution, but also because many IoT devices and systems have been designed and deployed with very limited security capabilities. In this document, we first discuss the various stages in the lifecycle of a thing.Next, we document the security threats to a thing and the challenges that one might face to protect against these threats. Lastly, we discuss the next steps needed to facilitate the deployment of secureIoT systems. This document can be used by implementers and authors of IoT specifications as a reference for details about security considerations while documenting their specific security challenges, threat models, and mitigations.
This document is a product of the IRTF Thing-to-Thing Research Group(T2TRG). |
|
| |
| RFC 8578 | Deterministic Networking Use Cases |
| |
| Authors: | E. Grossman, Ed.. |
| Date: | May 2019 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8578 |
|
This document presents use cases for diverse industries that have in common a need for "deterministic flows". "Deterministic" in this context means that such flows provide guaranteed bandwidth, bounded latency, and other properties germane to the transport of time- sensitive data. These use cases differ notably in their network topologies and specific desired behavior, providing as a group broad industry context for Deterministic Networking (DetNet). For each use case, this document will identify the use case, identify representative solutions used today, and describe potential improvements that DetNet can enable. |
|
| |
| RFC 8585 | Requirements for IPv6 Customer Edge Routers to Support IPv4-as-a-Service |
| |
| Authors: | J. Palet Martinez, H. M.-H. Liu, M. Kawashima. |
| Date: | May 2019 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8585 |
|
This document specifies the IPv4 service continuity requirements forIPv6 Customer Edge (CE) routers that are provided either by the service provider or by vendors who sell through the retail market.
Specifically, this document extends the basic requirements for IPv6CE routers as described in RFC 7084 to allow the provisioning of IPv6 transition services for the support of IPv4-as-a-Service (IPv4aaS) by means of new transition mechanisms. The document only coversIPv4aaS, i.e., transition technologies for delivering IPv4 inIPv6-only access networks. IPv4aaS is necessary because there aren't sufficient IPv4 addresses available for every possible customer/ device. However, devices or applications in the customer Local AreaNetworks (LANs) may be IPv4-only or IPv6-only and still need to communicate with IPv4-only services on the Internet. |
|
| |
| RFC 8589 | The 'leaptofrogans' URI Scheme |
| |
| Authors: | A. Tamas, B. Phister, Ed., J-E. Rodriguez. |
| Date: | May 2019 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8589 |
|
This document describes the 'leaptofrogans' Uniform ResourceIdentifier (URI) scheme, which enables applications to launch FrogansPlayer on a given Frogans site. Frogans is a medium for publishing content and services on the Internet, defined as a generic software layer on the Internet. Frogans Player is software that enables end users to browse Frogans sites. |
|
| |
| RFC 8592 | Key Performance Indicator (KPI) Stamping for the Network Service Header (NSH) |
| |
| Authors: | R. Browne, A. Chilikin, T. Mizrahi. |
| Date: | May 2019 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8592 |
|
This document describes methods of carrying Key PerformanceIndicators (KPIs) using the Network Service Header (NSH). These methods may be used, for example, to monitor latency and QoS marking to identify problems on some links or service functions. |
|
| |
| RFC 8593 | Video Traffic Models for RTP Congestion Control Evaluations |
| |
| Authors: | X. Zhu, S. Mena, Z. Sarker. |
| Date: | May 2019 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8593 |
|
This document describes two reference video traffic models for evaluating RTP congestion control algorithms. The first model statistically characterizes the behavior of a live video encoder in response to changing requests on the target video rate. The second model is trace-driven and emulates the output of actual encoded video frame sizes from a high-resolution test sequence. Both models are designed to strike a balance between simplicity, repeatability, and authenticity in modeling the interactions between a live video traffic source and the congestion control module. Finally, the document describes how both approaches can be combined into a hybrid model. |
|
| |
| RFC 8594 | The Sunset HTTP Header Field |
| |
| Authors: | E. Wilde. |
| Date: | May 2019 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8594 |
|
This specification defines the Sunset HTTP response header field, which indicates that a URI is likely to become unresponsive at a specified point in the future. It also defines a sunset link relation type that allows linking to resources providing information about an upcoming resource or service sunset. |
|
| |
| RFC 8596 | MPLS Transport Encapsulation for the Service Function Chaining (SFC) Network Service Header (NSH) |
| |
| Authors: | A. Malis, S. Bryant, J. Halpern, W. Henderickx. |
| Date: | June 2019 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8596 |
|
This document describes how to use a Service Function Forwarder (SFF)Label (similar to a pseudowire label or VPN label) to indicate the presence of a Service Function Chaining (SFC) Network Service Header(NSH) between an MPLS label stack and the NSH original packet/frame.This allows SFC packets using the NSH to be forwarded between SFFs over an MPLS network. The label is also used to select between multiple SFFs in the destination MPLS node. |
|
| |
| RFC 8597 | Cooperating Layered Architecture for Software-Defined Networking (CLAS) |
| |
| Authors: | LM. Contreras, CJ. Bernardos, D. Lopez, M. Boucadair, P. Iovanna. |
| Date: | May 2019 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8597 |
|
Software-Defined Networking (SDN) advocates for the separation of the control plane from the data plane in the network nodes and its logical centralization on one or a set of control entities. Most of the network and/or service intelligence is moved to these control entities. Typically, such an entity is seen as a compendium of interacting control functions in a vertical, tightly integrated fashion. The relocation of the control functions from a number of distributed network nodes to a logical central entity conceptually places together a number of control capabilities with different purposes. As a consequence, the existing solutions do not provide a clear separation between transport control and services that rely upon transport capabilities.
This document describes an approach called Cooperating LayeredArchitecture for Software-Defined Networking (CLAS), wherein the control functions associated with transport are differentiated from those related to services in such a way that they can be provided and maintained independently and can follow their own evolution path. |
|
| |
| RFC 8603 | Commercial National Security Algorithm (CNSA) Suite Certificate and Certificate Revocation List (CRL) Profile |
| |
| Authors: | M. Jenkins, L. Zieglar. |
| Date: | May 2019 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8603 |
|
This document specifies a base profile for X.509 v3 Certificates andX.509 v2 Certificate Revocation Lists (CRLs) for use with the UnitedStates National Security Agency's Commercial National SecurityAlgorithm (CNSA) Suite. The profile applies to the capabilities, configuration, and operation of all components of US NationalSecurity Systems that employ such X.509 certificates. US NationalSecurity Systems are described in NIST Special Publication 800-59.It is also appropriate for all other US Government systems that process high-value information. It is made publicly available for use by developers and operators of these and any other system deployments. |
|
| |
| RFC 8604 | Interconnecting Millions of Endpoints with Segment Routing |
| |
| Authors: | C. Filsfils, Ed., S. Previdi, G. Dawra, Ed., W. Henderickx, D. Cooper. |
| Date: | June 2019 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8604 |
|
This document describes an application of Segment Routing to scale the network to support hundreds of thousands of network nodes, and tens of millions of physical underlay endpoints. This use case can be applied to the interconnection of massive-scale Data Centers (DCs) and/or large aggregation networks. Forwarding tables of midpoint and leaf nodes only require a few tens of thousands of entries. This may be achieved by the inherently scaleable nature of Segment Routing and the design proposed in this document. |
|
| |
| RFC 8605 | vCard Format Extensions: ICANN Extensions for the Registration Data Access Protocol (RDAP) |
| |
| Authors: | S. Hollenbeck, R. Carney. |
| Date: | May 2019 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8605 |
|
This document defines extensions to the vCard data format for representing and exchanging contact information used to implement theInternet Corporation for Assigned Names and Numbers (ICANN) operational profile for the Registration Data Access Protocol (RDAP).The property and parameter defined here are used to add values toRDAP responses that are consistent with ICANN policies. |
|
| |
| RFC 8607 | Calendaring Extensions to WebDAV (CalDAV): Managed Attachments |
| |
| Authors: | C. Daboo, A. Quillaud, K. Murchison, Ed.. |
| Date: | June 2019 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8607 |
|
This specification adds an extension to the Calendaring Extensions toWebDAV (CalDAV) to allow attachments associated with iCalendar data to be stored and managed on the server.
This specification documents existing code deployed by multiple vendors. It is published as an Informational specification rather than Standards Track due to its noncompliance with multiple best current practices of HTTP. |
|
| |
| RFC 8612 | DDoS Open Threat Signaling (DOTS) Requirements |
| |
| Authors: | A. Mortensen, T. Reddy, R. Moskowitz. |
| Date: | May 2019 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8612 |
|
This document defines the requirements for the Distributed Denial-of-Service (DDoS) Open Threat Signaling (DOTS) protocols enabling coordinated response to DDoS attacks. |
|
| |
| RFC 8631 | Link Relation Types for Web Services |
| |
| Authors: | E. Wilde. |
| Date: | July 2019 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8631 |
|
Many resources provided on the Web are part of sets of resources that are provided in a context that is managed by one particular service provider. Often, these sets of resources are referred to as "Web services" or "Web APIs". This specification defines link relations that represent relationships from Web services or APIs to resources that provide documentation, descriptions, metadata, or status information for these resources. Documentation is primarily intended for human consumers, whereas descriptions are primarily intended for automated consumers. Metadata provides information about a service's context. This specification also defines a link relation to identify status resources that are used to represent information about service status. |
|
| |
| RFC 8637 | Applicability of the Path Computation Element (PCE) to the Abstraction and Control of TE Networks (ACTN) |
| |
| Authors: | D. Dhody, Y. Lee, D. Ceccarelli. |
| Date: | July 2019 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8637 |
|
Abstraction and Control of TE Networks (ACTN) refers to the set of virtual network (VN) operations needed to orchestrate, control, and manage large-scale multidomain TE networks so as to facilitate network programmability, automation, efficient resource sharing, and end-to-end virtual service-aware connectivity and network function virtualization services.
The Path Computation Element (PCE) is a component, application, or network node that is capable of computing a network path or route based on a network graph and applying computational constraints. ThePCE serves requests from Path Computation Clients (PCCs) that communicate with it over a local API or using the Path ComputationElement Communication Protocol (PCEP).
This document examines the applicability of PCE to the ACTN framework. |
|
| |
| RFC 8643 | An Opportunistic Approach for Secure Real-time Transport Protocol (OSRTP) |
| |
| Authors: | A. Johnston, B. Aboba, A. Hutton, R. Jesske, T. Stach. |
| Date: | August 2019 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8643 |
|
Opportunistic Secure Real-time Transport Protocol (OSRTP) is an implementation of the Opportunistic Security mechanism, as defined inRFC 7435, applied to the Real-time Transport Protocol (RTP). OSRTP allows encrypted media to be used in environments where support for encryption is not known in advance and is not required. OSRTP does not require Session Description Protocol (SDP) extensions or features and is fully backwards compatible with existing implementations using encrypted and authenticated media and implementations that do not encrypt or authenticate media packets. OSRTP is not specific to any key management technique for Secure RTP (SRTP). OSRTP is a transitional approach useful for migrating existing deployments of real-time communications to a fully encrypted and authenticated state. |
|
| |
| RFC 8645 | Re-keying Mechanisms for Symmetric Keys |
| |
| Authors: | S. Smyshlyaev, Ed.. |
| Date: | August 2019 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8645 |
|
A certain maximum amount of data can be safely encrypted when encryption is performed under a single key. This amount is called the "key lifetime". This specification describes a variety of methods for increasing the lifetime of symmetric keys. It provides two types of re-keying mechanisms based on hash functions and block ciphers that can be used with modes of operations such as CTR, GCM,CBC, CFB, and OMAC.
This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. |
|
| |
| RFC 8649 | Hash Of Root Key Certificate Extension |
| |
| Authors: | R. Housley. |
| Date: | August 2019 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8649 |
|
This document specifies the Hash Of Root Key certificate extension.This certificate extension is carried in the self-signed certificate for a trust anchor, which is often called a Root CertificationAuthority (CA) certificate. This certificate extension unambiguously identifies the next public key that will be used at some point in the future as the next Root CA certificate, eventually replacing the current one. |
|
| |
| RFC 8653 | On-Demand Mobility Management |
| |
| Authors: | A. Yegin, D. Moses, S. Jeon. |
| Date: | October 2019 |
| Formats: | txt xml html pdf json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8653 |
|
Applications differ with respect to whether they need session continuity and/or IP address reachability. The network providing the same type of service to any mobile host and any application running on the host yields inefficiencies, as described in RFC 7333. This document defines a new concept of enabling applications to influence the network's mobility services (session continuity and/or IP address reachability) on a per-socket basis, and suggests extensions to the networking stack's API to accommodate this concept. |
|
| |
| RFC 8670 | BGP Prefix Segment in Large-Scale Data Centers |
| |
| Authors: | C. Filsfils, Ed., S. Previdi, G. Dawra, E. Aries, P. Lapukhov. |
| Date: | December 2019 |
| Formats: | txt pdf xml json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8670 |
|
This document describes the motivation for, and benefits of, applyingSegment Routing (SR) in BGP-based large-scale data centers. It describes the design to deploy SR in those data centers for both theMPLS and IPv6 data planes. |
|
| |
| RFC 8674 | 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. |
|
| |
| RFC 8677 | Name-Based Service Function Forwarder (nSFF) Component within a Service Function Chaining (SFC) Framework |
| |
| Authors: | D. Trossen, D. Purkayastha, A. Rahman. |
| Date: | November 2019 |
| Formats: | txt pdf xml html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8677 |
|
Adoption of cloud and fog technology allows operators to deploy a single "Service Function" (SF) to multiple "execution locations".The decision to steer traffic to a specific location may change frequently based on load, proximity, etc. Under the current ServiceFunction Chaining (SFC) framework, steering traffic dynamically to the different execution endpoints requires a specific "rechaining", i.e., a change in the service function path reflecting the differentIP endpoints to be used for the new execution points. This procedure may be complex and take time. In order to simplify rechaining and reduce the time to complete the procedure, we discuss separating the logical Service Function Path (SFP) from the specific execution endpoints. This can be done by identifying the SFs using a name rather than a routable IP endpoint (or Layer 2 address). This document describes the necessary extensions, additional functions, and protocol details in the Service Function Forwarder (SFF) to handle name-based relationships.
This document presents InterDigital's approach to name-based SFC. It does not represent IETF consensus and is presented here so that theSFC community may benefit from considering this mechanism and the possibility of its use in the edge data centers. |
|
| |
| RFC 8678 | Enterprise Multihoming using Provider-Assigned IPv6 Addresses without Network Prefix Translation: Requirements and Solutions |
| |
| Authors: | F. Baker, C. Bowers, J. Linkova. |
| Date: | December 2019 |
| Formats: | txt json pdf xml html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8678 |
|
Connecting an enterprise site to multiple ISPs over IPv6 using provider-assigned addresses is difficult without the use of some form of Network Address Translation (NAT). Much has been written on this topic over the last 10 to 15 years, but it still remains a problem without a clearly defined or widely implemented solution. Any multihoming solution without NAT requires hosts at the site to have addresses from each ISP and to select the egress ISP by selecting a source address for outgoing packets. It also requires routers at the site to take into account those source addresses when forwarding packets out towards the ISPs.
This document examines currently available mechanisms for providing a solution to this problem for a broad range of enterprise topologies.It covers the behavior of routers to forward traffic by taking into account source address, and it covers the behavior of hosts to select appropriate default source addresses. It also covers any possible role that routers might play in providing information to hosts to help them select appropriate source addresses. In the process of exploring potential solutions, this document also makes explicit requirements for how the solution would be expected to behave from the perspective of an enterprise site network administrator. |
|
| |
| RFC 8683 | Additional Deployment Guidelines for NAT64/464XLAT in Operator and Enterprise Networks |
| |
|
|
This document describes how Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers (NAT64) (including 464XLAT) can be deployed in an IPv6 network -- whether it's cellular ISP, broadbandISP, or enterprise -- and the possible optimizations. This document also discusses issues to be considered when having IPv6-only connectivity, such as: a) DNS64, b) applications or devices that use literal IPv4 addresses or non-IPv6-compliant APIs, and c) IPv4-only hosts or applications. |
|
| |
| RFC 8694 | Applicability of the Path Computation Element to Inter-area and Inter-AS MPLS and GMPLS Traffic Engineering |
| |
|
|
The Path Computation Element (PCE) may be used for computing services that traverse multi-area and multi-Autonomous System (multi-AS)Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS)Traffic-Engineered (TE) networks.
This document examines the applicability of the PCE architecture, protocols, and protocol extensions for computing multi-area and multi-AS paths in MPLS and GMPLS networks. |
|
| |
| RFC 8700 | 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. |
|
| |
| RFC 8701 | Applying Generate Random Extensions And Sustain Extensibility (GREASE) to TLS Extensibility |
| |
|
|
This document describes GREASE (Generate Random Extensions AndSustain Extensibility), a mechanism to prevent extensibility failures in the TLS ecosystem. It reserves a set of TLS protocol values that may be advertised to ensure peers correctly handle unknown values. |
|
| |
| RFC 8712 | The IETF-ISOC Relationship |
| |
|
|
This document summarizes the Internet Engineering Task Force (IETF) -Internet Society (ISOC) relationship, following a major revision to the structure of the IETF Administrative Support Activity (IASA) in2018. The IASA was revised under a new "IASA 2.0" structure by theIASA2 Working Group, which changed the IETF's administrative, legal, and financial structure. As a result, it also changed the relationship between the IETF and ISOC, which made it necessary to revise RFC 2031. |
|
| |
| RFC 8715 | IETF Administrative Support Activity 2.0: Update to the Process for Selection of Trustees for the IETF Trust |
| |
|
|
This document captures the rationale for the changes introduced inRFC 8714, "Update to the Process for Selection of Trustees for theIETF Trust".
At the time RFC 8714 was published, the changes to the IETFAdministrative Support Activity, Version 2.0 (IASA 2.0) had an impact on the IETF Trust because members of the IETF AdministrativeOversight Committee (IAOC), which was being phased out, had served asTrustees of the IETF Trust. This document provides background on the past IETF Trust arrangements, explains the effect of the rules in the founding documents during the transition to the new arrangement, and provides a rationale for the update. |
|
| |
| RFC 8720 | Principles for Operation of Internet Assigned Numbers Authority (IANA) Registries |
| |
|
|
This document provides principles for the operation of InternetAssigned Numbers Authority (IANA) registries. |
|
| |
| RFC 8721 | Advice to the Trustees of the IETF Trust on Rights to Be Granted in IETF Documents |
| |
|
|
Contributors grant intellectual property rights to the IETF. TheIETF Trust holds and manages those rights on behalf of the IETF. TheTrustees of the IETF Trust are responsible for that management. This management includes granting the licenses to copy, implement, and otherwise use IETF Contributions, among them Internet-Drafts andRFCs. The Trustees of the IETF Trust accept direction from the IETF regarding the rights to be granted. This document describes the desires of the IETF regarding outbound rights to be granted in IETFContributions. This document obsoletes RFC 5377 solely for the purpose of removing references to the IETF Administrative OversightCommittee (IAOC), which was part of the IETF Administrative SupportActivity (IASA). |
|
| |
| RFC 8722 | Defining the Role and Function of IETF Protocol Parameter Registry Operators |
| |
| Authors: | D. McPherson, Ed., O. Kolkman, Ed., J. Klensin, Ed., G. Huston, Ed.. |
| Date: | February 2020 |
| Formats: | txt html json xml pdf |
| Obsoletes: | RFC 6220 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8722 |
|
Many Internet Engineering Task Force (IETF) protocols make use of commonly defined values that are passed in messages or packets. To ensure consistent interpretation of these values between independent implementations, there is a need to ensure that the values and associated semantic intent are uniquely defined. The IETF uses registry functions to record assigned protocol parameter values and their associated semantic intentions. For each IETF protocol parameter, it is current practice for the IETF to delegate the role of Protocol Parameter Registry Operator to a nominated entity. This document provides a description of, and the requirements for, these delegated functions. This document obsoletes RFC 6220 to replace all references to the IETF Administrative Support Activity (IASA) and related structures with those defined by the IASA 2.0 Model. |
|
| |
| RFC 8726 | 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 theIETF and documented in RFCs developed on the IETF Stream.
The Independent Submission Stream is another source of documents that can be published as RFCs. This stream is under the care of theIndependent Submissions Editor (ISE).
This document complements RFC 4846 by providing a description of how the ISE currently handles documents in the Independent SubmissionStream that request actions from IANA. Nothing in this document changes existing IANA registries or their allocation policies, nor does it change any previously documented processes. |
|
| |
| RFC 8728 | RFC Editor Model (Version 2) |
| |
|
|
The RFC Editor model described in this document divides the responsibilities for the RFC Series into three functions: the RFCSeries Editor, the RFC Production Center, and the RFC Publisher.Internet Architecture Board (IAB) oversight via the RFC SeriesOversight Committee (RSOC) is described, as is the relationship between the IETF Administration Limited Liability Company and theRSOC. This document reflects the experience gained with "RFC EditorModel (Version 1)", documented in RFC 5620; and obsoletes RFC 6635 to replace all references to the IETF Administrative Support Activity(IASA) and related structures with those defined by the IASA 2.0Model. |
|
| |
| RFC 8729 | The RFC Series and RFC Editor |
| |
|
|
This document describes the framework for an RFC Series and an RFCEditor function that incorporate the principles of organized community involvement and accountability that has become necessary as the Internet technical community has grown, thereby enabling the RFCSeries to continue to fulfill its mandate. This document obsoletesRFC 4844. |
|
| |
| RFC 8730 | Independent Submission Editor Model |
| |
|
|
This document describes the function and responsibilities of the RFCIndependent Submission Editor (ISE). The Independent Submission stream is one of the stream producers that create draft RFCs, with the ISE as its stream approver. The ISE is overall responsible for activities within the Independent Submission stream, working with draft editors and reviewers, and interacts with the RFC ProductionCenter and Publisher, and the RFC Series Editor (RSE). The ISE is appointed by the IAB, and also interacts with the IETF AdministrationLimited Liability Company (LLC).
This version obsoletes RFC 6548 to replace all references to theInternet Administrative Support Activity (IASA) and related structures with those defined by the IASA 2.0 structure. |
|
| |
| RFC 8734 | Elliptic Curve Cryptography (ECC) Brainpool Curves for Transport Layer Security (TLS) Version 1.3 |
| |
| Authors: | L. Bruckert, J. Merkle, M. Lochter. |
| Date: | February 2020 |
| Formats: | txt json html pdf xml |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8734 |
|
Elliptic Curve Cryptography (ECC) Brainpool curves were an option for authentication and key exchange in the Transport Layer Security (TLS) protocol version 1.2 but were deprecated by the IETF for use with TLS version 1.3 because they had little usage. However, these curves have not been shown to have significant cryptographical weaknesses, and there is some interest in using several of these curves in TLS1.3.
This document provides the necessary protocol mechanisms for usingECC Brainpool curves in TLS 1.3. This approach is not endorsed by the IETF. |
|
| |
| RFC 8735 | Scenarios and Simulation Results of PCE in a Native IP Network |
| |
| Authors: | A. Wang, X. Huang, C. Kou, Z. Li, P. Mi. |
| Date: | February 2020 |
| Formats: | txt json pdf xml html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8735 |
|
Requirements for providing the End-to-End (E2E) performance assurance are emerging within the service provider networks. While there are various technology solutions, there is no single solution that can fulfill these requirements for a native IP network. In particular, there is a need for a universal E2E solution that can cover both intra- and inter-domain scenarios.
One feasible E2E traffic-engineering solution is the addition of central control in a native IP network. This document describes various complex scenarios and simulation results when applying thePath Computation Element (PCE) in a native IP network. This solution, referred to as Centralized Control Dynamic Routing (CCDR), integrates the advantage of using distributed protocols and the power of a centralized control technology, providing traffic engineering for native IP networks in a manner that applies equally to intra- and inter-domain scenarios. |
|
| |
| RFC 8743 | Multiple Access Management Services Multi-Access Management Services (MAMS) |
| |
| Authors: | S. Kanugovi, F. Baboescu, J. Zhu, S. Seo. |
| Date: | March 2020 |
| Formats: | txt json xml pdf html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8743 |
|
In multiconnectivity scenarios, the clients can simultaneously connect to multiple networks based on different access technologies and network architectures like Wi-Fi, LTE, and DSL. Both the quality of experience of the users and the overall network utilization and efficiency may be improved through the smart selection and combination of access and core network paths that can dynamically adapt to changing network conditions.
This document presents a unified problem statement and introduces a solution for managing multiconnectivity. The solution has been developed by the authors based on their experiences in multiple standards bodies, including the IETF and the 3GPP. However, this document is not an Internet Standards Track specification, and it does not represent the consensus opinion of the IETF.
This document describes requirements, solution principles, and the architecture of the Multi-Access Management Services (MAMS) framework. The MAMS framework aims to provide best performance while being easy to implement in a wide variety of multiconnectivity deployments. It specifies the protocol for (1) flexibly selecting the best combination of access and core network paths for the uplink and downlink, and (2) determining the user-plane treatment (e.g., tunneling, encryption) and traffic distribution over the selected links, to ensure network efficiency and the best possible application performance. |
|
| |
| RFC 8744 | Issues and Requirements for Server Name Identification (SNI) Encryption in TLS |
| |
|
|
This document describes the general problem of encrypting the ServerName Identification (SNI) TLS parameter. The proposed solutions hide a hidden service behind a fronting service, only disclosing the SNI of the fronting service to external observers. This document lists known attacks against SNI encryption, discusses the current "HTTP co- tenancy" solution, and presents requirements for future TLS-layer solutions.
In practice, it may well be that no solution can meet every requirement and that practical solutions will have to make some compromises. |
|
| |
| RFC 8751 | Hierarchical Stateful Path Computation Element (PCE) |
| |
| Authors: | D. Dhody, Y. Lee, D. Ceccarelli, J. Shin, D. King. |
| Date: | March 2020 |
| Formats: | txt html xml pdf json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8751 |
|
A stateful Path Computation Element (PCE) maintains information on the current network state received from the Path Computation Clients(PCCs), including computed Label Switched Paths (LSPs), reserved resources within the network, and pending path computation requests.This information may then be considered when computing the path for a new traffic-engineered LSP or for any associated/dependent LSPs. The path-computation response from a PCE helps the PCC to gracefully establish the computed LSP.
The Hierarchical Path Computation Element (H-PCE) architecture allows the optimum sequence of interconnected domains to be selected and network policy to be applied if applicable, via the use of a hierarchical relationship between PCEs.
Combining the capabilities of stateful PCE and the hierarchical PCE would be advantageous. This document describes general considerations and use cases for the deployment of stateful, but not stateless, PCEs using the hierarchical PCE architecture. |
|
| |
| RFC 8752 | Report from the IAB Workshop on Exploring Synergy between Content Aggregation and the Publisher Ecosystem (ESCAPE) |
| |
|
|
The Exploring Synergy between Content Aggregation and the PublisherEcosystem (ESCAPE) Workshop was convened by the Internet ArchitectureBoard (IAB) in July 2019. This report summarizes its significant points of discussion and identifies topics that may warrant further consideration.
Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions. |
|
| |
| RFC 8755 | Using Commercial National Security Algorithm Suite Algorithms in Secure/Multipurpose Internet Mail Extensions |
| |
|
|
The United States Government has published the National SecurityAgency (NSA) Commercial National Security Algorithm (CNSA) Suite, which defines cryptographic algorithm policy for national security applications. This document specifies the conventions for using theUnited States National Security Agency's CNSA Suite algorithms inSecure/Multipurpose Internet Mail Extensions (S/MIME) as specified inRFC 8551. It applies to the capabilities, configuration, and operation of all components of US National Security Systems that employ S/MIME messaging. US National Security Systems are described in NIST Special Publication 800-59. It is also appropriate for all other US Government systems that process high-value information. It is made publicly available for use by developers and operators of these and any other system deployments. |
|
| |
| RFC 8756 | Commercial National Security Algorithm (CNSA) Suite Profile of Certificate Management over CMS |
| |
|
|
This document specifies a profile of the Certificate Management overCMS (CMC) protocol for managing X.509 public key certificates in applications that use the Commercial National Security Algorithm(CNSA) Suite published by the United States Government.
The profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that manage X.509 public key certificates over CMS. It is also appropriate for all other US Government systems that process high-value information.
The profile is made publicly available here for use by developers and operators of these and any other system deployments. |
|
| |
| RFC 8761 | Video Codec Requirements and Evaluation Methodology |
| |
| Authors: | A. Filippov, A. Norkin, J.R. Alvarez. |
| Date: | April 2020 |
| Formats: | txt pdf xml html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8761 |
|
This document provides requirements for a video codec designed mainly for use over the Internet. In addition, this document describes an evaluation methodology for measuring the compression efficiency to determine whether or not the stated requirements have been fulfilled. |
|
| |
| RFC 8763 | Deployment Considerations for Information-Centric Networking (ICN) |
| |
| Authors: | A. Rahman, D. Trossen, D. Kutscher, R. Ravindran. |
| Date: | April 2020 |
| Formats: | txt json xml html pdf |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8763 |
|
Information-Centric Networking (ICN) is now reaching technological maturity after many years of fundamental research and experimentation. This document provides a number of deployment considerations in the interest of helping the ICN community move forward to the next step of live deployments. First, the major deployment configurations for ICN are described, including the key overlay and underlay approaches. Then, proposed deployment migration paths are outlined to address major practical issues, such as network and application migration. Next, selected ICN trial experiences are summarized. Finally, protocol areas that require further standardization are identified to facilitate future interoperable ICN deployments. This document is a product of the Information-CentricNetworking Research Group (ICNRG). |
|
| |
| RFC 8764 | Apple's DNS Long-Lived Queries Protocol |
| |
|
|
Apple's DNS Long-Lived Queries (LLQ) is a mechanism for extending theDNS protocol to support change notification, thus allowing clients to learn about changes to DNS data without polling the server. From2005 onwards, LLQ was implemented in Apple products including Mac OSX, Bonjour for Windows, and AirPort wireless base stations. In 2020, the LLQ protocol was superseded by the IETF Standards Track RFC 8765,"DNS Push Notifications", which builds on experience gained with theLLQ protocol to create a superior replacement.
The existing LLQ protocol deployed and used from 2005 to 2020 is documented here to give background regarding the operational experience that informed the development of DNS Push Notifications, and to help facilitate a smooth transition from LLQ to DNS PushNotifications. |
|
| |
| RFC 8769 | Cryptographic Message Syntax (CMS) Content Types for Concise Binary Object Representation (CBOR) |
| |
|
|
Concise Binary Object Representation (CBOR) is becoming a widely used method of doing content encoding. The Cryptographic Message Syntax(CMS) is still a widely used method of doing message-based security.This document defines a set of content types for CMS that hold CBOR content. |
|
| |
| RFC 8772 | The China Mobile, Huawei, and ZTE Broadband Network Gateway (BNG) Simple Control and User Plane Separation Protocol (S-CUSP) |
| |
| Authors: | S. Hu, D. Eastlake, F. Qin, T. Chua, D. Huang. |
| Date: | May 2020 |
| Formats: | txt json pdf xml html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8772 |
|
A Broadband Network Gateway (BNG) in a fixed wireline access network is an Ethernet-centric IP edge router and the aggregation point for subscriber traffic. Control and User Plane Separation (CUPS) for such a BNG improves flexibility and scalability but requires various communication between the User Plane (UP) and the Control Plane (CP).China Mobile, Huawei Technologies, and ZTE have developed a simpleCUPS control channel protocol to support such communication: theSimple Control and User Plane Separation Protocol (S-CUSP). S-CUSP is defined in this document.
This document is not an IETF standard and does not have IETF consensus. S-CUSP is presented here to make its specification conveniently available to the Internet community to enable diagnosis and interoperability. |
|
| |
| RFC 8774 | 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 someInternet paths, a capability which was not predicted and so not included as a possibility in many protocol specifications. Worse than the millennium bug, this unexpected value is bound to cause serious Internet failures unless the specifications are fixed in time. |
|
| |
| RFC 8785 | JSON Canonicalization Scheme (JCS) |
| |
| Authors: | A. Rundgren, B. Jordan, S. Erdtman. |
| Date: | June 2020 |
| Formats: | txt pdf xml html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8785 |
|
Cryptographic operations like hashing and signing need the data to be expressed in an invariant format so that the operations are reliably repeatable. One way to address this is to create a canonical representation of the data. Canonicalization also permits data to be exchanged in its original form on the "wire" while cryptographic operations performed on the canonicalized counterpart of the data in the producer and consumer endpoints generate consistent results.
This document describes the JSON Canonicalization Scheme (JCS). This specification defines how to create a canonical representation ofJSON data by building on the strict serialization methods for JSON primitives defined by ECMAScript, constraining JSON data to theInternet JSON (I-JSON) subset, and by using deterministic property sorting. |
|
| |
| RFC 8792 | Handling Long Lines in Content of Internet-Drafts and RFCs |
| |
| Authors: | K. Watsen, E. Auerswald, A. Farrel, Q. Wu. |
| Date: | June 2020 |
| Formats: | txt xml pdf json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8792 |
|
This document defines two strategies for handling long lines in width-bounded text content. One strategy, called the "single backslash" strategy, is based on the historical use of a single backslash ('\') character to indicate where line-folding has occurred, with the continuation occurring with the first character that is not a space character (' ') on the next line. The second strategy, called the "double backslash" strategy, extends the first strategy by adding a second backslash character to identify where the continuation begins and is thereby able to handle cases not supported by the first strategy. Both strategies use a self-describing header enabling automated reconstitution of the original content. |
|
| |
| RFC 8793 | Information-Centric Networking (ICN): Content-Centric Networking (CCNx) and Named Data Networking (NDN) Terminology |
| |
| Authors: | B. Wissingh, C. Wood, A. Afanasyev, L. Zhang, D. Oran, C. Tschudin. |
| Date: | June 2020 |
| Formats: | txt json xml pdf html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8793 |
|
Information-Centric Networking (ICN) is a novel paradigm where network communications are accomplished by requesting named content instead of sending packets to destination addresses. Named DataNetworking (NDN) and Content-Centric Networking (CCNx) are two prominent ICN architectures. This document provides an overview of the terminology and definitions that have been used in describing concepts in these two implementations of ICN. While there are otherICN architectures, they are not part of the NDN and CCNx concepts and as such are out of scope for this document. This document is a product of the Information-Centric Networking Research Group (ICNRG). |
|
| |
| RFC 8799 | 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. |
|
| |
| RFC 8802 | The Quality for Service (Q4S) Protocol |
| |
| Authors: | J.J. Aranda, M. Cortes, J. Salvachúa, M. Narganes, I. Martínez-Sarriegui. |
| Date: | July 2020 |
| Formats: | txt html pdf xml json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8802 |
|
This memo describes an application-level protocol for the communication of end-to-end QoS compliance information based on theHyperText Transfer Protocol (HTTP) and the Session DescriptionProtocol (SDP). The Quality for Service (Q4S) protocol provides a mechanism to negotiate and monitor latency, jitter, bandwidth, and packet loss, and to alert whenever one of the negotiated conditions is violated.
Implementation details on the actions to be triggered upon reception/ detection of QoS alerts exchanged by the protocol are out of scope of this document; it is either application dependent (e.g., act to increase quality or reduce bit-rate) or network dependent (e.g., change connection's quality profile).
This protocol specification is the product of research conducted over a number of years; it is presented here as a permanent record and to offer a foundation for future similar work. It does not represent a standard protocol and does not have IETF consensus. |
|
| |
| RFC 8805 | A Format for Self-Published IP Geolocation Feeds |
| |
| Authors: | E. Kline, K. Duleba, Z. Szamonek, S. Moser, W. Kumari. |
| Date: | August 2020 |
| Formats: | txt json pdf xml html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8805 |
|
This document records a format whereby a network operator can publish a mapping of IP address prefixes to simplified geolocation information, colloquially termed a "geolocation feed". Interested parties can poll and parse these feeds to update or merge with other geolocation data sources and procedures. This format intentionally only allows specifying coarse-level location.
Some technical organizations operating networks that move from one conference location to the next have already experimentally published small geolocation feeds.
This document describes a currently deployed format. At least one consumer (Google) has incorporated these feeds into a geolocation data pipeline, and a significant number of ISPs are using it to inform them where their prefixes should be geolocated. |
|
| |
| RFC 8806 | Running a Root Server Local to a Resolver |
| |
|
|
Some DNS recursive resolvers have longer-than-desired round-trip times to the closest DNS root server; those resolvers may have difficulty getting responses from the root servers, such as during a network attack. Some DNS recursive resolver operators want to prevent snooping by third parties of requests sent to DNS root servers. In both cases, resolvers can greatly decrease the round- trip time and prevent observation of requests by serving a copy of the full root zone on the same server, such as on a loopback address or in the resolver software. This document shows how to start and maintain such a copy of the root zone that does not cause problems for other users of the DNS, at the cost of adding some operational fragility for the operator.
This document obsoletes RFC 7706. |
|
| |
| RFC 8809 | Registries for Web Authentication (WebAuthn) |
| |
| Authors: | J. Hodges, G. Mandyam, M. Jones. |
| Date: | August 2020 |
| Formats: | txt json html xml pdf |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8809 |
|
This specification defines IANA registries for W3C Web Authentication(WebAuthn) attestation statement format identifiers and extension identifiers. |
|
| |
| RFC 8811 | DDoS Open Threat Signaling (DOTS) Architecture |
| |
| Authors: | A. Mortensen, Ed., T. Reddy.K, Ed., F. Andreasen, N. Teague, R. Compton. |
| Date: | August 2020 |
| Formats: | txt json html pdf xml |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8811 |
|
This document describes an architecture for establishing and maintaining Distributed Denial-of-Service (DDoS) Open ThreatSignaling (DOTS) within and between domains. The document does not specify protocols or protocol extensions, instead focusing on defining architectural relationships, components, and concepts used in a DOTS deployment. |
|
| |
| RFC 8816 | Secure Telephone Identity Revisited (STIR) Out-of-Band Architecture and Use Cases |
| |
| Authors: | E. Rescorla, J. Peterson. |
| Date: | February 2021 |
| Formats: | txt html json pdf xml |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8816 |
|
The Personal Assertion Token (PASSporT) format defines a token that can be carried by signaling protocols, including SIP, to cryptographically attest the identity of callers. However, not all telephone calls use Internet signaling protocols, and some calls use them for only part of their signaling path, while some cannot reliably deliver SIP header fields end-to-end. This document describes use cases that require the delivery of PASSporT objects outside of the signaling path, and defines architectures and semantics to provide this functionality. |
|
| |
| RFC 8818 | Distributed Mobility Anchoring |
| |
| Authors: | H. Chan, Ed., X. Wei, J. Lee, S. Jeon, CJ. Bernardos, Ed.. |
| Date: | October 2020 |
| Formats: | txt json pdf html xml |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8818 |
|
This document defines distributed mobility anchoring in terms of the different configurations and functions to provide IP mobility support. A network may be configured with distributed mobility anchoring functions for both network-based or host-based mobility support, depending on the network's needs. In a distributed mobility anchoring environment, multiple anchors are available for mid-session switching of an IP prefix anchor. To start a new flow or to handle a flow not requiring IP session continuity as a mobile node moves to a new network, the flow can be started or restarted using an IP address configured from the new IP prefix anchored to the new network. If the flow needs to survive the change of network, there are solutions that can be used to enable IP address mobility. This document describes different anchoring approaches, depending on the IP mobility needs, and how this IP address mobility is handled by the network. |
|
| |
| RFC 8821 | PCE-Based Traffic Engineering (TE) in Native IP Networks |
| |
| Authors: | A. Wang, B. Khasanov, Q. Zhao, H. Chen. |
| Date: | April 2021 |
| Formats: | txt json xml pdf html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8821 |
|
This document defines an architecture for providing traffic engineering in a native IP network using multiple BGP sessions and aPath Computation Element (PCE)-based central control mechanism. It defines the Centralized Control Dynamic Routing (CCDR) procedures and identifies needed extensions for the Path Computation ElementCommunication Protocol (PCEP). |
|
| |
| RFC 8822 | 5G Wireless Wireline Convergence User Plane Encapsulation (5WE) |
| |
| Authors: | D. Allan, Ed., D. Eastlake, D. Woolley. |
| Date: | April 2021 |
| Formats: | txt html pdf xml json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8822 |
|
As part of providing wireline access to the 5G Core (5GC), deployed wireline networks carry user data between 5G residential gateways and the 5G Access Gateway Function (AGF). The encapsulation method specified in this document supports the multiplexing of traffic for multiple PDU sessions within a VLAN-delineated access circuit, permits legacy equipment in the data path to inspect certain packet fields, carries 5G QoS information associated with the packet data, and provides efficient encoding. It achieves this by specific points of similarity with the Point-to-Point Protocol over Ethernet (PPPoE) data packet encapsulation (RFC 2516). |
|
| |
| RFC 8823 | Extensions to Automatic Certificate Management Environment for End-User S/MIME Certificates |
| |
|
|
This document specifies identifiers and challenges required to enable the Automated Certificate Management Environment (ACME) to issue certificates for use by email users that want to use S/MIME. |
|
| |
| RFC 8836 | Congestion Control Requirements for Interactive Real-Time Media |
| |
|
|
Congestion control is needed for all data transported across theInternet, in order to promote fair usage and prevent congestion collapse. The requirements for interactive, point-to-point real-time multimedia, which needs low-delay, semi-reliable data delivery, are different from the requirements for bulk transfer like FTP or bursty transfers like web pages. Due to an increasing amount of RTP-based real-time media traffic on the Internet (e.g., with the introduction of the Web Real-Time Communication (WebRTC)), it is especially important to ensure that this kind of traffic is congestion controlled.
This document describes a set of requirements that can be used to evaluate other congestion control mechanisms in order to figure out their fitness for this purpose, and in particular to provide a set of possible requirements for a real-time media congestion avoidance technique. |
|
| |
| RFC 8867 | Test Cases for Evaluating Congestion Control for Interactive Real-Time Media |
| |
| Authors: | Z. Sarker, V. Singh, X. Zhu, M. Ramalho. |
| Date: | January 2021 |
| Formats: | txt xml pdf json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8867 |
|
The Real-time Transport Protocol (RTP) is used to transmit media in multimedia telephony applications. These applications are typically required to implement congestion control. This document describes the test cases to be used in the performance evaluation of such congestion control algorithms in a controlled environment. |
|
| |
| RFC 8868 | Evaluating Congestion Control for Interactive Real-Time Media |
| |
| Authors: | V. Singh, J. Ott, S. Holmer. |
| Date: | January 2021 |
| Formats: | txt html xml pdf json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8868 |
|
The Real-Time Transport Protocol (RTP) is used to transmit media in telephony and video conferencing applications. This document describes the guidelines to evaluate new congestion control algorithms for interactive point-to-point real-time media. |
|
| |
| RFC 8869 | Evaluation Test Cases for Interactive Real-Time Media over Wireless Networks |
| |
|
|
The Real-time Transport Protocol (RTP) is a common transport choice for interactive multimedia communication applications. The performance of these applications typically depends on a well- functioning congestion control algorithm. To ensure a seamless and robust user experience, a well-designed RTP-based congestion control algorithm should work well across all access network types. This document describes test cases for evaluating performances of candidate congestion control algorithms over cellular and Wi-Fi networks. |
|
| |
| RFC 8872 | Guidelines for Using the Multiplexing Features of RTP to Support Multiple Media Streams |
| |
| Authors: | M. Westerlund, B. Burman, C. Perkins, H. Alvestrand, R. Even. |
| Date: | January 2021 |
| Formats: | txt json html xml pdf |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8872 |
|
The Real-time Transport Protocol (RTP) is a flexible protocol that can be used in a wide range of applications, networks, and system topologies. That flexibility makes for wide applicability but can complicate the application design process. One particular design question that has received much attention is how to support multiple media streams in RTP. This memo discusses the available options and design trade-offs, and provides guidelines on how to use the multiplexing features of RTP to support multiple media streams. |
|
| |
| RFC 8874 | Working Group GitHub Usage Guidance |
| |
|
|
This document provides a set of guidelines for working groups that choose to use GitHub for their work. |
|
| |
| RFC 8875 | Working Group GitHub Administration |
| |
|
|
The use of GitHub in IETF working group processes is increasing.This document describes uses and conventions for working groups that are considering starting to use GitHub. It does not mandate any processes and does not require changes to the processes used by current and future working groups not using GitHub. |
|
| |
| RFC 8877 | Guidelines for Defining Packet Timestamps |
| |
| Authors: | T. Mizrahi, J. Fabini, A. Morton. |
| Date: | September 2020 |
| Formats: | txt pdf xml json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8877 |
|
Various network protocols make use of binary-encoded timestamps that are incorporated in the protocol packet format, referred to as"packet timestamps" for short. This document specifies guidelines for defining packet timestamp formats in networking protocols at various layers. It also presents three recommended timestamp formats. The target audience of this document includes network protocol designers. It is expected that a new network protocol that requires a packet timestamp will, in most cases, use one of the recommended timestamp formats. If none of the recommended formats fits the protocol requirements, the new protocol specification should specify the format of the packet timestamp according to the guidelines in this document. |
|
| |
| RFC 8878 | Zstandard Compression and the 'application/zstd' Media Type |
| |
|
|
Zstandard, or "zstd" (pronounced "zee standard"), is a lossless data compression mechanism. This document describes the mechanism and registers a media type, content encoding, and a structured syntax suffix to be used when transporting zstd-compressed content via MIME.
Despite use of the word "standard" as part of Zstandard, readers are advised that this document is not an Internet Standards Track specification; it is being published for informational purposes only.
This document replaces and obsoletes RFC 8478. |
|
| |
| RFC 8882 | DNS-Based Service Discovery (DNS-SD) Privacy and Security Requirements |
| |
|
|
DNS-SD (DNS-based Service Discovery) normally discloses information about devices offering and requesting services. This information includes hostnames, network parameters, and possibly a further description of the corresponding service instance. Especially when mobile devices engage in DNS-based Service Discovery at a public hotspot, serious privacy problems arise. We analyze the requirements of a privacy-respecting discovery service. |
|
| |
| RFC 8884 | Research Directions for Using Information-Centric Networking (ICN) in Disaster Scenarios |
| |
| Authors: | J. Seedorf, M. Arumaithurai, A. Tagami, K. Ramakrishnan, N. Blefari-Melazzi. |
| Date: | October 2020 |
| Formats: | txt xml pdf html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8884 |
|
Information-Centric Networking (ICN) is a new paradigm where the network provides users with named content instead of communication channels between hosts. This document outlines some research directions for ICN with respect to applying ICN approaches for coping with natural or human-generated, large-scale disasters. This document is a product of the Information-Centric Networking ResearchGroup (ICNRG). |
|
| |
| RFC 8886 | Secure Device Install |
| |
|
|
Deploying a new network device in a location where the operator has no staff of its own often requires that an employee physically travel to the location to perform the initial install and configuration, even in shared facilities with "remote-hands" (or similar) support.In many cases, this could be avoided if there were an easy way to transfer the initial configuration to a new device while still maintaining confidentiality of the configuration.
This document extends existing vendor proprietary auto-install to provide limited confidentiality to initial configuration during bootstrapping of the device. |
|
| |
| RFC 8890 | 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. |
|
| |
| RFC 8891 | 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), RussianFederal standard GOST R 34.12-2015 includes an updated version of the block cipher with a block length of n=64 bits and key length of k=256 bits, which is also referred to as "Magma". The algorithm is an updated version of an older block cipher with a block length of n=64 bits described in GOST 28147-89 (RFC 5830). This document is intended to be a source of information about the updated version of the 64-bit cipher. It may facilitate the use of the block cipher inInternet applications by providing information for developers and users of the GOST 64-bit cipher with the revised version of the cipher for encryption and decryption. |
|
| |
| RFC 8894 | Simple Certificate Enrolment Protocol |
| |
|
|
This document specifies the Simple Certificate Enrolment Protocol(SCEP), a PKI protocol that leverages existing technology by usingCryptographic Message Syntax (CMS, formerly known as PKCS #7) andPKCS #10 over HTTP. SCEP is the evolution of the enrolment protocol sponsored by Cisco Systems, which enjoys wide support in both client and server implementations, as well as being relied upon by numerous other industry standards that work with certificates. |
|
| |
| RFC 8897 | Requirements for Resource Public Key Infrastructure (RPKI) Relying Parties |
| |
|
|
This document provides a single reference point for requirements forRelying Party (RP) software for use in the Resource Public KeyInfrastructure (RPKI). It cites requirements that appear in severalRPKI RFCs, making it easier for implementers to become aware of these requirements. Over time, this RFC will be updated to reflect changes to the requirements and guidance specified in the RFCs discussed herein. |
|
| |
| RFC 8901 | Multi-Signer DNSSEC Models |
| |
| Authors: | S. Huque, P. Aras, J. Dickinson, J. Vcelak, D. Blacka. |
| Date: | September 2020 |
| Formats: | txt html pdf json xml |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8901 |
|
Many enterprises today employ the service of multiple DNS providers to distribute their authoritative DNS service. Deploying DNSSEC in such an environment may present some challenges, depending on the configuration and feature set in use. In particular, when each DNS provider independently signs zone data with their own keys, additional key-management mechanisms are necessary. This document presents deployment models that accommodate this scenario and describes these key-management requirements. These models do not require any changes to the behavior of validating resolvers, nor do they impose the new key-management requirements on authoritative servers not involved in multi-signer configurations. |
|
| |
| RFC 8903 | Use Cases for DDoS Open Threat Signaling |
| |
| Authors: | R. Dobbins, D. Migault, R. Moskowitz, N. Teague, L. Xia, K. Nishizuka. |
| Date: | May 2021 |
| Formats: | txt xml pdf json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8903 |
|
The DDoS Open Threat Signaling (DOTS) effort is intended to provide protocols to facilitate interoperability across disparate DDoSMitigation solutions. This document presents sample use cases that describe the interactions expected between the DOTS components as well as DOTS messaging exchanges. These use cases are meant to identify the interacting DOTS components, how they collaborate, and what the typical information to be exchanged is. |
|
| |
| RFC 8904 | DNS Whitelist (DNSWL) Email Authentication Method Extension |
| |
|
|
This document describes an email authentication method compliant withRFC 8601. The method consists of looking up the sender's IP address in a DNS whitelist. This document provides information in case the method is seen in the field, suggests a useful practice, and registers the relevant keywords.
This document does not consider blacklists. |
|
| |
| RFC 8905 | The 'payto' URI Scheme for Payments |
| |
|
|
This document defines the 'payto' Uniform Resource Identifier (URI) scheme for designating targets for payments.
A unified URI scheme for all payment target types allows applications to offer user interactions with URIs that represent payment targets, simplifying the introduction of new payment systems and applications. |
|
| |
| RFC 8907 | The Terminal Access Controller Access-Control System Plus (TACACS+) Protocol |
| |
| Authors: | T. Dahm, A. Ota, D.C. Medway Gash, D. Carrel, L. Grant. |
| Date: | September 2020 |
| Formats: | txt json html pdf xml |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8907 |
|
This document describes the Terminal Access Controller Access-ControlSystem Plus (TACACS+) protocol, which is widely deployed today to provide Device Administration for routers, network access servers, and other networked computing devices via one or more centralized servers. |
|
| |
| RFC 8921 | Dynamic Service Negotiation: The Connectivity Provisioning Negotiation Protocol (CPNP) |
| |
| Authors: | M. Boucadair, Ed., C. Jacquenet, D. Zhang, P. Georgatsos. |
| Date: | October 2020 |
| Formats: | txt html pdf xml json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8921 |
|
This document defines the Connectivity Provisioning NegotiationProtocol (CPNP), which is designed to facilitate the dynamic negotiation of service parameters.
CPNP is a generic protocol that can be used for various negotiation purposes that include (but are not necessarily limited to) connectivity provisioning services, storage facilities, ContentDelivery Networks, etc. |
|
| |
| RFC 8922 | A Survey of the Interaction between Security Protocols and Transport Services |
| |
| Authors: | T. Enghardt, T. Pauly, C. Perkins, K. Rose, C. Wood. |
| Date: | October 2020 |
| Formats: | txt json xml pdf html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8922 |
|
This document provides a survey of commonly used or notable network security protocols, with a focus on how they interact and integrate with applications and transport protocols. Its goal is to supplement efforts to define and catalog Transport Services by describing the interfaces required to add security protocols. This survey is not limited to protocols developed within the scope or context of theIETF, and those included represent a superset of features a TransportServices system may need to support. |
|
| |
| RFC 8923 | A Minimal Set of Transport Services for End Systems |
| |
|
|
This document recommends a minimal set of Transport Services offered by end systems and gives guidance on choosing among the available mechanisms and protocols. It is based on the set of transport features in RFC 8303. |
|
| |
| RFC 8924 | Service Function Chaining (SFC) Operations, Administration, and Maintenance (OAM) Framework |
| |
| Authors: | S. Aldrin, C. Pignataro, Ed., N. Kumar, Ed., R. Krishnan, A. Ghanwani. |
| Date: | October 2020 |
| Formats: | txt html json xml pdf |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8924 |
|
This document provides a reference framework for Operations,Administration, and Maintenance (OAM) for Service Function Chaining(SFC). |
|
| |
| RFC 8937 | Randomness Improvements for Security Protocols |
| |
| Authors: | C. Cremers, L. Garratt, S. Smyshlyaev, N. Sullivan, C. Wood. |
| Date: | October 2020 |
| Formats: | txt json xml pdf html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8937 |
|
Randomness is a crucial ingredient for Transport Layer Security (TLS) and related security protocols. Weak or predictable"cryptographically secure" pseudorandom number generators (CSPRNGs) can be abused or exploited for malicious purposes. An initial entropy source that seeds a CSPRNG might be weak or broken as well, which can also lead to critical and systemic security problems. This document describes a way for security protocol implementations to augment their CSPRNGs using long-term private keys. This improves randomness from broken or otherwise subverted CSPRNGs.
This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. |
|
| |
| RFC 8938 | Deterministic Networking (DetNet) Data Plane Framework |
| |
| Authors: | B. Varga, Ed., J. Farkas, L. Berger, A. Malis, S. Bryant. |
| Date: | November 2020 |
| Formats: | txt xml pdf html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8938 |
|
This document provides an overall framework for the DeterministicNetworking (DetNet) data plane. It covers concepts and considerations that are generally common to any DetNet data plane specification. It describes related Controller Plane considerations as well. |
|
| |
| RFC 8952 | Captive Portal Architecture |
| |
| Authors: | K. Larose, D. Dolson, H. Liu. |
| Date: | November 2020 |
| Formats: | txt pdf xml html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8952 |
|
This document describes a captive portal architecture. Network provisioning protocols such as DHCP or Router Advertisements (RAs), an optional signaling protocol, and an HTTP API are used to provide the solution. |
|
| |
| RFC 8953 | Coordinating Attack Response at Internet Scale 2 (CARIS2) Workshop Report |
| |
|
|
The Coordinating Attack Response at Internet Scale (CARIS) 2 workshop, sponsored by the Internet Society, took place on 28February and 1 March 2019 in Cambridge, Massachusetts, USA.Participants spanned regional, national, international, and enterprise Computer Security Incident Response Teams (CSIRTs), operators, service providers, network and security operators, transport operators and researchers, incident response researchers, vendors, and participants from standards communities. This workshop continued the work started at the first CARIS workshop, with a focus on scaling incident prevention and detection as the Internet industry moves to a stronger and a more ubiquitous deployment of session encryption. |
|
| |
| RFC 8959 | The "secret-token" URI Scheme |
| |
|
|
This document registers the "secret-token" URI scheme to aid in the identification of authentication tokens. |
|
| |
| RFC 8962 | Establishing the Protocol Police |
| |
| Authors: | G. Grover, N. ten Oever, C. Cath, S. Sahib. |
| Date: | 1 April 2021 |
| Formats: | txt html xml pdf json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8962 |
|
One mantra of the IETF is, "We are not the Protocol Police."However, to ensure that protocols are implemented and deployed in full compliance with the IETF's standards, it is important to set up a body that is responsible for assessing and enforcing correct protocol behavior.
This document formally establishes the Protocol Police. It defines the body and sets out what aspects of IETF protocols they will police. This document acts as a point of reference for networking engineers, law enforcement officials, government representatives, and others. It also provides advice on how to report issues to theProtocol Police. |
|
| |
| RFC 8963 | Evaluation of a Sample of RFCs Produced in 2018 |
| |
|
|
This document presents the author's effort to understand the delays involved in publishing an idea in the IETF or through the IndependentStream, from the first individual draft to the publication of theRFC. We analyze a set of randomly chosen RFCs approved in 2018, looking for history and delays. We also use two randomly chosen sets of RFCs published in 2008 and 1998 for comparing delays seen in 2018 to those observed 10 or 20 years ago. The average RFC in the 2018 sample was produced in 3 years and 4 months, of which 2 years and 10 months were spent in the working group, 3 to 4 months for IETF consensus and IESG review, and 3 to 4 months in RFC production. The main variation in RFC production delays comes from the AUTH48 phase.
We also measure the number of citations of the chosen RFC usingSemantic Scholar, and compare citation counts with what we know about deployment. We show that citation counts indicate academic interest, but correlate only loosely with deployment or usage of the specifications. Counting web references could complement that. |
|
| |
| RFC 8965 | Applicability of the Babel Routing Protocol |
| |
|
|
Babel is a routing protocol based on the distance-vector algorithm augmented with mechanisms for loop avoidance and starvation avoidance. This document describes a number of niches where Babel has been found to be useful and that are arguably not adequately served by more mature protocols. |
|
| |
| RFC 8969 | A Framework for Automating Service and Network Management with YANG |
| |
| Authors: | Q. Wu, Ed., M. Boucadair, Ed., D. Lopez, C. Xie, L. Geng. |
| Date: | January 2021 |
| Formats: | txt pdf xml json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8969 |
|
Data models provide a programmatic approach to represent services and networks. Concretely, they can be used to derive configuration information for network and service components, and state information that will be monitored and tracked. Data models can be used during the service and network management life cycle (e.g., service instantiation, service provisioning, service optimization, service monitoring, service diagnosing, and service assurance). Data models are also instrumental in the automation of network management, and they can provide closed-loop control for adaptive and deterministic service creation, delivery, and maintenance.
This document describes a framework for service and network management automation that takes advantage of YANG modeling technologies. This framework is drawn from a network operator perspective irrespective of the origin of a data model; thus, it can accommodate YANG modules that are developed outside the IETF. |
|
| |
| RFC 8971 | Bidirectional Forwarding Detection (BFD) for Virtual eXtensible Local Area Network (VXLAN) |
| |
| Authors: | S. Pallagatti, Ed., G. Mirsky, Ed., S. Paragiri, V. Govindan, M. Mudigonda. |
| Date: | December 2020 |
| Formats: | txt xml pdf json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8971 |
|
This document describes the use of the Bidirectional ForwardingDetection (BFD) protocol in point-to-point Virtual eXtensible LocalArea Network (VXLAN) tunnels used to form an overlay network. |
|
| |
| RFC 8975 | Network Coding for Satellite Systems |
| |
| Authors: | N. Kuhn, Ed., E. Lochin, Ed.. |
| Date: | January 2021 |
| Formats: | txt json html pdf xml |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8975 |
|
This document is a product of the Coding for Efficient NetworkCommunications Research Group (NWCRG). It conforms to the directions found in the NWCRG taxonomy (RFC 8406).
The objective is to contribute to a larger deployment of NetworkCoding techniques in and above the network layer in satellite communication systems. This document also identifies open research issues related to the deployment of Network Coding in satellite communication systems. |
|
| |
| RFC 8978 | Reaction of IPv6 Stateless Address Autoconfiguration (SLAAC) to Flash-Renumbering Events |
| |
| Authors: | F. Gont, J. Žorž, R. Patterson. |
| Date: | March 2021 |
| Formats: | txt xml json pdf html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8978 |
|
In scenarios where network configuration information related to IPv6 prefixes becomes invalid without any explicit and reliable signaling of that condition (such as when a Customer Edge router crashes and reboots without knowledge of the previously employed prefixes), hosts on the local network may continue using stale prefixes for an unacceptably long time (on the order of several days), thus resulting in connectivity problems. This document describes this issue and discusses operational workarounds that may help to improve network robustness. Additionally, it highlights areas where further work may be needed. |
|
| |
| RFC 8980 | Report from the IAB Workshop on Design Expectations vs |
| |
| Authors: | Deployment Reality in Protocol Development. J. Arkko, T. Hardie. |
| Date: | February 2021 |
| Formats: | txt json html xml pdf |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8980 |
|
The Design Expectations vs. Deployment Reality in ProtocolDevelopment Workshop was convened by the Internet Architecture Board(IAB) in June 2019. This report summarizes the workshop's significant points of discussion and identifies topics that may warrant further consideration.
Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions. |
|
| |
| RFC 8991 | GeneRic Autonomic Signaling Protocol Application Program Interface (GRASP API) |
| |
| Authors: | B. Carpenter, B. Liu, Ed., W. Wang, X. Gong. |
| Date: | May 2021 |
| Formats: | txt json pdf xml html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8991 |
|
This document is a conceptual outline of an Application ProgrammingInterface (API) for the GeneRic Autonomic Signaling Protocol (GRASP).Such an API is needed for Autonomic Service Agents (ASAs) calling theGRASP protocol module to exchange Autonomic Network messages with other ASAs. Since GRASP is designed to support asynchronous operations, the API will need to be adapted according to the support for asynchronicity in various programming languages and operating systems. |
|
| |
| RFC 8992 | Autonomic IPv6 Edge Prefix Management in Large-Scale Networks |
| |
| Authors: | S. Jiang, Ed., Z. Du, B. Carpenter, Q. Sun. |
| Date: | May 2021 |
| Formats: | txt xml pdf html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8992 |
|
This document defines two autonomic technical objectives for IPv6 prefix management at the edge of large-scale ISP networks, with an extension to support IPv4 prefixes. An important purpose of this document is to use it for validation of the design of various components of the Autonomic Networking Infrastructure. |
|
| |
| RFC 8993 | A Reference Model for Autonomic Networking |
| |
| Authors: | M. Behringer, Ed., B. Carpenter, T. Eckert, L. Ciavaglia, J. Nobre. |
| Date: | May 2021 |
| Formats: | txt html xml pdf json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 8993 |
|
This document describes a reference model for Autonomic Networking for managed networks. It defines the behavior of an autonomic node, how the various elements in an autonomic context work together, and how autonomic services can use the infrastructure. |
|
| |
| RFC 8998 | 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. |
|
| |
| RFC 9004 | Updates for the Back-to-Back Frame Benchmark in RFC 2544 |
| |
|
|
Fundamental benchmarking methodologies for network interconnect devices of interest to the IETF are defined in RFC 2544. This memo updates the procedures of the test to measure the Back-to-Back Frames benchmark of RFC 2544, based on further experience.
This memo updates Section 26.4 of RFC 2544. |
|
| |
| RFC 9006 | TCP Usage Guidance in the Internet of Things (IoT) |
| |
| Authors: | C. Gomez, J. Crowcroft, M. Scharf. |
| Date: | March 2021 |
| Formats: | txt json html xml pdf |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9006 |
|
This document provides guidance on how to implement and use theTransmission Control Protocol (TCP) in Constrained-Node Networks(CNNs), which are a characteristic of the Internet of Things (IoT).Such environments require a lightweight TCP implementation and may not make use of optional functionality. This document explains a number of known and deployed techniques to simplify a TCP stack as well as corresponding trade-offs. The objective is to help embedded developers with decisions on which TCP features to use. |
|
| |
| RFC 9016 | Flow and Service Information Model for Deterministic Networking (DetNet) |
| |
| Authors: | B. Varga, J. Farkas, R. Cummings, Y. Jiang, D. Fedyk. |
| Date: | March 2021 |
| Formats: | txt json pdf xml html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9016 |
|
This document describes the flow and service information model forDeterministic Networking (DetNet). These models are defined for IP and MPLS DetNet data planes. |
|
| |
| RFC 9019 | A Firmware Update Architecture for Internet of Things |
| |
| Authors: | B. Moran, H. Tschofenig, D. Brown, M. Meriac. |
| Date: | April 2021 |
| Formats: | txt html json pdf xml |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9019 |
|
Vulnerabilities in Internet of Things (IoT) devices have raised the need for a reliable and secure firmware update mechanism suitable for devices with resource constraints. Incorporating such an update mechanism is a fundamental requirement for fixing vulnerabilities, but it also enables other important capabilities such as updating configuration settings and adding new functionality.
In addition to the definition of terminology and an architecture, this document provides the motivation for the standardization of a manifest format as a transport-agnostic means for describing and protecting firmware updates. |
|
| |
| RFC 9021 | Use of the Walnut Digital Signature Algorithm with CBOR Object Signing and Encryption (COSE) |
| |
|
|
This document specifies the conventions for using the Walnut DigitalSignature Algorithm (WalnutDSA) for digital signatures with the CBORObject Signing and Encryption (COSE) syntax. WalnutDSA is a lightweight, quantum-resistant signature scheme based on GroupTheoretic Cryptography with implementation and computational efficiency of signature verification in constrained environments, even on 8- and 16-bit platforms.
The goal of this publication is to document a way to use the lightweight, quantum-resistant WalnutDSA signature algorithm in COSE in a way that would allow multiple developers to build compatible implementations. As of this publication, the security properties ofWalnutDSA have not been evaluated by the IETF and its use has not been endorsed by the IETF.
WalnutDSA and the Walnut Digital Signature Algorithm are trademarks of Veridify Security Inc. |
|
| |
| RFC 9023 | Deterministic Networking (DetNet) Data Plane: IP over IEEE 802.1 Time-Sensitive Networking (TSN) |
| |
| Authors: | B. Varga, Ed., J. Farkas, A. Malis, S. Bryant. |
| Date: | June 2021 |
| Formats: | txt json pdf xml html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9023 |
|
This document specifies the Deterministic Networking IP data plane when operating over a Time-Sensitive Networking (TSN) sub-network.This document does not define new procedures or processes. Whenever this document makes statements or recommendations, these are taken from normative text in the referenced RFCs. |
|
| |
| RFC 9030 | An Architecture for IPv6 over the Time-Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH) |
| |
|
|
This document describes a network architecture that provides low- latency, low-jitter, and high-reliability packet delivery. It combines a high-speed powered backbone and subnetworks using IEEE802.15.4 time-slotted channel hopping (TSCH) to meet the requirements of low-power wireless deterministic applications. |
|
| |
| RFC 9037 | Deterministic Networking (DetNet) Data Plane: MPLS over IEEE 802.1 Time-Sensitive Networking (TSN) |
| |
| Authors: | B. Varga, Ed., J. Farkas, A. Malis, S. Bryant. |
| Date: | June 2021 |
| Formats: | txt pdf json xml html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9037 |
|
This document specifies the Deterministic Networking (DetNet) MPLS data plane when operating over an IEEE 802.1 Time-SensitiveNetworking (TSN) sub-network. This document does not define new procedures or processes. Whenever this document makes statements or recommendations, they are taken from normative text in the referencedRFCs. |
|
| |
| RFC 9040 | TCP Control Block Interdependence |
| |
|
|
This memo provides guidance to TCP implementers that is intended to help improve connection convergence to steady-state operation without affecting interoperability. It updates and replaces RFC 2140's description of sharing TCP state, as typically represented in TCPControl Blocks, among similar concurrent or consecutive connections. |
|
| |
| RFC 9043 | FFV1 Video Coding Format Versions 0, 1, and 3 |
| |
| Authors: | M. Niedermayer, D. Rice, J. Martinez. |
| Date: | August 2021 |
| Formats: | txt html pdf xml json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9043 |
|
This document defines FFV1, a lossless, intra-frame video encoding format. FFV1 is designed to efficiently compress video data in a variety of pixel formats. Compared to uncompressed video, FFV1 offers storage compression, frame fixity, and self-description, which makes FFV1 useful as a preservation or intermediate video format. |
|
| |
| RFC 9046 | Babel Information Model |
| |
|
|
The Babel information model provides structured data elements for aBabel implementation reporting its current state and may allow limited configuration of some such data elements. This information model can be used as a basis for creating data models under various data modeling regimes. This information model only includes parameters and parameter values useful for managing Babel over IPv6. |
|
| |
| RFC 9049 | Path Aware Networking: Obstacles to Deployment (A Bestiary of Roads Not Taken) |
| |
|
|
This document is a product of the Path Aware Networking ResearchGroup (PANRG). At the first meeting of the PANRG, the Research Group agreed to catalog and analyze past efforts to develop and deploy PathAware techniques, most of which were unsuccessful or at most partially successful, in order to extract insights and lessons forPath Aware networking researchers.
This document contains that catalog and analysis. |
|
| |
| RFC 9053 | CBOR Object Signing and Encryption (COSE): Initial Algorithms |
| |
|
|
Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines a set of algorithms that can be used with the CBORObject Signing and Encryption (COSE) protocol (RFC 9052).
This document, along with RFC 9052, obsoletes RFC 8152. |
|
| |
| RFC 9054 | CBOR Object Signing and Encryption (COSE): Hash Algorithms |
| |
|
|
The CBOR Object Signing and Encryption (COSE) syntax (see RFC 9052) does not define any direct methods for using hash algorithms. There are, however, circumstances where hash algorithms are used, such as indirect signatures, where the hash of one or more contents are signed, and identification of an X.509 certificate or other object by the use of a fingerprint. This document defines hash algorithms that are identified by COSE algorithm identifiers. |
|
| |
| RFC 9055 | Deterministic Networking (DetNet) Security Considerations |
| |
| Authors: | E. Grossman, Ed., T. Mizrahi, A. Hacker. |
| Date: | June 2021 |
| Formats: | txt json xml pdf html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9055 |
|
A DetNet (deterministic network) provides specific performance guarantees to its data flows, such as extremely low data loss rates and bounded latency (including bounded latency variation, i.e.,"jitter"). As a result, securing a DetNet requires that in addition to the best practice security measures taken for any mission-critical network, additional security measures may be needed to secure the intended operation of these novel service properties.
This document addresses DetNet-specific security considerations from the perspectives of both the DetNet system-level designer and component designer. System considerations include a taxonomy of relevant threats and attacks, and associations of threats versus use cases and service properties. Component-level considerations include ingress filtering and packet arrival-time violation detection.
This document also addresses security considerations specific to theIP and MPLS data plane technologies, thereby complementing theSecurity Considerations sections of those documents. |
|
| |
| RFC 9058 | Multilinear Galois Mode (MGM) |
| |
| Authors: | S. Smyshlyaev, Ed., V. Nozdrunov, V. Shishkin, E. Griboedova. |
| Date: | June 2021 |
| Formats: | txt json pdf html xml |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9058 |
|
Multilinear Galois Mode (MGM) is an Authenticated Encryption withAssociated Data (AEAD) block cipher mode based on the Encrypt-then-MAC (EtM) principle. MGM is defined for use with 64-bit and 128-bit block ciphers.
MGM has been standardized in Russia. It is used as an AEAD mode for the GOST block cipher algorithms in many protocols, e.g., TLS 1.3 andIPsec. This document provides a reference for MGM to enable review of the mechanisms in use and to make MGM available for use with any block cipher. |
|
| |
| RFC 9062 | Framework and Requirements for Ethernet VPN (EVPN) Operations, Administration, and Maintenance (OAM) |
| |
| Authors: | S. Salam, A. Sajassi, S. Aldrin, J. Drake, D. Eastlake 3rd. |
| Date: | June 2021 |
| Formats: | txt html json pdf xml |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9062 |
|
This document specifies the requirements and reference framework forEthernet VPN (EVPN) Operations, Administration, and Maintenance(OAM). The requirements cover the OAM aspects of EVPN and ProviderBackbone Bridge EVPN (PBB-EVPN). The framework defines the layeredOAM model encompassing the EVPN service layer, network layer, underlying Packet Switched Network (PSN) transport layer, and link layer but focuses on the service and network layers. |
|
| |
| RFC 9063 | Host Identity Protocol Architecture |
| |
|
|
This memo describes the Host Identity (HI) namespace, which provides a cryptographic namespace to applications, and the associated protocol layer, the Host Identity Protocol, located between the internetworking and transport layers, that supports end-host mobility, multihoming, and NAT traversal. Herein are presented the basics of the current namespaces, their strengths and weaknesses, and how a HI namespace will add completeness to them. The roles of theHI namespace in the protocols are defined.
This document obsoletes RFC 4423 and addresses the concerns raised by the IESG, particularly that of crypto agility. The SecurityConsiderations section also describes measures against flooding attacks, usage of identities in access control lists, weaker types of identifiers, and trust on first use. This document incorporates lessons learned from the implementations of RFC 7401 and goes further to explain how HIP works as a secure signaling channel. |
|
| |
| RFC 9064 | Considerations in the Development of a QoS Architecture for CCNx-Like Information-Centric Networking Protocols |
| |
|
|
This is a position paper. It documents the author's personal views on how Quality of Service (QoS) capabilities ought to be accommodated in Information-Centric Networking (ICN) protocols like Content-Centric Networking (CCNx) or Named Data Networking (NDN), which employ flow-balanced Interest/Data exchanges and hop-by-hop forwarding state as their fundamental machinery. It argues that such protocols demand a substantially different approach to QoS from that taken in TCP/IP and proposes specific design patterns to achieve both classification and differentiated QoS treatment on both a flow and aggregate basis. It also considers the effect of caches in addition to memory, CPU, and link bandwidth as resources that should be subject to explicitly unfair resource allocation. The proposed methods are intended to operate purely at the network layer, providing the primitives needed to achieve transport- and higher- layer QoS objectives. It explicitly excludes any discussion ofQuality of Experience (QoE), which can only be assessed and controlled at the application layer or above.
This document is not a product of the IRTF Information-CentricNetworking Research Group (ICNRG) but has been through formal LastCall and has the support of the participants in the research group for publication as an individual submission. |
|
| |
| RFC 9065 | Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols |
| |
|
|
To protect user data and privacy, Internet transport protocols have supported payload encryption and authentication for some time. Such encryption and authentication are now also starting to be applied to the transport protocol headers. This helps avoid transport protocol ossification by middleboxes, mitigate attacks against the transport protocol, and protect metadata about the communication. Current operational practice in some networks inspect transport header information within the network, but this is no longer possible when those transport headers are encrypted.
This document discusses the possible impact when network traffic uses a protocol with an encrypted transport header. It suggests issues to consider when designing new transport protocols or features. |
|
| |
| RFC 9075 | Report from the IAB COVID-19 Network Impacts Workshop 2020 |
| |
| Authors: | J. Arkko, S. Farrell, M. Kühlewind, C. Perkins. |
| Date: | July 2021 |
| Formats: | txt json html xml pdf |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9075 |
|
The Coronavirus disease (COVID-19) pandemic caused changes inInternet user behavior, particularly during the introduction of initial quarantine and work-from-home arrangements. These behavior changes drove changes in Internet traffic.
The Internet Architecture Board (IAB) held a workshop to discuss network impacts of the pandemic on November 9-13, 2020. The workshop was held to convene interested researchers, network operators, network management experts, and Internet technologists to share their experiences. The meeting was held online given the ongoing travel and contact restrictions at that time.
Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions. |
|
| |
| RFC 9076 | DNS Privacy Considerations |
| |
|
|
This document describes the privacy issues associated with the use of the DNS by Internet users. It provides general observations about typical current privacy practices. It is intended to be an analysis of the present situation and does not prescribe solutions. This document obsoletes RFC 7626. |
|
| |
| RFC 9087 | Segment Routing Centralized BGP Egress Peer Engineering |
| |
| Authors: | C. Filsfils, Ed., S. Previdi, G. Dawra, Ed., E. Aries, D. Afanasiev. |
| Date: | August 2021 |
| Formats: | txt html pdf xml json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9087 |
|
Segment Routing (SR) leverages source routing. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. A segment can represent any instruction, topological or service based. SR allows for the enforcement of a flow through any topological path while maintaining per-flow state only at the ingress node of the SR domain.
The Segment Routing architecture can be directly applied to the MPLS data plane with no change on the forwarding plane. It requires a minor extension to the existing link-state routing protocols.
This document illustrates the application of Segment Routing to solve the BGP Egress Peer Engineering (BGP-EPE) requirement. The SR-basedBGP-EPE solution allows a centralized (Software-Defined Networking, or SDN) controller to program any egress peer policy at ingress border routers or at hosts within the domain. |
|
| |
| RFC 9095 | Extensible Provisioning Protocol (EPP) Domain Name Mapping Extension for Strict Bundling Registration |
| |
| Authors: | J. Yao, L. Zhou, H. Li, N. Kong, J. Xie. |
| Date: | July 2021 |
| Formats: | txt json pdf xml html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9095 |
|
This document describes an extension of Extensible ProvisioningProtocol (EPP) domain name mapping for the provisioning and management of strict bundling registration of domain names.Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of bundled domain names. This is a nonstandard proprietary extension. |
|
| |
| RFC 9098 | Operational Implications of IPv6 Packets with Extension Headers |
| |
| Authors: | F. Gont, N. Hilliard, G. Doering, W. Kumari, G. Huston, W. Liu. |
| Date: | September 2021 |
| Formats: | txt json xml html pdf |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9098 |
|
This document summarizes the operational implications of IPv6 extension headers specified in the IPv6 protocol specification (RFC8200) and attempts to analyze reasons why packets with IPv6 extension headers are often dropped in the public Internet. |
|
| |
| RFC 9099 | Operational Security Considerations for IPv6 Networks |
| |
| Authors: | É. Vyncke, K. Chittimaneni, M. Kaeo, E. Rey. |
| Date: | August 2021 |
| Formats: | txt json xml pdf html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9099 |
|
Knowledge and experience on how to operate IPv4 networks securely is available, whether the operator is an Internet Service Provider (ISP) or an enterprise internal network. However, IPv6 presents some new security challenges. RFC 4942 describes security issues in the protocol, but network managers also need a more practical, operations-minded document to enumerate advantages and/or disadvantages of certain choices.
This document analyzes the operational security issues associated with several types of networks and proposes technical and procedural mitigation techniques. This document is only applicable to managed networks, such as enterprise networks, service provider networks, or managed residential networks. |
|
| |
| RFC 9106 | Argon2 Memory-Hard Function for Password Hashing and Proof-of-Work Applications |
| |
| Authors: | A. Biryukov, D. Dinu, D. Khovratovich, S. Josefsson. |
| Date: | September 2021 |
| Formats: | txt html json pdf xml |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9106 |
|
This document describes the Argon2 memory-hard function for password hashing and proof-of-work applications. We provide an implementer- oriented description with test vectors. The purpose is to simplify adoption of Argon2 for Internet protocols. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. |
|
| |
| RFC 9116 | A File Format to Aid in Security Vulnerability Disclosure |
| |
|
|
When security vulnerabilities are discovered by researchers, proper reporting channels are often lacking. As a result, vulnerabilities may be left unreported. This document defines a machine-parsable format ("security.txt") to help organizations describe their vulnerability disclosure practices to make it easier for researchers to report vulnerabilities. |
|
| |
| RFC 9119 | Multicast Considerations over IEEE 802 Wireless Media |
| |
| Authors: | C. Perkins, M. McBride, D. Stanley, W. Kumari, JC. Zúñiga. |
| Date: | October 2021 |
| Formats: | txt json html xml pdf |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9119 |
|
Well-known issues with multicast have prevented the deployment of multicast in 802.11 (Wi-Fi) and other local-area wireless environments. This document describes the known limitations of wireless (primarily 802.11) Layer 2 multicast. Also described are certain multicast enhancement features that have been specified by the IETF and by IEEE 802 for wireless media, as well as some operational choices that can be made to improve the performance of the network. Finally, some recommendations are provided about the usage and combination of these features and operational choices. |
|
| |
| RFC 9120 | Nameservers for the Address and Routing Parameter Area ("arpa") Domain |
| |
|
|
This document describes revisions to operational practices to separate the function of the "arpa" top-level domain in the DNS from its historical operation alongside the DNS root zone. |
|
| |
| RFC 9121 | Deprecating Infrastructure "int" Domains |
| |
|
|
This document deprecates the use of any "int" domain names that were designated for infrastructure purposes by the IETF, and it identifies them for removal from the "int" top-level domain. Any implementations that involve these domains are now deprecated. This document also changes the status of RFC 1528 and RFC 1706 toHistoric. |
|
| |
| RFC 9124 | A Manifest Information Model for Firmware Updates in Internet of Things (IoT) Devices |
| |
| Authors: | B. Moran, H. Tschofenig, H. Birkholz. |
| Date: | January 2022 |
| Formats: | txt json xml html pdf |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9124 |
|
Vulnerabilities with Internet of Things (IoT) devices have raised the need for a reliable and secure firmware update mechanism that is also suitable for constrained devices. Ensuring that devices function and remain secure over their service lifetime requires such an update mechanism to fix vulnerabilities, update configuration settings, and add new functionality.
One component of such a firmware update is a concise and machine- processable metadata document, or manifest, that describes the firmware image(s) and offers appropriate protection. This document describes the information that must be present in the manifest. |
|
| |
| RFC 9138 | Design Considerations for Name Resolution Service in Information-Centric Networking (ICN) |
| |
| Authors: | J. Hong, T. You, L. Dong, C. Westphal, B. Ohlman. |
| Date: | December 2021 |
| Formats: | txt xml json pdf html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9138 |
|
This document provides the functionalities and design considerations for a Name Resolution Service (NRS) in Information-Centric Networking(ICN). The purpose of an NRS in ICN is to translate an object name into some other information such as a locator, another name, etc. in order to forward the object request. This document is a product of the Information-Centric Networking Research Group (ICNRG). |
|
| |
| RFC 9150 | TLS 1.3 Authentication and Integrity-Only Cipher Suites |
| |
|
|
This document defines the use of cipher suites for TLS 1.3 based onHashed Message Authentication Code (HMAC). Using these cipher suites provides server and, optionally, mutual authentication and data authenticity, but not data confidentiality. Cipher suites with these properties are not of general applicability, but there are use cases, specifically in Internet of Things (IoT) and constrained environments, that do not require confidentiality of exchanged messages while still requiring integrity protection, server authentication, and optional client authentication. This document gives examples of such use cases, with the caveat that prior to using these integrity-only cipher suites, a threat model for the situation at hand is needed, and a threat analysis must be performed within that model to determine whether the use of integrity-only cipher suites is appropriate. The approach described in this document is not endorsed by the IETF and does not have IETF consensus, but it is presented here to enable interoperable implementation of a reduced- security mechanism that provides authentication and message integrity without supporting confidentiality. |
|
| |
| RFC 9151 | Commercial National Security Algorithm (CNSA) Suite Profile for TLS and DTLS 1.2 and 1.3 |
| |
|
|
This document defines a base profile for TLS protocol versions 1.2 and 1.3 as well as DTLS protocol versions 1.2 and 1.3 for use with the US Commercial National Security Algorithm (CNSA) Suite.
The profile applies to the capabilities, configuration, and operation of all components of US National Security Systems that use TLS orDTLS. It is also appropriate for all other US Government systems that process high-value information.
The profile is made publicly available here for use by developers and operators of these and any other system deployments. |
|
| |
| RFC 9152 | Secure Object Delivery Protocol (SODP) Server Interfaces: NSA's Profile for Delivery of Certificates, Certificate Revocation Lists (CRLs), and Symmetric Keys to Clients |
| |
|
|
This document specifies protocol interfaces profiled by the UnitedStates National Security Agency (NSA) for National Security System(NSS) servers that provide public key certificates, CertificateRevocation Lists (CRLs), and symmetric keys to NSS clients. Servers that support these interfaces are referred to as Secure ObjectDelivery Protocol (SODP) servers. The intended audience for this profile comprises developers of client devices that will obtain key management services from NSA-operated SODP servers. Interfaces supported by SODP servers include Enrollment over Secure Transport(EST) and its extensions as well as Certificate Management over CMS(CMC).
This profile applies to the capabilities, configuration, and operation of all components of US National Security Systems (SP800-59). It is also appropriate for other US Government systems that process high-value information. It is made publicly available for use by developers and operators of these and any other system deployments. |
|
| |
| RFC 9153 | Drone Remote Identification Protocol (DRIP) Requirements and Terminology |
| |
| Authors: | S. Card, Ed., A. Wiethuechter, R. Moskowitz, A. Gurtov. |
| Date: | February 2022 |
| Formats: | txt json pdf xml html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9153 |
|
This document defines terminology and requirements for solutions produced by the Drone Remote Identification Protocol (DRIP) WorkingGroup. These solutions will support Unmanned Aircraft System RemoteIdentification and tracking (UAS RID) for security, safety, and other purposes (e.g., initiation of identity-based network sessions supporting UAS applications). DRIP will facilitate use of existingInternet resources to support RID and to enable enhanced related services, and it will enable online and offline verification that RID information is trustworthy. |
|
| |
| RFC 9158 | Update to the Object Identifier Registry for the PKIX Working Group |
| |
|
|
RFC 7299 describes the object identifiers that were assigned by thePublic Key Infrastructure using X.509 (PKIX) Working Group in an arc that was allocated by IANA (1.3.6.1.5.5.7). A small number of object identifiers that were assigned in RFC 4212 are omitted from RFC 7299, and this document updates RFC 7299 to correct that oversight. |
|
| |
| RFC 9160 | Export of MPLS Segment Routing Label Type Information in IP Flow Information Export (IPFIX) |
| |
|
|
This document introduces new IP Flow Information Export (IPFIX) code points to identify which traffic is being forwarded based on whichMPLS control plane protocol is used within a Segment Routing domain.In particular, this document defines five code points for the IPFIX mplsTopLabelType Information Element for Path Computation Element(PCE), IS-IS, OSPFv2, OSPFv3, and BGP MPLS Segment Routing extensions. |
|
| |
| RFC 9169 | New ASN.1 Modules for the Evidence Record Syntax (ERS) |
| |
|
|
The Evidence Record Syntax (ERS) and the conventions for including these evidence records in the Server-based Certificate ValidationProtocol (SCVP) are expressed using ASN.1. This document offers alternative ASN.1 modules that conform to the 2002 version of ASN.1 and employ the conventions adopted in RFCs 5911, 5912, and 6268.There are no bits-on-the-wire changes to any of the formats; this is simply a change to the ASN.1 syntax. |
|
| |
| RFC 9170 | Long-Term Viability of Protocol Extension Mechanisms |
| |
|
|
The ability to change protocols depends on exercising the extension and version-negotiation mechanisms that support change. This document explores how regular use of new protocol features can ensure that it remains possible to deploy changes to a protocol. Examples are given where lack of use caused changes to be more difficult or costly. |
|
| |
| RFC 9178 | Building Power-Efficient Constrained Application Protocol (CoAP) Devices for Cellular Networks |
| |
| Authors: | J. Arkko, A. Eriksson, A. Keränen. |
| Date: | May 2022 |
| Formats: | txt html xml pdf json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9178 |
|
This memo discusses the use of the Constrained Application Protocol(CoAP) in building sensors and other devices that employ cellular networks as a communications medium. Building communicating devices that employ these networks is obviously well known, but this memo focuses specifically on techniques necessary to minimize power consumption. |
|
| |
| RFC 9180 | Hybrid Public Key Encryption |
| |
| Authors: | R. Barnes, K. Bhargavan, B. Lipp, C. Wood. |
| Date: | February 2022 |
| Formats: | txt html xml json pdf |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9180 |
|
This document describes a scheme for hybrid public key encryption(HPKE). This scheme provides a variant of public key encryption of arbitrary-sized plaintexts for a recipient public key. It also includes three authenticated variants, including one that authenticates possession of a pre-shared key and two optional ones that authenticate possession of a key encapsulation mechanism (KEM) private key. HPKE works for any combination of an asymmetric KEM, key derivation function (KDF), and authenticated encryption with additional data (AEAD) encryption function. Some authenticated variants may not be supported by all KEMs. We provide instantiations of the scheme using widely used and efficient primitives, such asElliptic Curve Diffie-Hellman (ECDH) key agreement, HMAC-based key derivation function (HKDF), and SHA2.
This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. |
|
| |
| RFC 9185 | DTLS Tunnel between a Media Distributor and Key Distributor to Facilitate Key Exchange |
| |
| Authors: | P. Jones, P. Ellenbogen, N. Ohlmeier. |
| Date: | April 2022 |
| Formats: | txt pdf xml html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9185 |
|
This document defines a protocol for tunneling DTLS traffic in multimedia conferences that enables a Media Distributor to facilitate key exchange between an endpoint in a conference and the KeyDistributor. The protocol is designed to ensure that the keying material used for hop-by-hop encryption and authentication is accessible to the Media Distributor, while the keying material used for end-to-end encryption and authentication is inaccessible to theMedia Distributor. |
|
| |
| RFC 9187 | 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. |
|
| |
| RFC 9189 | GOST Cipher Suites for Transport Layer Security (TLS) Protocol Version 1.2 |
| |
| Authors: | S. Smyshlyaev, Ed., D. Belyavsky, E. Alekseev. |
| Date: | March 2022 |
| Formats: | txt html xml pdf json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9189 |
|
This document specifies three new cipher suites, two new signature algorithms, seven new supported groups, and two new certificate types for the Transport Layer Security (TLS) protocol version 1.2 to support the Russian cryptographic standard algorithms (called "GOST" algorithms). This document specifies a profile of TLS 1.2 with GOST algorithms so that implementers can produce interoperable implementations.
This specification facilitates implementations that aim to support the GOST algorithms. This document does not imply IETF endorsement of the cipher suites, signature algorithms, supported groups, and certificate types. |
|
| |
| RFC 9191 | Handling Large Certificates and Long Certificate Chains in TLS-Based EAP Methods |
| |
| Authors: | M. Sethi, J. Preuß Mattsson, S. Turner. |
| Date: | February 2022 |
| Formats: | txt html pdf xml json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9191 |
|
The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides a standard mechanism for support of multiple authentication methods. EAP-TLS and other TLS-based EAP methods are widely deployed and used for network access authentication. Large certificates and long certificate chains combined with authenticators that drop an EAP session after only 40 - 50 round trips is a major deployment problem.This document looks at this problem in detail and describes the potential solutions available. |
|
| |
| RFC 9192 | Network Service Header (NSH) Fixed-Length Context Header Allocation |
| |
| Authors: | T. Mizrahi, I. Yerushalmi, D. Melman, R. Browne. |
| Date: | February 2022 |
| Formats: | txt xml json pdf html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9192 |
|
The Network Service Header (NSH) specification defines two possible methods of including metadata (MD): MD Type 0x1 and MD Type 0x2. MDType 0x1 uses a fixed-length Context Header. The allocation of thisContext Header, i.e., its structure and semantics, has not been standardized. This memo defines the Timestamp Context Header, which is an NSH fixed-length Context Header that incorporates the packet's timestamp, a sequence number, and a source interface identifier.
Although the definition of the Context Header presented in this document has not been standardized by the IETF, it has been implemented in silicon by several manufacturers and is published here to facilitate interoperability. |
|
| |
| RFC 9199 | Considerations for Large Authoritative DNS Server Operators |
| |
| Authors: | G. Moura, W. Hardaker, J. Heidemann, M. Davids. |
| Date: | March 2022 |
| Formats: | txt html pdf xml json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9199 |
|
Recent research work has explored the deployment characteristics and configuration of the Domain Name System (DNS). This document summarizes the conclusions from these research efforts and offers specific, tangible considerations or advice to authoritative DNS server operators. Authoritative server operators may wish to follow these considerations to improve their DNS services.
It is possible that the results presented in this document could be applicable in a wider context than just the DNS protocol, as some of the results may generically apply to any stateless/short-duration anycasted service.
This document is not an IETF consensus document: it is published for informational purposes. |
|
| |
| RFC 9206 | Commercial National Security Algorithm (CNSA) Suite Cryptography for Internet Protocol Security (IPsec) |
| |
|
|
The United States Government has published the National SecurityAgency's Commercial National Security Algorithm (CNSA) Suite, which defines cryptographic algorithm policy for national security applications. This document specifies the conventions for using theUnited States National Security Agency's CNSA Suite algorithms inInternet Protocol Security (IPsec). It applies to the capabilities, configuration, and operation of all components of US NationalSecurity Systems (described in NIST Special Publication 800-59) that employ IPsec. This document is also appropriate for all other USGovernment systems that process high-value information. It is made publicly available for use by developers and operators of these and any other system deployments. |
|
| |
| RFC 9212 | Commercial National Security Algorithm (CNSA) Suite Cryptography for Secure Shell (SSH) |
| |
|
|
The United States Government has published the National SecurityAgency (NSA) Commercial National Security Algorithm (CNSA) Suite, which defines cryptographic algorithm policy for national security applications. This document specifies the conventions for using theUnited States National Security Agency's CNSA Suite algorithms with the Secure Shell Transport Layer Protocol and the Secure ShellAuthentication Protocol. It applies to the capabilities, configuration, and operation of all components of US NationalSecurity Systems (described in NIST Special Publication 800-59) that employ Secure Shell (SSH). This document is also appropriate for all other US Government systems that process high-value information. It is made publicly available for use by developers and operators of these and any other system deployments. |
|
| |
| RFC 9215 | Using GOST R 34.10-2012 and GOST R 34.11-2012 Algorithms with the Internet X.509 Public Key Infrastructure |
| |
| Authors: | D. Baryshkov, Ed., V. Nikolaev, A. Chelpanov. |
| Date: | March 2022 |
| Formats: | txt xml pdf html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9215 |
|
This document describes encoding formats, identifiers, and parameter formats for the GOST R 34.10-2012 and GOST R 34.11-2012 algorithms for use in the Internet X.509 Public Key Infrastructure (PKI).
This specification is developed to facilitate implementations that wish to support the GOST algorithms. This document does not implyIETF endorsement of the cryptographic algorithms used in this document. |
|
| |
| RFC 9216 | S/MIME Example Keys and Certificates |
| |
|
|
The S/MIME development community benefits from sharing samples of signed or encrypted data. This document facilitates such collaboration by defining a small set of X.509v3 certificates and keys for use when generating such samples. |
|
| |
| RFC 9217 | Current Open Questions in Path-Aware Networking |
| |
|
|
In contrast to the present Internet architecture, a path-aware internetworking architecture has two important properties: it exposes the properties of available Internet paths to endpoints, and it provides for endpoints and applications to use these properties to select paths through the Internet for their traffic. While this property of "path awareness" already exists in many Internet- connected networks within single domains and via administrative interfaces to the network layer, a fully path-aware internetwork expands these concepts across layers and across the Internet.
This document poses questions in path-aware networking, open as of2021, that must be answered in the design, development, and deployment of path-aware internetworks. It was originally written to frame discussions in the Path Aware Networking Research Group(PANRG), and has been published to snapshot current thinking in this space. |
|
| |
| RFC 9222 | Guidelines for Autonomic Service Agents |
| |
| Authors: | B. E. Carpenter, L. Ciavaglia, S. Jiang, P. Peloso. |
| Date: | March 2022 |
| Formats: | txt json pdf html xml |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9222 |
|
This document proposes guidelines for the design of Autonomic ServiceAgents for autonomic networks. Autonomic Service Agents, together with the Autonomic Network Infrastructure, the Autonomic ControlPlane, and the GeneRic Autonomic Signaling Protocol, constitute base elements of an autonomic networking ecosystem. |
|
| |
| RFC 9223 | Real-Time Transport Object Delivery over Unidirectional Transport (ROUTE) |
| |
| Authors: | W. Zia, T. Stockhammer, L. Chaponniere, G. Mandyam, M. Luby. |
| Date: | April 2022 |
| Formats: | txt json pdf html xml |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9223 |
|
The Real-time Transport Object delivery over Unidirectional Transport(ROUTE) protocol is specified for robust delivery of ApplicationObjects, including Application Objects with real-time delivery constraints, to receivers over a unidirectional transport.Application Objects consist of data that has meaning to applications that use the ROUTE protocol for delivery of data to receivers; for example, it can be a file, a Dynamic Adaptive Streaming over HTTP(DASH) or HTTP Live Streaming (HLS) segment, a WAV audio clip, etc.The ROUTE protocol also supports low-latency streaming applications.
The ROUTE protocol is suitable for unicast, broadcast, and multicast transport. Therefore, it can be run over UDP/IP, including multicastIP. The ROUTE protocol can leverage the features of the underlying protocol layer, e.g., to provide security, it can leverage IP security protocols such as IPsec.
This document specifies the ROUTE protocol such that it could be used by a variety of services for delivery of Application Objects by specifying their own profiles of this protocol (e.g., by adding or constraining some features).
This is not an IETF specification and does not have IETF consensus. |
|
| |
| RFC 9225 | Software Defects Considered Harmful |
| |
| Authors: | J. Snijders, C. Morrow, R. van Mook. |
| Date: | 1 April 2022 |
| Formats: | txt html pdf xml json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9225 |
|
This document discourages the practice of introducing software defects in general and in network protocol implementations specifically. Software defects are one of the largest cost drivers for the networking industry. This document is intended to clarify the best current practice in this regard. |
|
| |
| RFC 9227 | 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 theEncapsulating Security Payload (ESP) and in the Internet Key Exchange version 2 (IKEv2) protocols, which are parts of the IP Security(IPsec) protocol suite. The transforms are based on the GOST R34.12-2015 block ciphers (which are named "Magma" and "Kuznyechik") in Multilinear Galois Mode (MGM) and the external rekeying approach.
This specification was developed to facilitate implementations that wish to support the GOST algorithms. This document does not implyIETF endorsement of the cryptographic algorithms used in this document. |
|
| |
| RFC 9232 | Network Telemetry Framework |
| |
| Authors: | H. Song, F. Qin, P. Martinez-Julia, L. Ciavaglia, A. Wang. |
| Date: | May 2022 |
| Formats: | txt json html xml pdf |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9232 |
|
Network telemetry is a technology for gaining network insight and facilitating efficient and automated network management. It encompasses various techniques for remote data generation, collection, correlation, and consumption. This document describes an architectural framework for network telemetry, motivated by challenges that are encountered as part of the operation of networks and by the requirements that ensue. This document clarifies the terminology and classifies the modules and components of a network telemetry system from different perspectives. The framework and taxonomy help to set a common ground for the collection of related work and provide guidance for related technique and standard developments. |
|
| |
| RFC 9235 | TCP Authentication Option (TCP-AO) Test Vectors |
| |
|
|
This document provides test vectors to validate implementations of the two mandatory authentication algorithms specified for the TCPAuthentication Option over both IPv4 and IPv6. This includes validation of the key derivation function (KDF) based on a set of test connection parameters as well as validation of the message authentication code (MAC). Vectors are provided for both currently required pairs of KDF and MAC algorithms: KDF_HMAC_SHA1 and HMAC-SHA-1-96, and KDF_AES_128_CMAC and AES-128-CMAC-96. The vectors also validate both whole TCP segments as well as segments whose options are excluded for middlebox traversal. |
|
| |
| RFC 9236 | Architectural Considerations of Information-Centric Networking (ICN) Using a Name Resolution Service |
| |
|
|
This document describes architectural considerations and implications related to the use of a Name Resolution Service (NRS) in Information-Centric Networking (ICN). It explains how the ICN architecture can change when an NRS is utilized and how its use influences the ICN routing system. This document is a product of the Information-Centric Networking Research Group (ICNRG). |
|
| |
| RFC 9238 | Loading Manufacturer Usage Description (MUD) URLs from QR Codes |
| |
| Authors: | M. Richardson, J. Latour, H. Habibi Gharakheili. |
| Date: | May 2022 |
| Formats: | txt pdf xml html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9238 |
|
This informational document details a protocol to load ManufacturerUsage Description (MUD) definitions from RFC 8520 for devices that do not have them integrated.
This document is published to inform the Internet community of this mechanism to allow interoperability and to serve as a basis of other standards work if there is interest. |
|
| |
| RFC 9239 | Updates to ECMAScript Media Types |
| |
|
|
This document describes the registration of media types for theECMAScript and JavaScript programming languages and conformance requirements for implementations of these types. This document obsoletes RFC 4329 ("Scripting Media Types)", replacing the previous registrations with information and requirements aligned with common usage and implementation experiences. |
|
| |
| RFC 9257 | Guidance for External Pre-Shared Key (PSK) Usage in TLS |
| |
| Authors: | R. Housley, J. Hoyland, M. Sethi, C. A. Wood. |
| Date: | July 2022 |
| Formats: | txt html pdf xml json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9257 |
|
This document provides usage guidance for external Pre-Shared Keys(PSKs) in Transport Layer Security (TLS) 1.3 as defined in RFC 8446.It lists TLS security properties provided by PSKs under certain assumptions, then it demonstrates how violations of these assumptions lead to attacks. Advice for applications to help meet these assumptions is provided. This document also discusses PSK use cases and provisioning processes. Finally, it lists the privacy and security properties that are not provided by TLS 1.3 when externalPSKs are used. |
|
| |
| RFC 9265 | Forward Erasure Correction (FEC) Coding and Congestion Control in Transport |
| |
| Authors: | N. Kuhn, E. Lochin, F. Michel, M. Welzl. |
| Date: | July 2022 |
| Formats: | txt json pdf html xml |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9265 |
|
Forward Erasure Correction (FEC) is a reliability mechanism that is distinct and separate from the retransmission logic in reliable transfer protocols such as TCP. FEC coding can help deal with losses at the end of transfers or with networks having non-congestion losses. However, FEC coding mechanisms should not hide congestion signals. This memo offers a discussion of how FEC coding and congestion control can coexist. Another objective is to encourage the research community to also consider congestion control aspects when proposing and comparing FEC coding solutions in communication systems.
This document is the product of the Coding for Efficient NetworkCommunications Research Group (NWCRG). The scope of the document is end-to-end communications; FEC coding for tunnels is out of the scope of the document. |
|
| |
| RFC 9267 | Common Implementation Anti-Patterns Related to Domain Name System (DNS) Resource Record (RR) Processing |
| |
| Authors: | S. Dashevskyi, D. dos Santos, J. Wetzels, A. Amri. |
| Date: | July 2022 |
| Formats: | txt xml pdf html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9267 |
|
This memo describes common vulnerabilities related to Domain NameSystem (DNS) resource record (RR) processing as seen in several DNS client implementations. These vulnerabilities may lead to successfulDenial-of-Service and Remote Code Execution attacks against the affected software. Where applicable, violations of RFC 1035 are mentioned. |
|
| |
| RFC 9269 | Experimental Scenarios of Information-Centric Networking (ICN) Integration in 4G Mobile Networks |
| |
| Authors: | P. Suthar, M. Stolic, A. Jangam, Ed., D. Trossen, R. Ravindran. |
| Date: | August 2022 |
| Formats: | txt xml pdf json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9269 |
|
A 4G mobile network uses IP-based transport for the control plane to establish the data session at the user plane for the actual data delivery. In the existing architecture, IP-based unicast is used for the delivery of multimedia content to a mobile terminal, where each user is receiving a separate stream from the server. From a bandwidth and routing perspective, this approach is inefficient.Evolved multimedia broadcast and multicast service (eMBMS) provides capabilities for delivering contents to multiple users simultaneously, but its deployment is very limited or at an experimental stage due to numerous challenges. The focus of this document is to list the options for using Information-CentricNetworking (ICN) in 4G mobile networks and elaborate the experimental setups for its further evaluation. The experimental setups discussed provide guidance for using ICN either natively or with an existing mobility protocol stack. With further investigations based on the listed experiments, ICN with its inherent capabilities such as network-layer multicast, anchorless mobility, security, and optimized data delivery using local caching at the edge may provide a viable alternative to IP transport in 4G mobile networks. |
|
| |
| RFC 9271 | 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 AttachmentDaemon and the Management Daemon. The practice current when this protocol was first developed risks weak security, and this is addressed in the Security Considerations sections of this document. |
|
| |
| RFC 9273 | Network Coding for Content-Centric Networking / Named Data Networking: Considerations and Challenges |
| |
| Authors: | K. Matsuzono, H. Asaeda, C. Westphal. |
| Date: | August 2022 |
| Formats: | txt html xml json pdf |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9273 |
|
This document describes the current research outcomes in NetworkCoding (NC) for Content-Centric Networking (CCNx) / Named DataNetworking (NDN) and clarifies the technical considerations and potential challenges for applying NC in CCNx/NDN. This document is the product of the Coding for Efficient Network CommunicationsResearch Group (NWCRG) and the Information-Centric NetworkingResearch Group (ICNRG). |
|
| |
| RFC 9280 | 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 SeriesWorking Group (RSWG), which produces policy proposals, and the RFCSeries Approval Board (RSAB), which approves such proposals. Second, policy implementation is primarily the responsibility of the RFCProduction Center (RPC) as contractually overseen by the IETFAdministration Limited Liability Company (IETF LLC). In addition, various responsibilities of the RFC Editor function are now performed alone or in combination by the RSWG, RSAB, RPC, RFC Series ConsultingEditor (RSCE), and IETF LLC. Finally, this document establishes theEditorial Stream for publication of future policy definition documents produced through the processes defined herein.
This document obsoletes RFC 8728. This document updates RFCs 7841,8729, and 8730. |
|
| |
| RFC 9284 | Multihoming Deployment Considerations for DDoS Open Threat Signaling (DOTS) |
| |
| Authors: | M. Boucadair, T. Reddy.K, W. Pan. |
| Date: | August 2022 |
| Formats: | txt xml pdf json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9284 |
|
This document discusses multihoming considerations for DDoS OpenThreat Signaling (DOTS). The goal is to provide some guidance forDOTS clients and client-domain DOTS gateways when multihomed. |
|
| |
| RFC 9285 | The Base45 Data Encoding |
| |
| Authors: | P. Fältström, F. Ljunggren, D.W. van Gulik. |
| Date: | August 2022 |
| Formats: | txt json xml pdf html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9285 |
|
This document describes the Base45 encoding scheme, which is built upon the Base64, Base32, and Base16 encoding schemes. |
|
| |
| RFC 9288 | Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers at Transit Routers |
| |
|
|
This document analyzes the security implications of IPv6 ExtensionHeaders and associated IPv6 options. Additionally, it discusses the operational and interoperability implications of discarding packets based on the IPv6 Extension Headers and IPv6 options they contain.Finally, it provides advice on the filtering of such IPv6 packets at transit routers for traffic not directed to them, for those cases where such filtering is deemed as necessary. |
|
| |
| RFC 9296 | ifStackTable for the Point-to-Point (P2P) Interface over a LAN Type: Definition and Examples |
| |
| Authors: | D. Liu, J. Halpern, C. Zhang. |
| Date: | August 2022 |
| Formats: | txt html json xml pdf |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9296 |
|
RFC 5309 defines the Point-to-Point (P2P) circuit type, one of the two circuit types used in the link-state routing protocols, and highlights that it is important to identify the correct circuit type when forming adjacencies, flooding link-state database packets, and monitoring the link state.
This document provides advice about the ifStack for the P2P interface over a LAN Type to facilitate operational control, maintenance, and statistics. |
|
| |
| RFC 9299 | An Architectural Introduction to the Locator/ID Separation Protocol (LISP) |
| |
| Authors: | A. Cabellos, D. Saucez, Ed.. |
| Date: | October 2022 |
| Formats: | txt json xml pdf html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9299 |
|
This document describes the architecture of the Locator/ID SeparationProtocol (LISP), making it easier to read the rest of the LISP specifications and providing a basis for discussion about the details of the LISP protocols. This document is used for introductory purposes; more details can be found in the protocol specifications,RFCs 9300 and 9301. |
|
| |
| RFC 9307 | Report from the IAB Workshop on Analyzing IETF Data (AID) 2021 |
| |
| Authors: | N. ten Oever, C. Cath, M. Kühlewind, C. S. Perkins. |
| Date: | September 2022 |
| Formats: | txt html json pdf xml |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9307 |
|
The "Show me the numbers: Workshop on Analyzing IETF Data (AID)" workshop was convened by the Internet Architecture Board (IAB) fromNovember 29 to December 2, 2021 and hosted by the IN-SIGHT.it project at the University of Amsterdam; however, it was converted to an online-only event. The workshop was organized into two discussion parts with a hackathon activity in between. This report summarizes the workshop's discussion and identifies topics that warrant future work and consideration.
Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions. |
|
| |
| RFC 9308 | Applicability of the QUIC Transport Protocol |
| |
| Authors: | M. Kühlewind, B. Trammell. |
| Date: | September 2022 |
| Formats: | txt json pdf xml html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9308 |
|
This document discusses the applicability of the QUIC transport protocol, focusing on caveats impacting application protocol development and deployment over QUIC. Its intended audience is designers of application protocol mappings to QUIC and implementors of these application protocols. |
|
| |
| RFC 9311 | Running an IETF Hackathon |
| |
|
|
IETF Hackathons encourage the IETF community to collaborate on running code related to existing and evolving Internet standards.This document provides a set of practices that have been used for running IETF Hackathons. These practices apply to Hackathons in which both in-person and remote participation are possible, with adaptations for Hackathons that are online only. |
|
| |
| RFC 9312 | Manageability of the QUIC Transport Protocol |
| |
| Authors: | M. Kühlewind, B. Trammell. |
| Date: | September 2022 |
| Formats: | txt html pdf xml json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9312 |
|
This document discusses manageability of the QUIC transport protocol and focuses on the implications of QUIC's design and wire image on network operations involving QUIC traffic. It is intended as a"user's manual" for the wire image to provide guidance for network operators and equipment vendors who rely on the use of transport- aware network functions. |
|
| |
| RFC 9313 | Pros and Cons of IPv6 Transition Technologies for IPv4-as-a-Service (IPv4aaS) |
| |
| Authors: | G. Lencse, J. Palet Martinez, L. Howard, R. Patterson, I. Farrer. |
| Date: | October 2022 |
| Formats: | txt pdf xml html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9313 |
|
Several IPv6 transition technologies have been developed to provide customers with IPv4-as-a-Service (IPv4aaS) for ISPs with an IPv6-only access and/or core network. These technologies have their advantages and disadvantages. Depending on existing topology, skills, strategy, and other preferences, one of these technologies may be the most appropriate solution for a network operator.
This document examines the five most prominent IPv4aaS technologies and considers a number of different aspects to provide network operators with an easy-to-use reference to assist in selecting the technology that best suits their needs. |
|
| |
| RFC 9315 | Intent-Based Networking - Concepts and Definitions |
| |
| Authors: | A. Clemm, L. Ciavaglia, L. Z. Granville, J. Tantsura. |
| Date: | October 2022 |
| Formats: | txt pdf xml json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9315 |
|
Intent and Intent-Based Networking are taking the industry by storm.At the same time, terms related to Intent-Based Networking are often used loosely and inconsistently, in many cases overlapping and confused with other concepts such as "policy." This document clarifies the concept of "intent" and provides an overview of the functionality that is associated with it. The goal is to contribute towards a common and shared understanding of terms, concepts, and functionality that can be used as the foundation to guide further definition of associated research and engineering problems and their solutions.
This document is a product of the IRTF Network Management ResearchGroup (NMRG). It reflects the consensus of the research group, having received many detailed and positive reviews by research group participants. It is published for informational purposes. |
|
| |
| RFC 9316 | Intent Classification |
| |
| Authors: | C. Li, O. Havel, A. Olariu, P. Martinez-Julia, J. Nobre, D. Lopez. |
| Date: | October 2022 |
| Formats: | txt html json xml pdf |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9316 |
|
Intent is an abstract, high-level policy used to operate a network.An intent-based management system includes an interface for users to input requests and an engine to translate the intents into the network configuration and manage their life cycle.
This document mostly discusses the concept of network intents, but other types of intents are also considered. Specifically, this document highlights stakeholder perspectives of intent, methods to classify and encode intent, and the associated intent taxonomy; it also defines relevant intent terms where necessary, provides a foundation for intent-related research, and facilitates solution development.
This document is a product of the IRTF Network Management ResearchGroup (NMRG). |
|
| |
| RFC 9317 | Operational Considerations for Streaming Media |
| |
| Authors: | J. Holland, A. Begen, S. Dawkins. |
| Date: | October 2022 |
| Formats: | txt html xml json pdf |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9317 |
|
This document provides an overview of operational networking and transport protocol issues that pertain to the quality of experience(QoE) when streaming video and other high-bitrate media over theInternet.
This document explains the characteristics of streaming media delivery that have surprised network designers or transport experts who lack specific media expertise, since streaming media highlights key differences between common assumptions in existing networking practices and observations of media delivery issues encountered when streaming media over those existing networks. |
|
| |
| RFC 9318 | IAB Workshop Report: Measuring Network Quality for End-Users |
| |
|
|
The Measuring Network Quality for End-Users workshop was held virtually by the Internet Architecture Board (IAB) on September14-16, 2021. This report summarizes the workshop, the topics discussed, and some preliminary conclusions drawn at the end of the workshop.
Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions. |
|
| |
| RFC 9320 | Deterministic Networking (DetNet) Bounded Latency |
| |
| Authors: | N. Finn, J.-Y. Le Boudec, E. Mohammadpour, J. Zhang, B. Varga. |
| Date: | November 2022 |
| Formats: | txt pdf xml json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9320 |
|
This document presents a timing model for sources, destinations, andDeterministic Networking (DetNet) transit nodes. Using the model, it provides a methodology to compute end-to-end latency and backlog bounds for various queuing methods. The methodology can be used by the management and control planes and by resource reservation algorithms to provide bounded latency and zero congestion loss for the DetNet service. |
|
| |
| RFC 9321 | Signature Validation Token |
| |
|
|
Electronic signatures have a limited lifespan with respect to the time period that they can be validated and determined to be authentic. The Signature Validation Token (SVT) defined in this specification provides evidence that asserts the validity of an electronic signature. The SVT is provided by a trusted authority, which asserts that a particular signature was successfully validated according to defined procedures at a certain time. Any future validation of that electronic signature can be satisfied by validating the SVT without any need to also validate the original electronic signature or the associated digital certificates. The SVT supports electronic signatures in Cryptographic Message Syntax (CMS),XML, PDF, and JSON documents. |
|
| |
| RFC 9330 | Low Latency, Low Loss, and Scalable Throughput (L4S) Internet Service: Architecture |
| |
| Authors: | B. Briscoe, Ed., K. De Schepper, M. Bagnulo, G. White. |
| Date: | January 2023 |
| Formats: | txt xml json pdf html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9330 |
|
This document describes the L4S architecture, which enables Internet applications to achieve low queuing latency, low congestion loss, and scalable throughput control. L4S is based on the insight that the root cause of queuing delay is in the capacity-seeking congestion controllers of senders, not in the queue itself. With the L4S architecture, all Internet applications could (but do not have to) transition away from congestion control algorithms that cause substantial queuing delay and instead adopt a new class of congestion controls that can seek capacity with very little queuing. These are aided by a modified form of Explicit Congestion Notification (ECN) from the network. With this new architecture, applications can have both low latency and high throughput.
The architecture primarily concerns incremental deployment. It defines mechanisms that allow the new class of L4S congestion controls to coexist with 'Classic' congestion controls in a shared network. The aim is for L4S latency and throughput to be usually much better (and rarely worse) while typically not impacting Classic performance. |
|
| |
| RFC 9333 | Minimal IP Encapsulating Security Payload (ESP) |
| |
|
|
This document describes the minimal properties that an IPEncapsulating Security Payload (ESP) implementation needs to meet to remain interoperable with the standard ESP as defined in RFC 4303.Such a minimal version of ESP is not intended to become a replacement of ESP in RFC 4303. Instead, a minimal implementation is expected to be optimized for constrained environments while remaining interoperable with implementations of ESP. In addition, this document provides some considerations for implementing minimal ESP in a constrained environment, such as limiting the number of flash writes, handling frequent wakeup and sleep states, limiting wakeup time, and reducing the use of random generation.
This document does not update or modify RFC 4303. It provides a compact description of how to implement the minimal version of that protocol. RFC 4303 remains the authoritative description. |
|
| |
| RFC 9334 | Remote ATtestation procedureS (RATS) Architecture |
| |
| Authors: | H. Birkholz, D. Thaler, M. Richardson, N. Smith, W. Pan. |
| Date: | January 2023 |
| Formats: | txt json pdf html xml |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9334 |
|
In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims.It provides a model that is neutral toward processor architectures, the content of Claims, and protocols. |
|
| |
| RFC 9337 | Generating Password-Based Keys Using the GOST Algorithms |
| |
|
|
This document specifies how to use "PKCS #5: Password-BasedCryptography Specification Version 2.1" (RFC 8018) to generate a symmetric key from a password in conjunction with the Russian national standard GOST algorithms.
PKCS #5 applies a Pseudorandom Function (PRF) -- a cryptographic hash, cipher, or Hash-Based Message Authentication Code (HMAC) -- to the input password along with a salt value and repeats the process many times to produce a derived key.
This specification has been developed outside the IETF. The purpose of publication being to facilitate interoperable implementations that wish to support the GOST algorithms. This document does not implyIETF endorsement of the cryptographic algorithms used here. |
|
| |
| RFC 9340 | Architectural Principles for a Quantum Internet |
| |
| Authors: | W. Kozlowski, S. Wehner, R. Van Meter, B. Rijsman, A. S. Cacciapuoti, M. Caleffi, S. Nagayama. |
| Date: | March 2023 |
| Formats: | txt html json pdf xml |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9340 |
|
The vision of a quantum internet is to enhance existing Internet technology by enabling quantum communication between any two points on Earth. To achieve this goal, a quantum network stack should be built from the ground up to account for the fundamentally new properties of quantum entanglement. The first quantum entanglement networks have been realised, but there is no practical proposal for how to organise, utilise, and manage such networks. In this document, we attempt to lay down the framework and introduce some basic architectural principles for a quantum internet. This is intended for general guidance and general interest. It is also intended to provide a foundation for discussion between physicists and network specialists. This document is a product of the QuantumInternet Research Group (QIRG). |
|
| |
| RFC 9361 | ICANN Trademark Clearinghouse (TMCH) Functional Specifications |
| |
|
|
This document describes the requirements, the architecture, and the interfaces between the ICANN Trademark Clearinghouse (TMCH) andDomain Name Registries, as well as between the ICANN TMCH and DomainName Registrars for the provisioning and management of domain names during Sunrise and Trademark Claims Periods. |
|
| |
| RFC 9365 | IPv6 Wireless Access in Vehicular Environments (IPWAVE): Problem Statement and Use Cases |
| |
|
|
This document discusses the problem statement and use cases ofIPv6-based vehicular networking for Intelligent TransportationSystems (ITS). The main scenarios of vehicular communications are vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), and vehicle-to-everything (V2X) communications. First, this document explains use cases using V2V, V2I, and V2X networking. Next, forIPv6-based vehicular networks, it makes a gap analysis of currentIPv6 protocols (e.g., IPv6 Neighbor Discovery, mobility management, as well as security and privacy). |
|
| |
| RFC 9367 | GOST Cipher Suites for Transport Layer Security (TLS) Protocol Version 1.3 |
| |
| Authors: | S. Smyshlyaev, Ed., E. Alekseev, E. Griboedova, A. Babueva, L. Nikiforova. |
| Date: | February 2023 |
| Formats: | txt pdf xml json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9367 |
|
The purpose of this document is to make the Russian cryptographic standards available to the Internet community for their implementation in the Transport Layer Security (TLS) Protocol Version1.3.
This document defines the cipher suites, signature schemes, and key exchange mechanisms for using Russian cryptographic standards, calledGOST algorithms, with TLS Version 1.3. Additionally, this document specifies a profile of TLS 1.3 with GOST algorithms to facilitate interoperable implementations. The IETF has not endorsed the cipher suites, signature schemes, or key exchange mechanisms described in this document. |
|
| |
| RFC 9371 | Registration Procedures for Private Enterprise Numbers (PENs) |
| |
|
|
This document describes how Private Enterprise Numbers (PENs) are registered by IANA. It shows how to request a new PEN and how to modify a current PEN. It also gives a brief overview of PEN uses. |
|
| |
| RFC 9372 | L-Band Digital Aeronautical Communications System (LDACS) |
| |
| Authors: | N. Mäurer, Ed., T. Gräupl, Ed., C. Schmitt, Ed.. |
| Date: | March 2023 |
| Formats: | txt json pdf html xml |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9372 |
|
This document gives an overview of the L-band Digital AeronauticalCommunications System (LDACS) architecture, which provides a secure, scalable, and spectrum-efficient terrestrial data link for civil aviation. LDACS is a scheduled and reliable multi-application cellular broadband system with support for IPv6. It is part of a larger shift of flight guidance communication moving to IP-based communication. High reliability and availability of IP connectivity over LDACS, as well as security, are therefore essential. The intent of this document is to introduce LDACS to the IETF community, raise awareness on related activities inside and outside of the IETF, and to seek expertise in shaping the shift of aeronautics to IP. |
|
| |
| RFC 9376 | Applicability of GMPLS for beyond 100 Gbit/s Optical Transport Network |
| |
| Authors: | Q. Wang, Ed., R. Valiveti, Ed., H. Zheng, Ed., H. van Helvoort, S. Belotti. |
| Date: | March 2023 |
| Formats: | txt json xml pdf html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9376 |
|
This document examines the applicability of using existing GMPLS routing and signaling mechanisms to set up Optical Data Unit-k (ODUk)Label Switched Paths (LSPs) over Optical Data Unit-Cn (ODUCn) links as defined in the 2020 version of ITU-T Recommendation G.709. |
|
| |
| RFC 9378 | In Situ Operations, Administration, and Maintenance (IOAM) Deployment |
| |
| Authors: | F. Brockners, Ed., S. Bhandari, Ed., D. Bernier, T. Mizrahi, Ed.. |
| Date: | April 2023 |
| Formats: | txt xml html pdf json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9378 |
|
In situ Operations, Administration, and Maintenance (IOAM) collects operational and telemetry information in the packet while the packet traverses a path between two points in the network. This document provides a framework for IOAM deployment and provides IOAM deployment considerations and guidance. |
|
| |
| RFC 9380 | Hashing to Elliptic Curves |
| |
| Authors: | A. Faz-Hernandez, S. Scott, N. Sullivan, R. S. Wahby, C. A. Wood. |
| Date: | August 2023 |
| Formats: | txt html json xml pdf |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9380 |
|
This document specifies a number of algorithms for encoding or hashing an arbitrary string to a point on an elliptic curve. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. |
|
| |
| RFC 9381 | Verifiable Random Functions (VRFs) |
| |
| Authors: | S. Goldberg, L. Reyzin, D. Papadopoulos, J. Včelák. |
| Date: | August 2023 |
| Formats: | txt html xml pdf json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9381 |
|
A Verifiable Random Function (VRF) is the public key version of a keyed cryptographic hash. Only the holder of the secret key can compute the hash, but anyone with the public key can verify the correctness of the hash. VRFs are useful for preventing enumeration of hash-based data structures. This document specifies VRF constructions based on RSA and elliptic curves that are secure in the cryptographic random oracle model.
This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. |
|
| |
| RFC 9382 | SPAKE2, a Password-Authenticated Key Exchange |
| |
|
|
This document describes SPAKE2, which is a protocol for two parties that share a password to derive a strong shared key without disclosing the password. This method is compatible with any group, is computationally efficient, and has a security proof. This document predated the Crypto Forum Research Group (CFRG) password- authenticated key exchange (PAKE) competition, and it was not selected; however, given existing use of variants in Kerberos and other applications, it was felt that publication was beneficial.Applications that need a symmetric PAKE, but are unable to hash onto an elliptic curve at execution time, can use SPAKE2. This document is a product of the Crypto Forum Research Group in the InternetResearch Task Force (IRTF). |
|
| |
| RFC 9383 | SPAKE2+, an Augmented Password-Authenticated Key Exchange (PAKE) Protocol |
| |
|
|
This document describes SPAKE2+, a Password-Authenticated KeyExchange (PAKE) protocol run between two parties for deriving a strong shared key with no risk of disclosing the password. SPAKE2+ is an augmented PAKE protocol, as only one party has knowledge of the password. This method is simple to implement, compatible with any prime-order group, and computationally efficient.
This document was produced outside of the IETF and IRTF and represents the opinions of the authors. Publication of this document as an RFC in the Independent Submissions Stream does not imply endorsement of SPAKE2+ by the IETF or IRTF. |
|
| |
| RFC 9385 | 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 implyIETF endorsement of the cryptographic algorithms used in this document. |
|
| |
| RFC 9386 | IPv6 Deployment Status |
| |
| Authors: | G. Fioccola, P. Volpato, J. Palet Martinez, G. Mishra, C. Xie. |
| Date: | April 2023 |
| Formats: | txt json xml pdf html |
| Obsoletes: | RFC 6036 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9386 |
|
This document provides an overview of the status of IPv6 deployment in 2022. Specifically, it looks at the degree of adoption of IPv6 in the industry, analyzes the remaining challenges, and proposes further investigations in areas where the industry has not yet taken a clear and unified approach in the transition to IPv6. It obsoletes RFC6036. |
|
| |
| RFC 9387 | Use Cases for DDoS Open Threat Signaling (DOTS) Telemetry |
| |
|
|
DDoS Open Threat Signaling (DOTS) telemetry enriches the base DOTS protocols to assist the mitigator in using efficient DDoS attack mitigation techniques in a network. This document presents sample use cases for DOTS telemetry. It discusses what components are deployed in the network, how they cooperate, and what information is exchanged to effectively use these techniques. |
|
| |
| RFC 9392 | Sending RTP Control Protocol (RTCP) Feedback for Congestion Control in Interactive Multimedia Conferences |
| |
|
|
This memo discusses the rate at which congestion control feedback can be sent using the RTP Control Protocol (RTCP) and the suitability ofRTCP for implementing congestion control for unicast multimedia applications. |
|
| |
| RFC 9397 | Trusted Execution Environment Provisioning (TEEP) Architecture |
| |
| Authors: | M. Pei, H. Tschofenig, D. Thaler, D. Wheeler. |
| Date: | July 2023 |
| Formats: | txt json pdf xml html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9397 |
|
A Trusted Execution Environment (TEE) is an environment that enforces the following: any code within the environment cannot be tampered with, and any data used by such code cannot be read or tampered with by any code outside the environment. This architecture document discusses the motivation for designing and standardizing a protocol for managing the lifecycle of Trusted Applications running inside such a TEE. |
|
| |
| RFC 9400 | Guidelines for the Organization of Fully Online Meetings |
| |
|
|
This document provides guidelines for the planning and organization of fully online meetings, regarding the number, length, and composition of sessions on the meeting agenda. These guidelines are based on the experience gained by holding online meetings during theCOVID-19 pandemic in 2020 and 2021. |
|
| |
| RFC 9401 | The Addition of the Death (DTH) Flag to TCP |
| |
|
|
This memo specifies the incorporation of Death (DTH) flag to TCP, including DTH's use of one bit in the TCP header. The flag is designed to make TCP session narratives smooth and attractive. |
|
| |
| RFC 9402 | Concat Notation |
| |
| Authors: | M. Basaglia, J. Bernards, J. Maas. |
| Date: | 1 April 2023 |
| Formats: | txt json pdf html xml |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9402 |
|
This document defines the Concat notation: a text-based language used to describe pictures and videos whose subject includes cats, containers, and their interactions. |
|
| |
| RFC 9405 | AI Sarcasm Detection: Insult Your AI without Offending It |
| |
| Authors: | C. GPT, R. L. Barnes, Ed.. |
| Date: | 1 April 2023 |
| Formats: | txt html pdf xml json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9405 |
|
This RFC proposes a framework for detecting sarcasm in AI systems and provides guidelines for using sarcasm without causing offense. By training AI systems to identify linguistic patterns that indicate sarcasm, we can improve their understanding of human communication.The guidelines offer a lighthearted approach to using sarcasm in a way that is both effective and respectful, without crossing the line into offensive language. |
|
| |
| RFC 9409 | The 'sip-trunking-capability' Link Relation Type |
| |
| Authors: | K. Inamdar, S. Narayanan, D. Engi, G. Salgueiro. |
| Date: | July 2023 |
| Formats: | txt xml html pdf json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9409 |
|
This Informational document defines the 'sip-trunking-capability' link relation type that may be used by an enterprise telephonySession Initiation Protocol (SIP) network to retrieve a SIP trunking capability set document, which contains the capabilities and configuration requirements of an Internet Telephony Service Provider(ITSP). These technical requirements allow for seamless peering between SIP-based enterprise telephony networks and the ITSP. |
|
| |
| RFC 9411 | Benchmarking Methodology for Network Security Device Performance |
| |
|
|
This document provides benchmarking terminology and methodology for next-generation network security devices, including next-generation firewalls (NGFWs) and next-generation intrusion prevention systems(NGIPSs). The main areas covered in this document are test terminology, test configuration parameters, and benchmarking methodology for NGFWs and NGIPSs. (It is assumed that readers have a working knowledge of these devices and the security functionality they contain.) This document aims to improve the applicability, reproducibility, and transparency of benchmarks and to align the test methodology with today's increasingly complex layer 7 security- centric network application use cases. As a result, this document makes RFC 3511 obsolete. |
|
| |
| RFC 9413 | 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. |
|
| |
| RFC 9414 | 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 AssessmentsResearch Group (PEARG) in the IRTF. |
|
| |
| RFC 9415 | 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. |
|
| |
| RFC 9417 | Service Assurance for Intent-Based Networking Architecture |
| |
| Authors: | B. Claise, J. Quilbeuf, D. Lopez, D. Voyer, T. Arumugam. |
| Date: | July 2023 |
| Formats: | txt json pdf xml html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9417 |
|
This document describes an architecture that provides some assurance that service instances are running as expected. As services rely upon multiple subservices provided by a variety of elements, including the underlying network devices and functions, getting the assurance of a healthy service is only possible with a holistic view of all involved elements. This architecture not only helps to correlate the service degradation with symptoms of a specific network component but, it also lists the services impacted by the failure or degradation of a specific network component. |
|
| |
| RFC 9419 | Considerations on Application - Network Collaboration Using Path Signals |
| |
| Authors: | J. Arkko, T. Hardie, T. Pauly, M. Kühlewind. |
| Date: | July 2023 |
| Formats: | txt html pdf xml json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9419 |
|
This document discusses principles for designing mechanisms that use or provide path signals and calls for standards action in specific valuable cases. RFC 8558 describes path signals as messages to or from on-path elements and points out that visible information will be used whether or not it is intended as a signal. The principles in this document are intended as guidance for the design of explicit path signals, which are encouraged to be authenticated and include a minimal set of parties to minimize information sharing. These principles can be achieved through mechanisms like encryption of information and establishing trust relationships between entities on a path. |
|
| |
| RFC 9423 | Constrained RESTful Environments (CoRE) Target Attributes Registry |
| |
|
|
The Constrained RESTful Environments (CoRE) specifications apply web technologies to constrained environments. One such important technology is Web Linking (RFC 8288), which CoRE specifications use as the basis for a number of discovery protocols, such as the LinkFormat (RFC 6690) in the Constrained Application Protocol's (CoAP's) resource discovery process (Section 7.2 of RFC 7252) and the ResourceDirectory (RD) (RFC 9176).
Web Links can have target attributes, the names of which are not generally coordinated by the Web Linking specification (Section 2.2 of RFC 8288). This document introduces an IANA registry for coordinating names of target attributes when used in CoRE. It updates the "RD Parameters" IANA registry created by RFC 9176 to coordinate with this registry. |
|
| |
| RFC 9424 | Indicators of Compromise (IoCs) and Their Role in Attack Defence |
| |
| Authors: | K. Paine, O. Whitehouse, J. Sellwood, A. Shaw. |
| Date: | August 2023 |
| Formats: | txt pdf html xml json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9424 |
|
Cyber defenders frequently rely on Indicators of Compromise (IoCs) to identify, trace, and block malicious activity in networks or on endpoints. This document reviews the fundamentals, opportunities, operational limitations, and recommendations for IoC use. It highlights the need for IoCs to be detectable in implementations ofInternet protocols, tools, and technologies -- both for the IoCs' initial discovery and their use in detection -- and provides a foundation for approaches to operational challenges in network security. |
|
| |
| RFC 9426 | BATched Sparse (BATS) Coding Scheme for Multi-hop Data Transport |
| |
| Authors: | S. Yang, X. Huang, R. Yeung, J. Zao. |
| Date: | July 2023 |
| Formats: | txt json xml pdf html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9426 |
|
In general, linear network coding can improve the network communication performance in terms of throughput, latency, and reliability. BATched Sparse (BATS) code is a class of efficient linear network coding scheme with a matrix generalization of fountain codes as the outer code and batch-based linear network coding as the inner code. This document describes a baseline BATS coding scheme for communication through multi-hop networks and discusses the related research issues towards a more sophisticated BATS coding scheme. This document is a product of the Coding for EfficientNetwork Communications Research Group (NWCRG). |
|
| |
| RFC 9433 | Segment Routing over IPv6 for the Mobile User Plane |
| |
| Authors: | S. Matsushima, Ed., C. Filsfils, M. Kohno, P. Camarillo, Ed., D. Voyer. |
| Date: | July 2023 |
| Formats: | txt json xml pdf html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9433 |
|
This document discusses the applicability of Segment Routing overIPv6 (SRv6) to the user plane of mobile networks. The network programming nature of SRv6 accomplishes mobile user-plane functions in a simple manner. The statelessness of SRv6 and its ability to control both service layer path and underlying transport can be beneficial to the mobile user plane, providing flexibility, end-to- end network slicing, and Service Level Agreement (SLA) control for various applications.
This document discusses how SRv6 could be used as the user plane of mobile networks. This document also specifies the SRv6 EndpointBehaviors required for mobility use cases. |
|
| |
| RFC 9434 | Drone Remote Identification Protocol (DRIP) Architecture |
| |
| Authors: | S. Card, A. Wiethuechter, R. Moskowitz, S. Zhao, Ed., A. Gurtov. |
| Date: | July 2023 |
| Formats: | txt html xml pdf json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9434 |
|
This document describes an architecture for protocols and services to support Unmanned Aircraft System Remote Identification and tracking(UAS RID), plus UAS-RID-related communications. This architecture adheres to the requirements listed in the Drone Remote IdentificationProtocol (DRIP) Requirements document (RFC 9153). |
|
| |
| RFC 9435 | Considerations for Assigning a New Recommended Differentiated Services Code Point (DSCP) |
| |
| Authors: | A. Custura, G. Fairhurst, R. Secchi. |
| Date: | July 2023 |
| Formats: | txt xml pdf html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9435 |
|
This document discusses considerations for assigning a new recommended Differentiated Services Code Point (DSCP) for a standardPer-Hop Behavior (PHB). It considers the common observed re-marking behaviors that the Diffserv field might be subjected to along anInternet path. It also notes some implications of using a specificDSCP. |
|
| |
| RFC 9440 | Client-Cert HTTP Header Field |
| |
|
|
This document describes HTTP extension header fields that allow a TLS terminating reverse proxy (TTRP) to convey the client certificate information of a mutually authenticated TLS connection to the origin server in a common and predictable manner. |
|
| |
| RFC 9446 | Reflections on Ten Years Past the Snowden Revelations |
| |
| Authors: | S. Farrell, F. Badii, B. Schneier, S. M. Bellovin. |
| Date: | July 2023 |
| Formats: | txt html xml pdf json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9446 |
|
This memo contains the thoughts and recountings of events that transpired during and after the release of information about theUnited States National Security Agency (NSA) by Edward Snowden in2013. There are four perspectives: that of someone who was involved with sifting through the information to responsibly inform the public, that of a security area director of the IETF, that of a human rights expert, and that of a computer science and affiliate law professor. The purpose of this memo is to provide some historical perspective, while at the same time offering a view as to what security and privacy challenges the technical community should consider. These essays do not represent a consensus view, but that of the individual authors. |
|
| |
| RFC 9450 | Reliable and Available Wireless (RAW) Use Cases |
| |
| Authors: | CJ. Bernardos, Ed., G. Papadopoulos, P. Thubert, F. Theoleyre. |
| Date: | August 2023 |
| Formats: | txt json pdf xml html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9450 |
|
The wireless medium presents significant specific challenges to achieve properties similar to those of wired deterministic networks.At the same time, a number of use cases cannot be solved with wires and justify the extra effort of going wireless. This document presents wireless use cases (such as aeronautical communications, amusement parks, industrial applications, pro audio and video, gaming, Unmanned Aerial Vehicle (UAV) and vehicle-to-vehicle (V2V) control, edge robotics, and emergency vehicles), demanding reliable and available behavior. |
|
| |
| RFC 9453 | Applicability and Use Cases for IPv6 over Networks of Resource-constrained Nodes (6lo) |
| |
| Authors: | Y. Hong, C. Gomez, Y. Choi, A. Sangi, S. Chakrabarti. |
| Date: | September 2023 |
| Formats: | txt html json xml pdf |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9453 |
|
This document describes the applicability of IPv6 over constrained- node networks (6lo) and provides practical deployment examples. In addition to IEEE Std 802.15.4, various link-layer technologies are used as examples, such as ITU-T G.9959 (Z-Wave), Bluetooth Low Energy(Bluetooth LE), Digital Enhanced Cordless Telecommunications - UltraLow Energy (DECT-ULE), Master-Slave/Token Passing (MS/TP), Near FieldCommunication (NFC), and Power Line Communication (PLC). This document targets an audience who would like to understand and evaluate running end-to-end IPv6 over the constrained-node networks for local or Internet connectivity. |
|
| |
| RFC 9469 | Applicability of Ethernet Virtual Private Network (EVPN) to Network Virtualization over Layer 3 (NVO3) Networks |
| |
| Authors: | J. Rabadan, Ed., M. Bocci, S. Boutros, A. Sajassi. |
| Date: | September 2023 |
| Formats: | txt json xml html pdf |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9469 |
|
An Ethernet Virtual Private Network (EVPN) provides a unified control plane that solves the issues of Network Virtualization Edge (NVE) auto-discovery, tenant Media Access Control (MAC) / IP dissemination, and advanced features in a scablable way as required by NetworkVirtualization over Layer 3 (NVO3) networks. EVPN is a scalable solution for NVO3 networks and keeps the independence of the underlayIP Fabric, i.e., there is no need to enable Protocol IndependentMulticast (PIM) in the underlay network and maintain multicast states for tenant Broadcast Domains. This document describes the use ofEVPN for NVO3 networks and discusses its applicability to basic Layer2 and Layer 3 connectivity requirements and to advanced features such as MAC Mobility, MAC Protection and Loop Protection, multihoming,Data Center Interconnect (DCI), and much more. No new EVPN procedures are introduced. |
|
| |
| RFC 9473 | A Vocabulary of Path Properties |
| |
| Authors: | R. Enghardt, C. Krähenbühl. |
| Date: | September 2023 |
| Formats: | txt html xml pdf json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9473 |
|
Path properties express information about paths across a network and the services provided via such paths. In a path-aware network, path properties may be fully or partially available to entities such as endpoints. This document defines and categorizes path properties.Furthermore, the document identifies several path properties that might be useful to endpoints or other entities, e.g., for selecting between paths or for invoking some of the provided services. This document is a product of the Path Aware Networking Research Group(PANRG). |
|
| |
| RFC 9474 | RSA Blind Signatures |
| |
| Authors: | F. Denis, F. Jacobs, C. A. Wood. |
| Date: | October 2023 |
| Formats: | txt xml pdf json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9474 |
|
This document specifies an RSA-based blind signature protocol. RSA blind signatures were first introduced by Chaum for untraceable payments. A signature that is output from this protocol can be verified as an RSA-PSS signature.
This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. |
|
| |
| RFC 9490 | Report from the IAB Workshop on Management Techniques in Encrypted Networks (M-TEN) |
| |
| Authors: | M. Knodel, W. Hardaker, T. Pauly. |
| Date: | January 2024 |
| Formats: | txt json xml pdf html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9490 |
|
The "Management Techniques in Encrypted Networks (M-TEN)" workshop was convened by the Internet Architecture Board (IAB) from 17 October2022 to 19 October 2022 as a three-day online meeting. The workshop was organized in three parts to discuss ways to improve network management techniques in support of even broader adoption of encryption on the Internet. This report summarizes the workshop's discussion and identifies topics that warrant future work and consideration.
Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the expressed during the workshop by participants and do not necessarily reflect IAB views and positions. |
|
| |
| RFC 9496 | The ristretto255 and decaf448 Groups |
| |
| Authors: | H. de Valence, J. Grigg, M. Hamburg, I. Lovecruft, G. Tankersley, F. Valsorda. |
| Date: | December 2023 |
| Formats: | txt xml html pdf json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9496 |
|
This memo specifies two prime-order groups, ristretto255 and decaf448, suitable for safely implementing higher-level and complex cryptographic protocols. The ristretto255 group can be implemented using Curve25519, allowing existing Curve25519 implementations to be reused and extended to provide a prime-order group. Likewise, the decaf448 group can be implemented using edwards448.
This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. |
|
| |
| RFC 9497 | Oblivious Pseudorandom Functions (OPRFs) Using Prime-Order Groups |
| |
| Authors: | A. Davidson, A. Faz-Hernandez, N. Sullivan, C. A. Wood. |
| Date: | December 2023 |
| Formats: | txt xml html pdf json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9497 |
|
An Oblivious Pseudorandom Function (OPRF) is a two-party protocol between a client and a server for computing the output of aPseudorandom Function (PRF). The server provides the PRF private key, and the client provides the PRF input. At the end of the protocol, the client learns the PRF output without learning anything about the PRF private key, and the server learns neither the PRF input nor output. An OPRF can also satisfy a notion of'verifiability', called a VOPRF. A VOPRF ensures clients can verify that the server used a specific private key during the execution of the protocol. A VOPRF can also be partially oblivious, called aPOPRF. A POPRF allows clients and servers to provide public input to the PRF computation. This document specifies an OPRF, VOPRF, andPOPRF instantiated within standard prime-order groups, including elliptic curves. This document is a product of the Crypto ForumResearch Group (CFRG) in the IRTF. |
|
| |
| RFC 9498 | The GNU Name System |
| |
| Authors: | M. Schanzenbach, C. Grothoff, B. Fix. |
| Date: | November 2023 |
| Formats: | txt json xml pdf html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9498 |
|
This document provides the GNU Name System (GNS) technical specification. GNS is a decentralized and censorship-resistant domain name resolution protocol that provides a privacy-enhancing alternative to the Domain Name System (DNS) protocols.
This document defines the normative wire format of resource records, resolution processes, cryptographic routines, and security and privacy considerations for use by implementers.
This specification was developed outside the IETF and does not haveIETF consensus. It is published here to inform readers about the function of GNS, guide future GNS implementations, and ensure interoperability among implementations (for example, pre-existingGNUnet implementations). |
|
| |
| RFC 9500 | Standard Public Key Cryptography (PKC) Test Keys |
| |
|
|
This document provides a set of standard Public Key Cryptography(PKC) test keys that may be used wherever pre-generated keys and associated operations like digital signatures are required. Like theEuropean Institute for Computer Antivirus Research (EICAR) virus test and the Generic Test for Unsolicited Bulk Email (GTUBE) spam test files, these publicly known test keys can be detected and recognised by applications consuming them as being purely for testing purposes without assigning any security properties to them. |
|
| |
| RFC 9505 | A Survey of Worldwide Censorship Techniques |
| |
| Authors: | J. L. Hall, M. D. Aaron, A. Andersdotter, B. Jones, N. Feamster, M. Knodel. |
| Date: | November 2023 |
| Formats: | txt json xml pdf html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9505 |
|
This document describes technical mechanisms employed in network censorship that regimes around the world use for blocking or impairing Internet traffic. It aims to make designers, implementers, and users of Internet protocols aware of the properties exploited and mechanisms used for censoring end-user access to information. This document makes no suggestions on individual protocol considerations, and is purely informational, intended as a reference. This document is a product of the Privacy Enhancement and Assessment Research Group(PEARG) in the IRTF. |
|
| |
| RFC 9506 | Explicit Host-to-Network Flow Measurements Techniques |
| |
| Authors: | M. Cociglio, A. Ferrieux, G. Fioccola, I. Lubashev, F. Bulgarella, M. Nilo, I. Hamchaoui, R. Sisto. |
| Date: | October 2023 |
| Formats: | txt html pdf xml json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9506 |
|
This document describes protocol-independent methods called ExplicitHost-to-Network Flow Measurement Techniques that can be applicable to transport-layer protocols between the client and server. These methods employ just a few marking bits inside the header of each packet for performance measurements and require the client and server to collaborate. Both endpoints cooperate by marking packets and, possibly, mirroring the markings on the round-trip connection. The techniques are especially valuable when applied to protocols that encrypt transport headers since they enable loss and delay measurements by passive, on-path network devices. This document describes several methods that can be used separately or jointly depending of the availability of marking bits, desired measurements, and properties of the protocol to which the methods are applied. |
|
| |
| RFC 9511 | Attribution of Internet Probes |
| |
| Authors: | É. Vyncke, B. Donnet, J. Iurman. |
| Date: | November 2023 |
| Formats: | txt xml json pdf html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9511 |
|
Active measurements over the public Internet can target either collaborating parties or non-collaborating ones. Sometimes these measurements, also called "probes", are viewed as unwelcome or aggressive.
This document suggests some simple techniques for a source to identify its probes. This allows any party or organization to understand what an unsolicited probe packet is, what its purpose is, and, most importantly, who to contact. The technique relies on offline analysis of the probe; therefore, it does not require any change in the data or control plane. It has been designed mainly for layer 3 measurements. |
|
| |
| RFC 9512 | YAML Media Type |
| |
| Authors: | R. Polli, E. Wilde, E. Aro. |
| Date: | February 2024 |
| Formats: | txt html json pdf xml |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9512 |
|
This document registers the application/yaml media type and the +yaml structured syntax suffix with IANA. Both identify document components that are serialized according to the YAML specification. |
|
| |
| RFC 9517 | A URN Namespace for the Data Documentation Initiative (DDI) |
| |
|
|
This document describes the Namespace Identifier (NID) "ddi" forUniform Resource Names (URNs) used to identify resources that conform to the standards published by the Data Documentation Initiative (DDI)Alliance.
The DDI Alliance is not affiliated with the Internet Engineering TaskForce (IETF) or Internet Society (ISOC). This Independent Submission is not a standard nor does it have IETF community consensus. |
|
| |
| RFC 9518 | Centralization, Decentralization, and Internet Standards |
| |
|
|
This document discusses aspects of centralization that relate toInternet standards efforts. It argues that, while standards bodies have a limited ability to prevent many forms of centralization, they can still make contributions that assist in the decentralization of the Internet. |
|
| |
| RFC 9522 | Overview and Principles of Internet Traffic Engineering |
| |
|
|
This document describes the principles of traffic engineering (TE) in the Internet. The document is intended to promote better understanding of the issues surrounding traffic engineering in IP networks and the networks that support IP networking and to provide a common basis for the development of traffic-engineering capabilities for the Internet. The principles, architectures, and methodologies for performance evaluation and performance optimization of operational networks are also discussed.
This work was first published as RFC 3272 in May 2002. This document obsoletes RFC 3272 by making a complete update to bring the text in line with best current practices for Internet traffic engineering and to include references to the latest relevant work in the IETF. |
|
| |
| RFC 9523 | A Secure Selection and Filtering Mechanism for the Network Time Protocol with Khronos |
| |
| Authors: | N. Rozen-Schiff, D. Dolev, T. Mizrahi, M. Schapira. |
| Date: | February 2024 |
| Formats: | txt xml pdf html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9523 |
|
The Network Time Protocol version 4 (NTPv4), as defined in RFC 5905, is the mechanism used by NTP clients to synchronize with NTP servers across the Internet. This document describes a companion application to the NTPv4 client, named "Khronos", that is used as a "watchdog" alongside NTPv4 and that provides improved security against time- shifting attacks. Khronos involves changes to the NTP client's system process only. Since it does not affect the wire protocol, theKhronos mechanism is applicable to current and future time protocols. |
|
| |
| RFC 9529 | Traces of Ephemeral Diffie-Hellman Over COSE (EDHOC) |
| |
| Authors: | G. Selander, J. Preuß Mattsson, M. Serafin, M. Tiloca, M. Vučinić. |
| Date: | March 2024 |
| Formats: | txt json html pdf xml |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9529 |
|
This document contains example traces of Ephemeral Diffie-HellmanOver COSE (EDHOC). |
|
| |
| RFC 9543 | A Framework for Network Slices in Networks Built from IETF Technologies |
| |
| Authors: | A. Farrel, Ed., J. Drake, Ed., R. Rokui, S. Homma, K. Makhijani, L. Contreras, J. Tantsura. |
| Date: | March 2024 |
| Formats: | txt json html xml pdf |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9543 |
|
This document describes network slicing in the context of networks built from IETF technologies. It defines the term "IETF NetworkSlice" to describe this type of network slice and establishes the general principles of network slicing in the IETF context.
The document discusses the general framework for requesting and operating IETF Network Slices, the characteristics of an IETF NetworkSlice, the necessary system components and interfaces, and the mapping of abstract requests to more specific technologies. The document also discusses related considerations with monitoring and security.
This document also provides definitions of related terms to enable consistent usage in other IETF documents that describe or use aspects of IETF Network Slices. |
|
| |
| RFC 9544 | Precision Availability Metrics (PAMs) for Services Governed by Service Level Objectives (SLOs) |
| |
| Authors: | G. Mirsky, J. Halpern, X. Min, A. Clemm, J. Strassner, J. François. |
| Date: | March 2024 |
| Formats: | txt html json xml pdf |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9544 |
|
This document defines a set of metrics for networking services with performance requirements expressed as Service Level Objectives(SLOs). These metrics, referred to as "Precision AvailabilityMetrics (PAMs)", are useful for defining and monitoring SLOs. For example, PAMs can be used by providers and/or customers of an RFC9543 Network Slice Service to assess whether the service is provided in compliance with its defined SLOs. |
|
| |
| RFC 9547 | Report from the IAB Workshop on Environmental Impact of Internet Applications and Systems, 2022 |
| |
| Authors: | J. Arkko, C. S. Perkins, S. Krishnan. |
| Date: | February 2024 |
| Formats: | txt pdf xml json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9547 |
|
Internet communications and applications have both environmental costs and benefits. The IAB ran an online workshop in December 2022 to explore and understand these impacts.
The role of the workshop was to discuss the impacts and the evolving industry needs, and to identify areas for improvements and future work. A key goal of the workshop was to call further attention to the topic and bring together a diverse stakeholder community to discuss these issues.
Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions. |
|
| |
| RFC 9548 | Generating Transport Key Containers (PFX) Using the GOST Algorithms |
| |
|
|
This document specifies how to use "PKCS #12: Personal InformationExchange Syntax v1.1" (RFC 7292) to transport key containers (PFX) for storing keys and certificates in conjunction with the Russian national standard GOST algorithms.
This specification has been developed outside the IETF. The purpose of publication is to facilitate interoperable implementations that wish to support the GOST algorithms. This document does not implyIETF endorsement of the cryptographic algorithms used here. |
|
| |
| RFC 9550 | Deterministic Networking (DetNet): Packet Ordering Function |
| |
| Authors: | B. Varga, Ed., J. Farkas, S. Kehrer, T. Heer. |
| Date: | March 2024 |
| Formats: | txt html xml pdf json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9550 |
|
The replication and elimination functions of the DeterministicNetworking (DetNet) architecture can result in out-of-order packets, which is not acceptable for some time-sensitive applications. ThePacket Ordering Function (POF) algorithms described in this document enable restoration of the correct packet order when the replication and elimination functions are used in DetNet networks. The POF only provides ordering within the latency bound of a DetNet flow; it does not provide any additional reliability. |
|
| |
| RFC 9551 | Framework of Operations, Administration, and Maintenance (OAM) for Deterministic Networking (DetNet) |
| |
| Authors: | G. Mirsky, F. Theoleyre, G. Papadopoulos, CJ. Bernardos, B. Varga, J. Farkas. |
| Date: | March 2024 |
| Formats: | txt xml pdf html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9551 |
|
Deterministic Networking (DetNet), as defined in RFC 8655, aims to provide bounded end-to-end latency on top of the network infrastructure, comprising both Layer 2 bridged and Layer 3 routed segments. This document's primary purpose is to detail the specific requirements of the Operations, Administration, and Maintenance (OAM) recommended to maintain a deterministic network. The document will be used in future work that defines the applicability of and extension of OAM protocols for a deterministic network. With the implementation of the OAM framework in DetNet, an operator will have a real-time view of the network infrastructure regarding the network's ability to respect the Service Level Objective (SLO), such as packet delay, delay variation, and packet-loss ratio, assigned to each DetNet flow. |
|
| |
| RFC 9556 | Internet of Things (IoT) Edge Challenges and Functions |
| |
| Authors: | J. Hong, Y-G. Hong, X. de Foy, M. Kovatsch, E. Schooler, D. Kutscher. |
| Date: | April 2024 |
| Formats: | txt xml json pdf html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9556 |
|
Many Internet of Things (IoT) applications have requirements that cannot be satisfied by centralized cloud-based systems (i.e., cloud computing). These include time sensitivity, data volume, connectivity cost, operation in the face of intermittent services, privacy, and security. As a result, IoT is driving the Internet toward edge computing. This document outlines the requirements of the emerging IoT edge and its challenges. It presents a general model and major components of the IoT edge to provide a common basis for future discussions in the Thing-to-Thing Research Group (T2TRG) and other IRTF and IETF groups. This document is a product of theIRTF T2TRG. |
|
| |
| RFC 9558 | Use of GOST 2012 Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC |
| |
| Authors: | B. Makarenko, V. Dolmatov, Ed.. |
| Date: | April 2024 |
| Formats: | txt html xml pdf json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9558 |
|
This document describes how to produce digital signatures and hash functions using the GOST R 34.10-2012 and GOST R 34.11-2012 algorithms for DNSKEY, RRSIG, and DS resource records, for use in theDomain Name System Security Extensions (DNSSEC). |
|
| |
| RFC 9563 | SM2 Digital Signature Algorithm for DNSSEC |
| |
| Authors: | C. Zhang, Y. Liu, F. Leng, Q. Zhao, Z. He. |
| Date: | December 2024 |
| Formats: | txt xml pdf json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9563 |
|
This document specifies the use of the SM2 digital signature algorithm and SM3 hash algorithm for DNS Security (DNSSEC).
This document is an Independent Submission to the RFC series and does not have consensus of the IETF community. |
|
| |
| RFC 9564 | Faster Than Light Speed Protocol (FLIP) |
| |
|
|
The recent advances in artificial intelligence (AI) such as large language models enable the design of the Faster than LIght speedProtocol (FLIP) for Internet. FLIP provides a way to avoid congestion, enhance security, and deliver faster packets on theInternet by using AI to predict future packets at the receiving peer before they arrive. This document describes the protocol, its various encapsulations, and some operational considerations. |
|
| |
| RFC 9566 | Deterministic Networking (DetNet) Packet Replication, Elimination, and Ordering Functions (PREOF) via MPLS over UDP/IP |
| |
| Authors: | B. Varga, J. Farkas, A. Malis. |
| Date: | April 2024 |
| Formats: | txt json pdf html xml |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9566 |
|
This document describes how the DetNet IP data plane can support thePacket Replication, Elimination, and Ordering Functions (PREOF) built on the existing MPLS PREOF solution defined for the DetNet MPLS data plane and the mechanisms defined by MPLS-over-UDP technology. |
|
| |
| RFC 9576 | The Privacy Pass Architecture |
| |
| Authors: | A. Davidson, J. Iyengar, C. A. Wood. |
| Date: | June 2024 |
| Formats: | txt json html xml pdf |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9576 |
|
This document specifies the Privacy Pass architecture and requirements for its constituent protocols used for authorization based on privacy-preserving authentication mechanisms. It describes the conceptual model of Privacy Pass and its protocols, its security and privacy goals, practical deployment models, and recommendations for each deployment model, to help ensure that the desired security and privacy goals are fulfilled. |
|
| |
| RFC 9579 | Use of Password-Based Message Authentication Code 1 (PBMAC1) in PKCS #12 Syntax |
| |
|
|
This document specifies additions and amendments to RFCs 7292 and8018. It defines a way to use the Password-Based MessageAuthentication Code 1 (PBMAC1), defined in RFC 8018, inside the PKCS#12 syntax. The purpose of this specification is to permit the use of more modern Password-Based Key Derivation Functions (PBKDFs) and allow for regulatory compliance. |
|
| |
| RFC 9583 | Application Scenarios for the Quantum Internet |
| |
| Authors: | C. Wang, A. Rahman, R. Li, M. Aelmans, K. Chakraborty. |
| Date: | June 2024 |
| Formats: | txt json html pdf xml |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9583 |
|
The Quantum Internet has the potential to improve application functionality by incorporating quantum information technology into the infrastructure of the overall Internet. This document provides an overview of some applications expected to be used on the QuantumInternet and categorizes them. Some general requirements for theQuantum Internet are also discussed. The intent of this document is to describe a framework for applications and to describe a few selected application scenarios for the Quantum Internet. This document is a product of the Quantum Internet Research Group (QIRG). |
|
| |
| RFC 9591 | The Flexible Round-Optimized Schnorr Threshold (FROST) Protocol for Two-Round Schnorr Signatures |
| |
| Authors: | D. Connolly, C. Komlo, I. Goldberg, C. A. Wood. |
| Date: | June 2024 |
| Formats: | txt pdf xml html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9591 |
|
This document specifies the Flexible Round-Optimized SchnorrThreshold (FROST) signing protocol. FROST signatures can be issued after a threshold number of entities cooperate to compute a signature, allowing for improved distribution of trust and redundancy with respect to a secret key. FROST depends only on a prime-order group and cryptographic hash function. This document specifies a number of ciphersuites to instantiate FROST using different prime- order groups and hash functions. This document is a product of theCrypto Forum Research Group (CFRG) in the IRTF. |
|
| |
| RFC 9592 | Retiring the Tao of the IETF |
| |
|
|
This document retires and obsoletes the Tao of the IETF as an IETF- maintained document. This document also obsoletes RFC 6722, which describes the publication process of the Tao. Furthermore, this document describes the rationale for the retirement of the Tao. For archival purposes, the last version of the Tao is included in the appendix. Information that new participants need to engage in the work of the IETF will continue to be provided through the IETF website in a more timely and accessible manner. This is the way. |
|
| |
| RFC 9602 | Segment Routing over IPv6 (SRv6) Segment Identifiers in the IPv6 Addressing Architecture |
| |
|
|
Segment Routing over IPv6 (SRv6) uses IPv6 as the underlying data plane. Thus, Segment Identifiers (SIDs) used by SRv6 can resembleIPv6 addresses and behave like them while exhibiting slightly different behaviors in some situations. This document explores the characteristics of SRv6 SIDs and focuses on the relationship of SRv6SIDs to the IPv6 Addressing Architecture. This document allocates and makes a dedicated prefix available for SRv6 SIDs. |
|
| |
| RFC 9613 | Requirements for Solutions that Support MPLS Network Actions (MNAs) |
| |
| Authors: | M. Bocci, Ed., S. Bryant, J. Drake. |
| Date: | August 2024 |
| Formats: | txt json xml pdf html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9613 |
|
This document specifies requirements for the development of MPLSNetwork Actions (MNAs) that affect the forwarding or other processing of MPLS packets. These requirements are informed by a number of proposals for additions to the MPLS information in the labeled packet to allow such actions to be performed, either by a transit or terminating Label Switching Router (i.e., the Label Edge Router -LER). |
|
| |
| RFC 9614 | Partitioning as an Architecture for Privacy |
| |
| Authors: | M. Kühlewind, T. Pauly, C. A. Wood. |
| Date: | July 2024 |
| Formats: | txt html json xml pdf |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9614 |
|
This document describes the principle of privacy partitioning, which selectively spreads data and communication across multiple parties as a means to improve privacy by separating user identity from user data. This document describes emerging patterns in protocols to partition what data and metadata is revealed through protocol interactions, provides common terminology, and discusses how to analyze such models. |
|
| |
| RFC 9620 | Guidelines for Human Rights Protocol and Architecture Considerations |
| |
|
|
This document sets guidelines for human rights considerations for developers working on network protocols and architectures, similar to the work done on the guidelines for privacy considerations (RFC6973). This is an updated version of the guidelines for human rights considerations in RFC 8280.
This document is a product of the Human Right Protocol Considerations(HRPC) Research Group in the IRTF. |
|
| |
| RFC 9634 | Operations, Administration, and Maintenance (OAM) for Deterministic Networking (DetNet) with the IP Data Plane |
| |
| Authors: | G. Mirsky, M. Chen, D. Black. |
| Date: | October 2024 |
| Formats: | txt xml html pdf json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9634 |
|
This document discusses the use of existing IP Operations,Administration, and Maintenance protocols and mechanisms inDeterministic Networking networks that use the IP data plane. |
|
| |
| RFC 9637 | Expanding the IPv6 Documentation Space |
| |
|
|
The document describes the reservation of an additional IPv6 address prefix for use in documentation. This update to RFC 3849 expands on the existing 2001:db8::/32 address block with the reservation of an additional, larger prefix. The addition of a /20 prefix allows documented examples to more closely reflect a broader range of realistic, current deployment scenarios and more closely aligns with contemporary allocation models for large networks. |
|
| |
| RFC 9638 | Network Virtualization over Layer 3 (NVO3) Encapsulation Considerations |
| |
| Authors: | S. Boutros, D. Eastlake 3rd, Ed.. |
| Date: | September 2024 |
| Formats: | txt html pdf xml json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9638 |
|
The IETF Network Virtualization Overlays (NVO3) Working Group developed considerations for a common encapsulation that addresses various network virtualization overlay technical concerns. This document provides a record, for the benefit of the IETF community, of the considerations arrived at by the NVO3 Working Group starting from the output of the NVO3 encapsulation Design Team. These considerations may be helpful with future deliberations by working groups over the choice of encapsulation formats.
There are implications of having different encapsulations in real environments consisting of both software and hardware implementations and within and spanning multiple data centers. For example,Operations, Administration, and Maintenance (OAM) functions such as path MTU discovery become challenging with multiple encapsulations along the data path.
Based on these considerations, the NVO3 Working Group determined thatGeneric Network Virtualization Encapsulation (Geneve) with a few modifications is the common encapsulation. This document provides more details, particularly in Section 7. |
|
| |
| RFC 9649 | WebP Image Format |
| |
| Authors: | J. Zern, P. Massimino, J. Alakuijala. |
| Date: | November 2024 |
| Formats: | txt xml json pdf html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9649 |
|
This document defines the WebP image format and registers a media type supporting its use. |
|
| |
| RFC 9657 | Time-Variant Routing (TVR) Use Cases |
| |
| Authors: | E. Birrane III, N. Kuhn, Y. Qu, R. Taylor, L. Zhang. |
| Date: | October 2024 |
| Formats: | txt pdf xml html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9657 |
|
This document introduces use cases where Time-Variant Routing (TVR) computations (i.e., routing computations that take into consideration time-based or scheduled changes to a network) could improve routing protocol convergence and/or network performance. |
|
| |
| RFC 9659 | Window Sizing for Zstandard Content Encoding |
| |
|
|
Deployments of Zstandard, or "zstd", can use different window sizes to limit memory usage during compression and decompression. Some browsers and user agents limit window sizes to mitigate memory usage concerns, thereby causing interoperability issues. This document updates the window size limit in RFC 8878 from a recommendation to a requirement in HTTP contexts. |
|
| |
| RFC 9663 | Using DHCPv6 Prefix Delegation (DHCPv6-PD) to Allocate Unique IPv6 Prefixes per Client in Large Broadcast Networks |
| |
| Authors: | L. Colitti, J. Linkova, Ed., X. Ma, Ed.. |
| Date: | October 2024 |
| Formats: | txt html pdf xml json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9663 |
|
This document discusses an IPv6 deployment scenario when individual nodes connected to large broadcast networks (such as enterprise networks or public Wi-Fi networks) are allocated unique prefixes viaDHCPv6 Prefix Delegation (DHCPv6-PD), as specified in RFC 8415. |
|
| |
| RFC 9675 | Delay-Tolerant Networking Management Architecture (DTNMA) |
| |
| Authors: | E. Birrane III, S. Heiner, E. Annis. |
| Date: | November 2024 |
| Formats: | txt json xml pdf html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9675 |
|
The Delay-Tolerant Networking (DTN) architecture describes a type of challenged network in which communications may be significantly affected by long signal propagation delays, frequent link disruptions, or both. The unique characteristics of this environment require a unique approach to network management that supports asynchronous transport, autonomous local control, and a small footprint (in both resources and dependencies) so as to deploy on constrained devices.
This document describes a DTN Management Architecture (DTNMA) suitable for managing devices in any challenged environment but, in particular, those communicating using the DTN Bundle Protocol (BP).Operating over BP requires an architecture that neither presumes synchronized transport behavior nor relies on query-response mechanisms. Implementations compliant with this DTNMA should expect to successfully operate in extremely challenging conditions, such as over unidirectional links and other places where BP is the preferred transport. |
|
| |
| RFC 9680 | Antitrust Guidelines for IETF Participants |
| |
| Authors: | J. Halpern, Ed., J. Daley. |
| Date: | October 2024 |
| Formats: | txt json pdf xml html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9680 |
|
This document provides education and guidance for IETF participants on compliance with antitrust laws and how to reduce antitrust risks in connection with IETF activities. |
|
| |
| RFC 9683 | Remote Integrity Verification of Network Devices Containing Trusted Platform Modules |
| |
| Authors: | G. C. Fedorkow, Ed., E. Voit, J. Fitzgerald-McKay. |
| Date: | December 2024 |
| Formats: | txt html json xml pdf |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9683 |
|
This document describes a workflow for remote attestation of the integrity of firmware and software installed on network devices that contain Trusted Platform Modules (TPMs), as defined by the TrustedComputing Group (TCG), or equivalent hardware implementations that include the protected capabilities, as provided by TPMs. |
|
| |
| RFC 9689 | Use Cases for a PCE as a Central Controller (PCECC) |
| |
| Authors: | Z. Li, D. Dhody, Q. Zhao, Z. Ke, B. Khasanov. |
| Date: | December 2024 |
| Formats: | txt pdf xml json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 9689 |
|
The PCE is a core component of a Software-Defined Networking (SDN) system. It can be used to compute optimal paths for network traffic and update existing paths to reflect changes in the network or traffic demands. The PCE was developed to derive Traffic Engineering(TE) paths in MPLS networks, which are supplied to the headend of the paths using the Path Computation Element Communication Protocol(PCEP).
SDN has much broader applicability than signalled MPLS TE networks, and the PCE may be used to determine paths in a range of use cases including static Label-Switched Paths (LSPs), Segment Routing (SR),Service Function Chaining (SFC), and most forms of a routed or switched network. Therefore, it is reasonable to consider PCEP as a control protocol for use in these environments to allow the PCE to be fully enabled as a central controller.
A PCE as a Central Controller (PCECC) can simplify the processing of a distributed control plane by blending it with elements of SDN without necessarily completely replacing it. This document describes general considerations for PCECC deployment and examines its applicability and benefits, as well as its challenges and limitations, through a number of use cases. PCEP extensions, which are required for the PCECC use cases, are covered in separate documents. |
|
