Internet Documents

RFCs

RFCs All DocumentsSTDs Internet Standards DocumentsBCPs Best Current Practice DocumentsFYIs Informational Documents
 

 
RFC 887 Resource Location Protocol
 
Authors:M. Accetta.
Date:December 1983
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 0887
This RFC specifies a draft standard for the ARPA Internet community. It describes a resource location protocol for use in the ARPA Internet. It is most useful on networks employing technologies which support some method of broadcast addressing, however it may also be used on other types of networks. For maximum benefit, all hosts which provide significant resources or services to other hosts on the Internet should implement this protocol. Hosts failing to implement the Resource Location Protocol risk being ignored by other hosts which are attempting to locate resources on the Internet.
 
RFC 908 Reliable Data Protocol
 
Authors:D. Velten, R.M. Hinden, J. Sax.
Date:July 1984
Formats:txt pdf
Updated by:RFC 1151
Status:EXPERIMENTAL
DOI:10.17487/RFC 0908
The Reliable Data Protocol (RDP) is designed to provide a reliable data transport service for packet-based applications. This RFC specifies a proposed protocol for the ARPA-Internet and DARPA research community, and requests discussion and suggestions for improvemts.
 
RFC 909 Loader Debugger Protocol
 
Authors:C. Welles, W. Milliken.
Date:July 1984
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 0909
The Loader Debugger Protocol (LDP) is an application layer protocol for loading, dumping, and debugging target machines from hosts in a network environment. This RFC specifies a proposed protocol for the ARPA-Internet and DARPA research community, and requests discussion and suggestions for improvemts.
 
RFC 938 Internet Reliable Transaction Protocol functional and interface specification
 
Authors:T. Miller.
Date:February 1985
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 0938
This RFC is being distributed to members of the DARPA research community in order to solicit their reactions to the proposals contained in it. While the issues discussed may not be directly relevant to the research problems of the DARPA community, they may be interesting to a number of researchers and implementors. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.
 
RFC 998 NETBLT: A bulk data transfer protocol
 
Authors:D.D. Clark, M.L. Lambert, L. Zhang.
Date:March 1987
Formats:txt pdf
Obsoletes:RFC 0969
Status:EXPERIMENTAL
DOI:10.17487/RFC 0998
This document is a description of, and a specification for, the NETBLT protocol. It is a revision of the specification published in RFC-969. NETBLT (NETwork BLock Transfer) is a transport level protocol intended for the rapid transfer of a large quantity of data between computers. It provides a transfer that is reliable and flow controlled, and is designed to provide maximum throughput over a wide variety of networks. Although NETBLT currently runs on top of the Internet Protocol (IP), it should be able to operate on top of any datagram protocol similar in function to IP. This document is published for discussion and comment, and does not constitute a standard. The proposal may change and certain parts of the protocol have not yet been specified; implementation of this document is therefore not advised. Obsoletes RFC-969.
 
RFC 1004 Distributed-protocol authentication scheme
 
Authors:D.L. Mills.
Date:April 1987
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 1004
The purpose of this RFC is to focus discussion on authentication problems in the Internet and possible methods of solution. The proposed solutions this document are not intended as standards for the Internet at this time. Rather, it is hoped that a general consensus will emerge as to the appropriate solution to authentication problems, leading eventually to the adoption of standards. This document suggests mediated access-control and authentication procedures suitable for those cases when an association is to be set up between users belonging to different trust environments.
 
RFC 1045 VMTP: Versatile Message Transaction Protocol: Protocol specification
 
Authors:D.R. Cheriton.
Date:February 1988
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 1045
This memo specifies the Versatile Message Transaction Protocol (VMTP) [Version 0.7 of 19-Feb-88], a transport protocol specifically designed to support the transaction model of communication, as exemplified by remote procedure call (RPC). The full function of VMTP, including support for security, real-time, asynchronous message exchanges, streaming, multicast and idempotency, provides a rich selection to the VMTP user level. Subsettability allows the VMTP module for particular clients and servers to be specialized and simplified to the services actually required. Examples of such simple clients and servers include PROM network bootload programs, network boot servers, data sensors and simple controllers, to mention but a few examples. This RFC describes a protocol proposed as a standard for the Internet community.
 
RFC 1075 Distance Vector Multicast Routing Protocol
 
Authors:D. Waitzman, C. Partridge, S.E. Deering.
Date:November 1988
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 1075
This RFC describes a distance-vector-style routing protocol for routing multicast datagrams through an internet. It is derived from the Routing Information Protocol (RIP), and implements multicasting as described in RFC-1054. This is an experimental protocol, and its implementation is not recommended at this time.
 
RFC 1105 Border Gateway Protocol (BGP)
 
Authors:K. Lougheed, Y. Rekhter.
Date:June 1989
Formats:txt pdf
Obsoleted by:RFC 1163
Status:EXPERIMENTAL
DOI:10.17487/RFC 1105
This RFC outlines a specific approach for the exchange of network reachability information between Autonomous Systems. Updated by RFCs 1163 and 1164. [STANDARDS-TRACK]
 
RFC 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
DOI:10.17487/RFC 1138
Ths RFC suggests an electronic mail protocol mapping for the Internet community and UK Academic Community, and requests discussion and suggestions for improvements. This memo does not specify an Internet standard. This memo updates RFCs 822, 987, and 1026.
 
RFC 1143 The Q Method of Implementing TELNET Option Negotiation
 
Authors:D.J. Bernstein.
Date:February 1990
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 1143
This is RFC discusses an implementation approach to option negotiation in the Telnet protocol (RFC 854). It does not propose any changes to the TELNET protocol. Rather, it discusses the implementation of the protocol of one feature, only. This is not a protocol specification. This is an experimental method of implementing a protocol.
 
RFC 1148 Mapping between X.400(1988) / ISO 10021 and RFC 822
 
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
DOI:10.17487/RFC 1148
This RFC suggests an electronic mail protocol mapping for the Internet community and UK Academic Community, and requests discussion and suggestions for improvements. This memo does not specify an Internet standard. This edition includes material lost in editing.
 
RFC 1149 Standard for the transmission of IP datagrams on avian carriers
 
Authors:D. Waitzman.
Date:1 April 1990
Formats:txt pdf
Updated by:RFC 2549, RFC 6214
Status:EXPERIMENTAL
DOI:10.17487/RFC 1149
This memo describes an experimental method for the encapsulation of IP datagrams in avian carriers. This specification is primarily useful in Metropolitan Area Networks. This is an experimental, not recommended standard.
 
RFC 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
DOI:10.17487/RFC 1151
This RFC suggests several updates to the specification of the Reliable Data Protocol (RDP) in RFC-908 based on experience with the protocol. This revised version of the protocol is experimental.
 
RFC 1153 Digest message format
 
Authors:F.J. Wancho.
Date:April 1990
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 1153
This memo describes the de facto standard Digest Message Format. This is an elective experimental protocol.
 
RFC 1154 Encoding header field for internet messages
 
Authors:D. Robinson, R. Ullmann.
Date:April 1990
Formats:txt pdf
Obsoleted by:RFC 1505
Status:EXPERIMENTAL
DOI:10.17487/RFC 1154
This RFC proposes an elective experimental Encoding header field to permit the mailing of multi-part, multi-structured messages. The use of Encoding updates RFC 1049 (Content-Type), and is a suggested update to RFCs 1113, 1114, and 1115 (Privacy Enhancement).
 
RFC 1159 Message Send Protocol
 
Authors:R. Nelson.
Date:June 1990
Formats:txt pdf
Obsoleted by:RFC 1312
Status:EXPERIMENTAL
DOI:10.17487/RFC 1159
This RFC suggests an Experimental Protocol for the Internet community. Hosts on the Internet that choose to implement a Message Send Protocol may experiment with this protocol.
 
RFC 1161 SNMP over OSI
 
Authors:M.T. Rose.
Date:June 1990
Formats:txt pdf
Obsoleted by:RFC 1418
Status:EXPERIMENTAL
DOI:10.17487/RFC 1161
This memo defines an experimental means for running the Simple Network Management Protocol (SNMP) over OSI transports. This memo does not specify a standard for the Internet community,
 
RFC 1162 Connectionless Network Protocol (ISO 8473) and End System to Intermediate System (ISO 9542) Management Information Base
 
Authors:G. Satz.
Date:June 1990
Formats:txt pdf
Obsoleted by:RFC 1238
Status:EXPERIMENTAL
DOI:10.17487/RFC 1162
This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. This memo does not specify a standard for the Internet community.
 
RFC 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
DOI:10.17487/RFC 1165
This memo suggests an Experimental Protocol for the OSI and Internet communities. Hosts in either community, and in particular those on both are encouraged to experiment with this mechanism.
 
RFC 1176 Interactive Mail Access Protocol: Version 2
 
Authors:M.R. Crispin.
Date:August 1990
Formats:txt pdf
Obsoletes:RFC 1064
Status:EXPERIMENTAL
DOI:10.17487/RFC 1176
This RFC suggests a method for personal computers and workstations to dynamically access mail from a mailbox server ("repository"). It obosoletes RFC 1064. This RFC specifies an Experimental Protocol for the Internet community. Discussion and suggestions for improvement are requested. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol.
 
RFC 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, RFC 6895
Status:EXPERIMENTAL
DOI:10.17487/RFC 1183
This memo defines five new DNS types for experimental purposes. This RFC describes an Experimental Protocol for the Internet community, and requests discussion and suggestions for improvements.
 
RFC 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
DOI:10.17487/RFC 1185
This memo describes an Experimental Protocol extension to TCP for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol.
 
RFC 1187 Bulk Table Retrieval with the SNMP
 
Authors:M.T. Rose, K. McCloghrie, J.R. Davin.
Date:October 1990
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 1187
This memo reports an interesting family of algorithms for bulk table retrieval using the Simple Network Management Protocol (SNMP). This memo describes an Experimental Protocol for the Internet community, and requests discussion and suggestions for improvements. This memo does not specify a standard for the Internet community. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol.
 
RFC 1190 Experimental Internet Stream Protocol: Version 2 (ST-II)
 
Authors:C. Topolcic.
Date:October 1990
Formats:txt pdf
Obsoletes:IEN119
Obsoleted by:RFC 1819
Status:EXPERIMENTAL
DOI:10.17487/RFC 1190
This memo defines a revised version of the Internet Stream Protocol, originally defined in IEN-119 [8], based on results from experiments with the original version, and subsequent requests, discussion, and suggestions for improvements. This is a Limited-Use Experimental Protocol. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol.
 
RFC 1204 Message Posting Protocol (MPP)
 
Authors:S. Yeh, D. Lee.
Date:February 1991
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 1204
This memo describes a protocol for posting messages from workstations (e.g., PCs) to a mail service host. This RFC specifies an Experimental Protocol for the Internet community. It does not specify any standard.
 
RFC 1224 Techniques for managing asynchronously generated alerts
 
Authors:L. Steinberg.
Date:May 1991
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 1224
This RFC explores mechanisms to prevent a remotely managed entity from burdening a manager or network with an unexpected amount of network management information, and to ensure delivery of "important" information. The focus is on controlling the flow of asynchronously generated information, and not how the information is generated.
 
RFC 1226 Internet protocol encapsulation of AX.25 frames
 
Authors:B. Kantor.
Date:May 1991
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 1226
This memo describes a method for the encapsulation of AX.25 (the Amateur Packet-Radio Link-Layer Protocol) frames within IP packets. This technique is an Experimental Protocol for the Internet community. It does not specify an Internet standard.
 
RFC 1228 SNMP-DPI: Simple Network Management Protocol Distributed Program Interface
 
Authors:G. Carpenter, B. Wijnen.
Date:May 1991
Formats:txt pdf
Obsoleted by:RFC 1592
Status:EXPERIMENTAL
DOI:10.17487/RFC 1228
This RFC describes a protocol that International Business Machines Corporation (IBM) has been implementing in most of its SNMP agents to allow dynamic extension of supported MIBs. This is an Experimental Protocol for the Internet community. It does not specify an Internet standard.
 
RFC 1235 Coherent File Distribution Protocol
 
Authors:J. Ioannidis, G. Maguire.
Date:June 1991
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 1235
This memo describes the Coherent File Distribution Protocol (CFDP). This is an Experimental Protocol for the Internet community. It does not specify an Internet standard.
 
RFC 1238 CLNS MIB for use with Connectionless Network Protocol (ISO 8473) and End System to Intermediate System (ISO 9542)
 
Authors:G. Satz.
Date:June 1991
Formats:txt pdf
Obsoletes:RFC 1162
Status:EXPERIMENTAL
DOI:10.17487/RFC 1238
This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. This is an Experimental Protocol for the Internet community. It does not specify an Internet standard.
 
RFC 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
DOI:10.17487/RFC 1241
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard.
 
RFC 1279 X.500 and Domains
 
Authors:S.E. Hardcastle-Kille.
Date:November 1991
Formats:txt ps pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 1279
This RFCconsiders X.500 in relation to Internet and UK Domains.A basic model of X.500 providing a higher level and more descriptive naming structure is emphasised. In addition, a mapping of domains onto X.500 is proposed, which gives a range of new management and user facilities over and above those currently available. This specification proposes an experimental new mechanism to access and manage domain information on the Internet and in the UK Academic Community. There is no current intention to provide an operational replacement for DNS.
 
RFC 1283 SNMP over OSI
 
Authors:M. Rose.
Date:December 1991
Formats:txt pdf
Obsoleted by:RFC 1418
Status:EXPERIMENTAL
DOI:10.17487/RFC 1283
This memo describes mappings from the SNMP onto both the COTS and the CLTS. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet Standard.
 
RFC 1307 Dynamically Switched Link Control Protocol
 
Authors:J. Young, A. Nicholson.
Date:March 1992
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 1307
This memo describes an experimental protocol developed by a project team at Cray Research, Inc., in implementing support for circuit- switched T3 services. The protocol is used for the control of network connections external to a host, but known to the host. It is documented here for the benefit of others who may wish to perform further research.

While working with circuit-switched T3 networks, developers at CrayResearch, Inc., defined a model wherein a host would generate control messages for a network switch. This work is described in RFC 1306,"Experiences Supporting By-Request Circuit-Switched T3 Networks". In order to simplify the model it was decided that the inconsistencies of switch control should be hidden from the host generating the control messages. To that end, a protocol was defined and implemented. This RFC documents the Dynamically Switched LinkControl Protocol (DSLCP), which is used for creation and control of downstream network links by a host.

 
RFC 1312 Message Send Protocol 2
 
Authors:R. Nelson, G. Arnold.
Date:April 1992
Formats:txt pdf
Obsoletes:RFC 1159
Status:EXPERIMENTAL
DOI:10.17487/RFC 1312
The Message Send Protocol is used to send a short message to a given user on a given terminal on a given host. This memo defines an Experimental Protocol for the Internet community.
 
RFC 1339 Remote Mail Checking Protocol
 
Authors:S. Dorner, P. Resnick.
Date:June 1992
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 1339
This RFC defines a protocol to provide a mail checking service to be used between a client and server pair. Typically, a small program on a client workstation would use the protocol to query a server in order to find out whether new mail has arrived for a specified user.
 
RFC 1348 DNS NSAP RRs
 
Authors:B. Manning.
Date:July 1992
Formats:txt pdf
Obsoleted by:RFC 1637
Updates:RFC 1034, RFC 1035
Status:EXPERIMENTAL
DOI:10.17487/RFC 1348
This RFC defines the format of two new Resource Records (RRs) for the Domain Name System (DNS), and reserves corresponding DNS type mnemonic and numerical codes. This memo defines an Experimental Protocol for the Internet community.
 
RFC 1383 An Experiment in DNS Based IP Routing
 
Authors:C. Huitema.
Date:December 1992
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 1383
Potential solutions to the routing explosion. This memo defines an Experimental Protocol for the Internet community.
 
RFC 1405 Mapping between X.400(1984/1988) and Mail-11 (DECnet mail)
 
Authors:C. Allocchio.
Date:January 1993
Formats:txt pdf
Obsoleted by:RFC 2162
Status:EXPERIMENTAL
DOI:10.17487/RFC 1405
This document describes a set of mappings which will enable inter working between systems operating the CCITT X.400 ( 1984 / 1988 )Recommendations on Message Handling Systems, and systems running theMail-11 (also known as DECnet mail) protocol. The specifications are valid within DECnet Phase IV addressing and routing scheme.

The complete scenario of X.400 / RFC822 / Mail-11 is also considered, in order to cover the possible complex cases arising in multiple gateway translations.

This document covers mainly the O/R address to DECnet from/to address mapping (and vice versa); other mappings are based on RFC 1327 and its eventual future updates.

This is a combined effort of COSINE S2.2, the RARE MSG Working Group, and the IETF X.400 Ops Working Group.

 
RFC 1409 Telnet Authentication Option
 
Authors:D. Borman, Ed..
Date:January 1993
Formats:txt pdf
Obsoleted by:RFC 1416
Status:EXPERIMENTAL
DOI:10.17487/RFC 1409
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
DOI:10.17487/RFC 1411
This memo defines an Experimental Protocol for the Internet community.
 
RFC 1412 Telnet Authentication: SPX
 
Authors:K. Alagappan.
Date:January 1993
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 1412
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
DOI:10.17487/RFC 1416
This RFC 1416 replaces RFC 1409, which has an important typographical error in the example on page 6 (one occurance of "REPLY" should be "IS"). This memo defines an Experimental Protocol for the Internet community.
 
RFC 1433 Directed ARP
 
Authors:J. Garrett, J. Hagan, J. Wong.
Date:March 1993
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 1433
A router with an interface to two IP networks via the same link level interface could observe that the two IP networks share the same link level network, and could advertise that information to hosts (viaICMP Redirects) and routers (via dynamic routing protocols).However, a host or router on only one of the IP networks could not use that information to communicate directly with hosts and routers on the other IP network unless it could resolve IP addresses on the"foreign" IP network to their corresponding link level addresses.Directed ARP is a dynamic address resolution procedure that enables hosts and routers to resolve advertised potential next-hop IP addresses on foreign IP networks to their associated link level addresses.
 
RFC 1440 SIFT/UFT: Sender-Initiated/Unsolicited File Transfer
 
Authors:R. Troth.
Date:July 1993
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 1440
This document describes a Sender-Initiated File Transfer (SIFT) protocol, also commonly called Unsolicited File Transfer (UFT) protocol. This memo defines an Experimental Protocol for the Internet community.
 
RFC 1455 Physical Link Security Type of Service
 
Authors:D. Eastlake 3rd.
Date:May 1993
Formats:txt pdf
Obsoleted by:RFC 2474
Status:EXPERIMENTAL
DOI:10.17487/RFC 1455
This RFC documents an experimental protocol providing a Type ofService (TOS) to request maximum physical link security. This is an addition to the types of service enumerated in RFC 1349: Type ofService in the Internet Protocol Suite. The new TOS requests the network to provide what protection it can against surreptitious observation by outside agents of traffic so labeled. The purpose is protection against traffic analysis and as an additional possible level of data confidentiality. This TOS is consistent with all other defined types of service for IP version 4 in that it is based on link level characteristics and will not provide any particular guaranteed level of service.
 
RFC 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, RFC 7194
Status:EXPERIMENTAL
DOI:10.17487/RFC 1459
The IRC protocol was developed over the last 4 years since it was first implemented as a means for users on a BBS to chat amongst themselves. Now it supports a world-wide network of servers and clients, and is stringing to cope with growth. Over the past 2 years, the average number of users connected to the main IRC network has grown by a factor of 10.

The IRC protocol is a text-based protocol, with the simplest client being any socket program capable of connecting to the server.

 
RFC 1464 Using the Domain Name System To Store Arbitrary String Attributes
 
Authors:R. Rosenbaum.
Date:May 1993
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 1464
While the Domain Name System (DNS) [2,3] is generally used to store predefined types of information (e.g., addresses of hosts), it is possible to use it to store information that has not been previously classified.

This paper describes a simple means to associate arbitrary string information (ASCII text) with attributes that have not been defined by the DNS. It uses DNS TXT resource records to store the information. It requires no change to current DNS implementations.

 
RFC 1465 Routing Coordination for X.400 MHS Services Within a Multi Protocol / Multi Network Environment Table Format V3 for Static Routing
 
Authors:D. Eppenberger.
Date:May 1993
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 1465
This document proposes short term solutions for maintaining and distributing routing information and shows how messages can travel over different networks by using multi stack MTAs as relays. This memo defines an Experimental Protocol for the Internet community.
 
RFC 1476 RAP: Internet Route Access Protocol
 
Authors:R. Ullmann.
Date:June 1993
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 1476
This RFC describes an open distance vector routing protocol for use at all levels of the internet, from isolated LANs to the major routers of an international commercial network provider.
 
RFC 1486 An Experiment in Remote Printing
 
Authors:M. Rose, C. Malamud.
Date:July 1993
Formats:txt pdf
Obsoleted by:RFC 1528, RFC 1529
Status:EXPERIMENTAL
DOI:10.17487/RFC 1486
This memo describes a technique for "remote printing" using the Internet mail infrastructure. In particular, this memo focuses on the case in which remote printers are connected to the international telephone network. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard.
 
RFC 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
DOI:10.17487/RFC 1505
This document expands upon the elective experimental Encoding header field which permits the mailing of multi-part, multi-structured messages. It replaces RFC 1154 [1].
 
RFC 1507 DASS - Distributed Authentication Security Service
 
Authors:C. Kaufman.
Date:September 1993
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 1507
The goal of DASS is to provide authentication services in a distributed environment which are both more secure and easier to use than existing mechanisms. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard.
 
RFC 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
DOI:10.17487/RFC 1528
This memo describes a technique for "remote printing" using the Internet mail infrastructure. In particular, this memo focuses on the case in which remote printers are connected to the international telephone network. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard.
 
RFC 1545 FTP Operation Over Big Address Records (FOOBAR)
 
Authors:D. Piscitello.
Date:November 1993
Formats:txt pdf
Obsoleted by:RFC 1639
Status:EXPERIMENTAL
DOI:10.17487/RFC 1545
This paper describes a convention for specifying longer addresses in the PORT command.
 
RFC 1561 Use of ISO CLNP in TUBA Environments
 
Authors:D. Piscitello.
Date:December 1993
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 1561
This memo specifies a profile of the ISO/IEC 8473 Connectionless-modeNetwork Layer Protocol (CLNP, [1]) for use in conjunction with RFC1347, TCP/UDP over Bigger Addresses (TUBA, [2]). It describes the use of CLNP to provide the lower-level service expected byTransmission Control Protocol (TCP, [3]) and User Datagram Protocol(UDP, [4]). CLNP provides essentially the same datagram service asInternet Protocol (IP, [5]), but offers a means of conveying bigger network addresses (with additional structure, to aid routing).

While the protocols offer nearly the same services, IP and CLNP are not identical. This document describes a means of preserving the semantics of IP information that is absent from CLNP while preserving consistency between the use of CLNP in Internet and OSI environments.This maximizes the use of already-deployed CLNP implementations.

 
RFC 1592 Simple Network Management Protocol Distributed Protocol Interface Version 2.0
 
Authors:B. Wijnen, G. Carpenter, K. Curran, A. Sehgal, G. Waters.
Date:March 1994
Formats:txt pdf
Obsoletes:RFC 1228
Status:EXPERIMENTAL
DOI:10.17487/RFC 1592
This RFC describes version 2.0 of a protocol that International Business Machines Corporation (IBM) has been implementing in most of its SNMP agents to allow dynamic extension of supported MIBs. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1608 Representing IP Information in the X.500 Directory
 
Authors:T. Johannsen, G. Mansfield, M. Kosters, S. Sataluri.
Date:March 1994
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 1608
This document describes the objects necessary to include information about IP networks and IP numbers in the X.500 Directory. It extends the work "Charting networks in the X.500 Directory" [1] where a general framework is presented for representing networks in theDirectory by applying it to IP networks. This application of theDirectory is intended to support the work of IP network assigning authorities, NICs, as well as other applications looking for a mapping of IP numbers to data of related networks. Furthermore,Autonomous Systems and related routing policy information can be represented in the Directory along with their relationship to networks and organizations.
 
RFC 1609 Charting Networks in the X.500 Directory
 
Authors:G. Mansfield, T. Johannsen, M. Knopper.
Date:March 1994
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 1609
There is a need for a framework wherein the infrastructural and service related information about communication networks can be made accessible from all places and at all times in a reasonably efficient manner and with reasonable accuracy. This document presents a model in which a communication network with all its related details and descriptions can be represented in the X.500 Directory. Schemas of objects and their attributes which may be used for this purpose are presented. The model envisages physical objects and several logical abstractions of the physical objects.
 
RFC 1637 DNS NSAP Resource Records
 
Authors:B. Manning, R. Colella.
Date:June 1994
Formats:txt pdf
Obsoletes:RFC 1348
Obsoleted by:RFC 1706
Status:EXPERIMENTAL
DOI:10.17487/RFC 1637
The Internet is moving towards the deployment of an OSI lower layers infrastructure. This infrastructure comprises the connectionless network protocol (CLNP) and supporting routing protocols. Also required as part of this infrastructure is support in the Domain NameSystem (DNS) for mapping between names and NSAP addresses.

This document defines the format of one new Resource Record (RR) for the DNS for domain name-to-NSAP mapping. The RR may be used with anyNSAP address format. This document supercedes RFC 1348.

NSAP-to-name translation is accomplished through use of the PTR RR(see STD 13, RFC 1035 for a description of the PTR RR). This paper describes how PTR RRs are used to support this translation.

 
RFC 1639 FTP Operation Over Big Address Records (FOOBAR)
 
Authors:D. Piscitello.
Date:June 1994
Formats:txt pdf
Obsoletes:RFC 1545
Status:EXPERIMENTAL
DOI:10.17487/RFC 1639
This paper describes a convention for specifying address families other than the default Internet address family in FTP commands and replies.
 
RFC 1641 Using Unicode with MIME
 
Authors:D. Goldsmith, M. Davis.
Date:July 1994
Formats:txt ps pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 1641
The Unicode Standard, version 1.1, and ISO/IEC 10646-1:1993(E) jointly define a 16 bit character set (hereafter referred to asUnicode) which encompasses most of the world's writing systems.However, Internet mail (STD 11, RFC 822) currently supports only 7- bit US ASCII as a character set. MIME (RFC 1521 and RFC 1522) extendsInternet mail to support different media types and character sets, and thus could support Unicode in mail messages. MIME neither definesUnicode as a permitted character set nor specifies how it would be encoded, although it does provide for the registration of additional character sets over time.

This document specifies the usage of Unicode within MIME.

 
RFC 1642 UTF-7 - A Mail-Safe Transformation Format of Unicode
 
Authors:D. Goldsmith, M. Davis.
Date:July 1994
Formats:txt pdf ps
Obsoleted by:RFC 2152
Status:EXPERIMENTAL
DOI:10.17487/RFC 1642
The Unicode Standard, version 1.1, and ISO/IEC 10646-1:1993(E) jointly define a 16 bit character set (hereafter referred to asUnicode) which encompasses most of the world's writing systems.However, Internet mail (STD 11, RFC 822) currently supports only 7- bit US ASCII as a character set. MIME (RFC 1521 and RFC 1522) extendsInternet mail to support different media types and character sets, and thus could support Unicode in mail messages. MIME neither definesUnicode as a permitted character set nor specifies how it would be encoded, although it does provide for the registration of additional character sets over time.

This document describes a new transformation format of Unicode that contains only 7-bit ASCII characters and is intended to be readable by humans in the limiting case that the document consists of characters from the US-ASCII repertoire. It also specifies how this transformation format is used in the context of RFC 1521, RFC 1522, and the document "Using Unicode with MIME".

 
RFC 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
DOI:10.17487/RFC 1664
This memo defines how to store in the Internet Domain Name System the mapping information needed by e-mail gateways and other tools to mapRFC822 domain names into X.400 O/R names and vice versa. Mapping information can be managed in a distributed rather than a centralised way. Gateways located on Internet hosts can retrieve the mapping information querying the DNS instead of having fixed tables which need to be centrally updated and distributed. This memo is a joint effort of X400 operation working group (x400ops) and RARE Mail andMessaging working group (WG-MSG).
 
RFC 1712 DNS Encoding of Geographical Location
 
Authors:C. Farrell, M. Schulze, S. Pleitner, D. Baldoni.
Date:November 1994
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 1712
This document defines the format of a new Resource Record (RR) for the Domain Naming System (DNS), and reserves a corresponding DNS type mnemonic and numerical code. This definition deals with associating geographical host location mappings to host names within a domain.The data shown in this document is fictitious and does not necessarily reflect the real Internet.
 
RFC 1735 NBMA Address Resolution Protocol (NARP)
 
Authors:J. Heinanen, R. Govindan.
Date:December 1994
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 1735
This document describes the NBMA Address Resolution Protocol (NARP).NARP can be used by a source terminal (host or router) connected to aNon-Broadcast, Multi-Access link layer (NBMA) network to find out theNBMA addresses of the a destination terminal provided that the destination terminal is connected to the same NBMA network. Although this document focuses on NARP in the context of IP, the technique is applicable to other network layer protocols as well. This RFC is a product of the Routing over Large Clouds Working Group of the IETF.
 
RFC 1756 Remote Write Protocol - Version 1.0
 
Authors:T. Rinne.
Date:January 1995
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 1756
This document describes a simple Remote Write Protocol (RWP). This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 1765 OSPF Database Overflow
 
Authors:J. Moy.
Date:March 1995
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 1765
Proper operation of the OSPF protocol requires that all OSPF routers maintain an identical copy of the OSPF link-state database. However, when the size of the link-state database becomes very large, some routers may be unable to keep the entire database due to resource shortages; we term this "database overflow". When database overflow is anticipated, the routers with limited resources can be accommodated by configuring OSPF stub areas and NSSAs. This memo details a way of gracefully handling unanticipated database overflows.

This memo is a product of the OSPF Working Group. Please send comments to ospf@gated.cornell.edu.

 
RFC 1768 Host Group Extensions for CLNP Multicasting
 
Authors:D. Marlow.
Date:March 1995
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 1768
This memo documents work performed in the TUBA (TCP/UDP over BiggerAddresses) working group of IPng area prior to the July 1994 decision to utilize SIPP-16 as the basis for IPng. The TUBA group worked on extending the Internet Protocol suite by the use of ISO 8473 (CLNP) and its related routing protocols. This memo describes multicast extensions to CLNP and its related routing protocols for Internet multicast use. Publication of this memo does not imply acceptance by any IETF Working Group for the ideas expressed within.

This memo provides a specification for multicast extensions to theCLNP protocol similar to those provided to IP by RFC1112. These extensions are intended to provide the mechanisms needed by a host for multicasting in a CLNP based Internet. This memo covers addressing extensions to the CLNP addressing structure, extensions to the CLNP protocol and extensions to the ES-IS protocol. An appendix discusses the differences between IP multicast and the CLNP multicast approach provided in this memo.

 
RFC 1791 TCP And UDP Over IPX Networks With Fixed Path MTU
 
Authors:T. Sung.
Date:April 1995
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 1791
TCP/IPX allows TCP/IP applications to run over IPX networks by letting TCP and UDP run over IPX. And this memo specifies the packet format and operational procedures for running TCP and UDP over IPX. This document defines an Experimental Protocol for the Internet community. This does not specify an Internet standard of any kind.
 
RFC 1792 TCP/IPX Connection Mib Specification
 
Authors:T. Sung.
Date:April 1995
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 1792
New MIB objects, tcpIpxConnTable, udpIpxTable, tcpUnspecConnTable and udpUnspecTable are presented in this paper, to be used in place of tcpConnTable and udpListenerTable when TCP and UDP are running over IPX. This document defines an Experimental Protocol for the Internet community. This does not specify an Internet standard of any kind.
 
RFC 1797 Class A Subnet Experiment
 
Authors:Internet Assigned Numbers Authority (IANA).
Date:April 1995
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 1797
There appears to be some interest in experimenting with subnetting the class A addresses. It is suggested that conducting an experiment now to identify and fix any software that does not properly handle subnetted class A addresses would be useful and important. This document defines an Experimental Protocol for the Internet community. This does not specify an Internet standard of any kind.
 
RFC 1801 MHS use of the X.500 Directory to support MHS Routing
 
Authors:S. Kille.
Date:June 1995
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 1801
The key problem in routing is to map from an O/R Address onto an MTA (next hop). This shall be an MTA which in some sense is "nearer" to the destination UA. This is done repeatedly until the message can be directly delivered to the recipient UA. This memo defines an Experimental Protocol for the Internet community.
 
RFC 1804 Schema Publishing in X.500 Directory
 
Authors:G. Mansfield, P. Rajeev, S. Raghavan, T. Howes.
Date:June 1995
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 1804
The X.500 directory provides a powerful mechanism for storing and retrieving information about objects of interest. To interpret the information stored in the directory, the schema must be known to all the components of the directory. Presently, there are no means other than ftp to distribute schema information across the Internet. This is proving to be a severe constraint as the Directory is growing.This document presents a solution to the schema distribution problem using the existing mechanisms of the directory. A naming scheme for naming schema objects and a meta-schema for storing schema objects is presented. The procedures for fetching unknown schema from the directory at runtime are described.
 
RFC 1806 Communicating Presentation Information in Internet Messages: The Content-Disposition Header
 
Authors:R. Troost, S. Dorner.
Date:June 1995
Formats:txt pdf
Obsoleted by:RFC 2183
Status:EXPERIMENTAL
DOI:10.17487/RFC 1806
This memo provides a mechanism whereby messages conforming to the[RFC 1521] ("MIME") specification can convey presentational information. It specifies a new "Content-Disposition" header, optional and valid for any [RFC 1521] entity ("message" or "body part"). Two values for this header are described in this memo; one for the ordinary linear presentation of the body part, and another to facilitate the use of mail to transfer files. It is expected that more values will be defined in the future, and procedures are defined for extending this set of values.

This document is intended as an extension to [RFC 1521]. As such, the reader is assumed to be familiar with [RFC 1521], and [RFC 822]. The information presented herein supplements but does not replace that found in those documents.

 
RFC 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
DOI:10.17487/RFC 1830
This memo defines two extensions to the SMTP service. The first service enables a SMTP client and server to negotiate the use of an alternate DATA command "BDAT" for efficiently sending large MIME messages. The second extension takes advantage of the BDAT command to permit the negotiated sending of unencoded binary data. This memo defines an Experimental Protocol for the Internet community.
 
RFC 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
DOI:10.17487/RFC 1836
This document defines a representation of the O/R Address hierarchy in the Directory Information Tree [6, 1]. This is useful for a range of purposes, including:
 
RFC 1837 Representing Tables and Subtrees in the X.500 Directory
 
Authors:S. Kille.
Date:August 1995
Formats:txt pdf
Obsoleted by:RFC 2293
Status:EXPERIMENTAL
DOI:10.17487/RFC 1837
This document defines techniques for representing two types of information mapping in the OSI Directory [1].

1. Mapping from a key to a value (or set of values), as might be done in a table lookup.

2. Mapping from a distinguished name to an associated value (or values), where the values are not defined by the owner of the entry. This is achieved by use of a directory subtree.

These techniques were developed for supporting MHS use of Directory[2], but are specified separately as they have more general applicability.

 
RFC 1838 Use of the X.500 Directory to support mapping between X.400 and RFC 822 Addresses
 
Authors:S. Kille.
Date:August 1995
Formats:txt pdf
Obsoleted by:RFC 2164
Status:EXPERIMENTAL
DOI:10.17487/RFC 1838
This document defines how to use directory to support the mapping between X.400 O/R Addresses and mailboxes defined in RFC 1327 [2].
 
RFC 1845 SMTP Service Extension for Checkpoint/Restart
 
Authors:D. Crocker, N. Freed, A. Cargille.
Date:September 1995
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 1845
This memo defines an extension to the SMTP service whereby an interrupted SMTP transaction can be restarted at a later time without having to repeat all of the commands and message content sent prior to the interruption.
 
RFC 1846 SMTP 521 Reply Code
 
Authors:A. Durand, F. Dupont.
Date:September 1995
Formats:txt pdf
Updated by:RFC 7504
Status:EXPERIMENTAL
DOI:10.17487/RFC 1846
This memo defines a new Simple Mail Transfer Protocol (SMTP) [1] reply code, 521, which one may use to indicate that an Internet host does not accept incoming mail.
 
RFC 1851 The ESP Triple DES Transform
 
Authors:P. Karn, P. Metzger, W. Simpson.
Date:September 1995
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 1851
This document describes the Triple DES-CBC security transform for theIP Encapsulating Security Payload (ESP).
 
RFC 1852 IP Authentication using Keyed SHA
 
Authors:P. Metzger, W. Simpson.
Date:September 1995
Formats:txt pdf
Obsoleted by:RFC 2841
Status:EXPERIMENTAL
DOI:10.17487/RFC 1852
This document describes the use of keyed SHA with the IPAuthentication Header.
 
RFC 1868 ARP Extension - UNARP
 
Authors:G. Malkin.
Date:November 1995
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 1868
The Address Resolution Protocol allows an IP node to determine the hardware (datalink) address of a neighboring node on a broadcast network. The protocol depends on timers to age away old ARP entries.This document specifies a trivial modification to the ARP mechanism, not the packet format, which allows a node to announce that it is leaving the network and that all other nodes should modify their ARP tables accordingly.
 
RFC 1872 The MIME Multipart/Related Content-type
 
Authors:E. Levinson.
Date:December 1995
Formats:txt pdf
Obsoleted by:RFC 2112
Status:EXPERIMENTAL
DOI:10.17487/RFC 1872
The Multipart/Related content-type provides a common mechanism for representing objects that are aggregates of related MIME body parts.This document defines the Multipart/Related content-type and provides examples of its use.
 
RFC 1873 Message/External-Body Content-ID Access Type
 
Authors:E. Levinson.
Date:December 1995
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 1873
When using MIME [MIME] to encapsulate a structured object that consist of many elements, for example an SGML [SGML] document, a single element may occur several times. An encapsulation normally maps each of the structured objects elements to a MIME entity. It is useful to include elements that occur multiple time exactly once. To accomplish that and to preserve the object structure it is desirable to unambiguously refer to another body part of the same message.

The existing MIME Content-Type Message/External-Body access-types allow a MIME entity (body-part) to refer to an object that is not in the message by specifying how to access that object. The Content-ID access method described in this document provides the capability to refer to an object within the message.

 
RFC 1874 SGML Media Types
 
Authors:E. Levinson.
Date:December 1995
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 1874
This document proposes new media sub-types of Text/SGML andApplication/SGML. These media types can be used in the exchange ofSGML documents and their entities. Specific details for the exchange or encapsulation of groups of related SGML entities using MIME are currently being considered by the mimesgml Working Group <sgml- internet@ebt.com&rt;.
 
RFC 1876 A Means for Expressing Location Information in the Domain Name System
 
Authors:C. Davis, P. Vixie, T. Goodwin, I. Dickinson.
Date:January 1996
Formats:txt pdf
Updates:RFC 1034, RFC 1035
Status:EXPERIMENTAL
DOI:10.17487/RFC 1876
This memo defines a new DNS RR type for experimental purposes. This RFC describes a mechanism to allow the DNS to carry location information about hosts, networks, and subnets. This memo defines an Experimental Protocol for the Internet community.
 
RFC 1897 IPv6 Testing Address Allocation
 
Authors:R. Hinden, J. Postel.
Date:January 1996
Formats:txt pdf
Obsoleted by:RFC 2471
Status:EXPERIMENTAL
DOI:10.17487/RFC 1897
This document describes an allocation plan for IPv6 addresses to be used in testing IPv6 prototype software. This document specifies an Experimental protocol for the Internet community.
 
RFC 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
DOI:10.17487/RFC 1911
The following document is a profile of the Internet standard MIME and ESMTP protocols for use as a digital voice networking protocol. This memo defines an Experimental Protocol for the Internet community.
 
RFC 1949 Scalable Multicast Key Distribution
 
Authors:A. Ballardie.
Date:May 1996
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 1949
The benefits of multicasting are becoming ever-more apparent, and its use much more widespread. This is evident from the growth of theMBONE [1]. Providing security services for multicast, such as traffic integrity, authentication, and confidentiality, is particularly problematic since it requires securely distributing a group (session) key to each of a group's receivers. Traditionally, the key distribution function has been assigned to a central network entity, or Key Distribution Centre (KDC), but this method does not scale for wide-area multicasting, where group members may be widely-distributed across the internetwork, and a wide-area group may be densely populated.

Even more problematic is the scalable distribution of sender-specific keys. Sender-specific keys are required if data traffic is to be authenticated on a per-sender basis.

This memo provides a scalable solution to the multicast key distribution problem.

NOTE: this proposal requires some simple support mechanisms, which, it is recommended here, be integrated into version 3 of IGMP. This support is described in Appendix B.

 
RFC 1965 Autonomous System Confederations for BGP
 
Authors:P. Traina.
Date:June 1996
Formats:txt pdf
Obsoleted by:RFC 3065
Status:EXPERIMENTAL
DOI:10.17487/RFC 1965
Border Gateway Protocol [1] is an inter-autonomous system routing protocol designed for TCP/IP networks.

This document describes an extension to BGP which may be used to create a confederation of autonomous systems which is represented as one single autonomous system to BGP peers external to the confederation.

The intention of this extension is to aid in policy administration and reduce the management complexity of maintaining a large autonomous system.

The extension this document describes is widely deployed in theInternet today.

 
RFC 1966 BGP Route Reflection An alternative to full mesh IBGP
 
Authors:T. Bates, R. Chandra.
Date:June 1996
Formats:txt pdf
Obsoleted by:RFC 4456
Updated by:RFC 2796
Status:EXPERIMENTAL
DOI:10.17487/RFC 1966
The Border Gateway Protocol [1] is an inter-autonomous system routing protocol designed for TCP/IP internets. BGP deployments are configured such that that all BGP speakers within a single AS must be fully meshed so that any external routing information must be re- distributed to all other routers within that AS. This represents a serious scaling problem that has been well documented with several alternatives proposed [2,3].

This document describes the use and design of a method known as"Route Reflection" to alleviate the the need for "full mesh" IBGP.

 
RFC 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
DOI:10.17487/RFC 1986
This document is a description of the Enhanced Trivial File Transfer Protocol (ETFTP). This protocol is an experimental implementation of the NETwork BLock Transfer Protocol (NETBLT), RFC 998 [1], as a file transfer application program. This memo defines an Experimental Protocol for the Internet community.
 
RFC 2009 GPS-Based Addressing and Routing
 
Authors:T. Imielinski, J. Navas.
Date:November 1996
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 2009
This document describes a possible experiment with geographic addresses. It uses several specific IP addresses and domain names in the discussion as concrete examples to aid in understanding the concepts. This memo defines an Experimental Protocol for the Internet community.
 
RFC 2016 Uniform Resource Agents (URAs)
 
Authors:L. Daigle, P. Deutsch, B. Heelan, C. Alpaugh, M. Maclachlan.
Date:October 1996
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 2016
This paper presents an experimental architecture for an agent system that provides sophisticated Internet information access and management. Not a generalized architecture for active objects that roam the Internet, these agents are modeled as extensions of existing pieces of the Internet information infrastructure. This experimental agent technology focuses on the necessary information structures to encapsulate Internet activities into objects that can be activated, transformed, and combined into larger structured activities.
 
RFC 2052 A DNS RR for specifying the location of services (DNS SRV)
 
Authors:A. Gulbrandsen, P. Vixie.
Date:October 1996
Formats:txt pdf
Obsoleted by:RFC 2782
Status:EXPERIMENTAL
DOI:10.17487/RFC 2052
This document describes a DNS RR which specifies the location of the server(s) for a specific protocol and domain (like a more general form of MX).
 
RFC 2063 Traffic Flow Measurement: Architecture
 
Authors:N. Brownlee, C. Mills, G. Ruth.
Date:January 1997
Formats:txt pdf
Obsoleted by:RFC 2722
Status:EXPERIMENTAL
DOI:10.17487/RFC 2063
This document describes an architecture for the measurement and reporting of network traffic flows, discusses how this relates to an overall network traffic flow architecture, and describes how it can be used within the Internet. It is intended to provide a starting point for the Realtime Traffic Flow Measurement Working Group.
 
RFC 2064 Traffic Flow Measurement: Meter MIB
 
Authors:N. Brownlee.
Date:January 1997
Formats:txt pdf
Obsoleted by:RFC 2720
Status:EXPERIMENTAL
DOI:10.17487/RFC 2064
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, this memo defines managed objects used for obtaining traffic flow information from network traffic meters.
 
RFC 2066 TELNET CHARSET Option
 
Authors:R. Gellens.
Date:January 1997
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 2066
This document specifies a mechanism for passing character set and translation information between a TELNET client and server. Use of this mechanism enables an application used by a TELNET user to send and receive data in the correct character set.

Either side can (subject to option negotiation) at any time request that a (new) character set be used.

 
RFC 2075 IP Echo Host Service
 
Authors:C. Partridge.
Date:January 1997
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 2075
This memo describes how to implement an IP echo host. IP echo hosts send back IP datagrams after exchanging the source and destination IP addresses. The effect is that datagrams sent to the echo host are sent back to the source, as if they originated at the echo host.
 
RFC 2090 TFTP Multicast Option
 
Authors:A. Emberson.
Date:February 1997
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 2090
The Trivial File Transfer Protocol [1] is a simple, lock-step, file transfer protocol which allows a client to get or put a file onto a remote host.

This document describes a new TFTP option. This new option will allow the multiple clients to receive the same file concurrently through the use of Multicast packets. The TFTP Option Extension mechanism is described in [2].

Often when similar computers are booting remotely they will each download the same image file. By adding multicast into the TFTP option set, two or more computers can download a file concurrently, thus increasing network efficiency.

This document assumes that the reader is familiar with the terminology and notation of both [1] and [2].

 
RFC 2093 Group Key Management Protocol (GKMP) Specification
 
Authors:H. Harney, C. Muckenhirn.
Date:July 1997
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 2093
This specification proposes a protocol to create grouped symmetric keys and distribute them amongst communicating peers. This protocol has the following advantages: 1) virtually invisible to operator, 2) no central key distribution site is needed, 3) only group members have the key, 4) sender or receiver oriented operation, 5) can make use of multicast communications protocols.
 
RFC 2094 Group Key Management Protocol (GKMP) Architecture
 
Authors:H. Harney, C. Muckenhirn.
Date:July 1997
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 2094
This specification proposes a protocol to create grouped symmetric keys and distribute them amongst communicating peers. This protocol has the following advantages: 1) virtually invisible to operator, 2) no central key distribution site is needed, 3) only group members have the key, 4) sender or receiver oriented operation, 5) can make use of multicast communications protocols.
 
RFC 2117 Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification
 
Authors:D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, L. Wei.
Date:June 1997
Formats:txt pdf
Obsoleted by:RFC 2362
Status:EXPERIMENTAL
DOI:10.17487/RFC 2117
This document describes a protocol for efficiently routing to multicast groups that may span wide-area (and inter-domain) internets. This memo defines an Experimental Protocol for the Internet community.
 
RFC 2120 Managing the X.500 Root Naming Context
 
Authors:D. Chadwick.
Date:March 1997
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 2120
The X.500 Standard [X.500 93] has the concept of first level DSAs, whose administrators must collectively manage the root naming context through bi-lateral agreements or other private means which are outside the scope of the X.500 Standard.

The NameFLOW-Paradise X.500 service has an established procedure for managing the root naming context, which currently uses Quipu proprietary replication mechanisms and a root DSA. The benefits that derive from this are twofold:

- firstly it is much easier to co-ordinate the management of the root context information, when there is a central point of administration,

- secondly the performance of one-level Search operations is greatly improved because the Quipu distribution and replication mechanism does not have a restriction that exists in the 1988 and1993 X.500 Standard.

The NameFLOW-Paradise project is moving towards 1993 ISO X.500Standard replication protocols and wants to standardise the protocol and procedure for managing the root naming context which will be based on 1993 X.500 Standard protocols. Such a protocol and procedure will be useful to private X.500 domains as well as to the InternetX.500 public domain. It is imperative that overall system performance is not degraded by this transition.

This document describes the use of 1993 ISO X.500 Standard protocols for managing the root context. Whilst the ASN.1 is compatible with that of the X.500 Standard, the actual settings of the parameters are supplementary to that of the X.500 Standard.

 
RFC 2143 Encapsulating IP with the Small Computer System Interface
 
Authors:B. Elliston.
Date:May 1997
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 2143
This document outlines a protocol for connecting hosts running the TCP/IP protocol suite over a Small Computer System Interface (SCSI) bus. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind.
 
RFC 2154 OSPF with Digital Signatures
 
Authors:S. Murphy, M. Badger, B. Wellington.
Date:June 1997
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 2154
This memo describes the extensions to OSPF required to add digital signature authentication to Link State data, and to provide a certification mechanism for router data. Added LSA processing and key management is detailed. A method for migration from, or co- existence with, standard OSPF V2 is described.
 
RFC 2161 A MIME Body Part for ODA
 
Authors:H. Alvestrand.
Date:January 1998
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 2161
This document contains the definitions, originally contained in RFC 1495 and RFC 1341, on how to carry ODA in MIME, and how to translate it to its X.400 representation. This memo defines an Experimental Protocol for the Internet community.
 
RFC 2162 MaXIM-11 - Mapping between X.400 / Internet mail and Mail-11 mail
 
Authors:C. Allocchio.
Date:January 1998
Formats:txt pdf
Obsoletes:RFC 1405
Status:EXPERIMENTAL
DOI:10.17487/RFC 2162
This document describes a set of mappings which will enable inter working between systems operating the ISO/IEC 10021 - CCITT (now ITU)X.400 Recommendations on Message Handling Systems, and systems running the Mail-11 (also known as DECnet mail or VMSmail) protocol.The specifications are valid both within DECnet Phase IV andDECnet/OSI addressing and routing scheme.

The complete scenario of X.400 / MIME / Mail-11 is also considered, in order to cover the possible complex cases arising in multiple gateway translations.

This document covers mainly the X.400 O/R address to/from Mail-11 address mapping and the RFC822 to/from Mail-11 ones; other mappings are based on MIXER specifications. Bodypart mappings are not specified in this document: MIXER and MIME-MHS specifications can be applied to map bodyparts between X.400, MIME and Mail-11, too. In fact MIME encoding can be used without modifications within Mail-11 text bodyparts.

This document obsoletes RFC 1405, which was a combined effort ofTERENA Working Group on Messaging, and the IETF X.400 Ops WorkingGroup. This update was prepared by IETF MIXER working group.

 
RFC 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
DOI:10.17487/RFC 2168
The requirements document for URN resolution systems defines the concept of a "resolver discovery service". This document describes the first, experimental, RDS. It is implemented by a new DNS Resource Record, NAPTR (Naming Authority PoinTeR), that provides rules for mapping parts of URIs to domain names. This memo defines an Experimental Protocol for the Internet community.
 
RFC 2169 A Trivial Convention for using HTTP in URN Resolution
 
Authors:R. Daniel.
Date:June 1997
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 2169
This document specifies the "THTTP" resolution protocol - a trivial convention for encoding resolution service requests and responses as HTTP 1.0 or 1.1 requests and responses. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested.
 
RFC 2217 Telnet Com Port Control Option
 
Authors:G. Clark.
Date:October 1997
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 2217
This memo proposes a protocol to allow greater use of modems attached to a network for outbound dialing purposes. This memo defines an Experimental Protocol for the Internet community.
 
RFC 2295 Transparent Content Negotiation in HTTP
 
Authors:K. Holtman, A. Mutz.
Date:March 1998
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 2295
HTTP allows web site authors to put multiple versions of the same information under a single URL. Transparent content negotiation is an extensible negotiation mechanism, layered on top of HTTP, for automatically selecting the best version when the URL is accessed. This enables the smooth deployment of new web data formats and markup tags. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested.
 
RFC 2296 HTTP Remote Variant Selection Algorithm -- RVSA/1.0
 
Authors:K. Holtman, A. Mutz.
Date:March 1998
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 2296
HTTP allows web site authors to put multiple versions of the same information under a single URL. Transparent content negotiation is a mechanism for automatically selecting the best version when the URL is accessed. A remote variant selection algorithm can be used to speed up the transparent negotiation process. This document defines the remote variant selection algorithm with the version number 1.0. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested.
 
RFC 2307 An Approach for Using LDAP as a Network Information Service
 
Authors:L. Howard.
Date:March 1998
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 2307
This document describes an experimental mechanism for mapping entities related to TCP/IP and the UNIX system into X.500 [X500] entries so that they may be resolved with the Lightweight DirectoryAccess Protocol [RFC2251]. A set of attribute types and object classes are proposed, along with specific guidelines for interpreting them.

The intention is to assist the deployment of LDAP as an organizational nameservice. No proposed solutions are intended as standards for the Internet. Rather, it is hoped that a general consensus will emerge as to the appropriate solution to such problems, leading eventually to the adoption of standards. The proposed mechanism has already been implemented with some success.

 
RFC 2310 The Safe Response Header Field
 
Authors:K. Holtman.
Date:April 1998
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 2310
This document defines a HTTP response header field called Safe, which can be used to indicate that repeating a HTTP request is safe. Such an indication will allow user agents to handle retries of some safe requests, in particular safe POST requests, in a more user-friendly way.
 
RFC 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
DOI:10.17487/RFC 2337
This document describes how intra-LIS IP multicast can be efficiently supported among routers over ATM without using the Multicast Address Resolution Server (MARS). This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested.
 
RFC 2343 RTP Payload Format for Bundled MPEG
 
Authors:M. Civanlar, G. Cash, B. Haskell.
Date:May 1998
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 2343
This document describes a payload type for bundled, MPEG-2 encoded video and audio data that may be used with RTP, version 2. Bundling has some advantages for this payload type particularly when it is used for video-on-demand applications. This payload type may be used when its advantages are important enough to sacrifice the modularity of having separate audio and video streams.
 
RFC 2345 Domain Names and Company Name Retrieval
 
Authors:J. Klensin, T. Wolf, G. Oglesby.
Date:May 1998
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 2345
Location of web information for particular companies based on their names has become an increasingly difficult problem as the Internet and the web grow. The use of a naming convention and the domain name system (DNS) for that purpose has caused complications for the latter while not solving the problem. While there have been several proposals to use contemporary, high-capability, directory service and search protocols to reduce the dependencies on DNS conventions, none of them have been significantly deployed.

This document proposes a company name to URL mapping service based on the oldest and least complex of Internet directory protocols, whois, in order to explore whether an extremely simple and widely-deployed protocol can succeed where more complex and powerful options have failed or been excessively delayed.

 
RFC 2362 Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification
 
Authors:D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, L. Wei.
Date:June 1998
Formats:txt pdf
Obsoletes:RFC 2117
Obsoleted by:RFC 4601, RFC 5059
Status:EXPERIMENTAL
DOI:10.17487/RFC 2362
This document describes a protocol for efficiently routing to multicast groups that may span wide-area (and inter-domain) internets. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested.
 
RFC 2414 Increasing TCP's Initial Window
 
Authors:M. Allman, S. Floyd, C. Partridge.
Date:September 1998
Formats:txt pdf
Obsoleted by:RFC 3390
Status:EXPERIMENTAL
DOI:10.17487/RFC 2414
This document specifies an increase in the permitted initial window for TCP from one segment to roughly 4K bytes. This document discusses the advantages and disadvantages of such a change, outlining experimental results that indicate the costs and benefits of such a change to TCP.
 
RFC 2443 A Distributed MARS Service Using SCSP
 
Authors:J. Luciani, A. Gallo.
Date:November 1998
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 2443
This document describes a method for distributing a MARS service within a LIS[1]. This method uses the Server Cache SynchronizationProtocol (SCSP)[2] to synchronize the MARS Server databases within aLIS. When SCSP is used to synchronize the caches of MARS Servers in a LIS, the LIS defines the boundary of an SCSP Server Group (SG).
 
RFC 2481 A Proposal to add Explicit Congestion Notification (ECN) to IP
 
Authors:K. Ramakrishnan, S. Floyd.
Date:January 1999
Formats:txt pdf
Obsoleted by:RFC 3168
Status:EXPERIMENTAL
DOI:10.17487/RFC 2481
This note describes a proposed addition of ECN (Explicit CongestionNotification) to IP. TCP is currently the dominant transport protocol used in the Internet. We begin by describing TCP's use of packet drops as an indication of congestion. Next we argue that with the addition of active queue management (e.g., RED) to the Internet infrastructure, where routers detect congestion before the queue overflows, routers are no longer limited to packet drops as an indication of congestion. Routers could instead set a CongestionExperienced (CE) bit in the packet header of packets from ECN-capable transport protocols. We describe when the CE bit would be set in the routers, and describe what modifications would be needed to TCP to make it ECN-capable. Modifications to other transport protocols(e.g., unreliable unicast or multicast, reliable multicast, other reliable unicast transport protocols) could be considered as those protocols are developed and advance through the standards process.
 
RFC 2483 URI Resolution Services Necessary for URN Resolution
 
Authors:M. Mealling, R. Daniel.
Date:January 1999
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 2483
Retrieving the resource identified by a Uniform Resource Identifier(URI) [1] is only one of the operations that can be performed on aURI. One might also ask for and get a list of other identifiers that are aliases for the original URI or a bibliographic description of the resource the URI denotes, for example. This applies to bothUniform Resource Names (URNs) and Uniform Resource Locators (URLs).Uniform Resource Characteristics (URCs) are discussed in this document but only as descriptions of resources rather than identifiers.

A service in the network providing access to a resource may provide one or some of these options, but it need not provide all of them.This memo specifies an initial set of these operations that can be used to describe the interactions provided by a given access service.It also suggests guidelines that should be adhered to when those operations are encoded in a protocol.

 
RFC 2498 IPPM Metrics for Measuring Connectivity
 
Authors:J. Mahdavi, V. Paxson.
Date:January 1999
Formats:txt pdf
Obsoleted by:RFC 2678
Status:EXPERIMENTAL
DOI:10.17487/RFC 2498
This memo defines a series of metrics for connectivity between a pair of Internet hosts. It builds on notions introduced and discussed in RFC 2330, the IPPM framework document. This memo defines an Experimental Protocol for the Internet community.
 
RFC 2520 NHRP with Mobile NHCs
 
Authors:J. Luciani, H. Suzuki, N. Doraswamy, D. Horton.
Date:February 1999
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 2520
This document describes an extension to NHRP [1] which would allowMobile NHCs to perform a registration with and attach to an NHS in their home LIS in an authenticated manner.

As described in this document, Mobile NHCs are NHCs which are not configured with enough information to find a specific serving NHS in their home LIS, but which have a mechanism to find an NHS (which may or may not be a serving NHS) to which they will attach. As described in [1], an NHC may attach to a 'surrogate' NHS by using a mechanism such as an anycast address. In this case, the NHC may use the surrogate NHS to send a NHRP Registration Request toward the NHC's home LIS where a serving NHS resides. However, as defined in [1], packet authentication is performed on a hop by hop basis. In the mobile NHC case, it is not practical for the mobile NHC be in a security relationship with every surrogate NHS, thus it is presumably desirable to have some form of end to end only authentication for the case of a mobile NHC's registration. This document describes an authentication extension for NHRP which has such end to end only semantics.

 
RFC 2521 ICMP Security Failures Messages
 
Authors:P. Karn, W. Simpson.
Date:March 1999
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 2521
This document specifies ICMP messages for indicating failures when using IP Security Protocols (AH and ESP).
 
RFC 2522 Photuris: Session-Key Management Protocol
 
Authors:P. Karn, W. Simpson.
Date:March 1999
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 2522
Photuris is a session-key management protocol intended for use with the IP Security Protocols (AH and ESP). This document defines the basic protocol mechanisms.
 
RFC 2523 Photuris: Extended Schemes and Attributes
 
Authors:P. Karn, W. Simpson.
Date:March 1999
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 2523
Photuris is a session-key management protocol. Extensible Exchange-Schemes are provided to enable future implementation changes without affecting the basic protocol.

Additional authentication attributes are included for use with the IPAuthentication Header (AH) or the IP Encapsulating Security Protocol(ESP).

Additional confidentiality attributes are included for use with ESP.

 
RFC 2540 Detached Domain Name System (DNS) Information
 
Authors:D. Eastlake 3rd.
Date:March 1999
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 2540
A standard format is defined for representing detached DNS information. This is anticipated to be of use for storing information retrieved from the Domain Name System (DNS), including security information, in archival contexts or contexts not connected to the Internet.
 
RFC 2565 Internet Printing Protocol/1.0: Encoding and Transport
 
Authors:R. Herriot, Ed., S. Butler, P. Moore, R. Turner.
Date:April 1999
Formats:txt pdf
Obsoleted by:RFC 2910
Status:EXPERIMENTAL
DOI:10.17487/RFC 2565
This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing using Internet tools and technologies. This document defines the rules for encoding IPP operations and IPP attributes into a newInternet mime media type called "application/ipp". This document also defines the rules for transporting over HTTP a message body whose Content-Type is "application/ipp".

The full set of IPP documents includes:

Design Goals for an Internet Printing Protocol [RFC2567]Rationale for the Structure and Model and Protocol for theInternet Printing Protocol [RFC2568]Internet Printing Protocol/1.0: Model and Semantics [RFC2566]Internet Printing Protocol/1.0: Encoding and Transport (this document)Internet Printing Protocol/1.0: Implementer's Guide [ipp-iig]Mapping between LPD and IPP Protocols [RFC2569]

The document, "Design Goals for an Internet Printing Protocol", takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. It calls out a subset of end user requirements that are satisfied in IPP/1.0. Operator and administrator requirements are out of scope for version 1.0.

The document, "Rationale for the Structure and Model and Protocol for the Internet Printing Protocol", describes IPP from a high level view, defines a roadmap for the various documents that form the suite of IPP specifications, and gives background and rationale for theIETF working group's major decisions.

The document, "Internet Printing Protocol/1.0: Model and Semantics", describes a simplified model with abstract objects, their attributes, and their operations that are independent of encoding and transport.It introduces a Printer and a Job object. The Job object optionally supports multiple documents per Job. It also addresses security, internationalization, and directory issues.

This document "Internet Printing Protocol/1.0: Implementer's Guide", gives advice to implementers of IPP clients and IPP objects.

The document "Mapping between LPD and IPP Protocols" gives some advice to implementers of gateways between IPP and LPD (Line PrinterDaemon) implementations.

 
RFC 2566 Internet Printing Protocol/1.0: Model and Semantics
 
Authors:R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell.
Date:April 1999
Formats:txt pdf
Obsoleted by:RFC 2911
Status:EXPERIMENTAL
DOI:10.17487/RFC 2566
This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing using Internet tools and technologies. This document describes a simplified model consisting of abstract objects, their attributes, and their operations that is independent of encoding and transport.The model consists of a Printer and a Job object. A Job optionally supports multiple documents. IPP 1.0 semantics allow end-users and operators to query printer capabilities, submit print jobs, inquire about the status of print jobs and printers, and cancel print jobs.This document also addresses security, internationalization, and directory issues.

The full set of IPP documents includes:

Design Goals for an Internet Printing Protocol [RFC2567]Rationale for the Structure and Model and Protocol for the InternetPrinting Protocol [RFC2568]Internet Printing Protocol/1.0: Model and Semantics (this document)Internet Printing Protocol/1.0: Encoding and Transport [RFC2565]Internet Printing Protocol/1.0: Implementer's Guide [ipp-iig]Mapping between LPD and IPP Protocols [RFC2569]

The "Design Goals for an Internet Printing Protocol" document takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. It calls out a subset of end user requirements that are satisfied in IPP/1.0. Operator and administrator requirements are out of scope for version 1.0.

The "Rationale for the Structure and Model and Protocol for theInternet Printing Protocol" document describes IPP from a high level view, defines a roadmap for the various documents that form the suite of IPP specifications, and gives background and rationale for theIETF working group's major decisions.

The "Internet Printing Protocol/1.0: Encoding and Transport" document is a formal mapping of the abstract operations and attributes defined in the model document onto HTTP/1.1. It defines the encoding rules for a new Internet media type called "application/ipp".

The "Internet Printing Protocol/1.0: Implementer's Guide" document gives insight and advice to implementers of IPP clients and IPP objects. It is intended to help them understand IPP/1.0 and some of the considerations that may assist them in the design of their client and/or IPP object implementations. For example, a typical order of processing requests is given, including error checking. Motivation for some of the specification decisions is also included.

The "Mapping between LPD and IPP Protocols" document gives some advice to implementers of gateways between IPP and LPD (Line PrinterDaemon) implementations.

 
RFC 2567 Design Goals for an Internet Printing Protocol
 
Authors:F. Wright.
Date:April 1999
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 2567
This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing using Internet tools and technologies. This document takes a broad look at distributed printing functionality, and it enumerates real- life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. The design goals document calls out a subset of end user requirements that are satisfied in IPP/1.0. Operator and administrator requirements are out of scope for version 1.0.

The full set of IPP documents includes:

Design Goals for an Internet Printing Protocol (this document)Rationale for the Structure and Model and Protocol for theInternet Printing Protocol [RFC2568]Internet Printing Protocol/1.0: Model and Semantics [RFC2568]Internet Printing Protocol/1.0: Encoding and Transport [RFC2565]Internet Printing Protocol/1.0: Implementer's Guide [ipp-iig]Mapping between LPD and IPP Protocols [RFC2569]

The "Rationale for the Structure and Model and Protocol for theInternet Printing Protocol" document describes IPP from a high level view, defines a roadmap for the various documents that form the suite of IPP specifications, and gives background and rationale for theIETF working group's major decisions.

The "Internet Printing Protocol/1.0: Model and Semantics" document describes a simplified model consisting of abstract objects, their attributes, and their operations that is independent of encoding and transport. The model consists of a Printer and a Job object. TheJob optionally supports multiple documents. IPP 1.0 semantics allow end-users and operators to query printer capabilities, submit print jobs, inquire about the status of print jobs and printers, and cancel print jobs. This document also addresses security, internationalization, and directory issues.

The "Internet Printing Protocol/1.0: Encoding and Transport" document is a formal mapping of the abstract operations and attributes defined in the model document onto HTTP/1.1. It defines the encoding rules for a new Internet media type called "application/ipp".

The "Internet Printing Protocol/1.0: Implementer's Guide" document gives insight and advice to implementers of IPP clients and IPP objects. It is intended to help them understand IPP/1.0 and some of the considerations that may assist them in the design of their client and/or IPP object implementations. For example, a typical order of processing requests is given, including error checking. Motivation for some of the specification decisions is also included.

The "Mapping between LPD and IPP Protocols" document gives some advice to implementers of gateways between IPP and LPD (Line PrinterDaemon) implementations.

 
RFC 2568 Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol
 
Authors:S. Zilles.
Date:April 1999
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 2568
This document describes IPP from a high level view, defines a roadmap for the various documents that form the suite of IPP specifications, and gives background and rationale for the IETF working group's major decisions. This memo defines an Experimental Protocol for the Internet community.
 
RFC 2569 Mapping between LPD and IPP Protocols
 
Authors:R. Herriot, Ed., T. Hastings, N. Jacobs, J. Martin.
Date:April 1999
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 2569
This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing using Internet tools and technologies. This document gives some advice to implementers of gateways between IPP and LPD (Line PrinterDaemon). This document describes the mapping between (1) the commands and operands of the 'Line Printer Daemon (LPD) Protocol' specified inRFC 1179 and (2) the operations, operation attributes and job template attributes of the Internet Printing Protocol/1.0 (IPP). One of the purposes of this document is to compare the functionality of the two protocols. Another purpose is to facilitate implementation of gateways between LPD and IPP.

WARNING: RFC 1179 was not on the IETF standards track. While RFC1179 was intended to record existing practice, it fell short in some areas. However, this specification maps between (1) the actual current practice of RFC 1179 and (2) IPP. This document does not attempt to map the numerous divergent extensions to the LPD protocol that have been made by many implementers.

The full set of IPP documents includes:

Design Goals for an Internet Printing Protocol [RFC2567]Rationale for the Structure and Model and Protocol for theInternet Printing Protocol [RFC2568]Internet Printing Protocol/1.0: Model and Semantics [RFC2566]Internet Printing Protocol/1.0: Encoding and Transport [RFC2565]Internet Printing Protocol/1.0: Implementors Guide [ipp-iig]Mapping between LPD and IPP Protocols (this document)

The document, "Design Goals for an Internet Printing Protocol", takes a broad look at distributed printing functionality, and it enumerates real-life scenarios that help to clarify the features that need to be included in a printing protocol for the Internet. It identifies requirements for three types of users: end users, operators, and administrators. It calls out a subset of end user requirements that are satisfied in IPP/1.0. Operator and administrator requirements are out of scope for version 1.0.

The document, "Rationale for the Structure and Model and Protocol for the Internet Printing Protocol", describes IPP from a high level view, defines a roadmap for the various documents that form the suite of IPP specifications, and gives background and rationale for theIETF working group's major decisions.

The document, "Internet Printing Protocol/1.0: Model and Semantics", describes a simplified model with abstract objects, their attributes, and their operations. It introduces a Printer and a Job object. TheJob object supports multiple documents per Job. It also addresses security, internationalization, and directory issues.

The document, "Internet Printing Protocol/1.0: Encoding andTransport", is a formal mapping of the abstract operations and attributes defined in the model document onto HTTP/1.1. It defines the encoding rules for a new Internet media type called ' application/ipp'.

This document "Internet Printing Protocol/1.0: Implementer's Guide", gives advice to implementers of IPP clients and IPP objects.

 
RFC 2582 The NewReno Modification to TCP's Fast Recovery Algorithm
 
Authors:S. Floyd, T. Henderson.
Date:April 1999
Formats:txt pdf
Obsoleted by:RFC 3782
Status:EXPERIMENTAL
DOI:10.17487/RFC 2582
RFC 2001 [RFC2001] documents the following four intertwined TCP congestion control algorithms: Slow Start, Congestion Avoidance, FastRetransmit, and Fast Recovery. RFC 2581 [RFC2581] explicitly allows certain modifications of these algorithms, including modifications that use the TCP Selective Acknowledgement (SACK) option [MMFR96], and modifications that respond to "partial acknowledgments" (ACKs which cover new data, but not all the data outstanding when loss was detected) in the absence of SACK. This document describes a specific algorithm for responding to partial acknowledgments, referred to asNewReno. This response to partial acknowledgments was first proposed by Janey Hoe in [Hoe95].
 
RFC 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
DOI:10.17487/RFC 2593
The IETF Script MIB defines an interface for the delegation of management functions based on the Internet management framework. A management script is a set of instructions that are executed by a language specific runtime system. The Script MIB extensibility protocol (SMX) defined in this memo separates language specific runtime systems from language independent Script MIB implementations.
 
RFC 2649 An LDAP Control and Schema for Holding Operation Signatures
 
Authors:B. Greenblatt, P. Richard.
Date:August 1999
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 2649
In many environments clients require the ability to validiate the source and integrity of information provided by the directory. This document describes an LDAP message control which allows for the retrieval of digitally signed information. This document defines anLDAP v3 based mechanism for signing directory operations in order to create a secure journal of changes that have been made to each directory entry. Both client and server based signatures are supported. An object class for subsequent retrieval are "journal entries" is also defined. This document specifies LDAP v3 controls that enable this functionality. It also defines an LDAP v3 schema that allows for subsequent browsing of the journal information.
 
RFC 2654 A Tagged Index Object for use in the Common Indexing Protocol
 
Authors:R. Hedberg, B. Greenblatt, R. Moats, M. Wahl.
Date:August 1999
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 2654
This document defines a mechanism by which information servers can exchange indices of information from their databases by making use of the Common Indexing Protocol (CIP). This document defines the structure of the index information being exchanged, as well as the appropriate meanings for the headers that are defined in the CommonIndexing Protocol. It is assumed that the structures defined here can be used by X.500 DSAs, LDAP servers, Whois++ servers, CSO Ph servers and many others.
 
RFC 2655 CIP Index Object Format for SOIF Objects
 
Authors:T. Hardie, M. Bowman, D. Hardy, M. Schwartz, D. Wessels.
Date:August 1999
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 2655
This document describes SOIF, the Summary Object Interchange Format, as an index object type in the context of the CIP framework. This memo defines an Experimental Protocol for the Internet community.
 
RFC 2656 Registration Procedures for SOIF Template Types
 
Authors:T. Hardie.
Date:August 1999
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 2656
The Summary Object Interchange Format [Ref. 1] was first defined by the Harvest Project [Ref 2.] in January 1994. SOIF was derived from a combination of the Internet Anonymous FTP Archives IETF WorkingGroup (IAFA) templates [Ref 3.] and the BibTeX bibliography format[Ref 4.]. The combination was originally noted for its advantages of providing a convenient and intuitive way for delimiting objects within a stream, and setting apart the URL for easy object access or invocation, while still preserving compatibility with IAFA templates.

SOIF uses named template types to indicate the attributes which may be contained within a particular summary object. Within the context of a single application, private agreement on the definition of template types has been adequate. As SOIF objects are moved among applications, however, the need for standard, well-specified, and easily identifiable template types increases. This need is particularly intense in the context of query referral, where knowledge of an attribute's definition and the allowed data types for specific values is crucial. For a discussion of this in the context of the Common Indexing Protocol, see [Ref. 1].

The registration procedure described in this document is specific toSOIF template types. There is ongoing work within the IETF to specify a more generic schema registration facility[Ref. 5]. It is not yet clear whether the results of that work will encompass the ability to register entities like SOIF template types. If it does so, the registration of SOIF template types may be shifted to that method and registry. Should that occur, appropriate pointers will be created in cooperation with the Registrar to ensure that no registrations are lost.

 
RFC 2657 LDAPv2 Client vs
 
Authors:the Index Mesh. R. Hedberg.
Date:August 1999
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 2657
LDAPv2 clients as implemented according to RFC 1777 [1] have no notion on referral. The integration between such a client and anIndex Mesh, as defined by the Common Indexing Protocol [2], heavily depends on referrals and therefore needs to be handled in a special way. This document defines one possible way of doing this.
 
RFC 2659 Security Extensions For HTML
 
Authors:E. Rescorla, A. Schiffman.
Date:August 1999
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 2659
This memo describes a syntax for embedding S-HTTP negotiation parameters in HTML documents. S-HTTP, as described by RFC 2660, contains the concept of negotiation headers which reflect the potential receiver of a message's preferences as to which crypto- graphic enhancements should be applied to the message. This document describes a syntax for binding these negotiation parameters to HTML anchors.

1. Introduction

2. Anchor Attributes

We define the following new anchor (and form submission) attributes:

DN -- The distinguished name of the principal for whom the request should be encrypted when dereferencing the anchor's url.This need not be specified, but failure to do so runs the risk that the client will be unable to determine the DN and therefore will be unable to encrypt. This should be specified in the form of RFC1485, using SGML quoting conventions as needed.

NONCE -- A free-format string (appropriately SGML quoted) which is to be included in a SHTTP-Nonce: header (after SGML quoting is removed) when the anchor is dereferenced.

CRYPTOPTS -- Cryptographic option information as described in

[SHTTP]. Specifically, the <cryptopt-list&rt; production.

 
RFC 2660 The Secure HyperText Transfer Protocol
 
Authors:E. Rescorla, A. Schiffman.
Date:August 1999
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 2660
This memo describes a syntax for securing messages sent using theHypertext Transfer Protocol (HTTP), which forms the basis for theWorld Wide Web. Secure HTTP (S-HTTP) provides independently applicable security services for transaction confidentiality, authenticity/integrity and non-repudiability of origin.

The protocol emphasizes maximum flexibility in choice of key management mechanisms, security policies and cryptographic algorithms by supporting option negotiation between parties for each transaction.

 
RFC 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
DOI:10.17487/RFC 2676
This memo describes extensions to the OSPF [Moy98] protocol to support QoS routes. The focus of this document is on the algorithms used to compute QoS routes and on the necessary modifications to OSPF to support this function, e.g., the information needed, its format, how it is distributed, and how it is used by the QoS path selection process. Aspects related to how QoS routes are established and managed are also briefly discussed. The goal of this document is to identify a framework and possible approaches to allow deployment ofQoS routing capabilities with the minimum possible impact to the existing routing infrastructure.

In addition, experience from an implementation of the proposed extensions in the GateD environment [Con], along with performance measurements is presented.

 
RFC 2692 SPKI Requirements
 
Authors:C. Ellison.
Date:September 1999
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 2692
The IETF Simple Public Key Infrastructure [SPKI] Working Group is tasked with producing a certificate structure and operating procedure to meet the needs of the Internet community for trust management in as easy, simple and extensible a way as possible.

The SPKI Working Group first established a list of things one might want to do with certificates (attached at the end of this document), and then summarized that list of desires into requirements. This document presents that summary of requirements.

 
RFC 2693 SPKI Certificate Theory
 
Authors:C. Ellison, B. Frantz, B. Lampson, R. Rivest, B. Thomas, T. Ylonen.
Date:September 1999
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 2693
The SPKI Working Group has developed a standard form for digital certificates whose main purpose is authorization rather than authentication. These structures bind either names or explicit authorizations to keys or other objects. The binding to a key can be directly to an explicit key, or indirectly through the hash of the key or a name for it. The name and authorization structures can be used separately or together. We use S-expressions as the standard format for these certificates and define a canonical form for thoseS-expressions. As part of this development, a mechanism for deriving authorization decisions from a mixture of certificate types was developed and is presented in this document.

This document gives the theory behind SPKI certificates and ACLs without going into technical detail about those structures or their uses.

 
RFC 2716 PPP EAP TLS Authentication Protocol
 
Authors:B. Aboba, D. Simon.
Date:October 1999
Formats:txt pdf
Obsoleted by:RFC 5216
Status:EXPERIMENTAL
DOI:10.17487/RFC 2716
The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links.The Extensible Authentication Protocol (EAP) is a PPP extension that provides support for additional authentication methods within PPP. This memo defines an Experimental Protocol for the Internet community.
 
RFC 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
DOI:10.17487/RFC 2724
The RTFM Traffic Measurement Architecture provides a general framework for describing and measuring network traffic flows. Flows are defined in terms of their Address Attribute values and measured by a 'Traffic Meter'. This document discusses RTFM flows and the attributes which they can have, so as to provide a logical framework for extending the architecture by adding new attributes.

Extensions described include Address Attributes such as DSCodePoint,SourceASN and DestASN, and Group Attributes such as short-term bit rates and turnaround times. Quality of Service parameters forIntegrated Services are also discussed.

 
RFC 2756 Hyper Text Caching Protocol (HTCP/0.0)
 
Authors:P. Vixie, D. Wessels.
Date:January 2000
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 2756
This document describes HTCP, a protocol for discovering HTTP caches and cached data, managing sets of HTTP caches, and monitoring cache activity. This is an experimental protocol, one among several proposals to perform these functions.
 
RFC 2758 Definitions of Managed Objects for Service Level Agreements Performance Monitoring
 
Authors:K. White.
Date:February 2000
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 2758
This memo defines a Management Information Base (MIB) for performance monitoring of Service Level Agreements (SLAs) defined via policy definitions. The MIB defined herein focuses on defining a set of objects for monitoring SLAs and not on replication of the content of the policy definitions being monitored. The goal of the MIB defined within this document is to defined statistics related to a policy rule definition for reporting on the effect that a policy rule has on a system and to defined a method of monitoring this data.
 
RFC 2762 Sampling of the Group Membership in RTP
 
Authors:J. Rosenberg, H. Schulzrinne.
Date:February 2000
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 2762
In large multicast groups, the size of the group membership table maintained by RTP (Real Time Transport Protocol) participants may become unwieldy, particularly for embedded devices with limited memory and processing power. This document discusses mechanisms for sampling of this group membership table in order to reduce the memory requirements. Several mechanisms are proposed, and the performance of each is considered.
 
RFC 2770 GLOP Addressing in 233/8
 
Authors:D. Meyer, P. Lothberg.
Date:February 2000
Formats:txt pdf
Obsoleted by:RFC 3180
Status:EXPERIMENTAL
DOI:10.17487/RFC 2770
This describes an experimental policy for use of the class D address space using 233/8 as the experimental statically assigned subset of the class D address space. This new experimental allocation is in addition to those described on [IANA] (e.g. [RFC2365]).

This memo is a product of the Multicast Deployment Working Group(MBONED) in the Operations and Management Area of the InternetEngineering Task Force. Submit comments to <mboned@ns.uoregon.edu&rt; or the authors.

 
RFC 2773 Encryption using KEA and SKIPJACK
 
Authors:R. Housley, P. Yee, W. Nace.
Date:February 2000
Formats:txt pdf
Updates:RFC 0959
Status:EXPERIMENTAL
DOI:10.17487/RFC 2773
This document defines a method to encrypt a file transfer using theFTP specification STD 9, RFC 959, "File Transfer Protocol (FTP)",(October 1985) [3] and RFC 2228, "FTP Security Extensions" (October1997) [1]. This method will use the Key Exchange Algorithm (KEA) to give mutual authentication and establish the data encryption keys.SKIPJACK is used to encrypt file data and the FTP command channel.
 
RFC 2774 An HTTP Extension Framework
 
Authors:H. Nielsen, P. Leach, S. Lawrence.
Date:February 2000
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 2774
A wide range of applications have proposed various extensions of theHTTP protocol. Current efforts span an enormous range, including distributed authoring, collaboration, printing, and remote procedure call mechanisms. These HTTP extensions are not coordinated, since there has been no standard framework for defining extensions and thus, separation of concerns. This document describes a generic extension mechanism for HTTP, which is designed to address the tension between private agreement and public specification and to accommodate extension of applications using HTTP clients, servers, and proxies. The proposal associates each extension with a globally unique identifier, and uses HTTP header fields to carry the extension identifier and related information between the parties involved in the extended communication.
 
RFC 2786 Diffie-Helman USM Key Management Information Base and Textual Convention
 
Authors:M. St. Johns.
Date:March 2000
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 2786
This memo defines an experimental portion of the ManagementInformation Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a textual convention for doing Diffie-Helman key agreement key exchanges and a set of objects which extend the usmUserTable to permit the use of aDH key exchange in addition to the key change method described in[12]. In otherwords, this MIB adds the possibility of forward secrecy to the USM model. It also defines a set of objects that can be used to kick start security on an SNMPv3 agent when the out of band path is authenticated, but not necessarily private or confidential.

The KeyChange textual convention described in [12] permits secure key changes, but has the property that if a third-party has knowledge of the original key (e.g. if the agent was manufactured with a standard default key) and could capture all SNMP exchanges, the third-party would know the new key. The Diffie-Helman key change described here limits knowledge of the new key to the agent and the manager making the change. In otherwords, this process adds forward secrecy to the key change process.

The recommendation in [12] is that the usmUserTable be populated out of band - e.g. not via SNMP. If the number of agents to be configured is small, this can be done via a console port and manually. If the number of agents is large, as is the case for a cable modem system, the manual approach doesn't scale well. The combination of the two mechanisms specified here - the DH key change mechanism, and the DH key ignition mechanism - allows managable use of SNMPv3 USM in a system of millions of devices.

This memo specifies a MIB module in a manner that is compliant to theSNMP SMIv2[5][6][7]. The set of objects is consistent with the SNMP framework and existing SNMP standards and is intended for use with the SNMPv3 User Security Model MIB and other security related MIBs.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [16].

This memo is a private submission by the author, but is applicable to the SNMPv3 working group within the Internet Engineering Task Force.Comments are solicited and should be addressed to the the author.

 
RFC 2823 PPP over Simple Data Link (SDL) using SONET/SDH with ATM-like framing
 
Authors:J. Carlson, P. Langner, E. Hernandez-Valencia, J. Manchester.
Date:May 2000
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 2823
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links, andRFCs 1662 [2] and 2615 [3] provide a means to carry PPP overSynchronous Optical Network (SONET) [4] and Synchronous DigitalHierarchy (SDH) [5] circuits. This document extends these standards to include a new encapsulation for PPP called Simple Data Link (SDL)[6]. SDL provides a very low overhead alternative to HDLC-like encapsulation, and can also be used on SONET/SDH links.
 
RFC 2844 OSPF over ATM and Proxy-PAR
 
Authors:T. Przygienda, P. Droz, R. Haas.
Date:May 2000
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 2844
This memo specifies, for OSPF implementors and users, mechanisms describing how the protocol operates in ATM networks over PVC and SVC meshes with the presence of Proxy-PAR. These recommendations require no protocol changes and allow simpler, more efficient and cost- effective network designs. It is recommended that OSPF implementations should be able to support logical interfaces, each consisting of one or more virtual circuits and used either as numbered logical point-to-point links (one VC), logical NBMA networks(more than one VC) or Point-to-MultiPoint networks (more than oneVC), where a solution simulating broadcast interfaces is not appropriate. PAR can help distribute across the ATM cloud configuration setup and changes of such interfaces when OSPF capable routers are (re-)configured. Proxy-PAR can in turn be used to exchange this information between the ATM cloud and the routers connected to it.
 
RFC 2859 A Time Sliding Window Three Colour Marker (TSWTCM)
 
Authors:W. Fang, N. Seddigh, B. Nandy.
Date:June 2000
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 2859
This memo defines a Time Sliding Window Three Colour Marker (TSWTCM), which can be used as a component in a Diff-Serv traffic conditioner[RFC2475, RFC2474]. The marker is intended to mark packets that will be treated by the Assured Forwarding (AF) Per Hop Behaviour (PHB)[AFPHB] in downstream routers. The TSWTCM meters a traffic stream and marks packets to be either green, yellow or red based on the measured throughput relative to two specified rates: Committed Target Rate(CTR) and Peak Target Rate (PTR).
 
RFC 2903 Generic AAA Architecture
 
Authors:C. de Laat, G. Gross, L. Gommans, J. Vollbrecht, D. Spence.
Date:August 2000
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 2903
This memo proposes an Authentication, Authorization, Accounting (AAA) architecture that would incorporate a generic AAA server along with an application interface to a set of Application Specific Modules that could perform application specific AAA functions. A separation of AAA functions required in a multi-domain environment is then proposed using a layered protocol abstraction. The long term goal is to create a generic framework which allows complex authorizations to be realized through a network of interconnected AAA servers.
 
RFC 2934 Protocol Independent Multicast MIB for IPv4
 
Authors:K. McCloghrie, D. Farinacci, D. Thaler, B. Fenner.
Date:October 2000
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 2934
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes managed objects used for managing theProtocol Independent Multicast (PIM) protocol for IPv4.
 
RFC 2974 Session Announcement Protocol
 
Authors:M. Handley, C. Perkins, E. Whelan.
Date:October 2000
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 2974
This document describes version 2 of the multicast session directory announcement protocol, Session Announcement Protocol (SAP), and the related issues affecting security and scalability that should be taken into account by implementors.
 
RFC 3018 Unified Memory Space Protocol Specification
 
Authors:A. Bogdanov.
Date:December 2000
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 3018
This document specifies Unified Memory Space Protocol (UMSP), which gives a capability of immediate access to memory of the remote nodes.
 
RFC 3029 Internet X.509 Public Key Infrastructure Data Validation and Certification Server Protocols
 
Authors:C. Adams, P. Sylvester, M. Zolotarev, R. Zuccherato.
Date:February 2001
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 3029
This document describes a general Data Validation and CertificationServer (DVCS) and the protocols to be used when communicating with it. The Data Validation and Certification Server is a Trusted ThirdParty (TTP) that can be used as one component in building reliable non-repudiation services.

Useful Data Validation and Certification Server responsibilities in aPKI are to assert the validity of signed documents, public key certificates, and the possession or existence of data.

Assertions created by this protocol are called Data ValidationCertificates (DVC).

We give examples of how to use the Data Validation and CertificationServer to extend the lifetime of a signature beyond key expiry or revocation and to query the Data Validation and Certification Server regarding the status of a public key certificate. The document includes a complete example of a time stamping transaction.

 
RFC 3063 MPLS Loop Prevention Mechanism
 
Authors:Y. Ohba, Y. Katsube, E. Rosen, P. Doolan.
Date:February 2001
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 3063
This paper presents a simple mechanism, based on "threads", which can be used to prevent Multiprotocol Label Switching (MPLS) from setting up label switched path (LSPs) which have loops. The mechanism is compatible with, but does not require, VC merge. The mechanism can be used with either the ordered downstream-on-demand allocation or ordered downstream allocation. The amount of information that must be passed in a protocol message is tightly bounded (i.e., no path- vector is used). When a node needs to change its next hop, a distributed procedure is executed, but only nodes which are downstream of the change are involved.
 
RFC 3082 Notification and Subscription for SLP
 
Authors:J. Kempf, J. Goldschmidt.
Date:March 2001
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 3082
The Service Location Protocol (SLP) provides mechanisms whereby service agent clients can advertise and user agent clients can query for services. The design is very much demand-driven, so that user agents only obtain service information when they specifically ask for it. There exists another class of user agent applications, however, that requires notification when a new service appears or disappears.In the RFC 2608 design, these applications are forced to poll the network to catch changes. In this document, we describe a protocol for allowing such clients to be notified when a change occurs, removing the need for polling.
 
RFC 3088 OpenLDAP Root Service An experimental LDAP referral service
 
Authors:K. Zeilenga.
Date:April 2001
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 3088
The OpenLDAP Project is operating an experimental LDAP (LightweightDirectory Access Protocol) referral service known as the "OpenLDAPRoot Service". The automated system generates referrals based upon service location information published in DNS SRV RRs (Domain NameSystem location of services resource records). This document describes this service.
 
RFC 3102 Realm Specific IP: Framework
 
Authors:M. Borella, J. Lo, D. Grabelsky, G. Montenegro.
Date:October 2001
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 3102
This document examines the general framework of Realm Specific IP(RSIP). RSIP is intended as a alternative to NAT in which the end- to-end integrity of packets is maintained. We focus on implementation issues, deployment scenarios, and interaction with other layer-three protocols.
 
RFC 3103 Realm Specific IP: Protocol Specification
 
Authors:M. Borella, D. Grabelsky, J. Lo, K. Taniguchi.
Date:October 2001
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 3103
This document presents a protocol with which to implement RealmSpecific IP (RSIP). The protocol defined herein allows negotiation of resources between an RSIP host and gateway, so that the host can lease some of the gateway's addressing parameters in order to establish a global network presence. This protocol is designed to operate on the application layer and to use its own TCP or UDP port.In particular, the protocol allows a gateway to allocate addressing and control parameters to a host such that a flow policy can be enforced at the gateway.
 
RFC 3104 RSIP Support for End-to-end IPsec
 
Authors:G. Montenegro, M. Borella.
Date:October 2001
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 3104
This document proposes mechanisms that enable Realm Specific IP(RSIP) to handle end-to-end IPsec (IP Security).
 
RFC 3105 Finding an RSIP Server with SLP
 
Authors:J. Kempf, G. Montenegro.
Date:October 2001
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 3105
This document contains an SLP service type template that describes the advertisements made by RSIP servers for their services. ServiceLocation Protocol (SLP) is an IETF standards track protocol specifically designed to allow clients to find servers offering particular services. Since RSIP (Realm Specific IP) clients require a mechanism to discover RSIP servers, SLP is a natural match for a solution. The service type template is the basis for an InternetAssigned Numbers Authority (IANA) standard definition of the advertisements offered by RSIP servers, an important step toward interoperability.
 
RFC 3123 A DNS RR Type for Lists of Address Prefixes (APL RR)
 
Authors:P. Koch.
Date:June 2001
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 3123
The Domain Name System (DNS) is primarily used to translate domain names into IPv4 addresses using A RRs (Resource Records). Several approaches exist to describe networks or address ranges. This document specifies a new DNS RR type "APL" for address prefix lists.
 
RFC 3125 Electronic Signature Policies
 
Authors:J. Ross, D. Pinkas, N. Pope.
Date:September 2001
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 3125
This document defines signature policies for electronic signatures. A signature policy is a set of rules for the creation and validation of an electronic signature, under which the validity of signature can be determined. A given legal/contractual context may recognize a particular signature policy as meeting its requirements.

A signature policy has a globally unique reference, which is bound to an electronic signature by the signer as part of the signature calculation.

The signature policy needs to be available in human readable form so that it can be assessed to meet the requirements of the legal and contractual context in which it is being applied.

To allow for the automatic processing of an electronic signature another part of the signature policy specifies the electronic rules for the creation and validation of the electronic signature in a computer processable form. In the current document the format of the signature policy is defined using ASN.1.

The contents of this document is based on the signature policy defined in ETSI TS 101 733 V.1.2.2 (2000-12) Copyright (C).Individual copies of this ETSI deliverable can be downloaded from http://www.etsi.org.

 
RFC 3163 ISO/IEC 9798-3 Authentication SASL Mechanism
 
Authors:R. Zuccherato, M. Nystrom.
Date:August 2001
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 3163
This document defines a SASL (Simple Authentication and SecurityLayer) authentication mechanism based on ISO/IEC 9798-3 and FIPS PUB196 entity authentication.
 
RFC 3179 Script MIB Extensibility Protocol Version 1.1
 
Authors:J. Schoenwaelder, J. Quittek.
Date:October 2001
Formats:txt pdf
Obsoletes:RFC 2593
Status:EXPERIMENTAL
DOI:10.17487/RFC 3179
The Script MIB extensibility protocol (SMX) defined in this memo separates language specific runtime systems from language independentScript MIB implementations. The IETF Script MIB defines an interface for the delegation of management functions based on the Internet management framework. A management script is a set of instructions that are executed by a language specific runtime system.
 
RFC 3183 Domain Security Services using S/MIME
 
Authors:T. Dean, W. Ottaway.
Date:October 2001
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 3183
This document describes how the S/MIME (Secure/Multipurpose InternetMail Extensions) protocol can be processed and generated by a number of components of a communication system, such as message transfer agents, guards and gateways to deliver security services. These services are collectively referred to as 'Domain Security Services'.
 
RFC 3208 PGM Reliable Transport Protocol Specification
 
Authors:T. Speakman, J. Crowcroft, J. Gemmell, D. Farinacci, S. Lin, D. Leshchiner, M. Luby, T. Montgomery, L. Rizzo, A. Tweedly, N. Bhaskar, R. Edmonstone, R. Sumanasekera, L. Vicisano.
Date:December 2001
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 3208
Pragmatic General Multicast (PGM) is a reliable multicast transport protocol for applications that require ordered or unordered, duplicate-free, multicast data delivery from multiple sources to multiple receivers. PGM guarantees that a receiver in the group either receives all data packets from transmissions and repairs, or is able to detect unrecoverable data packet loss. PGM is specifically intended as a workable solution for multicast applications with basic reliability requirements. Its central design goal is simplicity of operation with due regard for scalability and network efficiency.
 
RFC 3334 Policy-Based Accounting
 
Authors:T. Zseby, S. Zander, C. Carle.
Date:October 2002
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 3334
This document describes policy-based accounting which is an approach to provide flexibility to accounting architectures. Accounting policies describe the configuration of an accounting architecture in a standardized way. They are used to instrument the accounting architecture and can be exchanged between Authentication,Authorization and Accounting (AAA) entities in order to share configuration information.

This document describes building blocks and message sequences for policy-based accounting in the generic AAA architecture (RFC 2903).Examples are given for the usage of accounting policies in different scenarios. It is also shown how accounting components can be integrated into the AAA authorization framework (RFC 2904). This document does not propose a language for the description of accounting policies. Rather, it is assumed that a suitable policy language can be chosen from existing or upcoming standards.

 
RFC 3338 Dual Stack Hosts Using "Bump-in-the-API" (BIA)
 
Authors:S. Lee, M-K. Shin, Y-J. Kim, E. Nordmark, A. Durand.
Date:October 2002
Formats:txt pdf
Obsoleted by:RFC 6535
Status:EXPERIMENTAL
DOI:10.17487/RFC 3338
This document specifies a mechanism of dual stack hosts using a technique called "Bump-in-the-API"(BIA) which allows for the hosts to communicate with other IPv6 hosts using existing IPv4 applications.The goal of this mechanism is the same as that of the Bump-in-the- stack mechanism, but this mechanism provides the translation method between the IPv4 APIs and IPv6 APIs. Thus, the goal is simply achieved without IP header translation.
 
RFC 3421 Select and Sort Extensions for the Service Location Protocol (SLP)
 
Authors:W. Zhao, H. Schulzrinne, E. Guttman, C. Bisdikian, W. Jerome.
Date:November 2002
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 3421
This document defines two extensions (Select and Sort) for theService Location Protocol (SLP). These extensions allow a User Agent(UA) to request that the Uniform Resource Locator (URL) entries in aService Reply (SrvRply) be limited to the specified number, or be sorted according to the specified sort key list. Using these two extensions together can facilitate discovering the best match, such as finding a service that has the maximum speed or the minimum load.
 
RFC 3430 Simple Network Management Protocol Over Transmission Control Protocol Transport Mapping
 
Authors:J. Schoenwaelder.
Date:December 2002
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 3430
This memo defines a transport mapping for using the Simple NetworkManagement Protocol (SNMP) over TCP. The transport mapping can be used with any version of SNMP. This document extends the transport mappings defined in STD 62, RFC 3417.
 
RFC 3450 Asynchronous Layered Coding (ALC) Protocol Instantiation
 
Authors:M. Luby, J. Gemmell, L. Vicisano, L. Rizzo, J. Crowcroft.
Date:December 2002
Formats:txt pdf
Obsoleted by:RFC 5775
Status:EXPERIMENTAL
DOI:10.17487/RFC 3450
This document describes the Asynchronous Layered Coding (ALC) protocol, a massively scalable reliable content delivery protocol.Asynchronous Layered Coding combines the Layered Coding Transport(LCT) building block, a multiple rate congestion control building block and the Forward Error Correction (FEC) building block to provide congestion controlled reliable asynchronous delivery of content to an unlimited number of concurrent receivers from a single sender.
 
RFC 3451 Layered Coding Transport (LCT) Building Block
 
Authors:M. Luby, J. Gemmell, L. Vicisano, L. Rizzo, M. Handley, J. Crowcroft.
Date:December 2002
Formats:txt pdf
Obsoleted by:RFC 5651
Status:EXPERIMENTAL
DOI:10.17487/RFC 3451
Layered Coding Transport (LCT) provides transport level support for reliable content delivery and stream delivery protocols. LCT is specifically designed to support protocols using IP multicast, but also provides support to protocols that use unicast. LCT is compatible with congestion control that provides multiple rate delivery to receivers and is also compatible with coding techniques that provide reliable delivery of content.
 
RFC 3452 Forward Error Correction (FEC) Building Block
 
Authors:M. Luby, L. Vicisano, J. Gemmell, L. Rizzo, M. Handley, J. Crowcroft.
Date:December 2002
Formats:txt pdf
Obsoleted by:RFC 5052, RFC 5445
Status:EXPERIMENTAL
DOI:10.17487/RFC 3452
This document generally describes how to use Forward Error Correction(FEC) codes to efficiently provide and/or augment reliability for data transport. The primary focus of this document is the application of FEC codes to one-to-many reliable data transport usingIP multicast. This document describes what information is needed to identify a specific FEC code, what information needs to be communicated out-of-band to use the FEC code, and what information is needed in data packets to identify the encoding symbols they carry.The procedures for specifying FEC codes and registering them with theInternet Assigned Numbers Authority (IANA) are also described. This document should be read in conjunction with and uses the terminology of the companion document titled, "The Use of Forward ErrorCorrection (FEC) in Reliable Multicast".
 
RFC 3465 TCP Congestion Control with Appropriate Byte Counting (ABC)
 
Authors:M. Allman.
Date:February 2003
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 3465
This document proposes a small modification to the way TCP increases its congestion window. Rather than the traditional method of increasing the congestion window by a constant amount for each arriving acknowledgment, the document suggests basing the increase on the number of previously unacknowledged bytes each ACK covers. This change improves the performance of TCP, as well as closes a security hole TCP receivers can use to induce the sender into increasing the sending rate too rapidly.
 
RFC 3522 The Eifel Detection Algorithm for TCP
 
Authors:R. Ludwig, M. Meyer.
Date:April 2003
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 3522
The Eifel detection algorithm allows a TCP sender to detect a posteriori whether it has entered loss recovery unnecessarily. It requires that the TCP Timestamps option defined in RFC 1323 be enabled for a connection. The Eifel detection algorithm makes use of the fact that the TCP Timestamps option eliminates the retransmission ambiguity in TCP. Based on the timestamp of the first acceptable ACK that arrives during loss recovery, it decides whether loss recovery was entered unnecessarily. The Eifel detection algorithm provides a basis for future TCP enhancements. This includes response algorithms to back out of loss recovery by restoring a TCP sender's congestion control state.
 
RFC 3528 Mesh-enhanced Service Location Protocol (mSLP)
 
Authors:W. Zhao, H. Schulzrinne, E. Guttman.
Date:April 2003
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 3528
This document describes the Mesh-enhanced Service Location Protocol(mSLP). mSLP enhances the Service Location Protocol (SLP) with a scope-based fully-meshed peering Directory Agent (DA) architecture.Peer DAs exchange new service registrations in shared scopes via anti-entropy and direct forwarding. mSLP improves the reliability and consistency of SLP DA services, and simplifies Service Agent (SA) registrations in systems with multiple DAs. mSLP is backward compatible with SLPv2 and can be deployed incrementally.
 
RFC 3529 Using Extensible Markup Language-Remote Procedure Calling (XML-RPC) in Blocks Extensible Exchange Protocol (BEEP)
 
Authors:W. Harold.
Date:April 2003
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 3529
XML-RPC is an Extensible Markup Language-Remote Procedure Calling protocol that works over the Internet. It defines an XML format for messages that are transfered between clients and servers using HTTP.An XML-RPC message encodes either a procedure to be invoked by the server, along with the parameters to use in the invocation, or the result of an invocation. Procedure parameters and results can be scalars, numbers, strings, dates, etc.; they can also be complex record and list structures.

This document specifies a how to use the Blocks Extensible ExchangeProtocol (BEEP) to transfer messages encoded in the XML-RPC format between clients and servers.

 
RFC 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
DOI:10.17487/RFC 3561
The Ad hoc On-Demand Distance Vector (AODV) routing protocol is intended for use by mobile nodes in an ad hoc network. It offers quick adaptation to dynamic link conditions, low processing and memory overhead, low network utilization, and determines unicast routes to destinations within the ad hoc network. It uses destination sequence numbers to ensure loop freedom at all times(even in the face of anomalous delivery of routing control messages), avoiding problems (such as "counting to infinity") associated with classical distance vector protocols.
 
RFC 3618 Multicast Source Discovery Protocol (MSDP)
 
Authors:B. Fenner, Ed., D. Meyer, Ed..
Date:October 2003
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 3618
The Multicast Source Discovery Protocol (MSDP) describes a mechanism to connect multiple IP Version 4 Protocol Independent MulticastSparse-Mode (PIM-SM) domains together. Each PIM-SM domain uses its own independent Rendezvous Point (RP) and does not have to depend onRPs in other domains. This document reflects existing MSDP implementations.
 
RFC 3626 Optimized Link State Routing Protocol (OLSR)
 
Authors:T. Clausen, Ed., P. Jacquet, Ed..
Date:October 2003
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 3626
This document describes the Optimized Link State Routing (OLSR) protocol for mobile ad hoc networks. The protocol is an optimization of the classical link state algorithm tailored to the requirements of a mobile wireless LAN. The key concept used in the protocol is that of multipoint relays (MPRs). MPRs are selected nodes which forward broadcast messages during the flooding process. This technique substantially reduces the message overhead as compared to a classical flooding mechanism, where every node retransmits each message when it receives the first copy of the message. In OLSR, link state information is generated only by nodes elected as MPRs. Thus, a second optimization is achieved by minimizing the number of control messages flooded in the network. As a third optimization, an MPR node may chose to report only links between itself and its MPR selectors. Hence, as contrary to the classic link state algorithm, partial link state information is distributed in the network. This information is then used for route calculation. OLSR provides optimal routes (in terms of number of hops). The protocol is particularly suitable for large and dense networks as the technique of MPRs works well in this context.
 
RFC 3649 HighSpeed TCP for Large Congestion Windows
 
Authors:S. Floyd.
Date:December 2003
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 3649
The proposals in this document are experimental. While they may be deployed in the current Internet, they do not represent a consensus that this is the best method for high-speed congestion control. In particular, we note that alternative experimental proposals are likely to be forthcoming, and it is not well understood how the proposals in this document will interact with such alternative proposals.

This document proposes HighSpeed TCP, a modification to TCP's congestion control mechanism for use with TCP connections with large congestion windows. The congestion control mechanisms of the currentStandard TCP constrains the congestion windows that can be achieved by TCP in realistic environments. For example, for a Standard TCP connection with 1500-byte packets and a 100 ms round-trip time, achieving a steady-state throughput of 10 Gbps would require an average congestion window of 83,333 segments, and a packet drop rate of at most one congestion event every 5,000,000,000 packets (or equivalently, at most one congestion event every 1 2/3 hours). This is widely acknowledged as an unrealistic constraint. To address this limitation of TCP, this document proposes HighSpeed TCP, and solicits experimentation and feedback from the wider community.

 
RFC 3656 The Mailbox Update (MUPDATE) Distributed Mailbox Database Protocol
 
Authors:R. Siemborski.
Date:December 2003
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 3656
As the demand for high-performance mail delivery agents increases, it becomes apparent that single-machine solutions are inadequate to the task, both because of capacity limits and that the failure of the single machine means a loss of mail delivery for all users. It is preferable to allow many machines to share the responsibility of mail delivery.

The Mailbox Update (MUPDATE) protocol allows a group of InternetMessage Access Protocol (IMAP) or Post Office Protocol - Version 3(POP3) servers to function with a unified mailbox namespace. This document is intended to serve as a reference guide to that protocol.

 
RFC 3663 Domain Administrative Data in Lightweight Directory Access Protocol (LDAP)
 
Authors:A. Newton.
Date:December 2003
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 3663
Domain registration data has typically been exposed to the general public via Nicname/Whois for administrative purposes. This document describes the Referral Lightweight Directory Access Protocol (LDAP)Service, an experimental service using LDAP and well-known LDAP types to make domain administrative data available.
 
RFC 3682 The Generalized TTL Security Mechanism (GTSM)
 
Authors:V. Gill, J. Heasley, D. Meyer.
Date:February 2004
Formats:txt pdf
Obsoleted by:RFC 5082
Status:EXPERIMENTAL
DOI:10.17487/RFC 3682
The use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to protect a protocol stack from CPU-utilization based attacks has been proposed in many settings (see for example, RFC 2461). This document generalizes these techniques for use by other protocols such as BGP (RFC 1771), Multicast Source Discovery Protocol (MSDP),Bidirectional Forwarding Detection, and Label Distribution Protocol(LDP) (RFC 3036). While the Generalized TTL Security Mechanism(GTSM) is most effective in protecting directly connected protocol peers, it can also provide a lower level of protection to multi-hop sessions. GTSM is not directly applicable to protocols employing flooding mechanisms (e.g., multicast), and use of multi-hop GTSM should be considered on a case-by-case basis.
 
RFC 3684 Topology Dissemination Based on Reverse-Path Forwarding (TBRPF)
 
Authors:R. Ogier, F. Templin, M. Lewis.
Date:February 2004
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 3684
Topology Dissemination Based on Reverse-Path Forwarding (TBRPF) is a proactive, link-state routing protocol designed for mobile ad-hoc networks, which provides hop-by-hop routing along shortest paths to each destination. Each node running TBRPF computes a source tree(providing paths to all reachable nodes) based on partial topology information stored in its topology table, using a modification ofDijkstra's algorithm. To minimize overhead, each node reports only*part* of its source tree to neighbors. TBRPF uses a combination of periodic and differential updates to keep all neighbors informed of the reported part of its source tree. Each node also has the option to report additional topology information (up to the full topology), to provide improved robustness in highly mobile networks. TBRPF performs neighbor discovery using "differential" HELLO messages which report only *changes* in the status of neighbors. This results inHELLO messages that are much smaller than those of other link-state routing protocols such as OSPF.
 
RFC 3695 Compact Forward Error Correction (FEC) Schemes
 
Authors:M. Luby, L. Vicisano.
Date:February 2004
Formats:txt pdf
Obsoleted by:RFC 5445
Status:EXPERIMENTAL
DOI:10.17487/RFC 3695
This document introduces some Forward Error Correction (FEC) schemes that supplement the FEC schemes described in RFC 3452. The primary benefits of these additional FEC schemes are that they are designed for reliable bulk delivery of large objects using a more compact FECPayload ID, and they can be used to sequentially deliver blocks of an object of indeterminate length. Thus, they more flexibly support different delivery models with less packet header overhead.

This document also describes the Fully-Specified FEC scheme corresponding to FEC Encoding ID 0. This Fully-Specified FEC scheme requires no FEC coding and is introduced primarily to allow simple interoperability testing between different implementations of protocol instantiations that use the FEC building block.

 
RFC 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
DOI:10.17487/RFC 3708
TCP and Stream Control Transmission Protocol (SCTP) provide notification of duplicate segment receipt through Duplicate SelectiveAcknowledgement (DSACKs) and Duplicate Transmission Sequence Number(TSN) notification, respectively. This document presents conservative methods of using this information to identify unnecessary retransmissions for various applications.
 
RFC 3738 Wave and Equation Based Rate Control (WEBRC) Building Block
 
Authors:M. Luby, V. Goyal.
Date:April 2004
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 3738
This document specifies Wave and Equation Based Rate Control (WEBRC), which provides rate and congestion control for data delivery. WEBRC is specifically designed to support protocols using IP multicast. It provides multiple-rate, congestion-controlled delivery to receivers, i.e., different receivers joined to the same session may be receiving packets at different rates depending on the bandwidths of their individual connections to the sender and on competing traffic along these connections. WEBRC requires no feedback from receivers to the sender, i.e., it is a completely receiver-driven congestion control protocol. Thus, it is designed to scale to potentially massive numbers of receivers attached to a session from a single sender.Furthermore, because each individual receiver adjusts to the available bandwidth between the sender and that receiver, there is the potential to deliver data to each individual receiver at the fastest possible rate for that receiver, even in a highly heterogeneous network architecture, using a single sender.
 
RFC 3742 Limited Slow-Start for TCP with Large Congestion Windows
 
Authors:S. Floyd.
Date:March 2004
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 3742
This document describes an optional modification for TCP's slow-start for use with TCP connections with large congestion windows. For TCP connections that are able to use congestion windows of thousands (or tens of thousands) of MSS-sized segments (for MSS the sender'sMAXIMUM SEGMENT SIZE), the current slow-start procedure can result in increasing the congestion window by thousands of segments in a single round-trip time. Such an increase can easily result in thousands of packets being dropped in one round-trip time. This is often counter-productive for the TCP flow itself, and is also hard on the rest of the traffic sharing the congested link. This note describesLimited Slow-Start as an optional mechanism for limiting the number of segments by which the congestion window is increased for one window of data during slow-start, in order to improve performance forTCP connections with large congestion windows.
 
RFC 3780 SMIng - Next Generation Structure of Management Information
 
Authors:F. Strauss, J. Schoenwaelder.
Date:May 2004
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 3780
This memo defines the base SMIng (Structure of ManagementInformation, Next Generation) language. SMIng is a data definition language that provides a protocol-independent representation for management information. Separate RFCs define mappings of SMIng to specific management protocols, including SNMP.
 
RFC 3781 Next Generation Structure of Management Information (SMIng) Mappings to the Simple Network Management Protocol (SNMP)
 
Authors:F. Strauss, J. Schoenwaelder.
Date:May 2004
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 3781
SMIng (Structure of Management Information, Next Generation)(RFC3780), is a protocol-independent data definition language for management information. This memo defines an SMIng language extension that specifies the mapping of SMIng definitions of identities, classes, and their attributes and events to dedicated definitions of nodes, scalar objects, tables and columnar objects, and notifications, for application to the SNMP management framework.
 
RFC 3832 Remote Service Discovery in the Service Location Protocol (SLP) via DNS SRV
 
Authors:W. Zhao, H. Schulzrinne, E. Guttman, C. Bisdikian, W. Jerome.
Date:July 2004
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 3832
Remote service discovery refers to discovering desired services in given remote (i.e., non-local) DNS domains. This document describes remote service discovery in the Service Location Protocol (SLP) viaDNS SRV. It defines the DNS SRV Resource Records for SLP DirectoryAgent services, discusses various issues in using SLP and DNS SRV together for remote service discovery, and gives the steps for discovering desired services in remote DNS domains.
 
RFC 3926 FLUTE - File Delivery over Unidirectional Transport
 
Authors:T. Paila, M. Luby, R. Lehtonen, V. Roca, R. Walsh.
Date:October 2004
Formats:txt pdf
Obsoleted by:RFC 6726
Status:EXPERIMENTAL
DOI:10.17487/RFC 3926
This document defines FLUTE, a protocol for the unidirectional delivery of files over the Internet, which is particularly suited to multicast networks. The specification builds on Asynchronous LayeredCoding, the base protocol designed for massively scalable multicast distribution.
 
RFC 3929 Alternative Decision Making Processes for Consensus-Blocked Decisions in the IETF
 
Authors:T. Hardie.
Date:October 2004
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 3929
This document proposes an experimental set of alternative decision- making processes for use in IETF working groups. There are a small number of cases in IETF working groups in which the group has come to consensus that a particular decision must be made but cannot agree on the decision itself. This document describes alternative mechanisms for reaching a decision in those cases. This is not meant to provide an exhaustive list, but to provide a known set of tools that can be used when needed.
 
RFC 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
DOI:10.17487/RFC 3940
This document describes the messages and procedures of the Negative- acknowledgment (NACK) Oriented Reliable Multicast (NORM) protocol.This protocol is designed to provide end-to-end reliable transport of bulk data objects or streams over generic IP multicast routing and forwarding services. NORM uses a selective, negative acknowledgment mechanism for transport reliability and offers additional protocol mechanisms to allow for operation with minimal "a priori" coordination among senders and receivers. A congestion control scheme is specified to allow the NORM protocol to fairly share available network bandwidth with other transport protocols such asTransmission Control Protocol (TCP). It is capable of operating with both reciprocal multicast routing among senders and receivers and with asymmetric connectivity (possibly a unicast return path) between the senders and receivers. The protocol offers a number of features to allow different types of applications or possibly other higher level transport protocols to utilize its service in different ways.The protocol leverages the use of FEC-based repair and other IETF reliable multicast transport (RMT) building blocks in its design.
 
RFC 3941 Negative-Acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Building Blocks
 
Authors:B. Adamson, C. Bormann, M. Handley, J. Macker.
Date:November 2004
Formats:txt pdf
Obsoleted by:RFC 5401
Status:EXPERIMENTAL
DOI:10.17487/RFC 3941
This document discusses the creation of negative-acknowledgment(NACK)-oriented reliable multicast (NORM) protocols. The rationale for NORM goals and assumptions are presented. Technical challenges for NACK-oriented (and in some cases general) reliable multicast protocol operation are identified. These goals and challenges are resolved into a set of functional "building blocks" that address different aspects of NORM protocol operation. It is anticipated that these building blocks will be useful in generating different instantiations of reliable multicast protocols.
 
RFC 3951 Internet Low Bit Rate Codec (iLBC)
 
Authors:S. Andersen, A. Duric, H. Astrom, R. Hagen, W. Kleijn, J. Linden.
Date:December 2004
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 3951
This document specifies a speech codec suitable for robust voice communication over IP. The codec is developed by Global IP Sound(GIPS). It is designed for narrow band speech and results in a payload bit rate of 13.33 kbit/s for 30 ms frames and 15.20 kbit/s for 20 ms frames. The codec enables graceful speech quality degradation in the case of lost frames, which occurs in connection with lost or delayed IP packets.
 
RFC 3952 Real-time Transport Protocol (RTP) Payload Format for internet Low Bit Rate Codec (iLBC) Speech
 
Authors:A. Duric, S. Andersen.
Date:December 2004
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 3952
This document describes the Real-time Transport Protocol (RTP) payload format for the internet Low Bit Rate Codec (iLBC) Speech developed by Global IP Sound (GIPS). Also, within the document there are included necessary details for the use of iLBC with MIME andSession Description Protocol (SDP).
 
RFC 3973 Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)
 
Authors:A. Adams, J. Nicholas, W. Siadak.
Date:January 2005
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 3973
This document specifies Protocol Independent Multicast - Dense Mode(PIM-DM). PIM-DM is a multicast routing protocol that uses the underlying unicast routing information base to flood multicast datagrams to all multicast routers. Prune messages are used to prevent future messages from propagating to routers without group membership information.
 
RFC 3988 Maximum Transmission Unit Signalling Extensions for the Label Distribution Protocol
 
Authors:B. Black, K. Kompella.
Date:January 2005
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 3988
Proper functioning of RFC 1191 path Maximum Transmission Unit (MTU) discovery requires that IP routers have knowledge of the MTU for each link to which they are connected. As currently specified, the LabelDistribution Protocol (LDP) does not have the ability to signal theMTU for a Label Switched Path (LSP) to the ingress Label SwitchingRouter (LSR). In the absence of this functionality, the MTU for eachLSP must be statically configured by network operators or by equivalent off-line mechanisms.

This document specifies experimental extensions to LDP in support ofLSP MTU discovery.

 
RFC 4045 Extensions to Support Efficient Carrying of Multicast Traffic in Layer-2 Tunneling Protocol (L2TP)
 
Authors:G. Bourdon.
Date:April 2005
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 4045
The Layer Two Tunneling Protocol (L2TP) provides a method for tunneling PPP packets. This document describes an extension to L2TP, to make efficient use of L2TP tunnels within the context of deploying multicast services whose data will have to be conveyed by these tunnels.
 
RFC 4049 BinaryTime: An Alternate Format for Representing Date and Time in ASN.1
 
Authors:R. Housley.
Date:April 2005
Formats:txt pdf
Obsoleted by:RFC 6019
Status:EXPERIMENTAL
DOI:10.17487/RFC 4049
This document specifies a new ASN.1 type for representing time:BinaryTime. This document also specifies an alternate to the signing-time attribute for use with the Cryptographic Message Syntax(CMS) SignedData and AuthenticatedData content types; the binary- signing-time attribute uses BinaryTime. CMS and the signing-time attribute are defined in RFC 3852.
 
RFC 4065 Instructions for Seamoby and Experimental Mobility Protocol IANA Allocations
 
Authors:J. Kempf.
Date:July 2005
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 4065
The Seamoby Candidate Access Router Discovery (CARD) protocol and theContext Transfer Protocol (CXTP) are experimental protocols designed to accelerate IP handover between wireless access routers. These protocols require IANA allocations for ICMP type and options, StreamControl Transmission Protocol (SCTP) Payload Protocol Identifiers, port numbers, and registries for certain formatted message options.This document contains instructions to IANA about which allocations are required for the Seamoby protocols. The ICMP subtype extension format for Seamoby has been additionally designed so that it can be utilized by other experimental mobility protocols, and the SCTP port number is also available for other experimental mobility protocols.
 
RFC 4066 Candidate Access Router Discovery (CARD)
 
Authors:M. Liebsch, Ed., A. Singh, Ed., H. Chaskar, D. Funato, E. Shim.
Date:July 2005
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 4066
To enable seamless IP-layer handover of a mobile node (MN) from one access router (AR) to another, the MN is required to discover the identities and capabilities of candidate ARs (CARs) for handover prior to the initiation of the handover. The act of discovery ofCARs has two aspects: identifying the IP addresses of the CARs and finding their capabilities. This process is called "candidate access router discovery" (CARD). At the time of IP-layer handover, the CAR, whose capabilities are a good match to the preferences of the MN, is chosen as the target AR for handover. The protocol described in this document allows a mobile node to perform CARD.
 
RFC 4067 Context Transfer Protocol (CXTP)
 
Authors:J. Loughney, Ed., M. Nakhjiri, C. Perkins, R. Koodli.
Date:July 2005
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 4067
This document presents the Context Transfer Protocol (CXTP) that enables authorized context transfers. Context transfers allow better support for node based mobility so that the applications running on mobile nodes can operate with minimal disruption. Key objectives are to reduce latency and packet losses, and to avoid the re-initiation of signaling to and from the mobile node.
 
RFC 4068 Fast Handovers for Mobile IPv6
 
Authors:R. Koodli, Ed..
Date:July 2005
Formats:txt pdf
Obsoleted by:RFC 5268
Status:EXPERIMENTAL
DOI:10.17487/RFC 4068
Mobile IPv6 enables a Mobile Node to maintain its connectivity to theInternet when moving from one Access Router to another, a process referred to as handover. During handover, there is a period during which the Mobile Node is unable to send or receive packets because of link switching delay and IP protocol operations. This "handover latency" resulting from standard Mobile IPv6 procedures, namely movement detection, new Care of Address configuration, and BindingUpdate, is often unacceptable to real-time traffic such as Voice overIP. Reducing the handover latency could be beneficial to non-real- time, throughput-sensitive applications as well. This document specifies a protocol to improve handover latency due to Mobile IPv6 procedures. This document does not address improving the link switching latency.
 
RFC 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
DOI:10.17487/RFC 4125
This document provides specifications for one Bandwidth ConstraintsModel for Diffserv-aware MPLS Traffic Engineering, which is referred to as the Maximum Allocation Model.
 
RFC 4126 Max Allocation with Reservation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering & Performance Comparisons
 
Authors:J. Ash.
Date:June 2005
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 4126
This document complements the Diffserv-aware MPLS Traffic Engineering(DS-TE) requirements document by giving a functional specification for the Maximum Allocation with Reservation (MAR) BandwidthConstraints Model. Assumptions, applicability, and examples of the operation of the MAR Bandwidth Constraints Model are presented. MAR performance is analyzed relative to the criteria for selecting aBandwidth Constraints Model, in order to provide guidance to user implementation of the model in their networks.
 
RFC 4127 Russian Dolls Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering
 
Authors:F. Le Faucheur, Ed..
Date:June 2005
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 4127
This document provides specifications for one Bandwidth ConstraintsModel for Diffserv-aware MPLS Traffic Engineering, which is referred to as the Russian Dolls Model.
 
RFC 4138 Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP and the Stream Control Transmission Protocol (SCTP)
 
Authors:P. Sarolahti, M. Kojo.
Date:August 2005
Formats:txt pdf
Updated by:RFC 5682
Status:EXPERIMENTAL
DOI:10.17487/RFC 4138
Spurious retransmission timeouts cause suboptimal TCP performance because they often result in unnecessary retransmission of the last window of data. This document describes the F-RTO detection algorithm for detecting spurious TCP retransmission timeouts. F-RTO is a TCP sender-only algorithm that does not require any TCP options to operate. After retransmitting the first unacknowledged segment triggered by a timeout, the F-RTO algorithm of the TCP sender monitors the incoming acknowledgments to determine whether the timeout was spurious. It then decides whether to send new segments or retransmit unacknowledged segments. The algorithm effectively helps to avoid additional unnecessary retransmissions and thereby improves TCP performance in the case of a spurious timeout. TheF-RTO algorithm can also be applied to the Stream ControlTransmission Protocol (SCTP).
 
RFC 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
DOI:10.17487/RFC 4140
This document introduces extensions to Mobile IPv6 and IPv6 NeighbourDiscovery to allow for local mobility handling. Hierarchical mobility management for Mobile IPv6 is designed to reduce the amount of signalling between the Mobile Node, its Correspondent Nodes, and its Home Agent. The Mobility Anchor Point (MAP) described in this document can also be used to improve the performance of Mobile IPv6 in terms of handover speed.
 
RFC 4214 Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)
 
Authors:F. Templin, T. Gleeson, M. Talwar, D. Thaler.
Date:October 2005
Formats:txt pdf
Obsoleted by:RFC 5214
Status:EXPERIMENTAL
DOI:10.17487/RFC 4214
The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) connectsIPv6 hosts/routers over IPv4 networks. ISATAP views the IPv4 network as a link layer for IPv6 and views other nodes on the network as potential IPv6 hosts/routers. ISATAP supports an automatic tunneling abstraction similar to the Non-Broadcast Multiple Access (NBMA) model.
 
RFC 4316 Datatypes for Web Distributed Authoring and Versioning (WebDAV) Properties
 
Authors:J. Reschke.
Date:December 2005
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 4316
This specification extends the Web Distributed Authoring andVersioning Protocol (WebDAV) to support datatyping. Protocol elements are defined to let clients and servers specify the datatype, and to instruct the WebDAV method PROPFIND to return datatype information.
 
RFC 4324 Calendar Access Protocol (CAP)
 
Authors:D. Royer, G. Babics, S. Mansour.
Date:December 2005
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 4324
The Calendar Access Protocol (CAP) described in this memo permits aCalendar User (CU) to utilize a Calendar User Agent (CUA) to access an iCAL-based Calendar Store (CS). At the time of this writing, three vendors are implementing CAP, but it has already been determined that some changes are needed. In order to get implementation experience, the participants felt that a CAP specification is needed to preserve many years of work. Many properties in CAP which have had many years of debate, can be used by other iCalendar protocols.
 
RFC 4386 Internet X.509 Public Key Infrastructure Repository Locator Service
 
Authors:S. Boeyen, P. Hallam-Baker.
Date:February 2006
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 4386
This document defines a Public Key Infrastructure (PKI) repository locator service. The service makes use of DNS SRV records defined in accordance with RFC 2782. The service enables certificate-using systems to locate PKI repositories.
 
RFC 4389 Neighbor Discovery Proxies (ND Proxy)
 
Authors:D. Thaler, M. Talwar, C. Patel.
Date:April 2006
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 4389
Bridging multiple links into a single entity has several operational advantages. A single subnet prefix is sufficient to support multiple physical links. There is no need to allocate subnet numbers to the different networks, simplifying management. Bridging some types of media requires network-layer support, however. This document describes these cases and specifies the IP-layer support that enables bridging under these circumstances.
 
RFC 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
DOI:10.17487/RFC 4405
This memo defines an extension to the Simple Mail Transfer Protocol(SMTP) service that allows an SMTP client to specify the responsible submitter of an e-mail message. The responsible submitter is the e-mail address of the entity most recently responsible for introducing a message into the transport stream. This extension helps receiving e-mail servers efficiently determine whether the SMTP client is authorized to transmit mail on behalf of the responsible submitter's domain.
 
RFC 4406 Sender ID: Authenticating E-Mail
 
Authors:J. Lyon, M. Wong.
Date:April 2006
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 4406
Internet mail suffers from the fact that much unwanted mail is sent using spoofed addresses -- "spoofed" in this case means that the address is used without the permission of the domain owner. This document describes a family of tests by which SMTP servers can determine whether an e-mail address in a received message was used with the permission of the owner of the domain contained in that e-mail address.
 
RFC 4407 Purported Responsible Address in E-Mail Messages
 
Authors:J. Lyon.
Date:April 2006
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 4407
This document defines an algorithm by which, given an e-mail message, one can extract the identity of the party that appears to have most proximately caused that message to be delivered. This identity is called the Purported Responsible Address (PRA).
 
RFC 4408 Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1
 
Authors:M. Wong, W. Schlitt.
Date:April 2006
Formats:txt pdf
Obsoleted by:RFC 7208
Updated by:RFC 6652
Status:EXPERIMENTAL
DOI:10.17487/RFC 4408
E-mail on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction on what a sending host can use as the reverse-path of a message or the domain given on the SMTP HELO/EHLO commands. This document describes version 1 of the Sender Policy Framework (SPF) protocol, whereby a domain may explicitly authorize the hosts that are allowed to use its domain name, and a receiving host may check such authorization.
 
RFC 4410 Selectively Reliable Multicast Protocol (SRMP)
 
Authors:M. Pullen, F. Zhao, D. Cohen.
Date:February 2006
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 4410
The Selectively Reliable Multicast Protocol (SRMP) is a transport protocol, intended to deliver a mix of reliable and best-effort messages in an any-to-any multicast environment, where the best- effort traffic occurs in significantly greater volume than the reliable traffic and therefore can carry sequence numbers of reliable messages for loss detection. SRMP is intended for use in a distributed simulation application environment, where only the latest value of reliable transmission for any particular data identifier requires delivery. SRMP has two sublayers: a bundling sublayer handling message aggregation and congestion control, and aSelectively Reliable Transport (SRT) sublayer. Selection between reliable and best-effort messages is performed by the application.
 
RFC 4437 Web Distributed Authoring and Versioning (WebDAV) Redirect Reference Resources
 
Authors:J. Whitehead, G. Clemm, J. Reschke, Ed..
Date:March 2006
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 4437
This specification defines an extension to Web Distributed Authoring and Versioning (WebDAV) to allow clients to author HTTP redirect reference resources whose default response is an HTTP/1.1 3xx(Redirection) status code. A redirect reference makes it possible to access the target resourced indirectly through any URI mapped to the redirect reference resource. This specification does not address remapping of trees of resources or regular expression based redirections. There are no integrity guarantees associated with redirect reference resources. Other mechanisms can also be used to achieve the same functionality as this specification. This specification allows operators to experiment with this mechanism and develop experience on what is the best approach to the problem.
 
RFC 4471 Derivation of DNS Name Predecessor and Successor
 
Authors:G. Sisson, B. Laurie.
Date:September 2006
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 4471
This document describes two methods for deriving the canonically- ordered predecessor and successor of a DNS name. These methods may be used for dynamic NSEC resource record synthesis, enabling security-aware name servers to provide authenticated denial of existence without disclosing other owner names in a DNSSEC secured zone.
 
RFC 4478 Repeated Authentication in Internet Key Exchange (IKEv2) Protocol
 
Authors:Y. Nir.
Date:April 2006
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 4478
This document extends the Internet Key Exchange (IKEv2) Protocol document [IKEv2]. With some IPsec peers, particularly in the remote access scenario, it is desirable to repeat the mutual authentication periodically. The purpose of this is to limit the time that security associations (SAs) can be used by a third party who has gained control of the IPsec peer. This document describes a mechanism to perform this function.
 
RFC 4498 The Managed Object Aggregation MIB
 
Authors:G. Keeni.
Date:May 2006
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 4498
This memo defines a portion of the Management Information Base (MIB), the Aggregation MIB modules, for use with network management protocols in the Internet community. In particular, the AggregationMIB modules will be used to configure a network management agent to aggregate the values of a user-specified set of Managed Object instances and to service queries related to the aggregated ManagedObject instances.
 
RFC 4531 Lightweight Directory Access Protocol (LDAP) Turn Operation
 
Authors:K. Zeilenga.
Date:June 2006
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 4531
This specification describes a Lightweight Directory Access Protocol(LDAP) extended operation to reverse (or "turn") the roles of client and server for subsequent protocol exchanges in the session, or to enable each peer to act as both client and server with respect to the other.
 
RFC 4533 The Lightweight Directory Access Protocol (LDAP) Content Synchronization Operation
 
Authors:K. Zeilenga, J.H. Choi.
Date:June 2006
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 4533
This specification describes the Lightweight Directory AccessProtocol (LDAP) Content Synchronization Operation. The operation allows a client to maintain a copy of a fragment of the DirectoryInformation Tree (DIT). It supports both polling for changes and listening for changes. The operation is defined as an extension of the LDAP Search Operation.
 
RFC 4540 NEC's Simple Middlebox Configuration (SIMCO) Protocol Version 3.0
 
Authors:M. Stiemerling, J. Quittek, C. Cadar.
Date:May 2006
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 4540
This document describes a protocol for controlling middleboxes such as firewalls and network address translators. It is a fully compliant implementation of the Middlebox Communications (MIDCOM) semantics described in RFC 3989. Compared to earlier experimental versions of the SIMCO protocol, this version (3.0) uses binary message encodings in order to reduce resource requirements.
 
RFC 4620 IPv6 Node Information Queries
 
Authors:M. Crawford, B. Haberman, Ed..
Date:August 2006
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 4620
This document describes a protocol for asking an IPv6 node to supply certain network information, such as its hostname or fully-qualified domain name. IPv6 implementation experience has shown that direct queries for a hostname are useful, and a direct query mechanism for other information has been found useful in serverless environments and for debugging.
 
RFC 4624 Multicast Source Discovery Protocol (MSDP) MIB
 
Authors:B. Fenner, D. Thaler.
Date:October 2006
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 4624
This memo defines an experimental portion of the ManagementInformation Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing Multicast Source Discovery Protocol (MSDP) (RFC3618) speakers.
 
RFC 4633 Experiment in Long-Term Suspensions From Internet Engineering Task Force (IETF) Mailing Lists
 
Authors:S. Hartman.
Date:August 2006
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 4633
Discussion in the community has begun to question whether RFC 3683 and RFC 3934 provide the appropriate flexibility for managingInternet Engineering Task Force (IETF) mailing lists. This document is an RFC 3933 experiment designed to allow the community to experiment with a broader set of tools for mailing list management while trying to determine what the long-term guidelines should be.
 
RFC 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
DOI:10.17487/RFC 4653
This document specifies Non-Congestion Robustness (NCR) for TCP. In the absence of explicit congestion notification from the network, TCP uses loss as an indication of congestion. One of the ways TCP detects loss is using the arrival of three duplicate acknowledgments.However, this heuristic is not always correct, notably in the case when network paths reorder segments (for whatever reason), resulting in degraded performance. TCP-NCR is designed to mitigate this degraded performance by increasing the number of duplicate acknowledgments required to trigger loss recovery, based on the current state of the connection, in an effort to better disambiguate true segment loss from segment reordering. This document specifies the changes to TCP, as well as the costs and benefits of these modifications.
 
RFC 4654 TCP-Friendly Multicast Congestion Control (TFMCC): Protocol Specification
 
Authors:J. Widmer, M. Handley.
Date:August 2006
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 4654
This document specifies TCP-Friendly Multicast Congestion Control(TFMCC). TFMCC is a congestion control mechanism for multicast transmissions in a best-effort Internet environment. It is a single-rate congestion control scheme, where the sending rate is adapted to the receiver experiencing the worst network conditions.TFMCC is reasonably fair when competing for bandwidth with TCP flows and has a relatively low variation of throughput over time, making it suitable for applications where a relatively smooth sending rate is of importance, such as streaming media.
 
RFC 4707 Netnews Administration System (NAS)
 
Authors:P. Grau, V. Heinau, H. Schlichting, R. Schuettler.
Date:October 2006
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 4707
The Netnews Administration System (NAS) is a framework to simplify the administration and usage of network news (also known as Netnews) on the Internet. Data for the administration of newsgroups and hierarchies are kept in a distributed hierarchical database and are available through a client-server protocol.

The database is accessible by news servers, news administrators, and news readers. News servers can update their configuration automatically; administrators are able to get the data manually.News reader programs are able to get certain information from an NAS server, automatically or at a user's discretion, which provides detailed information about groups and hierarchies to the user.

NAS is usable in coexistence with the current, established process of control messages; an unwanted interference is impossible.Furthermore, NAS is able to reflect the somewhat chaotic structure ofUsenet in a hierarchical database. NAS can be used without modification of existing news relay, news server, or news reader software; however, some tasks will be better accomplished with NAS- compliant software.

 
RFC 4728 The Dynamic Source Routing Protocol (DSR) for Mobile Ad Hoc Networks for IPv4
 
Authors:D. Johnson, Y. Hu, D. Maltz.
Date:February 2007
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 4728
The Dynamic Source Routing protocol (DSR) is a simple and efficient routing protocol designed specifically for use in multi-hop wireless ad hoc networks of mobile nodes. DSR allows the network to be completely self-organizing and self-configuring, without the need for any existing network infrastructure or administration. The protocol is composed of the two main mechanisms of "Route Discovery" and"Route Maintenance", which work together to allow nodes to discover and maintain routes to arbitrary destinations in the ad hoc network.All aspects of the protocol operate entirely on demand, allowing the routing packet overhead of DSR to scale automatically to only what is needed to react to changes in the routes currently in use. The protocol allows multiple routes to any destination and allows each sender to select and control the routes used in routing its packets, for example, for use in load balancing or for increased robustness.Other advantages of the DSR protocol include easily guaranteed loop- free routing, operation in networks containing unidirectional links, use of only "soft state" in routing, and very rapid recovery when routes in the network change. The DSR protocol is designed mainly for mobile ad hoc networks of up to about two hundred nodes and is designed to work well even with very high rates of mobility. This document specifies the operation of the DSR protocol for routing unicast IPv4 packets.
 
RFC 4739 Multiple Authentication Exchanges in the Internet Key Exchange (IKEv2) Protocol
 
Authors:P. Eronen, J. Korhonen.
Date:November 2006
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 4739
The Internet Key Exchange (IKEv2) protocol supports several mechanisms for authenticating the parties, including signatures with public-key certificates, shared secrets, and ExtensibleAuthentication Protocol (EAP) methods. Currently, each endpoint uses only one of these mechanisms to authenticate itself. This document specifies an extension to IKEv2 that allows the use of multiple authentication exchanges, using either different mechanisms or the same mechanism. This extension allows, for instance, performing certificate-based authentication of the client host followed by anEAP authentication of the user. When backend authentication servers are used, they can belong to different administrative domains, such as the network access provider and the service provider.
 
RFC 4764 The EAP-PSK Protocol: A Pre-Shared Key Extensible Authentication Protocol (EAP) Method
 
Authors:F. Bersani, H. Tschofenig.
Date:January 2007
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 4764
This document specifies EAP-PSK, an Extensible AuthenticationProtocol (EAP) method for mutual authentication and session key derivation using a Pre-Shared Key (PSK). EAP-PSK provides a protected communication channel when mutual authentication is successful for both parties to communicate over. This document describes the use of this channel only for protected exchange of result indications, but future EAP-PSK extensions may use the channel for other purposes. EAP-PSK is designed for authentication over insecure networks such as IEEE 802.11.
 
RFC 4765 The Intrusion Detection Message Exchange Format (IDMEF)
 
Authors:H. Debar, D. Curry, B. Feinstein.
Date:March 2007
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 4765
The purpose of the Intrusion Detection Message Exchange Format(IDMEF) is to define data formats and exchange procedures for sharing information of interest to intrusion detection and response systems and to the management systems that may need to interact with them.

This document describes a data model to represent information exported by intrusion detection systems and explains the rationale for using this model. An implementation of the data model in theExtensible Markup Language (XML) is presented, an XML Document TypeDefinition is developed, and examples are provided.

 
RFC 4767 The Intrusion Detection Exchange Protocol (IDXP)
 
Authors:B. Feinstein, G. Matthews.
Date:March 2007
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 4767
This memo describes the Intrusion Detection Exchange Protocol (IDXP), an application-level protocol for exchanging data between intrusion detection entities. IDXP supports mutual-authentication, integrity, and confidentiality over a connection-oriented protocol. The protocol provides for the exchange of IDMEF messages, unstructured text, and binary data. The IDMEF message elements are described inRFC 4765, "The Intrusion Detection Message Exchange Format (IDMEF)", a companion document of the Intrusion Detection Exchange FormatWorking Group (IDWG) of the IETF.
 
RFC 4782 Quick-Start for TCP and IP
 
Authors:S. Floyd, M. Allman, A. Jain, P. Sarolahti.
Date:January 2007
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 4782
This document specifies an optional Quick-Start mechanism for transport protocols, in cooperation with routers, to determine an allowed sending rate at the start and, at times, in the middle of a data transfer (e.g., after an idle period). While Quick-Start is designed to be used by a range of transport protocols, in this document we only specify its use with TCP. Quick-Start is designed to allow connections to use higher sending rates when there is significant unused bandwidth along the path, and the sender and all of the routers along the path approve the Quick-Start Request.

This document describes many paths where Quick-Start Requests would not be approved. These paths include all paths containing routers,IP tunnels, MPLS paths, and the like that do not support Quick-Start. These paths also include paths with routers or middleboxes that drop packets containing IP options. Quick-Start Requests could be difficult to approve over paths that include multi-access layer- two networks. This document also describes environments where theQuick-Start process could fail with false positives, with the sender incorrectly assuming that the Quick-Start Request had been approved by all of the routers along the path. As a result of these concerns, and as a result of the difficulties and seeming absence of motivation for routers, such as core routers to deploy Quick-Start, Quick-Start is being proposed as a mechanism that could be of use in controlled environments, and not as a mechanism that would be intended or appropriate for ubiquitous deployment in the global Internet.

 
RFC 4813 OSPF Link-Local Signaling
 
Authors:B. Friedman, L. Nguyen, A. Roy, D. Yeung, A. Zinin.
Date:March 2007
Formats:txt pdf
Obsoleted by:RFC 5613
Status:EXPERIMENTAL
DOI:10.17487/RFC 4813
OSPF is a link-state intra-domain routing protocol used in IP networks. OSPF routers exchange information on a link using packets that follow a well-defined format. The format of OSPF packets is not flexible enough to enable applications to exchange arbitrary data, which may be necessary in certain situations. This memo describes a vendor-specific, backward-compatible technique to perform link-local signaling, i.e., exchange arbitrary data on a link.
 
RFC 4828 TCP Friendly Rate Control (TFRC): The Small-Packet (SP) Variant
 
Authors:S. Floyd, E. Kohler.
Date:April 2007
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 4828
This document proposes a mechanism for further experimentation, but not for widespread deployment at this time in the global Internet.

TCP-Friendly Rate Control (TFRC) is a congestion control mechanism for unicast flows operating in a best-effort Internet environment(RFC 3448). TFRC was intended for applications that use a fixed packet size, and was designed to be reasonably fair when competing for bandwidth with TCP connections using the same packet size. This document proposes TFRC-SP, a Small-Packet (SP) variant of TFRC, that is designed for applications that send small packets. The design goal for TFRC-SP is to achieve the same bandwidth in bps (bits per second) as a TCP flow using packets of up to 1500 bytes. TFRC-SP enforces a minimum interval of 10 ms between data packets to prevent a single flow from sending small packets arbitrarily frequently.

Flows using TFRC-SP compete reasonably fairly with large-packet TCP and TFRC flows in environments where large-packet flows and small- packet flows experience similar packet drop rates. However, in environments where small-packet flows experience lower packet drop rates than large-packet flows (e.g., with Drop-Tail queues in units of bytes), TFRC-SP can receive considerably more than its share of the bandwidth.

 
RFC 4843 An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID)
 
Authors:P. Nikander, J. Laganier, F. Dupont.
Date:April 2007
Formats:txt pdf
Obsoleted by:RFC 7343
Status:EXPERIMENTAL
DOI:10.17487/RFC 4843
This document introduces Overlay Routable Cryptographic HashIdentifiers (ORCHID) as a new, experimental class of IPv6-address- like identifiers. These identifiers are intended to be used as endpoint identifiers at applications and Application ProgrammingInterfaces (API) and not as identifiers for network location at theIP layer, i.e., locators. They are designed to appear as application layer entities and at the existing IPv6 APIs, but they should not appear in actual IPv6 headers. To make them more like vanilla IPv6 addresses, they are expected to be routable at an overlay level.Consequently, while they are considered non-routable addresses from the IPv6 layer point-of-view, all existing IPv6 applications are expected to be able to use them in a manner compatible with currentIPv6 addresses.

This document requests IANA to allocate a temporary prefix out of theIPv6 addressing space for Overlay Routable Cryptographic HashIdentifiers. By default, the prefix will be returned to IANA in2014, with continued use requiring IETF consensus.

 
RFC 4857 Mobile IPv4 Regional Registration
 
Authors:E. Fogelstroem, A. Jonsson, C. Perkins.
Date:June 2007
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 4857
Using Mobile IP, a mobile node registers with its home agent each time it changes care-of address. This document describes a new kind of "regional registrations", i.e., registrations local to the visited domain. The regional registrations are performed via a new network entity called a Gateway Foreign Agent (GFA) and introduce a layer of hierarchy in the visited domain. Regional registrations reduce the number of signaling messages to the home network, and reduce the signaling delay when a mobile node moves from one foreign agent to another within the same visited domain. This document is an optional extension to the Mobile IPv4 protocol.
 
RFC 4881 Low-Latency Handoffs in Mobile IPv4
 
Authors:K. El Malki, Ed..
Date:June 2007
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 4881
Mobile IPv4 describes how a Mobile Node can perform IPv4-layer handoffs between subnets served by different Foreign Agents. In certain cases, the latency involved in these handoffs can be above the threshold required for the support of delay-sensitive or real- time services. The aim of this document is to present two methods to achieve low-latency Mobile IPv4 handoffs. In addition, a combination of these two methods is described. The described techniques allow greater support for real-time services on a Mobile IPv4 network by minimizing the period of time when a Mobile Node is unable to send or receive IPv4 packets due to the delay in the Mobile IPv4 Registration process.
 
RFC 4908 Multi-homing for small scale fixed network Using Mobile IP and NEMO
 
Authors:K. Nagami, S. Uda, N. Ogashiwa, H. Esaki, R. Wakikawa, H. Ohnishi.
Date:June 2007
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 4908
Multihoming technology improves the availability of host and network connectivity. Since the behaviors of fixed and mobile networks differ, distinct architectures for each have been discussed and proposed. This document proposes a common architecture for both mobile and fixed networking environments, using mobile IP (RFC 3775) and Network Mobility (NEMO; RFC 3963). The proposed architecture requires a modification of mobile IP and NEMO so that multiple Care- of Addresses (CoAs) can be used. In addition, multiple Home Agents(HAs) that are located in different places are required for redundancy.
 
RFC 4910 Robust XML Encoding Rules (RXER) for Abstract Syntax Notation One (ASN.1)
 
Authors:S. Legg, D. Prager.
Date:July 2007
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 4910
This document defines a set of Abstract Syntax Notation One (ASN.1) encoding rules, called the Robust XML Encoding Rules or RXER, that produce an Extensible Markup Language (XML) representation for values of any given ASN.1 data type. Rules for producing a canonical RXER encoding are also defined.
 
RFC 4911 Encoding Instructions for the Robust XML Encoding Rules (RXER)
 
Authors:S. Legg.
Date:July 2007
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 4911
This document defines encoding instructions that may be used in anAbstract Syntax Notation One (ASN.1) specification to alter how ASN.1 values are encoded by the Robust XML Encoding Rules (RXER) andCanonical Robust XML Encoding Rules (CRXER), for example, to encode a component of an ASN.1 value as an Extensible Markup Language (XML) attribute rather than as a child element. Some of these encoding instructions also affect how an ASN.1 specification is translated into an Abstract Syntax Notation X (ASN.X) specification. Encoding instructions that allow an ASN.1 specification to reference definitions in other XML schema languages are also defined.
 
RFC 4912 Abstract Syntax Notation X (ASN.X)
 
Authors:S. Legg.
Date:July 2007
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 4912
Abstract Syntax Notation X (ASN.X) is a semantically equivalentExtensible Markup Language (XML) representation for Abstract SyntaxNotation One (ASN.1) specifications. ASN.X completely avoids the numerous ambiguities inherent in the ASN.1 language; therefore, specifications written in ASN.X are much easier to parse and manage than original ASN.1 specifications. ASN.X, together with the RobustXML Encoding Rules (RXER), constitutes a schema language for XML documents that offers, through other ASN.1 encoding rules, alternative compact binary encodings for XML instance documents.
 
RFC 4913 Abstract Syntax Notation X (ASN.X) Representation of Encoding Instructions for the Generic String Encoding Rules (GSER)
 
Authors:S. Legg.
Date:July 2007
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 4913
Abstract Syntax Notation X (ASN.X) is an Extensible Markup Language(XML) representation for Abstract Syntax Notation One (ASN.1) specifications. This document specifies the ASN.X representation of encoding instructions for the Generic String Encoding Rules (GSER).
 
RFC 4914 Abstract Syntax Notation X (ASN.X) Representation of Encoding Instructions for the XML Encoding Rules (XER)
 
Authors:S. Legg.
Date:July 2007
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 4914
Abstract Syntax Notation X (ASN.X) is an Extensible Markup Language(XML) representation for Abstract Syntax Notation One (ASN.1) specifications. This document specifies the ASN.X representation of encoding instructions for the XML Encoding Rules (XER).
 
RFC 4946 Atom License Extension
 
Authors:J. Snell.
Date:July 2007
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 4946
This memo defines an extension to the Atom Syndication Format for describing licenses associated with Atom feeds and entries.
 
RFC 4956 DNS Security (DNSSEC) Opt-In
 
Authors:R. Arends, M. Kosters, D. Blacka.
Date:July 2007
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 4956
In the DNS security (DNSSEC) extensions, delegations to unsigned subzones are cryptographically secured. Maintaining this cryptography is not always practical or necessary. This document describes an experimental "Opt-In" model that allows administrators to omit this cryptography and manage the cost of adopting DNSSEC with large zones.
 
RFC 4973 OSPF-xTE: Experimental Extension to OSPF for Traffic Engineering
 
Authors:P. Srisuresh, P. Joseph.
Date:July 2007
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 4973
This document defines OSPF-xTE, an experimental traffic engineering(TE) extension to the link-state routing protocol OSPF. OSPF-xTE defines new TE Link State Advertisements (LSAs) to disseminate TE metrics within an autonomous System (AS), which may consist of multiple areas. When an AS consists of TE and non-TE nodes, OSPF-xTE ensures that non-TE nodes in the AS are unaffected by the TE LSAs.OSPF-xTE generates a stand-alone TE Link State Database (TE-LSDB), distinct from the native OSPF LSDB, for computation of TE circuit paths. OSPF-xTE is versatile and extendible to non-packet networks such as Synchronous Optical Network (SONET) / Time DivisionMultiplexing (TDM) and optical networks.
 
RFC 4988 Mobile IPv4 Fast Handovers
 
Authors:R. Koodli, C. Perkins.
Date:October 2007
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 4988
This document adapts the Mobile IPv6 Fast Handovers to improve delay and packet loss resulting from Mobile IPv4 handover operations.Specifically, this document addresses movement detection, IP address configuration, and location update latencies during a handover. For reducing the IP address configuration latency, the document proposes that the new Care-of Address is always made to be the new access router's IP address.
 
RFC 5006 IPv6 Router Advertisement Option for DNS Configuration
 
Authors:J. Jeong, Ed., S. Park, L. Beloeil, S. Madanapalli.
Date:September 2007
Formats:txt pdf
Obsoleted by:RFC 6106
Status:EXPERIMENTAL
DOI:10.17487/RFC 5006
This document specifies a new IPv6 Router Advertisement option to allow IPv6 routers to advertise DNS recursive server addresses toIPv6 hosts.
 
RFC 5050 Bundle Protocol Specification
 
Authors:K. Scott, S. Burleigh.
Date:November 2007
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 5050
This document describes the end-to-end protocol, block formats, and abstract service description for the exchange of messages (bundles) in Delay Tolerant Networking (DTN).

This document was produced within the IRTF's Delay TolerantNetworking Research Group (DTNRG) and represents the consensus of all of the active contributors to this group. See http://www.dtnrg.org for more information.

 
RFC 5058 Explicit Multicast (Xcast) Concepts and Options
 
Authors:R. Boivie, N. Feldman, Y. Imai, W. Livens, D. Ooms.
Date:November 2007
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 5058
While traditional IP multicast schemes (RFC 1112) are scalable for very large multicast groups, they have scalability issues with a very large number of distinct multicast groups. This document describesXcast (Explicit Multi-unicast), a new multicast scheme with complementary scaling properties: Xcast supports a very large number of small multicast sessions. Xcast achieves this by explicitly encoding the list of destinations in the data packets, instead of using a multicast group address.

This document discusses Xcast concepts and options in several areas; it does not provide a complete technical specification.

 
RFC 5081 Using OpenPGP Keys for Transport Layer Security (TLS) Authentication
 
Authors:N. Mavrogiannopoulos.
Date:November 2007
Formats:txt pdf
Obsoleted by:RFC 6091
Status:EXPERIMENTAL
DOI:10.17487/RFC 5081
This memo proposes extensions to the Transport Layer Security (TLS) protocol to support the OpenPGP key format. The extensions discussed here include a certificate type negotiation mechanism, and the required modifications to the TLS Handshake Protocol.
 
RFC 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
DOI:10.17487/RFC 5106
This document specifies EAP-IKEv2, an Extensible AuthenticationProtocol (EAP) method that is based on the Internet Key Exchange(IKEv2) protocol. EAP-IKEv2 provides mutual authentication and session key establishment between an EAP peer and an EAP server. It supports authentication techniques that are based on passwords, high-entropy shared keys, and public key certificates. EAP-IKEv2 further provides support for cryptographic ciphersuite negotiation, hash function agility, identity confidentiality (in certain modes of operation), fragmentation, and an optional "fast reconnect" mode.
 
RFC 5111 Experiment in Exploratory Group Formation within the Internet Engineering Task Force (IETF)
 
Authors:B. Aboba, L. Dondeti.
Date:January 2008
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 5111
This document describes an RFC 3933 experiment in the Working Group formation process, known as the Exploratory Group. ExploratoryGroups may be created as the first step toward Working Group formation, or as an intermediate step between a Birds of a Feather(BOF) session and Working Group creation. Exploratory Groups are focused on completion of prerequisites for Working Group formation, and as a result they have a short life-time, with limited opportunities for milestone extension.
 
RFC 5184 Unified Layer 2 (L2) Abstractions for Layer 3 (L3)-Driven Fast Handover
 
Authors:F. Teraoka, K. Gogo, K. Mitsuya, R. Shibui, K. Mitani.
Date:May 2008
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 5184
This document proposes unified Layer 2 (L2) abstractions for Layer 3(L3)-driven fast handovers. For efficient network communication, it is vital for a protocol layer to know or utilize other layers' information, such as the form of L2 triggers. However, each protocol layer is basically designed independently. Since each protocol layer is also implemented independently in current operating systems, it is very hard to exchange control information between protocol layers.This document defines nine kinds of L2 abstractions in the form of"primitives" to achieve fast handovers in the network layer as a means of solving the problem. This mechanism is called "L3-driven fast handovers" because the network layer initiates L2 and L3 handovers by using the primitives. This document is a product of theIP Mobility Optimizations (MobOpts) Research Group.
 
RFC 5201 Host Identity Protocol
 
Authors:R. Moskowitz, P. Nikander, P. Jokela, Ed., T. Henderson.
Date:April 2008
Formats:txt pdf
Obsoleted by:RFC 7401
Updated by:RFC 6253
Status:EXPERIMENTAL
DOI:10.17487/RFC 5201
This memo specifies the details of the Host Identity Protocol (HIP).HIP allows consenting hosts to securely establish and maintain sharedIP-layer state, allowing separation of the identifier and locator roles of IP addresses, thereby enabling continuity of communications across IP address changes. HIP is based on a Sigma-compliant Diffie-Hellman key exchange, using public key identifiers from a new HostIdentity namespace for mutual peer authentication. The protocol is designed to be resistant to denial-of-service (DoS) and man-in-the- middle (MitM) attacks. When used together with another suitable security protocol, such as the Encapsulated Security Payload (ESP), it provides integrity protection and optional encryption for upper- layer protocols, such as TCP and UDP.
 
RFC 5202 Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP)
 
Authors:P. Jokela, R. Moskowitz, P. Nikander.
Date:April 2008
Formats:txt pdf
Obsoleted by:RFC 7402
Status:EXPERIMENTAL
DOI:10.17487/RFC 5202
This memo specifies an Encapsulated Security Payload (ESP) based mechanism for transmission of user data packets, to be used with theHost Identity Protocol (HIP).
 
RFC 5203 Host Identity Protocol (HIP) Registration Extension
 
Authors:J. Laganier, T. Koponen, L. Eggert.
Date:April 2008
Formats:txt pdf
Obsoleted by:RFC 8003
Status:EXPERIMENTAL
DOI:10.17487/RFC 5203
This document specifies a registration mechanism for the HostIdentity Protocol (HIP) that allows hosts to register with services, such as HIP rendezvous servers or middleboxes.
 
RFC 5204 Host Identity Protocol (HIP) Rendezvous Extension
 
Authors:J. Laganier, L. Eggert.
Date:April 2008
Formats:txt pdf
Obsoleted by:RFC 8004
Status:EXPERIMENTAL
DOI:10.17487/RFC 5204
This document defines a rendezvous extension for the Host IdentityProtocol (HIP). The rendezvous extension extends HIP and the HIP registration extension for initiating communication between HIP nodes via HIP rendezvous servers. Rendezvous servers improve reachability and operation when HIP nodes are multi-homed or mobile.
 
RFC 5205 Host Identity Protocol (HIP) Domain Name System (DNS) Extensions
 
Authors:P. Nikander, J. Laganier.
Date:April 2008
Formats:txt pdf
Obsoleted by:RFC 8005
Status:EXPERIMENTAL
DOI:10.17487/RFC 5205
This document specifies a new resource record (RR) for the DomainName System (DNS), and how to use it with the Host Identity Protocol(HIP). This RR allows a HIP node to store in the DNS its HostIdentity (HI, the public component of the node public-private key pair), Host Identity Tag (HIT, a truncated hash of its public key), and the Domain Names of its rendezvous servers (RVSs).
 
RFC 5206 End-Host Mobility and Multihoming with the Host Identity Protocol
 
Authors:P. Nikander, T. Henderson, Ed., C. Vogt, J. Arkko.
Date:April 2008
Formats:txt pdf
Obsoleted by:RFC 8046
Status:EXPERIMENTAL
DOI:10.17487/RFC 5206
This document defines mobility and multihoming extensions to the HostIdentity Protocol (HIP). Specifically, this document defines a general "LOCATOR" parameter for HIP messages that allows for a HIP host to notify peers about alternate addresses at which it may be reached. This document also defines elements of procedure for mobility of a HIP host -- the process by which a host dynamically changes the primary locator that it uses to receive packets. While the same LOCATOR parameter can also be used to support end-host multihoming, detailed procedures are left for further study.
 
RFC 5210 A Source Address Validation Architecture (SAVA) Testbed and Deployment Experience
 
Authors:J. Wu, J. Bi, X. Li, G. Ren, K. Xu, M. Williams.
Date:June 2008
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 5210
Because the Internet forwards packets according to the IP destination address, packet forwarding typically takes place without inspection of the source address and malicious attacks have been launched using spoofed source addresses. In an effort to enhance the Internet withIP source address validation, a prototype implementation of the IPSource Address Validation Architecture (SAVA) was created and an evaluation was conducted on an IPv6 network. This document reports on the prototype implementation and the test results, as well as the lessons and insights gained from experimentation.
 
RFC 5257 Internet Message Access Protocol - ANNOTATE Extension
 
Authors:C. Daboo, R. Gellens.
Date:June 2008
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 5257
The ANNOTATE extension to the Internet Message Access Protocol permits clients and servers to maintain "meta data" for messages, or individual message parts, stored in a mailbox on the server. For example, this can be used to attach comments and other useful information to a message. It is also possible to attach annotations to specific parts of a message, so that, for example, they could be marked as seen, or important, or a comment added.

Note that this document was the product of a WG that had good consensus on how to approach the problem. Nevertheless, the WG felt it did not have enough information on implementation and deployment hurdles to meet all of the requirements of a Proposed Standard. TheIETF solicits implementations and implementation reports in order to make further progress.

Implementers should be aware that this specification may change in an incompatible manner when going to Proposed Standard status. However, any incompatible changes will result in a new capability name being used to prevent problems with any deployments of the experimental extension.

 
RFC 5320 The Subnetwork Encapsulation and Adaptation Layer (SEAL)
 
Authors:F. Templin, Ed..
Date:February 2010
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 5320
For the purpose of this document, subnetworks are defined as virtual topologies that span connected network regions bounded by encapsulating border nodes. These virtual topologies may span multiple IP and/or sub-IP layer forwarding hops, and can introduce failure modes due to packet duplication and/or links with diverseMaximum Transmission Units (MTUs). This document specifies aSubnetwork Encapsulation and Adaptation Layer (SEAL) that accommodates such virtual topologies over diverse underlying link technologies.
 
RFC 5326 Licklider Transmission Protocol - Specification
 
Authors:M. Ramadas, S. Burleigh, S. Farrell.
Date:September 2008
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 5326
This document describes the Licklider Transmission Protocol (LTP), designed to provide retransmission-based reliability over links characterized by extremely long message round-trip times (RTTs) and/or frequent interruptions in connectivity. Since communication across interplanetary space is the most prominent example of this sort of environment, LTP is principally aimed at supporting "long- haul" reliable transmission in interplanetary space, but it has applications in other environments as well.

This document is a product of the Delay Tolerant Networking ResearchGroup and has been reviewed by that group. No objections to its publication as an RFC were raised.

 
RFC 5327 Licklider Transmission Protocol - Security Extensions
 
Authors:S. Farrell, M. Ramadas, S. Burleigh.
Date:September 2008
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 5327
The Licklider Transmission Protocol (LTP) is intended to serve as a reliable convergence layer over single-hop deep-space radio frequency(RF) links. LTP does Automatic Repeat reQuest (ARQ) of data transmissions by soliciting selective-acknowledgment reception reports. It is stateful and has no negotiation or handshakes. This document describes security extensions to LTP, and is part of a series of related documents describing LTP.

This document is a product of the Delay Tolerant Networking ResearchGroup and has been reviewed by that group. No objections to its publication as an RFC were raised.

 
RFC 5335 Internationalized Email Headers
 
Authors:A. Yang, Ed..
Date:September 2008
Formats:txt pdf
Obsoleted by:RFC 6532
Updates:RFC 2045, RFC 2822
Status:EXPERIMENTAL
DOI:10.17487/RFC 5335
Full internationalization of electronic mail requires not only the capabilities to transmit non-ASCII content, to encode selected information in specific header fields, and to use non-ASCII characters in envelope addresses. It also requires being able to express those addresses and the information based on them in mail header fields. This document specifies an experimental variant ofInternet mail that permits the use of Unicode encoded in UTF-8, rather than ASCII, as the base form for Internet email header field.This form is permitted in transmission only if authorized by an SMTP extension, as specified in an associated specification. This specification Updates section 6.4 of RFC 2045 to conform with the requirements.
 
RFC 5336 SMTP Extension for Internationalized Email Addresses
 
Authors:J. Yao, Ed., W. Mao, Ed..
Date:September 2008
Formats:txt pdf
Obsoleted by:RFC 6531
Updates:RFC 2821, RFC 2822, RFC 4952
Status:EXPERIMENTAL
DOI:10.17487/RFC 5336
This document specifies an SMTP extension for transport and delivery of email messages with internationalized email addresses or header information. Communication with systems that do not implement this specification is specified in another document. This document updates some syntaxes and rules defined in RFC 2821 and RFC 2822, and has some material updating RFC 4952.
 
RFC 5337 Internationalized Delivery Status and Disposition Notifications
 
Authors:C. Newman, A. Melnikov, Ed..
Date:September 2008
Formats:txt pdf
Obsoleted by:RFC 6533
Updates:RFC 3461, RFC 3462, RFC 3464, RFC 3798
Status:EXPERIMENTAL
DOI:10.17487/RFC 5337
Delivery status notifications (DSNs) are critical to the correct operation of an email system. However, the existing Draft Standards(RFC 3461, RFC 3462, RFC 3464) are presently limited to US-ASCII text in the machine-readable portions of the protocol. This specification adds a new address type for international email addresses so an original recipient address with non-US-ASCII characters can be correctly preserved even after downgrading. This also provides updated content return media types for delivery status notifications and message disposition notifications to support use of the new address type.

This document experimentally extends RFC 3461, RFC 3464, and RFC3798.

 
RFC 5338 Using the Host Identity Protocol with Legacy Applications
 
Authors:T. Henderson, P. Nikander, M. Komu.
Date:September 2008
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 5338
This document is an informative overview of how legacy applications can be made to work with the Host Identity Protocol (HIP). HIP proposes to add a cryptographic name space for network stack names.From an application viewpoint, HIP-enabled systems support a new address family of host identifiers, but it may be a long time until such HIP-aware applications are widely deployed even if host systems are upgraded. This informational document discusses implementation and Application Programming Interface (API) issues relating to usingHIP in situations in which the system is HIP-aware but the applications are not, and is intended to aid implementors and early adopters in thinking about and locally solving systems issues regarding the incremental deployment of HIP.
 
RFC 5352 Aggregate Server Access Protocol (ASAP)
 
Authors:R. Stewart, Q. Xie, M. Stillman, M. Tuexen.
Date:September 2008
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 5352
Aggregate Server Access Protocol (ASAP; RFC 5352), in conjunction with the Endpoint Handlespace Redundancy Protocol (ENRP; RFC 5353), provides a high-availability data transfer mechanism over IP networks. ASAP uses a handle-based addressing model that isolates a logical communication endpoint from its IP address(es), thus effectively eliminating the binding between the communication endpoint and its physical IP address(es), which normally constitutes a single point of failure.

In addition, ASAP defines each logical communication destination as a pool, providing full transparent support for server pooling and load sharing. It also allows dynamic system scalability -- members of a server pool can be added or removed at any time without interrupting the service.

ASAP is designed to take full advantage of the network level redundancy provided by the Stream Transmission Control Protocol(SCTP; RFC 4960). Each transport protocol, other than SCTP, MUST have an accompanying transport mapping document. It should be noted that ASAP messages passed between Pool Elements (PEs) and ENRP servers MUST use the SCTP transport protocol.

The high-availability server pooling is gained by combining two protocols, namely ASAP and ENRP, in which ASAP provides the user interface for Pool Handle to address translation, load sharing management, and fault management, while ENRP defines the high- availability Pool Handle translation service.

 
RFC 5353 Endpoint Handlespace Redundancy Protocol (ENRP)
 
Authors:Q. Xie, R. Stewart, M. Stillman, M. Tuexen, A. Silverton.
Date:September 2008
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 5353
The Endpoint Handlespace Redundancy Protocol (ENRP) is designed to work in conjunction with the Aggregate Server Access Protocol (ASAP) to accomplish the functionality of the Reliable Server Pooling(RSerPool) requirements and architecture. Within the operational scope of RSerPool, ENRP defines the procedures and message formats of a distributed, fault-tolerant registry service for storing, bookkeeping, retrieving, and distributing pool operation and membership information.
 
RFC 5354 Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace Redundancy Protocol (ENRP) Parameters
 
Authors:R. Stewart, Q. Xie, M. Stillman, M. Tuexen.
Date:September 2008
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 5354
This document details the parameters of the Aggregate Server AccessProtocol (ASAP) and Endpoint Handlespace Redundancy Protocol (ENRP) defined within the Reliable Server Pooling (RSerPool) architecture.
 
RFC 5356 Reliable Server Pooling Policies
 
Authors:T. Dreibholz, M. Tuexen.
Date:September 2008
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 5356
This document describes server pool policies for Reliable ServerPooling (RSerPool) including considerations for implementing them atEndpoint Handlespace Redundancy Protocol (ENRP) servers and pool users.
 
RFC 5449 OSPF Multipoint Relay (MPR) Extension for Ad Hoc Networks
 
Authors:E. Baccelli, P. Jacquet, D. Nguyen, T. Clausen.
Date:February 2009
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 5449
This document specifies an OSPFv3 interface type tailored for mobile ad hoc networks. This interface type is derived from the broadcast interface type, and is denoted the "OSPFv3 MANET interface type".
 
RFC 5467 GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs)
 
Authors:L. Berger, A. Takacs, D. Caviglia, D. Fedyk, J. Meuric.
Date:March 2009
Formats:txt pdf
Obsoleted by:RFC 6387
Status:EXPERIMENTAL
DOI:10.17487/RFC 5467
This document defines a method for the support of GMPLS asymmetric bandwidth bidirectional Label Switched Paths (LSPs). The presented approach is applicable to any switching technology and builds on the original Resource Reservation Protocol (RSVP) model for the transport of traffic-related parameters. The procedures described in this document are experimental.
 
RFC 5504 Downgrading Mechanism for Email Address Internationalization
 
Authors:K. Fujiwara, Ed., Y. Yoneya, Ed..
Date:March 2009
Formats:txt pdf
Obsoleted by:RFC 6530
Status:EXPERIMENTAL
DOI:10.17487/RFC 5504
Traditional mail systems handle only ASCII characters in SMTP envelope and mail header fields. The Email AddressInternationalization (UTF8SMTP) extension allows UTF-8 characters inSMTP envelope and mail header fields. To avoid rejecting internationalized email messages when a server in the delivery path does not support the UTF8SMTP extension, some sort of converting mechanism is required. This document describes a downgrading mechanism for Email Address Internationalization. Note that this is a way to downgrade, not tunnel. There is no associated up-conversion mechanism, although internationalized email clients might use original internationalized addresses or other data when displaying or replying to downgraded messages.
 
RFC 5514 IPv6 over Social Networks
 
Authors:E. Vyncke.
Date:1 April 2009
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 5514
There is a lack of IPv6 utilization in early 2009; this is partly linked to the fact that the number of IPv6 nodes is rather low. This document proposes to vastly increase the number of IPv6 hosts by transforming all Social Networking platforms into IPv6 networks.This will immediately add millions of IPv6 hosts to the existing IPv6Internet. This document includes sections on addressing and transport of IPv6 over a Social Network. A working prototype has been developed.
 
RFC 5523 OSPFv3-Based Layer 1 VPN Auto-Discovery
 
Authors:L. Berger.
Date:April 2009
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 5523
This document defines an OSPFv3-based (Open Shortest Path First version 3) Layer 1 Virtual Private Network (L1VPN) auto-discovery mechanism. This document parallels the existing OSPF version 2 L1VPN auto-discovery mechanism. The notable functional difference is the support of IPv6.
 
RFC 5525 Reliable Server Pooling MIB Module Definition
 
Authors:T. Dreibholz, J. Mulik.
Date:April 2009
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 5525
Reliable Server Pooling (RSerPool) is a framework to provide reliable server pooling. The RSerPool framework consists of two protocols:ASAP (Aggregate Server Access Protocol) and ENRP (EndpointHandlespace Redundancy Protocol). This document defines an SMIv2- compliant (Structure of Management Information Version 2) ManagementInformation Base (MIB) module providing access to managed objects in an RSerPool implementation.
 
RFC 5562 Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets
 
Authors:A. Kuzmanovic, A. Mondal, S. Floyd, K. Ramakrishnan.
Date:June 2009
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 5562
The proposal in this document is Experimental. While it may be deployed in the current Internet, it does not represent a consensus that this is the best possible mechanism for the use of ExplicitCongestion Notification (ECN) in TCP SYN/ACK packets.

This document describes an optional, experimental modification to RFC3168 to allow TCP SYN/ACK packets to be ECN-Capable. For TCP, RFC3168 specifies setting an ECN-Capable codepoint on data packets, but not on SYN and SYN/ACK packets. However, because of the high cost to the TCP transfer of having a SYN/ACK packet dropped, with the resulting retransmission timeout, this document describes the use ofECN for the SYN/ACK packet itself, when sent in response to a SYN packet with the two ECN flags set in the TCP header, indicating a willingness to use ECN. Setting the initial TCP SYN/ACK packet asECN-Capable can be of great benefit to the TCP connection, avoiding the severe penalty of a retransmission timeout for a connection that has not yet started placing a load on the network. The TCP responder(the sender of the SYN/ACK packet) must reply to a report of an ECN- marked SYN/ACK packet by resending a SYN/ACK packet that is not ECN-Capable. If the resent SYN/ACK packet is acknowledged, then the TCP responder reduces its initial congestion window from two, three, or four segments to one segment, thereby reducing the subsequent load from that connection on the network. If instead the SYN/ACK packet is dropped, or for some other reason the TCP responder does not receive an acknowledgement in the specified time, the TCP responder follows TCP standards for a dropped SYN/ACK packet (setting the retransmission timer).

 
RFC 5572 IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP)
 
Authors:M. Blanchet, F. Parent.
Date:February 2010
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 5572
A tunnel broker with the Tunnel Setup Protocol (TSP) enables the establishment of tunnels of various inner protocols, such as IPv6 orIPv4, inside various outer protocols packets, such as IPv4, IPv6, orUDP over IPv4 for IPv4 NAT traversal. The control protocol (TSP) is used by the tunnel client to negotiate the tunnel with the broker. A mobile node implementing TSP can be connected to both IPv4 and IPv6 networks whether it is on IPv4 only, IPv4 behind a NAT, or on IPv6 only. A tunnel broker may terminate the tunnels on remote tunnel servers or on itself. This document describes the TSP within the model of the tunnel broker model.
 
RFC 5573 Asynchronous Channels for the Blocks Extensible Exchange Protocol (BEEP)
 
Authors:M. Thomson.
Date:June 2009
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 5573
The Blocks Extensible Exchange Protocol (BEEP) provides a protocol framework for the development of application protocols. This document describes a BEEP feature that enables asynchrony for individual channels.
 
RFC 5614 Mobile Ad Hoc Network (MANET) Extension of OSPF Using Connected Dominating Set (CDS) Flooding
 
Authors:R. Ogier, P. Spagnolo.
Date:August 2009
Formats:txt pdf
Updated by:RFC 7038
Status:EXPERIMENTAL
DOI:10.17487/RFC 5614
This document specifies an extension of OSPFv3 to support mobile ad hoc networks (MANETs). The extension, called OSPF-MDR, is designed as a new OSPF interface type for MANETs. OSPF-MDR is based on the selection of a subset of MANET routers, consisting of MANETDesignated Routers (MDRs) and Backup MDRs. The MDRs form a connected dominating set (CDS), and the MDRs and Backup MDRs together form a biconnected CDS for robustness. This CDS is exploited in two ways.First, to reduce flooding overhead, an optimized flooding procedure is used in which only (Backup) MDRs flood new link state advertisements (LSAs) back out the receiving interface; reliable flooding is ensured by retransmitting LSAs along adjacencies.Second, adjacencies are formed only between (Backup) MDRs and a subset of their neighbors, allowing for much better scaling in dense networks. The CDS is constructed using 2-hop neighbor information provided in a Hello protocol extension. The Hello protocol is further optimized by allowing differential Hellos that report only changes in neighbor states. Options are specified for originating router-LSAs that provide full or partial topology information, allowing overhead to be reduced by advertising less topology information.
 
RFC 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, RFC 8311
Status:EXPERIMENTAL
DOI:10.17487/RFC 5622
This document specifies a profile for Congestion Control Identifier4, the small-packet variant of TCP-Friendly Rate Control (TFRC), in the Datagram Congestion Control Protocol (DCCP). CCID 4 is for experimental use, and uses TFRC-SP (RFC 4828), a variant of TFRC designed for applications that send small packets. CCID 4 is considered experimental because TFRC-SP is itself experimental, and is not proposed for widespread deployment in the global Internet at this time. The goal for TFRC-SP is to achieve roughly the same bandwidth in bits per second (bps) as a TCP flow using packets of up to 1500 bytes but experiencing the same level of congestion. CCID 4 is for use for senders that send small packets and would like a TCP- friendly sending rate, possibly with Explicit Congestion Notification(ECN), while minimizing abrupt rate changes.
 
RFC 5634 Quick-Start for the Datagram Congestion Control Protocol (DCCP)
 
Authors:G. Fairhurst, A. Sathiaseelan.
Date:August 2009
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 5634
This document specifies the use of the Quick-Start mechanism by theDatagram Congestion Control Protocol (DCCP). DCCP is a transport protocol that allows the transmission of congestion-controlled, unreliable datagrams. DCCP is intended for applications such as streaming media, Internet telephony, and online games. In DCCP, an application has a choice of congestion control mechanisms, each specified by a Congestion Control Identifier (CCID). This document specifies general procedures applicable to all DCCP CCIDs and specific procedures for the use of Quick-Start with DCCP CCID 2, CCID3, and CCID 4. Quick-Start enables a DCCP sender to cooperate withQuick-Start routers along the end-to-end path to determine an allowed sending rate at the start of a connection and, at times, in the middle of a DCCP connection (e.g., after an idle or application- limited period). The present specification is provided for use in controlled environments, and not as a mechanism that would be intended or appropriate for ubiquitous deployment in the globalInternet.
 
RFC 5636 Traceable Anonymous Certificate
 
Authors:S. Park, H. Park, Y. Won, J. Lee, S. Kent.
Date:August 2009
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 5636
This document defines a practical architecture and protocols for offering privacy for a user who requests and uses an X.509 certificate containing a pseudonym, while still retaining the ability to map such a certificate to the real user who requested it. The architecture is compatible with IETF certificate request formats such as PKCS10 (RFC 2986) and CMC (RFC 5272). The architecture separates the authorities involved in issuing a certificate: one for verifying ownership of a private key (Blind Issuer) and the other for validating the contents of a certificate (Anonymity Issuer). The end entity (EE) certificates issued under this model are called TraceableAnonymous Certificates (TACs).
 
RFC 5697 Other Certificates Extension
 
Authors:S. Farrell.
Date:November 2009
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 5697
Some applications that associate state information with public key certificates can benefit from a way to link together a set of certificates that belong to the same end entity and that can safely be considered equivalent to one another for the purposes of referencing that application-state information. This memo defines a certificate extension that allows applications to establish the required linkage without introducing a new application protocol data unit.
 
RFC 5721 POP3 Support for UTF-8
 
Authors:R. Gellens, C. Newman.
Date:February 2010
Formats:txt pdf
Obsoleted by:RFC 6856
Status:EXPERIMENTAL
DOI:10.17487/RFC 5721
This specification extends the Post Office Protocol version 3 (POP3) to support un-encoded international characters in user names, passwords, mail addresses, message headers, and protocol-level textual error strings.
 
RFC 5726 Mobile IPv6 Location Privacy Solutions
 
Authors:Y. Qiu, F. Zhao, Ed., R. Koodli.
Date:February 2010
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 5726
Mobile IPv6 (RFC 3775) enables a mobile node to remain reachable while it roams on the Internet. However, the location and movement of the mobile node can be revealed by the IP addresses used in signaling or data packets. In this document, we consider the MobileIPv6 location privacy problem described in RFC 4882, and propose efficient and secure techniques to protect location privacy of the mobile node. This document is a product of the IP MobilityOptimizations (MobOpts) Research Group.
 
RFC 5738 IMAP Support for UTF-8
 
Authors:P. Resnick, C. Newman.
Date:March 2010
Formats:txt pdf
Obsoleted by:RFC 6855
Updates:RFC 3501
Status:EXPERIMENTAL
DOI:10.17487/RFC 5738
This specification extends the Internet Message Access Protocol version 4rev1 (IMAP4rev1) to support UTF-8 encoded international characters in user names, mail addresses, and message headers.
 
RFC 5739 IPv6 Configuration in Internet Key Exchange Protocol Version 2 (IKEv2)
 
Authors:P. Eronen, J. Laganier, C. Madson.
Date:February 2010
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 5739
When Internet Key Exchange Protocol version 2 (IKEv2) is used for remote VPN access (client to VPN gateway), the gateway assigns the client an IP address from the internal network using IKEv2 configuration payloads. The configuration payloads specified in RFC4306 work well for IPv4 but make it difficult to use certain features of IPv6. This document specifies new configuration attributes forIKEv2 that allows the VPN gateway to assign IPv6 prefixes to clients, enabling all features of IPv6 to be used with the client-gateway"virtual link".
 
RFC 5747 4over6 Transit Solution Using IP Encapsulation and MP-BGP Extensions
 
Authors:J. Wu, Y. Cui, X. Li, M. Xu, C. Metz.
Date:March 2010
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 5747
The emerging and growing deployment of IPv6 networks will introduce cases where connectivity with IPv4 networks crossing IPv6 transit backbones is desired. This document describes a mechanism for automatic discovery and creation of IPv4-over-IPv6 tunnels via extensions to multiprotocol BGP. It is targeted at connecting islands of IPv4 networks across an IPv6-only backbone without the need for a manually configured overlay of tunnels. The mechanisms described in this document have been implemented, tested, and deployed on the large research IPv6 network in China.
 
RFC 5770 Basic Host Identity Protocol (HIP) Extensions for Traversal of Network Address Translators
 
Authors:M. Komu, T. Henderson, H. Tschofenig, J. Melen, A. Keranen, Ed..
Date:April 2010
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 5770
This document specifies extensions to the Host Identity Protocol(HIP) to facilitate Network Address Translator (NAT) traversal. The extensions are based on the use of the Interactive ConnectivityEstablishment (ICE) methodology to discover a working path between two end-hosts, and on standard techniques for encapsulatingEncapsulating Security Payload (ESP) packets within the User DatagramProtocol (UDP). This document also defines elements of a procedure for NAT traversal, including the optional use of a HIP relay server.With these extensions HIP is able to work in environments that haveNATs and provides a generic NAT traversal solution to higher-layer networking applications.
 
RFC 5776 Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols
 
Authors:V. Roca, A. Francillon, S. Faurite.
Date:April 2010
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 5776
This document details the Timed Efficient Stream Loss-TolerantAuthentication (TESLA) packet source authentication and packet integrity verification protocol and its integration within theAsynchronous Layered Coding (ALC) and NACK-Oriented ReliableMulticast (NORM) content delivery protocols. This document only considers the authentication/integrity verification of the packets generated by the session's sender. The authentication and integrity verification of the packets sent by receivers, if any, is out of the scope of this document.
 
RFC 5780 NAT Behavior Discovery Using Session Traversal Utilities for NAT (STUN)
 
Authors:D. MacDonald, B. Lowekamp.
Date:May 2010
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 5780
This specification defines an experimental usage of the SessionTraversal Utilities for NAT (STUN) Protocol that discovers the presence and current behavior of NATs and firewalls between the STUN client and the STUN server.
 
RFC 5787 OSPFv2 Routing Protocols Extensions for Automatically Switched Optical Network (ASON) Routing
 
Authors:D. Papadimitriou.
Date:March 2010
Formats:txt pdf
Obsoleted by:RFC 6827
Status:EXPERIMENTAL
DOI:10.17487/RFC 5787
The ITU-T has defined an architecture and requirements for operating an Automatically Switched Optical Network (ASON).

The Generalized Multiprotocol Label Switching (GMPLS) protocol suite is designed to provide a control plane for a range of network technologies including optical networks such as time division multiplexing (TDM) networks including SONET/SDH and Optical TransportNetworks (OTNs), and lambda switching optical networks.

The requirements for GMPLS routing to satisfy the requirements ofASON routing, and an evaluation of existing GMPLS routing protocols are provided in other documents. This document defines extensions to the OSPFv2 Link State Routing Protocol to meet the requirements for routing in an ASON.

Note that this work is scoped to the requirements and evaluation expressed in RFC 4258 and RFC 4652 and the ITU-T Recommendations current when those documents were written. Future extensions of revisions of this work may be necessary if the ITU-T Recommendations are revised or if new requirements are introduced into a revision ofRFC 4258.

 
RFC 5805 Lightweight Directory Access Protocol (LDAP) Transactions
 
Authors:K. Zeilenga.
Date:March 2010
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 5805
Lightweight Directory Access Protocol (LDAP) update operations, such as Add, Delete, and Modify operations, have atomic, consistency, isolation, durability (ACID) properties. Each of these update operations act upon an entry. It is often desirable to update two or more entries in a single unit of interaction, a transaction.Transactions are necessary to support a number of applications including resource provisioning. This document extends LDAP to support transactions.
 
RFC 5820 Extensions to OSPF to Support Mobile Ad Hoc Networking
 
Authors:A. Roy, Ed., M. Chandra, Ed..
Date:March 2010
Formats:txt pdf
Updated by:RFC 7137
Status:EXPERIMENTAL
DOI:10.17487/RFC 5820
This document describes extensions to OSPF to support mobile ad hoc networks (MANETs). The extensions, called OSPF-OR (OSPF-OverlappingRelay), include mechanisms for link-local signaling (LLS), an OSPF-MANET interface, a simple technique to reduce the size of Hello packets by only transmitting incremental state changes, and a method for optimized flooding of routing updates. OSPF-OR also provides a means to reduce unnecessary adjacencies to support larger MANETs.
 
RFC 5825 Displaying Downgraded Messages for Email Address Internationalization
 
Authors:K. Fujiwara, B. Leiba.
Date:April 2010
Formats:txt pdf
Obsoleted by:RFC 6530
Status:EXPERIMENTAL
DOI:10.17487/RFC 5825
This document describes a method for displaying downgraded messages that originally contained internationalized email addresses or internationalized header fields.
 
RFC 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
DOI:10.17487/RFC 5827
This document proposes a new mechanism for TCP and Stream ControlTransmission Protocol (SCTP) that can be used to recover lost segments when a connection's congestion window is small. The "EarlyRetransmit" mechanism allows the transport to reduce, in certain special circumstances, the number of duplicate acknowledgments required to trigger a fast retransmission. This allows the transport to use fast retransmit to recover segment losses that would otherwise require a lengthy retransmission timeout.
 
RFC 5842 Binding Extensions to Web Distributed Authoring and Versioning (WebDAV)
 
Authors:G. Clemm, J. Crawford, J. Reschke, Ed., J. Whitehead.
Date:April 2010
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 5842
This specification defines bindings, and the BIND method for creating multiple bindings to the same resource. Creating a new binding to a resource causes at least one new URI to be mapped to that resource.Servers are required to ensure the integrity of any bindings that they allow to be created.
 
RFC 5873 Pre-Authentication Support for the Protocol for Carrying Authentication for Network Access (PANA)
 
Authors:Y. Ohba, A. Yegin.
Date:May 2010
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 5873
This document defines an extension to the Protocol for CarryingAuthentication for Network Access (PANA) for proactively establishing a PANA Security Association between a PANA Client in one access network and a PANA Authentication Agent in another access network to which the PANA Client may move.
 
RFC 5878 Transport Layer Security (TLS) Authorization Extensions
 
Authors:M. Brown, R. Housley.
Date:May 2010
Formats:txt pdf
Updates:RFC 5246
Updated by:RFC 8447
Status:EXPERIMENTAL
DOI:10.17487/RFC 5878
This document specifies authorization extensions to the TransportLayer Security (TLS) Handshake Protocol. Extensions are carried in the client and server hello messages to confirm that both parties support the desired authorization data types. Then, if supported by both the client and the server, authorization information, such as attribute certificates (ACs) or Security Assertion Markup Language(SAML) assertions, is exchanged in the supplemental data handshake message.
 
RFC 5924 Extended Key Usage (EKU) for Session Initiation Protocol (SIP) X.509 Certificates
 
Authors:S. Lawrence, V. Gurbani.
Date:June 2010
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 5924
This memo documents an extended key usage (EKU) X.509 certificate extension for restricting the applicability of a certificate to use with a Session Initiation Protocol (SIP) service. As such, in addition to providing rules for SIP implementations, this memo also provides guidance to issuers of certificates for use with SIP.
 
RFC 5971 GIST: General Internet Signalling Transport
 
Authors:H. Schulzrinne, R. Hancock.
Date:October 2010
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 5971
This document specifies protocol stacks for the routing and transport of per-flow signalling messages along the path taken by that flow through the network. The design uses existing transport and security protocols under a common messaging layer, the General InternetSignalling Transport (GIST), which provides a common service for diverse signalling applications. GIST does not handle signalling application state itself, but manages its own internal state and the configuration of the underlying transport and security protocols to enable the transfer of messages in both directions along the flow path. The combination of GIST and the lower layer transport and security protocols provides a solution for the base protocol component of the "Next Steps in Signalling" (NSIS) framework.
 
RFC 5973 NAT/Firewall NSIS Signaling Layer Protocol (NSLP)
 
Authors:M. Stiemerling, H. Tschofenig, C. Aoun, E. Davies.
Date:October 2010
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 5973
This memo defines the NSIS Signaling Layer Protocol (NSLP) forNetwork Address Translators (NATs) and firewalls. This NSLP allows hosts to signal on the data path for NATs and firewalls to be configured according to the needs of the application data flows. For instance, it enables hosts behind NATs to obtain a publicly reachable address and hosts behind firewalls to receive data traffic. The overall architecture is given by the framework and requirements defined by the Next Steps in Signaling (NSIS) working group. The network scenarios, the protocol itself, and examples for path-coupled signaling are given in this memo.
 
RFC 5974 NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling
 
Authors:J. Manner, G. Karagiannis, A. McDonald.
Date:October 2010
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 5974
This specification describes the NSIS Signaling Layer Protocol (NSLP) for signaling Quality of Service (QoS) reservations in the Internet.It is in accordance with the framework and requirements developed inNSIS. Together with General Internet Signaling Transport (GIST), it provides functionality similar to RSVP and extends it. The QoS NSLP is independent of the underlying QoS specification or architecture and provides support for different reservation models. It is simplified by the elimination of support for multicast flows. This specification explains the overall protocol approach, describes the design decisions made, and provides examples. It specifies object, message formats, and processing rules.
 
RFC 5975 QSPEC Template for the Quality-of-Service NSIS Signaling Layer Protocol (NSLP)
 
Authors:G. Ash, Ed., A. Bader, Ed., C. Kappler, Ed., D. Oran, Ed..
Date:October 2010
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 5975
The Quality-of-Service (QoS) NSIS signaling layer protocol (NSLP) is used to signal QoS reservations and is independent of a specific QoS model (QOSM) such as IntServ or Diffserv. Rather, all information specific to a QOSM is encapsulated in a separate object, the QSPEC.This document defines a template for the QSPEC including a number ofQSPEC parameters. The QSPEC parameters provide a common language to be reused in several QOSMs and thereby aim to ensure the extensibility and interoperability of QoS NSLP. While the base protocol is QOSM-agnostic, the parameters that can be carried in theQSPEC object are possibly closely coupled to specific models. The node initiating the NSIS signaling adds an Initiator QSPEC, which indicates the QSPEC parameters that must be interpreted by the downstream nodes less the reservation fails, thereby ensuring the intention of the NSIS initiator is preserved along the signaling path.
 
RFC 5976 Y.1541-QOSM: Model for Networks Using Y.1541 Quality-of-Service Classes
 
Authors:G. Ash, A. Morton, M. Dolly, P. Tarapore, C. Dvorak, Y. El Mghazli.
Date:October 2010
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 5976
This document describes a QoS-NSLP Quality-of-Service model (QOSM) based on ITU-T Recommendation Y.1541 Network QoS Classes and related guidance on signaling. Y.1541 specifies 8 classes of NetworkPerformance objectives, and the Y.1541-QOSM extensions include additional QSPEC parameters and QOSM processing guidelines.
 
RFC 5977 RMD-QOSM: The NSIS Quality-of-Service Model for Resource Management in Diffserv
 
Authors:A. Bader, L. Westberg, G. Karagiannis, C. Kappler, T. Phelan.
Date:October 2010
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 5977
This document describes a Next Steps in Signaling (NSIS) Quality-of-Service (QoS) Model for networks that use the Resource Management inDiffserv (RMD) concept. RMD is a technique for adding admission control and preemption function to Differentiated Services (Diffserv) networks. The RMD QoS Model allows devices external to the RMD network to signal reservation requests to Edge nodes in the RMD network. The RMD Ingress Edge nodes classify the incoming flows into traffic classes and signals resource requests for the corresponding traffic class along the data path to the Egress Edge nodes for each flow. Egress nodes reconstitute the original requests and continue forwarding them along the data path towards the final destination.In addition, RMD defines notification functions to indicate overload situations within the domain to the Edge nodes.
 
RFC 5979 NSIS Operation over IP Tunnels
 
Authors:C. Shen, H. Schulzrinne, S. Lee, J. Bang.
Date:March 2011
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 5979
NSIS Quality of Service (QoS) signaling enables applications to perform QoS reservation along a data flow path. When the data flow path contains IP tunnel segments, NSIS QoS signaling has no effect within those tunnel segments. Therefore, the resulting tunnel segments could become the weakest QoS link and invalidate the QoS efforts in the rest of the end-to-end path. The problem with NSIS signaling within the tunnel is caused by the tunnel encapsulation that masks packets' original IP header fields. Those original IP header fields are needed to intercept NSIS signaling messages and classify QoS data packets. This document defines a solution to this problem by mapping end-to-end QoS session requests to correspondingQoS sessions in the tunnel, thus extending the end-to-end QoS signaling into the IP tunnel segments.
 
RFC 5981 Authorization for NSIS Signaling Layer Protocols
 
Authors:J. Manner, M. Stiemerling, H. Tschofenig, R. Bless, Ed..
Date:February 2011
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 5981
Signaling layer protocols specified within the Next Steps inSignaling (NSIS) framework may rely on the General Internet SignalingTransport (GIST) protocol to handle authorization. Still, the signaling layer protocol above GIST itself may require separate authorization to be performed when a node receives a request for a certain kind of service or resources. This document presents a generic model and object formats for session authorization within theNSIS signaling layer protocols. The goal of session authorization is to allow the exchange of information between network elements in order to authorize the use of resources for a service and to coordinate actions between the signaling and transport planes.
 
RFC 5983 Mailing Lists and Internationalized Email Addresses
 
Authors:R. Gellens.
Date:October 2010
Formats:txt pdf
Obsoleted by:RFC 6783
Status:EXPERIMENTAL
DOI:10.17487/RFC 5983
This document describes considerations for mailing lists with the introduction of internationalized email addresses.

This document makes some specific recommendations on how mailing lists should act in various situations.

 
RFC 5984 Increasing Throughput in IP Networks with ESP-Based Forwarding: ESPBasedForwarding
 
Authors:K-M. Moller.
Date:1 April 2011
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 5984
This document proposes an experimental way of reaching infinite bandwidth in IP networks by the use of ESP-based forwarding.
 
RFC 6023 A Childless Initiation of the Internet Key Exchange Version 2 (IKEv2) Security Association (SA)
 
Authors:Y. Nir, H. Tschofenig, H. Deng, R. Singh.
Date:October 2010
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6023
This document describes an extension to the Internet Key Exchange version 2 (IKEv2) protocol that allows an IKEv2 Security Association(SA) to be created and authenticated without generating a Child SA.
 
RFC 6028 Host Identity Protocol (HIP) Multi-Hop Routing Extension
 
Authors:G. Camarillo, A. Keranen.
Date:October 2010
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6028
This document specifies two extensions to the Host Identity Protocol(HIP) to implement multi-hop routing. The first extension allows implementing source routing in HIP. That is, a node sending a HIP packet can define a set of nodes that the HIP packet should traverse.The second extension allows a HIP packet to carry and record the list of nodes that forwarded it.
 
RFC 6058 Transient Binding for Proxy Mobile IPv6
 
Authors:M. Liebsch, Ed., A. Muhanna, O. Blume.
Date:March 2011
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6058
This document specifies a mechanism that enhances Proxy Mobile IPv6 protocol signaling to support the creation of a transient binding cache entry that is used to optimize the performance of dual radio handover, as well as single radio handover. This mechanism is applicable to the mobile node's inter-MAG (Mobility Access Gateway) handover while using a single interface or different interfaces. The handover problem space using the Proxy Mobile IPv6 base protocol is analyzed and the use of transient binding cache entries at the local mobility anchor is described. The specified extension to the ProxyMobile IPv6 protocol ensures optimized forwarding of downlink as well as uplink packets between mobile nodes and the network infrastructure and avoids superfluous packet forwarding delay or even packet loss.
 
RFC 6069 Making TCP More Robust to Long Connectivity Disruptions (TCP-LCD)
 
Authors:A. Zimmermann, A. Hannemann.
Date:December 2010
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6069
Disruptions in end-to-end path connectivity, which last longer than one retransmission timeout, cause suboptimal TCP performance. The reason for this performance degradation is that TCP interprets segment loss induced by long connectivity disruptions as a sign of congestion, resulting in repeated retransmission timer backoffs.This, in turn, leads to a delayed detection of the re-establishment of the connection since TCP waits for the next retransmission timeout before it attempts a retransmission.

This document proposes an algorithm to make TCP more robust to long connectivity disruptions (TCP-LCD). It describes how standard ICMP messages can be exploited during timeout-based loss recovery to disambiguate true congestion loss from non-congestion loss caused by connectivity disruptions. Moreover, a reversion strategy of the retransmission timer is specified that enables a more prompt detection of whether or not the connectivity to a previously disconnected peer node has been restored. TCP-LCD is a TCP sender- only modification that effectively improves TCP performance in the case of connectivity disruptions.

 
RFC 6078 Host Identity Protocol (HIP) Immediate Carriage and Conveyance of Upper-Layer Protocol Signaling (HICCUPS)
 
Authors:G. Camarillo, J. Melen.
Date:January 2011
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6078
This document defines a new Host Identity Protocol (HIP) packet type called DATA. HIP DATA packets are used to reliably convey authenticated arbitrary protocol messages over various overlay networks.
 
RFC 6079 HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking Environment (BONE)
 
Authors:G. Camarillo, P. Nikander, J. Hautakorpi, A. Keranen, A. Johnston.
Date:January 2011
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6079
This document specifies a framework to build HIP-based (Host IdentityProtocol) overlay networks. This framework uses HIP to perform connection management. Other functions, such as data storage and retrieval or overlay maintenance, are implemented using protocols other than HIP. These protocols are loosely referred to as "peer protocols".
 
RFC 6084 General Internet Signaling Transport (GIST) over Stream Control Transmission Protocol (SCTP) and Datagram Transport Layer Security (DTLS)
 
Authors:X. Fu, C. Dickmann, J. Crowcroft.
Date:January 2011
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6084
The General Internet Signaling Transport (GIST) protocol currently uses TCP or Transport Layer Security (TLS) over TCP for Connection mode operation. This document describes the usage of GIST over theStream Control Transmission Protocol (SCTP) and Datagram TransportLayer Security (DTLS).
 
RFC 6095 Extending YANG with Language Abstractions
 
Authors:B. Linowski, M. Ersue, S. Kuryla.
Date:March 2011
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6095
YANG -- the Network Configuration Protocol (NETCONF) Data ModelingLanguage -- supports modeling of a tree of data elements that represent the configuration and runtime status of a particular network element managed via NETCONF. This memo suggests enhancingYANG with supplementary modeling features and language abstractions with the aim to improve the model extensibility and reuse.
 
RFC 6126 The Babel Routing Protocol
 
Authors:J. Chroboczek.
Date:April 2011
Formats:txt pdf
Updated by:RFC 7298, RFC 7557
Status:EXPERIMENTAL
DOI:10.17487/RFC 6126
Babel is a loop-avoiding distance-vector routing protocol that is robust and efficient both in ordinary wired networks and in wireless mesh networks.
 
RFC 6137 The Network Trouble Ticket Data Model (NTTDM)
 
Authors:D. Zisiadis, Ed., S. Kopsidas, Ed., M. Tsavli, Ed., G. Cessieux, Ed..
Date:February 2011
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6137
Handling multiple sets of network trouble tickets (TTs) originating from different participants' inter-connected network environments poses a series of challenges for the involved institutions. A Grid is a good example of such a multi-domain project. Each of the participants follows different procedures for handling trouble in its domain, according to the local technical and linguistic profile. TheTT systems of the participants collect, represent, and disseminate TT information in different formats.

As a result, management of the daily workload by a central NetworkOperation Centre (NOC) is a challenge on its own. Normalization ofTTs to a common format at the central NOC can ease presentation, storing, and handling of the TTs. In the present document, we provide a model for automating the collection and normalization of the TT received by multiple networks forming the Grid. Each of the participants is using its home TT system within its domain for handling trouble incidents, whereas the central NOC is gathering the tickets in the normalized format for repository and handling. XML is used as the common representation language. The model was defined and used as part of the networking support activity of the EGEE(Enabling Grids for E-sciencE) project.

 
RFC 6179 The Internet Routing Overlay Network (IRON)
 
Authors:F. Templin, Ed..
Date:March 2011
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6179
Since the Internet must continue to support escalating growth due to increasing demand, it is clear that current routing architectures and operational practices must be updated. This document proposes anInternet Routing Overlay Network (IRON) that supports sustainable growth while requiring no changes to end systems and no changes to the existing routing system. IRON further addresses other important issues including routing scaling, mobility management, multihoming, traffic engineering and NAT traversal. While business considerations are an important determining factor for widespread adoption, they are out of scope for this document. This document is a product of theIRTF Routing Research Group.
 
RFC 6197 Location-to-Service Translation (LoST) Service List Boundary Extension
 
Authors:K. Wolf.
Date:April 2011
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6197
Location-to-Service Translation (LoST) maps service identifiers and location information to service contact URIs. If a LoST client wants to discover available services for a particular location, it will perform a <listServicesByLocation&rt; query to the LoST server.However, the LoST server, in its response, does not provide context information; that is, it does not provide any additional information about the geographical region within which the returned list of services is considered valid. Therefore, this document defines aService List Boundary that returns a local context along with the list of services returned, in order to assist the client in not missing a change in available services when moving.
 
RFC 6210 Experiment: Hash Functions with Parameters in the Cryptographic Message Syntax (CMS) and S/MIME
 
Authors:J. Schaad.
Date:April 2011
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6210
New hash algorithms are being developed that may include parameters.Cryptographic Message Syntax (CMS) has not currently defined any hash algorithms with parameters, but anecdotal evidence suggests that defining one could cause major problems. This document defines just such an algorithm and describes how to use it so that experiments can be run to find out how bad including hash parameters will be.
 
RFC 6217 Regional Broadcast Using an Atmospheric Link Layer
 
Authors:T. Ritter.
Date:1 April 2011
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6217
Broadcasting is a technology that has been largely discarded in favor of technologies like multicast. This document builds on RFC 919 and describes a more efficient routing mechanism for broadcast packets destined for multiple Local Area Networks (LANs) or Metropolitan AreaNetworks (MANs) using an alternative link layer. It significantly reduces congestion on network equipment and does not require additional physical infrastructure investment.
 
RFC 6235 IP Flow Anonymization Support
 
Authors:E. Boschi, B. Trammell.
Date:May 2011
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6235
This document describes anonymization techniques for IP flow data and the export of anonymized data using the IP Flow Information Export(IPFIX) protocol. It categorizes common anonymization schemes and defines the parameters needed to describe them. It provides guidelines for the implementation of anonymized data export and storage over IPFIX, and describes an information model and Options- based method for anonymization metadata export within the IPFIX protocol or storage in IPFIX Files.
 
RFC 6237 IMAP4 Multimailbox SEARCH Extension
 
Authors:B. Leiba, A. Melnikov.
Date:May 2011
Formats:txt pdf
Obsoleted by:RFC 7377
Updates:RFC 4466
Status:EXPERIMENTAL
DOI:10.17487/RFC 6237
The IMAP4 specification allows the searching of only the selected mailbox. A user often wants to search multiple mailboxes, and a client that wishes to support this must issue a series of SELECT andSEARCH commands, waiting for each to complete before moving on to the next. This extension allows a client to search multiple mailboxes with one command, limiting the round trips and waiting for various searches to complete, and not requiring disruption of the currently selected mailbox. This extension also uses MAILBOX and TAG fields inESEARCH responses, allowing a client to pipeline the searches if it chooses. This document updates RFC 4466.
 
RFC 6253 Host Identity Protocol Certificates
 
Authors:T. Heer, S. Varjonen.
Date:May 2011
Formats:txt pdf
Obsoleted by:RFC 8002
Updates:RFC 5201
Status:EXPERIMENTAL
DOI:10.17487/RFC 6253
The Certificate (CERT) parameter is a container for digital certificates. It is used for carrying these certificates in HostIdentity Protocol (HIP) control packets. This document specifies theCERT parameter and the error signaling in case of a failed verification. Additionally, this document specifies the representations of Host Identity Tags in X.509 version 3 (v3) andSimple Public Key Infrastructure (SPKI) certificates.

The concrete use of certificates, including how certificates are obtained, requested, and which actions are taken upon successful or failed verification, is specific to the scenario in which the certificates are used. Hence, the definition of these scenario- specific aspects is left to the documents that use the CERT parameter.

This document updates RFC 5201.

 
RFC 6257 Bundle Security Protocol Specification
 
Authors:S. Symington, S. Farrell, H. Weiss, P. Lovell.
Date:May 2011
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6257
This document defines the bundle security protocol, which provides data integrity and confidentiality services for the Bundle Protocol.Separate capabilities are provided to protect the bundle payload and additional data that may be included within the bundle. We also describe various security considerations including some policy options.

This document is a product of the Delay-Tolerant Networking ResearchGroup and has been reviewed by that group. No objections to its publication as an RFC were raised.

 
RFC 6258 Delay-Tolerant Networking Metadata Extension Block
 
Authors:S. Symington.
Date:May 2011
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6258
This document defines an extension block that may be used with theDelay-Tolerant Networking (DTN) Bundle Protocol. This MetadataExtension Block is designed to carry additional information that DTN nodes can use to make processing decisions regarding bundles, such as deciding whether to store a bundle or determining to which nodes to forward a bundle. The metadata that is carried in a metadata block must be formatted according to the metadata type that is identified in the block's metadata type field. One specific metadata type, for carrying URIs as metadata, is defined in this document. Other metadata types may be defined in separate documents. This document is a product of the Delay Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as anRFC were raised.
 
RFC 6259 Delay-Tolerant Networking Previous-Hop Insertion Block
 
Authors:S. Symington.
Date:May 2011
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6259
This document defines an extension block for use with the Delay-Tolerant Networking (DTN) Bundle Protocol. This Previous-HopInsertion Block (PHIB) extension block is designed to be inserted by a forwarding node to provide the endpoint identifier (EID) of an endpoint of which the forwarding node is a member so that this EID may be conveyed to the next-hop receiving node. Knowledge of an EID of an endpoint of which a previous-hop node is a member may be required in some circumstances to support certain routing protocols(e.g., flood routing). If this EID cannot be provided by the convergence layer or other means, the PHIB defines the mechanism whereby the EID can be provided with the bundle. Each PHIB is always removed from the bundle by the receiving node so that its presence within the bundle is limited to exactly one hop. This document defines the format and processing of this PHIB. This document is a product of the Delay-Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised.
 
RFC 6260 Compressed Bundle Header Encoding (CBHE)
 
Authors:S. Burleigh.
Date:May 2011
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6260
This document describes a convention by which Delay-TolerantNetworking (DTN) Bundle Protocol (BP) "convergence-layer" adapters may represent endpoint identifiers in a compressed form within the primary blocks of bundles, provided those endpoint identifiers conform to the structure prescribed by this convention.

Compressed Bundle Header Encoding (CBHE) compression is a convergence-layer adaptation. It is opaque to bundle processing.Therefore, it has no impact on the interoperability of differentBundle Protocol implementations, but instead affects only the interoperability of different convergence-layer adaptation implementations.

This document is a product of the Delay-Tolerant Networking ResearchGroup and has been reviewed by that group. No objections to its publication as an RFC were raised.

 
RFC 6261 Encrypted Signaling Transport Modes for the Host Identity Protocol
 
Authors:A. Keranen.
Date:May 2011
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6261
This document specifies two transport modes for Host IdentityProtocol (HIP) signaling messages that allow them to be conveyed over encrypted connections initiated with the Host Identity Protocol.
 
RFC 6296 IPv6-to-IPv6 Network Prefix Translation
 
Authors:M. Wasserman, F. Baker.
Date:June 2011
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6296
This document describes a stateless, transport-agnostic IPv6-to-IPv6Network Prefix Translation (NPTv6) function that provides the address-independence benefit associated with IPv4-to-IPv4 NAT(NAPT44) and provides a 1:1 relationship between addresses in the"inside" and "outside" prefixes, preserving end-to-end reachability at the network layer.
 
RFC 6306 Hierarchical IPv4 Framework
 
Authors:P. Frejborg.
Date:July 2011
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6306
This document describes a framework for how the current IPv4 address space can be divided into two new address categories: a core address space (Area Locators, ALOCs) that is globally unique, and an edge address space (Endpoint Locators, ELOCs) that is regionally unique.In the future, the ELOC space will only be significant in a private network or in a service provider domain. Therefore, a 32x32 bit addressing scheme and a hierarchical routing architecture are achieved. The hierarchical IPv4 framework is backwards compatible with the current IPv4 Internet.

This document also discusses a method for decoupling the location and identifier functions -- future applications can make use of the separation. The framework requires extensions to the existing DomainName System (DNS), the existing IPv4 stack of the endpoints, middleboxes, and routers in the Internet. The framework can be implemented incrementally for endpoints, DNS, middleboxes, and routers.

 
RFC 6317 Basic Socket Interface Extensions for the Host Identity Protocol (HIP)
 
Authors:M. Komu, T. Henderson.
Date:July 2011
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6317
This document defines extensions to the current sockets API for theHost Identity Protocol (HIP). The extensions focus on the use of public-key-based identifiers discovered via DNS resolution, but also define interfaces for manual bindings between Host Identity Tags(HITs) and locators. With the extensions, the application can also support more relaxed security models where communication can be non-HIP-based, according to local policies. The extensions in this document are experimental and provide basic tools for further experimentation with policies.
 
RFC 6346 The Address plus Port (A+P) Approach to the IPv4 Address Shortage
 
Authors:R. Bush, Ed..
Date:August 2011
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6346
We are facing the exhaustion of the IANA IPv4 free IP address pool.Unfortunately, IPv6 is not yet deployed widely enough to fully replace IPv4, and it is unrealistic to expect that this is going to change before the depletion of IPv4 addresses. Letting hosts seamlessly communicate in an IPv4 world without assigning a unique globally routable IPv4 address to each of them is a challenging problem.

This document proposes an IPv4 address sharing scheme, treating some of the port number bits as part of an extended IPv4 address (Address plus Port, or A+P). Instead of assigning a single IPv4 address to a single customer device, we propose to extend the address field by using bits from the port number range in the TCP/UDP header as additional endpoint identifiers, thus leaving a reduced range of ports available to applications. This means assigning the same IPv4 address to multiple clients (e.g., Customer Premises Equipment (CPE), mobile phones), each with its assigned port range. In the face ofIPv4 address exhaustion, the need for addresses is stronger than the need to be able to address thousands of applications on a single host. If address translation is needed, the end-user should be in control of the translation process -- not some smart boxes in the core.

 
RFC 6356 Coupled Congestion Control for Multipath Transport Protocols
 
Authors:C. Raiciu, M. Handley, D. Wischik.
Date:October 2011
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6356
Often endpoints are connected by multiple paths, but communications are usually restricted to a single path per connection. Resource usage within the network would be more efficient were it possible for these multiple paths to be used concurrently. Multipath TCP is a proposal to achieve multipath transport in TCP.

New congestion control algorithms are needed for multipath transport protocols such as Multipath TCP, as single path algorithms have a series of issues in the multipath context. One of the prominent problems is that running existing algorithms such as standard TCP independently on each path would give the multipath flow more than its fair share at a bottleneck link traversed by more than one of its subflows. Further, it is desirable that a source with multiple paths available will transfer more traffic using the least congested of the paths, achieving a property called "resource pooling" where a bundle of links effectively behaves like one shared link with bigger capacity. This would increase the overall efficiency of the network and also its robustness to failure.

This document presents a congestion control algorithm that couples the congestion control algorithms running on different subflows by linking their increase functions, and dynamically controls the overall aggressiveness of the multipath flow. The result is a practical algorithm that is fair to TCP at bottlenecks while moving traffic away from congested links.

 
RFC 6358 Additional Master Secret Inputs for TLS
 
Authors:P. Hoffman.
Date:January 2012
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6358
This document describes a mechanism for using additional master secret inputs with Transport Layer Security (TLS) and Datagram TLS(DTLS).
 
RFC 6451 Location-to-Service Translation (LoST) Protocol Extensions
 
Authors:A. Forte, H. Schulzrinne.
Date:December 2011
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6451
An important class of location-based services answers the question,"What instances of this service are closest to me?" Examples include finding restaurants, gas stations, stores, automated teller machines, wireless access points (hot spots), or parking spaces. Currently, the Location-to-Service Translation (LoST) protocol only supports mapping locations to a single service based on service regions. This document describes an extension that allows queries of the type "N nearest", "within distance X", and "served by".
 
RFC 6496 Secure Proxy ND Support for SEcure Neighbor Discovery (SEND)
 
Authors:S. Krishnan, J. Laganier, M. Bonola, A. Garcia-Martinez.
Date:February 2012
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6496
SEcure Neighbor Discovery (SEND) specifies a method for securingNeighbor Discovery (ND) signaling against specific threats. As defined today, SEND assumes that the node sending an ND message is the owner of the address from which the message is sent and/or possesses a key that authorizes the node to act as a router, so that it is in possession of the private key or keys used to generate the digital signature on each message. This means that the Proxy ND signaling performed by nodes that do not possess knowledge of the address owner's private key and/or knowledge of a router's key cannot be secured using SEND. This document extends the current SEND specification in order to secure Proxy ND operation.
 
RFC 6521 Home Agent-Assisted Route Optimization between Mobile IPv4 Networks
 
Authors:A. Makela, J. Korhonen.
Date:February 2012
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6521
This document describes a home agent-assisted route optimization functionality for the IPv4 Network Mobility Protocol. The function is designed to facilitate optimal routing in cases where all nodes are connected to a single home agent; thus, the use case is route optimization within a single organization or similar entity. The functionality enables the discovery of eligible peer nodes (based on information received from the home agent) and their network prefixes, and the establishment of a direct tunnel between such nodes.
 
RFC 6537 Host Identity Protocol Distributed Hash Table Interface
 
Authors:J. Ahrenholz.
Date:February 2012
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6537
This document specifies a common interface for using the HostIdentity Protocol (HIP) with a Distributed Hash Table (DHT) service to provide a name-to-Host-Identity-Tag lookup service and a Host-Identity-Tag-to-address lookup service.
 
RFC 6541 DomainKeys Identified Mail (DKIM) Authorized Third-Party Signatures
 
Authors:M. Kucherawy.
Date:February 2012
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6541
This experimental specification proposes a modification to DomainKeysIdentified Mail (DKIM) allowing advertisement of third-party signature authorizations that are to be interpreted as equivalent to a signature added by the administrative domain of the message's author.
 
RFC 6559 A Reliable Transport Mechanism for PIM
 
Authors:D. Farinacci, IJ. Wijnands, S. Venaas, M. Napierala.
Date:March 2012
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6559
This document defines a reliable transport mechanism for the PIM protocol for transmission of Join/Prune messages. This eliminates the need for periodic Join/Prune message transmission and processing.The reliable transport mechanism can use either TCP or SCTP as the transport protocol.
 
RFC 6593 Service Undiscovery Using Hide-and-Go-Seek for the Domain Pseudonym System (DPS)
 
Authors:C. Pignataro, J. Clarke, G. Salgueiro.
Date:1 April 2012
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6593
With the ubiquitous success of service discovery techniques, curious clients are faced with an increasing overload of service instances and options listed when they browse for services. A typical domain may contain web servers, remote desktop servers, printers, file servers, video content servers, automatons, Points of Presence using artificial intelligence, etc., all advertising their presence.Unsurprisingly, it is expected that some protocols and services will choose the comfort of anonymity and avoid discovery.

This memo describes a new experimental protocol for this purpose utilizing the Domain Pseudonym System (DPS), and discusses strategies for its successful implementation and deployment.

 
RFC 6601 Generic Connection Admission Control (GCAC) Algorithm Specification for IP/MPLS Networks
 
Authors:G. Ash, Ed., D. McDysan.
Date:April 2012
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6601
This document presents a generic connection admission control (GCAC) reference model and algorithm for IP-/MPLS-based networks. Service provider (SP) IP/MPLS networks need an MPLS GCAC mechanism, as one motivational example, to reject Voice over IP (VoIP) calls when additional calls would adversely affect calls already in progress.Without MPLS GCAC, connections on congested links will suffer degraded quality. The MPLS GCAC algorithm can be optionally implemented in vendor equipment and deployed by service providers.MPLS GCAC interoperates between vendor equipment and across multiple service provider domains. The MPLS GCAC algorithm uses available standard mechanisms for MPLS-based networks, such as RSVP, Diffserv- aware MPLS Traffic Engineering (DS-TE), Path Computation Element(PCE), Next Steps in Signaling (NSIS), Diffserv, and OSPF. The MPLSGCAC algorithm does not include aspects of CAC that might be considered vendor proprietary implementations, such as detailed path selection mechanisms. MPLS GCAC functions are implemented in a distributed manner to deliver the objective Quality of Service (QoS) for specified QoS constraints. The objective is that the source is able to compute a source route with high likelihood that via-elements along the selected path will in fact admit the request. In some cases (e.g., multiple Autonomous Systems (ASes)), this objective cannot always be met, but this document summarizes methods that partially meet this objective. MPLS GCAC is applicable to any service or flow that must meet an objective QoS (delay, jitter, packet loss rate) for a specified quantity of traffic.
 
RFC 6613 RADIUS over TCP
 
Authors:A. DeKok.
Date:May 2012
Formats:txt pdf
Updated by:RFC 7930
Status:EXPERIMENTAL
DOI:10.17487/RFC 6613
The Remote Authentication Dial-In User Server (RADIUS) protocol has, until now, required the User Datagram Protocol (UDP) as the underlying transport layer. This document defines RADIUS over theTransmission Control Protocol (RADIUS/TCP), in order to address handling issues related to RADIUS over Transport Layer Security(RADIUS/TLS). It permits TCP to be used as a transport protocol forRADIUS only when a transport layer such as TLS or IPsec provides confidentiality and security.
 
RFC 6614 Transport Layer Security (TLS) Encryption for RADIUS
 
Authors:S. Winter, M. McCauley, S. Venaas, K. Wierenga.
Date:May 2012
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6614
This document specifies a transport profile for RADIUS usingTransport Layer Security (TLS) over TCP as the transport protocol.This enables dynamic trust relationships between RADIUS servers.
 
RFC 6617 Secure Pre-Shared Key (PSK) Authentication for the Internet Key Exchange Protocol (IKE)
 
Authors:D. Harkins.
Date:June 2012
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6617
This memo describes a secure pre-shared key (PSK) authentication method for the Internet Key Exchange Protocol (IKE). It is resistant to dictionary attack and retains security even when used with weak pre-shared keys.
 
RFC 6618 Mobile IPv6 Security Framework Using Transport Layer Security for Communication between the Mobile Node and Home Agent
 
Authors:J. Korhonen, Ed., B. Patil, H. Tschofenig, D. Kroeselberg.
Date:May 2012
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6618
Mobile IPv6 signaling between a Mobile Node (MN) and its Home Agent(HA) is secured using IPsec. The security association (SA) between an MN and the HA is established using Internet Key Exchange Protocol(IKE) version 1 or 2. The security model specified for Mobile IPv6, which relies on IKE/IPsec, requires interaction between the MobileIPv6 protocol component and the IKE/IPsec module of the IP stack.This document proposes an alternate security framework for MobileIPv6 and Dual-Stack Mobile IPv6, which relies on Transport LayerSecurity for establishing keying material and other bootstrapping parameters required to protect Mobile IPv6 signaling and data traffic between the MN and HA.
 
RFC 6621 Simplified Multicast Forwarding
 
Authors:J. Macker, Ed..
Date:May 2012
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6621
This document describes a Simplified Multicast Forwarding (SMF) mechanism that provides basic Internet Protocol (IP) multicast forwarding suitable for limited wireless mesh and mobile ad hoc network (MANET) use. It is mainly applicable in situations where efficient flooding represents an acceptable engineering design trade- off. It defines techniques for multicast duplicate packet detection(DPD), to be applied in the forwarding process, for both IPv4 andIPv6 protocol use. This document also specifies optional mechanisms for using reduced relay sets to achieve more efficient multicast data distribution within a mesh topology as compared to Classic Flooding.Interactions with other protocols, such as use of information provided by concurrently running unicast routing protocols or interaction with other multicast protocols, as well as multiple deployment approaches are also described. Distributed algorithms for selecting reduced relay sets and related discussion are provided in the appendices. Basic issues relating to the operation of multicastMANET border routers are discussed, but ongoing work remains in this area and is beyond the scope of this document.
 
RFC 6628 Efficient Augmented Password-Only Authentication and Key Exchange for IKEv2
 
Authors:S. Shin, K. Kobara.
Date:June 2012
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6628
This document describes an efficient augmented password-only authentication and key exchange (AugPAKE) protocol where a user remembers a low-entropy password and its verifier is registered in the intended server. In general, the user password is chosen from a small set of dictionary words that allows an attacker to perform exhaustive searches (i.e., off-line dictionary attacks). The AugPAKE protocol described here is secure against passive attacks, active attacks, and off-line dictionary attacks (on the obtained messages with passive/active attacks), and also provides resistance to server compromise (in the context of augmented PAKE security). In addition, this document describes how the AugPAKE protocol is integrated into the Internet Key Exchange Protocol version 2 (IKEv2).
 
RFC 6631 Password Authenticated Connection Establishment with the Internet Key Exchange Protocol version 2 (IKEv2)
 
Authors:D. Kuegler, Y. Sheffer.
Date:June 2012
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6631
The Internet Key Exchange protocol version 2 (IKEv2) does not allow secure peer authentication when using short credential strings, i.e., passwords. Several proposals have been made to integrate password- authentication protocols into IKE. This document provides an adaptation of Password Authenticated Connection Establishment (PACE) to the setting of IKEv2 and demonstrates the advantages of this integration.
 
RFC 6661 Pre-Congestion Notification (PCN) Boundary-Node Behavior for the Controlled Load (CL) Mode of Operation
 
Authors:A. Charny, F. Huang, G. Karagiannis, M. Menth, T. Taylor, Ed..
Date:July 2012
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6661
Pre-Congestion Notification (PCN) is a means for protecting the quality of service for inelastic traffic admitted to a Diffserv domain. The overall PCN architecture is described in RFC 5559. This memo is one of a series describing possible boundary-node behaviors for a PCN-domain. The behavior described here is that for a form of measurement-based load control using three PCN marking states: not- marked, threshold-marked, and excess-traffic-marked. This behavior is known informally as the Controlled Load (CL) PCN-boundary-node behavior.
 
RFC 6662 Pre-Congestion Notification (PCN) Boundary-Node Behavior for the Single Marking (SM) Mode of Operation
 
Authors:A. Charny, J. Zhang, G. Karagiannis, M. Menth, T. Taylor, Ed..
Date:July 2012
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6662
Pre-Congestion Notification (PCN) is a means for protecting the quality of service for inelastic traffic admitted to a Diffserv domain. The overall PCN architecture is described in RFC 5559. This memo is one of a series describing possible boundary-node behaviors for a PCN-domain. The behavior described here is that for a form of measurement-based load control using two PCN marking states: not- marked and excess-traffic-marked. This behavior is known informally as the Single Marking (SM) PCN-boundary-node behavior.
 
RFC 6693 Probabilistic Routing Protocol for Intermittently Connected Networks
 
Authors:A. Lindgren, A. Doria, E. Davies, S. Grasic.
Date:August 2012
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6693
This document is a product of the Delay Tolerant Networking ResearchGroup and has been reviewed by that group. No objections to its publication as an RFC were raised.

This document defines PRoPHET, a Probabilistic Routing Protocol usingHistory of Encounters and Transitivity. PRoPHET is a variant of the epidemic routing protocol for intermittently connected networks that operates by pruning the epidemic distribution tree to minimize resource usage while still attempting to achieve the best-case routing capabilities of epidemic routing. It is intended for use in sparse mesh networks where there is no guarantee that a fully connected path between the source and destination exists at any time, rendering traditional routing protocols unable to deliver messages between hosts. These networks are examples of networks where there is a disparity between the latency requirements of applications and the capabilities of the underlying network (networks often referred to as delay and disruption tolerant). The document presents an architectural overview followed by the protocol specification.

 
RFC 6706 Asymmetric Extended Route Optimization (AERO)
 
Authors:F. Templin, Ed..
Date:August 2012
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6706
Nodes attached to common multi-access link types (e.g., multicast- capable, shared media, non-broadcast multiple access (NBMA), etc.) can exchange packets as neighbors on the link, but they may not always be provisioned with sufficient routing information for optimal neighbor selection. Such nodes should therefore be able to discover a trusted intermediate router on the link that provides both forwarding services to reach off-link destinations and redirection services to inform the node of an on-link neighbor that is closer to the final destination. This redirection can provide a useful route optimization, since the triangular path from the ingress link neighbor, to the intermediate router, and finally to the egress link neighbor may be considerably longer than the direct path from ingress to egress. However, ordinary redirection may lead to operational issues on certain link types and/or in certain deployment scenarios.This document therefore introduces an Asymmetric Extended RouteOptimization (AERO) capability that addresses the issues.
 
RFC 6739 Synchronizing Service Boundaries and Elements Based on the Location-to-Service Translation (LoST) Protocol
 
Authors:H. Schulzrinne, H. Tschofenig.
Date:October 2012
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6739
The Location-to-Service Translation (LoST) protocol is an XML-based protocol for mapping service identifiers and geodetic or civic location information to service URIs and service boundaries. In particular, it can be used to determine the location-appropriatePublic Safety Answering Point (PSAP) for emergency services.

The <mapping&rt; element in the LoST protocol specification encapsulates information about service boundaries and circumscribes the region within which all locations map to the same service Uniform ResourceIdentifier (URI) or set of URIs for a given service.

This document defines an XML protocol to exchange these mappings between two nodes. This mechanism is designed for the exchange of authoritative <mapping&rt; elements between two entities. Exchanging cached <mapping&rt; elements, i.e., non-authoritative elements, is possible but not envisioned. Even though the <mapping&rt; element format is reused from the LoST specification, the mechanism in this document can be used without the LoST protocol.

 
RFC 6740 Identifier-Locator Network Protocol (ILNP) Architectural Description
 
Authors:RJ Atkinson, SN Bhatti.
Date:November 2012
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6740
This document provides an architectural description and the concept of operations for the Identifier-Locator Network Protocol (ILNP), which is an experimental, evolutionary enhancement to IP. This is a product of the IRTF Routing Research Group.
 
RFC 6741 Identifier-Locator Network Protocol (ILNP) Engineering Considerations
 
Authors:RJ Atkinson, SN Bhatti.
Date:November 2012
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6741
This document describes common (i.e., version independent) engineering details for the Identifier-Locator Network Protocol(ILNP), which is an experimental, evolutionary enhancement to IP.This document is a product of the IRTF Routing Research Group.
 
RFC 6742 DNS Resource Records for the Identifier-Locator Network Protocol (ILNP)
 
Authors:RJ Atkinson, SN Bhatti, S. Rose.
Date:November 2012
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6742
This note describes additional optional resource records for use with the Domain Name System (DNS). These optional resource records are for use with the Identifier-Locator Network Protocol (ILNP). This document is a product of the IRTF Routing Research Group.
 
RFC 6743 ICMP Locator Update Message for the Identifier-Locator Network Protocol for IPv6 (ILNPv6)
 
Authors:RJ Atkinson, SN Bhatti.
Date:November 2012
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6743
This note specifies an experimental ICMPv6 message type used with theIdentifier-Locator Network Protocol (ILNP). The Identifier-LocatorNetwork Protocol (ILNP) is an experimental, evolutionary enhancement to IP. This message is used to dynamically update Identifier/Locator bindings for an existing ILNP session. This is a product of the IRTFRouting Research Group.
 
RFC 6744 IPv6 Nonce Destination Option for the Identifier-Locator Network Protocol for IPv6 (ILNPv6)
 
Authors:RJ Atkinson, SN Bhatti.
Date:November 2012
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6744
The Identifier-Locator Network Protocol (ILNP) is an experimental, evolutionary enhancement to IP. ILNP has multiple instantiations.This document describes an experimental Nonce Destination Option used only with ILNP for IPv6 (ILNPv6). This document is a product of theIRTF Routing Research Group.
 
RFC 6745 ICMP Locator Update Message for the Identifier-Locator Network Protocol for IPv4 (ILNPv4)
 
Authors:RJ Atkinson, SN Bhatti.
Date:November 2012
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6745
This note defines an experimental ICMP message type for IPv4 used with the Identifier-Locator Network Protocol (ILNP). ILNP is an experimental, evolutionary enhancement to IP. The ICMP message defined herein is used to dynamically update Identifier/Locator bindings for an existing ILNP session. This is a product of the IRTFRouting Research Group.
 
RFC 6746 IPv4 Options for the Identifier-Locator Network Protocol (ILNP)
 
Authors:RJ Atkinson, SN Bhatti.
Date:November 2012
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6746
This document defines two new IPv4 Options that are used only with the Identifier-Locator Network Protocol for IPv4 (ILNPv4). ILNP is an experimental, evolutionary enhancement to IP. This document is a product of the IRTF Routing Research Group.
 
RFC 6747 Address Resolution Protocol (ARP) for the Identifier-Locator Network Protocol for IPv4 (ILNPv4)
 
Authors:RJ Atkinson, SN Bhatti.
Date:November 2012
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6747
This document defines an Address Resolution Protocol (ARP) extension to support the Identifier-Locator Network Protocol for IPv4 (ILNPv4).ILNP is an experimental, evolutionary enhancement to IP. This document is a product of the IRTF Routing Research Group.
 
RFC 6748 Optional Advanced Deployment Scenarios for the Identifier-Locator Network Protocol (ILNP)
 
Authors:RJ Atkinson, SN Bhatti.
Date:November 2012
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6748
This document provides an Architectural description and the Concept of Operations of some optional advanced deployment scenarios for theIdentifier-Locator Network Protocol (ILNP), which is an evolutionary enhancement to IP. None of the functions described here is required for the use or deployment of ILNP. Instead, it offers descriptions of engineering and deployment options that might provide either enhanced capability or convenience in administration or management ofILNP-based systems.
 
RFC 6751 Native IPv6 behind IPv4-to-IPv4 NAT Customer Premises Equipment (6a44)
 
Authors:R. Despres, Ed., B. Carpenter, D. Wing, S. Jiang.
Date:October 2012
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6751
In customer sites having IPv4-only Customer Premises Equipment (CPE),Teredo (RFC 4380, RFC 5991, RFC 6081) provides last-resort IPv6 connectivity. However, because it is designed to work without the involvement of Internet Service Providers, it has significant limitations (connectivity between IPv6 native addresses and Teredo addresses is uncertain; connectivity between Teredo addresses fails for some combinations of NAT types). 6a44 is a complementary solution that, being based on ISP cooperation, avoids these limitations. At the beginning of 6a44 IPv6 addresses, it replaces the Teredo well-known prefix, present at the beginning of Teredo IPv6 addresses, with network-specific /48 prefixes assigned by local ISPs(an evolution similar to that from 6to4 to 6rd (IPv6 Rapid Deployment on IPv4 Infrastructures)). The specification is expected to be complete enough for running code to be independently written and the solution to be incrementally deployed and used.
 
RFC 6807 Population Count Extensions to Protocol Independent Multicast (PIM)
 
Authors:D. Farinacci, G. Shepherd, S. Venaas, Y. Cai.
Date:December 2012
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6807
This specification defines a method for providing multicast distribution-tree accounting data. Simple extensions to the ProtocolIndependent Multicast (PIM) protocol allow a rough approximation of tree-based data in a scalable fashion.
 
RFC 6817 Low Extra Delay Background Transport (LEDBAT)
 
Authors:S. Shalunov, G. Hazel, J. Iyengar, M. Kuehlewind.
Date:December 2012
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6817
Low Extra Delay Background Transport (LEDBAT) is an experimental delay-based congestion control algorithm that seeks to utilize the available bandwidth on an end-to-end path while limiting the consequent increase in queueing delay on that path. LEDBAT uses changes in one-way delay measurements to limit congestion that the flow itself induces in the network. LEDBAT is designed for use by background bulk-transfer applications to be no more aggressive than standard TCP congestion control (as specified in RFC 5681) and to yield in the presence of competing flows, thus limiting interference with the network performance of competing flows.
 
RFC 6824 TCP Extensions for Multipath Operation with Multiple Addresses
 
Authors:A. Ford, C. Raiciu, M. Handley, O. Bonaventure.
Date:January 2013
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6824
TCP/IP communication is currently restricted to a single path per connection, yet multiple paths often exist between peers. The simultaneous use of these multiple paths for a TCP/IP session would improve resource usage within the network and, thus, improve user experience through higher throughput and improved resilience to network failure.

Multipath TCP provides the ability to simultaneously use multiple paths between peers. This document presents a set of extensions to traditional TCP to support multipath operation. The protocol offers the same type of service to applications as TCP (i.e., reliable bytestream), and it provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths.

 
RFC 6830 The Locator/ID Separation Protocol (LISP)
 
Authors:D. Farinacci, V. Fuller, D. Meyer, D. Lewis.
Date:January 2013
Formats:txt pdf
Updated by:RFC 8113
Status:EXPERIMENTAL
DOI:10.17487/RFC 6830
This document describes a network-layer-based protocol that enables separation of IP addresses into two new numbering spaces: EndpointIdentifiers (EIDs) and Routing Locators (RLOCs). No changes are required to either host protocol stacks or to the "core" of theInternet infrastructure. The Locator/ID Separation Protocol (LISP) can be incrementally deployed, without a "flag day", and offersTraffic Engineering, multihoming, and mobility benefits to early adopters, even when there are relatively few LISP-capable sites.

Design and development of LISP was largely motivated by the problem statement produced by the October 2006 IAB Routing and AddressingWorkshop.

 
RFC 6831 The Locator/ID Separation Protocol (LISP) for Multicast Environments
 
Authors:D. Farinacci, D. Meyer, J. Zwiebel, S. Venaas.
Date:January 2013
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6831
This document describes how inter-domain multicast routing will function in an environment where Locator/ID Separation is deployed using the Locator/ID Separation Protocol (LISP) architecture.
 
RFC 6832 Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites
 
Authors:D. Lewis, D. Meyer, D. Farinacci, V. Fuller.
Date:January 2013
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6832
This document describes techniques for allowing sites running theLocator/ID Separation Protocol (LISP) to interoperate with Internet sites that may be using either IPv4, IPv6, or both but that are not running LISP. A fundamental property of LISP-speaking sites is that they use Endpoint Identifiers (EIDs), rather than traditional IP addresses, in the source and destination fields of all traffic they emit or receive. While EIDs are syntactically identical to IPv4 orIPv6 addresses, normally routes to them are not carried in the global routing system, so an interoperability mechanism is needed for non-LISP-speaking sites to exchange traffic with LISP-speaking sites.This document introduces three such mechanisms. The first uses a new network element, the LISP Proxy Ingress Tunnel Router (Proxy-ITR), to act as an intermediate LISP Ingress Tunnel Router (ITR) for non-LISP- speaking hosts. Second, this document adds Network AddressTranslation (NAT) functionality to LISP ITRs and LISP Egress TunnelRouters (ETRs) to substitute routable IP addresses for non-routableEIDs. Finally, this document introduces the Proxy Egress TunnelRouter (Proxy-ETR) to handle cases where a LISP ITR cannot send packets to non-LISP sites without encapsulation.
 
RFC 6833 Locator/ID Separation Protocol (LISP) Map-Server Interface
 
Authors:V. Fuller, D. Farinacci.
Date:January 2013
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6833
This document describes the Mapping Service for the Locator/IDSeparation Protocol (LISP), implemented by two new types of LISP- speaking devices -- the LISP Map-Resolver and LISP Map-Server -- that provides a simplified "front end" for one or more Endpoint ID toRouting Locator mapping databases.

By using this service interface and communicating with Map-Resolvers and Map-Servers, LISP Ingress Tunnel Routers and Egress TunnelRouters are not dependent on the details of mapping database systems, which facilitates experimentation with different database designs.Since these devices implement the "edge" of the LISP infrastructure, connect directly to LISP-capable Internet end sites, and comprise the bulk of LISP-speaking devices, reducing their implementation and operational complexity should also reduce the overall cost and effort of deploying LISP.

 
RFC 6834 Locator/ID Separation Protocol (LISP) Map-Versioning
 
Authors:L. Iannone, D. Saucez, O. Bonaventure.
Date:January 2013
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6834
This document describes the LISP (Locator/ID Separation Protocol)Map-Versioning mechanism, which provides in-packet information aboutEndpoint ID to Routing Locator (EID-to-RLOC) mappings used to encapsulate LISP data packets. The proposed approach is based on associating a version number to EID-to-RLOC mappings and the transport of such a version number in the LISP-specific header ofLISP-encapsulated packets. LISP Map-Versioning is particularly useful to inform communicating Ingress Tunnel Routers (ITRs) andEgress Tunnel Routers (ETRs) about modifications of the mappings used to encapsulate packets. The mechanism is transparent to implementations not supporting this feature, since in the LISP- specific header and in the Map Records, bits used for Map-Versioning can be safely ignored by ITRs and ETRs that do not support the mechanism.
 
RFC 6836 Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT)
 
Authors:V. Fuller, D. Farinacci, D. Meyer, D. Lewis.
Date:January 2013
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6836
This document describes a simple distributed index system to be used by a Locator/ID Separation Protocol (LISP) Ingress Tunnel Router(ITR) or Map-Resolver (MR) to find the Egress Tunnel Router (ETR) that holds the mapping information for a particular EndpointIdentifier (EID). The MR can then query that ETR to obtain the actual mapping information, which consists of a list of RoutingLocators (RLOCs) for the EID. Termed the Alternative LogicalTopology (ALT), the index is built as an overlay network on the public Internet using the Border Gateway Protocol (BGP) and GenericRouting Encapsulation (GRE).
 
RFC 6837 NERD: A Not-so-novel Endpoint ID (EID) to Routing Locator (RLOC) Database
 
Authors:E. Lear.
Date:January 2013
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6837
The Locator/ID Separation Protocol (LISP) is a protocol to encapsulate IP packets in order to allow end sites to route to one another without injecting routes from one end of the Internet to another. This memo presents an experimental database and a discussion of methods to transport the mapping of Endpoint IDs (EIDs) to Routing Locators (RLOCs) to routers in a reliable, scalable, and secure manner. Our analysis concludes that transport of all EID-to-RLOC mappings scales well to at least 10^8 entries.
 
RFC 6867 An Internet Key Exchange Protocol Version 2 (IKEv2) Extension to Support EAP Re-authentication Protocol (ERP)
 
Authors:Y. Nir, Q. Wu.
Date:January 2013
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6867
This document updates the Internet Key Exchange Protocol version 2(IKEv2) described in RFC 5996. This extension allows an IKE SecurityAssociation (SA) to be created and authenticated using the ExtensibleAuthentication Protocol (EAP) Re-authentication Protocol extension, as described in RFC 6696.
 
RFC 6882 Support for Resource Reservation Protocol Traffic Engineering (RSVP-TE) in Layer 3 Virtual Private Networks (L3VPNs)
 
Authors:K. Kumaki, Ed., T. Murai, D. Cheng, S. Matsushima, P. Jiang.
Date:March 2013
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6882
IP Virtual Private Networks (VPNs) provide connectivity between sites across an IP/MPLS backbone. These VPNs can be operated usingBGP/MPLS, and a single Provider Edge (PE) node may provide access to multiple customer sites belonging to different VPNs.

The VPNs may support a number of customer services, including RSVP and Resource Reservation Protocol Traffic Engineering (RSVP-TE) traffic. This document describes how to support RSVP-TE between customer sites when a single PE supports multiple VPNs and labels are not used to identify VPNs between PEs.

 
RFC 6919 Further Key Words for Use in RFCs to Indicate Requirement Levels
 
Authors:R. Barnes, S. Kent, E. Rescorla.
Date:1 April 2013
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6919
RFC 2119 defines a standard set of key words for describing requirements of a specification. Many IETF documents have found that these words cannot accurately capture the nuanced requirements of their specification. This document defines additional key words that can be used to address alternative requirements scenarios. Authors who follow these guidelines should incorporate this phrase near the beginning of their document:

The key words "MUST (BUT WE KNOW YOU WON'T)", "SHOULD CONSIDER","REALLY SHOULD NOT", "OUGHT TO", "WOULD PROBABLY", "MAY WISH TO","COULD", "POSSIBLE", and "MIGHT" in this document are to be interpreted as described in RFC 6919.

 
RFC 6928 Increasing TCP's Initial Window
 
Authors:J. Chu, N. Dukkipati, Y. Cheng, M. Mathis.
Date:April 2013
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6928
This document proposes an experiment to increase the permitted TCP initial window (IW) from between 2 and 4 segments, as specified inRFC 3390, to 10 segments with a fallback to the existing recommendation when performance issues are detected. It discusses the motivation behind the increase, the advantages and disadvantages of the higher initial window, and presents results from several large-scale experiments showing that the higher initial window improves the overall performance of many web services without resulting in a congestion collapse. The document closes with a discussion of usage and deployment for further experimental purposes recommended by the IETF TCP Maintenance and Minor Extensions (TCPM) working group.
 
RFC 6937 Proportional Rate Reduction for TCP
 
Authors:M. Mathis, N. Dukkipati, Y. Cheng.
Date:May 2013
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6937
This document describes an experimental Proportional Rate Reduction(PRR) algorithm as an alternative to the widely deployed FastRecovery and Rate-Halving algorithms. These algorithms determine the amount of data sent by TCP during loss recovery. PRR minimizes excess window adjustments, and the actual window size at the end of recovery will be as close as possible to the ssthresh, as determined by the congestion control algorithm.
 
RFC 6962 Certificate Transparency
 
Authors:B. Laurie, A. Langley, E. Kasper.
Date:June 2013
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6962
This document describes an experimental protocol for publicly logging the existence of Transport Layer Security (TLS) certificates as they are issued or observed, in a manner that allows anyone to audit certificate authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcingCAs to add all issued certificates to the logs.

Logs are network services that implement the protocol operations for submissions and queries that are defined in this document.

 
RFC 6968 FCAST: Object Delivery for the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols
 
Authors:V. Roca, B. Adamson.
Date:July 2013
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6968
This document introduces the FCAST reliable object (e.g., file) delivery application. It is designed to operate either on top of the underlying Asynchronous Layered Coding (ALC) / Layered CodingTransport (LCT) reliable multicast transport protocol or the NACK-Oriented Reliable Multicast (NORM) transport protocol.
 
RFC 6971 Depth-First Forwarding (DFF) in Unreliable Networks
 
Authors:U. Herberg, Ed., A. Cardenas, T. Iwao, M. Dow, S. Cespedes.
Date:June 2013
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6971
This document specifies the Depth-First Forwarding (DFF) protocol forIPv6 networks, a data-forwarding mechanism that can increase reliability of data delivery in networks with dynamic topology and/or lossy links. The protocol operates entirely on the forwarding plane but may interact with the routing plane. DFF forwards data packets using a mechanism similar to a "depth-first search" for the destination of a packet. The routing plane may be informed of failures to deliver a packet or loops. This document specifies theDFF mechanism both for IPv6 networks (as specified in RFC 2460) and for "mesh-under" Low-Power Wireless Personal Area Networks (LoWPANs), as specified in RFC 4944. The design of DFF assumes that the underlying link layer provides means to detect if a packet has been successfully delivered to the Next Hop or not. It is applicable for networks with little traffic and is used for unicast transmissions only.
 
RFC 6978 A TCP Authentication Option Extension for NAT Traversal
 
Authors:J. Touch.
Date:July 2013
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6978
This document describes an extension to the TCP Authentication Option(TCP-AO) to support its use over connections that pass throughNetwork Address Translators and/or Network Address and PortTranslators (NATs/NAPTs). This extension changes the data used to compute traffic keys, but it does not alter TCP-AO's packet processing or key generation algorithms.
 
RFC 6982 Improving Awareness of Running Code: The Implementation Status Section
 
Authors:Y. Sheffer, A. Farrel.
Date:July 2013
Formats:txt pdf
Obsoleted by:RFC 7942
Status:EXPERIMENTAL
DOI:10.17487/RFC 6982
This document describes a simple process that allows authors ofInternet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature.

The process in this document is offered as an experiment. Authors ofInternet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. The authors of this document intend to collate experiences with this experiment and to report them to the community.

 
RFC 6997 Reactive Discovery of Point-to-Point Routes in Low-Power and Lossy Networks
 
Authors:M. Goyal, Ed., E. Baccelli, M. Philipp, A. Brandt, J. Martocci.
Date:August 2013
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6997
This document specifies a point-to-point route discovery mechanism, complementary to the Routing Protocol for Low-power and LossyNetworks (RPL) core functionality. This mechanism allows an IPv6 router to discover "on demand" routes to one or more IPv6 routers in a Low-power and Lossy Network (LLN) such that the discovered routes meet specified metrics constraints.
 
RFC 6998 A Mechanism to Measure the Routing Metrics along a Point-to-Point Route in a Low-Power and Lossy Network
 
Authors:M. Goyal, Ed., E. Baccelli, A. Brandt, J. Martocci.
Date:August 2013
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 6998
This document specifies a mechanism that enables a Routing Protocol for Low-power and Lossy Networks (RPL) router to measure the aggregated values of given routing metrics along an existing route towards another RPL router, thereby allowing the router to decide if it wants to initiate the discovery of a better route.
 
RFC 7019 Application-Layer Multicast Extensions to REsource LOcation And Discovery (RELOAD)
 
Authors:J. Buford, M. Kolberg, Ed..
Date:September 2013
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 7019
We define a REsource LOcation And Discovery (RELOAD) Usage forApplication-Layer Multicast (ALM) as well as a mapping to the RELOAD experimental message type to support ALM. The ALM Usage is intended to support a variety of ALM control algorithms in an overlay- independent way. Two example algorithms are defined, based on Scribe and P2PCast.

This document is a product of the Scalable Adaptive MulticastResearch Group (SAM RG).

 
RFC 7028 Multicast Mobility Routing Optimizations for Proxy Mobile IPv6
 
Authors:JC. Zuniga, LM. Contreras, CJ. Bernardos, S. Jeon, Y. Kim.
Date:September 2013
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 7028
This document proposes some experimental enhancements to the base solution to support IP multicasting in a Proxy Mobile IPv6 (PMIPv6) domain. These enhancements include the use of a multicast tree mobility anchor as the topological anchor point for multicast traffic, as well as a direct routing option where the Mobile AccessGateway can provide access to multicast content in the local network.The goal of these enhancements is to provide benefits such as reducing multicast traffic replication and supporting differentPMIPv6 deployment scenarios.
 
RFC 7038 Use of OSPF-MDR in Single-Hop Broadcast Networks
 
Authors:R. Ogier.
Date:October 2013
Formats:txt pdf
Updates:RFC 5614
Status:EXPERIMENTAL
DOI:10.17487/RFC 7038
RFC 5614 (OSPF-MDR) extends OSPF to support mobile ad hoc networks(MANETs) by specifying its operation on the new OSPF interface of type MANET. This document describes the use of OSPF-MDR (MANETDesignated Router) in a single-hop broadcast network, which is a special case of a MANET in which each router is a (one-hop) neighbor of each other router. Unlike an OSPF broadcast interface, such an interface can have a different cost associated with each neighbor.The document includes configuration recommendations and simplified mechanisms that can be used in single-hop broadcast networks.
 
RFC 7046 A Common API for Transparent Hybrid Multicast
 
Authors:M. Waehlisch, T. Schmidt, S. Venaas.
Date:December 2013
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 7046
Group communication services exist in a large variety of flavors and technical implementations at different protocol layers. Multicast data distribution is most efficiently performed on the lowest available layer, but a heterogeneous deployment status of multicast technologies throughout the Internet requires an adaptive service binding at runtime. Today, it is difficult to write an application that runs everywhere and at the same time makes use of the most efficient multicast service available in the network. Facing robustness requirements, developers are frequently forced to use a stable upper-layer protocol provided by the application itself. This document describes a common multicast API that is suitable for transparent communication in underlay and overlay and that grants access to the different flavors of multicast. It proposes an abstract naming scheme that uses multicast URIs, and it discusses mapping mechanisms between different namespaces and distribution technologies. Additionally, this document describes the application of this API for building gateways that interconnect current MulticastDomains throughout the Internet. It reports on an implementation of the programming Interface, including service middleware. This document is a product of the Scalable Adaptive Multicast (SAM)Research Group.
 
RFC 7052 Locator/ID Separation Protocol (LISP) MIB
 
Authors:G. Schudel, A. Jain, V. Moreno.
Date:October 2013
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 7052
This document defines the MIB module that contains managed objects to support the monitoring devices of the Locator/ID Separation Protocol(LISP). These objects provide information useful for monitoring LISP devices, including determining basic LISP configuration information,LISP functional status, and operational counters and other statistics.
 
RFC 7086 Host Identity Protocol-Based Overlay Networking Environment (HIP BONE) Instance Specification for REsource LOcation And Discovery (RELOAD)
 
Authors:A. Keranen, G. Camarillo, J. Maenpaa.
Date:January 2014
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 7086
This document is the HIP-Based Overlay Networking Environment (HIPBONE) instance specification for the REsource LOcation And Discovery(RELOAD) protocol. The document provides the details needed to build a RELOAD-based overlay that uses HIP.
 
RFC 7109 Flow Bindings Initiated by Home Agents for Mobile IPv6
 
Authors:H. Yokota, D. Kim, B. Sarikaya, F. Xia.
Date:February 2014
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 7109
There are scenarios in which the home agent needs to trigger flow binding operations towards the mobile node, such as moving a flow from one access network to another based on network resource availability. In order for the home agent to be able to initiate interactions for flow bindings with the mobile node, this document defines new signaling messages and sub-options for Mobile IPv6. Flow bindings initiated by a home agent are supported for mobile nodes enabled by both IPv4 and IPv6.
 
RFC 7122 Datagram Convergence Layers for the Delay- and Disruption-Tolerant Networking (DTN) Bundle Protocol and Licklider Transmission Protocol (LTP)
 
Authors:H. Kruse, S. Jero, S. Ostermann.
Date:March 2014
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 7122
This document specifies the preferred method for transporting Delay- and Disruption-Tolerant Networking (DTN) protocol data over theInternet using datagrams. It covers convergence layers for theBundle Protocol (RFC 5050), as well as the transportation of segments using the Licklider Transmission Protocol (LTP) (RFC 5326). UDP and the Datagram Congestion Control Protocol (DCCP) are the candidate datagram protocols discussed. UDP can only be used on a local network or in cases where the DTN node implements explicit congestion control. DCCP addresses the congestion control problem, and its use is recommended whenever possible. This document is a product of theDelay-Tolerant Networking Research Group (DTNRG) and represents the consensus of the DTNRG.
 
RFC 7137 Use of the OSPF-MANET Interface in Single-Hop Broadcast Networks
 
Authors:A. Retana, S. Ratliff.
Date:February 2014
Formats:txt pdf
Updates:RFC 5820
Status:EXPERIMENTAL
DOI:10.17487/RFC 7137
This document describes the use of the OSPF-MANET interface in single-hop broadcast networks. It includes a mechanism to dynamically determine the presence of such a network and specific operational considerations due to its nature.

This document updates RFC 5820.

 
RFC 7161 Proxy Mobile IPv6 (PMIPv6) Multicast Handover Optimization by the Subscription Information Acquisition through the LMA (SIAL)
 
Authors:LM. Contreras, CJ. Bernardos, I. Soto.
Date:March 2014
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 7161
This document specifies an experimental multicast handover optimization mechanism for Proxy Mobile IPv6 (PMIPv6) to accelerate the delivery of multicast traffic to mobile nodes after handovers.The mechanism, called Subscription Information Acquisition through the LMA (SIAL), is based on speeding up the acquisition of mobile nodes' multicast context by the mobile access gateways. To do that, extensions to the current PMIPv6 protocol are proposed. These extensions are not only applicable to the base solution for multicast support in Proxy Mobile IPv6, but they can also be applied to other solutions developed to avoid the tunnel convergence problem.Furthermore, these extensions are also independent of the role played by the mobile access gateway within the multicast network (acting as either multicast listener discovery proxy or multicast router).
 
RFC 7215 Locator/Identifier Separation Protocol (LISP) Network Element Deployment Considerations
 
Authors:L. Jakab, A. Cabellos-Aparicio, F. Coras, J. Domingo-Pascual, D. Lewis.
Date:April 2014
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 7215
This document is a snapshot of different Locator/IdentifierSeparation Protocol (LISP) deployment scenarios. It discusses the placement of new network elements introduced by the protocol, representing the thinking of the LISP working group as of Summer2013. LISP deployment scenarios may have evolved since then. This memo represents one stable point in that evolution of understanding.
 
RFC 7238 The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect)
 
Authors:J. Reschke.
Date:June 2014
Formats:txt pdf
Obsoleted by:RFC 7538
Status:EXPERIMENTAL
DOI:10.17487/RFC 7238
This document specifies the additional Hypertext Transfer Protocol(HTTP) status code 308 (Permanent Redirect).
 
RFC 7242 Delay-Tolerant Networking TCP Convergence-Layer Protocol
 
Authors:M. Demmer, J. Ott, S. Perreault.
Date:June 2014
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 7242
This document describes the protocol for the TCP-based convergence layer for Delay-Tolerant Networking (DTN). It is the product of theIRTF's DTN Research Group (DTNRG).
 
RFC 7287 Mobile Multicast Sender Support in Proxy Mobile IPv6 (PMIPv6) Domains
 
Authors:T. Schmidt, Ed., S. Gao, H. Zhang, M. Waehlisch.
Date:June 2014
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 7287
Multicast communication can be enabled in Proxy Mobile IPv6 (PMIPv6) domains via the Local Mobility Anchors by deploying MulticastListener Discovery (MLD) proxy functions at Mobile Access Gateways, by using direct traffic distribution within an ISP's access network, or by selective route optimization schemes. This document describes a base solution and an experimental protocol to support mobile multicast senders in PMIPv6 domains for all three scenarios.Protocol optimizations for synchronizing PMIPv6 with PIM, as well as a peering function for MLD proxies are defined. Mobile sources always remain agnostic of multicast mobility operations.
 
RFC 7298 Babel Hashed Message Authentication Code (HMAC) Cryptographic Authentication
 
Authors:D. Ovsienko.
Date:July 2014
Formats:txt pdf
Updates:RFC 6126
Status:EXPERIMENTAL
DOI:10.17487/RFC 7298
This document describes a cryptographic authentication mechanism for the Babel routing protocol. This document updates RFC 6126. The mechanism allocates two new TLV types for the authentication data, uses Hashed Message Authentication Code (HMAC), and is both optional and backward compatible.
 
RFC 7314 Extension Mechanisms for DNS (EDNS) EXPIRE Option
 
Authors:M. Andrews.
Date:July 2014
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 7314
This document specifies a method for secondary DNS servers to honour the SOA EXPIRE field as if they were always transferring from the primary, even when using other secondaries to perform indirect transfers and refresh queries.
 
RFC 7334 PCE-Based Computation Procedure to Compute Shortest Constrained Point-to-Multipoint (P2MP) Inter-Domain Traffic Engineering Label Switched Paths
 
Authors:Q. Zhao, D. Dhody, D. King, Z. Ali, R. Casellas.
Date:August 2014
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 7334
The ability to compute paths for constrained point-to-multipoint(P2MP) Traffic Engineering Label Switched Paths (TE LSPs) across multiple domains has been identified as a key requirement for the deployment of P2MP services in MPLS- and GMPLS-controlled networks.The Path Computation Element (PCE) has been recognized as an appropriate technology for the determination of inter-domain paths ofP2MP TE LSPs.

This document describes an experiment to provide procedures and extensions to the PCE Communication Protocol (PCEP) for the computation of inter-domain paths for P2MP TE LSPs.

 
RFC 7360 Datagram Transport Layer Security (DTLS) as a Transport Layer for RADIUS
 
Authors:A. DeKok.
Date:September 2014
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 7360
The RADIUS protocol defined in RFC 2865 has limited support for authentication and encryption of RADIUS packets. The protocol transports data in the clear, although some parts of the packets can have obfuscated content. Packets may be replayed verbatim by an attacker, and client-server authentication is based on fixed shared secrets. This document specifies how the Datagram Transport LayerSecurity (DTLS) protocol may be used as a fix for these problems. It also describes how implementations of this proposal can coexist with current RADIUS systems.
 
RFC 7367 Definition of Managed Objects for the Mobile Ad Hoc Network (MANET) Simplified Multicast Framework Relay Set Process
 
Authors:R. Cole, J. Macker, B. Adamson.
Date:October 2014
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 7367
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes objects for configuring aspects of theSimplified Multicast Forwarding (SMF) process for Mobile Ad HocNetworks (MANETs). The SMF-MIB module also reports state information, performance information, and notifications. In addition to configuration, the additional state and performance information is useful to operators troubleshooting multicast forwarding problems.
 
RFC 7390 Group Communication for the Constrained Application Protocol (CoAP)
 
Authors:A. Rahman, Ed., E. Dijk, Ed..
Date:October 2014
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 7390
The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for constrained devices and constrained networks.It is anticipated that constrained devices will often naturally operate in groups (e.g., in a building automation scenario, all lights in a given room may need to be switched on/off as a group).This specification defines how CoAP should be used in a group communication context. An approach for using CoAP on top of IP multicast is detailed based on existing CoAP functionality as well as new features introduced in this specification. Also, various use cases and corresponding protocol flows are provided to illustrate important concepts. Finally, guidance is provided for deployment in various network topologies.
 
RFC 7409 Forwarding and Control Element Separation (ForCES) Packet Parallelization
 
Authors:E. Haleplidis, J. Halpern.
Date:November 2014
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 7409
Many network devices support parallel packet processing. This document describes how Forwarding and Control Element Separation(ForCES) can model a network device's parallelization datapath using constructs defined by the ForCES model (RFC 5812) and controlled via the ForCES protocol (RFC 5810).
 
RFC 7411 Multicast Listener Extensions for Mobile IPv6 (MIPv6) and Proxy Mobile IPv6 (PMIPv6) Fast Handovers
 
Authors:T. Schmidt, Ed., M. Waehlisch, R. Koodli, G. Fairhurst, D. Liu.
Date:November 2014
Formats:txt pdf
Updates:RFC 5568
Status:EXPERIMENTAL
DOI:10.17487/RFC 7411
Fast handover protocols for Mobile IPv6 (MIPv6) and Proxy Mobile IPv6(PMIPv6) define mobility management procedures that support unicast communication at reduced handover latency. Fast handover base operations do not affect multicast communication and, hence, do not accelerate handover management for native multicast listeners. Many multicast applications like IPTV or conferencing, though, comprise delay-sensitive, real-time traffic and will benefit from fast handover completion. This document specifies extension of the MobileIPv6 Fast Handovers (FMIPv6) and the Fast Handovers for Proxy MobileIPv6 (PFMIPv6) protocols to include multicast traffic management in fast handover operations. This multicast support is provided first at the control plane by management of rapid context transfer between access routers and second at the data plane by optional fast traffic forwarding that may include buffering. An FMIPv6 access router indicates support for multicast using an updated Proxy RouterAdvertisements message format.

This document updates RFC 5568, "Mobile IPv6 Fast Handovers".

 
RFC 7413 TCP Fast Open
 
Authors:Y. Cheng, J. Chu, S. Radhakrishnan, A. Jain.
Date:December 2014
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 7413
This document describes an experimental TCP mechanism called TCP FastOpen (TFO). TFO allows data to be carried in the SYN and SYN-ACK packets and consumed by the receiving end during the initial connection handshake, and saves up to one full round-trip time (RTT) compared to the standard TCP, which requires a three-way handshake(3WHS) to complete before data can be exchanged. However, TFO deviates from the standard TCP semantics, since the data in the SYN could be replayed to an application in some rare circumstances.Applications should not use TFO unless they can tolerate this issue, as detailed in the Applicability section.
 
RFC 7417 Extensions to Generic Aggregate RSVP for IPv4 and IPv6 Reservations over Pre-Congestion Notification (PCN) Domains
 
Authors:G. Karagiannis, A. Bhargava.
Date:December 2014
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 7417
This document specifies extensions to Generic Aggregate RSVP (RFC4860) for support of the Pre-Congestion Notification (PCN) ControlledLoad (CL) and Single Marking (SM) edge behaviors over a Diffserv cloud using PCN.
 
RFC 7486 HTTP Origin-Bound Authentication (HOBA)
 
Authors:S. Farrell, P. Hoffman, M. Thomas.
Date:March 2015
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 7486
HTTP Origin-Bound Authentication (HOBA) is a digital-signature-based design for an HTTP authentication method. The design can also be used in JavaScript-based authentication embedded in HTML. HOBA is an alternative to HTTP authentication schemes that require passwords and therefore avoids all problems related to passwords, such as leakage of server-side password databases.
 
RFC 7499 Support of Fragmentation of RADIUS Packets
 
Authors:A. Perez-Mendez, Ed., R. Marin-Lopez, F. Pereniguez-Garcia, G. Lopez-Millan, D. Lopez, A. DeKok.
Date:April 2015
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 7499
The Remote Authentication Dial-In User Service (RADIUS) protocol is limited to a total packet size of 4096 bytes. Provisions exist for fragmenting large amounts of authentication data across multiple packets, via Access-Challenge packets. No similar provisions exist for fragmenting large amounts of authorization data. This document specifies how existing RADIUS mechanisms can be leveraged to provide that functionality. These mechanisms are largely compatible with existing implementations, and they are designed to be invisible to proxies and "fail-safe" to legacy RADIUS Clients and Servers.
 
RFC 7508 Securing Header Fields with S/MIME
 
Authors:L. Cailleux, C. Bonatti.
Date:April 2015
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 7508
This document describes how the S/MIME protocol can be extended in order to secure message header fields defined in RFC 5322. This technology provides security services such as data integrity, non- repudiation, and confidentiality. This extension is referred to as'Secure Headers'.
 
RFC 7514 Really Explicit Congestion Notification (RECN)
 
Authors:M. Luckie.
Date:1 April 2015
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 7514
This document proposes a new ICMP message that a router or host may use to advise a host to reduce the rate at which it sends, in cases where the host ignores other signals provided by packet loss andExplicit Congestion Notification (ECN).
 
RFC 7557 Extension Mechanism for the Babel Routing Protocol
 
Authors:J. Chroboczek.
Date:May 2015
Formats:txt pdf
Updates:RFC 6126
Status:EXPERIMENTAL
DOI:10.17487/RFC 7557
This document defines the encoding of extensions to the Babel routing protocol, as specified in RFC 6126.
 
RFC 7566 Enumservice Registration for 'acct' URI
 
Authors:L. Goix, K. Li.
Date:June 2015
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 7566
This document registers an E.164 Number Mapping (ENUM) service for'acct' URIs (Uniform Resource Identifiers).
 
RFC 7585 Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS Based on the Network Access Identifier (NAI)
 
Authors:S. Winter, M. McCauley.
Date:October 2015
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 7585
This document specifies a means to find authoritative RADIUS servers for a given realm. It is used in conjunction with either RADIUS overTransport Layer Security (RADIUS/TLS) or RADIUS over DatagramTransport Layer Security (RADIUS/DTLS).
 
RFC 7586 The Scalable Address Resolution Protocol (SARP) for Large Data Centers
 
Authors:Y. Nachum, L. Dunbar, I. Yerushalmi, T. Mizrahi.
Date:June 2015
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 7586
This document introduces the Scalable Address Resolution Protocol(SARP), an architecture that uses proxy gateways to scale large data center networks. SARP is based on fast proxies that significantly reduce switches' Filtering Database (FDB) table sizes and reduce impact of ARP and Neighbor Discovery (ND) on network elements in an environment where hosts within one subnet (or VLAN) can spread over various locations. SARP is targeted for massive data centers with a significant number of Virtual Machines (VMs) that can move across various physical locations.
 
RFC 7592 OAuth 2.0 Dynamic Client Registration Management Protocol
 
Authors:J. Richer, Ed., M. Jones, J. Bradley, M. Machulak.
Date:July 2015
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 7592
This specification defines methods for management of OAuth 2.0 dynamic client registrations for use cases in which the properties of a registered client may need to be changed during the lifetime of the client. Not all authorization servers supporting dynamic client registration will support these management methods.
 
RFC 7600 IPv4 Residual Deployment via IPv6 - A Stateless Solution (4rd)
 
Authors:R. Despres, S. Jiang, Ed., R. Penno, Y. Lee, G. Chen, M. Chen.
Date:July 2015
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 7600
This document specifies a stateless solution for service providers to progressively deploy IPv6-only network domains while still offeringIPv4 service to customers. The solution's distinctive properties are that TCP/UDP IPv4 packets are valid TCP/UDP IPv6 packets during domain traversal and that IPv4 fragmentation rules are fully preserved end to end. Each customer can be assigned one public IPv4 address, several public IPv4 addresses, or a shared address with a restricted port set.
 
RFC 7629 Flow-Binding Support for Mobile IP
 
Authors:S. Gundavelli, Ed., K. Leung, G. Tsirtsis, A. Petrescu.
Date:August 2015
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 7629
This specification defines extensions to the Mobile IP protocol for allowing a mobile node with multiple interfaces to register a care-of address for each of its network interfaces and to simultaneously establish multiple IP tunnels with its home agent. This essentially allows the mobile node to utilize all the available network interfaces and build a higher aggregated logical pipe with its home agent for its home address traffic. Furthermore, these extensions also allow the mobile node and the home agent to negotiate IP traffic flow policies for binding individual flows with the registered care- of addresses.
 
RFC 7661 Updating TCP to Support Rate-Limited Traffic
 
Authors:G. Fairhurst, A. Sathiaseelan, R. Secchi.
Date:October 2015
Formats:txt pdf
Obsoletes:RFC 2861
Status:EXPERIMENTAL
DOI:10.17487/RFC 7661
This document provides a mechanism to address issues that arise whenTCP is used for traffic that exhibits periods where the sending rate is limited by the application rather than the congestion window. It provides an experimental update to TCP that allows a TCP sender to restart quickly following a rate-limited interval. This method is expected to benefit applications that send rate-limited traffic usingTCP while also providing an appropriate response if congestion is experienced.

This document also evaluates the Experimental specification of TCPCongestion Window Validation (CWV) defined in RFC 2861 and concludes that RFC 2861 sought to address important issues but failed to deliver a widely used solution. This document therefore reclassifies the status of RFC 2861 from Experimental to Historic. This document obsoletes RFC 2861.

 
RFC 7722 Multi-Topology Extension for the Optimized Link State Routing Protocol Version 2 (OLSRv2)
 
Authors:C. Dearlove, T. Clausen.
Date:December 2015
Formats:txt pdf
Updates:RFC 7188, RFC 7631
Status:EXPERIMENTAL
DOI:10.17487/RFC 7722
This specification describes an extension to the Optimized Link StateRouting Protocol version 2 (OLSRv2) to support multiple routing topologies, while retaining interoperability with OLSRv2 routers that do not implement this extension.

This specification updates RFCs 7188 and 7631 by modifying and extending TLV registries and descriptions.

 
RFC 7758 Time Capability in NETCONF
 
Authors:T. Mizrahi, Y. Moses.
Date:February 2016
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 7758
This document defines a capability-based extension to the NetworkConfiguration Protocol (NETCONF) that allows time-triggered configuration and management operations. This extension allowsNETCONF clients to invoke configuration updates according to scheduled times and allows NETCONF servers to attach timestamps to the data they send to NETCONF clients.
 
RFC 7765 TCP and Stream Control Transmission Protocol (SCTP) RTO Restart
 
Authors:P. Hurtig, A. Brunstrom, A. Petlund, M. Welzl.
Date:February 2016
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 7765
This document describes a modified sender-side algorithm for managing the TCP and Stream Control Transmission Protocol (SCTP) retransmission timers that provides faster loss recovery when there is a small amount of outstanding data for a connection. The modification, RTO Restart (RTOR), allows the transport to restart its retransmission timer using a smaller timeout duration, so that the effective retransmission timeout (RTO) becomes more aggressive in situations where fast retransmit cannot be used. This enables faster loss detection and recovery for connections that are short lived or application limited.
 
RFC 7779 Directional Airtime Metric Based on Packet Sequence Numbers for Optimized Link State Routing Version 2 (OLSRv2)
 
Authors:H. Rogge, E. Baccelli.
Date:April 2016
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 7779
This document specifies a Directional Airtime (DAT) link metric for usage in Optimized Link State Routing version 2 (OLSRv2).
 
RFC 7786 TCP Modifications for Congestion Exposure (ConEx)
 
Authors:M. Kuehlewind, Ed., R. Scheffenegger.
Date:May 2016
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 7786
Congestion Exposure (ConEx) is a mechanism by which senders inform the network about expected congestion based on congestion feedback from previous packets in the same flow. This document describes the necessary modifications to use ConEx with the Transmission ControlProtocol (TCP).
 
RFC 7804 Salted Challenge Response HTTP Authentication Mechanism
 
Authors:A. Melnikov.
Date:March 2016
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 7804
This specification describes a family of HTTP authentication mechanisms called the Salted Challenge Response AuthenticationMechanism (SCRAM), which provides a more robust authentication mechanism than a plaintext password protected by Transport LayerSecurity (TLS) and avoids the deployment obstacles presented by earlier TLS-protected challenge response authentication mechanisms.
 
RFC 7816 DNS Query Name Minimisation to Improve Privacy
 
Authors:S. Bortzmeyer.
Date:March 2016
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 7816
This document describes a technique to improve DNS privacy, a technique called "QNAME minimisation", where the DNS resolver no longer sends the full original QNAME to the upstream name server.
 
RFC 7820 UDP Checksum Complement in the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP)
 
Authors:T. Mizrahi.
Date:March 2016
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 7820
The One-Way Active Measurement Protocol (OWAMP) and the Two-WayActive Measurement Protocol (TWAMP) are used for performance monitoring in IP networks. Delay measurement is performed in these protocols by using timestamped test packets. Some implementations use hardware-based timestamping engines that integrate the accurate transmission time into every outgoing OWAMP/TWAMP test packet during transmission. Since these packets are transported over UDP, the UDPChecksum field is then updated to reflect this modification. This document proposes to use the last 2 octets of every test packet as aChecksum Complement, allowing timestamping engines to reflect the checksum modification in the last 2 octets rather than in the UDPChecksum field. The behavior defined in this document is completely interoperable with existing OWAMP/TWAMP implementations.
 
RFC 7821 UDP Checksum Complement in the Network Time Protocol (NTP)
 
Authors:T. Mizrahi.
Date:March 2016
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 7821
The Network Time Protocol (NTP) allows clients to synchronize to a time server using timestamped protocol messages. To facilitate accurate timestamping, some implementations use hardware-based timestamping engines that integrate the accurate transmission time into every outgoing NTP packet during transmission. Since these packets are transported over UDP, the UDP Checksum field is then updated to reflect this modification. This document proposes an extension field that includes a 2-octet Checksum Complement, allowing timestamping engines to reflect the checksum modification in the last2 octets of the packet rather than in the UDP Checksum field. The behavior defined in this document is interoperable with existing NTP implementations.
 
RFC 7837 IPv6 Destination Option for Congestion Exposure (ConEx)
 
Authors:S. Krishnan, M. Kuehlewind, B. Briscoe, C. Ralli.
Date:May 2016
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 7837
Congestion Exposure (ConEx) is a mechanism by which senders inform the network about the congestion encountered by packets earlier in the same flow. This document specifies an IPv6 destination option that is capable of carrying ConEx markings in IPv6 datagrams.
 
RFC 7859 Identity-Based Signatures for Mobile Ad Hoc Network (MANET) Routing Protocols
 
Authors:C. Dearlove.
Date:May 2016
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 7859
This document extends RFC 7182, which specifies a framework for (and specific examples of) Integrity Check Values (ICVs) for packets and messages using the generalized packet/message format specified in RFC5444. It does so by defining an additional cryptographic function that allows the creation of an ICV that is an Identity-BasedSignature (IBS), defined according to the Elliptic Curve-BasedCertificateless Signatures for Identity-Based Encryption (ECCSI) algorithm specified in RFC 6507.
 
RFC 7897 Domain Subobjects for the Path Computation Element Communication Protocol (PCEP)
 
Authors:D. Dhody, U. Palle, R. Casellas.
Date:June 2016
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 7897
The ability to compute shortest constrained Traffic Engineering LabelSwitched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) andGeneralized MPLS (GMPLS) networks across multiple domains has been identified as a key requirement. In this context, a domain is a collection of network elements within a common sphere of address management or path computational responsibility such as an InteriorGateway Protocol (IGP) area or an Autonomous System (AS). This document specifies a representation and encoding of a domain sequence, which is defined as an ordered sequence of domains traversed to reach the destination domain to be used by PathComputation Elements (PCEs) to compute inter-domain constrained shortest paths across a predetermined sequence of domains. This document also defines new subobjects to be used to encode domain identifiers.
 
RFC 7898 Domain Subobjects for Resource Reservation Protocol - Traffic Engineering (RSVP-TE)
 
Authors:D. Dhody, U. Palle, V. Kondreddy, R. Casellas.
Date:June 2016
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 7898
The Resource Reservation Protocol - Traffic Engineering (RSVP-TE) specification and the Generalized Multiprotocol Label Switching(GMPLS) extensions to RSVP-TE allow abstract nodes and resources to be explicitly included in a path setup. Further, Exclude Route extensions to RSVP-TE allow abstract nodes and resources to be explicitly excluded in a path setup.

This document specifies new subobjects to include or excludeAutonomous Systems (ASes), which are identified by a 4-byte AS number, and Interior Gateway Protocol (IGP) areas during path setup.

 
RFC 7901 CHAIN Query Requests in DNS
 
Authors:P. Wouters.
Date:June 2016
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 7901
This document defines an EDNS0 extension that can be used by a security-aware validating resolver configured to use a forwarding resolver to send a single query, requesting a complete validation path along with the regular query answer. The reduction in queries potentially lowers the latency and reduces the need to send multiple queries at once. This extension mandates the use of source-IP- verified transport such as TCP or UDP with EDNS-COOKIE, so it cannot be abused in amplification attacks.
 
RFC 7929 DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP
 
Authors:P. Wouters.
Date:August 2016
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 7929
OpenPGP is a message format for email (and file) encryption that lacks a standardized lookup mechanism to securely obtain OpenPGP public keys. DNS-Based Authentication of Named Entities (DANE) is a method for publishing public keys in DNS. This document specifies aDANE method for publishing and locating OpenPGP public keys in DNS for a specific email address using a new OPENPGPKEY DNS resource record. Security is provided via Secure DNS, however the OPENPGPKEY record is not a replacement for verification of authenticity via the"web of trust" or manual verification. The OPENPGPKEY record can be used to encrypt an email that would otherwise have to be sent unencrypted.
 
RFC 7930 Larger Packets for RADIUS over TCP
 
Authors:S. Hartman.
Date:August 2016
Formats:txt pdf
Updates:RFC 6613
Status:EXPERIMENTAL
DOI:10.17487/RFC 7930
The RADIUS-over-TLS experiment described in RFC 6614 has openedRADIUS to new use cases where the 4096-octet maximum size limit of aRADIUS packet proves problematic. This specification extends theRADIUS-over-TCP experiment (RFC 6613) to permit larger RADIUS packets. This specification compliments other ongoing work to permit fragmentation of RADIUS authorization information. This document registers a new RADIUS code, an action that required IESG approval.
 
RFC 7954 Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block
 
Authors:L. Iannone, D. Lewis, D. Meyer, V. Fuller.
Date:September 2016
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 7954
This document directs IANA to allocate a /32 IPv6 prefix for use with the Locator/ID Separation Protocol (LISP). The prefix will be used for local intra-domain routing and global endpoint identification, by sites deploying LISP as Endpoint Identifier (EID) addressing space.
 
RFC 7974 An Experimental TCP Option for Host Identification
 
Authors:B. Williams, M. Boucadair, D. Wing.
Date:October 2016
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 7974
Recent RFCs have discussed issues with host identification in IP address-sharing systems, such as address/prefix-sharing devices and application-layer proxies. Potential solutions for revealing a host identifier in shared address deployments have also been discussed.This memo describes the design, deployment, and privacy considerations for one such solution in operational use on theInternet today that uses a TCP option to transmit a host identifier.
 
RFC 8033 Proportional Integral Controller Enhanced (PIE): A Lightweight Control Scheme to Address the Bufferbloat Problem
 
Authors:R. Pan, P. Natarajan, F. Baker, G. White.
Date:February 2017
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 8033
Bufferbloat is a phenomenon in which excess buffers in the network cause high latency and latency variation. As more and more interactive applications (e.g., voice over IP, real-time video streaming, and financial transactions) run in the Internet, high latency and latency variation degrade application performance. There is a pressing need to design intelligent queue management schemes that can control latency and latency variation, and hence provide desirable quality of service to users.

This document presents a lightweight active queue management design called "PIE" (Proportional Integral controller Enhanced) that can effectively control the average queuing latency to a target value.Simulation results, theoretical analysis, and Linux testbed results have shown that PIE can ensure low latency and achieve high link utilization under various congestion situations. The design does not require per-packet timestamps, so it incurs very little overhead and is simple enough to implement in both hardware and software.

 
RFC 8039 Multipath Time Synchronization
 
Authors:A. Shpiner, R. Tse, C. Schelp, T. Mizrahi.
Date:December 2016
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 8039
Clock synchronization protocols are very widely used in IP-based networks. The Network Time Protocol (NTP) has been commonly deployed for many years, and the last few years have seen an increasingly rapid deployment of the Precision Time Protocol (PTP). As time- sensitive applications evolve, clock accuracy requirements are becoming increasingly stringent, requiring the time synchronization protocols to provide high accuracy. This memo describes a multipath approach to PTP and NTP over IP networks, allowing the protocols to run concurrently over multiple communication paths between the master and slave clocks, without modifying these protocols. The multipath approach can significantly contribute to clock accuracy, security, and fault tolerance. The multipath approach that is presented in this document enables backward compatibility with nodes that do not support the multipath functionality.
 
RFC 8053 HTTP Authentication Extensions for Interactive Clients
 
Authors:Y. Oiwa, H. Watanabe, H. Takagi, K. Maeda, T. Hayashi, Y. Ioku.
Date:January 2017
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 8053
This document specifies extensions for the HTTP authentication framework for interactive clients. Currently, fundamental features of HTTP-level authentication are insufficient for complex requirements of various Web-based applications. This forces these applications to implement their own authentication frameworks by means such as HTML forms, which becomes one of the hurdles against introducing secure authentication mechanisms handled jointly by servers and user agents. The extended framework fills gaps betweenWeb application requirements and HTTP authentication provisions to solve the above problems, while maintaining compatibility with existing Web and non-Web uses of HTTP authentication.
 
RFC 8059 PIM Join Attributes for Locator/ID Separation Protocol (LISP) Environments
 
Authors:J. Arango, S. Venaas, I. Kouvelas, D. Farinacci.
Date:January 2017
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 8059
This document defines two PIM Join/Prune attributes that support the construction of multicast distribution trees where the root and receivers are located in different Locator/ID Separation Protocol(LISP) sites. These attributes allow the receiver site to select between unicast and multicast underlying transport and to convey theRLOC (Routing Locator) address of the receiver ETR (Egress TunnelRouter) to the control plane of the root ITR (Ingress Tunnel Router).
 
RFC 8060 LISP Canonical Address Format (LCAF)
 
Authors:D. Farinacci, D. Meyer, J. Snijders.
Date:February 2017
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 8060
This document defines a canonical address format encoding used inLocator/ID Separation Protocol (LISP) control messages and in the encoding of lookup keys for the LISP Mapping Database System.
 
RFC 8061 Locator/ID Separation Protocol (LISP) Data-Plane Confidentiality
 
Authors:D. Farinacci, B. Weis.
Date:February 2017
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 8061
This document describes a mechanism for encrypting traffic encapsulated using the Locator/ID Separation Protocol (LISP). The design describes how key exchange is achieved using existing LISP control-plane mechanisms as well as how to secure the LISP data plane from third-party surveillance attacks.
 
RFC 8094 DNS over Datagram Transport Layer Security (DTLS)
 
Authors:T. Reddy, D. Wing, P. Patil.
Date:February 2017
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 8094
DNS queries and responses are visible to network elements on the path between the DNS client and its server. These queries and responses can contain privacy-sensitive information, which is valuable to protect.

This document proposes the use of Datagram Transport Layer Security(DTLS) for DNS, to protect against passive listeners and certain active attacks. As latency is critical for DNS, this proposal also discusses mechanisms to reduce DTLS round trips and reduce the DTLS handshake size. The proposed mechanism runs over port 853.

 
RFC 8099 OSPF Topology-Transparent Zone
 
Authors:H. Chen, R. Li, A. Retana, Y. Yang, Z. Liu.
Date:February 2017
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 8099
This document presents a Topology-Transparent Zone (TTZ) in an OSPF area. A TTZ comprises a group of routers and a number of links connecting these routers. Any router outside of the zone is not aware of the zone. A TTZ hides the internal topology of the TTZ from the outside. It does not directly advertise any internal information about the TTZ to a router outside of the TTZ. The information about the links and routers such as a link down inside the TTZ is not advertised to any router outside of the TTZ.
 
RFC 8111 Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT)
 
Authors:V. Fuller, D. Lewis, V. Ermagan, A. Jain, A. Smirnov.
Date:May 2017
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 8111
This document describes the Locator/ID Separation Protocol DelegatedDatabase Tree (LISP-DDT), a hierarchical distributed database that embodies the delegation of authority to provide mappings from LISPEndpoint Identifiers (EIDs) to Routing Locators (RLOCs). It is a statically defined distribution of the EID namespace among a set ofLISP-speaking servers called "DDT nodes". Each DDT node is configured as "authoritative" for one or more EID-prefixes, along with the set of RLOCs for Map-Servers or "child" DDT nodes to which more-specific EID-prefixes are delegated.
 
RFC 8113 Locator/ID Separation Protocol (LISP): Shared Extension Message & IANA Registry for Packet Type Allocations
 
Authors:M. Boucadair, C. Jacquenet.
Date:March 2017
Formats:txt pdf
Updates:RFC 6830
Status:EXPERIMENTAL
DOI:10.17487/RFC 8113
This document specifies a Locator/ID Separation Protocol (LISP) shared message type for defining future extensions and conducting experiments without consuming a LISP packet type codepoint for each extension. It also defines a registry for LISP Packet Type allocations, thus updating RFC 6830.
 
RFC 8120 Mutual Authentication Protocol for HTTP
 
Authors:Y. Oiwa, H. Watanabe, H. Takagi, K. Maeda, T. Hayashi, Y. Ioku.
Date:April 2017
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 8120
This document specifies an authentication scheme for the HypertextTransfer Protocol (HTTP) that is referred to as either the Mutual authentication scheme or the Mutual authentication protocol. This scheme provides true mutual authentication between an HTTP client and an HTTP server using password-based authentication. Unlike the Basic and Digest authentication schemes, the Mutual authentication scheme specified in this document assures the user that the server truly knows the user's encrypted password.
 
RFC 8121 Mutual Authentication Protocol for HTTP: Cryptographic Algorithms Based on the Key Agreement Mechanism 3 (KAM3)
 
Authors:Y. Oiwa, H. Watanabe, H. Takagi, K. Maeda, T. Hayashi, Y. Ioku.
Date:April 2017
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 8121
This document specifies cryptographic algorithms for use with theMutual user authentication method for the Hypertext Transfer Protocol(HTTP).
 
RFC 8135 Complex Addressing in IPv6
 
Authors:M. Danielson, M. Nilsson.
Date:1 April 2017
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 8135
The 128-bit length of IPv6 addresses (RFC 4291) allows for new and innovative address schemes that can adapt to the challenges of today's complex network world. It also allows for new and improved security measures and supports advanced cloud computing challenges.
 
RFC 8162 Using Secure DNS to Associate Certificates with Domain Names for S/MIME
 
Authors:P. Hoffman, J. Schlyter.
Date:May 2017
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 8162
This document describes how to use secure DNS to associate an S/MIME user's certificate with the intended domain name, similar to the way that DNS-Based Authentication of Named Entities (DANE), RFC 6698, does for TLS.
 
RFC 8164 Opportunistic Security for HTTP/2
 
Authors:M. Nottingham, M. Thomson.
Date:May 2017
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 8164
This document describes how "http" URIs can be accessed usingTransport Layer Security (TLS) and HTTP/2 to mitigate pervasive monitoring attacks. This mechanism not a replacement for "https"URIs; it is vulnerable to active attacks.
 
RFC 8218 Multipath Extension for the Optimized Link State Routing Protocol Version 2 (OLSRv2)
 
Authors:J. Yi, B. Parrein.
Date:August 2017
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 8218
This document specifies a multipath extension for the Optimized LinkState Routing Protocol version 2 (OLSRv2) to discover multiple disjoint paths for Mobile Ad Hoc Networks (MANETs). Considering the characteristics of MANETs, especially the dynamic network topology, using multiple paths can increase aggregated throughput and improve the reliability by avoiding single route failures. The interoperability with OLSRv2 is retained.
 
RFC 8289 Controlled Delay Active Queue Management
 
Authors:K. Nichols, V. Jacobson, A. McGregor, Ed., J. Iyengar, Ed..
Date:January 2018
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 8289
This document describes CoDel (Controlled Delay) -- a general framework that controls bufferbloat-generated excess delay in modern networking environments. CoDel consists of an estimator, a setpoint, and a control loop. It requires no configuration in normal Internet deployments.
 
RFC 8290 The Flow Queue CoDel Packet Scheduler and Active Queue Management Algorithm
 
Authors:T. Hoeiland-Joergensen, P. McKenney, D. Taht, J. Gettys, E. Dumazet.
Date:January 2018
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 8290
This memo presents the FQ-CoDel hybrid packet scheduler and ActiveQueue Management (AQM) algorithm, a powerful tool for fighting bufferbloat and reducing latency.

FQ-CoDel mixes packets from multiple flows and reduces the impact of head-of-line blocking from bursty traffic. It provides isolation for low-rate traffic such as DNS, web, and videoconferencing traffic. It improves utilisation across the networking fabric, especially for bidirectional traffic, by keeping queue lengths short, and it can be implemented in a memory- and CPU-efficient fashion across a wide range of hardware.

 
RFC 8297 An HTTP Status Code for Indicating Hints
 
Authors:K. Oku.
Date:December 2017
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 8297
This memo introduces an informational HTTP status code that can be used to convey hints that help a client make preparations for processing the final response.
 
RFC 8298 Self-Clocked Rate Adaptation for Multimedia
 
Authors:I. Johansson, Z. Sarker.
Date:December 2017
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 8298
This memo describes a rate adaptation algorithm for conversational media services such as interactive video. The solution conforms to the packet conservation principle and uses a hybrid loss-and-delay- based congestion control algorithm. The algorithm is evaluated over both simulated Internet bottleneck scenarios as well as in a LongTerm Evolution (LTE) system simulator and is shown to achieve both low latency and high video throughput in these scenarios.
 
RFC 8321 Alternate-Marking Method for Passive and Hybrid Performance Monitoring
 
Authors:G. Fioccola, Ed., A. Capello, M. Cociglio, L. Castaldelli, M. Chen, L. Zheng, G. Mirsky, T. Mizrahi.
Date:January 2018
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 8321
This document describes a method to perform packet loss, delay, and jitter measurements on live traffic. This method is based on anAlternate-Marking (coloring) technique. A report is provided in order to explain an example and show the method applicability. This technology can be applied in various situations, as detailed in this document, and could be considered Passive or Hybrid depending on the application.
 
RFC 8337 Model-Based Metrics for Bulk Transport Capacity
 
Authors:M. Mathis, A. Morton.
Date:March 2018
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 8337
This document introduces a new class of Model-Based Metrics designed to assess if a complete Internet path can be expected to meet a predefined Target Transport Performance by applying a suite of IP diagnostic tests to successive subpaths. The subpath-at-a-time tests can be robustly applied to critical infrastructure, such as network interconnections or even individual devices, to accurately detect if any part of the infrastructure will prevent paths traversing it from meeting the Target Transport Performance.

Model-Based Metrics rely on mathematical models to specify a TargetedIP Diagnostic Suite, a set of IP diagnostic tests designed to assess whether common transport protocols can be expected to meet a predetermined Target Transport Performance over an Internet path.

For Bulk Transport Capacity, the IP diagnostics are built using test streams and statistical criteria for evaluating the packet transfer that mimic TCP over the complete path. The temporal structure of the test stream (e.g., bursts) mimics TCP or other transport protocols carrying bulk data over a long path. However, they are constructed to be independent of the details of the subpath under test, end systems, or applications. Likewise, the success criteria evaluates the packet transfer statistics of the subpath against criteria determined by protocol performance models applied to the TargetTransport Performance of the complete path. The success criteria also does not depend on the details of the subpath, end systems, or applications.

 
RFC 8350 Alternate Tunnel Encapsulation for Data Frames in Control and Provisioning of Wireless Access Points (CAPWAP)
 
Authors:R. Zhang, R. Pazhyannur, S. Gundavelli, Z. Cao, H. Deng, Z. Du.
Date:April 2018
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 8350
Control and Provisioning of Wireless Access Points (CAPWAP) is a protocol for encapsulating a station's data frames between theWireless Transmission Point (WTP) and Access Controller (AC).Specifically, the station's IEEE 802.11 data frames can be either locally bridged or tunneled to the AC. When tunneled, a CAPWAP DataChannel is used for tunneling. In many deployments, encapsulating data frames to an entity other than the AC (for example, to an AccessRouter (AR)) is desirable. Furthermore, it may also be desirable to use different tunnel encapsulation modes between the WTP and theAccess Router. This document defines an extension to the CAPWAP protocol that supports this capability and refers to it as alternate tunnel encapsulation. The alternate tunnel encapsulation allows 1) the WTP to tunnel non-management data frames to an endpoint different from the AC and 2) the WTP to tunnel using one of many known encapsulation types, such as IP-IP, IP-GRE, or CAPWAP. The WTP may advertise support for alternate tunnel encapsulation during the discovery and join process, and the AC may select one of the supported alternate tunnel encapsulation types while configuring theWTP.
 
RFC 8364 PIM Flooding Mechanism (PFM) and Source Discovery (SD)
 
Authors:IJ. Wijnands, S. Venaas, M. Brig, A. Jonasson.
Date:March 2018
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 8364
Protocol Independent Multicast - Sparse Mode (PIM-SM) uses aRendezvous Point (RP) and shared trees to forward multicast packets from new sources. Once Last-Hop Routers (LHRs) receive packets from a new source, they may join the Shortest Path Tree (SPT) for the source for optimal forwarding. This document defines a new mechanism that provides a way to support PIM-SM without the need for PIM registers, RPs, or shared trees. Multicast source information is flooded throughout the multicast domain using a new generic PIMFlooding Mechanism (PFM). This allows LHRs to learn about new sources without receiving initial data packets.
 
RFC 8378 Signal-Free Locator/ID Separation Protocol (LISP) Multicast
 
Authors:V. Moreno, D. Farinacci.
Date:May 2018
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 8378
When multicast sources and receivers are active at Locator/IDSeparation Protocol (LISP) sites, the core network is required to use native multicast so packets can be delivered from sources to group members. When multicast is not available to connect the multicast sites together, a signal-free mechanism can be used to allow traffic to flow between sites. The mechanism described in this document uses unicast replication and encapsulation over the core network for the data plane and uses the LISP mapping database system so encapsulators at the source LISP multicast site can find decapsulators at the receiver LISP multicast sites.
 
RFC 8382 Shared Bottleneck Detection for Coupled Congestion Control for RTP Media
 
Authors:D. Hayes, Ed., S. Ferlin, M. Welzl, K. Hiorth.
Date:June 2018
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 8382
This document describes a mechanism to detect whether end-to-end data flows share a common bottleneck. This mechanism relies on summary statistics that are calculated based on continuous measurements and used as input to a grouping algorithm that runs wherever the knowledge is needed.
 
RFC 8424 Extensions to RSVP-TE for Label Switched Path (LSP) Ingress Fast Reroute (FRR) Protection
 
Authors:H. Chen, Ed., R. Torvi, Ed..
Date:August 2018
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 8424
This document describes extensions to Resource Reservation Protocol -Traffic Engineering (RSVP-TE) for locally protecting the ingress node of a Point-to-Point (P2P) or Point-to-Multipoint (P2MP) TrafficEngineered (TE) Label Switched Path (LSP). It extends the FastReroute (FRR) protection for transit nodes of an LSP to the ingress node of the LSP. The procedures described in this document are experimental.
 
RFC 8459 Hierarchical Service Function Chaining (hSFC)
 
Authors:D. Dolson, S. Homma, D. Lopez, M. Boucadair.
Date:September 2018
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 8459
Hierarchical Service Function Chaining (hSFC) is a network architecture allowing an organization to decompose a large-scale network into multiple domains of administration.

The goals of hSFC are to make a large-scale network easier to design, simpler to control, and supportive of independent functional groups within large network operators.

 
RFC 8467 Padding Policies for Extension Mechanisms for DNS (EDNS(0))
 
Authors:A. Mayrhofer.
Date:October 2018
Formats:txt pdf
Status:EXPERIMENTAL
DOI:10.17487/RFC 8467
RFC 7830 specifies the "Padding" option for Extension Mechanisms forDNS (EDNS(0)) but does not specify the actual padding length for specific applications. This memo lists the possible options("padding policies"), discusses the implications of each option, and provides a recommended (experimental) option.