| |
| RFC 887 | Resource Location Protocol |
| |
| Authors: | M. Accetta. |
| Date: | December 1983 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 0887 |
|
This RFC specifies a draft standard for the ARPA Internet community. It describes a resource location protocol for use in the ARPA Internet. It is most useful on networks employing technologies which support some method of broadcast addressing, however it may also be used on other types of networks. For maximum benefit, all hosts which provide significant resources or services to other hosts on the Internet should implement this protocol. Hosts failing to implement the Resource Location Protocol risk being ignored by other hosts which are attempting to locate resources on the Internet. |
|
| |
| RFC 908 | Reliable Data Protocol |
| |
| Authors: | D. Velten, R.M. Hinden, J. Sax. |
| Date: | July 1984 |
| Formats: | txt html json |
| Updated by: | RFC 1151 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 0908 |
|
The Reliable Data Protocol (RDP) is designed to provide a reliable data transport service for packet-based applications. This RFC specifies a proposed protocol for the ARPA-Internet and DARPA research community, and requests discussion and suggestions for improvemts. |
|
| |
| RFC 909 | Loader Debugger Protocol |
| |
| Authors: | C. Welles, W. Milliken. |
| Date: | July 1984 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 0909 |
|
The Loader Debugger Protocol (LDP) is an application layer protocol for loading, dumping, and debugging target machines from hosts in a network environment. This RFC specifies a proposed protocol for the ARPA-Internet and DARPA research community, and requests discussion and suggestions for improvemts. |
|
| |
| RFC 938 | Internet Reliable Transaction Protocol functional and interface specification |
| |
| Authors: | T. Miller. |
| Date: | February 1985 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 0938 |
|
This RFC is being distributed to members of the DARPA research community in order to solicit their reactions to the proposals contained in it. While the issues discussed may not be directly relevant to the research problems of the DARPA community, they may be interesting to a number of researchers and implementors. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. |
|
| |
| RFC 998 | NETBLT: A bulk data transfer protocol |
| |
| Authors: | D.D. Clark, M.L. Lambert, L. Zhang. |
| Date: | March 1987 |
| Formats: | txt json html |
| Obsoletes: | RFC 0969 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 0998 |
|
This document is a description of, and a specification for, the NETBLT protocol. It is a revision of the specification published in RFC-969. NETBLT (NETwork BLock Transfer) is a transport level protocol intended for the rapid transfer of a large quantity of data between computers. It provides a transfer that is reliable and flow controlled, and is designed to provide maximum throughput over a wide variety of networks. Although NETBLT currently runs on top of the Internet Protocol (IP), it should be able to operate on top of any datagram protocol similar in function to IP. This document is published for discussion and comment, and does not constitute a standard. The proposal may change and certain parts of the protocol have not yet been specified; implementation of this document is therefore not advised. Obsoletes RFC-969. |
|
| |
| RFC 1004 | Distributed-protocol authentication scheme |
| |
| Authors: | D.L. Mills. |
| Date: | April 1987 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1004 |
|
The purpose of this RFC is to focus discussion on authentication problems in the Internet and possible methods of solution. The proposed solutions this document are not intended as standards for the Internet at this time. Rather, it is hoped that a general consensus will emerge as to the appropriate solution to authentication problems, leading eventually to the adoption of standards. This document suggests mediated access-control and authentication procedures suitable for those cases when an association is to be set up between users belonging to different trust environments. |
|
| |
| RFC 1045 | VMTP: Versatile Message Transaction Protocol: Protocol specification |
| |
| Authors: | D.R. Cheriton. |
| Date: | February 1988 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1045 |
|
This memo specifies the Versatile Message Transaction Protocol (VMTP) [Version 0.7 of 19-Feb-88], a transport protocol specifically designed to support the transaction model of communication, as exemplified by remote procedure call (RPC). The full function of VMTP, including support for security, real-time, asynchronous message exchanges, streaming, multicast and idempotency, provides a rich selection to the VMTP user level. Subsettability allows the VMTP module for particular clients and servers to be specialized and simplified to the services actually required. Examples of such simple clients and servers include PROM network bootload programs, network boot servers, data sensors and simple controllers, to mention but a few examples. This RFC describes a protocol proposed as a standard for the Internet community. |
|
| |
| RFC 1075 | Distance Vector Multicast Routing Protocol |
| |
| Authors: | D. Waitzman, C. Partridge, S.E. Deering. |
| Date: | November 1988 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1075 |
|
This RFC describes a distance-vector-style routing protocol for routing multicast datagrams through an internet. It is derived from the Routing Information Protocol (RIP), and implements multicasting as described in RFC-1054. This is an experimental protocol, and its implementation is not recommended at this time. |
|
| |
| RFC 1105 | Border Gateway Protocol (BGP) |
| |
|
|
This RFC outlines a specific approach for the exchange of network reachability information between Autonomous Systems. Updated by RFCs 1163 and 1164. [STANDARDS-TRACK] |
|
| |
| RFC 1138 | Mapping between X.400(1988) / ISO 10021 and RFC 822 |
| |
|
|
Ths RFC suggests an electronic mail protocol mapping for the Internet community and UK Academic Community, and requests discussion and suggestions for improvements. This memo does not specify an Internet standard. This memo updates RFCs 822, 987, and 1026. |
|
| |
| RFC 1143 | The Q Method of Implementing TELNET Option Negotiation |
| |
| Authors: | D.J. Bernstein. |
| Date: | February 1990 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1143 |
|
This is RFC discusses an implementation approach to option negotiation in the Telnet protocol (RFC 854). It does not propose any changes to the TELNET protocol. Rather, it discusses the implementation of the protocol of one feature, only. This is not a protocol specification. This is an experimental method of implementing a protocol. |
|
| |
| RFC 1148 | Mapping between X.400(1988) / ISO 10021 and RFC 822 |
| |
|
|
This RFC suggests an electronic mail protocol mapping for the Internet community and UK Academic Community, and requests discussion and suggestions for improvements. This memo does not specify an Internet standard. This edition includes material lost in editing. |
|
| |
| RFC 1149 | Standard for the transmission of IP datagrams on avian carriers |
| |
|
|
This memo describes an experimental method for the encapsulation of IP datagrams in avian carriers. This specification is primarily useful in Metropolitan Area Networks. This is an experimental, not recommended standard. |
|
| |
| RFC 1151 | Version 2 of the Reliable Data Protocol (RDP) |
| |
|
|
This RFC suggests several updates to the specification of the Reliable Data Protocol (RDP) in RFC-908 based on experience with the protocol. This revised version of the protocol is experimental. |
|
| |
| RFC 1153 | Digest message format |
| |
| Authors: | F.J. Wancho. |
| Date: | April 1990 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1153 |
|
This memo describes the de facto standard Digest Message Format. This is an elective experimental protocol. |
|
| |
| RFC 1154 | Encoding header field for internet messages |
| |
|
|
This RFC proposes an elective experimental Encoding header field to permit the mailing of multi-part, multi-structured messages. The use of Encoding updates RFC 1049 (Content-Type), and is a suggested update to RFCs 1113, 1114, and 1115 (Privacy Enhancement). |
|
| |
| RFC 1159 | Message Send Protocol |
| |
|
|
This RFC suggests an Experimental Protocol for the Internet community. Hosts on the Internet that choose to implement a Message Send Protocol may experiment with this protocol. |
|
| |
| RFC 1161 | SNMP over OSI |
| |
|
|
This memo defines an experimental means for running the Simple Network Management Protocol (SNMP) over OSI transports. This memo does not specify a standard for the Internet community, |
|
| |
| RFC 1162 | Connectionless Network Protocol (ISO 8473) and End System to Intermediate System (ISO 9542) Management Information Base |
| |
|
|
This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. This memo does not specify a standard for the Internet community. |
|
| |
| RFC 1165 | Network Time Protocol (NTP) over the OSI Remote Operations Service |
| |
| Authors: | J. Crowcroft, J.P. Onions. |
| Date: | June 1990 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1165 |
|
This memo suggests an Experimental Protocol for the OSI and Internet communities. Hosts in either community, and in particular those on both are encouraged to experiment with this mechanism. |
|
| |
| RFC 1176 | Interactive Mail Access Protocol: Version 2 |
| |
|
|
This RFC suggests a method for personal computers and workstations to dynamically access mail from a mailbox server ("repository"). It obosoletes RFC 1064. This RFC specifies an Experimental Protocol for the Internet community. Discussion and suggestions for improvement are requested. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. |
|
| |
| RFC 1183 | New DNS RR Definitions |
| |
|
|
This memo defines five new DNS types for experimental purposes. This RFC describes an Experimental Protocol for the Internet community, and requests discussion and suggestions for improvements. |
|
| |
| RFC 1185 | TCP Extension for High-Speed Paths |
| |
| Authors: | V. Jacobson, R.T. Braden, L. Zhang. |
| Date: | October 1990 |
| Formats: | txt html json |
| Obsoleted by: | RFC 1323 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1185 |
|
This memo describes an Experimental Protocol extension to TCP for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. |
|
| |
| RFC 1187 | Bulk Table Retrieval with the SNMP |
| |
| Authors: | M.T. Rose, K. McCloghrie, J.R. Davin. |
| Date: | October 1990 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1187 |
|
This memo reports an interesting family of algorithms for bulk table retrieval using the Simple Network Management Protocol (SNMP). This memo describes an Experimental Protocol for the Internet community, and requests discussion and suggestions for improvements. This memo does not specify a standard for the Internet community. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. |
|
| |
| RFC 1190 | Experimental Internet Stream Protocol: Version 2 (ST-II) |
| |
| Authors: | C. Topolcic. |
| Date: | October 1990 |
| Formats: | txt html json |
| Obsoletes: | IEN119 |
| Obsoleted by: | RFC 1819 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1190 |
|
This memo defines a revised version of the Internet Stream Protocol, originally defined in IEN-119 [8], based on results from experiments with the original version, and subsequent requests, discussion, and suggestions for improvements. This is a Limited-Use Experimental Protocol. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. |
|
| |
| RFC 1204 | Message Posting Protocol (MPP) |
| |
| Authors: | S. Yeh, D. Lee. |
| Date: | February 1991 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1204 |
|
This memo describes a protocol for posting messages from workstations (e.g., PCs) to a mail service host. This RFC specifies an Experimental Protocol for the Internet community. It does not specify any standard. |
|
| |
| RFC 1224 | Techniques for managing asynchronously generated alerts |
| |
| Authors: | L. Steinberg. |
| Date: | May 1991 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1224 |
|
This RFC explores mechanisms to prevent a remotely managed entity from burdening a manager or network with an unexpected amount of network management information, and to ensure delivery of "important" information. The focus is on controlling the flow of asynchronously generated information, and not how the information is generated. |
|
| |
| RFC 1226 | Internet protocol encapsulation of AX.25 frames |
| |
| Authors: | B. Kantor. |
| Date: | May 1991 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1226 |
|
This memo describes a method for the encapsulation of AX.25 (the Amateur Packet-Radio Link-Layer Protocol) frames within IP packets. This technique is an Experimental Protocol for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1228 | SNMP-DPI: Simple Network Management Protocol Distributed Program Interface |
| |
|
|
This RFC describes a protocol that International Business Machines Corporation (IBM) has been implementing in most of its SNMP agents to allow dynamic extension of supported MIBs. This is an Experimental Protocol for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1235 | Coherent File Distribution Protocol |
| |
| Authors: | J. Ioannidis, G. Maguire. |
| Date: | June 1991 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1235 |
|
This memo describes the Coherent File Distribution Protocol (CFDP). This is an Experimental Protocol for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1238 | CLNS MIB for use with Connectionless Network Protocol (ISO 8473) and End System to Intermediate System (ISO 9542) |
| |
|
|
This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. This is an Experimental Protocol for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1241 | Scheme for an internet encapsulation protocol: Version 1 |
| |
| Authors: | R.A. Woodburn, D.L. Mills. |
| Date: | July 1991 |
| Formats: | txt json pdf ps html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1241 |
|
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1279 | X.500 and Domains |
| |
| Authors: | S.E. Hardcastle-Kille. |
| Date: | November 1991 |
| Formats: | txt json html ps pdf |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1279 |
|
This RFCconsiders X.500 in relation to Internet and UK Domains.A basic model of X.500 providing a higher level and more descriptive naming structure is emphasised. In addition, a mapping of domains onto X.500 is proposed, which gives a range of new management and user facilities over and above those currently available. This specification proposes an experimental new mechanism to access and manage domain information on the Internet and in the UK Academic Community. There is no current intention to provide an operational replacement for DNS. |
|
| |
| RFC 1283 | SNMP over OSI |
| |
|
|
This memo describes mappings from the SNMP onto both the COTS and the CLTS. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet Standard. |
|
| |
| RFC 1307 | Dynamically Switched Link Control Protocol |
| |
| Authors: | J. Young, A. Nicholson. |
| Date: | March 1992 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1307 |
|
This memo describes an experimental protocol developed by a project team at Cray Research, Inc., in implementing support for circuit- switched T3 services. The protocol is used for the control of network connections external to a host, but known to the host. It is documented here for the benefit of others who may wish to perform further research.
While working with circuit-switched T3 networks, developers at CrayResearch, Inc., defined a model wherein a host would generate control messages for a network switch. This work is described in RFC 1306,"Experiences Supporting By-Request Circuit-Switched T3 Networks". In order to simplify the model it was decided that the inconsistencies of switch control should be hidden from the host generating the control messages. To that end, a protocol was defined and implemented. This RFC documents the Dynamically Switched LinkControl Protocol (DSLCP), which is used for creation and control of downstream network links by a host. |
|
| |
| RFC 1312 | Message Send Protocol 2 |
| |
|
|
The Message Send Protocol is used to send a short message to a given user on a given terminal on a given host. This memo defines an Experimental Protocol for the Internet community. |
|
| |
| RFC 1339 | Remote Mail Checking Protocol |
| |
| Authors: | S. Dorner, P. Resnick. |
| Date: | June 1992 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1339 |
|
This RFC defines a protocol to provide a mail checking service to be used between a client and server pair. Typically, a small program on a client workstation would use the protocol to query a server in order to find out whether new mail has arrived for a specified user. |
|
| |
| RFC 1348 | DNS NSAP RRs |
| |
|
|
This RFC defines the format of two new Resource Records (RRs) for the Domain Name System (DNS), and reserves corresponding DNS type mnemonic and numerical codes. This memo defines an Experimental Protocol for the Internet community. |
|
| |
| RFC 1383 | An Experiment in DNS Based IP Routing |
| |
| Authors: | C. Huitema. |
| Date: | December 1992 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1383 |
|
Potential solutions to the routing explosion. This memo defines an Experimental Protocol for the Internet community. |
|
| |
| RFC 1405 | Mapping between X.400(1984/1988) and Mail-11 (DECnet mail) |
| |
|
|
This document describes a set of mappings which will enable inter working between systems operating the CCITT X.400 ( 1984 / 1988 )Recommendations on Message Handling Systems, and systems running theMail-11 (also known as DECnet mail) protocol. The specifications are valid within DECnet Phase IV addressing and routing scheme.
The complete scenario of X.400 / RFC822 / Mail-11 is also considered, in order to cover the possible complex cases arising in multiple gateway translations.
This document covers mainly the O/R address to DECnet from/to address mapping (and vice versa); other mappings are based on RFC 1327 and its eventual future updates.
This is a combined effort of COSINE S2.2, the RARE MSG Working Group, and the IETF X.400 Ops Working Group. |
|
| |
| RFC 1409 | Telnet Authentication Option |
| |
|
|
This memo defines an Experimental Protocol for the Internet community. |
|
| |
| RFC 1411 | Telnet Authentication: Kerberos Version 4 |
| |
| Authors: | D. Borman, Ed.. |
| Date: | January 1993 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1411 |
|
This memo defines an Experimental Protocol for the Internet community. |
|
| |
| RFC 1412 | Telnet Authentication: SPX |
| |
| Authors: | K. Alagappan. |
| Date: | January 1993 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1412 |
|
This memo defines an Experimental Protocol for the Internet community. |
|
| |
| RFC 1416 | Telnet Authentication Option |
| |
|
|
This RFC 1416 replaces RFC 1409, which has an important typographical error in the example on page 6 (one occurance of "REPLY" should be "IS"). This memo defines an Experimental Protocol for the Internet community. |
|
| |
| RFC 1433 | Directed ARP |
| |
| Authors: | J. Garrett, J. Hagan, J. Wong. |
| Date: | March 1993 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1433 |
|
A router with an interface to two IP networks via the same link level interface could observe that the two IP networks share the same link level network, and could advertise that information to hosts (viaICMP Redirects) and routers (via dynamic routing protocols).However, a host or router on only one of the IP networks could not use that information to communicate directly with hosts and routers on the other IP network unless it could resolve IP addresses on the"foreign" IP network to their corresponding link level addresses.Directed ARP is a dynamic address resolution procedure that enables hosts and routers to resolve advertised potential next-hop IP addresses on foreign IP networks to their associated link level addresses. |
|
| |
| RFC 1440 | SIFT/UFT: Sender-Initiated/Unsolicited File Transfer |
| |
| Authors: | R. Troth. |
| Date: | July 1993 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1440 |
|
This document describes a Sender-Initiated File Transfer (SIFT) protocol, also commonly called Unsolicited File Transfer (UFT) protocol. This memo defines an Experimental Protocol for the Internet community. |
|
| |
| RFC 1455 | Physical Link Security Type of Service |
| |
|
|
This RFC documents an experimental protocol providing a Type ofService (TOS) to request maximum physical link security. This is an addition to the types of service enumerated in RFC 1349: Type ofService in the Internet Protocol Suite. The new TOS requests the network to provide what protection it can against surreptitious observation by outside agents of traffic so labeled. The purpose is protection against traffic analysis and as an additional possible level of data confidentiality. This TOS is consistent with all other defined types of service for IP version 4 in that it is based on link level characteristics and will not provide any particular guaranteed level of service. |
|
| |
| RFC 1459 | Internet Relay Chat Protocol |
| |
|
|
The IRC protocol was developed over the last 4 years since it was first implemented as a means for users on a BBS to chat amongst themselves. Now it supports a world-wide network of servers and clients, and is stringing to cope with growth. Over the past 2 years, the average number of users connected to the main IRC network has grown by a factor of 10.
The IRC protocol is a text-based protocol, with the simplest client being any socket program capable of connecting to the server. |
|
| |
| RFC 1464 | Using the Domain Name System To Store Arbitrary String Attributes |
| |
| Authors: | R. Rosenbaum. |
| Date: | May 1993 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1464 |
|
While the Domain Name System (DNS) [2,3] is generally used to store predefined types of information (e.g., addresses of hosts), it is possible to use it to store information that has not been previously classified.
This paper describes a simple means to associate arbitrary string information (ASCII text) with attributes that have not been defined by the DNS. It uses DNS TXT resource records to store the information. It requires no change to current DNS implementations. |
|
| |
| RFC 1465 | Routing Coordination for X.400 MHS Services Within a Multi Protocol / Multi Network Environment Table Format V3 for Static Routing |
| |
| Authors: | D. Eppenberger. |
| Date: | May 1993 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1465 |
|
This document proposes short term solutions for maintaining and distributing routing information and shows how messages can travel over different networks by using multi stack MTAs as relays. This memo defines an Experimental Protocol for the Internet community. |
|
| |
| RFC 1476 | RAP: Internet Route Access Protocol |
| |
| Authors: | R. Ullmann. |
| Date: | June 1993 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1476 |
|
This RFC describes an open distance vector routing protocol for use at all levels of the internet, from isolated LANs to the major routers of an international commercial network provider. |
|
| |
| RFC 1486 | An Experiment in Remote Printing |
| |
|
|
This memo describes a technique for "remote printing" using the Internet mail infrastructure. In particular, this memo focuses on the case in which remote printers are connected to the international telephone network. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1505 | Encoding Header Field for Internet Messages |
| |
| Authors: | A. Costanzo, D. Robinson, R. Ullmann. |
| Date: | August 1993 |
| Formats: | txt json html |
| Obsoletes: | RFC 1154 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1505 |
|
This document expands upon the elective experimental Encoding header field which permits the mailing of multi-part, multi-structured messages. It replaces RFC 1154 [1]. |
|
| |
| RFC 1507 | DASS - Distributed Authentication Security Service |
| |
| Authors: | C. Kaufman. |
| Date: | September 1993 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1507 |
|
The goal of DASS is to provide authentication services in a distributed environment which are both more secure and easier to use than existing mechanisms. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard. |
|
| |
| RFC 1545 | FTP Operation Over Big Address Records (FOOBAR) |
| |
|
|
This paper describes a convention for specifying longer addresses in the PORT command. |
|
| |
| RFC 1561 | Use of ISO CLNP in TUBA Environments |
| |
| Authors: | D. Piscitello. |
| Date: | December 1993 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1561 |
|
This memo specifies a profile of the ISO/IEC 8473 Connectionless-modeNetwork Layer Protocol (CLNP, [1]) for use in conjunction with RFC1347, TCP/UDP over Bigger Addresses (TUBA, [2]). It describes the use of CLNP to provide the lower-level service expected byTransmission Control Protocol (TCP, [3]) and User Datagram Protocol(UDP, [4]). CLNP provides essentially the same datagram service asInternet Protocol (IP, [5]), but offers a means of conveying bigger network addresses (with additional structure, to aid routing).
While the protocols offer nearly the same services, IP and CLNP are not identical. This document describes a means of preserving the semantics of IP information that is absent from CLNP while preserving consistency between the use of CLNP in Internet and OSI environments.This maximizes the use of already-deployed CLNP implementations. |
|
| |
| RFC 1592 | Simple Network Management Protocol Distributed Protocol Interface Version 2.0 |
| |
| Authors: | B. Wijnen, G. Carpenter, K. Curran, A. Sehgal, G. Waters. |
| Date: | March 1994 |
| Formats: | txt json html |
| Obsoletes: | RFC 1228 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1592 |
|
This RFC describes version 2.0 of a protocol that International Business Machines Corporation (IBM) has been implementing in most of its SNMP agents to allow dynamic extension of supported MIBs. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1608 | Representing IP Information in the X.500 Directory |
| |
| Authors: | T. Johannsen, G. Mansfield, M. Kosters, S. Sataluri. |
| Date: | March 1994 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1608 |
|
This document describes the objects necessary to include information about IP networks and IP numbers in the X.500 Directory. It extends the work "Charting networks in the X.500 Directory" [1] where a general framework is presented for representing networks in theDirectory by applying it to IP networks. This application of theDirectory is intended to support the work of IP network assigning authorities, NICs, as well as other applications looking for a mapping of IP numbers to data of related networks. Furthermore,Autonomous Systems and related routing policy information can be represented in the Directory along with their relationship to networks and organizations. |
|
| |
| RFC 1609 | Charting Networks in the X.500 Directory |
| |
| Authors: | G. Mansfield, T. Johannsen, M. Knopper. |
| Date: | March 1994 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1609 |
|
There is a need for a framework wherein the infrastructural and service related information about communication networks can be made accessible from all places and at all times in a reasonably efficient manner and with reasonable accuracy. This document presents a model in which a communication network with all its related details and descriptions can be represented in the X.500 Directory. Schemas of objects and their attributes which may be used for this purpose are presented. The model envisages physical objects and several logical abstractions of the physical objects. |
|
| |
| RFC 1637 | DNS NSAP Resource Records |
| |
|
|
The Internet is moving towards the deployment of an OSI lower layers infrastructure. This infrastructure comprises the connectionless network protocol (CLNP) and supporting routing protocols. Also required as part of this infrastructure is support in the Domain NameSystem (DNS) for mapping between names and NSAP addresses.
This document defines the format of one new Resource Record (RR) for the DNS for domain name-to-NSAP mapping. The RR may be used with anyNSAP address format. This document supercedes RFC 1348.
NSAP-to-name translation is accomplished through use of the PTR RR(see STD 13, RFC 1035 for a description of the PTR RR). This paper describes how PTR RRs are used to support this translation. |
|
| |
| RFC 1639 | FTP Operation Over Big Address Records (FOOBAR) |
| |
|
|
This paper describes a convention for specifying address families other than the default Internet address family in FTP commands and replies. |
|
| |
| RFC 1641 | Using Unicode with MIME |
| |
|
|
The Unicode Standard, version 1.1, and ISO/IEC 10646-1:1993(E) jointly define a 16 bit character set (hereafter referred to asUnicode) which encompasses most of the world's writing systems.However, Internet mail (STD 11, RFC 822) currently supports only 7- bit US ASCII as a character set. MIME (RFC 1521 and RFC 1522) extendsInternet mail to support different media types and character sets, and thus could support Unicode in mail messages. MIME neither definesUnicode as a permitted character set nor specifies how it would be encoded, although it does provide for the registration of additional character sets over time.
This document specifies the usage of Unicode within MIME. |
|
| |
| RFC 1642 | UTF-7 - A Mail-Safe Transformation Format of Unicode |
| |
|
|
The Unicode Standard, version 1.1, and ISO/IEC 10646-1:1993(E) jointly define a 16 bit character set (hereafter referred to asUnicode) which encompasses most of the world's writing systems.However, Internet mail (STD 11, RFC 822) currently supports only 7- bit US ASCII as a character set. MIME (RFC 1521 and RFC 1522) extendsInternet mail to support different media types and character sets, and thus could support Unicode in mail messages. MIME neither definesUnicode as a permitted character set nor specifies how it would be encoded, although it does provide for the registration of additional character sets over time.
This document describes a new transformation format of Unicode that contains only 7-bit ASCII characters and is intended to be readable by humans in the limiting case that the document consists of characters from the US-ASCII repertoire. It also specifies how this transformation format is used in the context of RFC 1521, RFC 1522, and the document "Using Unicode with MIME". |
|
| |
| RFC 1664 | Using the Internet DNS to Distribute RFC1327 Mail Address Mapping Tables |
| |
| Authors: | C. Allocchio, A. Bonito, B. Cole, S. Giordano, R. Hagens. |
| Date: | August 1994 |
| Formats: | txt json html |
| Obsoleted by: | RFC 2163 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1664 |
|
This memo defines how to store in the Internet Domain Name System the mapping information needed by e-mail gateways and other tools to mapRFC822 domain names into X.400 O/R names and vice versa. Mapping information can be managed in a distributed rather than a centralised way. Gateways located on Internet hosts can retrieve the mapping information querying the DNS instead of having fixed tables which need to be centrally updated and distributed. This memo is a joint effort of X400 operation working group (x400ops) and RARE Mail andMessaging working group (WG-MSG). |
|
| |
| RFC 1712 | DNS Encoding of Geographical Location |
| |
| Authors: | C. Farrell, M. Schulze, S. Pleitner, D. Baldoni. |
| Date: | November 1994 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1712 |
|
This document defines the format of a new Resource Record (RR) for the Domain Naming System (DNS), and reserves a corresponding DNS type mnemonic and numerical code. This definition deals with associating geographical host location mappings to host names within a domain.The data shown in this document is fictitious and does not necessarily reflect the real Internet. |
|
| |
| RFC 1735 | NBMA Address Resolution Protocol (NARP) |
| |
| Authors: | J. Heinanen, R. Govindan. |
| Date: | December 1994 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1735 |
|
This document describes the NBMA Address Resolution Protocol (NARP).NARP can be used by a source terminal (host or router) connected to aNon-Broadcast, Multi-Access link layer (NBMA) network to find out theNBMA addresses of the a destination terminal provided that the destination terminal is connected to the same NBMA network. Although this document focuses on NARP in the context of IP, the technique is applicable to other network layer protocols as well. This RFC is a product of the Routing over Large Clouds Working Group of the IETF. |
|
| |
| RFC 1756 | Remote Write Protocol - Version 1.0 |
| |
| Authors: | T. Rinne. |
| Date: | January 1995 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1756 |
|
This document describes a simple Remote Write Protocol (RWP). This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 1765 | OSPF Database Overflow |
| |
| Authors: | J. Moy. |
| Date: | March 1995 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1765 |
|
Proper operation of the OSPF protocol requires that all OSPF routers maintain an identical copy of the OSPF link-state database. However, when the size of the link-state database becomes very large, some routers may be unable to keep the entire database due to resource shortages; we term this "database overflow". When database overflow is anticipated, the routers with limited resources can be accommodated by configuring OSPF stub areas and NSSAs. This memo details a way of gracefully handling unanticipated database overflows.
This memo is a product of the OSPF Working Group. Please send comments to ospf@gated.cornell.edu. |
|
| |
| RFC 1768 | Host Group Extensions for CLNP Multicasting |
| |
| Authors: | D. Marlow. |
| Date: | March 1995 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1768 |
|
This memo documents work performed in the TUBA (TCP/UDP over BiggerAddresses) working group of IPng area prior to the July 1994 decision to utilize SIPP-16 as the basis for IPng. The TUBA group worked on extending the Internet Protocol suite by the use of ISO 8473 (CLNP) and its related routing protocols. This memo describes multicast extensions to CLNP and its related routing protocols for Internet multicast use. Publication of this memo does not imply acceptance by any IETF Working Group for the ideas expressed within.
This memo provides a specification for multicast extensions to theCLNP protocol similar to those provided to IP by RFC1112. These extensions are intended to provide the mechanisms needed by a host for multicasting in a CLNP based Internet. This memo covers addressing extensions to the CLNP addressing structure, extensions to the CLNP protocol and extensions to the ES-IS protocol. An appendix discusses the differences between IP multicast and the CLNP multicast approach provided in this memo. |
|
| |
| RFC 1791 | TCP And UDP Over IPX Networks With Fixed Path MTU |
| |
| Authors: | T. Sung. |
| Date: | April 1995 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1791 |
|
TCP/IPX allows TCP/IP applications to run over IPX networks by letting TCP and UDP run over IPX. And this memo specifies the packet format and operational procedures for running TCP and UDP over IPX. This document defines an Experimental Protocol for the Internet community. This does not specify an Internet standard of any kind. |
|
| |
| RFC 1792 | TCP/IPX Connection Mib Specification |
| |
| Authors: | T. Sung. |
| Date: | April 1995 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1792 |
|
New MIB objects, tcpIpxConnTable, udpIpxTable, tcpUnspecConnTable and udpUnspecTable are presented in this paper, to be used in place of tcpConnTable and udpListenerTable when TCP and UDP are running over IPX. This document defines an Experimental Protocol for the Internet community. This does not specify an Internet standard of any kind. |
|
| |
| RFC 1797 | Class A Subnet Experiment |
| |
| Authors: | Internet Assigned Numbers Authority (IANA). |
| Date: | April 1995 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1797 |
|
There appears to be some interest in experimenting with subnetting the class A addresses. It is suggested that conducting an experiment now to identify and fix any software that does not properly handle subnetted class A addresses would be useful and important. This document defines an Experimental Protocol for the Internet community. This does not specify an Internet standard of any kind. |
|
| |
| RFC 1801 | MHS use of the X.500 Directory to support MHS Routing |
| |
| Authors: | S. Kille. |
| Date: | June 1995 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1801 |
|
The key problem in routing is to map from an O/R Address onto an MTA (next hop). This shall be an MTA which in some sense is "nearer" to the destination UA. This is done repeatedly until the message can be directly delivered to the recipient UA. This memo defines an Experimental Protocol for the Internet community. |
|
| |
| RFC 1804 | Schema Publishing in X.500 Directory |
| |
| Authors: | G. Mansfield, P. Rajeev, S. Raghavan, T. Howes. |
| Date: | June 1995 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1804 |
|
The X.500 directory provides a powerful mechanism for storing and retrieving information about objects of interest. To interpret the information stored in the directory, the schema must be known to all the components of the directory. Presently, there are no means other than ftp to distribute schema information across the Internet. This is proving to be a severe constraint as the Directory is growing.This document presents a solution to the schema distribution problem using the existing mechanisms of the directory. A naming scheme for naming schema objects and a meta-schema for storing schema objects is presented. The procedures for fetching unknown schema from the directory at runtime are described. |
|
| |
| RFC 1806 | Communicating Presentation Information in Internet Messages: The Content-Disposition Header |
| |
|
|
This memo provides a mechanism whereby messages conforming to the[RFC 1521] ("MIME") specification can convey presentational information. It specifies a new "Content-Disposition" header, optional and valid for any [RFC 1521] entity ("message" or "body part"). Two values for this header are described in this memo; one for the ordinary linear presentation of the body part, and another to facilitate the use of mail to transfer files. It is expected that more values will be defined in the future, and procedures are defined for extending this set of values.
This document is intended as an extension to [RFC 1521]. As such, the reader is assumed to be familiar with [RFC 1521], and [RFC 822]. The information presented herein supplements but does not replace that found in those documents. |
|
| |
| RFC 1830 | SMTP Service Extensions for Transmission of Large and Binary MIME Messages |
| |
|
|
This memo defines two extensions to the SMTP service. The first service enables a SMTP client and server to negotiate the use of an alternate DATA command "BDAT" for efficiently sending large MIME messages. The second extension takes advantage of the BDAT command to permit the negotiated sending of unencoded binary data. This memo defines an Experimental Protocol for the Internet community. |
|
| |
| RFC 1836 | Representing the O/R Address hierarchy in the X.500 Directory Information Tree |
| |
|
|
This document defines a representation of the O/R Address hierarchy in the Directory Information Tree [6, 1]. This is useful for a range of purposes, including: |
|
| |
| RFC 1837 | Representing Tables and Subtrees in the X.500 Directory |
| |
|
|
This document defines techniques for representing two types of information mapping in the OSI Directory [1].
1. Mapping from a key to a value (or set of values), as might be done in a table lookup.
2. Mapping from a distinguished name to an associated value (or values), where the values are not defined by the owner of the entry. This is achieved by use of a directory subtree.
These techniques were developed for supporting MHS use of Directory[2], but are specified separately as they have more general applicability. |
|
| |
| RFC 1838 | Use of the X.500 Directory to support mapping between X.400 and RFC 822 Addresses |
| |
|
|
This document defines how to use directory to support the mapping between X.400 O/R Addresses and mailboxes defined in RFC 1327 [2]. |
|
| |
| RFC 1845 | SMTP Service Extension for Checkpoint/Restart |
| |
| Authors: | D. Crocker, N. Freed, A. Cargille. |
| Date: | September 1995 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1845 |
|
This memo defines an extension to the SMTP service whereby an interrupted SMTP transaction can be restarted at a later time without having to repeat all of the commands and message content sent prior to the interruption. |
|
| |
| RFC 1846 | SMTP 521 Reply Code |
| |
|
|
This memo defines a new Simple Mail Transfer Protocol (SMTP) [1] reply code, 521, which one may use to indicate that an Internet host does not accept incoming mail. |
|
| |
| RFC 1851 | The ESP Triple DES Transform |
| |
| Authors: | P. Karn, P. Metzger, W. Simpson. |
| Date: | September 1995 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1851 |
|
This document describes the Triple DES-CBC security transform for theIP Encapsulating Security Payload (ESP). |
|
| |
| RFC 1852 | IP Authentication using Keyed SHA |
| |
| Authors: | P. Metzger, W. Simpson. |
| Date: | September 1995 |
| Formats: | txt json html |
| Obsoleted by: | RFC 2841 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1852 |
|
This document describes the use of keyed SHA with the IPAuthentication Header. |
|
| |
| RFC 1868 | ARP Extension - UNARP |
| |
| Authors: | G. Malkin. |
| Date: | November 1995 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1868 |
|
The Address Resolution Protocol allows an IP node to determine the hardware (datalink) address of a neighboring node on a broadcast network. The protocol depends on timers to age away old ARP entries.This document specifies a trivial modification to the ARP mechanism, not the packet format, which allows a node to announce that it is leaving the network and that all other nodes should modify their ARP tables accordingly. |
|
| |
| RFC 1872 | The MIME Multipart/Related Content-type |
| |
|
|
The Multipart/Related content-type provides a common mechanism for representing objects that are aggregates of related MIME body parts.This document defines the Multipart/Related content-type and provides examples of its use. |
|
| |
| RFC 1873 | Message/External-Body Content-ID Access Type |
| |
| Authors: | E. Levinson. |
| Date: | December 1995 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1873 |
|
When using MIME [MIME] to encapsulate a structured object that consist of many elements, for example an SGML [SGML] document, a single element may occur several times. An encapsulation normally maps each of the structured objects elements to a MIME entity. It is useful to include elements that occur multiple time exactly once. To accomplish that and to preserve the object structure it is desirable to unambiguously refer to another body part of the same message.
The existing MIME Content-Type Message/External-Body access-types allow a MIME entity (body-part) to refer to an object that is not in the message by specifying how to access that object. The Content-ID access method described in this document provides the capability to refer to an object within the message. |
|
| |
| RFC 1874 | SGML Media Types |
| |
| Authors: | E. Levinson. |
| Date: | December 1995 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1874 |
|
This document proposes new media sub-types of Text/SGML andApplication/SGML. These media types can be used in the exchange ofSGML documents and their entities. Specific details for the exchange or encapsulation of groups of related SGML entities using MIME are currently being considered by the mimesgml Working Group <sgml- internet@ebt.com&rt;. |
|
| |
| RFC 1876 | A Means for Expressing Location Information in the Domain Name System |
| |
|
|
This memo defines a new DNS RR type for experimental purposes. This RFC describes a mechanism to allow the DNS to carry location information about hosts, networks, and subnets. This memo defines an Experimental Protocol for the Internet community. |
|
| |
| RFC 1897 | IPv6 Testing Address Allocation |
| |
|
|
This document describes an allocation plan for IPv6 addresses to be used in testing IPv6 prototype software. This document specifies an Experimental protocol for the Internet community. |
|
| |
| RFC 1911 | Voice Profile for Internet Mail |
| |
|
|
The following document is a profile of the Internet standard MIME and ESMTP protocols for use as a digital voice networking protocol. This memo defines an Experimental Protocol for the Internet community. |
|
| |
| RFC 1949 | Scalable Multicast Key Distribution |
| |
| Authors: | A. Ballardie. |
| Date: | May 1996 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1949 |
|
The benefits of multicasting are becoming ever-more apparent, and its use much more widespread. This is evident from the growth of theMBONE [1]. Providing security services for multicast, such as traffic integrity, authentication, and confidentiality, is particularly problematic since it requires securely distributing a group (session) key to each of a group's receivers. Traditionally, the key distribution function has been assigned to a central network entity, or Key Distribution Centre (KDC), but this method does not scale for wide-area multicasting, where group members may be widely-distributed across the internetwork, and a wide-area group may be densely populated.
Even more problematic is the scalable distribution of sender-specific keys. Sender-specific keys are required if data traffic is to be authenticated on a per-sender basis.
This memo provides a scalable solution to the multicast key distribution problem.
NOTE: this proposal requires some simple support mechanisms, which, it is recommended here, be integrated into version 3 of IGMP. This support is described in Appendix B. |
|
| |
| RFC 1965 | Autonomous System Confederations for BGP |
| |
|
|
Border Gateway Protocol [1] is an inter-autonomous system routing protocol designed for TCP/IP networks.
This document describes an extension to BGP which may be used to create a confederation of autonomous systems which is represented as one single autonomous system to BGP peers external to the confederation.
The intention of this extension is to aid in policy administration and reduce the management complexity of maintaining a large autonomous system.
The extension this document describes is widely deployed in theInternet today. |
|
| |
| RFC 1966 | BGP Route Reflection An alternative to full mesh IBGP |
| |
|
|
The Border Gateway Protocol [1] is an inter-autonomous system routing protocol designed for TCP/IP internets. BGP deployments are configured such that that all BGP speakers within a single AS must be fully meshed so that any external routing information must be re- distributed to all other routers within that AS. This represents a serious scaling problem that has been well documented with several alternatives proposed [2,3].
This document describes the use and design of a method known as"Route Reflection" to alleviate the the need for "full mesh" IBGP. |
|
| |
| RFC 1986 | Experiments with a Simple File Transfer Protocol for Radio Links using Enhanced Trivial File Transfer Protocol (ETFTP) |
| |
| Authors: | W. Polites, W. Wollman, D. Woo, R. Langan. |
| Date: | August 1996 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 1986 |
|
This document is a description of the Enhanced Trivial File Transfer Protocol (ETFTP). This protocol is an experimental implementation of the NETwork BLock Transfer Protocol (NETBLT), RFC 998 [1], as a file transfer application program. This memo defines an Experimental Protocol for the Internet community. |
|
| |
| RFC 2009 | GPS-Based Addressing and Routing |
| |
| Authors: | T. Imielinski, J. Navas. |
| Date: | November 1996 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2009 |
|
This document describes a possible experiment with geographic addresses. It uses several specific IP addresses and domain names in the discussion as concrete examples to aid in understanding the concepts. This memo defines an Experimental Protocol for the Internet community. |
|
| |
| RFC 2016 | Uniform Resource Agents (URAs) |
| |
| Authors: | L. Daigle, P. Deutsch, B. Heelan, C. Alpaugh, M. Maclachlan. |
| Date: | October 1996 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2016 |
|
This paper presents an experimental architecture for an agent system that provides sophisticated Internet information access and management. Not a generalized architecture for active objects that roam the Internet, these agents are modeled as extensions of existing pieces of the Internet information infrastructure. This experimental agent technology focuses on the necessary information structures to encapsulate Internet activities into objects that can be activated, transformed, and combined into larger structured activities. |
|
| |
| RFC 2052 | A DNS RR for specifying the location of services (DNS SRV) |
| |
| Authors: | A. Gulbrandsen, P. Vixie. |
| Date: | October 1996 |
| Formats: | txt json html |
| Obsoleted by: | RFC 2782 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2052 |
|
This document describes a DNS RR which specifies the location of the server(s) for a specific protocol and domain (like a more general form of MX). |
|
| |
| RFC 2063 | Traffic Flow Measurement: Architecture |
| |
| Authors: | N. Brownlee, C. Mills, G. Ruth. |
| Date: | January 1997 |
| Formats: | txt json html |
| Obsoleted by: | RFC 2722 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2063 |
|
This document describes an architecture for the measurement and reporting of network traffic flows, discusses how this relates to an overall network traffic flow architecture, and describes how it can be used within the Internet. It is intended to provide a starting point for the Realtime Traffic Flow Measurement Working Group. |
|
| |
| RFC 2064 | Traffic Flow Measurement: Meter MIB |
| |
|
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, this memo defines managed objects used for obtaining traffic flow information from network traffic meters. |
|
| |
| RFC 2066 | TELNET CHARSET Option |
| |
| Authors: | R. Gellens. |
| Date: | January 1997 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2066 |
|
This document specifies a mechanism for passing character set and translation information between a TELNET client and server. Use of this mechanism enables an application used by a TELNET user to send and receive data in the correct character set.
Either side can (subject to option negotiation) at any time request that a (new) character set be used. |
|
| |
| RFC 2075 | IP Echo Host Service |
| |
| Authors: | C. Partridge. |
| Date: | January 1997 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2075 |
|
This memo describes how to implement an IP echo host. IP echo hosts send back IP datagrams after exchanging the source and destination IP addresses. The effect is that datagrams sent to the echo host are sent back to the source, as if they originated at the echo host. |
|
| |
| RFC 2090 | TFTP Multicast Option |
| |
| Authors: | A. Emberson. |
| Date: | February 1997 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2090 |
|
The Trivial File Transfer Protocol [1] is a simple, lock-step, file transfer protocol which allows a client to get or put a file onto a remote host.
This document describes a new TFTP option. This new option will allow the multiple clients to receive the same file concurrently through the use of Multicast packets. The TFTP Option Extension mechanism is described in [2].
Often when similar computers are booting remotely they will each download the same image file. By adding multicast into the TFTP option set, two or more computers can download a file concurrently, thus increasing network efficiency.
This document assumes that the reader is familiar with the terminology and notation of both [1] and [2]. |
|
| |
| RFC 2093 | Group Key Management Protocol (GKMP) Specification |
| |
| Authors: | H. Harney, C. Muckenhirn. |
| Date: | July 1997 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2093 |
|
This specification proposes a protocol to create grouped symmetric keys and distribute them amongst communicating peers. This protocol has the following advantages: 1) virtually invisible to operator, 2) no central key distribution site is needed, 3) only group members have the key, 4) sender or receiver oriented operation, 5) can make use of multicast communications protocols. |
|
| |
| RFC 2094 | Group Key Management Protocol (GKMP) Architecture |
| |
| Authors: | H. Harney, C. Muckenhirn. |
| Date: | July 1997 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2094 |
|
This specification proposes a protocol to create grouped symmetric keys and distribute them amongst communicating peers. This protocol has the following advantages: 1) virtually invisible to operator, 2) no central key distribution site is needed, 3) only group members have the key, 4) sender or receiver oriented operation, 5) can make use of multicast communications protocols. |
|
| |
| RFC 2117 | Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification |
| |
| Authors: | D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, L. Wei. |
| Date: | June 1997 |
| Formats: | txt json html |
| Obsoleted by: | RFC 2362 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2117 |
|
This document describes a protocol for efficiently routing to multicast groups that may span wide-area (and inter-domain) internets. This memo defines an Experimental Protocol for the Internet community. |
|
| |
| RFC 2120 | Managing the X.500 Root Naming Context |
| |
| Authors: | D. Chadwick. |
| Date: | March 1997 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2120 |
|
The X.500 Standard [X.500 93] has the concept of first level DSAs, whose administrators must collectively manage the root naming context through bi-lateral agreements or other private means which are outside the scope of the X.500 Standard.
The NameFLOW-Paradise X.500 service has an established procedure for managing the root naming context, which currently uses Quipu proprietary replication mechanisms and a root DSA. The benefits that derive from this are twofold:
- firstly it is much easier to co-ordinate the management of the root context information, when there is a central point of administration,
- secondly the performance of one-level Search operations is greatly improved because the Quipu distribution and replication mechanism does not have a restriction that exists in the 1988 and1993 X.500 Standard.
The NameFLOW-Paradise project is moving towards 1993 ISO X.500Standard replication protocols and wants to standardise the protocol and procedure for managing the root naming context which will be based on 1993 X.500 Standard protocols. Such a protocol and procedure will be useful to private X.500 domains as well as to the InternetX.500 public domain. It is imperative that overall system performance is not degraded by this transition.
This document describes the use of 1993 ISO X.500 Standard protocols for managing the root context. Whilst the ASN.1 is compatible with that of the X.500 Standard, the actual settings of the parameters are supplementary to that of the X.500 Standard. |
|
| |
| RFC 2143 | Encapsulating IP with the Small Computer System Interface |
| |
| Authors: | B. Elliston. |
| Date: | May 1997 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2143 |
|
This document outlines a protocol for connecting hosts running the TCP/IP protocol suite over a Small Computer System Interface (SCSI) bus. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. |
|
| |
| RFC 2154 | OSPF with Digital Signatures |
| |
| Authors: | S. Murphy, M. Badger, B. Wellington. |
| Date: | June 1997 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2154 |
|
This memo describes the extensions to OSPF required to add digital signature authentication to Link State data, and to provide a certification mechanism for router data. Added LSA processing and key management is detailed. A method for migration from, or co- existence with, standard OSPF V2 is described. |
|
| |
| RFC 2161 | A MIME Body Part for ODA |
| |
| Authors: | H. Alvestrand. |
| Date: | January 1998 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2161 |
|
This document contains the definitions, originally contained in RFC 1495 and RFC 1341, on how to carry ODA in MIME, and how to translate it to its X.400 representation. This memo defines an Experimental Protocol for the Internet community. |
|
| |
| RFC 2162 | MaXIM-11 - Mapping between X.400 / Internet mail and Mail-11 mail |
| |
|
|
This document describes a set of mappings which will enable inter working between systems operating the ISO/IEC 10021 - CCITT (now ITU)X.400 Recommendations on Message Handling Systems, and systems running the Mail-11 (also known as DECnet mail or VMSmail) protocol.The specifications are valid both within DECnet Phase IV andDECnet/OSI addressing and routing scheme.
The complete scenario of X.400 / MIME / Mail-11 is also considered, in order to cover the possible complex cases arising in multiple gateway translations.
This document covers mainly the X.400 O/R address to/from Mail-11 address mapping and the RFC822 to/from Mail-11 ones; other mappings are based on MIXER specifications. Bodypart mappings are not specified in this document: MIXER and MIME-MHS specifications can be applied to map bodyparts between X.400, MIME and Mail-11, too. In fact MIME encoding can be used without modifications within Mail-11 text bodyparts.
This document obsoletes RFC 1405, which was a combined effort ofTERENA Working Group on Messaging, and the IETF X.400 Ops WorkingGroup. This update was prepared by IETF MIXER working group. |
|
| |
| RFC 2168 | Resolution of Uniform Resource Identifiers using the Domain Name System |
| |
|
|
The requirements document for URN resolution systems defines the concept of a "resolver discovery service". This document describes the first, experimental, RDS. It is implemented by a new DNS Resource Record, NAPTR (Naming Authority PoinTeR), that provides rules for mapping parts of URIs to domain names. This memo defines an Experimental Protocol for the Internet community. |
|
| |
| RFC 2217 | Telnet Com Port Control Option |
| |
| Authors: | G. Clark. |
| Date: | October 1997 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2217 |
|
This memo proposes a protocol to allow greater use of modems attached to a network for outbound dialing purposes. This memo defines an Experimental Protocol for the Internet community. |
|
| |
| RFC 2295 | Transparent Content Negotiation in HTTP |
| |
| Authors: | K. Holtman, A. Mutz. |
| Date: | March 1998 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2295 |
|
HTTP allows web site authors to put multiple versions of the same information under a single URL. Transparent content negotiation is an extensible negotiation mechanism, layered on top of HTTP, for automatically selecting the best version when the URL is accessed. This enables the smooth deployment of new web data formats and markup tags. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. |
|
| |
| RFC 2307 | An Approach for Using LDAP as a Network Information Service |
| |
| Authors: | L. Howard. |
| Date: | March 1998 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2307 |
|
This document describes an experimental mechanism for mapping entities related to TCP/IP and the UNIX system into X.500 [X500] entries so that they may be resolved with the Lightweight DirectoryAccess Protocol [RFC2251]. A set of attribute types and object classes are proposed, along with specific guidelines for interpreting them.
The intention is to assist the deployment of LDAP as an organizational nameservice. No proposed solutions are intended as standards for the Internet. Rather, it is hoped that a general consensus will emerge as to the appropriate solution to such problems, leading eventually to the adoption of standards. The proposed mechanism has already been implemented with some success. |
|
| |
| RFC 2337 | Intra-LIS IP multicast among routers over ATM using Sparse Mode PIM |
| |
| Authors: | D. Farinacci, D. Meyer, Y. Rekhter. |
| Date: | April 1998 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2337 |
|
This document describes how intra-LIS IP multicast can be efficiently supported among routers over ATM without using the Multicast Address Resolution Server (MARS). This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. |
|
| |
| RFC 2343 | RTP Payload Format for Bundled MPEG |
| |
| Authors: | M. Civanlar, G. Cash, B. Haskell. |
| Date: | May 1998 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2343 |
|
This document describes a payload type for bundled, MPEG-2 encoded video and audio data that may be used with RTP, version 2. Bundling has some advantages for this payload type particularly when it is used for video-on-demand applications. This payload type may be used when its advantages are important enough to sacrifice the modularity of having separate audio and video streams. |
|
| |
| RFC 2345 | Domain Names and Company Name Retrieval |
| |
| Authors: | J. Klensin, T. Wolf, G. Oglesby. |
| Date: | May 1998 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2345 |
|
Location of web information for particular companies based on their names has become an increasingly difficult problem as the Internet and the web grow. The use of a naming convention and the domain name system (DNS) for that purpose has caused complications for the latter while not solving the problem. While there have been several proposals to use contemporary, high-capability, directory service and search protocols to reduce the dependencies on DNS conventions, none of them have been significantly deployed.
This document proposes a company name to URL mapping service based on the oldest and least complex of Internet directory protocols, whois, in order to explore whether an extremely simple and widely-deployed protocol can succeed where more complex and powerful options have failed or been excessively delayed. |
|
| |
| RFC 2362 | Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification |
| |
| Authors: | D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, L. Wei. |
| Date: | June 1998 |
| Formats: | txt html json |
| Obsoletes: | RFC 2117 |
| Obsoleted by: | RFC 4601, RFC 5059 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2362 |
|
This document describes a protocol for efficiently routing to multicast groups that may span wide-area (and inter-domain) internets. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. |
|
| |
| RFC 2414 | Increasing TCP's Initial Window |
| |
| Authors: | M. Allman, S. Floyd, C. Partridge. |
| Date: | September 1998 |
| Formats: | txt json html |
| Obsoleted by: | RFC 3390 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2414 |
|
This document specifies an increase in the permitted initial window for TCP from one segment to roughly 4K bytes. This document discusses the advantages and disadvantages of such a change, outlining experimental results that indicate the costs and benefits of such a change to TCP. |
|
| |
| RFC 2443 | A Distributed MARS Service Using SCSP |
| |
| Authors: | J. Luciani, A. Gallo. |
| Date: | November 1998 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2443 |
|
This document describes a method for distributing a MARS service within a LIS[1]. This method uses the Server Cache SynchronizationProtocol (SCSP)[2] to synchronize the MARS Server databases within aLIS. When SCSP is used to synchronize the caches of MARS Servers in a LIS, the LIS defines the boundary of an SCSP Server Group (SG). |
|
| |
| RFC 2481 | A Proposal to add Explicit Congestion Notification (ECN) to IP |
| |
| Authors: | K. Ramakrishnan, S. Floyd. |
| Date: | January 1999 |
| Formats: | txt html json |
| Obsoleted by: | RFC 3168 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2481 |
|
This note describes a proposed addition of ECN (Explicit CongestionNotification) to IP. TCP is currently the dominant transport protocol used in the Internet. We begin by describing TCP's use of packet drops as an indication of congestion. Next we argue that with the addition of active queue management (e.g., RED) to the Internet infrastructure, where routers detect congestion before the queue overflows, routers are no longer limited to packet drops as an indication of congestion. Routers could instead set a CongestionExperienced (CE) bit in the packet header of packets from ECN-capable transport protocols. We describe when the CE bit would be set in the routers, and describe what modifications would be needed to TCP to make it ECN-capable. Modifications to other transport protocols(e.g., unreliable unicast or multicast, reliable multicast, other reliable unicast transport protocols) could be considered as those protocols are developed and advance through the standards process. |
|
| |
| RFC 2483 | URI Resolution Services Necessary for URN Resolution |
| |
| Authors: | M. Mealling, R. Daniel. |
| Date: | January 1999 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2483 |
|
Retrieving the resource identified by a Uniform Resource Identifier(URI) [1] is only one of the operations that can be performed on aURI. One might also ask for and get a list of other identifiers that are aliases for the original URI or a bibliographic description of the resource the URI denotes, for example. This applies to bothUniform Resource Names (URNs) and Uniform Resource Locators (URLs).Uniform Resource Characteristics (URCs) are discussed in this document but only as descriptions of resources rather than identifiers.
A service in the network providing access to a resource may provide one or some of these options, but it need not provide all of them.This memo specifies an initial set of these operations that can be used to describe the interactions provided by a given access service.It also suggests guidelines that should be adhered to when those operations are encoded in a protocol. |
|
| |
| RFC 2498 | IPPM Metrics for Measuring Connectivity |
| |
|
|
This memo defines a series of metrics for connectivity between a pair of Internet hosts. It builds on notions introduced and discussed in RFC 2330, the IPPM framework document. This memo defines an Experimental Protocol for the Internet community. |
|
| |
| RFC 2520 | NHRP with Mobile NHCs |
| |
| Authors: | J. Luciani, H. Suzuki, N. Doraswamy, D. Horton. |
| Date: | February 1999 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2520 |
|
This document describes an extension to NHRP [1] which would allowMobile NHCs to perform a registration with and attach to an NHS in their home LIS in an authenticated manner.
As described in this document, Mobile NHCs are NHCs which are not configured with enough information to find a specific serving NHS in their home LIS, but which have a mechanism to find an NHS (which may or may not be a serving NHS) to which they will attach. As described in [1], an NHC may attach to a 'surrogate' NHS by using a mechanism such as an anycast address. In this case, the NHC may use the surrogate NHS to send a NHRP Registration Request toward the NHC's home LIS where a serving NHS resides. However, as defined in [1], packet authentication is performed on a hop by hop basis. In the mobile NHC case, it is not practical for the mobile NHC be in a security relationship with every surrogate NHS, thus it is presumably desirable to have some form of end to end only authentication for the case of a mobile NHC's registration. This document describes an authentication extension for NHRP which has such end to end only semantics. |
|
| |
| RFC 2521 | ICMP Security Failures Messages |
| |
| Authors: | P. Karn, W. Simpson. |
| Date: | March 1999 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2521 |
|
This document specifies ICMP messages for indicating failures when using IP Security Protocols (AH and ESP). |
|
| |
| RFC 2522 | Photuris: Session-Key Management Protocol |
| |
| Authors: | P. Karn, W. Simpson. |
| Date: | March 1999 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2522 |
|
Photuris is a session-key management protocol intended for use with the IP Security Protocols (AH and ESP). This document defines the basic protocol mechanisms. |
|
| |
| RFC 2523 | Photuris: Extended Schemes and Attributes |
| |
| Authors: | P. Karn, W. Simpson. |
| Date: | March 1999 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2523 |
|
Photuris is a session-key management protocol. Extensible Exchange-Schemes are provided to enable future implementation changes without affecting the basic protocol.
Additional authentication attributes are included for use with the IPAuthentication Header (AH) or the IP Encapsulating Security Protocol(ESP).
Additional confidentiality attributes are included for use with ESP. |
|
| |
| RFC 2540 | Detached Domain Name System (DNS) Information |
| |
| Authors: | D. Eastlake 3rd. |
| Date: | March 1999 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2540 |
|
A standard format is defined for representing detached DNS information. This is anticipated to be of use for storing information retrieved from the Domain Name System (DNS), including security information, in archival contexts or contexts not connected to the Internet. |
|
| |
| RFC 2565 | Internet Printing Protocol/1.0: Encoding and Transport |
| |
| Authors: | R. Herriot, Ed., S. Butler, P. Moore, R. Turner. |
| Date: | April 1999 |
| Formats: | txt json html |
| Obsoleted by: | RFC 2910 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2565 |
|
This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing using Internet tools and technologies. This document defines the rules for encoding IPP operations and IPP attributes into a newInternet mime media type called "application/ipp". This document also defines the rules for transporting over HTTP a message body whose Content-Type is "application/ipp".
The full set of IPP documents includes:
Design Goals for an Internet Printing Protocol [RFC2567]Rationale for the Structure and Model and Protocol for theInternet Printing Protocol [RFC2568]Internet Printing Protocol/1.0: Model and Semantics [RFC2566]Internet Printing Protocol/1.0: Encoding and Transport (this document)Internet Printing Protocol/1.0: Implementer's Guide [ipp-iig]Mapping between LPD and IPP Protocols [RFC2569]
The document, "Design Goals for an Internet Printing Protocol", takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. It calls out a subset of end user requirements that are satisfied in IPP/1.0. Operator and administrator requirements are out of scope for version 1.0.
The document, "Rationale for the Structure and Model and Protocol for the Internet Printing Protocol", describes IPP from a high level view, defines a roadmap for the various documents that form the suite of IPP specifications, and gives background and rationale for theIETF working group's major decisions.
The document, "Internet Printing Protocol/1.0: Model and Semantics", describes a simplified model with abstract objects, their attributes, and their operations that are independent of encoding and transport.It introduces a Printer and a Job object. The Job object optionally supports multiple documents per Job. It also addresses security, internationalization, and directory issues.
This document "Internet Printing Protocol/1.0: Implementer's Guide", gives advice to implementers of IPP clients and IPP objects.
The document "Mapping between LPD and IPP Protocols" gives some advice to implementers of gateways between IPP and LPD (Line PrinterDaemon) implementations. |
|
| |
| RFC 2566 | Internet Printing Protocol/1.0: Model and Semantics |
| |
| Authors: | R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell. |
| Date: | April 1999 |
| Formats: | txt html json |
| Obsoleted by: | RFC 2911 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2566 |
|
This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing using Internet tools and technologies. This document describes a simplified model consisting of abstract objects, their attributes, and their operations that is independent of encoding and transport.The model consists of a Printer and a Job object. A Job optionally supports multiple documents. IPP 1.0 semantics allow end-users and operators to query printer capabilities, submit print jobs, inquire about the status of print jobs and printers, and cancel print jobs.This document also addresses security, internationalization, and directory issues.
The full set of IPP documents includes:
Design Goals for an Internet Printing Protocol [RFC2567]Rationale for the Structure and Model and Protocol for the InternetPrinting Protocol [RFC2568]Internet Printing Protocol/1.0: Model and Semantics (this document)Internet Printing Protocol/1.0: Encoding and Transport [RFC2565]Internet Printing Protocol/1.0: Implementer's Guide [ipp-iig]Mapping between LPD and IPP Protocols [RFC2569]
The "Design Goals for an Internet Printing Protocol" document takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. It calls out a subset of end user requirements that are satisfied in IPP/1.0. Operator and administrator requirements are out of scope for version 1.0.
The "Rationale for the Structure and Model and Protocol for theInternet Printing Protocol" document describes IPP from a high level view, defines a roadmap for the various documents that form the suite of IPP specifications, and gives background and rationale for theIETF working group's major decisions.
The "Internet Printing Protocol/1.0: Encoding and Transport" document is a formal mapping of the abstract operations and attributes defined in the model document onto HTTP/1.1. It defines the encoding rules for a new Internet media type called "application/ipp".
The "Internet Printing Protocol/1.0: Implementer's Guide" document gives insight and advice to implementers of IPP clients and IPP objects. It is intended to help them understand IPP/1.0 and some of the considerations that may assist them in the design of their client and/or IPP object implementations. For example, a typical order of processing requests is given, including error checking. Motivation for some of the specification decisions is also included.
The "Mapping between LPD and IPP Protocols" document gives some advice to implementers of gateways between IPP and LPD (Line PrinterDaemon) implementations. |
|
| |
| RFC 2567 | Design Goals for an Internet Printing Protocol |
| |
| Authors: | F. Wright. |
| Date: | April 1999 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2567 |
|
This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing using Internet tools and technologies. This document takes a broad look at distributed printing functionality, and it enumerates real- life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. The design goals document calls out a subset of end user requirements that are satisfied in IPP/1.0. Operator and administrator requirements are out of scope for version 1.0.
The full set of IPP documents includes:
Design Goals for an Internet Printing Protocol (this document)Rationale for the Structure and Model and Protocol for theInternet Printing Protocol [RFC2568]Internet Printing Protocol/1.0: Model and Semantics [RFC2568]Internet Printing Protocol/1.0: Encoding and Transport [RFC2565]Internet Printing Protocol/1.0: Implementer's Guide [ipp-iig]Mapping between LPD and IPP Protocols [RFC2569]
The "Rationale for the Structure and Model and Protocol for theInternet Printing Protocol" document describes IPP from a high level view, defines a roadmap for the various documents that form the suite of IPP specifications, and gives background and rationale for theIETF working group's major decisions.
The "Internet Printing Protocol/1.0: Model and Semantics" document describes a simplified model consisting of abstract objects, their attributes, and their operations that is independent of encoding and transport. The model consists of a Printer and a Job object. TheJob optionally supports multiple documents. IPP 1.0 semantics allow end-users and operators to query printer capabilities, submit print jobs, inquire about the status of print jobs and printers, and cancel print jobs. This document also addresses security, internationalization, and directory issues.
The "Internet Printing Protocol/1.0: Encoding and Transport" document is a formal mapping of the abstract operations and attributes defined in the model document onto HTTP/1.1. It defines the encoding rules for a new Internet media type called "application/ipp".
The "Internet Printing Protocol/1.0: Implementer's Guide" document gives insight and advice to implementers of IPP clients and IPP objects. It is intended to help them understand IPP/1.0 and some of the considerations that may assist them in the design of their client and/or IPP object implementations. For example, a typical order of processing requests is given, including error checking. Motivation for some of the specification decisions is also included.
The "Mapping between LPD and IPP Protocols" document gives some advice to implementers of gateways between IPP and LPD (Line PrinterDaemon) implementations. |
|
| |
| RFC 2568 | Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol |
| |
| Authors: | S. Zilles. |
| Date: | April 1999 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2568 |
|
This document describes IPP from a high level view, defines a roadmap for the various documents that form the suite of IPP specifications, and gives background and rationale for the IETF working group's major decisions. This memo defines an Experimental Protocol for the Internet community. |
|
| |
| RFC 2569 | Mapping between LPD and IPP Protocols |
| |
| Authors: | R. Herriot, Ed., T. Hastings, N. Jacobs, J. Martin. |
| Date: | April 1999 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2569 |
|
This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing using Internet tools and technologies. This document gives some advice to implementers of gateways between IPP and LPD (Line PrinterDaemon). This document describes the mapping between (1) the commands and operands of the 'Line Printer Daemon (LPD) Protocol' specified inRFC 1179 and (2) the operations, operation attributes and job template attributes of the Internet Printing Protocol/1.0 (IPP). One of the purposes of this document is to compare the functionality of the two protocols. Another purpose is to facilitate implementation of gateways between LPD and IPP.
WARNING: RFC 1179 was not on the IETF standards track. While RFC1179 was intended to record existing practice, it fell short in some areas. However, this specification maps between (1) the actual current practice of RFC 1179 and (2) IPP. This document does not attempt to map the numerous divergent extensions to the LPD protocol that have been made by many implementers.
The full set of IPP documents includes:
Design Goals for an Internet Printing Protocol [RFC2567]Rationale for the Structure and Model and Protocol for theInternet Printing Protocol [RFC2568]Internet Printing Protocol/1.0: Model and Semantics [RFC2566]Internet Printing Protocol/1.0: Encoding and Transport [RFC2565]Internet Printing Protocol/1.0: Implementors Guide [ipp-iig]Mapping between LPD and IPP Protocols (this document)
The document, "Design Goals for an Internet Printing Protocol", takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. It calls out a subset of end user requirements that are satisfied in IPP/1.0. Operator and administrator requirements are out of scope for version 1.0.
The document, "Rationale for the Structure and Model and Protocol for the Internet Printing Protocol", describes IPP from a high level view, defines a roadmap for the various documents that form the suite of IPP specifications, and gives background and rationale for theIETF working group's major decisions.
The document, "Internet Printing Protocol/1.0: Model and Semantics", describes a simplified model with abstract objects, their attributes, and their operations. It introduces a Printer and a Job object. TheJob object supports multiple documents per Job. It also addresses security, internationalization, and directory issues.
The document, "Internet Printing Protocol/1.0: Encoding andTransport", is a formal mapping of the abstract operations and attributes defined in the model document onto HTTP/1.1. It defines the encoding rules for a new Internet media type called ' application/ipp'.
This document "Internet Printing Protocol/1.0: Implementer's Guide", gives advice to implementers of IPP clients and IPP objects. |
|
| |
| RFC 2582 | The NewReno Modification to TCP's Fast Recovery Algorithm |
| |
|
|
RFC 2001 [RFC2001] documents the following four intertwined TCP congestion control algorithms: Slow Start, Congestion Avoidance, FastRetransmit, and Fast Recovery. RFC 2581 [RFC2581] explicitly allows certain modifications of these algorithms, including modifications that use the TCP Selective Acknowledgement (SACK) option [MMFR96], and modifications that respond to "partial acknowledgments" (ACKs which cover new data, but not all the data outstanding when loss was detected) in the absence of SACK. This document describes a specific algorithm for responding to partial acknowledgments, referred to asNewReno. This response to partial acknowledgments was first proposed by Janey Hoe in [Hoe95]. |
|
| |
| RFC 2593 | Script MIB Extensibility Protocol Version 1.0 |
| |
| Authors: | J. Schoenwaelder, J. Quittek. |
| Date: | May 1999 |
| Formats: | txt html json |
| Obsoleted by: | RFC 3179 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2593 |
|
The IETF Script MIB defines an interface for the delegation of management functions based on the Internet management framework. A management script is a set of instructions that are executed by a language specific runtime system. The Script MIB extensibility protocol (SMX) defined in this memo separates language specific runtime systems from language independent Script MIB implementations. |
|
| |
| RFC 2649 | An LDAP Control and Schema for Holding Operation Signatures |
| |
| Authors: | B. Greenblatt, P. Richard. |
| Date: | August 1999 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2649 |
|
In many environments clients require the ability to validiate the source and integrity of information provided by the directory. This document describes an LDAP message control which allows for the retrieval of digitally signed information. This document defines anLDAP v3 based mechanism for signing directory operations in order to create a secure journal of changes that have been made to each directory entry. Both client and server based signatures are supported. An object class for subsequent retrieval are "journal entries" is also defined. This document specifies LDAP v3 controls that enable this functionality. It also defines an LDAP v3 schema that allows for subsequent browsing of the journal information. |
|
| |
| RFC 2654 | A Tagged Index Object for use in the Common Indexing Protocol |
| |
| Authors: | R. Hedberg, B. Greenblatt, R. Moats, M. Wahl. |
| Date: | August 1999 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2654 |
|
This document defines a mechanism by which information servers can exchange indices of information from their databases by making use of the Common Indexing Protocol (CIP). This document defines the structure of the index information being exchanged, as well as the appropriate meanings for the headers that are defined in the CommonIndexing Protocol. It is assumed that the structures defined here can be used by X.500 DSAs, LDAP servers, Whois++ servers, CSO Ph servers and many others. |
|
| |
| RFC 2655 | CIP Index Object Format for SOIF Objects |
| |
| Authors: | T. Hardie, M. Bowman, D. Hardy, M. Schwartz, D. Wessels. |
| Date: | August 1999 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2655 |
|
This document describes SOIF, the Summary Object Interchange Format, as an index object type in the context of the CIP framework. This memo defines an Experimental Protocol for the Internet community. |
|
| |
| RFC 2656 | Registration Procedures for SOIF Template Types |
| |
| Authors: | T. Hardie. |
| Date: | August 1999 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2656 |
|
The Summary Object Interchange Format [Ref. 1] was first defined by the Harvest Project [Ref 2.] in January 1994. SOIF was derived from a combination of the Internet Anonymous FTP Archives IETF WorkingGroup (IAFA) templates [Ref 3.] and the BibTeX bibliography format[Ref 4.]. The combination was originally noted for its advantages of providing a convenient and intuitive way for delimiting objects within a stream, and setting apart the URL for easy object access or invocation, while still preserving compatibility with IAFA templates.
SOIF uses named template types to indicate the attributes which may be contained within a particular summary object. Within the context of a single application, private agreement on the definition of template types has been adequate. As SOIF objects are moved among applications, however, the need for standard, well-specified, and easily identifiable template types increases. This need is particularly intense in the context of query referral, where knowledge of an attribute's definition and the allowed data types for specific values is crucial. For a discussion of this in the context of the Common Indexing Protocol, see [Ref. 1].
The registration procedure described in this document is specific toSOIF template types. There is ongoing work within the IETF to specify a more generic schema registration facility[Ref. 5]. It is not yet clear whether the results of that work will encompass the ability to register entities like SOIF template types. If it does so, the registration of SOIF template types may be shifted to that method and registry. Should that occur, appropriate pointers will be created in cooperation with the Registrar to ensure that no registrations are lost. |
|
| |
| RFC 2657 | LDAPv2 Client vs |
| |
| Authors: | the Index Mesh. R. Hedberg. |
| Date: | August 1999 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2657 |
|
LDAPv2 clients as implemented according to RFC 1777 [1] have no notion on referral. The integration between such a client and anIndex Mesh, as defined by the Common Indexing Protocol [2], heavily depends on referrals and therefore needs to be handled in a special way. This document defines one possible way of doing this. |
|
| |
| RFC 2659 | Security Extensions For HTML |
| |
| Authors: | E. Rescorla, A. Schiffman. |
| Date: | August 1999 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2659 |
|
This memo describes a syntax for embedding S-HTTP negotiation parameters in HTML documents. S-HTTP, as described by RFC 2660, contains the concept of negotiation headers which reflect the potential receiver of a message's preferences as to which crypto- graphic enhancements should be applied to the message. This document describes a syntax for binding these negotiation parameters to HTML anchors.
1. Introduction
2. Anchor Attributes
We define the following new anchor (and form submission) attributes:
DN -- The distinguished name of the principal for whom the request should be encrypted when dereferencing the anchor's url.This need not be specified, but failure to do so runs the risk that the client will be unable to determine the DN and therefore will be unable to encrypt. This should be specified in the form of RFC1485, using SGML quoting conventions as needed.
NONCE -- A free-format string (appropriately SGML quoted) which is to be included in a SHTTP-Nonce: header (after SGML quoting is removed) when the anchor is dereferenced.
CRYPTOPTS -- Cryptographic option information as described in
[SHTTP]. Specifically, the <cryptopt-list&rt; production. |
|
| |
| RFC 2676 | QoS Routing Mechanisms and OSPF Extensions |
| |
| Authors: | G. Apostolopoulos, S. Kama, D. Williams, R. Guerin, A. Orda, T. Przygienda. |
| Date: | August 1999 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2676 |
|
This memo describes extensions to the OSPF [Moy98] protocol to support QoS routes. The focus of this document is on the algorithms used to compute QoS routes and on the necessary modifications to OSPF to support this function, e.g., the information needed, its format, how it is distributed, and how it is used by the QoS path selection process. Aspects related to how QoS routes are established and managed are also briefly discussed. The goal of this document is to identify a framework and possible approaches to allow deployment ofQoS routing capabilities with the minimum possible impact to the existing routing infrastructure.
In addition, experience from an implementation of the proposed extensions in the GateD environment [Con], along with performance measurements is presented. |
|
| |
| RFC 2692 | SPKI Requirements |
| |
| Authors: | C. Ellison. |
| Date: | September 1999 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2692 |
|
The IETF Simple Public Key Infrastructure [SPKI] Working Group is tasked with producing a certificate structure and operating procedure to meet the needs of the Internet community for trust management in as easy, simple and extensible a way as possible.
The SPKI Working Group first established a list of things one might want to do with certificates (attached at the end of this document), and then summarized that list of desires into requirements. This document presents that summary of requirements. |
|
| |
| RFC 2693 | SPKI Certificate Theory |
| |
| Authors: | C. Ellison, B. Frantz, B. Lampson, R. Rivest, B. Thomas, T. Ylonen. |
| Date: | September 1999 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2693 |
|
The SPKI Working Group has developed a standard form for digital certificates whose main purpose is authorization rather than authentication. These structures bind either names or explicit authorizations to keys or other objects. The binding to a key can be directly to an explicit key, or indirectly through the hash of the key or a name for it. The name and authorization structures can be used separately or together. We use S-expressions as the standard format for these certificates and define a canonical form for thoseS-expressions. As part of this development, a mechanism for deriving authorization decisions from a mixture of certificate types was developed and is presented in this document.
This document gives the theory behind SPKI certificates and ACLs without going into technical detail about those structures or their uses. |
|
| |
| RFC 2716 | PPP EAP TLS Authentication Protocol |
| |
|
|
The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links.The Extensible Authentication Protocol (EAP) is a PPP extension that provides support for additional authentication methods within PPP. This memo defines an Experimental Protocol for the Internet community. |
|
| |
| RFC 2724 | RTFM: New Attributes for Traffic Flow Measurement |
| |
| Authors: | S. Handelman, S. Stibler, N. Brownlee, G. Ruth. |
| Date: | October 1999 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2724 |
|
The RTFM Traffic Measurement Architecture provides a general framework for describing and measuring network traffic flows. Flows are defined in terms of their Address Attribute values and measured by a 'Traffic Meter'. This document discusses RTFM flows and the attributes which they can have, so as to provide a logical framework for extending the architecture by adding new attributes.
Extensions described include Address Attributes such as DSCodePoint,SourceASN and DestASN, and Group Attributes such as short-term bit rates and turnaround times. Quality of Service parameters forIntegrated Services are also discussed. |
|
| |
| RFC 2756 | Hyper Text Caching Protocol (HTCP/0.0) |
| |
| Authors: | P. Vixie, D. Wessels. |
| Date: | January 2000 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2756 |
|
This document describes HTCP, a protocol for discovering HTTP caches and cached data, managing sets of HTTP caches, and monitoring cache activity. This is an experimental protocol, one among several proposals to perform these functions. |
|
| |
| RFC 2758 | Definitions of Managed Objects for Service Level Agreements Performance Monitoring |
| |
| Authors: | K. White. |
| Date: | February 2000 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2758 |
|
This memo defines a Management Information Base (MIB) for performance monitoring of Service Level Agreements (SLAs) defined via policy definitions. The MIB defined herein focuses on defining a set of objects for monitoring SLAs and not on replication of the content of the policy definitions being monitored. The goal of the MIB defined within this document is to defined statistics related to a policy rule definition for reporting on the effect that a policy rule has on a system and to defined a method of monitoring this data. |
|
| |
| RFC 2762 | Sampling of the Group Membership in RTP |
| |
| Authors: | J. Rosenberg, H. Schulzrinne. |
| Date: | February 2000 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2762 |
|
In large multicast groups, the size of the group membership table maintained by RTP (Real Time Transport Protocol) participants may become unwieldy, particularly for embedded devices with limited memory and processing power. This document discusses mechanisms for sampling of this group membership table in order to reduce the memory requirements. Several mechanisms are proposed, and the performance of each is considered. |
|
| |
| RFC 2770 | GLOP Addressing in 233/8 |
| |
| Authors: | D. Meyer, P. Lothberg. |
| Date: | February 2000 |
| Formats: | txt json html |
| Obsoleted by: | RFC 3180 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2770 |
|
This describes an experimental policy for use of the class D address space using 233/8 as the experimental statically assigned subset of the class D address space. This new experimental allocation is in addition to those described on [IANA] (e.g. [RFC2365]).
This memo is a product of the Multicast Deployment Working Group(MBONED) in the Operations and Management Area of the InternetEngineering Task Force. Submit comments to <mboned@ns.uoregon.edu&rt; or the authors. |
|
| |
| RFC 2773 | Encryption using KEA and SKIPJACK |
| |
| Authors: | R. Housley, P. Yee, W. Nace. |
| Date: | February 2000 |
| Formats: | txt html json |
| Updates: | RFC 0959 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2773 |
|
This document defines a method to encrypt a file transfer using theFTP specification STD 9, RFC 959, "File Transfer Protocol (FTP)",(October 1985) [3] and RFC 2228, "FTP Security Extensions" (October1997) [1]. This method will use the Key Exchange Algorithm (KEA) to give mutual authentication and establish the data encryption keys.SKIPJACK is used to encrypt file data and the FTP command channel. |
|
| |
| RFC 2786 | Diffie-Helman USM Key Management Information Base and Textual Convention |
| |
| Authors: | M. St. Johns. |
| Date: | March 2000 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2786 |
|
This memo defines an experimental portion of the ManagementInformation Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a textual convention for doing Diffie-Helman key agreement key exchanges and a set of objects which extend the usmUserTable to permit the use of aDH key exchange in addition to the key change method described in[12]. In otherwords, this MIB adds the possibility of forward secrecy to the USM model. It also defines a set of objects that can be used to kick start security on an SNMPv3 agent when the out of band path is authenticated, but not necessarily private or confidential.
The KeyChange textual convention described in [12] permits secure key changes, but has the property that if a third-party has knowledge of the original key (e.g. if the agent was manufactured with a standard default key) and could capture all SNMP exchanges, the third-party would know the new key. The Diffie-Helman key change described here limits knowledge of the new key to the agent and the manager making the change. In otherwords, this process adds forward secrecy to the key change process.
The recommendation in [12] is that the usmUserTable be populated out of band - e.g. not via SNMP. If the number of agents to be configured is small, this can be done via a console port and manually. If the number of agents is large, as is the case for a cable modem system, the manual approach doesn't scale well. The combination of the two mechanisms specified here - the DH key change mechanism, and the DH key ignition mechanism - allows managable use of SNMPv3 USM in a system of millions of devices.
This memo specifies a MIB module in a manner that is compliant to theSNMP SMIv2[5][6][7]. The set of objects is consistent with the SNMP framework and existing SNMP standards and is intended for use with the SNMPv3 User Security Model MIB and other security related MIBs.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [16].
This memo is a private submission by the author, but is applicable to the SNMPv3 working group within the Internet Engineering Task Force.Comments are solicited and should be addressed to the the author. |
|
| |
| RFC 2823 | PPP over Simple Data Link (SDL) using SONET/SDH with ATM-like framing |
| |
| Authors: | J. Carlson, P. Langner, E. Hernandez-Valencia, J. Manchester. |
| Date: | May 2000 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2823 |
|
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links, andRFCs 1662 [2] and 2615 [3] provide a means to carry PPP overSynchronous Optical Network (SONET) [4] and Synchronous DigitalHierarchy (SDH) [5] circuits. This document extends these standards to include a new encapsulation for PPP called Simple Data Link (SDL)[6]. SDL provides a very low overhead alternative to HDLC-like encapsulation, and can also be used on SONET/SDH links. |
|
| |
| RFC 2844 | OSPF over ATM and Proxy-PAR |
| |
| Authors: | T. Przygienda, P. Droz, R. Haas. |
| Date: | May 2000 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2844 |
|
This memo specifies, for OSPF implementors and users, mechanisms describing how the protocol operates in ATM networks over PVC and SVC meshes with the presence of Proxy-PAR. These recommendations require no protocol changes and allow simpler, more efficient and cost- effective network designs. It is recommended that OSPF implementations should be able to support logical interfaces, each consisting of one or more virtual circuits and used either as numbered logical point-to-point links (one VC), logical NBMA networks(more than one VC) or Point-to-MultiPoint networks (more than oneVC), where a solution simulating broadcast interfaces is not appropriate. PAR can help distribute across the ATM cloud configuration setup and changes of such interfaces when OSPF capable routers are (re-)configured. Proxy-PAR can in turn be used to exchange this information between the ATM cloud and the routers connected to it. |
|
| |
| RFC 2859 | A Time Sliding Window Three Colour Marker (TSWTCM) |
| |
| Authors: | W. Fang, N. Seddigh, B. Nandy. |
| Date: | June 2000 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2859 |
|
This memo defines a Time Sliding Window Three Colour Marker (TSWTCM), which can be used as a component in a Diff-Serv traffic conditioner[RFC2475, RFC2474]. The marker is intended to mark packets that will be treated by the Assured Forwarding (AF) Per Hop Behaviour (PHB)[AFPHB] in downstream routers. The TSWTCM meters a traffic stream and marks packets to be either green, yellow or red based on the measured throughput relative to two specified rates: Committed Target Rate(CTR) and Peak Target Rate (PTR). |
|
| |
| RFC 2903 | Generic AAA Architecture |
| |
| Authors: | C. de Laat, G. Gross, L. Gommans, J. Vollbrecht, D. Spence. |
| Date: | August 2000 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2903 |
|
This memo proposes an Authentication, Authorization, Accounting (AAA) architecture that would incorporate a generic AAA server along with an application interface to a set of Application Specific Modules that could perform application specific AAA functions. A separation of AAA functions required in a multi-domain environment is then proposed using a layered protocol abstraction. The long term goal is to create a generic framework which allows complex authorizations to be realized through a network of interconnected AAA servers. |
|
| |
| RFC 2934 | Protocol Independent Multicast MIB for IPv4 |
| |
| Authors: | K. McCloghrie, D. Farinacci, D. Thaler, B. Fenner. |
| Date: | October 2000 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2934 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes managed objects used for managing theProtocol Independent Multicast (PIM) protocol for IPv4. |
|
| |
| RFC 2974 | Session Announcement Protocol |
| |
| Authors: | M. Handley, C. Perkins, E. Whelan. |
| Date: | October 2000 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 2974 |
|
This document describes version 2 of the multicast session directory announcement protocol, Session Announcement Protocol (SAP), and the related issues affecting security and scalability that should be taken into account by implementors. |
|
| |
| RFC 3018 | Unified Memory Space Protocol Specification |
| |
| Authors: | A. Bogdanov. |
| Date: | December 2000 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3018 |
|
This document specifies Unified Memory Space Protocol (UMSP), which gives a capability of immediate access to memory of the remote nodes. |
|
| |
| RFC 3029 | Internet X.509 Public Key Infrastructure Data Validation and Certification Server Protocols |
| |
| Authors: | C. Adams, P. Sylvester, M. Zolotarev, R. Zuccherato. |
| Date: | February 2001 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3029 |
|
This document describes a general Data Validation and CertificationServer (DVCS) and the protocols to be used when communicating with it. The Data Validation and Certification Server is a Trusted ThirdParty (TTP) that can be used as one component in building reliable non-repudiation services.
Useful Data Validation and Certification Server responsibilities in aPKI are to assert the validity of signed documents, public key certificates, and the possession or existence of data.
Assertions created by this protocol are called Data ValidationCertificates (DVC).
We give examples of how to use the Data Validation and CertificationServer to extend the lifetime of a signature beyond key expiry or revocation and to query the Data Validation and Certification Server regarding the status of a public key certificate. The document includes a complete example of a time stamping transaction. |
|
| |
| RFC 3063 | MPLS Loop Prevention Mechanism |
| |
| Authors: | Y. Ohba, Y. Katsube, E. Rosen, P. Doolan. |
| Date: | February 2001 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3063 |
|
This paper presents a simple mechanism, based on "threads", which can be used to prevent Multiprotocol Label Switching (MPLS) from setting up label switched path (LSPs) which have loops. The mechanism is compatible with, but does not require, VC merge. The mechanism can be used with either the ordered downstream-on-demand allocation or ordered downstream allocation. The amount of information that must be passed in a protocol message is tightly bounded (i.e., no path- vector is used). When a node needs to change its next hop, a distributed procedure is executed, but only nodes which are downstream of the change are involved. |
|
| |
| RFC 3082 | Notification and Subscription for SLP |
| |
| Authors: | J. Kempf, J. Goldschmidt. |
| Date: | March 2001 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3082 |
|
The Service Location Protocol (SLP) provides mechanisms whereby service agent clients can advertise and user agent clients can query for services. The design is very much demand-driven, so that user agents only obtain service information when they specifically ask for it. There exists another class of user agent applications, however, that requires notification when a new service appears or disappears.In the RFC 2608 design, these applications are forced to poll the network to catch changes. In this document, we describe a protocol for allowing such clients to be notified when a change occurs, removing the need for polling. |
|
| |
| RFC 3088 | OpenLDAP Root Service An experimental LDAP referral service |
| |
| Authors: | K. Zeilenga. |
| Date: | April 2001 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3088 |
|
The OpenLDAP Project is operating an experimental LDAP (LightweightDirectory Access Protocol) referral service known as the "OpenLDAPRoot Service". The automated system generates referrals based upon service location information published in DNS SRV RRs (Domain NameSystem location of services resource records). This document describes this service. |
|
| |
| RFC 3102 | Realm Specific IP: Framework |
| |
| Authors: | M. Borella, J. Lo, D. Grabelsky, G. Montenegro. |
| Date: | October 2001 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3102 |
|
This document examines the general framework of Realm Specific IP(RSIP). RSIP is intended as a alternative to NAT in which the end- to-end integrity of packets is maintained. We focus on implementation issues, deployment scenarios, and interaction with other layer-three protocols. |
|
| |
| RFC 3103 | Realm Specific IP: Protocol Specification |
| |
| Authors: | M. Borella, D. Grabelsky, J. Lo, K. Taniguchi. |
| Date: | October 2001 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3103 |
|
This document presents a protocol with which to implement RealmSpecific IP (RSIP). The protocol defined herein allows negotiation of resources between an RSIP host and gateway, so that the host can lease some of the gateway's addressing parameters in order to establish a global network presence. This protocol is designed to operate on the application layer and to use its own TCP or UDP port.In particular, the protocol allows a gateway to allocate addressing and control parameters to a host such that a flow policy can be enforced at the gateway. |
|
| |
| RFC 3104 | RSIP Support for End-to-end IPsec |
| |
| Authors: | G. Montenegro, M. Borella. |
| Date: | October 2001 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3104 |
|
This document proposes mechanisms that enable Realm Specific IP(RSIP) to handle end-to-end IPsec (IP Security). |
|
| |
| RFC 3105 | Finding an RSIP Server with SLP |
| |
| Authors: | J. Kempf, G. Montenegro. |
| Date: | October 2001 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3105 |
|
This document contains an SLP service type template that describes the advertisements made by RSIP servers for their services. ServiceLocation Protocol (SLP) is an IETF standards track protocol specifically designed to allow clients to find servers offering particular services. Since RSIP (Realm Specific IP) clients require a mechanism to discover RSIP servers, SLP is a natural match for a solution. The service type template is the basis for an InternetAssigned Numbers Authority (IANA) standard definition of the advertisements offered by RSIP servers, an important step toward interoperability. |
|
| |
| RFC 3123 | A DNS RR Type for Lists of Address Prefixes (APL RR) |
| |
| Authors: | P. Koch. |
| Date: | June 2001 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3123 |
|
The Domain Name System (DNS) is primarily used to translate domain names into IPv4 addresses using A RRs (Resource Records). Several approaches exist to describe networks or address ranges. This document specifies a new DNS RR type "APL" for address prefix lists. |
|
| |
| RFC 3125 | Electronic Signature Policies |
| |
| Authors: | J. Ross, D. Pinkas, N. Pope. |
| Date: | September 2001 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3125 |
|
This document defines signature policies for electronic signatures. A signature policy is a set of rules for the creation and validation of an electronic signature, under which the validity of signature can be determined. A given legal/contractual context may recognize a particular signature policy as meeting its requirements.
A signature policy has a globally unique reference, which is bound to an electronic signature by the signer as part of the signature calculation.
The signature policy needs to be available in human readable form so that it can be assessed to meet the requirements of the legal and contractual context in which it is being applied.
To allow for the automatic processing of an electronic signature another part of the signature policy specifies the electronic rules for the creation and validation of the electronic signature in a computer processable form. In the current document the format of the signature policy is defined using ASN.1.
The contents of this document is based on the signature policy defined in ETSI TS 101 733 V.1.2.2 (2000-12) Copyright (C).Individual copies of this ETSI deliverable can be downloaded from http://www.etsi.org. |
|
| |
| RFC 3163 | ISO/IEC 9798-3 Authentication SASL Mechanism |
| |
| Authors: | R. Zuccherato, M. Nystrom. |
| Date: | August 2001 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3163 |
|
This document defines a SASL (Simple Authentication and SecurityLayer) authentication mechanism based on ISO/IEC 9798-3 and FIPS PUB196 entity authentication. |
|
| |
| RFC 3179 | Script MIB Extensibility Protocol Version 1.1 |
| |
| Authors: | J. Schoenwaelder, J. Quittek. |
| Date: | October 2001 |
| Formats: | txt json html |
| Obsoletes: | RFC 2593 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3179 |
|
The Script MIB extensibility protocol (SMX) defined in this memo separates language specific runtime systems from language independentScript MIB implementations. The IETF Script MIB defines an interface for the delegation of management functions based on the Internet management framework. A management script is a set of instructions that are executed by a language specific runtime system. |
|
| |
| RFC 3183 | Domain Security Services using S/MIME |
| |
| Authors: | T. Dean, W. Ottaway. |
| Date: | October 2001 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3183 |
|
This document describes how the S/MIME (Secure/Multipurpose InternetMail Extensions) protocol can be processed and generated by a number of components of a communication system, such as message transfer agents, guards and gateways to deliver security services. These services are collectively referred to as 'Domain Security Services'. |
|
| |
| RFC 3208 | PGM Reliable Transport Protocol Specification |
| |
| Authors: | T. Speakman, J. Crowcroft, J. Gemmell, D. Farinacci, S. Lin, D. Leshchiner, M. Luby, T. Montgomery, L. Rizzo, A. Tweedly, N. Bhaskar, R. Edmonstone, R. Sumanasekera, L. Vicisano. |
| Date: | December 2001 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3208 |
|
Pragmatic General Multicast (PGM) is a reliable multicast transport protocol for applications that require ordered or unordered, duplicate-free, multicast data delivery from multiple sources to multiple receivers. PGM guarantees that a receiver in the group either receives all data packets from transmissions and repairs, or is able to detect unrecoverable data packet loss. PGM is specifically intended as a workable solution for multicast applications with basic reliability requirements. Its central design goal is simplicity of operation with due regard for scalability and network efficiency. |
|
| |
| RFC 3334 | Policy-Based Accounting |
| |
| Authors: | T. Zseby, S. Zander, C. Carle. |
| Date: | October 2002 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3334 |
|
This document describes policy-based accounting which is an approach to provide flexibility to accounting architectures. Accounting policies describe the configuration of an accounting architecture in a standardized way. They are used to instrument the accounting architecture and can be exchanged between Authentication,Authorization and Accounting (AAA) entities in order to share configuration information.
This document describes building blocks and message sequences for policy-based accounting in the generic AAA architecture (RFC 2903).Examples are given for the usage of accounting policies in different scenarios. It is also shown how accounting components can be integrated into the AAA authorization framework (RFC 2904). This document does not propose a language for the description of accounting policies. Rather, it is assumed that a suitable policy language can be chosen from existing or upcoming standards. |
|
| |
| RFC 3338 | Dual Stack Hosts Using "Bump-in-the-API" (BIA) |
| |
| Authors: | S. Lee, M-K. Shin, Y-J. Kim, E. Nordmark, A. Durand. |
| Date: | October 2002 |
| Formats: | txt html json |
| Obsoleted by: | RFC 6535 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3338 |
|
This document specifies a mechanism of dual stack hosts using a technique called "Bump-in-the-API"(BIA) which allows for the hosts to communicate with other IPv6 hosts using existing IPv4 applications.The goal of this mechanism is the same as that of the Bump-in-the- stack mechanism, but this mechanism provides the translation method between the IPv4 APIs and IPv6 APIs. Thus, the goal is simply achieved without IP header translation. |
|
| |
| RFC 3421 | Select and Sort Extensions for the Service Location Protocol (SLP) |
| |
| Authors: | W. Zhao, H. Schulzrinne, E. Guttman, C. Bisdikian, W. Jerome. |
| Date: | November 2002 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3421 |
|
This document defines two extensions (Select and Sort) for theService Location Protocol (SLP). These extensions allow a User Agent(UA) to request that the Uniform Resource Locator (URL) entries in aService Reply (SrvRply) be limited to the specified number, or be sorted according to the specified sort key list. Using these two extensions together can facilitate discovering the best match, such as finding a service that has the maximum speed or the minimum load. |
|
| |
| RFC 3430 | Simple Network Management Protocol Over Transmission Control Protocol Transport Mapping |
| |
| Authors: | J. Schoenwaelder. |
| Date: | December 2002 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3430 |
|
This memo defines a transport mapping for using the Simple NetworkManagement Protocol (SNMP) over TCP. The transport mapping can be used with any version of SNMP. This document extends the transport mappings defined in STD 62, RFC 3417. |
|
| |
| RFC 3450 | Asynchronous Layered Coding (ALC) Protocol Instantiation |
| |
| Authors: | M. Luby, J. Gemmell, L. Vicisano, L. Rizzo, J. Crowcroft. |
| Date: | December 2002 |
| Formats: | txt html json |
| Obsoleted by: | RFC 5775 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3450 |
|
This document describes the Asynchronous Layered Coding (ALC) protocol, a massively scalable reliable content delivery protocol.Asynchronous Layered Coding combines the Layered Coding Transport(LCT) building block, a multiple rate congestion control building block and the Forward Error Correction (FEC) building block to provide congestion controlled reliable asynchronous delivery of content to an unlimited number of concurrent receivers from a single sender. |
|
| |
| RFC 3451 | Layered Coding Transport (LCT) Building Block |
| |
| Authors: | M. Luby, J. Gemmell, L. Vicisano, L. Rizzo, M. Handley, J. Crowcroft. |
| Date: | December 2002 |
| Formats: | txt html json |
| Obsoleted by: | RFC 5651 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3451 |
|
Layered Coding Transport (LCT) provides transport level support for reliable content delivery and stream delivery protocols. LCT is specifically designed to support protocols using IP multicast, but also provides support to protocols that use unicast. LCT is compatible with congestion control that provides multiple rate delivery to receivers and is also compatible with coding techniques that provide reliable delivery of content. |
|
| |
| RFC 3452 | Forward Error Correction (FEC) Building Block |
| |
| Authors: | M. Luby, L. Vicisano, J. Gemmell, L. Rizzo, M. Handley, J. Crowcroft. |
| Date: | December 2002 |
| Formats: | txt json html |
| Obsoleted by: | RFC 5052, RFC 5445 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3452 |
|
This document generally describes how to use Forward Error Correction(FEC) codes to efficiently provide and/or augment reliability for data transport. The primary focus of this document is the application of FEC codes to one-to-many reliable data transport usingIP multicast. This document describes what information is needed to identify a specific FEC code, what information needs to be communicated out-of-band to use the FEC code, and what information is needed in data packets to identify the encoding symbols they carry.The procedures for specifying FEC codes and registering them with theInternet Assigned Numbers Authority (IANA) are also described. This document should be read in conjunction with and uses the terminology of the companion document titled, "The Use of Forward ErrorCorrection (FEC) in Reliable Multicast". |
|
| |
| RFC 3465 | TCP Congestion Control with Appropriate Byte Counting (ABC) |
| |
| Authors: | M. Allman. |
| Date: | February 2003 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3465 |
|
This document proposes a small modification to the way TCP increases its congestion window. Rather than the traditional method of increasing the congestion window by a constant amount for each arriving acknowledgment, the document suggests basing the increase on the number of previously unacknowledged bytes each ACK covers. This change improves the performance of TCP, as well as closes a security hole TCP receivers can use to induce the sender into increasing the sending rate too rapidly. |
|
| |
| RFC 3522 | The Eifel Detection Algorithm for TCP |
| |
| Authors: | R. Ludwig, M. Meyer. |
| Date: | April 2003 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3522 |
|
The Eifel detection algorithm allows a TCP sender to detect a posteriori whether it has entered loss recovery unnecessarily. It requires that the TCP Timestamps option defined in RFC 1323 be enabled for a connection. The Eifel detection algorithm makes use of the fact that the TCP Timestamps option eliminates the retransmission ambiguity in TCP. Based on the timestamp of the first acceptable ACK that arrives during loss recovery, it decides whether loss recovery was entered unnecessarily. The Eifel detection algorithm provides a basis for future TCP enhancements. This includes response algorithms to back out of loss recovery by restoring a TCP sender's congestion control state. |
|
| |
| RFC 3528 | Mesh-enhanced Service Location Protocol (mSLP) |
| |
| Authors: | W. Zhao, H. Schulzrinne, E. Guttman. |
| Date: | April 2003 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3528 |
|
This document describes the Mesh-enhanced Service Location Protocol(mSLP). mSLP enhances the Service Location Protocol (SLP) with a scope-based fully-meshed peering Directory Agent (DA) architecture.Peer DAs exchange new service registrations in shared scopes via anti-entropy and direct forwarding. mSLP improves the reliability and consistency of SLP DA services, and simplifies Service Agent (SA) registrations in systems with multiple DAs. mSLP is backward compatible with SLPv2 and can be deployed incrementally. |
|
| |
| RFC 3529 | Using Extensible Markup Language-Remote Procedure Calling (XML-RPC) in Blocks Extensible Exchange Protocol (BEEP) |
| |
|
|
XML-RPC is an Extensible Markup Language-Remote Procedure Calling protocol that works over the Internet. It defines an XML format for messages that are transfered between clients and servers using HTTP.An XML-RPC message encodes either a procedure to be invoked by the server, along with the parameters to use in the invocation, or the result of an invocation. Procedure parameters and results can be scalars, numbers, strings, dates, etc.; they can also be complex record and list structures.
This document specifies a how to use the Blocks Extensible ExchangeProtocol (BEEP) to transfer messages encoded in the XML-RPC format between clients and servers. |
|
| |
| RFC 3561 | Ad hoc On-Demand Distance Vector (AODV) Routing |
| |
| Authors: | C. Perkins, E. Belding-Royer, S. Das. |
| Date: | July 2003 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3561 |
|
The Ad hoc On-Demand Distance Vector (AODV) routing protocol is intended for use by mobile nodes in an ad hoc network. It offers quick adaptation to dynamic link conditions, low processing and memory overhead, low network utilization, and determines unicast routes to destinations within the ad hoc network. It uses destination sequence numbers to ensure loop freedom at all times(even in the face of anomalous delivery of routing control messages), avoiding problems (such as "counting to infinity") associated with classical distance vector protocols. |
|
| |
| RFC 3618 | Multicast Source Discovery Protocol (MSDP) |
| |
| Authors: | B. Fenner, Ed., D. Meyer, Ed.. |
| Date: | October 2003 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3618 |
|
The Multicast Source Discovery Protocol (MSDP) describes a mechanism to connect multiple IP Version 4 Protocol Independent MulticastSparse-Mode (PIM-SM) domains together. Each PIM-SM domain uses its own independent Rendezvous Point (RP) and does not have to depend onRPs in other domains. This document reflects existing MSDP implementations. |
|
| |
| RFC 3626 | Optimized Link State Routing Protocol (OLSR) |
| |
| Authors: | T. Clausen, Ed., P. Jacquet, Ed.. |
| Date: | October 2003 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3626 |
|
This document describes the Optimized Link State Routing (OLSR) protocol for mobile ad hoc networks. The protocol is an optimization of the classical link state algorithm tailored to the requirements of a mobile wireless LAN. The key concept used in the protocol is that of multipoint relays (MPRs). MPRs are selected nodes which forward broadcast messages during the flooding process. This technique substantially reduces the message overhead as compared to a classical flooding mechanism, where every node retransmits each message when it receives the first copy of the message. In OLSR, link state information is generated only by nodes elected as MPRs. Thus, a second optimization is achieved by minimizing the number of control messages flooded in the network. As a third optimization, an MPR node may chose to report only links between itself and its MPR selectors. Hence, as contrary to the classic link state algorithm, partial link state information is distributed in the network. This information is then used for route calculation. OLSR provides optimal routes (in terms of number of hops). The protocol is particularly suitable for large and dense networks as the technique of MPRs works well in this context. |
|
| |
| RFC 3649 | HighSpeed TCP for Large Congestion Windows |
| |
| Authors: | S. Floyd. |
| Date: | December 2003 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3649 |
|
The proposals in this document are experimental. While they may be deployed in the current Internet, they do not represent a consensus that this is the best method for high-speed congestion control. In particular, we note that alternative experimental proposals are likely to be forthcoming, and it is not well understood how the proposals in this document will interact with such alternative proposals.
This document proposes HighSpeed TCP, a modification to TCP's congestion control mechanism for use with TCP connections with large congestion windows. The congestion control mechanisms of the currentStandard TCP constrains the congestion windows that can be achieved by TCP in realistic environments. For example, for a Standard TCP connection with 1500-byte packets and a 100 ms round-trip time, achieving a steady-state throughput of 10 Gbps would require an average congestion window of 83,333 segments, and a packet drop rate of at most one congestion event every 5,000,000,000 packets (or equivalently, at most one congestion event every 1 2/3 hours). This is widely acknowledged as an unrealistic constraint. To address this limitation of TCP, this document proposes HighSpeed TCP, and solicits experimentation and feedback from the wider community. |
|
| |
| RFC 3656 | The Mailbox Update (MUPDATE) Distributed Mailbox Database Protocol |
| |
|
|
As the demand for high-performance mail delivery agents increases, it becomes apparent that single-machine solutions are inadequate to the task, both because of capacity limits and that the failure of the single machine means a loss of mail delivery for all users. It is preferable to allow many machines to share the responsibility of mail delivery.
The Mailbox Update (MUPDATE) protocol allows a group of InternetMessage Access Protocol (IMAP) or Post Office Protocol - Version 3(POP3) servers to function with a unified mailbox namespace. This document is intended to serve as a reference guide to that protocol. |
|
| |
| RFC 3663 | Domain Administrative Data in Lightweight Directory Access Protocol (LDAP) |
| |
| Authors: | A. Newton. |
| Date: | December 2003 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3663 |
|
Domain registration data has typically been exposed to the general public via Nicname/Whois for administrative purposes. This document describes the Referral Lightweight Directory Access Protocol (LDAP)Service, an experimental service using LDAP and well-known LDAP types to make domain administrative data available. |
|
| |
| RFC 3682 | The Generalized TTL Security Mechanism (GTSM) |
| |
| Authors: | V. Gill, J. Heasley, D. Meyer. |
| Date: | February 2004 |
| Formats: | txt json html |
| Obsoleted by: | RFC 5082 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3682 |
|
The use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to protect a protocol stack from CPU-utilization based attacks has been proposed in many settings (see for example, RFC 2461). This document generalizes these techniques for use by other protocols such as BGP (RFC 1771), Multicast Source Discovery Protocol (MSDP),Bidirectional Forwarding Detection, and Label Distribution Protocol(LDP) (RFC 3036). While the Generalized TTL Security Mechanism(GTSM) is most effective in protecting directly connected protocol peers, it can also provide a lower level of protection to multi-hop sessions. GTSM is not directly applicable to protocols employing flooding mechanisms (e.g., multicast), and use of multi-hop GTSM should be considered on a case-by-case basis. |
|
| |
| RFC 3684 | Topology Dissemination Based on Reverse-Path Forwarding (TBRPF) |
| |
| Authors: | R. Ogier, F. Templin, M. Lewis. |
| Date: | February 2004 |
| Formats: | txt html json |
| Updated by: | RFC 9141 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3684 |
|
Topology Dissemination Based on Reverse-Path Forwarding (TBRPF) is a proactive, link-state routing protocol designed for mobile ad-hoc networks, which provides hop-by-hop routing along shortest paths to each destination. Each node running TBRPF computes a source tree(providing paths to all reachable nodes) based on partial topology information stored in its topology table, using a modification ofDijkstra's algorithm. To minimize overhead, each node reports only*part* of its source tree to neighbors. TBRPF uses a combination of periodic and differential updates to keep all neighbors informed of the reported part of its source tree. Each node also has the option to report additional topology information (up to the full topology), to provide improved robustness in highly mobile networks. TBRPF performs neighbor discovery using "differential" HELLO messages which report only *changes* in the status of neighbors. This results inHELLO messages that are much smaller than those of other link-state routing protocols such as OSPF. |
|
| |
| RFC 3695 | Compact Forward Error Correction (FEC) Schemes |
| |
|
|
This document introduces some Forward Error Correction (FEC) schemes that supplement the FEC schemes described in RFC 3452. The primary benefits of these additional FEC schemes are that they are designed for reliable bulk delivery of large objects using a more compact FECPayload ID, and they can be used to sequentially deliver blocks of an object of indeterminate length. Thus, they more flexibly support different delivery models with less packet header overhead.
This document also describes the Fully-Specified FEC scheme corresponding to FEC Encoding ID 0. This Fully-Specified FEC scheme requires no FEC coding and is introduced primarily to allow simple interoperability testing between different implementations of protocol instantiations that use the FEC building block. |
|
| |
| RFC 3708 | Using TCP Duplicate Selective Acknowledgement (DSACKs) and Stream Control Transmission Protocol (SCTP) Duplicate Transmission Sequence Numbers (TSNs) to Detect Spurious Retransmissions |
| |
| Authors: | E. Blanton, M. Allman. |
| Date: | February 2004 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3708 |
|
TCP and Stream Control Transmission Protocol (SCTP) provide notification of duplicate segment receipt through Duplicate SelectiveAcknowledgement (DSACKs) and Duplicate Transmission Sequence Number(TSN) notification, respectively. This document presents conservative methods of using this information to identify unnecessary retransmissions for various applications. |
|
| |
| RFC 3738 | Wave and Equation Based Rate Control (WEBRC) Building Block |
| |
| Authors: | M. Luby, V. Goyal. |
| Date: | April 2004 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3738 |
|
This document specifies Wave and Equation Based Rate Control (WEBRC), which provides rate and congestion control for data delivery. WEBRC is specifically designed to support protocols using IP multicast. It provides multiple-rate, congestion-controlled delivery to receivers, i.e., different receivers joined to the same session may be receiving packets at different rates depending on the bandwidths of their individual connections to the sender and on competing traffic along these connections. WEBRC requires no feedback from receivers to the sender, i.e., it is a completely receiver-driven congestion control protocol. Thus, it is designed to scale to potentially massive numbers of receivers attached to a session from a single sender.Furthermore, because each individual receiver adjusts to the available bandwidth between the sender and that receiver, there is the potential to deliver data to each individual receiver at the fastest possible rate for that receiver, even in a highly heterogeneous network architecture, using a single sender. |
|
| |
| RFC 3742 | Limited Slow-Start for TCP with Large Congestion Windows |
| |
| Authors: | S. Floyd. |
| Date: | March 2004 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3742 |
|
This document describes an optional modification for TCP's slow-start for use with TCP connections with large congestion windows. For TCP connections that are able to use congestion windows of thousands (or tens of thousands) of MSS-sized segments (for MSS the sender'sMAXIMUM SEGMENT SIZE), the current slow-start procedure can result in increasing the congestion window by thousands of segments in a single round-trip time. Such an increase can easily result in thousands of packets being dropped in one round-trip time. This is often counter-productive for the TCP flow itself, and is also hard on the rest of the traffic sharing the congested link. This note describesLimited Slow-Start as an optional mechanism for limiting the number of segments by which the congestion window is increased for one window of data during slow-start, in order to improve performance forTCP connections with large congestion windows. |
|
| |
| RFC 3780 | SMIng - Next Generation Structure of Management Information |
| |
| Authors: | F. Strauss, J. Schoenwaelder. |
| Date: | May 2004 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3780 |
|
This memo defines the base SMIng (Structure of ManagementInformation, Next Generation) language. SMIng is a data definition language that provides a protocol-independent representation for management information. Separate RFCs define mappings of SMIng to specific management protocols, including SNMP. |
|
| |
| RFC 3781 | Next Generation Structure of Management Information (SMIng) Mappings to the Simple Network Management Protocol (SNMP) |
| |
| Authors: | F. Strauss, J. Schoenwaelder. |
| Date: | May 2004 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3781 |
|
SMIng (Structure of Management Information, Next Generation)(RFC3780), is a protocol-independent data definition language for management information. This memo defines an SMIng language extension that specifies the mapping of SMIng definitions of identities, classes, and their attributes and events to dedicated definitions of nodes, scalar objects, tables and columnar objects, and notifications, for application to the SNMP management framework. |
|
| |
| RFC 3832 | Remote Service Discovery in the Service Location Protocol (SLP) via DNS SRV |
| |
| Authors: | W. Zhao, H. Schulzrinne, E. Guttman, C. Bisdikian, W. Jerome. |
| Date: | July 2004 |
| Formats: | txt json html |
| Updated by: | RFC 8553 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3832 |
|
Remote service discovery refers to discovering desired services in given remote (i.e., non-local) DNS domains. This document describes remote service discovery in the Service Location Protocol (SLP) viaDNS SRV. It defines the DNS SRV Resource Records for SLP DirectoryAgent services, discusses various issues in using SLP and DNS SRV together for remote service discovery, and gives the steps for discovering desired services in remote DNS domains. |
|
| |
| RFC 3926 | FLUTE - File Delivery over Unidirectional Transport |
| |
| Authors: | T. Paila, M. Luby, R. Lehtonen, V. Roca, R. Walsh. |
| Date: | October 2004 |
| Formats: | txt html json |
| Obsoleted by: | RFC 6726 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3926 |
|
This document defines FLUTE, a protocol for the unidirectional delivery of files over the Internet, which is particularly suited to multicast networks. The specification builds on Asynchronous LayeredCoding, the base protocol designed for massively scalable multicast distribution. |
|
| |
| RFC 3929 | Alternative Decision Making Processes for Consensus-Blocked Decisions in the IETF |
| |
|
|
This document proposes an experimental set of alternative decision- making processes for use in IETF working groups. There are a small number of cases in IETF working groups in which the group has come to consensus that a particular decision must be made but cannot agree on the decision itself. This document describes alternative mechanisms for reaching a decision in those cases. This is not meant to provide an exhaustive list, but to provide a known set of tools that can be used when needed. |
|
| |
| RFC 3940 | Negative-acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol |
| |
| Authors: | B. Adamson, C. Bormann, M. Handley, J. Macker. |
| Date: | November 2004 |
| Formats: | txt html json |
| Obsoleted by: | RFC 5740 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3940 |
|
This document describes the messages and procedures of the Negative- acknowledgment (NACK) Oriented Reliable Multicast (NORM) protocol.This protocol is designed to provide end-to-end reliable transport of bulk data objects or streams over generic IP multicast routing and forwarding services. NORM uses a selective, negative acknowledgment mechanism for transport reliability and offers additional protocol mechanisms to allow for operation with minimal "a priori" coordination among senders and receivers. A congestion control scheme is specified to allow the NORM protocol to fairly share available network bandwidth with other transport protocols such asTransmission Control Protocol (TCP). It is capable of operating with both reciprocal multicast routing among senders and receivers and with asymmetric connectivity (possibly a unicast return path) between the senders and receivers. The protocol offers a number of features to allow different types of applications or possibly other higher level transport protocols to utilize its service in different ways.The protocol leverages the use of FEC-based repair and other IETF reliable multicast transport (RMT) building blocks in its design. |
|
| |
| RFC 3941 | Negative-Acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Building Blocks |
| |
| Authors: | B. Adamson, C. Bormann, M. Handley, J. Macker. |
| Date: | November 2004 |
| Formats: | txt html json |
| Obsoleted by: | RFC 5401 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3941 |
|
This document discusses the creation of negative-acknowledgment(NACK)-oriented reliable multicast (NORM) protocols. The rationale for NORM goals and assumptions are presented. Technical challenges for NACK-oriented (and in some cases general) reliable multicast protocol operation are identified. These goals and challenges are resolved into a set of functional "building blocks" that address different aspects of NORM protocol operation. It is anticipated that these building blocks will be useful in generating different instantiations of reliable multicast protocols. |
|
| |
| RFC 3951 | Internet Low Bit Rate Codec (iLBC) |
| |
| Authors: | S. Andersen, A. Duric, H. Astrom, R. Hagen, W. Kleijn, J. Linden. |
| Date: | December 2004 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3951 |
|
This document specifies a speech codec suitable for robust voice communication over IP. The codec is developed by Global IP Sound(GIPS). It is designed for narrow band speech and results in a payload bit rate of 13.33 kbit/s for 30 ms frames and 15.20 kbit/s for 20 ms frames. The codec enables graceful speech quality degradation in the case of lost frames, which occurs in connection with lost or delayed IP packets. |
|
| |
| RFC 3952 | Real-time Transport Protocol (RTP) Payload Format for internet Low Bit Rate Codec (iLBC) Speech |
| |
| Authors: | A. Duric, S. Andersen. |
| Date: | December 2004 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3952 |
|
This document describes the Real-time Transport Protocol (RTP) payload format for the internet Low Bit Rate Codec (iLBC) Speech developed by Global IP Sound (GIPS). Also, within the document there are included necessary details for the use of iLBC with MIME andSession Description Protocol (SDP). |
|
| |
| RFC 3973 | Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised) |
| |
|
|
This document specifies Protocol Independent Multicast - Dense Mode(PIM-DM). PIM-DM is a multicast routing protocol that uses the underlying unicast routing information base to flood multicast datagrams to all multicast routers. Prune messages are used to prevent future messages from propagating to routers without group membership information. |
|
| |
| RFC 3988 | Maximum Transmission Unit Signalling Extensions for the Label Distribution Protocol |
| |
| Authors: | B. Black, K. Kompella. |
| Date: | January 2005 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 3988 |
|
Proper functioning of RFC 1191 path Maximum Transmission Unit (MTU) discovery requires that IP routers have knowledge of the MTU for each link to which they are connected. As currently specified, the LabelDistribution Protocol (LDP) does not have the ability to signal theMTU for a Label Switched Path (LSP) to the ingress Label SwitchingRouter (LSR). In the absence of this functionality, the MTU for eachLSP must be statically configured by network operators or by equivalent off-line mechanisms.
This document specifies experimental extensions to LDP in support ofLSP MTU discovery. |
|
| |
| RFC 4045 | Extensions to Support Efficient Carrying of Multicast Traffic in Layer-2 Tunneling Protocol (L2TP) |
| |
| Authors: | G. Bourdon. |
| Date: | April 2005 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4045 |
|
The Layer Two Tunneling Protocol (L2TP) provides a method for tunneling PPP packets. This document describes an extension to L2TP, to make efficient use of L2TP tunnels within the context of deploying multicast services whose data will have to be conveyed by these tunnels. |
|
| |
| RFC 4049 | BinaryTime: An Alternate Format for Representing Date and Time in ASN.1 |
| |
|
|
This document specifies a new ASN.1 type for representing time:BinaryTime. This document also specifies an alternate to the signing-time attribute for use with the Cryptographic Message Syntax(CMS) SignedData and AuthenticatedData content types; the binary- signing-time attribute uses BinaryTime. CMS and the signing-time attribute are defined in RFC 3852. |
|
| |
| RFC 4065 | Instructions for Seamoby and Experimental Mobility Protocol IANA Allocations |
| |
| Authors: | J. Kempf. |
| Date: | July 2005 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4065 |
|
The Seamoby Candidate Access Router Discovery (CARD) protocol and theContext Transfer Protocol (CXTP) are experimental protocols designed to accelerate IP handover between wireless access routers. These protocols require IANA allocations for ICMP type and options, StreamControl Transmission Protocol (SCTP) Payload Protocol Identifiers, port numbers, and registries for certain formatted message options.This document contains instructions to IANA about which allocations are required for the Seamoby protocols. The ICMP subtype extension format for Seamoby has been additionally designed so that it can be utilized by other experimental mobility protocols, and the SCTP port number is also available for other experimental mobility protocols. |
|
| |
| RFC 4066 | Candidate Access Router Discovery (CARD) |
| |
| Authors: | M. Liebsch, Ed., A. Singh, Ed., H. Chaskar, D. Funato, E. Shim. |
| Date: | July 2005 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4066 |
|
To enable seamless IP-layer handover of a mobile node (MN) from one access router (AR) to another, the MN is required to discover the identities and capabilities of candidate ARs (CARs) for handover prior to the initiation of the handover. The act of discovery ofCARs has two aspects: identifying the IP addresses of the CARs and finding their capabilities. This process is called "candidate access router discovery" (CARD). At the time of IP-layer handover, the CAR, whose capabilities are a good match to the preferences of the MN, is chosen as the target AR for handover. The protocol described in this document allows a mobile node to perform CARD. |
|
| |
| RFC 4067 | Context Transfer Protocol (CXTP) |
| |
| Authors: | J. Loughney, Ed., M. Nakhjiri, C. Perkins, R. Koodli. |
| Date: | July 2005 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4067 |
|
This document presents the Context Transfer Protocol (CXTP) that enables authorized context transfers. Context transfers allow better support for node based mobility so that the applications running on mobile nodes can operate with minimal disruption. Key objectives are to reduce latency and packet losses, and to avoid the re-initiation of signaling to and from the mobile node. |
|
| |
| RFC 4068 | Fast Handovers for Mobile IPv6 |
| |
|
|
Mobile IPv6 enables a Mobile Node to maintain its connectivity to theInternet when moving from one Access Router to another, a process referred to as handover. During handover, there is a period during which the Mobile Node is unable to send or receive packets because of link switching delay and IP protocol operations. This "handover latency" resulting from standard Mobile IPv6 procedures, namely movement detection, new Care of Address configuration, and BindingUpdate, is often unacceptable to real-time traffic such as Voice overIP. Reducing the handover latency could be beneficial to non-real- time, throughput-sensitive applications as well. This document specifies a protocol to improve handover latency due to Mobile IPv6 procedures. This document does not address improving the link switching latency. |
|
| |
| RFC 4125 | Maximum Allocation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering |
| |
| Authors: | F. Le Faucheur, W. Lai. |
| Date: | June 2005 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4125 |
|
This document provides specifications for one Bandwidth ConstraintsModel for Diffserv-aware MPLS Traffic Engineering, which is referred to as the Maximum Allocation Model. |
|
| |
| RFC 4126 | Max Allocation with Reservation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering & Performance Comparisons |
| |
|
|
This document complements the Diffserv-aware MPLS Traffic Engineering(DS-TE) requirements document by giving a functional specification for the Maximum Allocation with Reservation (MAR) BandwidthConstraints Model. Assumptions, applicability, and examples of the operation of the MAR Bandwidth Constraints Model are presented. MAR performance is analyzed relative to the criteria for selecting aBandwidth Constraints Model, in order to provide guidance to user implementation of the model in their networks. |
|
| |
| RFC 4127 | Russian Dolls Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering |
| |
| Authors: | F. Le Faucheur, Ed.. |
| Date: | June 2005 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4127 |
|
This document provides specifications for one Bandwidth ConstraintsModel for Diffserv-aware MPLS Traffic Engineering, which is referred to as the Russian Dolls Model. |
|
| |
| RFC 4138 | Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP and the Stream Control Transmission Protocol (SCTP) |
| |
|
|
Spurious retransmission timeouts cause suboptimal TCP performance because they often result in unnecessary retransmission of the last window of data. This document describes the F-RTO detection algorithm for detecting spurious TCP retransmission timeouts. F-RTO is a TCP sender-only algorithm that does not require any TCP options to operate. After retransmitting the first unacknowledged segment triggered by a timeout, the F-RTO algorithm of the TCP sender monitors the incoming acknowledgments to determine whether the timeout was spurious. It then decides whether to send new segments or retransmit unacknowledged segments. The algorithm effectively helps to avoid additional unnecessary retransmissions and thereby improves TCP performance in the case of a spurious timeout. TheF-RTO algorithm can also be applied to the Stream ControlTransmission Protocol (SCTP). |
|
| |
| RFC 4140 | Hierarchical Mobile IPv6 Mobility Management (HMIPv6) |
| |
| Authors: | H. Soliman, C. Castelluccia, K. El Malki, L. Bellier. |
| Date: | August 2005 |
| Formats: | txt html json |
| Obsoleted by: | RFC 5380 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4140 |
|
This document introduces extensions to Mobile IPv6 and IPv6 NeighbourDiscovery to allow for local mobility handling. Hierarchical mobility management for Mobile IPv6 is designed to reduce the amount of signalling between the Mobile Node, its Correspondent Nodes, and its Home Agent. The Mobility Anchor Point (MAP) described in this document can also be used to improve the performance of Mobile IPv6 in terms of handover speed. |
|
| |
| RFC 4214 | Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) |
| |
| Authors: | F. Templin, T. Gleeson, M. Talwar, D. Thaler. |
| Date: | October 2005 |
| Formats: | txt html json |
| Obsoleted by: | RFC 5214 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4214 |
|
The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) connectsIPv6 hosts/routers over IPv4 networks. ISATAP views the IPv4 network as a link layer for IPv6 and views other nodes on the network as potential IPv6 hosts/routers. ISATAP supports an automatic tunneling abstraction similar to the Non-Broadcast Multiple Access (NBMA) model. |
|
| |
| RFC 4316 | Datatypes for Web Distributed Authoring and Versioning (WebDAV) Properties |
| |
| Authors: | J. Reschke. |
| Date: | December 2005 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4316 |
|
This specification extends the Web Distributed Authoring andVersioning Protocol (WebDAV) to support datatyping. Protocol elements are defined to let clients and servers specify the datatype, and to instruct the WebDAV method PROPFIND to return datatype information. |
|
| |
| RFC 4324 | Calendar Access Protocol (CAP) |
| |
| Authors: | D. Royer, G. Babics, S. Mansour. |
| Date: | December 2005 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4324 |
|
The Calendar Access Protocol (CAP) described in this memo permits aCalendar User (CU) to utilize a Calendar User Agent (CUA) to access an iCAL-based Calendar Store (CS). At the time of this writing, three vendors are implementing CAP, but it has already been determined that some changes are needed. In order to get implementation experience, the participants felt that a CAP specification is needed to preserve many years of work. Many properties in CAP which have had many years of debate, can be used by other iCalendar protocols. |
|
| |
| RFC 4386 | Internet X.509 Public Key Infrastructure Repository Locator Service |
| |
| Authors: | S. Boeyen, P. Hallam-Baker. |
| Date: | February 2006 |
| Formats: | txt json html |
| Updated by: | RFC 8553 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4386 |
|
This document defines a Public Key Infrastructure (PKI) repository locator service. The service makes use of DNS SRV records defined in accordance with RFC 2782. The service enables certificate-using systems to locate PKI repositories. |
|
| |
| RFC 4389 | Neighbor Discovery Proxies (ND Proxy) |
| |
| Authors: | D. Thaler, M. Talwar, C. Patel. |
| Date: | April 2006 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4389 |
|
Bridging multiple links into a single entity has several operational advantages. A single subnet prefix is sufficient to support multiple physical links. There is no need to allocate subnet numbers to the different networks, simplifying management. Bridging some types of media requires network-layer support, however. This document describes these cases and specifies the IP-layer support that enables bridging under these circumstances. |
|
| |
| RFC 4408 | Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1 |
| |
|
|
E-mail on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction on what a sending host can use as the reverse-path of a message or the domain given on the SMTP HELO/EHLO commands. This document describes version 1 of the Sender Policy Framework (SPF) protocol, whereby a domain may explicitly authorize the hosts that are allowed to use its domain name, and a receiving host may check such authorization. |
|
| |
| RFC 4410 | Selectively Reliable Multicast Protocol (SRMP) |
| |
| Authors: | M. Pullen, F. Zhao, D. Cohen. |
| Date: | February 2006 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4410 |
|
The Selectively Reliable Multicast Protocol (SRMP) is a transport protocol, intended to deliver a mix of reliable and best-effort messages in an any-to-any multicast environment, where the best- effort traffic occurs in significantly greater volume than the reliable traffic and therefore can carry sequence numbers of reliable messages for loss detection. SRMP is intended for use in a distributed simulation application environment, where only the latest value of reliable transmission for any particular data identifier requires delivery. SRMP has two sublayers: a bundling sublayer handling message aggregation and congestion control, and aSelectively Reliable Transport (SRT) sublayer. Selection between reliable and best-effort messages is performed by the application. |
|
| |
| RFC 4437 | Web Distributed Authoring and Versioning (WebDAV) Redirect Reference Resources |
| |
| Authors: | J. Whitehead, G. Clemm, J. Reschke, Ed.. |
| Date: | March 2006 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4437 |
|
This specification defines an extension to Web Distributed Authoring and Versioning (WebDAV) to allow clients to author HTTP redirect reference resources whose default response is an HTTP/1.1 3xx(Redirection) status code. A redirect reference makes it possible to access the target resourced indirectly through any URI mapped to the redirect reference resource. This specification does not address remapping of trees of resources or regular expression based redirections. There are no integrity guarantees associated with redirect reference resources. Other mechanisms can also be used to achieve the same functionality as this specification. This specification allows operators to experiment with this mechanism and develop experience on what is the best approach to the problem. |
|
| |
| RFC 4471 | Derivation of DNS Name Predecessor and Successor |
| |
| Authors: | G. Sisson, B. Laurie. |
| Date: | September 2006 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4471 |
|
This document describes two methods for deriving the canonically- ordered predecessor and successor of a DNS name. These methods may be used for dynamic NSEC resource record synthesis, enabling security-aware name servers to provide authenticated denial of existence without disclosing other owner names in a DNSSEC secured zone. |
|
| |
| RFC 4478 | Repeated Authentication in Internet Key Exchange (IKEv2) Protocol |
| |
| Authors: | Y. Nir. |
| Date: | April 2006 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4478 |
|
This document extends the Internet Key Exchange (IKEv2) Protocol document [IKEv2]. With some IPsec peers, particularly in the remote access scenario, it is desirable to repeat the mutual authentication periodically. The purpose of this is to limit the time that security associations (SAs) can be used by a third party who has gained control of the IPsec peer. This document describes a mechanism to perform this function. |
|
| |
| RFC 4498 | The Managed Object Aggregation MIB |
| |
| Authors: | G. Keeni. |
| Date: | May 2006 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4498 |
|
This memo defines a portion of the Management Information Base (MIB), the Aggregation MIB modules, for use with network management protocols in the Internet community. In particular, the AggregationMIB modules will be used to configure a network management agent to aggregate the values of a user-specified set of Managed Object instances and to service queries related to the aggregated ManagedObject instances. |
|
| |
| RFC 4531 | Lightweight Directory Access Protocol (LDAP) Turn Operation |
| |
|
|
This specification describes a Lightweight Directory Access Protocol(LDAP) extended operation to reverse (or "turn") the roles of client and server for subsequent protocol exchanges in the session, or to enable each peer to act as both client and server with respect to the other. |
|
| |
| RFC 4533 | The Lightweight Directory Access Protocol (LDAP) Content Synchronization Operation |
| |
| Authors: | K. Zeilenga, J.H. Choi. |
| Date: | June 2006 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4533 |
|
This specification describes the Lightweight Directory AccessProtocol (LDAP) Content Synchronization Operation. The operation allows a client to maintain a copy of a fragment of the DirectoryInformation Tree (DIT). It supports both polling for changes and listening for changes. The operation is defined as an extension of the LDAP Search Operation. |
|
| |
| RFC 4540 | NEC's Simple Middlebox Configuration (SIMCO) Protocol Version 3.0 |
| |
| Authors: | M. Stiemerling, J. Quittek, C. Cadar. |
| Date: | May 2006 |
| Formats: | txt html json |
| Updated by: | RFC 8996 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4540 |
|
This document describes a protocol for controlling middleboxes such as firewalls and network address translators. It is a fully compliant implementation of the Middlebox Communications (MIDCOM) semantics described in RFC 3989. Compared to earlier experimental versions of the SIMCO protocol, this version (3.0) uses binary message encodings in order to reduce resource requirements. |
|
| |
| RFC 4620 | IPv6 Node Information Queries |
| |
| Authors: | M. Crawford, B. Haberman, Ed.. |
| Date: | August 2006 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4620 |
|
This document describes a protocol for asking an IPv6 node to supply certain network information, such as its hostname or fully-qualified domain name. IPv6 implementation experience has shown that direct queries for a hostname are useful, and a direct query mechanism for other information has been found useful in serverless environments and for debugging. |
|
| |
| RFC 4624 | Multicast Source Discovery Protocol (MSDP) MIB |
| |
| Authors: | B. Fenner, D. Thaler. |
| Date: | October 2006 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4624 |
|
This memo defines an experimental portion of the ManagementInformation Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing Multicast Source Discovery Protocol (MSDP) (RFC3618) speakers. |
|
| |
| RFC 4633 | Experiment in Long-Term Suspensions From Internet Engineering Task Force (IETF) Mailing Lists |
| |
|
|
Discussion in the community has begun to question whether RFC 3683 and RFC 3934 provide the appropriate flexibility for managingInternet Engineering Task Force (IETF) mailing lists. This document is an RFC 3933 experiment designed to allow the community to experiment with a broader set of tools for mailing list management while trying to determine what the long-term guidelines should be. |
|
| |
| RFC 4653 | Improving the Robustness of TCP to Non-Congestion Events |
| |
| Authors: | S. Bhandarkar, A. L. N. Reddy, M. Allman, E. Blanton. |
| Date: | August 2006 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4653 |
|
This document specifies Non-Congestion Robustness (NCR) for TCP. In the absence of explicit congestion notification from the network, TCP uses loss as an indication of congestion. One of the ways TCP detects loss is using the arrival of three duplicate acknowledgments.However, this heuristic is not always correct, notably in the case when network paths reorder segments (for whatever reason), resulting in degraded performance. TCP-NCR is designed to mitigate this degraded performance by increasing the number of duplicate acknowledgments required to trigger loss recovery, based on the current state of the connection, in an effort to better disambiguate true segment loss from segment reordering. This document specifies the changes to TCP, as well as the costs and benefits of these modifications. |
|
| |
| RFC 4654 | TCP-Friendly Multicast Congestion Control (TFMCC): Protocol Specification |
| |
| Authors: | J. Widmer, M. Handley. |
| Date: | August 2006 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4654 |
|
This document specifies TCP-Friendly Multicast Congestion Control(TFMCC). TFMCC is a congestion control mechanism for multicast transmissions in a best-effort Internet environment. It is a single-rate congestion control scheme, where the sending rate is adapted to the receiver experiencing the worst network conditions.TFMCC is reasonably fair when competing for bandwidth with TCP flows and has a relatively low variation of throughput over time, making it suitable for applications where a relatively smooth sending rate is of importance, such as streaming media. |
|
| |
| RFC 4707 | Netnews Administration System (NAS) |
| |
| Authors: | P. Grau, V. Heinau, H. Schlichting, R. Schuettler. |
| Date: | October 2006 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4707 |
|
The Netnews Administration System (NAS) is a framework to simplify the administration and usage of network news (also known as Netnews) on the Internet. Data for the administration of newsgroups and hierarchies are kept in a distributed hierarchical database and are available through a client-server protocol.
The database is accessible by news servers, news administrators, and news readers. News servers can update their configuration automatically; administrators are able to get the data manually.News reader programs are able to get certain information from an NAS server, automatically or at a user's discretion, which provides detailed information about groups and hierarchies to the user.
NAS is usable in coexistence with the current, established process of control messages; an unwanted interference is impossible.Furthermore, NAS is able to reflect the somewhat chaotic structure ofUsenet in a hierarchical database. NAS can be used without modification of existing news relay, news server, or news reader software; however, some tasks will be better accomplished with NAS- compliant software. |
|
| |
| RFC 4728 | The Dynamic Source Routing Protocol (DSR) for Mobile Ad Hoc Networks for IPv4 |
| |
| Authors: | D. Johnson, Y. Hu, D. Maltz. |
| Date: | February 2007 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4728 |
|
The Dynamic Source Routing protocol (DSR) is a simple and efficient routing protocol designed specifically for use in multi-hop wireless ad hoc networks of mobile nodes. DSR allows the network to be completely self-organizing and self-configuring, without the need for any existing network infrastructure or administration. The protocol is composed of the two main mechanisms of "Route Discovery" and"Route Maintenance", which work together to allow nodes to discover and maintain routes to arbitrary destinations in the ad hoc network.All aspects of the protocol operate entirely on demand, allowing the routing packet overhead of DSR to scale automatically to only what is needed to react to changes in the routes currently in use. The protocol allows multiple routes to any destination and allows each sender to select and control the routes used in routing its packets, for example, for use in load balancing or for increased robustness.Other advantages of the DSR protocol include easily guaranteed loop- free routing, operation in networks containing unidirectional links, use of only "soft state" in routing, and very rapid recovery when routes in the network change. The DSR protocol is designed mainly for mobile ad hoc networks of up to about two hundred nodes and is designed to work well even with very high rates of mobility. This document specifies the operation of the DSR protocol for routing unicast IPv4 packets. |
|
| |
| RFC 4739 | Multiple Authentication Exchanges in the Internet Key Exchange (IKEv2) Protocol |
| |
| Authors: | P. Eronen, J. Korhonen. |
| Date: | November 2006 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4739 |
|
The Internet Key Exchange (IKEv2) protocol supports several mechanisms for authenticating the parties, including signatures with public-key certificates, shared secrets, and ExtensibleAuthentication Protocol (EAP) methods. Currently, each endpoint uses only one of these mechanisms to authenticate itself. This document specifies an extension to IKEv2 that allows the use of multiple authentication exchanges, using either different mechanisms or the same mechanism. This extension allows, for instance, performing certificate-based authentication of the client host followed by anEAP authentication of the user. When backend authentication servers are used, they can belong to different administrative domains, such as the network access provider and the service provider. |
|
| |
| RFC 4764 | The EAP-PSK Protocol: A Pre-Shared Key Extensible Authentication Protocol (EAP) Method |
| |
| Authors: | F. Bersani, H. Tschofenig. |
| Date: | January 2007 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4764 |
|
This document specifies EAP-PSK, an Extensible AuthenticationProtocol (EAP) method for mutual authentication and session key derivation using a Pre-Shared Key (PSK). EAP-PSK provides a protected communication channel when mutual authentication is successful for both parties to communicate over. This document describes the use of this channel only for protected exchange of result indications, but future EAP-PSK extensions may use the channel for other purposes. EAP-PSK is designed for authentication over insecure networks such as IEEE 802.11. |
|
| |
| RFC 4765 | The Intrusion Detection Message Exchange Format (IDMEF) |
| |
| Authors: | H. Debar, D. Curry, B. Feinstein. |
| Date: | March 2007 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4765 |
|
The purpose of the Intrusion Detection Message Exchange Format(IDMEF) is to define data formats and exchange procedures for sharing information of interest to intrusion detection and response systems and to the management systems that may need to interact with them.
This document describes a data model to represent information exported by intrusion detection systems and explains the rationale for using this model. An implementation of the data model in theExtensible Markup Language (XML) is presented, an XML Document TypeDefinition is developed, and examples are provided. |
|
| |
| RFC 4767 | The Intrusion Detection Exchange Protocol (IDXP) |
| |
| Authors: | B. Feinstein, G. Matthews. |
| Date: | March 2007 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4767 |
|
This memo describes the Intrusion Detection Exchange Protocol (IDXP), an application-level protocol for exchanging data between intrusion detection entities. IDXP supports mutual-authentication, integrity, and confidentiality over a connection-oriented protocol. The protocol provides for the exchange of IDMEF messages, unstructured text, and binary data. The IDMEF message elements are described inRFC 4765, "The Intrusion Detection Message Exchange Format (IDMEF)", a companion document of the Intrusion Detection Exchange FormatWorking Group (IDWG) of the IETF. |
|
| |
| RFC 4782 | Quick-Start for TCP and IP |
| |
| Authors: | S. Floyd, M. Allman, A. Jain, P. Sarolahti. |
| Date: | January 2007 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4782 |
|
This document specifies an optional Quick-Start mechanism for transport protocols, in cooperation with routers, to determine an allowed sending rate at the start and, at times, in the middle of a data transfer (e.g., after an idle period). While Quick-Start is designed to be used by a range of transport protocols, in this document we only specify its use with TCP. Quick-Start is designed to allow connections to use higher sending rates when there is significant unused bandwidth along the path, and the sender and all of the routers along the path approve the Quick-Start Request.
This document describes many paths where Quick-Start Requests would not be approved. These paths include all paths containing routers,IP tunnels, MPLS paths, and the like that do not support Quick-Start. These paths also include paths with routers or middleboxes that drop packets containing IP options. Quick-Start Requests could be difficult to approve over paths that include multi-access layer- two networks. This document also describes environments where theQuick-Start process could fail with false positives, with the sender incorrectly assuming that the Quick-Start Request had been approved by all of the routers along the path. As a result of these concerns, and as a result of the difficulties and seeming absence of motivation for routers, such as core routers to deploy Quick-Start, Quick-Start is being proposed as a mechanism that could be of use in controlled environments, and not as a mechanism that would be intended or appropriate for ubiquitous deployment in the global Internet. |
|
| |
| RFC 4813 | OSPF Link-Local Signaling |
| |
| Authors: | B. Friedman, L. Nguyen, A. Roy, D. Yeung, A. Zinin. |
| Date: | March 2007 |
| Formats: | txt html json |
| Obsoleted by: | RFC 5613 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4813 |
|
OSPF is a link-state intra-domain routing protocol used in IP networks. OSPF routers exchange information on a link using packets that follow a well-defined format. The format of OSPF packets is not flexible enough to enable applications to exchange arbitrary data, which may be necessary in certain situations. This memo describes a vendor-specific, backward-compatible technique to perform link-local signaling, i.e., exchange arbitrary data on a link. |
|
| |
| RFC 4828 | TCP Friendly Rate Control (TFRC): The Small-Packet (SP) Variant |
| |
| Authors: | S. Floyd, E. Kohler. |
| Date: | April 2007 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4828 |
|
This document proposes a mechanism for further experimentation, but not for widespread deployment at this time in the global Internet.
TCP-Friendly Rate Control (TFRC) is a congestion control mechanism for unicast flows operating in a best-effort Internet environment(RFC 3448). TFRC was intended for applications that use a fixed packet size, and was designed to be reasonably fair when competing for bandwidth with TCP connections using the same packet size. This document proposes TFRC-SP, a Small-Packet (SP) variant of TFRC, that is designed for applications that send small packets. The design goal for TFRC-SP is to achieve the same bandwidth in bps (bits per second) as a TCP flow using packets of up to 1500 bytes. TFRC-SP enforces a minimum interval of 10 ms between data packets to prevent a single flow from sending small packets arbitrarily frequently.
Flows using TFRC-SP compete reasonably fairly with large-packet TCP and TFRC flows in environments where large-packet flows and small- packet flows experience similar packet drop rates. However, in environments where small-packet flows experience lower packet drop rates than large-packet flows (e.g., with Drop-Tail queues in units of bytes), TFRC-SP can receive considerably more than its share of the bandwidth. |
|
| |
| RFC 4843 | An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID) |
| |
| Authors: | P. Nikander, J. Laganier, F. Dupont. |
| Date: | April 2007 |
| Formats: | txt json html |
| Obsoleted by: | RFC 7343 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4843 |
|
This document introduces Overlay Routable Cryptographic HashIdentifiers (ORCHID) as a new, experimental class of IPv6-address- like identifiers. These identifiers are intended to be used as endpoint identifiers at applications and Application ProgrammingInterfaces (API) and not as identifiers for network location at theIP layer, i.e., locators. They are designed to appear as application layer entities and at the existing IPv6 APIs, but they should not appear in actual IPv6 headers. To make them more like vanilla IPv6 addresses, they are expected to be routable at an overlay level.Consequently, while they are considered non-routable addresses from the IPv6 layer point-of-view, all existing IPv6 applications are expected to be able to use them in a manner compatible with currentIPv6 addresses.
This document requests IANA to allocate a temporary prefix out of theIPv6 addressing space for Overlay Routable Cryptographic HashIdentifiers. By default, the prefix will be returned to IANA in2014, with continued use requiring IETF consensus. |
|
| |
| RFC 4857 | Mobile IPv4 Regional Registration |
| |
| Authors: | E. Fogelstroem, A. Jonsson, C. Perkins. |
| Date: | June 2007 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4857 |
|
Using Mobile IP, a mobile node registers with its home agent each time it changes care-of address. This document describes a new kind of "regional registrations", i.e., registrations local to the visited domain. The regional registrations are performed via a new network entity called a Gateway Foreign Agent (GFA) and introduce a layer of hierarchy in the visited domain. Regional registrations reduce the number of signaling messages to the home network, and reduce the signaling delay when a mobile node moves from one foreign agent to another within the same visited domain. This document is an optional extension to the Mobile IPv4 protocol. |
|
| |
| RFC 4881 | Low-Latency Handoffs in Mobile IPv4 |
| |
| Authors: | K. El Malki, Ed.. |
| Date: | June 2007 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4881 |
|
Mobile IPv4 describes how a Mobile Node can perform IPv4-layer handoffs between subnets served by different Foreign Agents. In certain cases, the latency involved in these handoffs can be above the threshold required for the support of delay-sensitive or real- time services. The aim of this document is to present two methods to achieve low-latency Mobile IPv4 handoffs. In addition, a combination of these two methods is described. The described techniques allow greater support for real-time services on a Mobile IPv4 network by minimizing the period of time when a Mobile Node is unable to send or receive IPv4 packets due to the delay in the Mobile IPv4 Registration process. |
|
| |
| RFC 4908 | Multi-homing for small scale fixed network Using Mobile IP and NEMO |
| |
| Authors: | K. Nagami, S. Uda, N. Ogashiwa, H. Esaki, R. Wakikawa, H. Ohnishi. |
| Date: | June 2007 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4908 |
|
Multihoming technology improves the availability of host and network connectivity. Since the behaviors of fixed and mobile networks differ, distinct architectures for each have been discussed and proposed. This document proposes a common architecture for both mobile and fixed networking environments, using mobile IP (RFC 3775) and Network Mobility (NEMO; RFC 3963). The proposed architecture requires a modification of mobile IP and NEMO so that multiple Care- of Addresses (CoAs) can be used. In addition, multiple Home Agents(HAs) that are located in different places are required for redundancy. |
|
| |
| RFC 4910 | Robust XML Encoding Rules (RXER) for Abstract Syntax Notation One (ASN.1) |
| |
| Authors: | S. Legg, D. Prager. |
| Date: | July 2007 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4910 |
|
This document defines a set of Abstract Syntax Notation One (ASN.1) encoding rules, called the Robust XML Encoding Rules or RXER, that produce an Extensible Markup Language (XML) representation for values of any given ASN.1 data type. Rules for producing a canonical RXER encoding are also defined. |
|
| |
| RFC 4911 | Encoding Instructions for the Robust XML Encoding Rules (RXER) |
| |
| Authors: | S. Legg. |
| Date: | July 2007 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4911 |
|
This document defines encoding instructions that may be used in anAbstract Syntax Notation One (ASN.1) specification to alter how ASN.1 values are encoded by the Robust XML Encoding Rules (RXER) andCanonical Robust XML Encoding Rules (CRXER), for example, to encode a component of an ASN.1 value as an Extensible Markup Language (XML) attribute rather than as a child element. Some of these encoding instructions also affect how an ASN.1 specification is translated into an Abstract Syntax Notation X (ASN.X) specification. Encoding instructions that allow an ASN.1 specification to reference definitions in other XML schema languages are also defined. |
|
| |
| RFC 4912 | Abstract Syntax Notation X (ASN.X) |
| |
| Authors: | S. Legg. |
| Date: | July 2007 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4912 |
|
Abstract Syntax Notation X (ASN.X) is a semantically equivalentExtensible Markup Language (XML) representation for Abstract SyntaxNotation One (ASN.1) specifications. ASN.X completely avoids the numerous ambiguities inherent in the ASN.1 language; therefore, specifications written in ASN.X are much easier to parse and manage than original ASN.1 specifications. ASN.X, together with the RobustXML Encoding Rules (RXER), constitutes a schema language for XML documents that offers, through other ASN.1 encoding rules, alternative compact binary encodings for XML instance documents. |
|
| |
| RFC 4913 | Abstract Syntax Notation X (ASN.X) Representation of Encoding Instructions for the Generic String Encoding Rules (GSER) |
| |
| Authors: | S. Legg. |
| Date: | July 2007 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4913 |
|
Abstract Syntax Notation X (ASN.X) is an Extensible Markup Language(XML) representation for Abstract Syntax Notation One (ASN.1) specifications. This document specifies the ASN.X representation of encoding instructions for the Generic String Encoding Rules (GSER). |
|
| |
| RFC 4914 | Abstract Syntax Notation X (ASN.X) Representation of Encoding Instructions for the XML Encoding Rules (XER) |
| |
| Authors: | S. Legg. |
| Date: | July 2007 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4914 |
|
Abstract Syntax Notation X (ASN.X) is an Extensible Markup Language(XML) representation for Abstract Syntax Notation One (ASN.1) specifications. This document specifies the ASN.X representation of encoding instructions for the XML Encoding Rules (XER). |
|
| |
| RFC 4946 | Atom License Extension |
| |
| Authors: | J. Snell. |
| Date: | July 2007 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4946 |
|
This memo defines an extension to the Atom Syndication Format for describing licenses associated with Atom feeds and entries. |
|
| |
| RFC 4956 | DNS Security (DNSSEC) Opt-In |
| |
| Authors: | R. Arends, M. Kosters, D. Blacka. |
| Date: | July 2007 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4956 |
|
In the DNS security (DNSSEC) extensions, delegations to unsigned subzones are cryptographically secured. Maintaining this cryptography is not always practical or necessary. This document describes an experimental "Opt-In" model that allows administrators to omit this cryptography and manage the cost of adopting DNSSEC with large zones. |
|
| |
| RFC 4973 | OSPF-xTE: Experimental Extension to OSPF for Traffic Engineering |
| |
| Authors: | P. Srisuresh, P. Joseph. |
| Date: | July 2007 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4973 |
|
This document defines OSPF-xTE, an experimental traffic engineering(TE) extension to the link-state routing protocol OSPF. OSPF-xTE defines new TE Link State Advertisements (LSAs) to disseminate TE metrics within an autonomous System (AS), which may consist of multiple areas. When an AS consists of TE and non-TE nodes, OSPF-xTE ensures that non-TE nodes in the AS are unaffected by the TE LSAs.OSPF-xTE generates a stand-alone TE Link State Database (TE-LSDB), distinct from the native OSPF LSDB, for computation of TE circuit paths. OSPF-xTE is versatile and extendible to non-packet networks such as Synchronous Optical Network (SONET) / Time DivisionMultiplexing (TDM) and optical networks. |
|
| |
| RFC 4988 | Mobile IPv4 Fast Handovers |
| |
| Authors: | R. Koodli, C. Perkins. |
| Date: | October 2007 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 4988 |
|
This document adapts the Mobile IPv6 Fast Handovers to improve delay and packet loss resulting from Mobile IPv4 handover operations.Specifically, this document addresses movement detection, IP address configuration, and location update latencies during a handover. For reducing the IP address configuration latency, the document proposes that the new Care-of Address is always made to be the new access router's IP address. |
|
| |
| RFC 5006 | IPv6 Router Advertisement Option for DNS Configuration |
| |
| Authors: | J. Jeong, Ed., S. Park, L. Beloeil, S. Madanapalli. |
| Date: | September 2007 |
| Formats: | txt json html |
| Obsoleted by: | RFC 6106 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5006 |
|
This document specifies a new IPv6 Router Advertisement option to allow IPv6 routers to advertise DNS recursive server addresses toIPv6 hosts. |
|
| |
| RFC 5050 | Bundle Protocol Specification |
| |
| Authors: | K. Scott, S. Burleigh. |
| Date: | November 2007 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5050 |
|
This document describes the end-to-end protocol, block formats, and abstract service description for the exchange of messages (bundles) in Delay Tolerant Networking (DTN).
This document was produced within the IRTF's Delay TolerantNetworking Research Group (DTNRG) and represents the consensus of all of the active contributors to this group. See http://www.dtnrg.org for more information. |
|
| |
| RFC 5058 | Explicit Multicast (Xcast) Concepts and Options |
| |
| Authors: | R. Boivie, N. Feldman, Y. Imai, W. Livens, D. Ooms. |
| Date: | November 2007 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5058 |
|
While traditional IP multicast schemes (RFC 1112) are scalable for very large multicast groups, they have scalability issues with a very large number of distinct multicast groups. This document describesXcast (Explicit Multi-unicast), a new multicast scheme with complementary scaling properties: Xcast supports a very large number of small multicast sessions. Xcast achieves this by explicitly encoding the list of destinations in the data packets, instead of using a multicast group address.
This document discusses Xcast concepts and options in several areas; it does not provide a complete technical specification. |
|
| |
| RFC 5081 | Using OpenPGP Keys for Transport Layer Security (TLS) Authentication |
| |
|
|
This memo proposes extensions to the Transport Layer Security (TLS) protocol to support the OpenPGP key format. The extensions discussed here include a certificate type negotiation mechanism, and the required modifications to the TLS Handshake Protocol. |
|
| |
| RFC 5106 | The Extensible Authentication Protocol-Internet Key Exchange Protocol version 2 (EAP-IKEv2) Method |
| |
| Authors: | H. Tschofenig, D. Kroeselberg, A. Pashalidis, Y. Ohba, F. Bersani. |
| Date: | February 2008 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5106 |
|
This document specifies EAP-IKEv2, an Extensible AuthenticationProtocol (EAP) method that is based on the Internet Key Exchange(IKEv2) protocol. EAP-IKEv2 provides mutual authentication and session key establishment between an EAP peer and an EAP server. It supports authentication techniques that are based on passwords, high-entropy shared keys, and public key certificates. EAP-IKEv2 further provides support for cryptographic ciphersuite negotiation, hash function agility, identity confidentiality (in certain modes of operation), fragmentation, and an optional "fast reconnect" mode. |
|
| |
| RFC 5111 | Experiment in Exploratory Group Formation within the Internet Engineering Task Force (IETF) |
| |
| Authors: | B. Aboba, L. Dondeti. |
| Date: | January 2008 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5111 |
|
This document describes an RFC 3933 experiment in the Working Group formation process, known as the Exploratory Group. ExploratoryGroups may be created as the first step toward Working Group formation, or as an intermediate step between a Birds of a Feather(BOF) session and Working Group creation. Exploratory Groups are focused on completion of prerequisites for Working Group formation, and as a result they have a short life-time, with limited opportunities for milestone extension. |
|
| |
| RFC 5184 | Unified Layer 2 (L2) Abstractions for Layer 3 (L3)-Driven Fast Handover |
| |
| Authors: | F. Teraoka, K. Gogo, K. Mitsuya, R. Shibui, K. Mitani. |
| Date: | May 2008 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5184 |
|
This document proposes unified Layer 2 (L2) abstractions for Layer 3(L3)-driven fast handovers. For efficient network communication, it is vital for a protocol layer to know or utilize other layers' information, such as the form of L2 triggers. However, each protocol layer is basically designed independently. Since each protocol layer is also implemented independently in current operating systems, it is very hard to exchange control information between protocol layers.This document defines nine kinds of L2 abstractions in the form of"primitives" to achieve fast handovers in the network layer as a means of solving the problem. This mechanism is called "L3-driven fast handovers" because the network layer initiates L2 and L3 handovers by using the primitives. This document is a product of theIP Mobility Optimizations (MobOpts) Research Group. |
|
| |
| RFC 5201 | Host Identity Protocol |
| |
| Authors: | R. Moskowitz, P. Nikander, P. Jokela, Ed., T. Henderson. |
| Date: | April 2008 |
| Formats: | txt html json |
| Obsoleted by: | RFC 7401 |
| Updated by: | RFC 6253 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5201 |
|
This memo specifies the details of the Host Identity Protocol (HIP).HIP allows consenting hosts to securely establish and maintain sharedIP-layer state, allowing separation of the identifier and locator roles of IP addresses, thereby enabling continuity of communications across IP address changes. HIP is based on a Sigma-compliant Diffie-Hellman key exchange, using public key identifiers from a new HostIdentity namespace for mutual peer authentication. The protocol is designed to be resistant to denial-of-service (DoS) and man-in-the- middle (MitM) attacks. When used together with another suitable security protocol, such as the Encapsulated Security Payload (ESP), it provides integrity protection and optional encryption for upper- layer protocols, such as TCP and UDP. |
|
| |
| RFC 5202 | Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP) |
| |
| Authors: | P. Jokela, R. Moskowitz, P. Nikander. |
| Date: | April 2008 |
| Formats: | txt json html |
| Obsoleted by: | RFC 7402 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5202 |
|
This memo specifies an Encapsulated Security Payload (ESP) based mechanism for transmission of user data packets, to be used with theHost Identity Protocol (HIP). |
|
| |
| RFC 5203 | Host Identity Protocol (HIP) Registration Extension |
| |
| Authors: | J. Laganier, T. Koponen, L. Eggert. |
| Date: | April 2008 |
| Formats: | txt json html |
| Obsoleted by: | RFC 8003 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5203 |
|
This document specifies a registration mechanism for the HostIdentity Protocol (HIP) that allows hosts to register with services, such as HIP rendezvous servers or middleboxes. |
|
| |
| RFC 5204 | Host Identity Protocol (HIP) Rendezvous Extension |
| |
|
|
This document defines a rendezvous extension for the Host IdentityProtocol (HIP). The rendezvous extension extends HIP and the HIP registration extension for initiating communication between HIP nodes via HIP rendezvous servers. Rendezvous servers improve reachability and operation when HIP nodes are multi-homed or mobile. |
|
| |
| RFC 5205 | Host Identity Protocol (HIP) Domain Name System (DNS) Extensions |
| |
| Authors: | P. Nikander, J. Laganier. |
| Date: | April 2008 |
| Formats: | txt html json |
| Obsoleted by: | RFC 8005 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5205 |
|
This document specifies a new resource record (RR) for the DomainName System (DNS), and how to use it with the Host Identity Protocol(HIP). This RR allows a HIP node to store in the DNS its HostIdentity (HI, the public component of the node public-private key pair), Host Identity Tag (HIT, a truncated hash of its public key), and the Domain Names of its rendezvous servers (RVSs). |
|
| |
| RFC 5206 | End-Host Mobility and Multihoming with the Host Identity Protocol |
| |
| Authors: | P. Nikander, T. Henderson, Ed., C. Vogt, J. Arkko. |
| Date: | April 2008 |
| Formats: | txt json html |
| Obsoleted by: | RFC 8046 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5206 |
|
This document defines mobility and multihoming extensions to the HostIdentity Protocol (HIP). Specifically, this document defines a general "LOCATOR" parameter for HIP messages that allows for a HIP host to notify peers about alternate addresses at which it may be reached. This document also defines elements of procedure for mobility of a HIP host -- the process by which a host dynamically changes the primary locator that it uses to receive packets. While the same LOCATOR parameter can also be used to support end-host multihoming, detailed procedures are left for further study. |
|
| |
| RFC 5210 | A Source Address Validation Architecture (SAVA) Testbed and Deployment Experience |
| |
| Authors: | J. Wu, J. Bi, X. Li, G. Ren, K. Xu, M. Williams. |
| Date: | June 2008 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5210 |
|
Because the Internet forwards packets according to the IP destination address, packet forwarding typically takes place without inspection of the source address and malicious attacks have been launched using spoofed source addresses. In an effort to enhance the Internet withIP source address validation, a prototype implementation of the IPSource Address Validation Architecture (SAVA) was created and an evaluation was conducted on an IPv6 network. This document reports on the prototype implementation and the test results, as well as the lessons and insights gained from experimentation. |
|
| |
| RFC 5257 | Internet Message Access Protocol - ANNOTATE Extension |
| |
| Authors: | C. Daboo, R. Gellens. |
| Date: | June 2008 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5257 |
|
The ANNOTATE extension to the Internet Message Access Protocol permits clients and servers to maintain "meta data" for messages, or individual message parts, stored in a mailbox on the server. For example, this can be used to attach comments and other useful information to a message. It is also possible to attach annotations to specific parts of a message, so that, for example, they could be marked as seen, or important, or a comment added.
Note that this document was the product of a WG that had good consensus on how to approach the problem. Nevertheless, the WG felt it did not have enough information on implementation and deployment hurdles to meet all of the requirements of a Proposed Standard. TheIETF solicits implementations and implementation reports in order to make further progress.
Implementers should be aware that this specification may change in an incompatible manner when going to Proposed Standard status. However, any incompatible changes will result in a new capability name being used to prevent problems with any deployments of the experimental extension. |
|
| |
| RFC 5320 | The Subnetwork Encapsulation and Adaptation Layer (SEAL) |
| |
| Authors: | F. Templin, Ed.. |
| Date: | February 2010 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5320 |
|
For the purpose of this document, subnetworks are defined as virtual topologies that span connected network regions bounded by encapsulating border nodes. These virtual topologies may span multiple IP and/or sub-IP layer forwarding hops, and can introduce failure modes due to packet duplication and/or links with diverseMaximum Transmission Units (MTUs). This document specifies aSubnetwork Encapsulation and Adaptation Layer (SEAL) that accommodates such virtual topologies over diverse underlying link technologies. |
|
| |
| RFC 5326 | Licklider Transmission Protocol - Specification |
| |
| Authors: | M. Ramadas, S. Burleigh, S. Farrell. |
| Date: | September 2008 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5326 |
|
This document describes the Licklider Transmission Protocol (LTP), designed to provide retransmission-based reliability over links characterized by extremely long message round-trip times (RTTs) and/or frequent interruptions in connectivity. Since communication across interplanetary space is the most prominent example of this sort of environment, LTP is principally aimed at supporting "long- haul" reliable transmission in interplanetary space, but it has applications in other environments as well.
This document is a product of the Delay Tolerant Networking ResearchGroup and has been reviewed by that group. No objections to its publication as an RFC were raised. |
|
| |
| RFC 5327 | Licklider Transmission Protocol - Security Extensions |
| |
| Authors: | S. Farrell, M. Ramadas, S. Burleigh. |
| Date: | September 2008 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5327 |
|
The Licklider Transmission Protocol (LTP) is intended to serve as a reliable convergence layer over single-hop deep-space radio frequency(RF) links. LTP does Automatic Repeat reQuest (ARQ) of data transmissions by soliciting selective-acknowledgment reception reports. It is stateful and has no negotiation or handshakes. This document describes security extensions to LTP, and is part of a series of related documents describing LTP.
This document is a product of the Delay Tolerant Networking ResearchGroup and has been reviewed by that group. No objections to its publication as an RFC were raised. |
|
| |
| RFC 5335 | Internationalized Email Headers |
| |
|
|
Full internationalization of electronic mail requires not only the capabilities to transmit non-ASCII content, to encode selected information in specific header fields, and to use non-ASCII characters in envelope addresses. It also requires being able to express those addresses and the information based on them in mail header fields. This document specifies an experimental variant ofInternet mail that permits the use of Unicode encoded in UTF-8, rather than ASCII, as the base form for Internet email header field.This form is permitted in transmission only if authorized by an SMTP extension, as specified in an associated specification. This specification Updates section 6.4 of RFC 2045 to conform with the requirements. |
|
| |
| RFC 5336 | SMTP Extension for Internationalized Email Addresses |
| |
|
|
This document specifies an SMTP extension for transport and delivery of email messages with internationalized email addresses or header information. Communication with systems that do not implement this specification is specified in another document. This document updates some syntaxes and rules defined in RFC 2821 and RFC 2822, and has some material updating RFC 4952. |
|
| |
| RFC 5337 | Internationalized Delivery Status and Disposition Notifications |
| |
|
|
Delivery status notifications (DSNs) are critical to the correct operation of an email system. However, the existing Draft Standards(RFC 3461, RFC 3462, RFC 3464) are presently limited to US-ASCII text in the machine-readable portions of the protocol. This specification adds a new address type for international email addresses so an original recipient address with non-US-ASCII characters can be correctly preserved even after downgrading. This also provides updated content return media types for delivery status notifications and message disposition notifications to support use of the new address type.
This document experimentally extends RFC 3461, RFC 3464, and RFC3798. |
|
| |
| RFC 5338 | Using the Host Identity Protocol with Legacy Applications |
| |
| Authors: | T. Henderson, P. Nikander, M. Komu. |
| Date: | September 2008 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5338 |
|
This document is an informative overview of how legacy applications can be made to work with the Host Identity Protocol (HIP). HIP proposes to add a cryptographic name space for network stack names.From an application viewpoint, HIP-enabled systems support a new address family of host identifiers, but it may be a long time until such HIP-aware applications are widely deployed even if host systems are upgraded. This informational document discusses implementation and Application Programming Interface (API) issues relating to usingHIP in situations in which the system is HIP-aware but the applications are not, and is intended to aid implementors and early adopters in thinking about and locally solving systems issues regarding the incremental deployment of HIP. |
|
| |
| RFC 5352 | Aggregate Server Access Protocol (ASAP) |
| |
| Authors: | R. Stewart, Q. Xie, M. Stillman, M. Tuexen. |
| Date: | September 2008 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5352 |
|
Aggregate Server Access Protocol (ASAP; RFC 5352), in conjunction with the Endpoint Handlespace Redundancy Protocol (ENRP; RFC 5353), provides a high-availability data transfer mechanism over IP networks. ASAP uses a handle-based addressing model that isolates a logical communication endpoint from its IP address(es), thus effectively eliminating the binding between the communication endpoint and its physical IP address(es), which normally constitutes a single point of failure.
In addition, ASAP defines each logical communication destination as a pool, providing full transparent support for server pooling and load sharing. It also allows dynamic system scalability -- members of a server pool can be added or removed at any time without interrupting the service.
ASAP is designed to take full advantage of the network level redundancy provided by the Stream Transmission Control Protocol(SCTP; RFC 4960). Each transport protocol, other than SCTP, MUST have an accompanying transport mapping document. It should be noted that ASAP messages passed between Pool Elements (PEs) and ENRP servers MUST use the SCTP transport protocol.
The high-availability server pooling is gained by combining two protocols, namely ASAP and ENRP, in which ASAP provides the user interface for Pool Handle to address translation, load sharing management, and fault management, while ENRP defines the high- availability Pool Handle translation service. |
|
| |
| RFC 5353 | Endpoint Handlespace Redundancy Protocol (ENRP) |
| |
| Authors: | Q. Xie, R. Stewart, M. Stillman, M. Tuexen, A. Silverton. |
| Date: | September 2008 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5353 |
|
The Endpoint Handlespace Redundancy Protocol (ENRP) is designed to work in conjunction with the Aggregate Server Access Protocol (ASAP) to accomplish the functionality of the Reliable Server Pooling(RSerPool) requirements and architecture. Within the operational scope of RSerPool, ENRP defines the procedures and message formats of a distributed, fault-tolerant registry service for storing, bookkeeping, retrieving, and distributing pool operation and membership information. |
|
| |
| RFC 5354 | Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace Redundancy Protocol (ENRP) Parameters |
| |
| Authors: | R. Stewart, Q. Xie, M. Stillman, M. Tuexen. |
| Date: | September 2008 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5354 |
|
This document details the parameters of the Aggregate Server AccessProtocol (ASAP) and Endpoint Handlespace Redundancy Protocol (ENRP) defined within the Reliable Server Pooling (RSerPool) architecture. |
|
| |
| RFC 5356 | Reliable Server Pooling Policies |
| |
| Authors: | T. Dreibholz, M. Tuexen. |
| Date: | September 2008 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5356 |
|
This document describes server pool policies for Reliable ServerPooling (RSerPool) including considerations for implementing them atEndpoint Handlespace Redundancy Protocol (ENRP) servers and pool users. |
|
| |
| RFC 5449 | OSPF Multipoint Relay (MPR) Extension for Ad Hoc Networks |
| |
| Authors: | E. Baccelli, P. Jacquet, D. Nguyen, T. Clausen. |
| Date: | February 2009 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5449 |
|
This document specifies an OSPFv3 interface type tailored for mobile ad hoc networks. This interface type is derived from the broadcast interface type, and is denoted the "OSPFv3 MANET interface type". |
|
| |
| RFC 5467 | GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs) |
| |
| Authors: | L. Berger, A. Takacs, D. Caviglia, D. Fedyk, J. Meuric. |
| Date: | March 2009 |
| Formats: | txt html json |
| Obsoleted by: | RFC 6387 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5467 |
|
This document defines a method for the support of GMPLS asymmetric bandwidth bidirectional Label Switched Paths (LSPs). The presented approach is applicable to any switching technology and builds on the original Resource Reservation Protocol (RSVP) model for the transport of traffic-related parameters. The procedures described in this document are experimental. |
|
| |
| RFC 5504 | Downgrading Mechanism for Email Address Internationalization |
| |
| Authors: | K. Fujiwara, Ed., Y. Yoneya, Ed.. |
| Date: | March 2009 |
| Formats: | txt json html |
| Obsoleted by: | RFC 6530 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5504 |
|
Traditional mail systems handle only ASCII characters in SMTP envelope and mail header fields. The Email AddressInternationalization (UTF8SMTP) extension allows UTF-8 characters inSMTP envelope and mail header fields. To avoid rejecting internationalized email messages when a server in the delivery path does not support the UTF8SMTP extension, some sort of converting mechanism is required. This document describes a downgrading mechanism for Email Address Internationalization. Note that this is a way to downgrade, not tunnel. There is no associated up-conversion mechanism, although internationalized email clients might use original internationalized addresses or other data when displaying or replying to downgraded messages. |
|
| |
| RFC 5514 | IPv6 over Social Networks |
| |
| Authors: | E. Vyncke. |
| Date: | 1 April 2009 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5514 |
|
There is a lack of IPv6 utilization in early 2009; this is partly linked to the fact that the number of IPv6 nodes is rather low. This document proposes to vastly increase the number of IPv6 hosts by transforming all Social Networking platforms into IPv6 networks.This will immediately add millions of IPv6 hosts to the existing IPv6Internet. This document includes sections on addressing and transport of IPv6 over a Social Network. A working prototype has been developed. |
|
| |
| RFC 5523 | OSPFv3-Based Layer 1 VPN Auto-Discovery |
| |
| Authors: | L. Berger. |
| Date: | April 2009 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5523 |
|
This document defines an OSPFv3-based (Open Shortest Path First version 3) Layer 1 Virtual Private Network (L1VPN) auto-discovery mechanism. This document parallels the existing OSPF version 2 L1VPN auto-discovery mechanism. The notable functional difference is the support of IPv6. |
|
| |
| RFC 5525 | Reliable Server Pooling MIB Module Definition |
| |
| Authors: | T. Dreibholz, J. Mulik. |
| Date: | April 2009 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5525 |
|
Reliable Server Pooling (RSerPool) is a framework to provide reliable server pooling. The RSerPool framework consists of two protocols:ASAP (Aggregate Server Access Protocol) and ENRP (EndpointHandlespace Redundancy Protocol). This document defines an SMIv2- compliant (Structure of Management Information Version 2) ManagementInformation Base (MIB) module providing access to managed objects in an RSerPool implementation. |
|
| |
| RFC 5562 | Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets |
| |
| Authors: | A. Kuzmanovic, A. Mondal, S. Floyd, K. Ramakrishnan. |
| Date: | June 2009 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5562 |
|
The proposal in this document is Experimental. While it may be deployed in the current Internet, it does not represent a consensus that this is the best possible mechanism for the use of ExplicitCongestion Notification (ECN) in TCP SYN/ACK packets.
This document describes an optional, experimental modification to RFC3168 to allow TCP SYN/ACK packets to be ECN-Capable. For TCP, RFC3168 specifies setting an ECN-Capable codepoint on data packets, but not on SYN and SYN/ACK packets. However, because of the high cost to the TCP transfer of having a SYN/ACK packet dropped, with the resulting retransmission timeout, this document describes the use ofECN for the SYN/ACK packet itself, when sent in response to a SYN packet with the two ECN flags set in the TCP header, indicating a willingness to use ECN. Setting the initial TCP SYN/ACK packet asECN-Capable can be of great benefit to the TCP connection, avoiding the severe penalty of a retransmission timeout for a connection that has not yet started placing a load on the network. The TCP responder(the sender of the SYN/ACK packet) must reply to a report of an ECN- marked SYN/ACK packet by resending a SYN/ACK packet that is not ECN-Capable. If the resent SYN/ACK packet is acknowledged, then the TCP responder reduces its initial congestion window from two, three, or four segments to one segment, thereby reducing the subsequent load from that connection on the network. If instead the SYN/ACK packet is dropped, or for some other reason the TCP responder does not receive an acknowledgement in the specified time, the TCP responder follows TCP standards for a dropped SYN/ACK packet (setting the retransmission timer). |
|
| |
| RFC 5572 | IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP) |
| |
| Authors: | M. Blanchet, F. Parent. |
| Date: | February 2010 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5572 |
|
A tunnel broker with the Tunnel Setup Protocol (TSP) enables the establishment of tunnels of various inner protocols, such as IPv6 orIPv4, inside various outer protocols packets, such as IPv4, IPv6, orUDP over IPv4 for IPv4 NAT traversal. The control protocol (TSP) is used by the tunnel client to negotiate the tunnel with the broker. A mobile node implementing TSP can be connected to both IPv4 and IPv6 networks whether it is on IPv4 only, IPv4 behind a NAT, or on IPv6 only. A tunnel broker may terminate the tunnels on remote tunnel servers or on itself. This document describes the TSP within the model of the tunnel broker model. |
|
| |
| RFC 5573 | Asynchronous Channels for the Blocks Extensible Exchange Protocol (BEEP) |
| |
| Authors: | M. Thomson. |
| Date: | June 2009 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5573 |
|
The Blocks Extensible Exchange Protocol (BEEP) provides a protocol framework for the development of application protocols. This document describes a BEEP feature that enables asynchrony for individual channels. |
|
| |
| RFC 5614 | Mobile Ad Hoc Network (MANET) Extension of OSPF Using Connected Dominating Set (CDS) Flooding |
| |
|
|
This document specifies an extension of OSPFv3 to support mobile ad hoc networks (MANETs). The extension, called OSPF-MDR, is designed as a new OSPF interface type for MANETs. OSPF-MDR is based on the selection of a subset of MANET routers, consisting of MANETDesignated Routers (MDRs) and Backup MDRs. The MDRs form a connected dominating set (CDS), and the MDRs and Backup MDRs together form a biconnected CDS for robustness. This CDS is exploited in two ways.First, to reduce flooding overhead, an optimized flooding procedure is used in which only (Backup) MDRs flood new link state advertisements (LSAs) back out the receiving interface; reliable flooding is ensured by retransmitting LSAs along adjacencies.Second, adjacencies are formed only between (Backup) MDRs and a subset of their neighbors, allowing for much better scaling in dense networks. The CDS is constructed using 2-hop neighbor information provided in a Hello protocol extension. The Hello protocol is further optimized by allowing differential Hellos that report only changes in neighbor states. Options are specified for originating router-LSAs that provide full or partial topology information, allowing overhead to be reduced by advertising less topology information. |
|
| |
| RFC 5622 | Profile for Datagram Congestion Control Protocol (DCCP) Congestion ID 4: TCP-Friendly Rate Control for Small Packets (TFRC-SP) |
| |
|
|
This document specifies a profile for Congestion Control Identifier4, the small-packet variant of TCP-Friendly Rate Control (TFRC), in the Datagram Congestion Control Protocol (DCCP). CCID 4 is for experimental use, and uses TFRC-SP (RFC 4828), a variant of TFRC designed for applications that send small packets. CCID 4 is considered experimental because TFRC-SP is itself experimental, and is not proposed for widespread deployment in the global Internet at this time. The goal for TFRC-SP is to achieve roughly the same bandwidth in bits per second (bps) as a TCP flow using packets of up to 1500 bytes but experiencing the same level of congestion. CCID 4 is for use for senders that send small packets and would like a TCP- friendly sending rate, possibly with Explicit Congestion Notification(ECN), while minimizing abrupt rate changes. |
|
| |
| RFC 5634 | Quick-Start for the Datagram Congestion Control Protocol (DCCP) |
| |
| Authors: | G. Fairhurst, A. Sathiaseelan. |
| Date: | August 2009 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5634 |
|
This document specifies the use of the Quick-Start mechanism by theDatagram Congestion Control Protocol (DCCP). DCCP is a transport protocol that allows the transmission of congestion-controlled, unreliable datagrams. DCCP is intended for applications such as streaming media, Internet telephony, and online games. In DCCP, an application has a choice of congestion control mechanisms, each specified by a Congestion Control Identifier (CCID). This document specifies general procedures applicable to all DCCP CCIDs and specific procedures for the use of Quick-Start with DCCP CCID 2, CCID3, and CCID 4. Quick-Start enables a DCCP sender to cooperate withQuick-Start routers along the end-to-end path to determine an allowed sending rate at the start of a connection and, at times, in the middle of a DCCP connection (e.g., after an idle or application- limited period). The present specification is provided for use in controlled environments, and not as a mechanism that would be intended or appropriate for ubiquitous deployment in the globalInternet. |
|
| |
| RFC 5636 | Traceable Anonymous Certificate |
| |
| Authors: | S. Park, H. Park, Y. Won, J. Lee, S. Kent. |
| Date: | August 2009 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5636 |
|
This document defines a practical architecture and protocols for offering privacy for a user who requests and uses an X.509 certificate containing a pseudonym, while still retaining the ability to map such a certificate to the real user who requested it. The architecture is compatible with IETF certificate request formats such as PKCS10 (RFC 2986) and CMC (RFC 5272). The architecture separates the authorities involved in issuing a certificate: one for verifying ownership of a private key (Blind Issuer) and the other for validating the contents of a certificate (Anonymity Issuer). The end entity (EE) certificates issued under this model are called TraceableAnonymous Certificates (TACs). |
|
| |
| RFC 5697 | Other Certificates Extension |
| |
| Authors: | S. Farrell. |
| Date: | November 2009 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5697 |
|
Some applications that associate state information with public key certificates can benefit from a way to link together a set of certificates that belong to the same end entity and that can safely be considered equivalent to one another for the purposes of referencing that application-state information. This memo defines a certificate extension that allows applications to establish the required linkage without introducing a new application protocol data unit. |
|
| |
| RFC 5721 | POP3 Support for UTF-8 |
| |
| Authors: | R. Gellens, C. Newman. |
| Date: | February 2010 |
| Formats: | txt json html |
| Obsoleted by: | RFC 6856 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5721 |
|
This specification extends the Post Office Protocol version 3 (POP3) to support un-encoded international characters in user names, passwords, mail addresses, message headers, and protocol-level textual error strings. |
|
| |
| RFC 5726 | Mobile IPv6 Location Privacy Solutions |
| |
| Authors: | Y. Qiu, F. Zhao, Ed., R. Koodli. |
| Date: | February 2010 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5726 |
|
Mobile IPv6 (RFC 3775) enables a mobile node to remain reachable while it roams on the Internet. However, the location and movement of the mobile node can be revealed by the IP addresses used in signaling or data packets. In this document, we consider the MobileIPv6 location privacy problem described in RFC 4882, and propose efficient and secure techniques to protect location privacy of the mobile node. This document is a product of the IP MobilityOptimizations (MobOpts) Research Group. |
|
| |
| RFC 5738 | IMAP Support for UTF-8 |
| |
|
|
This specification extends the Internet Message Access Protocol version 4rev1 (IMAP4rev1) to support UTF-8 encoded international characters in user names, mail addresses, and message headers. |
|
| |
| RFC 5739 | IPv6 Configuration in Internet Key Exchange Protocol Version 2 (IKEv2) |
| |
| Authors: | P. Eronen, J. Laganier, C. Madson. |
| Date: | February 2010 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5739 |
|
When Internet Key Exchange Protocol version 2 (IKEv2) is used for remote VPN access (client to VPN gateway), the gateway assigns the client an IP address from the internal network using IKEv2 configuration payloads. The configuration payloads specified in RFC4306 work well for IPv4 but make it difficult to use certain features of IPv6. This document specifies new configuration attributes forIKEv2 that allows the VPN gateway to assign IPv6 prefixes to clients, enabling all features of IPv6 to be used with the client-gateway"virtual link". |
|
| |
| RFC 5747 | 4over6 Transit Solution Using IP Encapsulation and MP-BGP Extensions |
| |
| Authors: | J. Wu, Y. Cui, X. Li, M. Xu, C. Metz. |
| Date: | March 2010 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5747 |
|
The emerging and growing deployment of IPv6 networks will introduce cases where connectivity with IPv4 networks crossing IPv6 transit backbones is desired. This document describes a mechanism for automatic discovery and creation of IPv4-over-IPv6 tunnels via extensions to multiprotocol BGP. It is targeted at connecting islands of IPv4 networks across an IPv6-only backbone without the need for a manually configured overlay of tunnels. The mechanisms described in this document have been implemented, tested, and deployed on the large research IPv6 network in China. |
|
| |
| RFC 5770 | Basic Host Identity Protocol (HIP) Extensions for Traversal of Network Address Translators |
| |
| Authors: | M. Komu, T. Henderson, H. Tschofenig, J. Melen, A. Keranen, Ed.. |
| Date: | April 2010 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5770 |
|
This document specifies extensions to the Host Identity Protocol(HIP) to facilitate Network Address Translator (NAT) traversal. The extensions are based on the use of the Interactive ConnectivityEstablishment (ICE) methodology to discover a working path between two end-hosts, and on standard techniques for encapsulatingEncapsulating Security Payload (ESP) packets within the User DatagramProtocol (UDP). This document also defines elements of a procedure for NAT traversal, including the optional use of a HIP relay server.With these extensions HIP is able to work in environments that haveNATs and provides a generic NAT traversal solution to higher-layer networking applications. |
|
| |
| RFC 5776 | Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols |
| |
| Authors: | V. Roca, A. Francillon, S. Faurite. |
| Date: | April 2010 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5776 |
|
This document details the Timed Efficient Stream Loss-TolerantAuthentication (TESLA) packet source authentication and packet integrity verification protocol and its integration within theAsynchronous Layered Coding (ALC) and NACK-Oriented ReliableMulticast (NORM) content delivery protocols. This document only considers the authentication/integrity verification of the packets generated by the session's sender. The authentication and integrity verification of the packets sent by receivers, if any, is out of the scope of this document. |
|
| |
| RFC 5780 | NAT Behavior Discovery Using Session Traversal Utilities for NAT (STUN) |
| |
|
|
This specification defines an experimental usage of the SessionTraversal Utilities for NAT (STUN) Protocol that discovers the presence and current behavior of NATs and firewalls between the STUN client and the STUN server. |
|
| |
| RFC 5787 | OSPFv2 Routing Protocols Extensions for Automatically Switched Optical Network (ASON) Routing |
| |
|
|
The ITU-T has defined an architecture and requirements for operating an Automatically Switched Optical Network (ASON).
The Generalized Multiprotocol Label Switching (GMPLS) protocol suite is designed to provide a control plane for a range of network technologies including optical networks such as time division multiplexing (TDM) networks including SONET/SDH and Optical TransportNetworks (OTNs), and lambda switching optical networks.
The requirements for GMPLS routing to satisfy the requirements ofASON routing, and an evaluation of existing GMPLS routing protocols are provided in other documents. This document defines extensions to the OSPFv2 Link State Routing Protocol to meet the requirements for routing in an ASON.
Note that this work is scoped to the requirements and evaluation expressed in RFC 4258 and RFC 4652 and the ITU-T Recommendations current when those documents were written. Future extensions of revisions of this work may be necessary if the ITU-T Recommendations are revised or if new requirements are introduced into a revision ofRFC 4258. |
|
| |
| RFC 5805 | Lightweight Directory Access Protocol (LDAP) Transactions |
| |
| Authors: | K. Zeilenga. |
| Date: | March 2010 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5805 |
|
Lightweight Directory Access Protocol (LDAP) update operations, such as Add, Delete, and Modify operations, have atomic, consistency, isolation, durability (ACID) properties. Each of these update operations act upon an entry. It is often desirable to update two or more entries in a single unit of interaction, a transaction.Transactions are necessary to support a number of applications including resource provisioning. This document extends LDAP to support transactions. |
|
| |
| RFC 5820 | Extensions to OSPF to Support Mobile Ad Hoc Networking |
| |
| Authors: | A. Roy, Ed., M. Chandra, Ed.. |
| Date: | March 2010 |
| Formats: | txt json html |
| Updated by: | RFC 7137 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5820 |
|
This document describes extensions to OSPF to support mobile ad hoc networks (MANETs). The extensions, called OSPF-OR (OSPF-OverlappingRelay), include mechanisms for link-local signaling (LLS), an OSPF-MANET interface, a simple technique to reduce the size of Hello packets by only transmitting incremental state changes, and a method for optimized flooding of routing updates. OSPF-OR also provides a means to reduce unnecessary adjacencies to support larger MANETs. |
|
| |
| RFC 5825 | Displaying Downgraded Messages for Email Address Internationalization |
| |
|
|
This document describes a method for displaying downgraded messages that originally contained internationalized email addresses or internationalized header fields. |
|
| |
| RFC 5827 | Early Retransmit for TCP and Stream Control Transmission Protocol (SCTP) |
| |
| Authors: | M. Allman, K. Avrachenkov, U. Ayesta, J. Blanton, P. Hurtig. |
| Date: | May 2010 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5827 |
|
This document proposes a new mechanism for TCP and Stream ControlTransmission Protocol (SCTP) that can be used to recover lost segments when a connection's congestion window is small. The "EarlyRetransmit" mechanism allows the transport to reduce, in certain special circumstances, the number of duplicate acknowledgments required to trigger a fast retransmission. This allows the transport to use fast retransmit to recover segment losses that would otherwise require a lengthy retransmission timeout. |
|
| |
| RFC 5842 | Binding Extensions to Web Distributed Authoring and Versioning (WebDAV) |
| |
| Authors: | G. Clemm, J. Crawford, J. Reschke, Ed., J. Whitehead. |
| Date: | April 2010 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5842 |
|
This specification defines bindings, and the BIND method for creating multiple bindings to the same resource. Creating a new binding to a resource causes at least one new URI to be mapped to that resource.Servers are required to ensure the integrity of any bindings that they allow to be created. |
|
| |
| RFC 5873 | Pre-Authentication Support for the Protocol for Carrying Authentication for Network Access (PANA) |
| |
| Authors: | Y. Ohba, A. Yegin. |
| Date: | May 2010 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5873 |
|
This document defines an extension to the Protocol for CarryingAuthentication for Network Access (PANA) for proactively establishing a PANA Security Association between a PANA Client in one access network and a PANA Authentication Agent in another access network to which the PANA Client may move. |
|
| |
| RFC 5878 | Transport Layer Security (TLS) Authorization Extensions |
| |
|
|
This document specifies authorization extensions to the TransportLayer Security (TLS) Handshake Protocol. Extensions are carried in the client and server hello messages to confirm that both parties support the desired authorization data types. Then, if supported by both the client and the server, authorization information, such as attribute certificates (ACs) or Security Assertion Markup Language(SAML) assertions, is exchanged in the supplemental data handshake message. |
|
| |
| RFC 5924 | Extended Key Usage (EKU) for Session Initiation Protocol (SIP) X.509 Certificates |
| |
| Authors: | S. Lawrence, V. Gurbani. |
| Date: | June 2010 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5924 |
|
This memo documents an extended key usage (EKU) X.509 certificate extension for restricting the applicability of a certificate to use with a Session Initiation Protocol (SIP) service. As such, in addition to providing rules for SIP implementations, this memo also provides guidance to issuers of certificates for use with SIP. |
|
| |
| RFC 5971 | GIST: General Internet Signalling Transport |
| |
| Authors: | H. Schulzrinne, R. Hancock. |
| Date: | October 2010 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5971 |
|
This document specifies protocol stacks for the routing and transport of per-flow signalling messages along the path taken by that flow through the network. The design uses existing transport and security protocols under a common messaging layer, the General InternetSignalling Transport (GIST), which provides a common service for diverse signalling applications. GIST does not handle signalling application state itself, but manages its own internal state and the configuration of the underlying transport and security protocols to enable the transfer of messages in both directions along the flow path. The combination of GIST and the lower layer transport and security protocols provides a solution for the base protocol component of the "Next Steps in Signalling" (NSIS) framework. |
|
| |
| RFC 5973 | NAT/Firewall NSIS Signaling Layer Protocol (NSLP) |
| |
| Authors: | M. Stiemerling, H. Tschofenig, C. Aoun, E. Davies. |
| Date: | October 2010 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5973 |
|
This memo defines the NSIS Signaling Layer Protocol (NSLP) forNetwork Address Translators (NATs) and firewalls. This NSLP allows hosts to signal on the data path for NATs and firewalls to be configured according to the needs of the application data flows. For instance, it enables hosts behind NATs to obtain a publicly reachable address and hosts behind firewalls to receive data traffic. The overall architecture is given by the framework and requirements defined by the Next Steps in Signaling (NSIS) working group. The network scenarios, the protocol itself, and examples for path-coupled signaling are given in this memo. |
|
| |
| RFC 5974 | NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling |
| |
| Authors: | J. Manner, G. Karagiannis, A. McDonald. |
| Date: | October 2010 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5974 |
|
This specification describes the NSIS Signaling Layer Protocol (NSLP) for signaling Quality of Service (QoS) reservations in the Internet.It is in accordance with the framework and requirements developed inNSIS. Together with General Internet Signaling Transport (GIST), it provides functionality similar to RSVP and extends it. The QoS NSLP is independent of the underlying QoS specification or architecture and provides support for different reservation models. It is simplified by the elimination of support for multicast flows. This specification explains the overall protocol approach, describes the design decisions made, and provides examples. It specifies object, message formats, and processing rules. |
|
| |
| RFC 5975 | QSPEC Template for the Quality-of-Service NSIS Signaling Layer Protocol (NSLP) |
| |
| Authors: | G. Ash, Ed., A. Bader, Ed., C. Kappler, Ed., D. Oran, Ed.. |
| Date: | October 2010 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5975 |
|
The Quality-of-Service (QoS) NSIS signaling layer protocol (NSLP) is used to signal QoS reservations and is independent of a specific QoS model (QOSM) such as IntServ or Diffserv. Rather, all information specific to a QOSM is encapsulated in a separate object, the QSPEC.This document defines a template for the QSPEC including a number ofQSPEC parameters. The QSPEC parameters provide a common language to be reused in several QOSMs and thereby aim to ensure the extensibility and interoperability of QoS NSLP. While the base protocol is QOSM-agnostic, the parameters that can be carried in theQSPEC object are possibly closely coupled to specific models. The node initiating the NSIS signaling adds an Initiator QSPEC, which indicates the QSPEC parameters that must be interpreted by the downstream nodes less the reservation fails, thereby ensuring the intention of the NSIS initiator is preserved along the signaling path. |
|
| |
| RFC 5976 | Y.1541-QOSM: Model for Networks Using Y.1541 Quality-of-Service Classes |
| |
| Authors: | G. Ash, A. Morton, M. Dolly, P. Tarapore, C. Dvorak, Y. El Mghazli. |
| Date: | October 2010 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5976 |
|
This document describes a QoS-NSLP Quality-of-Service model (QOSM) based on ITU-T Recommendation Y.1541 Network QoS Classes and related guidance on signaling. Y.1541 specifies 8 classes of NetworkPerformance objectives, and the Y.1541-QOSM extensions include additional QSPEC parameters and QOSM processing guidelines. |
|
| |
| RFC 5977 | RMD-QOSM: The NSIS Quality-of-Service Model for Resource Management in Diffserv |
| |
| Authors: | A. Bader, L. Westberg, G. Karagiannis, C. Kappler, T. Phelan. |
| Date: | October 2010 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5977 |
|
This document describes a Next Steps in Signaling (NSIS) Quality-of-Service (QoS) Model for networks that use the Resource Management inDiffserv (RMD) concept. RMD is a technique for adding admission control and preemption function to Differentiated Services (Diffserv) networks. The RMD QoS Model allows devices external to the RMD network to signal reservation requests to Edge nodes in the RMD network. The RMD Ingress Edge nodes classify the incoming flows into traffic classes and signals resource requests for the corresponding traffic class along the data path to the Egress Edge nodes for each flow. Egress nodes reconstitute the original requests and continue forwarding them along the data path towards the final destination.In addition, RMD defines notification functions to indicate overload situations within the domain to the Edge nodes. |
|
| |
| RFC 5979 | NSIS Operation over IP Tunnels |
| |
| Authors: | C. Shen, H. Schulzrinne, S. Lee, J. Bang. |
| Date: | March 2011 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5979 |
|
NSIS Quality of Service (QoS) signaling enables applications to perform QoS reservation along a data flow path. When the data flow path contains IP tunnel segments, NSIS QoS signaling has no effect within those tunnel segments. Therefore, the resulting tunnel segments could become the weakest QoS link and invalidate the QoS efforts in the rest of the end-to-end path. The problem with NSIS signaling within the tunnel is caused by the tunnel encapsulation that masks packets' original IP header fields. Those original IP header fields are needed to intercept NSIS signaling messages and classify QoS data packets. This document defines a solution to this problem by mapping end-to-end QoS session requests to correspondingQoS sessions in the tunnel, thus extending the end-to-end QoS signaling into the IP tunnel segments. |
|
| |
| RFC 5981 | Authorization for NSIS Signaling Layer Protocols |
| |
| Authors: | J. Manner, M. Stiemerling, H. Tschofenig, R. Bless, Ed.. |
| Date: | February 2011 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5981 |
|
Signaling layer protocols specified within the Next Steps inSignaling (NSIS) framework may rely on the General Internet SignalingTransport (GIST) protocol to handle authorization. Still, the signaling layer protocol above GIST itself may require separate authorization to be performed when a node receives a request for a certain kind of service or resources. This document presents a generic model and object formats for session authorization within theNSIS signaling layer protocols. The goal of session authorization is to allow the exchange of information between network elements in order to authorize the use of resources for a service and to coordinate actions between the signaling and transport planes. |
|
| |
| RFC 5983 | Mailing Lists and Internationalized Email Addresses |
| |
|
|
This document describes considerations for mailing lists with the introduction of internationalized email addresses.
This document makes some specific recommendations on how mailing lists should act in various situations. |
|
| |
| RFC 5984 | Increasing Throughput in IP Networks with ESP-Based Forwarding: ESPBasedForwarding |
| |
| Authors: | K-M. Moller. |
| Date: | 1 April 2011 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5984 |
|
This document proposes an experimental way of reaching infinite bandwidth in IP networks by the use of ESP-based forwarding. |
|
| |
| RFC 6023 | A Childless Initiation of the Internet Key Exchange Version 2 (IKEv2) Security Association (SA) |
| |
| Authors: | Y. Nir, H. Tschofenig, H. Deng, R. Singh. |
| Date: | October 2010 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6023 |
|
This document describes an extension to the Internet Key Exchange version 2 (IKEv2) protocol that allows an IKEv2 Security Association(SA) to be created and authenticated without generating a Child SA. |
|
| |
| RFC 6028 | Host Identity Protocol (HIP) Multi-Hop Routing Extension |
| |
| Authors: | G. Camarillo, A. Keranen. |
| Date: | October 2010 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6028 |
|
This document specifies two extensions to the Host Identity Protocol(HIP) to implement multi-hop routing. The first extension allows implementing source routing in HIP. That is, a node sending a HIP packet can define a set of nodes that the HIP packet should traverse.The second extension allows a HIP packet to carry and record the list of nodes that forwarded it. |
|
| |
| RFC 6058 | Transient Binding for Proxy Mobile IPv6 |
| |
| Authors: | M. Liebsch, Ed., A. Muhanna, O. Blume. |
| Date: | March 2011 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6058 |
|
This document specifies a mechanism that enhances Proxy Mobile IPv6 protocol signaling to support the creation of a transient binding cache entry that is used to optimize the performance of dual radio handover, as well as single radio handover. This mechanism is applicable to the mobile node's inter-MAG (Mobility Access Gateway) handover while using a single interface or different interfaces. The handover problem space using the Proxy Mobile IPv6 base protocol is analyzed and the use of transient binding cache entries at the local mobility anchor is described. The specified extension to the ProxyMobile IPv6 protocol ensures optimized forwarding of downlink as well as uplink packets between mobile nodes and the network infrastructure and avoids superfluous packet forwarding delay or even packet loss. |
|
| |
| RFC 6069 | Making TCP More Robust to Long Connectivity Disruptions (TCP-LCD) |
| |
| Authors: | A. Zimmermann, A. Hannemann. |
| Date: | December 2010 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6069 |
|
Disruptions in end-to-end path connectivity, which last longer than one retransmission timeout, cause suboptimal TCP performance. The reason for this performance degradation is that TCP interprets segment loss induced by long connectivity disruptions as a sign of congestion, resulting in repeated retransmission timer backoffs.This, in turn, leads to a delayed detection of the re-establishment of the connection since TCP waits for the next retransmission timeout before it attempts a retransmission.
This document proposes an algorithm to make TCP more robust to long connectivity disruptions (TCP-LCD). It describes how standard ICMP messages can be exploited during timeout-based loss recovery to disambiguate true congestion loss from non-congestion loss caused by connectivity disruptions. Moreover, a reversion strategy of the retransmission timer is specified that enables a more prompt detection of whether or not the connectivity to a previously disconnected peer node has been restored. TCP-LCD is a TCP sender- only modification that effectively improves TCP performance in the case of connectivity disruptions. |
|
| |
| RFC 6078 | Host Identity Protocol (HIP) Immediate Carriage and Conveyance of Upper-Layer Protocol Signaling (HICCUPS) |
| |
| Authors: | G. Camarillo, J. Melen. |
| Date: | January 2011 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6078 |
|
This document defines a new Host Identity Protocol (HIP) packet type called DATA. HIP DATA packets are used to reliably convey authenticated arbitrary protocol messages over various overlay networks. |
|
| |
| RFC 6079 | HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking Environment (BONE) |
| |
| Authors: | G. Camarillo, P. Nikander, J. Hautakorpi, A. Keranen, A. Johnston. |
| Date: | January 2011 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6079 |
|
This document specifies a framework to build HIP-based (Host IdentityProtocol) overlay networks. This framework uses HIP to perform connection management. Other functions, such as data storage and retrieval or overlay maintenance, are implemented using protocols other than HIP. These protocols are loosely referred to as "peer protocols". |
|
| |
| RFC 6084 | General Internet Signaling Transport (GIST) over Stream Control Transmission Protocol (SCTP) and Datagram Transport Layer Security (DTLS) |
| |
| Authors: | X. Fu, C. Dickmann, J. Crowcroft. |
| Date: | January 2011 |
| Formats: | txt html json |
| Updated by: | RFC 8996 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6084 |
|
The General Internet Signaling Transport (GIST) protocol currently uses TCP or Transport Layer Security (TLS) over TCP for Connection mode operation. This document describes the usage of GIST over theStream Control Transmission Protocol (SCTP) and Datagram TransportLayer Security (DTLS). |
|
| |
| RFC 6095 | Extending YANG with Language Abstractions |
| |
| Authors: | B. Linowski, M. Ersue, S. Kuryla. |
| Date: | March 2011 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6095 |
|
YANG -- the Network Configuration Protocol (NETCONF) Data ModelingLanguage -- supports modeling of a tree of data elements that represent the configuration and runtime status of a particular network element managed via NETCONF. This memo suggests enhancingYANG with supplementary modeling features and language abstractions with the aim to improve the model extensibility and reuse. |
|
| |
| RFC 6126 | The Babel Routing Protocol |
| |
|
|
Babel is a loop-avoiding distance-vector routing protocol that is robust and efficient both in ordinary wired networks and in wireless mesh networks. |
|
| |
| RFC 6137 | The Network Trouble Ticket Data Model (NTTDM) |
| |
| Authors: | D. Zisiadis, Ed., S. Kopsidas, Ed., M. Tsavli, Ed., G. Cessieux, Ed.. |
| Date: | February 2011 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6137 |
|
Handling multiple sets of network trouble tickets (TTs) originating from different participants' inter-connected network environments poses a series of challenges for the involved institutions. A Grid is a good example of such a multi-domain project. Each of the participants follows different procedures for handling trouble in its domain, according to the local technical and linguistic profile. TheTT systems of the participants collect, represent, and disseminate TT information in different formats.
As a result, management of the daily workload by a central NetworkOperation Centre (NOC) is a challenge on its own. Normalization ofTTs to a common format at the central NOC can ease presentation, storing, and handling of the TTs. In the present document, we provide a model for automating the collection and normalization of the TT received by multiple networks forming the Grid. Each of the participants is using its home TT system within its domain for handling trouble incidents, whereas the central NOC is gathering the tickets in the normalized format for repository and handling. XML is used as the common representation language. The model was defined and used as part of the networking support activity of the EGEE(Enabling Grids for E-sciencE) project. |
|
| |
| RFC 6179 | The Internet Routing Overlay Network (IRON) |
| |
| Authors: | F. Templin, Ed.. |
| Date: | March 2011 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6179 |
|
Since the Internet must continue to support escalating growth due to increasing demand, it is clear that current routing architectures and operational practices must be updated. This document proposes anInternet Routing Overlay Network (IRON) that supports sustainable growth while requiring no changes to end systems and no changes to the existing routing system. IRON further addresses other important issues including routing scaling, mobility management, multihoming, traffic engineering and NAT traversal. While business considerations are an important determining factor for widespread adoption, they are out of scope for this document. This document is a product of theIRTF Routing Research Group. |
|
| |
| RFC 6197 | Location-to-Service Translation (LoST) Service List Boundary Extension |
| |
| Authors: | K. Wolf. |
| Date: | April 2011 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6197 |
|
Location-to-Service Translation (LoST) maps service identifiers and location information to service contact URIs. If a LoST client wants to discover available services for a particular location, it will perform a <listServicesByLocation&rt; query to the LoST server.However, the LoST server, in its response, does not provide context information; that is, it does not provide any additional information about the geographical region within which the returned list of services is considered valid. Therefore, this document defines aService List Boundary that returns a local context along with the list of services returned, in order to assist the client in not missing a change in available services when moving. |
|
| |
| RFC 6210 | Experiment: Hash Functions with Parameters in the Cryptographic Message Syntax (CMS) and S/MIME |
| |
| Authors: | J. Schaad. |
| Date: | April 2011 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6210 |
|
New hash algorithms are being developed that may include parameters.Cryptographic Message Syntax (CMS) has not currently defined any hash algorithms with parameters, but anecdotal evidence suggests that defining one could cause major problems. This document defines just such an algorithm and describes how to use it so that experiments can be run to find out how bad including hash parameters will be. |
|
| |
| RFC 6217 | Regional Broadcast Using an Atmospheric Link Layer |
| |
| Authors: | T. Ritter. |
| Date: | 1 April 2011 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6217 |
|
Broadcasting is a technology that has been largely discarded in favor of technologies like multicast. This document builds on RFC 919 and describes a more efficient routing mechanism for broadcast packets destined for multiple Local Area Networks (LANs) or Metropolitan AreaNetworks (MANs) using an alternative link layer. It significantly reduces congestion on network equipment and does not require additional physical infrastructure investment. |
|
| |
| RFC 6235 | IP Flow Anonymization Support |
| |
| Authors: | E. Boschi, B. Trammell. |
| Date: | May 2011 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6235 |
|
This document describes anonymization techniques for IP flow data and the export of anonymized data using the IP Flow Information Export(IPFIX) protocol. It categorizes common anonymization schemes and defines the parameters needed to describe them. It provides guidelines for the implementation of anonymized data export and storage over IPFIX, and describes an information model and Options- based method for anonymization metadata export within the IPFIX protocol or storage in IPFIX Files. |
|
| |
| RFC 6237 | IMAP4 Multimailbox SEARCH Extension |
| |
|
|
The IMAP4 specification allows the searching of only the selected mailbox. A user often wants to search multiple mailboxes, and a client that wishes to support this must issue a series of SELECT andSEARCH commands, waiting for each to complete before moving on to the next. This extension allows a client to search multiple mailboxes with one command, limiting the round trips and waiting for various searches to complete, and not requiring disruption of the currently selected mailbox. This extension also uses MAILBOX and TAG fields inESEARCH responses, allowing a client to pipeline the searches if it chooses. This document updates RFC 4466. |
|
| |
| RFC 6253 | Host Identity Protocol Certificates |
| |
|
|
The Certificate (CERT) parameter is a container for digital certificates. It is used for carrying these certificates in HostIdentity Protocol (HIP) control packets. This document specifies theCERT parameter and the error signaling in case of a failed verification. Additionally, this document specifies the representations of Host Identity Tags in X.509 version 3 (v3) andSimple Public Key Infrastructure (SPKI) certificates.
The concrete use of certificates, including how certificates are obtained, requested, and which actions are taken upon successful or failed verification, is specific to the scenario in which the certificates are used. Hence, the definition of these scenario- specific aspects is left to the documents that use the CERT parameter.
This document updates RFC 5201. |
|
| |
| RFC 6257 | Bundle Security Protocol Specification |
| |
| Authors: | S. Symington, S. Farrell, H. Weiss, P. Lovell. |
| Date: | May 2011 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6257 |
|
This document defines the bundle security protocol, which provides data integrity and confidentiality services for the Bundle Protocol.Separate capabilities are provided to protect the bundle payload and additional data that may be included within the bundle. We also describe various security considerations including some policy options.
This document is a product of the Delay-Tolerant Networking ResearchGroup and has been reviewed by that group. No objections to its publication as an RFC were raised. |
|
| |
| RFC 6258 | Delay-Tolerant Networking Metadata Extension Block |
| |
| Authors: | S. Symington. |
| Date: | May 2011 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6258 |
|
This document defines an extension block that may be used with theDelay-Tolerant Networking (DTN) Bundle Protocol. This MetadataExtension Block is designed to carry additional information that DTN nodes can use to make processing decisions regarding bundles, such as deciding whether to store a bundle or determining to which nodes to forward a bundle. The metadata that is carried in a metadata block must be formatted according to the metadata type that is identified in the block's metadata type field. One specific metadata type, for carrying URIs as metadata, is defined in this document. Other metadata types may be defined in separate documents. This document is a product of the Delay Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as anRFC were raised. |
|
| |
| RFC 6259 | Delay-Tolerant Networking Previous-Hop Insertion Block |
| |
| Authors: | S. Symington. |
| Date: | May 2011 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6259 |
|
This document defines an extension block for use with the Delay-Tolerant Networking (DTN) Bundle Protocol. This Previous-HopInsertion Block (PHIB) extension block is designed to be inserted by a forwarding node to provide the endpoint identifier (EID) of an endpoint of which the forwarding node is a member so that this EID may be conveyed to the next-hop receiving node. Knowledge of an EID of an endpoint of which a previous-hop node is a member may be required in some circumstances to support certain routing protocols(e.g., flood routing). If this EID cannot be provided by the convergence layer or other means, the PHIB defines the mechanism whereby the EID can be provided with the bundle. Each PHIB is always removed from the bundle by the receiving node so that its presence within the bundle is limited to exactly one hop. This document defines the format and processing of this PHIB. This document is a product of the Delay-Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. |
|
| |
| RFC 6260 | Compressed Bundle Header Encoding (CBHE) |
| |
| Authors: | S. Burleigh. |
| Date: | May 2011 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6260 |
|
This document describes a convention by which Delay-TolerantNetworking (DTN) Bundle Protocol (BP) "convergence-layer" adapters may represent endpoint identifiers in a compressed form within the primary blocks of bundles, provided those endpoint identifiers conform to the structure prescribed by this convention.
Compressed Bundle Header Encoding (CBHE) compression is a convergence-layer adaptation. It is opaque to bundle processing.Therefore, it has no impact on the interoperability of differentBundle Protocol implementations, but instead affects only the interoperability of different convergence-layer adaptation implementations.
This document is a product of the Delay-Tolerant Networking ResearchGroup and has been reviewed by that group. No objections to its publication as an RFC were raised. |
|
| |
| RFC 6261 | Encrypted Signaling Transport Modes for the Host Identity Protocol |
| |
| Authors: | A. Keranen. |
| Date: | May 2011 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6261 |
|
This document specifies two transport modes for Host IdentityProtocol (HIP) signaling messages that allow them to be conveyed over encrypted connections initiated with the Host Identity Protocol. |
|
| |
| RFC 6296 | IPv6-to-IPv6 Network Prefix Translation |
| |
| Authors: | M. Wasserman, F. Baker. |
| Date: | June 2011 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6296 |
|
This document describes a stateless, transport-agnostic IPv6-to-IPv6Network Prefix Translation (NPTv6) function that provides the address-independence benefit associated with IPv4-to-IPv4 NAT(NAPT44) and provides a 1:1 relationship between addresses in the"inside" and "outside" prefixes, preserving end-to-end reachability at the network layer. |
|
| |
| RFC 6306 | Hierarchical IPv4 Framework |
| |
| Authors: | P. Frejborg. |
| Date: | July 2011 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6306 |
|
This document describes a framework for how the current IPv4 address space can be divided into two new address categories: a core address space (Area Locators, ALOCs) that is globally unique, and an edge address space (Endpoint Locators, ELOCs) that is regionally unique.In the future, the ELOC space will only be significant in a private network or in a service provider domain. Therefore, a 32x32 bit addressing scheme and a hierarchical routing architecture are achieved. The hierarchical IPv4 framework is backwards compatible with the current IPv4 Internet.
This document also discusses a method for decoupling the location and identifier functions -- future applications can make use of the separation. The framework requires extensions to the existing DomainName System (DNS), the existing IPv4 stack of the endpoints, middleboxes, and routers in the Internet. The framework can be implemented incrementally for endpoints, DNS, middleboxes, and routers. |
|
| |
| RFC 6317 | Basic Socket Interface Extensions for the Host Identity Protocol (HIP) |
| |
| Authors: | M. Komu, T. Henderson. |
| Date: | July 2011 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6317 |
|
This document defines extensions to the current sockets API for theHost Identity Protocol (HIP). The extensions focus on the use of public-key-based identifiers discovered via DNS resolution, but also define interfaces for manual bindings between Host Identity Tags(HITs) and locators. With the extensions, the application can also support more relaxed security models where communication can be non-HIP-based, according to local policies. The extensions in this document are experimental and provide basic tools for further experimentation with policies. |
|
| |
| RFC 6346 | The Address plus Port (A+P) Approach to the IPv4 Address Shortage |
| |
| Authors: | R. Bush, Ed.. |
| Date: | August 2011 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6346 |
|
We are facing the exhaustion of the IANA IPv4 free IP address pool.Unfortunately, IPv6 is not yet deployed widely enough to fully replace IPv4, and it is unrealistic to expect that this is going to change before the depletion of IPv4 addresses. Letting hosts seamlessly communicate in an IPv4 world without assigning a unique globally routable IPv4 address to each of them is a challenging problem.
This document proposes an IPv4 address sharing scheme, treating some of the port number bits as part of an extended IPv4 address (Address plus Port, or A+P). Instead of assigning a single IPv4 address to a single customer device, we propose to extend the address field by using bits from the port number range in the TCP/UDP header as additional endpoint identifiers, thus leaving a reduced range of ports available to applications. This means assigning the same IPv4 address to multiple clients (e.g., Customer Premises Equipment (CPE), mobile phones), each with its assigned port range. In the face ofIPv4 address exhaustion, the need for addresses is stronger than the need to be able to address thousands of applications on a single host. If address translation is needed, the end-user should be in control of the translation process -- not some smart boxes in the core. |
|
| |
| RFC 6356 | Coupled Congestion Control for Multipath Transport Protocols |
| |
| Authors: | C. Raiciu, M. Handley, D. Wischik. |
| Date: | October 2011 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6356 |
|
Often endpoints are connected by multiple paths, but communications are usually restricted to a single path per connection. Resource usage within the network would be more efficient were it possible for these multiple paths to be used concurrently. Multipath TCP is a proposal to achieve multipath transport in TCP.
New congestion control algorithms are needed for multipath transport protocols such as Multipath TCP, as single path algorithms have a series of issues in the multipath context. One of the prominent problems is that running existing algorithms such as standard TCP independently on each path would give the multipath flow more than its fair share at a bottleneck link traversed by more than one of its subflows. Further, it is desirable that a source with multiple paths available will transfer more traffic using the least congested of the paths, achieving a property called "resource pooling" where a bundle of links effectively behaves like one shared link with bigger capacity. This would increase the overall efficiency of the network and also its robustness to failure.
This document presents a congestion control algorithm that couples the congestion control algorithms running on different subflows by linking their increase functions, and dynamically controls the overall aggressiveness of the multipath flow. The result is a practical algorithm that is fair to TCP at bottlenecks while moving traffic away from congested links. |
|
| |
| RFC 6358 | Additional Master Secret Inputs for TLS |
| |
| Authors: | P. Hoffman. |
| Date: | January 2012 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6358 |
|
This document describes a mechanism for using additional master secret inputs with Transport Layer Security (TLS) and Datagram TLS(DTLS). |
|
| |
| RFC 6451 | Location-to-Service Translation (LoST) Protocol Extensions |
| |
| Authors: | A. Forte, H. Schulzrinne. |
| Date: | December 2011 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6451 |
|
An important class of location-based services answers the question,"What instances of this service are closest to me?" Examples include finding restaurants, gas stations, stores, automated teller machines, wireless access points (hot spots), or parking spaces. Currently, the Location-to-Service Translation (LoST) protocol only supports mapping locations to a single service based on service regions. This document describes an extension that allows queries of the type "N nearest", "within distance X", and "served by". |
|
| |
| RFC 6496 | Secure Proxy ND Support for SEcure Neighbor Discovery (SEND) |
| |
| Authors: | S. Krishnan, J. Laganier, M. Bonola, A. Garcia-Martinez. |
| Date: | February 2012 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6496 |
|
SEcure Neighbor Discovery (SEND) specifies a method for securingNeighbor Discovery (ND) signaling against specific threats. As defined today, SEND assumes that the node sending an ND message is the owner of the address from which the message is sent and/or possesses a key that authorizes the node to act as a router, so that it is in possession of the private key or keys used to generate the digital signature on each message. This means that the Proxy ND signaling performed by nodes that do not possess knowledge of the address owner's private key and/or knowledge of a router's key cannot be secured using SEND. This document extends the current SEND specification in order to secure Proxy ND operation. |
|
| |
| RFC 6521 | Home Agent-Assisted Route Optimization between Mobile IPv4 Networks |
| |
| Authors: | A. Makela, J. Korhonen. |
| Date: | February 2012 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6521 |
|
This document describes a home agent-assisted route optimization functionality for the IPv4 Network Mobility Protocol. The function is designed to facilitate optimal routing in cases where all nodes are connected to a single home agent; thus, the use case is route optimization within a single organization or similar entity. The functionality enables the discovery of eligible peer nodes (based on information received from the home agent) and their network prefixes, and the establishment of a direct tunnel between such nodes. |
|
| |
| RFC 6537 | Host Identity Protocol Distributed Hash Table Interface |
| |
| Authors: | J. Ahrenholz. |
| Date: | February 2012 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6537 |
|
This document specifies a common interface for using the HostIdentity Protocol (HIP) with a Distributed Hash Table (DHT) service to provide a name-to-Host-Identity-Tag lookup service and a Host-Identity-Tag-to-address lookup service. |
|
| |
| RFC 6541 | DomainKeys Identified Mail (DKIM) Authorized Third-Party Signatures |
| |
| Authors: | M. Kucherawy. |
| Date: | February 2012 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6541 |
|
This experimental specification proposes a modification to DomainKeysIdentified Mail (DKIM) allowing advertisement of third-party signature authorizations that are to be interpreted as equivalent to a signature added by the administrative domain of the message's author. |
|
| |
| RFC 6559 | A Reliable Transport Mechanism for PIM |
| |
| Authors: | D. Farinacci, IJ. Wijnands, S. Venaas, M. Napierala. |
| Date: | March 2012 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6559 |
|
This document defines a reliable transport mechanism for the PIM protocol for transmission of Join/Prune messages. This eliminates the need for periodic Join/Prune message transmission and processing.The reliable transport mechanism can use either TCP or SCTP as the transport protocol. |
|
| |
| RFC 6593 | Service Undiscovery Using Hide-and-Go-Seek for the Domain Pseudonym System (DPS) |
| |
| Authors: | C. Pignataro, J. Clarke, G. Salgueiro. |
| Date: | 1 April 2012 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6593 |
|
With the ubiquitous success of service discovery techniques, curious clients are faced with an increasing overload of service instances and options listed when they browse for services. A typical domain may contain web servers, remote desktop servers, printers, file servers, video content servers, automatons, Points of Presence using artificial intelligence, etc., all advertising their presence.Unsurprisingly, it is expected that some protocols and services will choose the comfort of anonymity and avoid discovery.
This memo describes a new experimental protocol for this purpose utilizing the Domain Pseudonym System (DPS), and discusses strategies for its successful implementation and deployment. |
|
| |
| RFC 6601 | Generic Connection Admission Control (GCAC) Algorithm Specification for IP/MPLS Networks |
| |
| Authors: | G. Ash, Ed., D. McDysan. |
| Date: | April 2012 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6601 |
|
This document presents a generic connection admission control (GCAC) reference model and algorithm for IP-/MPLS-based networks. Service provider (SP) IP/MPLS networks need an MPLS GCAC mechanism, as one motivational example, to reject Voice over IP (VoIP) calls when additional calls would adversely affect calls already in progress.Without MPLS GCAC, connections on congested links will suffer degraded quality. The MPLS GCAC algorithm can be optionally implemented in vendor equipment and deployed by service providers.MPLS GCAC interoperates between vendor equipment and across multiple service provider domains. The MPLS GCAC algorithm uses available standard mechanisms for MPLS-based networks, such as RSVP, Diffserv- aware MPLS Traffic Engineering (DS-TE), Path Computation Element(PCE), Next Steps in Signaling (NSIS), Diffserv, and OSPF. The MPLSGCAC algorithm does not include aspects of CAC that might be considered vendor proprietary implementations, such as detailed path selection mechanisms. MPLS GCAC functions are implemented in a distributed manner to deliver the objective Quality of Service (QoS) for specified QoS constraints. The objective is that the source is able to compute a source route with high likelihood that via-elements along the selected path will in fact admit the request. In some cases (e.g., multiple Autonomous Systems (ASes)), this objective cannot always be met, but this document summarizes methods that partially meet this objective. MPLS GCAC is applicable to any service or flow that must meet an objective QoS (delay, jitter, packet loss rate) for a specified quantity of traffic. |
|
| |
| RFC 6613 | RADIUS over TCP |
| |
|
|
The Remote Authentication Dial-In User Server (RADIUS) protocol has, until now, required the User Datagram Protocol (UDP) as the underlying transport layer. This document defines RADIUS over theTransmission Control Protocol (RADIUS/TCP), in order to address handling issues related to RADIUS over Transport Layer Security(RADIUS/TLS). It permits TCP to be used as a transport protocol forRADIUS only when a transport layer such as TLS or IPsec provides confidentiality and security. |
|
| |
| RFC 6614 | Transport Layer Security (TLS) Encryption for RADIUS |
| |
| Authors: | S. Winter, M. McCauley, S. Venaas, K. Wierenga. |
| Date: | May 2012 |
| Formats: | txt json html |
| Updated by: | RFC 8996 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6614 |
|
This document specifies a transport profile for RADIUS usingTransport Layer Security (TLS) over TCP as the transport protocol.This enables dynamic trust relationships between RADIUS servers. |
|
| |
| RFC 6617 | Secure Pre-Shared Key (PSK) Authentication for the Internet Key Exchange Protocol (IKE) |
| |
| Authors: | D. Harkins. |
| Date: | June 2012 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6617 |
|
This memo describes a secure pre-shared key (PSK) authentication method for the Internet Key Exchange Protocol (IKE). It is resistant to dictionary attack and retains security even when used with weak pre-shared keys. |
|
| |
| RFC 6618 | Mobile IPv6 Security Framework Using Transport Layer Security for Communication between the Mobile Node and Home Agent |
| |
| Authors: | J. Korhonen, Ed., B. Patil, H. Tschofenig, D. Kroeselberg. |
| Date: | May 2012 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6618 |
|
Mobile IPv6 signaling between a Mobile Node (MN) and its Home Agent(HA) is secured using IPsec. The security association (SA) between an MN and the HA is established using Internet Key Exchange Protocol(IKE) version 1 or 2. The security model specified for Mobile IPv6, which relies on IKE/IPsec, requires interaction between the MobileIPv6 protocol component and the IKE/IPsec module of the IP stack.This document proposes an alternate security framework for MobileIPv6 and Dual-Stack Mobile IPv6, which relies on Transport LayerSecurity for establishing keying material and other bootstrapping parameters required to protect Mobile IPv6 signaling and data traffic between the MN and HA. |
|
| |
| RFC 6621 | Simplified Multicast Forwarding |
| |
| Authors: | J. Macker, Ed.. |
| Date: | May 2012 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6621 |
|
This document describes a Simplified Multicast Forwarding (SMF) mechanism that provides basic Internet Protocol (IP) multicast forwarding suitable for limited wireless mesh and mobile ad hoc network (MANET) use. It is mainly applicable in situations where efficient flooding represents an acceptable engineering design trade- off. It defines techniques for multicast duplicate packet detection(DPD), to be applied in the forwarding process, for both IPv4 andIPv6 protocol use. This document also specifies optional mechanisms for using reduced relay sets to achieve more efficient multicast data distribution within a mesh topology as compared to Classic Flooding.Interactions with other protocols, such as use of information provided by concurrently running unicast routing protocols or interaction with other multicast protocols, as well as multiple deployment approaches are also described. Distributed algorithms for selecting reduced relay sets and related discussion are provided in the appendices. Basic issues relating to the operation of multicastMANET border routers are discussed, but ongoing work remains in this area and is beyond the scope of this document. |
|
| |
| RFC 6628 | Efficient Augmented Password-Only Authentication and Key Exchange for IKEv2 |
| |
| Authors: | S. Shin, K. Kobara. |
| Date: | June 2012 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6628 |
|
This document describes an efficient augmented password-only authentication and key exchange (AugPAKE) protocol where a user remembers a low-entropy password and its verifier is registered in the intended server. In general, the user password is chosen from a small set of dictionary words that allows an attacker to perform exhaustive searches (i.e., off-line dictionary attacks). The AugPAKE protocol described here is secure against passive attacks, active attacks, and off-line dictionary attacks (on the obtained messages with passive/active attacks), and also provides resistance to server compromise (in the context of augmented PAKE security). In addition, this document describes how the AugPAKE protocol is integrated into the Internet Key Exchange Protocol version 2 (IKEv2). |
|
| |
| RFC 6631 | Password Authenticated Connection Establishment with the Internet Key Exchange Protocol version 2 (IKEv2) |
| |
| Authors: | D. Kuegler, Y. Sheffer. |
| Date: | June 2012 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6631 |
|
The Internet Key Exchange protocol version 2 (IKEv2) does not allow secure peer authentication when using short credential strings, i.e., passwords. Several proposals have been made to integrate password- authentication protocols into IKE. This document provides an adaptation of Password Authenticated Connection Establishment (PACE) to the setting of IKEv2 and demonstrates the advantages of this integration. |
|
| |
| RFC 6661 | Pre-Congestion Notification (PCN) Boundary-Node Behavior for the Controlled Load (CL) Mode of Operation |
| |
| Authors: | A. Charny, F. Huang, G. Karagiannis, M. Menth, T. Taylor, Ed.. |
| Date: | July 2012 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6661 |
|
Pre-Congestion Notification (PCN) is a means for protecting the quality of service for inelastic traffic admitted to a Diffserv domain. The overall PCN architecture is described in RFC 5559. This memo is one of a series describing possible boundary-node behaviors for a PCN-domain. The behavior described here is that for a form of measurement-based load control using three PCN marking states: not- marked, threshold-marked, and excess-traffic-marked. This behavior is known informally as the Controlled Load (CL) PCN-boundary-node behavior. |
|
| |
| RFC 6662 | Pre-Congestion Notification (PCN) Boundary-Node Behavior for the Single Marking (SM) Mode of Operation |
| |
| Authors: | A. Charny, J. Zhang, G. Karagiannis, M. Menth, T. Taylor, Ed.. |
| Date: | July 2012 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6662 |
|
Pre-Congestion Notification (PCN) is a means for protecting the quality of service for inelastic traffic admitted to a Diffserv domain. The overall PCN architecture is described in RFC 5559. This memo is one of a series describing possible boundary-node behaviors for a PCN-domain. The behavior described here is that for a form of measurement-based load control using two PCN marking states: not- marked and excess-traffic-marked. This behavior is known informally as the Single Marking (SM) PCN-boundary-node behavior. |
|
| |
| RFC 6693 | Probabilistic Routing Protocol for Intermittently Connected Networks |
| |
| Authors: | A. Lindgren, A. Doria, E. Davies, S. Grasic. |
| Date: | August 2012 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6693 |
|
This document is a product of the Delay Tolerant Networking ResearchGroup and has been reviewed by that group. No objections to its publication as an RFC were raised.
This document defines PRoPHET, a Probabilistic Routing Protocol usingHistory of Encounters and Transitivity. PRoPHET is a variant of the epidemic routing protocol for intermittently connected networks that operates by pruning the epidemic distribution tree to minimize resource usage while still attempting to achieve the best-case routing capabilities of epidemic routing. It is intended for use in sparse mesh networks where there is no guarantee that a fully connected path between the source and destination exists at any time, rendering traditional routing protocols unable to deliver messages between hosts. These networks are examples of networks where there is a disparity between the latency requirements of applications and the capabilities of the underlying network (networks often referred to as delay and disruption tolerant). The document presents an architectural overview followed by the protocol specification. |
|
| |
| RFC 6706 | Asymmetric Extended Route Optimization (AERO) |
| |
| Authors: | F. Templin, Ed.. |
| Date: | August 2012 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6706 |
|
Nodes attached to common multi-access link types (e.g., multicast- capable, shared media, non-broadcast multiple access (NBMA), etc.) can exchange packets as neighbors on the link, but they may not always be provisioned with sufficient routing information for optimal neighbor selection. Such nodes should therefore be able to discover a trusted intermediate router on the link that provides both forwarding services to reach off-link destinations and redirection services to inform the node of an on-link neighbor that is closer to the final destination. This redirection can provide a useful route optimization, since the triangular path from the ingress link neighbor, to the intermediate router, and finally to the egress link neighbor may be considerably longer than the direct path from ingress to egress. However, ordinary redirection may lead to operational issues on certain link types and/or in certain deployment scenarios.This document therefore introduces an Asymmetric Extended RouteOptimization (AERO) capability that addresses the issues. |
|
| |
| RFC 6739 | Synchronizing Service Boundaries and Elements Based on the Location-to-Service Translation (LoST) Protocol |
| |
| Authors: | H. Schulzrinne, H. Tschofenig. |
| Date: | October 2012 |
| Formats: | txt html json |
| Updated by: | RFC 8996 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6739 |
|
The Location-to-Service Translation (LoST) protocol is an XML-based protocol for mapping service identifiers and geodetic or civic location information to service URIs and service boundaries. In particular, it can be used to determine the location-appropriatePublic Safety Answering Point (PSAP) for emergency services.
The <mapping&rt; element in the LoST protocol specification encapsulates information about service boundaries and circumscribes the region within which all locations map to the same service Uniform ResourceIdentifier (URI) or set of URIs for a given service.
This document defines an XML protocol to exchange these mappings between two nodes. This mechanism is designed for the exchange of authoritative <mapping&rt; elements between two entities. Exchanging cached <mapping&rt; elements, i.e., non-authoritative elements, is possible but not envisioned. Even though the <mapping&rt; element format is reused from the LoST specification, the mechanism in this document can be used without the LoST protocol. |
|
| |
| RFC 6740 | Identifier-Locator Network Protocol (ILNP) Architectural Description |
| |
| Authors: | RJ Atkinson, SN Bhatti. |
| Date: | November 2012 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6740 |
|
This document provides an architectural description and the concept of operations for the Identifier-Locator Network Protocol (ILNP), which is an experimental, evolutionary enhancement to IP. This is a product of the IRTF Routing Research Group. |
|
| |
| RFC 6741 | Identifier-Locator Network Protocol (ILNP) Engineering Considerations |
| |
| Authors: | RJ Atkinson, SN Bhatti. |
| Date: | November 2012 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6741 |
|
This document describes common (i.e., version independent) engineering details for the Identifier-Locator Network Protocol(ILNP), which is an experimental, evolutionary enhancement to IP.This document is a product of the IRTF Routing Research Group. |
|
| |
| RFC 6742 | DNS Resource Records for the Identifier-Locator Network Protocol (ILNP) |
| |
| Authors: | RJ Atkinson, SN Bhatti, S. Rose. |
| Date: | November 2012 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6742 |
|
This note describes additional optional resource records for use with the Domain Name System (DNS). These optional resource records are for use with the Identifier-Locator Network Protocol (ILNP). This document is a product of the IRTF Routing Research Group. |
|
| |
| RFC 6743 | ICMP Locator Update Message for the Identifier-Locator Network Protocol for IPv6 (ILNPv6) |
| |
| Authors: | RJ Atkinson, SN Bhatti. |
| Date: | November 2012 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6743 |
|
This note specifies an experimental ICMPv6 message type used with theIdentifier-Locator Network Protocol (ILNP). The Identifier-LocatorNetwork Protocol (ILNP) is an experimental, evolutionary enhancement to IP. This message is used to dynamically update Identifier/Locator bindings for an existing ILNP session. This is a product of the IRTFRouting Research Group. |
|
| |
| RFC 6744 | IPv6 Nonce Destination Option for the Identifier-Locator Network Protocol for IPv6 (ILNPv6) |
| |
| Authors: | RJ Atkinson, SN Bhatti. |
| Date: | November 2012 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6744 |
|
The Identifier-Locator Network Protocol (ILNP) is an experimental, evolutionary enhancement to IP. ILNP has multiple instantiations.This document describes an experimental Nonce Destination Option used only with ILNP for IPv6 (ILNPv6). This document is a product of theIRTF Routing Research Group. |
|
| |
| RFC 6745 | ICMP Locator Update Message for the Identifier-Locator Network Protocol for IPv4 (ILNPv4) |
| |
| Authors: | RJ Atkinson, SN Bhatti. |
| Date: | November 2012 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6745 |
|
This note defines an experimental ICMP message type for IPv4 used with the Identifier-Locator Network Protocol (ILNP). ILNP is an experimental, evolutionary enhancement to IP. The ICMP message defined herein is used to dynamically update Identifier/Locator bindings for an existing ILNP session. This is a product of the IRTFRouting Research Group. |
|
| |
| RFC 6746 | IPv4 Options for the Identifier-Locator Network Protocol (ILNP) |
| |
| Authors: | RJ Atkinson, SN Bhatti. |
| Date: | November 2012 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6746 |
|
This document defines two new IPv4 Options that are used only with the Identifier-Locator Network Protocol for IPv4 (ILNPv4). ILNP is an experimental, evolutionary enhancement to IP. This document is a product of the IRTF Routing Research Group. |
|
| |
| RFC 6747 | Address Resolution Protocol (ARP) for the Identifier-Locator Network Protocol for IPv4 (ILNPv4) |
| |
| Authors: | RJ Atkinson, SN Bhatti. |
| Date: | November 2012 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6747 |
|
This document defines an Address Resolution Protocol (ARP) extension to support the Identifier-Locator Network Protocol for IPv4 (ILNPv4).ILNP is an experimental, evolutionary enhancement to IP. This document is a product of the IRTF Routing Research Group. |
|
| |
| RFC 6748 | Optional Advanced Deployment Scenarios for the Identifier-Locator Network Protocol (ILNP) |
| |
| Authors: | RJ Atkinson, SN Bhatti. |
| Date: | November 2012 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6748 |
|
This document provides an Architectural description and the Concept of Operations of some optional advanced deployment scenarios for theIdentifier-Locator Network Protocol (ILNP), which is an evolutionary enhancement to IP. None of the functions described here is required for the use or deployment of ILNP. Instead, it offers descriptions of engineering and deployment options that might provide either enhanced capability or convenience in administration or management ofILNP-based systems. |
|
| |
| RFC 6751 | Native IPv6 behind IPv4-to-IPv4 NAT Customer Premises Equipment (6a44) |
| |
| Authors: | R. Despres, Ed., B. Carpenter, D. Wing, S. Jiang. |
| Date: | October 2012 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6751 |
|
In customer sites having IPv4-only Customer Premises Equipment (CPE),Teredo (RFC 4380, RFC 5991, RFC 6081) provides last-resort IPv6 connectivity. However, because it is designed to work without the involvement of Internet Service Providers, it has significant limitations (connectivity between IPv6 native addresses and Teredo addresses is uncertain; connectivity between Teredo addresses fails for some combinations of NAT types). 6a44 is a complementary solution that, being based on ISP cooperation, avoids these limitations. At the beginning of 6a44 IPv6 addresses, it replaces the Teredo well-known prefix, present at the beginning of Teredo IPv6 addresses, with network-specific /48 prefixes assigned by local ISPs(an evolution similar to that from 6to4 to 6rd (IPv6 Rapid Deployment on IPv4 Infrastructures)). The specification is expected to be complete enough for running code to be independently written and the solution to be incrementally deployed and used. |
|
| |
| RFC 6807 | Population Count Extensions to Protocol Independent Multicast (PIM) |
| |
| Authors: | D. Farinacci, G. Shepherd, S. Venaas, Y. Cai. |
| Date: | December 2012 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6807 |
|
This specification defines a method for providing multicast distribution-tree accounting data. Simple extensions to the ProtocolIndependent Multicast (PIM) protocol allow a rough approximation of tree-based data in a scalable fashion. |
|
| |
| RFC 6817 | Low Extra Delay Background Transport (LEDBAT) |
| |
| Authors: | S. Shalunov, G. Hazel, J. Iyengar, M. Kuehlewind. |
| Date: | December 2012 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6817 |
|
Low Extra Delay Background Transport (LEDBAT) is an experimental delay-based congestion control algorithm that seeks to utilize the available bandwidth on an end-to-end path while limiting the consequent increase in queueing delay on that path. LEDBAT uses changes in one-way delay measurements to limit congestion that the flow itself induces in the network. LEDBAT is designed for use by background bulk-transfer applications to be no more aggressive than standard TCP congestion control (as specified in RFC 5681) and to yield in the presence of competing flows, thus limiting interference with the network performance of competing flows. |
|
| |
| RFC 6824 | TCP Extensions for Multipath Operation with Multiple Addresses |
| |
| Authors: | A. Ford, C. Raiciu, M. Handley, O. Bonaventure. |
| Date: | January 2013 |
| Formats: | txt html json |
| Obsoleted by: | RFC 8684 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6824 |
|
TCP/IP communication is currently restricted to a single path per connection, yet multiple paths often exist between peers. The simultaneous use of these multiple paths for a TCP/IP session would improve resource usage within the network and, thus, improve user experience through higher throughput and improved resilience to network failure.
Multipath TCP provides the ability to simultaneously use multiple paths between peers. This document presents a set of extensions to traditional TCP to support multipath operation. The protocol offers the same type of service to applications as TCP (i.e., reliable bytestream), and it provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths. |
|
| |
| RFC 6830 | The Locator/ID Separation Protocol (LISP) |
| |
|
|
This document describes a network-layer-based protocol that enables separation of IP addresses into two new numbering spaces: EndpointIdentifiers (EIDs) and Routing Locators (RLOCs). No changes are required to either host protocol stacks or to the "core" of theInternet infrastructure. The Locator/ID Separation Protocol (LISP) can be incrementally deployed, without a "flag day", and offersTraffic Engineering, multihoming, and mobility benefits to early adopters, even when there are relatively few LISP-capable sites.
Design and development of LISP was largely motivated by the problem statement produced by the October 2006 IAB Routing and AddressingWorkshop. |
|
| |
| RFC 6831 | The Locator/ID Separation Protocol (LISP) for Multicast Environments |
| |
| Authors: | D. Farinacci, D. Meyer, J. Zwiebel, S. Venaas. |
| Date: | January 2013 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6831 |
|
This document describes how inter-domain multicast routing will function in an environment where Locator/ID Separation is deployed using the Locator/ID Separation Protocol (LISP) architecture. |
|
| |
| RFC 6832 | Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites |
| |
| Authors: | D. Lewis, D. Meyer, D. Farinacci, V. Fuller. |
| Date: | January 2013 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6832 |
|
This document describes techniques for allowing sites running theLocator/ID Separation Protocol (LISP) to interoperate with Internet sites that may be using either IPv4, IPv6, or both but that are not running LISP. A fundamental property of LISP-speaking sites is that they use Endpoint Identifiers (EIDs), rather than traditional IP addresses, in the source and destination fields of all traffic they emit or receive. While EIDs are syntactically identical to IPv4 orIPv6 addresses, normally routes to them are not carried in the global routing system, so an interoperability mechanism is needed for non-LISP-speaking sites to exchange traffic with LISP-speaking sites.This document introduces three such mechanisms. The first uses a new network element, the LISP Proxy Ingress Tunnel Router (Proxy-ITR), to act as an intermediate LISP Ingress Tunnel Router (ITR) for non-LISP- speaking hosts. Second, this document adds Network AddressTranslation (NAT) functionality to LISP ITRs and LISP Egress TunnelRouters (ETRs) to substitute routable IP addresses for non-routableEIDs. Finally, this document introduces the Proxy Egress TunnelRouter (Proxy-ETR) to handle cases where a LISP ITR cannot send packets to non-LISP sites without encapsulation. |
|
| |
| RFC 6833 | Locator/ID Separation Protocol (LISP) Map-Server Interface |
| |
| Authors: | V. Fuller, D. Farinacci. |
| Date: | January 2013 |
| Formats: | txt json html |
| Obsoleted by: | RFC 9301 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6833 |
|
This document describes the Mapping Service for the Locator/IDSeparation Protocol (LISP), implemented by two new types of LISP- speaking devices -- the LISP Map-Resolver and LISP Map-Server -- that provides a simplified "front end" for one or more Endpoint ID toRouting Locator mapping databases.
By using this service interface and communicating with Map-Resolvers and Map-Servers, LISP Ingress Tunnel Routers and Egress TunnelRouters are not dependent on the details of mapping database systems, which facilitates experimentation with different database designs.Since these devices implement the "edge" of the LISP infrastructure, connect directly to LISP-capable Internet end sites, and comprise the bulk of LISP-speaking devices, reducing their implementation and operational complexity should also reduce the overall cost and effort of deploying LISP. |
|
| |
| RFC 6834 | Locator/ID Separation Protocol (LISP) Map-Versioning |
| |
| Authors: | L. Iannone, D. Saucez, O. Bonaventure. |
| Date: | January 2013 |
| Formats: | txt html json |
| Obsoleted by: | RFC 9302 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6834 |
|
This document describes the LISP (Locator/ID Separation Protocol)Map-Versioning mechanism, which provides in-packet information aboutEndpoint ID to Routing Locator (EID-to-RLOC) mappings used to encapsulate LISP data packets. The proposed approach is based on associating a version number to EID-to-RLOC mappings and the transport of such a version number in the LISP-specific header ofLISP-encapsulated packets. LISP Map-Versioning is particularly useful to inform communicating Ingress Tunnel Routers (ITRs) andEgress Tunnel Routers (ETRs) about modifications of the mappings used to encapsulate packets. The mechanism is transparent to implementations not supporting this feature, since in the LISP- specific header and in the Map Records, bits used for Map-Versioning can be safely ignored by ITRs and ETRs that do not support the mechanism. |
|
| |
| RFC 6836 | Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT) |
| |
| Authors: | V. Fuller, D. Farinacci, D. Meyer, D. Lewis. |
| Date: | January 2013 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6836 |
|
This document describes a simple distributed index system to be used by a Locator/ID Separation Protocol (LISP) Ingress Tunnel Router(ITR) or Map-Resolver (MR) to find the Egress Tunnel Router (ETR) that holds the mapping information for a particular EndpointIdentifier (EID). The MR can then query that ETR to obtain the actual mapping information, which consists of a list of RoutingLocators (RLOCs) for the EID. Termed the Alternative LogicalTopology (ALT), the index is built as an overlay network on the public Internet using the Border Gateway Protocol (BGP) and GenericRouting Encapsulation (GRE). |
|
| |
| RFC 6837 | NERD: A Not-so-novel Endpoint ID (EID) to Routing Locator (RLOC) Database |
| |
| Authors: | E. Lear. |
| Date: | January 2013 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6837 |
|
The Locator/ID Separation Protocol (LISP) is a protocol to encapsulate IP packets in order to allow end sites to route to one another without injecting routes from one end of the Internet to another. This memo presents an experimental database and a discussion of methods to transport the mapping of Endpoint IDs (EIDs) to Routing Locators (RLOCs) to routers in a reliable, scalable, and secure manner. Our analysis concludes that transport of all EID-to-RLOC mappings scales well to at least 10^8 entries. |
|
| |
| RFC 6867 | An Internet Key Exchange Protocol Version 2 (IKEv2) Extension to Support EAP Re-authentication Protocol (ERP) |
| |
| Authors: | Y. Nir, Q. Wu. |
| Date: | January 2013 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6867 |
|
This document updates the Internet Key Exchange Protocol version 2(IKEv2) described in RFC 5996. This extension allows an IKE SecurityAssociation (SA) to be created and authenticated using the ExtensibleAuthentication Protocol (EAP) Re-authentication Protocol extension, as described in RFC 6696. |
|
| |
| RFC 6882 | Support for Resource Reservation Protocol Traffic Engineering (RSVP-TE) in Layer 3 Virtual Private Networks (L3VPNs) |
| |
| Authors: | K. Kumaki, Ed., T. Murai, D. Cheng, S. Matsushima, P. Jiang. |
| Date: | March 2013 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6882 |
|
IP Virtual Private Networks (VPNs) provide connectivity between sites across an IP/MPLS backbone. These VPNs can be operated usingBGP/MPLS, and a single Provider Edge (PE) node may provide access to multiple customer sites belonging to different VPNs.
The VPNs may support a number of customer services, including RSVP and Resource Reservation Protocol Traffic Engineering (RSVP-TE) traffic. This document describes how to support RSVP-TE between customer sites when a single PE supports multiple VPNs and labels are not used to identify VPNs between PEs. |
|
| |
| RFC 6919 | Further Key Words for Use in RFCs to Indicate Requirement Levels |
| |
| Authors: | R. Barnes, S. Kent, E. Rescorla. |
| Date: | 1 April 2013 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6919 |
|
RFC 2119 defines a standard set of key words for describing requirements of a specification. Many IETF documents have found that these words cannot accurately capture the nuanced requirements of their specification. This document defines additional key words that can be used to address alternative requirements scenarios. Authors who follow these guidelines should incorporate this phrase near the beginning of their document:
The key words "MUST (BUT WE KNOW YOU WON'T)", "SHOULD CONSIDER","REALLY SHOULD NOT", "OUGHT TO", "WOULD PROBABLY", "MAY WISH TO","COULD", "POSSIBLE", and "MIGHT" in this document are to be interpreted as described in RFC 6919. |
|
| |
| RFC 6928 | Increasing TCP's Initial Window |
| |
| Authors: | J. Chu, N. Dukkipati, Y. Cheng, M. Mathis. |
| Date: | April 2013 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6928 |
|
This document proposes an experiment to increase the permitted TCP initial window (IW) from between 2 and 4 segments, as specified inRFC 3390, to 10 segments with a fallback to the existing recommendation when performance issues are detected. It discusses the motivation behind the increase, the advantages and disadvantages of the higher initial window, and presents results from several large-scale experiments showing that the higher initial window improves the overall performance of many web services without resulting in a congestion collapse. The document closes with a discussion of usage and deployment for further experimental purposes recommended by the IETF TCP Maintenance and Minor Extensions (TCPM) working group. |
|
| |
| RFC 6937 | Proportional Rate Reduction for TCP |
| |
| Authors: | M. Mathis, N. Dukkipati, Y. Cheng. |
| Date: | May 2013 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6937 |
|
This document describes an experimental Proportional Rate Reduction(PRR) algorithm as an alternative to the widely deployed FastRecovery and Rate-Halving algorithms. These algorithms determine the amount of data sent by TCP during loss recovery. PRR minimizes excess window adjustments, and the actual window size at the end of recovery will be as close as possible to the ssthresh, as determined by the congestion control algorithm. |
|
| |
| RFC 6962 | Certificate Transparency |
| |
| Authors: | B. Laurie, A. Langley, E. Kasper. |
| Date: | June 2013 |
| Formats: | txt json html |
| Obsoleted by: | RFC 9162 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6962 |
|
This document describes an experimental protocol for publicly logging the existence of Transport Layer Security (TLS) certificates as they are issued or observed, in a manner that allows anyone to audit certificate authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcingCAs to add all issued certificates to the logs.
Logs are network services that implement the protocol operations for submissions and queries that are defined in this document. |
|
| |
| RFC 6968 | FCAST: Object Delivery for the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols |
| |
| Authors: | V. Roca, B. Adamson. |
| Date: | July 2013 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6968 |
|
This document introduces the FCAST reliable object (e.g., file) delivery application. It is designed to operate either on top of the underlying Asynchronous Layered Coding (ALC) / Layered CodingTransport (LCT) reliable multicast transport protocol or the NACK-Oriented Reliable Multicast (NORM) transport protocol. |
|
| |
| RFC 6971 | Depth-First Forwarding (DFF) in Unreliable Networks |
| |
| Authors: | U. Herberg, Ed., A. Cardenas, T. Iwao, M. Dow, S. Cespedes. |
| Date: | June 2013 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6971 |
|
This document specifies the Depth-First Forwarding (DFF) protocol forIPv6 networks, a data-forwarding mechanism that can increase reliability of data delivery in networks with dynamic topology and/or lossy links. The protocol operates entirely on the forwarding plane but may interact with the routing plane. DFF forwards data packets using a mechanism similar to a "depth-first search" for the destination of a packet. The routing plane may be informed of failures to deliver a packet or loops. This document specifies theDFF mechanism both for IPv6 networks (as specified in RFC 2460) and for "mesh-under" Low-Power Wireless Personal Area Networks (LoWPANs), as specified in RFC 4944. The design of DFF assumes that the underlying link layer provides means to detect if a packet has been successfully delivered to the Next Hop or not. It is applicable for networks with little traffic and is used for unicast transmissions only. |
|
| |
| RFC 6978 | A TCP Authentication Option Extension for NAT Traversal |
| |
| Authors: | J. Touch. |
| Date: | July 2013 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6978 |
|
This document describes an extension to the TCP Authentication Option(TCP-AO) to support its use over connections that pass throughNetwork Address Translators and/or Network Address and PortTranslators (NATs/NAPTs). This extension changes the data used to compute traffic keys, but it does not alter TCP-AO's packet processing or key generation algorithms. |
|
| |
| RFC 6982 | Improving Awareness of Running Code: The Implementation Status Section |
| |
|
|
This document describes a simple process that allows authors ofInternet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature.
The process in this document is offered as an experiment. Authors ofInternet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. The authors of this document intend to collate experiences with this experiment and to report them to the community. |
|
| |
| RFC 6997 | Reactive Discovery of Point-to-Point Routes in Low-Power and Lossy Networks |
| |
| Authors: | M. Goyal, Ed., E. Baccelli, M. Philipp, A. Brandt, J. Martocci. |
| Date: | August 2013 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6997 |
|
This document specifies a point-to-point route discovery mechanism, complementary to the Routing Protocol for Low-power and LossyNetworks (RPL) core functionality. This mechanism allows an IPv6 router to discover "on demand" routes to one or more IPv6 routers in a Low-power and Lossy Network (LLN) such that the discovered routes meet specified metrics constraints. |
|
| |
| RFC 6998 | A Mechanism to Measure the Routing Metrics along a Point-to-Point Route in a Low-Power and Lossy Network |
| |
| Authors: | M. Goyal, Ed., E. Baccelli, A. Brandt, J. Martocci. |
| Date: | August 2013 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 6998 |
|
This document specifies a mechanism that enables a Routing Protocol for Low-power and Lossy Networks (RPL) router to measure the aggregated values of given routing metrics along an existing route towards another RPL router, thereby allowing the router to decide if it wants to initiate the discovery of a better route. |
|
| |
| RFC 7019 | Application-Layer Multicast Extensions to REsource LOcation And Discovery (RELOAD) |
| |
| Authors: | J. Buford, M. Kolberg, Ed.. |
| Date: | September 2013 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7019 |
|
We define a REsource LOcation And Discovery (RELOAD) Usage forApplication-Layer Multicast (ALM) as well as a mapping to the RELOAD experimental message type to support ALM. The ALM Usage is intended to support a variety of ALM control algorithms in an overlay- independent way. Two example algorithms are defined, based on Scribe and P2PCast.
This document is a product of the Scalable Adaptive MulticastResearch Group (SAM RG). |
|
| |
| RFC 7028 | Multicast Mobility Routing Optimizations for Proxy Mobile IPv6 |
| |
| Authors: | JC. Zuniga, LM. Contreras, CJ. Bernardos, S. Jeon, Y. Kim. |
| Date: | September 2013 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7028 |
|
This document proposes some experimental enhancements to the base solution to support IP multicasting in a Proxy Mobile IPv6 (PMIPv6) domain. These enhancements include the use of a multicast tree mobility anchor as the topological anchor point for multicast traffic, as well as a direct routing option where the Mobile AccessGateway can provide access to multicast content in the local network.The goal of these enhancements is to provide benefits such as reducing multicast traffic replication and supporting differentPMIPv6 deployment scenarios. |
|
| |
| RFC 7038 | Use of OSPF-MDR in Single-Hop Broadcast Networks |
| |
|
|
RFC 5614 (OSPF-MDR) extends OSPF to support mobile ad hoc networks(MANETs) by specifying its operation on the new OSPF interface of type MANET. This document describes the use of OSPF-MDR (MANETDesignated Router) in a single-hop broadcast network, which is a special case of a MANET in which each router is a (one-hop) neighbor of each other router. Unlike an OSPF broadcast interface, such an interface can have a different cost associated with each neighbor.The document includes configuration recommendations and simplified mechanisms that can be used in single-hop broadcast networks. |
|
| |
| RFC 7046 | A Common API for Transparent Hybrid Multicast |
| |
| Authors: | M. Waehlisch, T. Schmidt, S. Venaas. |
| Date: | December 2013 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7046 |
|
Group communication services exist in a large variety of flavors and technical implementations at different protocol layers. Multicast data distribution is most efficiently performed on the lowest available layer, but a heterogeneous deployment status of multicast technologies throughout the Internet requires an adaptive service binding at runtime. Today, it is difficult to write an application that runs everywhere and at the same time makes use of the most efficient multicast service available in the network. Facing robustness requirements, developers are frequently forced to use a stable upper-layer protocol provided by the application itself. This document describes a common multicast API that is suitable for transparent communication in underlay and overlay and that grants access to the different flavors of multicast. It proposes an abstract naming scheme that uses multicast URIs, and it discusses mapping mechanisms between different namespaces and distribution technologies. Additionally, this document describes the application of this API for building gateways that interconnect current MulticastDomains throughout the Internet. It reports on an implementation of the programming Interface, including service middleware. This document is a product of the Scalable Adaptive Multicast (SAM)Research Group. |
|
| |
| RFC 7052 | Locator/ID Separation Protocol (LISP) MIB |
| |
| Authors: | G. Schudel, A. Jain, V. Moreno. |
| Date: | October 2013 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7052 |
|
This document defines the MIB module that contains managed objects to support the monitoring devices of the Locator/ID Separation Protocol(LISP). These objects provide information useful for monitoring LISP devices, including determining basic LISP configuration information,LISP functional status, and operational counters and other statistics. |
|
| |
| RFC 7086 | Host Identity Protocol-Based Overlay Networking Environment (HIP BONE) Instance Specification for REsource LOcation And Discovery (RELOAD) |
| |
| Authors: | A. Keranen, G. Camarillo, J. Maenpaa. |
| Date: | January 2014 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7086 |
|
This document is the HIP-Based Overlay Networking Environment (HIPBONE) instance specification for the REsource LOcation And Discovery(RELOAD) protocol. The document provides the details needed to build a RELOAD-based overlay that uses HIP. |
|
| |
| RFC 7109 | Flow Bindings Initiated by Home Agents for Mobile IPv6 |
| |
| Authors: | H. Yokota, D. Kim, B. Sarikaya, F. Xia. |
| Date: | February 2014 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7109 |
|
There are scenarios in which the home agent needs to trigger flow binding operations towards the mobile node, such as moving a flow from one access network to another based on network resource availability. In order for the home agent to be able to initiate interactions for flow bindings with the mobile node, this document defines new signaling messages and sub-options for Mobile IPv6. Flow bindings initiated by a home agent are supported for mobile nodes enabled by both IPv4 and IPv6. |
|
| |
| RFC 7122 | Datagram Convergence Layers for the Delay- and Disruption-Tolerant Networking (DTN) Bundle Protocol and Licklider Transmission Protocol (LTP) |
| |
| Authors: | H. Kruse, S. Jero, S. Ostermann. |
| Date: | March 2014 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7122 |
|
This document specifies the preferred method for transporting Delay- and Disruption-Tolerant Networking (DTN) protocol data over theInternet using datagrams. It covers convergence layers for theBundle Protocol (RFC 5050), as well as the transportation of segments using the Licklider Transmission Protocol (LTP) (RFC 5326). UDP and the Datagram Congestion Control Protocol (DCCP) are the candidate datagram protocols discussed. UDP can only be used on a local network or in cases where the DTN node implements explicit congestion control. DCCP addresses the congestion control problem, and its use is recommended whenever possible. This document is a product of theDelay-Tolerant Networking Research Group (DTNRG) and represents the consensus of the DTNRG. |
|
| |
| RFC 7137 | Use of the OSPF-MANET Interface in Single-Hop Broadcast Networks |
| |
|
|
This document describes the use of the OSPF-MANET interface in single-hop broadcast networks. It includes a mechanism to dynamically determine the presence of such a network and specific operational considerations due to its nature.
This document updates RFC 5820. |
|
| |
| RFC 7161 | Proxy Mobile IPv6 (PMIPv6) Multicast Handover Optimization by the Subscription Information Acquisition through the LMA (SIAL) |
| |
| Authors: | LM. Contreras, CJ. Bernardos, I. Soto. |
| Date: | March 2014 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7161 |
|
This document specifies an experimental multicast handover optimization mechanism for Proxy Mobile IPv6 (PMIPv6) to accelerate the delivery of multicast traffic to mobile nodes after handovers.The mechanism, called Subscription Information Acquisition through the LMA (SIAL), is based on speeding up the acquisition of mobile nodes' multicast context by the mobile access gateways. To do that, extensions to the current PMIPv6 protocol are proposed. These extensions are not only applicable to the base solution for multicast support in Proxy Mobile IPv6, but they can also be applied to other solutions developed to avoid the tunnel convergence problem.Furthermore, these extensions are also independent of the role played by the mobile access gateway within the multicast network (acting as either multicast listener discovery proxy or multicast router). |
|
| |
| RFC 7215 | Locator/Identifier Separation Protocol (LISP) Network Element Deployment Considerations |
| |
| Authors: | L. Jakab, A. Cabellos-Aparicio, F. Coras, J. Domingo-Pascual, D. Lewis. |
| Date: | April 2014 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7215 |
|
This document is a snapshot of different Locator/IdentifierSeparation Protocol (LISP) deployment scenarios. It discusses the placement of new network elements introduced by the protocol, representing the thinking of the LISP working group as of Summer2013. LISP deployment scenarios may have evolved since then. This memo represents one stable point in that evolution of understanding. |
|
| |
| RFC 7238 | The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect) |
| |
|
|
This document specifies the additional Hypertext Transfer Protocol(HTTP) status code 308 (Permanent Redirect). |
|
| |
| RFC 7242 | Delay-Tolerant Networking TCP Convergence-Layer Protocol |
| |
| Authors: | M. Demmer, J. Ott, S. Perreault. |
| Date: | June 2014 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7242 |
|
This document describes the protocol for the TCP-based convergence layer for Delay-Tolerant Networking (DTN). It is the product of theIRTF's DTN Research Group (DTNRG). |
|
| |
| RFC 7287 | Mobile Multicast Sender Support in Proxy Mobile IPv6 (PMIPv6) Domains |
| |
| Authors: | T. Schmidt, Ed., S. Gao, H. Zhang, M. Waehlisch. |
| Date: | June 2014 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7287 |
|
Multicast communication can be enabled in Proxy Mobile IPv6 (PMIPv6) domains via the Local Mobility Anchors by deploying MulticastListener Discovery (MLD) proxy functions at Mobile Access Gateways, by using direct traffic distribution within an ISP's access network, or by selective route optimization schemes. This document describes a base solution and an experimental protocol to support mobile multicast senders in PMIPv6 domains for all three scenarios.Protocol optimizations for synchronizing PMIPv6 with PIM, as well as a peering function for MLD proxies are defined. Mobile sources always remain agnostic of multicast mobility operations. |
|
| |
| RFC 7298 | Babel Hashed Message Authentication Code (HMAC) Cryptographic Authentication |
| |
|
|
This document describes a cryptographic authentication mechanism for the Babel routing protocol. This document updates RFC 6126. The mechanism allocates two new TLV types for the authentication data, uses Hashed Message Authentication Code (HMAC), and is both optional and backward compatible. |
|
| |
| RFC 7314 | Extension Mechanisms for DNS (EDNS) EXPIRE Option |
| |
| Authors: | M. Andrews. |
| Date: | July 2014 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7314 |
|
This document specifies a method for secondary DNS servers to honour the SOA EXPIRE field as if they were always transferring from the primary, even when using other secondaries to perform indirect transfers and refresh queries. |
|
| |
| RFC 7334 | PCE-Based Computation Procedure to Compute Shortest Constrained Point-to-Multipoint (P2MP) Inter-Domain Traffic Engineering Label Switched Paths |
| |
| Authors: | Q. Zhao, D. Dhody, D. King, Z. Ali, R. Casellas. |
| Date: | August 2014 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7334 |
|
The ability to compute paths for constrained point-to-multipoint(P2MP) Traffic Engineering Label Switched Paths (TE LSPs) across multiple domains has been identified as a key requirement for the deployment of P2MP services in MPLS- and GMPLS-controlled networks.The Path Computation Element (PCE) has been recognized as an appropriate technology for the determination of inter-domain paths ofP2MP TE LSPs.
This document describes an experiment to provide procedures and extensions to the PCE Communication Protocol (PCEP) for the computation of inter-domain paths for P2MP TE LSPs. |
|
| |
| RFC 7360 | Datagram Transport Layer Security (DTLS) as a Transport Layer for RADIUS |
| |
| Authors: | A. DeKok. |
| Date: | September 2014 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7360 |
|
The RADIUS protocol defined in RFC 2865 has limited support for authentication and encryption of RADIUS packets. The protocol transports data in the clear, although some parts of the packets can have obfuscated content. Packets may be replayed verbatim by an attacker, and client-server authentication is based on fixed shared secrets. This document specifies how the Datagram Transport LayerSecurity (DTLS) protocol may be used as a fix for these problems. It also describes how implementations of this proposal can coexist with current RADIUS systems. |
|
| |
| RFC 7367 | Definition of Managed Objects for the Mobile Ad Hoc Network (MANET) Simplified Multicast Framework Relay Set Process |
| |
| Authors: | R. Cole, J. Macker, B. Adamson. |
| Date: | October 2014 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7367 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes objects for configuring aspects of theSimplified Multicast Forwarding (SMF) process for Mobile Ad HocNetworks (MANETs). The SMF-MIB module also reports state information, performance information, and notifications. In addition to configuration, the additional state and performance information is useful to operators troubleshooting multicast forwarding problems. |
|
| |
| RFC 7390 | Group Communication for the Constrained Application Protocol (CoAP) |
| |
| Authors: | A. Rahman, Ed., E. Dijk, Ed.. |
| Date: | October 2014 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7390 |
|
The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for constrained devices and constrained networks.It is anticipated that constrained devices will often naturally operate in groups (e.g., in a building automation scenario, all lights in a given room may need to be switched on/off as a group).This specification defines how CoAP should be used in a group communication context. An approach for using CoAP on top of IP multicast is detailed based on existing CoAP functionality as well as new features introduced in this specification. Also, various use cases and corresponding protocol flows are provided to illustrate important concepts. Finally, guidance is provided for deployment in various network topologies. |
|
| |
| RFC 7409 | Forwarding and Control Element Separation (ForCES) Packet Parallelization |
| |
| Authors: | E. Haleplidis, J. Halpern. |
| Date: | November 2014 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7409 |
|
Many network devices support parallel packet processing. This document describes how Forwarding and Control Element Separation(ForCES) can model a network device's parallelization datapath using constructs defined by the ForCES model (RFC 5812) and controlled via the ForCES protocol (RFC 5810). |
|
| |
| RFC 7411 | Multicast Listener Extensions for Mobile IPv6 (MIPv6) and Proxy Mobile IPv6 (PMIPv6) Fast Handovers |
| |
| Authors: | T. Schmidt, Ed., M. Waehlisch, R. Koodli, G. Fairhurst, D. Liu. |
| Date: | November 2014 |
| Formats: | txt json html |
| Updates: | RFC 5568 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7411 |
|
Fast handover protocols for Mobile IPv6 (MIPv6) and Proxy Mobile IPv6(PMIPv6) define mobility management procedures that support unicast communication at reduced handover latency. Fast handover base operations do not affect multicast communication and, hence, do not accelerate handover management for native multicast listeners. Many multicast applications like IPTV or conferencing, though, comprise delay-sensitive, real-time traffic and will benefit from fast handover completion. This document specifies extension of the MobileIPv6 Fast Handovers (FMIPv6) and the Fast Handovers for Proxy MobileIPv6 (PFMIPv6) protocols to include multicast traffic management in fast handover operations. This multicast support is provided first at the control plane by management of rapid context transfer between access routers and second at the data plane by optional fast traffic forwarding that may include buffering. An FMIPv6 access router indicates support for multicast using an updated Proxy RouterAdvertisements message format.
This document updates RFC 5568, "Mobile IPv6 Fast Handovers". |
|
| |
| RFC 7413 | TCP Fast Open |
| |
| Authors: | Y. Cheng, J. Chu, S. Radhakrishnan, A. Jain. |
| Date: | December 2014 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7413 |
|
This document describes an experimental TCP mechanism called TCP FastOpen (TFO). TFO allows data to be carried in the SYN and SYN-ACK packets and consumed by the receiving end during the initial connection handshake, and saves up to one full round-trip time (RTT) compared to the standard TCP, which requires a three-way handshake(3WHS) to complete before data can be exchanged. However, TFO deviates from the standard TCP semantics, since the data in the SYN could be replayed to an application in some rare circumstances.Applications should not use TFO unless they can tolerate this issue, as detailed in the Applicability section. |
|
| |
| RFC 7417 | Extensions to Generic Aggregate RSVP for IPv4 and IPv6 Reservations over Pre-Congestion Notification (PCN) Domains |
| |
| Authors: | G. Karagiannis, A. Bhargava. |
| Date: | December 2014 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7417 |
|
This document specifies extensions to Generic Aggregate RSVP (RFC4860) for support of the Pre-Congestion Notification (PCN) ControlledLoad (CL) and Single Marking (SM) edge behaviors over a Diffserv cloud using PCN. |
|
| |
| RFC 7486 | HTTP Origin-Bound Authentication (HOBA) |
| |
| Authors: | S. Farrell, P. Hoffman, M. Thomas. |
| Date: | March 2015 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7486 |
|
HTTP Origin-Bound Authentication (HOBA) is a digital-signature-based design for an HTTP authentication method. The design can also be used in JavaScript-based authentication embedded in HTML. HOBA is an alternative to HTTP authentication schemes that require passwords and therefore avoids all problems related to passwords, such as leakage of server-side password databases. |
|
| |
| RFC 7499 | Support of Fragmentation of RADIUS Packets |
| |
| Authors: | A. Perez-Mendez, Ed., R. Marin-Lopez, F. Pereniguez-Garcia, G. Lopez-Millan, D. Lopez, A. DeKok. |
| Date: | April 2015 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7499 |
|
The Remote Authentication Dial-In User Service (RADIUS) protocol is limited to a total packet size of 4096 bytes. Provisions exist for fragmenting large amounts of authentication data across multiple packets, via Access-Challenge packets. No similar provisions exist for fragmenting large amounts of authorization data. This document specifies how existing RADIUS mechanisms can be leveraged to provide that functionality. These mechanisms are largely compatible with existing implementations, and they are designed to be invisible to proxies and "fail-safe" to legacy RADIUS Clients and Servers. |
|
| |
| RFC 7508 | Securing Header Fields with S/MIME |
| |
| Authors: | L. Cailleux, C. Bonatti. |
| Date: | April 2015 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7508 |
|
This document describes how the S/MIME protocol can be extended in order to secure message header fields defined in RFC 5322. This technology provides security services such as data integrity, non- repudiation, and confidentiality. This extension is referred to as'Secure Headers'. |
|
| |
| RFC 7514 | Really Explicit Congestion Notification (RECN) |
| |
| Authors: | M. Luckie. |
| Date: | 1 April 2015 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7514 |
|
This document proposes a new ICMP message that a router or host may use to advise a host to reduce the rate at which it sends, in cases where the host ignores other signals provided by packet loss andExplicit Congestion Notification (ECN). |
|
| |
| RFC 7557 | Extension Mechanism for the Babel Routing Protocol |
| |
|
|
This document defines the encoding of extensions to the Babel routing protocol, as specified in RFC 6126. |
|
| |
| RFC 7566 | Enumservice Registration for 'acct' URI |
| |
| Authors: | L. Goix, K. Li. |
| Date: | June 2015 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7566 |
|
This document registers an E.164 Number Mapping (ENUM) service for'acct' URIs (Uniform Resource Identifiers). |
|
| |
| RFC 7585 | Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS Based on the Network Access Identifier (NAI) |
| |
| Authors: | S. Winter, M. McCauley. |
| Date: | October 2015 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7585 |
|
This document specifies a means to find authoritative RADIUS servers for a given realm. It is used in conjunction with either RADIUS overTransport Layer Security (RADIUS/TLS) or RADIUS over DatagramTransport Layer Security (RADIUS/DTLS). |
|
| |
| RFC 7586 | The Scalable Address Resolution Protocol (SARP) for Large Data Centers |
| |
| Authors: | Y. Nachum, L. Dunbar, I. Yerushalmi, T. Mizrahi. |
| Date: | June 2015 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7586 |
|
This document introduces the Scalable Address Resolution Protocol(SARP), an architecture that uses proxy gateways to scale large data center networks. SARP is based on fast proxies that significantly reduce switches' Filtering Database (FDB) table sizes and reduce impact of ARP and Neighbor Discovery (ND) on network elements in an environment where hosts within one subnet (or VLAN) can spread over various locations. SARP is targeted for massive data centers with a significant number of Virtual Machines (VMs) that can move across various physical locations. |
|
| |
| RFC 7592 | OAuth 2.0 Dynamic Client Registration Management Protocol |
| |
| Authors: | J. Richer, Ed., M. Jones, J. Bradley, M. Machulak. |
| Date: | July 2015 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7592 |
|
This specification defines methods for management of OAuth 2.0 dynamic client registrations for use cases in which the properties of a registered client may need to be changed during the lifetime of the client. Not all authorization servers supporting dynamic client registration will support these management methods. |
|
| |
| RFC 7600 | IPv4 Residual Deployment via IPv6 - A Stateless Solution (4rd) |
| |
| Authors: | R. Despres, S. Jiang, Ed., R. Penno, Y. Lee, G. Chen, M. Chen. |
| Date: | July 2015 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7600 |
|
This document specifies a stateless solution for service providers to progressively deploy IPv6-only network domains while still offeringIPv4 service to customers. The solution's distinctive properties are that TCP/UDP IPv4 packets are valid TCP/UDP IPv6 packets during domain traversal and that IPv4 fragmentation rules are fully preserved end to end. Each customer can be assigned one public IPv4 address, several public IPv4 addresses, or a shared address with a restricted port set. |
|
| |
| RFC 7629 | Flow-Binding Support for Mobile IP |
| |
| Authors: | S. Gundavelli, Ed., K. Leung, G. Tsirtsis, A. Petrescu. |
| Date: | August 2015 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7629 |
|
This specification defines extensions to the Mobile IP protocol for allowing a mobile node with multiple interfaces to register a care-of address for each of its network interfaces and to simultaneously establish multiple IP tunnels with its home agent. This essentially allows the mobile node to utilize all the available network interfaces and build a higher aggregated logical pipe with its home agent for its home address traffic. Furthermore, these extensions also allow the mobile node and the home agent to negotiate IP traffic flow policies for binding individual flows with the registered care- of addresses. |
|
| |
| RFC 7661 | Updating TCP to Support Rate-Limited Traffic |
| |
| Authors: | G. Fairhurst, A. Sathiaseelan, R. Secchi. |
| Date: | October 2015 |
| Formats: | txt html json |
| Obsoletes: | RFC 2861 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7661 |
|
This document provides a mechanism to address issues that arise whenTCP is used for traffic that exhibits periods where the sending rate is limited by the application rather than the congestion window. It provides an experimental update to TCP that allows a TCP sender to restart quickly following a rate-limited interval. This method is expected to benefit applications that send rate-limited traffic usingTCP while also providing an appropriate response if congestion is experienced.
This document also evaluates the Experimental specification of TCPCongestion Window Validation (CWV) defined in RFC 2861 and concludes that RFC 2861 sought to address important issues but failed to deliver a widely used solution. This document therefore reclassifies the status of RFC 2861 from Experimental to Historic. This document obsoletes RFC 2861. |
|
| |
| RFC 7722 | Multi-Topology Extension for the Optimized Link State Routing Protocol Version 2 (OLSRv2) |
| |
|
|
This specification describes an extension to the Optimized Link StateRouting Protocol version 2 (OLSRv2) to support multiple routing topologies, while retaining interoperability with OLSRv2 routers that do not implement this extension.
This specification updates RFCs 7188 and 7631 by modifying and extending TLV registries and descriptions. |
|
| |
| RFC 7758 | Time Capability in NETCONF |
| |
| Authors: | T. Mizrahi, Y. Moses. |
| Date: | February 2016 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7758 |
|
This document defines a capability-based extension to the NetworkConfiguration Protocol (NETCONF) that allows time-triggered configuration and management operations. This extension allowsNETCONF clients to invoke configuration updates according to scheduled times and allows NETCONF servers to attach timestamps to the data they send to NETCONF clients. |
|
| |
| RFC 7765 | TCP and Stream Control Transmission Protocol (SCTP) RTO Restart |
| |
| Authors: | P. Hurtig, A. Brunstrom, A. Petlund, M. Welzl. |
| Date: | February 2016 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7765 |
|
This document describes a modified sender-side algorithm for managing the TCP and Stream Control Transmission Protocol (SCTP) retransmission timers that provides faster loss recovery when there is a small amount of outstanding data for a connection. The modification, RTO Restart (RTOR), allows the transport to restart its retransmission timer using a smaller timeout duration, so that the effective retransmission timeout (RTO) becomes more aggressive in situations where fast retransmit cannot be used. This enables faster loss detection and recovery for connections that are short lived or application limited. |
|
| |
| RFC 7779 | Directional Airtime Metric Based on Packet Sequence Numbers for Optimized Link State Routing Version 2 (OLSRv2) |
| |
| Authors: | H. Rogge, E. Baccelli. |
| Date: | April 2016 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7779 |
|
This document specifies a Directional Airtime (DAT) link metric for usage in Optimized Link State Routing version 2 (OLSRv2). |
|
| |
| RFC 7786 | TCP Modifications for Congestion Exposure (ConEx) |
| |
| Authors: | M. Kuehlewind, Ed., R. Scheffenegger. |
| Date: | May 2016 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7786 |
|
Congestion Exposure (ConEx) is a mechanism by which senders inform the network about expected congestion based on congestion feedback from previous packets in the same flow. This document describes the necessary modifications to use ConEx with the Transmission ControlProtocol (TCP). |
|
| |
| RFC 7804 | Salted Challenge Response HTTP Authentication Mechanism |
| |
| Authors: | A. Melnikov. |
| Date: | March 2016 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7804 |
|
This specification describes a family of HTTP authentication mechanisms called the Salted Challenge Response AuthenticationMechanism (SCRAM), which provides a more robust authentication mechanism than a plaintext password protected by Transport LayerSecurity (TLS) and avoids the deployment obstacles presented by earlier TLS-protected challenge response authentication mechanisms. |
|
| |
| RFC 7816 | DNS Query Name Minimisation to Improve Privacy |
| |
|
|
This document describes a technique to improve DNS privacy, a technique called "QNAME minimisation", where the DNS resolver no longer sends the full original QNAME to the upstream name server. |
|
| |
| RFC 7820 | UDP Checksum Complement in the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP) |
| |
| Authors: | T. Mizrahi. |
| Date: | March 2016 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7820 |
|
The One-Way Active Measurement Protocol (OWAMP) and the Two-WayActive Measurement Protocol (TWAMP) are used for performance monitoring in IP networks. Delay measurement is performed in these protocols by using timestamped test packets. Some implementations use hardware-based timestamping engines that integrate the accurate transmission time into every outgoing OWAMP/TWAMP test packet during transmission. Since these packets are transported over UDP, the UDPChecksum field is then updated to reflect this modification. This document proposes to use the last 2 octets of every test packet as aChecksum Complement, allowing timestamping engines to reflect the checksum modification in the last 2 octets rather than in the UDPChecksum field. The behavior defined in this document is completely interoperable with existing OWAMP/TWAMP implementations. |
|
| |
| RFC 7821 | UDP Checksum Complement in the Network Time Protocol (NTP) |
| |
| Authors: | T. Mizrahi. |
| Date: | March 2016 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7821 |
|
The Network Time Protocol (NTP) allows clients to synchronize to a time server using timestamped protocol messages. To facilitate accurate timestamping, some implementations use hardware-based timestamping engines that integrate the accurate transmission time into every outgoing NTP packet during transmission. Since these packets are transported over UDP, the UDP Checksum field is then updated to reflect this modification. This document proposes an extension field that includes a 2-octet Checksum Complement, allowing timestamping engines to reflect the checksum modification in the last2 octets of the packet rather than in the UDP Checksum field. The behavior defined in this document is interoperable with existing NTP implementations. |
|
| |
| RFC 7837 | IPv6 Destination Option for Congestion Exposure (ConEx) |
| |
| Authors: | S. Krishnan, M. Kuehlewind, B. Briscoe, C. Ralli. |
| Date: | May 2016 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7837 |
|
Congestion Exposure (ConEx) is a mechanism by which senders inform the network about the congestion encountered by packets earlier in the same flow. This document specifies an IPv6 destination option that is capable of carrying ConEx markings in IPv6 datagrams. |
|
| |
| RFC 7859 | Identity-Based Signatures for Mobile Ad Hoc Network (MANET) Routing Protocols |
| |
| Authors: | C. Dearlove. |
| Date: | May 2016 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7859 |
|
This document extends RFC 7182, which specifies a framework for (and specific examples of) Integrity Check Values (ICVs) for packets and messages using the generalized packet/message format specified in RFC5444. It does so by defining an additional cryptographic function that allows the creation of an ICV that is an Identity-BasedSignature (IBS), defined according to the Elliptic Curve-BasedCertificateless Signatures for Identity-Based Encryption (ECCSI) algorithm specified in RFC 6507. |
|
| |
| RFC 7897 | Domain Subobjects for the Path Computation Element Communication Protocol (PCEP) |
| |
| Authors: | D. Dhody, U. Palle, R. Casellas. |
| Date: | June 2016 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7897 |
|
The ability to compute shortest constrained Traffic Engineering LabelSwitched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) andGeneralized MPLS (GMPLS) networks across multiple domains has been identified as a key requirement. In this context, a domain is a collection of network elements within a common sphere of address management or path computational responsibility such as an InteriorGateway Protocol (IGP) area or an Autonomous System (AS). This document specifies a representation and encoding of a domain sequence, which is defined as an ordered sequence of domains traversed to reach the destination domain to be used by PathComputation Elements (PCEs) to compute inter-domain constrained shortest paths across a predetermined sequence of domains. This document also defines new subobjects to be used to encode domain identifiers. |
|
| |
| RFC 7898 | Domain Subobjects for Resource Reservation Protocol - Traffic Engineering (RSVP-TE) |
| |
| Authors: | D. Dhody, U. Palle, V. Kondreddy, R. Casellas. |
| Date: | June 2016 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7898 |
|
The Resource Reservation Protocol - Traffic Engineering (RSVP-TE) specification and the Generalized Multiprotocol Label Switching(GMPLS) extensions to RSVP-TE allow abstract nodes and resources to be explicitly included in a path setup. Further, Exclude Route extensions to RSVP-TE allow abstract nodes and resources to be explicitly excluded in a path setup.
This document specifies new subobjects to include or excludeAutonomous Systems (ASes), which are identified by a 4-byte AS number, and Interior Gateway Protocol (IGP) areas during path setup. |
|
| |
| RFC 7901 | CHAIN Query Requests in DNS |
| |
| Authors: | P. Wouters. |
| Date: | June 2016 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7901 |
|
This document defines an EDNS0 extension that can be used by a security-aware validating resolver configured to use a forwarding resolver to send a single query, requesting a complete validation path along with the regular query answer. The reduction in queries potentially lowers the latency and reduces the need to send multiple queries at once. This extension mandates the use of source-IP- verified transport such as TCP or UDP with EDNS-COOKIE, so it cannot be abused in amplification attacks. |
|
| |
| RFC 7929 | DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP |
| |
| Authors: | P. Wouters. |
| Date: | August 2016 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7929 |
|
OpenPGP is a message format for email (and file) encryption that lacks a standardized lookup mechanism to securely obtain OpenPGP public keys. DNS-Based Authentication of Named Entities (DANE) is a method for publishing public keys in DNS. This document specifies aDANE method for publishing and locating OpenPGP public keys in DNS for a specific email address using a new OPENPGPKEY DNS resource record. Security is provided via Secure DNS, however the OPENPGPKEY record is not a replacement for verification of authenticity via the"web of trust" or manual verification. The OPENPGPKEY record can be used to encrypt an email that would otherwise have to be sent unencrypted. |
|
| |
| RFC 7930 | Larger Packets for RADIUS over TCP |
| |
|
|
The RADIUS-over-TLS experiment described in RFC 6614 has openedRADIUS to new use cases where the 4096-octet maximum size limit of aRADIUS packet proves problematic. This specification extends theRADIUS-over-TCP experiment (RFC 6613) to permit larger RADIUS packets. This specification compliments other ongoing work to permit fragmentation of RADIUS authorization information. This document registers a new RADIUS code, an action that required IESG approval. |
|
| |
| RFC 7974 | An Experimental TCP Option for Host Identification |
| |
| Authors: | B. Williams, M. Boucadair, D. Wing. |
| Date: | October 2016 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 7974 |
|
Recent RFCs have discussed issues with host identification in IP address-sharing systems, such as address/prefix-sharing devices and application-layer proxies. Potential solutions for revealing a host identifier in shared address deployments have also been discussed.This memo describes the design, deployment, and privacy considerations for one such solution in operational use on theInternet today that uses a TCP option to transmit a host identifier. |
|
| |
| RFC 8033 | Proportional Integral Controller Enhanced (PIE): A Lightweight Control Scheme to Address the Bufferbloat Problem |
| |
| Authors: | R. Pan, P. Natarajan, F. Baker, G. White. |
| Date: | February 2017 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8033 |
|
Bufferbloat is a phenomenon in which excess buffers in the network cause high latency and latency variation. As more and more interactive applications (e.g., voice over IP, real-time video streaming, and financial transactions) run in the Internet, high latency and latency variation degrade application performance. There is a pressing need to design intelligent queue management schemes that can control latency and latency variation, and hence provide desirable quality of service to users.
This document presents a lightweight active queue management design called "PIE" (Proportional Integral controller Enhanced) that can effectively control the average queuing latency to a target value.Simulation results, theoretical analysis, and Linux testbed results have shown that PIE can ensure low latency and achieve high link utilization under various congestion situations. The design does not require per-packet timestamps, so it incurs very little overhead and is simple enough to implement in both hardware and software. |
|
| |
| RFC 8039 | Multipath Time Synchronization |
| |
| Authors: | A. Shpiner, R. Tse, C. Schelp, T. Mizrahi. |
| Date: | December 2016 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8039 |
|
Clock synchronization protocols are very widely used in IP-based networks. The Network Time Protocol (NTP) has been commonly deployed for many years, and the last few years have seen an increasingly rapid deployment of the Precision Time Protocol (PTP). As time- sensitive applications evolve, clock accuracy requirements are becoming increasingly stringent, requiring the time synchronization protocols to provide high accuracy. This memo describes a multipath approach to PTP and NTP over IP networks, allowing the protocols to run concurrently over multiple communication paths between the master and slave clocks, without modifying these protocols. The multipath approach can significantly contribute to clock accuracy, security, and fault tolerance. The multipath approach that is presented in this document enables backward compatibility with nodes that do not support the multipath functionality. |
|
| |
| RFC 8053 | HTTP Authentication Extensions for Interactive Clients |
| |
| Authors: | Y. Oiwa, H. Watanabe, H. Takagi, K. Maeda, T. Hayashi, Y. Ioku. |
| Date: | January 2017 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8053 |
|
This document specifies extensions for the HTTP authentication framework for interactive clients. Currently, fundamental features of HTTP-level authentication are insufficient for complex requirements of various Web-based applications. This forces these applications to implement their own authentication frameworks by means such as HTML forms, which becomes one of the hurdles against introducing secure authentication mechanisms handled jointly by servers and user agents. The extended framework fills gaps betweenWeb application requirements and HTTP authentication provisions to solve the above problems, while maintaining compatibility with existing Web and non-Web uses of HTTP authentication. |
|
| |
| RFC 8059 | PIM Join Attributes for Locator/ID Separation Protocol (LISP) Environments |
| |
| Authors: | J. Arango, S. Venaas, I. Kouvelas, D. Farinacci. |
| Date: | January 2017 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8059 |
|
This document defines two PIM Join/Prune attributes that support the construction of multicast distribution trees where the root and receivers are located in different Locator/ID Separation Protocol(LISP) sites. These attributes allow the receiver site to select between unicast and multicast underlying transport and to convey theRLOC (Routing Locator) address of the receiver ETR (Egress TunnelRouter) to the control plane of the root ITR (Ingress Tunnel Router). |
|
| |
| RFC 8060 | LISP Canonical Address Format (LCAF) |
| |
| Authors: | D. Farinacci, D. Meyer, J. Snijders. |
| Date: | February 2017 |
| Formats: | txt json html |
| Updated by: | RFC 9306 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8060 |
|
This document defines a canonical address format encoding used inLocator/ID Separation Protocol (LISP) control messages and in the encoding of lookup keys for the LISP Mapping Database System. |
|
| |
| RFC 8061 | Locator/ID Separation Protocol (LISP) Data-Plane Confidentiality |
| |
| Authors: | D. Farinacci, B. Weis. |
| Date: | February 2017 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8061 |
|
This document describes a mechanism for encrypting traffic encapsulated using the Locator/ID Separation Protocol (LISP). The design describes how key exchange is achieved using existing LISP control-plane mechanisms as well as how to secure the LISP data plane from third-party surveillance attacks. |
|
| |
| RFC 8094 | DNS over Datagram Transport Layer Security (DTLS) |
| |
| Authors: | T. Reddy, D. Wing, P. Patil. |
| Date: | February 2017 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8094 |
|
DNS queries and responses are visible to network elements on the path between the DNS client and its server. These queries and responses can contain privacy-sensitive information, which is valuable to protect.
This document proposes the use of Datagram Transport Layer Security(DTLS) for DNS, to protect against passive listeners and certain active attacks. As latency is critical for DNS, this proposal also discusses mechanisms to reduce DTLS round trips and reduce the DTLS handshake size. The proposed mechanism runs over port 853. |
|
| |
| RFC 8099 | OSPF Topology-Transparent Zone |
| |
| Authors: | H. Chen, R. Li, A. Retana, Y. Yang, Z. Liu. |
| Date: | February 2017 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8099 |
|
This document presents a Topology-Transparent Zone (TTZ) in an OSPF area. A TTZ comprises a group of routers and a number of links connecting these routers. Any router outside of the zone is not aware of the zone. A TTZ hides the internal topology of the TTZ from the outside. It does not directly advertise any internal information about the TTZ to a router outside of the TTZ. The information about the links and routers such as a link down inside the TTZ is not advertised to any router outside of the TTZ. |
|
| |
| RFC 8111 | Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT) |
| |
| Authors: | V. Fuller, D. Lewis, V. Ermagan, A. Jain, A. Smirnov. |
| Date: | May 2017 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8111 |
|
This document describes the Locator/ID Separation Protocol DelegatedDatabase Tree (LISP-DDT), a hierarchical distributed database that embodies the delegation of authority to provide mappings from LISPEndpoint Identifiers (EIDs) to Routing Locators (RLOCs). It is a statically defined distribution of the EID namespace among a set ofLISP-speaking servers called "DDT nodes". Each DDT node is configured as "authoritative" for one or more EID-prefixes, along with the set of RLOCs for Map-Servers or "child" DDT nodes to which more-specific EID-prefixes are delegated. |
|
| |
| RFC 8113 | Locator/ID Separation Protocol (LISP): Shared Extension Message & IANA Registry for Packet Type Allocations |
| |
|
|
This document specifies a Locator/ID Separation Protocol (LISP) shared message type for defining future extensions and conducting experiments without consuming a LISP packet type codepoint for each extension. It also defines a registry for LISP Packet Type allocations, thus updating RFC 6830. |
|
| |
| RFC 8120 | Mutual Authentication Protocol for HTTP |
| |
| Authors: | Y. Oiwa, H. Watanabe, H. Takagi, K. Maeda, T. Hayashi, Y. Ioku. |
| Date: | April 2017 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8120 |
|
This document specifies an authentication scheme for the HypertextTransfer Protocol (HTTP) that is referred to as either the Mutual authentication scheme or the Mutual authentication protocol. This scheme provides true mutual authentication between an HTTP client and an HTTP server using password-based authentication. Unlike the Basic and Digest authentication schemes, the Mutual authentication scheme specified in this document assures the user that the server truly knows the user's encrypted password. |
|
| |
| RFC 8121 | Mutual Authentication Protocol for HTTP: Cryptographic Algorithms Based on the Key Agreement Mechanism 3 (KAM3) |
| |
| Authors: | Y. Oiwa, H. Watanabe, H. Takagi, K. Maeda, T. Hayashi, Y. Ioku. |
| Date: | April 2017 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8121 |
|
This document specifies cryptographic algorithms for use with theMutual user authentication method for the Hypertext Transfer Protocol(HTTP). |
|
| |
| RFC 8135 | Complex Addressing in IPv6 |
| |
| Authors: | M. Danielson, M. Nilsson. |
| Date: | 1 April 2017 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8135 |
|
The 128-bit length of IPv6 addresses (RFC 4291) allows for new and innovative address schemes that can adapt to the challenges of today's complex network world. It also allows for new and improved security measures and supports advanced cloud computing challenges. |
|
| |
| RFC 8162 | Using Secure DNS to Associate Certificates with Domain Names for S/MIME |
| |
| Authors: | P. Hoffman, J. Schlyter. |
| Date: | May 2017 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8162 |
|
This document describes how to use secure DNS to associate an S/MIME user's certificate with the intended domain name, similar to the way that DNS-Based Authentication of Named Entities (DANE), RFC 6698, does for TLS. |
|
| |
| RFC 8218 | Multipath Extension for the Optimized Link State Routing Protocol Version 2 (OLSRv2) |
| |
| Authors: | J. Yi, B. Parrein. |
| Date: | August 2017 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8218 |
|
This document specifies a multipath extension for the Optimized LinkState Routing Protocol version 2 (OLSRv2) to discover multiple disjoint paths for Mobile Ad Hoc Networks (MANETs). Considering the characteristics of MANETs, especially the dynamic network topology, using multiple paths can increase aggregated throughput and improve the reliability by avoiding single route failures. The interoperability with OLSRv2 is retained. |
|
| |
| RFC 8289 | Controlled Delay Active Queue Management |
| |
| Authors: | K. Nichols, V. Jacobson, A. McGregor, Ed., J. Iyengar, Ed.. |
| Date: | January 2018 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8289 |
|
This document describes CoDel (Controlled Delay) -- a general framework that controls bufferbloat-generated excess delay in modern networking environments. CoDel consists of an estimator, a setpoint, and a control loop. It requires no configuration in normal Internet deployments. |
|
| |
| RFC 8290 | The Flow Queue CoDel Packet Scheduler and Active Queue Management Algorithm |
| |
| Authors: | T. Hoeiland-Joergensen, P. McKenney, D. Taht, J. Gettys, E. Dumazet. |
| Date: | January 2018 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8290 |
|
This memo presents the FQ-CoDel hybrid packet scheduler and ActiveQueue Management (AQM) algorithm, a powerful tool for fighting bufferbloat and reducing latency.
FQ-CoDel mixes packets from multiple flows and reduces the impact of head-of-line blocking from bursty traffic. It provides isolation for low-rate traffic such as DNS, web, and videoconferencing traffic. It improves utilisation across the networking fabric, especially for bidirectional traffic, by keeping queue lengths short, and it can be implemented in a memory- and CPU-efficient fashion across a wide range of hardware. |
|
| |
| RFC 8297 | An HTTP Status Code for Indicating Hints |
| |
| Authors: | K. Oku. |
| Date: | December 2017 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8297 |
|
This memo introduces an informational HTTP status code that can be used to convey hints that help a client make preparations for processing the final response. |
|
| |
| RFC 8298 | Self-Clocked Rate Adaptation for Multimedia |
| |
| Authors: | I. Johansson, Z. Sarker. |
| Date: | December 2017 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8298 |
|
This memo describes a rate adaptation algorithm for conversational media services such as interactive video. The solution conforms to the packet conservation principle and uses a hybrid loss-and-delay- based congestion control algorithm. The algorithm is evaluated over both simulated Internet bottleneck scenarios as well as in a LongTerm Evolution (LTE) system simulator and is shown to achieve both low latency and high video throughput in these scenarios. |
|
| |
| RFC 8321 | Alternate-Marking Method for Passive and Hybrid Performance Monitoring |
| |
| Authors: | G. Fioccola, Ed., A. Capello, M. Cociglio, L. Castaldelli, M. Chen, L. Zheng, G. Mirsky, T. Mizrahi. |
| Date: | January 2018 |
| Formats: | txt json html |
| Obsoleted by: | RFC 9341 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8321 |
|
This document describes a method to perform packet loss, delay, and jitter measurements on live traffic. This method is based on anAlternate-Marking (coloring) technique. A report is provided in order to explain an example and show the method applicability. This technology can be applied in various situations, as detailed in this document, and could be considered Passive or Hybrid depending on the application. |
|
| |
| RFC 8337 | Model-Based Metrics for Bulk Transport Capacity |
| |
| Authors: | M. Mathis, A. Morton. |
| Date: | March 2018 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8337 |
|
This document introduces a new class of Model-Based Metrics designed to assess if a complete Internet path can be expected to meet a predefined Target Transport Performance by applying a suite of IP diagnostic tests to successive subpaths. The subpath-at-a-time tests can be robustly applied to critical infrastructure, such as network interconnections or even individual devices, to accurately detect if any part of the infrastructure will prevent paths traversing it from meeting the Target Transport Performance.
Model-Based Metrics rely on mathematical models to specify a TargetedIP Diagnostic Suite, a set of IP diagnostic tests designed to assess whether common transport protocols can be expected to meet a predetermined Target Transport Performance over an Internet path.
For Bulk Transport Capacity, the IP diagnostics are built using test streams and statistical criteria for evaluating the packet transfer that mimic TCP over the complete path. The temporal structure of the test stream (e.g., bursts) mimics TCP or other transport protocols carrying bulk data over a long path. However, they are constructed to be independent of the details of the subpath under test, end systems, or applications. Likewise, the success criteria evaluates the packet transfer statistics of the subpath against criteria determined by protocol performance models applied to the TargetTransport Performance of the complete path. The success criteria also does not depend on the details of the subpath, end systems, or applications. |
|
| |
| RFC 8350 | Alternate Tunnel Encapsulation for Data Frames in Control and Provisioning of Wireless Access Points (CAPWAP) |
| |
| Authors: | R. Zhang, R. Pazhyannur, S. Gundavelli, Z. Cao, H. Deng, Z. Du. |
| Date: | April 2018 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8350 |
|
Control and Provisioning of Wireless Access Points (CAPWAP) is a protocol for encapsulating a station's data frames between theWireless Transmission Point (WTP) and Access Controller (AC).Specifically, the station's IEEE 802.11 data frames can be either locally bridged or tunneled to the AC. When tunneled, a CAPWAP DataChannel is used for tunneling. In many deployments, encapsulating data frames to an entity other than the AC (for example, to an AccessRouter (AR)) is desirable. Furthermore, it may also be desirable to use different tunnel encapsulation modes between the WTP and theAccess Router. This document defines an extension to the CAPWAP protocol that supports this capability and refers to it as alternate tunnel encapsulation. The alternate tunnel encapsulation allows 1) the WTP to tunnel non-management data frames to an endpoint different from the AC and 2) the WTP to tunnel using one of many known encapsulation types, such as IP-IP, IP-GRE, or CAPWAP. The WTP may advertise support for alternate tunnel encapsulation during the discovery and join process, and the AC may select one of the supported alternate tunnel encapsulation types while configuring theWTP. |
|
| |
| RFC 8364 | PIM Flooding Mechanism (PFM) and Source Discovery (SD) |
| |
|
|
Protocol Independent Multicast - Sparse Mode (PIM-SM) uses aRendezvous Point (RP) and shared trees to forward multicast packets from new sources. Once Last-Hop Routers (LHRs) receive packets from a new source, they may join the Shortest Path Tree (SPT) for the source for optimal forwarding. This document defines a new mechanism that provides a way to support PIM-SM without the need for PIM registers, RPs, or shared trees. Multicast source information is flooded throughout the multicast domain using a new generic PIMFlooding Mechanism (PFM). This allows LHRs to learn about new sources without receiving initial data packets. |
|
| |
| RFC 8378 | Signal-Free Locator/ID Separation Protocol (LISP) Multicast |
| |
| Authors: | V. Moreno, D. Farinacci. |
| Date: | May 2018 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8378 |
|
When multicast sources and receivers are active at Locator/IDSeparation Protocol (LISP) sites, the core network is required to use native multicast so packets can be delivered from sources to group members. When multicast is not available to connect the multicast sites together, a signal-free mechanism can be used to allow traffic to flow between sites. The mechanism described in this document uses unicast replication and encapsulation over the core network for the data plane and uses the LISP mapping database system so encapsulators at the source LISP multicast site can find decapsulators at the receiver LISP multicast sites. |
|
| |
| RFC 8382 | Shared Bottleneck Detection for Coupled Congestion Control for RTP Media |
| |
| Authors: | D. Hayes, Ed., S. Ferlin, M. Welzl, K. Hiorth. |
| Date: | June 2018 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8382 |
|
This document describes a mechanism to detect whether end-to-end data flows share a common bottleneck. This mechanism relies on summary statistics that are calculated based on continuous measurements and used as input to a grouping algorithm that runs wherever the knowledge is needed. |
|
| |
| RFC 8424 | Extensions to RSVP-TE for Label Switched Path (LSP) Ingress Fast Reroute (FRR) Protection |
| |
| Authors: | H. Chen, Ed., R. Torvi, Ed.. |
| Date: | August 2018 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8424 |
|
This document describes extensions to Resource Reservation Protocol -Traffic Engineering (RSVP-TE) for locally protecting the ingress node of a Point-to-Point (P2P) or Point-to-Multipoint (P2MP) TrafficEngineered (TE) Label Switched Path (LSP). It extends the FastReroute (FRR) protection for transit nodes of an LSP to the ingress node of the LSP. The procedures described in this document are experimental. |
|
| |
| RFC 8459 | Hierarchical Service Function Chaining (hSFC) |
| |
| Authors: | D. Dolson, S. Homma, D. Lopez, M. Boucadair. |
| Date: | September 2018 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8459 |
|
Hierarchical Service Function Chaining (hSFC) is a network architecture allowing an organization to decompose a large-scale network into multiple domains of administration.
The goals of hSFC are to make a large-scale network easier to design, simpler to control, and supportive of independent functional groups within large network operators. |
|
| |
| RFC 8467 | Padding Policies for Extension Mechanisms for DNS (EDNS(0)) |
| |
| Authors: | A. Mayrhofer. |
| Date: | October 2018 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8467 |
|
RFC 7830 specifies the "Padding" option for Extension Mechanisms forDNS (EDNS(0)) but does not specify the actual padding length for specific applications. This memo lists the possible options("padding policies"), discusses the implications of each option, and provides a recommended (experimental) option. |
|
| |
| RFC 8511 | TCP Alternative Backoff with ECN (ABE) |
| |
| Authors: | N. Khademi, M. Welzl, G. Armitage, G. Fairhurst. |
| Date: | December 2018 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8511 |
|
Active Queue Management (AQM) mechanisms allow for burst tolerance while enforcing short queues to minimise the time that packets spend enqueued at a bottleneck. This can cause noticeable performance degradation for TCP connections traversing such a bottleneck, especially if there are only a few flows or their bandwidth-delay product (BDP) is large. The reception of a Congestion Experienced(CE) Explicit Congestion Notification (ECN) mark indicates that anAQM mechanism is used at the bottleneck, and the bottleneck network queue is therefore likely to be short. Feedback of this signal allows the TCP sender-side ECN reaction in congestion avoidance to reduce the Congestion Window (cwnd) by a smaller amount than the congestion control algorithm's reaction to inferred packet loss.Therefore, this specification defines an experimental change to theTCP reaction specified in RFC 3168, as permitted by RFC 8311. |
|
| |
| RFC 8547 | TCP-ENO: Encryption Negotiation Option |
| |
| Authors: | A. Bittau, D. Giffin, M. Handley, D. Mazieres, E. Smith. |
| Date: | May 2019 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8547 |
|
Despite growing adoption of TLS, a significant fraction of TCP traffic on the Internet remains unencrypted. The persistence of unencrypted traffic can be attributed to at least two factors.First, some legacy protocols lack a signaling mechanism (such as aSTARTTLS command) by which to convey support for encryption, thus making incremental deployment impossible. Second, legacy applications themselves cannot always be upgraded and therefore require a way to implement encryption transparently entirely within the transport layer. The TCP Encryption Negotiation Option (TCP-ENO) addresses both of these problems through a new TCP option kind providing out-of-band, fully backward-compatible negotiation of encryption. |
|
| |
| RFC 8548 | Cryptographic Protection of TCP Streams (tcpcrypt) |
| |
| Authors: | A. Bittau, D. Giffin, M. Handley, D. Mazieres, Q. Slack, E. Smith. |
| Date: | May 2019 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8548 |
|
This document specifies "tcpcrypt", a TCP encryption protocol designed for use in conjunction with the TCP Encryption NegotiationOption (TCP-ENO). Tcpcrypt coexists with middleboxes by tolerating resegmentation, NATs, and other manipulations of the TCP header. The protocol is self-contained and specifically tailored to TCP implementations, which often reside in kernels or other environments in which large external software dependencies can be undesirable.Because the size of TCP options is limited, the protocol requires one additional one-way message latency to perform key exchange before application data can be transmitted. However, the extra latency can be avoided between two hosts that have recently established a previous tcpcrypt connection. |
|
| |
| RFC 8569 | Content-Centric Networking (CCNx) Semantics |
| |
| Authors: | M. Mosko, I. Solis, C. Wood. |
| Date: | July 2019 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8569 |
|
This document describes the core concepts of the Content-CentricNetworking (CCNx) architecture and presents a network protocol based on two messages: Interests and Content Objects. It specifies the set of mandatory and optional fields within those messages and describes their behavior and interpretation. This architecture and protocol specification is independent of a specific wire encoding.
The protocol also uses a control message called an Interest Return, whereby one system can return an Interest message to the previous hop due to an error condition. This indicates to the previous hop that the current system will not respond to the Interest.
This document is a product of the Information-Centric NetworkingResearch Group (ICNRG). The document received wide review amongICNRG participants. Two full implementations are in active use and have informed the technical maturity of the protocol specification. |
|
| |
| RFC 8609 | Content-Centric Networking (CCNx) Messages in TLV Format |
| |
| Authors: | M. Mosko, I. Solis, C. Wood. |
| Date: | July 2019 |
| Formats: | txt html json |
| Updated by: | RFC 9510 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8609 |
|
Content-Centric Networking (CCNx) is a network protocol that uses a hierarchical name to forward requests and to match responses to requests. This document specifies the encoding of CCNx messages in aTLV packet format, including the TLV types used by each message element and the encoding of each value. The semantics of CCNx messages follow the encoding-independent CCNx Semantics specification.
This document is a product of the Information Centric Networking research group (ICNRG). The document received wide review amongICNRG participants and has two full implementations currently in active use, which have informed the technical maturity of the protocol specification. |
|
| |
| RFC 8617 | The Authenticated Received Chain (ARC) Protocol |
| |
| Authors: | K. Andersen, B. Long, Ed., S. Blank, Ed., M. Kucherawy, Ed.. |
| Date: | July 2019 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8617 |
|
The Authenticated Received Chain (ARC) protocol provides an authenticated "chain of custody" for a message, allowing each entity that handles the message to see what entities handled it before and what the message's authentication assessment was at each step in the handling.
ARC allows Internet Mail Handlers to attach assertions of message authentication assessment to individual messages. As messages traverse ARC-enabled Internet Mail Handlers, additional ARC assertions can be attached to messages to form ordered sets of ARC assertions that represent the authentication assessment at each step of the message-handling paths.
ARC-enabled Internet Mail Handlers can process sets of ARC assertions to inform message disposition decisions, identify Internet MailHandlers that might break existing authentication mechanisms, and convey original authentication assessments across trust boundaries. |
|
| |
| RFC 8672 | TLS Server Identity Pinning with Tickets |
| |
|
|
Misissued public-key certificates can prevent TLS clients from appropriately authenticating the TLS server. Several alternatives have been proposed to detect this situation and prevent a client from establishing a TLS session with a TLS end point authenticated with an illegitimate public-key certificate. These mechanisms are either not widely deployed or limited to public web browsing.
This document proposes experimental extensions to TLS with opaque pinning tickets as a way to pin the server's identity. During an initial TLS session, the server provides an original encrypted pinning ticket. In subsequent TLS session establishment, upon receipt of the pinning ticket, the server proves its ability to decrypt the pinning ticket and thus the ownership of the pinning protection key. The client can now safely conclude that the TLS session is established with the same TLS server as the original TLS session. One of the important properties of this proposal is that no manual management actions are required. |
|
| |
| RFC 8673 | HTTP Random Access and Live Content |
| |
| Authors: | C. Pratt, D. Thakore, B. Stark. |
| Date: | November 2019 |
| Formats: | txt html json xml pdf |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8673 |
|
To accommodate byte-range requests for content that has data appended over time, this document defines semantics that allow an HTTP client and a server to perform byte-range GET and HEAD requests that start at an arbitrary byte offset within the representation and end at an indeterminate offset. |
|
| |
| RFC 8698 | Network-Assisted Dynamic Adaptation (NADA): A Unified Congestion Control Scheme for Real-Time Media |
| |
| Authors: | X. Zhu, R. Pan, M. Ramalho, S. Mena. |
| Date: | February 2020 |
| Formats: | txt json xml html pdf |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8698 |
|
This document describes Network-Assisted Dynamic Adaptation (NADA), a novel congestion control scheme for interactive real-time media applications such as video conferencing. In the proposed scheme, the sender regulates its sending rate, based on either implicit or explicit congestion signaling, in a unified approach. The scheme can benefit from Explicit Congestion Notification (ECN) markings from network nodes. It also maintains consistent sender behavior in the absence of such markings by reacting to queuing delays and packet losses instead. |
|
| |
| RFC 8699 | Coupled Congestion Control for RTP Media |
| |
| Authors: | S. Islam, M. Welzl, S. Gjessing. |
| Date: | January 2020 |
| Formats: | txt json xml html pdf |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8699 |
|
When multiple congestion-controlled Real-time Transport Protocol(RTP) sessions traverse the same network bottleneck, combining their controls can improve the total on-the-wire behavior in terms of delay, loss, and fairness. This document describes such a method for flows that have the same sender, in a way that is as flexible and simple as possible while minimizing the number of changes needed to existing RTP applications. This document also specifies how to apply the method for the Network-Assisted Dynamic Adaptation (NADA) congestion control algorithm and provides suggestions on how to apply it to other congestion control algorithms. |
|
| |
| RFC 8771 | The Internationalized Deliberately Unreadable Network NOtation (I-DUNNO) |
| |
|
|
Domain Names were designed for humans, IP addresses were not. But more than 30 years after the introduction of the DNS, a minority of mankind persists in invading the realm of machine-to-machine communication by reading, writing, misspelling, memorizing, permuting, and confusing IP addresses. This memo describes theInternationalized Deliberately Unreadable Network NOtation("I-DUNNO"), a notation designed to replace current textual representations of IP addresses with something that is not only more concise but will also discourage this small, but obviously important, subset of human activity. |
|
| |
| RFC 8773 | TLS 1.3 Extension for Certificate-Based Authentication with an External Pre-Shared Key |
| |
|
|
This document specifies a TLS 1.3 extension that allows a server to authenticate with a combination of a certificate and an external pre- shared key (PSK). |
|
| |
| RFC 8803 | 0-RTT TCP Convert Protocol |
| |
| Authors: | O. Bonaventure, Ed., M. Boucadair, Ed., S. Gundavelli, S. Seo, B. Hesmans. |
| Date: | July 2020 |
| Formats: | txt pdf xml html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8803 |
|
This document specifies an application proxy, called TransportConverter, to assist the deployment of TCP extensions such asMultipath TCP. A Transport Converter may provide conversion service for one or more TCP extensions. The conversion service is provided by means of the 0-RTT TCP Convert Protocol (Convert).
This protocol provides 0-RTT (Zero Round-Trip Time) conversion service since no extra delay is induced by the protocol compared to connections that are not proxied. Also, the Convert Protocol does not require any encapsulation (no tunnels whatsoever).
This specification assumes an explicit model, where the TransportConverter is explicitly configured on hosts. As a sample applicability use case, this document specifies how the ConvertProtocol applies for Multipath TCP. |
|
| |
| RFC 8847 | Protocol for Controlling Multiple Streams for Telepresence (CLUE) |
| |
|
|
The Controlling Multiple Streams for Telepresence (CLUE) protocol is an application protocol conceived for the description and negotiation of a telepresence session. The design of the CLUE protocol takes into account the requirements and the framework defined within theIETF CLUE Working Group. A companion document, RFC 8848, delves intoCLUE signaling details as well as the SIP / Session DescriptionProtocol (SDP) session establishment phase. CLUE messages flow over the CLUE data channel, based on reliable and ordered SCTP-over-DTLS transport. ("SCTP" stands for "Stream Control TransmissionProtocol".) Message details, together with the behavior of CLUEParticipants acting as Media Providers and/or Media Consumers, are herein discussed. |
|
| |
| RFC 8848 | Session Signaling for Controlling Multiple Streams for Telepresence (CLUE) |
| |
| Authors: | R. Hanton, P. Kyzivat, L. Xiao, C. Groves. |
| Date: | January 2021 |
| Formats: | txt html json xml pdf |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8848 |
|
This document is about Controlling Multiple Streams for Telepresence(CLUE) signaling. It specifies how the CLUE protocol and the CLUE data channel are used in conjunction with each other and with existing signaling mechanisms, such as SIP and the SessionDescription Protocol (SDP), to produce a telepresence call. |
|
| |
| RFC 8850 | Controlling Multiple Streams for Telepresence (CLUE) Protocol Data Channel |
| |
|
|
This document defines how to use the WebRTC data channel mechanism to realize a data channel, referred to as a Controlling Multiple Streams for Telepresence (CLUE) data channel, for transporting CLUE protocol messages between two CLUE entities. |
|
| |
| RFC 8885 | Proxy Mobile IPv6 Extensions for Distributed Mobility Management |
| |
| Authors: | CJ. Bernardos, A. de la Oliva, F. Giust, JC. Zúñiga, A. Mourad. |
| Date: | October 2020 |
| Formats: | txt html xml pdf json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8885 |
|
Distributed Mobility Management solutions allow networks to be set up in such a way that traffic is distributed optimally and centrally deployed anchors are not relied upon to provide IP mobility support.
There are many different approaches to address Distributed MobilityManagement -- for example, extending network-based mobility protocols(like Proxy Mobile IPv6) or client-based mobility protocols (likeMobile IPv6), among others. This document follows the former approach and proposes a solution based on Proxy Mobile IPv6, in which mobility sessions are anchored at the last IP hop router (called the mobility anchor and access router). The mobility anchor and access router is an enhanced access router that is also able to operate as a local mobility anchor or mobility access gateway on a per-prefix basis. The document focuses on the required extensions to effectively support the simultaneous anchoring several flows at different distributed gateways. |
|
| |
| RFC 8889 | Multipoint Alternate-Marking Method for Passive and Hybrid Performance Monitoring |
| |
| Authors: | G. Fioccola, Ed., M. Cociglio, A. Sapio, R. Sisto. |
| Date: | August 2020 |
| Formats: | txt html pdf xml json |
| Obsoleted by: | RFC 9342 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8889 |
|
The Alternate-Marking method, as presented in RFC 8321, can only be applied to point-to-point flows, because it assumes that all the packets of the flow measured on one node are measured again by a single second node. This document generalizes and expands this methodology to measure any kind of unicast flow whose packets can follow several different paths in the network -- in wider terms, a multipoint-to-multipoint network. For this reason, the technique here described is called "Multipoint Alternate Marking". |
|
| |
| RFC 8902 | TLS Authentication Using Intelligent Transport System (ITS) Certificates |
| |
| Authors: | M. Msahli, Ed., N. Cam-Winget, Ed., W. Whyte, Ed., A. Serhrouchni, H. Labiod. |
| Date: | September 2020 |
| Formats: | txt json xml pdf html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 8902 |
|
The IEEE and ETSI have specified a type of end-entity certificate.This document defines an experimental change to TLS to support IEEE/ETSI certificate types to authenticate TLS entities. |
|
| |
| RFC 8927 | JSON Type Definition |
| |
|
|
This document proposes a format, called JSON Type Definition (JTD), for describing the shape of JavaScript Object Notation (JSON) messages. Its main goals are to enable code generation from schemas as well as portable validation with standardized error indicators.To this end, JTD is intentionally limited to be no more expressive than the type systems of mainstream programming languages. This intentional limitation, as well as the decision to make JTD schemas be JSON documents, makes tooling atop of JTD easier to build.
This document does not have IETF consensus and is presented here to facilitate experimentation with the concept of JTD. |
|
| |
| RFC 8942 | HTTP Client Hints |
| |
|
|
HTTP defines proactive content negotiation to allow servers to select the appropriate response for a given request, based upon the user agent's characteristics, as expressed in request headers. In practice, user agents are often unwilling to send those request headers, because it is not clear whether they will be used, and sending them impacts both performance and privacy.
This document defines an Accept-CH response header that servers can use to advertise their use of request headers for proactive content negotiation, along with a set of guidelines for the creation of such headers, colloquially known as "Client Hints." |
|
| |
| RFC 8989 | Additional Criteria for Nominating Committee Eligibility |
| |
|
|
This document defines a process experiment under RFC 3933 that temporarily updates the criteria for qualifying volunteers to participate in the IETF Nominating Committee. It therefore also updates the criteria for qualifying signatories to a community recall petition. The purpose is to make the criteria more flexible in view of increasing remote participation in the IETF and a reduction in face-to-face meetings. The experiment is of fixed duration and will apply to one, or at most two, consecutive Nominating Committee cycles, starting in 2021. This document temporarily varies the rules in RFC 8713. |
|
| |
| RFC 9028 | Native NAT Traversal Mode for the Host Identity Protocol |
| |
| Authors: | A. Keränen, J. Melén, M. Komu, Ed.. |
| Date: | July 2021 |
| Formats: | txt xml pdf html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 9028 |
|
This document specifies a new Network Address Translator (NAT) traversal mode for the Host Identity Protocol (HIP). The new mode is based on the Interactive Connectivity Establishment (ICE) methodology and UDP encapsulation of data and signaling traffic. The main difference from the previously specified modes is the use of HIP messages instead of ICE for all NAT traversal procedures due to the kernel-space dependencies of HIP. |
|
| |
| RFC 9057 | Email Author Header Field |
| |
|
|
Internet mail defines the From: header field to indicate the author of the message's content and the Sender: field to indicate who initially handled the message on the author's behalf. The Sender: field is optional if it has the same information as the From: field.This was not a problem until development of stringent protections on use of the From: field. It has prompted Mediators, such as mailing lists, to modify the From: field to circumvent mail rejection caused by those protections. In effect, the From: field has become dominated by its role as a handling identifier.
The current specification augments the altered use of the From: field by specifying the Author: field, which ensures identification of the original author of the message and is not subject to modification byMediators. This document is published as an Experimental RFC to assess community interest, functional efficacy, and technical adequacy. |
|
| |
| RFC 9078 | Reaction: Indicating Summary Reaction to a Message |
| |
| Authors: | D. Crocker, R. Signes, N. Freed. |
| Date: | August 2021 |
| Formats: | txt json pdf xml html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 9078 |
|
The popularity of social media has led to user comfort with easily signaling basic reactions to an author's posting, such as with a'thumbs up' or 'smiley' graphic. This specification permits a similar facility for Internet Mail. |
|
| |
| RFC 9091 | Experimental Domain-Based Message Authentication, Reporting, and Conformance (DMARC) Extension for Public Suffix Domains |
| |
| Authors: | S. Kitterman, T. Wicinski, Ed.. |
| Date: | July 2021 |
| Formats: | txt json xml pdf html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 9091 |
|
Domain-based Message Authentication, Reporting, and Conformance(DMARC), defined in RFC 7489, permits a domain-controlling organization to express domain-level policies and preferences for message validation, disposition, and reporting, which a mail- receiving organization can use to improve mail handling.
DMARC distinguishes the portion of a name that is a Public SuffixDomain (PSD), below which Organizational Domain names are created.The basic DMARC capability allows Organizational Domains to specify policies that apply to their subdomains, but it does not give that capability to PSDs. This document describes an extension to DMARC to fully enable DMARC functionality for PSDs.
Some implementations of DMARC consider a PSD to be ineligible forDMARC enforcement. This specification addresses that case. |
|
| |
| RFC 9102 | TLS DNSSEC Chain Extension |
| |
| Authors: | V. Dukhovni, S. Huque, W. Toorop, P. Wouters, M. Shore. |
| Date: | August 2021 |
| Formats: | txt html xml pdf json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 9102 |
|
This document describes an experimental TLS extension for the in-band transport of the complete set of records that can be validated byDNSSEC and that are needed to perform DNS-Based Authentication ofNamed Entities (DANE) of a TLS server. This extension obviates the need to perform separate, out-of-band DNS lookups. When the requisite DNS records do not exist, the extension conveys a denial- of-existence proof that can be validated.
This experimental extension is developed outside the IETF and is published here to guide implementation of the extension and to ensure interoperability among implementations. |
|
| |
| RFC 9139 | Information-Centric Networking (ICN) Adaptation to Low-Power Wireless Personal Area Networks (LoWPANs) |
| |
| Authors: | C. Gündoğan, T. Schmidt, M. Wählisch, C. Scherb, C. Marxer, C. Tschudin. |
| Date: | November 2021 |
| Formats: | txt xml pdf json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 9139 |
|
This document defines a convergence layer for Content-CentricNetworking (CCNx) and Named Data Networking (NDN) over IEEE 802.15.4Low-Power Wireless Personal Area Networks (LoWPANs). A new frame format is specified to adapt CCNx and NDN packets to the small MTU size of IEEE 802.15.4. For that, syntactic and semantic changes to the TLV-based header formats are described. To support compatibility with other LoWPAN technologies that may coexist on a wireless medium, the dispatching scheme provided by IPv6 over LoWPAN (6LoWPAN) is extended to include new dispatch types for CCNx and NDN.Additionally, the fragmentation component of the 6LoWPAN dispatching framework is applied to Information-Centric Network (ICN) chunks. In its second part, the document defines stateless and stateful compression schemes to improve efficiency on constrained links.Stateless compression reduces TLV expressions to static header fields for common use cases. Stateful compression schemes elide states local to the LoWPAN and replace names in Data packets by short local identifiers.
This document is a product of the IRTF Information-Centric NetworkingResearch Group (ICNRG). |
|
| |
| RFC 9162 | Certificate Transparency Version 2.0 |
| |
|
|
This document describes version 2.0 of the Certificate Transparency(CT) protocol for publicly logging the existence of Transport LayerSecurity (TLS) server certificates as they are issued or observed, in a manner that allows anyone to audit certification authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs.
This document obsoletes RFC 6962. It also specifies a new TLS extension that is used to send various CT log artifacts.
Logs are network services that implement the protocol operations for submissions and queries that are defined in this document. |
|
| |
| RFC 9163 | Expect-CT Extension for HTTP |
| |
|
|
This document defines a new HTTP header field named "Expect-CT", which allows web host operators to instruct user agents (UAs) to expect valid Signed Certificate Timestamps (SCTs) to be served on connections to these hosts. Expect-CT allows web host operators to discover misconfigurations in their Certificate Transparency (CT) deployments. Further, web host operators can use Expect-CT to ensure that if a UA that supports Expect-CT accepts a misissued certificate, that certificate will be discoverable in Certificate Transparency logs. |
|
| |
| RFC 9188 | Generic Multi-Access (GMA) Encapsulation Protocol |
| |
|
|
A device can be simultaneously connected to multiple networks, e.g.,Wi-Fi, LTE, 5G, and DSL. It is desirable to seamlessly combine the connectivity over these networks below the transport layer (L4) to improve the quality of experience for applications that do not have built-in multi-path capabilities. Such optimization requires additional control information, e.g., a sequence number, in each packet. This document presents a new lightweight and flexible encapsulation protocol for this need. The solution has been developed by the authors based on their experiences in multiple standards bodies including the IETF and 3GPP. However, this document is not an Internet Standard and does not represent the consensus opinion of the IETF. This document will enable other developers to build interoperable implementations in order to experiment with the protocol. |
|
| |
| RFC 9226 | Bioctal: Hexadecimal 2.0 |
| |
|
|
The prevailing hexadecimal system was chosen for congruence with groups of four binary digits, but its design exhibits an indifference to cognitive factors. An alternative is introduced that is designed to reduce brain cycles in cases where a hexadecimal number should be readily convertible to binary by a human being. |
|
| |
| RFC 9228 | Delivered-To Email Header Field |
| |
|
|
The address to which email is delivered might be different than any of the addresses shown in any of the content header fields that were created by the email's author. For example, the address used by the email transport service is provided separately, such as throughSMTP's "RCPT TO" command, and might not match any address in the To: or cc: fields. In addition, before final delivery, handling can entail a sequence of submission/delivery events, using a sequence of different destination addresses that (eventually) lead to the recipient. As well, a receiving system's delivery process can produce local address transformations.
It can be helpful for a message to have a common way to record each delivery in such a sequence, noting each address used in the sequence to that recipient, such as for (1) analyzing the path a message has taken, (2) loop detection, or (3) formulating the author's address in a reply message. This document defines a header field for this information.
Email handling information discloses details about the email infrastructure, as well as about a particular recipient; this can raise privacy concerns.
A header field such as this is not automatically assured of widespread use. Therefore, this document is being published as anExperimental RFC, looking for constituency and for operational utility. This document was produced through the IndependentSubmission Stream and was not subject to the IETF's approval process. |
|
| |
| RFC 9229 | IPv4 Routes with an IPv6 Next Hop in the Babel Routing Protocol |
| |
|
|
This document defines an extension to the Babel routing protocol that allows announcing routes to an IPv4 prefix with an IPv6 next hop, which makes it possible for IPv4 traffic to flow through interfaces that have not been assigned an IPv4 address. |
|
| |
| RFC 9230 | Oblivious DNS over HTTPS |
| |
| Authors: | E. Kinnear, P. McManus, T. Pauly, T. Verma, C.A. Wood. |
| Date: | June 2022 |
| Formats: | txt pdf html xml json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 9230 |
|
This document describes a protocol that allows clients to hide theirIP addresses from DNS resolvers via proxying encrypted DNS over HTTPS(DoH) messages. This improves privacy of DNS operations by not allowing any one server entity to be aware of both the client IP address and the content of DNS queries and answers.
This experimental protocol has been developed outside the IETF and is published here to guide implementation, ensure interoperability among implementations, and enable wide-scale experimentation. |
|
| |
| RFC 9268 | IPv6 Minimum Path MTU Hop-by-Hop Option |
| |
|
|
This document specifies a new IPv6 Hop-by-Hop Option that is used to record the Minimum Path MTU (PMTU) along the forward path between a source host to a destination host. The recorded value can then be communicated back to the source using the return Path MTU field in the Option. |
|
| |
| RFC 9275 | An Extension for Application-Layer Traffic Optimization (ALTO): Path Vector |
| |
| Authors: | K. Gao, Y. Lee, S. Randriamasy, Y. Yang, J. Zhang. |
| Date: | September 2022 |
| Formats: | txt json html xml pdf |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 9275 |
|
This document is an extension to the base Application-Layer TrafficOptimization (ALTO) protocol. It extends the ALTO cost map and ALTO property map services so that an application can decide to which endpoint(s) to connect based not only on numerical/ordinal cost values but also on fine-grained abstract information regarding the paths. This is useful for applications whose performance is impacted by specific components of a network on the end-to-end paths, e.g., they may infer that several paths share common links and prevent traffic bottlenecks by avoiding such paths. This extension introduces a new abstraction called the "Abstract Network Element"(ANE) to represent these components and encodes a network path as a vector of ANEs. Thus, it provides a more complete but still abstract graph representation of the underlying network(s) for informed traffic optimization among endpoints. |
|
| |
| RFC 9306 | Vendor-Specific LISP Canonical Address Format (LCAF) |
| |
| Authors: | A. Rodriguez-Natal, V. Ermagan, A. Smirnov, V. Ashtaputre, D. Farinacci. |
| Date: | October 2022 |
| Formats: | txt html pdf xml json |
| Updates: | RFC 8060 |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 9306 |
|
This document describes a new Locator/ID Separation Protocol (LISP)Canonical Address Format (LCAF), the Vendor-Specific LCAF. This LCAF enables organizations to have implementation-specific encodings forLCAF addresses. This document updates RFC 8060. |
|
| |
| RFC 9331 | The Explicit Congestion Notification (ECN) Protocol for Low Latency, Low Loss, and Scalable Throughput (L4S) |
| |
| Authors: | K. De Schepper, B. Briscoe, Ed.. |
| Date: | January 2023 |
| Formats: | txt xml json pdf html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 9331 |
|
This specification defines the protocol to be used for a new network service called Low Latency, Low Loss, and Scalable throughput (L4S).L4S uses an Explicit Congestion Notification (ECN) scheme at the IP layer that is similar to the original (or 'Classic') ECN approach, except as specified within. L4S uses 'Scalable' congestion control, which induces much more frequent control signals from the network, and it responds to them with much more fine-grained adjustments so that very low (typically sub-millisecond on average) and consistently low queuing delay becomes possible for L4S traffic without compromising link utilization. Thus, even capacity-seeking (TCP- like) traffic can have high bandwidth and very low delay at the same time, even during periods of high traffic load.
The L4S identifier defined in this document distinguishes L4S from'Classic' (e.g., TCP-Reno-friendly) traffic. Then, network bottlenecks can be incrementally modified to distinguish and isolate existing traffic that still follows the Classic behaviour, to prevent it from degrading the low queuing delay and low loss of L4S traffic.This Experimental specification defines the rules that L4S transports and network elements need to follow, with the intention that L4S flows neither harm each other's performance nor that of Classic traffic. It also suggests open questions to be investigated during experimentation. Examples of new Active Queue Management (AQM) marking algorithms and new transports (whether TCP-like or real time) are specified separately. |
|
| |
| RFC 9332 | Dual-Queue Coupled Active Queue Management (AQM) for Low Latency, Low Loss, and Scalable Throughput (L4S) |
| |
| Authors: | K. De Schepper, B. Briscoe, Ed., G. White. |
| Date: | January 2023 |
| Formats: | txt html json pdf xml |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 9332 |
|
This specification defines a framework for coupling the Active QueueManagement (AQM) algorithms in two queues intended for flows with different responses to congestion. This provides a way for theInternet to transition from the scaling problems of standard TCP-Reno-friendly ('Classic') congestion controls to the family of'Scalable' congestion controls. These are designed for consistently very low queuing latency, very low congestion loss, and scaling of per-flow throughput by using Explicit Congestion Notification (ECN) in a modified way. Until the Coupled Dual Queue (DualQ), theseScalable L4S congestion controls could only be deployed where a clean-slate environment could be arranged, such as in private data centres.
This specification first explains how a Coupled DualQ works. It then gives the normative requirements that are necessary for it to work well. All this is independent of which two AQMs are used, but pseudocode examples of specific AQMs are given in appendices. |
|
| |
| RFC 9344 | CCNinfo: Discovering Content and Network Information in Content-Centric Networks |
| |
| Authors: | H. Asaeda, A. Ooka, X. Shao. |
| Date: | February 2023 |
| Formats: | txt xml pdf html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 9344 |
|
This document describes a mechanism named "CCNinfo" that discovers information about the network topology and in-network cache inContent-Centric Networks (CCNs). CCNinfo investigates 1) the CCN routing path information per name prefix, 2) the Round-Trip Time(RTT) between the content forwarder and the consumer, and 3) the states of in-network cache per name prefix. CCNinfo is useful to understand and debug the behavior of testbed networks and other experimental deployments of CCN systems.
This document is a product of the IRTF Information-Centric NetworkingResearch Group (ICNRG). This document represents the consensus view of ICNRG and has been reviewed extensively by several members of theICN community and the RG. The authors and RG chairs approve of the contents. The document is sponsored under the IRTF, is not issued by the IETF, and is not an IETF standard. This is an experimental protocol and the specification may change in the future. |
|
| |
| RFC 9377 | IS-IS Flood Reflection |
| |
| Authors: | T. Przygienda, Ed., C. Bowers, Y. Lee, A. Sharma, R. White. |
| Date: | April 2023 |
| Formats: | txt xml json pdf html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 9377 |
|
This document describes a backward-compatible, optional IS-IS extension that allows the creation of IS-IS flood reflection topologies. Flood reflection permits topologies in whichIS-IS Level 1 (L1) areas provide transit-forwarding for IS-IS Level 2(L2) areas using all available L1 nodes internally. It accomplishes this by creating L2 flood reflection adjacencies within each L1 area.Those adjacencies are used to flood L2 Link State Protocol Data Units(LSPs) and are used in the L2 Shortest Path First (SPF) computation.However, they are not ordinarily utilized for forwarding within the flood reflection cluster. This arrangement gives the L2 topology significantly better scaling properties than prevalently used flat designs. As an additional benefit, only those routers directly participating in flood reflection are required to support the feature. This allows for incremental deployment of scalable L1 transit areas in an existing, previously flat network design, without the necessity of upgrading all routers in the network. |
|
| |
| RFC 9407 | Tetrys: An On-the-Fly Network Coding Protocol |
| |
| Authors: | J. Detchart, E. Lochin, J. Lacan, V. Roca. |
| Date: | June 2023 |
| Formats: | txt xml pdf json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 9407 |
|
This document describes Tetrys, which is an on-the-fly network coding protocol that can be used to transport delay-sensitive and loss- sensitive data over a lossy network. Tetrys may recover from erasures within an RTT-independent delay thanks to the transmission of coded packets. This document is a record of the experience gained by the authors while developing and testing the Tetrys protocol in real conditions.
This document is a product of the Coding for Efficient NetWorkCommunications Research Group (NWCRG). It conforms to the NWCRG taxonomy described in RFC 8406. |
|
| |
| RFC 9477 | Complaint Feedback Loop Address Header |
| |
|
|
This document describes a method that allows a Message Originator to specify a Complaint Feedback Loop (CFBL) address as a message header field. It also defines the rules for processing and forwarding such a complaint. The motivation for this arises out of the absence of a standardized and automated way to provide Mailbox Providers with an address for a CFBL. Currently, providing and maintaining such an address is a manual and time-consuming process for MessageOriginators and Mailbox Providers.
The mechanism specified in this document is being published as an experiment to gather feedback and gauge the interest of implementers and deployers. This document is produced through the Independent RFCStream and was not subject to the IETF's approval process. |
|
| |
| RFC 9507 | Information-Centric Networking (ICN) Traceroute Protocol Specification |
| |
| Authors: | S. Mastorakis, D. Oran, I. Moiseenko, J. Gibson, R. Droms. |
| Date: | March 2024 |
| Formats: | txt pdf xml html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 9507 |
|
This document presents the design of an Information-CentricNetworking (ICN) Traceroute protocol. This includes the operation of both the client and the forwarder.
This document is a product of the Information-Centric NetworkingResearch Group (ICNRG) of the IRTF. |
|
| |
| RFC 9508 | Information-Centric Networking (ICN) Ping Protocol Specification |
| |
| Authors: | S. Mastorakis, D. Oran, J. Gibson, I. Moiseenko, R. Droms. |
| Date: | March 2024 |
| Formats: | txt pdf json xml html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 9508 |
|
This document presents the design of an Information-CentricNetworking (ICN) Ping protocol. It includes the operations of both the client and the forwarder.
This document is a product of the Information-Centric NetworkingResearch Group (ICNRG) of the IRTF. |
|
| |
| RFC 9510 | Alternative Delta Time Encoding for Content-Centric Networking (CCNx) Using Compact Floating-Point Arithmetic |
| |
|
|
Content-Centric Networking (CCNx) utilizes delta time for a number of functions. When using CCNx in environments with constrained nodes or bandwidth-constrained networks, it is valuable to have a compressed representation of delta time. In order to do so, either accuracy or dynamic range has to be sacrificed. Since the current uses of delta time do not require both simultaneously, one can consider a logarithmic encoding. This document updates RFC 8609 ("CCNx messages in TLV Format") to specify this alternative encoding.
This document is a product of the IRTF Information-Centric NetworkingResearch Group (ICNRG). |
|
| |
| RFC 9526 | Simple Provisioning of Public Names for Residential Networks |
| |
| Authors: | D. Migault, R. Weber, M. Richardson, R. Hunter. |
| Date: | January 2024 |
| Formats: | txt html pdf xml json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 9526 |
|
Home network owners may have devices or services hosted on their home network that they wish to access from the Internet (i.e., from a network outside of the home network). Home networks are increasingly numbered using IPv6 addresses, which in principle makes this access simpler, but accessing home networks from the Internet requires the names and IP addresses of these devices and services to be made available in the public DNS.
This document describes how a Home Naming Authority (NHA) instructs the outsourced infrastructure to publish these pieces of information in the public DNS. The names and IP addresses of the home network are set in the Public Homenet Zone by the Homenet Naming Authority(HNA), which in turn instructs an outsourced infrastructure to publish the zone on behalf of the home network owner. |
|
| |
| RFC 9531 | Path Steering in Content-Centric Networking (CCNx) and Named Data Networking (NDN) |
| |
|
|
Path steering is a mechanism to discover paths to the producers ofInformation-Centric Networking (ICN) Content Objects and steer subsequent Interest messages along a previously discovered path. It has various uses, including the operation of state-of-the-art multi- path congestion control algorithms and for network measurement and management. This specification derives directly from the design published in "Path Switching in Content Centric and Named DataNetworks" (4th ACM Conference on Information-Centric Networking) and, therefore, does not recapitulate the design motivations, implementation details, or evaluation of the scheme. However, some technical details are different, and where there are differences, the design documented here is to be considered definitive.
This document is a product of the IRTF Information-Centric NetworkingResearch Group (ICNRG). It is not an IETF product and is not anInternet Standard. |
|
| |
| RFC 9539 | Unilateral Opportunistic Deployment of Encrypted Recursive-to-Authoritative DNS |
| |
| Authors: | D. K. Gillmor, Ed., J. Salazar, Ed., P. Hoffman, Ed.. |
| Date: | February 2024 |
| Formats: | txt json xml pdf html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 9539 |
|
This document sets out steps that DNS servers (recursive resolvers and authoritative servers) can take unilaterally (without any coordination with other peers) to defend DNS query privacy against a passive network monitor. The protections provided by the guidance in this document can be defeated by an active attacker, but they should be simpler and less risky to deploy than more powerful defenses.
The goal of this document is to simplify and speed up deployment of opportunistic encrypted transport in the recursive-to-authoritative hop of the DNS ecosystem. Wider easy deployment of the underlying encrypted transport on an opportunistic basis may facilitate the future specification of stronger cryptographic protections against more-powerful attacks. |
|
