Internet Documents RFCs RFCs All Documents STDs Internet Standards Documents BCPs Best Current Practice Documents FYIs Informational Documents

RFC 887	Resource Location Protocol
	Authors: M. Accetta. Date: December 1983 Formats: txt pdf Status: EXPERIMENTAL 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 pdf Updated by: RFC 1151 Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Obsoletes: RFC 0969 Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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)
	Authors: K. Lougheed, Y. Rekhter. Date: June 1989 Formats: txt pdf Obsoleted by: RFC 1163 Status: EXPERIMENTAL 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
	Authors: S.E. Kille. Date: December 1989 Formats: txt pdf Obsoleted by: RFC 2156, RFC 1327 Updates: RFC 1026, RFC 0987, RFC 0822 Updated by: RFC 1148 Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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
	Authors: S.E. Kille. Date: March 1990 Formats: txt pdf Obsoleted by: RFC 2156, RFC 1327 Updates: RFC 1026, RFC 0987, RFC 1138, RFC 0822 Status: EXPERIMENTAL This RFC suggests an electronic mail protocol mapping for the Internet community and UK Academic Community, and requests discussion and suggestions for improvements. This memo does not specify an Internet standard. This edition includes material lost in editing.
RFC 1149	Standard for the transmission of IP datagrams on avian carriers
	Authors: D. Waitzman. Date: April 1 1990 Formats: txt pdf Updated by: RFC 2549 Status: EXPERIMENTAL 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)
	Authors: C. Partridge, R.M. Hinden. Date: April 1990 Formats: txt pdf Updates: RFC 0908 Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL This memo describes the de facto standard Digest Message Format. This is an elective experimental protocol.
RFC 1154	Encoding header field for internet messages
	Authors: D. Robinson, R. Ullmann. Date: April 1990 Formats: txt pdf Obsoleted by: RFC 1505 Status: EXPERIMENTAL 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
	Authors: R. Nelson. Date: June 1990 Formats: txt pdf Obsoleted by: RFC 1312 Status: EXPERIMENTAL 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
	Authors: M.T. Rose. Date: June 1990 Formats: txt pdf Obsoleted by: RFC 1418 Status: EXPERIMENTAL This memo defines an experimental means for running the Simple Network Management Protocol (SNMP) over OSI transports. This memo does not specify a standard for the Internet community,
RFC 1162	Connectionless Network Protocol (ISO 8473) and End System to Intermediate System (ISO 9542) Management Information Base
	Authors: G. Satz. Date: June 1990 Formats: txt pdf Obsoleted by: RFC 1238 Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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
	Authors: M.R. Crispin. Date: August 1990 Formats: txt pdf Obsoletes: RFC 1064 Status: EXPERIMENTAL 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
	Authors: C.F. Everhart, L.A. Mamakos, R. Ullmann, P.V. Mockapetris. Date: October 1990 Formats: txt pdf Updates: RFC 1034, RFC 1035 Updated by: RFC 5395, RFC 5864, RFC 6195 Status: EXPERIMENTAL 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 pdf Obsoleted by: RFC 1323 Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Obsoletes: IEN 119 Obsoleted by: RFC 1819 Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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
	Authors: G. Carpenter, B. Wijnen. Date: May 1991 Formats: txt pdf Obsoleted by: RFC 1592 Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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)
	Authors: G. Satz. Date: June 1991 Formats: txt pdf Obsoletes: RFC 1162 Status: EXPERIMENTAL 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 pdf ps Status: EXPERIMENTAL 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 pdf ps Status: EXPERIMENTAL 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
	Authors: M. Rose. Date: December 1991 Formats: txt pdf Obsoleted by: RFC 1418 Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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
	Authors: R. Nelson, G. Arnold. Date: April 1992 Formats: txt pdf Obsoletes: RFC 1159 Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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
	Authors: B. Manning. Date: July 1992 Formats: txt pdf Obsoleted by: RFC 1637 Updates: RFC 1034, RFC 1035 Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL Potential solutions to the routing explosion. This memo defines an Experimental Protocol for the Internet community.
RFC 1393	Traceroute Using an IP Option
	Authors: G. Malkin. Date: January 1993 Formats: txt pdf Status: EXPERIMENTAL Traceroute serves as a valuable network debugging tool. The way in which it is currently implemented has the advantage of being automatically supported by all of the routers. It's two problems are the number of packets it generates and the amount of time it takes to run. This document specifies a new IP option and ICMP message type which duplicates the functionality of the existing traceroute method while generating fewer packets and completing in a shorter time.
RFC 1405	Mapping between X.400(1984/1988) and Mail-11 (DECnet mail)
	Authors: C. Allocchio. Date: January 1993 Formats: txt pdf Obsoleted by: RFC 2162 Status: EXPERIMENTAL 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
	Authors: D. Borman, Ed.. Date: January 1993 Formats: txt pdf Obsoleted by: RFC 1416 Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL This memo defines an Experimental Protocol for the Internet community.
RFC 1412	Telnet Authentication: SPX
	Authors: K. Alagappan. Date: January 1993 Formats: txt pdf Status: EXPERIMENTAL This memo defines an Experimental Protocol for the Internet community.
RFC 1416	Telnet Authentication Option
	Authors: D. Borman, Ed.. Date: February 1993 Formats: txt pdf Obsoletes: RFC 1409 Obsoleted by: RFC 2941 Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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
	Authors: D. Eastlake 3rd. Date: May 1993 Formats: txt pdf Obsoleted by: RFC 2474 Status: EXPERIMENTAL 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
	Authors: J. Oikarinen, D. Reed. Date: May 1993 Formats: txt pdf Updated by: RFC 2810, RFC 2811, RFC 2812, RFC 2813 Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 1475	TP/IX: The Next Internet
	Authors: R. Ullmann. Date: June 1993 Formats: txt pdf Status: EXPERIMENTAL The first version of this memo, describing a possible next generation of Internet protocols, was written by the present author in the summer and fall of 1989, and circulated informally, including to theIESG, in December 1989. A further informal note on the addressing, called "Toasternet Part II", was circulated on the IETF mail list during March of 1992.
RFC 1476	RAP: Internet Route Access Protocol
	Authors: R. Ullmann. Date: June 1993 Formats: txt pdf Status: EXPERIMENTAL 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
	Authors: M. Rose, C. Malamud. Date: July 1993 Formats: txt pdf Obsoleted by: RFC 1528, RFC 1529 Status: EXPERIMENTAL 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 pdf Obsoletes: RFC 1154 Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 1528	Principles of Operation for the TPC.INT Subdomain: Remote Printing -- Technical Procedures
	Authors: C. Malamud, M. Rose. Date: October 1993 Formats: txt pdf Obsoletes: RFC 1486 Status: EXPERIMENTAL 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 1545	FTP Operation Over Big Address Records (FOOBAR)
	Authors: D. Piscitello. Date: November 1993 Formats: txt pdf Obsoleted by: RFC 1639 Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Obsoletes: RFC 1228 Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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
	Authors: B. Manning, R. Colella. Date: June 1994 Formats: txt pdf Obsoletes: RFC 1348 Obsoleted by: RFC 1706 Status: EXPERIMENTAL 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)
	Authors: D. Piscitello. Date: June 1994 Formats: txt pdf Obsoletes: RFC 1545 Status: EXPERIMENTAL 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
	Authors: D. Goldsmith, M. Davis. Date: July 1994 Formats: txt pdf ps Status: EXPERIMENTAL The Unicode Standard, version 1.1, and ISO/IEC 10646-1:1993(E) jointly define a 16 bit character set (hereafter referred to asUnicode) which encompasses most of the world's writing systems.However, Internet mail (STD 11, RFC 822) currently supports only 7- bit US ASCII as a character set. MIME (RFC 1521 and RFC 1522) extendsInternet mail to support different media types and character sets, and thus could support Unicode in mail messages. MIME neither definesUnicode as a permitted character set nor specifies how it would be encoded, although it does provide for the registration of additional character sets over time. This document specifies the usage of Unicode within MIME.
RFC 1642	UTF-7 - A Mail-Safe Transformation Format of Unicode
	Authors: D. Goldsmith, M. Davis. Date: July 1994 Formats: txt pdf ps Obsoleted by: RFC 2152 Status: EXPERIMENTAL 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 pdf Obsoleted by: RFC 2163 Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 1788	ICMP Domain Name Messages
	Authors: W. Simpson. Date: April 1995 Formats: txt pdf Status: EXPERIMENTAL This document specifies ICMP messages for learning the FullyQualified Domain Name associated with an IP address.
RFC 1791	TCP And UDP Over IPX Networks With Fixed Path MTU
	Authors: T. Sung. Date: April 1995 Formats: txt pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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
	Authors: R. Troost, S. Dorner. Date: June 1995 Formats: txt pdf Obsoleted by: RFC 2183 Status: EXPERIMENTAL 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 1819	Internet Stream Protocol Version 2 (ST2) Protocol Specification - Version ST2+
	Authors: L. Delgrossi, L. Berger, Eds.. Date: August 1995 Formats: txt pdf Obsoletes: RFC 1190, IEN 119 Status: EXPERIMENTAL This memo contains a revised specification of the Internet STreamProtocol Version 2 (ST2). ST2 is an experimental resource reservation protocol intended to provide end-to-end real-time guarantees over an internet. It allows applications to build multi-destination simplex data streams with a desired quality of service. The revised version of ST2 specified in this memo is called ST2+. This specification is a product of the STream Protocol Working Group of the Internet Engineering Task Force.
RFC 1830	SMTP Service Extensions for Transmission of Large and Binary MIME Messages
	Authors: G. Vaudreuil. Date: August 1995 Formats: txt pdf Obsoleted by: RFC 3030 Status: EXPERIMENTAL 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
	Authors: S. Kille. Date: August 1995 Formats: txt pdf Obsoleted by: RFC 2294 Status: EXPERIMENTAL This document defines a representation of the O/R Address hierarchy in the Directory Information Tree [6, 1]. This is useful for a range of purposes, including:
RFC 1837	Representing Tables and Subtrees in the X.500 Directory
	Authors: S. Kille. Date: August 1995 Formats: txt pdf Obsoleted by: RFC 2293 Status: EXPERIMENTAL This document defines techniques for representing two types of information mapping in the OSI Directory [1]. 1. Mapping from a key to a value (or set of values), as might be done in a table lookup. 2. Mapping from a distinguished name to an associated value (or values), where the values are not defined by the owner of the entry. This is achieved by use of a directory subtree. These techniques were developed for supporting MHS use of Directory[2], but are specified separately as they have more general applicability.
RFC 1838	Use of the X.500 Directory to support mapping between X.400 and RFC 822 Addresses
	Authors: S. Kille. Date: August 1995 Formats: txt pdf Obsoleted by: RFC 2164 Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL This memo defines an extension to the SMTP service whereby an interrupted SMTP transaction can be restarted at a later time without having to repeat all of the commands and message content sent prior to the interruption.
RFC 1846	SMTP 521 Reply Code
	Authors: A. Durand, F. Dupont. Date: September 1995 Formats: txt pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Obsoleted by: RFC 2841 Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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
	Authors: E. Levinson. Date: December 1995 Formats: txt pdf Obsoleted by: RFC 2112 Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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
	Authors: C. Davis, P. Vixie, T. Goodwin, I. Dickinson. Date: January 1996 Formats: txt pdf Updates: RFC 1034, RFC 1035 Status: EXPERIMENTAL 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
	Authors: R. Hinden, J. Postel. Date: January 1996 Formats: txt pdf Obsoleted by: RFC 2471 Status: EXPERIMENTAL 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
	Authors: G. Vaudreuil. Date: February 1996 Formats: txt pdf Obsoleted by: RFC 2421, RFC 2422, RFC 2423 Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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
	Authors: P. Traina. Date: June 1996 Formats: txt pdf Obsoleted by: RFC 3065 Status: EXPERIMENTAL Border Gateway Protocol [1] is an inter-autonomous system routing protocol designed for TCP/IP networks. This document describes an extension to BGP which may be used to create a confederation of autonomous systems which is represented as one single autonomous system to BGP peers external to the confederation. The intention of this extension is to aid in policy administration and reduce the management complexity of maintaining a large autonomous system. The extension this document describes is widely deployed in theInternet today.
RFC 1966	BGP Route Reflection An alternative to full mesh IBGP
	Authors: T. Bates, R. Chandra. Date: June 1996 Formats: txt pdf Obsoleted by: RFC 4456 Updated by: RFC 2796 Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Obsoleted by: RFC 2782 Status: EXPERIMENTAL 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 pdf Obsoleted by: RFC 2722 Status: EXPERIMENTAL This document describes an architecture for the measurement and reporting of network traffic flows, discusses how this relates to an overall network traffic flow architecture, and describes how it can be used within the Internet. It is intended to provide a starting point for the Realtime Traffic Flow Measurement Working Group.
RFC 2064	Traffic Flow Measurement: Meter MIB
	Authors: N. Brownlee. Date: January 1997 Formats: txt pdf Obsoleted by: RFC 2720 Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Obsoleted by: RFC 2362 Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL This document contains the definitions, originally contained in RFC 1495 and RFC 1341, on how to carry ODA in MIME, and how to translate it to its X.400 representation. This memo defines an Experimental Protocol for the Internet community.
RFC 2162	MaXIM-11 - Mapping between X.400 / Internet mail and Mail-11 mail
	Authors: C. Allocchio. Date: January 1998 Formats: txt pdf Obsoletes: RFC 1405 Status: EXPERIMENTAL 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
	Authors: R. Daniel, M. Mealling. Date: June 1997 Formats: txt pdf Obsoleted by: RFC 3401, RFC 3402, RFC 3403, RFC 3404 Updated by: RFC 2915 Status: EXPERIMENTAL The requirements document for URN resolution systems defines the concept of a "resolver discovery service". This document describes the first, experimental, RDS. It is implemented by a new DNS Resource Record, NAPTR (Naming Authority PoinTeR), that provides rules for mapping parts of URIs to domain names. This memo defines an Experimental Protocol for the Internet community.
RFC 2169	A Trivial Convention for using HTTP in URN Resolution
	Authors: R. Daniel. Date: June 1997 Formats: txt pdf Status: EXPERIMENTAL This document specifies the "THTTP" resolution protocol - a trivial convention for encoding resolution service requests and responses as HTTP 1.0 or 1.1 requests and responses. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested.
RFC 2217	Telnet Com Port Control Option
	Authors: G. Clark. Date: October 1997 Formats: txt pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL HTTP allows web site authors to put multiple versions of the same information under a single URL. Transparent content negotiation is an extensible negotiation mechanism, layered on top of HTTP, for automatically selecting the best version when the URL is accessed. This enables the smooth deployment of new web data formats and markup tags. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested.
RFC 2296	HTTP Remote Variant Selection Algorithm -- RVSA/1.0
	Authors: K. Holtman, A. Mutz. Date: March 1998 Formats: txt pdf Status: EXPERIMENTAL HTTP allows web site authors to put multiple versions of the same information under a single URL. Transparent content negotiation is a mechanism for automatically selecting the best version when the URL is accessed. A remote variant selection algorithm can be used to speed up the transparent negotiation process. This document defines the remote variant selection algorithm with the version number 1.0. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested.
RFC 2307	An Approach for Using LDAP as a Network Information Service
	Authors: L. Howard. Date: March 1998 Formats: txt pdf Status: EXPERIMENTAL 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 2310	The Safe Response Header Field
	Authors: K. Holtman. Date: April 1998 Formats: txt pdf Status: EXPERIMENTAL This document defines a HTTP response header field called Safe, which can be used to indicate that repeating a HTTP request is safe. Such an indication will allow user agents to handle retries of some safe requests, in particular safe POST requests, in a more user-friendly way.
RFC 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Obsoletes: RFC 2117 Obsoleted by: RFC 4601, RFC 5059 Status: EXPERIMENTAL 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 pdf Obsoleted by: RFC 3390 Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Obsoleted by: RFC 3168 Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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
	Authors: J. Mahdavi, V. Paxson. Date: January 1999 Formats: txt pdf Obsoleted by: RFC 2678 Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Obsoleted by: RFC 2910 Status: EXPERIMENTAL 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 pdf Obsoleted by: RFC 2911 Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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
	Authors: S. Floyd, T. Henderson. Date: April 1999 Formats: txt pdf Obsoleted by: RFC 3782 Status: EXPERIMENTAL 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 pdf Obsoleted by: RFC 3179 Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL This memo describes a syntax for embedding S-HTTP negotiation parameters in HTML documents. S-HTTP, as described by RFC 2660, contains the concept of negotiation headers which reflect the potential receiver of a message's preferences as to which crypto- graphic enhancements should be applied to the message. This document describes a syntax for binding these negotiation parameters to HTML anchors. 1. Introduction 2. Anchor Attributes We define the following new anchor (and form submission) attributes: DN -- The distinguished name of the principal for whom the request should be encrypted when dereferencing the anchor's url.This need not be specified, but failure to do so runs the risk that the client will be unable to determine the DN and therefore will be unable to encrypt. This should be specified in the form of RFC1485, using SGML quoting conventions as needed. NONCE -- A free-format string (appropriately SGML quoted) which is to be included in a SHTTP-Nonce: header (after SGML quoting is removed) when the anchor is dereferenced. CRYPTOPTS -- Cryptographic option information as described in [SHTTP]. Specifically, the <cryptopt-list&rt; production.
RFC 2660	The Secure HyperText Transfer Protocol
	Authors: E. Rescorla, A. Schiffman. Date: August 1999 Formats: txt pdf Status: EXPERIMENTAL This memo describes a syntax for securing messages sent using theHypertext Transfer Protocol (HTTP), which forms the basis for theWorld Wide Web. Secure HTTP (S-HTTP) provides independently applicable security services for transaction confidentiality, authenticity/integrity and non-repudiability of origin. The protocol emphasizes maximum flexibility in choice of key management mechanisms, security policies and cryptographic algorithms by supporting option negotiation between parties for each transaction.
RFC 2673	Binary Labels in the Domain Name System
	Authors: M. Crawford. Date: August 1999 Formats: txt pdf Updated by: RFC 3363, RFC 3364 Status: EXPERIMENTAL This document defines a "Bit-String Label" which may appear within domain names. This new label type compactly represents a sequence of "One-Bit Labels" and enables resource records to be stored at any bit- boundary in a binary-named section of the domain name tree. [STANDARDS-TRACK]
RFC 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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
	Authors: B. Aboba, D. Simon. Date: October 1999 Formats: txt pdf Obsoleted by: RFC 5216 Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Obsoleted by: RFC 3180 Status: EXPERIMENTAL 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 pdf Updates: RFC 0959 Status: EXPERIMENTAL This document defines a method to encrypt a file transfer using theFTP specification STD 9, RFC 959, "File Transfer Protocol (FTP)",(October 1985) [3] and RFC 2228, "FTP Security Extensions" (October1997) [1]. This method will use the Key Exchange Algorithm (KEA) to give mutual authentication and establish the data encryption keys.SKIPJACK is used to encrypt file data and the FTP command channel.
RFC 2774	An HTTP Extension Framework
	Authors: H. Nielsen, P. Leach, S. Lawrence. Date: February 2000 Formats: txt pdf Status: EXPERIMENTAL A wide range of applications have proposed various extensions of theHTTP protocol. Current efforts span an enormous range, including distributed authoring, collaboration, printing, and remote procedure call mechanisms. These HTTP extensions are not coordinated, since there has been no standard framework for defining extensions and thus, separation of concerns. This document describes a generic extension mechanism for HTTP, which is designed to address the tension between private agreement and public specification and to accommodate extension of applications using HTTP clients, servers, and proxies. The proposal associates each extension with a globally unique identifier, and uses HTTP header fields to carry the extension identifier and related information between the parties involved in the extended communication.
RFC 2786	Diffie-Helman USM Key Management Information Base and Textual Convention
	Authors: M. St. Johns. Date: March 2000 Formats: txt pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 2861	TCP Congestion Window Validation
	Authors: M. Handley, J. Padhye, S. Floyd. Date: June 2000 Formats: txt pdf Status: EXPERIMENTAL TCP's congestion window controls the number of packets a TCP flow may have in the network at any time. However, long periods when the sender is idle or application-limited can lead to the invalidation of the congestion window, in that the congestion window no longer reflects current information about the state of the network. This document describes a simple modification to TCP's congestion control algorithms to decay the congestion window cwnd after the transition from a sufficiently-long application-limited period, while using the slow-start threshold ssthresh to save information about the previous value of the congestion window. An invalid congestion window also results when the congestion window is increased (i.e., in TCP's slow-start or congestion avoidance phases) during application-limited periods, when the previous value of the congestion window might never have been fully utilized. We propose that the TCP sender should not increase the congestion window when the TCP sender has been application-limited (and therefore has not fully used the current congestion window). We have explored these algorithms both with simulations and with experiments from an implementation in FreeBSD.
RFC 2903	Generic AAA Architecture
	Authors: C. de Laat, G. Gross, L. Gommans, J. Vollbrecht, D. Spence. Date: August 2000 Formats: txt pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Obsoletes: RFC 2593 Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 3343	The Application Exchange (APEX) Presence Service
	Authors: M. Rose, G. Klyne, D. Crocker. Date: April 2003 Formats: txt pdf Status: EXPERIMENTAL This memo describes the Application Exchange (APEX) presence service, addressed as the well-known endpoint "apex=presence". The presence service is used to manage presence information for APEX endpoints.
RFC 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Obsoleted by: RFC 5775 Status: EXPERIMENTAL 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 pdf Obsoleted by: RFC 5651 Status: EXPERIMENTAL 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 pdf Obsoleted by: RFC 5052, RFC 5445 Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL This document describes the Mesh-enhanced Service Location Protocol(mSLP). mSLP enhances the Service Location Protocol (SLP) with a scope-based fully-meshed peering Directory Agent (DA) architecture.Peer DAs exchange new service registrations in shared scopes via anti-entropy and direct forwarding. mSLP improves the reliability and consistency of SLP DA services, and simplifies Service Agent (SA) registrations in systems with multiple DAs. mSLP is backward compatible with SLPv2 and can be deployed incrementally.
RFC 3529	Using Extensible Markup Language-Remote Procedure Calling (XML-RPC) in Blocks Extensible Exchange Protocol (BEEP)
	Authors: W. Harold. Date: April 2003 Formats: txt pdf Status: EXPERIMENTAL 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 3540	Robust Explicit Congestion Notification (ECN) Signaling with Nonces
	Authors: N. Spring, D. Wetherall, D. Ely. Date: June 2003 Formats: txt pdf Status: EXPERIMENTAL This note describes the Explicit Congestion Notification (ECN)-nonce, an optional addition to ECN that protects against accidental or malicious concealment of marked packets from the TCP sender. It improves the robustness of congestion control by preventing receivers from exploiting ECN to gain an unfair share of network bandwidth.The ECN-nonce uses the two ECN-Capable Transport (ECT)codepoints in the ECN field of the IP header, and requires a flag in the TCP header. It is computationally efficient for both routers and hosts.
RFC 3561	Ad hoc On-Demand Distance Vector (AODV) Routing
	Authors: C. Perkins, E. Belding-Royer, S. Das. Date: July 2003 Formats: txt pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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
	Authors: R. Siemborski. Date: December 2003 Formats: txt pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Obsoleted by: RFC 5082 Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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
	Authors: M. Luby, L. Vicisano. Date: February 2004 Formats: txt pdf Obsoleted by: RFC 5445 Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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
	Authors: T. Hardie. Date: October 2004 Formats: txt pdf Status: EXPERIMENTAL 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 pdf Obsoleted by: RFC 5740 Status: EXPERIMENTAL 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 pdf Obsoleted by: RFC 5401 Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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)
	Authors: A. Adams, J. Nicholas, W. Siadak. Date: January 2005 Formats: txt pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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
	Authors: R. Housley. Date: April 2005 Formats: txt pdf Obsoleted by: RFC 6019 Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL This document presents the Context Transfer Protocol (CXTP) that enables authorized context transfers. Context transfers allow better support for node based mobility so that the applications running on mobile nodes can operate with minimal disruption. Key objectives are to reduce latency and packet losses, and to avoid the re-initiation of signaling to and from the mobile node.
RFC 4068	Fast Handovers for Mobile IPv6
	Authors: R. Koodli, Ed.. Date: July 2005 Formats: txt pdf Obsoleted by: RFC 5268 Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL This document provides specifications for one Bandwidth ConstraintsModel for Diffserv-aware MPLS Traffic Engineering, which is referred to as the Maximum Allocation Model.
RFC 4126	Max Allocation with Reservation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering & Performance Comparisons
	Authors: J. Ash. Date: June 2005 Formats: txt pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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)
	Authors: P. Sarolahti, M. Kojo. Date: August 2005 Formats: txt pdf Updated by: RFC 5682 Status: EXPERIMENTAL 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 pdf Obsoleted by: RFC 5380 Status: EXPERIMENTAL 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 pdf Obsoleted by: RFC 5214 Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 4405	SMTP Service Extension for Indicating the Responsible Submitter of an E-Mail Message
	Authors: E. Allman, H. Katz. Date: April 2006 Formats: txt pdf Status: EXPERIMENTAL This memo defines an extension to the Simple Mail Transfer Protocol(SMTP) service that allows an SMTP client to specify the responsible submitter of an e-mail message. The responsible submitter is the e-mail address of the entity most recently responsible for introducing a message into the transport stream. This extension helps receiving e-mail servers efficiently determine whether the SMTP client is authorized to transmit mail on behalf of the responsible submitter's domain.
RFC 4406	Sender ID: Authenticating E-Mail
	Authors: J. Lyon, M. Wong. Date: April 2006 Formats: txt pdf Status: EXPERIMENTAL Internet mail suffers from the fact that much unwanted mail is sent using spoofed addresses -- "spoofed" in this case means that the address is used without the permission of the domain owner. This document describes a family of tests by which SMTP servers can determine whether an e-mail address in a received message was used with the permission of the owner of the domain contained in that e-mail address.
RFC 4407	Purported Responsible Address in E-Mail Messages
	Authors: J. Lyon. Date: April 2006 Formats: txt pdf Status: EXPERIMENTAL This document defines an algorithm by which, given an e-mail message, one can extract the identity of the party that appears to have most proximately caused that message to be delivered. This identity is called the Purported Responsible Address (PRA).
RFC 4408	Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1
	Authors: M. Wong, W. Schlitt. Date: April 2006 Formats: txt pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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
	Authors: K. Zeilenga. Date: June 2006 Formats: txt pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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
	Authors: S. Hartman. Date: August 2006 Formats: txt pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Obsoleted by: RFC 5613 Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Obsoleted by: RFC 6106 Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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
	Authors: N. Mavrogiannopoulos. Date: November 2007 Formats: txt pdf Obsoleted by: RFC 6091 Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Updated by: RFC 6253 Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL This document specifies a registration mechanism for the HostIdentity Protocol (HIP) that allows hosts to register with services, such as HIP rendezvous servers or middleboxes.
RFC 5204	Host Identity Protocol (HIP) Rendezvous Extension
	Authors: J. Laganier, L. Eggert. Date: April 2008 Formats: txt pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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
	Authors: A. Yang, Ed.. Date: September 2008 Formats: txt pdf Updates: RFC 2045, RFC 2822 Status: EXPERIMENTAL Full internationalization of electronic mail requires not only the capabilities to transmit non-ASCII content, to encode selected information in specific header fields, and to use non-ASCII characters in envelope addresses. It also requires being able to express those addresses and the information based on them in mail header fields. This document specifies an experimental variant ofInternet mail that permits the use of Unicode encoded in UTF-8, rather than ASCII, as the base form for Internet email header field.This form is permitted in transmission only if authorized by an SMTP extension, as specified in an associated specification. This specification Updates section 6.4 of RFC 2045 to conform with the requirements.
RFC 5336	SMTP Extension for Internationalized Email Addresses
	Authors: J. Yao, Ed., W. Mao, Ed.. Date: September 2008 Formats: txt pdf Updates: RFC 2821, RFC 2822, RFC 4952 Status: EXPERIMENTAL This document specifies an SMTP extension for transport and delivery of email messages with internationalized email addresses or header information. Communication with systems that do not implement this specification is specified in another document. This document updates some syntaxes and rules defined in RFC 2821 and RFC 2822, and has some material updating RFC 4952.
RFC 5337	Internationalized Delivery Status and Disposition Notifications
	Authors: C. Newman, A. Melnikov, Ed.. Date: September 2008 Formats: txt pdf Updates: RFC 3461, RFC 3462, RFC 3464, RFC 3798 Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Obsoleted by: RFC 6387 Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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: April 1 2009 Formats: txt pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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
	Authors: R. Ogier, P. Spagnolo. Date: August 2009 Formats: txt pdf Status: EXPERIMENTAL 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)
	Authors: S. Floyd, E. Kohler. Date: August 2009 Formats: txt pdf Updated by: RFC 6323 Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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
	Authors: P. Resnick, C. Newman. Date: March 2010 Formats: txt pdf Updates: RFC 3501 Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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)
	Authors: D. MacDonald, B. Lowekamp. Date: May 2010 Formats: txt pdf Status: EXPERIMENTAL 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
	Authors: D. Papadimitriou. Date: March 2010 Formats: txt pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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
	Authors: K. Fujiwara, B. Leiba. Date: April 2010 Formats: txt pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL 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 pdf Status: EXPERIMENTAL This document