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

RFC 698	Telnet extended ASCII option
	Authors: T. Mock. Date: July 1975 Formats: txt pdf Obsoleted by: RFC 5198 Status: PROPOSED STANDARD Describes an option to allow transmission of a special kind of extended ASCII used at the Stanford AI and MIT AI Labs.
RFC 726	Remote Controlled Transmission and Echoing Telnet option
	Authors: J. Postel, D. Crocker. Date: March 1977 Formats: txt pdf Status: PROPOSED STANDARD
RFC 727	Telnet logout option
	Authors: M.R. Crispin. Date: April 1977 Formats: txt pdf Status: PROPOSED STANDARD
RFC 735	Revised Telnet byte macro option
	Authors: D. Crocker, R.H. Gumpertz. Date: November 1977 Formats: txt pdf Obsoletes: RFC 0729 Status: PROPOSED STANDARD
RFC 736	Telnet SUPDUP option
	Authors: M.R. Crispin. Date: October 1977 Formats: txt pdf Status: PROPOSED STANDARD
RFC 749	Telnet SUPDUP-Output option
	Authors: B. Greenberg. Date: September 1978 Formats: txt pdf Status: PROPOSED STANDARD
RFC 779	Telnet send-location option
	Authors: E. Killian. Date: April 1981 Formats: txt pdf Status: PROPOSED STANDARD
RFC 885	Telnet end of record option
	Authors: J. Postel. Date: December 1983 Formats: txt pdf Status: PROPOSED STANDARD This RFC specifies a standard for the ARPA Internet community. It specifies a method for marking the end of records in data transmitted on Telnet connections.
RFC 927	TACACS user identification Telnet option
	Authors: B.A. Anderson. Date: December 1984 Formats: txt pdf Status: PROPOSED STANDARD The following is the description of a TELNET option designed to facilitate double login avoidance. It is intended primarily for TAC connections to target hosts on behalf of TAC users, but it can be used between any two consenting hosts. For example, all hosts at one site (e.g., BBN) can use this option to avoid double login when TELNETing to one another. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.
RFC 933	Output marking Telnet option
	Authors: S. Silverman. Date: January 1985 Formats: txt pdf Status: PROPOSED STANDARD This proposed option would allow a Server-Telnet to send a banner to a User-Telnet so that this banner would be displayed on the workstation screen independently of the application software running in the Server-Telnet.
RFC 946	Telnet terminal location number option
	Authors: R. Nedved. Date: May 1985 Formats: txt pdf Status: PROPOSED STANDARD Many systems provide a mechanism for finding out where a user is logged in from usually including information about telephone extension and office occupants names. The information is useful for physically locating people and/or calling them on the phone. In 1982 CMU designed and implemented a terminal location database and modified existing network software to handle a 64-bit number called the Terminal Location Number (or TTYLOC). It now seems appropriate to incorporate this mechanism into the TCP-based network protocol family. The mechanism is not viewed as a replacement for the Terminal Location Telnet Option (SEND-LOCATION) but as a shorthand mechansim for communicating terminal location information between hosts in a localized community. This RFC proposes a new option for Telnet for the ARPA-Internet community, and requests discussion and suggestions for improvements.
RFC 977	Network News Transfer Protocol
	Authors: B. Kantor, P. Lapsley. Date: February 1986 Formats: txt pdf Obsoleted by: RFC 3977 Status: PROPOSED STANDARD NNTP specifies a protocol for the distribution, inquiry, retrieval, and posting of news articles using a reliable stream-based transmission of news among the ARPA-Internet community. NNTP is designed so that news articles are stored in a central database allowing a subscriber to select only those items he wishes to read. Indexing, cross-referencing, and expiration of aged messages are also provided. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.
RFC 1041	Telnet 3270 regime option
	Authors: Y. Rekhter. Date: January 1988 Formats: txt pdf Updated by: RFC 6270 Status: PROPOSED STANDARD This RFC specifies a proposed standard for the Internet community. Hosts on the Internet that want to support 3270 data stream within the Telnet protocol, are expected to adopt and implement this standard.
RFC 1043	Telnet Data Entry Terminal option: DODIIS implementation
	Authors: A. Yasuda, T. Thompson. Date: February 1988 Formats: txt pdf Updates: RFC 0732 Status: PROPOSED STANDARD This RFC suggests a proposed protocol on the TELNET Data Entry Terminal (DET) Option - DODIIS Implementation for the Internet community. It is intended that this specification be capatible with the specification of DET Option in RFC-732. Discussion and suggests for improvements are encouraged.
RFC 1053	Telnet X.3 PAD option
	Authors: S. Levy, T. Jacobson. Date: April 1988 Formats: txt pdf Status: PROPOSED STANDARD This RFC proposes a new option to Telnet for the Internet community, and requests discussion and suggestions for improvements.
RFC 1073	Telnet window size option
	Authors: D. Waitzman. Date: October 1988 Formats: txt pdf Status: PROPOSED STANDARD This RFC describes a proposed Telnet option to allow a client to convey window size to a Telnet server.
RFC 1079	Telnet terminal speed option
	Authors: C.L. Hedrick. Date: December 1988 Formats: txt pdf Status: PROPOSED STANDARD This RFC specifies a standard for the Internet community. Hosts on the Internet that exchange terminal speed information within the Telnet protocol are expected to adopt and implement this standard.
RFC 1091	Telnet terminal-type option
	Authors: J. VanBokkelen. Date: February 1989 Formats: txt pdf Obsoletes: RFC 0930 Status: PROPOSED STANDARD This RFC specifies a standard for the Internet community. Hosts on the Internet that exchange terminal type information within the Telnet protocol are expected to adopt and implement this standard. This standard supersedes RFC 930. A change is made to permit cycling through a list of possible terminal types and selecting the most appropriate
RFC 1096	Telnet X display location option
	Authors: G.A. Marcy. Date: March 1989 Formats: txt pdf Status: PROPOSED STANDARD This RFC specifies a standard for the Internet community. Hosts on the Internet that transmit the X display location within the Telnet protocol are expected to adopt and implement this standard.
RFC 1116	Telnet Linemode option
	Authors: D.A. Borman. Date: August 1989 Formats: txt pdf Obsoleted by: RFC 1184 Status: PROPOSED STANDARD Hosts on the Internet that support Linemode within the Telnet protocol are expected to adopt and implement this protocol. Obsoleted by RFC 1184. [STANDARDS-TRACK]
RFC 1131	OSPF specification
	Authors: J. Moy. Date: October 1989 Formats: txt pdf ps Obsoleted by: RFC 1247 Status: PROPOSED STANDARD This RFC is the specification of the Open Shortest Path First (OSPF) Internet routing protocol. OSPF is in the class of Internal Gateway Protocols (IGPs) for distributing routing information between gateways of a single Autonomous System. This routing protocol is based on the link-state approach (in contrast to the distance-vector approach). This specification was developed by the OSPF Working Group of the Internet Engineering Task Force. [STANDARDS-TRACK]
RFC 1134	Point-to-Point Protocol: A proposal for multi-protocol transmission of datagrams over Point-to-Point links
	Authors: D. Perkins. Date: November 1989 Formats: txt pdf Obsoleted by: RFC 1171 Status: PROPOSED STANDARD The Point-to-Point Protocol (PPP) provides a method for transmitting datagrams over serial point-to-point links. PPP is composed of three parts: 1. A method for encapsulating datagrams over serial links. 2. An extensible Link Control Protocol (LCP). 3. A family of Network Control Protocols (NCP) for establishing and configuring different network-layer protocols. This document defines the encapsulation scheme, the basic LCP, and anNCP for establishing and configuring the Internet Protocol (IP)(called the IP Control Protocol, IPCP). The options and facilities used by the LCP and the IPCP are defined in separate documents. Control protocols for configuring and utilizing other network-layer protocols besides IP (e.g., DECNET,OSI) are expected to be developed as needed.
RFC 1139	Echo function for ISO 8473
	Authors: R.A. Hagens. Date: January 1990 Formats: txt pdf Obsoleted by: RFC 1574, RFC 1575 Status: PROPOSED STANDARD This memo defines an echo function for the connection-less network layer protocol. Two mechanisms are introduced that may be used to implement the echo function. The first mechanism is recommended as an interim solution for the Internet community. The second mechanism will be progressed to the ANSI X3S3.3 working group for consideration as a work item. When an ISO standard is adopted that provides functionality similar to that described by this memo, then this memo will become obsolete and superceded by the ISO standard.
RFC 1144	Compressing TCP/IP Headers for Low-Speed Serial Links
	Authors: V. Jacobson. Date: February 1990 Formats: txt pdf ps Status: PROPOSED STANDARD This RFC describes a method for compressing the headers of TCP/IP datagrams to improve performance over low speed serial links. The motivation, implementation and performance of the method are described. C code for a sample implementation is given for reference. [STANDARDS- TRACK]
RFC 1158	Management Information Base for network management of TCP/IP-based internets: MIB-II
	Authors: M.T. Rose. Date: May 1990 Formats: txt pdf Obsoleted by: RFC 1213 Status: PROPOSED STANDARD This memo defines the second version of the Management Information Base (MIB-II) for use with network management protocols in TCP/IP- based internets. In particular, together with its companion memos which describe the structure of management information (RFC 1155) along with the network management protocol (RFC 1157) for TCP/IP- based internets, these documents provide a simple, workable architecture and system for managing TCP/IP-based internets and in particular the Internet community. This document on MIB-II incorporates all of the technical content of RFC 1156 on MIB-I and extends it, without loss of compatibilty. [STANDARDS-TRACK]
RFC 1172	Point-to-Point Protocol (PPP) initial configuration options
	Authors: D. Perkins, R. Hobby. Date: July 1990 Formats: txt pdf Obsoleted by: RFC 1331, RFC 1332 Status: PROPOSED STANDARD The Point-to-Point Protocol (PPP) provides a method for transmitting datagrams over serial point-to-point links. PPP is composed of 1) a method for encapsulating datagrams over serial links,2) an extensible Link Control Protocol (LCP), and3) a family of Network Control Protocols (NCP) for establishing and configuring different network-layer protocols. The PPP encapsulating scheme, the basic LCP, and an NCP for controlling and establishing the Internet Protocol (IP) (called theIP Control Protocol, IPCP) are defined in The Point-to-Point Protocol(PPP) [1]. This document defines the intial options used by the LCP and IPCP. It also defines a method of Link Quality Monitoring and a simple authentication scheme.
RFC 1195	Use of OSI IS-IS for routing in TCP/IP and dual environments
	Authors: R.W. Callon. Date: December 1990 Formats: txt pdf ps Updated by: RFC 1349, RFC 5302, RFC 5304 Status: PROPOSED STANDARD This RFC specifies an integrated routing protocol, based on the OSIIntra-Domain IS-IS Routing Protocol, which may be used as an interior gateway protocol (IGP) to support TCP/IP as well as OSI. This allows a single routing protocol to be used to support pure IP environments, pure OSI environments, and dual environments. This specification was developed by the IS-IS working group of the Internet Engineering TaskForce. The OSI IS-IS protocol has reached a mature state, and is ready for implementation and operational use. The most recent version of theOSI IS-IS protocol is contained in ISO DP 10589 [1]. The proposed standard for using IS-IS for support of TCP/IP will therefore make use of this version (with a minor bug correction, as discussed inAnnex B). We expect that future versions of this proposed standard will upgrade to the final International Standard version of IS-IS when available. Comments should be sent to "isis@merit.edu".
RFC 1220	Point-to-Point Protocol extensions for bridging
	Authors: F. Baker. Date: April 1991 Formats: txt pdf Obsoleted by: RFC 1638 Status: PROPOSED STANDARD This document defines an extension of the Internet Point-to-Point Protocol (PPP) described in RFC 1171, targeting the use of Point-to- Point lines for Remote Bridging. [STANDARDS-TRACK]
RFC 1229	Extensions to the generic-interface MIB
	Authors: K. McCloghrie. Date: May 1991 Formats: txt pdf Obsoleted by: RFC 1573 Updated by: RFC 1239 Status: PROPOSED STANDARD This RFC contains definitions of managed objects used as experimental extensions to the generic interfaces structure of MIB-II. [STANDARDS- TRACK]
RFC 1231	IEEE 802.5 Token Ring MIB
	Authors: K. McCloghrie, R. Fox, E. Decker. Date: May 1991 Formats: txt pdf Obsoleted by: RFC 1743, RFC 1748 Updated by: RFC 1239 Status: PROPOSED STANDARD This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, this memo defines managed objects used for managing subnetworks which use the IEEE 802.5 Token Ring technology described in 802.5 Token Ring Access Method and Physical Layer Specifications, IEEE Standard 802.5-1989. [STANDARDS-TRACK]
RFC 1232	Definitions of managed objects for the DS1 Interface type
	Authors: F. Baker, C.P. Kolb. Date: May 1991 Formats: txt pdf Obsoleted by: RFC 1406 Updated by: RFC 1239 Status: PROPOSED STANDARD
RFC 1233	Definitions of managed objects for the DS3 Interface type
	Authors: T.A. Cox, K. Tesink. Date: May 1991 Formats: txt pdf Obsoleted by: RFC 1407 Updated by: RFC 1239 Status: PROPOSED STANDARD This memo defines objects for managing DS3 Interface objects for use with the SNMP protocol. [STANDARDS-TRACK]
RFC 1237	Guidelines for OSI NSAP Allocation in the Internet
	Authors: R. Colella, E. Gardner, R. Callon. Date: July 1991 Formats: txt pdf ps Obsoleted by: RFC 1629 Status: PROPOSED STANDARD This paper provides guidelines for allocating NSAPs in the Internet.[STANDARDS-TRACK]
RFC 1243	AppleTalk Management Information Base
	Authors: S. Waldbusser. Date: July 1991 Formats: txt pdf Obsoleted by: RFC 1742 Status: PROPOSED STANDARD This memo defines objects for managing AppleTalk objects for use with the SNMP protocol. [STANDARDS-TRACK]
RFC 1248	OSPF Version 2 Management Information Base
	Authors: F. Baker, R. Coltun. Date: July 1991 Formats: txt pdf Obsoleted by: RFC 1252 Updated by: RFC 1349 Status: PROPOSED STANDARD This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing OSPF Version 2. [STANDARDS-TRACK]
RFC 1252	OSPF Version 2 Management Information Base
	Authors: F. Baker, R. Coltun. Date: August 1991 Formats: txt pdf Obsoletes: RFC 1248 Obsoleted by: RFC 1253 Also: RFC 1247, RFC 1245 Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing OSPF Version 2. [STANDARDS- TRACK]
RFC 1253	OSPF Version 2 Management Information Base
	Authors: F. Baker, R. Coltun. Date: August 1991 Formats: txt pdf Obsoletes: RFC 1252 Obsoleted by: RFC 1850 Also: RFC 1247, RFC 1245, RFC 1246 Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing OSPF Version 2. [STANDARDS- TRACK]
RFC 1256	ICMP Router Discovery Messages
	Authors: S. Deering, Ed.. Date: September 1991 Formats: txt pdf Also: RFC 0792 Status: PROPOSED STANDARD This document specifies an extension of the Internet Control MessageProtocol (ICMP) to enable hosts attached to multicast or broadcast networks to discover the IP addresses of their neighboring routers.
RFC 1269	Definitions of Managed Objects for the Border Gateway Protocol: Version 3
	Authors: S. Willis, J.W. Burruss. Date: October 1991 Formats: txt pdf Obsoleted by: RFC 4273 Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the Border Gateway Protocol. [STANDARDS-TRACK]
RFC 1271	Remote Network Monitoring Management Information Base
	Authors: S. Waldbusser. Date: November 1991 Formats: txt pdf Obsoleted by: RFC 1757 Updated by: RFC 1513 Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing remote network monitoring devices. [STANDARDS-TRACK]
RFC 1274	The COSINE and Internet X.500 Schema
	Authors: P. Barker, S. Kille. Date: November 1991 Formats: txt pdf Obsoleted by: RFC 4524 Status: PROPOSED STANDARD This document suggests an X.500 Directory Schema, or NamingArchitecture, for use in the COSINE and Internet X.500 pilots. The schema is independent of any specific implementation. As well as indicating support for the standard object classes and attributes, a large number of generally useful object classes and attributes are also defined. An appendix to this document includes a machine processable version of the schema. This document also proposes a mechanism for allowing the schema to evolve in line with emerging requirements. Proformas to support this process are included. Corrections and additions to the schema should be sent to na- update@cs.ucl.ac.uk list, as described within.
RFC 1277	Encoding Network Addresses to Support Operation over Non-OSI Lower Layers
	Authors: S.E. Hardcastle-Kille. Date: November 1991 Formats: txt ps pdf Status: PROPOSED STANDARD The OSI Directory specifies an encoding of Presentation Address, which utilises OSI Network Addresses as defined in the OSINetwork Layer standards [CCI88] [ISO87a]. The OSI Directory, and any OSI application utilising the OSI Directory must be able use these Network Addresses to identify end systems. Currently, OSI applications are often run over lower layers other than the OSINetwork Service. It is neither reasonable nor desirable for groups wishing to investigate and use OSI Applications in conjunction with the OSI Directory to be dependent on a globalOSI Network Service. This document defines a new network address format, and rules for using some existing network address formats. The scope of this document is:
RFC 1284	Definitions of Managed Objects for the Ethernet-like Interface Types
	Authors: J. Cook, Ed.. Date: December 1991 Formats: txt pdf Obsoleted by: RFC 1398 Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing ethernet-like objects. [STANDARDS-TRACK]
RFC 1286	Definitions of Managed Objects for Bridges
	Authors: E. Decker, P. Langille, A. Rijsinghani, K. McCloghrie. Date: December 1991 Formats: txt pdf Obsoleted by: RFC 1493, RFC 1525 Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular it defines objects for managing bridges based on the IEEE 802.1d draft standard between Local Area Network (LAN) segments. This memo is an extension to the SNMP MIB. [STANDARDS-TRACK]
RFC 1289	DECnet Phase IV MIB Extensions
	Authors: J. Saperia. Date: December 1991 Formats: txt pdf Obsoleted by: RFC 1559 Status: PROPOSED STANDARD This memo defines a set of DECnet Phase IV extensions that have been created for the Internet MIB. When used in conjunction with the structure of management information (RFC 1155), the management information base for network management of TCP/IP-based internets(RFC 1213) and the Simple Network Management Protocol (RFC 1157), it will be possible to provide integrated network management of combinedTCP/IP and DECnet Phase IV based internets. This document was produced by the DECnet Phase IV MIB working group of the InternetEngineering Task Force (IETF).
RFC 1293	Inverse Address Resolution Protocol
	Authors: T. Bradley, C. Brown. Date: January 1992 Formats: txt pdf Obsoleted by: RFC 2390 Status: PROPOSED STANDARD This memo describes additions to ARP that will allow a station to request a protocol address corresponding to a given hardware address. [STANDARDS-TRACK]
RFC 1294	Multiprotocol Interconnect over Frame Relay
	Authors: T. Bradley, C. Brown, A. Malis. Date: January 1992 Formats: txt pdf Obsoleted by: RFC 1490, RFC 2427 Status: PROPOSED STANDARD This memo describes an encapsulation method for carrying network interconnect traffic over a Frame Relay backbone. It covers aspects of both Bridging and Routing. [STANDARDS-TRACK]
RFC 1304	Definitions of Managed Objects for the SIP Interface Type
	Authors: T. Cox, K. Tesink, Eds.. Date: February 1992 Formats: txt pdf Obsoleted by: RFC 1694 Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it defines objects for managing SIP (SMDS InterfaceProtocol) objects.
RFC 1315	Management Information Base for Frame Relay DTEs
	Authors: C. Brown, F. Baker, C. Carvalho. Date: April 1992 Formats: txt pdf Obsoleted by: RFC 2115 Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it defines objects for managing Frame Relay.
RFC 1316	Definitions of Managed Objects for Character Stream Devices
	Authors: B. Stewart. Date: April 1992 Formats: txt pdf Obsoleted by: RFC 1658 Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular it defines objects for the management of character stream devices. [STANDARDS-TRACK]
RFC 1317	Definitions of Managed Objects for RS-232-like Hardware Devices
	Authors: B. Stewart. Date: April 1992 Formats: txt pdf Obsoleted by: RFC 1659 Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular, it defines objects for the management of RS-232-like devices. [STANDARDS-TRACK]
RFC 1318	Definitions of Managed Objects for Parallel-printer-like Hardware Devices
	Authors: B. Stewart. Date: April 1992 Formats: txt pdf Obsoleted by: RFC 1660 Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular, it defines objects for the management of parallel-printer- like devices. [STANDARDS-TRACK]
RFC 1323	TCP Extensions for High Performance
	Authors: V. Jacobson, R. Braden, D. Borman. Date: May 1992 Formats: txt pdf Obsoletes: RFC 1072, RFC 1185 Status: PROPOSED STANDARD This memo presents a set of TCP extensions to improve performance over large bandwidth*delay product paths and to provide reliable operation over very high-speed paths. It defines new TCP options for scaled windows and timestamps, which are designed to provide compatible interworking with TCP's that do not implement the extensions. The timestamps are used for two distinct mechanisms:RTTM (Round Trip Time Measurement) and PAWS (Protect Against WrappedSequences). Selective acknowledgments are not included in this memo. This memo combines and supersedes RFC-1072 and RFC-1185, adding additional clarification and more detailed specification. Appendix C summarizes the changes from the earlier RFCs.
RFC 1327	Mapping between X.400(1988) / ISO 10021 and RFC 822
	Authors: S. Hardcastle-Kille. Date: May 1992 Formats: txt pdf Obsoletes: RFC 0987, RFC 1026, RFC 1138, RFC 1148 Obsoleted by: RFC 2156 Updates: RFC 0822 Updated by: RFC 1495 Status: PROPOSED STANDARD This document describes a set of mappings which will enable interworking between systems operating the CCITT X.400 1988)Recommendations on Message Handling Systems / ISO IEC 10021 MessageOriented Text Interchange Systems (MOTIS) [CCITT/ISO88a], and systems using the RFC 822 mail protocol [Crocker82a] or protocols derived from RFC 822. The approach aims to maximise the services offered across the boundary, whilst not requiring unduly complex mappings.The mappings should not require any changes to end systems. This document is a revision based on RFCs 987, 1026, 1138, and 1148[Kille86a,Kille87a] which it obsoletes. This document specifies a mapping between two protocols. This specification should be used when this mapping is performed on theDARPA Internet or in the UK Academic Community. This specification may be modified in the light of implementation experience, but no substantial changes are expected.
RFC 1331	The Point-to-Point Protocol (PPP) for the Transmission of Multi-protocol Datagrams over Point-to-Point Links
	Authors: W. Simpson. Date: May 1992 Formats: txt pdf Obsoletes: RFC 1171, RFC 1172 Obsoleted by: RFC 1548 Status: PROPOSED STANDARD The Point-to-Point Protocol (PPP) provides a method for transmitting datagrams over serial point-to-point links. PPP is comprised of three main components: 1. A method for encapsulating datagrams over serial links. 2. A Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection. 3. A family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. This document defines the PPP encapsulation scheme, together with thePPP Link Control Protocol (LCP), an extensible option negotiation protocol which is able to negotiate a rich assortment of configuration parameters and provides additional management functions. This RFC is a product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). Comments on this memo should be submitted to the ietf-ppp@ucdavis.edu mailing list.
RFC 1332	The PPP Internet Protocol Control Protocol (IPCP)
	Authors: G. McGregor. Date: May 1992 Formats: txt pdf Obsoletes: RFC 1172 Updated by: RFC 3241 Status: PROPOSED STANDARD The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. This document defines the NCP for establishing and configuring theInternet Protocol [2] over PPP, and a method to negotiate and use VanJacobson TCP/IP header compression [3] with PPP. This RFC is a product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF).
RFC 1333	PPP Link Quality Monitoring
	Authors: W. Simpson. Date: May 1992 Formats: txt pdf Obsoleted by: RFC 1989 Status: PROPOSED STANDARD The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, which allows negotiation of a Quality Protocol for continuous monitoring of the viability of the link. This document defines a protocol for generating Link-Quality-Reports. This RFC is a product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). Comments on this memo should be submitted to the ietf-ppp@ucdavis.edu mailing list.
RFC 1334	PPP Authentication Protocols
	Authors: B. Lloyd, W. Simpson. Date: October 1992 Formats: txt pdf Obsoleted by: RFC 1994 Status: PROPOSED STANDARD The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, which allows negotiation of an Authentication Protocol for authenticating its peer before allowing Network Layer protocols to transmit over the link. This document defines two protocols for Authentication: the PasswordAuthentication Protocol and the Challenge-Handshake AuthenticationProtocol. This memo is the product of the Point-to-Point ProtocolWorking Group of the Internet Engineering Task Force (IETF).Comments on this memo should be submitted to the ietf-ppp@ucdavis.edu mailing list.
RFC 1341	MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies
	Authors: N. Borenstein, N. Freed. Date: June 1992 Formats: txt pdf ps Obsoleted by: RFC 1521 Status: PROPOSED STANDARD This document redefines the format of message bodies to allow multi-part textual and non-textual message bodies to be represented and exchanged without loss of information. [STANDARDS-TRACK]
RFC 1342	Representation of Non-ASCII Text in Internet Message Headers
	Authors: K. Moore. Date: June 1992 Formats: txt pdf Obsoleted by: RFC 1522 Status: PROPOSED STANDARD This memo describes an extension to the message format defined in [1](known to the IETF Mail Extensions Working Group as "RFC 1341"), to allow the representation of character sets other than ASCII in RFC822 message headers. The extensions described were designed to be highly compatible with existing Internet mail handling software, and to be easily implemented in mail readers that support RFC 1341.
RFC 1349	Type of Service in the Internet Protocol Suite
	Authors: P. Almquist. Date: July 1992 Formats: txt pdf Obsoleted by: RFC 2474 Updates: RFC 1248, RFC 1247, RFC 1195, RFC 1123, RFC 1122, RFC 1060, RFC 0791 Status: PROPOSED STANDARD This memo changes and clarifies some aspects of the semantics of the Type of Service octet in the Internet Protocol (IP) header. [STANDARDS-TRACK]
RFC 1354	IP Forwarding Table MIB
	Authors: F. Baker. Date: July 1992 Formats: txt pdf Obsoleted by: RFC 2096 Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it defines objects for managing routes in the IPInternet. It is proposed that the ipRouteTable defined by MIB-II (RFC 1213) be deprecated and replaced with this table. This adds the ability to set or display multi-path routes, and varying routes by network management policy.
RFC 1364	BGP OSPF Interaction
	Authors: K. Varadhan. Date: September 1992 Formats: txt pdf Obsoleted by: RFC 1403 Also: RFC 1247, RFC 1267 Status: PROPOSED STANDARD This memo defines the various criteria to be used when designingAutonomous System Border Routers (ASBR) that will run BGP with otherASBRs external to the AS and OSPF as its IGP.
RFC 1368	Definition of Managed Objects for IEEE 802.3 Repeater Devices
	Authors: D. McMaster, K. McCloghrie. Date: October 1992 Formats: txt pdf Obsoleted by: RFC 1516 Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it defines objects for managing IEEE 802.3 10Mb/second baseband repeaters, sometimes referred to as "hubs."
RFC 1372	Telnet Remote Flow Control Option
	Authors: C. Hedrick, D. Borman. Date: October 1992 Formats: txt pdf Obsoletes: RFC 1080 Status: PROPOSED STANDARD This document specifies an extended version of the Telnet Remote Flow Control Option, RFC 1080, with the addition of the RESTART-ANY and RESTART-XON suboptions. [STANDARDS-TRACK]
RFC 1374	IP and ARP on HIPPI
	Authors: J. Renwick, A. Nicholson. Date: October 1992 Formats: txt pdf Obsoleted by: RFC 2834 Status: PROPOSED STANDARD The ANSI X3T9.3 committee has drafted a proposal for the encapsulation of IEEE 802.2 LLC PDUs and, by implication, IP onHIPPI. Another X3T9.3 draft describes the operation of HIPPI physical switches. X3T9.3 chose to leave HIPPI networking issues largely outside the scope of their standards; this document discusses methods of using of ANSI standard HIPPI hardware and protocols in the context of the Internet, including the use of HIPPI switches as LANs and interoperation with other networks.
RFC 1376	The PPP DECnet Phase IV Control Protocol (DNCP)
	Authors: S. Senum. Date: November 1992 Formats: txt pdf Obsoleted by: RFC 1762 Status: PROPOSED STANDARD The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. This document defines the NCP for establishing and configuringDigital's DNA Phase IV Routing protocol (DECnet Phase IV) over PPP.This document applies only to DNA Phase IV Routing messages (both data and control), and not to other DNA Phase IV protocols (MOP, LAT, etc.).
RFC 1377	The PPP OSI Network Layer Control Protocol (OSINLCP)
	Authors: D. Katz. Date: November 1992 Formats: txt pdf Status: PROPOSED STANDARD The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. This document defines the NCP for establishing and configuring OSINetwork Layer Protocols. This memo is the product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). Comments on this memo should be submitted to the ietf-ppp@ucdavis.edu mailing list.
RFC 1381	SNMP MIB Extension for X.25 LAPB
	Authors: D. Throop, F. Baker. Date: November 1992 Formats: txt pdf Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it defines objects for managing the Link Layer ofX.25, LAPB. The objects defined here, along with the objects in the"SNMP MIB Extension for the Packet Layer of X.25" [9] and the"Definitions of Managed Objects for RS-232-like Hardware Devices"[8], combine to allow management of an X.25 protocol stack.
RFC 1382	SNMP MIB Extension for the X.25 Packet Layer
	Authors: D. Throop, Ed.. Date: November 1992 Formats: txt pdf Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it defines objects for managing the Packet Layer ofX.25. The objects defined here, along with the objects in the "SNMPMIB Extension for LAPB" [9] and the "Definitions of Managed Objects for RS-232-like Hardware Devices" [8], combine to allow management of an X.25 protocol stack.
RFC 1388	RIP Version 2 Carrying Additional Information
	Authors: G. Malkin. Date: January 1993 Formats: txt pdf Obsoleted by: RFC 1723 Updates: RFC 1058 Status: PROPOSED STANDARD This document specifies an extension of the Routing InformationProtocol (RIP), as defined in [1], to expand the amount of useful information carried in RIP packets and to add a measure of security.A companion document will define the SNMP MIB objects for RIP-2 [2].
RFC 1389	RIP Version 2 MIB Extensions
	Authors: G. Malkin, F. Baker. Date: January 1993 Formats: txt pdf Obsoleted by: RFC 1724 Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it defines objects for managing RIP Version 2.
RFC 1406	Definitions of Managed Objects for the DS1 and E1 Interface Types
	Authors: F. Baker, J. Watt, Eds.. Date: January 1993 Formats: txt pdf Obsoletes: RFC 1232 Obsoleted by: RFC 2495 Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it defines objects for managing DS1 Interfaces -- including both T1 and E1 (a.k.a., CEPT 2 Mbit/s) links. This document entirely replaces RFC 1232, which contains a fundamental error: many objects are encoded as Counters that must be encoded as INTEGERs or Gauges. The magnitude of the change required is sufficient that virtually every object changed. Therefore, theMIB documented in RFC 1232 should not be implemented.
RFC 1407	Definitions of Managed Objects for the DS3/E3 Interface Type
	Authors: T. Cox, K. Tesink. Date: January 1993 Formats: txt pdf Obsoletes: RFC 1233 Obsoleted by: RFC 2496 Status: PROPOSED STANDARD This memo defines an extension to the Management Information Base(MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing DS3 and E3Interfaces. This document is a companion document with Definitions of Managed Objects for the DS1 Interface Type. This document entirely replaces RFC 1233, which contains a fundamental error: many objects are encoded as Counters that must be encoded as INTEGERs or Gauges. The magnitude of the change required is sufficient that virtually every object changed. Therefore, theMIB documented in RFC 1233 should not be implemented.
RFC 1413	Identification Protocol
	Authors: M. St. Johns. Date: February 1993 Formats: txt pdf Obsoletes: RFC 0931 Status: PROPOSED STANDARD The Identification Protocol was formerly called the Authentication Server Protocol. It has been renamed to better reflect its function. [STANDARDS-TRACK]
RFC 1420	SNMP over IPX
	Authors: S. Bostock. Date: March 1993 Formats: txt pdf Obsoletes: RFC 1298 Status: PROPOSED STANDARD This document defines a convention for encapsulating Simple NetworkManagement Protocol (SNMP) [1] packets over the transport mechanism provided via the Internetwork Packet Exchange (IPX) protocol [2].
RFC 1425	SMTP Service Extensions
	Authors: J. Klensin, WG Chair, N. Freed, Ed., M. Rose, E. Stefferud, D. Crocker. Date: February 1993 Formats: txt pdf Obsoleted by: RFC 1651 Status: PROPOSED STANDARD This memo defines a framework for extending the SMTP service by defining a means whereby a server SMTP can inform a client SMTP as to the service extensions it supports. [STANDARDS-TRACK]
RFC 1426	SMTP Service Extension for 8bit-MIMEtransport
	Authors: J. Klensin, WG Chair, N. Freed, Ed., M. Rose, E. Stefferud, D. Crocker. Date: February 1993 Formats: txt pdf Obsoleted by: RFC 1652 Status: PROPOSED STANDARD This memo defines an extension to the SMTP service whereby an SMTP content body containing octets outside of the US ASCII octet range (hex
RFC 1427	SMTP Service Extension for Message Size Declaration
	Authors: J. Klensin, WG Chair, N. Freed, Ed., K. Moore. Date: February 1993 Formats: txt pdf Obsoleted by: RFC 1653 Status: PROPOSED STANDARD This memo defines an extension to the SMTP service whereby an SMTP client and server may interact to give the server an opportunity to decline to accept a message (perhaps temporarily) based on the client's estimate of the message size. [STANDARDS-TRACK]
RFC 1442	Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2)
	Authors: J. Case, K. McCloghrie, M. Rose, S. Waldbusser. Date: April 1993 Formats: txt pdf Obsoleted by: RFC 1902 Status: PROPOSED STANDARD Management information is viewed as a collection of managed objects, residing in a virtual information store, termed the Management Information Base (MIB). Collections of related objects are defined in MIB modules. These modules are written using a subset of OSI's Abstract Syntax Notation One (ASN.1) [1]. It is the purpose of this document, the Structure of Management Information (SMI), to define that subset. [STANDARDS-TRACK]
RFC 1443	Textual Conventions for version 2 of the Simple Network Management Protocol (SNMPv2)
	Authors: J. Case, K. McCloghrie, M. Rose, S. Waldbusser. Date: April 1993 Formats: txt pdf Obsoleted by: RFC 1903 Status: PROPOSED STANDARD It is the purpose of this document to define the initial set of textual conventions available to all MIB modules. [STANDARDS-TRACK]
RFC 1444	Conformance Statements for version 2 of the Simple Network Management Protocol (SNMPv2)
	Authors: J. Case, K. McCloghrie, M. Rose, S. Waldbusser. Date: April 1993 Formats: txt pdf Obsoleted by: RFC 1904 Status: PROPOSED STANDARD It may be useful to define the acceptable lower-bounds of implementation, along with the actual level of implementation achieved. It is the purpose of this document to define the notation used for these purposes. [STANDARDS-TRACK]
RFC 1448	Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2)
	Authors: J. Case, K. McCloghrie, M. Rose, S. Waldbusser. Date: April 1993 Formats: txt pdf Obsoleted by: RFC 1905 Status: PROPOSED STANDARD It is the purpose of this document, Protocol Operations for SNMPv2, to define the operations of the protocol with respect to the sending and receiving of the PDUs. [STANDARDS-TRACK]
RFC 1449	Transport Mappings for version 2 of the Simple Network Management Protocol (SNMPv2)
	Authors: J. Case, K. McCloghrie, M. Rose, S. Waldbusser. Date: April 1993 Formats: txt pdf Obsoleted by: RFC 1906 Status: PROPOSED STANDARD It is the purpose of this document to define how the SNMPv2 maps onto an initial set of transport domains. [STANDARDS-TRACK]
RFC 1450	Management Information Base for version 2 of the Simple Network Management Protocol (SNMPv2)
	Authors: J. Case, K. McCloghrie, M. Rose, S. Waldbusser. Date: April 1993 Formats: txt pdf Obsoleted by: RFC 1907 Status: PROPOSED STANDARD It is the purpose of this document to define managed objects which describe the behavior of a SNMPv2 entity. [STANDARDS-TRACK]
RFC 1452	Coexistence between version 1 and version 2 of the Internet-standard Network Management Framework
	Authors: J. Case, K. McCloghrie, M. Rose, S. Waldbusser. Date: April 1993 Formats: txt pdf Obsoleted by: RFC 1908 Status: PROPOSED STANDARD The purpose of this document is to describe coexistence between version 2 of the Internet-standard Network Management Framework, termed the SNMP version 2 framework (SNMPv2) [1], and the original Internet-standard Network Management Framework (SNMPv1). [STANDARDS-TRACK]
RFC 1471	The Definitions of Managed Objects for the Link Control Protocol of the Point-to-Point Protocol
	Authors: F. Kastenholz. Date: June 1993 Formats: txt pdf Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it describes managed objects used for managing theLink Control Protocol and Link Quality Monitoring on subnetwork interfaces that use the family of Point-to-Point Protocols [8, 9, 10,11, & 12].
RFC 1472	The Definitions of Managed Objects for the Security Protocols of the Point-to-Point Protocol
	Authors: F. Kastenholz. Date: June 1993 Formats: txt pdf Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it describes managed objects used for managing theSecurity Protocols on subnetwork interfaces using the family ofPoint-to-Point Protocols [8, 9, 10, 11, & 12].
RFC 1473	The Definitions of Managed Objects for the IP Network Control Protocol of the Point-to-Point Protocol
	Authors: F. Kastenholz. Date: June 1993 Formats: txt pdf Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it describes managed objects used for managing the IPNetwork Control Protocol on subnetwork interfaces using the family ofPoint-to-Point Protocols [8, 9, 10, 11, & 12].
RFC 1483	Multiprotocol Encapsulation over ATM Adaptation Layer 5
	Authors: Juha Heinanen. Date: July 1993 Formats: txt pdf Obsoleted by: RFC 2684 Status: PROPOSED STANDARD This memo describes two encapsulations methods for carrying network interconnect traffic over ATM AAL5. The first method allows multiplexing of multiple protocols over a single ATM virtual circuit whereas the second method assumes that each protocol is carried over a separate ATM virtual circuit.
RFC 1488	The X.500 String Representation of Standard Attribute Syntaxes
	Authors: T. Howes, S. Kille, W. Yeong, C. Robbins. Date: July 1993 Formats: txt pdf Obsoleted by: RFC 1778 Status: PROPOSED STANDARD The Lightweight Directory Access Protocol (LDAP) [9] requires that the contents of AttributeValue fields in protocol elements be octet strings. This document defines the requirements that must be satisfied by encoding rules used to render Directory attribute syntaxes into a form suitable for use in the LDAP, then goes on to define the encoding rules for the standard set of attribute syntaxes defined in [1,2] and [3].
RFC 1495	Mapping between X.400 and RFC-822 Message Bodies
	Authors: H. Alvestrand, S. Kille, R. Miles, M. Rose, S. Thompson. Date: August 1993 Formats: txt pdf Obsoleted by: RFC 2156 Updates: RFC 1327 Status: PROPOSED STANDARD Since the introduction of X.400(84), there has been work ongoing for defining mappings between MHS and RFC-822. The most recent work in this area is RFC-1327 [3], which focuses primarily on translation of envelope and headers. This document is complimentary to RFC-1327 as it focuses on translation of the message body. [STANDARDS-TRACK]
RFC 1508	Generic Security Service Application Program Interface
	Authors: J. Linn. Date: September 1993 Formats: txt pdf Obsoleted by: RFC 2078 Status: PROPOSED STANDARD This Generic Security Service Application Program Interface (GSS-API) definition provides security services to callers in a generic fashion, supportable with a range of underlying mechanisms and technologies and hence allowing source-level portability of applications to different environments. This specification definesGSS-API services and primitives at a level independent of underlying mechanism and programming language environment, and is to be complemented by other, related specifications: documents defining specific parameter bindings for particular language environments documents defining token formats, protocols, and procedures to be implemented in order to realize GSS-API services atop particular security mechanisms
RFC 1509	Generic Security Service API : C-bindings
	Authors: J. Wray. Date: September 1993 Formats: txt pdf Obsoleted by: RFC 2744 Status: PROPOSED STANDARD This document specifies C language bindings for the Generic SecurityService Application Program Interface (GSS-API), which is described at a language-independent conceptual level in other documents. The Generic Security Service Application Programming Interface (GSS-API) provides security services to its callers, and is intended for implementation atop alternative underlying cryptographic mechanisms.Typically, GSS-API callers will be application protocols into which security enhancements are integrated through invocation of services provided by the GSS-API. The GSS-API allows a caller application to authenticate a principal identity associated with a peer application, to delegate rights to a peer, and to apply security services such as confidentiality and integrity on a per-message basis.
RFC 1510	The Kerberos Network Authentication Service (V5)
	Authors: J. Kohl, C. Neuman. Date: September 1993 Formats: txt pdf Obsoleted by: RFC 4120 Status: PROPOSED STANDARD This document gives an overview and specification of Version 5 of the protocol for the Kerberos network authentication system. Version 4, described elsewhere [1,2], is presently in production use at MIT'sProject Athena, and at other Internet sites.
RFC 1514	Host Resources MIB
	Authors: P. Grillo, S. Waldbusser. Date: September 1993 Formats: txt pdf Obsoleted by: RFC 2790 Status: PROPOSED STANDARD This memo defines a MIB for use with managing host systems. The term"host" is construed to mean any computer that communicates with other similar computers attached to the internet and that is directly used by one or more human beings. Although this MIB does not necessarily apply to devices whose primary function is communications services(e.g., terminal servers, routers, bridges, monitoring equipment), such relevance is not explicitly precluded. This MIB instruments attributes common to all internet hosts including, for example, both personal computers and systems that run variants of Unix.
RFC 1515	Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs)
	Authors: D. McMaster, K. McCloghrie, S. Roberts. Date: September 1993 Formats: txt pdf Obsoleted by: RFC 3636 Status: PROPOSED STANDARD This document defines a portion of the Management Information Base(MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing IEEE 802.3Medium Attachment Units (MAUs).
RFC 1519	Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy
	Authors: V. Fuller, T. Li, J. Yu, K. Varadhan. Date: September 1993 Formats: txt pdf Obsoletes: RFC 1338 Obsoleted by: RFC 4632 Status: PROPOSED STANDARD This memo discusses strategies for address assignment of the existingIP address space with a view to conserve the address space and stem the explosive growth of routing tables in default-route-free routers.
RFC 1531	Dynamic Host Configuration Protocol
	Authors: R. Droms. Date: October 1993 Formats: txt pdf Obsoleted by: RFC 1541 Status: PROPOSED STANDARD The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCP/IP network.DHCP is based on the Bootstrap Protocol (BOOTP) [7], adding the capability of automatic allocation of reusable network addresses and additional configuration options [19]. DHCP captures the behavior ofBOOTP relay agents [7, 23], and DHCP participants can interoperate with BOOTP participants [9].
RFC 1532	Clarifications and Extensions for the Bootstrap Protocol
	Authors: W. Wimer. Date: October 1993 Formats: txt pdf Obsoleted by: RFC 1542 Updates: RFC 0951 Status: PROPOSED STANDARD Some aspects of the BOOTP protocol were rather loosely defined in its original specification. In particular, only a general description was provided for the behavior of "BOOTP relay agents" (originally called BOOTP forwarding agents"). The client behavior description also suffered in certain ways. This memo attempts to clarify and strengthen the specification in these areas. In addition, new issues have arisen since the original specification was written. This memo also attempts to address some of these.
RFC 1533	DHCP Options and BOOTP Vendor Extensions
	Authors: S. Alexander, R. Droms. Date: October 1993 Formats: txt pdf Obsoletes: RFC 1497, RFC 1395, RFC 1084, RFC 1048 Obsoleted by: RFC 2132 Status: PROPOSED STANDARD The Dynamic Host Configuration Protocol (DHCP) [1] provides a framework for passing configuration information to hosts on a TCP/IP network. Configuration parameters and other control information are carried in tagged data items that are stored in the "options" field of the DHCP message. The data items themselves are also called"options." This document specifies the current set of DHCP options. This document will be periodically updated as new options are defined.Each superseding document will include the entire current list of valid options. All of the vendor information extensions defined in RFC 1497 [2] may be used as DHCP options. The definitions given in RFC 1497 are included in this document, which supersedes RFC 1497. All of theDHCP options defined in this document, except for those specific toDHCP as defined in section 9, may be used as BOOTP vendor information extensions.
RFC 1541	Dynamic Host Configuration Protocol
	Authors: R. Droms. Date: October 1993 Formats: txt pdf Obsoletes: RFC 1531 Obsoleted by: RFC 2131 Status: PROPOSED STANDARD The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCP/IP network.DHCP is based on the Bootstrap Protocol (BOOTP) [7], adding the capability of automatic allocation of reusable network addresses and additional configuration options [19]. DHCP captures the behavior ofBOOTP relay agents [7, 23], and DHCP participants can interoperate with BOOTP participants [9]. Due to some errors introduced into RFC1531 in the editorial process, this memo is reissued as RFC 1541.
RFC 1544	The Content-MD5 Header Field
	Authors: M. Rose. Date: November 1993 Formats: txt pdf Obsoleted by: RFC 1864 Status: PROPOSED STANDARD This memo specifies an optional header field, Content-MD5, for use with MIME-conformant messages.
RFC 1565	Network Services Monitoring MIB
	Authors: S. Kille, N. Freed. Date: January 1994 Formats: txt pdf Obsoleted by: RFC 2248 Status: PROPOSED STANDARD This document defines a MIB which contains the elements common to the monitoring of any network service application. This information includes a table of all monitorable network service applications, a count of the associations (connections) to each application, and basic information about the parameters and status of each application-related association. [STANDARDS-TRACK]
RFC 1566	Mail Monitoring MIB
	Authors: S. Kille, N. Freed. Date: January 1994 Formats: txt pdf Obsoleted by: RFC 2249, RFC 2789 Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, this memo extends the basic Network Services Monitoring MIB to allow monitoring of Message Transfer Agents (MTAs). It may also be used to monitor MTA components within gateways. [STANDARDS-TRACK]
RFC 1567	X.500 Directory Monitoring MIB
	Authors: G. Mansfield, S. Kille. Date: January 1994 Formats: txt pdf Obsoleted by: RFC 2605 Status: PROPOSED STANDARD This document defines a portion of the Management Information Base(MIB). It defines the MIB for monitoring Directory System Agents(DSA), a component of the OSI Directory. This MIB will be used in conjunction with the APPLICATION-MIB for monitoring DSAs.
RFC 1570	PPP LCP Extensions
	Authors: W. Simpson, Ed.. Date: January 1994 Formats: txt pdf Updates: RFC 1548 Updated by: RFC 2484 Status: PROPOSED STANDARD The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection. This document defines several additional LCP features which have been suggested over the past few years. This document is the product of the Point-to-Point Protocol WorkingGroup of the Internet Engineering Task Force (IETF). Comments should be submitted to the ietf-ppp@ucdavis.edu mailing list.
RFC 1572	Telnet Environment Option
	Authors: S. Alexander, Ed.. Date: January 1994 Formats: txt pdf Status: PROPOSED STANDARD This document specifies a mechanism for passing environment information between a telnet client and server. Use of this mechanism enables a telnet user to propagate configuration information to a remote host when connecting. This document corrects some errors in [1].
RFC 1573	Evolution of the Interfaces Group of MIB-II
	Authors: K. McCloghrie, F. Kastenholz. Date: January 1994 Formats: txt pdf Obsoletes: RFC 1229 Obsoleted by: RFC 2233 Status: PROPOSED STANDARD 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 Network Interfaces. [STANARDS-TRACK]
RFC 1577	Classical IP and ARP over ATM
	Authors: M. Laubach. Date: January 1994 Formats: txt pdf Obsoleted by: RFC 2225 Status: PROPOSED STANDARD This memo defines an initial application of classical IP and ARP in an Asynchronous Transfer Mode (ATM) network environment configured as a Logical IP Subnetwork (LIS) as described in Section 3. This memo does not preclude the subsequent development of ATM technology into areas other than a LIS; specifically, as single ATM networks grow to replace many ethernet local LAN segments and as these networks become globally connected, the application of IP and ARP will be treated differently. This memo considers only the application of ATM as a direct replacement for the "wires" and local LAN segments connectingIP end-stations ("members") and routers operating in the "classical"LAN-based paradigm. Issues raised by MAC level bridging and LAN emulation are beyond the scope of this paper. This memo introduces general ATM technology and nomenclature.Readers are encouraged to review the ATM Forum and ITU-TS (formerlyCCITT) references for more detailed information about ATM implementation agreements and standards.
RFC 1582	Extensions to RIP to Support Demand Circuits
	Authors: G. Meyer. Date: February 1994 Formats: txt pdf Status: PROPOSED STANDARD Running routing protocols on connection oriented Public DataNetworks, for example X.25 packet switched networks or ISDN, can be expensive if the standard form of periodic broadcasting of routing information is adhered to. The high cost arises because a connection has to all practical intents and purposes be kept open to every destination to which routing information is to be sent, whether or not it is being used to carry user data. Routing information may also fail to be propagated if the number of destinations to which the routing information is to be sent exceeds the number of channels available to the router on the Wide AreaNetwork (WAN). This memo defines a generalized modification which can be applied toBellman-Ford (or distance vector) algorithm information broadcasting protocols, for example IP RIP, Netware RIP or Netware SAP, which overcomes the limitations of the traditional methods described above. The routing protocols support a purely triggered update mechanism on demand circuits on WANs. The protocols run UNMODIFIED on LANs or fixed point-to-point links. Routing information is sent on the WAN when the routing database is modified by new routing information received from another interface.When this happens a (triggered) update is sent to a list of destinations on other WAN interfaces. Because routing protocols are datagram based they are not guaranteed to be received by the peer router on the WAN. An acknowledgement and retransmission mechanism is provided to ensure that routing updates are received. The WAN circuit manager advises the routing applications on the reachability and non-reachability of destinations on the WAN.
RFC 1587	The OSPF NSSA Option
	Authors: R. Coltun, V. Fuller. Date: March 1994 Formats: txt pdf Obsoleted by: RFC 3101 Status: PROPOSED STANDARD This document describes a new optional type of OSPF area, somewhat humorously referred to as a "not-so-stubby" area (or NSSA). NSSAs are similar to the existing OSPF stub area configuration option but have the additional capability of importing AS external routes in a limited fashion. [STANDARDS-TRACK]
RFC 1595	Definitions of Managed Objects for the SONET/SDH Interface Type
	Authors: T. Brown, K. Tesink. Date: March 1994 Formats: txt pdf Obsoleted by: RFC 2558 Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it defines objects for managing Synchronous OpticalNetwork/Synchronous Digital Hierarchy (SONET/SDH) objects. This document is a companion document with Definitions of Managed Objects for the DS1/E1 and DS3/E3 Interface Types, RFC1406 [14] and RFC1407[13]. This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions.
RFC 1596	Definitions of Managed Objects for Frame Relay Service
	Authors: T. Brown, Ed.. Date: March 1994 Formats: txt pdf Obsoleted by: RFC 1604 Status: PROPOSED STANDARD This memo defines an extension to the Management Information Base(MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the FrameRelay Service.
RFC 1598	PPP in X.25
	Authors: W. Simpson. Date: March 1994 Formats: txt pdf Status: PROPOSED STANDARD The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.This document describes the use of X.25 for framing PPP encapsulated packets. This document is the product of the Point-to-Point Protocol WorkingGroup of the Internet Engineering Task Force (IETF). Comments should be submitted to the ietf-ppp@merit.edu mailing list.
RFC 1604	Definitions of Managed Objects for Frame Relay Service
	Authors: T. Brown, Ed.. Date: March 1994 Formats: txt pdf Obsoletes: RFC 1596 Obsoleted by: RFC 2954 Status: PROPOSED STANDARD This memo defines an extension to the Management Information Base(MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the FrameRelay Service.
RFC 1618	PPP over ISDN
	Authors: W. Simpson. Date: May 1994 Formats: txt pdf Status: PROPOSED STANDARD The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.This document describes the use of PPP over Integrated ServicesDigital Network (ISDN) switched circuits. This document is the product of the Point-to-Point Protocol WorkingGroup of the Internet Engineering Task Force (IETF). Comments should be submitted to the ietf-ppp@merit.edu mailing list.
RFC 1619	PPP over SONET/SDH
	Authors: W. Simpson. Date: May 1994 Formats: txt pdf Obsoleted by: RFC 2615 Status: PROPOSED STANDARD The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.This document describes the use of PPP over Synchronous OpticalNetwork (SONET) and Synchronous Digital Heirarchy (SDH) circuits. This document is the product of the Point-to-Point Protocol WorkingGroup of the Internet Engineering Task Force (IETF). Comments should be submitted to the ietf-ppp@merit.edu mailing list.
RFC 1626	Default IP MTU for use over ATM AAL5
	Authors: R. Atkinson. Date: May 1994 Formats: txt pdf Obsoleted by: RFC 2225 Status: PROPOSED STANDARD There are a number of good reasons to have a reasonably large default MTU value for IP over ATM AAL5. This paper presents the default IP MIU for use over ATM AAL5. [STANDARDS-TRACK]
RFC 1638	PPP Bridging Control Protocol (BCP)
	Authors: F. Baker, R. Bowen. Date: June 1994 Formats: txt pdf Obsoletes: RFC 1220 Obsoleted by: RFC 2878 Status: PROPOSED STANDARD The Point-to-Point Protocol (PPP) [6] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol, and proposes a family ofNetwork Control Protocols for establishing and configuring different network-layer protocols. This document defines the Network Control Protocol for establishing and configuring Remote Bridging for PPP links.
RFC 1647	TN3270 Enhancements
	Authors: B. Kelly. Date: July 1994 Formats: txt pdf Obsoleted by: RFC 2355 Status: PROPOSED STANDARD This document describes a protocol that more fully supports 3270 devices than do the existing tn3270 practices. Specifically, it defines a method of emulating both the terminal and printer members of the 3270 family of devices via Telnet; it provides for the ability of a Telnet client to request that it be assigned a specific device- name (also referred to as "LU name" or "network name"); finally, it adds support for a variety of functions such as the ATTN key, theSYSREQ key, and SNA response handling. This protocol would be negotiated and implemented under a new TelnetOption and would be unrelated to the Telnet 3270 Regime Option as defined in RFC 1041 [1].
RFC 1650	Definitions of Managed Objects for the Ethernet-like Interface Types using SMIv2
	Authors: F. Kastenholz. Date: August 1994 Formats: txt pdf Obsoleted by: RFC 2358 Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing ethernet-like objects. [STANDARDS-TRACK]
RFC 1654	A Border Gateway Protocol 4 (BGP-4)
	Authors: Y. Rekhter, T. Li, Eds.. Date: July 1994 Formats: txt pdf Obsoleted by: RFC 1771 Status: PROPOSED STANDARD This document defines an inter-autonomous system routing protocol for the Internet. [STANDARDS-TRACK]
RFC 1655	Application of the Border Gateway Protocol in the Internet
	Authors: Y. Rekhter, P. Gross, Eds.. Date: July 1994 Formats: txt pdf Obsoletes: RFC 1268 Obsoleted by: RFC 1772 Status: PROPOSED STANDARD This document, together with its companion document, "A BorderGateway Protocol 4 (BGP-4)", define an inter-autonomous system routing protocol for the Internet. "A Border Gateway Protocol 4(BGP-4)" defines the BGP protocol specification, and this document describes the usage of the BGP in the Internet. Information about the progress of BGP can be monitored and/or reported on the BGP mailing list (bgp@ans.net).
RFC 1663	PPP Reliable Transmission
	Authors: D. Rand. Date: July 1994 Formats: txt pdf Status: PROPOSED STANDARD The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. This document defines a method for negotiating and using Numbered-Mode, as defined by ISO 7776 [2], to provide a reliable serial link. This document is the product of the Point-to-Point Protocol WorkingGroup of the Internet Engineering Task Force (IETF). Comments should be submitted to the ietf-ppp@ucdavis.edu mailing list.
RFC 1665	Definitions of Managed Objects for SNA NAUs using SMIv2
	Authors: Z. Kielczewski, D. Kostick, K. Shih, Eds.. Date: July 1994 Formats: txt pdf Obsoleted by: RFC 1666 Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing the configuration, monitoring and control of Physical Units (PUs) and Logical Units (LUs) in an SNA environment. [STANDARDS-TRACK]
RFC 1695	Definitions of Managed Objects for ATM Management Version 8.0 using SMIv2
	Authors: M. Ahmed, K. Tesink, Eds.. Date: August 1994 Formats: txt pdf Obsoleted by: RFC 2515 Status: PROPOSED STANDARD 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 used for managing ATM-based interfaces, devices, networks and services. [STANDARDS-TRACK]
RFC 1697	Relational Database Management System (RDBMS) Management Information Base (MIB) using SMIv2
	Authors: D. Brower, Ed., B. Purvy, A. Daniel, M. Sinykin, J. Smith. Date: August 1994 Formats: txt pdf Status: PROPOSED STANDARD 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 relational database (RDBMS) implementations. [STANDARDS-TRACK]
RFC 1717	The PPP Multilink Protocol (MP)
	Authors: K. Sklower, B. Lloyd, G. McGregor, D. Carr. Date: November 1994 Formats: txt pdf Obsoleted by: RFC 1990 Status: PROPOSED STANDARD This document proposes a method for splitting, recombining and sequencing datagrams across multiple logical data links. This work was originally motivated by the desire to exploit multiple bearer channels in ISDN, but is equally applicable to any situation in which multiple PPP links connect two systems, including async links. This is accomplished by means of new PPP [2] options and protocols.
RFC 1730	Internet Message Access Protocol - Version 4
	Authors: M. Crispin. Date: December 1994 Formats: txt pdf Obsoleted by: RFC 2060, RFC 2061 Status: PROPOSED STANDARD The Internet Message Access Protocol, Version 4 (IMAP4) allows a client to access and manipulate electronic mail messages on a server.IMAP4 permits manipulation of remote message folders, called"mailboxes", in a way that is functionally equivalent to local mailboxes. IMAP4 also provides the capability for an offline client to resynchronize with the server (see also [IMAP-DISC]). IMAP4 includes operations for creating, deleting, and renaming mailboxes; checking for new messages; permanently removing messages; setting and clearing flags; RFC 822 and MIME parsing; searching; and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4 are accessed by the use of numbers.These numbers are either message sequence numbers (relative position from 1 to the number of messages in the mailbox) or unique identifiers (immutable, strictly ascending values assigned to each message, but which are not necessarily contiguous). IMAP4 supports a single server. A mechanism for supporting multipleIMAP4 servers is discussed in [IMSP]. IMAP4 does not specify a means of posting mail; this function is handled by a mail transfer protocol such as [SMTP]. IMAP4 is designed to be upwards compatible from the [IMAP2] protocol.Compatibility issues are discussed in [IMAP-COMPAT].
RFC 1731	IMAP4 Authentication Mechanisms
	Authors: J. Myers. Date: December 1994 Formats: txt pdf Status: PROPOSED STANDARD The Internet Message Access Protocol, Version 4 [IMAP4] contains the AUTHENTICATE command, for identifying and authenticating a user to an IMAP4 server and for optionally negotiating a protection mechanism for subsequent protocol interactions. This document describes several authentication mechanisms for use by the IMAP4 AUTHENTICATE command. [STANDARDS-TRACK]
RFC 1734	POP3 AUTHentication command
	Authors: J. Myers. Date: December 1994 Formats: txt pdf Obsoleted by: RFC 5034 Status: PROPOSED STANDARD This document describes the optional AUTH command, for indicating an authentication mechanism to the server, performing an authentication protocol exchange, and optionally negotiating a protection mechanism for subsequent protocol interactions. [STANDARDS-TRACK]
RFC 1738	Uniform Resource Locators (URL)
	Authors: T. Berners-Lee, L. Masinter, M. McCahill. Date: December 1994 Formats: txt pdf Obsoleted by: RFC 4248, RFC 4266 Updated by: RFC 1808, RFC 2368, RFC 2396, RFC 3986, RFC 6196, RFC 6270 Status: PROPOSED STANDARD This document specifies a Uniform Resource Locator (URL), the syntax and semantics of formalized information for location and access of resources via the Internet.
RFC 1740	MIME Encapsulation of Macintosh Files - MacMIME
	Authors: P. Faltstrom, D. Crocker, E. Fair. Date: December 1994 Formats: txt pdf Status: PROPOSED STANDARD This memo describes the format to use when sending Apple Macintosh files via MIME [BORE93]. The format is compatible with existing mechanisms for distributing Macintosh files, while allowing non-Macintosh systems access to data in standardized formats.
RFC 1752	The Recommendation for the IP Next Generation Protocol
	Authors: S. Bradner, A. Mankin. Date: January 1995 Formats: txt pdf Status: PROPOSED STANDARD This document presents the recommendation of the IPng Area Directors on what should be used to replace the current version of the InternetProtocol. This recommendation was accepted by the InternetEngineering Steering Group (IESG).
RFC 1755	ATM Signaling Support for IP over ATM
	Authors: M. Perez, F. Liaw, A. Mankin, E. Hoffman, D. Grossman, A. Malis. Date: February 1995 Formats: txt pdf Status: PROPOSED STANDARD This memo describes the ATM call control signaling exchanges needed to support Classical IP over ATM implementations as described in RFC1577 [LAUB94]. ATM endpoints will incorporate ATM signaling services as specified in the ATM Forum User-Network Interface (UNI)Specification Version 3.1 [ATMF94]. IP over ATM implementations utilize the services of local ATM signaling entities to establish and release ATM connections. This memo should be used to define the support required by IP over ATM implementations from their local ATM signaling entities. This document is an implementors guide intended to foster interoperability among RFC 1577, RFC 1483, and UNI ATM signaling. It applies to IP hosts and routers which are also ATM endsystems and assumes ATM networks that completely implement the ATM Forum UNISpecification Version 3.1. Unless explicitly stated, no distinction is made between the Private and Public UNI. UNI 3.1 is considered an erratum to the UNI 3.0 specification. It has been produced by the ATM Forum, largely for reasons of alignment withRecommendation Q.2931. Although UNI 3.1 is based on UNI 3.0 there are several changes that make the two versions incompatible. A description of how to support IP over ATM using UNI 3.0 is found inAppendix B.
RFC 1759	Printer MIB
	Authors: R. Smith, F. Wright, T. Hastings, S. Zilles, J. Gyllenskog. Date: March 1995 Formats: txt pdf Obsoleted by: RFC 3805 Status: PROPOSED STANDARD A printer is the physical device that takes media from an input source, produces marks on that media according to some page description or page control language and puts the result in some output destination, possibly with finishing applied. The information needed in the management of the physical printer and the management of a printing job overlap highly and many of the tasks in each management area require the same or similar information. [STANDARDS-TRACK]
RFC 1766	Tags for the Identification of Languages
	Authors: H. Alvestrand. Date: March 1995 Formats: txt pdf Obsoleted by: RFC 3066, RFC 3282 Status: PROPOSED STANDARD This document describes a language tag for use in cases where it is desired to indicate the language used in an information object. It also defines a Content-language: header, for use in the case where one desires to indicate the language of something that has RFC-822- like headers, like MIME body parts or Web documents, and a new parameter to the Multipart/Alternative type, to aid in the usage of the Content-Language: header.
RFC 1767	MIME Encapsulation of EDI Objects
	Authors: D. Crocker. Date: March 1995 Formats: txt pdf Status: PROPOSED STANDARD Since there are many different EDI specifications, the current document defines three distinct categories as three different MIME content-types. [STANDARDS-TRACK]
RFC 1782	TFTP Option Extension
	Authors: G. Malkin, A. Harkin. Date: March 1995 Formats: txt pdf Obsoleted by: RFC 2347 Updates: RFC 1350 Status: PROPOSED STANDARD 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 simple extension to TFTP to allow option negotiation prior to the file transfer.
RFC 1783	TFTP Blocksize Option
	Authors: G. Malkin, A. Harkin. Date: March 1995 Formats: txt pdf Obsoleted by: RFC 2348 Updates: RFC 1350 Status: PROPOSED STANDARD 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. One of its primary uses is the booting of diskless nodes on a Local Area Network. TFTP is used because it is very simple to implement in a small node's limited ROM space. However, the choice of a 512-byte blocksize is not the most efficient for use on a LAN whose MTU may 1500 bytes or greater. This document describes a TFTP option which allows the client and server to negotiate a blocksize more applicable to the network medium. The TFTP Option Extension mechanism is described in [2].
RFC 1784	TFTP Timeout Interval and Transfer Size Options
	Authors: G. Malkin, A. Harkin. Date: March 1995 Formats: txt pdf Obsoleted by: RFC 2349 Updates: RFC 1350 Status: PROPOSED STANDARD 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 two TFTP options. The first allows the client and server to negotiate the Timeout Interval. The second allows the side receiving the file to determine the ultimate size of the transfer before it begins. The TFTP Option Extension mechanism is described in [2]. This document assumes that the reader is familiar with the terminology and notation of both [1] and [2].
RFC 1793	Extending OSPF to Support Demand Circuits
	Authors: J. Moy. Date: April 1995 Formats: txt pdf Updated by: RFC 3883 Status: PROPOSED STANDARD This memo defines enhancements to the OSPF protocol that allow efficient operation over "demand circuits". Demand circuits are network segments whose costs vary with usage; charges can be based both on connect time and on bytes/packets transmitted. Examples of demand circuits include ISDN circuits, X.25 SVCs, and dial-up lines.The periodic nature of OSPF routing traffic has until now required a demand circuit's underlying data-link connection to be constantly open, resulting in unwanted usage charges. With the modifications described herein, OSPF Hellos and the refresh of OSPF routing information are suppressed on demand circuits, allowing the underlying data-link connections to be closed when not carrying application traffic. Demand circuits and regular network segments (e.g., leased lines) are allowed to be combined in any manner. In other words, there are no topological restrictions on the demand circuit support. However, while any OSPF network segment can be defined as a demand circuit, only point-to-point networks receive the full benefit. When broadcast and NBMA networks are declared demand circuits, routing update traffic is reduced but the periodic sending of Hellos is not, which in effect still requires that the data-link connections remain constantly open. While mainly intended for use with cost-conscious network links such as ISDN, X.25 and dial-up, the modifications in this memo may also prove useful over bandwidth-limited network links such as slow-speed leased lines and packet radio. The enhancements defined in this memo are backward-compatible with the OSPF specification defined in [1], and with the OSPF extensions defined in [3] (OSPF NSSA areas), [4] (MOSPF) and [8] (OSPF Point- to-MultiPoint Interface). This memo provides functionality similar to that specified for RIP in[2], with the main difference being the way the two proposals handle oversubscription (see Sections 4.3 and 7 below). However, becauseOSPF employs link-state routing technology as opposed to RIP'sDistance Vector base, the mechanisms used to achieve the demand circuit functionality are quite different. Please send comments to ospf@gated.cornell.edu.
RFC 1808	Relative Uniform Resource Locators
	Authors: R. Fielding. Date: June 1995 Formats: txt pdf Obsoleted by: RFC 3986 Updates: RFC 1738 Updated by: RFC 2368, RFC 2396 Status: PROPOSED STANDARD A Uniform Resource Locator (URL) is a compact representation of the location and access method for a resource available via the Internet.When embedded within a base document, a URL in its absolute form may contain a great deal of information which is already known from the context of that base document's retrieval, including the scheme, network location, and parts of the url-path. In situations where the base URL is well-defined and known to the parser (human or machine), it is useful to be able to embed URL references which inherit that context rather than re-specifying it in every instance. This document defines the syntax and semantics for such Relative UniformResource Locators.
RFC 1812	Requirements for IP Version 4 Routers
	Authors: F. Baker, Ed.. Date: June 1995 Formats: txt pdf Obsoletes: RFC 1716, RFC 1009 Updated by: RFC 2644 Status: PROPOSED STANDARD This memo defines and discusses requirements for devices that perform the network layer forwarding function of the Internet protocol suite. [STANDARDS-TRACK]
RFC 1825	Security Architecture for the Internet Protocol
	Authors: R. Atkinson. Date: August 1995 Formats: txt pdf Obsoleted by: RFC 2401 Status: PROPOSED STANDARD This memo describes the security mechanisms for IP version 4 (IPv4) and IP version 6 (IPv6) and the services that they provide. [STANDARDS- TRACK]
RFC 1826	IP Authentication Header
	Authors: R. Atkinson. Date: August 1995 Formats: txt pdf Obsoleted by: RFC 2402 Status: PROPOSED STANDARD This document describes a mechanism for providing cryptographic authentication for IPv4 and IPv6 datagrams. [STANDARDS-TRACK]
RFC 1827	IP Encapsulating Security Payload (ESP)
	Authors: R. Atkinson. Date: August 1995 Formats: txt pdf Obsoleted by: RFC 2406 Status: PROPOSED STANDARD This document describes the IP Encapsulating Security Payload (ESP). ESP is a mechanism for providing integrity and confidentiality to IP datagrams. [STANDARDS-TRACK]
RFC 1829	The ESP DES-CBC Transform
	Authors: P. Karn, P. Metzger, W. Simpson. Date: August 1995 Formats: txt pdf Status: PROPOSED STANDARD This document describes the DES-CBC security transform for the IPEncapsulating Security Payload (ESP).
RFC 1831	RPC: Remote Procedure Call Protocol Specification Version 2
	Authors: R. Srinivasan. Date: August 1995 Formats: txt pdf Obsoleted by: RFC 5531 Status: PROPOSED STANDARD This document describes the ONC Remote Procedure Call (ONC RPC Version 2) protocol as it is currently deployed and accepted. [STANDARDS-TRACK]
RFC 1833	Binding Protocols for ONC RPC Version 2
	Authors: R. Srinivasan. Date: August 1995 Formats: txt pdf Updated by: RFC 5665 Status: PROPOSED STANDARD This document describes the binding protocols used in conjunction with the ONC Remote Procedure Call (ONC RPC Version 2) protocols. [STANDARDS-TRACK]
RFC 1847	Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted
	Authors: J. Galvin, S. Murphy, S. Crocker, N. Freed. Date: October 1995 Formats: txt pdf Status: PROPOSED STANDARD This document defines a framework within which security services may be applied to MIME body parts. MIME, an acronym for "MultipurposeInternet Mail Extensions", defines the format of the contents ofInternet mail messages and provides for multi-part textual and non- textual message bodies. The new content types are subtypes of multipart: signed and encrypted. Each will contain two body parts: one for the protected data and one for the control information necessary to remove the protection. The type and contents of the control information body parts are determined by the value of the protocol parameter of the enclosing multipart/signed or multipart/encrypted content type, which is required to be present.
RFC 1854	SMTP Service Extension for Command Pipelining
	Authors: N. Freed. Date: October 1995 Formats: txt pdf Obsoleted by: RFC 2197 Status: PROPOSED STANDARD This memo defines an extension to the SMTP service whereby a server can indicate the extent of its ability to accept multiple commands in a single TCP send operation. Using a single TCP send operation for multiple commands can improve SMTP performance significantly.
RFC 1883	Internet Protocol, Version 6 (IPv6) Specification
	Authors: S. Deering, R. Hinden. Date: December 1995 Formats: txt pdf Obsoleted by: RFC 2460 Status: PROPOSED STANDARD This document specifies version 6 of the Internet Protocol (IPv6), also sometimes referred to as IP Next Generation or IPng.
RFC 1885	Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)
	Authors: A. Conta, S. Deering. Date: December 1995 Formats: txt pdf Obsoleted by: RFC 2463 Status: PROPOSED STANDARD This document specifies a set of Internet Control Message Protocol(ICMP) messages for use with version 6 of the Internet Protocol(IPv6). The Internet Group Management Protocol (IGMP) messages specified in STD 5, RFC 1112 have been merged into ICMP, for IPv6, and are included in this document.
RFC 1886	DNS Extensions to support IP version 6
	Authors: S. Thomson, C. Huitema. Date: December 1995 Formats: txt pdf Obsoleted by: RFC 3596 Updated by: RFC 2874, RFC 3152 Status: PROPOSED STANDARD This document defines the changes that need to be made to the DomainName System to support hosts running IP version 6 (IPv6). The changes include a new resource record type to store an IPv6 address, a new domain to support lookups based on an IPv6 address, and updated definitions of existing query types that return Internet addresses as part of additional section processing. The extensions are designed to be compatible with existing applications and, in particular, DNS implementations themselves.
RFC 1889	RTP: A Transport Protocol for Real-Time Applications
	Authors: Audio-Video Transport Working Group, H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson. Date: January 1996 Formats: txt pdf Obsoleted by: RFC 3550 Status: PROPOSED STANDARD This memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of- service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers.
RFC 1890	RTP Profile for Audio and Video Conferences with Minimal Control
	Authors: Audio-Video Transport Working Group, H. Schulzrinne. Date: January 1996 Formats: txt pdf Obsoleted by: RFC 3551 Status: PROPOSED STANDARD This memo describes a profile for the use of the real-time transport protocol (RTP), version 2, and the associated control protocol, RTCP, within audio and video multiparticipant conferences with minimal control. It provides interpretations of generic fields within the RTP specification suitable for audio and video conferences. In particular, this document defines a set of default mappings from payload type numbers to encodings. The document also describes how audio and video data may be carried within RTP. It defines a set of standard encodings and their names when used within RTP. However, the encoding definitions are independent of the particular transport mechanism used. The descriptions provide pointers to reference implementations and the detailed standards. This document is meant as an aid for implementors of audio, video and other real-time multimedia applications.
RFC 1891	SMTP Service Extension for Delivery Status Notifications
	Authors: K. Moore. Date: January 1996 Formats: txt pdf Obsoleted by: RFC 3461 Status: PROPOSED STANDARD This memo defines an extension to the SMTP service, which allows an SMTP client to specify (a) that delivery status notifications (DSNs) should be generated under certain conditions, (b) whether such notifications should return the contents of the message, and (c) additional information, to be returned with a DSN, that allows the sender to identify both the recipient(s) for which the DSN was issued, and the transaction in which the original message was sent. [STANDARDS-TRACK]
RFC 1892	The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages
	Authors: G. Vaudreuil. Date: January 1996 Formats: txt pdf Obsoleted by: RFC 3462 Status: PROPOSED STANDARD The Multipart/Report MIME content-type is a general "family" or "container" type for electronic mail reports of any kind. Although this memo defines only the use of the Multipart/Report content-type with respect to delivery status reports, mail processing programs will benefit if a single content-type is used to for all kinds of reports. [STANDARDS-TRACK]
RFC 1893	Enhanced Mail System Status Codes
	Authors: G. Vaudreuil. Date: January 1996 Formats: txt pdf Obsoleted by: RFC 3463 Status: PROPOSED STANDARD There currently is not a standard mechanism for the reporting of mail system errors except for the limited set offered by SMTP and the system specific text descriptions sent in mail messages. There is a pressing need for a rich machine readable status code for use in delivery status notifications [DSN]. This document proposes a new set of status codes for this purpose. [STANDARDS-TRACK]
RFC 1894	An Extensible Message Format for Delivery Status Notifications
	Authors: K. Moore, G. Vaudreuil. Date: January 1996 Formats: txt pdf Obsoleted by: RFC 3464 Updated by: RFC 2852 Status: PROPOSED STANDARD This memo defines a MIME content-type that may be used by a message transfer agent (MTA) or electronic mail gateway to report the result of an attempt to deliver a message to one or more recipients. This content-type is intended as a machine-processable replacement for the various types of delivery status notifications currently used inInternet electronic mail. Because many messages are sent between the Internet and other messaging systems (such as X.400 or the so-called "LAN-based" systems), the DSN protocol is designed to be useful in a multi- protocol messaging environment. To this end, the protocol described in this memo provides for the carriage of "foreign" addresses and error codes, in addition to those normally used in Internet mail.Additional attributes may also be defined to support "tunneling" of foreign notifications through Internet mail. Any questions, comments, and reports of defects or ambiguities in this specification may be sent to the mailing list for the NOTARY working group of the IETF, using the address<notifications@cs.utk.edu&rt;. Requests to subscribe to the mailing list should be addressed to <notifications-request@cs.utk.edu&rt;.Implementors of this specification are encouraged to subscribe to the mailing list, so that they will quickly be informed of any problems which might hinder interoperability. NOTE: This document is a Proposed Standard. If and when this protocol is submitted for Draft Standard status, any normative text(phrases containing SHOULD, SHOULD NOT, MUST, MUST NOT, or MAY) in this document will be re-evaluated in light of implementation experience, and are thus subject to change.
RFC 1928	SOCKS Protocol Version 5
	Authors: M. Leech, M. Ganis, Y. Lee, R. Kuris, D. Koblas, L. Jones. Date: March 1996 Formats: txt pdf Status: PROPOSED STANDARD This memo describes a protocol that is an evolution of the previous version of the protocol, version 4 [1]. This new protocol stems from active discussions and prototype implementations. [STANDARDS-TRACK]
RFC 1929	Username/Password Authentication for SOCKS V5
	Authors: M. Leech. Date: March 1996 Formats: txt pdf Status: PROPOSED STANDARD The protocol specification for SOCKS Version 5 specifies a generalized framework for the use of arbitrary authentication protocols in the initial socks connection setup. This document describes one of those protocols, as it fits into the SOCKS Version 5 authentication "subnegotiation". [STANDARDS-TRACK]
RFC 1933	Transition Mechanisms for IPv6 Hosts and Routers
	Authors: R. Gilligan, E. Nordmark. Date: April 1996 Formats: txt pdf Obsoleted by: RFC 2893 Status: PROPOSED STANDARD This document specifies IPv4 compatibility mechanisms that can be implemented by IPv6 hosts and routers. These mechanisms include providing complete implementations of both versions of the InternetProtocol (IPv4 and IPv6), and tunneling IPv6 packets over IPv4 routing infrastructures. They are designed to allow IPv6 nodes to maintain complete compatibility with IPv4, which should greatly simplify the deployment of IPv6 in the Internet, and facilitate the eventual transition of the entire Internet to IPv6.
RFC 1938	A One-Time Password System
	Authors: N. Haller, C. Metz. Date: May 1996 Formats: txt pdf Obsoleted by: RFC 2289 Status: PROPOSED STANDARD This document describes a one-time password authentication system (OTP). [STANDARDS-TRACK]
RFC 1959	An LDAP URL Format
	Authors: T. Howes, M. Smith. Date: June 1996 Formats: txt pdf Obsoleted by: RFC 2255 Status: PROPOSED STANDARD This document describes a format for an LDAP Uniform Resource Locator which will allow Internet clients to have direct access to the LDAP protocol. [STANDARDS-TRACK]
RFC 1960	A String Representation of LDAP Search Filters
	Authors: T. Howes. Date: June 1996 Formats: txt pdf Obsoletes: RFC 1558 Obsoleted by: RFC 2254 Status: PROPOSED STANDARD The Lightweight Directory Access Protocol (LDAP) [1] defines a network representation of a search filter transmitted to an LDAP server. Some applications may find it useful to have a common way of representing these search filters in a human-readable form. This document defines a human-readable string format for representing LDAP search filters. [STANDARDS-TRACK]
RFC 1961	GSS-API Authentication Method for SOCKS Version 5
	Authors: P. McMahon. Date: June 1996 Formats: txt pdf Status: PROPOSED STANDARD This document provides the specification for the SOCKS V5 GSS-API authentication protocol, and defines a GSS-API-based encapsulation for provision of integrity, authentication and optional confidentiality. [STANDARDS-TRACK]
RFC 1962	The PPP Compression Control Protocol (CCP)
	Authors: D. Rand. Date: June 1996 Formats: txt pdf Updated by: RFC 2153 Status: PROPOSED STANDARD The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP also defines an extensible Link Control Protocol. This document defines a method for negotiating data compression overPPP links.
RFC 1964	The Kerberos Version 5 GSS-API Mechanism
	Authors: J. Linn. Date: June 1996 Formats: txt pdf Updated by: RFC 4121 Status: PROPOSED STANDARD This specification defines protocols, procedures, and conventions to be employed by peers implementing the Generic Security Service Application Program Interface (as specified in RFCs 1508 and 1509) when using Kerberos Version 5 technology (as specified in RFC 1510). [STANDARDS- TRACK]
RFC 1968	The PPP Encryption Control Protocol (ECP)
	Authors: G. Meyer. Date: June 1996 Formats: txt pdf Status: PROPOSED STANDARD The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP also defines an extensible Link Control Protocol. This document defines a method for negotiating data encryption overPPP links.
RFC 1970	Neighbor Discovery for IP Version 6 (IPv6)
	Authors: T. Narten, E. Nordmark, W. Simpson. Date: August 1996 Formats: txt pdf Obsoleted by: RFC 2461 Status: PROPOSED STANDARD This document specifies the Neighbor Discovery protocol for IPVersion 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers and to maintain reachability information about the paths to active neighbors.
RFC 1971	IPv6 Stateless Address Autoconfiguration
	Authors: S. Thomson, T. Narten. Date: August 1996 Formats: txt pdf Obsoleted by: RFC 2462 Status: PROPOSED STANDARD This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. The autoconfiguration process includes creating a link-local address and verifying its uniqueness on a link, determining what information should be autoconfigured (addresses, other information, or both), and in the case of addresses, whether they should be obtained through the stateless mechanism, the stateful mechanism, or both. This document defines the process for generating a link-local address, the process for generating site-local and global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure. The details of autoconfiguration using the stateful protocol are specified elsewhere.
RFC 1972	A Method for the Transmission of IPv6 Packets over Ethernet Networks
	Authors: M. Crawford. Date: August 1996 Formats: txt pdf Obsoleted by: RFC 2464 Status: PROPOSED STANDARD This memo specifies the frame format for transmission of IPv6 [IPV6] packets and the method of forming IPv6 link-local addresses on Ethernet networks. [STANDARDS-TRACK]
RFC 1973	PPP in Frame Relay
	Authors: W. Simpson. Date: June 1996 Formats: txt pdf Status: PROPOSED STANDARD The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. This document describes the use of Frame Relay for framing PPP encapsulated packets.
RFC 1982	Serial Number Arithmetic
	Authors: R. Elz, R. Bush. Date: August 1996 Formats: txt pdf Updates: RFC 1034, RFC 1035 Status: PROPOSED STANDARD This memo defines serial number arithmetic, as used in the DomainName System. The DNS has long relied upon serial number arithmetic, a concept which has never really been defined, certainly not in anIETF document, though which has been widely understood. This memo supplies the missing definition. It is intended to update RFC1034 and RFC1035.
RFC 1985	SMTP Service Extension for Remote Message Queue Starting
	Authors: J. De Winter. Date: August 1996 Formats: txt pdf Status: PROPOSED STANDARD This memo defines an extension to the SMTP service whereby an SMTP client and server may interact to give the server an opportunity to start the processing of its queues for messages to go to a given host. This extension is meant to be used in startup conditions as well as for mail nodes that have transient connections to their service providers.
RFC 1995	Incremental Zone Transfer in DNS
	Authors: M. Ohta. Date: August 1996 Formats: txt pdf Updates: RFC 1035 Status: PROPOSED STANDARD This document proposes extensions to the DNS protocols to provide an incremental zone transfer (IXFR) mechanism.
RFC 1996	A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)
	Authors: P. Vixie. Date: August 1996 Formats: txt pdf Updates: RFC 1035 Status: PROPOSED STANDARD This memo describes the NOTIFY opcode for DNS, by which a master server advises a set of slave servers that the master's data has been changed and that a query should be initiated to discover the new data.
RFC 1997	BGP Communities Attribute
	Authors: R. Chandra, P. Traina, T. Li. Date: August 1996 Formats: txt pdf Status: PROPOSED STANDARD Border Gateway Protocol [1] is an inter-autonomous system routing protocol designed for TCP/IP internets. This document describes an extension to BGP which may be used to pass additional information to both neighboring and remote BGP peers. The intention of the proposed technique is to aid in policy administration and reduce the management complexity of maintaining the Internet.
RFC 2001	TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms
	Authors: W. Stevens. Date: January 1997 Formats: txt pdf Obsoleted by: RFC 2581 Status: PROPOSED STANDARD Modern implementations of TCP contain four intertwined algorithms that have never been fully documented as Internet standards: slow start, congestion avoidance, fast retransmit, and fast recovery. [2] and [3] provide some details on these algorithms, [4] provides examples of the algorithms in action, and [5] provides the source code for the 4.4BSD implementation. RFC 1122 requires that a TCP must implement slow start and congestion avoidance (Section 4.2.2.15 of [1]), citing [2] as the reference, but fast retransmit and fast recovery were implemented after RFC 1122. The purpose of this document is to document these four algorithms for the Internet.
RFC 2002	IP Mobility Support
	Authors: C. Perkins, Ed.. Date: October 1996 Formats: txt pdf Obsoleted by: RFC 3220 Updated by: RFC 2290 Status: PROPOSED STANDARD This document specifies protocol enhancements that allow transparent routing of IP datagrams to mobile nodes in the Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about its current point of attachment to the Internet. The protocol provides for registering the care-of address with a home agent. The home agent sends datagrams destined for the mobile node through a tunnel to the care- of address. After arriving at the end of the tunnel, each datagram is then delivered to the mobile node.
RFC 2003	IP Encapsulation within IP
	Authors: C. Perkins. Date: October 1996 Formats: txt pdf Updated by: RFC 3168 Status: PROPOSED STANDARD This document specifies a method by which an IP datagram may be encapsulated (carried as payload) within an IP datagram.Encapsulation is suggested as a means to alter the normal IP routing for datagrams, by delivering them to an intermediate destination that would otherwise not be selected by the (network part of the) IPDestination Address field in the original IP header. Encapsulation may serve a variety of purposes, such as delivery of a datagram to a mobile node using Mobile IP.
RFC 2004	Minimal Encapsulation within IP
	Authors: C. Perkins. Date: October 1996 Formats: txt pdf Status: PROPOSED STANDARD This document specifies a method by which an IP datagram may be encapsulated (carried as payload) within an IP datagram, with less overhead than "conventional" IP encapsulation that adds a second IP header to each encapsulated datagram. Encapsulation is suggested as a means to alter the normal IP routing for datagrams, by delivering them to an intermediate destination that would otherwise not be selected by the (network part of the) IP Destination Address field in the original IP header. Encapsulation may be serve a variety of purposes, such as delivery of a datagram to a mobile node usingMobile IP.
RFC 2005	Applicability Statement for IP Mobility Support
	Authors: J. Solomon. Date: October 1996 Formats: txt pdf Status: PROPOSED STANDARD As required by [RFC 1264], this report discusses the applicability ofMobile IP to provide host mobility in the Internet. In particular, this document describes the key features of Mobile IP and shows how the requirements for advancement to Proposed Standard RFC have been satisfied.
RFC 2006	The Definitions of Managed Objects for IP Mobility Support using SMIv2
	Authors: D. Cong, M. Hamlen, C. Perkins. Date: October 1996 Formats: txt pdf Status: PROPOSED STANDARD This memo defines the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it describes managed objects used for managing the MobileNode, Foreign Agent and Home Agent of the Mobile IP Protocol.
RFC 2011	SNMPv2 Management Information Base for the Internet Protocol using SMIv2
	Authors: K. McCloghrie, Ed.. Date: November 1996 Formats: txt pdf Obsoleted by: RFC 4293 Updates: RFC 1213 Status: PROPOSED STANDARD This document is the MIB module which defines managed objects for managing implementations of the Internet Protocol (IP) and its associated Internet Control Message Protocol (ICMP). [STANDARDS-TRACK]
RFC 2012	SNMPv2 Management Information Base for the Transmission Control Protocol using SMIv2
	Authors: K. McCloghrie, Ed.. Date: November 1996 Formats: txt pdf Obsoleted by: RFC 4022 Updates: RFC 1213 Status: PROPOSED STANDARD This document is the MIB module which defines managed objects for managing implementations of the Transmission Control Protocol (TCP). [STANDARDS-TRACK]
RFC 2013	SNMPv2 Management Information Base for the User Datagram Protocol using SMIv2
	Authors: K. McCloghrie, Ed.. Date: November 1996 Formats: txt pdf Obsoleted by: RFC 4113 Updates: RFC 1213 Status: PROPOSED STANDARD This document is the MIB module which defines managed objects for managing implementations of the User Datagram Protocol (UDP). [STANDARDS-TRACK]
RFC 2015	MIME Security with Pretty Good Privacy (PGP)
	Authors: M. Elkins. Date: October 1996 Formats: txt pdf Updated by: RFC 3156 Status: PROPOSED STANDARD This document describes how Pretty Good Privacy (PGP) can be used to provide privacy and authentication using the Multipurpose InternetMail Extensions (MIME) security content types described in RFC1847.
RFC 2017	Definition of the URL MIME External-Body Access-Type
	Authors: N. Freed, K. Moore, A. Cargille. Date: October 1996 Formats: txt pdf Status: PROPOSED STANDARD This memo defines a new access-type for message/external-body MIME parts for Uniform Resource Locators (URLs). [STANDARDS-TRACK]
RFC 2018	TCP Selective Acknowledgment Options
	Authors: M. Mathis, J. Mahdavi, S. Floyd, A. Romanow. Date: October 1996 Formats: txt pdf Obsoletes: RFC 1072 Status: PROPOSED STANDARD TCP may experience poor performance when multiple packets are lost from one window of data. With the limited information available from cumulative acknowledgments, a TCP sender can only learn about a single lost packet per round trip time. An aggressive sender could choose to retransmit packets early, but such retransmitted segments may have already been successfully received. A Selective Acknowledgment (SACK) mechanism, combined with a selective repeat retransmission policy, can help to overcome these limitations. The receiving TCP sends back SACK packets to the sender informing the sender of data that has been received. The sender can then retransmit only the missing data segments. This memo proposes an implementation of SACK and discusses its performance and related issues.
RFC 2019	Transmission of IPv6 Packets Over FDDI
	Authors: M. Crawford. Date: October 1996 Formats: txt pdf Obsoleted by: RFC 2467 Status: PROPOSED STANDARD This memo specifies the MTU and frame format for transmission of IPv6 [IPV6] packets on FDDI networks, including a method for MTU determination in the presence of 802.1d bridges to other media. [STANDARDS-TRACK]
RFC 2020	IEEE 802.12 Interface MIB
	Authors: J. Flick. Date: October 1996 Formats: txt pdf Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing network interfaces based on IEEE 802.12. [STANDARDS-TRACK]
RFC 2021	Remote Network Monitoring Management Information Base Version 2 using SMIv2
	Authors: S. Waldbusser. Date: January 1997 Formats: txt pdf Obsoleted by: RFC 4502 Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it defines objects for managing remote network monitoring devices.
RFC 2022	Support for Multicast over UNI 3.0/3.1 based ATM Networks
	Authors: G. Armitage. Date: November 1996 Formats: txt pdf Status: PROPOSED STANDARD Mapping the connectionless IP multicast service over the connection oriented ATM services provided by UNI 3.0/3.1 is a non-trivial task.This memo describes a mechanism to support the multicast needs ofLayer 3 protocols in general, and describes its application to IP multicasting in particular. ATM based IP hosts and routers use a Multicast Address ResolutionServer (MARS) to support RFC 1112 style Level 2 IP multicast over theATM Forum's UNI 3.0/3.1 point to multipoint connection service.Clusters of endpoints share a MARS and use it to track and disseminate information identifying the nodes listed as receivers for given multicast groups. This allows endpoints to establish and manage point to multipoint VCs when transmitting to the group. The MARS behaviour allows Layer 3 multicasting to be supported using either meshes of VCs or ATM level multicast servers. This choice may be made on a per-group basis, and is transparent to the endpoints.
RFC 2023	IP Version 6 over PPP
	Authors: D. Haskin, E. Allen. Date: October 1996 Formats: txt pdf Obsoleted by: RFC 2472 Status: PROPOSED STANDARD The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. This document defines the method for transmission of IP Version 6 [2] packets over PPP links as well as the Network Control Protocol (NCP) for establishing and configuring the IPv6 over PPP. It also specifies the method of forming IPv6 link-local addresses on PPP links.
RFC 2024	Definitions of Managed Objects for Data Link Switching using SMIv2
	Authors: D. Chen, Ed., P. Gayek, S. Nix. Date: October 1996 Formats: txt pdf Status: PROPOSED STANDARD This specification defines an extension to the Management InformationBase (MIB) for use with SNMP-based network management. In particular, it defines objects for configuring, monitoring, and controlling Data Link Switches (DLSw) [1]. This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI [2], and semantically identical to the SNMPv1 definitions [3].
RFC 2025	The Simple Public-Key GSS-API Mechanism (SPKM)
	Authors: C. Adams. Date: October 1996 Formats: txt pdf Status: PROPOSED STANDARD This specification defines protocols, procedures, and conventions to be employed by peers implementing the Generic Security ServiceApplication Program Interface (as specified in RFCs 1508 and 1509) when using the Simple Public-Key Mechanism.
RFC 2029	RTP Payload Format of Sun's CellB Video Encoding
	Authors: M. Speer, D. Hoffman. Date: October 1996 Formats: txt pdf Status: PROPOSED STANDARD This memo describes a packetization scheme for the CellB video encoding. The scheme proposed allows applications to transport CellB video flows over protocols used by RTP. This document is meant for implementors of video applications that want to use RTP and CellB.
RFC 2032	RTP Payload Format for H.261 Video Streams
	Authors: T. Turletti, C. Huitema. Date: October 1996 Formats: txt pdf Obsoleted by: RFC 4587 Status: PROPOSED STANDARD This memo describes a scheme to packetize an H.261 video stream for transport using the Real-time Transport Protocol, RTP, with any of the underlying protocols that carry RTP. [STANDARDS-TRACK]
RFC 2034	SMTP Service Extension for Returning Enhanced Error Codes
	Authors: N. Freed. Date: October 1996 Formats: txt pdf Status: PROPOSED STANDARD This memo defines an extension to the SMTP service [RFC-821, RFC-1869] whereby an SMTP server augments its responses with the enhanced mail system status codes defined in RFC 1893. [STANDARDS-TRACK]
RFC 2035	RTP Payload Format for JPEG-compressed Video
	Authors: L. Berc, W. Fenner, R. Frederick, S. McCanne. Date: October 1996 Formats: txt pdf Obsoleted by: RFC 2435 Status: PROPOSED STANDARD This memo describes the RTP payload format for JPEG video streams.The packet format is optimized for real-time video streams where codec parameters change rarely from frame to frame. This document is a product of the Audio-Video Transport working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at rem- conf@es.net and/or the author(s).
RFC 2037	Entity MIB using SMIv2
	Authors: K. McCloghrie, A. Bierman. Date: October 1996 Formats: txt pdf Obsoleted by: RFC 2737 Status: PROPOSED STANDARD 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 multiple logical and physical entities managed by a single SNMP agent. [STANDARDS-TRACK]
RFC 2038	RTP Payload Format for MPEG1/MPEG2 Video
	Authors: D. Hoffman, G. Fernando, V. Goyal. Date: October 1996 Formats: txt pdf Obsoleted by: RFC 2250 Status: PROPOSED STANDARD This memo describes a packetization scheme for MPEG video and audio streams. The scheme proposed can be used to transport such a video or audio flow over the transport protocols supported by RTP. Two approaches are described. The first is designed to support maximum interoperability with MPEG System environments. The second is designed to provide maximum compatibility with other RTP-encapsulated media streams and future conference control work of the IETF.
RFC 2043	The PPP SNA Control Protocol (SNACP)
	Authors: A. Fuqua. Date: October 1996 Formats: txt pdf Status: PROPOSED STANDARD The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol, and proposes a family ofNetwork Control Protocols for establishing and configuring different network-layer protocols. This document defines the Network Control Protocols for establishing and configuring Systems Network Architecture (SNA) over PPP and SNA over LLC 802.2 over PPP.
RFC 2051	Definitions of Managed Objects for APPC using SMIv2
	Authors: M. Allen, B. Clouston, Z. Kielczewski, W. Kwan, B. Moore. Date: October 1996 Formats: txt pdf Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing the configuration, monitoring and controlling of network devices with APPC (Advanced Program-to-Program Communications) capabilities. This memo identifies managed objects for the SNA LU6.2 protocols. [STANDARDS-TRACK]
RFC 2056	Uniform Resource Locators for Z39.50
	Authors: R. Denenberg, J. Kunze, D. Lynch. Date: November 1996 Formats: txt pdf Status: PROPOSED STANDARD Z39.50 is an information retrieval protocol that does not fit neatly into a retrieval model designed primarily around the stateless fetch of data. Instead, it models a general user inquiry as a session-oriented, multi-step task, any step of which may be suspended temporarily while the server requests additional parameters from the client before continuing. [STANDARDS-TRACK]
RFC 2058	Remote Authentication Dial In User Service (RADIUS)
	Authors: C. Rigney, A. Rubens, W. Simpson, S. Willens. Date: January 1997 Formats: txt pdf Obsoleted by: RFC 2138 Status: PROPOSED STANDARD This document describes a protocol for carrying authentication, authorization, and configuration information between a Network AccessServer which desires to authenticate its links and a sharedAuthentication Server.
RFC 2060	Internet Message Access Protocol - Version 4rev1
	Authors: M. Crispin. Date: December 1996 Formats: txt pdf Obsoletes: RFC 1730 Obsoleted by: RFC 3501 Status: PROPOSED STANDARD The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev1 permits manipulation of remote message folders, called "mailboxes", in a way that is functionally equivalent to local mailboxes. IMAP4rev1 also provides the capability for an offline client to resynchronize with the server (see also [IMAP-DISC]). IMAP4rev1 includes operations for creating, deleting, and renaming mailboxes; checking for new messages; permanently removing messages; setting and clearing flags; [RFC-822] and [MIME-IMB] parsing; searching; and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4rev1 are accessed by the use of numbers. These numbers are either message sequence numbers or unique identifiers. IMAP4rev1 supports a single server. A mechanism for accessing configuration information to support multiple IMAP4rev1 servers is discussed in [ACAP]. IMAP4rev1 does not specify a means of posting mail; this function is handled by a mail transfer protocol such as [SMTP]. IMAP4rev1 is designed to be upwards compatible from the [IMAP2] and unpublished IMAP2bis protocols. In the course of the evolution ofIMAP4rev1, some aspects in the earlier protocol have become obsolete.Obsolete commands, responses, and data formats which an IMAP4rev1 implementation may encounter when used with an earlier implementation are described in [IMAP-OBSOLETE]. Other compatibility issues with IMAP2bis, the most common variant of the earlier protocol, are discussed in [IMAP-COMPAT]. A full discussion of compatibility issues with rare (and presumed extinct) variants of [IMAP2] is in [IMAP-HISTORICAL]; this document is primarily of historical interest.
RFC 2065	Domain Name System Security Extensions
	Authors: D. Eastlake 3rd, C. Kaufman. Date: January 1997 Formats: txt pdf Obsoleted by: RFC 2535 Updates: RFC 1034, RFC 1035 Status: PROPOSED STANDARD The Domain Name System (DNS) has become a critical operational part of the Internet infrastructure yet it has no strong security mechanisms to assure data integrity or authentication. Extensions to the DNS are described that provide these services to security aware resolvers or applications through the use of cryptographic digital signatures. These digital signatures are included in secured zones as resource records. Security can still be provided even through non-security aware DNS servers in many cases. The extensions also provide for the storage of authenticated public keys in the DNS. This storage of keys can support general public key distribution service as well as DNS security. The stored keys enable security aware resolvers to learn the authenticating key of zones in addition to those for which they are initially configured. Keys associated with DNS names can be retrieved to support other protocols. Provision is made for a variety of key types and algorithms. In addition, the security extensions provide for the optional authentication of DNS protocol transactions.
RFC 2068	Hypertext Transfer Protocol -- HTTP/1.1
	Authors: R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-Lee. Date: January 1997 Formats: txt pdf Obsoleted by: RFC 2616 Status: PROPOSED STANDARD The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, object-oriented protocol which can be used for many tasks, such as name servers and distributed object management systems, through extension of its request methods.A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred. HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as "HTTP/1.1".
RFC 2069	An Extension to HTTP : Digest Access Authentication
	Authors: J. Franks, P. Hallam-Baker, J. Hostetler, P. Leach, A. Luotonen, E. Sink, L. Stewart. Date: January 1997 Formats: txt pdf Obsoleted by: RFC 2617 Status: PROPOSED STANDARD The protocol referred to as "HTTP/1.0" includes the specification for a Basic Access Authentication scheme. This scheme is not considered to be a secure method of user authentication, as the user name and password are passed over the network as clear text. A specification for a different authentication scheme is needed to address this severe limitation. This document provides specification for such a scheme, referred to as "Digest Access Authentication". Like Basic,Digest access authentication verifies that both parties to a communication know a shared secret (a password); unlike Basic, this verification can be done without sending the password in the clear, which is Basic's biggest weakness. As with most other authentication protocols, the greatest sources of risks are usually found not in the core protocol itself but in policies and procedures surrounding its use.
RFC 2073	An IPv6 Provider-Based Unicast Address Format
	Authors: Y. Rekhter, P. Lothberg, R. Hinden, S. Deering, J. Postel. Date: January 1997 Formats: txt pdf Obsoleted by: RFC 2374 Status: PROPOSED STANDARD This document defines an IPv6 provider-based unicast address format for use in the Internet. [STANDARDS-TRACK]
RFC 2074	Remote Network Monitoring MIB Protocol Identifiers
	Authors: A. Bierman, R. Iddon. Date: January 1997 Formats: txt pdf Obsoleted by: RFC 2895 Status: PROPOSED STANDARD This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes the algorithms required to identify different protocol encapsulations managed with the Remote Network Monitoring MIB Version 2 [RMON2]. [STANDARDS-TRACK]
RFC 2077	The Model Primary Content Type for Multipurpose Internet Mail Extensions
	Authors: S. Nelson, C. Parks, Mitra. Date: January 1997 Formats: txt pdf Status: PROPOSED STANDARD The purpose of this memo is to propose an update to Internet RFC 2045 to include a new primary content-type to be known as "model". [STANDARDS- TRACK]
RFC 2078	Generic Security Service Application Program Interface, Version 2
	Authors: J. Linn. Date: January 1997 Formats: txt pdf Obsoletes: RFC 1508 Obsoleted by: RFC 2743 Status: PROPOSED STANDARD The Generic Security Service Application Program Interface (GSS-API), as defined in RFC-1508, provides security services to callers in a generic fashion, supportable with a range of underlying mechanisms and technologies and hence allowing source-level portability of applications to different environments. This specification definesGSS-API services and primitives at a level independent of underlying mechanism and programming language environment, and is to be complemented by other, related specifications: documents defining specific parameter bindings for particular language environments documents defining token formats, protocols, and procedures to be implemented in order to realize GSS-API services atop particular security mechanisms This memo revises RFC-1508, making specific, incremental changes in response to implementation experience and liaison requests. It is intended, therefore, that this memo or a successor version thereto will become the basis for subsequent progression of the GSS-API specification on the standards track.
RFC 2079	Definition of an X.500 Attribute Type and an Object Class to Hold Uniform Resource Identifiers (URIs)
	Authors: M. Smith. Date: January 1997 Formats: txt pdf Status: PROPOSED STANDARD Uniform Resource Locators (URLs) are being widely used to specify the location of Internet resources. There is an urgent need to be able to include URLs in directories that conform to the LDAP and X.500 information models, and a desire to include other types of UniformResource Identifiers (URIs) as they are defined. A number of independent groups are already experimenting with the inclusion ofURLs in LDAP and X.500 directories. This document builds on the experimentation to date and defines a new attribute type and an auxiliary object class to allow URIs, including URLs, to be stored in directory entries in a standard way.
RFC 2080	RIPng for IPv6
	Authors: G. Malkin, R. Minnear. Date: January 1997 Formats: txt pdf Status: PROPOSED STANDARD This document specifies a routing protocol for an IPv6 internet. It is based on protocols and algorithms currently in wide use in theIPv4 Internet. This specification represents the minimum change to the RoutingInformation Protocol (RIP), as specified in RFC 1058 [1] and RFC 1723[2], necessary for operation over IPv6 [3].
RFC 2082	RIP-2 MD5 Authentication
	Authors: F. Baker, R. Atkinson. Date: January 1997 Formats: txt pdf Obsoleted by: RFC 4822 Status: PROPOSED STANDARD Growth in the Internet has made us aware of the need for improved authentication of routing information. RIP-2 provides for unauthenticated service (as in classical RIP), or password authentication. [STANDARDS-TRACK]
RFC 2085	HMAC-MD5 IP Authentication with Replay Prevention
	Authors: M. Oehler, R. Glenn. Date: February 1997 Formats: txt pdf Status: PROPOSED STANDARD This document describes a keyed-MD5 transform to be used in conjunction with the IP Authentication Header [RFC-1826]. The particular transform is based on [HMAC-MD5]. An option is also specified to guard against replay attacks.
RFC 2086	IMAP4 ACL extension
	Authors: J. Myers. Date: January 1997 Formats: txt pdf Obsoleted by: RFC 4314 Status: PROPOSED STANDARD The ACL extension of the Internet Message Access Protocol [IMAP4] permits access control lists to be manipulated through the IMAP protocol. [STANDARDS-TRACK]
RFC 2087	IMAP4 QUOTA extension
	Authors: J. Myers. Date: January 1997 Formats: txt pdf Status: PROPOSED STANDARD The QUOTA extension of the Internet Message Access Protocol [IMAP4] permits administrative limits on resource usage (quotas) to be manipulated through the IMAP protocol. [STANDARDS-TRACK]
RFC 2088	IMAP4 non-synchronizing literals
	Authors: J. Myers. Date: January 1997 Formats: txt pdf Updated by: RFC 4466 Status: PROPOSED STANDARD The Internet Message Access Protocol [IMAP4] contains the "literal" syntactic construct for communicating strings. When sending a literal from client to server, IMAP4 requires the client to wait for the server to send a command continuation request between sending the octet count and the string data. This document specifies an alternate form of literal which does not require this network round trip. [STANDARDS- TRACK]
RFC 2091	Triggered Extensions to RIP to Support Demand Circuits
	Authors: G. Meyer, S. Sherry. Date: January 1997 Formats: txt pdf Status: PROPOSED STANDARD This document defines a modification which can be applied toBellman-Ford (distance vector) algorithm information broadcasting protocols - for example IP RIP, Netware RIP or Netware SAP - which makes it feasible to run them on connection oriented Public DataNetworks. This proposal has a number of efficiency advantages over the DemandRIP proposal (RFC 1582).
RFC 2095	IMAP/POP AUTHorize Extension for Simple Challenge/Response
	Authors: J. Klensin, R. Catoe, P. Krumviede. Date: January 1997 Formats: txt pdf Obsoleted by: RFC 2195 Status: PROPOSED STANDARD While IMAP4 supports a number of strong authentication mechanisms as described in RFC 1731, it lacks any mechanism that neither passes cleartext, reusable passwords across the network nor requires either a significant security infrastructure or that the mail server update a mail-system-wide user authentication file on each mail access.This specification provides a simple challenge-response authentication protocol that is suitable for use with IMAP4. Since it utilizes Keyed-MD5 digests and does not require that the secret be stored in the clear on the server, it may also constitute an improvement on APOP for POP3 use as specified in RFC 1734.
RFC 2096	IP Forwarding Table MIB
	Authors: F. Baker. Date: January 1997 Formats: txt pdf Obsoletes: RFC 1354 Obsoleted by: RFC 4292 Status: PROPOSED STANDARD This memo defines an update to RFC 1354. The significant difference between this MIB and RFC 1354 is the recognition (explicitly discussed but by consensus left to future work) that CIDR routes may have the same network number but different network masks. [STANDARDS-TRACK]
RFC 2097	The PPP NetBIOS Frames Control Protocol (NBFCP)
	Authors: G. Pall. Date: January 1997 Formats: txt pdf Status: PROPOSED STANDARD The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol, and proposes a family ofNetwork Control Protocols for establishing and configuring different network-layer protocols. The NBF protocol [3] was originally called the NetBEUI protocol. This document defines the Network Control Protocol for establishing and configuring the NBF protocol over PPP. The NBFCP protocol is only applicable for an end system to connect to a peer system or the LAN that peer system is connected to. It is not applicable for connecting two LANs together due to NetBIOS name limitations and NetBIOS name defense mechanisms.
RFC 2108	Definitions of Managed Objects for IEEE 802.3 Repeater Devices using SMIv2
	Authors: K. de Graaf, D. Romascanu, D. McMaster, K. McCloghrie. Date: February 1997 Formats: txt pdf Obsoletes: RFC 1516 Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it defines objects for managing IEEE 802.3 10 and 100Mb/second baseband repeaters based on IEEE Std 802.3 Section 30, "10& 100 Mb/s Management," October 26, 1995.
RFC 2110	MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML)
	Authors: J. Palme, A. Hopmann. Date: March 1997 Formats: txt pdf Obsoleted by: RFC 2557 Status: PROPOSED STANDARD Although HTML [RFC 1866] was designed within the context of MIME, more than the specification of HTML as defined in RFC 1866 is needed for two electronic mail user agents to be able to interoperate usingHTML as a document format. These issues include the naming of objects that are normally referred to by URIs, and the means of aggregating objects that go together. This document describes a set of guidelines that will allow conforming mail user agents to be able to send, deliver and display these objects, such as HTML objects, that can contain links represented by URIs. In order to be able to handle inter-linked objects, the document uses the MIME type multipart/related and specifies the MIME content-headers "Content-Location" and "Content-Base".
RFC 2111	Content-ID and Message-ID Uniform Resource Locators
	Authors: E. Levinson. Date: March 1997 Formats: txt pdf Obsoleted by: RFC 2392 Status: PROPOSED STANDARD The Uniform Resource Locator (URL) schemes, "cid:" and "mid:" allow references to messages and the body parts of messages. For example, within a single multipart message, one HTML body part might include embedded references to other parts of the same message.
RFC 2112	The MIME Multipart/Related Content-type
	Authors: E. Levinson. Date: March 1997 Formats: txt pdf Obsoletes: RFC 1872 Obsoleted by: RFC 2387 Status: PROPOSED STANDARD 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 2113	IP Router Alert Option
	Authors: D. Katz. Date: February 1997 Formats: txt pdf Updated by: RFC 5350, RFC 6398 Status: PROPOSED STANDARD This memo describes a new IP Option type that alerts transit routers to more closely examine the contents of an IP packet. This is useful for, but not limited to, new protocols that are addressed to a destination but require relatively complex processing in routers along the path.
RFC 2122	VEMMI URL Specification
	Authors: D. Mavrakis, H. Layec, K. Kartmann. Date: March 1997 Formats: txt pdf Status: PROPOSED STANDARD A new URL scheme, "vemmi" is defined. VEMMI is a new international standard for on-line multimedia services, that is both an ITU-T (International Telecommunications Union, ex. CCITT) International Standard (T.107) and an European Standard (ETSI European Telecommunications Standard Institute) standard (ETS 300 382, obsoleted by ETS 300 709). [STANDARDS-TRACK]
RFC 2125	The PPP Bandwidth Allocation Protocol (BAP) / The PPP Bandwidth Allocation Control Protocol (BACP)
	Authors: C. Richards, K. Smith. Date: March 1997 Formats: txt pdf Status: PROPOSED STANDARD This document proposes a method to manage the dynamic bandwidth allocation of implementations supporting the PPP multilink protocol[2]. This is done by defining the Bandwidth Allocation Protocol(BAP), as well as its associated control protocol, the BandwidthAllocation Control Protocol (BACP). BAP can be used to manage the number of links in a multilink bundle. BAP defines datagrams to co- ordinate adding and removing individual links in a multilink bundle, as well as specifying which peer is responsible for which decisions regarding managing bandwidth during a multilink connection.
RFC 2126	ISO Transport Service on top of TCP (ITOT)
	Authors: Y. Pouffary, A. Young. Date: March 1997 Formats: txt pdf Updates: RFC 1006 Status: PROPOSED STANDARD This document is a revision to STD35, RFC1006 written by Marshall T.Rose and Dwight E. Cass. Since the release of RFC1006 in May 1987, much experience has been gained in using ISO transport services on top of TCP. This document refines the protocol and will eventually supersede RFC1006. This document describes the mechanism to allow ISO Transport Services to run over TCP over IPv4 or IPv6. It also defines a number of new features, which are not provided in RFC1006. The goal of this version is to minimise the number of changes toRFC1006 and ISO 8073 transport protocol definitions, while maximising performance, extending its applicability and protecting the installed base of RFC1006 users.
RFC 2127	ISDN Management Information Base using SMIv2
	Authors: G. Roeck, Ed.. Date: March 1997 Formats: txt pdf Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it defines a minimal set of managed objects for SNMP- based management of ISDN terminal interfaces. ISDN interfaces are supported on a variety of equipment (for data and voice) including terminal adapters, bridges, hosts, and routers. This document specifies a MIB module in a manner that is compliant to the SNMPv2 SMI. The set of objects is consistent with the SNMP framework and existing SNMP standards. This document is a product of the ISDN MIB working group within theInternet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at isdn- mib@cisco.com and/or the author. The current version of this document reflects changes made during the last call period and the IESG review.
RFC 2128	Dial Control Management Information Base using SMIv2
	Authors: G. Roeck, Ed.. Date: March 1997 Formats: txt pdf Status: PROPOSED STANDARD 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 demand access circuits, including ISDN. This document specifies a MIB module in a manner that is compliant to the SNMPv2 SMI. The set of objects is consistent with the SNMP framework and existing SNMP standards. This document is a product of the ISDN MIB working group within theInternet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at isdn- mib@cisco.com and/or the author.
RFC 2136	Dynamic Updates in the Domain Name System (DNS UPDATE)
	Authors: P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound. Date: April 1997 Formats: txt pdf Updates: RFC 1035 Updated by: RFC 3007, RFC 4035, RFC 4033, RFC 4034 Status: PROPOSED STANDARD The Domain Name System was originally designed to support queries of a statically configured database. While the data was expected to change, the frequency of those changes was expected to be fairly low, and all updates were made as external edits to a zone's Master File. Using this specification of the UPDATE opcode, it is possible to add or delete RRs or RRsets from a specified zone. Prerequisites are specified separately from update operations, and can specify a dependency upon either the previous existence or nonexistence of anRRset, or the existence of a single RR. UPDATE is atomic, i.e., all prerequisites must be satisfied or else no update operations will take place. There are no data dependent error conditions defined after the prerequisites have been met.
RFC 2137	Secure Domain Name System Dynamic Update
	Authors: D. Eastlake 3rd. Date: April 1997 Formats: txt pdf Obsoleted by: RFC 3007 Updates: RFC 1035 Status: PROPOSED STANDARD Domain Name System (DNS) protocol extensions have been defined to authenticate the data in DNS and provide key distribution services[RFC2065]. DNS Dynamic Update operations have also been defined[RFC2136], but without a detailed description of security for the update operation. This memo describes how to use DNSSEC digital signatures covering requests and data to secure updates and restrict updates to those authorized to perform them as indicated by the updater's possession of cryptographic keys.
RFC 2138	Remote Authentication Dial In User Service (RADIUS)
	Authors: C. Rigney, A. Rubens, W. Simpson, S. Willens. Date: April 1997 Formats: txt pdf Obsoletes: RFC 2058 Obsoleted by: RFC 2865 Status: PROPOSED STANDARD This document describes a protocol for carrying authentication, authorization, and configuration information between a Network AccessServer which desires to authenticate its links and a sharedAuthentication Server.
RFC 2141	URN Syntax
	Authors: R. Moats. Date: May 1997 Formats: txt pdf Status: PROPOSED STANDARD Uniform Resource Names (URNs) are intended to serve as persistent, location-independent, resource identifiers. This document sets forward the canonical syntax for URNs. A discussion of both existing legacy and new namespaces and requirements for URN presentation and transmission are presented. Finally, there is a discussion of URN equivalence and how to determine it.
RFC 2142	Mailbox Names for Common Services, Roles and Functions
	Authors: D. Crocker. Date: May 1997 Formats: txt pdf Status: PROPOSED STANDARD This specification enumerates and describes Internet mail addresses (mailbox name @ host reference) to be used when contacting personnel at an organization. [STANDARDS-TRACK]
RFC 2147	TCP and UDP over IPv6 Jumbograms
	Authors: D. Borman. Date: May 1997 Formats: txt pdf Obsoleted by: RFC 2675 Status: PROPOSED STANDARD IPv6 supports datagrams larger than 65535 bytes long, often referred to as jumbograms, through use of the Jumbo Payload hop-by-hop option. The UDP protocol has a 16-bit length field that keeps it from being able to make use of jumbograms, and though TCP does not have a length field, both the MSS option and the Urgent field are constrained by 16-bits. This document describes some simple changes that can be made to allow TCP and UDP to make use of IPv6 jumbograms. [STANDARDS-TRACK]
RFC 2155	Definitions of Managed Objects for APPN using SMIv2
	Authors: B. Clouston, B. Moore. Date: June 1997 Formats: txt pdf Obsoleted by: RFC 2455 Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for monitoring and controlling network devices with APPN (Advanced Peer-to-Peer Networking) capabilities. This memo identifies managed objects for the APPN protocol. [STANDARDS- TRACK]
RFC 2156	MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME
	Authors: S. Kille. Date: January 1998 Formats: txt pdf Obsoletes: RFC 0987, RFC 1026, RFC 1138, RFC 1148, RFC 1327, RFC 1495 Updates: RFC 0822 Status: PROPOSED STANDARD This document relates primarily to the ITU-T 1988 and 1992 X.400 Series Recommendations / ISO IEC 10021 International Standard. This ISO/ITU-T standard is referred to in this document as "X.400", which is a convenient shorthand. [STANDARDS-TRACK]
RFC 2157	Mapping between X.400 and RFC-822/MIME Message Bodies
	Authors: H. Alvestrand. Date: January 1998 Formats: txt pdf Status: PROPOSED STANDARD This document defines how to map body parts of X.400 messages into MIME entities and vice versa, including the handling of multipart messages and forwarded messages. [STANDARDS-TRACK]
RFC 2158	X.400 Image Body Parts
	Authors: H. Alvestrand. Date: January 1998 Formats: txt pdf Status: PROPOSED STANDARD This document contains the body parts defined in RFC 1495 for carrying image formats that were originally defined in MIME through an X.400 system. [STANDARDS-TRACK]
RFC 2159	A MIME Body Part for FAX
	Authors: H. Alvestrand. Date: January 1998 Formats: txt pdf Status: PROPOSED STANDARD This document contains the definitions, originally contained in RFC 1494, on how to carry CCITT G3Fax in MIME, and how to translate it to its X.400 representation. [STANDARDS-TRACK]
RFC 2160	Carrying PostScript in X.400 and MIME
	Authors: H. Alvestrand. Date: January 1998 Formats: txt pdf Status: PROPOSED STANDARD This document describes methods for carrying PostScript information in the two standard mail systems MIME and X.400, and the conversion between them. [STANDARDS-TRACK]
RFC 2163	Using the Internet DNS to Distribute MIXER Conformant Global Address Mapping (MCGAM)
	Authors: C. Allocchio. Date: January 1998 Formats: txt pdf Obsoletes: RFC 1664 Updated by: RFC 3597 Status: PROPOSED STANDARD This memo is the complete technical specification to store in theInternet Domain Name System (DNS) the mapping information (MCGAM) needed by MIXER conformant 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. Organizations can publish their MIXER mapping or preferred gateway routing information using just local resources (their localDNS server), avoiding the need for a strong coordination with any centralised organization. MIXER conformant gateways and tools located on Internet hosts can retrieve the mapping information querying theDNS instead of having fixed tables which need to be centrally updated and distributed. This memo obsoletes RFC1664. It includes the changes introduced byMIXER specification with respect to RFC1327: the new 'gate1' (O/R addresses to domain) table is fully supported. Full backward compatibility with RFC1664 specification is mantained, too. RFC1664 was a joint effort of IETF X400 operation working group(x400ops) and TERENA (formely named "RARE") Mail and Messaging working group (WG-MSG). This update was performed by the IETF MIXER working group.
RFC 2164	Use of an X.500/LDAP directory to support MIXER address mapping
	Authors: S. Kille. Date: January 1998 Formats: txt pdf Obsoletes: RFC 1838 Status: PROPOSED STANDARD This specification defines how to represent and maintain these mappings (MIXER Conformant Global Address Mappings of MCGAMs) in an X.500 or LDAP directory. [STANDARDS-TRACK]
RFC 2165	Service Location Protocol
	Authors: J. Veizades, E. Guttman, C. Perkins, S. Kaplan. Date: June 1997 Formats: txt pdf Updated by: RFC 2608, RFC 2609 Status: PROPOSED STANDARD The Service Location Protocol provides a scalable framework for the discovery and selection of network services. Using this protocol, computers using the Internet no longer need so much static configuration of network services for network based applications.This is especially important as computers become more portable, and users less tolerant or able to fulfill the demands of network system administration.
RFC 2177	IMAP4 IDLE command
	Authors: B. Leiba. Date: June 1997 Formats: txt pdf Status: PROPOSED STANDARD This document specifies the syntax of an IDLE command, which will allow a client to tell the server that it's ready to accept such real-time updates. [STANDARDS-TRACK]
RFC 2181	Clarifications to the DNS Specification
	Authors: R. Elz, R. Bush. Date: July 1997 Formats: txt pdf Updates: RFC 1034, RFC 1035, RFC 1123 Updated by: RFC 4035, RFC 2535, RFC 4343, RFC 4033, RFC 4034, RFC 5452 Status: PROPOSED STANDARD This document considers some areas that have been identified as problems with the specification of the Domain Name System, and proposes remedies for the defects identified. [STANDARDS TRACK]
RFC 2183	Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field
	Authors: R. Troost, S. Dorner, K. Moore, Ed.. Date: August 1997 Formats: txt pdf Obsoletes: RFC 1806 Updated by: RFC 2184, RFC 2231 Status: PROPOSED STANDARD This memo provides a mechanism whereby messages conforming to theMIME specifications [RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC2049] can convey presentational information. It specifies the"Content-Disposition" header field, which is optional and valid for any MIME entity ("message" or "body part"). Two values for this header field 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 MIME. As such, the reader is assumed to be familiar with the MIME specifications, and[RFC 822]. The information presented herein supplements but does not replace that found in those documents. This document is a revision to the Experimental protocol defined inRFC 1806. As compared to RFC 1806, this document contains minor editorial updates, adds new parameters needed to support the FileTransfer Body Part, and references a separate specification for the handling of non-ASCII and/or very long parameter values.
RFC 2184	MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations
	Authors: N. Freed, K. Moore. Date: August 1997 Formats: txt pdf Obsoleted by: RFC 2231 Updates: RFC 2045, RFC 2047, RFC 2183 Status: PROPOSED STANDARD This memo defines extensions to the RFC 2045 media type and RFC 2183 disposition parameter value mechanisms. [STANDARDS-TRACK]
RFC 2192	IMAP URL Scheme
	Authors: C. Newman. Date: September 1997 Formats: txt pdf Obsoleted by: RFC 5092 Status: PROPOSED STANDARD IMAP [IMAP4] is a rich protocol for accessing remote message stores. It provides an ideal mechanism for accessing public mailing list archives as well as private and shared message stores.This document defines a URL scheme for referencing objects on anIMAP server.
RFC 2193	IMAP4 Mailbox Referrals
	Authors: M. Gahrns. Date: September 1997 Formats: txt pdf Status: PROPOSED STANDARD Mailbox referrals allow clients to seamlessly access mailboxes that are distributed across several IMAP4 servers. [STANDARDS-TRACK]
RFC 2195	IMAP/POP AUTHorize Extension for Simple Challenge/Response
	Authors: J. Klensin, R. Catoe, P. Krumviede. Date: September 1997 Formats: txt pdf Obsoletes: RFC 2095 Status: PROPOSED STANDARD While IMAP4 supports a number of strong authentication mechanisms as described in RFC 1731, it lacks any mechanism that neither passes cleartext, reusable passwords across the network nor requires either a significant security infrastructure or that the mail server update a mail-system-wide user authentication file on each mail access.This specification provides a simple challenge-response authentication protocol that is suitable for use with IMAP4. Since it utilizes Keyed-MD5 digests and does not require that the secret be stored in the clear on the server, it may also constitute an improvement on APOP for POP3 use as specified in RFC 1734.
RFC 2198	RTP Payload for Redundant Audio Data
	Authors: C. Perkins, I. Kouvelas, O. Hodson, V. Hardman, M. Handley, J.C. Bolot, A. Vega-Garcia, S. Fosse-Parisis. Date: September 1997 Formats: txt pdf Updated by: RFC 6354 Status: PROPOSED STANDARD This document describes a payload format for use with the real-time transport protocol (RTP), version 2, for encoding redundant audio data. The primary motivation for the scheme described herein is the development of audio conferencing tools for use with lossy packet networks such as the Internet Mbone, although this scheme is not limited to such applications.
RFC 2203	RPCSEC_GSS Protocol Specification
	Authors: M. Eisler, A. Chiu, L. Ling. Date: September 1997 Formats: txt pdf Updated by: RFC 5403 Status: PROPOSED STANDARD This memo describes an ONC/RPC security flavor that allows RPC protocols to access the Generic Security Services ApplicationProgramming Interface (referred to henceforth as GSS-API).
RFC 2205	Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification
	Authors: R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin. Date: September 1997 Formats: txt pdf Updated by: RFC 2750, RFC 3936, RFC 4495, RFC 5946, RFC 6437 Status: PROPOSED STANDARD This memo describes version 1 of RSVP, a resource reservation setup protocol designed for an integrated services Internet. RSVP provides receiver-initiated setup of resource reservations for multicast or unicast data flows, with good scaling and robustness properties.
RFC 2206	RSVP Management Information Base using SMIv2
	Authors: F. Baker, J. Krawczyk, A. Sastry. Date: September 1997 Formats: txt pdf Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it defines objects for managing the ResourceReservation Protocol (RSVP) within the interface attributes defined in the Integrated Services Model. Thus, the Integrated Services MIB is directly relevant to and cross-referenced by this MIB. Comments should be made to the RSVP Working Group, rsvp@isi.edu.
RFC 2207	RSVP Extensions for IPSEC Data Flows
	Authors: L. Berger, T. O'Malley. Date: September 1997 Formats: txt pdf Status: PROPOSED STANDARD This document presents extensions to Version 1 of RSVP. These extensions permit support of individual data flows using RFC 1826, IPAuthentication Header (AH) or RFC 1827, IP Encapsulating SecurityPayload (ESP). RSVP Version 1 as currently specified can support theIPSEC protocols, but only on a per address, per protocol basis not on a per flow basis. The presented extensions can be used with bothIPv4 and IPv6.
RFC 2210	The Use of RSVP with IETF Integrated Services
	Authors: J. Wroclawski. Date: September 1997 Formats: txt pdf Status: PROPOSED STANDARD This note describes the use of the RSVP resource reservation protocol with the Controlled-Load and Guaranteed QoS control services. TheRSVP protocol defines several data objects which carry resource reservation information but are opaque to RSVP itself. The usage and data format of those objects is given here.
RFC 2211	Specification of the Controlled-Load Network Element Service
	Authors: J. Wroclawski. Date: September 1997 Formats: txt pdf Status: PROPOSED STANDARD This memo specifies the network element behavior required to deliverControlled-Load service in the Internet. Controlled-load service provides the client data flow with a quality of service closely approximating the QoS that same flow would receive from an unloaded network element, but uses capacity (admission) control to assure that this service is received even when the network element is overloaded.
RFC 2212	Specification of Guaranteed Quality of Service
	Authors: S. Shenker, C. Partridge, R. Guerin. Date: September 1997 Formats: txt pdf Status: PROPOSED STANDARD This memo describes the network element behavior required to deliver a guaranteed service (guaranteed delay and bandwidth) in theInternet. Guaranteed service provides firm (mathematically provable) bounds on end-to-end datagram queueing delays. This service makes it possible to provide a service that guarantees both delay and bandwidth. This specification follows the service specification template described in [1].
RFC 2213	Integrated Services Management Information Base using SMIv2
	Authors: F. Baker, J. Krawczyk, A. Sastry. Date: September 1997 Formats: txt pdf Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it defines objects for managing the the interface attributes defined in the Integrated Services Model. Comments should be made to the Integrated Services Working Group, int-serv@isi.edu.
RFC 2214	Integrated Services Management Information Base Guaranteed Service Extensions using SMIv2
	Authors: F. Baker, J. Krawczyk, A. Sastry. Date: September 1997 Formats: txt pdf Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it defines objects for managing the the interface attributes defined in the Guaranteed Service of the IntegratedServices Model. Comments should be made to the Integrated ServicesWorking Group, intserv@isi.edu.
RFC 2215	General Characterization Parameters for Integrated Service Network Elements
	Authors: S. Shenker, J. Wroclawski. Date: September 1997 Formats: txt pdf Status: PROPOSED STANDARD This memo defines a set of general control and characterization parameters for network elements supporting the IETF integrated services QoS control framework. General parameters are those with common, shared definitions across all QoS control services.
RFC 2218	A Common Schema for the Internet White Pages Service
	Authors: T. Genovese, B. Jennings. Date: October 1997 Formats: txt pdf Status: PROPOSED STANDARD This work is the result of the IETF Integrated Directory Services(IDS) Working Group. The IDS Working Group proposes a standard specification for a simple Internet White Pages service by defining a common schema for use by the various White Pages servers. This schema is independent of specific implementations of the White Pages service. This document specifies the minimum set of core attributes of a WhitePages entry for an individual and describes how new objects with those attributes can be defined and published. It does not describe how to represent other objects in the White Pages service. Further, it does not address the search sort expectations within a particular service.
RFC 2221	IMAP4 Login Referrals
	Authors: M. Gahrns. Date: October 1997 Formats: txt pdf Status: PROPOSED STANDARD When dealing with large amounts of users and many IMAP4 [RFC-2060] servers, it is often necessary to move users from one IMAP4 server to another. Login referrals allow clients to transparently connect to an alternate IMAP4 server, if their home IMAP4 server has changed. [STANDARDS-TRACK]
RFC 2222	Simple Authentication and Security Layer (SASL)
	Authors: J. Myers. Date: October 1997 Formats: txt pdf Obsoleted by: RFC 4422, RFC 4752 Updated by: RFC 2444 Status: PROPOSED STANDARD This document describes a method for adding authentication support to connection-based protocols. [STANDARDS-TRACK]
RFC 2225	Classical IP and ARP over ATM
	Authors: M. Laubach, J. Halpern. Date: April 1998 Formats: txt pdf Obsoletes: RFC 1626, RFC 1577 Updated by: RFC 5494 Status: PROPOSED STANDARD This memo defines an initial application of classical IP and ARP in an Asynchronous Transfer Mode (ATM) network environment configured as a Logical IP Subnetwork (LIS). [STANDARDS-TRACK]
RFC 2226	IP Broadcast over ATM Networks
	Authors: T. Smith, G. Armitage. Date: October 1997 Formats: txt pdf Status: PROPOSED STANDARD This memo describes how the IP multicast service being developed by the IP over ATM working group may be used to support IP broadcast transmission. The solution revolves around treating the broadcast problem as a special case of multicast, where every host in the subnet or cluster is a member of the group. An understanding of the services provided by RFC 2022 is assumed.
RFC 2227	Simple Hit-Metering and Usage-Limiting for HTTP
	Authors: J. Mogul, P. Leach. Date: October 1997 Formats: txt pdf Status: PROPOSED STANDARD This document proposes a simple extension to HTTP, using a new "Meter" header. [STANDARDS-TRACK]
RFC 2228	FTP Security Extensions
	Authors: M. Horowitz, S. Lunt. Date: October 1997 Formats: txt pdf Updates: RFC 0959 Status: PROPOSED STANDARD This document defines extensions to the FTP specification STD 9, RFC959, "FILE TRANSFER PROTOCOL (FTP)" (October 1985). These extensions provide strong authentication, integrity, and confidentiality on both the control and data channels with the introduction of new optional commands, replies, and file transfer encodings. The following new optional commands are introduced in this specification: AUTH (Authentication/Security Mechanism),ADAT (Authentication/Security Data),PROT (Data Channel Protection Level),PBSZ (Protection Buffer Size),CCC (Clear Command Channel),MIC (Integrity Protected Command),CONF (Confidentiality Protected Command), andENC (Privacy Protected Command). A new class of reply types (6yz) is also introduced for protected replies. None of the above commands are required to be implemented, but interdependencies exist. These dependencies are documented with the commands. Note that this specification is compatible with STD 9, RFC 959.
RFC 2231	MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations
	Authors: N. Freed, K. Moore. Date: November 1997 Formats: txt pdf Obsoletes: RFC 2184 Updates: RFC 2045, RFC 2047, RFC 2183 Status: PROPOSED STANDARD This memo defines extensions to the RFC 2045 media type and RFC 2183 disposition parameter value mechanisms. This memo also defines an extension to the encoded words defined in RFC 2047 to allow the specification of the language to be used for display as well as the character set. [STANDARDS-TRACK]
RFC 2232	Definitions of Managed Objects for DLUR using SMIv2
	Authors: B. Clouston, Ed., B. Moore, Ed.. Date: November 1997 Formats: txt pdf Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for monitoring and controlling network devices with DLUR (Dependent LU Requester) capabilities. This memo identifies managed objects for the DLUR protocol. [STANDARDS-TRACK]
RFC 2233	The Interfaces Group MIB using SMIv2
	Authors: K. McCloghrie, F. Kastenholz. Date: November 1997 Formats: txt pdf Obsoletes: RFC 1573 Obsoleted by: RFC 2863 Status: PROPOSED STANDARD 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 Network Interfaces. [STANDARDS-TRACK]
RFC 2234	Augmented BNF for Syntax Specifications: ABNF
	Authors: D. Crocker, Ed., P. Overell. Date: November 1997 Formats: txt pdf Obsoleted by: RFC 4234 Status: PROPOSED STANDARD In the early days of the Arpanet, each specification contained its own definition of ABNF. This included the email specifications, RFC733 and then RFC822 which have come to be the common citations for defining ABNF. The current document separates out that definition, to permit selective reference. Predictably, it also provides some modifications and enhancements. [STANDARDS-TRACK]
RFC 2236	Internet Group Management Protocol, Version 2
	Authors: W. Fenner. Date: November 1997 Formats: txt pdf Obsoleted by: RFC 3376 Updates: RFC 1112 Status: PROPOSED STANDARD This memo documents IGMPv2, used by IP hosts to report their multicast group memberships to routers. It updates STD 5, RFC 1112. IGMPv2 allows group membership termination to be quickly reported to the routing protocol, which is important for high-bandwidth multicast groups and/or subnets with highly volatile group membership. This document is a product of the Inter-Domain Multicast Routing working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at idmr@cs.ucl.ac.uk and/or the author(s).
RFC 2238	Definitions of Managed Objects for HPR using SMIv2
	Authors: B. Clouston, Ed., B. Moore, Ed.. Date: November 1997 Formats: txt pdf Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for monitoring and controlling network devices with HPR (High Performance Routing) capabilities. This memo identifies managed objects for the HPR protocol. [STANDARDS-TRACK]
RFC 2239	Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) using SMIv2
	Authors: K. de Graaf, D. Romascanu, D. McMaster, K. McCloghrie, S. Roberts. Date: November 1997 Formats: txt pdf Obsoleted by: RFC 2668 Status: PROPOSED STANDARD This memo defines an portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it defines objects for managing 10 and 100 Mb/secondMedium Attachment Units (MAUs) based on IEEE Std 802.3 Section 30,"10 & 100 Mb/s Management," October 26, 1995.
RFC 2241	DHCP Options for Novell Directory Services
	Authors: D. Provan. Date: November 1997 Formats: txt pdf Status: PROPOSED STANDARD This document defines three new DHCP options for delivering configuration information to clients of the Novell DirectoryServices. The first option carries a list of NDS servers. The second option carries the name of the client's NDS tree. The third carries the initial NDS context. These three options provide an NDS client with enough information to connect to an NDS tree without manual configuration of the client.
RFC 2242	NetWare/IP Domain Name and Information
	Authors: R. Droms, K. Fong. Date: November 1997 Formats: txt pdf Status: PROPOSED STANDARD This document defines options that carry NetWare/IP domain name and NetWare/IP sub-options to DHCP clients. [STANDARDS-TRACK]
RFC 2243	OTP Extended Responses
	Authors: C. Metz. Date: November 1997 Formats: txt pdf Status: PROPOSED STANDARD This document provides a specification for a type of response to anOTP [RFC 1938] challenge that carries explicit indication of the response's encoding. Codings for the two mandatory OTP data formats using this new type of response are presented. This document also provides a specification for a response that allows an OTP generator to request that a server re-initialize a sequence and change parameters such as the secret pass phrase.
RFC 2244	ACAP -- Application Configuration Access Protocol
	Authors: C. Newman, J. G. Myers. Date: November 1997 Formats: txt pdf Updated by: RFC 6075 Status: PROPOSED STANDARD The Application Configuration Access Protocol (ACAP) is designed to support remote storage and access of program option, configuration and preference information. The data store model is designed to allow a client relatively simple access to interesting data, to allow new information to be easily added without server re-configuration, and to promote the use of both standardized data and custom or proprietary data. Key features include "inheritance" which can be used to manage default values for configuration settings and access control lists which allow interesting personal information to be shared and group information to be restricted.
RFC 2245	Anonymous SASL Mechanism
	Authors: C. Newman. Date: November 1997 Formats: txt pdf Obsoleted by: RFC 4505 Status: PROPOSED STANDARD It is common practice on the Internet to permit anonymous access to various services. Traditionally, this has been done with a plain text password mechanism using "anonymous" as the user name and optional trace information, such as an email address, as the password. As plaintext login commands are not permitted in new IETF protocols, a new way to provide anonymous login is needed within the context of the SASL [SASL] framework.
RFC 2246	The TLS Protocol Version 1.0
	Authors: T. Dierks, C. Allen. Date: January 1999 Formats: txt pdf Obsoleted by: RFC 4346 Updated by: RFC 3546, RFC 5746, RFC 6176 Status: PROPOSED STANDARD This document specifies Version 1.0 of the Transport Layer Security(TLS) protocol. The TLS protocol provides communications privacy over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.
RFC 2247	Using Domains in LDAP/X.500 Distinguished Names
	Authors: S. Kille, M. Wahl, A. Grimstad, R. Huber, S. Sataluri. Date: January 1998 Formats: txt pdf Updated by: RFC 4519, RFC 4524 Status: PROPOSED STANDARD This document defines an algorithm by which a name registered with the Internet Domain Name Service [2] can be represented as an LDAP distinguished name. [STANDARDS-TRACK]
RFC 2248	Network Services Monitoring MIB
	Authors: N. Freed, S. Kille. Date: January 1998 Formats: txt pdf Obsoletes: RFC 1565 Obsoleted by: RFC 2788 Status: PROPOSED STANDARD This MIB may be used on its own for any application, and for most simple applications this will suffice. This MIB is also designed to serve as a building block which can be used in conjunction with application- specific monitoring and management. [STANDARDS-TRACK]
RFC 2249	Mail Monitoring MIB
	Authors: N. Freed, S. Kille. Date: January 1998 Formats: txt pdf Obsoletes: RFC 1566 Obsoleted by: RFC 2789 Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Specifically, this memo extends the basic Network Services Monitoring MIB [8] to allow monitoring of Message Transfer Agents (MTAs). It may also be used to monitor MTA components within gateways. [STANDARDS- TRACK]
RFC 2250	RTP Payload Format for MPEG1/MPEG2 Video
	Authors: D. Hoffman, G. Fernando, V. Goyal, M. Civanlar. Date: January 1998 Formats: txt pdf Obsoletes: RFC 2038 Status: PROPOSED STANDARD This memo describes a packetization scheme for MPEG video and audio streams. The scheme proposed can be used to transport such a video or audio flow over the transport protocols supported by RTP. Two approaches are described. The first is designed to support maximum interoperability with MPEG System environments. The second is designed to provide maximum compatibility with other RTP-encapsulated media streams and future conference control work of the IETF. This memo is a revision of RFC 2038, an Internet standards track protocol. In this revision, the packet loss resilience mechanisms inSection 3.4 were extended to include additional picture header information required for MPEG2. A new section on security considerations for this payload type is added.
RFC 2251	Lightweight Directory Access Protocol (v3)
	Authors: M. Wahl, T. Howes, S. Kille. Date: December 1997 Formats: txt pdf Obsoleted by: RFC 4510, RFC 4511, RFC 4513, RFC 4512 Updated by: RFC 3377, RFC 3771 Status: PROPOSED STANDARD The protocol described in this document is designed to provide access to directories supporting the X.500 models, while not incurring the resource requirements of the X.500 Directory Access Protocol (DAP). [STANDARDS-TRACK]
RFC 2252	Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions
	Authors: M. Wahl, A. Coulbeck, T. Howes, S. Kille. Date: December 1997 Formats: txt pdf Obsoleted by: RFC 4510, RFC 4517, RFC 4523, RFC 4512 Updated by: RFC 3377 Status: PROPOSED STANDARD This document defines a set of syntaxes for LDAPv3, and the rules by which attribute values of these syntaxes are represented as octet strings for transmission in the LDAP protocol. [STANDARDS-TRACK]
RFC 2253	Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names
	Authors: M. Wahl, S. Kille, T. Howes. Date: December 1997 Formats: txt pdf Obsoletes: RFC 1779 Obsoleted by: RFC 4510, RFC 4514 Updated by: RFC 3377 Status: PROPOSED STANDARD The X.500 Directory uses distinguished names as the primary keys to entries in the directory. Distinguished Names are encoded in ASN.1 in the X.500 Directory protocols. In the Lightweight DirectoryAccess Protocol, a string representation of distinguished names is transferred. This specification defines the string format for representing names, which is designed to give a clean representation of commonly used distinguished names, while being able to represent any distinguished name.
RFC 2254	The String Representation of LDAP Search Filters
	Authors: T. Howes. Date: December 1997 Formats: txt pdf Obsoletes: RFC 1960 Obsoleted by: RFC 4510, RFC 4515 Updated by: RFC 3377 Status: PROPOSED STANDARD This document defines a human-readable string format for representing LDAP search filters. [STANDARDS-TRACK]
RFC 2255	The LDAP URL Format
	Authors: T. Howes, M. Smith. Date: December 1997 Formats: txt pdf Obsoletes: RFC 1959 Obsoleted by: RFC 4510, RFC 4516 Updated by: RFC 3377 Status: PROPOSED STANDARD This document describes a format for an LDAP Uniform Resource Locator. [STANDARDS-TRACK]
RFC 2256	A Summary of the X.500(96) User Schema for use with LDAPv3
	Authors: M. Wahl. Date: December 1997 Formats: txt pdf Obsoleted by: RFC 4517, RFC 4519, RFC 4523, RFC 4512, RFC 4510 Updated by: RFC 3377 Status: PROPOSED STANDARD This document provides an overview of the attribute types and object classes defined by the ISO and ITU-T committees in the X.500 documents, in particular those intended for use by directory clients. [STANDARDS- TRACK]
RFC 2257	Agent Extensibility (AgentX) Protocol Version 1
	Authors: M. Daniele, B. Wijnen, D. Francisco. Date: January 1998 Formats: txt pdf Obsoleted by: RFC 2741 Status: PROPOSED STANDARD This memo defines a standardized framework for extensible SNMP agents. It defines processing entities called master agents and subagents, a protocol (AgentX) used to communicate between them, and the elements of procedure by which the extensible agent processes SNMP protocol messages. [STANDARDS-TRACK]
RFC 2261	An Architecture for Describing SNMP Management Frameworks
	Authors: D. Harrington, R. Presuhn, B. Wijnen. Date: January 1998 Formats: txt pdf Obsoleted by: RFC 2271 Status: PROPOSED STANDARD This document describes an architecture for describing SNMPManagement Frameworks. The architecture is designed to be modular to allow the evolution of the SNMP protocol standards over time. The major portions of the architecture are an SNMP engine containing aMessage Processing Subsystem, a Security Subsystem and an AccessControl Subsystem, and possibly multiple SNMP applications which provide specific functional processing of management data.
RFC 2262	Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)
	Authors: J. Case, D. Harrington, R. Presuhn, B. Wijnen. Date: January 1998 Formats: txt pdf Obsoleted by: RFC 2272 Status: PROPOSED STANDARD This document describes the Message Processing and Dispatching forSNMP messages within the SNMP architecture [RFC2261]. It defines the procedures for dispatching potentially multiple versions of SNMP messages to the proper SNMP Message Processing Models, and for dispatching PDUs to SNMP applications. This document also describes one Message Processing Model - the SNMPv3 Message Processing Model.
RFC 2263	SNMPv3 Applications
	Authors: D. Levi, P. Meyer, B. Stewart. Date: January 1998 Formats: txt pdf Obsoleted by: RFC 2273 Status: PROPOSED STANDARD This memo describes five types of SNMP applications which make use of an SNMP engine as described in [RFC2261]. The types of application described are Command Generators, Command Responders, NotificationOriginators, Notification Receivers, and Proxy Forwarders. This memo also defines MIB modules for specifying targets of management operations, for notification filtering, and for proxy forwarding.
RFC 2264	User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)
	Authors: U. Blumenthal, B. Wijnen. Date: January 1998 Formats: txt pdf Obsoleted by: RFC 2274 Status: PROPOSED STANDARD This document describes the User-based Security Model (USM) for SNMP version 3 for use in the SNMP architecture [RFC2261]. It defines theElements of Procedure for providing SNMP message level security.This document also includes a MIB for remotely monitoring/managing the configuration parameters for this Security Model.
RFC 2265	View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)
	Authors: B. Wijnen, R. Presuhn, K. McCloghrie. Date: January 1998 Formats: txt pdf Obsoleted by: RFC 2275 Status: PROPOSED STANDARD This document describes the View-based Access Control Model for use in the SNMP architecture [RFC2261]. It defines the Elements ofProcedure for controlling access to management information. This document also includes a MIB for remotely managing the configuration parameters for the View-based Access Control Model.
RFC 2266	Definitions of Managed Objects for IEEE 802.12 Repeater Devices
	Authors: J. Flick. Date: January 1998 Formats: txt pdf Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it defines objects for managing network repeaters based on IEEE 802.12.
RFC 2271	An Architecture for Describing SNMP Management Frameworks
	Authors: D. Harrington, R. Presuhn, B. Wijnen. Date: January 1998 Formats: txt pdf Obsoletes: RFC 2261 Obsoleted by: RFC 2571 Status: PROPOSED STANDARD This document describes an architecture for describing SNMPManagement Frameworks. The architecture is designed to be modular to allow the evolution of the SNMP protocol standards over time. The major portions of the architecture are an SNMP engine containing aMessage Processing Subsystem, a Security Subsystem and an AccessControl Subsystem, and possibly multiple SNMP applications which provide specific functional processing of management data.
RFC 2272	Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)
	Authors: J. Case, D. Harrington, R. Presuhn, B. Wijnen. Date: January 1998 Formats: txt pdf Obsoletes: RFC 2262 Obsoleted by: RFC 2572 Status: PROPOSED STANDARD This document describes the Message Processing and Dispatching forSNMP messages within the SNMP architecture [RFC2271]. It defines the procedures for dispatching potentially multiple versions of SNMP messages to the proper SNMP Message Processing Models, and for dispatching PDUs to SNMP applications. This document also describes one Message Processing Model - the SNMPv3 Message Processing Model.
RFC 2273	SNMPv3 Applications
	Authors: D. Levi, P. Meyer, B. Stewart. Date: January 1998 Formats: txt pdf Obsoletes: RFC 2263 Obsoleted by: RFC 2573 Status: PROPOSED STANDARD This memo describes five types of SNMP applications which make use of an SNMP engine as described in [RFC2271]. The types of application described are Command Generators, Command Responders, NotificationOriginators, Notification Receivers, and Proxy Forwarders. This memo also defines MIB modules for specifying targets of management operations, for notification filtering, and for proxy forwarding.
RFC 2274	User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)
	Authors: U. Blumenthal, B. Wijnen. Date: January 1998 Formats: txt pdf Obsoletes: RFC 2264 Obsoleted by: RFC 2574 Status: PROPOSED STANDARD This document describes the User-based Security Model (USM) for SNMP version 3 for use in the SNMP architecture [RFC2271]. It defines theElements of Procedure for providing SNMP message level security.This document also includes a MIB for remotely monitoring/managing the configuration parameters for this Security Model.
RFC 2275	View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)
	Authors: B. Wijnen, R. Presuhn, K. McCloghrie. Date: January 1998 Formats: txt pdf Obsoletes: RFC 2265 Obsoleted by: RFC 2575 Status: PROPOSED STANDARD This document describes the View-based Access Control Model for use in the SNMP architecture [RFC2271]. It defines the Elements ofProcedure for controlling access to management information. This document also includes a MIB for remotely managing the configuration parameters for the View-based Access Control Model.
RFC 2280	Routing Policy Specification Language (RPSL)
	Authors: C. Alaettinoglu, T. Bates, E. Gerich, D. Karrenberg, D. Meyer, M. Terpstra, C. Villamizar. Date: January 1998 Formats: txt pdf Obsoleted by: RFC 2622 Status: PROPOSED STANDARD This memo is the reference document for the Routing Policy Specification Language (RPSL). RPSL allows a network operator to be able to specify routing policies at various levels in the Internet hierarchy; for example at the Autonomous System (AS) level. At the same time, policies can be specified with sufficient detail in RPSL so that low level router configurations can be generated from them. RPSL is extensible; new routing protocols and new protocol features can be introduced at any time. [STANDARDS-TRACK]
RFC 2283	Multiprotocol Extensions for BGP-4
	Authors: T. Bates, R. Chandra, D. Katz, Y. Rekhter. Date: February 1998 Formats: txt pdf Obsoleted by: RFC 2858 Status: PROPOSED STANDARD This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, etc...). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions. [STANDARDS-TRACK]
RFC 2284	PPP Extensible Authentication Protocol (EAP)
	Authors: L. Blunk, J. Vollbrecht. Date: March 1998 Formats: txt pdf Obsoleted by: RFC 3748 Updated by: RFC 2484 Status: PROPOSED STANDARD The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP also defines an extensible Link Control Protocol, which allows negotiation of an Authentication Protocol for authenticating its peer before allowing Network Layer protocols to transmit over the link. This document defines the PPP Extensible Authentication Protocol.
RFC 2287	Definitions of System-Level Managed Objects for Applications
	Authors: C. Krupczak, J. Saperia. Date: February 1998 Formats: txt pdf Status: PROPOSED STANDARD 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 a basic set of managed objects for fault, configuration and performance management of applications from a systems perspective. [STANDARDS-TRACK]
RFC 2290	Mobile-IPv4 Configuration Option for PPP IPCP
	Authors: J. Solomon, S. Glass. Date: February 1998 Formats: txt pdf Updates: RFC 2002 Updated by: RFC 2794 Status: PROPOSED STANDARD Mobile IP [RFC 2002] defines media-independent procedures by which aMobile Node can maintain existing transport and application-layer connections despite changing its point-of-attachment to the Internet and without changing its IP address. PPP [RFC 1661] provides a standard method for transporting multi-protocol packets over point- to-point links. As currently specified, Mobile IP Foreign Agents which support Mobile Node connections via PPP can do so only by first assigning unique addresses to those Mobile Nodes, defeating one of the primary advantages of Foreign Agents. This documents corrects this problem by defining the Mobile-IPv4 Configuration Option to theInternet Protocol Control Protocol (IPCP) [RFC 1332]. Using this option, two peers can communicate their support for Mobile IP during the IPCP phase of PPP. Familiarity with Mobile IP [RFC 2002], IPCP[RFC 1332], and PPP [RFC 1661] is assumed.
RFC 2293	Representing Tables and Subtrees in the X.500 Directory
	Authors: S. Kille. Date: March 1998 Formats: txt pdf Obsoletes: RFC 1837 Status: PROPOSED STANDARD 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 2294	Representing the O/R Address hierarchy in the X.500 Directory Information Tree
	Authors: S. Kille. Date: March 1998 Formats: txt pdf Obsoletes: RFC 1836 Status: PROPOSED STANDARD 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: o Support for MHS Routing [4]. o Support for X.400/RFC 822 address mappings [2, 5]. Please send comments to the author or to the discussion group <mhs- ds@mercury.udev.cdc.com&rt;. Object Class Mandatory------------ --------- mHSCountry M aDMD M pRMD O mHSX121 O mHSNumericUserIdentifier O mHSOrganization O mHSOrganizationalUnit O mHSPerson O mHSNamedObject O mHSTerminalID O mHSDomainDefinedAttribute O Table 1: Order of O/R Address Directory Components
RFC 2298	An Extensible Message Format for Message Disposition Notifications
	Authors: R. Fajman. Date: March 1998 Formats: txt pdf Obsoleted by: RFC 3798 Status: PROPOSED STANDARD This memo defines a MIME content-type that may be used by a mail user agent (UA) or electronic mail gateway to report the disposition of a message after it has been sucessfully delivered to a recipient. This content-type is intended to be machine-processable. Additional message headers are also defined to permit Message DispositionNotifications (MDNs) to be requested by the sender of a message. The purpose is to extend Internet Mail to support functionality often found in other messaging systems, such as X.400 and the proprietary"LAN-based" systems, and often referred to as "read receipts,""acknowledgements," or "receipt notifications." The intention is to do this while respecting the privacy concerns that have often been expressed when such functions have been discussed in the past. Because many messages are sent between the Internet and other messaging systems (such as X.400 or the proprietary "LAN-based" systems), the MDN protocol is designed to be useful in a multi- protocol messaging environment. To this end, the protocol described in this memo provides for the carriage of "foreign" addresses, in addition to those normally used in Internet Mail. Additional attributes may also be defined to support "tunneling" of foreign notifications through Internet Mail.
RFC 2301	File Format for Internet Fax
	Authors: L. McIntyre, S. Zilles, R. Buckley, D. Venable, G. Parsons, J. Rafferty. Date: March 1998 Formats: txt pdf Obsoleted by: RFC 3949 Status: PROPOSED STANDARD This document describes the TIFF (Tag Image File Format) representation of image data specified by the ITU-T Recommendations for black-and-white and color facsimile. This file format specification is commonly known as TIFF-FX. It formally defines minimal, extended and lossless JBIG modes (Profiles S, F, J) for black-and-white fax, and base JPEG, lossless JBIG and Mixed RasterContent modes (Profiles C, L, M) for color and grayscale fax. These modes or profiles correspond to the content of the applicable ITU-TRecommendations. Files formatted according to this specification use the image/tiff MIME Content Type.
RFC 2302	Tag Image File Format (TIFF) - image/tiff MIME Sub-type Registration
	Authors: G. Parsons, J. Rafferty, S. Zilles. Date: March 1998 Formats: txt pdf Obsoleted by: RFC 3302 Status: PROPOSED STANDARD This document describes the registration of the MIME sub-type image/tiff. [STANDARDS-TRACK]
RFC 2303	Minimal PSTN address format in Internet Mail
	Authors: C. Allocchio. Date: March 1998 Formats: txt pdf Obsoleted by: RFC 3191 Status: PROPOSED STANDARD This memo describes the MINIMAL addressing method to encode PSTN addresses into e-mail addresses and the standard extension mechanism to allow definition of further standard elements. [STANDARDS-TRACK]
RFC 2304	Minimal FAX address format in Internet Mail
	Authors: C. Allocchio. Date: March 1998 Formats: txt pdf Obsoleted by: RFC 3192 Status: PROPOSED STANDARD This memo describes the MINIMAL addressing method and standard extensions to encode FAX addresses in e-mail addresses. [STANDARDS- TRACK]
RFC 2305	A Simple Mode of Facsimile Using Internet Mail
	Authors: K. Toyoda, H. Ohno, J. Murai, D. Wing. Date: March 1998 Formats: txt pdf Obsoleted by: RFC 3965 Status: PROPOSED STANDARD This specification provides for "simple mode" carriage of facsimile data over the Internet. [STANDARDS-TRACK]
RFC 2308	Negative Caching of DNS Queries (DNS NCACHE)
	Authors: M. Andrews. Date: March 1998 Formats: txt pdf Updates: RFC 1034, RFC 1035 Updated by: RFC 4035, RFC 4033, RFC 4034, RFC 6604 Status: PROPOSED STANDARD [RFC1034] provided a description of how to cache negative responses.It however had a fundamental flaw in that it did not allow a name server to hand out those cached responses to other resolvers, thereby greatly reducing the effect of the caching. This document addresses issues raise in the light of experience and replaces [RFC1034 Section4.3.4]. Negative caching was an optional part of the DNS specification and deals with the caching of the non-existence of an RRset [RFC2181] or domain name. Negative caching is useful as it reduces the response time for negative answers. It also reduces the number of messages that have to be sent between resolvers and name servers hence overall network traffic. A large proportion of DNS traffic on the Internet could be eliminated if all resolvers implemented negative caching. With this in mind negative caching should no longer be seen as an optional part of a DNS resolver.
RFC 2320	Definitions of Managed Objects for Classical IP and ARP Over ATM Using SMIv2 (IPOA-MIB)
	Authors: M. Greene, J. Luciani, K. White, T. Kuo. Date: April 1998 Formats: txt pdf Status: PROPOSED STANDARD The purpose of this memo is to define the Management Information Base(MIB) for supporting Classical IP and ARP over ATM as specified inClassical IP and ARP over ATM, refer to reference [3]. Support of anATM interface by an IP layer will require implementation of objects from several Management Information Bases (MIBs) as well as their enhancement in order to enable usage of ATM transports. It is the intent of this MIB to fully adhere to all prerequisite MIBs unless explicitly stated. Deviations will be documented in corresponding conformance statements. The specification of this MIB will utilize the Structure of Management Information (SMI) for Version 2 of theSimple Network Management Protocol Version (refer to RFC 1902, reference [1]).
RFC 2326	Real Time Streaming Protocol (RTSP)
	Authors: H. Schulzrinne, A. Rao, R. Lanphier. Date: April 1998 Formats: txt pdf Status: PROPOSED STANDARD The Real Time Streaming Protocol, or RTSP, is an application-level protocol for control over the delivery of data with real-time properties. RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and video. Sources of data can include both live data feeds and stored clips. This protocol is intended to control multiple data delivery sessions, provide a means for choosing delivery channels such as UDP, multicast UDP and TCP, and provide a means for choosing delivery mechanisms based upon RTP (RFC 1889).
RFC 2327	SDP: Session Description Protocol
	Authors: M. Handley, V. Jacobson. Date: April 1998 Formats: txt pdf Obsoleted by: RFC 4566 Updated by: RFC 3266 Status: PROPOSED STANDARD This document defines the Session Description Protocol, SDP. SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. This document is a product of the Multiparty Multimedia SessionControl (MMUSIC) working group of the Internet Engineering TaskForce. Comments are solicited and should be addressed to the working group's mailing list at confctrl@isi.edu and/or the authors.
RFC 2331	ATM Signalling Support for IP over ATM - UNI Signalling 4.0 Update
	Authors: M. Maher. Date: April 1998 Formats: txt pdf Status: PROPOSED STANDARD This memo describes how to efficiently use the ATM call control signalling procedures defined in UNI Signalling 4.0 [SIG40] to support IP over ATM environments as described in RFC 2225 [LAUB98] and in RFC 2332 [LUC98]. Among the new features found in UNISignalling 4.0 are Available Bit Rate signalling and traffic parameter negotiation. This memo highlights the features of UNISignalling 4.0 that provide IP entities capabilities for requestingATM service in sites with SVC support, whether it is private ATM or publicly provisioned ATM, in which case the SVC support is probably configured inside PVPs. This document is only relevant to IP when used as the well known"best effort" connectionless service. In particular, this means that this document does not pertain to IP in the presence of implementedIP Integrated Services. The topic of IP with Integrated Services over ATM will be handled by a different specification or set of specifications being worked on in the ISSLL WG. This specification is a follow-on to RFC 1755, "ATM Signaling Support for IP over ATM", which is based on UNI 3.1 signalling [UNI95].Readers are assumed to be familiar with RFC 1755.
RFC 2332	NBMA Next Hop Resolution Protocol (NHRP)
	Authors: J. Luciani, D. Katz, D. Piscitello, B. Cole, N. Doraswamy. Date: April 1998 Formats: txt pdf Status: PROPOSED STANDARD This document describes the NBMA Next Hop Resolution Protocol (NHRP).NHRP can be used by a source station (host or router) connected to aNon-Broadcast, Multi-Access (NBMA) subnetwork to determine the internetworking layer address and NBMA subnetwork addresses of the"NBMA next hop" towards a destination station. If the destination is connected to the NBMA subnetwork, then the NBMA next hop is the destination station itself. Otherwise, the NBMA next hop is the egress router from the NBMA subnetwork that is "nearest" to the destination station. NHRP is intended for use in a multiprotocol internetworking layer environment over NBMA subnetworks. Note that while this protocol was developed for use with NBMA subnetworks, it is possible, if not likely, that it will be applied to BMA subnetworks as well. However, this usage of NHRP is for further study. This document is intended to be a functional superset of the NBMAAddress Resolution Protocol (NARP) documented in [1]. Operation of NHRP as a means of establishing a transit path across anNBMA subnetwork between two routers will be addressed in a separate document (see [13]).
RFC 2333	NHRP Protocol Applicability Statement
	Authors: D. Cansever. Date: April 1998 Formats: txt pdf Status: PROPOSED STANDARD As required by the Routing Protocol Criteria [RFC 1264], this memo discusses the applicability of the Next Hop Resolution Protocol(NHRP) in routing of IP datagrams over Non-Broadcast Multiple Access(NBMA) networks, such as ATM, SMDS and X.25.
RFC 2334	Server Cache Synchronization Protocol (SCSP)
	Authors: J. Luciani, G. Armitage, J. Halpern, N. Doraswamy. Date: April 1998 Formats: txt pdf Status: PROPOSED STANDARD This document describes the Server Cache Synchronization Protocol(SCSP) and is written in terms of SCSP's use within Non BroadcastMultiple Access (NBMA) networks; although, a somewhat straight forward usage is applicable to BMA networks. SCSP attempts to solve the generalized cache synchronization/cache-replication problem for distributed protocol entities. However, in this document, SCSP is couched in terms of the client/server paradigm in which distributed server entities, which are bound to a Server Group (SG) through some means, wish to synchronize the contents (or a portion thereof) of their caches which contain information about the state of clients being served.
RFC 2335	A Distributed NHRP Service Using SCSP
	Authors: J. Luciani. Date: April 1998 Formats: txt pdf Status: PROPOSED STANDARD This document describes a method for distributing an NHRP service within a LIS [1]. This method uses the Server Cache SynchronizationProtocol (SCSP) [2] to synchronize the client information databases held by NHRP Servers (NHSs) within a LIS.
RFC 2338	Virtual Router Redundancy Protocol
	Authors: S. Knight, D. Weaver, D. Whipple, R. Hinden, D. Mitzel, P. Hunt, P. Higginson, M. Shand, A. Lindem. Date: April 1998 Formats: txt pdf Obsoleted by: RFC 3768 Status: PROPOSED STANDARD This memo defines the Virtual Router Redundancy Protocol (VRRP).VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on aLAN. The VRRP router controlling the IP address(es) associated with a virtual router is called the Master, and forwards packets sent to these IP addresses. The election process provides dynamic fail over in the forwarding responsibility should the Master become unavailable. This allows any of the virtual router IP addresses on the LAN to be used as the default first hop router by end-hosts. The advantage gained from using VRRP is a higher availability default path without requiring configuration of dynamic routing or router discovery protocols on every end-host.
RFC 2342	IMAP4 Namespace
	Authors: M. Gahrns, C. Newman. Date: May 1998 Formats: txt pdf Updated by: RFC 4466 Status: PROPOSED STANDARD This document defines a NAMESPACE command that allows a client to discover the prefixes of namespaces used by a server for personal mailboxes, other users' mailboxes, and shared mailboxes. [STANDARDS- TRACK]
RFC 2344	Reverse Tunneling for Mobile IP
	Authors: G. Montenegro, Ed.. Date: May 1998 Formats: txt pdf Obsoleted by: RFC 3024 Status: PROPOSED STANDARD Mobile IP uses tunneling from the home agent to the mobile node's care-of address, but rarely in the reverse direction. Usually, a mobile node sends its packets through a router on the foreign network, and assumes that routing is independent of source address.When this assumption is not true, it is convenient to establish a topologically correct reverse tunnel from the care-of address to the home agent. This document proposes backwards-compatible extensions to Mobile IP in order to support topologically correct reverse tunnels. This document does not attempt to solve the problems posed by firewalls located between the home agent and the mobile node's care-of address.
RFC 2358	Definitions of Managed Objects for the Ethernet-like Interface Types
	Authors: J. Flick, J. Johnson. Date: June 1998 Formats: txt pdf Obsoletes: RFC 1650 Obsoleted by: RFC 2665 Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.This memo obsoletes RFC 1650 "Definitions of Managed Objects for theEthernet-like Interface Types using SMIv2". This memo extends that specification by including management information useful for the management of 100 Mb/s Ethernet interfaces. Ethernet technology, as defined by the 802.3 Working Group of theIEEE, continues to evolve, with scalable increases in speed, new types of cabling and interfaces, and new features. This evolution may require changes in the managed objects in order to reflect this new functionality. This document, as with other documents issued by this working group, reflect a certain stage in the evolution ofEthernet technology. In the future, this document might be revised, or new documents might be issued by the Ethernet Interfaces and HubMIB Working Group, in order to reflect the evolution of Ethernet technology.
RFC 2359	IMAP4 UIDPLUS extension
	Authors: J. Myers. Date: June 1998 Formats: txt pdf Obsoleted by: RFC 4315 Status: PROPOSED STANDARD The UIDPLUS extension of the Internet Message Access Protocol [IMAP4] provides a set of features intended to reduce the amount of time and resources used by some client operations. [STANDARDS-TRACK]
RFC 2363	PPP Over FUNI
	Authors: G. Gross, M. Kaycee, A. Li, A. Malis, J. Stephens. Date: July 1998 Formats: txt pdf Status: PROPOSED STANDARD The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. This document describes the use of ATM Frame User Network Interface(FUNI) for framing PPP encapsulated packets.
RFC 2364	PPP Over AAL5
	Authors: G. Gross, M. Kaycee, A. Li, A. Malis, J. Stephens. Date: July 1998 Formats: txt pdf Status: PROPOSED STANDARD The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. This document describes the use of ATM Adaptation Layer 5 (AAL5) for framing PPP encapsulated packets.
RFC 2366	Definitions of Managed Objects for Multicast over UNI 3.0/3.1 based ATM Networks
	Authors: C. Chung, M. Greene. Date: July 1998 Formats: txt pdf Obsoleted by: RFC 2417 Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes managed objects for IP hosts and routers that use a Multicast Address Resolution Server (MARS) to support IP multicast over ATM, as described in 'Support for Multicast over UNI3.0/3.1 based ATM Networks' [1]. This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions. This memo does not specify a standard for the Internet community.
RFC 2368	The mailto URL scheme
	Authors: P. Hoffman, L. Masinter, J. Zawinski. Date: July 1998 Formats: txt pdf Obsoleted by: RFC 6068 Updates: RFC 1738, RFC 1808 Status: PROPOSED STANDARD This document defines the format of Uniform Resource Locators (URL) for designating electronic mail addresses. It is one of a suite of documents which replace RFC 1738, 'Uniform Resource Locators', andRFC 1808, 'Relative Uniform Resource Locators'. The syntax of'mailto' URLs from RFC 1738 is extended to allow creation of more RFC822 messages by allowing the URL to express additional header and body fields.
RFC 2369	The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields
	Authors: G. Neufeld, J. Baer. Date: July 1998 Formats: txt pdf Status: PROPOSED STANDARD The mailing list command specification header fields are a set of structured fields to be added to email messages sent by email distribution lists. Each field typically contains a URL (usually mailto [RFC2368]) locating the relevant information or performing the command directly. The three core header fields described in this document are List-Help, List-Subscribe, and List-Unsubscribe. There are three other header fields described here which, although not as widely applicable, will have utility for a sufficient number of mailing lists to justify their formalization here. These areList-Post, List-Owner and List-Archive. By including these header fields, list servers can make it possible for mail clients to provide automated tools for users to perform list functions. This could take the form of a menu item, push button, or other user interface element. The intent is to simplify the user experience, providing a common interface to the often cryptic and varied mailing list manager commands.
RFC 2370	The OSPF Opaque LSA Option
	Authors: R. Coltun. Date: July 1998 Formats: txt pdf Obsoleted by: RFC 5250 Updated by: RFC 3630 Also: RFC 2328 Status: PROPOSED STANDARD This memo defines enhancements to the OSPF protocol to support a new class of link-state advertisements (LSA) called Opaque LSAs. [STANDARDS-TRACK]
RFC 2371	Transaction Internet Protocol Version 3.0
	Authors: J. Lyon, K. Evans, J. Klein. Date: July 1998 Formats: txt pdf Status: PROPOSED STANDARD In many applications where different nodes cooperate on some work, there is a need to guarantee that the work happens atomically. That is, each node must reach the same conclusion as to whether the work is to be completed, even in the face of failures. This document proposes a simple, easily-implemented protocol for achieving this end.
RFC 2373	IP Version 6 Addressing Architecture
	Authors: R. Hinden, S. Deering. Date: July 1998 Formats: txt pdf Obsoletes: RFC 1884 Obsoleted by: RFC 3513 Status: PROPOSED STANDARD This specification defines the addressing architecture of the IPVersion 6 protocol [IPV6]. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and anIPv6 node's required addresses.
RFC 2380	RSVP over ATM Implementation Requirements
	Authors: L. Berger. Date: August 1998 Formats: txt pdf Status: PROPOSED STANDARD This memo presents specific implementation requirements for runningRSVP over ATM switched virtual circuits (SVCs). It presents requirements that ensure interoperability between multiple implementations and conformance to the RSVP and Integrated Services specifications. A separate document [5] provides specific guidelines for running over today's ATM networks. The general problem is discussed in [9]. Integrated Services to ATM service mappings are covered in [6]. The full set of documents present the background and information needed to implement Integrated Services and RSVP overATM.
RFC 2381	Interoperation of Controlled-Load Service and Guaranteed Service with ATM
	Authors: M. Garrett, M. Borden. Date: August 1998 Formats: txt pdf Status: PROPOSED STANDARD This document provides guidelines for mapping service classes, and traffic management features and parameters between Internet and ATM technologies. The service mappings are useful for providing effective interoperation and end-to-end Quality of Service for IPIntegrated Services networks containing ATM subnetworks. The discussion and specifications given here support the IP integrated services protocols for Guaranteed Service (GS),Controlled-Load Service (CLS) and the ATM Forum UNI specification, versions 3.0, 3.1 and 4.0. Some discussion of IP best effort service over ATM is also included.
RFC 2384	POP URL Scheme
	Authors: R. Gellens. Date: August 1998 Formats: txt pdf Status: PROPOSED STANDARD This memo defines a URL scheme for referencing a POP mailbox. [STANDARDS-TRACK]
RFC 2385	Protection of BGP Sessions via the TCP MD5 Signature Option
	Authors: A. Heffernan. Date: August 1998 Formats: txt pdf Obsoleted by: RFC 5925 Status: PROPOSED STANDARD This memo describes a TCP extension to enhance security for BGP. It defines a new TCP option for carrying an MD5 [RFC1321] digest in aTCP segment. This digest acts like a signature for that segment, incorporating information known only to the connection end points.Since BGP uses TCP as its transport, using this option in the way described in this paper significantly reduces the danger from certain security attacks on BGP.
RFC 2387	The MIME Multipart/Related Content-type
	Authors: E. Levinson. Date: August 1998 Formats: txt pdf Obsoletes: RFC 2112 Status: PROPOSED STANDARD 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 2388	Returning Values from Forms: multipart/form-data
	Authors: L. Masinter. Date: August 1998 Formats: txt pdf Status: PROPOSED STANDARD This specification defines an Internet Media Type, multipart/form-data, which can be used by a wide variety of applications and transported by a wide variety of protocols as a way of returning a set of values as the result of a user filling out a form. [STANDARDS-TRACK]
RFC 2389	Feature negotiation mechanism for the File Transfer Protocol
	Authors: P. Hethmon, R. Elz. Date: August 1998 Formats: txt pdf Also: RFC 0959 Status: PROPOSED STANDARD The File Transfer Protocol is, from time to time, extended with new commands, or facilities. Implementations of the FTP protocol cannot be assumed to all immediately implement all newly defined mechanisms.This document provides a mechanism by which clients of the FTP protocol can discover which new features are supported by a particular FTP server.
RFC 2392	Content-ID and Message-ID Uniform Resource Locators
	Authors: E. Levinson. Date: August 1998 Formats: txt pdf Obsoletes: RFC 2111 Status: PROPOSED STANDARD The Uniform Resource Locator (URL) schemes, "cid:" and "mid:" allow references to messages and the body parts of messages. For example, within a single multipart message, one HTML body part might include embedded references to other parts of the same message.
RFC 2393	IP Payload Compression Protocol (IPComp)
	Authors: A. Shacham, R. Monsour, R. Pereira, M. Thomas. Date: December 1998 Formats: txt pdf Obsoleted by: RFC 3173 Status: PROPOSED STANDARD This document describes a protocol intended to provide lossless compression for Internet Protocol datagrams in an Internet environment.
RFC 2397	The "data" URL scheme
	Authors: L. Masinter. Date: August 1998 Formats: txt pdf Status: PROPOSED STANDARD A new URL scheme, "data", is defined. It allows inclusion of small data items as "immediate" data, as if it had been included externally. [STANDARDS-TRACK]
RFC 2401	Security Architecture for the Internet Protocol
	Authors: S. Kent, R. Atkinson. Date: November 1998 Formats: txt pdf Obsoletes: RFC 1825 Obsoleted by: RFC 4301 Updated by: RFC 3168 Status: PROPOSED STANDARD This memo specifies the base architecture for IPsec compliant systems. [STANDARDS-TRACK]
RFC 2402	IP Authentication Header
	Authors: S. Kent, R. Atkinson. Date: November 1998 Formats: txt pdf Obsoletes: RFC 1826 Obsoleted by: RFC 4302, RFC 4305 Status: PROPOSED STANDARD The IP Authentication Header (AH) is used to provide connectionless integrity and data origin authentication for IP datagrams (hereafter referred to as just "authentication"), and to provide protection against replays. [STANDARDS-TRACK]
RFC 2403	The Use of HMAC-MD5-96 within ESP and AH
	Authors: C. Madson, R. Glenn. Date: November 1998 Formats: txt pdf Status: PROPOSED STANDARD This memo describes the use of the HMAC algorithm [RFC-2104] in conjunction with the MD5 algorithm [RFC-1321] as an authentication mechanism within the revised IPSEC Encapsulating Security Payload[ESP] and the revised IPSEC Authentication Header [AH]. HMAC with MD5 provides data origin authentication and integrity protection. Further information on the other components necessary for ESP and AH implementations is provided by [Thayer97a].
RFC 2404	The Use of HMAC-SHA-1-96 within ESP and AH
	Authors: C. Madson, R. Glenn. Date: November 1998 Formats: txt pdf Status: PROPOSED STANDARD This memo describes the use of the HMAC algorithm [RFC-2104] in conjunction with the SHA-1 algorithm [FIPS-180-1] as an authentication mechanism within the revised IPSEC EncapsulatingSecurity Payload [ESP] and the revised IPSEC Authentication Header[AH]. HMAC with SHA-1 provides data origin authentication and integrity protection. Further information on the other components necessary for ESP and AH implementations is provided by [Thayer97a].
RFC 2405	The ESP DES-CBC Cipher Algorithm With Explicit IV
	Authors: C. Madson, N. Doraswamy. Date: November 1998 Formats: txt pdf Status: PROPOSED STANDARD This document describes the use of the DES Cipher algorithm in CipherBlock Chaining Mode, with an explicit IV, as a confidentiality mechanism within the context of the IPSec Encapsulating SecurityPayload (ESP).
RFC 2406	IP Encapsulating Security Payload (ESP)
	Authors: S. Kent, R. Atkinson. Date: November 1998 Formats: txt pdf Obsoletes: RFC 1827 Obsoleted by: RFC 4303, RFC 4305 Status: PROPOSED STANDARD The Encapsulating Security Payload (ESP) header is designed to provide a mix of security services in IPv4 and IPv6. [STANDARDS-TRACK]
RFC 2407	The Internet IP Security Domain of Interpretation for ISAKMP
	Authors: D. Piper. Date: November 1998 Formats: txt pdf Obsoleted by: RFC 4306 Status: PROPOSED STANDARD This document defines the Internet IP Security DOI (IPSEC DOI), which instantiates ISAKMP for use with IP when IP uses ISAKMP to negotiate security associations. [STANDARDS-TRACK]
RFC 2408	Internet Security Association and Key Management Protocol (ISAKMP)
	Authors: D. Maughan, M. Schertler, M. Schneider, J. Turner. Date: November 1998 Formats: txt pdf Obsoleted by: RFC 4306 Status: PROPOSED STANDARD This memo describes a protocol utilizing security concepts necessary for establishing Security Associations (SA) and cryptographic keys in an Internet environment. A Security Association protocol that negotiates, establishes, modifies and deletes Security Associations and their attributes is required for an evolving Internet, where there will be numerous security mechanisms and several options for each security mechanism. The key management protocol must be robust in order to handle public key generation for the Internet community at large and private key requirements for those private networks with that requirement. The Internet Security Association and KeyManagement Protocol (ISAKMP) defines the procedures for authenticating a communicating peer, creation and management ofSecurity Associations, key generation techniques, and threat mitigation (e.g. denial of service and replay attacks). All of these are necessary to establish and maintain secure communications(via IP Security Service or any other security protocol) in anInternet environment.
RFC 2409	The Internet Key Exchange (IKE)
	Authors: D. Harkins, D. Carrel. Date: November 1998 Formats: txt pdf Obsoleted by: RFC 4306 Updated by: RFC 4109 Status: PROPOSED STANDARD This memo describes a hybrid protocol. The purpose is to negotiate, and provide authenticated keying material for, security associations in a protected manner. [STANDARDS-TRACK]
RFC 2410	The NULL Encryption Algorithm and Its Use With IPsec
	Authors: R. Glenn, S. Kent. Date: November 1998 Formats: txt pdf Status: PROPOSED STANDARD This memo defines the NULL encryption algorithm and its use with theIPsec Encapsulating Security Payload (ESP). NULL does nothing to alter plaintext data. In fact, NULL, by itself, does nothing. NULL provides the means for ESP to provide authentication and integrity without confidentiality. Further information on the other components necessary for ESP implementations is provided by [ESP] and [ROAD].
RFC 2417	Definitions of Managed Objects for Multicast over UNI 3.0/3.1 based ATM Networks
	Authors: C. Chung, M. Greene. Date: September 1998 Formats: txt pdf Obsoletes: RFC 2366 Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes managed objects for IP hosts and routers that use a Multicast Address Resolution Server (MARS) to support IP multicast over ATM, as described in 'Support for Multicast over UNI3.0/3.1 based ATM Networks' [1]. This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions.
RFC 2419	The PPP DES Encryption Protocol, Version 2 (DESE-bis)
	Authors: K. Sklower, G. Meyer. Date: September 1998 Formats: txt pdf Obsoletes: RFC 1969 Status: PROPOSED STANDARD The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. The PPP Encryption Control Protocol (ECP) [2] provides a method to negotiate and utilize encryption protocols over PPP encapsulated links. This document provides specific details for the use of the DES standard [5, 6] for encrypting PPP encapsulated packets.
RFC 2420	The PPP Triple-DES Encryption Protocol (3DESE)
	Authors: H. Kummert. Date: September 1998 Formats: txt pdf Status: PROPOSED STANDARD The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. The PPP Encryption Control Protocol (ECP) [2] provides a method to negotiate and utilize encryption protocols over PPP encapsulated links. This document provides specific details for the use of the Triple-DES standard (3DES) [6] for encrypting PPP encapsulated packets.
RFC 2421	Voice Profile for Internet Mail - version 2
	Authors: G. Vaudreuil, G. Parsons. Date: September 1998 Formats: txt pdf Obsoletes: RFC 1911 Obsoleted by: RFC 3801 Status: PROPOSED STANDARD This document profiles Internet mail for voice messaging. [STANDARDS- TRACK]
RFC 2422	Toll Quality Voice - 32 kbit/s ADPCM MIME Sub-type Registration
	Authors: G. Vaudreuil, G. Parsons. Date: September 1998 Formats: txt pdf Obsoletes: RFC 1911 Obsoleted by: RFC 3802 Status: PROPOSED STANDARD This document describes the registration of the MIME sub-type audio/32KADPCM for toll quality audio. [STANDARDS-TRACK]
RFC 2423	VPIM Voice Message MIME Sub-type Registration
	Authors: G. Vaudreuil, G. Parsons. Date: September 1998 Formats: txt pdf Obsoletes: RFC 1911 Obsoleted by: RFC 3801 Status: PROPOSED STANDARD This document describes the registration of the MIME sub-type multipart/voice-message for use with the Voice Profile for Internet Mail (VPIM). [STANDARDS-TRACK]
RFC 2424	Content Duration MIME Header Definition
	Authors: G. Vaudreuil, G. Parsons. Date: September 1998 Formats: txt pdf Obsoleted by: RFC 3803 Status: PROPOSED STANDARD This document describes the MIME header Content-Duration that is intended for use with any timed media content (typically audio/* or video/*). [STANDARDS-TRACK]
RFC 2425	A MIME Content-Type for Directory Information
	Authors: T. Howes, M. Smith, F. Dawson. Date: September 1998 Formats: txt pdf Obsoleted by: RFC 6350 Status: PROPOSED STANDARD This document defines a MIME Content-Type for holding directory information. [STANDARDS-TRACK]
RFC 2426	vCard MIME Directory Profile
	Authors: F. Dawson, T. Howes. Date: September 1998 Formats: txt pdf Obsoleted by: RFC 6350 Status: PROPOSED STANDARD This memo defines the profile of the MIME Content-Type [MIME-DIR] for directory information for a white-pages person object, based on a vCard electronic business card. The profile definition is independent of any particular directory service or protocol. The profile is defined for representing and exchanging a variety of information about an individual (e.g., formatted and structured name and delivery addresses, email address, multiple telephone numbers, photograph, logo, audio clips, etc.). The directory information used by this profile is based on the attributes for the person object defined in the X.520 and X.521 directory services recommendations. The profile also provides the method for including a [VCARD] representation of a white-pages directory entry within the MIME Content-Type defined by the [MIME-DIR] document.
RFC 2428	FTP Extensions for IPv6 and NATs
	Authors: M. Allman, S. Ostermann, C. Metz. Date: September 1998 Formats: txt pdf Status: PROPOSED STANDARD The specification for the File Transfer Protocol assumes that the underlying network protocol uses a 32-bit network address(specifically IP version 4). With the deployment of version 6 of theInternet Protocol, network addresses will no longer be 32-bits. This paper specifies extensions to FTP that will allow the protocol to work over IPv4 and IPv6. In addition, the framework defined can support additional network protocols in the future.
RFC 2429	RTP Payload Format for the 1998 Version of ITU-T Rec
	Authors: H.263 Video (H.263+). C. Bormann, L. Cline, G. Deisher, T. Gardos, C. Maciocco, D. Newell, J. Ott, G. Sullivan, S. Wenger, C. Zhu. Date: October 1998 Formats: txt pdf Obsoleted by: RFC 4629 Status: PROPOSED STANDARD This document specifies an RTP payload header format applicable to the transmission of video streams generated based on the 1998 version of ITU-T Recommendation H.263. [STANDARDS-TRACK]
RFC 2431	RTP Payload Format for BT.656 Video Encoding
	Authors: D. Tynan. Date: October 1998 Formats: txt pdf Status: PROPOSED STANDARD This document specifies the RTP payload format for encapsulating ITURecommendation BT.656-3 video streams in the Real-Time TransportProtocol (RTP). Each RTP packet contains all or a portion of one scan line as defined by ITU Recommendation BT.601-5, and includes fragmentation, decoding and positioning information.
RFC 2435	RTP Payload Format for JPEG-compressed Video
	Authors: L. Berc, W. Fenner, R. Frederick, S. McCanne, P. Stewart. Date: October 1998 Formats: txt pdf Obsoletes: RFC 2035 Status: PROPOSED STANDARD This memo describes the RTP payload format for JPEG video streams.The packet format is optimized for real-time video streams where codec parameters change rarely from frame to frame. This document is a product of the Audio-Video Transport working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at rem- conf@es.net and/or the author(s).
RFC 2439	BGP Route Flap Damping
	Authors: C. Villamizar, R. Chandra, R. Govindan. Date: November 1998 Formats: txt pdf Status: PROPOSED STANDARD A usage of the BGP routing protocol is described which is capable of reducing the routing traffic passed on to routing peers and therefore the load on these peers without adversely affecting route convergence time for relatively stable routes. This technique has been implemented in commercial products supporting BGP. The technique is also applicable to IDRP. The overall goals are: o to provide a mechanism capable of reducing router processing load caused by instability o in doing so prevent sustained routing oscillations o to do so without sacrificing route convergence time for generally well behaved routes. This must be accomplished keeping other goals of BGP in mind: o pack changes into a small number of updates o preserve consistent routing o minimal addition space and computational overhead An excessive rate of update to the advertised reachability of a subset of Internet prefixes has been widespread in the Internet.This observation was made in the early 1990s by many people involved in Internet operations and remains the case. These excessive updates are not necessarily periodic so route oscillation would be a misleading term. The informal term used to describe this effect is"route flap". The techniques described here are now widely deployed and are commonly referred to as "route flap damping".
RFC 2440	OpenPGP Message Format
	Authors: J. Callas, L. Donnerhacke, H. Finney, R. Thayer. Date: November 1998 Formats: txt pdf Obsoleted by: RFC 4880 Status: PROPOSED STANDARD This document is maintained in order to publish all necessary information needed to develop interoperable applications based on theOpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network.It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws. Open-PGP software uses a combination of strong public-key and symmetric cryptography to provide security services for electronic communications and data storage. These services include confidentiality, key management, authentication, and digital signatures. This document specifies the message formats used inOpenPGP.
RFC 2444	The One-Time-Password SASL Mechanism
	Authors: C. Newman. Date: October 1998 Formats: txt pdf Updates: RFC 2222 Status: PROPOSED STANDARD OTP [OTP] provides a useful authentication mechanism for situations where there is limited client or server trust. Currently, OTP is added to protocols in an ad-hoc fashion with heuristic parsing. This specification defines an OTP SASL [SASL] mechanism so it can be easily and formally integrated into many application protocols.
RFC 2445	Internet Calendaring and Scheduling Core Object Specification (iCalendar)
	Authors: F. Dawson, D. Stenerson. Date: November 1998 Formats: txt pdf Obsoleted by: RFC 5545 Status: PROPOSED STANDARD There is a clear need to provide and deploy interoperable calendaring and scheduling services for the Internet. Current group scheduling and Personal Information Management (PIM) products are being extended for use across the Internet, today, in proprietary ways. This memo has been defined to provide the definition of a common format for openly exchanging calendaring and scheduling information across theInternet. This memo is formatted as a registration for a MIME media type per[RFC 2048]. However, the format in this memo is equally applicable for use outside of a MIME message content type. The proposed media type value is 'text/calendar'. This string would label a media type containing calendaring and scheduling information encoded as text characters formatted in a manner outlined below. This MIME media type provides a standard content type for capturing calendar event, to-do and journal entry information. It also can be used to convey free/busy time information. The content type is suitable as a MIME message entity that can be transferred over MIME based email systems, using HTTP or some other Internet transport. In addition, the content type is useful as an object for interactions between desktop applications using the operating system clipboard, drag/drop or file systems capabilities. This memo is based on the earlier work of the vCalendar specification for the exchange of personal calendaring and scheduling information.In order to avoid confusion with this referenced work, this memo is to be known as the iCalendar specification. This memo defines the format for specifying iCalendar object methods.An iCalendar object method is a set of usage constraints for the iCalendar object. For example, these methods might define scheduling messages that request an event be scheduled, reply to an event request, send a cancellation notice for an event, modify or replace the definition of an event, provide a counter proposal for an original event request, delegate an event request to another individual, request free or busy time, reply to a free or busy time request, or provide similar scheduling messages for a to-do or journal entry calendar component. The iCalendar Transport-indendentInteroperability Protocol (iTIP) defined in [ITIP] is one such scheduling protocol.
RFC 2446	iCalendar Transport-Independent Interoperability Protocol (iTIP) Scheduling Events, BusyTime, To-dos and Journal Entries
	Authors: S. Silverberg, S. Mansour, F. Dawson, R. Hopson. Date: November 1998 Formats: txt pdf Obsoleted by: RFC 5546 Status: PROPOSED STANDARD This document specifies how calendaring systems use iCalendar objects to interoperate with other calendar systems. It does so in a general way so as to allow multiple methods of communication between systems.Subsequent documents specify interoperable methods of communications between systems that use this protocol. The document outlines a model for calendar exchange that defines both static and dynamic event, to-do, journal and free/busy objects.Static objects are used to transmit information from one entity to another without the expectation of continuity or referential integrity with the original item. Dynamic objects are a superset of static objects and will gracefully degrade to their static counterparts for clients that only support static objects. This document specifies an Internet protocol based on the iCalendar object specification that provides scheduling interoperability between different calendar systems. The Internet protocol is called the "iCalendar Transport-Independent Interoperability Protocol(iTIP)". iTIP complements the iCalendar object specification by adding semantics for group scheduling methods commonly available in current calendar systems. These scheduling methods permit two or more calendar systems to perform transactions such as publish, schedule, reschedule, respond to scheduling requests, negotiation of changes or cancel iCalendar-based calendar components. iTIP is defined independent of the particular transport used to transmit the scheduling information. Companion memos to iTIP provide bindings of the interoperability protocol to a number of Internet protocols.
RFC 2447	iCalendar Message-Based Interoperability Protocol (iMIP)
	Authors: F. Dawson, S. Mansour, S. Silverberg. Date: November 1998 Formats: txt pdf Obsoleted by: RFC 6047 Status: PROPOSED STANDARD This document, [iMIP], specifies a binding from the iCalendarTransport-independent Interoperability Protocol (iTIP) to Internet email-based transports. Calendaring entries defined by the iCalendarObject Model [iCAL] are composed using constructs from [RFC-822],[RFC-2045], [RFC-2046], [RFC-2047], [RFC-2048] and [RFC-2049]. This document is based on discussions within the Internet EngineeringTask Force (IETF) Calendaring and Scheduling (CALSCH) working group.More information about the IETF CALSCH working group activities can be found on the IMC web site at http://www.imc.org, the IETF web site at http://www.ietf.org/html.charters/calsch-charter.html. Refer to the references within this document for further information on how to access these various documents.
RFC 2449	POP3 Extension Mechanism
	Authors: R. Gellens, C. Newman, L. Lundblade. Date: November 1998 Formats: txt pdf Updates: RFC 1939 Updated by: RFC 5034 Status: PROPOSED STANDARD This memo updates RFC 1939 to define a mechanism to announce support for optional commands, extensions, and unconditional server behavior. [STANDARDS-TRACK]
RFC 2451	The ESP CBC-Mode Cipher Algorithms
	Authors: R. Pereira, R. Adams. Date: November 1998 Formats: txt pdf Status: PROPOSED STANDARD This document describes how to use CBC-mode cipher algorithms with the IPSec ESP (Encapsulating Security Payload) Protocol. It not only clearly states how to use certain cipher algorithms, but also how to use all CBC-mode cipher algorithms.
RFC 2452	IP Version 6 Management Information Base for the Transmission Control Protocol
	Authors: M. Daniele. Date: December 1998 Formats: txt pdf Obsoleted by: RFC 4022 Status: PROPOSED STANDARD This document is one in the series of documents that define variousMIB objects for IPv6. Specifically, this document is the MIB module which defines managed objects for implementations of the TransmissionControl Protocol (TCP) over IP Version 6 (IPv6). This document also recommends a specific policy with respect to the applicability of RFC 2012 for implementations of IPv6. Namely, that most of managed objects defined in RFC 2012 are independent of whichIP versions underlie TCP, and only the TCP connection information isIP version-specific. This memo defines an experimental portion of the ManagementInformation Base (MIB) for use with network management protocols inIPv6-based internets.
RFC 2455	Definitions of Managed Objects for APPN
	Authors: B. Clouston, B. Moore. Date: November 1998 Formats: txt pdf Obsoletes: RFC 2155 Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it defines objects for monitoring and controlling network devices with APPN (Advanced Peer-to-Peer Networking) capabilities. This memo identifies managed objects for the APPN protocol.
RFC 2456	Definitions of Managed Objects for APPN TRAPS
	Authors: B. Clouston, B. Moore. Date: November 1998 Formats: txt pdf Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it defines objects for receiving notifications from network devices with APPN (Advanced Peer-to-Peer Network) and DLUR(Dependent LU Requester) capabilities. This memo identifies notifications for the APPN and DLUR architecture.
RFC 2457	Definitions of Managed Objects for Extended Border Node
	Authors: B. Clouston, B. Moore. Date: November 1998 Formats: txt pdf Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it defines objects for monitoring and controlling network devices with APPN (Advanced Peer-to-Peer Network) EBN(Extended Border Node) capabilities. This memo identifies managed objects for the EBN architecture.
RFC 2459	Internet X.509 Public Key Infrastructure Certificate and CRL Profile
	Authors: R. Housley, W. Ford, W. Polk, D. Solo. Date: January 1999 Formats: txt pdf Obsoleted by: RFC 3280 Status: PROPOSED STANDARD This memo profiles the X.509 v3 certificate and X.509 v2 CRL for use in the Internet. An overview of the approach and model are provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms (e.g., IP addresses). Standard certificate extensions are described and one new Internet-specific extension is defined. A required set of certificate extensions is specified. The X.509 v2 CRL format is described and a required extension set is defined as well. An algorithm for X.509 certificate path validation is described. Supplemental information is provided describing the format of public keys and digital signatures in X.509 certificates for common Internet public key encryption algorithms(i.e., RSA, DSA, and Diffie-Hellman). ASN.1 modules and examples are provided in the appendices.
RFC 2464	Transmission of IPv6 Packets over Ethernet Networks
	Authors: M. Crawford. Date: December 1998 Formats: txt pdf Obsoletes: RFC 1972 Updated by: RFC 6085 Status: PROPOSED STANDARD This document specifies the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on Ethernet networks. It also specifies the content of the Source/Target Link-layer Address option used in Router Solicitation, Router Advertisement, Neighbor Solicitation, Neighbor Advertisement and Redirect messages when those messages are transmitted on an Ethernet. [STANDARDS-TRACK]
RFC 2465	Management Information Base for IP Version 6: Textual Conventions and General Group
	Authors: D. Haskin, S. Onishi. Date: December 1998 Formats: txt pdf Obsoleted by: RFC 4293 Status: PROPOSED STANDARD This document is one in the series of documents that provide MIB definitions for for IP Version 6. Specifically, the IPv6 MIB textual conventions as well as the IPv6 MIB General group is defined in this document. This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the IPv6-based internets. This document specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peerSNMPv1 definitions.
RFC 2466	Management Information Base for IP Version 6: ICMPv6 Group
	Authors: D. Haskin, S. Onishi. Date: December 1998 Formats: txt pdf Obsoleted by: RFC 4293 Status: PROPOSED STANDARD This document is one in the series of documents that define variousMIB object groups for IPv6. Specifically, the ICMPv6 group is defined in this document. This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the IPv6-based internets. This document specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peerSNMPv1 definitions.
RFC 2467	Transmission of IPv6 Packets over FDDI Networks
	Authors: M. Crawford. Date: December 1998 Formats: txt pdf Obsoletes: RFC 2019 Status: PROPOSED STANDARD This document specifies the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on FDDI networks. [STANDARDS- TRACK]
RFC 2470	Transmission of IPv6 Packets over Token Ring Networks
	Authors: M. Crawford, T. Narten, S. Thomas. Date: December 1998 Formats: txt pdf Status: PROPOSED STANDARD This memo specifies the MTU and frame format for transmission of IPv6 packets on Token Ring networks. [STANDARDS-TRACK]
RFC 2472	IP Version 6 over PPP
	Authors: D. Haskin, E. Allen. Date: December 1998 Formats: txt pdf Obsoletes: RFC 2023 Obsoleted by: RFC 5072, RFC 5172 Status: PROPOSED STANDARD The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. This document defines the method for transmission of IP Version 6 [2] packets over PPP links as well as the Network Control Protocol (NCP) for establishing and configuring the IPv6 over PPP. It also specifies the method of forming IPv6 link-local addresses on PPP links.
RFC 2473	Generic Packet Tunneling in IPv6 Specification
	Authors: A. Conta, S. Deering. Date: December 1998 Formats: txt pdf Status: PROPOSED STANDARD This document defines the model and generic mechanisms for IPv6 encapsulation of Internet packets, such as IPv6 and IPv4. The model and mechanisms can be applied to other protocol packets as well, such as AppleTalk, IPX, CLNP, or others.
RFC 2474	Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers
	Authors: K. Nichols, S. Blake, F. Baker, D. Black. Date: December 1998 Formats: txt pdf Obsoletes: RFC 1455, RFC 1349 Updated by: RFC 3168, RFC 3260 Status: PROPOSED STANDARD Differentiated services enhancements to the Internet protocol are intended to enable scalable service discrimination in the Internet without the need for per-flow state and signaling at every hop. A variety of services may be built from a small, well-defined set of building blocks which are deployed in network nodes. The services may be either end-to-end or intra-domain; they include both those that can satisfy quantitative performance requirements (e.g., peak bandwidth) and those based on relative performance (e.g., "class" differentiation). Services can be constructed by a combination of: - setting bits in an IP header field at network boundaries(autonomous system boundaries, internal administrative boundaries, or hosts),- using those bits to determine how packets are forwarded by the nodes inside the network, and- conditioning the marked packets at network boundaries in accordance with the requirements or rules of each service. The requirements or rules of each service must be set through administrative policy mechanisms which are outside the scope of this document. A differentiated services-compliant network node includes a classifier that selects packets based on the value of the DS field, along with buffer management and packet scheduling mechanisms capable of delivering the specific packet forwarding treatment indicated by the DS field value. Setting of the DS field and conditioning of the temporal behavior of marked packets need only be performed at network boundaries and may vary in complexity. This document defines the IP header field, called the DS (for differentiated services) field. In IPv4, it defines the layout of the TOS octet; in IPv6, the Traffic Class octet. In addition, a base set of packet forwarding treatments, or per-hop behaviors, is defined. For a more complete understanding of differentiated services, see also the differentiated services architecture [ARCH].
RFC 2476	Message Submission
	Authors: R. Gellens, J. Klensin. Date: December 1998 Formats: txt pdf Obsoleted by: RFC 4409 Status: PROPOSED STANDARD This memo describes a low cost, deterministic means for messages to be identified as submissions, and specifies what actions are to be taken by a submission server. [STANDARDS-TRACK]
RFC 2478	The Simple and Protected GSS-API Negotiation Mechanism
	Authors: E. Baize, D. Pinkas. Date: December 1998 Formats: txt pdf Obsoleted by: RFC 4178 Status: PROPOSED STANDARD This document specifies a Security Negotiation Mechanism for the Generic Security Service Application Program Interface (GSS-API). [STANDARDS- TRACK]
RFC 2480	Gateways and MIME Security Multiparts
	Authors: N. Freed. Date: January 1999 Formats: txt pdf Status: PROPOSED STANDARD This document examines the problems associated with use of MIME security multiparts and gateways to non-MIME environments. [STANDARDS-TRACK]
RFC 2484	PPP LCP Internationalization Configuration Option
	Authors: G. Zorn. Date: January 1999 Formats: txt pdf Updates: RFC 2284, RFC 1994, RFC 1570 Status: PROPOSED STANDARD The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP also defines an extensible Link Control Protocol (LCP), which allows negotiation of an Authentication Protocol for authenticating its peer before allowing Network Layer protocols to transmit over the link. [STANDARDS-TRACK]
RFC 2485	DHCP Option for The Open Group's User Authentication Protocol
	Authors: S. Drach. Date: January 1999 Formats: txt pdf Status: PROPOSED STANDARD This document defines a DHCP [1] option that contains a list of pointers to User Authentication Protocol servers that provide user authentication services for clients that conform to The Open GroupNetwork Computing Client Technical Standard [2].
RFC 2486	The Network Access Identifier
	Authors: B. Aboba, M. Beadles. Date: January 1999 Formats: txt pdf Obsoleted by: RFC 4282 Status: PROPOSED STANDARD This document proposes syntax for the Network Access Identifier (NAI), the userID submitted by the client during PPP authentication. [STANDARDS-TRACK]
RFC 2487	SMTP Service Extension for Secure SMTP over TLS
	Authors: P. Hoffman. Date: January 1999 Formats: txt pdf Obsoleted by: RFC 3207 Status: PROPOSED STANDARD This document describes an extension to the SMTP service that allows an SMTP server and client to use transport-layer security to provide private, authenticated communication over the Internet. This gives SMTP agents the ability to protect some or all of their communications from eavesdroppers and attackers. [STANDARDS-TRACK]
RFC 2491	IPv6 over Non-Broadcast Multiple Access (NBMA) networks
	Authors: G. Armitage, P. Schulter, M. Jork, G. Harter. Date: January 1999 Formats: txt pdf Status: PROPOSED STANDARD This document describes a general architecture for IPv6 over NBMA networks. It forms the basis for subsidiary companion documents that describe details for various specific NBMA technologies (such as ATM or Frame Relay). The IPv6 over NBMA architecture allows conventional host-side operation of the IPv6 Neighbor Discovery protocol, while also supporting the establishment of 'shortcut' NBMA forwarding paths when dynamically signaled NBMA links are available. Operations over administratively configured Point to Point NBMA links are also described. Dynamic NBMA shortcuts are achieved through the use of IPv6 NeighborDiscovery protocol operation within Logical Links, and inter-routerNHRP for the discovery of off-Link NBMA destinations. Both flow- triggered and explicitly source-triggered shortcuts are supported.
RFC 2492	IPv6 over ATM Networks
	Authors: G. Armitage, P. Schulter, M. Jork. Date: January 1999 Formats: txt pdf Status: PROPOSED STANDARD This document is a companion to the ION working group's architecture document, "IPv6 over Non Broadcast Multiple Access (NBMA) networks".It provides specific details on how to apply the IPv6 over NBMA architecture to ATM networks. This architecture allows conventional host-side operation of the IPv6 Neighbor Discovery protocol, while also supporting the establishment of 'shortcut' ATM forwarding paths(when using SVCs). Operation over administratively configured Point to Point PVCs is also supported.
RFC 2493	Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals
	Authors: K. Tesink, Ed.. Date: January 1999 Formats: txt pdf Obsoleted by: RFC 3593 Status: PROPOSED STANDARD This document defines a set of Textual Conventions for MIB modules which make use of performance history data based on 15 minute intervals.
RFC 2494	Definitions of Managed Objects for the DS0 and DS0 Bundle Interface Type
	Authors: D. Fowler, Ed.. Date: January 1999 Formats: txt pdf Status: PROPOSED STANDARD 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 used for managing DS0 and DS0Bundle interfaces. This document is a companion document withDefinitions of Managed Objects for the DS1/E1/DS2/E2 (RFC 2495 [17]),DS3/E3 (RFC 2496 [18]), and the work in progress, SONET/SDH InterfaceTypes. This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions.
RFC 2495	Definitions of Managed Objects for the DS1, E1, DS2 and E2 Interface Types
	Authors: D. Fowler, Ed.. Date: January 1999 Formats: txt pdf Obsoletes: RFC 1406 Obsoleted by: RFC 3895 Status: PROPOSED STANDARD 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 used for managing DS1, E1, DS2 and E2 interfaces. This document is a companion document withDefinitions of Managed Objects for the DS0 (RFC 2494 [30]), DS3/E3(RFC 2496 [28]), and the work in progress, SONET/SDH Interface Types. This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions.
RFC 2496	Definitions of Managed Object for the DS3/E3 Interface Type
	Authors: D. Fowler, Ed.. Date: January 1999 Formats: txt pdf Obsoletes: RFC 1407 Obsoleted by: RFC 3896 Status: PROPOSED STANDARD 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 used for managing DS3 and E3 interfaces. This document is a companion document with Definitions of Managed Objects for the DS0 (RFC 2494 [25]), DS1/E1/DS2/E2 (RFC2495 [17]), and the work in progress SONET/SDH Interface Types. This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions.
RFC 2497	Transmission of IPv6 Packets over ARCnet Networks
	Authors: I. Souvatzis. Date: January 1999 Formats: txt pdf Also: RFC 1201 Status: PROPOSED STANDARD This memo specifies a frame format for transmission of IPv6 packets and the method of forming IPv6 link-local and statelessly autoconfigured addresses on ARCnet networks. It also specifies the content of the Source/Target Link-layer Address option used by the Router Solicitation, Router Advertisement, Neighbor Solicitation, Neighbor Advertisement and Redirect messages described in, when those messages are transmitted on an ARCnet. [STANDARDS-TRACK]
RFC 2507	IP Header Compression
	Authors: M. Degermark, B. Nordgren, S. Pink. Date: February 1999 Formats: txt pdf Status: PROPOSED STANDARD This document describes how to compress multiple IP headers and TCP and UDP headers per hop over point to point links. The methods can be applied to of IPv6 base and extension headers, IPv4 headers, TCP andUDP headers, and encapsulated IPv6 and IPv4 headers. Headers of typical UDP or TCP packets can be compressed down to 4-7 octets including the 2 octet UDP or TCP checksum. This largely removes the negative impact of large IP headers and allows efficient use of bandwidth on low and medium speed links. The compression algorithms are specifically designed to work well over links with nontrivial packet-loss rates. Several wireless and modem technologies result in such links.
RFC 2508	Compressing IP/UDP/RTP Headers for Low-Speed Serial Links
	Authors: S. Casner, V. Jacobson. Date: February 1999 Formats: txt pdf Status: PROPOSED STANDARD This document describes a method for compressing the headers ofIP/UDP/RTP datagrams to reduce overhead on low-speed serial links.In many cases, all three headers can be compressed to 2-4 bytes. Comments are solicited and should be addressed to the working group mailing list rem-conf@es.net and/or the author(s).
RFC 2509	IP Header Compression over PPP
	Authors: M. Engan, S. Casner, C. Bormann. Date: February 1999 Formats: txt pdf Obsoleted by: RFC 3544 Status: PROPOSED STANDARD This document describes an option for negotiating the use of header compression on IP datagrams transmitted over the Point-to-PointProtocol [RFC1661]. It defines extensions to the PPP ControlProtocols for IPv4 and IPv6 [RFC1332, RFC2023]. Header compression may be applied to IPv4 and IPv6 datagrams in combination with TCP,UDP and RTP transport protocols as specified in [IPHC] and [CRTP].
RFC 2510	Internet X.509 Public Key Infrastructure Certificate Management Protocols
	Authors: C. Adams, S. Farrell. Date: March 1999 Formats: txt pdf Obsoleted by: RFC 4210 Status: PROPOSED STANDARD This document describes the Internet X.509 Public Key Infrastructure(PKI) Certificate Management Protocols. Protocol messages are defined for all relevant aspects of certificate creation and management.Note that "certificate" in this document refers to an X.509v3Certificate as defined in [COR95, X509-AM].
RFC 2511	Internet X.509 Certificate Request Message Format
	Authors: M. Myers, C. Adams, D. Solo, D. Kemp. Date: March 1999 Formats: txt pdf Obsoleted by: RFC 4211 Status: PROPOSED STANDARD This document describes the Certificate Request Message Format (CRMF). [STANDARDS-TRACK]
RFC 2512	Accounting Information for ATM Networks
	Authors: K. McCloghrie, J. Heinanen, W. Greene, A. Prasad. Date: February 1999 Formats: txt pdf Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. This memo defines a set of ATM-specific accounting information which can be collected for connections on ATM networks. [STANDARDS-TRACK]
RFC 2513	Managed Objects for Controlling the Collection and Storage of Accounting Information for Connection-Oriented Networks
	Authors: K. McCloghrie, J. Heinanen, W. Greene, A. Prasad. Date: February 1999 Formats: txt pdf Status: PROPOSED STANDARD 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 controlling the collection and storage of accounting information for connection-oriented networks such as ATM. [STANDARDS-TRACK]
RFC 2514	Definitions of Textual Conventions and OBJECT-IDENTITIES for ATM Management
	Authors: M. Noto, E. Spiegel, K. Tesink. Date: February 1999 Formats: txt pdf Status: PROPOSED STANDARD This memo describes Textual Conventions and OBJECT-IDENTITIES used for managing ATM-based interfaces, devices, networks and services.
RFC 2515	Definitions of Managed Objects for ATM Management
	Authors: K. Tesink, Ed. Date: February 1999 Formats: txt pdf Obsoletes: RFC 1695 Status: PROPOSED STANDARD 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 used for managing ATM-based interfaces, devices, networks and services. [STANDARDS-TRACK]
RFC 2518	HTTP Extensions for Distributed Authoring -- WEBDAV
	Authors: Y. Goland, E. Whitehead, A. Faizi, S. Carter, D. Jensen. Date: February 1999 Formats: txt pdf Obsoleted by: RFC 4918 Status: PROPOSED STANDARD This document specifies a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, namespace manipulation, and resource locking (collision avoidance).
RFC 2526	Reserved IPv6 Subnet Anycast Addresses
	Authors: D. Johnson, S. Deering. Date: March 1999 Formats: txt pdf Status: PROPOSED STANDARD The IP Version 6 addressing architecture defines an "anycast" address as an IPv6 address that is assigned to one or more network interfaces(typically belonging to different nodes), with the property that a packet sent to an anycast address is routed to the "nearest" interface having that address, according to the routing protocols' measure of distance. This document defines a set of reserved anycast addresses within each subnet prefix, and lists the initial allocation of these reserved subnet anycast addresses.
RFC 2529	Transmission of IPv6 over IPv4 Domains without Explicit Tunnels
	Authors: B. Carpenter, C. Jung. Date: March 1999 Formats: txt pdf Status: PROPOSED STANDARD This memo specifies the frame format for transmission of IPv6 [IPV6] packets and the method of forming IPv6 link-local addresses over IPv4 domains. It also specifies the content of the Source/Target Link- layer Address option used in the Router Solicitation, RouterAdvertisement, Neighbor Solicitation, and Neighbor Advertisement andRedirect messages, when those messages are transmitted on an IPv4 multicast network. The motivation for this method is to allow isolated IPv6 hosts, located on a physical link which has no directly connected IPv6 router, to become fully functional IPv6 hosts by using an IPv4 domain that supports IPv4 multicast as their virtual local link. It usesIPv4 multicast as a "virtual Ethernet".
RFC 2530	Indicating Supported Media Features Using Extensions to DSN and MDN
	Authors: D. Wing. Date: March 1999 Formats: txt pdf Status: PROPOSED STANDARD This memo describes a format for generating Message Disposition Notifications and Delivery Status Notifications which contain such information. [STANDARDS-TRACK]
RFC 2531	Content Feature Schema for Internet Fax
	Authors: G. Klyne, L. McIntyre. Date: March 1999 Formats: txt pdf Obsoleted by: RFC 2879 Status: PROPOSED STANDARD This document defines a content feature schema that is a profile of the media feature registration mechanisms [1,2,3] for use in performing capability identification between extended Internet fax systems [5]. This document does not describe any specific mechanisms for communicating capability information, but does presume that any such mechanisms will transfer textual values. It specifies a textual format to be used for describing Internet fax capability information.
RFC 2532	Extended Facsimile Using Internet Mail
	Authors: L. Masinter, D. Wing. Date: March 1999 Formats: txt pdf Status: PROPOSED STANDARD This document describes extensions to "Simple Mode of Facsimile UsingInternet Mail" [RFC2305] and describes additional features, including transmission of enhanced document characteristics (higher resolution, color) and confirmation of delivery and processing. These additional features are designed to provide the highest level of interoperability with the existing and future standards-compliant email infrastructure and mail user agents, while providing a level of service that approximates the level currently enjoyed by fax users. The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights in <http://www.ietf.org/ipr.html&rt;.
RFC 2533	A Syntax for Describing Media Feature Sets
	Authors: G. Klyne. Date: March 1999 Formats: txt pdf Updated by: RFC 2738, RFC 2938 Status: PROPOSED STANDARD A number of Internet application protocols have a need to provide content negotiation for the resources with which they interact [1].A framework for such negotiation is described in [2], part of which is a way to describe the range of media features which can be handled by the sender, recipient or document transmission format of a message. A format for a vocabulary of individual media features and procedures for feature registration are presented in [3]. This document introduces and describes a syntax that can be used to define feature sets which are formed from combinations and relations involving individual media features. Such feature sets are used to describe the media feature handling capabilities of message senders, recipients and file formats. An algorithm for feature set matching is also described here.
RFC 2534	Media Features for Display, Print, and Fax
	Authors: L. Masinter, D. Wing, A. Mutz, K. Holtman. Date: March 1999 Formats: txt pdf Status: PROPOSED STANDARD This specification defines some common media features for describing image resolution, size, color, and image representation methods that are common to web browsing, printing, and facsimile applications.These features are registered for use within the framework of [REG].
RFC 2535	Domain Name System Security Extensions
	Authors: D. Eastlake 3rd. Date: March 1999 Formats: txt pdf Obsoletes: RFC 2065 Obsoleted by: RFC 4033, RFC 4034, RFC 4035 Updates: RFC 2181, RFC 1035, RFC 1034 Updated by: RFC 2931, RFC 3007, RFC 3008, RFC 3090, RFC 3226, RFC 3445, RFC 3597, RFC 3655, RFC 3658, RFC 3755, RFC 3757, RFC 3845 Status: PROPOSED STANDARD Extensions to the Domain Name System (DNS) are described that provide data integrity and authentication to security aware resolvers and applications through the use of cryptographic digital signatures.These digital signatures are included in secured zones as resource records. Security can also be provided through non-security awareDNS servers in some cases. The extensions provide for the storage of authenticated public keys in the DNS. This storage of keys can support general public key distribution services as well as DNS security. The stored keys enable security aware resolvers to learn the authenticating key of zones in addition to those for which they are initially configured.Keys associated with DNS names can be retrieved to support other protocols. Provision is made for a variety of key types and algorithms. In addition, the security extensions provide for the optional authentication of DNS protocol transactions and requests. This document incorporates feedback on RFC 2065 from early implementers and potential users.
RFC 2536	DSA KEYs and SIGs in the Domain Name System (DNS)
	Authors: D. Eastlake 3rd. Date: March 1999 Formats: txt pdf Status: PROPOSED STANDARD A standard method for storing US Government Digital SignatureAlgorithm keys and signatures in the Domain Name System is described which utilizes DNS KEY and SIG resource records.
RFC 2537	RSA/MD5 KEYs and SIGs in the Domain Name System (DNS)
	Authors: D. Eastlake 3rd. Date: March 1999 Formats: txt pdf Obsoleted by: RFC 3110 Status: PROPOSED STANDARD A standard method for storing RSA keys and and RSA/MD5 based signatures in the Domain Name System is described which utilizes DNSKEY and SIG resource records.
RFC 2538	Storing Certificates in the Domain Name System (DNS)
	Authors: D. Eastlake 3rd, O. Gudmundsson. Date: March 1999 Formats: txt pdf Obsoleted by: RFC 4398 Status: PROPOSED STANDARD Cryptographic public key are frequently published and their authenticity demonstrated by certificates. A CERT resource record(RR) is defined so that such certificates and related certificate revocation lists can be stored in the Domain Name System (DNS).
RFC 2539	Storage of Diffie-Hellman Keys in the Domain Name System (DNS)
	Authors: D. Eastlake 3rd. Date: March 1999 Formats: txt pdf Status: PROPOSED STANDARD A standard method for storing Diffie-Hellman keys in the Domain NameSystem is described which utilizes DNS KEY resource records.
RFC 2543	SIP: Session Initiation Protocol
	Authors: M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg. Date: March 1999 Formats: txt pdf Obsoleted by: RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265 Status: PROPOSED STANDARD The Session Initiation Protocol (SIP) is an application-layer control(signaling) protocol for creating, modifying and terminating sessions with one or more participants. These sessions include Internet multimedia conferences, Internet telephone calls and multimedia distribution. Members in a session can communicate via multicast or via a mesh of unicast relations, or a combination of these. SIP invitations used to create sessions carry session descriptions which allow participants to agree on a set of compatible media types.SIP supports user mobility by proxying and redirecting requests to the user's current location. Users can register their current location. SIP is not tied to any particular conference control protocol. SIP is designed to be independent of the lower-layer transport protocol and can be extended with additional capabilities.
RFC 2545	Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing
	Authors: P. Marques, F. Dupont. Date: March 1999 Formats: txt pdf Status: PROPOSED STANDARD BGP-4 Multiprotocol Extensions [BGP-MP] defines the format of two BGP attributes (MP_REACH_NLRI and MP_UNREACH_NLRI) that can be used to announce and withdraw the announcement of reachability information.This document defines how compliant systems should make use of those attributes for the purpose of conveying IPv6 routing information.
RFC 2554	SMTP Service Extension for Authentication
	Authors: J. Myers. Date: March 1999 Formats: txt pdf Obsoleted by: RFC 4954 Status: PROPOSED STANDARD This document defines an SMTP service extension [ESMTP] whereby an SMTP client may indicate an authentication mechanism to the server, perform an authentication protocol exchange, and optionally negotiate a security layer for subsequent protocol interactions. [STANDARDS-TRACK]
RFC 2557	MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)
	Authors: J. Palme, A. Hopmann, N. Shelness. Date: March 1999 Formats: txt pdf Obsoletes: RFC 2110 Status: PROPOSED STANDARD HTML [RFC 1866] defines a powerful means of specifying multimedia documents. These multimedia documents consist of a text/html root resource (object) and other subsidiary resources (image, video clip, applet, etc. objects) referenced by Uniform Resource Identifiers(URIs) within the text/html root resource. When an HTML multimedia document is retrieved by a browser, each of these component resources is individually retrieved in real time from a location, and using a protocol, specified by each URI. In order to transfer a complete HTML multimedia document in a single e-mail message, it is necessary to: a) aggregate a text/html root resource and all of the subsidiary resources it references into a single composite message structure, and b) define a means by whichURIs in the text/html root can reference subsidiary resources within that composite message structure. This document a) defines the use of a MIME multipart/related structure to aggregate a text/html root resource and the subsidiary resources it references, and b) specifies a MIME content-header(Content-Location) that allow URIs in a multipart/related text/html root body part to reference subsidiary resources in other body parts of the same multipart/related structure. While initially designed to support e-mail transfer of complete multi-resource HTML multimedia documents, these conventions can also be employed to resources retrieved by other transfer protocols such as HTTP and FTP to retrieve a complete multi-resource HTML multimedia document in a single transfer or for storage and archiving of complete HTML-documents. Differences between this and a previous version of this standard, which was published as RFC 2110, are summarized in chapter 12.
RFC 2558	Definitions of Managed Objects for the SONET/SDH Interface Type
	Authors: K. Tesink. Date: March 1999 Formats: txt pdf Obsoletes: RFC 1595 Obsoleted by: RFC 3592 Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) interfaces. This document is a companion to the documents that define Managed Objects for the DS1/E1/DS2/E2 and DS3/E3 Interface Types. [STANDARDS-TRACK]
RFC 2560	X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP
	Authors: M. Myers, R. Ankney, A. Malpani, S. Galperin, C. Adams. Date: June 1999 Formats: txt pdf Updated by: RFC 6277 Status: PROPOSED STANDARD This document specifies a protocol useful in determining the current status of a digital certificate without requiring CRLs. [STANDARDS- TRACK]
RFC 2561	Base Definitions of Managed Objects for TN3270E Using SMIv2
	Authors: K. White, R. Moore. Date: April 1999 Formats: txt pdf Status: PROPOSED STANDARD This memo defines a Management Information Base (MIB) for configuring and managing TN3270E servers. TN3270E, defined by RFC 2355 [19], refers to the enhancements made to the Telnet 3270 (TN3270) terminal emulation practices. Refer to RFC 1041 [18], STD 8, RFC 854 [16], and STD 31, RFC 860 [17] for a sample of what is meant by TN3270 practices. The MIB defined by this memo provides generic support for both host and gateway TN3270E server implementations. A TN3270E server connects a Telnet client performing 3270 emulation to a target SNA host over both a client-side network (client to TN3270E server) and an SNA Network (TN3270E server to target SNA host). The client-side network is typically TCP/IP, but it need not be. A host TN3270E server refers to an implementation where the TN3270E server is collocated with the Systems Network Architecture (SNA)System Services Control Point (SSCP) for the dependent SecondaryLogical Units (SLUs) that the server makes available to its clients for connecting into a SNA network. A gateway TN3270E server resides on an SNA node other than an SSCP, either an SNA type 2.0 node, a boundary-function-attached type 2.1 node, or an APPN node acting in the role of a Dependent LU Requester (DLUR). Host and gatewayTN3270E server implementations typically differ greatly as to their internal implementation and system definition (SYSDEF) methods. It is the intent that the MIB defined herein be extended by subsequent memos. For example, one such extension enables collection of TN3270E response time data.
RFC 2562	Definitions of Protocol and Managed Objects for TN3270E Response Time Collection Using SMIv2 (TN3270E-RT-MIB)
	Authors: K. White, R. Moore. Date: April 1999 Formats: txt pdf Status: PROPOSED STANDARD This memo defines the protocol and the Management Information Base(MIB) for performing response time data collection on TN3270 andTN3270E sessions by a TN3270E server. The response time data collected by a TN3270E server is structured to support both validation of service level agreements and performance monitoring ofTN3270 and TN3270E Sessions. This MIB has as a prerequisite theTN3270E-MIB, reference [20]. TN3270E, defined by RFC 2355 [19], refers to the enhancements made to the Telnet 3270 (TN3270) terminal emulation practices. Refer to RFC1041 [18], STD 8, RFC 854 [16], and STD 31, RFC 860 [17] for a sample of what is meant by TN3270 practices.
RFC 2563	DHCP Option to Disable Stateless Auto-Configuration in IPv4 Clients
	Authors: R. Troll. Date: May 1999 Formats: txt pdf Status: PROPOSED STANDARD Operating Systems are now attempting to support ad-hoc networks of two or more systems, while keeping user configuration at a minimum.To accommodate this, in the absence of a central configuration mechanism (DHCP), some OS's are automatically choosing a link-localIP address which will allow them to communicate only with other hosts on the same link. This address will not allow the OS to communicate with anything beyond a router. However, some sites depend on the fact that a host with no DHCP response will have no IP address. This document describes a mechanism by which DHCP servers are able to tell clients that they do not have an IP address to offer, and that the client should not generate an IP address it's own.
RFC 2564	Application Management MIB
	Authors: C. Kalbfleisch, C. Krupczak, R. Presuhn, J. Saperia. Date: May 1999 Formats: txt pdf Status: PROPOSED STANDARD This memo defines a standards track portion of the ManagementInformation Base (MIB) for use with network management protocols in the Internet Community. In particular, it defines objects used for the management of applications. This MIB complements the SystemApplication MIB, providing for the management of applications' common attributes which could not typically be observed without the cooperation of the software being managed.
RFC 2576	Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework
	Authors: R. Frye, D. Levi, S. Routhier, B. Wijnen. Date: March 2000 Formats: txt pdf Obsoletes: RFC 1908, RFC 2089 Obsoleted by: RFC 3584 Status: PROPOSED STANDARD The purpose of this document is to describe coexistence between version 3 of the Internet-standard Network Management Framework,(SNMPv3), version 2 of the Internet-standard Network ManagementFramework (SNMPv2), and the original Internet-standard NetworkManagement Framework (SNMPv1). This document obsoletes RFC 1908 [13] and RFC2089 [14].
RFC 2581	TCP Congestion Control
	Authors: M. Allman, V. Paxson, W. Stevens. Date: April 1999 Formats: txt pdf Obsoletes: RFC 2001 Obsoleted by: RFC 5681 Updated by: RFC 3390 Status: PROPOSED STANDARD This document defines TCP's four intertwined congestion control algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery. In addition, the document specifies how TCP should begin transmission after a relatively long idle period, as well as discussing various acknowledgment generation methods.
RFC 2584	Definitions of Managed Objects for APPN/HPR in IP Networks
	Authors: B. Clouston, B. Moore. Date: May 1999 Formats: txt pdf Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it defines objects for monitoring and controlling HPR(High Performance Routing) network devices which have the capability to communicate in IP (Internet Protocol) networks. This memo identifies managed objects for the HPR in IP network communications.
RFC 2585	Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP
	Authors: R. Housley, P. Hoffman. Date: May 1999 Formats: txt pdf Status: PROPOSED STANDARD The protocol conventions described in this document satisfy some of the operational requirements of the Internet Public KeyInfrastructure (PKI). This document specifies the conventions for using the File Transfer Protocol (FTP) and the Hypertext TransferProtocol (HTTP) to obtain certificates and certificate revocation lists (CRLs) from PKI repositories. Additional mechanisms addressingPKIX operational requirements are specified in separate documents.
RFC 2587	Internet X.509 Public Key Infrastructure LDAPv2 Schema
	Authors: S. Boeyen, T. Howes, P. Richard. Date: June 1999 Formats: txt pdf Obsoleted by: RFC 4523 Status: PROPOSED STANDARD The schema defined in this document is a minimal schema to support PKIX in an LDAPv2 environment, as defined in RFC 2559. Only PKIX-specific components are specified here. [STANDARDS-TRACK]
RFC 2589	Lightweight Directory Access Protocol (v3): Extensions for Dynamic Directory Services
	Authors: Y. Yaacovi, M. Wahl, T. Genovese. Date: May 1999 Formats: txt pdf Status: PROPOSED STANDARD This document defines the requirements for dynamic directory services and specifies the format of request and response extended operations for supporting client-server interoperation in a dynamic directories environment. [STANDARDS-TRACK]
RFC 2590	Transmission of IPv6 Packets over Frame Relay Networks Specification
	Authors: A. Conta, A. Malis, M. Mueller. Date: May 1999 Formats: txt pdf Status: PROPOSED STANDARD This memo describes mechanisms for the transmission of IPv6 packets over Frame Relay networks.
RFC 2591	Definitions of Managed Objects for Scheduling Management Operations
	Authors: D. Levi, J. Schoenwaelder. Date: May 1999 Formats: txt pdf Obsoleted by: RFC 3231 Status: PROPOSED STANDARD 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 a set of managed objects that are used to schedule management operations periodically or at specified dates and times.
RFC 2592	Definitions of Managed Objects for the Delegation of Management Script
	Authors: D. Levi, J. Schoenwaelder. Date: May 1999 Formats: txt pdf Obsoleted by: RFC 3165 Status: PROPOSED STANDARD 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 a set of managed objects that allow the delegation of management scripts to distributed managers.
RFC 2594	Definitions of Managed Objects for WWW Services
	Authors: H. Hazewinkel, C. Kalbfleisch, J. Schoenwaelder. Date: May 1999 Formats: txt pdf Status: PROPOSED STANDARD 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 a set of objects for managing World WideWeb (WWW) services.
RFC 2595	Using TLS with IMAP, POP3 and ACAP
	Authors: C. Newman. Date: June 1999 Formats: txt pdf Updated by: RFC 4616 Status: PROPOSED STANDARD Recognizing that such sites will desire simple password authentication in combination with TLS encryption, this specification defines the PLAIN SASL mechanism for use with protocols which lack a simple password authentication command such as ACAP and SMTP. [STANDARDS-TRACK]
RFC 2596	Use of Language Codes in LDAP
	Authors: M. Wahl, T. Howes. Date: May 1999 Formats: txt pdf Obsoleted by: RFC 3866 Status: PROPOSED STANDARD This document describes how language codes are carried in LDAP and are to be interpreted by LDAP servers. [STANDARDS-TRACK]
RFC 2597	Assured Forwarding PHB Group
	Authors: J. Heinanen, F. Baker, W. Weiss, J. Wroclawski. Date: June 1999 Formats: txt pdf Updated by: RFC 3260 Status: PROPOSED STANDARD This document defines a general use Differentiated Services (DS)[Blake] Per-Hop-Behavior (PHB) Group called Assured Forwarding (AF).The AF PHB group provides delivery of IP packets in four independently forwarded AF classes. Within each AF class, an IP packet can be assigned one of three different levels of drop precedence. A DS node does not reorder IP packets of the same microflow if they belong to the same AF class.
RFC 2598	An Expedited Forwarding PHB
	Authors: V. Jacobson, K. Nichols, K. Poduri. Date: June 1999 Formats: txt pdf Obsoleted by: RFC 3246 Status: PROPOSED STANDARD The definition of PHBs (per-hop forwarding behaviors) is a critical part of the work of the Diffserv Working Group. This document describes a PHB called Expedited Forwarding. We show the generality of this PHB by noting that it can be produced by more than one mechanism and give an example of its use to produce at least one service, a Virtual Leased Line. A recommended codepoint for this PHB is given. A pdf version of this document is available at ftp://ftp.ee.lbl.gov/papers/ef_phb.pdf
RFC 2601	ILMI-Based Server Discovery for ATMARP
	Authors: M. Davison. Date: June 1999 Formats: txt pdf Status: PROPOSED STANDARD This memo defines how ILMI-based Server Discovery, which provides a method for ATM-attached hosts and routers to dynamically determine the ATM addresses of servers, shall be used to locate ATMARP servers.
RFC 2602	ILMI-Based Server Discovery for MARS
	Authors: M. Davison. Date: June 1999 Formats: txt pdf Status: PROPOSED STANDARD This memo defines how ILMI-based Server Discovery, which provides a method for ATM-attached hosts and routers to dynamically determine the ATM addresses of servers, shall be used to locate MARS servers.
RFC 2603	ILMI-Based Server Discovery for NHRP
	Authors: M. Davison. Date: June 1999 Formats: txt pdf Status: PROPOSED STANDARD This memo defines how ILMI-based Server Discovery, which provides a method for ATM-attached hosts and routers to dynamically determine the ATM addresses of servers, shall be used to locate NHRP servers.
RFC 2605	Directory Server Monitoring MIB
	Authors: G. Mansfield, S. Kille. Date: June 1999 Formats: txt pdf Obsoletes: RFC 1567 Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.This memo obsoletes RFC 1567, "X.500 Directory Monitoring MIB". This memo extends that specification to a more generic MIB for monitoring one or more directory servers each of which may support multiple access protocols. The MIB defined in this memo will be used in conjunction with the NETWORK-SERVICES-MIB [19] for monitoringDirectory Servers.
RFC 2608	Service Location Protocol, Version 2
	Authors: E. Guttman, C. Perkins, J. Veizades, M. Day. Date: June 1999 Formats: txt pdf Updates: RFC 2165 Updated by: RFC 3224 Status: PROPOSED STANDARD The Service Location Protocol provides a scalable framework for the discovery and selection of network services. Using this protocol, computers using the Internet need little or no static configuration of network services for network based applications. This is especially important as computers become more portable, and users less tolerant or able to fulfill the demands of network system administration.
RFC 2609	Service Templates and Service: Schemes
	Authors: E. Guttman, C. Perkins, J. Kempf. Date: June 1999 Formats: txt pdf Updates: RFC 2165 Status: PROPOSED STANDARD The "service:" URL scheme name is used to define URLs (called"service: URLs" in this document) that are primarily intended to be used by the Service Location Protocol in order to distribute service access information. These schemes provide an extensible framework for client-based network software to obtain configuration information required to make use of network services. When registering a service: URL, the URL is accompanied by a set of well-defined attributes which define the service. These attributes convey configuration information to client software, or service characteristics meaningful to end users. This document describes a formal procedure for defining and standardizing new service types and attributes for use with the"service:" scheme. The formal descriptions of service types and attributes are templates that are human and machine understandable.They SHOULD be used by administrative tools to parse service registration information and by client applications to provide localized translations of service attribute strings.
RFC 2610	DHCP Options for Service Location Protocol
	Authors: C. Perkins, E. Guttman. Date: June 1999 Formats: txt pdf Status: PROPOSED STANDARD The Dynamic Host Configuration Protocol provides a framework for passing configuration information to hosts on a TCP/IP network.Entities using the Service Location Protocol need to find out the address of Directory Agents in order to transact messages. Another option provides an assignment of scope for configuration of SLP User and Service Agents.
RFC 2615	PPP over SONET/SDH
	Authors: A. Malis, W. Simpson. Date: June 1999 Formats: txt pdf Obsoletes: RFC 1619 Status: PROPOSED STANDARD The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.This document describes the use of PPP over Synchronous OpticalNetwork (SONET) and Synchronous Digital Hierarchy (SDH) circuits. This document replaces and obsoletes RFC 1619. See section 7 for a summary of the changes from RFC 1619.
RFC 2618	RADIUS Authentication Client MIB
	Authors: B. Aboba, G. Zorn. Date: June 1999 Formats: txt pdf Obsoleted by: RFC 4668 Status: PROPOSED STANDARD This memo defines a set of extensions which instrument RADIUS authentication client functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions IP-based management stations can manage RADIUS authentication clients.
RFC 2619	RADIUS Authentication Server MIB
	Authors: G. Zorn, B. Aboba. Date: June 1999 Formats: txt pdf Obsoleted by: RFC 4669 Status: PROPOSED STANDARD This memo defines a set of extensions which instrument RADIUS authentication server functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions IP-based management stations can manage RADIUS authentication servers.
RFC 2622	Routing Policy Specification Language (RPSL)
	Authors: C. Alaettinoglu, C. Villamizar, E. Gerich, D. Kessens, D. Meyer, T. Bates, D. Karrenberg, M. Terpstra. Date: June 1999 Formats: txt pdf Obsoletes: RFC 2280 Updated by: RFC 4012 Status: PROPOSED STANDARD RPSL allows a network operator to be able to specify routing policies at various levels in the Internet hierarchy; for example at theAutonomous System (AS) level. At the same time, policies can be specified with sufficient detail in RPSL so that low level router configurations can be generated from them. RPSL is extensible; new routing protocols and new protocol features can be introduced at any time.
RFC 2623	NFS Version 2 and Version 3 Security Issues and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5
	Authors: M. Eisler. Date: June 1999 Formats: txt pdf Status: PROPOSED STANDARD This memorandum clarifies various security issues involving the NFS protocol (Version 2 and Version 3 only) and then describes how theVersion 2 and Version 3 of the NFS protocol use the RPCSEC_GSS security flavor protocol and Kerberos V5. This memorandum is provided so that people can write compatible implementations.
RFC 2625	IP and ARP over Fibre Channel
	Authors: M. Rajagopal, R. Bhagwat, W. Rickard. Date: June 1999 Formats: txt pdf Obsoleted by: RFC 4338 Status: PROPOSED STANDARD Fibre Channel (FC) is a high speed serial interface technology that supports several higher layer protocols including Small ComputerSystem Interface (SCSI) and Internet Protocol(IP). Until now, SCSI has been the only widely used protocol over FC. Existing FC standards[3] do not adequately specify how IP packets may be transported overFC and how IP addresses are resolved to FC addresses. The purpose of this document is to specify a way of encapsulating IP and AddressResolution Protocol(ARP) over Fibre Channel and also to describe a mechanism(s) for IP address resolution.
RFC 2630	Cryptographic Message Syntax
	Authors: R. Housley. Date: June 1999 Formats: txt pdf Obsoleted by: RFC 3369, RFC 3370 Status: PROPOSED STANDARD This document describes the Cryptographic Message Syntax. This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary messages. The Cryptographic Message Syntax is derived from PKCS #7 version 1.5 as specified in RFC 2315 [PKCS#7]. Wherever possible, backward compatibility is preserved; however, changes were necessary to accommodate attribute certificate transfer and key agreement techniques for key management.
RFC 2631	Diffie-Hellman Key Agreement Method
	Authors: E. Rescorla. Date: June 1999 Formats: txt pdf Status: PROPOSED STANDARD This document standardizes one particular Diffie-Hellman variant, based on the ANSI X9.42 draft, developed by the ANSI X9F1 working group. Diffie-Hellman is a key agreement algorithm used by two parties to agree on a shared secret. An algorithm for converting the shared secret into an arbitrary amount of keying material is provided. The resulting keying material is used as a symmetric encryption key. The Diffie-Hellman variant described requires the recipient to have a certificate, but the originator may have a static key pair (with the public key placed in a certificate) or an ephemeral key pair.
RFC 2632	S/MIME Version 3 Certificate Handling
	Authors: B. Ramsdell, Ed.. Date: June 1999 Formats: txt pdf Obsoleted by: RFC 3850 Status: PROPOSED STANDARD S/MIME (Secure/Multipurpose Internet Mail Extensions), provides a method to send and receive secure MIME messages. Before using a public key to provide security services, the S/MIME agent MUST certify that the public key is valid. S/MIME agents MUST use PKIX certificates to validate public keys as described in the Internet X.509 Public Key Infrastructure (PKIX) Certificate and CRL Profile. [STANDARDS-TRACK]
RFC 2633	S/MIME Version 3 Message Specification
	Authors: B. Ramsdell, Ed.. Date: June 1999 Formats: txt pdf Obsoleted by: RFC 3851 Status: PROPOSED STANDARD This document describes a protocol for adding cryptographic signature and encryption services to MIME data. [STANDARDS-TRACK]
RFC 2634	Enhanced Security Services for S/MIME
	Authors: P. Hoffman, Ed.. Date: June 1999 Formats: txt pdf Updated by: RFC 5035 Status: PROPOSED STANDARD This document describes four optional security service extensions for S/MIME. [STANDARDS-TRACK]
RFC 2640	Internationalization of the File Transfer Protocol
	Authors: B. Curtin. Date: July 1999 Formats: txt pdf Updates: RFC 0959 Status: PROPOSED STANDARD The File Transfer Protocol, as defined in RFC 959 [RFC959] and RFC1123 Section 4 [RFC1123], is one of the oldest and widely used protocols on the Internet. The protocol's primary character set, 7 bit ASCII, has served the protocol well through the early growth years of the Internet. However, as the Internet becomes more global, there is a need to support character sets beyond 7 bit ASCII. This document addresses the internationalization (I18n) of FTP, which includes supporting the multiple character sets and languages found throughout the Internet community. This is achieved by extending theFTP specification and giving recommendations for proper internationalization support.
RFC 2645	ON-DEMAND MAIL RELAY (ODMR) SMTP with Dynamic IP Addresses
	Authors: R. Gellens. Date: August 1999 Formats: txt pdf Status: PROPOSED STANDARD This memo proposes a new service, On-Demand Mail Relay (ODMR), which is a profile of SMTP, providing for a secure, extensible, easy to implement approach to the problem. [STANDARDS-TRACK]
RFC 2646	The Text/Plain Format Parameter
	Authors: R. Gellens, Ed.. Date: August 1999 Formats: txt pdf Obsoleted by: RFC 3676 Updates: RFC 2046 Status: PROPOSED STANDARD This memo proposes a new parameter to be used with Text/Plain, and, in the presence of this parameter, the use of trailing whitespace to indicate flowed lines. This results in an encoding which appears as normal Text/Plain in older implementations, since it is in fact normal Text/Plain. [STANDARDS-TRACK]
RFC 2651	The Architecture of the Common Indexing Protocol (CIP)
	Authors: J. Allen, M. Mealling. Date: August 1999 Formats: txt pdf Status: PROPOSED STANDARD The Common Indexing Protocol (CIP) is used to pass indexing information from server to server in order to facilitate query routing. Query routing is the process of redirecting and replicating queries through a distributed database system towards servers holding the desired results. This document describes the CIP framework, including its architecture and the protocol specifics of exchanging indices.
RFC 2652	MIME Object Definitions for the Common Indexing Protocol (CIP)
	Authors: J. Allen, M. Mealling. Date: August 1999 Formats: txt pdf Status: PROPOSED STANDARD The Common Indexing Protocol (CIP) is used to pass indexing information from server to server in order to facilitate query routing. The protocol is comprised of several MIME objects being passed from server to server. This document describes the definitions of those objects as well as the methods and requirements needed to define a new index type.
RFC 2653	CIP Transport Protocols
	Authors: J. Allen, P. Leach, R. Hedberg. Date: August 1999 Formats: txt pdf Status: PROPOSED STANDARD This document specifies three protocols for transporting CIP requests, responses and index objects, utilizing TCP, mail, and HTTP.The objects themselves are defined in [CIP-MIME] and the overall CIP architecture is defined in [CIP-ARCH].
RFC 2658	RTP Payload Format for PureVoice(tm) Audio
	Authors: K. McKay. Date: August 1999 Formats: txt pdf Status: PROPOSED STANDARD This document describes the RTP payload format for PureVoice(tm) Audio. [STANDARDS-TRACK]
RFC 2661	Layer Two Tunneling Protocol "L2TP"
	Authors: W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn, B. Palter. Date: August 1999 Formats: txt pdf Status: PROPOSED STANDARD This document describes the Layer Two Tunneling Protocol (L2TP). STD51, RFC 1661 specifies multi-protocol access via PPP [RFC1661]. L2TP facilitates the tunneling of PPP packets across an intervening network in a way that is as transparent as possible to both end-users and applications.
RFC 2662	Definitions of Managed Objects for the ADSL Lines
	Authors: G. Bathrick, F. Ly. Date: August 1999 Formats: txt pdf Status: PROPOSED STANDARD This document defines a standard SNMP MIB for ADSL lines based on the ADSL Forum standard data model. [STANDARDS-TRACK]
RFC 2665	Definitions of Managed Objects for the Ethernet-like Interface Types
	Authors: J. Flick, J. Johnson. Date: August 1999 Formats: txt pdf Obsoletes: RFC 2358 Obsoleted by: RFC 3635 Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.This memo obsoletes RFC 2358, "Definitions of Managed Objects for theEthernet-like Interface Types". This memo extends that specification by including management information useful for the management of 1000Mb/s and full-duplex Ethernet interfaces. Ethernet technology, as defined by the 802.3 Working Group of theIEEE, continues to evolve, with scalable increases in speed, new types of cabling and interfaces, and new features. This evolution may require changes in the managed objects in order to reflect this new functionality. This document, as with other documents issued by this working group, reflects a certain stage in the evolution ofEthernet technology. In the future, this document might be revised, or new documents might be issued by the Ethernet Interfaces and HubMIB Working Group, in order to reflect the evolution of Ethernet technology.
RFC 2667	IP Tunnel MIB
	Authors: D. Thaler. Date: August 1999 Formats: txt pdf Obsoleted by: RFC 4087 Status: PROPOSED STANDARD This memo defines a Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing tunnels of any type over IPv4 networks. [STANDARDS-TRACK]
RFC 2668	Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs)
	Authors: A. Smith, J. Flick, K. de Graaf, D. Romascanu, D. McMaster, K. McCloghrie, S. Roberts. Date: August 1999 Formats: txt pdf Obsoletes: RFC 2239 Obsoleted by: RFC 3636 Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.This memo obsoletes RFC 2239, "Definitions of Managed Objects forIEEE 802.3 Medium Attachment Units (MAUs) using SMIv2". This memo extends that specification by including management information useful for the management of 1000 Mb/s MAUs. Ethernet technology, as defined by the 802.3 Working Group of theIEEE, continues to evolve, with scalable increases in speed, new types of cabling and interfaces, and new features. This evolution may require changes in the managed objects in order to reflect this new functionality. This document, as with other documents issued by this working group, reflects a certain stage in the evolution ofEthernet technology. In the future, this document might be revised, or new documents might be issued by the Ethernet Interfaces and HubMIB Working Group, in order to reflect the evolution of Ethernet technology.
RFC 2669	DOCSIS Cable Device MIB Cable Device Management Information Base for DOCSIS compliant Cable Modems and Cable Modem Termination Systems
	Authors: M. St. Johns, Ed.. Date: August 1999 Formats: txt pdf Obsoleted by: RFC 4639 Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it defines a basic set of managed objects for SNMP- based management of DOCSIS 1.0 compliant Cable Modems and Cable ModemTermination Systems. 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. This memo is a product of the IPCDN working group within the InternetEngineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at ipcdn@terayon.com and/or the author.
RFC 2670	Radio Frequency (RF) Interface Management Information Base for MCNS/DOCSIS compliant RF interfaces
	Authors: M. St. Johns, Ed.. Date: August 1999 Formats: txt pdf Obsoleted by: RFC 4546 Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it defines a basic set of managed objects for SNMP- based management of MCNS/DOCSIS compliant Radio Frequency (RF) interfaces. This memo specifies a MIB module in a manner that is compliant to theSNMP SMIv2 [5][6][7]. The set of objects are consistent with theSNMP framework and existing SNMP standards. This memo is a product of the IPCDN working group within the InternetEngineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at ipcdn@terayon.com and/or the author.
RFC 2671	Extension Mechanisms for DNS (EDNS0)
	Authors: P. Vixie. Date: August 1999 Formats: txt pdf Status: PROPOSED STANDARD The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow clients to advertise their capabilities to servers. This document describes backward compatible mechanisms for allowing the protocol to grow.
RFC 2672	Non-Terminal DNS Name Redirection
	Authors: M. Crawford. Date: August 1999 Formats: txt pdf Updated by: RFC 4592, RFC 6604 Status: PROPOSED STANDARD This document defines a new DNS Resource Record called "DNAME", which provides the capability to map an entire subtree of the DNS name space to another domain. [STANDARDS-TRACK]
RFC 2674	Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering and Virtual LAN Extensions
	Authors: E. Bell, A. Smith, P. Langille, A. Rijhsinghani, K. McCloghrie. Date: August 1999 Formats: txt pdf Obsoleted by: RFC 4363 Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets.In particular, it defines two MIB modules for managing the new capabilities of MAC bridges defined by the IEEE 802.1D-1998 MACBridges and the IEEE 802.1Q-1998 Virtual LAN (VLAN) standards for bridging between Local Area Network (LAN) segments. One MIB module defines objects for managing the 'Traffic Classes' and 'EnhancedMulticast Filtering' components of IEEE 802.1D-1998. The other MIB module defines objects for managing IEEE 802.1Q VLANs. Provisions are made for support of transparent bridging. Provisions are also made so that these objects apply to bridges connected by subnetworks other than LAN segments. This memo also includes severalMIB modules in a manner that is compliant to the SMIv2 [V2SMI]. This memo supplements RFC 1493 [BRIDGEMIB] and (to a lesser extent)RFC 1525 [SBRIDGEMIB].
RFC 2675	IPv6 Jumbograms
	Authors: D. Borman, S. Deering, R. Hinden. Date: August 1999 Formats: txt pdf Obsoletes: RFC 2147 Status: PROPOSED STANDARD A "jumbogram" is an IPv6 packet containing a payload longer than65,535 octets. This document describes the IPv6 Jumbo Payload option, which provides the means of specifying such large payload lengths. It also describes the changes needed to TCP and UDP to make use of jumbograms. Jumbograms are relevant only to IPv6 nodes that may be attached to links with a link MTU greater than 65,575 octets, and need not be implemented or understood by IPv6 nodes that do not support attachment to links with such large MTUs.
RFC 2677	Definitions of Managed Objects for the NBMA Next Hop Resolution Protocol (NHRP)
	Authors: M. Greene, J. Cucchiara, J. Luciani. Date: August 1999 Formats: txt pdf Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes managed objects for the Next HopResolution Protocol (NHRP) as defined in RFC 2332.
RFC 2678	IPPM Metrics for Measuring Connectivity
	Authors: J. Mahdavi, V. Paxson. Date: September 1999 Formats: txt pdf Obsoletes: RFC 2498 Status: PROPOSED STANDARD This memo defines a series of metrics for connectivity between a pair of Internet hosts. [STANDARDS-TRACK]
RFC 2679	A One-way Delay Metric for IPPM
	Authors: G. Almes, S. Kalidindi, M. Zekauskas. Date: September 1999 Formats: txt pdf Status: PROPOSED STANDARD This memo defines a metric for one-way delay of packets across Internet paths. [STANDARDS-TRACK]
RFC 2680	A One-way Packet Loss Metric for IPPM
	Authors: G. Almes, S. Kalidindi, M. Zekauskas. Date: September 1999 Formats: txt pdf Status: PROPOSED STANDARD This memo defines a metric for one-way packet loss across Internet paths. [STANDARDS-TRACK]
RFC 2681	A Round-trip Delay Metric for IPPM
	Authors: G. Almes, S. Kalidindi, M. Zekauskas. Date: September 1999 Formats: txt pdf Status: PROPOSED STANDARD This memo defines a metric for round-trip delay of packets across Internet paths. [STANDARDS-TRACK]
RFC 2684	Multiprotocol Encapsulation over ATM Adaptation Layer 5
	Authors: D. Grossman, J. Heinanen. Date: September 1999 Formats: txt pdf Obsoletes: RFC 1483 Status: PROPOSED STANDARD This memo replaces RFC 1483. It describes two encapsulations methods for carrying network interconnect traffic over AAL type 5 over ATM.The first method allows multiplexing of multiple protocols over a single ATM virtual connection whereas the second method assumes that each protocol is carried over a separate ATM virtual connection.
RFC 2685	Virtual Private Networks Identifier
	Authors: B. Fox, B. Gleeson. Date: September 1999 Formats: txt pdf Status: PROPOSED STANDARD Virtual Private IP networks may span multiple Autonomous Systems orService Providers. There is a requirement for the use of a globally unique VPN identifier in order to be able to refer to a particularVPN (see section 6.1.1 of [1]). This document proposes a format for a globally unique VPN identifier.
RFC 2686	The Multi-Class Extension to Multi-Link PPP
	Authors: C. Bormann. Date: September 1999 Formats: txt pdf Status: PROPOSED STANDARD A companion document describes an architecture for providing integrated services over low-bitrate links, such as modem lines, ISDNB-channels, and sub-T1 links [1]. The main components of the architecture are: a real-time encapsulation format for asynchronous and synchronous low-bitrate links, a header compression architecture optimized for real-time flows, elements of negotiation protocols used between routers (or between hosts and routers), and announcement protocols used by applications to allow this negotiation to take place. This document proposes the fragment-oriented solution for the real- time encapsulation format part of the architecture. The general approach is to start from the PPP Multilink fragmentation protocol[2] and provide a small number of extensions to add functionality and reduce the overhead.
RFC 2687	PPP in a Real-time Oriented HDLC-like Framing
	Authors: C. Bormann. Date: September 1999 Formats: txt pdf Status: PROPOSED STANDARD A companion document describes an architecture for providing integrated services over low-bitrate links, such as modem lines, ISDNB-channels, and sub-T1 links [1]. The main components of the architecture are: a real-time encapsulation format for asynchronous and synchronous low-bitrate links, a header compression architecture optimized for real-time flows, elements of negotiation protocols used between routers (or between hosts and routers), and announcement protocols used by applications to allow this negotiation to take place. This document proposes the suspend/resume-oriented solution for the real-time encapsulation format part of the architecture. The general approach is to start from the PPP Multilink fragmentation protocol[2] and its multi-class extension [5] and add suspend/resume in a way that is as compatible to existing hard- and firmware as possible.
RFC 2688	Integrated Services Mappings for Low Speed Networks
	Authors: S. Jackowski, D. Putzolu, E. Crawley, B. Davie. Date: September 1999 Formats: txt pdf Status: PROPOSED STANDARD A set of companion documents describe an architecture for providing integrated services over low-bitrate links, such as modem lines, ISDNB-channels, and sub-T1 links [1, 2, 3, 4]. The main components of the architecture are: a set of real-time encapsulation formats for asynchronous and synchronous low-bitrate links, a header compression architecture optimized for real-time flows, elements of negotiation protocols used between routers (or between hosts and routers), and announcement protocols used by applications to allow this negotiation to take place. This document defines the service mappings of the IETF IntegratedServices for low-bitrate links, specifically the controlled load [5] and guaranteed [6] services. The approach takes the form of a set of guidelines and considerations for implementing these services, along with evaluation criteria for elements providing these services.
RFC 2710	Multicast Listener Discovery (MLD) for IPv6
	Authors: S. Deering, W. Fenner, B. Haberman. Date: October 1999 Formats: txt pdf Updated by: RFC 3590, RFC 3810 Status: PROPOSED STANDARD This document specifies the protocol used by an IPv6 router to discover the presence of multicast listeners (that is, nodes wishing to receive multicast packets) on its directly attached links, and to discover specifically which multicast addresses are of interest to those neighboring nodes. This protocol is referred to as MulticastListener Discovery or MLD. MLD is derived from version 2 of IPv4'sInternet Group Management Protocol, IGMPv2. One important difference to note is that MLD uses ICMPv6 (IP Protocol 58) message types, rather than IGMP (IP Protocol 2) message types.
RFC 2711	IPv6 Router Alert Option
	Authors: C. Partridge, A. Jackson. Date: October 1999 Formats: txt pdf Updated by: RFC 6398 Status: PROPOSED STANDARD This memo describes a new IPv6 Hop-by-Hop Option type that alerts transit routers to more closely examine the contents of an IP datagram. This option is useful for situations where a datagram addressed to a particular destination contains information that may require special processing by routers along the path.
RFC 2712	Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)
	Authors: A. Medvinsky, M. Hur. Date: October 1999 Formats: txt pdf Status: PROPOSED STANDARD This document proposes the addition of new cipher suites to the TLS protocol to support Kerberos-based authentication. [STANDARDS TRACK]
RFC 2720	Traffic Flow Measurement: Meter MIB
	Authors: N. Brownlee. Date: October 1999 Formats: txt pdf Obsoletes: RFC 2064 Status: PROPOSED STANDARD 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 defines a Management Information Base (MIB) for use in controlling an RTFM Traffic Meter, in particular for specifying the flows to be measured. It also provides an efficient mechanism for retrieving flow data from the meter using SNMP. Security issues concerning the operation of traffic meters are summarised.
RFC 2725	Routing Policy System Security
	Authors: C. Villamizar, C. Alaettinoglu, D. Meyer, S. Murphy. Date: December 1999 Formats: txt pdf Updated by: RFC 4012 Status: PROPOSED STANDARD The RIPE database specifications and RPSL language define languages used as the basis for representing information in a routing policy system. A repository for routing policy system information is known as a routing registry. A routing registry provides a means of exchanging information needed to address many issues of importance to the operation of the Internet. The implementation and deployment of a routing policy system must maintain some degree of integrity to be of any operational use. This document addresses the need to assure integrity of the data by providing an authentication and authorization model.
RFC 2726	PGP Authentication for RIPE Database Updates
	Authors: J. Zsako. Date: December 1999 Formats: txt pdf Status: PROPOSED STANDARD This document presents the proposal for a stronger authentication method of the updates of the RIPE database based on digital signatures. The proposal tries to be as general as possible as far as digital signing methods are concerned, however, it concentrates mainly on PGP, as the first method to be implemented. The proposal is the result of the discussions within the RIPE DBSEC Task Force.
RFC 2728	The Transmission of IP Over the Vertical Blanking Interval of a Television Signal
	Authors: R. Panabaker, S. Wegerif, D. Zigmond. Date: November 1999 Formats: txt pdf Status: PROPOSED STANDARD This document describes a method for broadcasting IP data in a unidirectional manner using the vertical blanking interval of television signals. [STANDARDS TRACK]
RFC 2730	Multicast Address Dynamic Client Allocation Protocol (MADCAP)
	Authors: S. Hanna, B. Patel, M. Shah. Date: December 1999 Formats: txt pdf Status: PROPOSED STANDARD This document defines a protocol, Multicast Address Dynamic ClientAllocation Protocol (MADCAP), that allows hosts to request multicast addresses from multicast address allocation servers.
RFC 2732	Format for Literal IPv6 Addresses in URL's
	Authors: R. Hinden, B. Carpenter, L. Masinter. Date: December 1999 Formats: txt pdf Obsoleted by: RFC 3986 Updates: RFC 2396 Status: PROPOSED STANDARD This document defines the format for literal IPv6 Addresses in URL's for implementation in World Wide Web browsers. This format has been implemented in the IPv6 versions of several widely deployed browsers including Microsoft Internet Explorer, Mozilla, and Lynx. It is also intended to be used in the IPv6 version of the service location protocol. This document incudes an update to the generic syntax for UniformResource Identifiers defined in RFC 2396 [URL]. It defines a syntax for IPv6 addresses and allows the use of "[" and "]" within a URI explicitly for this reserved purpose.
RFC 2733	An RTP Payload Format for Generic Forward Error Correction
	Authors: J. Rosenberg, H. Schulzrinne. Date: December 1999 Formats: txt pdf Obsoleted by: RFC 5109 Status: PROPOSED STANDARD This document specifies a payload format for generic forward error correction of media encapsulated in RTP. It is engineered for FEC algorithms based on the exclusive-or (parity) operation. The payload format allows end systems to transmit using arbitrary block lengths and parity schemes. It also allows for the recovery of both the payload and critical RTP header fields. Since FEC is sent as a separate stream, it is backwards compatible with non-FEC capable hosts, so that receivers which do not wish to implement FEC can just ignore the extensions.
RFC 2734	IPv4 over IEEE 1394
	Authors: P. Johansson. Date: December 1999 Formats: txt pdf Status: PROPOSED STANDARD This document specifies how to use IEEE Std 1394-1995, Standard for a High Performance Serial Bus (and its supplements), for the transport of Internet Protocol Version 4 (IPv4) datagrams; it defines the necessary methods, data structures and codes for that purpose. [STANDARDS TRACK]
RFC 2735	NHRP Support for Virtual Private Networks
	Authors: B. Fox, B. Petri. Date: December 1999 Formats: txt pdf Status: PROPOSED STANDARD The NBMA Next Hop Resolution Protocol (NHRP) is used to determine theNBMA subnetwork addresses of the "NBMA next hop" towards a public internetworking layer address (see [1]). This document describes the enhancements necessary to enable NHRP to perform the same function for private internetworking layer addresses available within the framework of a Virtual Private Network (VPN) service on a shared NBMA network.
RFC 2737	Entity MIB (Version 2)
	Authors: K. McCloghrie, A. Bierman. Date: December 1999 Formats: txt pdf Obsoletes: RFC 2037 Obsoleted by: RFC 4133 Status: PROPOSED STANDARD 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 multiple logical and physical entities managed by a single SNMP agent.
RFC 2738	Corrections to "A Syntax for Describing Media Feature Sets"
	Authors: G. Klyne. Date: December 1999 Formats: txt pdf Updates: RFC 2533 Status: PROPOSED STANDARD In RFC 2533, "A Syntax for Describing Media Feature Sets", an expression format is presented for describing media feature capabilities using simple media feature tags. This memo contains two corrections to that specification: one fixes an error in the formal syntax specification, and the other fixes an error in the rules for reducing feature comparison predicates.
RFC 2739	Calendar Attributes for vCard and LDAP
	Authors: T. Small, D. Hennessy, F. Dawson. Date: January 2000 Formats: txt pdf Updated by: RFC 6350 Status: PROPOSED STANDARD When scheduling a calendar entity, such as an event, it is a prerequisite that an organizer has the calendar address of each attendee that will be invited to the event. Additionally, access to an attendee's current "busy time" provides an a priori indication of whether the attendee will be free to participate in the event. In order to meet these challenges, a calendar user agent (CUA) needs a mechanism to locate (URI) individual user's calendar and free/busy time. This memo defines three mechanisms for obtaining a URI to a user's calendar and free/busy time. These include: - Manual transfer of the information; - Personal data exchange using the vCard format; and - Directory lookup using the LDAP protocol.
RFC 2740	OSPF for IPv6
	Authors: R. Coltun, D. Ferguson, J. Moy. Date: December 1999 Formats: txt pdf Obsoleted by: RFC 5340 Status: PROPOSED STANDARD This document describes the modifications to OSPF to support version6 of the Internet Protocol (IPv6). The fundamental mechanisms ofOSPF (flooding, DR election, area support, SPF calculations, etc.) remain unchanged. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6. Changes between OSPF for IPv4 and this document include the following. Addressing semantics have been removed from OSPF packets and the basic LSAs. New LSAs have been created to carry IPv6 addresses and prefixes. OSPF now runs on a per-link basis, instead of on a per-IP-subnet basis. Flooding scope for LSAs has been generalized. Authentication has been removed from the OSPF protocol itself, instead relying on IPv6's Authentication Header andEncapsulating Security Payload. Most packets in OSPF for IPv6 are almost as compact as those in OSPF for IPv4, even with the larger IPv6 addresses. Most field-XSand packet-size limitations present in OSPF for IPv4 have been relaxed.In addition, option handling has been made more flexible. All of OSPF for IPv4's optional capabilities, including on-demand circuit support, NSSA areas, and the multicast extensions to OSPF(MOSPF) are also supported in OSPF for IPv6.
RFC 2743	Generic Security Service Application Program Interface Version 2, Update 1
	Authors: J. Linn. Date: January 2000 Formats: txt pdf Obsoletes: RFC 2078 Updated by: RFC 5554 Status: PROPOSED STANDARD The Generic Security Service Application Program Interface (GSS-API),Version 2, as defined in [RFC-2078], provides security services to callers in a generic fashion, supportable with a range of underlying mechanisms and technologies and hence allowing source-level portability of applications to different environments. This specification defines GSS-API services and primitives at a level independent of underlying mechanism and programming language environment, and is to be complemented by other, related specifications: documents defining specific parameter bindings for particular language environments documents defining token formats, protocols, and procedures to be implemented in order to realize GSS-API services atop particular security mechanisms This memo obsoletes [RFC-2078], making specific, incremental changes in response to implementation experience and liaison requests. It is intended, therefore, that this memo or a successor version thereto will become the basis for subsequent progression of the GSS-API specification on the standards track.
RFC 2744	Generic Security Service API Version 2 : C-bindings
	Authors: J. Wray. Date: January 2000 Formats: txt pdf Obsoletes: RFC 1509 Status: PROPOSED STANDARD This document specifies C language bindings for Version 2, Update 1 of the Generic Security Service Application Program Interface (GSS-API), which is described at a language-independent conceptual level in RFC-2743 [GSSAPI]. It obsoletes RFC-1509, making specific incremental changes in response to implementation experience and liaison requests. It is intended, therefore, that this memo or a successor version thereof will become the basis for subsequent progression of the GSS-API specification on the standards track. The Generic Security Service Application Programming Interface provides security services to its callers, and is intended for implementation atop a variety of underlying cryptographic mechanisms.Typically, GSS-API callers will be application protocols into which security enhancements are integrated through invocation of services provided by the GSS-API. The GSS-API allows a caller application to authenticate a principal identity associated with a peer application, to delegate rights to a peer, and to apply security services such as confidentiality and integrity on a per-message basis.
RFC 2745	RSVP Diagnostic Messages
	Authors: A. Terzis, B. Braden, S. Vincent, L. Zhang. Date: January 2000 Formats: txt pdf Status: PROPOSED STANDARD This document specifies the RSVP diagnostic facility, which allows a user to collect information about the RSVP state along a path. This specification describes the functionality, diagnostic message formats, and processing rules.
RFC 2746	RSVP Operation Over IP Tunnels
	Authors: A. Terzis, J. Krawczyk, J. Wroclawski, L. Zhang. Date: January 2000 Formats: txt pdf Status: PROPOSED STANDARD This document describes an approach for providing RSVP protocol services over IP tunnels. We briefly describe the problem, the characteristics of possible solutions, and the design goals of our approach. We then present the details of an implementation which meets our design goals.
RFC 2747	RSVP Cryptographic Authentication
	Authors: F. Baker, B. Lindell, M. Talwar. Date: January 2000 Formats: txt pdf Updated by: RFC 3097 Status: PROPOSED STANDARD This document describes the format and use of RSVP's INTEGRITY object to provide hop-by-hop integrity and authentication of RSVP messages.
RFC 2748	The COPS (Common Open Policy Service) Protocol
	Authors: D. Durham, Ed., J. Boyle, R. Cohen, S. Herzog, R. Rajan, A. Sastry. Date: January 2000 Formats: txt pdf Updated by: RFC 4261 Status: PROPOSED STANDARD This document describes a simple client/server model for supporting policy control over QoS signaling protocols. The model does not make any assumptions about the methods of the policy server, but is based on the server returning decisions to policy requests. The model is designed to be extensible so that other kinds of policy clients may be supported in the future. However, this document makes no claims that it is the only or the preferred approach for enforcing future types of policies.
RFC 2749	COPS usage for RSVP
	Authors: S. Herzog, Ed., J. Boyle, R. Cohen, D. Durham, R. Rajan, A. Sastry. Date: January 2000 Formats: txt pdf Status: PROPOSED STANDARD This document describes usage directives for supporting COPS policy services in RSVP environments.
RFC 2750	RSVP Extensions for Policy Control
	Authors: S. Herzog. Date: January 2000 Formats: txt pdf Updates: RFC 2205 Status: PROPOSED STANDARD This memo presents a set of extensions for supporting generic policy based admission control in RSVP. It should be perceived as an extension to the RSVP functional specifications [RSVP] These extensions include the standard format of POLICY_DATA objects, and a description of RSVP's handling of policy events. This document does not advocate particular policy control mechanisms; however, a Router/Server Policy Protocol description for these extensions can be found in [RAP, COPS, COPS-RSVP].
RFC 2751	Signaled Preemption Priority Policy Element
	Authors: S. Herzog. Date: January 2000 Formats: txt pdf Obsoleted by: RFC 3181 Status: PROPOSED STANDARD This document describes a preemption priority policy element for use by signaled policy based admission protocols (such as [RSVP] and[COPS]). Preemption priority defines a relative importance (rank) within the set of flows competing to be admitted into the network. Rather than admitting flows by order of arrival (First Come First Admitted) network nodes may consider priorities to preempt some previously admitted low priority flows in order to make room for a newer, high- priority flow.
RFC 2752	Identity Representation for RSVP
	Authors: S. Yadav, R. Yavatkar, R. Pabbati, P. Ford, T. Moore, S. Herzog. Date: January 2000 Formats: txt pdf Obsoleted by: RFC 3182 Status: PROPOSED STANDARD This document describes the representation of identity information inPOLICY_DATA object [POL-EXT] for supporting policy based admission control in RSVP. The goal of identity representation is to allow a process on a system to securely identify the owner and the application of the communicating process (e.g. user id) and convey this information in RSVP messages (PATH or RESV) in a secure manner.We describe the encoding of identities as RSVP policy element. We describe the processing rules to generate identity policy elements for multicast merged flows. Subsequently, we describe representations of user identities for Kerberos and Public Key based user authentication mechanisms. In summary we describe the use of this identity information in an operational setting.
RFC 2765	Stateless IP/ICMP Translation Algorithm (SIIT)
	Authors: E. Nordmark. Date: February 2000 Formats: txt pdf Obsoleted by: RFC 6145 Status: PROPOSED STANDARD This document specifies a transition mechanism algorithm in addition to the mechanisms already specified in [TRANS-MECH]. The algorithm translates between IPv4 and IPv6 packet headers (including ICMP headers) in separate translator "boxes" in the network without requiring any per-connection state in those "boxes". This new algorithm can be used as part of a solution that allows IPv6 hosts, which do not have a permanently assigned IPv4 addresses, to communicate with IPv4-only hosts. The document neither specifies address assignment nor routing to and from the IPv6 hosts when they communicate with the IPv4-only hosts.
RFC 2769	Routing Policy System Replication
	Authors: C. Villamizar, C. Alaettinoglu, R. Govindan, D. Meyer. Date: February 2000 Formats: txt pdf Status: PROPOSED STANDARD The RIPE database specifications and RPSL define languages used as the basis for representing information in a routing policy system. A repository for routing policy system information is known as a routing registry. A routing registry provides a means of exchanging information needed to address many issues of importance to the operation of the Internet. The implementation and deployment of a routing policy system must maintain some degree of integrity to be of any use. The Routing Policy System Security RFC [3] addresses the need to assure integrity of the data by proposing an authentication and authorization model. This document addresses the need to distribute data over multiple repositories and delegate authority for data subsets to other repositories without compromising the authorization model established in Routing Policy System SecurityRFC.
RFC 2782	A DNS RR for specifying the location of services (DNS SRV)
	Authors: A. Gulbrandsen, P. Vixie, L. Esibov. Date: February 2000 Formats: txt pdf Obsoletes: RFC 2052 Updated by: RFC 6335 Status: PROPOSED STANDARD This document describes a DNS RR which specifies the location of the server(s) for a specific protocol and domain.
RFC 2784	Generic Routing Encapsulation (GRE)
	Authors: D. Farinacci, T. Li, S. Hanks, D. Meyer, P. Traina. Date: March 2000 Formats: txt pdf Updated by: RFC 2890 Status: PROPOSED STANDARD This document specifies a protocol for encapsulation of an arbitrary network layer protocol over another arbitrary network layer protocol.
RFC 2787	Definitions of Managed Objects for the Virtual Router Redundancy Protocol
	Authors: B. Jewell, D. Chuang. Date: March 2000 Formats: txt pdf Obsoleted by: RFC 6527 Status: PROPOSED STANDARD This specification defines an extension to the Management InformationBase (MIB) for use with SNMP-based network management. In particular, it defines objects for configuring, monitoring, and controlling routers that employ the Virtual Router RedundancyProtocol (VRRP) [17]. This memo specifies a MIB module in a manner that is compliant withSMIv2 [5], and semantically identical to the SMIv1 definitions [2].
RFC 2788	Network Services Monitoring MIB
	Authors: N. Freed, S. Kille. Date: March 2000 Formats: txt pdf Obsoletes: RFC 2248 Status: PROPOSED STANDARD This document defines a MIB which contains the elements common to the monitoring of any network service application. [STANDARDS TRACK]
RFC 2789	Mail Monitoring MIB
	Authors: N. Freed, S. Kille. Date: March 2000 Formats: txt pdf Obsoletes: RFC 2249, RFC 1566 Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Specifically, this memo extends the basic Network Services Monitoring MIB defined in RFC 2788 [16] to allow monitoring of Message Transfer Agents (MTAs). It may also be used to monitor MTA components within gateways. [STANDARDS TRACK]
RFC 2793	RTP Payload for Text Conversation
	Authors: G. Hellstrom. Date: May 2000 Formats: txt pdf Obsoleted by: RFC 4103 Status: PROPOSED STANDARD This memo describes how to carry text conversation session contents in RTP packets. Text conversation session contents are specified inITU-T Recommendation T.140 [1]. Text conversation is used alone or in connection to other conversational facilities such as video and voice, to form multimedia conversation services. This RTP payload description contains an optional possibility to include redundant text from already transmitted packets in order to reduce the risk of text loss caused by packet loss. The redundancy coding follows RFC 2198.
RFC 2794	Mobile IP Network Access Identifier Extension for IPv4
	Authors: P. Calhoun, C. Perkins. Date: March 2000 Formats: txt pdf Updates: RFC 2290 Status: PROPOSED STANDARD AAA servers are in use within the Internet today to provide authentication and authorization services for dial-up computers.Such services are likely to be equally valuable for mobile nodes using Mobile IP when the nodes are attempting to connect to foreign domains with AAA servers. AAA servers today identify clients by using the Network Access Identifier (NAI). Our proposal defines a way for the mobile node to identify itself, by including the NAI along with the Mobile IP Registration Request. This memo also updates RFC2290 which specifies the Mobile-IPv4 Configuration option for IPCP, by allowing the Mobile Node's Home Address field of this option to be zero.
RFC 2796	BGP Route Reflection - An Alternative to Full Mesh IBGP
	Authors: T. Bates, R. Chandra, E. Chen. Date: April 2000 Formats: txt pdf Obsoleted by: RFC 4456 Updates: RFC 1966 Status: PROPOSED STANDARD The Border Gateway Protocol [1] is an inter-autonomous system routing protocol designed for TCP/IP internets. Currently in the Internet 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 thatAS. 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 2797	Certificate Management Messages over CMS
	Authors: M. Myers, X. Liu, J. Schaad, J. Weinstein. Date: April 2000 Formats: txt pdf Obsoleted by: RFC 5272 Status: PROPOSED STANDARD This document defines a Certificate Management protocol using CMS(CMC). This protocol addresses two immediate needs within theInternet PKI community: 1. The need for an interface to public key certification products and services based on [CMS] and [PKCS10], and2. The need in [SMIMEV3] for a certificate enrollment protocol forDSA-signed certificates with Diffie-Hellman public keys. A small number of additional services are defined to supplement the core certificate request service. Throughout this specification the term CMS is used to refer to both[CMS] and [PKCS7]. For both signedData and envelopedData, CMS is a superset of the PKCS7. In general, the use of PKCS7 in this document is aligned to the Cryptographic Message Syntax [CMS] that provides a superset of the PKCS7 syntax. The term CMC refers to this specification.
RFC 2806	URLs for Telephone Calls
	Authors: A. Vaha-Sipila. Date: April 2000 Formats: txt pdf Obsoleted by: RFC 3966 Status: PROPOSED STANDARD This document specifies URL (Uniform Resource Locator) schemes "tel","fax" and "modem" for specifying the location of a terminal in the phone network and the connection types (modes of operation) that can be used to connect to that entity. This specification covers voice calls (normal phone calls, answering machines and voice messaging systems), facsimile (telefax) calls and data calls, both for POTS and digital/mobile subscribers.
RFC 2814	SBM (Subnet Bandwidth Manager): A Protocol for RSVP-based Admission Control over IEEE 802-style networks
	Authors: R. Yavatkar, D. Hoffman, Y. Bernet, F. Baker, M. Speer. Date: May 2000 Formats: txt pdf Status: PROPOSED STANDARD This document describes a signaling method and protocol for RSVP- based admission control over IEEE 802-style LANs. The protocol is designed to work both with the current generation of IEEE 802 LANs as well as with the recent work completed by the IEEE 802.1 committee.
RFC 2815	Integrated Service Mappings on IEEE 802 Networks
	Authors: M. Seaman, A. Smith, E. Crawley, J. Wroclawski. Date: May 2000 Formats: txt pdf Status: PROPOSED STANDARD This document describes mappings of IETF Integrated Services overLANs built from IEEE 802 network segments which may be interconnected by IEEE 802.1D MAC Bridges (switches). It describes parameter mappings for supporting Controlled Load and Guaranteed Service using the inherent capabilities of relevant IEEE 802 technologies and, in particular, 802.1D-1998 queuing features in switches. These mappings are one component of the Integrated Services over IEEE802 LANs framework.
RFC 2817	Upgrading to TLS Within HTTP/1.1
	Authors: R. Khare, S. Lawrence. Date: May 2000 Formats: txt pdf Updates: RFC 2616 Status: PROPOSED STANDARD This memo explains how to use the Upgrade mechanism in HTTP/1.1 to initiate Transport Layer Security (TLS) over an existing TCP connection. This allows unsecured and secured HTTP traffic to share the same well known port (in this case, http: at 80 rather than https: at 443). It also enables "virtual hosting", so a single HTTP +TLS server can disambiguate traffic intended for several hostnames at a single IP address. Since HTTP/1.1 [1] defines Upgrade as a hop-by-hop mechanism, this memo also documents the HTTP CONNECT method for establishing end-to- end tunnels across HTTP proxies. Finally, this memo establishes newIANA registries for public HTTP status codes, as well as public or private Upgrade product tokens. This memo does NOT affect the current definition of the 'https' URI scheme, which already defines a separate namespace(http://example.org/ and https://example.org/ are not equivalent).
RFC 2821	Simple Mail Transfer Protocol
	Authors: J. Klensin, Ed.. Date: April 2001 Formats: txt pdf Obsoletes: RFC 0821, RFC 0974, RFC 1869, STD 0010 Obsoleted by: RFC 5321 Updated by: RFC 5336 Status: PROPOSED STANDARD This document is a self-contained specification of the basic protocol for the Internet electronic mail transport. It consolidates, updates and clarifies, but doesn't add new or change existing functionality of the following: - the original SMTP (Simple Mail Transfer Protocol) specification ofRFC 821 [30], - domain name system requirements and implications for mail transport from RFC 1035 [22] and RFC 974 [27], - the clarifications and applicability statements in RFC 1123 [2], and - material drawn from the SMTP Extension mechanisms [19]. It obsoletes RFC 821, RFC 974, and updates RFC 1123 (replaces the mail transport materials of RFC 1123). However, RFC 821 specifies some features that were not in significant use in the Internet by the mid-1990s and (in appendices) some additional transport models.Those sections are omitted here in the interest of clarity and brevity; readers needing them should refer to RFC 821. It also includes some additional material from RFC 1123 that required amplification. This material has been identified in multiple ways, mostly by tracking flaming on various lists and newsgroups and problems of unusual readings or interpretations that have appeared as the SMTP extensions have been deployed. Where this specification moves beyond consolidation and actually differs from earlier documents, it supersedes them technically as well as textually. Although SMTP was designed as a mail transport and delivery protocol, this specification also contains information that is important to its use as a 'mail submission' protocol, as recommended for POP [3, 26] and IMAP [6]. Additional submission issues are discussed in RFC 2476[15]. Section 2.3 provides definitions of terms specific to this document.Except when the historical terminology is necessary for clarity, this document uses the current 'client' and 'server' terminology to identify the sending and receiving SMTP processes, respectively. A companion document [32] discusses message headers, message bodies and formats and structures for them, and their relationship.
RFC 2822	Internet Message Format
	Authors: P. Resnick, Ed.. Date: April 2001 Formats: txt pdf Obsoletes: RFC 0822 Obsoleted by: RFC 5322 Updated by: RFC 5335, RFC 5336 Status: PROPOSED STANDARD This standard specifies a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This standard supersedes the one specified in Request ForComments (RFC) 822, "Standard for the Format of ARPA Internet TextMessages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs.
RFC 2829	Authentication Methods for LDAP
	Authors: M. Wahl, H. Alvestrand, J. Hodges, R. Morgan. Date: May 2000 Formats: txt pdf Obsoleted by: RFC 4513, RFC 4510 Updated by: RFC 3377 Status: PROPOSED STANDARD This document specifies particular combinations of security mechanisms which are required and recommended in LDAP [1] implementations.
RFC 2830	Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security
	Authors: J. Hodges, R. Morgan, M. Wahl. Date: May 2000 Formats: txt pdf Obsoleted by: RFC 4511, RFC 4513, RFC 4510 Updated by: RFC 3377 Status: PROPOSED STANDARD This document defines the "Start Transport Layer Security (TLS)Operation" for LDAP [LDAPv3, TLS]. This operation provides for TLS establishment in an LDAP association and is defined in terms of anLDAP extended request.
RFC 2833	RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals
	Authors: H. Schulzrinne, S. Petrack. Date: May 2000 Formats: txt pdf Obsoleted by: RFC 4733, RFC 4734 Status: PROPOSED STANDARD This memo describes how to carry dual-tone multifrequency (DTMF) signaling, other tone signals and telephony events in RTP packets.
RFC 2834	ARP and IP Broadcast over HIPPI-800
	Authors: J.-M. Pittet. Date: May 2000 Formats: txt pdf Obsoletes: RFC 1374 Updated by: RFC 5494 Status: PROPOSED STANDARD This document specifies a method for resolving IP addresses to ANSIHigh-Performance Parallel Interface (HIPPI) hardware addresses and for emulating IP broadcast in a logical IP subnet (LIS) as a direct extension of HARP. This memo defines a HARP that will interoperate between HIPPI-800 and HIPPI-6400 (also known as Gigabyte SystemNetwork, GSN). This document (when combined with RFC-2067 "IP overHIPPI") obsoletes RFC-1374.
RFC 2835	IP and ARP over HIPPI-6400 (GSN)
	Authors: J.-M. Pittet. Date: May 2000 Formats: txt pdf Updated by: RFC 5494 Status: PROPOSED STANDARD The ANSI T11.1 task force has standardized HIPPI-6400 also known asGigabyte System Network (GSN), a physical-level, point-to-point, full-duplex, link interface for reliable, flow-controlled, transmission of user data at 6400 Mbit/s, per direction. A parallel copper cable interface for distances of up to 40 m is specified inHIPPI-6400-PH [1]. Connections to a longer-distance optical interface are standardized in HIPPI-6400-OPT [3]. HIPPI-6400-PH [1] defines the encapsulation of IEEE 802.2 LLC PDUs[10] and by implication, IP on GSN. Another T11.1 standard describes the operation of HIPPI-6400 physical switches HIPPI-6400-SC [2].T11.1 chose to leave HIPPI-6400 networking issues largely outside the scope of their standards; this document specifies the use of HIPPI-6400 switches as IP local area networks. This document further specifies a method for resolving IP addresses to HIPPI-6400 hardware addresses (HARP) and for emulating IP broadcast in a logical IP subnet (LIS) as a direct extension of HARP. Furthermore it is the goal of this memo to define a IP and HARP that will allow interoperability for HIPPI-800 and HIPPI-6400 equipment both broadcast and non-broadcast capable networks.
RFC 2836	Per Hop Behavior Identification Codes
	Authors: S. Brim, B. Carpenter, F. Le Faucheur. Date: May 2000 Formats: txt pdf Obsoleted by: RFC 3140 Status: PROPOSED STANDARD This document defines a binary encoding to uniquely identify PHBs (Per Hop Behaviors) and/or sets of PHBs in protocol messages. [STANDARDS TRACK]
RFC 2837	Definitions of Managed Objects for the Fabric Element in Fibre Channel Standard
	Authors: K. Teow. Date: May 2000 Formats: txt pdf Obsoleted by: RFC 4044 Status: PROPOSED STANDARD This memo defines an extension to the Management Information Base(MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines the objects for managing the operations of the Fabric Element portion of the Fibre ChannelStandards.
RFC 2842	Capabilities Advertisement with BGP-4
	Authors: R. Chandra, J. Scudder. Date: May 2000 Formats: txt pdf Obsoleted by: RFC 3392 Status: PROPOSED STANDARD Currently BGP-4 [BGP-4] requires that when a BGP speaker receives anOPEN message with one or more unrecognized Optional Parameters, the speaker must terminate BGP peering. This complicates introduction of new capabilities in BGP. This document defines new Optional Parameter, called Capabilities, that is expected to facilitate introduction of new capabilities inBGP by providing graceful capability advertisement without requiring that BGP peering be terminated.
RFC 2845	Secret Key Transaction Authentication for DNS (TSIG)
	Authors: P. Vixie, O. Gudmundsson, D. Eastlake 3rd, B. Wellington. Date: May 2000 Formats: txt pdf Updates: RFC 1035 Updated by: RFC 3645, RFC 4635 Status: PROPOSED STANDARD This protocol allows for transaction level authentication using shared secrets and one way hashing. It can be used to authenticate dynamic updates as coming from an approved client, or to authenticate responses as coming from an approved recursive name server. No provision has been made here for distributing the shared secrets; it is expected that a network administrator will statically configure name servers and clients using some out of band mechanism such as sneaker-net until a secure automated mechanism for key distribution is available.
RFC 2846	GSTN Address Element Extensions in E-mail Services
	Authors: C. Allocchio. Date: June 2000 Formats: txt pdf Updated by: RFC 3191, RFC 3192 Status: PROPOSED STANDARD There are numerous applications where there is a need for interaction between the GSTN addressing and Internet addressing. This memo defines a full syntax for one specific case, where there is a need to represent GSTN addresses within Internet e-mail addresses. This full syntax is a superset of a minimal syntax which has been defined in[1].
RFC 2847	LIPKEY - A Low Infrastructure Public Key Mechanism Using SPKM
	Authors: M. Eisler. Date: June 2000 Formats: txt pdf Status: PROPOSED STANDARD This memorandum describes a method whereby one can use GSS-API[RFC2078] to supply a secure channel between a client and server, authenticating the client with a password, and a server with a public key certificate. As such, it is analogous to the common low infrastructure usage of the Transport Layer Security (TLS) protocol[RFC2246]. The method leverages the existing Simple Public Key Mechanism (SPKM)[RFC2025], and is specified as a separate GSS-API mechanism (LIPKEY) layered above SPKM.
RFC 2848	The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services
	Authors: S. Petrack, L. Conroy. Date: June 2000 Formats: txt pdf Status: PROPOSED STANDARD This document contains the specification of the PINT Service Protocol1.0, which defines a protocol for invoking certain telephone services from an IP network. These services include placing basic calls, sending and receiving faxes, and receiving content over the telephone. The protocol is specified as a set of enhancements and additions to the SIP 2.0 and SDP protocols.
RFC 2849	The LDAP Data Interchange Format (LDIF) - Technical Specification
	Authors: G. Good. Date: June 2000 Formats: txt pdf Status: PROPOSED STANDARD This document describes a file format suitable for describing directory information or modifications made to directory information.The file format, known as LDIF, for LDAP Data Interchange Format, is typically used to import and export directory information betweenLDAP-based directory servers, or to describe a set of changes which are to be applied to a directory.
RFC 2851	Textual Conventions for Internet Network Addresses
	Authors: M. Daniele, B. Haberman, S. Routhier, J. Schoenwaelder. Date: June 2000 Formats: txt pdf Obsoleted by: RFC 3291 Status: PROPOSED STANDARD This MIB module defines textual conventions to represent commonly used Internet network layer addressing information. The intent is that these definitions will be imported and used in MIBs that would otherwise define their own representations. This work is output from the Operations and Management Area "IPv6MIB" design team.
RFC 2852	Deliver By SMTP Service Extension
	Authors: D. Newman. Date: June 2000 Formats: txt pdf Updates: RFC 1894 Status: PROPOSED STANDARD This memo defines a mechanism whereby a SMTP client can request, when transmitting a message to a SMTP server, that the server deliver the message within a prescribed period of time. A client making such a request also specifies the message handling which is to occur if the message cannot be delivered within the specified time period: either the message is to be returned as undeliverable with no further processing, or a "delayed" delivery status notification (DSN) [6] is to be issued. This extension should not be viewed as a vehicle for requesting"priority" processing. A receiving SMTP server may assign whatever processing priority it wishes to a message transmitted with a DeliverBy request. A Deliver By request serves to express a message's urgency and to provide an additional degree of determinancy in its processing. An indication of an urgent message's status within a given time period may be requested and will be honored. Moreover, the message may be withdrawn if not delivered within that time period. A typical usage of this mechanism is to prevent delivery of a message beyond some future time of significance to the sender or recipient but not known by the MTAs handling the message. For instance, the sender may know that the message will be delivered as a page but does not consider the message to be sufficiently important as to warrant paging the recipient after business hours. In that case, the message could be marked such that delivery attempts are not made beyond 17:00. Another common usage arises when a sender wishes to be alerted to delivery delays. In this case, the sender can mark a message such that if it is not delivered within, say, 30 minutes, a"delayed" DSN is generated but delivery attempts are nonetheless continued. In this case the sender has been allowed to express a preference for when they would like to learn of delivery problems.
RFC 2853	Generic Security Service API Version 2 : Java Bindings
	Authors: J. Kabat, M. Upadhyay. Date: June 2000 Formats: txt pdf Obsoleted by: RFC 5653 Status: PROPOSED STANDARD The Generic Security Services Application Program Interface (GSS-API) offers application programmers uniform access to security services atop a variety of underlying cryptographic mechanisms. This document specifies the Java bindings for GSS-API which is described at a language independent conceptual level in RFC 2743 [GSSAPIv2-UPDATE]. The GSS-API allows a caller application to authenticate a principal identity, to delegate rights to a peer, and to apply security services such as confidentiality and integrity on a per-message basis. Examples of security mechanisms defined for GSS-API are TheSimple Public-Key GSS-API Mechanism [SPKM] and The Kerberos Version 5GSS-API Mechanism [KERBV5].
RFC 2855	DHCP for IEEE 1394
	Authors: K. Fujisawa. Date: June 2000 Formats: txt pdf Status: PROPOSED STANDARD IEEE Std 1394-1995 is a standard for a High Performance Serial Bus.Since 1394 uses a different link-layer addressing method than conventional IEEE802/Ethernet, the usage of some fields must be clarified to achieve interoperability. This memo describes the 1394 specific usage of some fields of DHCP messages.
RFC 2856	Textual Conventions for Additional High Capacity Data Types
	Authors: A. Bierman, K. McCloghrie, R. Presuhn. Date: June 2000 Formats: txt pdf Status: PROPOSED STANDARD This memo specifies new textual conventions for additional high capacity data types, intended for SNMP implementations which already support the Counter64 data type. The definitions contained in this document represent a short term solution which may be deprecated in the future.
RFC 2857	The Use of HMAC-RIPEMD-160-96 within ESP and AH
	Authors: A. Keromytis, N. Provos. Date: June 2000 Formats: txt pdf Status: PROPOSED STANDARD This memo describes the use of the HMAC algorithm [RFC 2104] in conjunction with the RIPEMD-160 algorithm [RIPEMD-160] as an authentication mechanism within the revised IPSEC EncapsulatingSecurity Payload [ESP] and the revised IPSEC Authentication Header[AH]. HMAC with RIPEMD-160 provides data origin authentication and integrity protection. Further information on the other components necessary for ESP and AH implementations is provided by [Thayer97a].
RFC 2858	Multiprotocol Extensions for BGP-4
	Authors: T. Bates, Y. Rekhter, R. Chandra, D. Katz. Date: June 2000 Formats: txt pdf Obsoletes: RFC 2283 Obsoleted by: RFC 4760 Status: PROPOSED STANDARD Currently BGP-4 [BGP-4] is capable of carrying routing information only for IPv4 [IPv4]. This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, etc...). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions. This document obsoletes RFC 2283.
RFC 2862	RTP Payload Format for Real-Time Pointers
	Authors: M. Civanlar, G. Cash. Date: June 2000 Formats: txt pdf Status: PROPOSED STANDARD This document describes an RTP [1] payload format for transporting the coordinates of a dynamic pointer that may be used during a presentation. Although a mouse can be used as the pointer, this payload format is not intended and may not have all functionalities needed to implement a general mouse event transmission mechanism.
RFC 2864	The Inverted Stack Table Extension to the Interfaces Group MIB
	Authors: K. McCloghrie, G. Hanson. Date: June 2000 Formats: txt pdf Status: PROPOSED STANDARD 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 which provide an inverted mapping of the interface stack table used for managing network interfaces. [STANDARDS TRACK]
RFC 2872	Application and Sub Application Identity Policy Element for Use with RSVP
	Authors: Y. Bernet, R. Pabbati. Date: June 2000 Formats: txt pdf Status: PROPOSED STANDARD RSVP [RFC 2205] signaling messages typically include policy data objects, which in turn contain policy elements. Policy elements may describe user and/or application information, which may be used byRSVP aware network elements to apply appropriate policy decisions to a traffic flow. This memo details the usage of policy elements that provide application information.
RFC 2873	TCP Processing of the IPv4 Precedence Field
	Authors: X. Xiao, A. Hannan, V. Paxson, E. Crabbe. Date: June 2000 Formats: txt pdf Status: PROPOSED STANDARD This memo describes a conflict between TCP [RFC793] and DiffServ[RFC2475] on the use of the three leftmost bits in the TOS octet of an IPv4 header [RFC791]. In a network that contains DiffServ-capable nodes, such a conflict can cause failures in establishing TCP connections or can cause some established TCP connections to be reset undesirably. This memo proposes a modification to TCP for resolving the conflict. Because the IPv6 [RFC2460] traffic class octet does not have any defined meaning except what is defined in RFC 2474, and in particular does not define precedence or security parameter bits, there is no conflict between TCP and DiffServ on the use of any bits in the IPv6 traffic class octet.
RFC 2875	Diffie-Hellman Proof-of-Possession Algorithms
	Authors: H. Prafullchandra, J. Schaad. Date: July 2000 Formats: txt pdf Status: PROPOSED STANDARD This document describes two methods for producing an integrity check value from a Diffie-Hellman key pair. This behavior is needed for such operations as creating the signature of a PKCS #10 certification request. These algorithms are designed to provide a proof-of- possession rather than general purpose signing.
RFC 2878	PPP Bridging Control Protocol (BCP)
	Authors: M. Higashiyama, F. Baker. Date: July 2000 Formats: txt pdf Obsoletes: RFC 1638 Obsoleted by: RFC 3518 Status: PROPOSED STANDARD The Point-to-Point Protocol (PPP) [6] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol, and proposes a family ofNetwork Control Protocols for establishing and configuring different network-layer protocols. This document defines the Network Control Protocol for establishing and configuring Remote Bridging for PPP links. This document obsoletes RFC 1638, which was based on the IEEE802.1D-1993 MAC Bridge[3]. This document extends that specification by including the IEEE 802.1D-1998 MAC Bridge[8] and IEEE 802.1QVirtual LAN (VLAN)[9] standards. This document also improves the protocol in order to support high-speed switched LANs.
RFC 2879	Content Feature Schema for Internet Fax (V2)
	Authors: G. Klyne, L. McIntyre. Date: August 2000 Formats: txt pdf Obsoletes: RFC 2531 Status: PROPOSED STANDARD This document defines a content media feature schema for Internet fax. It is a profile of the media feature registration mechanisms [1,2,3] for use in performing capability identification between extendedInternet fax systems [5]. It replaces and updates the feature schema defined in RFC 2531.
RFC 2883	An Extension to the Selective Acknowledgement (SACK) Option for TCP
	Authors: S. Floyd, J. Mahdavi, M. Mathis, M. Podolsky. Date: July 2000 Formats: txt pdf Status: PROPOSED STANDARD This note defines an extension of the Selective Acknowledgement(SACK) Option [RFC2018] for TCP. RFC 2018 specified the use of theSACK option for acknowledging out-of-sequence data not covered byTCP's cumulative acknowledgement field. This note extends RFC 2018 by specifying the use of the SACK option for acknowledging duplicate packets. This note suggests that when duplicate packets are received, the first block of the SACK option field can be used to report the sequence numbers of the packet that triggered the acknowledgement. This extension to the SACK option allows the TCP sender to infer the order of packets received at the receiver, allowing the sender to infer when it has unnecessarily retransmitted a packet. A TCP sender could then use this information for more robust operation in an environment of reordered packets [BPS99], ACK loss, packet replication, and/or early retransmit timeouts.
RFC 2890	Key and Sequence Number Extensions to GRE
	Authors: G. Dommety. Date: September 2000 Formats: txt pdf Updates: RFC 2784 Status: PROPOSED STANDARD GRE (Generic Routing Encapsulation) specifies a protocol for encapsulation of an arbitrary protocol over another arbitrary network layer protocol. This document describes extensions by which two fields, Key and Sequence Number, can be optionally carried in the GREHeader [1].
RFC 2891	LDAP Control Extension for Server Side Sorting of Search Results
	Authors: T. Howes, M. Wahl, A. Anantha. Date: August 2000 Formats: txt pdf Status: PROPOSED STANDARD This document describes two LDAPv3 control extensions for server side sorting of search results. These controls allows a client to specify the attribute types and matching rules a server should use when returning the results to an LDAP search request. The controls may be useful when the LDAP client has limited functionality or for some other reason cannot sort the results but still needs them sorted.Other permissible controls on search operations are not defined in this extension. The sort controls allow a server to return a result code for the sorting of the results that is independent of the result code returned for the search operation. The key words "MUST", "SHOULD", and "MAY" used in this document are to be interpreted as described in [bradner97].
RFC 2893	Transition Mechanisms for IPv6 Hosts and Routers
	Authors: R. Gilligan, E. Nordmark. Date: August 2000 Formats: txt pdf Obsoletes: RFC 1933 Obsoleted by: RFC 4213 Status: PROPOSED STANDARD This document specifies IPv4 compatibility mechanisms that can be implemented by IPv6 hosts and routers. These mechanisms include providing complete implementations of both versions of the InternetProtocol (IPv4 and IPv6), and tunneling IPv6 packets over IPv4 routing infrastructures. They are designed to allow IPv6 nodes to maintain complete compatibility with IPv4, which should greatly simplify the deployment of IPv6 in the Internet, and facilitate the eventual transition of the entire Internet to IPv6. This document obsoletes RFC 1933.
RFC 2894	Router Renumbering for IPv6
	Authors: M. Crawford. Date: August 2000 Formats: txt pdf Status: PROPOSED STANDARD IPv6 Neighbor Discovery and Address Autoconfiguration conveniently make initial assignments of address prefixes to hosts. Aside from the problem of connection survival across a renumbering event, these two mechanisms also simplify the reconfiguration of hosts when the set of valid prefixes changes. This document defines a mechanism called Router Renumbering ("RR") which allows address prefixes on routers to be configured and reconfigured almost as easily as the combination of NeighborDiscovery and Address Autoconfiguration works for hosts. It provides a means for a network manager to make updates to the prefixes used by and advertised by IPv6 routers throughout a site.
RFC 2907	MADCAP Multicast Scope Nesting State Option
	Authors: R. Kermode. Date: September 2000 Formats: txt pdf Status: PROPOSED STANDARD This document defines a new option to the Multicast Address DynamicClient Allocation Protocol (MADCAP) to support nested scoping. The new option's purpose is to allow clients to learn which scopes nest inside each other, and hence it may be used for expanding scope searches or hierarchical multicast transport.
RFC 2910	Internet Printing Protocol/1.1: Encoding and Transport
	Authors: R. Herriot, Ed., S. Butler, P. Moore, R. Turner, J. Wenn. Date: September 2000 Formats: txt pdf Obsoletes: RFC 2565 Updated by: RFC 3380, RFC 3381, RFC 3382, RFC 3510, RFC 3995 Status: PROPOSED STANDARD 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 Hypertext TransferProtocol (HTTP) a message body whose Content-Type is"application/ipp". This document defines a new scheme named 'ipp' for identifying IPP printers and jobs. 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.1: Model and Semantics [RFC2911]Internet Printing Protocol/1.1: Encoding and Transport (this document)Internet Printing Protocol/1.1: 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.1. A few OPTIONAL operator operations have been added to IPP/1.1. 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 specification documents, and gives background and rationale for the IETF working group's major decisions. The document, "Internet Printing Protocol/1.1: 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. The document "Internet Printing Protocol/1.1: 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 2911	Internet Printing Protocol/1.1: Model and Semantics
	Authors: T. Hastings, Ed., R. Herriot, R. deBry, S. Isaacson, P. Powell. Date: September 2000 Formats: txt pdf Obsoletes: RFC 2566 Updated by: RFC 3380, RFC 3382, RFC 3996, RFC 3995 Status: PROPOSED STANDARD 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.1 semantics allow end-users and operators to query printer capabilities, submit print jobs, inquire about the status of print jobs and printers, cancel, hold, release, and restart print jobs. IPP 1.1 semantics allow operators to pause, resume, and purge (jobs from) Printer objects. 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.1: Model and Semantics (this document)Internet Printing Protocol/1.1: Encoding and Transport [RFC2910]Internet Printing Protocol/1.1: 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. A few OPTIONAL operator operations have been added to IPP/1.1. 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 specification documents, and gives background and rationale for the IETF working group's major decisions. The "Internet Printing Protocol/1.1: Encoding and Transport" document is a formal mapping of the abstract operations and attributes defined in the model document onto HTTP/1.1 [RFC2616]. It defines the encoding rules for a new Internet 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". This document defines a new scheme named 'ipp' for identifying IPP printers and jobs. The "Internet Printing Protocol/1.1: 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.1 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 2912	Indicating Media Features for MIME Content
	Authors: G. Klyne. Date: September 2000 Formats: txt pdf Status: PROPOSED STANDARD In "A Syntax for Describing Media Feature Sets", an expression format is presented for describing media feature capabilities using simple media feature tags. This memo defines a Multipurpose Internet Mail Extensions (MIME)'Content-features:' header that can be used to annotate a MIME message part using this expression format, and indicates some ways it might be used.
RFC 2913	MIME Content Types in Media Feature Expressions
	Authors: G. Klyne. Date: September 2000 Formats: txt pdf Status: PROPOSED STANDARD In "A Syntax for Describing Media Feature Sets", an expression format is presented for describing media feature capabilities using simple media feature tags. This memo defines a media feature tag whose value is a MultipurposeInternet Mail Extensions (MIME) content type. This allows the construction of feature expressions that take account of the MIME content type of the corresponding data.
RFC 2915	The Naming Authority Pointer (NAPTR) DNS Resource Record
	Authors: M. Mealling, R. Daniel. Date: September 2000 Formats: txt pdf Obsoleted by: RFC 3401, RFC 3402, RFC 3403, RFC 3404 Updates: RFC 2168 Status: PROPOSED STANDARD This document describes a Domain Name System (DNS) resource record which specifies a regular expression based rewrite rule that, when applied to an existing string, will produce a new domain label orUniform Resource Identifier (URI). Depending on the value of the flags field of the resource record, the resulting domain label or URI may be used in subsequent queries for the Naming Authority Pointer(NAPTR) resource records (to delegate the name lookup) or as the output of the entire process for which this system is used (a resolution server for URI resolution, a service URI for ENUM style e.164 number to URI mapping, etc). This allows the DNS to be used to lookup services for a wide variety of resource names (including URIs) which are not in domain name syntax. Reasons for doing this range from URN Resource DiscoverySystems to moving out-of-date services to new domains. This document updates the portions of RFC 2168 specifically dealing with the definition of the NAPTR records and how other, non-URI specific applications, might use NAPTR.
RFC 2916	E.164 number and DNS
	Authors: P. Faltstrom. Date: September 2000 Formats: txt pdf Obsoleted by: RFC 3761 Status: PROPOSED STANDARD This document discusses the use of the Domain Name System (DNS) for storage of E.164 numbers. More specifically, how DNS can be used for identifying available services connected to one E.164 number.Routing of the actual connection using the service selected using these methods is not discussed.
RFC 2918	Route Refresh Capability for BGP-4
	Authors: E. Chen. Date: September 2000 Formats: txt pdf Status: PROPOSED STANDARD This document defines a new Border Gateway Protocol (BGP) capability termed 'Route Refresh Capability', which would allow the dynamic exchange of route refresh request between BGP speakers and subsequent re-advertisement of the respective Adj-RIB-Out. One possible application of this capability is to facilitate non-disruptive routing policy changes.
RFC 2919	List-Id: A Structured Field and Namespace for the Identification of Mailing Lists
	Authors: R. Chandhok, G. Wenger. Date: March 2001 Formats: txt pdf Status: PROPOSED STANDARD Software that handles electronic mailing list messages (servers and user agents) needs a way to reliably identify messages that belong to a particular mailing list. With the advent of list management headers, it has become even more important to provide a unique identifier for a mailing list regardless of the particular host that serves as the list processor at any given time. The List-Id header provides a standard location for such an identifier. In addition, a namespace for list identifiers based on fully qualified domain names is described. This namespace is intended to guarantee uniqueness for list owners who require it, while allowing for a less rigorous namespace for experimental and personal use. By including the List-Id field, list servers can make it easier for mail clients to provide automated tools for users to perform list functions. The list identifier can serve as a key to make many automated processing tasks easier, and hence more widely available.
RFC 2925	Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations
	Authors: K. White. Date: September 2000 Formats: txt pdf Obsoleted by: RFC 4560 Status: PROPOSED STANDARD This memo defines Management Information Bases (MIBs) for performing remote ping, traceroute and lookup operations at a remote host. When managing a network it is useful to be able to initiate and retrieve the results of ping or traceroute operations when performed at a remote host. A Lookup capability is defined in order to enable resolving of either an IP address to an DNS name or an DNS name to anIP address at a remote host. Currently, there are several enterprise-specific MIBs for performing remote ping or traceroute operations. The purpose of this memo is to define a standards-based solution to enable interoperability.
RFC 2930	Secret Key Establishment for DNS (TKEY RR)
	Authors: D. Eastlake 3rd. Date: September 2000 Formats: txt pdf Status: PROPOSED STANDARD [RFC 2845] provides a means of authenticating Domain Name System(DNS) queries and responses using shared secret keys via theTransaction Signature (TSIG) resource record (RR). However, it provides no mechanism for setting up such keys other than manual exchange. This document describes a Transaction Key (TKEY) RR that can be used in a number of different modes to establish shared secret keys between a DNS resolver and server.
RFC 2931	DNS Request and Transaction Signatures ( SIG(0)s)
	Authors: D. Eastlake 3rd. Date: September 2000 Formats: txt pdf Updates: RFC 2535 Status: PROPOSED STANDARD Extensions to the Domain Name System (DNS) are described in [RFC2535] that can provide data origin and transaction integrity and authentication to security aware resolvers and applications through the use of cryptographic digital signatures. Implementation experience has indicated the need for minor but non- interoperable changes in Request and Transaction signature resource records ( SIG(0)s ). These changes are documented herein.
RFC 2932	IPv4 Multicast Routing MIB
	Authors: K. McCloghrie, D. Farinacci, D. Thaler. Date: October 2000 Formats: txt pdf Obsoleted by: RFC 5132 Status: PROPOSED STANDARD 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 IPMulticast Routing for IPv4, independent of the specific multicast routing protocol in use.
RFC 2933	Internet Group Management Protocol MIB
	Authors: K. McCloghrie, D. Farinacci, D. Thaler. Date: October 2000 Formats: txt pdf Obsoleted by: RFC 5519 Status: PROPOSED STANDARD 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 used for managing the InternetGroup Management Protocol (IGMP).
RFC 2935	Internet Open Trading Protocol (IOTP) HTTP Supplement
	Authors: D. Eastlake 3rd, C. Smith. Date: September 2000 Formats: txt pdf Status: PROPOSED STANDARD Internet Open Trading Protocol (IOTP) messages will be carried asExtensible Markup Language (XML) documents. As such, the goal of mapping to the transport layer is to ensure that the underlying XML documents are carried successfully between the various parties. This document describes that mapping for the Hyper Text TransportProtocol (HTTP), Versions 1.0 and 1.1.
RFC 2937	The Name Service Search Option for DHCP
	Authors: C. Smith. Date: September 2000 Formats: txt pdf Status: PROPOSED STANDARD This document defines a new Dynamic Host Configuration Protocol(DHCP) option which is passed from the DHCP Server to the DHCP Client to specify the order in which name services should be consulted when resolving hostnames and other information.
RFC 2938	Identifying Composite Media Features
	Authors: G. Klyne, L. Masinter. Date: September 2000 Formats: txt pdf Updates: RFC 2533 Status: PROPOSED STANDARD In RFC 2533, an expression format is presented for describing media feature capabilities as a combination of simple media feature tags. This document describes an abbreviated format for a composite media feature set, based upon a hash of the feature expression describing that composite.
RFC 2940	Definitions of Managed Objects for Common Open Policy Service (COPS) Protocol Clients
	Authors: A. Smith, D. Partain, J. Seligson. Date: October 2000 Formats: txt pdf Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets.In particular it defines objects for managing a client of the CommonOpen Policy Service (COPS) protocol. This memo includes a MIB module in a manner that is compliant to theSMIv2 [V2SMI].
RFC 2941	Telnet Authentication Option
	Authors: T. Ts'o, Ed., J. Altman. Date: September 2000 Formats: txt pdf Obsoletes: RFC 1416 Status: PROPOSED STANDARD This document describes the authentication option to the telnet [1] protocol as a generic method for negotiating an authentication type and mode including whether encryption should be used and if credentials should be forwarded. While this document summarizes currently utilized commands and types it does not define a specific authentication type. Separate documents are to be published defining each authentication type. This document updates a previous specification of the telnet authentication option, RFC 1416 [2], so that it can be used to securely enable the telnet encryption option [3].
RFC 2942	Telnet Authentication: Kerberos Version 5
	Authors: T. Ts'o. Date: September 2000 Formats: txt pdf Status: PROPOSED STANDARD This document describes how Kerberos Version 5 [1] is used with the telnet protocol. It describes an telnet authentication suboption to be used with the telnet authentication option [2]. This mechanism can also used to provide keying material to provide data confidentiality services in conjunction with the telnet encryption option [3].
RFC 2943	TELNET Authentication Using DSA
	Authors: R. Housley, T. Horting, P. Yee. Date: September 2000 Formats: txt pdf Status: PROPOSED STANDARD This document defines a telnet authentication mechanism using theDigital Signature Algorithm (DSA) [FIPS186]. It relies on the TelnetAuthentication Option [RFC2941].
RFC 2944	Telnet Authentication: SRP
	Authors: T. Wu. Date: September 2000 Formats: txt pdf Status: PROPOSED STANDARD This document specifies an authentication scheme for the Telnet protocol under the framework described in [RFC2941], using the SecureRemote Password Protocol (SRP) authentication mechanism. The specific mechanism, SRP-SHA1, is described in [RFC2945].
RFC 2945	The SRP Authentication and Key Exchange System
	Authors: T. Wu. Date: September 2000 Formats: txt pdf Status: PROPOSED STANDARD This document describes a cryptographically strong network authentication mechanism known as the Secure Remote Password (SRP) protocol. This mechanism is suitable for negotiating secure connections using a user-supplied password, while eliminating the security problems traditionally associated with reusable passwords.This system also performs a secure key exchange in the process of authentication, allowing security layers (privacy and/or integrity protection) to be enabled during the session. Trusted key servers and certificate infrastructures are not required, and clients are not required to store or manage any long-term keys. SRP offers both security and deployment advantages over existing challenge-response techniques, making it an ideal drop-in replacement where secure password authentication is needed.
RFC 2946	Telnet Data Encryption Option
	Authors: T. Ts'o. Date: September 2000 Formats: txt pdf Status: PROPOSED STANDARD This document describes a the telnet encryption option as a generic method of providing data confidentiality services for the telnet data stream. While this document summarizes currently utilized encryption types and codes, it does not define a specific encryption algorithm.Separate documents are to be published defining implementations of this option for each encryption algorithm.
RFC 2947	Telnet Encryption: DES3 64 bit Cipher Feedback
	Authors: J. Altman. Date: September 2000 Formats: txt pdf Status: PROPOSED STANDARD This document specifies how to use the Triple-DES (data encryption standard) encryption algorithm in cipher feedback mode with the telnet encryption option.
RFC 2948	Telnet Encryption: DES3 64 bit Output Feedback
	Authors: J. Altman. Date: September 2000 Formats: txt pdf Status: PROPOSED STANDARD This document specifies how to use the Triple-DES (data encryption standard) encryption algorithm in output feedback mode with the telnet encryption option.
RFC 2949	Telnet Encryption: CAST-128 64 bit Output Feedback
	Authors: J. Altman. Date: September 2000 Formats: txt pdf Status: PROPOSED STANDARD This document specifies how to use the CAST-128 encryption algorithm in output feedback mode with the telnet encryption option. Two key sizes are defined: 40 bit and 128 bit.
RFC 2950	Telnet Encryption: CAST-128 64 bit Cipher Feedback
	Authors: J. Altman. Date: September 2000 Formats: txt pdf Status: PROPOSED STANDARD This document specifies how to use the CAST-128 encryption algorithm in cipher feedback mode with the telnet encryption option. Two key sizes are defined: 40 bit and 128 bit.
RFC 2954	Definitions of Managed Objects for Frame Relay Service
	Authors: K. Rehbehn, D. Fowler. Date: October 2000 Formats: txt pdf Obsoletes: RFC 1604 Status: PROPOSED STANDARD This memo defines an extension to the Management Information Base(MIB) for use with network management protocols in TransmissionControl Protocol/Internet Protocol-based (TCP/IP) internets. In particular, it defines objects for managing the frame relay service. This document obsoletes RFC 1604.
RFC 2955	Definitions of Managed Objects for Monitoring and Controlling the Frame Relay/ATM PVC Service Interworking Function
	Authors: K. Rehbehn, O. Nicklass, G. Mouradian. Date: October 2000 Formats: txt pdf Status: PROPOSED STANDARD This memo defines a Management Information Base (MIB) to configure, monitor, and control a service interworking function (IWF) forPermanent Virtual Connections (PVC) between Frame Relay andAsynchronous Transfer Mode (ATM) technologies.
RFC 2959	Real-Time Transport Protocol Management Information Base
	Authors: M. Baugher, B. Strahm, I. Suconick. Date: October 2000 Formats: txt pdf Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it defines objects for managing Real-Time TransportProtocol (RTP) systems (RFC1889).
RFC 2960	Stream Control Transmission Protocol
	Authors: R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, V. Paxson. Date: October 2000 Formats: txt pdf Obsoleted by: RFC 4960 Updated by: RFC 3309 Status: PROPOSED STANDARD This document describes the Stream Control Transmission Protocol(SCTP). SCTP is designed to transport PSTN signaling messages overIP networks, but is capable of broader applications. SCTP is a reliable transport protocol operating on top of a connectionless packet network such as IP. It offers the following services to its users: -- acknowledged error-free non-duplicated transfer of user data,-- data fragmentation to conform to discovered path MTU size, -- sequenced delivery of user messages within multiple streams, with an option for order-of-arrival delivery of individual user messages,-- optional bundling of multiple user messages into a single SCTP packet, and-- network-level fault tolerance through supporting of multi- homing at either or both ends of an association. The design of SCTP includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks.
RFC 2961	RSVP Refresh Overhead Reduction Extensions
	Authors: L. Berger, D. Gan, G. Swallow, P. Pan, F. Tommasi, S. Molendini. Date: April 2001 Formats: txt pdf Updated by: RFC 5063 Status: PROPOSED STANDARD This document describes a number of mechanisms that can be used to reduce processing overhead requirements of refresh messages, eliminate the state synchronization latency incurred when an RSVP(Resource ReserVation Protocol) message is lost and, when desired, refreshing state without the transmission of whole refresh messages.The same extensions also support reliable RSVP message delivery on a per hop basis. These extension present no backwards compatibility issues.
RFC 2971	IMAP4 ID extension
	Authors: T. Showalter. Date: October 2000 Formats: txt pdf Status: PROPOSED STANDARD The ID extension to the Internet Message Access Protocol - Version4rev1 (IMAP4rev1) protocol allows the server and client to exchange identification information on their implementation in order to make bug reports and usage statistics more complete.
RFC 2976	The SIP INFO Method
	Authors: S. Donovan. Date: October 2000 Formats: txt pdf Obsoleted by: RFC 6086 Status: PROPOSED STANDARD This document proposes an extension to the Session InitiationProtocol (SIP). This extension adds the INFO method to the SIP protocol. The intent of the INFO method is to allow for the carrying of session related control information that is generated during a session. One example of such session control information is ISUP andISDN signaling messages used to control telephony call services. This and other example uses of the INFO method may be standardized in the future.
RFC 2981	Event MIB
	Authors: R. Kavasseri, Ed.. Date: October 2000 Formats: txt pdf Status: PROPOSED STANDARD 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 that can be used to manage and monitor MIB objects and take action through events. The Event MIB provides the ability to monitor MIB objects on the local system or on a remote system and take simple action when a trigger condition is met.
RFC 2982	Distributed Management Expression MIB
	Authors: R. Kavasseri, Ed.. Date: October 2000 Formats: txt pdf Status: PROPOSED STANDARD 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 expressions of MIB objects. The results of these expressions becomeMIB objects usable like any other MIB object, such as for the test condition for declaring an event.
RFC 2984	Use of the CAST-128 Encryption Algorithm in CMS
	Authors: C. Adams. Date: October 2000 Formats: txt pdf Status: PROPOSED STANDARD This document specifies how to incorporate CAST-128 (RFC2144) into the S/MIME Cryptographic Message Syntax (CMS) as an additional algorithm for symmetric encryption. The relevant OIDs and processing steps are provided so that CAST-128 may be included in the CMS specification (RFC2630) for symmetric content and key encryption.
RFC 2987	Registration of Charset and Languages Media Features Tags
	Authors: P. Hoffman. Date: November 2000 Formats: txt pdf Status: PROPOSED STANDARD This document contains the registration for two media feature tags:"charset" and "language". These media features allow specification of character sets and human languages that can be understood by devices and the devices' users. The templates in this document are derived from RFC 2506.
RFC 2988	Computing TCP's Retransmission Timer
	Authors: V. Paxson, M. Allman. Date: November 2000 Formats: txt pdf Obsoleted by: RFC 6298 Status: PROPOSED STANDARD This document defines the standard algorithm that TransmissionControl Protocol (TCP) senders are required to use to compute and manage their retransmission timer. It expands on the discussion in section 4.2.3.1 of RFC 1122 and upgrades the requirement of supporting the algorithm from a SHOULD to a MUST.
RFC 2996	Format of the RSVP DCLASS Object
	Authors: Y. Bernet. Date: November 2000 Formats: txt pdf Status: PROPOSED STANDARD Resource Reservation Protocol (RSVP) signaling may be used to requestQuality of Service (QoS) services and enhance the manageability of application traffic's QoS in a differentiated service (diff-serv orDS) network. When using RSVP with DS networks it is useful to be able to carry carry Differentiated Services Code Points (DSCPs) inRSVP message objects. One example of this is the use of RSVP to arrange for the marking of packets with a particular DSCP upstream from the DS network's ingress point, at the sender or at a previous network's egress router. The DCLASS object is used to represent and carry DSCPs within RSVP messages. This document specifies the format of the DCLASS object and briefly discusses its use.
RFC 2997	Specification of the Null Service Type
	Authors: Y. Bernet, A. Smith, B. Davie. Date: November 2000 Formats: txt pdf Status: PROPOSED STANDARD In the typical Resource Reservation Protocol (RSVP)/Intserv model, applications request a specific Intserv service type and quantify the resources required for that service. For certain applications, the determination of service parameters is best left to the discretion of the network administrator. For example, ERP applications are often mission critical and require some form of prioritized service, but cannot readily specify their resource requirements. To serve such applications, we introduce the notion of the 'Null Service'. TheNull Service allows applications to identify themselves to networkQuality of Service (QoS) policy agents, using RSVP signaling.However, it does not require them to specify resource requirements.QoS policy agents in the network respond by applying QoS policies appropriate for the application (as determined by the network administrator). This mode of RSVP usage is particularly applicable to networks that combine differentiated service (diffserv) QoS mechanisms with RSVP signaling [intdiff]. In this environment, QoS policy agents may direct the signaled application's traffic to a particular diffserv class of service.
RFC 3003	The audio/mpeg Media Type
	Authors: M. Nilsson. Date: November 2000 Formats: txt pdf Status: PROPOSED STANDARD The audio layers of the MPEG-1 and MPEG-2 standards are in frequent use on the internet, but there is no uniform Multipurpose InternetMail Extension (MIME) type for these files. The intention of this document is to define the media type audio/mpeg to refer to this kind of contents.
RFC 3004	The User Class Option for DHCP
	Authors: G. Stump, R. Droms, Y. Gu, R. Vyaghrapuri, A. Demirtjis, B. Beser, J. Privat. Date: November 2000 Formats: txt pdf Status: PROPOSED STANDARD This option is used by a Dynamic Host Configuration Protocol (DHCP) client to optionally identify the type or category of user or applications it represents. The information contained in this option is an opaque field that represents the user class of which the client is a member. Based on this class, a DHCP server selects the appropriate address pool to assign an address to the client and the appropriate configuration parameters. This option should be configurable by a user.
RFC 3006	Integrated Services in the Presence of Compressible Flows
	Authors: B. Davie, C. Iturralde, D. Oran, S. Casner, J. Wroclawski. Date: November 2000 Formats: txt pdf Status: PROPOSED STANDARD An Integrated Services (int-serv) router performs admission control and resource allocation based on the information contained in a TSpec(among other things). As currently defined, TSpecs convey information about the data rate (using a token bucket) and range of packet sizes of the flow in question. However, the TSpec may not be an accurate representation of the resources needed to support the reservation if the router is able to compress the data at the link level. This specification describes an extension to the TSpec which enables a sender of potentially compressible data to provide hints to int-serv routers about the compressibility they may obtain. Routers which support appropriate compression take advantage of the hint in their admission control decisions and resource allocation procedures; other routers ignore the hint. An initial application of this approach is to notify routers performing real-time transport protocol(RTP) header compression that they may allocate fewer resources toRTP flows.
RFC 3007	Secure Domain Name System (DNS) Dynamic Update
	Authors: B. Wellington. Date: November 2000 Formats: txt pdf Obsoletes: RFC 2137 Updates: RFC 2535, RFC 2136 Status: PROPOSED STANDARD This document proposes a method for performing secure Domain NameSystem (DNS) dynamic updates. The method described here is intended to be flexible and useful while requiring as few changes to the protocol as possible. The authentication of the dynamic update message is separate from later DNSSEC validation of the data. Secure communication based on authenticated requests and transactions is used to provide authorization.
RFC 3008	Domain Name System Security (DNSSEC) Signing Authority
	Authors: B. Wellington. Date: November 2000 Formats: txt pdf Obsoleted by: RFC 4035, RFC 4033, RFC 4034 Updates: RFC 2535 Updated by: RFC 3658 Status: PROPOSED STANDARD This document proposes a revised model of Domain Name System Security(DNSSEC) Signing Authority. The revised model is designed to clarify earlier documents and add additional restrictions to simplify the secure resolution process. Specifically, this affects the authorization of keys to sign sets of records.
RFC 3009	Registration of parityfec MIME types
	Authors: J. Rosenberg, H. Schulzrinne. Date: November 2000 Formats: txt pdf Obsoleted by: RFC 5109 Status: PROPOSED STANDARD The RTP (Real-time Transport Protocol) payload format for generic forward error correction allows RTP participants to improve loss resiliency through the use of traditional parity-based channel codes.This payload format requires four new MIME types, audio/parityfec, video/parityfec, text/parityfec and application/parityfec. This document serves as the MIME type registration for those formats.
RFC 3010	NFS version 4 Protocol
	Authors: S. Shepler, B. Callaghan, D. Robinson, R. Thurlow, C. Beame, M. Eisler, D. Noveck. Date: December 2000 Formats: txt pdf Obsoleted by: RFC 3530 Status: PROPOSED STANDARD NFS (Network File System) version 4 is a distributed file system protocol which owes heritage to NFS protocol versions 2 [RFC1094] and3 [RFC1813]. Unlike earlier versions, the NFS version 4 protocol supports traditional file access while integrating support for file locking and the mount protocol. In addition, support for strong security (and its negotiation), compound operations, client caching, and internationalization have been added. Of course, attention has been applied to making NFS version 4 operate well in an Internet environment.
RFC 3011	The IPv4 Subnet Selection Option for DHCP
	Authors: G. Waters. Date: November 2000 Formats: txt pdf Status: PROPOSED STANDARD This memo defines a new Dynamic Host Configuration Protocol (DHCP) option for selecting the subnet on which to allocate an address.This option would override a DHCP server's normal methods of selecting the subnet on which to allocate an address for a client.
RFC 3012	Mobile IPv4 Challenge/Response Extensions
	Authors: C. Perkins, P. Calhoun. Date: November 2000 Formats: txt pdf Obsoleted by: RFC 4721 Status: PROPOSED STANDARD Mobile IP, as originally specified, defines an authentication extension (the Mobile-Foreign Authentication extension) by which a mobile node can authenticate itself to a foreign agent.Unfortunately, this extension does not provide ironclad replay protection for the foreign agent, and does not allow for the use of existing techniques (such as CHAP) for authenticating portable computer devices. In this specification, we define extensions for the Mobile IP Agent Advertisements and the Registration Request that allow a foreign agent to use a challenge/response mechanism to authenticate the mobile node.
RFC 3014	Notification Log MIB
	Authors: R. Kavasseri. Date: November 2000 Formats: txt pdf Status: PROPOSED STANDARD 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 logging SimpleNetwork Management Protocol (SNMP) Notifications.
RFC 3015	Megaco Protocol Version 1.0
	Authors: F. Cuervo, N. Greene, A. Rayhan, C. Huitema, B. Rosen, J. Segers. Date: November 2000 Formats: txt pdf Obsoletes: RFC 2885, RFC 2886 Obsoleted by: RFC 3525 Status: PROPOSED STANDARD This document defines the protocol used between elements of a physically decomposed multimedia gateway, i.e. a Media Gateway and aMedia Gateway Controller. The document is common text with ITU-TRecommendation H.248 and is a result of applying the changes in RFC2886 to the text of RFC 2885. The protocol presented in this document meets the requirements for a media gateway control protocol as presented in RFC 2805.
RFC 3016	RTP Payload Format for MPEG-4 Audio/Visual Streams
	Authors: Y. Kikuchi, T. Nomura, S. Fukunaga, Y. Matsui, H. Kimata. Date: November 2000 Formats: txt pdf Obsoleted by: RFC 6416 Status: PROPOSED STANDARD This document describes Real-Time Transport Protocol (RTP) payload formats for carrying each of MPEG-4 Audio and MPEG-4 Visual bitstreams without using MPEG-4 Systems. For the purpose of directly mapping MPEG-4 Audio/Visual bitstreams onto RTP packets, it provides specifications for the use of RTP header fields and also specifies fragmentation rules. It also provides specifications forMultipurpose Internet Mail Extensions (MIME) type registrations and the use of Session Description Protocol (SDP).
RFC 3017	XML DTD for Roaming Access Phone Book
	Authors: M. Riegel, G. Zorn. Date: December 2000 Formats: txt pdf Status: PROPOSED STANDARD This document defines the syntax as well as the semantics of the information to be included in the phone book for roaming applications. It comprises the information necessary to select the most appropriate ISP and to configure the host to get access to the network of the provider. The specification consists of a small set of required information elements and a variety of possible extensions.All data is specified in XML [5] (Extensible Markup Language) syntax leading to a concise XML DTD (Document Type Declaration) for the phone book.
RFC 3019	IP Version 6 Management Information Base for The Multicast Listener Discovery Protocol
	Authors: B. Haberman, R. Worzella. Date: January 2001 Formats: txt pdf Obsoleted by: RFC 5519 Status: PROPOSED STANDARD This document defines a portion of the Management Information Base(MIB) for use with network management protocols in Internet ProtocolVersion 6 internets. Specifically, this document is the MIB module that defines managed objects for implementations of the MulticastListener Discovery Protocol [RFC2710].
RFC 3020	Definitions of Managed Objects for Monitoring and Controlling the UNI/NNI Multilink Frame Relay Function
	Authors: P. Pate, B. Lynch, K. Rehbehn. Date: December 2000 Formats: txt pdf Status: PROPOSED STANDARD This memo defines a Management Information Base (MIB) for monitoring and controlling a UNI/NNI Multilink Frame Relay Function as defined in Frame Relay Forum FRF.16. This MIB also includes conformance and notification information.
RFC 3021	Using 31-Bit Prefixes on IPv4 Point-to-Point Links
	Authors: A. Retana, R. White, V. Fuller, D. McPherson. Date: December 2000 Formats: txt pdf Status: PROPOSED STANDARD With ever-increasing pressure to conserve IP address space on theInternet, it makes sense to consider where relatively minor changes can be made to fielded practice to improve numbering efficiency. One such change, proposed by this document, is to halve the amount of address space assigned to point-to-point links (common throughout theInternet infrastructure) by allowing the use of 31-bit subnet masks in a very limited way.
RFC 3023	XML Media Types
	Authors: M. Murata, S. St. Laurent, D. Kohn. Date: January 2001 Formats: txt pdf Obsoletes: RFC 2376 Updates: RFC 2048 Status: PROPOSED STANDARD This document standardizes five new media types -- text/xml, application/xml, text/xml-external-parsed-entity, application/xml- external-parsed-entity, and application/xml-dtd -- for use in exchanging network entities that are related to the Extensible MarkupLanguage (XML). This document also standardizes a convention (using the suffix '+xml') for naming media types outside of these five types when those media types represent XML MIME (Multipurpose Internet MailExtensions) entities. XML MIME entities are currently exchanged via the HyperText Transfer Protocol on the World Wide Web, are an integral part of the WebDAV protocol for remote web authoring, and are expected to have utility in many domains. Major differences from RFC 2376 are (1) the addition of text/xml- external-parsed-entity, application/xml-external-parsed-entity, and application/xml-dtd, (2) the '+xml' suffix convention (which also updates the RFC 2048 registration process), and (3) the discussion of"utf-16le" and "utf-16be".
RFC 3024	Reverse Tunneling for Mobile IP, revised
	Authors: G. Montenegro, Ed.. Date: January 2001 Formats: txt pdf Obsoletes: RFC 2344 Status: PROPOSED STANDARD Mobile Internet Protocol (IP) uses tunneling from the home agent to the mobile node's care-of address, but rarely in the reverse direction. Usually, a mobile node sends its packets through a router on the foreign network, and assumes that routing is independent of source address. When this assumption is not true, it is convenient to establish a topologically correct reverse tunnel from the care-of address to the home agent. This document proposes backwards-compatible extensions to Mobile IP to support topologically correct reverse tunnels. This document does not attempt to solve the problems posed by firewalls located between the home agent and the mobile node's care-of address. This document obsoletes RFC 2344.
RFC 3025	Mobile IP Vendor/Organization-Specific Extensions
	Authors: G. Dommety, K. Leung. Date: February 2001 Formats: txt pdf Obsoleted by: RFC 3115 Status: PROPOSED STANDARD This document defines two new extensions to Mobile IP. These extensions will facilitate equipment vendors and organizations to make specific use of these extensions as they see fit for research or deployment purposes.
RFC 3028	Sieve: A Mail Filtering Language
	Authors: T. Showalter. Date: January 2001 Formats: txt pdf Obsoleted by: RFC 5228, RFC 5429 Status: PROPOSED STANDARD This document describes a language for filtering e-mail messages at time of final delivery. It is designed to be implementable on either a mail client or mail server. It is meant to be extensible, simple, and independent of access protocol, mail architecture, and operating system. It is suitable for running on a mail server where users may not be allowed to execute arbitrary programs, such as on black boxInternet Message Access Protocol (IMAP) servers, as it has no variables, loops, or ability to shell out to external programs.
RFC 3030	SMTP Service Extensions for Transmission of Large and Binary MIME Messages
	Authors: G. Vaudreuil. Date: December 2000 Formats: txt pdf Obsoletes: RFC 1830 Status: PROPOSED STANDARD This memo defines two extensions to the SMTP (Simple Mail TransferProtocol) service. The first extension enables a SMTP client and server to negotiate the use of an alternative to the DATA command, called "BDAT", for efficiently sending large MIME (MultipurposeInternet Mail Extensions) messages. The second extension takes advantage of the BDAT command to permit the negotiated sending ofMIME messages that employ the binary transfer encoding. This document is intended to update and obsolete RFC 1830.
RFC 3031	Multiprotocol Label Switching Architecture
	Authors: E. Rosen, A. Viswanathan, R. Callon. Date: January 2001 Formats: txt pdf Updated by: RFC 6178 Status: PROPOSED STANDARD This document specifies the architecture for Multiprotocol LabelSwitching (MPLS).
RFC 3032	MPLS Label Stack Encoding
	Authors: E. Rosen, D. Tappan, G. Fedorkow, Y. Rekhter, D. Farinacci, T. Li, A. Conta. Date: January 2001 Formats: txt pdf Updated by: RFC 3443, RFC 4182, RFC 5332, RFC 3270, RFC 5129, RFC 5462, RFC 5586 Status: PROPOSED STANDARD "Multi-Protocol Label Switching (MPLS)" [1] requires a set of procedures for augmenting network layer packets with "label stacks", thereby turning them into "labeled packets". Routers which supportMPLS are known as "Label Switching Routers", or "LSRs". In order to transmit a labeled packet on a particular data link, an LSR must support an encoding technique which, given a label stack and a network layer packet, produces a labeled packet. This document specifies the encoding to be used by an LSR in order to transmit labeled packets on Point-to-Point Protocol (PPP) data links, on LAN data links, and possibly on other data links as well. On some data links, the label at the top of the stack may be encoded in a different manner, but the techniques described here MUST be used to encode the remainder of the label stack. This document also specifies rules and procedures for processing the various fields of the label stack encoding.
RFC 3033	The Assignment of the Information Field and Protocol Identifier in the Q.2941 Generic Identifier and Q.2957 User-to-user Signaling for the Internet Protocol
	Authors: M. Suzuki. Date: January 2001 Formats: txt pdf Status: PROPOSED STANDARD The purpose of this document is to specify the assignment of the information field and protocol identifier in the Q.2941 GenericIdentifier and Q.2957 User-to-user Signaling for the Internet protocol. The assignment, that is specified in section 4 of this document, is designed for advanced B-ISDN signaling support of the Internet protocol, especially the B-ISDN signaling support for the connection that corresponds to the session in the Internet protocol which is clarified in section 2. This specification provides an indispensable framework for the implementation of long-lived session and QoS- sensitive session transfers over ATM.
RFC 3034	Use of Label Switching on Frame Relay Networks Specification
	Authors: A. Conta, P. Doolan, A. Malis. Date: January 2001 Formats: txt pdf Status: PROPOSED STANDARD This document defines the model and generic mechanisms forMultiprotocol Label Switching on Frame Relay networks. Furthermore, it extends and clarifies portions of the Multiprotocol LabelSwitching Architecture described in [ARCH] and the Label DistributionProtocol (LDP) described in [LDP] relative to Frame Relay Networks.MPLS enables the use of Frame Relay Switches as Label SwitchingRouters (LSRs).
RFC 3035	MPLS using LDP and ATM VC Switching
	Authors: B. Davie, J. Lawrence, K. McCloghrie, E. Rosen, G. Swallow, Y. Rekhter, P. Doolan. Date: January 2001 Formats: txt pdf Status: PROPOSED STANDARD The Multiprotocol Label Switching (MPLS) Architecture [1] discusses a way in which Asynchronous Transfer Mode (ATM) switches may be used asLabel Switching Routers. The ATM switches run network layer routing algorithms (such as Open Shortest Path First (OSPF), IntermediateSystem to Intermediate System (IS-IS), etc.), and their data forwarding is based on the results of these routing algorithms. NoATM-specific routing or addressing is needed. ATM switches used in this way are known as ATM-LSRs (Label Switching Routers). This document extends and clarifies the relevant portions of [1] and[2] by specifying in more detail the procedures which to be used when distributing labels to or from ATM-LSRs, when those labels representForwarding Equivalence Classes (FECs, see [1]) for which the routes are determined on a hop-by-hop basis by network layer routing algorithms. This document also specifies the MPLS encapsulation to be used when sending labeled packets to or from ATM-LSRs, and in that respect is a companion document to [3].
RFC 3036	LDP Specification
	Authors: L. Andersson, P. Doolan, N. Feldman, A. Fredette, B. Thomas. Date: January 2001 Formats: txt pdf Obsoleted by: RFC 5036 Status: PROPOSED STANDARD The architecture for Multi Protocol Label Switching (MPLS) is described in RFC 3031. A fundamental concept in MPLS is that twoLabel Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using a set of procedures, called a label distribution protocol, by which one LSR informs another of label bindings it has made. This document defines a set of such procedures called LDP (for Label Distribution Protocol) by which LSRs distribute labels to support MPLS forwarding along normally routed paths.
RFC 3038	VCID Notification over ATM link for LDP
	Authors: K. Nagami, Y. Katsube, N. Demizu, H. Esaki, P. Doolan. Date: January 2001 Formats: txt pdf Status: PROPOSED STANDARD The Asynchronous Transfer Mode Label Switching Router (ATM-LSR) is one of the major applications of label switching. Because the ATM layer labels (VPI and VCI) associated with a VC rewritten with new value at every ATM switch nodes, it is not possible to use them to identify a VC in label mapping messages. The concept of VirtualConnection Identifier (VCID) is introduced to solve this problem.VCID has the same value at both ends of a VC. This document specifies the procedures for the communication of VCID values between neighboring ATM-LSRs that must occur in order to ensure this property.
RFC 3039	Internet X.509 Public Key Infrastructure Qualified Certificates Profile
	Authors: S. Santesson, W. Polk, P. Barzin, M. Nystrom. Date: January 2001 Formats: txt pdf Obsoleted by: RFC 3739 Status: PROPOSED STANDARD This document forms a certificate profile for Qualified Certificates, based on RFC 2459, for use in the Internet. The term QualifiedCertificate is used to describe a certificate with a certain qualified status within applicable governing law. Further, QualifiedCertificates are issued exclusively to physical persons. The goal of this document is to define a general syntax independent of local legal requirements. The profile is however designed to allow further profiling in order to meet specific local needs. It is important to note that the profile does not define any legal requirements for Qualified Certificates.
RFC 3041	Privacy Extensions for Stateless Address Autoconfiguration in IPv6
	Authors: T. Narten, R. Draves. Date: January 2001 Formats: txt pdf Obsoleted by: RFC 4941 Status: PROPOSED STANDARD Nodes use IPv6 stateless address autoconfiguration to generate addresses without the necessity of a Dynamic Host ConfigurationProtocol (DHCP) server. Addresses are formed by combining network prefixes with an interface identifier. On interfaces that contain embedded IEEE Identifiers, the interface identifier is typically derived from it. On other interface types, the interface identifier is generated through other means, for example, via random number generation. This document describes an extension to IPv6 stateless address autoconfiguration for interfaces whose interface identifier is derived from an IEEE identifier. Use of the extension causes nodes to generate global-scope addresses from interface identifiers that change over time, even in cases where the interface contains an embedded IEEE identifier. Changing the interface identifier (and the global-scope addresses generated from it) over time makes it more difficult for eavesdroppers and other information collectors to identify when different addresses used in different transactions actually correspond to the same node.
RFC 3042	Enhancing TCP's Loss Recovery Using Limited Transmit
	Authors: M. Allman, H. Balakrishnan, S. Floyd. Date: January 2001 Formats: txt pdf Status: PROPOSED STANDARD This document proposes a new Transmission Control Protocol (TCP) mechanism that can be used to more effectively recover lost segments when a connection's congestion window is small, or when a large number of segments are lost in a single transmission window. The"Limited Transmit" algorithm calls for sending a new data segment in response to each of the first two duplicate acknowledgments that arrive at the sender. Transmitting these segments increases the probability that TCP can recover from a single lost segment using the fast retransmit algorithm, rather than using a costly retransmission timeout. Limited Transmit can be used both in conjunction with, and in the absence of, the TCP selective acknowledgment (SACK) mechanism.
RFC 3046	DHCP Relay Agent Information Option
	Authors: M. Patrick. Date: January 2001 Formats: txt pdf Updated by: RFC 6607 Status: PROPOSED STANDARD Newer high-speed public Internet access technologies call for a high-speed modem to have a local area network (LAN) attachment to one or more customer premise hosts. It is advantageous to use theDynamic Host Configuration Protocol (DHCP) as defined in RFC 2131 to assign customer premise host IP addresses in this environment.However, a number of security and scaling problems arise with such"public" DHCP use. This document describes a new DHCP option to address these issues. This option extends the set of DHCP options as defined in RFC 2132. The new option is called the Relay Agent Information option and is inserted by the DHCP relay agent when forwarding client-originatedDHCP packets to a DHCP server. Servers recognizing the Relay AgentInformation option may use the information to implement IP address or other parameter assignment policies. The DHCP Server echoes the option back verbatim to the relay agent in server-to-client replies, and the relay agent strips the option before forwarding the reply to the client. The "Relay Agent Information" option is organized as a single DHCP option that contains one or more "sub-options" that convey information known by the relay agent. The initial sub-options are defined for a relay agent that is co-located in a public circuit access unit. These include a "circuit ID" for the incoming circuit, and a "remote ID" which provides a trusted identifier for the remote high-speed modem.
RFC 3047	RTP Payload Format for ITU-T Recommendation G.722.1
	Authors: P. Luthi. Date: January 2001 Formats: txt pdf Obsoleted by: RFC 5577 Status: PROPOSED STANDARD International Telecommunication Union (ITU-T) Recommendation G.722.1 is a wide-band audio codec, which operates at one of two selectable bit rates, 24kbit/s or 32kbit/s. This document describes the payload format for including G.722.1 generated bit streams within an RTP packet. Also included here are the necessary details for the use ofG.722.1 with MIME and SDP.
RFC 3049	TN3270E Service Location and Session Balancing
	Authors: J. Naugle, K. Kasthurirangan, G. Ledford. Date: January 2001 Formats: txt pdf Status: PROPOSED STANDARD This document discusses the implementation of Service LocationProtocol (SLP) and session balancing with a TN3270E emulator in a client server implementation with a TN3270E server. Application program developer's can locate TN3270E services and load balance among those services (3270 host sessions), by using this SLP support.
RFC 3055	Management Information Base for the PINT Services Architecture
	Authors: M. Krishnaswamy, D. Romascanu. Date: February 2001 Formats: txt pdf Status: PROPOSED STANDARD This memo describes a proposed Management Information Base (MIB) for the PSTN/Internet Interworking (PINT) Services Architecture.
RFC 3056	Connection of IPv6 Domains via IPv4 Clouds
	Authors: B. Carpenter, K. Moore. Date: February 2001 Formats: txt pdf Status: PROPOSED STANDARD This memo specifies an optional interim mechanism for IPv6 sites to communicate with each other over the IPv4 network without explicit tunnel setup, and for them to communicate with native IPv6 domains via relay routers. Effectively it treats the wide area IPv4 network as a unicast point-to-point link layer. The mechanism is intended as a start-up transition tool used during the period of co-existence ofIPv4 and IPv6. It is not intended as a permanent solution. The document defines a method for assigning an interim unique IPv6 address prefix to any site that currently has at least one globally unique IPv4 address, and specifies an encapsulation mechanism for transmitting IPv6 packets using such a prefix over the global IPv4 network. The motivation for this method is to allow isolated IPv6 domains or hosts, attached to an IPv4 network which has no native IPv6 support, to communicate with other such IPv6 domains or hosts with minimal manual configuration, before they can obtain natuve IPv6 connectivity. It incidentally provides an interim globally uniqueIPv6 address prefix to any site with at least one globally uniqueIPv4 address, even if combined with an IPv4 Network AddressTranslator (NAT).
RFC 3057	ISDN Q.921-User Adaptation Layer
	Authors: K. Morneault, S. Rengasami, M. Kalla, G. Sidebottom. Date: February 2001 Formats: txt pdf Obsoleted by: RFC 4233 Updated by: RFC 3807 Status: PROPOSED STANDARD This document defines a protocol for backhauling of ISDN Q.921 User messages over IP using the Stream Control Transmission Protocol(SCTP). This protocol would be used between a Signaling Gateway (SG) and Media Gateway Controller (MGC). It is assumed that the SG receives ISDN signaling over a standard ISDN interface.
RFC 3059	Attribute List Extension for the Service Location Protocol
	Authors: E. Guttman. Date: February 2001 Formats: txt pdf Status: PROPOSED STANDARD The Service Location Protocol, Version 2 (SLPv2) provides a mechanism for a service to be discovered in a single exchange of messages.This exchange of messages does not presently include any of the service's attributes. This document specifies a SLPv2 extension which allows a User Agent (UA) to request a service's attributes be included as an extension to Service Reply messages. This will eliminate the need for multiple round trip messages for a UA to acquire all service information.
RFC 3060	Policy Core Information Model -- Version 1 Specification
	Authors: B. Moore, E. Ellesson, J. Strassner, A. Westerinen. Date: February 2001 Formats: txt pdf Updated by: RFC 3460 Status: PROPOSED STANDARD This document presents the object-oriented information model for representing policy information developed jointly in the IETF PolicyFramework WG and as extensions to the Common Information Model (CIM) activity in the Distributed Management Task Force (DMTF). This model defines two hierarchies of object classes: structural classes representing policy information and control of policies, and association classes that indicate how instances of the structural classes are related to each other. Subsequent documents will define mappings of this information model to various concrete implementations, for example, to a directory that uses LDAPv3 as its access protocol.
RFC 3062	LDAP Password Modify Extended Operation
	Authors: K. Zeilenga. Date: February 2001 Formats: txt pdf Status: PROPOSED STANDARD The integration of the Lightweight Directory Access Protocol (LDAP) and external authentication services has introduced non-DN authentication identities and allowed for non-directory storage of passwords. As such, mechanisms which update the directory (e.g.,Modify) cannot be used to change a user's password. This document describes an LDAP extended operation to allow modification of user passwords which is not dependent upon the form of the authentication identity nor the password storage mechanism used.
RFC 3065	Autonomous System Confederations for BGP
	Authors: P. Traina, D. McPherson, J. Scudder. Date: February 2001 Formats: txt pdf Obsoletes: RFC 1965 Obsoleted by: RFC 5065 Status: PROPOSED STANDARD The Border Gateway Protocol (BGP) is an inter-autonomous system routing protocol designed for Transmission Control Protocol/InternetProtocol (TCP/IP) networks. BGP requires that all BGP speakers within a single autonomous system (AS) must be fully meshed. This represents a serious scaling problem that has been well documented in a number of proposals. This document describes an extension to BGP which may be used to create a confederation of autonomous systems that is represented as a single autonomous system to BGP peers external to the confederation, thereby removing the "full mesh" requirement. The intention of this extension is to aid in policy administration and reduce the management complexity of maintaining a large autonomous system.
RFC 3068	An Anycast Prefix for 6to4 Relay Routers
	Authors: C. Huitema. Date: June 2001 Formats: txt pdf Status: PROPOSED STANDARD This memo introduces a "6to4 anycast address" in order to simplify the configuration of 6to4 routers. It also defines how this address will be used by 6to4 relay routers, how the corresponding "6to4 anycast prefix" will be advertised in the IGP and in the EGP. The memo documents the reservation by IANA (Internet Assigned NumbersAuthority) of the "6to4 relay anycast prefix."
RFC 3070	Layer Two Tunneling Protocol (L2TP) over Frame Relay
	Authors: V. Rawat, R. Tio, S. Nanji, R. Verma. Date: February 2001 Formats: txt pdf Status: PROPOSED STANDARD Layer Two Tunneling Protocol (L2TP) describes a mechanism to tunnelPoint-to-Point (PPP) sessions. The protocol has been designed to be independent of the media it runs over. The base specification describes how it should be implemented to run over the User DatagramProtocol (UDP) and the Internet Protocol (IP). This document describes how L2TP is implemented over Frame Relay Permanent VirtualCircuits (PVCs) and Switched Virtual Circuits (SVCs).
RFC 3074	DHC Load Balancing Algorithm
	Authors: B. Volz, S. Gonczi, T. Lemon, R. Stevens. Date: February 2001 Formats: txt pdf Status: PROPOSED STANDARD This document proposes a method of algorithmic load balancing. It enables multiple, cooperating servers to decide which one should service a client, without exchanging any information beyond initial configuration. The server selection is based on the servers hashing client MediaAccess Control (MAC) addresses when multiple Dynamic HostConfiguration Protocol (DHCP) servers are available to service DHCP clients. The proposed technique provides for efficient server selection when multiple DHCP servers offer services on a network without requiring any changes to existing DHCP clients. The same method is proposed to select the target server of a forwarding agent such as a Bootstrap Protocol (BOOTP) relay.
RFC 3075	XML-Signature Syntax and Processing
	Authors: D. Eastlake 3rd, J. Reagle, D. Solo. Date: March 2001 Formats: txt pdf Obsoleted by: RFC 3275 Status: PROPOSED STANDARD This document specifies XML (Extensible Markup Language) digital signature processing rules and syntax. XML Signatures provide integrity, message authentication, and/or signer authentication services for data of any type, whether located within the XML that includes the signature or elsewhere.
RFC 3077	A Link-Layer Tunneling Mechanism for Unidirectional Links
	Authors: E. Duros, W. Dabbous, H. Izumiyama, N. Fujii, Y. Zhang. Date: March 2001 Formats: txt pdf Status: PROPOSED STANDARD This document describes a mechanism to emulate full bidirectional connectivity between all nodes that are directly connected by a unidirectional link. The "receiver" uses a link-layer tunneling mechanism to forward datagrams to "feeds" over a separate bidirectional IP (Internet Protocol) network. As it is implemented at the link-layer, protocols in addition to IP may also be supported by this mechanism.
RFC 3080	The Blocks Extensible Exchange Protocol Core
	Authors: M. Rose. Date: March 2001 Formats: txt pdf Status: PROPOSED STANDARD This memo describes a generic application protocol kernel for connection-oriented, asynchronous interactions called the BEEP(Blocks Extensible Exchange Protocol) core. BEEP permits simultaneous and independent exchanges within the context of a single application user-identity, supporting both textual and binary messages.
RFC 3081	Mapping the BEEP Core onto TCP
	Authors: M. Rose. Date: March 2001 Formats: txt pdf Status: PROPOSED STANDARD This memo describes how a BEEP (Blocks Extensible Exchange Protocol) session is mapped onto a single TCP (Transmission Control Protocol) connection.
RFC 3084	COPS Usage for Policy Provisioning (COPS-PR)
	Authors: K. Chan, J. Seligson, D. Durham, S. Gai, K. McCloghrie, S. Herzog, F. Reichmeyer, R. Yavatkar, A. Smith. Date: March 2001 Formats: txt pdf Status: PROPOSED STANDARD This document describes the use of the Common Open Policy Service(COPS) protocol for support of policy provisioning (COPS-PR). This specification is independent of the type of policy being provisioned(QoS, Security, etc.) but focuses on the mechanisms and conventions used to communicate provisioned information between PDPs and PEPs.The protocol extensions described in this document do not make any assumptions about the policy data model being communicated, but describe the message formats and objects that carry the modeled policy data.
RFC 3090	DNS Security Extension Clarification on Zone Status
	Authors: E. Lewis. Date: March 2001 Formats: txt pdf Obsoleted by: RFC 4033, RFC 4034, RFC 4035 Updates: RFC 2535 Updated by: RFC 3658 Status: PROPOSED STANDARD The definition of a secured zone is presented, clarifying and updating sections of RFC 2535. RFC 2535 defines a zone to be secured based on a per algorithm basis, e.g., a zone can be secured with RSA keys, and not secured with DSA keys. This document changes this to define a zone to be secured or not secured regardless of the key algorithm used (or not used). To further simplify the determination of a zone's status, "experimentally secure" status is deprecated.
RFC 3095	RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed
	Authors: C. Bormann, C. Burmeister, M. Degermark, H. Fukushima, H. Hannu, L-E. Jonsson, R. Hakenberg, T. Koren, K. Le, Z. Liu, A. Martensson, A. Miyazaki, K. Svanbro, T. Wiebke, T. Yoshimura, H. Zheng. Date: July 2001 Formats: txt pdf Updated by: RFC 3759, RFC 4815 Status: PROPOSED STANDARD This document specifies a highly robust and efficient header compression scheme for RTP/UDP/IP (Real-Time Transport Protocol, UserDatagram Protocol, Internet Protocol), UDP/IP, and ESP/IP(Encapsulating Security Payload) headers. Existing header compression schemes do not work well when used over links with significant error rates and long round-trip times. For many bandwidth limited links where header compression is essential, such characteristics are common. This is done in a framework designed to be extensible. For example, a scheme for compressing TCP/IP headers will be simple to add, and is in development. Headers specific to Mobile IPv4 are not subject to special treatment, but are expected to be compressed sufficiently well by the provided methods for compression of sequences of extension headers and tunneling headers. For the most part, the same will apply to work in progress on Mobile IPv6, but future work might be required to handle some extension headers, when a standards trackMobile IPv6 has been completed.
RFC 3097	RSVP Cryptographic Authentication -- Updated Message Type Value
	Authors: R. Braden, L. Zhang. Date: April 2001 Formats: txt pdf Updates: RFC 2747 Status: PROPOSED STANDARD This memo resolves a duplication in the assignment of RSVP MessageTypes, by changing the Message Types assigned by RFC 2747 toChallenge and Integrity Response messages.
RFC 3101	The OSPF Not-So-Stubby Area (NSSA) Option
	Authors: P. Murphy. Date: January 2003 Formats: txt pdf Obsoletes: RFC 1587 Status: PROPOSED STANDARD This memo documents an optional type of Open Shortest Path First(OSPF) area that is somewhat humorously referred to as a "not-so- stubby" area (or NSSA). NSSAs are similar to the existing OSPF stub area configuration option but have the additional capability of importing AS external routes in a limited fashion. The OSPF NSSA Option was originally defined in RFC 1587. The functional differences between this memo and RFC 1587 are explained in Appendix F. All differences, while expanding capability, are backward-compatible in nature. Implementations of this memo and ofRFC 1587 will interoperate.
RFC 3107	Carrying Label Information in BGP-4
	Authors: Y. Rekhter, E. Rosen. Date: May 2001 Formats: txt pdf Status: PROPOSED STANDARD This document specifies the way in which the label mapping information for a particular route is piggybacked in the same BorderGateway Protocol (BGP) Update message that is used to distribute the route itself. When BGP is used to distribute a particular route, it can be also be used to distribute a Multiprotocol Label Switching(MPLS) label which is mapped to that route.
RFC 3108	Conventions for the use of the Session Description Protocol (SDP) for ATM Bearer Connections
	Authors: R. Kumar, M. Mostafa. Date: May 2001 Formats: txt pdf Status: PROPOSED STANDARD This document describes conventions for using the Session DescriptionProtocol (SDP) described in RFC 2327 for controlling ATM BearerConnections, and any associated ATM Adaptation Layer (AAL). The AALs addressed are Type 1, Type 2 and Type 5. This list of conventions is meant to be exhaustive. Individual applications can use subsets of these conventions. Further, these conventions are meant to comply strictly with the SDP syntax as defined in RFC 2327.
RFC 3110	RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)
	Authors: D. Eastlake 3rd. Date: May 2001 Formats: txt pdf Obsoletes: RFC 2537 Status: PROPOSED STANDARD This document describes how to produce RSA/SHA1 SIG resource records(RRs) in Section 3 and, so as to completely replace RFC 2537, describes how to produce RSA KEY RRs in Section 2. Since the adoption of a Proposed Standard for RSA signatures in theDNS (Domain Name Space), advances in hashing have been made. A newDNS signature algorithm is defined to make these advances available in SIG RRs. The use of the previously specified weaker mechanism is deprecated. The algorithm number of the RSA KEY RR is changed to correspond to this new SIG algorithm. No other changes are made toDNS security.
RFC 3111	Service Location Protocol Modifications for IPv6
	Authors: E. Guttman. Date: May 2001 Formats: txt pdf Status: PROPOSED STANDARD This document defines the Service Location Protocol Version 2's(SLPv2) use over IPv6 networks. Since this protocol relies on UDP and TCP, the changes to support its use over IPv6 are minor. This document does not describe how to use SLPv1 over IPv6 networks.There is at the time of this publication no implementation or deployment of SLPv1 over IPv6. It is RECOMMENDED that SLPv2 be used in general, and specifically on networks which support IPv6.
RFC 3115	Mobile IP Vendor/Organization-Specific Extensions
	Authors: G. Dommety, K. Leung. Date: April 2001 Formats: txt pdf Obsoletes: RFC 3025 Status: PROPOSED STANDARD This document defines two new extensions to Mobile IP. These extensions will facilitate equipment vendors and organizations to make specific use of these extensions as they see fit for research or deployment purposes.
RFC 3118	Authentication for DHCP Messages
	Authors: R. Droms, W. Arbaugh, Eds.. Date: June 2001 Formats: txt pdf Status: PROPOSED STANDARD This document defines a new Dynamic Host Configuration Protocol(DHCP) option through which authorization tickets can be easily generated and newly attached hosts with proper authorization can be automatically configured from an authenticated DHCP server. DHCP provides a framework for passing configuration information to hosts on a TCP/IP network. In some situations, network administrators may wish to constrain the allocation of addresses to authorized hosts.Additionally, some network administrators may wish to provide for authentication of the source and contents of DHCP messages.
RFC 3119	A More Loss-Tolerant RTP Payload Format for MP3 Audio
	Authors: R. Finlayson. Date: June 2001 Formats: txt pdf Obsoleted by: RFC 5219 Status: PROPOSED STANDARD This document describes a RTP (Real-Time Protocol) payload format for transporting MPEG (Moving Picture Experts Group) 1 or 2, layer III audio (commonly known as "MP3"). This format is an alternative to that described in RFC 2250, and performs better if there is packet loss.
RFC 3122	Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification
	Authors: A. Conta. Date: June 2001 Formats: txt pdf Status: PROPOSED STANDARD This memo describes extensions to the IPv6 Neighbor Discovery that allow a node to determine and advertise an IPv6 address corresponding to a given link-layer address. These extensions are called InverseNeighbor Discovery. The Inverse Neighbor Discovery (IND) was originally developed for Frame Relay networks, but may also apply to other networks with similar behavior.
RFC 3124	The Congestion Manager
	Authors: H. Balakrishnan, S. Seshan. Date: June 2001 Formats: txt pdf Status: PROPOSED STANDARD This document describes the Congestion Manager (CM), an end-system module that: (i) Enables an ensemble of multiple concurrent streams from a sender destined to the same receiver and sharing the same congestion properties to perform proper congestion avoidance and control, and (ii) Allows applications to easily adapt to network congestion.
RFC 3140	Per Hop Behavior Identification Codes
	Authors: D. Black, S. Brim, B. Carpenter, F. Le Faucheur. Date: June 2001 Formats: txt pdf Obsoletes: RFC 2836 Status: PROPOSED STANDARD This document defines a 16 bit encoding mechanism for the identification of differentiated services Per Hop Behaviors in protocol messages. It replaces RFC 2836.
RFC 3144	Remote Monitoring MIB Extensions for Interface Parameters Monitoring
	Authors: D. Romascanu. Date: August 2001 Formats: txt pdf Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.The document proposes an extension to the Remote Monitoring MIB with a method of sorting the interfaces of a monitored device according to values of parameters specific to this interface.
RFC 3145	L2TP Disconnect Cause Information
	Authors: R. Verma, M. Verma, J. Carlson. Date: July 2001 Formats: txt pdf Status: PROPOSED STANDARD This document provides an extension to the Layer 2 Tunneling Protocol("L2TP"), a mechanism for tunneling Point-to-Point Protocol (PPP) sessions. L2TP lacks a mechanism for a host to provide PPP-related disconnect cause information to another host. This information, provided by the extension described in this document, can be useful for accounting and debugging purposes.
RFC 3146	Transmission of IPv6 Packets over IEEE 1394 Networks
	Authors: K. Fujisawa, A. Onoe. Date: October 2001 Formats: txt pdf Status: PROPOSED STANDARD This document describes the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE1394 networks.
RFC 3153	PPP Multiplexing
	Authors: R. Pazhyannur, I. Ali, C. Fox. Date: August 2001 Formats: txt pdf Status: PROPOSED STANDARD This document describes a method to reduce the PPP (Point-to-PointProtocol) framing overhead used to transport small packets over slow links.
RFC 3156	MIME Security with OpenPGP
	Authors: M. Elkins, D. Del Torto, R. Levien, T. Roessler. Date: August 2001 Formats: txt pdf Updates: RFC 2015 Status: PROPOSED STANDARD This document describes how the OpenPGP Message Format can be used to provide privacy and authentication using the Multipurpose InternetMail Extensions (MIME) security content types described in RFC 1847.
RFC 3159	Structure of Policy Provisioning Information (SPPI)
	Authors: K. McCloghrie, M. Fine, J. Seligson, K. Chan, S. Hahn, R. Sahita, A. Smith, F. Reichmeyer. Date: August 2001 Formats: txt pdf Status: PROPOSED STANDARD This document, the Structure of Policy Provisioning Information(SPPI), defines the adapted subset of SNMP's Structure of ManagementInformation (SMI) used to write Policy Information Base (PIB) modules. RFC 2748 defines the COPS protocol, and RFC 2749 describes how theCOPS protocol is used to provide for the outsourcing of policy decisions for RSVP. Another usage of the COPS protocol, for the provisioning of policy, is introduced in RFC 3084. In this provisioning model, the policy information is viewed as a collection of Provisioning Classes (PRCs) and Provisioning Instances (PRIs) residing in a virtual information store, termed the PolicyInformation Base (PIB). Collections of related Provisioning Classes are defined in a PIB module.
RFC 3161	Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)
	Authors: C. Adams, P. Cain, D. Pinkas, R. Zuccherato. Date: August 2001 Formats: txt pdf Updated by: RFC 5816 Status: PROPOSED STANDARD This document describes the format of a request sent to a TimeStamping Authority (TSA) and of the response that is returned. It also establishes several security-relevant requirements for TSA operation, with regards to processing requests to generate responses.
RFC 3162	RADIUS and IPv6
	Authors: B. Aboba, G. Zorn, D. Mitton. Date: August 2001 Formats: txt pdf Status: PROPOSED STANDARD This document specifies the operation of RADIUS (RemoteAuthentication Dial In User Service) when run over IPv6 as well as the RADIUS attributes used to support IPv6 network access.
RFC 3165	Definitions of Managed Objects for the Delegation of Management Scripts
	Authors: D. Levi, J. Schoenwaelder. Date: August 2001 Formats: txt pdf Obsoletes: RFC 2592 Status: PROPOSED STANDARD 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 a set of managed objects that allow the delegation of management scripts to distributed managers.
RFC 3168	The Addition of Explicit Congestion Notification (ECN) to IP
	Authors: K. Ramakrishnan, S. Floyd, D. Black. Date: September 2001 Formats: txt pdf Obsoletes: RFC 2481 Updates: RFC 2003, RFC 2474, RFC 2401, RFC 0793 Updated by: RFC 4301, RFC 6040 Status: PROPOSED STANDARD This memo specifies the incorporation of ECN (Explicit CongestionNotification) to TCP and IP, including ECN's use of two bits in theIP header.
RFC 3173	IP Payload Compression Protocol (IPComp)
	Authors: A. Shacham, B. Monsour, R. Pereira, M. Thomas. Date: September 2001 Formats: txt pdf Obsoletes: RFC 2393 Status: PROPOSED STANDARD This document describes a protocol intended to provide lossless compression for Internet Protocol datagrams in an Internet environment.
RFC 3175	Aggregation of RSVP for IPv4 and IPv6 Reservations
	Authors: F. Baker, C. Iturralde, F. Le Faucheur, B. Davie. Date: September 2001 Formats: txt pdf Updated by: RFC 5350 Status: PROPOSED STANDARD This document describes the use of a single RSVP (ResourceReSerVation Protocol) reservation to aggregate other RSVP reservations across a transit routing region, in a manner conceptually similar to the use of Virtual Paths in an ATM(Asynchronous Transfer Mode) network. It proposes a way to dynamically create the aggregate reservation, classify the traffic for which the aggregate reservation applies, determine how much bandwidth is needed to achieve the requirement, and recover the bandwidth when the sub-reservations are no longer required. It also contains recommendations concerning algorithms and policies for predictive reservations.
RFC 3181	Signaled Preemption Priority Policy Element
	Authors: S. Herzog. Date: October 2001 Formats: txt pdf Obsoletes: RFC 2751 Status: PROPOSED STANDARD This document describes a preemption priority policy element for use by signaled policy based admission protocols (such as the ResourceReSerVation Protocol (RSVP) and Common Open Policy Service (COPS). Preemption priority defines a relative importance (rank) within the set of flows competing to be admitted into the network. Rather than admitting flows by order of arrival (First Come First Admitted) network nodes may consider priorities to preempt some previously admitted low priority flows in order to make room for a newer, high- priority flow. This memo corrects an RSVP POLICY_DATA P-Type codepoint assignment error in RFC 2751.
RFC 3182	Identity Representation for RSVP
	Authors: S. Yadav, R. Yavatkar, R. Pabbati, P. Ford, T. Moore, S. Herzog, R. Hess. Date: October 2001 Formats: txt pdf Obsoletes: RFC 2752 Status: PROPOSED STANDARD This document describes the representation of identity information inPOLICY_DATA object for supporting policy based admission control in the Resource ReSerVation Protocol (RSVP). The goal of identity representation is to allow a process on a system to securely identify the owner and the application of the communicating process (e.g., user id) and convey this information in RSVP messages (PATH or RESV) in a secure manner. We describe the encoding of identities as RSVP policy element. We describe the processing rules to generate identity policy elements for multicast merged flows. Subsequently, we describe representations of user identities for Kerberos andPublic Key based user authentication mechanisms. In summary, we describe the use of this identity information in an operational setting. This memo corrects an RSVP POLICY_DATA P-Type codepoint assignment error and a field size definition error in ErrorValue in RFC 2752.
RFC 3185	Reuse of CMS Content Encryption Keys
	Authors: S. Farrell, S. Turner. Date: October 2001 Formats: txt pdf Status: PROPOSED STANDARD This document describes a way to include a key identifier in a CMS(Cryptographic Message Syntax) enveloped data structure, so that the content encryption key can be re-used for further enveloped data packets.
RFC 3189	RTP Payload Format for DV (IEC 61834) Video
	Authors: K. Kobayashi, A. Ogawa, S. Casner, C. Bormann. Date: January 2002 Formats: txt pdf Obsoleted by: RFC 6469 Status: PROPOSED STANDARD This document specifies the packetization scheme for encapsulating the compressed digital video data streams commonly known as "DV" into a payload format for the Real-Time Transport Protocol (RTP).
RFC 3190	RTP Payload Format for 12-bit DAT Audio and 20- and 24-bit Linear Sampled Audio
	Authors: K. Kobayashi, A. Ogawa, S. Casner, C. Bormann. Date: January 2002 Formats: txt pdf Status: PROPOSED STANDARD This document specifies a packetization scheme for encapsulating12-bit nonlinear, 20-bit linear, and 24-bit linear audio data streams using the Real-time Transport Protocol (RTP). This document also specifies the format of a Session Description Protocol (SDP) parameter to indicate when audio data is preemphasized before sampling. The parameter may be used with other audio payload formats, in particular L16 (16-bit linear).
RFC 3193	Securing L2TP using IPsec
	Authors: B. Patel, B. Aboba, W. Dixon, G. Zorn, S. Booth. Date: November 2001 Formats: txt pdf Status: PROPOSED STANDARD This document discusses how L2TP (Layer Two Tunneling Protocol) may utilize IPsec to provide for tunnel authentication, privacy protection, integrity checking and replay protection. Both the voluntary and compulsory tunneling cases are discussed.
RFC 3195	Reliable Delivery for syslog
	Authors: D. New, M. Rose. Date: November 2001 Formats: txt pdf Status: PROPOSED STANDARD The BSD Syslog Protocol describes a number of service options related to propagating event messages. This memo describes two mappings of the syslog protocol to TCP connections, both useful for reliable delivery of event messages. The first provides a trivial mapping maximizing backward compatibility. The second provides a more complete mapping. Both provide a degree of robustness and security in message delivery that is unavailable to the usual UDP-based syslog protocol, by providing encryption and authentication over a connection-oriented protocol.
RFC 3201	Definitions of Managed Objects for Circuit to Interface Translation
	Authors: R. Steinberger, O. Nicklass. Date: January 2002 Formats: txt pdf Status: PROPOSED STANDARD This memo defines an extension of the Management Information Base(MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the insertion of interesting Circuit Interfaces into the ifTable. This is important for circuits that must be used within other MIB modules which require an ifEntry. It allows for integrated monitoring of circuits as well as routing to circuits using unaltered, pre-existingMIB modules.
RFC 3202	Definitions of Managed Objects for Frame Relay Service Level Definitions
	Authors: R. Steinberger, O. Nicklass. Date: January 2002 Formats: txt pdf Status: PROPOSED STANDARD This memo defines an extension of the Management Information Base(MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing the FrameRelay Service Level Definitions.
RFC 3203	DHCP reconfigure extension
	Authors: Y. T'Joens, C. Hublet, P. De Schrijver. Date: December 2001 Formats: txt pdf Status: PROPOSED STANDARD This document defines extensions to DHCP (Dynamic Host ConfigurationProtocol) to allow dynamic reconfiguration of a single host triggered by the DHCP server (e.g., a new IP address and/or local configuration parameters). This is achieved by introducing a unicast FORCERENEW message which forces the client to the RENEW state. The behaviour for hosts using the DHCP INFORM message to obtain configuration information is also described.
RFC 3204	MIME media types for ISUP and QSIG Objects
	Authors: E. Zimmerer, J. Peterson, A. Vemuri, L. Ong, F. Audet, M. Watson, M. Zonoun. Date: December 2001 Formats: txt pdf Updated by: RFC 3459, RFC 5621 Status: PROPOSED STANDARD This document describes MIME types for application/ISUP and application/QSIG objects for use in SIP applications, according to the rules defined in RFC 2048. These types can be used to identifyISUP and QSIG objects within a SIP message such as INVITE or INFO, as might be implemented when using SIP in an environment where part of the call involves interworking to the PSTN.
RFC 3206	The SYS and AUTH POP Response Codes
	Authors: R. Gellens. Date: February 2002 Formats: txt pdf Status: PROPOSED STANDARD This memo proposes two response codes: SYS and AUTH, which enable clients to unambiguously determine an optimal response to an authentication failure. In addition, a new capability (AUTH-RESP-CODE) is defined.
RFC 3207	SMTP Service Extension for Secure SMTP over Transport Layer Security
	Authors: P. Hoffman. Date: February 2002 Formats: txt pdf Obsoletes: RFC 2487 Status: PROPOSED STANDARD This document describes an extension to the SMTP (Simple MailTransfer Protocol) service that allows an SMTP server and client to use TLS (Transport Layer Security) to provide private, authenticated communication over the Internet. This gives SMTP agents the ability to protect some or all of their communications from eavesdroppers and attackers.
RFC 3209	RSVP-TE: Extensions to RSVP for LSP Tunnels
	Authors: D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G. Swallow. Date: December 2001 Formats: txt pdf Updated by: RFC 3936, RFC 4420, RFC 4874, RFC 5151, RFC 5420, RFC 5711 Status: PROPOSED STANDARD This document describes the use of RSVP (Resource ReservationProtocol), including all the necessary extensions, to establish label-switched paths (LSPs) in MPLS (Multi-Protocol Label Switching).Since the flow along an LSP is completely identified by the label applied at the ingress node of the path, these paths may be treated as tunnels. A key application of LSP tunnels is traffic engineering with MPLS as specified in RFC 2702. We propose several additional objects that extend RSVP, allowing the establishment of explicitly routed label switched paths using RSVP as a signaling protocol. The result is the instantiation of label- switched tunnels which can be automatically routed away from network failures, congestion, and bottlenecks.
RFC 3211	Password-based Encryption for CMS
	Authors: P. Gutmann. Date: December 2001 Formats: txt pdf Obsoleted by: RFC 3369, RFC 3370 Status: PROPOSED STANDARD This document provides a method of encrypting data using user- supplied passwords and, by extension, any form of variable-length keying material which is not necessarily an algorithm-specific fixed-format key. The Cryptographic Message Syntax data format does not currently contain any provisions for password-based data encryption.
RFC 3212	Constraint-Based LSP Setup using LDP
	Authors: B. Jamoussi, Ed., L. Andersson, R. Callon, R. Dantu, L. Wu, P. Doolan, T. Worster, N. Feldman, A. Fredette, M. Girish, E. Gray, J. Heinanen, T. Kilty, A. Malis. Date: January 2002 Formats: txt pdf Updated by: RFC 3468 Status: PROPOSED STANDARD This document specifies mechanisms and TLVs (Type/Length/Value) for support of CR-LSPs (constraint-based routed Label Switched Path) using LDP (Label Distribution Protocol). This specification proposes an end-to-end setup mechanism of a CR-LSP initiated by the ingress LSR (Label Switching Router). We also specify mechanisms to provide means for reservation of resources using LDP.
RFC 3214	LSP Modification Using CR-LDP
	Authors: J. Ash, Y. Lee, P. Ashwood-Smith, B. Jamoussi, D. Fedyk, D. Skalecki, L. Li. Date: January 2002 Formats: txt pdf Status: PROPOSED STANDARD This document presents an approach to modify the bandwidth and possibly other parameters of an established CR-LSP (Constraint-basedRouted Label Switched Paths) using CR-LDP (Constraint-based RoutedLabel Distribution Protocol) without service interruption. After aCR-LSP is set up, its bandwidth reservation may need to be changed by the network operator, due to the new requirements for the traffic carried on that CR-LSP. The LSP modification feature can be supported by CR-LDP by use of the _modify_value for the _action indicator flag_ in the LSPID TLV. This feature has application in dynamic network resources management where traffic of different priorities and service classes is involved.
RFC 3219	Telephony Routing over IP (TRIP)
	Authors: J. Rosenberg, H. Salama, M. Squire. Date: January 2002 Formats: txt pdf Status: PROPOSED STANDARD This document presents the Telephony Routing over IP (TRIP). TRIP is a policy driven inter-administrative domain protocol for advertising the reachability of telephony destinations between location servers, and for advertising attributes of the routes to those destinations.TRIP's operation is independent of any signaling protocol, hence TRIP can serve as the telephony routing protocol for any signaling protocol. The Border Gateway Protocol (BGP-4) is used to distribute routing information between administrative domains. TRIP is used to distribute telephony routing information between telephony administrative domains. The similarity between the two protocols is obvious, and hence TRIP is modeled after BGP-4.
RFC 3220	IP Mobility Support for IPv4
	Authors: C. Perkins, Ed.. Date: January 2002 Formats: txt pdf Obsoletes: RFC 2002 Obsoleted by: RFC 3344 Status: PROPOSED STANDARD This document specifies protocol enhancements that allow transparent routing of IP datagrams to mobile nodes in the Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about its current point of attachment to the Internet. The protocol provides for registering the care-of address with a home agent. The home agent sends datagrams destined for the mobile node through a tunnel to the care- of address. After arriving at the end of the tunnel, each datagram is then delivered to the mobile node.
RFC 3224	Vendor Extensions for Service Location Protocol, Version 2
	Authors: E. Guttman. Date: January 2002 Formats: txt pdf Updates: RFC 2608 Status: PROPOSED STANDARD This document specifies how the features of the Service LocationProtocol, Version 2 allow for vendor extensibility safely, with no possibility of collisions. The specification introduces a new SLPv2 extension: The Vendor Opaque Extension. While proprietary protocol extensions are not encouraged by IETF standards, it is important that they not hinder interoperability of compliant implementations when they are undertaken. This document udpates RFC 2608, "The ServiceLocation Protocol."
RFC 3225	Indicating Resolver Support of DNSSEC
	Authors: D. Conrad. Date: December 2001 Formats: txt pdf Updated by: RFC 4033, RFC 4034, RFC 4035 Status: PROPOSED STANDARD In order to deploy DNSSEC (Domain Name System Security Extensions) operationally, DNSSEC aware servers should only perform automatic inclusion of DNSSEC RRs when there is an explicit indication that the resolver can understand those RRs. This document proposes the use of a bit in the EDNS0 header to provide that explicit indication and describes the necessary protocol changes to implement that notification.
RFC 3226	DNSSEC and IPv6 A6 aware server/resolver message size requirements
	Authors: O. Gudmundsson. Date: December 2001 Formats: txt pdf Updates: RFC 2535, RFC 2874 Updated by: RFC 4033, RFC 4034, RFC 4035 Status: PROPOSED STANDARD This document mandates support for EDNS0 (Extension Mechanisms forDNS) in DNS entities claiming to support either DNS SecurityExtensions or A6 records. This requirement is necessary because these new features increase the size of DNS messages. If EDNS0 is not supported fall back to TCP will happen, having a detrimental impact on query latency and DNS server load. This document updatesRFC 2535 and RFC 2874, by adding new requirements.
RFC 3229	Delta encoding in HTTP
	Authors: J. Mogul, B. Krishnamurthy, F. Douglis, A. Feldmann, Y. Goland, A. van Hoff, D. Hellerstein. Date: January 2002 Formats: txt pdf Status: PROPOSED STANDARD This document describes how delta encoding can be supported as a compatible extension to HTTP/1.1. Many HTTP (Hypertext Transport Protocol) requests cause the retrieval of slightly modified instances of resources for which the client already has a cache entry. Research has shown that such modifying updates are frequent, and that the modifications are typically much smaller than the actual entity. In such cases, HTTP would make more efficient use of network bandwidth if it could transfer a minimal description of the changes, rather than the entire new instance of the resource. This is called "delta encoding."
RFC 3230	Instance Digests in HTTP
	Authors: J. Mogul, A. Van Hoff. Date: January 2002 Formats: txt pdf Status: PROPOSED STANDARD HTTP/1.1 defines a Content-MD5 header that allows a server to include a digest of the response body. However, this is specifically defined to cover the body of the actual message, not the contents of the full file (which might be quite different, if the response is a Content-Range, or uses a delta encoding). Also, the Content-MD5 is limited to one specific digest algorithm; other algorithms, such as SHA-1(Secure Hash Standard), may be more appropriate in some circumstances. Finally, HTTP/1.1 provides no explicit mechanism by which a client may request a digest. This document proposes HTTP extensions that solve these problems.
RFC 3231	Definitions of Managed Objects for Scheduling Management Operations
	Authors: D. Levi, J. Schoenwaelder. Date: January 2002 Formats: txt pdf Obsoletes: RFC 2591 Status: PROPOSED STANDARD 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 a set of managed objects that are used to schedule management operations periodically or at specified dates and times. This document obsoletes RFC 2591.
RFC 3241	Robust Header Compression (ROHC) over PPP
	Authors: C. Bormann. Date: April 2002 Formats: txt pdf Updates: RFC 1332 Updated by: RFC 4815 Status: PROPOSED STANDARD This document describes an option for negotiating the use of robust header compression (ROHC) on IP datagrams transmitted over thePoint-to-Point Protocol (PPP). It defines extensions to the PPPControl Protocols for IPv4 and IPv6.
RFC 3242	RObust Header Compression (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP
	Authors: L-E. Jonsson, G. Pelletier. Date: April 2002 Formats: txt pdf Obsoleted by: RFC 4362 Status: PROPOSED STANDARD This document defines a ROHC (Robust Header Compression) profile for compression of IP/UDP/RTP (Internet Protocol/User DatagramProtocol/Real-Time Transport Protocol) packets, utilizing functionality provided by the lower layers to increase compression efficiency by completely eliminating the header for most packets during optimal operation. The profile is built as an extension to the ROHC RTP profile. It defines additional mechanisms needed inROHC, states requirements on the assisting layer to guarantee transparency, and specifies general logic for compression and decompression making use of this header-free packet.
RFC 3246	An Expedited Forwarding PHB (Per-Hop Behavior)
	Authors: B. Davie, A. Charny, J.C.R. Bennet, K. Benson, J.Y. Le Boudec, W. Courtney, S. Davari, V. Firoiu, D. Stiliadis. Date: March 2002 Formats: txt pdf Obsoletes: RFC 2598 Status: PROPOSED STANDARD This document defines a PHB (per-hop behavior) called ExpeditedForwarding (EF). The PHB is a basic building block in theDifferentiated Services architecture. EF is intended to provide a building block for low delay, low jitter and low loss services by ensuring that the EF aggregate is served at a certain configured rate. This document obsoletes RFC 2598.
RFC 3250	Tag Image File Format Fax eXtended (TIFF-FX) - image/tiff-fx MIME Sub-type Registration
	Authors: L. McIntyre, G. Parsons, J. Rafferty. Date: September 2002 Formats: txt pdf Obsoleted by: RFC 3950 Status: PROPOSED STANDARD This document describes the registration of the MIME sub-type image/tiff-fx. The encodings are defined by File Format for InternetFax and its extensions.
RFC 3253	Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)
	Authors: G. Clemm, J. Amsden, T. Ellison, C. Kaler, J. Whitehead. Date: March 2002 Formats: txt pdf Status: PROPOSED STANDARD This document specifies a set of methods, headers, and resource types that define the WebDAV (Web Distributed Authoring and Versioning) versioning extensions to the HTTP/1.1 protocol. WebDAV versioning will minimize the complexity of clients that are capable of interoperating with a variety of versioning repository managers, to facilitate widespread deployment of applications capable of utilizing the WebDAV Versioning services. WebDAV versioning includes automatic versioning for versioning-unaware clients, version history management, workspace management, baseline management, activity management, and URL namespace versioning.
RFC 3255	Extending Point-to-Point Protocol (PPP) over Synchronous Optical NETwork/Synchronous Digital Hierarchy (SONET/SDH) with virtual concatenation, high order and low order payloads
	Authors: N. Jones, C. Murton. Date: April 2002 Formats: txt pdf Status: PROPOSED STANDARD This document describes an extension to the mapping of Point-to-PointProtocol (PPP) into Synchronous Optical NETwork/Synchronous DigitalHierarchy (SONET/SDH) to include the use of SONET/SDH SPE/VC virtual concatenation and the use of both high order and low order payloads.
RFC 3256	The DOCSIS (Data-Over-Cable Service Interface Specifications) Device Class DHCP (Dynamic Host Configuration Protocol) Relay Agent Information Sub-option
	Authors: D. Jones, R. Woundy. Date: April 2002 Formats: txt pdf Status: PROPOSED STANDARD This document proposes a new sub-option to the DHCP (Dynamic HostConfiguration Protocol) Relay Agent Information Option. This new sub-option is for use with DOCSIS (Data-Over-Cable Service InterfaceSpecifications) cable modems and describes a "device class" to which the cable modem belongs. The cable modem signals its device class information to the Relay Agent using DOCSIS signaling, and the RelayAgent forwards the device class information to the DHCP Server which can then make a policy decision based on it.
RFC 3261	SIP: Session Initiation Protocol
	Authors: J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler. Date: June 2002 Formats: txt pdf Obsoletes: RFC 2543 Updated by: RFC 3265, RFC 3853, RFC 4320, RFC 4916, RFC 5393, RFC 5621, RFC 5626, RFC 5630, RFC 5922, RFC 5954, RFC 6026, RFC 6141 Status: PROPOSED STANDARD This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants.These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. SIP invitations used to create sessions carry session descriptions that allow participants to agree on a set of compatible media types.SIP makes use of elements called proxy servers to help route requests to the user's current location, authenticate and authorize users for services, implement provider call-routing policies, and provide features to users. SIP also provides a registration function that allows users to upload their current locations for use by proxy servers. SIP runs on top of several different transport protocols.
RFC 3262	Reliability of Provisional Responses in Session Initiation Protocol (SIP)
	Authors: J. Rosenberg, H. Schulzrinne. Date: June 2002 Formats: txt pdf Obsoletes: RFC 2543 Status: PROPOSED STANDARD This document specifies an extension to the Session InitiationProtocol (SIP) providing reliable provisional response messages.This extension uses the option tag 100rel and defines the ProvisionalResponse ACKnowledgement (PRACK) method.
RFC 3263	Session Initiation Protocol (SIP): Locating SIP Servers
	Authors: J. Rosenberg, H. Schulzrinne. Date: June 2002 Formats: txt pdf Obsoletes: RFC 2543 Status: PROPOSED STANDARD The Session Initiation Protocol (SIP) uses DNS procedures to allow a client to resolve a SIP Uniform Resource Identifier (URI) into the IP address, port, and transport protocol of the next hop to contact. It also uses DNS to allow a server to send a response to a backup client if the primary client has failed. This document describes those DNS procedures in detail.
RFC 3264	An Offer/Answer Model with Session Description Protocol (SDP)
	Authors: J. Rosenberg, H. Schulzrinne. Date: June 2002 Formats: txt pdf Obsoletes: RFC 2543 Updated by: RFC 6157 Status: PROPOSED STANDARD This document defines a mechanism by which two entities can make use of the Session Description Protocol (SDP) to arrive at a common view of a multimedia session between them. In the model, one participant offers the other a description of the desired session from their perspective, and the other participant answers with the desired session from their perspective. This offer/answer model is most useful in unicast sessions where information from both participants is needed for the complete view of the session. The offer/answer model is used by protocols like the Session Initiation Protocol(SIP).
RFC 3265	Session Initiation Protocol (SIP)-Specific Event Notification
	Authors: A. B. Roach. Date: June 2002 Formats: txt pdf Obsoletes: RFC 2543 Updates: RFC 3261 Updated by: RFC 5367, RFC 5727, RFC 6446 Status: PROPOSED STANDARD This document describes an extension to the Session InitiationProtocol (SIP). The purpose of this extension is to provide an extensible framework by which SIP nodes can request notification from remote nodes indicating that certain events have occurred. Concrete uses of the mechanism described in this document may be standardized in the future. Note that the event notification mechanisms defined herein are NOT intended to be a general-purpose infrastructure for all classes of event subscription and notification.
RFC 3266	Support for IPv6 in Session Description Protocol (SDP)
	Authors: S. Olson, G. Camarillo, A. B. Roach. Date: June 2002 Formats: txt pdf Obsoleted by: RFC 4566 Updates: RFC 2327 Status: PROPOSED STANDARD This document describes the use of Internet Protocol Version 6 (IPv6) addresses in conjunction with the Session Description Protocol (SDP).Specifically, this document clarifies existing text in SDP with regards to the syntax of IPv6 addresses.
RFC 3267	Real-Time Transport Protocol (RTP) Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs
	Authors: J. Sjoberg, M. Westerlund, A. Lakaniemi, Q. Xie. Date: June 2002 Formats: txt pdf Obsoleted by: RFC 4867 Status: PROPOSED STANDARD This document specifies a real-time transport protocol (RTP) payload format to be used for Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) encoded speech signals. The payload format is designed to be able to interoperate with existing AMR and AMR-WB transport formats on non-IP networks. In addition, a file format is specified for transport of AMR and AMR-WB speech data in storage mode applications such as email. Two separate MIME type registrations are included, one for AMR and one for AMR-WB, specifying use of both theRTP payload format and the storage format.
RFC 3268	Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)
	Authors: P. Chown. Date: June 2002 Formats: txt pdf Obsoleted by: RFC 5246 Status: PROPOSED STANDARD This document proposes several new ciphersuites. At present, the symmetric ciphers supported by Transport Layer Security (TLS) areRC2, RC4, International Data Encryption Algorithm (IDEA), DataEncryption Standard (DES), and triple DES. The protocol would be enhanced by the addition of Advanced Encryption Standard (AES) ciphersuites.
RFC 3270	Multi-Protocol Label Switching (MPLS) Support of Differentiated Services
	Authors: F. Le Faucheur, L. Wu, B. Davie, S. Davari, P. Vaananen, R. Krishnan, P. Cheval, J. Heinanen. Date: May 2002 Formats: txt pdf Updates: RFC 3032 Updated by: RFC 5462 Status: PROPOSED STANDARD This document defines a flexible solution for support ofDifferentiated Services (Diff-Serv) over Multi-Protocol LabelSwitching (MPLS) networks. This solution allows the MPLS network administrator to select howDiff-Serv Behavior Aggregates (BAs) are mapped onto Label SwitchedPaths (LSPs) so that he/she can best match the Diff-Serv, TrafficEngineering and protection objectives within his/her particular network. For instance, this solution allows the network administrator to decide whether different sets of BAs are to be mapped onto the same LSP or mapped onto separate LSPs.
RFC 3273	Remote Network Monitoring Management Information Base for High Capacity Networks
	Authors: S. Waldbusser. Date: July 2002 Formats: txt pdf Updated by: RFC 4502 Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it defines objects for managing remote network monitoring (RMON) devices for use on high speed networks. This document contains a MIB Module that defines these new objects and also contains definitions of some updated objects from the RMON-MIB in RFC 2819 and the RMON2-MIB in RFC 2021.
RFC 3274	Compressed Data Content Type for Cryptographic Message Syntax (CMS)
	Authors: P. Gutmann. Date: June 2002 Formats: txt pdf Status: PROPOSED STANDARD This document defines a format for using compressed data as aCryptographic Message Syntax (CMS) content type. Compressing data before transmission provides a number of advantages, including the elimination of data redundancy which could help an attacker, speeding up processing by reducing the amount of data to be processed by later steps (such as signing or encryption), and reducing overall message size. Although there have been proposals for adding compression at other levels (for example at the MIME or SSL level), these don't address the problem of compression of CMS content unless the compression is supplied by an external means (for example by intermixing MIME and CMS).
RFC 3276	Definitions of Managed Objects for High Bit-Rate DSL - 2nd generation (HDSL2) and Single-Pair High-Speed Digital Subscriber Line (SHDSL) Lines Processing
	Authors: B. Ray, R. Abbi. Date: May 2002 Formats: txt pdf Obsoleted by: RFC 4319 Status: PROPOSED STANDARD This document defines a portion of the Management Information Base(MIB) module for use with network management protocols in theInternet community. In particular, it describes objects used for managing High Bit-Rate DSL - 2nd generation (HDSL2) and Single-PairHigh-Speed Digital Subscriber Line (SHDSL) interfaces.
RFC 3279	Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
	Authors: L. Bassham, W. Polk, R. Housley. Date: April 2002 Formats: txt pdf Updated by: RFC 4055, RFC 4491, RFC 5480, RFC 5758 Status: PROPOSED STANDARD This document specifies algorithm identifiers and ASN.1 encoding formats for digital signatures and subject public keys used in theInternet X.509 Public Key Infrastructure (PKI). Digital signatures are used to sign certificates and certificate revocation list (CRLs).Certificates include the public key of the named subject.
RFC 3280	Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
	Authors: R. Housley, W. Polk, W. Ford, D. Solo. Date: April 2002 Formats: txt pdf Obsoletes: RFC 2459 Obsoleted by: RFC 5280 Updated by: RFC 4325, RFC 4630 Status: PROPOSED STANDARD This memo profiles the X.509 v3 certificate and X.509 v2 CertificateRevocation List (CRL) for use in the Internet. An overview of this approach and model are provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and twoInternet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail, and required extensions are defined. An algorithm for X.509 certification path validation is described. AnASN.1 module and examples are provided in the appendices.
RFC 3281	An Internet Attribute Certificate Profile for Authorization
	Authors: S. Farrell, R. Housley. Date: April 2002 Formats: txt pdf Obsoleted by: RFC 5755 Status: PROPOSED STANDARD This specification defines a profile for the use of X.509 AttributeCertificates in Internet Protocols. Attribute certificates may be used in a wide range of applications and environments covering a broad spectrum of interoperability goals and a broader spectrum of operational and assurance requirements. The goal of this document is to establish a common baseline for generic applications requiring broad interoperability as well as limited special purpose requirements. The profile places emphasis on attribute certificate support for Internet electronic mail, IPSec, and WWW security applications.
RFC 3284	The VCDIFF Generic Differencing and Compression Data Format
	Authors: D. Korn, J. MacDonald, J. Mogul, K. Vo. Date: June 2002 Formats: txt pdf Status: PROPOSED STANDARD This memo describes VCDIFF, a general, efficient and portable data format suitable for encoding compressed and/or differencing data so that they can be easily transported among computers.
RFC 3287	Remote Monitoring MIB Extensions for Differentiated Services
	Authors: A. Bierman. Date: July 2002 Formats: txt pdf Status: PROPOSED STANDARD 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 monitoringDifferentiated Services (DS) Codepoint usage in packets which contain a DS field, utilizing the monitoring framework defined in the RMON-2(Remote Network Monitoring Management Version 2) MIB.
RFC 3288	Using the Simple Object Access Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP)
	Authors: E. O'Tuathail, M. Rose. Date: June 2002 Formats: txt pdf Obsoleted by: RFC 4227 Status: PROPOSED STANDARD This memo specifies a Simple Object Access Protocol (SOAP) binding to the Blocks Extensible Exchange Protocol core (BEEP). A SOAP binding describes how SOAP messages are transmitted in the network. The SOAP is an XML-based (extensible markup language) messaging protocol used to implement a wide variety of distributed messaging models. It defines a message format and describes a variety of message patterns, including, but not limited to, RPC, asynchronous event notification, unacknowledged messages, and forwarding via SOAP intermediaries.
RFC 3289	Management Information Base for the Differentiated Services Architecture
	Authors: F. Baker, K. Chan, A. Smith. Date: May 2002 Formats: txt pdf Status: PROPOSED STANDARD This memo describes an SMIv2 (Structure of Management Information version 2) MIB for a device implementing the Differentiated ServicesArchitecture. It may be used both for monitoring and configuration of a router or switch capable of Differentiated Services functionality.
RFC 3291	Textual Conventions for Internet Network Addresses
	Authors: M. Daniele, B. Haberman, S. Routhier, J. Schoenwaelder. Date: May 2002 Formats: txt pdf Obsoletes: RFC 2851 Obsoleted by: RFC 4001 Status: PROPOSED STANDARD This MIB module defines textual conventions to represent commonly used Internet network layer addressing information. The intent is that these textual conventions (TCs) will be imported and used in MIB modules that would otherwise define their own representations. This document obsoletes RFC 2851.
RFC 3292	General Switch Management Protocol (GSMP) V3
	Authors: A. Doria, F. Hellstrand, K. Sundell, T. Worster. Date: June 2002 Formats: txt pdf Status: PROPOSED STANDARD This document describes the General Switch Management ProtocolVersion 3 (GSMPv3). The GSMPv3 is an asymmetric protocol that allows one or more external switch controllers to establish and maintain the state of a label switch such as, an ATM, frame relay or MPLS switch.The GSMPv3 allows control of both unicast and multicast switch connection state as well as control of switch system resources andQoS features.
RFC 3293	General Switch Management Protocol (GSMP) Packet Encapsulations for Asynchronous Transfer Mode (ATM), Ethernet and Transmission Control Protocol (TCP)
	Authors: T. Worster, A. Doria, J. Buerkle. Date: June 2002 Formats: txt pdf Status: PROPOSED STANDARD This memo specifies the encapsulation of GSMP (General SwitchManagement Protocol) packets in ATM (Asynchronous Transfer Mode),Ethernet and TCP (Transmission Control Protocol).
RFC 3295	Definitions of Managed Objects for the General Switch Management Protocol (GSMP)
	Authors: H. Sjostrand, J. Buerkle, B. Srinivasan. Date: June 2002 Formats: txt pdf Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for the use with the network management protocols in the Internet community. In particular, it describes managed objects for theGeneral Switch Management Protocol (GSMP).
RFC 3296	Named Subordinate References in Lightweight Directory Access Protocol (LDAP) Directories
	Authors: K. Zeilenga. Date: July 2002 Formats: txt pdf Status: PROPOSED STANDARD This document details schema and protocol elements for representing and managing named subordinate references in Lightweight DirectoryAccess Protocol (LDAP) Directories.
RFC 3297	Content Negotiation for Messaging Services based on Email
	Authors: G. Klyne, R. Iwazaki, D. Crocker. Date: July 2002 Formats: txt pdf Status: PROPOSED STANDARD This memo describes a content negotiation mechanism for facsimile, voice and other messaging services that use Internet email. Services such as facsimile and voice messaging need to cope with new message content formats, yet need to ensure that the content of any given message is renderable by the receiving agent. The mechanism described here aims to meet these needs in a fashion that is fully compatible with the current behaviour and expectations of Internet email.
RFC 3301	Layer Two Tunnelling Protocol (L2TP): ATM access network extensions
	Authors: Y. T'Joens, P. Crivellari, B. Sales. Date: June 2002 Formats: txt pdf Status: PROPOSED STANDARD This document augments the procedures described in RFC 2661 to further support ATM SVC (Switched Virtual Circuits) or PVC (PermanentVirtual Circuits) based access networks. L2TP (Layer 2 TunnelingProtocol) specifies a protocol for tunnelling PPP packets over packet based networks and over IP networks in particular. L2TP supports remote access by ISDN and PSTN networks. The extensions defined within this document allow for asymmetric bi-directional call establishment and service selection in the ATM access network.
RFC 3306	Unicast-Prefix-based IPv6 Multicast Addresses
	Authors: B. Haberman, D. Thaler. Date: August 2002 Formats: txt pdf Updated by: RFC 3956, RFC 4489 Status: PROPOSED STANDARD This specification defines an extension to the multicast addressing architecture of the IP Version 6 protocol. The extension presented in this document allows for unicast-prefix-based allocation of multicast addresses. By delegating multicast addresses at the same time as unicast prefixes, network operators will be able to identify their multicast addresses without needing to run an inter-domain allocation protocol.
RFC 3307	Allocation Guidelines for IPv6 Multicast Addresses
	Authors: B. Haberman. Date: August 2002 Formats: txt pdf Status: PROPOSED STANDARD This document specifies guidelines that must be implemented by any entity responsible for allocating IPv6 multicast addresses. This includes, but is not limited to, any documents or entities wishing to assign permanent IPv6 multicast addresses, allocate dynamic IPv6 multicast addresses, and define permanent IPv6 multicast group identifiers. The purpose of these guidelines is to reduce the probability of IPv6 multicast address collision, not only at the IPv6 layer, but also at the link-layer of media that encode portions of the IP layer address into the MAC layer address.
RFC 3308	Layer Two Tunneling Protocol (L2TP) Differentiated Services Extension
	Authors: P. Calhoun, W. Luo, D. McPherson, K. Peirce. Date: November 2002 Formats: txt pdf Status: PROPOSED STANDARD This document describes mechanisms which enable the Layer TwoTunneling Protocol (L2TP) to negotiate desired Per Hop Behavior (PHB) code for the L2TP control connection, as well as individual sessions within an L2TP tunnel. L2TP provides a standard method for tunneling PPP packets. The current specification provides no provisions for supportingDifferentiated Services (diffserv) over the L2TP control connection or subsequent data sessions. As a result, no standard mechanism currently exists within L2TP to provide L2TP protocol negotiations for service discrimination.
RFC 3309	Stream Control Transmission Protocol (SCTP) Checksum Change
	Authors: J. Stone, R. Stewart, D. Otis. Date: September 2002 Formats: txt pdf Obsoleted by: RFC 4960 Updates: RFC 2960 Status: PROPOSED STANDARD Stream Control Transmission Protocol (SCTP) currently uses an Adler-32 checksum. For small packets Adler-32 provides weak detection of errors. This document changes that checksum and updates SCTP to use a 32 bit CRC checksum.
RFC 3311	The Session Initiation Protocol (SIP) UPDATE Method
	Authors: J. Rosenberg. Date: October 2002 Formats: txt pdf Status: PROPOSED STANDARD This specification defines the new UPDATE method for the SessionInitiation Protocol (SIP). UPDATE allows a client to update parameters of a session (such as the set of media streams and their codecs) but has no impact on the state of a dialog. In that sense, it is like a re-INVITE, but unlike re-INVITE, it can be sent before the initial INVITE has been completed. This makes it very useful for updating session parameters within early dialogs.
RFC 3312	Integration of Resource Management and Session Initiation Protocol (SIP)
	Authors: G. Camarillo, Ed., W. Marshall, Ed., J. Rosenberg. Date: October 2002 Formats: txt pdf ps Updated by: RFC 4032, RFC 5027 Status: PROPOSED STANDARD This document defines a generic framework for preconditions, which are extensible through IANA registration. This document also discusses how network quality of service can be made a precondition for establishment of sessions initiated by the Session InitiationProtocol (SIP). These preconditions require that the participant reserve network resources before continuing with the session. We do not define new quality of service reservation mechanisms; these preconditions simply require a participant to use existing resource reservation mechanisms before beginning the session.
RFC 3315	Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
	Authors: R. Droms, Ed., J. Bound, B. Volz, T. Lemon, C. Perkins, M. Carney. Date: July 2003 Formats: txt pdf Updated by: RFC 4361, RFC 5494, RFC 6221, RFC 6422 Status: PROPOSED STANDARD The Dynamic Host Configuration Protocol for IPv6 (DHCP) enables DHCP servers to pass configuration parameters such as IPv6 network addresses to IPv6 nodes. It offers the capability of automatic allocation of reusable network addresses and additional configuration flexibility. This protocol is a stateful counterpart to "IPv6Stateless Address Autoconfiguration" (RFC 2462), and can be used separately or concurrently with the latter to obtain configuration parameters.
RFC 3319	Dynamic Host Configuration Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) Servers
	Authors: H. Schulzrinne, B. Volz. Date: July 2003 Formats: txt pdf Status: PROPOSED STANDARD This document defines a Dynamic Host Configuration Protocol version 6(DHCPv6) option that contains a list of domain names or IPv6 addresses that can be mapped to one or more Session InitiationProtocol (SIP) outbound proxy servers. This is one of the many methods that a SIP client can use to obtain the addresses of such a local SIP server.
RFC 3320	Signaling Compression (SigComp)
	Authors: R. Price, C. Bormann, J. Christoffersson, H. Hannu, Z. Liu, J. Rosenberg. Date: January 2003 Formats: txt pdf Updated by: RFC 4896 Status: PROPOSED STANDARD This document defines Signaling Compression (SigComp), a solution for compressing messages generated by application protocols such as theSession Initiation Protocol (SIP) (RFC 3261) and the Real TimeStreaming Protocol (RTSP) (RFC 2326). The architecture and prerequisites of SigComp are outlined, along with the format of theSigComp message. Decompression functionality for SigComp is provided by a UniversalDecompressor Virtual Machine (UDVM) optimized for the task of running decompression algorithms. The UDVM can be configured to understand the output of many well-known compressors such as DEFLATE (RFC-1951).
RFC 3321	Signaling Compression (SigComp) - Extended Operations
	Authors: H. Hannu, J. Christoffersson, S. Forsgren, K.-C. Leung, Z. Liu, R. Price. Date: January 2003 Formats: txt pdf Updated by: RFC 4896 Status: PROPOSED STANDARD This document describes how to implement certain mechanisms inSignaling Compression (SigComp), RFC 3320, which can significantly improve the compression efficiency compared to using simple per- message compression. SigComp uses a Universal Decompressor Virtual Machine (UDVM) for decompression, and the mechanisms described in this document are possible to implement using the UDVM instructions defined in RFC3320.
RFC 3323	A Privacy Mechanism for the Session Initiation Protocol (SIP)
	Authors: J. Peterson. Date: November 2002 Formats: txt pdf Status: PROPOSED STANDARD This document defines new mechanisms for the Session InitiationProtocol (SIP) in support of privacy. Specifically, guidelines are provided for the creation of messages that do not divulge personal identity information. A new "privacy service" logical role for intermediaries is defined to answer some privacy requirements that user agents cannot satisfy themselves. Finally, means are presented by which a user can request particular functions from a privacy service.
RFC 3326	The Reason Header Field for the Session Initiation Protocol (SIP)
	Authors: H. Schulzrinne, D. Oran, G. Camarillo. Date: December 2002 Formats: txt pdf Status: PROPOSED STANDARD For creating services, it is often useful to know why a SessionInitiation Protocol (SIP) request was issued. This document defines a header field, Reason, that provides this information. The Reason header field is also intended to be used to encapsulate a final status code in a provisional response. This functionality is needed to resolve the "Heterogeneous Error Response Forking Problem", orHERFP.
RFC 3327	Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts
	Authors: D. Willis, B. Hoeneisen. Date: December 2002 Formats: txt pdf Updated by: RFC 5626 Status: PROPOSED STANDARD The REGISTER function is used in a Session Initiation Protocol (SIP) system primarily to associate a temporary contact address with an address-of-record. This contact is generally in the form of aUniform Resource Identifier (URI), such as Contact:<sip:alice@pc33.atlanta.com&rt; and is generally dynamic and associated with the IP address or hostname of the SIP User Agent (UA). The problem is that network topology may have one or more SIP proxies between the UA and the registrar, such that any request traveling from the user's home network to the registered UA must traverse these proxies. The REGISTER method does not give us a mechanism to discover and record this sequence of proxies in the registrar for future use. This document defines an extension header field, "Path" which provides such a mechanism.
RFC 3329	Security Mechanism Agreement for the Session Initiation Protocol (SIP)
	Authors: J. Arkko, V. Torvinen, G. Camarillo, A. Niemi, T. Haukka. Date: January 2003 Formats: txt pdf Status: PROPOSED STANDARD This document defines new functionality for negotiating the security mechanisms used between a Session Initiation Protocol (SIP) user agent and its next-hop SIP entity. This new functionality supplements the existing methods of choosing security mechanisms between SIP entities.
RFC 3331	Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) - User Adaptation Layer
	Authors: K. Morneault, R. Dantu, G. Sidebottom, B. Bidulock, J. Heitz. Date: September 2002 Formats: txt pdf Status: PROPOSED STANDARD This document defines a protocol for the backhauling of SignalingSystem 7 Message Transfer Part 2 (SS7 MTP2) User signalling messages over IP using the Stream Control Transmission Protocol (SCTP). This protocol would be used between a Signalling Gateway (SG) and MediaGateway Controller (MGC). It is assumed that the SG receives SS7 signalling over a standard SS7 interface using the SS7 MessageTransfer Part (MTP) to provide transport. The Signalling Gateway would act as a Signalling Link Terminal.
RFC 3332	Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA)
	Authors: G. Sidebottom, Ed., K. Morneault, Ed., J. Pastor-Balbas, Ed.. Date: September 2002 Formats: txt pdf Obsoleted by: RFC 4666 Status: PROPOSED STANDARD This memo defines a protocol for supporting the transport of any SS7MTP3-User signalling (e.g., ISUP and SCCP messages) over IP using the services of the Stream Control Transmission Protocol. Also, provision is made for protocol elements that enable a seamless operation of the MTP3-User peers in the SS7 and IP domains. This protocol would be used between a Signalling Gateway (SG) and a MediaGateway Controller (MGC) or IP-resident Database, or between twoIP-based applications. It is assumed that the SG receives SS7 signalling over a standard SS7 interface using the SS7 MessageTransfer Part (MTP) to provide transport.
RFC 3335	MIME-based Secure Peer-to-Peer Business Data Interchange over the Internet
	Authors: T. Harding, R. Drummond, C. Shih. Date: September 2002 Formats: txt pdf Status: PROPOSED STANDARD This document describes how to exchange structured business data securely using SMTP transport for Electronic Data Interchange, (EDI - either the American Standards Committee X12 or UN/EDIFACT, ElectronicData Interchange for Administration, Commerce and Transport), XML or other data used for business to business data interchange. The data is packaged using standard MIME content-types. Authentication and privacy are obtained by using Cryptographic Message Syntax (S/MIME) or OpenPGP security body parts. Authenticated acknowledgements make use of multipart/signed replies to the original SMTP message.
RFC 3336	PPP Over Asynchronous Transfer Mode Adaptation Layer 2 (AAL2)
	Authors: B. Thompson, T. Koren, B. Buffam. Date: December 2002 Formats: txt pdf Status: PROPOSED STANDARD The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. This document describes the use of ATM Adaptation Layer 2 (AAL2) for framing PPP encapsulated packets.
RFC 3337	Class Extensions for PPP over Asynchronous Transfer Mode Adaptation Layer 2
	Authors: B. Thompson, T. Koren, B. Buffam. Date: December 2002 Formats: txt pdf Status: PROPOSED STANDARD The Point-to-Point Protocol (PPP) over Asynchronous Transfer Mode(ATM) Adaptation Layer 2 defines the encapsulation that allows a PPP session to be transported over an ATM virtual circuit using the ATMAdaptation Layer 2 (AAL2) adaptation layer. This document defines a set of class extensions to PPP over AAL2 that implement equivalent functionality to Multi Class Multi Link PPP over a single ATM virtual circuit. Instead of using Multi Link PPP as the basis for fragmentation functionality, this document uses the functionality of the Segmentation and Reassembly Service Specific Convergence Sublayer that is already required as the basic encapsulation format of PPP over AAL2.
RFC 3339	Date and Time on the Internet: Timestamps
	Authors: G. Klyne, C. Newman. Date: July 2002 Formats: txt pdf Status: PROPOSED STANDARD This document defines a date and time format for use in Internet protocols that is a profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
RFC 3340	The Application Exchange Core
	Authors: M. Rose, G. Klyne, D. Crocker. Date: July 2002 Formats: txt pdf Status: PROPOSED STANDARD This memo describes Application Exchange (APEX) Core, an extensible, asynchronous message relaying service for application layer programs.
RFC 3341	The Application Exchange (APEX) Access Service
	Authors: M. Rose, G. Klyne, D. Crocker. Date: July 2002 Formats: txt pdf Status: PROPOSED STANDARD This memo describes the Application Exchange (APEX) access service, addressed as the well-known endpoint "apex=access". The access service is used to control use of both the APEX "relaying mesh" and other APEX services.
RFC 3342	The Application Exchange (APEX) Option Party Pack, Part Deux!
	Authors: E. Dixon, H. Franklin, J. Kint, G. Klyne, D. New, S. Pead, M. Rose, M. Schwartz. Date: July 2002 Formats: txt pdf Status: PROPOSED STANDARD Application Exchange (APEX), at its core, provides a best-effort application-layer datagram service. Options are used to alter the semantics of the core service. This memo defines various options to change the default behavior of APEX's "relaying mesh".
RFC 3344	IP Mobility Support for IPv4
	Authors: C. Perkins, Ed.. Date: August 2002 Formats: txt pdf Obsoletes: RFC 3220 Obsoleted by: RFC 5944 Updated by: RFC 4721 Status: PROPOSED STANDARD This document specifies protocol enhancements that allow transparent routing of IP datagrams to mobile nodes in the Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about its current point of attachment to the Internet. The protocol provides for registering the care-of address with a home agent. The home agent sends datagrams destined for the mobile node through a tunnel to the care- of address. After arriving at the end of the tunnel, each datagram is then delivered to the mobile node.
RFC 3347	Small Computer Systems Interface protocol over the Internet (iSCSI) Requirements and Design Considerations
	Authors: M. Krueger, R. Haagens. Date: July 2002 Formats: txt pdf Status: PROPOSED STANDARD This document specifies the requirements iSCSI and its related infrastructure should satisfy and the design considerations guiding the iSCSI protocol development efforts. In the interest of timely adoption of the iSCSI protocol, the IPS group has chosen to focus the first version of the protocol to work with the existing SCSI architecture and commands, and the existing TCP/IP transport layer.Both these protocols are widely-deployed and well-understood. The thought is that using these mature protocols will entail a minimum of new invention, the most rapid possible adoption, and the greatest compatibility with Internet architecture, protocols, and equipment.
RFC 3355	Layer Two Tunnelling Protocol (L2TP) Over ATM Adaptation Layer 5 (AAL5)
	Authors: A. Singh, R. Turner, R. Tio, S. Nanji. Date: August 2002 Formats: txt pdf Status: PROPOSED STANDARD The Layer Two Tunneling Protocol (L2TP) provides a standard method for transporting the link layer of the Point-to-Point Protocol (PPP) between a dial-up server and a Network Access Server, using a network connection in lieu of a physical point-to-point connection. This document describes the use of an Asynchronous Transfer Mode (ATM) network for the underlying network connection. ATM User-NetworkInterface (UNI) Signaling Specification Version 4.0 or Version 3.1 with ATM Adaptation Layer 5 (AAL5) are supported as interfaces to theATM network.
RFC 3361	Dynamic Host Configuration Protocol (DHCP-for-IPv4) Option for Session Initiation Protocol (SIP) Servers
	Authors: H. Schulzrinne. Date: August 2002 Formats: txt pdf Status: PROPOSED STANDARD This document defines a Dynamic Host Configuration Protocol(DHCP-for-IPv4) option that contains a list of domain names or IPv4 addresses that can be mapped to one or more Session InitiationProtocol (SIP) outbound proxy servers. This is one of the many methods that a SIP client can use to obtain the addresses of such a local SIP server.
RFC 3362	Real-time Facsimile (T.38) - image/t38 MIME Sub-type Registration
	Authors: G. Parsons. Date: August 2002 Formats: txt pdf Status: PROPOSED STANDARD This document describes the registration of the MIME sub-type image/t38. The encoding is defined by ITU Recommendation T.38 and is intended for use as an Session Description Protocol (SDP) media descriptor.
RFC 3367	Common Name Resolution Protocol (CNRP)
	Authors: N. Popp, M. Mealling, M. Moseley. Date: August 2002 Formats: txt pdf Status: PROPOSED STANDARD People often refer to things in the real world by a common name or phrase, e.g., a trade name, company name, or a book title. These names are sometimes easier for people to remember and type than URLs.Furthermore, because of the limited syntax of URLs, companies and individuals are finding that the ones that might be most reasonable for their resources are being used elsewhere and so are unavailable.For the purposes of this document, a "common name" is a word or a phrase, without imposed syntactic structure, that may be associated with a resource. This effort is about the creation of a protocol for client applications to communicate with common name resolution services, as exemplified in both the browser enhancement and search site paradigms. Although the protocol's primary function is resolution, it is also intended to address issues of internationalization and localization. Name resolution services are not generic search services and thus do not need to provide complex Boolean query, relevance ranking or similar capabilities. The protocol is a simple, minimal interoperable core. Mechanisms for extension are provided, so that additional capabilities can be added.
RFC 3368	The 'go' URI Scheme for the Common Name Resolution Protocol
	Authors: M. Mealling. Date: August 2002 Formats: txt pdf Status: PROPOSED STANDARD This document defines a URI scheme, 'go:' to be used with the CommonName Resolution Protocol. Specifically it lays out the syntactic components and how those components are used by URI Resolution to find the available transports for a CNRP service. Care should be taken with several of the URI components because, while they may look like components found in other URI schemes, they often do not act like them. The "go" scheme has more in common with the location independent "news" scheme than any other URI scheme.
RFC 3369	Cryptographic Message Syntax (CMS)
	Authors: R. Housley. Date: August 2002 Formats: txt pdf Obsoletes: RFC 2630, RFC 3211 Obsoleted by: RFC 3852 Status: PROPOSED STANDARD This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content.
RFC 3370	Cryptographic Message Syntax (CMS) Algorithms
	Authors: R. Housley. Date: August 2002 Formats: txt pdf Obsoletes: RFC 2630, RFC 3211 Updated by: RFC 5754 Status: PROPOSED STANDARD This document describes the conventions for using several cryptographic algorithms with the Cryptographic Message Syntax (CMS).The CMS is used to digitally sign, digest, authenticate, or encrypt arbitrary message contents.
RFC 3371	Layer Two Tunneling Protocol "L2TP" Management Information Base
	Authors: E. Caves, P. Calhoun, R. Wheeler. Date: August 2002 Formats: txt pdf Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it defines objects for managing networks using Layer 2Tunneling Protocol (L2TP).
RFC 3376	Internet Group Management Protocol, Version 3
	Authors: B. Cain, S. Deering, I. Kouvelas, B. Fenner, A. Thyagarajan. Date: October 2002 Formats: txt pdf Obsoletes: RFC 2236 Updated by: RFC 4604 Status: PROPOSED STANDARD This document specifies Version 3 of the Internet Group ManagementProtocol, IGMPv3. IGMP is the protocol used by IPv4 systems to report their IP multicast group memberships to neighboring multicast routers. Version 3 of IGMP adds support for "source filtering", that is, the ability for a system to report interest in receiving packets*only* from specific source addresses, or from *all but* specific source addresses, sent to a particular multicast address. That information may be used by multicast routing protocols to avoid delivering multicast packets from specific sources to networks where there are no interested receivers. This document obsoletes RFC 2236.
RFC 3377	Lightweight Directory Access Protocol (v3): Technical Specification
	Authors: J. Hodges, R. Morgan. Date: September 2002 Formats: txt pdf Obsoleted by: RFC 4510 Updates: RFC 2251, RFC 2252, RFC 2253, RFC 2254, RFC 2255, RFC 2256, RFC 2829, RFC 2830 Status: PROPOSED STANDARD This document specifies the set of RFCs comprising the LightweightDirectory Access Protocol Version 3 (LDAPv3), and addresses the "IESGNote" attached to RFCs 2251 through 2256.
RFC 3380	Internet Printing Protocol (IPP): Job and Printer Set Operations
	Authors: T. Hastings, R. Herriot, C. Kugler, H. Lewis. Date: September 2002 Formats: txt pdf Updates: RFC 2910, RFC 2911 Status: PROPOSED STANDARD This document is an OPTIONAL extension to the Internet PrintingProtocol (IPP/1.0 and IPP/1.1). This document specifies 3 additionalOPTIONAL operations for use with the Internet Printing Protocol/1.0(IPP) and IPP/1.1. The end user, operator, and administrator Set-Job-Attributes and Set-Printer-Attributes operations are used to modify IPP Job objects and Printer objects, respectively. The Get-Printer-Supported-Values administrative operation returns values that the IPP Printer will accept for setting its "xxx-supported" attributes.
RFC 3381	Internet Printing Protocol (IPP): Job Progress Attributes
	Authors: T. Hastings, H. Lewis, R. Bergman. Date: September 2002 Formats: txt pdf Updates: RFC 2910 Status: PROPOSED STANDARD This document defines four new Job Description attributes for monitoring job progress to be registered as OPTIONAL extensions to the Internet Printing Protocol (IPP/1.0 and IPP/1.1). These attributes are drawn from the PWG Job Monitoring MIB. This document also defines a new "sheet-collate" Job Template attribute to control sheet collation and to help with the interpretation of the job progress attributes.
RFC 3382	Internet Printing Protocol (IPP): The 'collection' attribute syntax
	Authors: R. deBry, T. Hastings, R. Herriot, K. Ocke, P. Zehler. Date: September 2002 Formats: txt pdf Updates: RFC 2910, RFC 2911 Status: PROPOSED STANDARD This document specifies an OPTIONAL attribute syntax called'collection' for use with the Internet Printing Protocol (IPP/1.0 andIPP/1.1). A 'collection' is a container holding one or more named values, which are called "member" attributes. A collection allows data to be grouped like a PostScript dictionary or a Java Map. This document also specifies the conformance requirements for a definition document that defines a collection attribute. Finally, this document gives some illustrative example collection attribute definitions that are not intended as actual attribute specifications.
RFC 3388	Grouping of Media Lines in the Session Description Protocol (SDP)
	Authors: G. Camarillo, G. Eriksson, J. Holler, H. Schulzrinne. Date: December 2002 Formats: txt pdf Obsoleted by: RFC 5888 Status: PROPOSED STANDARD This document defines two Session Description Protocol (SDP) attributes: "group" and "mid". They allow to group together several"m" lines for two different purposes: for lip synchronization and for receiving media from a single flow (several media streams) that are encoded in different formats during a particular session, on different ports and host interfaces.
RFC 3389	Real-time Transport Protocol (RTP) Payload for Comfort Noise (CN)
	Authors: R. Zopf. Date: September 2002 Formats: txt pdf Status: PROPOSED STANDARD This document describes a Real-time Transport Protocol (RTP) payload format for transporting comfort noise (CN). The CN payload type is primarily for use with audio codecs that do not support comfort noise as part of the codec itself such as ITU-T Recommendations G.711,G.726, G.727, G.728, and G.722.
RFC 3390	Increasing TCP's Initial Window
	Authors: M. Allman, S. Floyd, C. Partridge. Date: October 2002 Formats: txt pdf Obsoletes: RFC 2414 Updates: RFC 2581 Status: PROPOSED STANDARD This document specifies an optional standard for TCP to increase the permitted initial window from one or two segment(s) to roughly 4K bytes, replacing RFC 2414. It discusses the advantages and disadvantages of the higher initial window, and includes discussion of experiments and simulations showing that the higher initial window does not lead to congestion collapse. Finally, this document provides guidance on implementation issues.
RFC 3393	IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)
	Authors: C. Demichelis, P. Chimento. Date: November 2002 Formats: txt pdf Status: PROPOSED STANDARD This document refers to a metric for variation in delay of packets across Internet paths. The metric is based on the difference in theOne-Way-Delay of selected packets. This difference in delay is called "IP Packet Delay Variation (ipdv)". The metric is valid for measurements between two hosts both in the case that they have synchronized clocks and in the case that they are not synchronized. We discuss both in this document.
RFC 3395	Remote Network Monitoring MIB Protocol Identifier Reference Extensions
	Authors: A. Bierman, C. Bucci, R. Dietz, A. Warth. Date: September 2002 Formats: txt pdf Updates: RFC 2895 Status: PROPOSED STANDARD This memo defines extensions to the Protocol Identifier Reference document for the identification of application verb information. It updates the Protocol Identifier Reference document but does not obsolete any portion of that document. In particular, it describes the algorithms required to identify protocol operations (verbs) within the protocol encapsulations managed with MIBs such as theRemote Network Monitoring MIB Version 2, RFC 2021.
RFC 3396	Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)
	Authors: T. Lemon, S. Cheshire. Date: November 2002 Formats: txt pdf Updates: RFC 2131 Status: PROPOSED STANDARD This document specifies the processing rules for Dynamic HostConfiguration Protocol (DHCPv4) options that appear multiple times in the same message. Multiple instances of the same option are generated when an option exceeds 255 octets in size (the maximum size of a single option) or when an option needs to be split apart in order to take advantage of DHCP option overloading. When multiple instances of the same option appear in the options, file and/or sname fields in a DHCP packet, the contents of these options are concatenated together to form a single option prior to processing.
RFC 3397	Dynamic Host Configuration Protocol (DHCP) Domain Search Option
	Authors: B. Aboba, S. Cheshire. Date: November 2002 Formats: txt pdf Status: PROPOSED STANDARD This document defines a new Dynamic Host Configuration Protocol(DHCP) option which is passed from the DHCP Server to the DHCP Client to specify the domain search list used when resolving hostnames usingDNS.
RFC 3398	Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping
	Authors: G. Camarillo, A. B. Roach, J. Peterson, L. Ong. Date: December 2002 Formats: txt pdf Status: PROPOSED STANDARD This document describes a way to perform the mapping between two signaling protocols: the Session Initiation Protocol (SIP) and theIntegrated Services Digital Network (ISDN) User Part (ISUP) ofSignaling System No. 7 (SS7). This mechanism might be implemented when using SIP in an environment where part of the call involves interworking with the Public Switched Telephone Network (PSTN).
RFC 3402	Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm
	Authors: M. Mealling. Date: October 2002 Formats: txt pdf Obsoletes: RFC 2915, RFC 2168 Status: PROPOSED STANDARD This document describes the Dynamic Delegation Discovery System(DDDS) algorithm for applying dynamically retrieved string transformation rules to an application-unique string. Well-formed transformation rules will reflect the delegation of management of information associated with the string. This document is also part of a series that is completely specified in "Dynamic DelegationDiscovery System (DDDS) Part One: The Comprehensive DDDS" (RFC 3401).It is very important to note that it is impossible to read and understand any document in this series without reading the others.
RFC 3403	Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database
	Authors: M. Mealling. Date: October 2002 Formats: txt pdf Obsoletes: RFC 2915, RFC 2168 Status: PROPOSED STANDARD This document describes a Dynamic Delegation Discovery System (DDDS)Database using the Domain Name System (DNS) as a distributed database of Rules. The Keys are domain-names and the Rules are encoded using the Naming Authority Pointer (NAPTR) Resource Record (RR). Since this document obsoletes RFC 2915, it is the official specification for the NAPTR DNS Resource Record. It is also part of a series that is completely specified in "Dynamic DelegationDiscovery System (DDDS) Part One: The Comprehensive DDDS" (RFC 3401).It is very important to note that it is impossible to read and understand any document in this series without reading the others.
RFC 3404	Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)
	Authors: M. Mealling. Date: October 2002 Formats: txt pdf Obsoletes: RFC 2915, RFC 2168 Status: PROPOSED STANDARD This document describes a specification for taking Uniform ResourceIdentifiers (URI) and locating an authoritative server for information about that URI. The method used to locate that authoritative server is the Dynamic Delegation Discovery System. This document is part of a series that is specified in "DynamicDelegation Discovery System (DDDS) Part One: The Comprehensive DDDS"(RFC 3401). It is very important to note that it is impossible to read and understand any document in this series without reading the others.
RFC 3407	Session Description Protocol (SDP) Simple Capability Declaration
	Authors: F. Andreasen. Date: October 2002 Formats: txt pdf Status: PROPOSED STANDARD This document defines a set of Session Description Protocol (SDP) attributes that enables SDP to provide a minimal and backwards compatible capability declaration mechanism. Such capability declarations can be used as input to a subsequent session negotiation, which is done by means outside the scope of this document. This provides a simple and limited solution to the general capability negotiation problem being addressed by the next generation of SDP, also known as SDPng.
RFC 3408	Zero-byte Support for Bidirectional Reliable Mode (R-mode) in Extended Link-Layer Assisted RObust Header Compression (ROHC) Profile
	Authors: Z. Liu, K. Le. Date: December 2002 Formats: txt pdf Status: PROPOSED STANDARD This document defines an additional mode of the link-layer assistedRObust Header Compression (ROHC) profile, also known as the zero-byte profile, beyond the two defined in RFC 3242. Zero-byte header compression exists in order to prevent the single-octet ROHC header from pushing a packet voice stream into the next higher fixed packet size for the radio. It is usable in certain widely deployed older air interfaces. This document adds the zero-byte operation for ROHCBidirectional Reliable mode (R-mode) to the ones specified forUnidirectional (U-mode) and Bidirectional Optimistic (O-mode) modes of header compression in RFC 3242.
RFC 3419	Textual Conventions for Transport Addresses
	Authors: M. Daniele, J. Schoenwaelder. Date: December 2002 Formats: txt pdf Status: PROPOSED STANDARD This document introduces a Management Information Base (MIB) module that defines textual conventions to represent commonly used transport-layer addressing information. The definitions are compatible with the concept of TAddress/TDomain pairs introduced by the Structure of Management Information version 2 (SMIv2) and support the Internet transport protocols over IPv4 and IPv6.
RFC 3420	Internet Media Type message/sipfrag
	Authors: R. Sparks. Date: November 2002 Formats: txt pdf Status: PROPOSED STANDARD This document registers the message/sipfrag Multipurpose InternetMail Extensions (MIME) media type. This type is similar to message/sip, but allows certain subsets of well formed SessionInitiation Protocol (SIP) messages to be represented instead of requiring a complete SIP message. In addition to end-to-end security uses, message/sipfrag is used with the REFER method to convey information about the status of a referenced request.
RFC 3425	Obsoleting IQUERY
	Authors: D. Lawrence. Date: November 2002 Formats: txt pdf Updates: RFC 1035 Status: PROPOSED STANDARD The IQUERY method of performing inverse DNS lookups, specified in RFC1035, has not been generally implemented and has usually been operationally disabled where it has been implemented. Both reflect a general view in the community that the concept was unwise and that the widely-used alternate approach of using pointer (PTR) queries and reverse-mapping records is preferable. Consequently, this document deprecates the IQUERY operation, declaring it entirely obsolete.This document updates RFC 1035.
RFC 3428	Session Initiation Protocol (SIP) Extension for Instant Messaging
	Authors: B. Campbell, Ed., J. Rosenberg, H. Schulzrinne, C. Huitema, D. Gurle. Date: December 2002 Formats: txt pdf Status: PROPOSED STANDARD Instant Messaging (IM) refers to the transfer of messages between users in near real-time. These messages are usually, but not required to be, short. IMs are often used in a conversational mode, that is, the transfer of messages back and forth is fast enough for participants to maintain an interactive conversation. This document proposes the MESSAGE method, an extension to theSession Initiation Protocol (SIP) that allows the transfer of InstantMessages. Since the MESSAGE request is an extension to SIP, it inherits all the request routing and security features of that protocol. MESSAGE requests carry the content in the form of MIME body parts. MESSAGE requests do not themselves initiate a SIP dialog; under normal usage each Instant Message stands alone, much like pager messages. MESSAGE requests may be sent in the context of a dialog initiated by some other SIP request.
RFC 3431	Sieve Extension: Relational Tests
	Authors: W. Segmuller. Date: December 2002 Formats: txt pdf Obsoleted by: RFC 5231 Status: PROPOSED STANDARD This document describes the RELATIONAL extension to the Sieve mail filtering language defined in RFC 3028. This extension extends existing conditional tests in Sieve to allow relational operators.In addition to testing their content, it also allows for testing of the number of entities in header and envelope fields.
RFC 3432	Network performance measurement with periodic streams
	Authors: V. Raisanen, G. Grotefeld, A. Morton. Date: November 2002 Formats: txt pdf Status: PROPOSED STANDARD This memo describes a periodic sampling method and relevant metrics for assessing the performance of IP networks. First, the memo motivates periodic sampling and addresses the question of its value as an alternative to the Poisson sampling described in RFC 2330. The benefits include applicability to active and passive measurements, simulation of constant bit rate (CBR) traffic (typical of multimedia communication, or nearly CBR, as found with voice activity detection), and several instances in which analysis can be simplified. The sampling method avoids predictability by mandating random start times and finite length tests. Following descriptions of the sampling method and sample metric parameters, measurement methods and errors are discussed. Finally, we give additional information on periodic measurements, including security considerations.
RFC 3433	Entity Sensor Management Information Base
	Authors: A. Bierman, D. Romascanu, K.C. Norseth. Date: December 2002 Formats: txt pdf Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes managed objects for extending the EntityMIB (RFC 2737) to provide generalized access to information related to physical sensors, which are often found in networking equipment(such as chassis temperature, fan RPM, power supply voltage).
RFC 3434	Remote Monitoring MIB Extensions for High Capacity Alarms
	Authors: A. Bierman, K. McCloghrie. Date: December 2002 Formats: txt pdf Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes managed objects for extending the alarm thresholding capabilities found in the Remote Monitoring (RMON) MIB(RFC 2819), to provide similar threshold monitoring of objects based on the Counter64 data type.
RFC 3436	Transport Layer Security over Stream Control Transmission Protocol
	Authors: A. Jungmaier, E. Rescorla, M. Tuexen. Date: December 2002 Formats: txt pdf Status: PROPOSED STANDARD This document describes the usage of the Transport Layer Security(TLS) protocol, as defined in RFC 2246, over the Stream ControlTransmission Protocol (SCTP), as defined in RFC 2960 and RFC 3309. The user of TLS can take advantage of the features provided by SCTP, namely the support of multiple streams to avoid head of line blocking and the support of multi-homing to provide network level fault tolerance. Additionally, discussions of extensions of SCTP are also supported, meaning especially the support of dynamic reconfiguration of IP- addresses.
RFC 3437	Layer-Two Tunneling Protocol Extensions for PPP Link Control Protocol Negotiation
	Authors: W. Palter, W. Townsley. Date: December 2002 Formats: txt pdf Status: PROPOSED STANDARD This document defines extensions to the Layer Two Tunneling Protocol(L2TP) for enhanced support of link-specific Point to Point Protocol(PPP) options. PPP endpoints typically have direct access to the common physical media connecting them and thus have detailed knowledge about the media that is in use. When the L2TP is used, the two PPP peers are no longer directly connected over the same physical media. Instead, L2TP inserts a virtual connection over some or all of the PPP connection by tunneling PPP frames over a packet switched network such as IP. Under some conditions, an L2TP endpoint may need to negotiate PPP Link Control Protocol (LCP) options at a location which may not have access to all of the media information necessary for proper participation in the LCP negotiation. This document provides a mechanism for communicating desired LCP options betweenL2TP endpoints in advance of PPP LCP negotiation at the far end of anL2TP tunnel, as well as a mechanism for communicating the negotiatedLCP options back to where the native PPP link resides.
RFC 3440	Definitions of Extension Managed Objects for Asymmetric Digital Subscriber Lines
	Authors: F. Ly, G. Bathrick. Date: December 2002 Formats: txt pdf Status: PROPOSED STANDARD 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 additional managed objects used for managing Asymmetric Digital Subscriber Line (ADSL) interfaces not covered by the ADSL Line MIB (RFC 2662).
RFC 3442	The Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP) version 4
	Authors: T. Lemon, S. Cheshire, B. Volz. Date: December 2002 Formats: txt pdf Updates: RFC 2132 Status: PROPOSED STANDARD This document defines a new Dynamic Host Configuration Protocol(DHCP) option which is passed from the DHCP Server to the DHCP Client to configure a list of static routes in the client. The network destinations in these routes are classless - each routing table entry includes a subnet mask.
RFC 3443	Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks
	Authors: P. Agarwal, B. Akyol. Date: January 2003 Formats: txt pdf Updates: RFC 3032 Updated by: RFC 5462 Status: PROPOSED STANDARD This document describes Time To Live (TTL) processing in hierarchicalMulti-Protocol Label Switching (MPLS) networks and is motivated by the need to formalize a TTL-transparent mode of operation for an MPLS label-switched path. It updates RFC 3032, "MPLS Label StackEncoding". TTL processing in both Pipe and Uniform Model hierarchical tunnels are specified with examples for both "push" and"pop" cases. The document also complements RFC 3270, "MPLS Support of Differentiated Services" and ties together the terminology introduced in that document with TTL processing in hierarchical MPLS networks.
RFC 3445	Limiting the Scope of the KEY Resource Record (RR)
	Authors: D. Massey, S. Rose. Date: December 2002 Formats: txt pdf Obsoleted by: RFC 4033, RFC 4034, RFC 4035 Updates: RFC 2535 Status: PROPOSED STANDARD This document limits the Domain Name System (DNS) KEY Resource Record(RR) to only keys used by the Domain Name System Security Extensions(DNSSEC). The original KEY RR used sub-typing to store both DNSSEC keys and arbitrary application keys. Storing both DNSSEC and application keys with the same record type is a mistake. This document removes application keys from the KEY record by redefining the Protocol Octet field in the KEY RR Data. As a result of removing application keys, all but one of the flags in the KEY record become unnecessary and are redefined. Three existing application key sub- types are changed to reserved, but the format of the KEY record is not changed. This document updates RFC 2535.
RFC 3448	TCP Friendly Rate Control (TFRC): Protocol Specification
	Authors: M. Handley, S. Floyd, J. Padhye, J. Widmer. Date: January 2003 Formats: txt pdf Obsoleted by: RFC 5348 Status: PROPOSED STANDARD This document specifies TCP-Friendly Rate Control (TFRC). TFRC is a congestion control mechanism for unicast flows operating in a best- effort Internet environment. It is reasonably fair when competing for bandwidth with TCP flows, but has a much lower variation of throughput over time compared with TCP, making it more suitable for applications such as telephony or streaming media where a relatively smooth sending rate is of importance.
RFC 3454	Preparation of Internationalized Strings ("stringprep")
	Authors: P. Hoffman, M. Blanchet. Date: December 2002 Formats: txt pdf Status: PROPOSED STANDARD This document describes a framework for preparing Unicode text strings in order to increase the likelihood that string input and string comparison work in ways that make sense for typical users throughout the world. The stringprep protocol is useful for protocol identifier values, company and personal names, internationalized domain names, and other text strings. This document does not specify how protocols should prepare text strings. Protocols must create profiles of stringprep in order to fully specify the processing options.
RFC 3456	Dynamic Host Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel Mode
	Authors: B. Patel, B. Aboba, S. Kelly, V. Gupta. Date: January 2003 Formats: txt pdf Status: PROPOSED STANDARD This memo explores the requirements for host configuration in IPsec tunnel mode, and describes how the Dynamic Host ConfigurationProtocol (DHCPv4) may be leveraged for configuration. In many remote access scenarios, a mechanism for making the remote host appear to be present on the local corporate network is quite useful. This may be accomplished by assigning the host a "virtual" address from the corporate network, and then tunneling traffic via IPsec from the host's ISP-assigned address to the corporate security gateway. InIPv4, DHCP provides for such remote host configuration.
RFC 3458	Message Context for Internet Mail
	Authors: E. Burger, E. Candell, C. Eliot, G. Klyne. Date: January 2003 Formats: txt pdf Updated by: RFC 3938 Status: PROPOSED STANDARD This memo describes a new RFC 2822 message header, "Message-Context".This header provides information about the context and presentation characteristics of a message. A receiving user agent (UA) may use this information as a hint to optimally present the message.
RFC 3459	Critical Content Multi-purpose Internet Mail Extensions (MIME) Parameter
	Authors: E. Burger. Date: January 2003 Formats: txt pdf Updates: RFC 3204 Updated by: RFC 5621 Status: PROPOSED STANDARD This document describes the use of a mechanism for identifying body parts that a sender deems critical in a multi-part Internet mail message. The mechanism described is a parameter to Content-Disposition, as described by RFC 3204. By knowing what parts of a message the sender deems critical, a content gateway can intelligently handle multi-part messages when providing gateway services to systems of lesser capability. Critical content can help a content gateway to decide what parts to forward.It can indicate how hard a gateway should try to deliver a body part.It can help the gateway to pick body parts that are safe to silently delete when a system of lesser capability receives a message. In addition, critical content can help the gateway chose the notification strategy for the receiving system. Likewise, if the sender expects the destination to do some processing on a body part, critical content allows the sender to mark body parts that the receiver must process.
RFC 3460	Policy Core Information Model (PCIM) Extensions
	Authors: B. Moore, Ed.. Date: January 2003 Formats: txt pdf Updates: RFC 3060 Status: PROPOSED STANDARD This document specifies a number of changes to the Policy CoreInformation Model (PCIM, RFC 3060). Two types of changes are included. First, several completely new elements are introduced, for example, classes for header filtering, that extend PCIM into areas that it did not previously cover. Second, there are cases where elements of PCIM (for example, policy rule priorities) are deprecated, and replacement elements are defined (in this case, priorities tied to associations that refer to policy rules). Both types of changes are done in such a way that, to the extent possible, interoperability with implementations of the original PCIM model is preserved. This document updates RFC 3060.
RFC 3471	Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description
	Authors: L. Berger, Ed.. Date: January 2003 Formats: txt pdf Updated by: RFC 4201, RFC 4328, RFC 4872, RFC 6002, RFC 6003, RFC 6205 Status: PROPOSED STANDARD This document describes extensions to Multi-Protocol Label Switching(MPLS) signaling required to support Generalized MPLS. GeneralizedMPLS extends the MPLS control plane to encompass time-division (e.g.,Synchronous Optical Network and Synchronous Digital Hierarchy,SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). This document presents a functional description of the extensions. Protocol specific formats and mechanisms, and technology specific details are specified in separate documents.
RFC 3472	Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions
	Authors: P. Ashwood-Smith, Ed., L. Berger, Ed.. Date: January 2003 Formats: txt pdf Updated by: RFC 3468, RFC 4201 Status: PROPOSED STANDARD This document describes extensions to Multi-Protocol Label Switching(MPLS) Constraint-based Routed Label Distribution Protocol (CR-LDP) signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time-division (e.g.,Synchronous Optical Network and Synchronous Digital Hierarchy,SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). This document presents a CR-LDP specific description of the extensions. A generic functional description can be found in separate documents.
RFC 3473	Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions
	Authors: L. Berger, Ed.. Date: January 2003 Formats: txt pdf Updated by: RFC 4003, RFC 4201, RFC 4420, RFC 4783, RFC 4874, RFC 4873, RFC 4974, RFC 5063, RFC 5151, RFC 5420, RFC 6002, RFC 6003 Status: PROPOSED STANDARD This document describes extensions to Multi-Protocol Label Switching(MPLS) Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time-division (e.g.,Synchronous Optical Network and Synchronous Digital Hierarchy,SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). This document presents a RSVP-TE specific description of the extensions. A generic functional description can be found in separate documents.
RFC 3477	Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)
	Authors: K. Kompella, Y. Rekhter. Date: January 2003 Formats: txt pdf Updated by: RFC 6107 Status: PROPOSED STANDARD Current signalling used by Multi-Protocol Label Switching TrafficEngineering (MPLS TE) does not provide support for unnumbered links.This document defines procedures and extensions to ResourceReSerVation Protocol (RSVP) for Label Switched Path (LSP) Tunnels(RSVP-TE), one of the MPLS TE signalling protocols, that are needed in order to support unnumbered links.
RFC 3478	Graceful Restart Mechanism for Label Distribution Protocol
	Authors: M. Leelanivas, Y. Rekhter, R. Aggarwal. Date: February 2003 Formats: txt pdf Status: PROPOSED STANDARD This document describes a mechanism that helps to minimize the negative effects on MPLS traffic caused by Label Switching Router's(LSR's) control plane restart, specifically by the restart of itsLabel Distribution Protocol (LDP) component, on LSRs that are capable of preserving the MPLS forwarding component across the restart. The mechanism described in this document is applicable to all LSRs, both those with the ability to preserve forwarding state during LDP restart and those without (although the latter needs to implement only a subset of the mechanism described in this document).Supporting (a subset of) the mechanism described here by the LSRs that can not preserve their MPLS forwarding state across the restart would not reduce the negative impact on MPLS traffic caused by their control plane restart, but it would minimize the impact if their neighbor(s) are capable of preserving the forwarding state across the restart of their control plane and implement the mechanism described here. The mechanism makes minimalistic assumptions on what has to be preserved across restart - the mechanism assumes that only the actualMPLS forwarding state has to be preserved; the mechanism does not require any of the LDP-related states to be preserved across the restart. The procedures described in this document apply to downstream unsolicited label distribution. Extending these procedures to downstream on demand label distribution is for further study.
RFC 3479	Fault Tolerance for the Label Distribution Protocol (LDP)
	Authors: A. Farrel, Ed.. Date: February 2003 Formats: txt pdf Status: PROPOSED STANDARD Multiprotocol Label Switching (MPLS) systems will be used in core networks where system downtime must be kept to an absolute minimum.Many MPLS Label Switching Routers (LSRs) may, therefore, exploitFault Tolerant (FT) hardware or software to provide high availability of the core networks. The details of how FT is achieved for the various components of an FTLSR, including Label Distribution Protocol (LDP), the switching hardware and TCP, are implementation specific. This document identifies issues in the LDP specification in RFC 3036, "LDPSpecification", that make it difficult to implement an FT LSR using the current LDP protocols, and defines enhancements to the LDP specification to ease such FT LSR implementations. The issues and extensions described here are equally applicable toRFC 3212, "Constraint-Based LSP Setup Using LDP" (CR-LDP).
RFC 3480	Signalling Unnumbered Links in CR-LDP (Constraint-Routing Label Distribution Protocol)
	Authors: K. Kompella, Y. Rekhter, A. Kullberg. Date: February 2003 Formats: txt pdf Status: PROPOSED STANDARD Current signalling used by Multi-Protocol Label Switching TrafficEngineering (MPLS TE) does not provide support for unnumbered links.This document defines procedures and extensions to Constraint-RoutingLabel Distribution Protocol (CR-LDP), one of the MPLS TE signalling protocols that are needed in order to support unnumbered links.
RFC 3484	Default Address Selection for Internet Protocol version 6 (IPv6)
	Authors: R. Draves. Date: February 2003 Formats: txt pdf Status: PROPOSED STANDARD This document describes two algorithms, for source address selection and for destination address selection. The algorithms specify default behavior for all Internet Protocol version 6 (IPv6) implementations. They do not override choices made by applications or upper-layer protocols, nor do they preclude the development of more advanced mechanisms for address selection. The two algorithms share a common context, including an optional mechanism for allowing administrators to provide policy that can override the default behavior. In dual stack implementations, the destination address selection algorithm can consider both IPv4 and IPv6 addresses - depending on the available source addresses, the algorithm might prefer IPv6 addresses over IPv4 addresses, or vice-versa. All IPv6 nodes, including both hosts and routers, must implement default address selection as defined in this specification.
RFC 3485	The Session Initiation Protocol (SIP) and Session Description Protocol (SDP) Static Dictionary for Signaling Compression (SigComp)
	Authors: M. Garcia-Martin, C. Bormann, J. Ott, R. Price, A. B. Roach. Date: February 2003 Formats: txt pdf Updated by: RFC 4896 Status: PROPOSED STANDARD The Session Initiation Protocol (SIP) is a text-based protocol for initiating and managing communication sessions. The protocol can be compressed by using Signaling Compression (SigComp). Similarly, theSession Description Protocol (SDP) is a text-based protocol intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. This memo defines the SIP/SDP-specific static dictionary that SigComp may use in order to achieve higher efficiency. The dictionary is compression algorithm independent.
RFC 3486	Compressing the Session Initiation Protocol (SIP)
	Authors: G. Camarillo. Date: February 2003 Formats: txt pdf Updated by: RFC 5049 Status: PROPOSED STANDARD This document describes a mechanism to signal that compression is desired for one or more Session Initiation Protocol (SIP) messages.It also states when it is appropriate to send compressed SIP messages to a SIP entity.
RFC 3489	STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)
	Authors: J. Rosenberg, J. Weinberger, C. Huitema, R. Mahy. Date: March 2003 Formats: txt pdf Obsoleted by: RFC 5389 Status: PROPOSED STANDARD Simple Traversal of User Datagram Protocol (UDP) Through NetworkAddress Translators (NATs) (STUN) is a lightweight protocol that allows applications to discover the presence and types of NATs and firewalls between them and the public Internet. It also provides the ability for applications to determine the public Internet Protocol(IP) addresses allocated to them by the NAT. STUN works with many existing NATs, and does not require any special behavior from them.As a result, it allows a wide variety of applications to work through existing NAT infrastructure.
RFC 3490	Internationalizing Domain Names in Applications (IDNA)
	Authors: P. Faltstrom, P. Hoffman, A. Costello. Date: March 2003 Formats: txt pdf Obsoleted by: RFC 5890, RFC 5891 Status: PROPOSED STANDARD Until now, there has been no standard method for domain names to use characters outside the ASCII repertoire. This document defines internationalized domain names (IDNs) and a mechanism calledInternationalizing Domain Names in Applications (IDNA) for handling them in a standard fashion. IDNs use characters drawn from a large repertoire (Unicode), but IDNA allows the non-ASCII characters to be represented using only the ASCII characters already allowed in so- called host names today. This backward-compatible representation is required in existing protocols like DNS, so that IDNs can be introduced with no changes to the existing infrastructure. IDNA is only meant for processing domain names, not free text.
RFC 3491	Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)
	Authors: P. Hoffman, M. Blanchet. Date: March 2003 Formats: txt pdf Obsoleted by: RFC 5891 Status: PROPOSED STANDARD This document describes how to prepare internationalized domain name(IDN) labels in order to increase the likelihood that name input and name comparison work in ways that make sense for typical users throughout the world. This profile of the stringprep protocol is used as part of a suite of on-the-wire protocols for internationalizing the Domain Name System (DNS).
RFC 3492	Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)
	Authors: A. Costello. Date: March 2003 Formats: txt pdf Updated by: RFC 5891 Status: PROPOSED STANDARD Punycode is a simple and efficient transfer encoding syntax designed for use with Internationalized Domain Names in Applications (IDNA).It uniquely and reversibly transforms a Unicode string into an ASCII string. ASCII characters in the Unicode string are represented literally, and non-ASCII characters are represented by ASCII characters that are allowed in host name labels (letters, digits, and hyphens). This document defines a general algorithm calledBootstring that allows a string of basic code points to uniquely represent any string of code points drawn from a larger set.Punycode is an instance of Bootstring that uses particular parameter values specified by this document, appropriate for IDNA.
RFC 3495	Dynamic Host Configuration Protocol (DHCP) Option for CableLabs Client Configuration
	Authors: B. Beser, P. Duffy, Ed.. Date: March 2003 Formats: txt pdf Status: PROPOSED STANDARD This document defines a Dynamic Host Configuration Protocol (DHCP) option that will be used to configure various devices deployed withinCableLabs architectures. Specifically, the document describes DHCP option content that will be used to configure one class of CableLabs client device: a PacketCable Media Terminal Adapter (MTA). The option content defined within this document will be extended as future CableLabs client devices are developed.
RFC 3497	RTP Payload Format for Society of Motion Picture and Television Engineers (SMPTE) 292M Video
	Authors: L. Gharai, C. Perkins, G. Goncher, A. Mankin. Date: March 2003 Formats: txt pdf Status: PROPOSED STANDARD This memo specifies an RTP payload format for encapsulating uncompressed High Definition Television (HDTV) as defined by theSociety of Motion Picture and Television Engineers (SMPTE) standard,SMPTE 292M. SMPTE is the main standardizing body in the motion imaging industry and the SMPTE 292M standard defines a bit-serial digital interface for local area HDTV transport.
RFC 3498	Definitions of Managed Objects for Synchronous Optical Network (SONET) Linear Automatic Protection Switching (APS) Architectures
	Authors: J. Kuhfeld, J. Johnson, M. Thatcher. Date: March 2003 Formats: txt pdf Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets.In particular, it defines objects for managing networks usingSynchronous Optical Network (SONET) linear Automatic ProtectionSwitching (APS) architectures.
RFC 3501	INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1
	Authors: M. Crispin. Date: March 2003 Formats: txt pdf Obsoletes: RFC 2060 Updated by: RFC 4466, RFC 4469, RFC 4551, RFC 5032, RFC 5182, RFC 5738, RFC 6186 Status: PROPOSED STANDARD The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev1 permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders. IMAP4rev1 also provides the capability for an offline client to resynchronize with the server. IMAP4rev1 includes operations for creating, deleting, and renaming mailboxes, checking for new messages, permanently removing messages, setting and clearing flags, RFC 2822 and RFC 2045 parsing, searching, and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4rev1 are accessed by the use of numbers.These numbers are either message sequence numbers or unique identifiers. IMAP4rev1 supports a single server. A mechanism for accessing configuration information to support multiple IMAP4rev1 servers is discussed in RFC 2244. IMAP4rev1 does not specify a means of posting mail; this function is handled by a mail transfer protocol such as RFC 2821.
RFC 3502	Internet Message Access Protocol (IMAP) - MULTIAPPEND Extension
	Authors: M. Crispin. Date: March 2003 Formats: txt pdf Updated by: RFC 4466, RFC 4469 Status: PROPOSED STANDARD This document describes the multiappending extension to the InternetMessage Access Protocol (IMAP) (RFC 3501). This extension provides substantial performance improvements for IMAP clients which upload multiple messages at a time to a mailbox on the server. A server which supports this extension indicates this with a capability name of "MULTIAPPEND".
RFC 3503	Message Disposition Notification (MDN) profile for Internet Message Access Protocol (IMAP)
	Authors: A. Melnikov. Date: March 2003 Formats: txt pdf Status: PROPOSED STANDARD The Message Disposition Notification (MDN) facility defined in RFC2298 provides a means by which a message can request that message processing by the recipient be acknowledged as well as a format to be used for such acknowledgements. However, it doesn't describe how multiple Mail User Agents (MUAs) should handle the generation of MDNs in an Internet Message Access Protocol (IMAP4) environment. This document describes how to handle MDNs in such an environment and provides guidelines for implementers of IMAP4 that want to add MDN support to their products.
RFC 3510	Internet Printing Protocol/1.1: IPP URL Scheme
	Authors: R. Herriot, I. McDonald. Date: April 2003 Formats: txt pdf Updates: RFC 2910 Status: PROPOSED STANDARD This memo defines the "ipp" URL (Uniform Resource Locator) scheme.This memo updates IPP/1.1: Encoding and Transport (RFC 2910), by expanding and clarifying Section 5, "IPP URL Scheme", of RFC 2910.An "ipp" URL is used to specify the network location of a print service that supports the IPP Protocol (RFC 2910), or of a network resource (for example, a print job) managed by such a print service.
RFC 3513	Internet Protocol Version 6 (IPv6) Addressing Architecture
	Authors: R. Hinden, S. Deering. Date: April 2003 Formats: txt pdf Obsoletes: RFC 2373 Obsoleted by: RFC 4291 Status: PROPOSED STANDARD This specification defines the addressing architecture of the IPVersion 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and anIPv6 node's required addresses.
RFC 3515	The Session Initiation Protocol (SIP) Refer Method
	Authors: R. Sparks. Date: April 2003 Formats: txt pdf Status: PROPOSED STANDARD This document defines the REFER method. This Session InitiationProtocol (SIP) extension requests that the recipient REFER to a resource provided in the request. It provides a mechanism allowing the party sending the REFER to be notified of the outcome of the referenced request. This can be used to enable many applications, including call transfer. In addition to the REFER method, this document defines the the refer event package and the Refer-To request header.
RFC 3516	IMAP4 Binary Content Extension
	Authors: L. Nerenberg. Date: April 2003 Formats: txt pdf Updated by: RFC 4466 Status: PROPOSED STANDARD This memo defines the Binary extension to the Internet Message AccessProtocol (IMAP4). It provides a mechanism for IMAP4 clients and servers to exchange message body data without using a MIME content- transfer-encoding.
RFC 3517	A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP
	Authors: E. Blanton, M. Allman, K. Fall, L. Wang. Date: April 2003 Formats: txt pdf Status: PROPOSED STANDARD This document presents a conservative loss recovery algorithm for TCP that is based on the use of the selective acknowledgment (SACK) TCP option. The algorithm presented in this document conforms to the spirit of the current congestion control specification (RFC 2581), but allows TCP senders to recover more effectively when multiple segments are lost from a single flight of data.
RFC 3518	Point-to-Point Protocol (PPP) Bridging Control Protocol (BCP)
	Authors: M. Higashiyama, F. Baker, T. Liao. Date: April 2003 Formats: txt pdf Obsoletes: RFC 2878 Status: PROPOSED STANDARD The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol (LCP) and proposes a family of Network Control Protocols (NCP) for establishing and configuring different network-layer protocols. This document defines the NCP for establishing and configuring RemoteBridging for PPP links. This document obsoletes RFC 2878, which was based on the IEEE802.1D-1993 MAC Bridge. This document extends that specification by improving support for bridge control packets.
RFC 3519	Mobile IP Traversal of Network Address Translation (NAT) Devices
	Authors: H. Levkowetz, S. Vaarala. Date: April 2003 Formats: txt pdf Status: PROPOSED STANDARD Mobile IP's datagram tunnelling is incompatible with Network AddressTranslation (NAT). This document presents extensions to the MobileIP protocol and a tunnelling method which permits mobile nodes usingMobile IP to operate in private address networks which are separated from the public internet by NAT devices. The NAT traversal is based on using the Mobile IP Home Agent UDP port for encapsulated data traffic.
RFC 3520	Session Authorization Policy Element
	Authors: L-N. Hamer, B. Gage, B. Kosinski, H. Shieh. Date: April 2003 Formats: txt pdf Status: PROPOSED STANDARD This document describes the representation of a session authorization policy element for supporting policy-based per-session authorization and admission control. 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 co-ordinate actions between the signaling and transport planes. This document describes how a process on a system authorizes the reservation of resources by a host and then provides that host with a session authorization policy element which can be inserted into a resource reservation protocol (e.g., the Resource ReSerVation Protocol (RSVP)PATH message) to facilitate proper and secure reservation of those resources within the network. We describe the encoding of session authorization information as a policy element conforming to the format of a Policy Data object (RFC 2750) and provide details relating to operations, processing rules and error scenarios.
RFC 3524	Mapping of Media Streams to Resource Reservation Flows
	Authors: G. Camarillo, A. Monrad. Date: April 2003 Formats: txt pdf Status: PROPOSED STANDARD This document defines an extension to the Session DescriptionProtocol (SDP) grouping framework. It allows requesting a group of media streams to be mapped into a single resource reservation flow.The SDP syntax needed is defined, as well as a new "semantics" attribute called Single Reservation Flow (SRF).
RFC 3526	More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)
	Authors: T. Kivinen, M. Kojo. Date: May 2003 Formats: txt pdf Status: PROPOSED STANDARD This document defines new Modular Exponential (MODP) Groups for theInternet Key Exchange (IKE) protocol. It documents the well known and used 1536 bit group 5, and also defines new 2048, 3072, 4096,6144, and 8192 bit Diffie-Hellman groups numbered starting at 14.The selection of the primes for theses groups follows the criteria established by Richard Schroeppel.
RFC 3527	Link Selection sub-option for the Relay Agent Information Option for DHCPv4
	Authors: K. Kinnear, M. Stapp, R. Johnson, J. Kumarasamy. Date: April 2003 Formats: txt pdf Status: PROPOSED STANDARD This document describes the link selection sub-option of the relay- agent-information option for the Dynamic Host Configuration Protocol(DHCPv4). The giaddr specifies an IP address which determines both a subnet, and thereby a link on which a Dynamic Host ConfigurationProtocol (DHCP) client resides as well as an IP address that can be used to communicate with the relay agent. The subnet-selection option allows the functions of the giaddr to be split so that when one entity is performing as a DHCP proxy, it can specify the subnet/link from which to allocate an IP address, which is different from the IP address with which it desires to communicate with theDHCP server. Analogous situations exist where the relay agent needs to specify the subnet/link on which a DHCP client resides, which is different from an IP address that can be used to communicate with the relay agent.
RFC 3530	Network File System (NFS) version 4 Protocol
	Authors: S. Shepler, B. Callaghan, D. Robinson, R. Thurlow, C. Beame, M. Eisler, D. Noveck. Date: April 2003 Formats: txt pdf Obsoletes: RFC 3010 Status: PROPOSED STANDARD The Network File System (NFS) version 4 is a distributed filesystem protocol which owes heritage to NFS protocol version 2, RFC 1094, and version 3, RFC 1813. Unlike earlier versions, the NFS version 4 protocol supports traditional file access while integrating support for file locking and the mount protocol. In addition, support for strong security (and its negotiation), compound operations, client caching, and internationalization have been added. Of course, attention has been applied to making NFS version 4 operate well in anInternet environment. This document replaces RFC 3010 as the definition of the NFS version4 protocol.
RFC 3534	The application/ogg Media Type
	Authors: L. Walleij. Date: May 2003 Formats: txt pdf Obsoleted by: RFC 5334 Status: PROPOSED STANDARD The Ogg Bitstream Format aims at becoming a general, freely-available standard for transporting multimedia content across computing platforms and networks. The intention of this document is to define the MIME media type application/ogg to refer to this kind of content when transported across the Internet. It is the intention of the OggBitstream Format developers that it be usable without intellectual property concerns.
RFC 3537	Wrapping a Hashed Message Authentication Code (HMAC) key with a Triple-Data Encryption Standard (DES) Key or an Advanced Encryption Standard (AES) Key
	Authors: J. Schaad, R. Housley. Date: May 2003 Formats: txt pdf Status: PROPOSED STANDARD This document defines two methods for wrapping an HMAC (HashedMessage Authentication Code) key. The first method defined uses aTriple DES (Data Encryption Standard) key to encrypt the HMAC key.The second method defined uses an AES (Advanced Encryption Standard) key to encrypt the HMAC key. One place that such an algorithm is used is for the Authenticated Data type in CMS (Cryptographic MessageSyntax).
RFC 3539	Authentication, Authorization and Accounting (AAA) Transport Profile
	Authors: B. Aboba, J. Wood. Date: June 2003 Formats: txt pdf Status: PROPOSED STANDARD This document discusses transport issues that arise within protocols for Authentication, Authorization and Accounting (AAA). It also provides recommendations on the use of transport by AAA protocols.This includes usage of standards-track RFCs as well as experimental proposals.
RFC 3543	Registration Revocation in Mobile IPv4
	Authors: S. Glass, M. Chandra. Date: August 2003 Formats: txt pdf Status: PROPOSED STANDARD This document defines a Mobile IPv4 Registration Revocation mechanism whereby a mobility agent involved in providing Mobile IP services to a mobile node can notify the other mobility agent providing Mobile IP services to the same mobile node of the termination of this registration. The mechanism is also usable by a home agent to notify a co-located mobile node of the termination of its binding as well.Moreover, the mechanism provides for this notification to be acknowledged. A signaling mechanism already defined by the MobileIPv4 protocol is leveraged as a way to inform a mobile node of the revocation of its binding.
RFC 3544	IP Header Compression over PPP
	Authors: T. Koren, S. Casner, C. Bormann. Date: July 2003 Formats: txt pdf Obsoletes: RFC 2509 Status: PROPOSED STANDARD This document describes an option for negotiating the use of header compression on IP datagrams transmitted over the Point-to-PointProtocol (RFC 1661). It defines extensions to the PPP ControlProtocols for IPv4 and IPv6 (RFC 1332, RFC 2472). Header compression may be applied to IPv4 and IPv6 datagrams in combination with TCP,UDP and RTP transport protocols as specified in RFC 2507, RFC 2508 and RFC 3545.
RFC 3545	Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering
	Authors: T. Koren, S. Casner, J. Geevarghese, B. Thompson, P. Ruddy. Date: July 2003 Formats: txt pdf Status: PROPOSED STANDARD This document describes a header compression scheme for point to point links with packet loss and long delays. It is based onCompressed Real-time Transport Protocol (CRTP), the IP/UDP/RTP header compression described in RFC 2508. CRTP does not perform well on such links: packet loss results in context corruption and due to the long delay, many more packets are discarded before the context is repaired. To correct the behavior of CRTP over such links, a few extensions to the protocol are specified here. The extensions aim to reduce context corruption by changing the way the compressor updates the context at the decompressor: updates are repeated and include updates to full and differential context parameters. With these extensions, CRTP performs well over links with packet loss, packet reordering and long delays.
RFC 3546	Transport Layer Security (TLS) Extensions
	Authors: S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, T. Wright. Date: June 2003 Formats: txt pdf Obsoleted by: RFC 4366 Updates: RFC 2246 Status: PROPOSED STANDARD This document describes extensions that may be used to add functionality to Transport Layer Security (TLS). It provides both generic extension mechanisms for the TLS handshake client and server hellos, and specific extensions using these generic mechanisms. The extensions may be used by TLS clients and servers. The extensions are backwards compatible - communication is possible between TLS 1.0 clients that support the extensions and TLS 1.0 servers that do not support the extensions, and vice versa.
RFC 3547	The Group Domain of Interpretation
	Authors: M. Baugher, B. Weis, T. Hardjono, H. Harney. Date: July 2003 Formats: txt pdf Obsoleted by: RFC 6407 Status: PROPOSED STANDARD This document presents an ISAMKP Domain of Interpretation (DOI) for group key management to support secure group communications. TheGDOI manages group security associations, which are used by IPSEC and potentially other data security protocols running at the IP or application layers. These security associations protect one or more key-encrypting keys, traffic-encrypting keys, or data shared by group members.
RFC 3554	On the Use of Stream Control Transmission Protocol (SCTP) with IPsec
	Authors: S. Bellovin, J. Ioannidis, A. Keromytis, R. Stewart. Date: July 2003 Formats: txt pdf Status: PROPOSED STANDARD This document describes functional requirements for IPsec (RFC 2401) and Internet Key Exchange (IKE) (RFC 2409) to facilitate their use in securing SCTP (RFC 2960) traffic.
RFC 3555	MIME Type Registration of RTP Payload Formats
	Authors: S. Casner, P. Hoschka. Date: July 2003 Formats: txt pdf Obsoleted by: RFC 4855, RFC 4856 Updated by: RFC 3625, RFC 4629 Status: PROPOSED STANDARD This document defines the procedure to register RTP Payload Formats as audio, video or other MIME subtype names. This is useful in a text-based format or control protocol to identify the type of an RTP transmission. This document also registers all the RTP payload formats defined in the RTP Profile for Audio and Video Conferences asMIME subtypes. Some of these may also be used for transfer modes other than RTP.
RFC 3556	Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth
	Authors: S. Casner. Date: July 2003 Formats: txt pdf Status: PROPOSED STANDARD This document defines an extension to the Session DescriptionProtocol (SDP) to specify two additional modifiers for the bandwidth attribute. These modifiers may be used to specify the bandwidth allowed for RTP Control Protocol (RTCP) packets in a Real-timeTransport Protocol (RTP) session.
RFC 3557	RTP Payload Format for European Telecommunications Standards Institute (ETSI) European Standard ES 201 108 Distributed Speech Recognition Encoding
	Authors: Q. Xie, Ed.. Date: July 2003 Formats: txt pdf Status: PROPOSED STANDARD This document specifies an RTP payload format for encapsulatingEuropean Telecommunications Standards Institute (ETSI) EuropeanStandard (ES) 201 108 front-end signal processing feature streams for distributed speech recognition (DSR) systems.
RFC 3558	RTP Payload Format for Enhanced Variable Rate Codecs (EVRC) and Selectable Mode Vocoders (SMV)
	Authors: A. Li. Date: July 2003 Formats: txt pdf Updated by: RFC 4788 Status: PROPOSED STANDARD This document describes the RTP payload format for Enhanced VariableRate Codec (EVRC) Speech and Selectable Mode Vocoder (SMV) Speech.Two sub-formats are specified for different application scenarios. A bundled/interleaved format is included to reduce the effect of packet loss on speech quality and amortize the overhead of the RTP header over more than one speech frame. A non-bundled format is also supported for conversational applications.
RFC 3559	Multicast Address Allocation MIB
	Authors: D. Thaler. Date: June 2003 Formats: txt pdf Status: PROPOSED STANDARD 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 multicast address allocation.
RFC 3560	Use of the RSAES-OAEP Key Transport Algorithm in Cryptographic Message Syntax (CMS)
	Authors: R. Housley. Date: July 2003 Formats: txt pdf Status: PROPOSED STANDARD This document describes the conventions for using the RSAES-OAEP key transport algorithm with the Cryptographic Message Syntax (CMS). TheCMS specifies the enveloped-data content type, which consists of an encrypted content and encrypted content-encryption keys for one or more recipients. The RSAES-OAEP key transport algorithm can be used to encrypt content-encryption keys for intended recipients.
RFC 3565	Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS)
	Authors: J. Schaad. Date: July 2003 Formats: txt pdf Status: PROPOSED STANDARD This document specifies the conventions for using the AdvancedEncryption Standard (AES) algorithm for encryption with theCryptographic Message Syntax (CMS).
RFC 3566	The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec
	Authors: S. Frankel, H. Herbert. Date: September 2003 Formats: txt pdf Status: PROPOSED STANDARD A Message Authentication Code (MAC) is a key-dependent one way hash function. One popular way to construct a MAC algorithm is to use a block cipher in conjunction with the Cipher-Block-Chaining (CBC) mode of operation. The classic CBC-MAC algorithm, while secure for messages of a pre-selected fixed length, has been shown to be insecure across messages of varying lengths such as the type found in typical IP datagrams. This memo specifies the use of AES in CBC mode with a set of extensions to overcome this limitation. This new algorithm is named AES-XCBC-MAC-96.
RFC 3573	Signalling of Modem-On-Hold status in Layer 2 Tunneling Protocol (L2TP)
	Authors: I. Goyret. Date: July 2003 Formats: txt pdf Status: PROPOSED STANDARD The Layer 2 Tunneling Protocol (L2TP) defines a mechanism for tunneling Point-to-Point Protocol (PPP) sessions. It is common for these PPP sessions to be established using modems connected over the public switched telephone network. One of the standards governing modem operation defines procedures that enable a client modem to put the call on hold and later, re- establish the modem link with minimal delay and without having to redial. While the modem call is on hold, the client phone line can be used to place or receive other calls. The L2TP base protocol does not provide any means to signal these events from the L2TP Access Controller (LAC), where the modem is physically connected, to the L2TP Network Server (LNS), where the PPP session is handled. This document describes a method to let the LNS know when a client modem connected to a LAC has placed the call on hold.
RFC 3575	IANA Considerations for RADIUS (Remote Authentication Dial In User Service)
	Authors: B. Aboba. Date: July 2003 Formats: txt pdf Updates: RFC 2865 Status: PROPOSED STANDARD This document describes the IANA considerations for the RemoteAuthentication Dial In User Service (RADIUS). This document updates RFC 2865.
RFC 3578	Mapping of Integrated Services Digital Network (ISDN) User Part (ISUP) Overlap Signalling to the Session Initiation Protocol (SIP)
	Authors: G. Camarillo, A. B. Roach, J. Peterson, L. Ong. Date: August 2003 Formats: txt pdf Status: PROPOSED STANDARD This document describes a way to map Integrated Services DigitalNetwork User Part (ISUP) overlap signalling to Session InitiationProtocol (SIP). This mechanism might be implemented when using SIP in an environment where part of the call involves interworking with the Public Switched Telephone Network (PSTN).
RFC 3581	An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing
	Authors: J. Rosenberg, H. Schulzrinne. Date: August 2003 Formats: txt pdf Status: PROPOSED STANDARD The Session Initiation Protocol (SIP) operates over UDP and TCP, among others. When used with UDP, responses to requests are returned to the source address the request came from, and to the port written into the topmost Via header field value of the request. This behavior is not desirable in many cases, most notably, when the client is behind a Network Address Translator (NAT). This extension defines a new parameter for the Via header field, called "rport", that allows a client to request that the server send the response back to the source IP address and port from which the request originated.
RFC 3585	IPsec Configuration Policy Information Model
	Authors: J. Jason, L. Rafalow, E. Vyncke. Date: August 2003 Formats: txt pdf Status: PROPOSED STANDARD This document presents an object-oriented information model of IPSecurity (IPsec) policy designed to facilitate agreement about the content and semantics of IPsec policy, and enable derivations of task-specific representations of IPsec policy such as storage schema, distribution representations, and policy specification languages used to configure IPsec-enabled endpoints. The information model described in this document models the configuration parameters defined by IPSec. The information model also covers the parameters found by the Internet Key Exchange protocol (IKE). Other key exchange protocols could easily be added to the information model by a simple extension. Further extensions can further be added easily due to the object-oriented nature of the model. This information model is based upon the core policy classes as defined in the Policy Core Information Model (PCIM) and in the PolicyCore Information Model Extensions (PCIMe).
RFC 3586	IP Security Policy (IPSP) Requirements
	Authors: M. Blaze, A. Keromytis, M. Richardson, L. Sanchez. Date: August 2003 Formats: txt pdf Status: PROPOSED STANDARD This document describes the problem space and solution requirements for developing an IP Security Policy (IPSP) configuration and management framework. The IPSP architecture provides a scalable, decentralized framework for managing, discovering and negotiating the host and network security policies that govern access, authorization, authentication, confidentiality, data integrity, and other IPSecurity properties. This document highlights such architectural components and presents their functional requirements.
RFC 3588	Diameter Base Protocol
	Authors: P. Calhoun, J. Loughney, E. Guttman, G. Zorn, J. Arkko. Date: September 2003 Formats: txt pdf Updated by: RFC 5729, RFC 5719, RFC 6408 Status: PROPOSED STANDARD The Diameter base protocol is intended to provide an Authentication,Authorization and Accounting (AAA) framework for applications such as network access or IP mobility. Diameter is also intended to work in both local Authentication, Authorization & Accounting and roaming situations. This document specifies the message format, transport, error reporting, accounting and security services to be used by allDiameter applications. The Diameter base application needs to be supported by all Diameter implementations.
RFC 3590	Source Address Selection for the Multicast Listener Discovery (MLD) Protocol
	Authors: B. Haberman. Date: September 2003 Formats: txt pdf Updates: RFC 2710 Status: PROPOSED STANDARD It has come to light that there is an issue with the selection of a suitable IPv6 source address for Multicast Listener Discovery (MLD) messages when a node is performing stateless address autoconfiguration. This document is intended to clarify the rules on selecting an IPv6 address to use for MLD messages.
RFC 3591	Definitions of Managed Objects for the Optical Interface Type
	Authors: H-K. Lam, M. Stewart, A. Huynh. Date: September 2003 Formats: txt pdf Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with Simple Network Management Protocol (SNMP) in TCP/IP- based internets. In particular, it defines objects for managingOptical Interfaces associated with WavelengthDivision Multiplexing systems or characterized by the Optical Transport Network (OTN) in accordance with the OTN architecture defined in ITU-T RecommendationG.872. The MIB module defined in this memo can be used for performance monitoring and/or configuration of such optical interface.
RFC 3594	PacketCable Security Ticket Control Sub-Option for the DHCP CableLabs Client Configuration (CCC) Option
	Authors: P. Duffy. Date: September 2003 Formats: txt pdf Status: PROPOSED STANDARD This document defines a new sub-option for the DHCP CableLabs ClientConfiguration (CCC) Option. This new sub-option will be used to direct CableLabs Client Devices (CCDs) to invalidate security tickets stored in CCD non volatile memory (i.e., locally persisted security tickets).
RFC 3595	Textual Conventions for IPv6 Flow Label
	Authors: B. Wijnen. Date: September 2003 Formats: txt pdf Status: PROPOSED STANDARD This MIB module defines textual conventions to represent the commonly used IPv6 Flow Label. The intent is that these textual conventions(TCs) will be imported and used in MIB modules that would otherwise define their own representations.
RFC 3597	Handling of Unknown DNS Resource Record (RR) Types
	Authors: A. Gustafsson. Date: September 2003 Formats: txt pdf Updates: RFC 2163, RFC 2535 Updated by: RFC 4033, RFC 4034, RFC 4035, RFC 5395, RFC 6195 Status: PROPOSED STANDARD Extending the Domain Name System (DNS) with new Resource Record (RR) types currently requires changes to name server software. This document specifies the changes necessary to allow future DNS implementations to handle new RR types transparently.
RFC 3598	Sieve Email Filtering -- Subaddress Extension
	Authors: K. Murchison. Date: September 2003 Formats: txt pdf Obsoleted by: RFC 5233 Status: PROPOSED STANDARD On email systems that allow for "subaddressing" or "detailed addressing" (e.g., "ken+sieve@example.org"), it is sometimes desirable to make comparisons against these sub-parts of addresses.This document defines an extension to the Sieve mail filtering language that allows users to compare against the user and detail parts of an address.
RFC 3601	Text String Notation for Dial Sequences and Global Switched Telephone Network (GSTN) / E.164 Addresses
	Authors: C. Allocchio. Date: September 2003 Formats: txt pdf Status: PROPOSED STANDARD This memo describes the full set of notations needed to represent a text string in a Dial Sequence. A Dial Sequence is normally composed of Dual Tone Multi Frequency (DTMF) elements, plus separators and additional "actions" (such as "wait for dialtone", "pause for N secs", etc.) which could be needed to successfully establish the connection with the target service: this includes the cases where subaddresses or DTMF menu navigation apply.
RFC 3602	The AES-CBC Cipher Algorithm and Its Use with IPsec
	Authors: S. Frankel, R. Glenn, S. Kelly. Date: September 2003 Formats: txt pdf Status: PROPOSED STANDARD This document describes the use of the Advanced Encryption Standard(AES) Cipher Algorithm in Cipher Block Chaining (CBC) Mode, with an explicit Initialization Vector (IV), as a confidentiality mechanism within the context of the IPsec Encapsulating Security Payload (ESP).
RFC 3605	Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)
	Authors: C. Huitema. Date: October 2003 Formats: txt pdf Status: PROPOSED STANDARD The Session Description Protocol (SDP) is used to describe the parameters of media streams used in multimedia sessions. When a session requires multiple ports, SDP assumes that these ports have consecutive numbers. However, when the session crosses a network address translation device that also uses port mapping, the ordering of ports can be destroyed by the translation. To handle this, we propose an extension attribute to SDP.
RFC 3606	Definitions of Supplemental Managed Objects for ATM Interface
	Authors: F. Ly, M. Noto, A. Smith, E. Spiegel, K. Tesink. Date: November 2003 Formats: txt pdf Status: PROPOSED STANDARD This memo defines objects used for managing ATM-based interfaces, devices, and services, in addition to those defined in RFC 2515, theATM-MIB, to provide additional support for the management of ATMSwitched Virtual Connections (SVCs) and ATM Permanent VirtualConnections (PVCs).
RFC 3608	Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration
	Authors: D. Willis, B. Hoeneisen. Date: October 2003 Formats: txt pdf Updated by: RFC 5630 Status: PROPOSED STANDARD This document defines a Session Initiation Protocol (SIP) extension header field used in conjunction with responses to REGISTER requests to provide a mechanism by which a registrar may inform a registering user agent (UA) of a service route that the UA may use to request outbound services from the registrar's domain.
RFC 3611	RTP Control Protocol Extended Reports (RTCP XR)
	Authors: T. Friedman, Ed., R. Caceres, Ed., A. Clark, Ed.. Date: November 2003 Formats: txt pdf Status: PROPOSED STANDARD This document defines the Extended Report (XR) packet type for theRTP Control Protocol (RTCP), and defines how the use of XR packets can be signaled by an application if it employs the SessionDescription Protocol (SDP). XR packets are composed of report blocks, and seven block types are defined here. The purpose of the extended reporting format is to convey information that supplements the six statistics that are contained in the report blocks used byRTCP's Sender Report (SR) and Receiver Report (RR) packets. Some applications, such as multicast inference of network characteristics(MINC) or voice over IP (VoIP) monitoring, require other and more detailed statistics. In addition to the block types defined here, additional block types may be defined in the future by adhering to the framework that this document provides.
RFC 3620	The TUNNEL Profile
	Authors: D. New. Date: October 2003 Formats: txt pdf Status: PROPOSED STANDARD This memo describes a Blocks Extensible Exchange Protocol (BEEP) profile that allows a BEEP peer to serve as an application-layer proxy. It allows authorized users to access services through a firewall.
RFC 3621	Power Ethernet MIB
	Authors: A. Berger, D. Romascanu. Date: December 2003 Formats: txt pdf Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.This document proposes an extension to the Ethernet-like InterfacesMIB with a set of objects for managing Power Sourcing Equipment(PSE).
RFC 3623	Graceful OSPF Restart
	Authors: J. Moy, P. Pillay-Esnault, A. Lindem. Date: November 2003 Formats: txt pdf Status: PROPOSED STANDARD This memo documents an enhancement to the OSPF routing protocol, whereby an OSPF router can stay on the forwarding path even as itsOSPF software is restarted. This is called "graceful restart" or"non-stop forwarding". A restarting router may not be capable of adjusting its forwarding in a timely manner when the network topology changes. In order to avoid the possible resulting routing loops, the procedure in this memo automatically reverts to a normal OSPF restart when such a topology change is detected, or when one or more of the restarting router's neighbors do not support the enhancements in this memo. Proper network operation during a graceful restart makes assumptions upon the operating environment of the restarting router; these assumptions are also documented.
RFC 3630	Traffic Engineering (TE) Extensions to OSPF Version 2
	Authors: D. Katz, K. Kompella, D. Yeung. Date: September 2003 Formats: txt pdf Updates: RFC 2370 Updated by: RFC 4203, RFC 5786 Status: PROPOSED STANDARD This document describes extensions to the OSPF protocol version 2 to support intra-area Traffic Engineering (TE), using Opaque Link StateAdvertisements.
RFC 3633	IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6
	Authors: O. Troan, R. Droms. Date: December 2003 Formats: txt pdf Updated by: RFC 6603 Status: PROPOSED STANDARD The Prefix Delegation options provide a mechanism for automated delegation of IPv6 prefixes using the Dynamic Host ConfigurationProtocol (DHCP). This mechanism is intended for delegating a long- lived prefix from a delegating router to a requesting router, across an administrative boundary, where the delegating router does not require knowledge about the topology of the links in the network to which the prefixes will be assigned.
RFC 3634	Key Distribution Center (KDC) Server Address Sub-option for the Dynamic Host Configuration Protocol (DHCP) CableLabs Client Configuration (CCC) Option
	Authors: K. Luehrs, R. Woundy, J. Bevilacqua, N. Davoust. Date: December 2003 Formats: txt pdf Status: PROPOSED STANDARD This document defines a new sub-option for the CableLabs ClientConfiguration (CCC) Dynamic Host Configuration Protocol (DHCP) option code for conveying the network addresses of Key Distribution Center(KDC) servers.
RFC 3635	Definitions of Managed Objects for the Ethernet-like Interface Types
	Authors: J. Flick. Date: September 2003 Formats: txt pdf Obsoletes: RFC 2665 Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it defines objects for managing Ethernet-like interfaces. This memo obsoletes RFC 2665. It updates that specification by including management information useful for the management of 10 Gigabit per second (Gb/s) Ethernet interfaces.
RFC 3636	Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs)
	Authors: J. Flick. Date: September 2003 Formats: txt pdf Obsoletes: RFC 2668, RFC 1515 Obsoleted by: RFC 4836 Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it defines objects for managing IEEE 802.3 MediumAttachment Units (MAUs). This memo obsoletes RFC 2668. This memo extends that specification by including management information useful for the management of 10 gigabit per second (Gb/s) MAUs. This memo also obsoletes RFC 1515.
RFC 3637	Definitions of Managed Objects for the Ethernet WAN Interface Sublayer
	Authors: C.M. Heard, Ed.. Date: September 2003 Formats: txt pdf Status: PROPOSED STANDARD This document defines a portion of the Management Information Base(MIB) for use with network management protocols in TCP/IP based internets. In particular, it defines objects for managing theEthernet Wide Area Network (WAN) Interface Sublayer (WIS). The MIB module defined in this memo is an extension of theSynchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH)Interface MIB and is implemented in conjunction with it and with theEthernet-like Interface MIB, the 802.3 Medium Attachment Unit MIB, the Interfaces Group MIB, and the Inverted Stack Table MIB.
RFC 3640	RTP Payload Format for Transport of MPEG-4 Elementary Streams
	Authors: J. van der Meer, D. Mackie, V. Swaminathan, D. Singer, P. Gentric. Date: November 2003 Formats: txt pdf Updated by: RFC 5691 Status: PROPOSED STANDARD The Motion Picture Experts Group (MPEG) Committee (ISO/IEC JTC1/SC29WG11) is a working group in ISO that produced the MPEG-4 standard.MPEG defines tools to compress content such as audio-visual information into elementary streams. This specification defines a simple, but generic RTP payload format for transport of any non- multiplexed MPEG-4 elementary stream.
RFC 3641	Generic String Encoding Rules (GSER) for ASN.1 Types
	Authors: S. Legg. Date: October 2003 Formats: txt pdf Updated by: RFC 4792 Status: PROPOSED STANDARD This document defines a set of Abstract Syntax Notation One (ASN.1) encoding rules, called the Generic String Encoding Rules (GSER), that produce a human readable text encoding for values of any given ASN.1 data type.
RFC 3642	Common Elements of Generic String Encoding Rules (GSER) Encodings
	Authors: S. Legg. Date: October 2003 Formats: txt pdf Status: PROPOSED STANDARD The Generic String Encoding Rules (GSER) describe a human readable text encoding for an Abstract Syntax Notation One (ASN.1) value of any ASN.1 type. Specifications making use of GSER may wish to provide an equivalent Augmented Backus-Naur Form (ABNF) description of the GSER encoding for a particular ASN.1 type as a convenience for implementors. This document supports such specifications by providing equivalent ABNF for the GSER encodings for ASN.1 types that commonly occur in Lightweight Directory Access Protocol (LDAP) syntaxes.
RFC 3643	Fibre Channel (FC) Frame Encapsulation
	Authors: R. Weber, M. Rajagopal, F. Travostino, M. O'Donnell, C. Monia, M. Merhar. Date: December 2003 Formats: txt pdf Status: PROPOSED STANDARD This document describes the common Fibre Channel (FC) frame encapsulation format and a procedure for the measurement and calculation of frame transit time through the IP network. This specification is intended for use by any IETF protocol that encapsulates FC frames.
RFC 3644	Policy Quality of Service (QoS) Information Model
	Authors: Y. Snir, Y. Ramberg, J. Strassner, R. Cohen, B. Moore. Date: November 2003 Formats: txt pdf Status: PROPOSED STANDARD This document presents an object-oriented information model for representing Quality of Service (QoS) network management policies.This document is based on the IETF Policy Core Information Model and its extensions. It defines an information model for QoS enforcement for differentiated and integrated services using policy. It is important to note that this document defines an information model, which by definition is independent of any particular data storage mechanism and access protocol.
RFC 3645	Generic Security Service Algorithm for Secret Key Transaction Authentication for DNS (GSS-TSIG)
	Authors: S. Kwan, P. Garg, J. Gilroy, L. Esibov, J. Westhead, R. Hall. Date: October 2003 Formats: txt pdf Updates: RFC 2845 Status: PROPOSED STANDARD The Secret Key Transaction Authentication for DNS (TSIG) protocol provides transaction level authentication for DNS. TSIG is extensible through the definition of new algorithms. This document specifies an algorithm based on the Generic Security ServiceApplication Program Interface (GSS-API) (RFC2743). This document updates RFC 2845.
RFC 3646	DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
	Authors: R. Droms, Ed.. Date: December 2003 Formats: txt pdf Status: PROPOSED STANDARD This document describes Dynamic Host Configuration Protocol for IPv6(DHCPv6) options for passing a list of available DNS recursive name servers and a domain search list to a client.
RFC 3648	Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol
	Authors: J. Whitehead, J. Reschke, Ed.. Date: December 2003 Formats: txt pdf Status: PROPOSED STANDARD This specification extends the Web Distributed Authoring andVersioning (WebDAV) Protocol to support the server-side ordering of collection members. Of particular interest are orderings that are not based on property values, and so cannot be achieved using a search protocol's ordering option and cannot be maintained automatically by the server. Protocol elements are defined to let clients specify the position in the ordering of each collection member, as well as the semantics governing the ordering.
RFC 3655	Redefinition of DNS Authenticated Data (AD) bit
	Authors: B. Wellington, O. Gudmundsson. Date: November 2003 Formats: txt pdf Obsoleted by: RFC 4033, RFC 4034, RFC 4035 Updates: RFC 2535 Status: PROPOSED STANDARD This document alters the specification defined in RFC 2535. Based on implementation experience, the Authenticated Data (AD) bit in the DNS header is not useful. This document redefines the AD bit such that it is only set if all answers or records proving that no answers exist in the response has been cryptographically verified or otherwise meets the server's local security policy.
RFC 3657	Use of the Camellia Encryption Algorithm in Cryptographic Message Syntax (CMS)
	Authors: S. Moriai, A. Kato. Date: January 2004 Formats: txt pdf Status: PROPOSED STANDARD This document specifies the conventions for using the Camellia encryption algorithm for encryption with the Cryptographic MessageSyntax (CMS).
RFC 3658	Delegation Signer (DS) Resource Record (RR)
	Authors: O. Gudmundsson. Date: December 2003 Formats: txt pdf Obsoleted by: RFC 4033, RFC 4034, RFC 4035 Updates: RFC 3090, RFC 3008, RFC 2535, RFC 1035 Updated by: RFC 3755 Status: PROPOSED STANDARD The delegation signer (DS) resource record (RR) is inserted at a zone cut (i.e., a delegation point) to indicate that the delegated zone is digitally signed and that the delegated zone recognizes the indicated key as a valid zone key for the delegated zone. The DS RR is a modification to the DNS Security Extensions definition, motivated by operational considerations. The intent is to use this resource record as an explicit statement about the delegation, rather than relying on inference. This document defines the DS RR, gives examples of how it is used and describes the implications on resolvers. This change is not backwards compatible with RFC 2535. This document updates RFC 1035,RFC 2535, RFC 3008 and RFC 3090.
RFC 3659	Extensions to FTP
	Authors: P. Hethmon. Date: March 2007 Formats: txt pdf Updates: RFC 0959 Status: PROPOSED STANDARD This document specifies new FTP commands to obtain listings of remote directories in a defined format, and to permit restarts of interrupted data transfers in STREAM mode. It allows character sets other than US-ASCII, and also defines an optional virtual file storage structure.
RFC 3664	The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE)
	Authors: P. Hoffman. Date: January 2004 Formats: txt pdf Obsoleted by: RFC 4434 Status: PROPOSED STANDARD Some implementations of IP Security (IPsec) may want to use a pseudo-random function derived from the Advanced Encryption Standard(AES). This document describes such an algorithm, called AES-XCBC-PRF-128.
RFC 3670	Information Model for Describing Network Device QoS Datapath Mechanisms
	Authors: B. Moore, D. Durham, J. Strassner, A. Westerinen, W. Weiss. Date: January 2004 Formats: txt pdf Status: PROPOSED STANDARD The purpose of this document is to define an information model to describe the quality of service (QoS) mechanisms inherent in different network devices, including hosts. Broadly speaking, these mechanisms describe the properties common to selecting and conditioning traffic through the forwarding path (datapath) of a network device. This selection and conditioning of traffic in the datapath spans both major QoS architectures: Differentiated Services and Integrated Services. This document should be used with the QoS Policy Information Model(QPIM) to model how policies can be defined to manage and configure the QoS mechanisms (i.e., the classification, marking, metering, dropping, queuing, and scheduling functionality) of devices.Together, these two documents describe how to write QoS policy rules to configure and manage the QoS mechanisms present in the datapaths of devices. This document, as well as QPIM, are information models. That is, they represent information independent of a binding to a specific type of repository.
RFC 3671	Collective Attributes in the Lightweight Directory Access Protocol (LDAP)
	Authors: K. Zeilenga. Date: December 2003 Formats: txt pdf Status: PROPOSED STANDARD X.500 collective attributes allow common characteristics to be shared between collections of entries. This document summarizes the X.500 information model for collective attributes and describes use of collective attributes in LDAP (Lightweight Directory AccessProtocol). This document provides schema definitions for collective attributes for use in LDAP.
RFC 3672	Subentries in the Lightweight Directory Access Protocol (LDAP)
	Authors: K. Zeilenga. Date: December 2003 Formats: txt pdf Status: PROPOSED STANDARD In X.500 directories, subentries are special entries used to hold information associated with a subtree or subtree refinement. This document adapts X.500 subentries mechanisms for use with theLightweight Directory Access Protocol (LDAP).
RFC 3673	Lightweight Directory Access Protocol version 3 (LDAPv3): All Operational Attributes
	Authors: K. Zeilenga. Date: December 2003 Formats: txt pdf Status: PROPOSED STANDARD The Lightweight Directory Access Protocol (LDAP) supports a mechanism for requesting the return of all user attributes but not all operational attributes. This document describes an LDAP extension which clients may use to request the return of all operational attributes.
RFC 3674	Feature Discovery in Lightweight Directory Access Protocol (LDAP)
	Authors: K. Zeilenga. Date: December 2003 Formats: txt pdf Obsoleted by: RFC 4512 Status: PROPOSED STANDARD The Lightweight Directory Access Protocol (LDAP) is an extensible protocol with numerous elective features. This document introduces a general mechanism for discovery of elective features and extensions which cannot be discovered using existing mechanisms.
RFC 3676	The Text/Plain Format and DelSp Parameters
	Authors: R. Gellens. Date: February 2004 Formats: txt pdf Obsoletes: RFC 2646 Status: PROPOSED STANDARD This specification establishes two parameters (Format and DelSP) to be used with the Text/Plain media type. In the presence of these parameters, trailing whitespace is used to indicate flowed lines and a canonical quote indicator is used to indicate quoted lines. This results in an encoding which appears as normal Text/Plain in older implementations, since it is in fact normal Text/Plain, yet provides for superior wrapping/flowing, and quoting. This document supersedes the one specified in RFC 2646, "TheText/Plain Format Parameter", and adds the DelSp parameter to accommodate languages/coded character sets in which ASCII spaces are not used or appear rarely.
RFC 3680	A Session Initiation Protocol (SIP) Event Package for Registrations
	Authors: J. Rosenberg. Date: March 2004 Formats: txt pdf Updated by: RFC 6140 Status: PROPOSED STANDARD This document defines a Session Initiation Protocol (SIP) event package for registrations. Through its REGISTER method, SIP allows a user agent to create, modify, and delete registrations.Registrations can also be altered by administrators in order to enforce policy. As a result, these registrations represent a piece of state in the network that can change dynamically. There are many cases where a user agent would like to be notified of changes in this state. This event package defines a mechanism by which those user agents can request and obtain such notifications.
RFC 3685	SIEVE Email Filtering: Spamtest and VirusTest Extensions
	Authors: C. Daboo. Date: February 2004 Formats: txt pdf Obsoleted by: RFC 5235 Status: PROPOSED STANDARD The SIEVE mail filtering language "spamtest" and "virustest" extensions permit users to use simple, portable commands for spam and virus tests on email messages. Each extension provides a new test using matches against numeric 'scores'. It is the responsibility of the underlying SIEVE implementation to do the actual checks that result in values returned by the tests.
RFC 3686	Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)
	Authors: R. Housley. Date: January 2004 Formats: txt pdf Status: PROPOSED STANDARD This document describes the use of Advanced Encryption Standard (AES)Counter Mode, with an explicit initialization vector, as an IPsecEncapsulating Security Payload (ESP) confidentiality mechanism.
RFC 3687	Lightweight Directory Access Protocol (LDAP) and X.500 Component Matching Rules
	Authors: S. Legg. Date: February 2004 Formats: txt pdf Status: PROPOSED STANDARD The syntaxes of attributes in a Lightweight Directory Access Protocol(LDAP) or X.500 directory range from simple data types, such as text string, integer, or boolean, to complex structured data types, such as the syntaxes of the directory schema operational attributes.Matching rules defined for the complex syntaxes usually only provide the most immediately useful matching capability. This document defines generic matching rules that can match any user selected component parts in an attribute value of any arbitrarily complex attribute syntax.
RFC 3691	Internet Message Access Protocol (IMAP) UNSELECT command
	Authors: A. Melnikov. Date: February 2004 Formats: txt pdf Status: PROPOSED STANDARD This document defines an UNSELECT command that can be used to close the current mailbox in an Internet Message Access Protocol - version4 (IMAP4) session without expunging it. Certain types of IMAP clients need to release resources associated with the selected mailbox without selecting a different mailbox. While IMAP4 provides this functionality (via a SELECT command with a nonexistent mailbox name or reselecting the same mailbox with EXAMINE command), a more clean solution is desirable.
RFC 3697	IPv6 Flow Label Specification
	Authors: J. Rajahalme, A. Conta, B. Carpenter, S. Deering. Date: March 2004 Formats: txt pdf Obsoleted by: RFC 6437 Status: PROPOSED STANDARD This document specifies the IPv6 Flow Label field and the minimum requirements for IPv6 source nodes labeling flows, IPv6 nodes forwarding labeled packets, and flow state establishment methods.Even when mentioned as examples of possible uses of the flow labeling, more detailed requirements for specific use cases are out of scope for this document. The usage of the Flow Label field enables efficient IPv6 flow classification based only on IPv6 main header fields in fixed positions.
RFC 3698	Lightweight Directory Access Protocol (LDAP): Additional Matching Rules
	Authors: K. Zeilenga, Ed.. Date: February 2004 Formats: txt pdf Updates: RFC 2798 Updated by: RFC 4517 Status: PROPOSED STANDARD This document provides a collection of matching rules for use with the Lightweight Directory Access Protocol (LDAP). As these matching rules are simple adaptations of matching rules specified for use with the X.500 Directory, most are already in wide use.
RFC 3703	Policy Core Lightweight Directory Access Protocol (LDAP) Schema
	Authors: J. Strassner, B. Moore, R. Moats, E. Ellesson. Date: February 2004 Formats: txt pdf Updated by: RFC 4104 Status: PROPOSED STANDARD This document defines a mapping of the Policy Core Information Model to a form that can be implemented in a directory that usesLightweight Directory Access Protocol (LDAP) as its access protocol.This model defines two hierarchies of object classes: structural classes representing information for representing and controlling policy data as specified in RFC 3060, and relationship classes that indicate how instances of the structural classes are related to each other. Classes are also added to the LDAP schema to improve the performance of a client's interactions with an LDAP server when the client is retrieving large amounts of policy-related information.These classes exist only to optimize LDAP retrievals: there are no classes in the information model that correspond to them.
RFC 3705	High Capacity Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals
	Authors: B. Ray, R. Abbi. Date: February 2004 Formats: txt pdf Status: PROPOSED STANDARD This document presents a set of High Capacity Textual Conventions for use in MIB modules which require performance history based upon 15 minute intervals. The Textual Conventions defined in this document extend the conventions presented in RFC 3593 to 64 bit resolution using the conventions presented in RFC 2856.
RFC 3709	Internet X.509 Public Key Infrastructure: Logotypes in X.509 Certificates
	Authors: S. Santesson, R. Housley, T. Freeman. Date: February 2004 Formats: txt pdf Updated by: RFC 6170 Status: PROPOSED STANDARD This document specifies a certificate extension for including logotypes in public key certificates and attribute certificates.
RFC 3711	The Secure Real-time Transport Protocol (SRTP)
	Authors: M. Baugher, D. McGrew, M. Naslund, E. Carrara, K. Norrman. Date: March 2004 Formats: txt pdf Updated by: RFC 5506 Status: PROPOSED STANDARD This document describes the Secure Real-time Transport Protocol(SRTP), a profile of the Real-time Transport Protocol (RTP), which can provide confidentiality, message authentication, and replay protection to the RTP traffic and to the control traffic for RTP, theReal-time Transport Control Protocol (RTCP).
RFC 3720	Internet Small Computer Systems Interface (iSCSI)
	Authors: J. Satran, K. Meth, C. Sapuntzakis, M. Chadalapaka, E. Zeidner. Date: April 2004 Formats: txt pdf Updated by: RFC 3980, RFC 4850, RFC 5048 Status: PROPOSED STANDARD This document describes a transport protocol for Internet SmallComputer Systems Interface (iSCSI) that works on top of TCP. The iSCSI protocol aims to be fully compliant with the standardized SCSI architecture model. SCSI is a popular family of protocols that enable systems to communicate with I/O devices, especially storage devices. SCSI protocols are request/response application protocols with a common standardized architecture model and basic command set, as well as standardized command sets for different device classes (disks, tapes, media-changers etc.). As system interconnects move from the classical bus structure to a network structure, SCSI has to be mapped to network transport protocols. IP networks now meet the performance requirements of fast system interconnects and as such are good candidates to "carry" SCSI.
RFC 3722	String Profile for Internet Small Computer Systems Interface (iSCSI) Names
	Authors: M. Bakke. Date: April 2004 Formats: txt pdf Status: PROPOSED STANDARD This document describes how to prepare internationalized iSCSI names to increase the likelihood that name input and comparison work in ways that make sense for typical users throughout the world. The Internet Small Computer Systems Interface (iSCSI) protocol provides a way for hosts to access SCSI devices over an IP network.The iSCSI end-points, called initiators and targets, each have a globally-unique name that must be transcribable, as well as easily compared.
RFC 3723	Securing Block Storage Protocols over IP
	Authors: B. Aboba, J. Tseng, J. Walker, V. Rangan, F. Travostino. Date: April 2004 Formats: txt pdf Status: PROPOSED STANDARD This document discusses how to secure block storage and storage discovery protocols running over IP (Internet Protocol) using IPsec and IKE (Internet Key Exchange). Threat models and security protocols are developed for iSCSI (Internet Protocol Small ComputerSystem Interface), iFCP (Internet Fibre Channel Storage Networking) and FCIP (Fibre Channel over TCP/IP), as well as the iSNS (InternetStorage Name Server) and SLPv2 (Service Location Protocol v2) discovery protocols. Performance issues and resource constraints are analyzed.
RFC 3727	ASN.1 Module Definition for the LDAP and X.500 Component Matching Rules
	Authors: S. Legg. Date: February 2004 Formats: txt pdf Status: PROPOSED STANDARD This document updates the specification of the component matching rules for Lightweight Directory Access Protocol (LDAP) and X.500 directories (RFC3687) by collecting the Abstract Syntax Notation One(ASN.1) definitions of the component matching rules into an appropriately identified ASN.1 module so that other specifications may reference the component matching rule definitions from within their own ASN.1 modules.
RFC 3728	Definitions of Managed Objects for Very High Speed Digital Subscriber Lines (VDSL)
	Authors: B. Ray, R. Abbi. Date: February 2004 Formats: txt pdf Status: PROPOSED STANDARD This document defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing Very High SpeedDigital Subscriber Line (VDSL) interfaces.
RFC 3729	Application Performance Measurement MIB
	Authors: S. Waldbusser. Date: March 2004 Formats: txt pdf Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it defines objects for measuring the application performance as experienced by end-users.
RFC 3730	Extensible Provisioning Protocol (EPP)
	Authors: S. Hollenbeck. Date: March 2004 Formats: txt pdf Obsoleted by: RFC 4930 Status: PROPOSED STANDARD This document describes an application layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. This document includes a protocol specification, an object mapping template, and an XML media type registration.
RFC 3731	Extensible Provisioning Protocol (EPP) Domain Name Mapping
	Authors: S. Hollenbeck. Date: March 2004 Formats: txt pdf Obsoleted by: RFC 4931 Status: PROPOSED STANDARD This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet domain names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to domain names.
RFC 3732	Extensible Provisioning Protocol (EPP) Host Mapping
	Authors: S. Hollenbeck. Date: March 2004 Formats: txt pdf Obsoleted by: RFC 4932 Status: PROPOSED STANDARD This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet host names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to host names.
RFC 3733	Extensible Provisioning Protocol (EPP) Contact Mapping
	Authors: S. Hollenbeck. Date: March 2004 Formats: txt pdf Obsoleted by: RFC 4933 Status: PROPOSED STANDARD This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of individual or organizational social information identifiers (known as "contacts") stored in a shared central repository. Specified in ExtensibleMarkup Language (XML), the mapping defines EPP command syntax and semantics as applied to contacts.
RFC 3734	Extensible Provisioning Protocol (EPP) Transport Over TCP
	Authors: S. Hollenbeck. Date: March 2004 Formats: txt pdf Obsoleted by: RFC 4934 Status: PROPOSED STANDARD This document describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a single Transmission Control Protocol (TCP) connection. This mapping requires use of the Transport LayerSecurity (TLS) protocol to protect information exchanged between anEPP client and an EPP server.
RFC 3736	Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6
	Authors: R. Droms. Date: April 2004 Formats: txt pdf Status: PROPOSED STANDARD Stateless Dynamic Host Configuration Protocol service for IPv6(DHCPv6) is used by nodes to obtain configuration information, such as the addresses of DNS recursive name servers, that does not require the maintenance of any dynamic state for individual clients. A node that uses stateless DHCP must have obtained its IPv6 addresses through some other mechanism, typically stateless address autoconfiguration. This document explains which parts of RFC 3315 must be implemented in each of the different kinds of DHCP agents so that agent can support stateless DHCP.
RFC 3737	IANA Guidelines for the Registry of Remote Monitoring (RMON) MIB modules
	Authors: B. Wijnen, A. Bierman. Date: April 2004 Formats: txt pdf Status: PROPOSED STANDARD This document defines the procedures for IANA to administer and maintain the Object Identifier (OID) tree under the Remote Monitoring(rmon) root. This memo also documents the currently assigned values.
RFC 3739	Internet X.509 Public Key Infrastructure: Qualified Certificates Profile
	Authors: S. Santesson, M. Nystrom, T. Polk. Date: March 2004 Formats: txt pdf Obsoletes: RFC 3039 Status: PROPOSED STANDARD This document forms a certificate profile, based on RFC 3280, for identity certificates issued to natural persons. The profile defines specific conventions for certificates that are qualified within a defined legal framework, named QualifiedCertificates. However, the profile does not define any legal requirements for such Qualified Certificates. The goal of this document is to define a certificate profile that supports the issuance of Qualified Certificates independent of local legal requirements. The profile is however not limited to QualifiedCertificates and further profiling may facilitate specific local needs.
RFC 3744	Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol
	Authors: G. Clemm, J. Reschke, E. Sedlar, J. Whitehead. Date: May 2004 Formats: txt pdf Status: PROPOSED STANDARD This document specifies a set of methods, headers, message bodies, properties, and reports that define Access Control extensions to theWebDAV Distributed Authoring Protocol. This protocol permits a client to read and modify access control lists that instruct a server whether to allow or deny operations upon a resource (such asHyperText Transfer Protocol (HTTP) method invocations) by a given principal. A lightweight representation of principals as Web resources supports integration of a wide range of user management repositories. Search operations allow discovery and manipulation of principals using human names.
RFC 3745	MIME Type Registrations for JPEG 2000 (ISO/IEC 15444)
	Authors: D. Singer, R. Clark, D. Lee. Date: April 2004 Formats: txt pdf Status: PROPOSED STANDARD This document serves to register and document the standard MIME types associated with the ISO/IEC 15444 standards, commonly known as JPEG2000 (Joint Photographic Experts Group).
RFC 3747	The Differentiated Services Configuration MIB
	Authors: H. Hazewinkel, Ed., D. Partain, Ed.. Date: April 2004 Formats: txt pdf Status: PROPOSED STANDARD This memo describes a MIB module that provides a conceptual layer between high-level "network-wide" policy definitions that effect configuration of the Differentiated Services (diffserv) subsystem and the instance-specific information that would include such details as the parameters for all the queues associated with each interface in a system. This essentially provides an interface for configuring differentiated services at a conceptually higher layer than that of the Differentiated Services MIB.
RFC 3748	Extensible Authentication Protocol (EAP)
	Authors: B. Aboba, L. Blunk, J. Vollbrecht, J. Carlson, H. Levkowetz, Ed.. Date: June 2004 Formats: txt pdf Obsoletes: RFC 2284 Updated by: RFC 5247 Status: PROPOSED STANDARD This document defines the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication methods. EAP typically runs directly over data link layers such asPoint-to-Point Protocol (PPP) or IEEE 802, without requiring IP. EAP provides its own support for duplicate elimination and retransmission, but is reliant on lower layer ordering guarantees.Fragmentation is not supported within EAP itself; however, individualEAP methods may support this. This document obsoletes RFC 2284. A summary of the changes between this document and RFC 2284 is available in Appendix A.
RFC 3749	Transport Layer Security Protocol Compression Methods
	Authors: S. Hollenbeck. Date: May 2004 Formats: txt pdf Status: PROPOSED STANDARD The Transport Layer Security (TLS) protocol (RFC 2246) includes features to negotiate selection of a lossless data compression method as part of the TLS Handshake Protocol and to then apply the algorithm associated with the selected method as part of the TLS RecordProtocol. TLS defines one standard compression method which specifies that data exchanged via the record protocol will not be compressed. This document describes an additional compression method associated with a lossless data compression algorithm for use withTLS, and it describes a method for the specification of additionalTLS compression methods.
RFC 3755	Legacy Resolver Compatibility for Delegation Signer (DS)
	Authors: S. Weiler. Date: May 2004 Formats: txt pdf Obsoleted by: RFC 4033, RFC 4034, RFC 4035 Updates: RFC 3658, RFC 2535 Updated by: RFC 3757, RFC 3845 Status: PROPOSED STANDARD As the DNS Security (DNSSEC) specifications have evolved, the syntax and semantics of the DNSSEC resource records (RRs) have changed.Many deployed nameservers understand variants of these semantics.Dangerous interactions can occur when a resolver that understands an earlier version of these semantics queries an authoritative server that understands the new delegation signer semantics, including at least one failure scenario that will cause an unsecured zone to be unresolvable. This document changes the type codes and mnemonics of the DNSSEC RRs (SIG, KEY, and NXT) to avoid those interactions.
RFC 3757	Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag
	Authors: O. Kolkman, J. Schlyter, E. Lewis. Date: April 2004 Formats: txt pdf Obsoleted by: RFC 4033, RFC 4034, RFC 4035 Updates: RFC 3755, RFC 2535 Status: PROPOSED STANDARD With the Delegation Signer (DS) resource record (RR), the concept of a public key acting as a secure entry point (SEP) has been introduced. During exchanges of public keys with the parent there is a need to differentiate SEP keys from other public keys in the DomainName System KEY (DNSKEY) resource record set. A flag bit in theDNSKEY RR is defined to indicate that DNSKEY is to be used as a SEP.The flag bit is intended to assist in operational procedures to correctly generate DS resource records, or to indicate what DNSKEYs are intended for static configuration. The flag bit is not to be used in the DNS verification protocol. This document updates RFC2535 and RFC 3755.
RFC 3758	Stream Control Transmission Protocol (SCTP) Partial Reliability Extension
	Authors: R. Stewart, M. Ramalho, Q. Xie, M. Tuexen, P. Conrad. Date: May 2004 Formats: txt pdf Status: PROPOSED STANDARD This memo describes an extension to the Stream Control TransmissionProtocol (SCTP) that allows an SCTP endpoint to signal to its peer that it should move the cumulative ack point forward. When both sides of an SCTP association support this extension, it can be used by an SCTP implementation to provide partially reliable data transmission service to an upper layer protocol. This memo describes the protocol extensions, which consist of a new parameter for INIT and INIT ACK, and a new FORWARD TSN chunk type, and provides one example of a partially reliable service that can be provided to the upper layer via this mechanism.
RFC 3761	The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)
	Authors: P. Faltstrom, M. Mealling. Date: April 2004 Formats: txt pdf Obsoletes: RFC 2916 Obsoleted by: RFC 6116, RFC 6117 Status: PROPOSED STANDARD This document discusses the use of the Domain Name System (DNS) for storage of E.164 numbers. More specifically, how DNS can be used for identifying available services connected to one E.164 number. It specifically obsoletes RFC 2916 to bring it in line with the DynamicDelegation Discovery System (DDDS) Application specification found in the document series specified in RFC 3401. It is very important to note that it is impossible to read and understand this document without reading the documents discussed in RFC 3401.
RFC 3762	Telephone Number Mapping (ENUM) Service Registration for H.323
	Authors: O. Levin. Date: April 2004 Formats: txt pdf Updated by: RFC 6118 Status: PROPOSED STANDARD The H.323 specification defines a means for building multimedia communication services over an arbitrary Packet Based Network, including the Internet. This document registers a Telephone NumberMapping (ENUM) service for H.323 according to specifications and guidelines in RFC 3761.
RFC 3764	enumservice registration for Session Initiation Protocol (SIP) Addresses-of-Record
	Authors: J. Peterson. Date: April 2004 Formats: txt pdf Updated by: RFC 6118 Status: PROPOSED STANDARD This document registers an Electronic Number (ENUM) service for theSession Initiation Protocol (SIP), pursuant to the guidelines in RFC3761. Specifically, this document focuses on provisioning SIP addresses-of-record in ENUM.
RFC 3767	Securely Available Credentials Protocol
	Authors: S. Farrell, Ed.. Date: June 2004 Formats: txt pdf Status: PROPOSED STANDARD This document describes a protocol whereby a user can acquire cryptographic credentials (e.g., private keys, PKCS #15 structures) from a credential server, using a workstation that has locally trusted software installed, but with no user-specific configuration.The protocol's payloads are described in XML. This memo also specifies a Blocks Extensible Exchange Protocol (BEEP) profile of the protocol. Security requirements are met by mandating support forTLS and/or DIGEST-MD5 (through BEEP).
RFC 3770	Certificate Extensions and Attributes Supporting Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN)
	Authors: R. Housley, T. Moore. Date: May 2004 Formats: txt pdf Obsoleted by: RFC 4334 Status: PROPOSED STANDARD This document defines two EAP extended key usage values and a public key certificate extension to carry Wireless LAN (WLAN) System Service identifiers (SSIDs).
RFC 3771	The Lightweight Directory Access Protocol (LDAP) Intermediate Response Message
	Authors: R. Harrison, K. Zeilenga. Date: April 2004 Formats: txt pdf Obsoleted by: RFC 4511, RFC 4510 Updates: RFC 2251 Status: PROPOSED STANDARD This document defines and describes the IntermediateResponse message, a general mechanism for defining single-request/multiple-response operations in Lightweight Directory Access Protocol (LDAP). TheIntermediateResponse message is defined in such a way that the protocol behavior of existing LDAP operations is maintained. This message is intended to be used in conjunction with the LDAPExtendedRequest and ExtendedResponse to define new single- request/multiple-response operations or in conjunction with a control when extending existing LDAP operations in a way that requires them to return intermediate response information.
RFC 3772	Point-to-Point Protocol (PPP) Vendor Protocol
	Authors: J. Carlson, R. Winslow. Date: May 2004 Formats: txt pdf Status: PROPOSED STANDARD The Point-to-Point Protocol (PPP) defines a Link Control Protocol(LCP) and a method for negotiating the use of multi-protocol traffic over point-to-point links. The PPP Vendor Extensions document adds vendor-specific general-purpose Configuration Option and Code numbers. This document extends these features to cover vendor- specific Network, Authentication, and Control Protocols.
RFC 3775	Mobility Support in IPv6
	Authors: D. Johnson, C. Perkins, J. Arkko. Date: June 2004 Formats: txt pdf Obsoleted by: RFC 6275 Status: PROPOSED STANDARD This document specifies a protocol which allows nodes to remain reachable while moving around in the IPv6 Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about the mobile node's current location. IPv6 packets addressed to a mobile node's home address are transparently routed to its care-of address. The protocol enables IPv6 nodes to cache the binding of a mobile node's home address with its care-of address, and to then send any packets destined for the mobile node directly to it at this care-of address. To support this operation,Mobile IPv6 defines a new IPv6 protocol and a new destination option.All IPv6 nodes, whether mobile or stationary, can communicate with mobile nodes.
RFC 3776	Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents
	Authors: J. Arkko, V. Devarapalli, F. Dupont. Date: June 2004 Formats: txt pdf Updated by: RFC 4877 Status: PROPOSED STANDARD Mobile IPv6 uses IPsec to protect signaling between the home agent and the mobile node. Mobile IPv6 base document defines the main requirements these nodes must follow. This document discusses these requirements in more depth, illustrates the used packet formats, describes suitable configuration procedures, and shows how implementations can process the packets in the right order.
RFC 3779	X.509 Extensions for IP Addresses and AS Identifiers
	Authors: C. Lynn, S. Kent, K. Seo. Date: June 2004 Formats: txt pdf Status: PROPOSED STANDARD This document defines two X.509 v3 certificate extensions. The first binds a list of IP address blocks, or prefixes, to the subject of a certificate. The second binds a list of autonomous system identifiers to the subject of a certificate. These extensions may be used to convey the authorization of the subject to use the IP addresses and autonomous system identifiers contained in the extensions.
RFC 3782	The NewReno Modification to TCP's Fast Recovery Algorithm
	Authors: S. Floyd, T. Henderson, A. Gurtov. Date: April 2004 Formats: txt pdf Obsoletes: RFC 2582 Obsoleted by: RFC 6582 Status: PROPOSED STANDARD The purpose of this document is to advance NewReno TCP's FastRetransmit and Fast Recovery algorithms in RFC 2582 from Experimental to Standards Track status. The main change in this document relative to RFC 2582 is to specify the Careful variant of NewReno's Fast Retransmit and Fast Recovery algorithms. The base algorithm described in RFC 2582 did not attempt to avoid unnecessary multiple Fast Retransmits that can occur after a timeout. However, RFC 2582 also defined "Careful" and "Less Careful" variants that avoid these unnecessary Fast Retransmits, and recommended the Careful variant. This document specifies the previously-named "Careful" variant as the basic version of NewRenoTCP.
RFC 3788	Security Considerations for Signaling Transport (SIGTRAN) Protocols
	Authors: J. Loughney, M. Tuexen, Ed., J. Pastor-Balbas. Date: June 2004 Formats: txt pdf Status: PROPOSED STANDARD This document discusses how Transport Layer Security (TLS) and IPsec can be used to secure communication for SIGTRAN protocols. The main goal is to recommend the minimum security means that a SIGTRAN node must implement in order to attain secured communication. The support of IPsec is mandatory for all nodes running SIGTRAN protocols. TLS support is optional.
RFC 3804	Voice Profile for Internet Mail (VPIM) Addressing
	Authors: G. Parsons. Date: June 2004 Formats: txt pdf Status: PROPOSED STANDARD This document lists the various Voice Profile for Internet Mail(VPIM) email address formats that are currently in common use and defines several new address formats for special case usage.Requirements are imposed on the formats of addresses used in VPIM submission mode.
RFC 3805	Printer MIB v2
	Authors: R. Bergman, H. Lewis, I. McDonald. Date: June 2004 Formats: txt pdf Obsoletes: RFC 1759 Status: PROPOSED STANDARD This document provides definitions of models and manageable objects for printing environments. The objects included in this MIB apply to physical, as well as logical entities within a printing device. This document obsoletes RFC 1759.
RFC 3807	V5.2-User Adaptation Layer (V5UA)
	Authors: E. Weilandt, N. Khanchandani, S. Rao. Date: June 2004 Formats: txt pdf Updates: RFC 3057 Status: PROPOSED STANDARD This document defines a mechanism for the backhauling of V5.2 messages over IP using the Stream Control Transmission Protocol(SCTP). This protocol may be used between a Signaling Gateway (SG) and a Media Gateway controller (MGC). It is assumed that the SG receives V5.2 signaling over a standard V5.2 interface. This document builds on the ISDN User Adaptation Layer Protocol (RFC3057). It defines all necessary extensions to the IUA Protocol needed for the V5UA protocol implementation.
RFC 3810	Multicast Listener Discovery Version 2 (MLDv2) for IPv6
	Authors: R. Vida, Ed., L. Costa, Ed.. Date: June 2004 Formats: txt pdf Updates: RFC 2710 Updated by: RFC 4604 Status: PROPOSED STANDARD This document updates RFC 2710, and it specifies Version 2 of theMulticast Listener Discovery Protocol (MLDv2). MLD is used by anIPv6 router to discover the presence of multicast listeners on directly attached links, and to discover which multicast addresses are of interest to those neighboring nodes. MLDv2 is designed to be interoperable with MLDv1. MLDv2 adds the ability for a node to report interest in listening to packets with a particular multicast address only from specific source addresses or from all sources except for specific source addresses.
RFC 3811	Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management
	Authors: T. Nadeau, Ed., J. Cucchiara, Ed.. Date: June 2004 Formats: txt pdf Status: PROPOSED STANDARD This memo defines a Management Information Base (MIB) module which contains Textual Conventions to represent commonly used MultiprotocolLabel Switching (MPLS) management information. The intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and used in MPLS related MIB modules that would otherwise define their own representations.
RFC 3812	Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)
	Authors: C. Srinivasan, A. Viswanathan, T. Nadeau. Date: June 2004 Formats: txt pdf Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes managed objects for Multiprotocol LabelSwitching (MPLS) based traffic engineering (TE).
RFC 3813	Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB)
	Authors: C. Srinivasan, A. Viswanathan, T. Nadeau. Date: June 2004 Formats: txt pdf Status: PROPOSED STANDARD This memo defines an portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes managed objects to configure and/or monitor a Multiprotocol Label Switching (MPLS) Label Switching Router(LSR).
RFC 3814	Multiprotocol Label Switching (MPLS) Forwarding Equivalence Class To Next Hop Label Forwarding Entry (FEC-To-NHLFE) Management Information Base (MIB)
	Authors: T. Nadeau, C. Srinivasan, A. Viswanathan. Date: June 2004 Formats: txt pdf Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes managed objects for defining, configuring, and monitoring Forwarding Equivalence Class (FEC) toNext Hop Label Forwarding Entry (NHLFE) mappings and corresponding actions for use with Multiprotocol Label Switching (MPLS).
RFC 3815	Definitions of Managed Objects for the Multiprotocol Label Switching (MPLS), Label Distribution Protocol (LDP)
	Authors: J. Cucchiara, H. Sjostrand, J. Luciani. Date: June 2004 Formats: txt pdf Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes managed objects for the MultiprotocolLabel Switching, Label Distribution Protocol (LDP).
RFC 3816	Definitions of Managed Objects for RObust Header Compression (ROHC)
	Authors: J. Quittek, M. Stiemerling, H. Hartenstein. Date: June 2004 Formats: txt pdf Status: PROPOSED STANDARD 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 a set of managed objects that allow monitoring of running instances of RObust Header Compression (ROHC).The managed objects defined in this memo are grouped into three MIB modules. The ROHC-MIB module defines managed objects shared by allROHC profiles, the ROHC-UNCOMPRESSED-MIB module defines managed objects specific to the ROHC uncompressed profile, the ROHC-RTP-MIB module defines managed objects specific to the ROHC RTP (Real-TimeTransport Protocol) profile, the ROHC UDP (User Datagram Protocol) profile, the ROHC ESP (Encapsulating Security Payload) profile, and the ROHC LLA (Link Layer Assisted) profile.
RFC 3820	Internet X.509 Public Key Infrastructure (PKI) Proxy Certificate Profile
	Authors: S. Tuecke, V. Welch, D. Engert, L. Pearlman, M. Thompson. Date: June 2004 Formats: txt pdf Status: PROPOSED STANDARD This document forms a certificate profile for Proxy Certificates, based on X.509 Public Key Infrastructure (PKI) certificates as defined in RFC 3280, for use in the Internet. The term ProxyCertificate is used to describe a certificate that is derived from, and signed by, a normal X.509 Public Key End Entity Certificate or by another Proxy Certificate for the purpose of providing restricted proxying and delegation within a PKI based authentication system.
RFC 3821	Fibre Channel Over TCP/IP (FCIP)
	Authors: M. Rajagopal, E. Rodriguez, R. Weber. Date: July 2004 Formats: txt pdf Status: PROPOSED STANDARD Fibre Channel Over TCP/IP (FCIP) describes mechanisms that allow the interconnection of islands of Fibre Channel storage area networks over IP-based networks to form a unified storage area network in a single Fibre Channel fabric. FCIP relies on IP-based network services to provide the connectivity between the storage area network islands over local area networks, metropolitan area networks, or wide area networks.
RFC 3822	Finding Fibre Channel over TCP/IP (FCIP) Entities Using Service Location Protocol version 2 (SLPv2)
	Authors: D. Peterson. Date: July 2004 Formats: txt pdf Status: PROPOSED STANDARD This document defines the use of Service Location Protocol version 2(SLPv2) by Fibre Channel over TCP/IP (FCIP) Entities.
RFC 3825	Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information
	Authors: J. Polk, J. Schnizlein, M. Linsner. Date: July 2004 Formats: txt pdf Obsoleted by: RFC 6225 Status: PROPOSED STANDARD This document specifies a Dynamic Host Configuration Protocol Option for the coordinate-based geographic location of the client. TheLocation Configuration Information (LCI) includes latitude, longitude, and altitude, with resolution indicators for each. The reference datum for these values is also included.
RFC 3826	The Advanced Encryption Standard (AES) Cipher Algorithm in the SNMP User-based Security Model
	Authors: U. Blumenthal, F. Maino, K. McCloghrie. Date: June 2004 Formats: txt pdf Status: PROPOSED STANDARD This document describes a symmetric encryption protocol that supplements the protocols described in the User-based Security Model(USM), which is a Security Subsystem for version 3 of the SimpleNetwork Management Protocol for use in the SNMP Architecture. The symmetric encryption protocol described in this document is based on the Advanced Encryption Standard (AES) cipher algorithm used inCipher FeedBack Mode (CFB), with a key size of 128 bits.
RFC 3828	The Lightweight User Datagram Protocol (UDP-Lite)
	Authors: L-A. Larzon, M. Degermark, S. Pink, L-E. Jonsson, Ed., G. Fairhurst, Ed.. Date: July 2004 Formats: txt pdf Updated by: RFC 6335 Status: PROPOSED STANDARD This document describes the Lightweight User Datagram Protocol (UDP-Lite), which is similar to the User Datagram Protocol (UDP) (RFC768), but can also serve applications in error-prone network environments that prefer to have partially damaged payloads delivered rather than discarded. If this feature is not used, UDP-Lite is semantically identical to UDP.
RFC 3830	MIKEY: Multimedia Internet KEYing
	Authors: J. Arkko, E. Carrara, F. Lindholm, M. Naslund, K. Norrman. Date: August 2004 Formats: txt pdf Updated by: RFC 4738, RFC 6309 Status: PROPOSED STANDARD This document describes a key management scheme that can be used for real-time applications (both for peer-to-peer communication and group communication). In particular, its use to support the Secure Real- time Transport Protocol is described in detail. Security protocols for real-time multimedia applications have started to appear. This has brought forward the need for a key management solution to support these protocols.
RFC 3831	Transmission of IPv6 Packets over Fibre Channel
	Authors: C. DeSanti. Date: July 2004 Formats: txt pdf Obsoleted by: RFC 4338 Status: PROPOSED STANDARD This document specifies the way of encapsulating IPv6 packets overFibre Channel, and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on Fibre Channel networks.
RFC 3834	Recommendations for Automatic Responses to Electronic Mail
	Authors: K. Moore. Date: August 2004 Formats: txt pdf Updated by: RFC 5436 Status: PROPOSED STANDARD This memo makes recommendations for software that automatically responds to incoming electronic mail messages, including "out of the office" or "vacation" response generators, mail filtering software, email-based information services, and other automatic responders.The purpose of these recommendations is to discourage undesirable behavior which is caused or aggravated by such software, to encourage uniform behavior (where appropriate) among automatic mail responders, and to clear up some sources of confusion among implementors of automatic email responders.
RFC 3839	MIME Type Registrations for 3rd Generation Partnership Project (3GPP) Multimedia files
	Authors: R. Castagno, D. Singer. Date: July 2004 Formats: txt pdf Updated by: RFC 6381 Status: PROPOSED STANDARD This document serves to register and document the standard MIME types associated with the 3GPP multimedia file format, which is part of the family based on the ISO Media File Format.
RFC 3840	Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)
	Authors: J. Rosenberg, H. Schulzrinne, P. Kyzivat. Date: August 2004 Formats: txt pdf Status: PROPOSED STANDARD This specification defines mechanisms by which a Session InitiationProtocol (SIP) user agent can convey its capabilities and characteristics to other user agents and to the registrar for its domain. This information is conveyed as parameters of the Contact header field.
RFC 3841	Caller Preferences for the Session Initiation Protocol (SIP)
	Authors: J. Rosenberg, H. Schulzrinne, P. Kyzivat. Date: August 2004 Formats: txt pdf Status: PROPOSED STANDARD This document describes a set of extensions to the Session InitiationProtocol (SIP) which allow a caller to express preferences about request handling in servers. These preferences include the ability to select which Uniform Resource Identifiers (URI) a request gets routed to, and to specify certain request handling directives in proxies and redirect servers. It does so by defining three new request header fields, Accept-Contact, Reject-Contact, and Request-Disposition, which specify the caller's preferences.
RFC 3842	A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP)
	Authors: R. Mahy. Date: August 2004 Formats: txt pdf Status: PROPOSED STANDARD This document describes a Session Initiation Protocol (SIP) event package to carry message waiting status and message summaries from a messaging system to an interested User Agent.
RFC 3843	RObust Header Compression (ROHC): A Compression Profile for IP
	Authors: L-E. Jonsson, G. Pelletier. Date: June 2004 Formats: txt pdf Updated by: RFC 4815 Status: PROPOSED STANDARD The original RObust Header Compression (ROHC) RFC (RFC 3095) defines a framework for header compression, along with compression protocols(profiles) for IP/UDP/RTP, IP/ESP (Encapsulating Security Payload),IP/UDP, and also a profile for uncompressed packet streams. However, no profile was defined for compression of IP only, which has been identified as a missing piece in RFC 3095. This document defines aROHC compression profile for IP, similar to the IP/UDP profile defined by RFC 3095, but simplified to exclude UDP, and enhanced to compress IP header chains of arbitrary length.
RFC 3845	DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format
	Authors: J. Schlyter, Ed.. Date: August 2004 Formats: txt pdf Obsoleted by: RFC 4033, RFC 4034, RFC 4035 Updates: RFC 3755, RFC 2535 Status: PROPOSED STANDARD This document redefines the wire format of the "Type Bit Map" field in the DNS NextSECure (NSEC) resource record RDATA format to cover the full resource record (RR) type space.
RFC 3846	Mobile IPv4 Extension for Carrying Network Access Identifiers
	Authors: F. Johansson, T. Johansson. Date: June 2004 Formats: txt pdf Status: PROPOSED STANDARD When a mobile node moves between two foreign networks, it has to be re-authenticated. If the home network has both multipleAuthentication Authorization and Accounting (AAA) servers and HomeAgents (HAs) in use, the Home AAA server may not have sufficient information to process the re-authentication correctly (i.e., to ensure that the same HA continues to be used). This document defines a Mobile IP extension that carries identities for the Home AAA and HA servers in the form of Network Access Identifiers (NAIs). The extension allows a Home Agent to pass its identity (and that of theHome AAA server) to the mobile node, which can then pass it on to the local AAA server when changing its point of attachment. This extension may also be used in other situations requiring communication of a NAI between Mobile IP nodes.
RFC 3850	Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling
	Authors: B. Ramsdell, Ed.. Date: July 2004 Formats: txt pdf Obsoletes: RFC 2632 Obsoleted by: RFC 5750 Status: PROPOSED STANDARD This document specifies conventions for X.509 certificate usage bySecure/Multipurpose Internet Mail Extensions (S/MIME) agents. S/MIME provides a method to send and receive secure MIME messages, and certificates are an integral part of S/MIME agent processing. S/MIME agents validate certificates as described in RFC 3280, the InternetX.509 Public Key Infrastructure Certificate and CRL Profile. S/MIME agents must meet the certificate processing requirements in this document as well as those in RFC 3280.
RFC 3851	Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification
	Authors: B. Ramsdell, Ed.. Date: July 2004 Formats: txt pdf Obsoletes: RFC 2633 Obsoleted by: RFC 5751 Status: PROPOSED STANDARD This document defines Secure/Multipurpose Internet Mail Extensions(S/MIME) version 3.1. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin.Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 2633.
RFC 3852	Cryptographic Message Syntax (CMS)
	Authors: R. Housley. Date: July 2004 Formats: txt pdf Obsoletes: RFC 3369 Obsoleted by: RFC 5652 Updated by: RFC 4853, RFC 5083 Status: PROPOSED STANDARD This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content.
RFC 3853	S/MIME Advanced Encryption Standard (AES) Requirement for the Session Initiation Protocol (SIP)
	Authors: J. Peterson. Date: July 2004 Formats: txt pdf Updates: RFC 3261 Status: PROPOSED STANDARD RFC 3261 currently specifies 3DES as the mandatory-to-implement ciphersuite for implementations of S/MIME in the Session InitiationProtocol (SIP). This document updates the normative guidance of RFC3261 to require the Advanced Encryption Standard (AES) for S/MIME.
RFC 3854	Securing X.400 Content with Secure/Multipurpose Internet Mail Extensions (S/MIME)
	Authors: P. Hoffman, C. Bonatti, A. Eggen. Date: July 2004 Formats: txt pdf Status: PROPOSED STANDARD This document describes a protocol for adding cryptographic signature and encryption services to X.400 content with Secure/MultipurposeInternet Mail Extensions (S/MIME).
RFC 3855	Transporting Secure/Multipurpose Internet Mail Extensions (S/MIME) Objects in X.400
	Authors: P. Hoffman, C. Bonatti. Date: July 2004 Formats: txt pdf Status: PROPOSED STANDARD This document describes protocol options for conveying objects that have been protected using the Cryptographic Message Syntax (CMS) andSecure/Multipurpose Internet Mail Extensions (S/MIME) version 3.1 over an X.400 message transfer system.
RFC 3856	A Presence Event Package for the Session Initiation Protocol (SIP)
	Authors: J. Rosenberg. Date: August 2004 Formats: txt pdf Status: PROPOSED STANDARD This document describes the usage of the Session Initiation Protocol(SIP) for subscriptions and notifications of presence. Presence is defined as the willingness and ability of a user to communicate with other users on the network. Historically, presence has been limited to "on-line" and "off-line" indicators; the notion of presence here is broader. Subscriptions and notifications of presence are supported by defining an event package within the general SIP event notification framework. This protocol is also compliant with theCommon Presence Profile (CPP) framework.
RFC 3857	A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP)
	Authors: J. Rosenberg. Date: August 2004 Formats: txt pdf Status: PROPOSED STANDARD This document defines the watcher information template-package for the Session Initiation Protocol (SIP) event framework. Watcher information refers to the set of users subscribed to a particular resource within a particular event package. Watcher information changes dynamically as users subscribe, unsubscribe, are approved, or are rejected. A user can subscribe to this information, and therefore learn about changes to it. This event package is a template-package because it can be applied to any event package, including itself.
RFC 3858	An Extensible Markup Language (XML) Based Format for Watcher Information
	Authors: J. Rosenberg. Date: August 2004 Formats: txt pdf Status: PROPOSED STANDARD Watchers are defined as entities that request (i.e., subscribe to) information about a resource. There is fairly complex state associated with these subscriptions. The union of the state for all subscriptions to a particular resource is called the watcher information for that resource. This state is dynamic, changing as subscribers come and go. As a result, it is possible, and indeed useful, to subscribe to the watcher information for a particular resource. In order to enable this, a format is needed to describe the state of watchers on a resource. This specification describes anExtensible Markup Language (XML) document format for such state.
RFC 3859	Common Profile for Presence (CPP)
	Authors: J. Peterson. Date: August 2004 Formats: txt pdf Status: PROPOSED STANDARD At the time this document was written, numerous presence protocols were in use (largely as components of commercial instant messaging services), and little interoperability between services based on these protocols has been achieved. This specification defines common semantics and data formats for presence to facilitate the creation of gateways between presence services.
RFC 3860	Common Profile for Instant Messaging (CPIM)
	Authors: J. Peterson. Date: August 2004 Formats: txt pdf Status: PROPOSED STANDARD At the time this document was written, numerous instant messaging protocols were in use, and little interoperability between services based on these protocols has been achieved. This specification defines common semantics and data formats for instant messaging to facilitate the creation of gateways between instant messaging services.
RFC 3861	Address Resolution for Instant Messaging and Presence
	Authors: J. Peterson. Date: August 2004 Formats: txt pdf Status: PROPOSED STANDARD Presence and instant messaging are defined in RFC 2778. The CommonProfiles for Presence and Instant Messaging define two UniversalResource Identifier (URI) schemes: 'im' for INSTANT INBOXes and'pres' for PRESENTITIES. This document provides guidance for locating the resources associated with URIs that employ these schemes.
RFC 3862	Common Presence and Instant Messaging (CPIM): Message Format
	Authors: G. Klyne, D. Atkins. Date: August 2004 Formats: txt pdf Status: PROPOSED STANDARD This memo defines the MIME content type 'Message/CPIM', a message format for protocols that conform to the Common Profile for InstantMessaging (CPIM) specification.
RFC 3863	Presence Information Data Format (PIDF)
	Authors: H. Sugano, S. Fujimoto, G. Klyne, A. Bateman, W. Carr, J. Peterson. Date: August 2004 Formats: txt pdf Status: PROPOSED STANDARD This memo specifies the Common Profile for Presence (CPP) PresenceInformation Data Format (PIDF) as a common presence data format forCPP-compliant Presence protocols, and also defines a new media type"application/pidf+xml" to represent the XML MIME entity for PIDF.
RFC 3865	A No Soliciting Simple Mail Transfer Protocol (SMTP) Service Extension
	Authors: C. Malamud. Date: September 2004 Formats: txt pdf Status: PROPOSED STANDARD This document proposes an extension to Soliciting Simple MailTransfer Protocol (SMTP) for an electronic mail equivalent to the real-world "No Soliciting" sign. In addition to the service extension, a new message header and extensions to the existing"received" message header are described.
RFC 3866	Language Tags and Ranges in the Lightweight Directory Access Protocol (LDAP)
	Authors: K. Zeilenga, Ed.. Date: July 2004 Formats: txt pdf Obsoletes: RFC 2596 Status: PROPOSED STANDARD It is often desirable to be able to indicate the natural language associated with values held in a directory and to be able to query the directory for values which fulfill the user's language needs.This document details the use of Language Tags and Ranges in theLightweight Directory Access Protocol (LDAP).
RFC 3868	Signalling Connection Control Part User Adaptation Layer (SUA)
	Authors: J. Loughney, Ed., G. Sidebottom, L. Coene, G. Verwimp, J. Keller, B. Bidulock. Date: October 2004 Formats: txt pdf Status: PROPOSED STANDARD This document defines a protocol for the transport of any SignallingConnection Control Part-User signalling over IP using the StreamControl Transmission Protocol. The protocol is designed to be modular and symmetric, to allow it to work in diverse architectures, such as a Signalling Gateway to IP Signalling Endpoint architecture as well as a peer-to-peer IP Signalling Endpoint architecture.
RFC 3872	Management Information Base for Telephony Routing over IP (TRIP)
	Authors: D. Zinman, D. Walker, J. Jiang. Date: September 2004 Formats: txt pdf Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that are used to manage Telephony Routing over IP (TRIP) devices.
RFC 3873	Stream Control Transmission Protocol (SCTP) Management Information Base (MIB)
	Authors: J. Pastor, M. Belinchon. Date: September 2004 Formats: txt pdf Status: PROPOSED STANDARD The Stream Control Transmission Protocol (SCTP) is a reliable transport protocol operating on top of a connectionless packet network such as IP. It is designed to transport public switched telephone network (PSTN) signaling messages over the connectionless packet network, but is capable of broader applications. This memo defines the Management Information Base (MIB) module which describes the minimum set of objects needed to manage the implementation of the SCTP.
RFC 3876	Returning Matched Values with the Lightweight Directory Access Protocol version 3 (LDAPv3)
	Authors: D. Chadwick, S. Mullan. Date: September 2004 Formats: txt pdf Status: PROPOSED STANDARD This document describes a control for the Lightweight DirectoryAccess Protocol version 3 that is used to return a subset of attribute values from an entry. Specifically, only those values that match a "values return" filter. Without support for this control, a client must retrieve all of an attribute's values and search for specific values locally.
RFC 3877	Alarm Management Information Base (MIB)
	Authors: S. Chisholm, D. Romascanu. Date: September 2004 Formats: txt pdf Status: PROPOSED STANDARD 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 management objects used for modelling and storing alarms.
RFC 3878	Alarm Reporting Control Management Information Base (MIB)
	Authors: H. Lam, A. Huynh, D. Perkins. Date: September 2004 Formats: txt pdf Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it defines objects for controlling the reporting of alarm conditions.
RFC 3879	Deprecating Site Local Addresses
	Authors: C. Huitema, B. Carpenter. Date: September 2004 Formats: txt pdf Status: PROPOSED STANDARD This document describes the issues surrounding the use of IPv6 site- local unicast addresses in their original form, and formally deprecates them. This deprecation does not prevent their continued use until a replacement has been standardized and implemented.
RFC 3880	Call Processing Language (CPL): A Language for User Control of Internet Telephony Services
	Authors: J. Lennox, X. Wu, H. Schulzrinne. Date: October 2004 Formats: txt pdf Status: PROPOSED STANDARD This document defines the Call Processing Language (CPL), a language to describe and control Internet telephony services. It is designed to be implementable on either network servers or user agents. It is meant to be simple, extensible, easily edited by graphical clients, and independent of operating system or signalling protocol. It is suitable for running on a server where users may not be allowed to execute arbitrary programs, as it has no variables, loops, or ability to run external programs.
RFC 3883	Detecting Inactive Neighbors over OSPF Demand Circuits (DC)
	Authors: S. Rao, A. Zinin, A. Roy. Date: October 2004 Formats: txt pdf Updates: RFC 1793 Status: PROPOSED STANDARD OSPF is a link-state intra-domain routing protocol used in IP networks. OSPF behavior over demand circuits (DC) is optimized inRFC 1793 to minimize the amount of overhead traffic. A part of theOSPF demand circuit extensions is the Hello suppression mechanism.This technique allows a demand circuit to go down when no interesting traffic is going through the link. However, it also introduces a problem, where it becomes impossible to detect an OSPF-inactive neighbor over such a link. This memo introduces a new mechanism called "neighbor probing" to address the above problem.
RFC 3885	SMTP Service Extension for Message Tracking
	Authors: E. Allman, T. Hansen. Date: September 2004 Formats: txt pdf Updates: RFC 3461 Status: PROPOSED STANDARD This memo defines an extension to the SMTP service whereby a client may mark a message for future tracking.
RFC 3886	An Extensible Message Format for Message Tracking Responses
	Authors: E. Allman. Date: September 2004 Formats: txt pdf Updates: RFC 3463 Status: PROPOSED STANDARD Message Tracking is expected to be used to determine the status of undelivered e-mail upon request. Tracking is used in conjunction with Delivery Status Notifications (DSN) and Message DispositionNotifications (MDN); generally, a message tracking request will be issued only when a DSN or MDN has not been received within a reasonable timeout period. This memo defines a MIME content-type for message tracking status in the same spirit as RFC 3464, "An Extensible Message Format forDelivery Status Notifications". It is to be issued upon a request as described in "Message Tracking Query Protocol". This memo defines only the format of the status information. An extension to SMTP to label messages for further tracking and request tracking status is defined in a separate memo.
RFC 3887	Message Tracking Query Protocol
	Authors: T. Hansen. Date: September 2004 Formats: txt pdf Status: PROPOSED STANDARD Customers buying enterprise message systems often ask: Can I track the messages? Message tracking is the ability to find out the path that a particular message has taken through a messaging system and the current routing status of that message. This document describes the Message Tracking Query Protocol that is used in conjunction with extensions to the ESMTP protocol to provide a complete message tracking solution for the Internet.
RFC 3890	A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP)
	Authors: M. Westerlund. Date: September 2004 Formats: txt pdf Status: PROPOSED STANDARD This document defines a Session Description Protocol (SDP) TransportIndependent Application Specific Maximum (TIAS) bandwidth modifier that does not include transport overhead; instead an additional packet rate attribute is defined. The transport independent bit-rate value together with the maximum packet rate can then be used to calculate the real bit-rate over the transport actually used. The existing SDP bandwidth modifiers and their values include the bandwidth needed for the transport and IP layers. When using SDP with protocols like the Session Announcement Protocol (SAP), theSession Initiation Protocol (SIP), and the Real-Time StreamingProtocol (RTSP), and when the involved hosts has different transport overhead, for example due to different IP versions, the interpretation of what lower layer bandwidths are included is not clear.
RFC 3891	The Session Initiation Protocol (SIP) "Replaces" Header
	Authors: R. Mahy, B. Biggs, R. Dean. Date: September 2004 Formats: txt pdf Status: PROPOSED STANDARD This document defines a new header for use with Session InitiationProtocol (SIP) multi-party applications and call control. TheReplaces header is used to logically replace an existing SIP dialog with a new SIP dialog. This primitive can be used to enable a variety of features, for example: "Attended Transfer" and "CallPickup". Note that the definition of these example features is non- normative.
RFC 3892	The Session Initiation Protocol (SIP) Referred-By Mechanism
	Authors: R. Sparks. Date: September 2004 Formats: txt pdf Status: PROPOSED STANDARD The Session Initiation Protocol (SIP) REFER method provides a mechanism where one party (the referrer) gives a second party (the referee) an arbitrary URI to reference. If that URI is a SIP URI, the referee will send a SIP request, often an INVITE, to that URI(the refer target). This document extends the REFER method, allowing the referrer to provide information about the REFER request to the refer target using the referee as an intermediary. This information includes the identity of the referrer and the URI to which the referrer referred. The mechanism utilizes S/MIME to help protect this information from a malicious intermediary. This protection is optional, but a recipient may refuse to accept a request unless it is present.
RFC 3893	Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format
	Authors: J. Peterson. Date: September 2004 Formats: txt pdf Status: PROPOSED STANDARD RFC 3261 introduces the concept of adding an S/MIME body to a SessionInitiation Protocol (SIP) request or response in order to provide reference integrity over its headers. This document provides a more specific mechanism to derive integrity and authentication properties from an 'authenticated identity body', a digitally-signed SIP message, or message fragment. A standard format for such bodies(known as Authenticated Identity Bodies, or AIBs) is given in this document. Some considerations for the processing of AIBs by recipients of SIP messages with such bodies are also given.
RFC 3894	Sieve Extension: Copying Without Side Effects
	Authors: J. Degener. Date: October 2004 Formats: txt pdf Status: PROPOSED STANDARD The Sieve scripting language allows users to control handling and disposal of their incoming e-mail. By default, an e-mail message that is processed by a Sieve script is saved in the owner's "inbox".Actions such as "fileinto" and "redirect" cancel this default behavior. This document defines a new keyword parameter, ":copy", to be used with the Sieve "fileinto" and "redirect" actions. Adding ":copy" to an action suppresses cancellation of the default "inbox" save. It allows users to add commands to an existing script without changing the meaning of the rest of the script.
RFC 3895	Definitions of Managed Objects for the DS1, E1, DS2, and E2 Interface Types
	Authors: O. Nicklass, Ed.. Date: September 2004 Formats: txt pdf Obsoletes: RFC 2495 Obsoleted by: RFC 4805 Status: PROPOSED STANDARD 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 used for managing DS1, E1, DS2 and E2 interfaces. This document is a companion to the documents that define Managed Objects for the DS0, DS3/E3 and SynchronousOptical Network/Synchronous Digital Hierarchy (SONET/SDH) InterfaceTypes. This document obsoletes RFC 2495.
RFC 3896	Definitions of Managed Objects for the DS3/E3 Interface Type
	Authors: O. Nicklass, Ed.. Date: September 2004 Formats: txt pdf Obsoletes: RFC 2496 Status: PROPOSED STANDARD 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 used for managing DS3 and E3 interfaces. This document is a companion to the documents that define Managed Objects for the DS0, DS1/E1/DS2/E2 and SynchronousOptical Network/Synchronous Digital Hierarchy (SONET/SDH) InterfaceTypes. This document obsoletes RFC 2496.
RFC 3898	Network Information Service (NIS) Configuration Options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
	Authors: V. Kalusivalingam. Date: October 2004 Formats: txt pdf Status: PROPOSED STANDARD This document describes four options for Network Information Service(NIS) related configuration information in Dynamic Host ConfigurationProtocol for IPv6 (DHCPv6): NIS Servers, NIS+ Servers, NIS ClientDomain Name, NIS+ Client Domain name.
RFC 3903	Session Initiation Protocol (SIP) Extension for Event State Publication
	Authors: A. Niemi, Ed.. Date: October 2004 Formats: txt pdf Status: PROPOSED STANDARD This document describes an extension to the Session InitiationProtocol (SIP) for publishing event state used within the SIP Events framework. The first application of this extension is for the publication of presence information. The mechanism described in this document can be extended to support publication of any event state for which there exists an appropriate event package. It is not intended to be a general-purpose mechanism for transport of arbitrary data, as there are better-suited mechanisms for this purpose.
RFC 3909	Lightweight Directory Access Protocol (LDAP) Cancel Operation
	Authors: K. Zeilenga. Date: October 2004 Formats: txt pdf Status: PROPOSED STANDARD This specification describes a Lightweight Directory Access Protocol(LDAP) extended operation to cancel (or abandon) an outstanding operation. Unlike the LDAP Abandon operation, but like the X.511Directory Access Protocol (DAP) Abandon operation, this operation has a response which provides an indication of its outcome.
RFC 3910	The SPIRITS (Services in PSTN requesting Internet Services) Protocol
	Authors: V. Gurbani, Ed., A. Brusilovsky, I. Faynberg, J. Gato, H. Lu, M. Unmehopa. Date: October 2004 Formats: txt pdf Status: PROPOSED STANDARD This document describes the Services in PSTN (Public SwitchedTelephone Network) requesting Internet Services (SPIRITS) protocol.The purpose of the SPIRITS protocol is to support services that originate in the cellular or wireline PSTN and necessitate interactions between the PSTN and the Internet. On the PSTN side, the SPIRITS services are most often initiated from the IntelligentNetwork (IN) entities. Internet Call Waiting and Internet Caller-IDDelivery are examples of SPIRITS services, as are location-based services on the cellular network. The protocol defines the building blocks from which many other services can be built.
RFC 3911	The Session Initiation Protocol (SIP) "Join" Header
	Authors: R. Mahy, D. Petrie. Date: October 2004 Formats: txt pdf Status: PROPOSED STANDARD This document defines a new header for use with SIP multi-party applications and call control. The Join header is used to logically join an existing SIP dialog with a new SIP dialog. This primitive can be used to enable a variety of features, for example: "Barge-In", answering-machine-style "Message Screening" and "Call CenterMonitoring". Note that definition of these example features is non- normative.
RFC 3915	Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP)
	Authors: S. Hollenbeck. Date: September 2004 Formats: txt pdf Status: PROPOSED STANDARD This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the management of Domain Name System (DNS) domain names subject to "grace period" policies defined by theInternet Corporation for Assigned Names and Numbers (ICANN). Grace period policies exist to allow protocol actions to be reversed or otherwise revoked during a short period of time after the protocol action has been performed. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for grace period processing.
RFC 3920	Extensible Messaging and Presence Protocol (XMPP): Core
	Authors: P. Saint-Andre, Ed.. Date: October 2004 Formats: txt pdf Obsoleted by: RFC 6120 Updated by: RFC 6122 Status: PROPOSED STANDARD This memo defines the core features of the Extensible Messaging andPresence Protocol (XMPP), a protocol for streaming Extensible MarkupLanguage (XML) elements in order to exchange structured information in close to real time between any two network endpoints. While XMPP provides a generalized, extensible framework for exchanging XML data, it is used mainly for the purpose of building instant messaging and presence applications that meet the requirements of RFC 2779.
RFC 3921	Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence
	Authors: P. Saint-Andre, Ed.. Date: October 2004 Formats: txt pdf Obsoleted by: RFC 6121 Status: PROPOSED STANDARD This memo describes extensions to and applications of the core features of the Extensible Messaging and Presence Protocol (XMPP) that provide the basic instant messaging (IM) and presence functionality defined in RFC 2779.
RFC 3922	Mapping the Extensible Messaging and Presence Protocol (XMPP) to Common Presence and Instant Messaging (CPIM)
	Authors: P. Saint-Andre. Date: October 2004 Formats: txt pdf Status: PROPOSED STANDARD This memo describes a mapping between the Extensible Messaging andPresence Protocol (XMPP) and the Common Presence and InstantMessaging (CPIM) specifications.
RFC 3923	End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP)
	Authors: P. Saint-Andre. Date: October 2004 Formats: txt pdf Status: PROPOSED STANDARD This memo defines methods of end-to-end signing and object encryption for the Extensible Messaging and Presence Protocol (XMPP).
RFC 3925	Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version 4 (DHCPv4)
	Authors: J. Littlefield. Date: October 2004 Formats: txt pdf Status: PROPOSED STANDARD The Dynamic Host Configuration Protocol (DHCP) options for VendorClass and Vendor-Specific Information can be limiting or ambiguous when a DHCP client represents multiple vendors. This document defines two new options, modeled on the IPv6 options for vendor class and vendor-specific information, that contain Enterprise Numbers to remove ambiguity.
RFC 3927	Dynamic Configuration of IPv4 Link-Local Addresses
	Authors: S. Cheshire, B. Aboba, E. Guttman. Date: May 2005 Formats: txt pdf Status: PROPOSED STANDARD To participate in wide-area IP networking, a host needs to be configured with IP addresses for its interfaces, either manually by the user or automatically from a source on the network such as aDynamic Host Configuration Protocol (DHCP) server. Unfortunately, such address configuration information may not always be available.It is therefore beneficial for a host to be able to depend on a useful subset of IP networking functions even when no address configuration is available. This document describes how a host may automatically configure an interface with an IPv4 address within the169.254/16 prefix that is valid for communication with other devices connected to the same physical (or logical) link. IPv4 Link-Local addresses are not suitable for communication with devices not directly connected to the same physical (or logical) link, and are only used where stable, routable addresses are not available (such as on ad hoc or isolated networks). This document does not recommend that IPv4 Link-Local addresses and routable addresses be configured simultaneously on the same interface.
RFC 3928	Lightweight Directory Access Protocol (LDAP) Client Update Protocol (LCUP)
	Authors: R. Megginson, Ed., M. Smith, O. Natkovich, J. Parham. Date: October 2004 Formats: txt pdf Status: PROPOSED STANDARD This document defines the Lightweight Directory Access Protocol(LDAP) Client Update Protocol (LCUP). The protocol is intended to allow an LDAP client to synchronize with the content of a directory information tree (DIT) stored by an LDAP server and to be notified about the changes to that content.
RFC 3931	Layer Two Tunneling Protocol - Version 3 (L2TPv3)
	Authors: J. Lau, Ed., M. Townsley, Ed., I. Goyret, Ed.. Date: March 2005 Formats: txt pdf Updated by: RFC 5641 Status: PROPOSED STANDARD This document describes "version 3" of the Layer Two TunnelingProtocol (L2TPv3). L2TPv3 defines the base control protocol and encapsulation for tunneling multiple Layer 2 connections between twoIP nodes. Additional documents detail the specifics for each data link type being emulated.
RFC 3938	Video-Message Message-Context
	Authors: T. Hansen. Date: October 2004 Formats: txt pdf Updates: RFC 3458 Status: PROPOSED STANDARD The Message-Context header defined in RFC 3458 describes the context of a message (for example: fax-message or voice-message). This specification extends the Message-Context header with one additional context value: "video-message". A receiving user agent (UA) may use this information as a hint to optimally present the message.
RFC 3939	Calling Line Identification for Voice Mail Messages
	Authors: G. Parsons, J. Maruszak. Date: December 2004 Formats: txt pdf Status: PROPOSED STANDARD This document describes a method for identifying the originating calling party in the headers of a stored voice mail message. Two new header fields are defined for this purpose: Caller_ID andCalled_Name. Caller_id is used to store sufficient information for the recipient to callback, or reply to, the sender of the message.Caller-name provides the name of the person sending the message.
RFC 3942	Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options
	Authors: B. Volz. Date: November 2004 Formats: txt pdf Updates: RFC 2132 Status: PROPOSED STANDARD This document updates RFC 2132 to reclassify Dynamic HostConfiguration Protocol version 4 (DHCPv4) option codes 128 to 223(decimal) as publicly defined options to be managed by IANA in accordance with RFC 2939. This document directs IANA to make these option codes available for assignment as publicly defined DHCP options for future options.
RFC 3945	Generalized Multi-Protocol Label Switching (GMPLS) Architecture
	Authors: E. Mannie, Ed.. Date: October 2004 Formats: txt pdf Updated by: RFC 6002 Status: PROPOSED STANDARD Future data and transmission networks will consist of elements such as routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexors (ADMs), photonic cross-connects(PXCs), optical cross-connects (OXCs), etc. that will use GeneralizedMulti-Protocol Label Switching (GMPLS) to dynamically provision resources and to provide network survivability using protection and restoration techniques. This document describes the architecture of GMPLS. GMPLS extendsMPLS to encompass time-division (e.g., SONET/SDH, PDH, G.709), wavelength (lambdas), and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). The focus of GMPLS is on the control plane of these various layers since each of them can use physically diverse data or forwarding planes. The intention is to cover both the signaling and the routing part of that control plane.
RFC 3946	Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control
	Authors: E. Mannie, D. Papadimitriou. Date: October 2004 Formats: txt pdf Obsoleted by: RFC 4606 Status: PROPOSED STANDARD This document is a companion to the Generalized Multi-Protocol LabelSwitching (GMPLS) signaling. It defines the Synchronous OpticalNetwork (SONET)/Synchronous Digital Hierarchy (SDH) technology specific information needed when using GMPLS signaling.
RFC 3947	Negotiation of NAT-Traversal in the IKE
	Authors: T. Kivinen, B. Swander, A. Huttunen, V. Volpe. Date: January 2005 Formats: txt pdf Status: PROPOSED STANDARD This document describes how to detect one or more network address translation devices (NATs) between IPsec hosts, and how to negotiate the use of UDP encapsulation of IPsec packets through NAT boxes inInternet Key Exchange (IKE).
RFC 3948	UDP Encapsulation of IPsec ESP Packets
	Authors: A. Huttunen, B. Swander, V. Volpe, L. DiBurro, M. Stenberg. Date: January 2005 Formats: txt pdf Status: PROPOSED STANDARD This protocol specification defines methods to encapsulate and decapsulate IP Encapsulating Security Payload (ESP) packets insideUDP packets for traversing Network Address Translators. ESP encapsulation, as defined in this document, can be used in both IPv4 and IPv6 scenarios. Whenever negotiated, encapsulation is used withInternet Key Exchange (IKE).
RFC 3953	Telephone Number Mapping (ENUM) Service Registration for Presence Services
	Authors: J. Peterson. Date: January 2005 Formats: txt pdf Updated by: RFC 6118 Status: PROPOSED STANDARD This document registers a Telephone Number Mapping (ENUM) service for presence. Specifically, this document focuses on provisioning presURIs in ENUM.
RFC 3956	Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address
	Authors: P. Savola, B. Haberman. Date: November 2004 Formats: txt pdf Updates: RFC 3306 Status: PROPOSED STANDARD This memo defines an address allocation policy in which the address of the Rendezvous Point (RP) is encoded in an IPv6 multicast group address. For Protocol Independent Multicast - Sparse Mode (PIM-SM), this can be seen as a specification of a group-to-RP mapping mechanism. This allows an easy deployment of scalable inter-domain multicast and simplifies the intra-domain multicast configuration as well. This memo updates the addressing format presented in RFC 3306.
RFC 3957	Authentication, Authorization, and Accounting (AAA) Registration Keys for Mobile IPv4
	Authors: C. Perkins, P. Calhoun. Date: March 2005 Formats: txt pdf Status: PROPOSED STANDARD Authentication, Authorization, and Accounting (AAA) servers, such asRADIUS and DIAMETER, are in use within the Internet today to provide authentication and authorization services for dial-up computers.Mobile IP for IPv4 requires strong authentication between the mobile node and its home agent. When the mobile node shares an AAA SecurityAssociation with its home AAA server, however, it is possible to use that AAA Security Association to create derived Mobility SecurityAssociations between the mobile node and its home agent, and again between the mobile node and the foreign agent currently offering connectivity to the mobile node. This document specifies extensions to Mobile IP registration messages that can be used to createMobility Security Associations between the mobile node and its home agent, and/or between the mobile node and a foreign agent.
RFC 3958	Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)
	Authors: L. Daigle, A. Newton. Date: January 2005 Formats: txt pdf Status: PROPOSED STANDARD This memo defines a generalized mechanism for application service naming that allows service location without relying on rigid domain naming conventions (so-called name hacks). The proposal defines aDynamic Delegation Discovery System (DDDS) Application to map domain name, application service name, and application protocol dynamically to target server and port.
RFC 3959	The Early Session Disposition Type for the Session Initiation Protocol (SIP)
	Authors: G. Camarillo. Date: December 2004 Formats: txt pdf Status: PROPOSED STANDARD This document defines a new disposition type (early-session) for theContent-Disposition header field in the Session Initiation Protocol(SIP). The treatment of "early-session" bodies is similar to the treatment of "session" bodies. That is, they follow the offer/answer model. Their only difference is that session descriptions whose disposition type is "early-session" are used to establish early media sessions within early dialogs, as opposed to regular sessions within regular dialogs.
RFC 3961	Encryption and Checksum Specifications for Kerberos 5
	Authors: K. Raeburn. Date: February 2005 Formats: txt pdf Status: PROPOSED STANDARD This document describes a framework for defining encryption and checksum mechanisms for use with the Kerberos protocol, defining an abstraction layer between the Kerberos protocol and related protocols, and the actual mechanisms themselves. The document also defines several mechanisms. Some are taken from RFC 1510, modified in form to fit this new framework and occasionally modified in content when the old specification was incorrect. New mechanisms are presented here as well. This document does NOT indicate which mechanisms may be considered "required to implement".
RFC 3962	Advanced Encryption Standard (AES) Encryption for Kerberos 5
	Authors: K. Raeburn. Date: February 2005 Formats: txt pdf Status: PROPOSED STANDARD The United States National Institute of Standards and Technology(NIST) has chosen a new Advanced Encryption Standard (AES), which is significantly faster and (it is believed) more secure than the oldData Encryption Standard (DES) algorithm. This document is a specification for the addition of this algorithm to the Kerberos cryptosystem suite.
RFC 3963	Network Mobility (NEMO) Basic Support Protocol
	Authors: V. Devarapalli, R. Wakikawa, A. Petrescu, P. Thubert. Date: January 2005 Formats: txt pdf Status: PROPOSED STANDARD This document describes the Network Mobility (NEMO) Basic Support protocol that enables Mobile Networks to attach to different points in the Internet. The protocol is an extension of Mobile IPv6 and allows session continuity for every node in the Mobile Network as the network moves. It also allows every node in the Mobile Network to be reachable while moving around. The Mobile Router, which connects the network to the Internet, runs the NEMO Basic Support protocol with its Home Agent. The protocol is designed so that network mobility is transparent to the nodes inside the Mobile Network.
RFC 3966	The tel URI for Telephone Numbers
	Authors: H. Schulzrinne. Date: December 2004 Formats: txt pdf Obsoletes: RFC 2806 Updated by: RFC 5341 Status: PROPOSED STANDARD This document specifies the URI (Uniform Resource Identifier) scheme"tel". The "tel" URI describes resources identified by telephone numbers. This document obsoletes RFC 2806.
RFC 3970	A Traffic Engineering (TE) MIB
	Authors: K. Kompella. Date: January 2005 Formats: txt pdf Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes managed objects for Traffic Engineered(TE) Tunnels; for example, Multi-Protocol Label Switched Paths.
RFC 3971	SEcure Neighbor Discovery (SEND)
	Authors: J. Arkko, Ed., J. Kempf, B. Zill, P. Nikander. Date: March 2005 Formats: txt pdf Updated by: RFC 6494, RFC 6495 Status: PROPOSED STANDARD IPv6 nodes use the Neighbor Discovery Protocol (NDP) to discover other nodes on the link, to determine their link-layer addresses to find routers, and to maintain reachability information about the paths to active neighbors. If not secured, NDP is vulnerable to various attacks. This document specifies security mechanisms forNDP. Unlike those in the original NDP specifications, these mechanisms do not use IPsec.
RFC 3972	Cryptographically Generated Addresses (CGA)
	Authors: T. Aura. Date: March 2005 Formats: txt pdf Updated by: RFC 4581, RFC 4982 Status: PROPOSED STANDARD This document describes a method for binding a public signature key to an IPv6 address in the Secure Neighbor Discovery (SEND) protocol.Cryptographically Generated Addresses (CGA) are IPv6 addresses for which the interface identifier is generated by computing a cryptographic one-way hash function from a public key and auxiliary parameters. The binding between the public key and the address can be verified by re-computing the hash value and by comparing the hash with the interface identifier. Messages sent from an IPv6 address can be protected by attaching the public key and auxiliary parameters and by signing the message with the corresponding private key. The protection works without a certification authority or any security infrastructure.
RFC 3977	Network News Transfer Protocol (NNTP)
	Authors: C. Feather. Date: October 2006 Formats: txt pdf Obsoletes: RFC 0977 Updates: RFC 2980 Updated by: RFC 6048 Status: PROPOSED STANDARD The Network News Transfer Protocol (NNTP) has been in use in theInternet for a decade, and remains one of the most popular protocols(by volume) in use today. This document is a replacement forRFC 977, and officially updates the protocol specification. It clarifies some vagueness in RFC 977, includes some new base functionality, and provides a specific mechanism to add standardized extensions to NNTP.
RFC 3980	T11 Network Address Authority (NAA) Naming Format for iSCSI Node Names
	Authors: M. Krueger, M. Chadalapaka, R. Elliott. Date: February 2005 Formats: txt pdf Updates: RFC 3720 Status: PROPOSED STANDARD Internet Small Computer Systems Interface (iSCSI) is a SCSI transport protocol that maps the SCSI family of protocols onto TCP/IP. This document defines an additional iSCSI node name type format to enable use of the "Network Address Authority" (NAA) worldwide naming format defined by the InterNational Committee for Information TechnologyStandards (INCITS) T11 - Fibre Channel (FC) protocols and used bySerial Attached SCSI (SAS). This document updates RFC 3720.
RFC 3981	IRIS: The Internet Registry Information Service (IRIS) Core Protocol
	Authors: A. Newton, M. Sanz. Date: January 2005 Formats: txt pdf Updated by: RFC 4992 Status: PROPOSED STANDARD This document describes an application layer client-server protocol for a framework to represent the query and result operations of the information services of Internet registries. Specified in theExtensible Markup Language (XML), the protocol defines generic query and result operations and a mechanism for extending these operations for specific registry service needs.
RFC 3982	IRIS: A Domain Registry (dreg) Type for the Internet Registry Information Service (IRIS)
	Authors: A. Newton, M. Sanz. Date: January 2005 Formats: txt pdf Status: PROPOSED STANDARD This document describes an Internet Registry Information Service(IRIS) registry schema for registered DNS information. The schema extends the necessary query and result operations of IRIS to provide the functional information service needs for syntaxes and results used by domain registries and registrars.
RFC 3983	Using the Internet Registry Information Service (IRIS) over the Blocks Extensible Exchange Protocol (BEEP)
	Authors: A. Newton, M. Sanz. Date: January 2005 Formats: txt pdf Status: PROPOSED STANDARD This document specifies how to use the Blocks Extensible ExchangeProtocol (BEEP) as the application transport substrate for theInternet Registry Information Service (IRIS).
RFC 3984	RTP Payload Format for H.264 Video
	Authors: S. Wenger, M.M. Hannuksela, T. Stockhammer, M. Westerlund, D. Singer. Date: February 2005 Formats: txt pdf Obsoleted by: RFC 6184 Status: PROPOSED STANDARD This memo describes an RTP Payload format for the ITU-TRecommendation H.264 video codec and the technically identicalISO/IEC International Standard 14496-10 video codec. The RTP payload format allows for packetization of one or more Network AbstractionLayer Units (NALUs), produced by an H.264 video encoder, in each RTP payload. The payload format has wide applicability, as it supports applications from simple low bit-rate conversational usage, toInternet video streaming with interleaved transmission, to high bit- rate video-on-demand.
RFC 3987	Internationalized Resource Identifiers (IRIs)
	Authors: M. Duerst, M. Suignard. Date: January 2005 Formats: txt pdf Status: PROPOSED STANDARD This document defines a new protocol element, the InternationalizedResource Identifier (IRI), as a complement to the Uniform ResourceIdentifier (URI). An IRI is a sequence of characters from theUniversal Character Set (Unicode/ISO 10646). A mapping from IRIs toURIs is defined, which means that IRIs can be used instead of URIs, where appropriate, to identify resources. The approach of defining a new protocol element was chosen instead of extending or changing the definition of URIs. This was done in order to allow a clear distinction and to avoid incompatibilities with existing software. Guidelines are provided for the use and deployment of IRIs in various protocols, formats, and software components that currently deal with URIs.
RFC 3993	Subscriber-ID Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option
	Authors: R. Johnson, T. Palaniappan, M. Stapp. Date: March 2005 Formats: txt pdf Status: PROPOSED STANDARD This memo defines a new Subscriber-ID suboption for the Dynamic HostConfiguration Protocol's (DHCP) relay agent information option. The suboption allows a DHCP relay agent to associate a stable"Subscriber-ID" with DHCP client messages in a way that is independent of the client and of the underlying physical network infrastructure.
RFC 3994	Indication of Message Composition for Instant Messaging
	Authors: H. Schulzrinne. Date: January 2005 Formats: txt pdf Status: PROPOSED STANDARD In instant messaging (IM) systems, it is useful to know during an IM conversation whether the other party is composing a message; e.g., typing or recording an audio message. This document defines a new status message content type and XML namespace that conveys information about a message being composed. The status message can indicate the composition of a message of any type, including text, voice, or video. The status messages are delivered to the instant messaging recipient in the same manner as the instant messages themselves.
RFC 3995	Internet Printing Protocol (IPP): Event Notifications and Subscriptions
	Authors: R. Herriot, T. Hastings. Date: March 2005 Formats: txt pdf Updates: RFC 2911, RFC 2910 Status: PROPOSED STANDARD This document describes an OPTIONAL extension to the InternetPrinting Protocol/1.1: Model and Semantics (RFC 2911, RFC 2910).This extension allows a client to subscribe to printing relatedEvents. Subscriptions are modeled as Subscription Objects. TheSubscription Object specifies that when one of the specified Events occurs, the Printer delivers an asynchronous Event Notification to the specified Notification Recipient via the specified Push or PullDelivery Method (i.e., protocol). A client associates Subscription Objects with a particular Job by performing the Create-Job-Subscriptions operation or by submitting aJob with subscription information. A client associates SubscriptionObjects with the Printer by performing a Create-Printer-Subscriptions operation. Four other operations are defined for SubscriptionObjects: Get-Subscriptions-Attributes, Get-Subscriptions, Renew-Subscription, and Cancel-Subscription.
RFC 3996	Internet Printing Protocol (IPP): The 'ippget' Delivery Method for Event Notifications
	Authors: R. Herriot, T. Hastings, H. Lewis. Date: March 2005 Formats: txt pdf Updates: RFC 2911 Status: PROPOSED STANDARD This document describes an extension to the Internet PrintingProtocol1.1: Model and Semantics (RFC 2911, RFC 2910). This document specifies the 'ippget' Pull Delivery Method for use with the"Internet Printing Protocol (IPP): Event Notifications andSubscriptions" specification (RFC 3995). This IPPGET Delivery Method is REQUIRED for all clients and Printers that support RFC 3995. TheNotification Recipient, acting as a client, fetches (pulls) EventNotifications by using the Get-Notifications operation defined in this document.
RFC 3998	Internet Printing Protocol (IPP): Job and Printer Administrative Operations
	Authors: C. Kugler, H. Lewis, T. Hastings, Ed.. Date: March 2005 Formats: txt pdf Status: PROPOSED STANDARD This document specifies the following 16 additional OPTIONAL system administration operations for use with the Internet PrintingProtocol/1.1 (IPP), plus a few associated attributes, values, and status codes, and using the IPP Printer object to manage printer fan-out and fan-in. Printer operations: Job operations:Enable-Printer and Disable-Printer Reprocess-JobPause-Printer-After-Current-Job Cancel-Current-JobHold-New-Jobs and Release-Held-New-Jobs Suspend-Current-JobDeactivate-Printer and Activate-Printer Resume-JobRestart-Printer Promote-JobShutdown-Printer and Startup-Printer Schedule-Job-After
RFC 4001	Textual Conventions for Internet Network Addresses
	Authors: M. Daniele, B. Haberman, S. Routhier, J. Schoenwaelder. Date: February 2005 Formats: txt pdf Obsoletes: RFC 3291 Status: PROPOSED STANDARD This MIB module defines textual conventions to represent commonly used Internet network layer addressing information. The intent is that these textual conventions will be imported and used in MIB modules that would otherwise define their own representations.
RFC 4002	IANA Registration for Enumservice 'web' and 'ft'
	Authors: R. Brandner, L. Conroy, R. Stastny. Date: February 2005 Formats: txt pdf Updated by: RFC 6118 Status: PROPOSED STANDARD This document registers the Enumservices 'web' and 'ft' by using theURI schemes 'http:', 'https:' and 'ftp:' as per the IANA registration process defined in the ENUM specification (RFC 3761).
RFC 4003	GMPLS Signaling Procedure for Egress Control
	Authors: L. Berger. Date: February 2005 Formats: txt pdf Updates: RFC 3473 Status: PROPOSED STANDARD This document clarifies the procedures for the control of the label used on an output/downstream interface of the egress node of a LabelSwitched Path (LSP). This control is also known as "Egress Control".Support for Egress Control is implicit in Generalized Multi-ProtocolLabel Switching (GMPLS) Signaling. This document clarifies the specification of GMPLS Signaling and does not modify GMPLS signaling mechanisms and procedures.
RFC 4004	Diameter Mobile IPv4 Application
	Authors: P. Calhoun, T. Johansson, C. Perkins, T. Hiller, Ed., P. McCann. Date: August 2005 Formats: txt pdf Status: PROPOSED STANDARD This document specifies a Diameter application that allows a Diameter server to authenticate, authorize and collect accounting information for Mobile IPv4 services rendered to a mobile node. Combined with the Inter-Realm capability of the base protocol, this application allows mobile nodes to receive service from foreign service providers. Diameter Accounting messages will be used by the foreign and home agents to transfer usage information to the Diameter servers.
RFC 4005	Diameter Network Access Server Application
	Authors: P. Calhoun, G. Zorn, D. Spence, D. Mitton. Date: August 2005 Formats: txt pdf Status: PROPOSED STANDARD This document describes the Diameter protocol application used forAuthentication, Authorization, and Accounting (AAA) services in theNetwork Access Server (NAS) environment. When combined with theDiameter Base protocol, Transport Profile, and ExtensibleAuthentication Protocol specifications, this application specification satisfies typical network access services requirements. Initial deployments of the Diameter protocol are expected to include legacy systems. Therefore, this application has been carefully designed to ease the burden of protocol conversion between RADIUS andDiameter. This is achieved by including the RADIUS attribute space to eliminate the need to perform many attribute translations. The interactions between Diameter applications and RADIUS specified in this document are to be applied to all Diameter applications. In this sense, this document extends the Base Diameter protocol.
RFC 4006	Diameter Credit-Control Application
	Authors: H. Hakala, L. Mattila, J-P. Koskinen, M. Stura, J. Loughney. Date: August 2005 Formats: txt pdf Status: PROPOSED STANDARD This document specifies a Diameter application that can be used to implement real-time credit-control for a variety of end user services such as network access, Session Initiation Protocol (SIP) services, messaging services, and download services.
RFC 4007	IPv6 Scoped Address Architecture
	Authors: S. Deering, B. Haberman, T. Jinmei, E. Nordmark, B. Zill. Date: March 2005 Formats: txt pdf Status: PROPOSED STANDARD This document specifies the architectural characteristics, expected behavior, textual representation, and usage of IPv6 addresses of different scopes. According to a decision in the IPv6 working group, this document intentionally avoids the syntax and usage of unicast site-local addresses.
RFC 4008	Definitions of Managed Objects for Network Address Translators (NAT)
	Authors: R. Rohit, P. Srisuresh, R. Raghunarayan, N. Pai, C. Wang. Date: March 2005 Formats: txt pdf Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for devices implementing Network Address Translator (NAT) function.This MIB module may be used for configuration as well as monitoring of a device capable of NAT function.
RFC 4010	Use of the SEED Encryption Algorithm in Cryptographic Message Syntax (CMS)
	Authors: J. Park, S. Lee, J. Kim, J. Lee. Date: February 2005 Formats: txt pdf Status: PROPOSED STANDARD This document specifies the conventions for using the SEED encryption algorithm for encryption with the Cryptographic Message Syntax (CMS). SEED is added to the set of optional symmetric encryption algorithms in CMS by providing two classes of unique object identifiers (OIDs).One OID class defines the content encryption algorithms and the other defines the key encryption algorithms.
RFC 4011	Policy Based Management MIB
	Authors: S. Waldbusser, J. Saperia, T. Hongal. Date: March 2005 Formats: txt pdf Status: PROPOSED STANDARD 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 MIB defines objects that enable policy-based monitoring and management of Simple Network Management Protocol(SNMP) infrastructures, a scripting language, and a script execution environment.
RFC 4012	Routing Policy Specification Language next generation (RPSLng)
	Authors: L. Blunk, J. Damas, F. Parent, A. Robachevsky. Date: March 2005 Formats: txt pdf Updates: RFC 2725, RFC 2622 Status: PROPOSED STANDARD This memo introduces a new set of simple extensions to the RoutingPolicy Specification Language (RPSL), enabling the language to document routing policies for the IPv6 and multicast address families currently used in the Internet.
RFC 4013	SASLprep: Stringprep Profile for User Names and Passwords
	Authors: K. Zeilenga. Date: February 2005 Formats: txt pdf Status: PROPOSED STANDARD This document describes how to prepare Unicode strings representing user names and passwords for comparison. The document defines the"SASLprep" profile of the "stringprep" algorithm to be used for both user names and passwords. This profile is intended to be used bySimple Authentication and Security Layer (SASL) mechanisms (such asPLAIN, CRAM-MD5, and DIGEST-MD5), as well as other protocols exchanging simple user names and/or passwords.
RFC 4014	Remote Authentication Dial-In User Service (RADIUS) Attributes Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Information Option
	Authors: R. Droms, J. Schnizlein. Date: February 2005 Formats: txt pdf Status: PROPOSED STANDARD The RADIUS Attributes suboption enables a network element to pass identification and authorization attributes received during RADIUS authentication to a DHCP server. When the DHCP server receives a message from a relay agent containing a RADIUS Attributes suboption, it extracts the contents of the suboption and uses that information in selecting configuration parameters for the client.
RFC 4015	The Eifel Response Algorithm for TCP
	Authors: R. Ludwig, A. Gurtov. Date: February 2005 Formats: txt pdf Status: PROPOSED STANDARD Based on an appropriate detection algorithm, the Eifel response algorithm provides a way for a TCP sender to respond to a detected spurious timeout. It adapts the retransmission timer to avoid further spurious timeouts and (depending on the detection algorithm) can avoid the often unnecessary go-back-N retransmits that would otherwise be sent. In addition, the Eifel response algorithm restores the congestion control state in such a way that packet bursts are avoided.
RFC 4018	Finding Internet Small Computer Systems Interface (iSCSI) Targets and Name Servers by Using Service Location Protocol version 2 (SLPv2)
	Authors: M. Bakke, J. Hufferd, K. Voruganti, M. Krueger, T. Sperry. Date: April 2005 Formats: txt pdf Status: PROPOSED STANDARD The iSCSI protocol provides a way for hosts to access SCSI devices over an IP network. This document defines the use of the ServiceLocation Protocol (SLP) by iSCSI hosts, devices, and management services, along with the SLP service type templates that describe the services they provide.
RFC 4019	RObust Header Compression (ROHC): Profiles for User Datagram Protocol (UDP) Lite
	Authors: G. Pelletier. Date: April 2005 Formats: txt pdf Updated by: RFC 4815 Status: PROPOSED STANDARD This document defines Robust Header Compression (ROHC) profiles for compression of Real-Time Transport Protocol, User Datagram Protocol-Lite, and Internet Protocol (RTP/UDP-Lite/IP) packets and UDP-Lite/IP. These profiles are defined based on their differences with the profiles for UDP as specified in RFC 3095.
RFC 4021	Registration of Mail and MIME Header Fields
	Authors: G. Klyne, J. Palme. Date: March 2005 Formats: txt pdf Updated by: RFC 5322 Status: PROPOSED STANDARD This document defines the initial IANA registration for permanent mail and MIME message header fields, per RFC 3864.
RFC 4022	Management Information Base for the Transmission Control Protocol (TCP)
	Authors: R. Raghunarayan, Ed.. Date: March 2005 Formats: txt pdf Obsoletes: RFC 2452, RFC 2012 Status: PROPOSED STANDARD 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 implementations of the Transmission Control Protocol (TCP) in an IP version independent manner. This memo obsoletes RFCs 2452 and 2012.
RFC 4023	Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)
	Authors: T. Worster, Y. Rekhter, E. Rosen, Ed.. Date: March 2005 Formats: txt pdf Updated by: RFC 5332 Status: PROPOSED STANDARD Various applications of MPLS make use of label stacks with multiple entries. In some cases, it is possible to replace the top label of the stack with an IP-based encapsulation, thereby enabling the application to run over networks that do not have MPLS enabled in their core routers. This document specifies two IP-based encapsulations: MPLS-in-IP and MPLS-in-GRE (Generic RoutingEncapsulation). Each of these is applicable in some circumstances.
RFC 4025	A Method for Storing IPsec Keying Material in DNS
	Authors: M. Richardson. Date: March 2005 Formats: txt pdf Status: PROPOSED STANDARD This document describes a new resource record for the Domain NameSystem (DNS). This record may be used to store public keys for use in IP security (IPsec) systems. The record also includes provisions for indicating what system should be contacted when an IPsec tunnel is established with the entity in question. This record replaces the functionality of the sub-type #4 of the KEYResource Record, which has been obsoleted by RFC 3445.
RFC 4028	Session Timers in the Session Initiation Protocol (SIP)
	Authors: S. Donovan, J. Rosenberg. Date: April 2005 Formats: txt pdf Status: PROPOSED STANDARD This document defines an extension to the Session Initiation Protocol(SIP). This extension allows for a periodic refresh of SIP sessions through a re-INVITE or UPDATE request. The refresh allows both user agents and proxies to determine whether the SIP session is still active. The extension defines two new header fields:Session-Expires, which conveys the lifetime of the session, andMin-SE, which conveys the minimum allowed value for the session timer.
RFC 4030	The Authentication Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option
	Authors: M. Stapp, T. Lemon. Date: March 2005 Formats: txt pdf Status: PROPOSED STANDARD The Dynamic Host Configuration Protocol (DHCP) Relay AgentInformation Option (RFC 3046) conveys information between a DHCPRelay Agent and a DHCP server. This specification defines an authentication suboption for that option, containing a keyed hash in its payload. The suboption supports data integrity and replay protection for relayed DHCP messages.
RFC 4032	Update to the Session Initiation Protocol (SIP) Preconditions Framework
	Authors: G. Camarillo, P. Kyzivat. Date: March 2005 Formats: txt pdf Updates: RFC 3312 Status: PROPOSED STANDARD This document updates RFC 3312, which defines the framework for preconditions in SIP. We provide guidelines for authors of new precondition types and describe how to use SIP preconditions in situations that involve session mobility.
RFC 4033	DNS Security Introduction and Requirements
	Authors: R. Arends, R. Austein, M. Larson, D. Massey, S. Rose. Date: March 2005 Formats: txt pdf Obsoletes: RFC 2535, RFC 3008, RFC 3090, RFC 3445, RFC 3655, RFC 3658, RFC 3755, RFC 3757, RFC 3845 Updates: RFC 1034, RFC 1035, RFC 2136, RFC 2181, RFC 2308, RFC 3225, RFC 3597, RFC 3226 Updated by: RFC 6014 Status: PROPOSED STANDARD The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions and describes their capabilities and limitations. This document also discusses the services that theDNS security extensions do and do not provide. Last, this document describes the interrelationships between the documents that collectively describe DNSSEC.
RFC 4034	Resource Records for the DNS Security Extensions
	Authors: R. Arends, R. Austein, M. Larson, D. Massey, S. Rose. Date: March 2005 Formats: txt pdf Obsoletes: RFC 2535, RFC 3008, RFC 3090, RFC 3445, RFC 3655, RFC 3658, RFC 3755, RFC 3757, RFC 3845 Updates: RFC 1034, RFC 1035, RFC 2136, RFC 2181, RFC 2308, RFC 3225, RFC 3597, RFC 3226 Updated by: RFC 4470, RFC 6014 Status: PROPOSED STANDARD This document is part of a family of documents that describe the DNSSecurity Extensions (DNSSEC). The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication for the DNS. This document defines the public key (DNSKEY), delegation signer (DS), resource record digital signature (RRSIG), and authenticated denial of existence (NSEC) resource records. The purpose and format of each resource record is described in detail, and an example of each resource record is given. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535.
RFC 4035	Protocol Modifications for the DNS Security Extensions
	Authors: R. Arends, R. Austein, M. Larson, D. Massey, S. Rose. Date: March 2005 Formats: txt pdf Obsoletes: RFC 2535, RFC 3008, RFC 3090, RFC 3445, RFC 3655, RFC 3658, RFC 3755, RFC 3757, RFC 3845 Updates: RFC 1034, RFC 1035, RFC 2136, RFC 2181, RFC 2308, RFC 3225, RFC 3597, RFC 3226 Updated by: RFC 4470, RFC 6014 Status: PROPOSED STANDARD This document is part of a family of documents that describe the DNSSecurity Extensions (DNSSEC). The DNS Security Extensions are a collection of new resource records and protocol modifications that add data origin authentication and data integrity to the DNS. This document describes the DNSSEC protocol modifications. This document defines the concept of a signed zone, along with the requirements for serving and resolving by using DNSSEC. These techniques allow a security-aware resolver to authenticate both DNS resource records and authoritative DNS error indications. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535.
RFC 4036	Management Information Base for Data Over Cable Service Interface Specification (DOCSIS) Cable Modem Termination Systems for Subscriber Management
	Authors: W. Sawyer. Date: April 2005 Formats: txt pdf Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it defines a set of managed objects for Simple NetworkManagement Protocol (SNMP)-based management of Data-over-CableService Interface Specification (DOCSIS)-compliant Cable ModemTermination Systems. These managed objects facilitate protection of the cable network from misuse by subscribers. The DifferentiatedServices MIB (RFC 3289) provides the filtering functions needed here, making use of classification items defined in this specification.
RFC 4037	Open Pluggable Edge Services (OPES) Callout Protocol (OCP) Core
	Authors: A. Rousskov. Date: March 2005 Formats: txt pdf Status: PROPOSED STANDARD This document specifies the core of the Open Pluggable Edge Services(OPES) Callout Protocol (OCP). OCP marshals application messages from other communication protocols: An OPES intermediary sends original application messages to a callout server; the callout server sends adapted application messages back to the processor. OCP is designed with typical adaptation tasks in mind (e.g., virus and spam management, language and format translation, message anonymization, or advertisement manipulation). As defined in this document, the OCPCore consists of application-agnostic mechanisms essential for efficient support of typical adaptations.
RFC 4039	Rapid Commit Option for the Dynamic Host Configuration Protocol version 4 (DHCPv4)
	Authors: S. Park, P. Kim, B. Volz. Date: March 2005 Formats: txt pdf Status: PROPOSED STANDARD This document defines a new Dynamic Host Configuration Protocol version 4 (DHCPv4) option, modeled on the DHCPv6 Rapid Commit option, for obtaining IP address and configuration information using a2-message exchange rather than the usual 4-message exchange, expediting client configuration.
RFC 4040	RTP Payload Format for a 64 kbit/s Transparent Call
	Authors: R. Kreuter. Date: April 2005 Formats: txt pdf Status: PROPOSED STANDARD This document describes how to carry 64 kbit/s channel data transparently in RTP packets, using a pseudo-codec called"Clearmode". It also serves as registration for a related MIME type called "audio/clearmode". "Clearmode" is a basic feature of VoIP Media Gateways.
RFC 4043	Internet X.509 Public Key Infrastructure Permanent Identifier
	Authors: D. Pinkas, T. Gindin. Date: May 2005 Formats: txt pdf Status: PROPOSED STANDARD This document defines a new form of name, called permanent identifier, that may be included in the subjectAltName extension of a public key certificate issued to an entity. The permanent identifier is an optional feature that may be used by aCA to indicate that two or more certificates relate to the same entity, even if they contain different subject name (DNs) or different names in the subjectAltName extension, or if the name or the affiliation of that entity stored in the subject or another name form in the subjectAltName extension has changed. The subject name, carried in the subject field, is only unique for each subject entity certified by the one CA as defined by the issuer name field. However, the new name form can carry a name that is unique for each subject entity certified by a CA.
RFC 4044	Fibre Channel Management MIB
	Authors: K. McCloghrie. Date: May 2005 Formats: txt pdf Obsoletes: RFC 2837 Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes managed objects for information related to the Fibre Channel.
RFC 4051	Additional XML Security Uniform Resource Identifiers (URIs)
	Authors: D. Eastlake 3rd. Date: April 2005 Formats: txt pdf Status: PROPOSED STANDARD A number of Uniform Resource Identifiers (URIs) intended for use withXML Digital Signatures, Encryption, and Canonicalization are defined.These URIs identify algorithms and types of keying information.
RFC 4055	Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
	Authors: J. Schaad, B. Kaliski, R. Housley. Date: June 2005 Formats: txt pdf Updates: RFC 3279 Updated by: RFC 5756 Status: PROPOSED STANDARD This document supplements RFC 3279. It describes the conventions for using the RSA Probabilistic Signature Scheme (RSASSA-PSS) signature algorithm, the RSA Encryption Scheme - Optimal Asymmetric EncryptionPadding (RSAES-OAEP) key transport algorithm and additional one-way hash functions with the Public-Key Cryptography Standards (PKCS) #1 version 1.5 signature algorithm in the Internet X.509 Public KeyInfrastructure (PKI). Encoding formats, algorithm identifiers, and parameter formats are specified.
RFC 4056	Use of the RSASSA-PSS Signature Algorithm in Cryptographic Message Syntax (CMS)
	Authors: J. Schaad. Date: June 2005 Formats: txt pdf Status: PROPOSED STANDARD This document specifies the conventions for using the RSASSA-PSS (RSAProbabilistic Signature Scheme) digital signature algorithm with theCryptographic Message Syntax (CMS).
RFC 4060	RTP Payload Formats for European Telecommunications Standards Institute (ETSI) European Standard ES 202 050, ES 202 211, and ES 202 212 Distributed Speech Recognition Encoding
	Authors: Q. Xie, D. Pearce. Date: May 2005 Formats: txt pdf Status: PROPOSED STANDARD This document specifies RTP payload formats for encapsulatingEuropean Telecommunications Standards Institute (ETSI) EuropeanStandard ES 202 050 DSR Advanced Front-end (AFE), ES 202 211 DSRExtended Front-end (XFE), and ES 202 212 DSR Extended AdvancedFront-end (XAFE) signal processing feature streams for distributed speech recognition (DSR) systems.
RFC 4064	Experimental Message, Extensions, and Error Codes for Mobile IPv4
	Authors: A. Patel, K. Leung. Date: May 2005 Formats: txt pdf Status: PROPOSED STANDARD Mobile IPv4 message types range from 0 to 255. This document reserves a message type for use by an individual, company, or organization for experimental purposes, to evaluate enhancements toMobile IPv4 messages before a formal standards proposal is issued.
RFC 4069	Definitions of Managed Object Extensions for Very High Speed Digital Subscriber Lines (VDSL) Using Single Carrier Modulation (SCM) Line Coding
	Authors: M. Dodge, B. Ray. Date: May 2005 Formats: txt pdf Status: PROPOSED STANDARD This document defines a portion of the Management Information Base(MIB) module for use with network management protocols in theInternet community. In particular, it describes objects used for managing the Line Code Specific parameters of Very High Speed DigitalSubscriber Line (VDSL) interfaces using Single Carrier Modulation(SCM) Line Coding. It is an optional extension to the VDSL-LINE-MIB,RFC 3728, which handles line code independent objects.
RFC 4070	Definitions of Managed Object Extensions for Very High Speed Digital Subscriber Lines (VDSL) Using Multiple Carrier Modulation (MCM) Line Coding
	Authors: M. Dodge, B. Ray. Date: May 2005 Formats: txt pdf Status: PROPOSED STANDARD This document defines a portion of the Management Information Base(MIB) module for use with network management protocols in theInternet community. In particular, it describes objects used for managing the Line Code Specific parameters of Very High Speed DigitalSubscriber Line (VDSL) interfaces using Multiple Carrier Modulation(MCM) Line Coding. It is an optional extension to the VDSL-LINE-MIB,RFC 3728, which handles line code independent objects.
RFC 4072	Diameter Extensible Authentication Protocol (EAP) Application
	Authors: P. Eronen, Ed., T. Hiller, G. Zorn. Date: August 2005 Formats: txt pdf Status: PROPOSED STANDARD The Extensible Authentication Protocol (EAP) provides a standard mechanism for support of various authentication methods. This document defines the Command-Codes and AVPs necessary to carry EAP packets between a Network Access Server (NAS) and a back-end authentication server.
RFC 4073	Protecting Multiple Contents with the Cryptographic Message Syntax (CMS)
	Authors: R. Housley. Date: May 2005 Formats: txt pdf Status: PROPOSED STANDARD This document describes a convention for using the CryptographicMessage Syntax (CMS) to protect a content collection. If desired, attributes can be associated with the content.
RFC 4075	Simple Network Time Protocol (SNTP) Configuration Option for DHCPv6
	Authors: V. Kalusivalingam. Date: May 2005 Formats: txt pdf Status: PROPOSED STANDARD This document describes a new DHCPv6 option for passing a list ofSimple Network Time Protocol (SNTP) server addresses to a client.
RFC 4077	A Negative Acknowledgement Mechanism for Signaling Compression
	Authors: A.B. Roach. Date: May 2005 Formats: txt pdf Status: PROPOSED STANDARD This document describes a mechanism that allows Signaling Compression(SigComp) implementations to report precise error information upon receipt of a message which cannot be decompressed. This negative feedback can be used by the recipient to make fine-grained adjustments to the compressed message before retransmitting it, allowing for rapid and efficient recovery from error situations.
RFC 4087	IP Tunnel MIB
	Authors: D. Thaler. Date: June 2005 Formats: txt pdf Obsoletes: RFC 2667 Status: PROPOSED STANDARD This memo defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing tunnels of any type over IPv4 and IPv6 networks. Extension MIB modules may be designed for managing protocol-specific objects. Likewise, extensionMIB modules may be designed for managing security-specific objects.This MIB module does not support tunnels over non-IP networks.Management of such tunnels may be supported by other MIB modules.This memo obsoletes RFC 2667.
RFC 4088	Uniform Resource Identifier (URI) Scheme for the Simple Network Management Protocol (SNMP)
	Authors: D. Black, K. McCloghrie, J. Schoenwaelder. Date: June 2005 Formats: txt pdf Status: PROPOSED STANDARD The Simple Network Management Protocol (SNMP) and the InternetStandard Management Framework are widely used for the management of communication devices, creating a need to specify SNMP access(including access to SNMP MIB object instances) from non-SNMP management environments. For example, when out-of-band IP management is used via a separate management interface (e.g., for a device that does not support in-band IP access), a uniform way to indicate how to contact the device for management is needed. Uniform ResourceIdentifiers (URIs) fit this need well, as they allow a single text string to indicate a management access communication endpoint for a wide variety of IP-based protocols. This document defines a URI scheme so that SNMP can be designated as the protocol used for management. The scheme also allows a URI to designate one or more MIB object instances.
RFC 4090	Fast Reroute Extensions to RSVP-TE for LSP Tunnels
	Authors: P. Pan, Ed., G. Swallow, Ed., A. Atlas, Ed.. Date: May 2005 Formats: txt pdf Status: PROPOSED STANDARD This document defines RSVP-TE extensions to establish backup label- switched path (LSP) tunnels for local repair of LSP tunnels. These mechanisms enable the re-direction of traffic onto backup LSP tunnels in 10s of milliseconds, in the event of a failure. Two methods are defined here. The one-to-one backup method creates detour LSPs for each protected LSP at each potential point of local repair. The facility backup method creates a bypass tunnel to protect a potential failure point; by taking advantage of MPLS label stacking, this bypass tunnel can protect a set of LSPs that have similar backup constraints. Both methods can be used to protect links and nodes during network failure. The described behavior and extensions to RSVP allow nodes to implement either method or both and to interoperate in a mixed network.
RFC 4091	The Alternative Network Address Types (ANAT) Semantics for the Session Description Protocol (SDP) Grouping Framework
	Authors: G. Camarillo, J. Rosenberg. Date: June 2005 Formats: txt pdf Obsoleted by: RFC 5245 Status: PROPOSED STANDARD This document defines the Alternative Network Address Types (ANAT) semantics for the Session Description Protocol (SDP) grouping framework. The ANAT semantics allow alternative types of network addresses to establish a particular media stream.
RFC 4092	Usage of the Session Description Protocol (SDP) Alternative Network Address Types (ANAT) Semantics in the Session Initiation Protocol (SIP)
	Authors: G. Camarillo, J. Rosenberg. Date: June 2005 Formats: txt pdf Obsoleted by: RFC 5245 Status: PROPOSED STANDARD This document describes how to use the Alternative Network AddressTypes (ANAT) semantics of the Session Description Protocol (SDP) grouping framework in SIP. In particular, we define the sdp-anat SIP option-tag. This SIP option-tag ensures that SDP session descriptions that use ANAT are only handled by SIP entities with ANAT support. To justify the need for such a SIP option-tag, we describe what could possibly happen if an ANAT-unaware SIP entity tried to handle media lines grouped with ANAT.
RFC 4095	Attaching Meaning to Solicitation Class Keywords
	Authors: C. Malamud. Date: May 2005 Formats: txt pdf Status: PROPOSED STANDARD This document proposes a mechanism for finding a URI associated with a solicitation class keyword, which is defined in RFC 3865, the NoSoliciting SMTP Service Extension. Solicitation class keywords are simple labels consisting of a domain name that has been reversed, such as "org.example.adv". These solicitation class keywords are inserted in selected header fields or used in the ESMTP service extension, including a new "No-Solicit:" header, which can contain one or more solicitation class keywords inserted by the sender. This document specifies an application based on the DynamicDelegation Discovery System (DDDS) described in RFC 3401 and related documents. An algorithm is specified to associate a solicitation class keyword with a URI which contains further information about the meaning and usage of that solicitation class keyword. For example, the registrant of the "example.org" domain could use this mechanism to create a URI which contains detailed information about the"org.example.adv" solicitation class keyword.
RFC 4102	Registration of the text/red MIME Sub-Type
	Authors: P. Jones. Date: June 2005 Formats: txt pdf Updated by: RFC 6354 Status: PROPOSED STANDARD This document defines the text/red MIME sub-type. "Red" is short for redundant. The actual RTP packetization for this MIME type is specified in RFC 2198.
RFC 4103	RTP Payload for Text Conversation
	Authors: G. Hellstrom, P. Jones. Date: June 2005 Formats: txt pdf Obsoletes: RFC 2793 Status: PROPOSED STANDARD This memo obsoletes RFC 2793; it describes how to carry real-time text conversation session contents in RTP packets. Text conversation session contents are specified in ITU-T Recommendation T.140. One payload format is described for transmitting text on a separateRTP session dedicated for the transmission of text. This RTP payload description recommends a method to include redundant text from already transmitted packets in order to reduce the risk of text loss caused by packet loss.
RFC 4104	Policy Core Extension Lightweight Directory Access Protocol Schema (PCELS)
	Authors: M. Pana, Ed., A. Reyes, A. Barba, D. Moron, M. Brunner. Date: June 2005 Formats: txt pdf Updates: RFC 3703 Status: PROPOSED STANDARD This document defines a number of changes and extensions to thePolicy Core Lightweight Directory Access Protocol (LDAP) Schema (RFC3703) based on the model extensions defined by the Policy CoreInformation Model (PCIM) Extensions (RFC 3460). These changes and extensions consist of new LDAP object classes and attribute types.Some of the schema items defined in this document re-implement existing concepts in accordance with their new semantics introduced by RFC 3460. The other schema items implement new concepts, not covered by RFC 3703. This document updates RFC 3703.
RFC 4106	The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)
	Authors: J. Viega, D. McGrew. Date: June 2005 Formats: txt pdf Status: PROPOSED STANDARD This memo describes the use of the Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) as an IPsec Encapsulating SecurityPayload (ESP) mechanism to provide confidentiality and data origin authentication. This method can be efficiently implemented in hardware for speeds of 10 gigabits per second and above, and is also well-suited to software implementations.
RFC 4108	Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages
	Authors: R. Housley. Date: August 2005 Formats: txt pdf Status: PROPOSED STANDARD This document describes the use of the Cryptographic Message Syntax(CMS) to protect firmware packages, which provide object code for one or more hardware module components. CMS is specified in RFC 3852. A digital signature is used to protect the firmware package from undetected modification and to provide data origin authentication.Encryption is optionally used to protect the firmware package from disclosure, and compression is optionally used to reduce the size of the protected firmware package. A firmware package loading receipt can optionally be generated to acknowledge the successful loading of a firmware package. Similarly, a firmware package load error report can optionally be generated to convey the failure to load a firmware package.
RFC 4109	Algorithms for Internet Key Exchange version 1 (IKEv1)
	Authors: P. Hoffman. Date: May 2005 Formats: txt pdf Updates: RFC 2409 Status: PROPOSED STANDARD The required and suggested algorithms in the original Internet KeyExchange version 1 (IKEv1) specification do not reflect the current reality of the IPsec market requirements. The original specification allows weak security and suggests algorithms that are thinly implemented. This document updates RFC 2409, the original specification, and is intended for all IKEv1 implementations deployed today.
RFC 4112	Electronic Commerce Modeling Language (ECML) Version 2 Specification
	Authors: D. Eastlake 3rd. Date: June 2005 Formats: txt pdf Updates: RFC 3106 Status: PROPOSED STANDARD Electronic commerce frequently requires a substantial exchange of information in order to complete a purchase or other transaction, especially the first time the parties communicate. A standard set of hierarchically-organized payment-related information field names in an XML syntax is defined so that this task can be more easily automated. This is the second version of an Electronic CommerceModeling Language (ECML) and is intended to meet the requirements ofRFC 3505.
RFC 4113	Management Information Base for the User Datagram Protocol (UDP)
	Authors: B. Fenner, J. Flick. Date: June 2005 Formats: txt pdf Obsoletes: RFC 2454, RFC 2013 Status: PROPOSED STANDARD 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 implementations of the User Datagram Protocol (UDP) in an IP version independent manner. This memo obsoletes RFCs 2013 and 2454.
RFC 4114	E.164 Number Mapping for the Extensible Provisioning Protocol (EPP)
	Authors: S. Hollenbeck. Date: June 2005 Formats: txt pdf Status: PROPOSED STANDARD This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of E.164 numbers that represent domain names stored in a shared central repository. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of E.164 numbers.
RFC 4119	A Presence-based GEOPRIV Location Object Format
	Authors: J. Peterson. Date: December 2005 Formats: txt pdf Updated by: RFC 5139, RFC 5491 Status: PROPOSED STANDARD This document describes an object format for carrying geographical information on the Internet. This location object extends thePresence Information Data Format (PIDF), which was designed for communicating privacy-sensitive presence information and which has similar properties.
RFC 4120	The Kerberos Network Authentication Service (V5)
	Authors: C. Neuman, T. Yu, S. Hartman, K. Raeburn. Date: July 2005 Formats: txt pdf Obsoletes: RFC 1510 Updated by: RFC 4537, RFC 5021, RFC 5896, RFC 6111, RFC 6112, RFC 6113 Status: PROPOSED STANDARD This document provides an overview and specification of Version 5 of the Kerberos protocol, and it obsoletes RFC 1510 to clarify aspects of the protocol and its intended use that require more detailed or clearer explanation than was provided in RFC 1510. This document is intended to provide a detailed description of the protocol, suitable for implementation, together with descriptions of the appropriate use of protocol messages and fields within those messages.
RFC 4121	The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2
	Authors: L. Zhu, K. Jaganathan, S. Hartman. Date: July 2005 Formats: txt pdf Updates: RFC 1964 Updated by: RFC 6112, RFC 6542 Status: PROPOSED STANDARD This document defines protocols, procedures, and conventions to be employed by peers implementing the Generic Security ServiceApplication Program Interface (GSS-API) when using the KerberosVersion 5 mechanism. RFC 1964 is updated and incremental changes are proposed in response to recent developments such as the introduction of Kerberos cryptosystem framework. These changes support the inclusion of new cryptosystems, by defining new per-message tokens along with their encryption and checksum algorithms based on the cryptosystem profiles.
RFC 4122	A Universally Unique IDentifier (UUID) URN Namespace
	Authors: P. Leach, M. Mealling, R. Salz. Date: July 2005 Formats: txt pdf Status: PROPOSED STANDARD This specification defines a Uniform Resource Name namespace forUUIDs (Universally Unique IDentifier), also known as GUIDs (GloballyUnique IDentifier). A UUID is 128 bits long, and can guarantee uniqueness across space and time. UUIDs were originally used in theApollo Network Computing System and later in the Open SoftwareFoundation's (OSF) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms. This specification is derived from the DCE specification with the kind permission of the OSF (now known as The Open Group).Information from earlier versions of the DCE specification have been incorporated into this document.
RFC 4124	Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering
	Authors: F. Le Faucheur, Ed.. Date: June 2005 Formats: txt pdf Status: PROPOSED STANDARD This document specifies the protocol extensions for support ofDiffserv-aware MPLS Traffic Engineering (DS-TE). This includes generalization of the semantics of a number of Interior GatewayProtocol (IGP) extensions already defined for existing MPLS TrafficEngineering in RFC 3630, RFC 3784, and additional IGP extensions beyond those. This also includes extensions to RSVP-TE signaling beyond those already specified in RFC 3209 for existing MPLS TrafficEngineering. These extensions address the requirements for DS-TE spelled out in RFC 3564.
RFC 4129	Digital Private Network Signaling System (DPNSS)/Digital Access Signaling System 2 (DASS 2) Extensions to the IUA Protocol
	Authors: R. Mukundan, K. Morneault, N. Mangalpally. Date: September 2005 Formats: txt pdf Status: PROPOSED STANDARD This document defines a mechanism for backhauling Digital PrivateNetwork Signaling System 1 (DPNSS 1) and Digital Access SignalingSystem 2 (DASS 2) messages over IP by extending the ISDN UserAdaptation (IUA) Layer Protocol defined in RFC 3057. DPNSS 1, specified in ND1301:2001/03 (formerly BTNR 188), is used to interconnect Private Branch Exchanges (PBX) in a private network.DASS 2, specified in BTNR 190, is used to connect PBXs to the PSTN.This document aims to become an Appendix to IUA and to be the base for a DPNSS 1/DASS 2 User Adaptation (DUA) implementation.
RFC 4130	MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2)
	Authors: D. Moberg, R. Drummond. Date: July 2005 Formats: txt pdf Status: PROPOSED STANDARD This document provides an applicability statement (RFC 2026, Section3.2) that describes how to exchange structured business data securely using the HTTP transfer protocol, instead of SMTP; the applicability statement for SMTP is found in RFC 3335. Structured business data may be XML; Electronic Data Interchange (EDI) in either the AmericanNational Standards Committee (ANSI) X12 format or the UN ElectronicData Interchange for Administration, Commerce, and Transport(UN/EDIFACT) format; or other structured data formats. The data is packaged using standard MIME structures. Authentication and data confidentiality are obtained by using Cryptographic Message Syntax with S/MIME security body parts. Authenticated acknowledgements make use of multipart/signed Message Disposition Notification (MDN) responses to the original HTTP message. This applicability statement is informally referred to as "AS2" because it is the second applicability statement, produced after "AS1", RFC 3335.
RFC 4131	Management Information Base for Data Over Cable Service Interface Specification (DOCSIS) Cable Modems and Cable Modem Termination Systems for Baseline Privacy Plus
	Authors: S. Green, K. Ozawa, E. Cardona, Ed., A. Katsnelson. Date: September 2005 Formats: txt pdf Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it defines a set of managed objects for Simple NetworkManagement Protocol (SNMP) based management of the Baseline PrivacyPlus features of DOCSIS 1.1 and DOCSIS 2.0 (Data-over-Cable ServiceInterface Specification) compliant Cable Modems and Cable ModemTermination Systems.
RFC 4132	Addition of Camellia Cipher Suites to Transport Layer Security (TLS)
	Authors: S. Moriai, A. Kato, M. Kanda. Date: July 2005 Formats: txt pdf Obsoleted by: RFC 5932 Status: PROPOSED STANDARD This document proposes the addition of new cipher suites to theTransport Layer Security (TLS) protocol to support the Camellia encryption algorithm as a bulk cipher algorithm.
RFC 4133	Entity MIB (Version 3)
	Authors: A. Bierman, K. McCloghrie. Date: August 2005 Formats: txt pdf Obsoletes: RFC 2737 Status: PROPOSED STANDARD 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 multiple logical and physical entities managed by a single SNMP agent. This document specifies version 3 of the Entity MIB, which obsoletes version 2 (RFC 2737).
RFC 4141	SMTP and MIME Extensions for Content Conversion
	Authors: K. Toyoda, D. Crocker. Date: November 2005 Formats: txt pdf Status: PROPOSED STANDARD A message originator sometimes sends content in a form the recipient cannot process or would prefer not to process a form of lower quality than is preferred. Such content needs to be converted to an acceptable form, with the same information or constrained information(e.g., changing from color to black and white). In a store-and- forward environment, it may be convenient to have this conversion performed by an intermediary. This specification integrates twoESMTP extensions and three MIME content header fields, which defines a cooperative service that permits authorized, accountable content form conversion by intermediaries.
RFC 4142	Full-mode Fax Profile for Internet Mail (FFPIM)
	Authors: D. Crocker, G. Klyne. Date: November 2005 Formats: txt pdf Status: PROPOSED STANDARD Classic facsimile document exchange represents both a set of technical specifications and a class of service. Previous work has replicated some of that service class as a profile within Internet mail. The current specification defines "full mode" carriage of facsimile data over the Internet, building upon that previous work and adding the remaining functionality necessary for achieving reliability and capability negotiation for Internet mail, on a par with classic T.30 facsimile. These additional features are designed to provide the highest level of interoperability with the standards-compliant email infrastructure and mail user agents, while providing a level of service that approximates what is currently enjoyed by fax users.
RFC 4143	Facsimile Using Internet Mail (IFAX) Service of ENUM
	Authors: K. Toyoda, D. Crocker. Date: November 2005 Formats: txt pdf Updated by: RFC 6118 Status: PROPOSED STANDARD This document describes the functional specification and definition of the ENUM Naming Authority Pointer (NAPTR) record for IFax service.IFax is "facsimile using Internet mail". For this use, the DomainName System (DNS) returns the email address of the referenced IFax system. This mechanism allows email-based fax communication to use telephone numbers instead of requiring the sender to already know the recipient email address.
RFC 4145	TCP-Based Media Transport in the Session Description Protocol (SDP)
	Authors: D. Yon, G. Camarillo. Date: September 2005 Formats: txt pdf Updated by: RFC 4572 Status: PROPOSED STANDARD This document describes how to express media transport over TCP using the Session Description Protocol (SDP). It defines the SDP 'TCP' protocol identifier, the SDP 'setup' attribute, which describes the connection setup procedure, and the SDP 'connection' attribute, which handles connection reestablishment.
RFC 4149	Definition of Managed Objects for Synthetic Sources for Performance Monitoring Algorithms
	Authors: C. Kalbfleisch, R. Cole, D. Romascanu. Date: August 2005 Formats: txt pdf Status: PROPOSED STANDARD 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 Synthetic Sources for Performance Monitoring (SSPM) algorithms.
RFC 4150	Transport Performance Metrics MIB
	Authors: R. Dietz, R. Cole. Date: August 2005 Formats: txt pdf Status: PROPOSED STANDARD 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 monitoring selectable performance metrics and statistics derived from the monitoring of network packets and sub-application level transactions.The metrics can be defined through reference to existing IETF, ITU, and other standards organizations' documents. The monitoring covers both passive and active traffic generation sources.
RFC 4162	Addition of SEED Cipher Suites to Transport Layer Security (TLS)
	Authors: H.J. Lee, J.H. Yoon, J.I. Lee. Date: August 2005 Formats: txt pdf Status: PROPOSED STANDARD This document proposes the addition of new cipher suites to theTransport Layer Security (TLS) protocol to support the SEED encryption algorithm as a bulk cipher algorithm.
RFC 4164	RObust Header Compression (ROHC): Context Replication for ROHC Profiles
	Authors: G. Pelletier. Date: August 2005 Formats: txt pdf Status: PROPOSED STANDARD This document defines context replication, a complement to the context initialization procedure found in Robust Header Compression(ROHC), as specified in RFC 3095. Profiles defining support for context replication may use the mechanism described herein to establish a new context based on another already existing context.Context replication is introduced to reduce the overhead of the context establishment procedure. It may be especially useful for the compression of multiple short-lived flows that may be occurring simultaneously or near-simultaneously, such as short-lived TCP flows.
RFC 4165	Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) - User Peer-to-Peer Adaptation Layer (M2PA)
	Authors: T. George, B. Bidulock, R. Dantu, H. Schwarzbauer, K. Morneault. Date: September 2005 Formats: txt pdf Status: PROPOSED STANDARD This document defines a protocol supporting the transport ofSignaling System Number 7 (SS7) Message Transfer Part (MTP) Level 3 signaling messages over Internet Protocol (IP) using the services of the Stream Control Transmission Protocol (SCTP). This protocol would be used between SS7 Signaling Points using the MTP Level 3 protocol.The SS7 Signaling Points may also use standard SS7 links using theSS7 MTP Level 2 to provide transport of MTP Level 3 signaling messages. The protocol operates in a manner similar to MTP Level 2 so as to provide peer-to-peer communication between SS7 endpoints.
RFC 4168	The Stream Control Transmission Protocol (SCTP) as a Transport for the Session Initiation Protocol (SIP)
	Authors: J. Rosenberg, H. Schulzrinne, G. Camarillo. Date: October 2005 Formats: txt pdf Status: PROPOSED STANDARD This document specifies a mechanism for usage of SCTP (the StreamControl Transmission Protocol) as the transport mechanism between SIP(Session Initiation Protocol) entities. SCTP is a new protocol that provides several features that may prove beneficial for transport between SIP entities that exchange a large amount of messages, including gateways and proxies. As SIP is transport-independent, support of SCTP is a relatively straightforward process, nearly identical to support for TCP.
RFC 4171	Internet Storage Name Service (iSNS)
	Authors: J. Tseng, K. Gibbons, F. Travostino, C. Du Laney, J. Souza. Date: September 2005 Formats: txt pdf Status: PROPOSED STANDARD This document specifies the Internet Storage Name Service (iSNS) protocol, used for interaction between iSNS servers and iSNS clients, which facilitates automated discovery, management, and configuration of iSCSI and Fibre Channel devices (using iFCP gateways) on a TCP/IP network. iSNS provides intelligent storage discovery and management services comparable to those found in Fibre Channel networks, allowing a commodity IP network to function in a capacity similar to that of a storage area network. iSNS facilitates a seamless integration of IP and Fibre Channel networks due to its ability to emulate Fibre Channel fabric services and to manage both iSCSI andFibre Channel devices. iSNS thereby provides value in any storage network comprised of iSCSI devices, Fibre Channel devices (using iFCP gateways), or any combination thereof.
RFC 4172	iFCP - A Protocol for Internet Fibre Channel Storage Networking
	Authors: C. Monia, R. Mullendore, F. Travostino, W. Jeong, M. Edwards. Date: September 2005 Formats: txt pdf Updated by: RFC 6172 Status: PROPOSED STANDARD This document specifies an architecture and a gateway-to-gateway protocol for the implementation of fibre channel fabric functionality over an IP network. This functionality is provided through TCP protocols for fibre channel frame transport and the distributed fabric services specified by the fibre channel standards. The architecture enables internetworking of fibre channel devices through gateway-accessed regions with the fault isolation properties of autonomous systems and the scalability of the IP network.
RFC 4173	Bootstrapping Clients using the Internet Small Computer System Interface (iSCSI) Protocol
	Authors: P. Sarkar, D. Missimer, C. Sapuntzakis. Date: September 2005 Formats: txt pdf Status: PROPOSED STANDARD Internet Small Computer System Interface (iSCSI) is a proposed transport protocol for Small Computer Systems Interface (SCSI) that operates on top of TCP. This memo describes a standard mechanism for enabling clients to bootstrap themselves using the iSCSI protocol.The goal of this standard is to enable iSCSI boot clients to obtain the information to open an iSCSI session with the iSCSI boot server.
RFC 4174	The IPv4 Dynamic Host Configuration Protocol (DHCP) Option for the Internet Storage Name Service
	Authors: C. Monia, J. Tseng, K. Gibbons. Date: September 2005 Formats: txt pdf Status: PROPOSED STANDARD This document describes the Dynamic Host Configuration Protocol(DHCP) option to allow Internet Storage Name Service (iSNS) clients to discover the location of the iSNS server automatically through the use of DHCP for IPv4. iSNS provides discovery and management capabilities for Internet SCSI (iSCSI) and Internet Fibre ChannelProtocol (iFCP) storage devices in an enterprise-scale IP storage network. iSNS provides intelligent storage management services comparable to those found in Fibre Channel networks, allowing a commodity IP network to function in a similar capacity to that of a storage area network.
RFC 4175	RTP Payload Format for Uncompressed Video
	Authors: L. Gharai, C. Perkins. Date: September 2005 Formats: txt pdf Updated by: RFC 4421 Status: PROPOSED STANDARD This memo specifies a packetization scheme for encapsulating uncompressed video into a payload format for the Real-time TransportProtocol, RTP. It supports a range of standard- and high-definition video formats, including common television formats such as ITUBT.601, and standards from the Society of Motion Picture andTelevision Engineers (SMPTE), such as SMPTE 274M and SMPTE 296M. The format is designed to be applicable and extensible to new video formats as they are developed.
RFC 4178	The Simple and Protected Generic Security Service Application Program Interface (GSS-API) Negotiation Mechanism
	Authors: L. Zhu, P. Leach, K. Jaganathan, W. Ingersoll. Date: October 2005 Formats: txt pdf Obsoletes: RFC 2478 Status: PROPOSED STANDARD This document specifies a negotiation mechanism for the GenericSecurity Service Application Program Interface (GSS-API), which is described in RFC 2743. GSS-API peers can use this negotiation mechanism to choose from a common set of security mechanisms. If per-message integrity services are available on the established mechanism context, then the negotiation is protected against an attacker that forces the selection of a mechanism not desired by the peers. This mechanism replaces RFC 2478 in order to fix defects in that specification and to describe how to inter-operate with implementations of that specification that are commonly deployed on the Internet.
RFC 4182	Removing a Restriction on the use of MPLS Explicit NULL
	Authors: E. Rosen. Date: September 2005 Formats: txt pdf Updates: RFC 3032 Updated by: RFC 5462 Status: PROPOSED STANDARD The label stack encoding for Multi-protocol Label Switching (MPLS) defines a reserved label value known as "IPv4 Explicit NULL" and a reserved label value known as "IPv6 Explicit NULL". Previously, these labels were only legal when they occurred at the bottom of theMPLS label stack. This restriction is now removed, so that these label values may legally occur anywhere in the stack. This document updates RFC 3032.
RFC 4184	RTP Payload Format for AC-3 Audio
	Authors: B. Link, T. Hager, J. Flaks. Date: October 2005 Formats: txt pdf Status: PROPOSED STANDARD This document describes an RTP payload format for transporting audio data using the AC-3 audio compression standard. AC-3 is a high quality, multichannel audio coding system that is used for UnitedStates HDTV, DVD, cable television, satellite television and other media. The RTP payload format presented in this document includes support for data fragmentation.
RFC 4188	Definitions of Managed Objects for Bridges
	Authors: K. Norseth, Ed., E. Bell, Ed.. Date: September 2005 Formats: txt pdf Obsoletes: RFC 1493 Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it defines objects for managing MAC bridges based on the IEEE 802.1D-1998 standard between Local Area Network (LAN) segments. Provisions are made for the support of transparent bridging. Provisions are also made so that these objects apply to bridges connected by subnetworks other than LAN segments. The MIB module presented in this memo is a translation of theBRIDGE-MIB defined in RFC 1493 to the SMIv2 syntax. This memo obsoletes RFC 1493.
RFC 4191	Default Router Preferences and More-Specific Routes
	Authors: R. Draves, D. Thaler. Date: November 2005 Formats: txt pdf Status: PROPOSED STANDARD This document describes an optional extension to Router Advertisement messages for communicating default router preferences and more- specific routes from routers to hosts. This improves the ability of hosts to pick an appropriate router, especially when the host is multi-homed and the routers are on different links. The preference values and specific routes advertised to hosts require administrative configuration; they are not automatically derived from routing tables.
RFC 4193	Unique Local IPv6 Unicast Addresses
	Authors: R. Hinden, B. Haberman. Date: October 2005 Formats: txt pdf Status: PROPOSED STANDARD This document defines an IPv6 unicast address format that is globally unique and is intended for local communications, usually inside of a site. These addresses are not expected to be routable on the globalInternet.
RFC 4194	The S Hexdump Format
	Authors: J. Strombergson, L. Walleij, P. Faltstrom. Date: October 2005 Formats: txt pdf Status: PROPOSED STANDARD This document specifies the S Hexdump Format (SHF), a new, XML-based open format for describing binary data in hexadecimal notation. SHF provides the ability to describe both small and large, simple and complex hexadecimal data dumps in an open, modern, transport- and vendor-neutral format.
RFC 4196	The SEED Cipher Algorithm and Its Use with IPsec
	Authors: H.J. Lee, J.H. Yoon, S.L. Lee, J.I. Lee. Date: October 2005 Formats: txt pdf Status: PROPOSED STANDARD This document describes the use of the SEED block cipher algorithm in the Cipher Block Chaining Mode, with an explicit IV, as a confidentiality mechanism within the context of the IPsecEncapsulating Security Payload (ESP).
RFC 4201	Link Bundling in MPLS Traffic Engineering (TE)
	Authors: K. Kompella, Y. Rekhter, L. Berger. Date: October 2005 Formats: txt pdf Updates: RFC 3471, RFC 3472, RFC 3473 Status: PROPOSED STANDARD For the purpose of Generalized Multi-Protocol Label Switching (GMPLS) signaling, in certain cases a combination of <link identifier, label&rt; is not sufficient to unambiguously identify the appropriate resource used by a Label Switched Path (LSP). Such cases are handled by using the link bundling construct, which is described in this document.This document updates the interface identification TLVs, which are defined in the GMPLS Signaling Functional Description.
RFC 4202	Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)
	Authors: K. Kompella, Ed., Y. Rekhter, Ed.. Date: October 2005 Formats: txt pdf Updated by: RFC 6001, RFC 6002 Status: PROPOSED STANDARD This document specifies routing extensions in support of carrying link state information for Generalized Multi-Protocol Label Switching(GMPLS). This document enhances the routing extensions required to support MPLS Traffic Engineering (TE).
RFC 4203	OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)
	Authors: K. Kompella, Ed., Y. Rekhter, Ed.. Date: October 2005 Formats: txt pdf Updates: RFC 3630 Updated by: RFC 6001, RFC 6002 Status: PROPOSED STANDARD This document specifies encoding of extensions to the OSPF routing protocol in support of Generalized Multi-Protocol Label Switching(GMPLS).
RFC 4204	Link Management Protocol (LMP)
	Authors: J. Lang, Ed.. Date: October 2005 Formats: txt pdf Status: PROPOSED STANDARD For scalability purposes, multiple data links can be combined to form a single traffic engineering (TE) link. Furthermore, the management of TE links is not restricted to in-band messaging, but instead can be done using out-of-band techniques. This document specifies a link management protocol (LMP) that runs between a pair of nodes and is used to manage TE links. Specifically, LMP will be used to maintain control channel connectivity, verify the physical connectivity of the data links, correlate the link property information, suppress downstream alarms, and localize link failures for protection/restoration purposes in multiple kinds of networks.
RFC 4206	Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)
	Authors: K. Kompella, Y. Rekhter. Date: October 2005 Formats: txt pdf Updated by: RFC 6001, RFC 6107 Status: PROPOSED STANDARD To improve scalability of Generalized Multi-Protocol Label Switching(GMPLS) it may be useful to aggregate Label Switched Paths (LSPs) by creating a hierarchy of such LSPs. A way to create such a hierarchy is by (a) a Label Switching Router (LSR) creating a TrafficEngineering Label Switched Path (TE LSP), (b) the LSR forming a forwarding adjacency (FA) out of that LSP (by advertising this LSP as a Traffic Engineering (TE) link into the same instance of ISIS/OSPF as the one that was used to create the LSP), (c) allowing other LSRs to use FAs for their path computation, and (d) nesting of LSPs originated by other LSRs into that LSP (by using the label stack construct). This document describes the mechanisms to accomplish this.
RFC 4207	Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) Encoding for Link Management Protocol (LMP) Test Messages
	Authors: J. Lang, D. Papadimitriou. Date: October 2005 Formats: txt pdf Status: PROPOSED STANDARD This document details the Synchronous Optical Network(SONET)/Synchronous Digital Hierarchy (SDH) technology-specific information needed when sending Link Management Protocol (LMP) test messages.
RFC 4208	Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model
	Authors: G. Swallow, J. Drake, H. Ishimatsu, Y. Rekhter. Date: October 2005 Formats: txt pdf Status: PROPOSED STANDARD Generalized Multiprotocol Label Switching (GMPLS) defines both routing and signaling protocols for the creation of Label SwitchedPaths (LSPs) in various switching technologies. These protocols can be used to support a number of deployment scenarios. This memo addresses the application of GMPLS to the overlay model.
RFC 4209	Link Management Protocol (LMP) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems
	Authors: A. Fredette, Ed., J. Lang, Ed.. Date: October 2005 Formats: txt pdf Status: PROPOSED STANDARD The Link Management Protocol (LMP) is defined to manage traffic engineering (TE) links. In its present form, LMP focuses on peer nodes, i.e., nodes that peer in signaling and/or routing. This document proposes extensions to LMP to allow it to be used between a peer node and an adjacent optical line system (OLS). These extensions are intended to satisfy the "Optical Link InterfaceRequirements" described in a companion document.
RFC 4210	Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)
	Authors: C. Adams, S. Farrell, T. Kause, T. Mononen. Date: September 2005 Formats: txt pdf Obsoletes: RFC 2510 Status: PROPOSED STANDARD This document describes the Internet X.509 Public Key Infrastructure(PKI) Certificate Management Protocol (CMP). Protocol messages are defined for X.509v3 certificate creation and management. CMP provides on-line interactions between PKI components, including an exchange between a Certification Authority (CA) and a client system.
RFC 4211	Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)
	Authors: J. Schaad. Date: September 2005 Formats: txt pdf Obsoletes: RFC 2511 Status: PROPOSED STANDARD This document describes the Certificate Request Message Format (CRMF) syntax and semantics. This syntax is used to convey a request for a certificate to a Certification Authority (CA), possibly via aRegistration Authority (RA), for the purposes of X.509 certificate production. The request will typically include a public key and the associated registration information. This document does not define a certificate request protocol.
RFC 4213	Basic Transition Mechanisms for IPv6 Hosts and Routers
	Authors: E. Nordmark, R. Gilligan. Date: October 2005 Formats: txt pdf Obsoletes: RFC 2893 Status: PROPOSED STANDARD This document specifies IPv4 compatibility mechanisms that can be implemented by IPv6 hosts and routers. Two mechanisms are specified, dual stack and configured tunneling. Dual stack implies providing complete implementations of both versions of the Internet Protocol(IPv4 and IPv6), and configured tunneling provides a means to carryIPv6 packets over unmodified IPv4 routing infrastructures. This document obsoletes RFC 2893.
RFC 4217	Securing FTP with TLS
	Authors: P. Ford-Hutchinson. Date: October 2005 Formats: txt pdf Status: PROPOSED STANDARD This document describes a mechanism that can be used by FTP clients and servers to implement security and authentication using the TLS protocol defined by RFC 2246, "The TLS Protocol Version 1.0.", and the extensions to the FTP protocol defined by RFC 2228, "FTP SecurityExtensions". It describes the subset of the extensions that are required and the parameters to be used, discusses some of the policy issues that clients and servers will need to take, considers some of the implications of those policies, and discusses some expected behaviours of implementations to allow interoperation. This document is intended to provide TLS support for FTP in a similar way to that provided for SMTP in RFC 2487, "SMTP Service Extension for SecureSMTP over Transport Layer Security", and HTTP in RFC 2817, "Upgrading to TLS Within HTTP/1.1.". This specification is in accordance with RFC 959, "File TransferProtocol". It relies on RFC 2246, "The TLS Protocol Version 1.0.", and RFC 2228, "FTP Security Extensions".
RFC 4220	Traffic Engineering Link Management Information Base
	Authors: M. Dubuc, T. Nadeau, J. Lang. Date: November 2005 Formats: txt pdf Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes managed objects for modeling TE links as described in the Link Bundling in MPLS Traffic Engineering (TE) document.
RFC 4227	Using the Simple Object Access Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP)
	Authors: E. O'Tuathail, M. Rose. Date: January 2006 Formats: txt pdf Obsoletes: RFC 3288 Status: PROPOSED STANDARD This memo specifies a Simple Object Access Protocol (SOAP) binding to the Blocks Extensible Exchange Protocol (BEEP) core. A SOAP binding describes how SOAP messages are transmitted in the network. The SOAP is an XML-based (eXtensible Markup Language) messaging protocol used to implement a wide variety of distributed messaging models. It defines a message format and describes a variety of message patterns, including, but not limited to, Remote ProcedureCalling (RPC), asynchronous event notification, unacknowledged messages, and forwarding via SOAP intermediaries.
RFC 4231	Identifiers and Test Vectors for HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512
	Authors: M. Nystrom. Date: December 2005 Formats: txt pdf Status: PROPOSED STANDARD This document provides test vectors for the HMAC-SHA-224,HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 message authentication schemes. It also provides ASN.1 object identifiers and UniformResource Identifiers (URIs) to identify use of these schemes in protocols. The test vectors provided in this document may be used for conformance testing.
RFC 4233	Integrated Services Digital Network (ISDN) Q.921-User Adaptation Layer
	Authors: K. Morneault, S. Rengasami, M. Kalla, G. Sidebottom. Date: January 2006 Formats: txt pdf Obsoletes: RFC 3057 Updated by: RFC 5133 Status: PROPOSED STANDARD This document defines a protocol for backhauling of IntegratedServices Digital Network (ISDN) Q.921 User messages over IP using theStream Control Transmission Protocol (SCTP). This protocol would be used between a Signaling Gateway (SG) and Media Gateway Controller(MGC). It is assumed that the SG receives ISDN signaling over a standard ISDN interface. This document obsoletes RFC 3057.
RFC 4235	An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP)
	Authors: J. Rosenberg, H. Schulzrinne, R. Mahy, Ed.. Date: November 2005 Formats: txt pdf Status: PROPOSED STANDARD This document defines a dialog event package for the SIP Events architecture, along with a data format used in notifications for this package. The dialog package allows users to subscribe to another user and to receive notification of the changes in state of INVITE- initiated dialog usages in which the subscribed-to user is involved.
RFC 4236	HTTP Adaptation with Open Pluggable Edge Services (OPES)
	Authors: A. Rousskov, M. Stecher. Date: November 2005 Formats: txt pdf Status: PROPOSED STANDARD Open Pluggable Edge Services (OPES) framework documents several application-agnostic mechanisms such as OPES tracing, OPES bypass, and OPES callout protocol. This document extends those generic mechanisms for Hypertext Transfer Protocol (HTTP) adaptation.Together, application-agnostic OPES documents and this HTTP profile constitute a complete specification for HTTP adaptation with OPES.
RFC 4237	Voice Messaging Directory Service
	Authors: G. Vaudreuil. Date: October 2005 Formats: txt pdf Status: PROPOSED STANDARD This document provides details of the Voice Profile for Internet Mail(VPIM) directory service. The service provides the email address of the recipient that is given a telephone number. It optionally provides the spoken name of the recipient and the media capabilities of the recipient. The VPIM directory Schema provides essential additional attributes to recreate the voice mail user experience using standardized directories. This user experience provides, at the time of addressing, basic assurances that the message will be delivered as intended. This document combines two earlier documents, one fromAnne Brown and one from Greg Vaudreuil, that define a voice messaging schema into a single working group submission.
RFC 4238	Voice Message Routing Service
	Authors: G. Vaudreuil. Date: October 2005 Formats: txt pdf Updated by: RFC 6118 Status: PROPOSED STANDARD Voice messaging is traditionally addressed using telephone number addressing. This document describes two techniques for routing voice messages based on a telephone number. The complete service uses theVoice Profile for Internet Mail (VPIM) Directory service to lookup aVPIM email address with a telephone number and confirm that the address is both valid and associated with the intended recipient.However, this service will take time to become widely deployed in the near term. This document also describes a basic send-and-pray service that routes and delivers messages using only the ENUM telephone number resolution service and the existing DNS mail routing facilities.
RFC 4239	Internet Voice Messaging (IVM)
	Authors: S. McRae, G. Parsons. Date: November 2005 Formats: txt pdf Status: PROPOSED STANDARD This document describes the carriage of voicemail messages overInternet mail as part of a unified messaging infrastructure. The Internet Voice Messaging (IVM) concept described in this document is not a successor format to VPIM v2 (Voice Profile for Internet MailVersion 2), but rather an alternative specification for a different application.
RFC 4242	Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
	Authors: S. Venaas, T. Chown, B. Volz. Date: November 2005 Formats: txt pdf Status: PROPOSED STANDARD This document describes a Dynamic Host Configuration Protocol forIPv6 (DHCPv6) option for specifying an upper bound for how long a client should wait before refreshing information retrieved fromDHCPv6. It is used with stateless DHCPv6 as there are no addresses or other entities with lifetimes that can tell the client when to contact the DHCPv6 server to refresh its configuration.
RFC 4243	Vendor-Specific Information Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option
	Authors: M. Stapp, R. Johnson, T. Palaniappan. Date: December 2005 Formats: txt pdf Status: PROPOSED STANDARD This memo defines a new Vendor-Specific Information suboption for theDynamic Host Configuration Protocol's (DHCP) relay agent information option. The suboption allows a DHCP relay agent to include vendor- specific information in the DHCP messages it forwards, as configured by its administrator.
RFC 4244	An Extension to the Session Initiation Protocol (SIP) for Request History Information
	Authors: M. Barnes, Ed.. Date: November 2005 Formats: txt pdf Status: PROPOSED STANDARD This document defines a standard mechanism for capturing the history information associated with a Session Initiation Protocol (SIP) request. This capability enables many enhanced services by providing the information as to how and why a call arrives at a specific application or user. This document defines a new optional SIP header, History-Info, for capturing the history information in requests.
RFC 4248	The telnet URI Scheme
	Authors: P. Hoffman. Date: October 2005 Formats: txt pdf Obsoletes: RFC 1738 Status: PROPOSED STANDARD This document specifies the telnet Uniform Resource Identifier (URI) scheme that was originally specified in RFC 1738. The purpose of this document is to allow RFC 1738 to be made obsolete while keeping the information about the scheme on standards track.
RFC 4250	The Secure Shell (SSH) Protocol Assigned Numbers
	Authors: S. Lehtinen, C. Lonvick, Ed.. Date: January 2006 Formats: txt pdf Status: PROPOSED STANDARD This document defines the instructions to the IANA and the initial state of the IANA assigned numbers for the Secure Shell (SSH) protocol. It is intended only for the initialization of the IANA registries referenced in the set of SSH documents.
RFC 4251	The Secure Shell (SSH) Protocol Architecture
	Authors: T. Ylonen, C. Lonvick, Ed.. Date: January 2006 Formats: txt pdf Status: PROPOSED STANDARD The Secure Shell (SSH) Protocol is a protocol for secure remote login and other secure network services over an insecure network. This document describes the architecture of the SSH protocol, as well as the notation and terminology used in SSH protocol documents. It also discusses the SSH algorithm naming system that allows local extensions. The SSH protocol consists of three major components: TheTransport Layer Protocol provides server authentication, confidentiality, and integrity with perfect forward secrecy. TheUser Authentication Protocol authenticates the client to the server.The Connection Protocol multiplexes the encrypted tunnel into several logical channels. Details of these protocols are described in separate documents.
RFC 4252	The Secure Shell (SSH) Authentication Protocol
	Authors: T. Ylonen, C. Lonvick, Ed.. Date: January 2006 Formats: txt pdf Status: PROPOSED STANDARD The Secure Shell Protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH authentication protocol framework and public key, password, and host-based client authentication methods.Additional authentication methods are described in separate documents. The SSH authentication protocol runs on top of the SSH transport layer protocol and provides a single authenticated tunnel for the SSH connection protocol.
RFC 4253	The Secure Shell (SSH) Transport Layer Protocol
	Authors: T. Ylonen, C. Lonvick, Ed.. Date: January 2006 Formats: txt pdf Status: PROPOSED STANDARD The Secure Shell (SSH) is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH transport layer protocol, which typically runs on top of TCP/IP. The protocol can be used as a basis for a number of secure network services. It provides strong encryption, server authentication, and integrity protection. It may also provide compression. Key exchange method, public key algorithm, symmetric encryption algorithm, message authentication algorithm, and hash algorithm are all negotiated. This document also describes the Diffie-Hellman key exchange method and the minimal set of algorithms that are needed to implement theSSH transport layer protocol.
RFC 4254	The Secure Shell (SSH) Connection Protocol
	Authors: T. Ylonen, C. Lonvick, Ed.. Date: January 2006 Formats: txt pdf Status: PROPOSED STANDARD Secure Shell (SSH) is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH Connection Protocol. It provides interactive login sessions, remote execution of commands, forwardedTCP/IP connections, and forwarded X11 connections. All of these channels are multiplexed into a single encrypted tunnel. The SSH Connection Protocol has been designed to run on top of theSSH transport layer and user authentication protocols.
RFC 4255	Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints
	Authors: J. Schlyter, W. Griffin. Date: January 2006 Formats: txt pdf Status: PROPOSED STANDARD This document describes a method of verifying Secure Shell (SSH) host keys using Domain Name System Security (DNSSEC). The document defines a new DNS resource record that contains a standard SSH key fingerprint.
RFC 4256	Generic Message Exchange Authentication for the Secure Shell Protocol (SSH)
	Authors: F. Cusack, M. Forssen. Date: January 2006 Formats: txt pdf Status: PROPOSED STANDARD The Secure Shell Protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network. This document describes a general purpose authentication method for theSSH protocol, suitable for interactive authentications where the authentication data should be entered via a keyboard (or equivalent alphanumeric input device). The major goal of this method is to allow the SSH client to support a whole class of authentication mechanism(s) without knowing the specifics of the actual authentication mechanism(s).
RFC 4261	Common Open Policy Service (COPS) Over Transport Layer Security (TLS)
	Authors: J. Walker, A. Kulkarni, Ed.. Date: December 2005 Formats: txt pdf Updates: RFC 2748 Status: PROPOSED STANDARD This document describes how to use Transport Layer Security (TLS) to secure Common Open Policy Service (COPS) connections over theInternet. This document also updates RFC 2748 by modifying the contents of theClient-Accept message.
RFC 4262	X.509 Certificate Extension for Secure/Multipurpose Internet Mail Extensions (S/MIME) Capabilities
	Authors: S. Santesson. Date: December 2005 Formats: txt pdf Status: PROPOSED STANDARD This document defines a certificate extension for inclusion ofSecure/Multipurpose Internet Mail Extensions (S/MIME) Capabilities inX.509 public key certificates, as defined by RFC 3280. This certificate extension provides an optional method to indicate the cryptographic capabilities of an entity as a complement to the S/MIMECapabilities signed attribute in S/MIME messages according to RFC3851.
RFC 4265	Definition of Textual Conventions for Virtual Private Network (VPN) Management
	Authors: B. Schliesser, T. Nadeau. Date: November 2005 Formats: txt pdf Status: PROPOSED STANDARD This document describes Textual Conventions used for managing VirtualPrivate Networks (VPNs).
RFC 4266	The gopher URI Scheme
	Authors: P. Hoffman. Date: November 2005 Formats: txt pdf Obsoletes: RFC 1738 Status: PROPOSED STANDARD This document specifies the gopher Uniform Resource Identifier (URI) scheme that was originally specified in RFC 1738. The purpose of this document is to allow RFC 1738 to be made obsolete while keeping the information about the scheme on standards track.
RFC 4268	Entity State MIB
	Authors: S. Chisholm, D. Perkins. Date: November 2005 Formats: txt pdf Status: PROPOSED STANDARD 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 extensions to the Entity MIB to provide information about the state of physical entities. In addition, this memo defines a set of Textual Conventions to represent various states of an entity. The intent is that theseTextual Conventions will be imported and used in MIB modules that would otherwise define their own representations.
RFC 4273	Definitions of Managed Objects for BGP-4
	Authors: J. Haas, Ed., S. Hares, Ed.. Date: January 2006 Formats: txt pdf Obsoletes: RFC 1269, RFC 1657 Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet communityIn particular, it describes managed objects used for managing theBorder Gateway Protocol Version 4 or lower. The origin of this memo is from RFC 1269 "Definitions of ManagedObjects for the Border Gateway Protocol (Version 3)", which was updated to support BGP-4 in RFC 1657. This memo fixes errors introduced when the MIB module was converted to use the SMIv2 language. This memo also updates references to the current SNMP framework documents. This memo is intended to document deployed implementations of thisMIB module in a historical context, to provide clarifications of some items, and to note errors where the MIB module fails to fully represent the BGP protocol. Work is currently in progress to replace this MIB module with a new one representing the current state of theBGP protocol and its extensions. This document obsoletes RFC 1269 and RFC 1657.
RFC 4279	Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)
	Authors: P. Eronen, Ed., H. Tschofenig, Ed.. Date: December 2005 Formats: txt pdf Status: PROPOSED STANDARD This document specifies three sets of new ciphersuites for theTransport Layer Security (TLS) protocol to support authentication based on pre-shared keys (PSKs). These pre-shared keys are symmetric keys, shared in advance among the communicating parties. The first set of ciphersuites uses only symmetric key operations for authentication. The second set uses a Diffie-Hellman exchange authenticated with a pre-shared key, and the third set combines public key authentication of the server with pre-shared key authentication of the client.
RFC 4280	Dynamic Host Configuration Protocol (DHCP) Options for Broadcast and Multicast Control Servers
	Authors: K. Chowdhury, P. Yegani, L. Madour. Date: November 2005 Formats: txt pdf Status: PROPOSED STANDARD This document defines new options to discover the Broadcast andMulticast Service (BCMCS) controller in an IP network. BCMCS is being developed for Third generation (3G) cellular telephone networks. Users of the service interact with a controller in the network via the Mobile Node (MN) to derive information required to receive Broadcast and Multicast Service. Dynamic Host ConfigurationProtocol can be used to configure the MN to access a particular controller. This document defines the related options and option codes.
RFC 4281	The Codecs Parameter for "Bucket" Media Types
	Authors: R. Gellens, D. Singer, P. Frojdh. Date: November 2005 Formats: txt pdf Obsoleted by: RFC 6381 Status: PROPOSED STANDARD Several MIME type/subtype combinations exist that can contain different media formats. A receiving agent thus needs to examine the details of such media content to determine if the specific elements can be rendered given an available set of codecs. Especially when the end system has limited resources, or the connection to the end system has limited bandwidth, it would be helpful to know from theContent-Type alone if the content can be rendered. This document adds a new parameter, "codecs", to various type/subtype combinations to allow for unambiguous specification of the codecs indicated by the media formats contained within. By labeling content with the specific codecs indicated to render the contained media, receiving systems can determine if the codecs are supported by the end system, and if not, can take appropriate action(such as rejecting the content, sending notification of the situation, transcoding the content to a supported type, fetching and installing the required codecs, further inspection to determine if it will be sufficient to support a subset of the indicated codecs, etc.)
RFC 4282	The Network Access Identifier
	Authors: B. Aboba, M. Beadles, J. Arkko, P. Eronen. Date: December 2005 Formats: txt pdf Obsoletes: RFC 2486 Status: PROPOSED STANDARD In order to provide roaming services, it is necessary to have a standardized method for identifying users. This document defines the syntax for the Network Access Identifier (NAI), the user identity submitted by the client during network authentication. "Roaming" may be loosely defined as the ability to use any one of multiple InternetService Providers (ISPs), while maintaining a formal, customer-vendor relationship with only one. Examples of where roaming capabilities might be required include ISP "confederations" and ISP-provided corporate network access support. This document is a revised version of RFC 2486, which originally defined NAIs. Enhancements include international character set and privacy support, as well as a number of corrections to the original RFC.
RFC 4283	Mobile Node Identifier Option for Mobile IPv6 (MIPv6)
	Authors: A. Patel, K. Leung, M. Khalil, H. Akhtar, K. Chowdhury. Date: November 2005 Formats: txt pdf Status: PROPOSED STANDARD Mobile IPv6 (MIPv6) defines a new Mobility header that is used by mobile nodes, correspondent nodes, and home agents in all messaging related to the creation and management of bindings. Mobile IPv6 nodes need the capability to identify themselves using an identity other than the default home IP address. Some examples of identifiers include Network Access Identifier (NAI), Fully Qualified Domain Name(FQDN), International Mobile Station Identifier (IMSI), and MobileSubscriber Number (MSISDN). This document defines a new mobility option that can be used by Mobile IPv6 entities to identify themselves in messages containing a mobility header.
RFC 4286	Multicast Router Discovery
	Authors: B. Haberman, J. Martin. Date: December 2005 Formats: txt pdf Status: PROPOSED STANDARD The concept of Internet Group Management Protocol (IGMP) andMulticast Listener Discovery (MLD) snooping requires the ability to identify the location of multicast routers. Since snooping is not standardized, there are many mechanisms in use to identify the multicast routers. However, this can lead to interoperability issues between multicast routers and snooping switches from different vendors. This document introduces a general mechanism that allows for the discovery of multicast routers. This new mechanism, Multicast RouterDiscovery (MRD), introduces a standardized means of identifying multicast routers without a dependency on particular multicast routing protocols.
RFC 4287	The Atom Syndication Format
	Authors: M. Nottingham, Ed., R. Sayre, Ed.. Date: December 2005 Formats: txt pdf Updated by: RFC 5988 Status: PROPOSED STANDARD This document specifies Atom, an XML-based Web content and metadata syndication format.
RFC 4292	IP Forwarding Table MIB
	Authors: B. Haberman. Date: April 2006 Formats: txt pdf Obsoletes: RFC 2096 Status: PROPOSED STANDARD This document 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 related to the forwarding of Internet Protocol (IP) packets in an IP version- independent manner. This document obsoletes RFC 2096.
RFC 4293	Management Information Base for the Internet Protocol (IP)
	Authors: S. Routhier, Ed.. Date: April 2006 Formats: txt pdf Obsoletes: RFC 2011, RFC 2465, RFC 2466 Status: PROPOSED STANDARD 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 implementations of the Internet Protocol (IP) in an IP version independent manner.This memo obsoletes RFCs 2011, 2465, and 2466.
RFC 4295	Mobile IPv6 Management Information Base
	Authors: G. Keeni, K. Koide, K. Nagami, S. Gundavelli. Date: April 2006 Formats: txt pdf Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB), the Mobile-IPv6 MIB, for use with network management protocols in theInternet community. In particular, the Mobile-IPv6 MIB will be used to monitor and control the mobile node, home agent, and correspondent node functions of a Mobile IPv6 (MIPv6) entity.
RFC 4298	RTP Payload Format for BroadVoice Speech Codecs
	Authors: J.-H. Chen, W. Lee, J. Thyssen. Date: December 2005 Formats: txt pdf Status: PROPOSED STANDARD This document describes the RTP payload format for the BroadVoice(R) narrowband and wideband speech codecs. The narrowband codec, calledBroadVoice16, or BV16, has been selected by CableLabs as a mandatory codec in PacketCable 1.5 and has a CableLabs specification. The document also provides specifications for the use of BroadVoice withMIME and the Session Description Protocol (SDP).
RFC 4301	Security Architecture for the Internet Protocol
	Authors: S. Kent, K. Seo. Date: December 2005 Formats: txt pdf Obsoletes: RFC 2401 Updates: RFC 3168 Updated by: RFC 6040 Status: PROPOSED STANDARD This document describes an updated version of the "SecurityArchitecture for IP", which is designed to provide security services for traffic at the IP layer. This document obsoletes RFC 2401(November 1998).
RFC 4302	IP Authentication Header
	Authors: S. Kent. Date: December 2005 Formats: txt pdf Obsoletes: RFC 2402 Status: PROPOSED STANDARD This document describes an updated version of the IP AuthenticationHeader (AH), which is designed to provide authentication services inIPv4 and IPv6. This document obsoletes RFC 2402 (November 1998).
RFC 4303	IP Encapsulating Security Payload (ESP)
	Authors: S. Kent. Date: December 2005 Formats: txt pdf Obsoletes: RFC 2406 Status: PROPOSED STANDARD This document describes an updated version of the EncapsulatingSecurity Payload (ESP) protocol, which is designed to provide a mix of security services in IPv4 and IPv6. ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality. This document obsoletes RFC 2406 (November 1998).
RFC 4304	Extended Sequence Number (ESN) Addendum to IPsec Domain of Interpretation (DOI) for Internet Security Association and Key Management Protocol (ISAKMP)
	Authors: S. Kent. Date: December 2005 Formats: txt pdf Status: PROPOSED STANDARD The IP Security Authentication Header (AH) and Encapsulating SecurityPayload (ESP) protocols use a sequence number to detect replay. This document describes extensions to the Internet IP Security Domain ofInterpretation (DOI) for the Internet Security Association and KeyManagement Protocol (ISAKMP). These extensions support negotiation of the use of traditional 32-bit sequence numbers or extended (64- bit) sequence numbers (ESNs) for a particular AH or ESP security association.
RFC 4305	Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)
	Authors: D. Eastlake 3rd. Date: December 2005 Formats: txt pdf Obsoletes: RFC 2402, RFC 2406 Obsoleted by: RFC 4835 Status: PROPOSED STANDARD The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. The EncapsulatingSecurity Payload (ESP) and the Authentication Header (AH) provide two mechanisms for protecting data being sent over an IPsec SecurityAssociation (SA). To ensure interoperability between disparate implementations, it is necessary to specify a set of mandatory-to- implement algorithms to ensure that there is at least one algorithm that all implementations will have available. This document defines the current set of mandatory-to-implement algorithms for ESP and AH as well as specifying algorithms that should be implemented because they may be promoted to mandatory at some future time.
RFC 4306	Internet Key Exchange (IKEv2) Protocol
	Authors: C. Kaufman, Ed.. Date: December 2005 Formats: txt pdf Obsoletes: RFC 2407, RFC 2408, RFC 2409 Obsoleted by: RFC 5996 Updated by: RFC 5282 Status: PROPOSED STANDARD This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining security associations(SAs). This version of the IKE specification combines the contents of what were previously separate documents, including Internet SecurityAssociation and Key Management Protocol (ISAKMP, RFC 2408), IKE (RFC2409), the Internet Domain of Interpretation (DOI, RFC 2407), NetworkAddress Translation (NAT) Traversal, Legacy authentication, and remote address acquisition. Version 2 of IKE does not interoperate with version 1, but it has enough of the header format in common that both versions can unambiguously run over the same UDP port.
RFC 4307	Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)
	Authors: J. Schiller. Date: December 2005 Formats: txt pdf Status: PROPOSED STANDARD The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Internet KeyExchange (IKE (RFC 2409) and IKEv2) provide a mechanism to negotiate which algorithms should be used in any given association. However, to ensure interoperability between disparate implementations, it is necessary to specify a set of mandatory-to-implement algorithms to ensure that there is at least one algorithm that all implementations will have available. This document defines the current set of algorithms that are mandatory to implement as part of IKEv2, as well as algorithms that should be implemented because they may be promoted to mandatory at some future time.
RFC 4308	Cryptographic Suites for IPsec
	Authors: P. Hoffman. Date: December 2005 Formats: txt pdf Status: PROPOSED STANDARD The IPsec, Internet Key Exchange (IKE), and IKEv2 protocols rely on security algorithms to provide privacy and authentication between the initiator and responder. There are many such algorithms available, and two IPsec systems cannot interoperate unless they are using the same algorithms. This document specifies optional suites of algorithms and attributes that can be used to simplify the administration of IPsec when used in manual keying mode, with IKEv1 or with IKEv2.
RFC 4309	Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)
	Authors: R. Housley. Date: December 2005 Formats: txt pdf Status: PROPOSED STANDARD This document describes the use of Advanced Encryption Standard (AES) in Counter with CBC-MAC (CCM) Mode, with an explicit initialization vector (IV), as an IPsec Encapsulating Security Payload (ESP) mechanism to provide confidentiality, data origin authentication, and connectionless integrity.
RFC 4310	Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)
	Authors: S. Hollenbeck. Date: December 2005 Formats: txt pdf Obsoleted by: RFC 5910 Status: PROPOSED STANDARD This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of Domain NameSystem security extensions (DNSSEC) for domain names stored in a shared central repository. Specified in XML, this mapping extends the EPP domain name mapping to provide additional features required for the provisioning of DNS security extensions.
RFC 4311	IPv6 Host-to-Router Load Sharing
	Authors: R. Hinden, D. Thaler. Date: November 2005 Formats: txt pdf Updates: RFC 2461 Status: PROPOSED STANDARD The original IPv6 conceptual sending algorithm does not do load sharing among equivalent IPv6 routers, and suggests schemes that can be problematic in practice. This document updates the conceptual sending algorithm in RFC 2461 so that traffic to different destinations can be distributed among routers in an efficient fashion.
RFC 4312	The Camellia Cipher Algorithm and Its Use With IPsec
	Authors: A. Kato, S. Moriai, M. Kanda. Date: December 2005 Formats: txt pdf Status: PROPOSED STANDARD This document describes the use of the Camellia block cipher algorithm in Cipher Block Chaining Mode, with an explicitInitialization Vector, as a confidentiality mechanism within the context of the IPsec Encapsulating Security Payload (ESP).
RFC 4314	IMAP4 Access Control List (ACL) Extension
	Authors: A. Melnikov. Date: December 2005 Formats: txt pdf Obsoletes: RFC 2086 Status: PROPOSED STANDARD The Access Control List (ACL) extension (RFC 2086) of the InternetMessage Access Protocol (IMAP) permits mailbox access control lists to be retrieved and manipulated through the IMAP protocol. This document is a revision of RFC 2086. It defines several new access control rights and clarifies which rights are required for different IMAP commands.
RFC 4315	Internet Message Access Protocol (IMAP) - UIDPLUS extension
	Authors: M. Crispin. Date: December 2005 Formats: txt pdf Obsoletes: RFC 2359 Status: PROPOSED STANDARD The UIDPLUS extension of the Internet Message Access Protocol (IMAP) provides a set of features intended to reduce the amount of time and resources used by some client operations. The features in UIDPLUS are primarily intended for disconnected-use clients.
RFC 4318	Definitions of Managed Objects for Bridges with Rapid Spanning Tree Protocol
	Authors: D. Levi, D. Harrington. Date: December 2005 Formats: txt pdf Status: PROPOSED STANDARD This memo defines an SMIv2 MIB module for managing the Rapid SpanningTree capability defined by the IEEE P802.1t and P802.1w amendments toIEEE Std 802.1D-1998 for bridging between Local Area Network (LAN) segments. The objects in this MIB are defined to apply both to transparent bridging and to bridges connected by subnetworks other than LAN segments.
RFC 4319	Definitions of Managed Objects for High Bit-Rate DSL - 2nd generation (HDSL2) and Single-Pair High-Speed Digital Subscriber Line (SHDSL) Lines
	Authors: C. Sikes, B. Ray, R. Abbi. Date: December 2005 Formats: txt pdf Obsoletes: RFC 3276 Status: PROPOSED STANDARD This document defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing High Bit-RateDigital Subscriber Line (DSL) - 2nd generation (HDSL2) andSingle-Pair High-Speed Digital Subscriber Line (SHDSL) interfaces.This document introduces extensions to several objects and textual conventions defined in HDSL2-SHDSL-Line MIB (RFC 3276). This document obsoletes RFC 3276.
RFC 4320	Actions Addressing Identified Issues with the Session Initiation Protocol's (SIP) Non-INVITE Transaction
	Authors: R. Sparks. Date: January 2006 Formats: txt pdf Updates: RFC 3261 Status: PROPOSED STANDARD This document describes modifications to the Session InitiationProtocol (SIP) to address problems that have been identified with theSIP non-INVITE transaction. These modifications reduce the probability of messages losing the race condition inherent in the non-INVITE transaction and reduce useless network traffic. They also improve the robustness of SIP networks when elements stop responding.These changes update behavior defined in RFC 3261.
RFC 4323	Data Over Cable System Interface Specification Quality of Service Management Information Base (DOCSIS-QoS MIB)
	Authors: M. Patrick, W. Murwin. Date: January 2006 Formats: txt pdf Status: PROPOSED STANDARD This document defines a basic set of managed objects for SNMP-based management of extended QoS features of Cable Modems (CMs) and CableModem Termination Systems (CMTSs) conforming to the Data over CableSystem (DOCSIS) specifications versions 1.1 and 2.0.
RFC 4325	Internet X.509 Public Key Infrastructure Authority Information Access Certificate Revocation List (CRL) Extension
	Authors: S. Santesson, R. Housley. Date: December 2005 Formats: txt pdf Obsoleted by: RFC 5280 Updates: RFC 3280 Status: PROPOSED STANDARD This document updates RFC 3280 by defining the Authority InformationAccess Certificate Revocation List (CRL) extension. RFC 3280 defines the Authority Information Access certificate extension using the same syntax. The CRL extension provides a means of discovering and retrieving CRL issuer certificates.
RFC 4326	Unidirectional Lightweight Encapsulation (ULE) for Transmission of IP Datagrams over an MPEG-2 Transport Stream (TS)
	Authors: G. Fairhurst, B. Collini-Nocker. Date: December 2005 Formats: txt pdf Status: PROPOSED STANDARD The MPEG-2 Transport Stream (TS) has been widely accepted not only for providing digital TV services, but also as a subnetwork technology for building IP networks. This document describes a Unidirectional Lightweight Encapsulation(ULE) mechanism for the transport of IPv4 and IPv6 Datagrams and other network protocol packets directly over the ISO MPEG-2 TransportStream as TS Private Data. ULE specifies a base encapsulation format and supports an extension format that allows it to carry additional header information to assist in network/Receiver processing.
RFC 4327	Link Management Protocol (LMP) Management Information Base (MIB)
	Authors: M. Dubuc, T. Nadeau, J. Lang, E. McGinnis. Date: January 2006 Formats: txt pdf Obsoleted by: RFC 4631 Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes managed objects for modeling the LinkManagement Protocol (LMP).
RFC 4328	Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control
	Authors: D. Papadimitriou, Ed.. Date: January 2006 Formats: txt pdf Updates: RFC 3471 Status: PROPOSED STANDARD This document is a companion to the Generalized Multi-Protocol LabelSwitching (GMPLS) signaling documents. It describes the technology- specific information needed to extend GMPLS signaling to controlOptical Transport Networks (OTN); it also includes the so-called pre-OTN developments.
RFC 4331	Quota and Size Properties for Distributed Authoring and Versioning (DAV) Collections
	Authors: B. Korver, L. Dusseault. Date: February 2006 Formats: txt pdf Status: PROPOSED STANDARD Web Distributed Authoring and Versioning (WebDAV) servers are frequently deployed with quota (size) limitations. This document discusses the properties and minor behaviors needed for clients to interoperate with quota (size) implementations on WebDAV repositories.
RFC 4334	Certificate Extensions and Attributes Supporting Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN)
	Authors: R. Housley, T. Moore. Date: February 2006 Formats: txt pdf Obsoletes: RFC 3770 Status: PROPOSED STANDARD This document defines two Extensible Authentication Protocol (EAP) extended key usage values and a public key certificate extension to carry Wireless LAN (WLAN) System Service identifiers (SSIDs). This document obsoletes RFC 3770.
RFC 4335	The Secure Shell (SSH) Session Channel Break Extension
	Authors: J. Galbraith, P. Remaker. Date: January 2006 Formats: txt pdf Status: PROPOSED STANDARD The Session Channel Break Extension provides a means to send a BREAK signal over a Secure Shell (SSH) terminal session.
RFC 4337	MIME Type Registration for MPEG-4
	Authors: Y Lim, D. Singer. Date: March 2006 Formats: txt pdf Updated by: RFC 6381 Status: PROPOSED STANDARD This document defines the standard MIME types associated with MP4 files. It also recommends use of registered MIME types according to the type of contents.
RFC 4338	Transmission of IPv6, IPv4, and Address Resolution Protocol (ARP) Packets over Fibre Channel
	Authors: C. DeSanti, C. Carlson, R. Nixon. Date: January 2006 Formats: txt pdf Obsoletes: RFC 3831, RFC 2625 Updated by: RFC 5494 Status: PROPOSED STANDARD This document specifies the way of encapsulating IPv6, IPv4, andAddress Resolution Protocol (ARP) packets over Fibre Channel. This document also specifies the method of forming IPv6 link-local addresses and statelessly autoconfigured IPv6 addresses on FibreChannel networks, and a mechanism to perform IPv4 address resolution over Fibre Channel networks. This document obsoletes RFC 2625 and RFC 3831.
RFC 4340	Datagram Congestion Control Protocol (DCCP)
	Authors: E. Kohler, M. Handley, S. Floyd. Date: March 2006 Formats: txt pdf Updated by: RFC 5595, RFC 5596, RFC 6335 Status: PROPOSED STANDARD The Datagram Congestion Control Protocol (DCCP) is a transport protocol that provides bidirectional unicast connections of congestion-controlled unreliable datagrams. DCCP is suitable for applications that transfer fairly large amounts of data and that can benefit from control over the tradeoff between timeliness and reliability.
RFC 4341	Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion Control
	Authors: S. Floyd, E. Kohler. Date: March 2006 Formats: txt pdf Status: PROPOSED STANDARD This document contains the profile for Congestion Control Identifier2 (CCID 2), TCP-like Congestion Control, in the Datagram CongestionControl Protocol (DCCP). CCID 2 should be used by senders who would like to take advantage of the available bandwidth in an environment with rapidly changing conditions, and who are able to adapt to the abrupt changes in the congestion window typical of TCP's AdditiveIncrease Multiplicative Decrease (AIMD) congestion control.
RFC 4342	Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC)
	Authors: S. Floyd, E. Kohler, J. Padhye. Date: March 2006 Formats: txt pdf Updated by: RFC 5348, RFC 6323 Status: PROPOSED STANDARD This document contains the profile for Congestion Control Identifier3, TCP-Friendly Rate Control (TFRC), in the Datagram CongestionControl Protocol (DCCP). CCID 3 should be used by senders that want a TCP-friendly sending rate, possibly with Explicit CongestionNotification (ECN), while minimizing abrupt rate changes.
RFC 4343	Domain Name System (DNS) Case Insensitivity Clarification
	Authors: D. Eastlake 3rd. Date: January 2006 Formats: txt pdf Updates: RFC 1034, RFC 1035, RFC 2181 Status: PROPOSED STANDARD Domain Name System (DNS) names are "case insensitive". This document explains exactly what that means and provides a clear specification of the rules. This clarification updates RFCs 1034, 1035, and 2181.
RFC 4344	The Secure Shell (SSH) Transport Layer Encryption Modes
	Authors: M. Bellare, T. Kohno, C. Namprempre. Date: January 2006 Formats: txt pdf Status: PROPOSED STANDARD Researchers have discovered that the authenticated encryption portion of the current SSH Transport Protocol is vulnerable to several attacks. This document describes new symmetric encryption methods for theSecure Shell (SSH) Transport Protocol and gives specific recommendations on how frequently SSH implementations should rekey.
RFC 4345	Improved Arcfour Modes for the Secure Shell (SSH) Transport Layer Protocol
	Authors: B. Harris. Date: January 2006 Formats: txt pdf Status: PROPOSED STANDARD This document specifies methods of using the Arcfour cipher in theSecure Shell (SSH) protocol that mitigate the weakness of the cipher's key-scheduling algorithm.
RFC 4346	The Transport Layer Security (TLS) Protocol Version 1.1
	Authors: T. Dierks, E. Rescorla. Date: April 2006 Formats: txt pdf Obsoletes: RFC 2246 Obsoleted by: RFC 5246 Updated by: RFC 4366, RFC 4680, RFC 4681, RFC 5746, RFC 6176 Status: PROPOSED STANDARD This document specifies Version 1.1 of the Transport Layer Security(TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.
RFC 4347	Datagram Transport Layer Security
	Authors: E. Rescorla, N. Modadugu. Date: April 2006 Formats: txt pdf Obsoleted by: RFC 6347 Updated by: RFC 5746 Status: PROPOSED STANDARD This document specifies Version 1.0 of the Datagram Transport LayerSecurity (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol.
RFC 4348	Real-Time Transport Protocol (RTP) Payload Format for the Variable-Rate Multimode Wideband (VMR-WB) Audio Codec
	Authors: S. Ahmadi. Date: January 2006 Formats: txt pdf Updated by: RFC 4424 Status: PROPOSED STANDARD This document specifies a real-time transport protocol (RTP) payload format to be used for the Variable-Rate Multimode Wideband (VMR-WB) speech codec. The payload format is designed to be able to interoperate with existing VMR-WB transport formats on non-IP networks. A media type registration is included for VMR-WB RTP payload format. VMR-WB is a variable-rate multimode wideband speech codec that has a number of operating modes, one of which is interoperable with AMR-WB(i.e., RFC 3267) audio codec at certain rates. Therefore, provisions have been made in this document to facilitate and simplify data packet exchange between VMR-WB and AMR-WB in the interoperable mode with no transcoding function involved.
RFC 4349	High-Level Data Link Control (HDLC) Frames over Layer 2 Tunneling Protocol, Version 3 (L2TPv3)
	Authors: C. Pignataro, M. Townsley. Date: February 2006 Formats: txt pdf Updated by: RFC 5641 Status: PROPOSED STANDARD The Layer 2 Tunneling Protocol, Version 3, (L2TPv3) defines a protocol for tunneling a variety of data link protocols over IP networks. This document describes the specifics of how to tunnelHigh-Level Data Link Control (HDLC) frames over L2TPv3.
RFC 4352	RTP Payload Format for the Extended Adaptive Multi-Rate Wideband (AMR-WB+) Audio Codec
	Authors: J. Sjoberg, M. Westerlund, A. Lakaniemi, S. Wenger. Date: January 2006 Formats: txt pdf Status: PROPOSED STANDARD This document specifies a Real-time Transport Protocol (RTP) payload format for Extended Adaptive Multi-Rate Wideband (AMR-WB+) encoded audio signals. The AMR-WB+ codec is an audio extension of the AMR-WB speech codec. It encompasses the AMR-WB frame types and a number of new frame types designed to support high-quality music and speech. A media type registration for AMR-WB+ is included in this specification.
RFC 4355	IANA Registration for Enumservices email, fax, mms, ems, and sms
	Authors: R. Brandner, L. Conroy, R. Stastny. Date: January 2006 Formats: txt pdf Updated by: RFC 6118 Status: PROPOSED STANDARD This document registers the Enumservices "email", "fax", "sms","ems", and "mms" using the URI schemes 'tel:' and 'mailto:' as per the IANA registration process defined in the ENUM specification RFC3761.
RFC 4356	Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail
	Authors: R. Gellens. Date: January 2006 Formats: txt pdf Status: PROPOSED STANDARD The cellular telephone industry has defined a service known as theMultimedia Messaging Service (MMS). This service uses formats and protocols that are similar to, but differ in key ways from, those used in Internet mail. One important difference between MMS and Internet Mail is that MMS uses headers that start with "X-Mms-" to carry a variety of user agent- and server-related information elements. This document specifies how to exchange messages between these two services, including mapping information elements as used in MMSX-Mms-* headers as well as delivery and disposition reports, to and from that used in SMTP and Internet message headers.
RFC 4359	The Use of RSA/SHA-1 Signatures within Encapsulating Security Payload (ESP) and Authentication Header (AH)
	Authors: B. Weis. Date: January 2006 Formats: txt pdf Status: PROPOSED STANDARD This memo describes the use of the RSA digital signature algorithm as an authentication algorithm within the revised IP EncapsulatingSecurity Payload (ESP) as described in RFC 4303 and the revised IPAuthentication Header (AH) as described in RFC 4302. The use of a digital signature algorithm, such as RSA, provides data origin authentication in applications when a secret key method (e.g., HMAC) does not provide this property. One example is the use of ESP and AH to authenticate the sender of an IP multicast packet.
RFC 4360	BGP Extended Communities Attribute
	Authors: S. Sangli, D. Tappan, Y. Rekhter. Date: February 2006 Formats: txt pdf Status: PROPOSED STANDARD This document describes the "extended community" BGP-4 attribute.This attribute provides a mechanism for labeling information carried in BGP-4. These labels can be used to control the distribution of this information, or for other applications.
RFC 4361	Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4)
	Authors: T. Lemon, B. Sommerfeld. Date: February 2006 Formats: txt pdf Updates: RFC 2131, RFC 2132, RFC 3315 Updated by: RFC 5494 Status: PROPOSED STANDARD This document specifies the format that is to be used for encodingDynamic Host Configuration Protocol Version Four (DHCPv4) client identifiers, so that those identifiers will be interchangeable with identifiers used in the DHCPv6 protocol. This document also addresses and corrects some problems in RFC 2131 and RFC 2132 with respect to the handling of DHCP client identifiers.
RFC 4362	RObust Header Compression (ROHC): A Link-Layer Assisted Profile for IP/UDP/RTP
	Authors: L-E. Jonsson, G. Pelletier, K. Sandlund. Date: January 2006 Formats: txt pdf Obsoletes: RFC 3242 Updated by: RFC 4815 Status: PROPOSED STANDARD This document defines a ROHC (Robust Header Compression) profile for compression of IP/UDP/RTP (Internet Protocol/User DatagramProtocol/Real-Time Transport Protocol) packets, utilizing functionality provided by the lower layers to increase compression efficiency by completely eliminating the header for most packets during optimal operation. The profile is built as an extension to the ROHC RTP profile. It defines additional mechanisms needed inROHC, states requirements on the assisting layer to guarantee transparency, and specifies general logic for compression and decompression related to the usage of the header-free packet format.This document is a replacement for RFC 3242, which it obsoletes.
RFC 4363	Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering, and Virtual LAN Extensions
	Authors: D. Levi, D. Harrington. Date: January 2006 Formats: txt pdf Obsoletes: RFC 2674 Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it defines two MIB modules for managing the capabilities of MAC bridges defined by the IEEE 802.1D-1998 (TM) MACBridges and the IEEE 802.1Q-2003 (TM) Virtual LAN (VLAN) standards for bridging between Local Area Network (LAN) segments. One MIB module defines objects for managing the 'Traffic Classes' and'Enhanced Multicast Filtering' components of IEEE 802.1D-1998 andP802.1t-2001 (TM). The other MIB module defines objects for managingVLANs, as specified in IEEE 802.1Q-2003, P802.1u (TM), and P802.1v(TM). Provisions are made for support of transparent bridging. Provisions are also made so that these objects apply to bridges connected by subnetworks other than LAN segments. This memo supplements RFC 4188 and obsoletes RFC 2674.
RFC 4364	BGP/MPLS IP Virtual Private Networks (VPNs)
	Authors: E. Rosen, Y. Rekhter. Date: February 2006 Formats: txt pdf Obsoletes: RFC 2547 Updated by: RFC 4577, RFC 4684, RFC 5462 Status: PROPOSED STANDARD This document describes a method by which a Service Provider may use an IP backbone to provide IP Virtual Private Networks (VPNs) for its customers. This method uses a "peer model", in which the customers' edge routers (CE routers) send their routes to the Service Provider's edge routers (PE routers); there is no "overlay" visible to the customer's routing algorithm, and CE routers at different sites do not peer with each other. Data packets are tunneled through the backbone, so that the core routers do not need to know the VPN routes. This document obsoletes RFC 2547.
RFC 4366	Transport Layer Security (TLS) Extensions
	Authors: S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, T. Wright. Date: April 2006 Formats: txt pdf Obsoletes: RFC 3546 Obsoleted by: RFC 5246, RFC 6066 Updates: RFC 4346 Updated by: RFC 5746 Status: PROPOSED STANDARD This document describes extensions that may be used to add functionality to Transport Layer Security (TLS). It provides both generic extension mechanisms for the TLS handshake client and server hellos, and specific extensions using these generic mechanisms. The extensions may be used by TLS clients and servers. The extensions are backwards compatible: communication is possible between TLS clients that support the extensions and TLS servers that do not support the extensions, and vice versa.
RFC 4368	Multiprotocol Label Switching (MPLS) Label-Controlled Asynchronous Transfer Mode (ATM) and Frame-Relay Management Interface Definition
	Authors: T. Nadeau, S. Hegde. Date: January 2006 Formats: txt pdf Status: PROPOSED STANDARD This memo defines two MIB modules and corresponding MIB ObjectDefinitions that describe how label-switching-controlled Frame-Relay and Asynchronous Transfer Mode (ATM) interfaces can be managed given the interface stacking as defined in the MPLS-LSR-STD-MIB andMPLS-TE-STD-MIB.
RFC 4369	Definitions of Managed Objects for Internet Fibre Channel Protocol (iFCP)
	Authors: K. Gibbons, C. Monia, J. Tseng, F. Travostino. Date: January 2006 Formats: txt pdf Obsoleted by: RFC 6173 Status: PROPOSED STANDARD The iFCP protocol (RFC 4172) provides Fibre Channel fabric functionality on an IP network in which TCP/IP switching and routing elements replace Fibre Channel components. The iFCP protocol is used between iFCP Gateways. This document provides a mechanism to monitor and control iFCP Gateway instances, and their associated sessions, using SNMP.
RFC 4370	Lightweight Directory Access Protocol (LDAP) Proxied Authorization Control
	Authors: R. Weltman. Date: February 2006 Formats: txt pdf Status: PROPOSED STANDARD This document defines the Lightweight Directory Access Protocol(LDAP) Proxy Authorization Control. The Proxy Authorization Control allows a client to request that an operation be processed under a provided authorization identity instead of under the current authorization identity associated with the connection.
RFC 4372	Chargeable User Identity
	Authors: F. Adrangi, A. Lior, J. Korhonen, J. Loughney. Date: January 2006 Formats: txt pdf Status: PROPOSED STANDARD This document describes a new Remote Authentication Dial-In UserService (RADIUS) attribute, Chargeable-User-Identity. This attribute can be used by a home network to identify a user for the purpose of roaming transactions that occur outside of the home network.
RFC 4379	Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures
	Authors: K. Kompella, G. Swallow. Date: February 2006 Formats: txt pdf Updates: RFC 1122 Updated by: RFC 5462, RFC 6424, RFC 6425, RFC 6426 Status: PROPOSED STANDARD This document describes a simple and efficient mechanism that can be used to detect data plane failures in Multi-Protocol Label Switching(MPLS) Label Switched Paths (LSPs). There are two parts to this document: information carried in an MPLS "echo request" and "echo reply" for the purposes of fault detection and isolation, and mechanisms for reliably sending the echo reply.
RFC 4380	Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)
	Authors: C. Huitema. Date: February 2006 Formats: txt pdf Updated by: RFC 5991, RFC 6081 Status: PROPOSED STANDARD We propose here a service that enables nodes located behind one or more IPv4 Network Address Translations (NATs) to obtain IPv6 connectivity by tunneling packets over UDP; we call this the Teredo service. Running the service requires the help of "Teredo servers" and "Teredo relays". The Teredo servers are stateless, and only have to manage a small fraction of the traffic between Teredo clients; theTeredo relays act as IPv6 routers between the Teredo service and the"native" IPv6 Internet. The relays can also provide interoperability with hosts using other transition mechanisms such as "6to4".
RFC 4382	MPLS/BGP Layer 3 Virtual Private Network (VPN) Management Information Base
	Authors: T. Nadeau, Ed., H. van der Linde, Ed.. Date: February 2006 Formats: txt pdf Status: PROPOSED STANDARD 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 to configure and/or monitor Multiprotocol Label Switching Layer-3 Virtual PrivateNetworks on a Multiprotocol Label Switching (MPLS) Label SwitchingRouter (LSR) supporting this feature.
RFC 4383	The Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Secure Real-time Transport Protocol (SRTP)
	Authors: M. Baugher, E. Carrara. Date: February 2006 Formats: txt pdf Status: PROPOSED STANDARD This memo describes the use of the Timed Efficient Stream Loss- tolerant Authentication (RFC 4082) transform within the Secure Real- time Transport Protocol (SRTP), to provide data origin authentication for multicast and broadcast data streams.
RFC 4385	Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN
	Authors: S. Bryant, G. Swallow, L. Martini, D. McPherson. Date: February 2006 Formats: txt pdf Updated by: RFC 5586 Status: PROPOSED STANDARD This document describes the preferred design of a PseudowireEmulation Edge-to-Edge (PWE3) Control Word to be used over an MPLS packet switched network, and the Pseudowire Associated ChannelHeader. The design of these fields is chosen so that an MPLS LabelSwitching Router performing MPLS payload inspection will not confuse a PWE3 payload with an IP payload.
RFC 4387	Internet X.509 Public Key Infrastructure Operational Protocols: Certificate Store Access via HTTP
	Authors: P. Gutmann, Ed.. Date: February 2006 Formats: txt pdf Status: PROPOSED STANDARD The protocol conventions described in this document satisfy some of the operational requirements of the Internet Public KeyInfrastructure (PKI). This document specifies the conventions for using the Hypertext Transfer Protocol (HTTP/HTTPS) as an interface mechanism to obtain certificates and certificate revocation lists(CRLs) from PKI repositories. Additional mechanisms addressing PKIX operational requirements are specified in separate documents.
RFC 4388	Dynamic Host Configuration Protocol (DHCP) Leasequery
	Authors: R. Woundy, K. Kinnear. Date: February 2006 Formats: txt pdf Updated by: RFC 6148 Status: PROPOSED STANDARD A Dynamic Host Configuration Protocol version 4 (DHCPv4) server is the authoritative source of IP addresses that it has provided toDHCPv4 clients. Other processes and devices that already make use ofDHCPv4 may need to access this information. The leasequery protocol provides these processes and devices a lightweight way to access IP address information.
RFC 4390	Dynamic Host Configuration Protocol (DHCP) over InfiniBand
	Authors: V. Kashyap. Date: April 2006 Formats: txt pdf Status: PROPOSED STANDARD IP over Infiniband (IPoIB) link-layer address is 20 octets long.This is larger than the 16 octets reserved for the hardware address in a Dynamic Host Configuration Protocol/Bootstrap Protocol(DHCP/BOOTP) message. The above inequality imposes restrictions on the use of the DHCP message fields when used over an IPoIB network.This document describes the use of DHCP message fields when implementing DHCP over IPoIB.
RFC 4391	Transmission of IP over InfiniBand (IPoIB)
	Authors: J. Chu, V. Kashyap. Date: April 2006 Formats: txt pdf Status: PROPOSED STANDARD This document specifies a method for encapsulating and transmittingIPv4/IPv6 and Address Resolution Protocol (ARP) packets overInfiniBand (IB). It describes the link-layer address to be used when resolving the IP addresses in IP over InfiniBand (IPoIB) subnets.The document also describes the mapping from IP multicast addresses to InfiniBand multicast addresses. In addition, this document defines the setup and configuration of IPoIB links.
RFC 4393	MIME Type Registrations for 3GPP2 Multimedia Files
	Authors: H. Garudadri. Date: March 2006 Formats: txt pdf Updated by: RFC 6381 Status: PROPOSED STANDARD This document serves to register and document the standard MIME types associated with the 3GPP2 multimedia file format, which is part of the family based on the ISO Media File Format.
RFC 4396	RTP Payload Format for 3rd Generation Partnership Project (3GPP) Timed Text
	Authors: J. Rey, Y. Matsui. Date: February 2006 Formats: txt pdf Status: PROPOSED STANDARD This document specifies an RTP payload format for the transmission of3GPP (3rd Generation Partnership Project) timed text. 3GPP timed text is a time-lined, decorated text media format with defined storage in a 3GP file. Timed Text can be synchronized with audio/video contents and used in applications such as captioning, titling, and multimedia presentations. In the following sections, the problems of streaming timed text are addressed, and a payload format for streaming 3GPP timed text over RTP is specified.
RFC 4398	Storing Certificates in the Domain Name System (DNS)
	Authors: S. Josefsson. Date: March 2006 Formats: txt pdf Obsoletes: RFC 2538 Status: PROPOSED STANDARD Cryptographic public keys are frequently published, and their authenticity is demonstrated by certificates. A CERT resource record(RR) is defined so that such certificates and related certificate revocation lists can be stored in the Domain Name System (DNS). This document obsoletes RFC 2538.
RFC 4401	A Pseudo-Random Function (PRF) API Extension for the Generic Security Service Application Program Interface (GSS-API)
	Authors: N. Williams. Date: February 2006 Formats: txt pdf Status: PROPOSED STANDARD This document defines a Pseudo-Random Function (PRF) extension to theGeneric Security Service Application Program Interface (GSS-API) for keying application protocols given an established GSS-API security context. The primary intended use of this function is to key secure session layers that do not or cannot use GSS-API per-message message integrity check (MIC) and wrap tokens for session protection.
RFC 4402	A Pseudo-Random Function (PRF) for the Kerberos V Generic Security Service Application Program Interface (GSS-API) Mechanism
	Authors: N. Williams. Date: February 2006 Formats: txt pdf Status: PROPOSED STANDARD This document defines the Pseudo-Random Function (PRF) for theKerberos V mechanism for the Generic Security Service ApplicationProgram Interface (GSS-API), based on the PRF defined for theKerberos V cryptographic framework, for keying application protocols given an established Kerberos V GSS-API security context.
RFC 4404	Definitions of Managed Objects for Fibre Channel Over TCP/IP (FCIP)
	Authors: R. Natarajan, A. Rijhsinghani. Date: February 2006 Formats: txt pdf Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets.In particular, it defines objects for managing Fibre Channel OverTCP/IP (FCIP) entities, which are used to interconnect Fibre Channel(FC) fabrics with IP networks.
RFC 4411	Extending the Session Initiation Protocol (SIP) Reason Header for Preemption Events
	Authors: J. Polk. Date: February 2006 Formats: txt pdf Status: PROPOSED STANDARD This document proposes an IANA Registration extension to the SessionInitiation Protocol (SIP) Reason Header to be included in a BYEMethod Request as a result of a session preemption event, either at a user agent (UA), or somewhere in the network involving a reservation-based protocol such as the Resource ReSerVation Protocol(RSVP) or Next Steps in Signaling (NSIS). This document does not attempt to address routers failing in the packet path; instead, it addresses a deliberate tear down of a flow between UAs, and informs the terminated UA(s) with an indication of what occurred.
RFC 4412	Communications Resource Priority for the Session Initiation Protocol (SIP)
	Authors: H. Schulzrinne, J. Polk. Date: February 2006 Formats: txt pdf Status: PROPOSED STANDARD This document defines two new Session Initiation Protocol (SIP) header fields for communicating resource priority, namely,"Resource-Priority" and "Accept-Resource-Priority". The"Resource-Priority" header field can influence the behavior of SIP user agents (such as telephone gateways and IP telephones) and SIP proxies. It does not directly influence the forwarding behavior ofIP routers.
RFC 4414	An ENUM Registry Type for the Internet Registry Information Service (IRIS)
	Authors: A. Newton. Date: February 2006 Formats: txt pdf Status: PROPOSED STANDARD This document describes an Internet Registry Information Service(IRIS) registry schema for registered ENUM information. The schema extends the necessary query and result operations of IRIS to provide the functional information service needs for syntaxes and results used by ENUM registries.
RFC 4415	IANA Registration for Enumservice Voice
	Authors: R. Brandner, L. Conroy, R. Stastny. Date: February 2006 Formats: txt pdf Updated by: RFC 6118 Status: PROPOSED STANDARD This document registers the Enumservice "voice" (which has a defined subtype "tel"), as per the IANA registration process defined in theENUM specification RFC 3761. This service indicates that the contact held in the generated Uniform Resource Identifier (URI) can be used to initiate an interactive voice (audio) call.
RFC 4419	Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol
	Authors: M. Friedl, N. Provos, W. Simpson. Date: March 2006 Formats: txt pdf Status: PROPOSED STANDARD This memo describes a new key exchange method for the Secure Shell(SSH) protocol. It allows the SSH server to propose new groups on which to perform the Diffie-Hellman key exchange to the client. The proposed groups need not be fixed and can change with time.
RFC 4420	Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)
	Authors: A. Farrel, Ed., D. Papadimitriou, J.-P. Vasseur, A. Ayyangar. Date: February 2006 Formats: txt pdf Obsoleted by: RFC 5420 Updates: RFC 3209, RFC 3473 Status: PROPOSED STANDARD Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) may be established using the Resource Reservation Protocol TrafficEngineering (RSVP-TE) extensions. This protocol includes an object(the SESSION_ATTRIBUTE object) that carries a Flags field used to indicate options and attributes of the LSP. That Flags field has eight bits allowing for eight options to be set. Recent proposals in many documents that extend RSVP-TE have suggested uses for each of the previously unused bits. This document defines a new object for RSVP-TE messages that allows the signaling of further attribute bits and also the carriage of arbitrary attribute parameters to make RSVP-TE easily extensible to support new requirements. Additionally, this document defines a way to record the attributes applied to the LSP on a hop-by-hop basis. The object mechanisms defined in this document are equally applicable to Generalized MPLS (GMPLS) Packet Switch Capable (PSC) LSPs and toGMPLS non-PSC LSPs.
RFC 4421	RTP Payload Format for Uncompressed Video: Additional Colour Sampling Modes
	Authors: C. Perkins. Date: February 2006 Formats: txt pdf Updates: RFC 4175 Status: PROPOSED STANDARD The RFC Payload Format for Uncompressed Video, RFC 4175, defines a scheme to packetise uncompressed, studio-quality, video streams for transport using RTP. This memo extends the format to support additional colour sampling modes.
RFC 4422	Simple Authentication and Security Layer (SASL)
	Authors: A. Melnikov, Ed., K. Zeilenga, Ed.. Date: June 2006 Formats: txt pdf Obsoletes: RFC 2222 Status: PROPOSED STANDARD The Simple Authentication and Security Layer (SASL) is a framework for providing authentication and data security services in connection-oriented protocols via replaceable mechanisms. It provides a structured interface between protocols and mechanisms.The resulting framework allows new protocols to reuse existing mechanisms and allows old protocols to make use of new mechanisms.The framework also provides a protocol for securing subsequent protocol exchanges within a data security layer. This document describes how a SASL mechanism is structured, describes how protocols include support for SASL, and defines the protocol for carrying a data security layer over a connection. In addition, this document defines one SASL mechanism, the EXTERNAL mechanism. This document obsoletes RFC 2222.
RFC 4424	Real-Time Transport Protocol (RTP) Payload Format for the Variable-Rate Multimode Wideband (VMR-WB) Extension Audio Codec
	Authors: S. Ahmadi. Date: February 2006 Formats: txt pdf Updates: RFC 4348 Status: PROPOSED STANDARD This document is an addendum to RFC 4348, which specifies the RTP payload format for the Variable-Rate Multimode Wideband (VMR-WB) speech codec. This document specifies some updates in RFC 4348 to enable support for the new operating mode of VMR-WB standard (i.e.,VMR-WB mode 4). These updates do not affect the existing modes ofVMR-WB already specified in RFC 4348. The payload formats and their associated parameters, as well as all provisions, restrictions, use cases, features, etc., that are specified in RFC 4348 are applicable to the new operating mode with no exception.
RFC 4425	RTP Payload Format for Video Codec 1 (VC-1)
	Authors: A. Klemets. Date: February 2006 Formats: txt pdf Status: PROPOSED STANDARD This memo specifies an RTP payload format for encapsulating VideoCodec 1 (VC-1) compressed bit streams, as defined by the Society ofMotion Picture and Television Engineers (SMPTE) standard, SMPTE 421M.SMPTE is the main standardizing body in the motion imaging industry, and the SMPTE 421M standard defines a compressed video bit stream format and decoding process for television.
RFC 4426	Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification
	Authors: J. Lang, Ed., B. Rajagopalan, Ed., D. Papadimitriou, Ed.. Date: March 2006 Formats: txt pdf Status: PROPOSED STANDARD This document presents a functional description of the protocol extensions needed to support Generalized Multi-Protocol LabelSwitching (GMPLS)-based recovery (i.e., protection and restoration).Protocol specific formats and mechanisms will be described in companion documents.
RFC 4429	Optimistic Duplicate Address Detection (DAD) for IPv6
	Authors: N. Moore. Date: April 2006 Formats: txt pdf Status: PROPOSED STANDARD Optimistic Duplicate Address Detection is an interoperable modification of the existing IPv6 Neighbor Discovery (RFC 2461) andStateless Address Autoconfiguration (RFC 2462) processes. The intention is to minimize address configuration delays in the successful case, to reduce disruption as far as possible in the failure case, and to remain interoperable with unmodified hosts and routers.
RFC 4430	Kerberized Internet Negotiation of Keys (KINK)
	Authors: S. Sakane, K. Kamada, M. Thomas, J. Vilhuber. Date: March 2006 Formats: txt pdf Status: PROPOSED STANDARD This document describes the Kerberized Internet Negotiation of Keys(KINK) protocol. KINK defines a low-latency, computationally inexpensive, easily managed, and cryptographically sound protocol to establish and maintain security associations using the Kerberos authentication system. KINK reuses the Quick Mode payloads of theInternet Key Exchange (IKE), which should lead to substantial reuse of existing IKE implementations.
RFC 4432	RSA Key Exchange for the Secure Shell (SSH) Transport Layer Protocol
	Authors: B. Harris. Date: March 2006 Formats: txt pdf Status: PROPOSED STANDARD This memo describes a key-exchange method for the Secure Shell (SSH) protocol based on Rivest-Shamir-Adleman (RSA) public-key encryption.It uses much less client CPU time than the Diffie-Hellman algorithm specified as part of the core protocol, and hence is particularly suitable for slow client systems.
RFC 4433	Mobile IPv4 Dynamic Home Agent (HA) Assignment
	Authors: M. Kulkarni, A. Patel, K. Leung. Date: March 2006 Formats: txt pdf Status: PROPOSED STANDARD Mobile IPv4 (RFC 3344) uses the home agent (HA) to anchor sessions of a roaming mobile node (MN). This document proposes a messaging mechanism for dynamic home agent assignment and HA redirection. The goal is to provide a mechanism to assign an optimal HA for a MobileIP session while allowing any suitable method for HA selection.
RFC 4434	The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE)
	Authors: P. Hoffman. Date: February 2006 Formats: txt pdf Obsoletes: RFC 3664 Status: PROPOSED STANDARD Some implementations of IP Security (IPsec) may want to use a pseudo-random function derived from the Advanced Encryption Standard(AES). This document describes such an algorithm, calledAES-XCBC-PRF-128.
RFC 4436	Detecting Network Attachment in IPv4 (DNAv4)
	Authors: B. Aboba, J. Carlson, S. Cheshire. Date: March 2006 Formats: txt pdf Status: PROPOSED STANDARD The time required to detect movement between networks and to obtain(or to continue to use) an IPv4 configuration may be significant as a fraction of the total handover latency in moving between points of attachment. This document synthesizes, from experience in the deployment of hosts supporting ARP, DHCP, and IPv4 Link-Local addresses, a set of steps known as Detecting Network Attachment forIPv4 (DNAv4), in order to decrease the handover latency in moving between points of attachment.
RFC 4438	Fibre-Channel Name Server MIB
	Authors: C. DeSanti, V. Gaonkar, H.K. Vivek, K. McCloghrie, S. Gai. Date: April 2006 Formats: txt pdf Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes managed objects for information related to the Name Server function of a Fibre Channel network. The FibreChannel Name Server provides a means for Fibre Channel ports to register and discover Fibre Channel names and attributes.
RFC 4439	Fibre Channel Fabric Address Manager MIB
	Authors: C. DeSanti, V. Gaonkar, K. McCloghrie, S. Gai. Date: March 2006 Formats: txt pdf Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes managed objects for information related to a Fibre Channel network's Fabric Address Manager.
RFC 4442	Bootstrapping Timed Efficient Stream Loss-Tolerant Authentication (TESLA)
	Authors: S. Fries, H. Tschofenig. Date: March 2006 Formats: txt pdf Status: PROPOSED STANDARD TESLA, the Timed Efficient Stream Loss-tolerant Authentication protocol, provides source authentication in multicast scenarios.TESLA is an efficient protocol with low communication and computation overhead that scales to large numbers of receivers and also tolerates packet loss. TESLA is based on loose time synchronization between the sender and the receivers. Source authentication is realized inTESLA by using Message Authentication Code (MAC) chaining. The use of TESLA within the Secure Real-time Transport Protocol (SRTP) has been published, targeting multicast authentication in scenarios whereSRTP is applied to protect the multimedia data. This solution assumes that TESLA parameters are made available by out-of-band mechanisms. This document specifies payloads for the Multimedia Internet Keying(MIKEY) protocol for bootstrapping TESLA for source authentication of secure group communications using SRTP. TESLA may be bootstrapped using one of the MIKEY key management approaches, e.g., by using a digitally signed MIKEY message sent via unicast, multicast, or broadcast.
RFC 4444	Management Information Base for Intermediate System to Intermediate System (IS-IS)
	Authors: J. Parker, Ed.. Date: April 2006 Formats: txt pdf Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.Specifically, this document describes a MIB for the IntermediateSystem to Intermediate System (IS-IS) Routing protocol when it is used to construct routing tables for IP networks.
RFC 4447	Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)
	Authors: L. Martini, Ed., E. Rosen, N. El-Aawar, T. Smith, G. Heron. Date: April 2006 Formats: txt pdf Status: PROPOSED STANDARD Layer 2 services (such as Frame Relay, Asynchronous Transfer Mode, and Ethernet) can be "emulated" over an MPLS backbone by encapsulating the Layer 2 Protocol Data Units (PDU) and transmitting them over "pseudowires". It is also possible to use pseudowires to provide low-rate Time Division Multiplexed and a Synchronous OpticalNETworking circuit emulation over an MPLS-enabled network. This document specifies a protocol for establishing and maintaining the pseudowires, using extensions to Label Distribution Protocol (LDP).Procedures for encapsulating Layer 2 PDUs are specified in a set of companion documents.
RFC 4448	Encapsulation Methods for Transport of Ethernet over MPLS Networks
	Authors: L. Martini, Ed., E. Rosen, N. El-Aawar, G. Heron. Date: April 2006 Formats: txt pdf Updated by: RFC 5462 Status: PROPOSED STANDARD An Ethernet pseudowire (PW) is used to carry Ethernet/802.3 ProtocolData Units (PDUs) over an MPLS network. This enables service providers to offer "emulated" Ethernet services over existing MPLS networks. This document specifies the encapsulation ofEthernet/802.3 PDUs within a pseudowire. It also specifies the procedures for using a PW to provide a "point-to-point Ethernet" service.
RFC 4449	Securing Mobile IPv6 Route Optimization Using a Static Shared Key
	Authors: C. Perkins. Date: June 2006 Formats: txt pdf Status: PROPOSED STANDARD A mobile node and a correspondent node may preconfigure data useful for precomputing a Binding Management Key that can subsequently be used for authorizing Binding Updates.
RFC 4454	Asynchronous Transfer Mode (ATM) over Layer 2 Tunneling Protocol Version 3 (L2TPv3)
	Authors: S. Singh, M. Townsley, C. Pignataro. Date: May 2006 Formats: txt pdf Updated by: RFC 5641 Status: PROPOSED STANDARD The Layer 2 Tunneling Protocol, Version 3 (L2TPv3) defines an extensible tunneling protocol to transport layer 2 services over IP networks. This document describes the specifics of how to use theL2TP control plane for Asynchronous Transfer Mode (ATM) Pseudowires and provides guidelines for transporting various ATM services over anIP network.
RFC 4455	Definition of Managed Objects for Small Computer System Interface (SCSI) Entities
	Authors: M. Hallak-Stamler, M. Bakke, Y. Lederman, M. Krueger, K. McCloghrie. Date: April 2006 Formats: txt pdf Status: PROPOSED STANDARD This memo defines a portion of the Management Information Base (MIB), for use with network management protocols in the Internet community.In particular, it describes managed objects for Small Computer SystemInterface (SCSI) entities, independently of the interconnect subsystem layer.
RFC 4462	Generic Security Service Application Program Interface (GSS-API) Authentication and Key Exchange for the Secure Shell (SSH) Protocol
	Authors: J. Hutzelman, J. Salowey, J. Galbraith, V. Welch. Date: May 2006 Formats: txt pdf Status: PROPOSED STANDARD The Secure Shell protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network. The Generic Security Service Application Program Interface (GSS-API) provides security services to callers in a mechanism-independent fashion. This memo describes methods for using the GSS-API for authentication and key exchange in SSH. It defines an SSH user authentication method that uses a specified GSS-API mechanism to authenticate a user, and a family of SSH key exchange methods that use GSS-API to authenticate a Diffie-Hellman key exchange. This memo also defines a new host public key algorithm that can be used when no operations are needed using a host's public key, and a new user authentication method that allows an authorization name to be used in conjunction with any authentication that has already occurred as a side-effect of GSS-API-based key exchange.
RFC 4466	Collected Extensions to IMAP4 ABNF
	Authors: A. Melnikov, C. Daboo. Date: April 2006 Formats: txt pdf Updates: RFC 2088, RFC 2342, RFC 3501, RFC 3502, RFC 3516 Updated by: RFC 6237 Status: PROPOSED STANDARD Over the years, many documents from IMAPEXT and LEMONADE working groups, as well as many individual documents, have added syntactic extensions to many base IMAP commands described in RFC 3501. For ease of reference, this document collects most of such ABNF changes in one place. This document also suggests a set of standard patterns for adding options and extensions to several existing IMAP commands defined inRFC 3501. The patterns provide for compatibility between existing and future extensions. This document updates ABNF in RFCs 2088, 2342, 3501, 3502, and 3516.It also includes part of the errata to RFC 3501. This document doesn't specify any semantic changes to the listed RFCs.
RFC 4467	Internet Message Access Protocol (IMAP) - URLAUTH Extension
	Authors: M. Crispin. Date: May 2006 Formats: txt pdf Updated by: RFC 5092, RFC 5550 Status: PROPOSED STANDARD This document describes the URLAUTH extension to the Internet MessageAccess Protocol (IMAP) (RFC 3501) and the IMAP URL Scheme (IMAPURL)(RFC 2192). This extension provides a means by which an IMAP client can use URLs carrying authorization to access limited message data on the IMAP server. An IMAP server that supports this extension indicates this with a capability name of "URLAUTH".
RFC 4468	Message Submission BURL Extension
	Authors: C. Newman. Date: May 2006 Formats: txt pdf Updates: RFC 3463 Updated by: RFC 5248 Status: PROPOSED STANDARD The submission profile of Simple Mail Transfer Protocol (SMTP) provides a standard way for an email client to submit a complete message for delivery. This specification extends the submission profile by adding a new BURL command that can be used to fetch submission data from an Internet Message Access Protocol (IMAP) server. This permits a mail client to inject content from an IMAP server into the SMTP infrastructure without downloading it to the client and uploading it back to the server.
RFC 4469	Internet Message Access Protocol (IMAP) CATENATE Extension
	Authors: P. Resnick. Date: April 2006 Formats: txt pdf Updates: RFC 3501, RFC 3502 Updated by: RFC 5550 Status: PROPOSED STANDARD The CATENATE extension to the Internet Message Access Protocol (IMAP) extends the APPEND command to allow clients to create messages on theIMAP server that may contain a combination of new data along with parts of (or entire) messages already on the server. Using this extension, the client can catenate parts of an already existing message onto a new message without having to first download the data and then upload it back to the server.
RFC 4470	Minimally Covering NSEC Records and DNSSEC On-line Signing
	Authors: S. Weiler, J. Ihren. Date: April 2006 Formats: txt pdf Updates: RFC 4035, RFC 4034 Status: PROPOSED STANDARD This document describes how to construct DNSSEC NSEC resource records that cover a smaller range of names than called for by RFC 4034. By generating and signing these records on demand, authoritative name servers can effectively stop the disclosure of zone contents otherwise made possible by walking the chain of NSEC records in a signed zone.
RFC 4474	Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)
	Authors: J. Peterson, C. Jennings. Date: August 2006 Formats: txt pdf Status: PROPOSED STANDARD The existing security mechanisms in the Session Initiation Protocol(SIP) are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context. This document defines a mechanism for securely identifying originators of SIP messages. It does so by defining two new SIP header fields, Identity, for conveying a signature used for validating the identity, and Identity-Info, for conveying a reference to the certificate of the signer.
RFC 4476	Attribute Certificate (AC) Policies Extension
	Authors: C. Francis, D. Pinkas. Date: May 2006 Formats: txt pdf Status: PROPOSED STANDARD This document describes one certificate extension that explicitly states the Attribute Certificate Policies (ACPs) that apply to a given Attribute Certificate (AC). The goal of this document is to allow relying parties to perform an additional test when validating an AC, i.e., to assess whether a given AC carrying some attributes can be accepted on the basis of references to one or more specificACPs.
RFC 4479	A Data Model for Presence
	Authors: J. Rosenberg. Date: July 2006 Formats: txt pdf Status: PROPOSED STANDARD This document defines the underlying presence data model used bySession Initiation Protocol (SIP) for Instant Messaging and PresenceLeveraging Extensions (SIMPLE) presence agents. The data model provides guidance on how to map various communications systems into presence documents in a consistent fashion.
RFC 4480	RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)
	Authors: H. Schulzrinne, V. Gurbani, P. Kyzivat, J. Rosenberg. Date: July 2006 Formats: txt pdf Status: PROPOSED STANDARD The Presence Information Data Format (PIDF) defines a basic format for representing presence information for a presentity. This format defines a textual note, an indication of availability (open or closed) and a Uniform Resource Identifier (URI) for communication.The Rich Presence Information Data format (RPID) described here is an extension that adds optional elements to the Presence InformationData Format (PIDF). These extensions provide additional information about the presentity and its contacts. The information is designed so that much of it can be derived automatically, e.g., from calendar files or user activity. This extension includes information about what the person is doing, a grouping identifier for a tuple, when a service or device was last used, the type of place a person is in, what media communications might remain private, the relationship of a service tuple to another presentity, the person's mood, the time zone it is located in, the type of service it offers, an icon reflecting the presentity's status, and the overall role of the presentity. These extensions include presence information for persons, services(tuples), and devices.
RFC 4481	Timed Presence Extensions to the Presence Information Data Format (PIDF) to Indicate Status Information for Past and Future Time Intervals
	Authors: H. Schulzrinne. Date: July 2006 Formats: txt pdf Status: PROPOSED STANDARD The Presence Information Data Format (PIDF) defines a basic XML format for presenting presence information for a presentity. This document extends PIDF, adding a timed status extension(<timed-status&rt; element) that allows a presentity to declare its status for a time interval fully in the future or the past.
RFC 4482	CIPID: Contact Information for the Presence Information Data Format
	Authors: H. Schulzrinne. Date: July 2006 Formats: txt pdf Status: PROPOSED STANDARD The Presence Information Data Format (PIDF) defines a basic XML format for presenting presence information for a presentity. TheContact Information for the Presence Information Data format (CIPID) is an extension that adds elements to PIDF that provide additional contact information about a presentity and its contacts, including references to address book entries and icons.
RFC 4483	A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages
	Authors: E. Burger, Ed.. Date: May 2006 Formats: txt pdf Status: PROPOSED STANDARD This document defines an extension to the URL MIME External-BodyAccess-Type to satisfy the content indirection requirements for theSession Initiation Protocol (SIP). These extensions are aimed at allowing any MIME part in a SIP message to be referred to indirectly via a URI.
RFC 4486	Subcodes for BGP Cease Notification Message
	Authors: E. Chen, V. Gillet. Date: April 2006 Formats: txt pdf Status: PROPOSED STANDARD This document defines several subcodes for the BGP Cease NOTIFICATION message that would provide more information to aid network operators in correlating network events and diagnosing BGP peering issues.
RFC 4488	Suppression of Session Initiation Protocol (SIP) REFER Method Implicit Subscription
	Authors: O. Levin. Date: May 2006 Formats: txt pdf Status: PROPOSED STANDARD The Session Initiation Protocol (SIP) REFER extension as defined inRFC 3515 automatically establishes a typically short-lived event subscription used to notify the party sending a REFER request about the receiver's status in executing the transaction requested by theREFER. These notifications are not needed in all cases. This specification provides a way to prevent the automatic establishment of an event subscription and subsequent notifications using a new SIP extension header field that may be included in a REFER request.
RFC 4489	A Method for Generating Link-Scoped IPv6 Multicast Addresses
	Authors: J-S. Park, M-K. Shin, H-J. Kim. Date: April 2006 Formats: txt pdf Updates: RFC 3306 Status: PROPOSED STANDARD This document specifies an extension to the multicast addressing architecture of the IPv6 protocol. The extension allows the use ofInterface Identifiers (IIDs) to allocate multicast addresses. When a link-local unicast address is configured at each interface of a node, an IID is uniquely determined. After that, each node can generate its unique multicast addresses automatically without conflicts. The alternative method for creating link-local multicast addresses proposed in this document is better than known methods like unicast- prefix-based IPv6 multicast addresses. This memo updates RFC 3306.
RFC 4490	Using the GOST 28147-89, GOST R 34.11-94, GOST R 34.10-94, and GOST R 34.10-2001 Algorithms with Cryptographic Message Syntax (CMS)
	Authors: S. Leontiev, Ed., G. Chudov, Ed.. Date: May 2006 Formats: txt pdf Status: PROPOSED STANDARD This document describes the conventions for using the cryptographic algorithms GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, andGOST R 34.11-94 with the Cryptographic Message Syntax (CMS). The CMS is used for digital signature, digest, authentication, and encryption of arbitrary message contents.
RFC 4491	Using the GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms with the Internet X.509 Public Key Infrastructure Certificate and CRL Profile
	Authors: S. Leontiev, Ed., D. Shefanovski, Ed.. Date: May 2006 Formats: txt pdf