| |
| RFC 698 | Telnet extended ASCII option |
| |
|
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 0726 |
|
|
|
| |
| RFC 727 | Telnet logout option |
| |
| Authors: | M.R. Crispin. |
| Date: | April 1977 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 0727 |
|
|
|
| |
| RFC 735 | Revised Telnet byte macro option |
| |
| Authors: | D. Crocker, R.H. Gumpertz. |
| Date: | November 1977 |
| Formats: | txt json html |
| Obsoletes: | RFC 0729 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 0735 |
|
|
|
| |
| RFC 736 | Telnet SUPDUP option |
| |
| Authors: | M.R. Crispin. |
| Date: | October 1977 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 0736 |
|
|
|
| |
| RFC 749 | Telnet SUPDUP-Output option |
| |
| Authors: | B. Greenberg. |
| Date: | September 1978 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 0749 |
|
|
|
| |
| RFC 779 | Telnet send-location option |
| |
| Authors: | E. Killian. |
| Date: | April 1981 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 0779 |
|
|
|
| |
| RFC 885 | Telnet end of record option |
| |
| Authors: | J. Postel. |
| Date: | December 1983 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 0885 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 0927 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 0933 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 0946 |
|
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 html json |
| Obsoleted by: | RFC 3977 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 0977 |
|
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 1043 | Telnet Data Entry Terminal option: DODIIS implementation |
| |
| Authors: | A. Yasuda, T. Thompson. |
| Date: | February 1988 |
| Formats: | txt html json |
| Updates: | RFC 0732 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1043 |
|
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 1073 | Telnet window size option |
| |
| Authors: | D. Waitzman. |
| Date: | October 1988 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1073 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1079 |
|
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 |
| |
|
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1096 |
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
| |
| RFC 1233 | Definitions of managed objects for the DS3 Interface type |
| |
|
|
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 |
| |
|
|
This paper provides guidelines for allocating NSAPs in the Internet.[STANDARDS-TRACK] |
|
| |
| RFC 1243 | AppleTalk Management Information Base |
| |
|
|
This memo defines objects for managing AppleTalk objects for use with the SNMP protocol. [STANDARDS-TRACK] |
|
| |
| RFC 1248 | OSPF Version 2 Management Information Base |
| |
|
|
This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing OSPF Version 2. [STANDARDS-TRACK] |
|
| |
| RFC 1252 | OSPF Version 2 Management Information Base |
| |
|
|
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 |
| |
|
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1256 |
|
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 json html |
| Obsoleted by: | RFC 4273 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1269 |
|
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 |
| |
|
|
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 json html |
| Obsoleted by: | RFC 4524 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1274 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1277 |
|
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 |
| |
|
|
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 html json |
| Obsoleted by: | RFC 1493, RFC 1525 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1286 |
|
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 |
| |
|
|
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 html json |
| Obsoleted by: | RFC 2390 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1293 |
|
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 |
| |
|
|
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, Ed., K. Tesink, Ed.. |
| Date: | February 1992 |
| Formats: | txt json html |
| Obsoleted by: | RFC 1694 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1304 |
|
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 json html |
| Obsoleted by: | RFC 2115 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1315 |
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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) |
| |
|
|
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 |
| |
|
|
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 json html |
| Obsoleted by: | RFC 1994 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1334 |
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 html json |
| Obsoleted by: | RFC 1516 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1368 |
|
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 json html |
| Obsoletes: | RFC 1080 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1372 |
|
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 html json |
| Obsoleted by: | RFC 2834 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1374 |
|
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) |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1377 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1381 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1382 |
|
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 |
| |
|
|
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 html json |
| Obsoleted by: | RFC 1724 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1389 |
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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, N. Freed, Ed., M. Rose, E. Stefferud, D. Crocker. |
| Date: | February 1993 |
| Formats: | txt html json |
| Obsoleted by: | RFC 1651 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1425 |
|
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, N. Freed, Ed., M. Rose, E. Stefferud, D. Crocker. |
| Date: | February 1993 |
| Formats: | txt json html |
| Obsoleted by: | RFC 1652 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1426 |
|
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, N. Freed, Ed., K. Moore. |
| Date: | February 1993 |
| Formats: | txt json html |
| Obsoleted by: | RFC 1653 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1427 |
|
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 html json |
| Obsoleted by: | RFC 1902 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1442 |
|
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 html json |
| Obsoleted by: | RFC 1903 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1443 |
|
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 json html |
| Obsoleted by: | RFC 1904 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1444 |
|
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 json html |
| Obsoleted by: | RFC 1905 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1448 |
|
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 json html |
| Obsoleted by: | RFC 1906 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1449 |
|
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 json html |
| Obsoleted by: | RFC 1907 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1450 |
|
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 html json |
| Obsoleted by: | RFC 1908 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1452 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1471 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1472 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1473 |
|
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 |
| |
|
|
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 json html |
| Obsoleted by: | RFC 1778 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1488 |
|
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 json html |
| Obsoleted by: | RFC 2156 |
| Updates: | RFC 1327 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1495 |
|
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 |
| |
|
|
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 |
| |
|
|
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 1514 | Host Resources MIB |
| |
| Authors: | P. Grillo, S. Waldbusser. |
| Date: | September 1993 |
| Formats: | txt json html |
| Obsoleted by: | RFC 2790 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1514 |
|
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 json html |
| Obsoleted by: | RFC 3636 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1515 |
|
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 json html |
| Obsoletes: | RFC 1338 |
| Obsoleted by: | RFC 4632 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1519 |
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 html json |
| Obsoleted by: | RFC 2248 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1565 |
|
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 |
| |
|
|
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 json html |
| Obsoleted by: | RFC 2605 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1567 |
|
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 |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1572 |
|
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 |
| |
|
|
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 |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1582 |
|
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 json html |
| Obsoleted by: | RFC 3101 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1587 |
|
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 html json |
| Obsoleted by: | RFC 2558 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1595 |
|
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 |
| |
|
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1598 |
|
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 |
| |
|
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1618 |
|
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 |
| |
|
|
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 |
| |
|
|
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) |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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, Ed., T. Li, Ed.. |
| Date: | July 1994 |
| Formats: | txt json html |
| Obsoleted by: | RFC 1771 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1654 |
|
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 |
| |
|
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1663 |
|
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, Ed., D. Kostick, Ed., K. Shih, Ed.. |
| Date: | July 1994 |
| Formats: | txt json html |
| Obsoleted by: | RFC 1666 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1665 |
|
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, Ed., K. Tesink, Ed.. |
| Date: | August 1994 |
| Formats: | txt json html |
| Obsoleted by: | RFC 2515 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1695 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1697 |
|
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 html json |
| Obsoleted by: | RFC 1990 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1717 |
|
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 |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1731 |
|
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 |
| |
|
|
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) |
| |
|
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1740 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1752 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1755 |
|
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 html json |
| Obsoleted by: | RFC 3805 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1759 |
|
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 |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1767 |
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
This document describes a mechanism for providing cryptographic authentication for IPv4 and IPv6 datagrams. [STANDARDS-TRACK] |
|
| |
| RFC 1827 | IP Encapsulating Security Payload (ESP) |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1829 |
|
This document describes the DES-CBC security transform for the IPEncapsulating Security Payload (ESP). |
|
| |
| RFC 1831 | RPC: Remote Procedure Call Protocol Specification Version 2 |
| |
|
|
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 |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1847 |
|
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 |
| |
|
|
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 json html |
| Obsoleted by: | RFC 2460 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1883 |
|
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 html json |
| Obsoleted by: | RFC 2463 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1885 |
|
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 |
| |
|
|
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 html json |
| Obsoleted by: | RFC 3550 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1889 |
|
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 html json |
| Obsoleted by: | RFC 3551 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1890 |
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1928 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1929 |
|
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 json html |
| Obsoleted by: | RFC 2893 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1933 |
|
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 |
| |
|
|
This document describes a one-time password authentication system (OTP). [STANDARDS-TRACK] |
|
| |
| RFC 1959 | An LDAP URL Format |
| |
|
|
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 |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1961 |
|
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) |
| |
|
|
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 |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1968 |
|
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 json html |
| Obsoleted by: | RFC 2461 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1970 |
|
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 json html |
| Obsoleted by: | RFC 2462 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1971 |
|
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 |
| |
|
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1973 |
|
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 |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 1985 |
|
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 |
| |
|
|
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) |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2004 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2005 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2006 |
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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) |
| |
|
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2017 |
|
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 json html |
| Obsoletes: | RFC 1072 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2018 |
|
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 |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2020 |
|
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 |
| |
|
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2022 |
|
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 html json |
| Obsoleted by: | RFC 2472 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2023 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2024 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2025 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2029 |
|
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 html json |
| Obsoleted by: | RFC 4587 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2032 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2034 |
|
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 json html |
| Obsoleted by: | RFC 2435 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2035 |
|
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 html json |
| Obsoleted by: | RFC 2737 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2037 |
|
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 json html |
| Obsoleted by: | RFC 2250 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2038 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2043 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2051 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2056 |
|
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 html json |
| Obsoleted by: | RFC 2138 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2058 |
|
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 |
| |
|
|
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 |
| |
|
|
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 html json |
| Obsoleted by: | RFC 2616 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2068 |
|
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 html json |
| Obsoleted by: | RFC 2617 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2069 |
|
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 json html |
| Obsoleted by: | RFC 2374 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2073 |
|
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 html json |
| Obsoleted by: | RFC 2895 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2074 |
|
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 json html |
| Updated by: | RFC 9141 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2077 |
|
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 |
| |
|
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2079 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2080 |
|
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 json html |
| Obsoleted by: | RFC 4822 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2082 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2085 |
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2091 |
|
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 html json |
| Obsoleted by: | RFC 2195 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2095 |
|
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 |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2097 |
|
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 html json |
| Obsoletes: | RFC 1516 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2108 |
|
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 html json |
| Obsoleted by: | RFC 2557 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2110 |
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2122 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2125 |
|
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) |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2127 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2128 |
|
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) |
| |
|
|
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 |
| |
|
|
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 html json |
| Obsoletes: | RFC 2058 |
| Obsoleted by: | RFC 2865 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2138 |
|
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 |
| |
|
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2142 |
|
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 |
| |
|
|
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 json html |
| Obsoleted by: | RFC 2455 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2155 |
|
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 |
| |
|
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2157 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2158 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2159 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2160 |
|
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) |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2177 |
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
This memo defines extensions to the RFC 2045 media type and RFC 2183 disposition parameter value mechanisms. [STANDARDS-TRACK] |
|
| |
| RFC 2192 | IMAP URL Scheme |
| |
|
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2193 |
|
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 json html |
| Obsoletes: | RFC 2095 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2195 |
|
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 json html |
| Updated by: | RFC 6354 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2198 |
|
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 html json |
| Updated by: | RFC 5403 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2203 |
|
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 json html |
| Updated by: | RFC 2750, RFC 3936, RFC 4495, RFC 5946, RFC 6437, RFC 6780 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2205 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2206 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2207 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2210 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2211 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2212 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2213 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2214 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2215 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2218 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2221 |
|
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) |
| |
|
|
This document describes a method for adding authentication support to connection-based protocols. [STANDARDS-TRACK] |
|
| |
| RFC 2225 | Classical IP and ARP over ATM |
| |
|
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2226 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2227 |
|
This document proposes a simple extension to HTTP, using a new "Meter" header. [STANDARDS-TRACK] |
|
| |
| RFC 2228 | FTP Security Extensions |
| |
|
|
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 |
| |
|
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2232 |
|
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 |
| |
|
|
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 json html |
| Obsoleted by: | RFC 4234 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2234 |
|
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 |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2238 |
|
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 json html |
| Obsoleted by: | RFC 2668 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2239 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2241 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2242 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2243 |
|
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 html json |
| Updated by: | RFC 6075 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2244 |
|
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 |
| |
|
|
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 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 json html |
| Updated by: | RFC 4519, RFC 4524 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2247 |
|
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 |
| |
|
|
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 |
| |
|
|
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 html json |
| Obsoletes: | RFC 2038 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2250 |
|
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) |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
This document defines a human-readable string format for representing LDAP search filters. [STANDARDS-TRACK] |
|
| |
| RFC 2255 | The LDAP URL Format |
| |
|
|
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 |
| |
|
|
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 json html |
| Obsoleted by: | RFC 2741 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2257 |
|
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 html json |
| Obsoleted by: | RFC 2271 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2261 |
|
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 json html |
| Obsoleted by: | RFC 2272 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2262 |
|
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 json html |
| Obsoleted by: | RFC 2273 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2263 |
|
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 html json |
| Obsoleted by: | RFC 2274 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2264 |
|
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 html json |
| Obsoleted by: | RFC 2275 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2265 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2266 |
|
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 |
| |
|
|
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 json html |
| Obsoletes: | RFC 2262 |
| Obsoleted by: | RFC 2572 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2272 |
|
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 |
| |
|
|
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) |
| |
|
|
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) |
| |
|
|
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 html json |
| Obsoleted by: | RFC 2622 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2280 |
|
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 json html |
| Obsoleted by: | RFC 2858 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2283 |
|
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) |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2287 |
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 html json |
| Obsoleted by: | RFC 3949 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2301 |
|
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 json html |
| Obsoleted by: | RFC 3302 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2302 |
|
This document describes the registration of the MIME sub-type image/tiff. [STANDARDS-TRACK] |
|
| |
| RFC 2303 | Minimal PSTN address format in Internet Mail |
| |
|
|
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 |
| |
|
|
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 html json |
| Obsoleted by: | RFC 3965 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2305 |
|
This specification provides for "simple mode" carriage of facsimile data over the Internet. [STANDARDS-TRACK] |
|
| |
| RFC 2308 | Negative Caching of DNS Queries (DNS NCACHE) |
| |
|
|
[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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2320 |
|
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 json html |
| Obsoleted by: | RFC 7826 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2326 |
|
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 |
| |
|
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2331 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2332 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2333 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2334 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2335 |
|
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 html json |
| Obsoleted by: | RFC 3768 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2338 |
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2363 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2364 |
|
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 |
| |
|
|
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 |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2369 |
|
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 |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2371 |
|
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 |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2380 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2381 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2384 |
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 html json |
| Obsoleted by: | RFC 3173 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2393 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2397 |
|
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 |
| |
|
|
This memo specifies the base architecture for IPsec compliant systems. [STANDARDS-TRACK] |
|
| |
| RFC 2402 | IP Authentication Header |
| |
|
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2403 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2404 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2405 |
|
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) |
| |
|
|
The Encapsulating Security Payload (ESP) header is designed to provide a mix of security services in IPv4 and IPv6. [STANDARDS-TRACK] |
|
| |
| RFC 2410 | The NULL Encryption Algorithm and Its Use With IPsec |
| |
| Authors: | R. Glenn, S. Kent. |
| Date: | November 1998 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2410 |
|
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 html json |
| Obsoletes: | RFC 2366 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2417 |
|
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 json html |
| Obsoletes: | RFC 1969 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2419 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2420 |
|
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 |
| |
|
|
This document profiles Internet mail for voice messaging. [STANDARDS- TRACK] |
|
| |
| RFC 2422 | Toll Quality Voice - 32 kbit/s ADPCM MIME Sub-type Registration |
| |
|
|
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 |
| |
|
|
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 json html |
| Obsoleted by: | RFC 3803 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2424 |
|
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 json html |
| Obsoleted by: | RFC 6350 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2425 |
|
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 html json |
| Obsoleted by: | RFC 6350 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2426 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2428 |
|
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 json html |
| Obsoleted by: | RFC 4629 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2429 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2431 |
|
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 json html |
| Obsoletes: | RFC 2035 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2435 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2439 |
|
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 html json |
| Obsoleted by: | RFC 4880 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2440 |
|
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 |
| |
|
|
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 html json |
| Obsoleted by: | RFC 5545 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2445 |
|
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 json html |
| Obsoleted by: | RFC 5546 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2446 |
|
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 json html |
| Obsoleted by: | RFC 6047 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2447 |
|
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 |
| |
|
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2451 |
|
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 2455 | Definitions of Managed Objects for APPN |
| |
| Authors: | B. Clouston, B. Moore. |
| Date: | November 1998 |
| Formats: | txt html json |
| Obsoletes: | RFC 2155 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2455 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2456 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2457 |
|
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 html json |
| Obsoleted by: | RFC 3280 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2459 |
|
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 |
| |
|
|
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 2467 | Transmission of IPv6 Packets over FDDI Networks |
| |
|
|
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 html json |
| Updated by: | RFC 8064 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2470 |
|
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 |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2473 |
|
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 |
| |
|
|
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 json html |
| Obsoleted by: | RFC 4409 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2476 |
|
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 html json |
| Obsoleted by: | RFC 4178 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2478 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2480 |
|
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 |
| |
|
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2485 |
|
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 json html |
| Obsoleted by: | RFC 4282 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2486 |
|
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 |
| |
|
|
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 html json |
| Updated by: | RFC 8064 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2491 |
|
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 json html |
| Updated by: | RFC 8064 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2492 |
|
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 |
| |
|
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2494 |
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2507 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2508 |
|
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 html json |
| Obsoleted by: | RFC 3544 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2509 |
|
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 html json |
| Obsoleted by: | RFC 4210 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2510 |
|
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 html json |
| Obsoleted by: | RFC 4211 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2511 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2512 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2513 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2514 |
|
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 |
| |
|
|
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 html json |
| Obsoleted by: | RFC 4918 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2518 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2526 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2529 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2530 |
|
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 html json |
| Obsoleted by: | RFC 2879 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2531 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2532 |
|
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 |
| |
|
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2534 |
|
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 html json |
| 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 |
| DOI: | 10.17487/RFC 2535 |
|
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) |
| |
|
|
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) |
| |
|
|
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 html json |
| Obsoleted by: | RFC 4398 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2538 |
|
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) |
| |
|
|
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 |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2545 |
|
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 |
| |
|
|
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 html json |
| Obsoletes: | RFC 2110 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2557 |
|
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 |
| |
|
|
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 json html |
| Obsoleted by: | RFC 6960 |
| Updated by: | RFC 6277 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2560 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2561 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2562 |
|
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 |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2564 |
|
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 |
| |
|
|
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 |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2584 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2585 |
|
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 html json |
| Obsoleted by: | RFC 4523 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2587 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2589 |
|
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 json html |
| Updated by: | RFC 8064 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2590 |
|
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 json html |
| Obsoleted by: | RFC 3231 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2591 |
|
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 html json |
| Obsoleted by: | RFC 3165 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2592 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2594 |
|
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 |
| |
|
|
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 |
| |
|
|
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 html json |
| Updated by: | RFC 3260 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2597 |
|
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 json html |
| Obsoleted by: | RFC 3246 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2598 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2601 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2602 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2603 |
|
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 |
| |
|
|
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 |
| |
|
|
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 json html |
| Updates: | RFC 2165 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2609 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2610 |
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 html json |
| Obsoletes: | RFC 2280 |
| Updated by: | RFC 4012, RFC 7909 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2622 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2623 |
|
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 json html |
| Obsoleted by: | RFC 4338 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2625 |
|
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 |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2631 |
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
This document describes four optional security service extensions for S/MIME. [STANDARDS-TRACK] |
|
| |
| RFC 2640 | Internationalization of the File Transfer Protocol |
| |
|
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2645 |
|
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 |
| |
|
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2651 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2652 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2653 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2658 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2661 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2662 |
|
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 |
| |
|
|
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 |
| |
|
|
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 html json |
| Obsoletes: | RFC 2239 |
| Obsoleted by: | RFC 3636 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2668 |
|
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 |
| |
|
|
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 |
| |
|
|
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) |
| |
|
|
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 |
| |
|
|
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 html json |
| Obsoleted by: | RFC 4363 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2674 |
|
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 html json |
| Obsoletes: | RFC 2147 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2675 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2677 |
|
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 html json |
| Obsoletes: | RFC 2498 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2678 |
|
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 html json |
| Obsoleted by: | RFC 7679 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2679 |
|
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 html json |
| Obsoleted by: | RFC 7680 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2680 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2681 |
|
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 html json |
| Obsoletes: | RFC 1483 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2684 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2685 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2686 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2687 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2688 |
|
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 |
| |
|
|
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 html json |
| Updated by: | RFC 6398 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2711 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2712 |
|
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 |
| |
|
|
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 html json |
| Updated by: | RFC 4012 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2725 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2726 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2728 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2730 |
|
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 |
| |
|
|
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 json html |
| Obsoleted by: | RFC 5109 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2733 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2734 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2735 |
|
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) |
| |
|
|
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" |
| |
|
|
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 html json |
| Updated by: | RFC 6350 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2739 |
|
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 json html |
| Obsoleted by: | RFC 5340 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2740 |
|
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 |
| |
|
|
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 |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2745 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2746 |
|
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 html json |
| Updated by: | RFC 3097 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2747 |
|
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 json html |
| Updated by: | RFC 4261 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2748 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2749 |
|
This document describes usage directives for supporting COPS policy services in RSVP environments. |
|
| |
| RFC 2750 | RSVP Extensions for Policy Control |
| |
|
|
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 |
| |
|
|
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 html json |
| Obsoleted by: | RFC 3182 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2752 |
|
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) |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2769 |
|
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) |
| |
|
|
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 json html |
| Updated by: | RFC 2890 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2784 |
|
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 html json |
| Obsoleted by: | RFC 6527 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2787 |
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 html json |
| Obsoleted by: | RFC 5272 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2797 |
|
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 |
| |
|
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2814 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2815 |
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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) |
| |
|
|
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 json html |
| Obsoleted by: | RFC 3140 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2836 |
|
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 |
| |
|
|
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 html json |
| Obsoleted by: | RFC 3392 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2842 |
|
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) |
| |
|
|
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 |
| |
|
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2847 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2848 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2849 |
|
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 json html |
| Obsoleted by: | RFC 3291 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2851 |
|
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 |
| |
|
|
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 html json |
| Obsoleted by: | RFC 5653 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2853 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2855 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2856 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2857 |
|
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 json html |
| Obsoletes: | RFC 2283 |
| Obsoleted by: | RFC 4760 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2858 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2862 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2864 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2872 |
|
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 html json |
| Obsoleted by: | RFC 9293 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2873 |
|
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 json html |
| Obsoleted by: | RFC 6955 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2875 |
|
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) |
| |
|
|
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 json html |
| Obsoletes: | RFC 2531 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2879 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2883 |
|
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 |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2891 |
|
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 |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2894 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2907 |
|
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 json html |
| Obsoletes: | RFC 2565 |
| Obsoleted by: | RFC 8010 |
| Updated by: | RFC 3380, RFC 3381, RFC 3382, RFC 3510, RFC 3995, RFC 7472 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2910 |
|
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 |
| |
|
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2912 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2913 |
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2919 |
|
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 |
| |
|
|
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) |
| |
|
|
[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 ) |
| |
|
|
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 html json |
| Obsoleted by: | RFC 5132 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2932 |
|
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 html json |
| Obsoleted by: | RFC 5519 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2933 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2935 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2937 |
|
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 json html |
| Updates: | RFC 2533 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2938 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2940 |
|
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 html json |
| Obsoletes: | RFC 1416 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2941 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2942 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2943 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2944 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2945 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2946 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2947 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2948 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2949 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2950 |
|
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 |
| |
|
|
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 html json |
| Updated by: | RFC 9141 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2955 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2959 |
|
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 html json |
| Obsoleted by: | RFC 4960 |
| Updated by: | RFC 3309 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2960 |
|
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 html json |
| Updated by: | RFC 5063 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2961 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2971 |
|
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 |
| |
|
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2981 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2982 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2984 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2987 |
|
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 html json |
| Obsoleted by: | RFC 6298 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2988 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2996 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 2997 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3003 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3004 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3006 |
|
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 |
| |
|
|
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 |
| |
|
|
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 json html |
| Obsoleted by: | RFC 5109 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3009 |
|
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 json html |
| Obsoleted by: | RFC 3530 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3010 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3011 |
|
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 html json |
| Obsoleted by: | RFC 4721 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3012 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3014 |
|
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 |
| |
|
|
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 html json |
| Obsoleted by: | RFC 6416 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3016 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3017 |
|
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 json html |
| Obsoleted by: | RFC 5519 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3019 |
|
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 json html |
| Updated by: | RFC 9141 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3020 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3021 |
|
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 |
| |
|
|
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 |
| |
|
|
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 json html |
| Obsoleted by: | RFC 3115 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3025 |
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 html json |
| Updated by: | RFC 3443, RFC 4182, RFC 5332, RFC 3270, RFC 5129, RFC 5462, RFC 5586, RFC 7274, RFC 9017 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3032 |
|
"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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3033 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3034 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3035 |
|
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 html json |
| Obsoleted by: | RFC 5036 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3036 |
|
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 json html |
| Updated by: | RFC 7274 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3038 |
|
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 json html |
| Obsoleted by: | RFC 3739 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3039 |
|
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 html json |
| Obsoleted by: | RFC 4941 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3041 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3042 |
|
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 |
| |
|
|
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 |
| |
|
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3049 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3055 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3056 |
|
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 json html |
| Obsoleted by: | RFC 4233 |
| Updated by: | RFC 3807 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3057 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3059 |
|
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 html json |
| Updated by: | RFC 3460 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3060 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3062 |
|
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 |
| |
|
|
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 3070 | Layer Two Tunneling Protocol (L2TP) over Frame Relay |
| |
| Authors: | V. Rawat, R. Tio, S. Nanji, R. Verma. |
| Date: | February 2001 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3070 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3074 |
|
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 html json |
| Obsoleted by: | RFC 3275 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3075 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3077 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3080 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3081 |
|
This memo describes how a BEEP (Blocks Extensible Exchange Protocol) session is mapped onto a single TCP (Transmission Control Protocol) connection. |
|
| |
| RFC 3090 | DNS Security Extension Clarification on Zone Status |
| |
|
|
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 html json |
| Updated by: | RFC 3759, RFC 4815 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3095 |
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3108 |
|
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) |
| |
|
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3111 |
|
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 |
| |
|
|
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, Ed., W. Arbaugh, Ed.. |
| Date: | June 2001 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3118 |
|
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 |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3122 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3124 |
|
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 json html |
| Obsoletes: | RFC 2836 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3140 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3144 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3145 |
|
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 html json |
| Updated by: | RFC 8064 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3146 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3153 |
|
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 html json |
| Updates: | RFC 2015 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3156 |
|
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 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 json html |
| Updated by: | RFC 5816 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3161 |
|
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 html json |
| Updated by: | RFC 8044 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3162 |
|
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 json html |
| Obsoletes: | RFC 2592 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3165 |
|
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 |
| |
|
|
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 html json |
| Obsoletes: | RFC 2393 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3173 |
|
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 json html |
| Updated by: | RFC 5350 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3175 |
|
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 |
| |
|
|
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 html json |
| Obsoletes: | RFC 2752 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3182 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3185 |
|
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 json html |
| Obsoleted by: | RFC 6469 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3189 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3190 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3193 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3195 |
|
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 json html |
| Updated by: | RFC 9141 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3201 |
|
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 html json |
| Updated by: | RFC 9141 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3202 |
|
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 html json |
| Updated by: | RFC 6704 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3203 |
|
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 json html |
| Updated by: | RFC 3459, RFC 5621 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3204 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3206 |
|
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 |
| |
|
|
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 json html |
| Updated by: | RFC 3936, RFC 4420, RFC 4874, RFC 5151, RFC 5420, RFC 5711, RFC 6780, RFC 6790, RFC 7274 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3209 |
|
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 |
| |
|
|
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 html json |
| Updated by: | RFC 3468, RFC 7358 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3212 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3214 |
|
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 json html |
| Updated by: | RFC 8602 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3219 |
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3229 |
|
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 json html |
| Obsoleted by: | RFC 9530 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3230 |
|
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 json html |
| Obsoletes: | RFC 2591 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3231 |
|
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 |
| |
|
|
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 json html |
| Obsoleted by: | RFC 4362 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3242 |
|
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 json html |
| Obsoletes: | RFC 2598 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3246 |
|
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 html json |
| Obsoleted by: | RFC 3950 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3250 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3253 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3255 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3256 |
|
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 html json |
| 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, RFC 6665, RFC 6878, RFC 7462, RFC 7463, RFC 8217, RFC 8591, RFC 8760, RFC 8898, RFC 8996 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3261 |
|
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 json html |
| Obsoletes: | RFC 2543 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3262 |
|
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 |
| |
|
|
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) |
| |
|
|
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 |
| |
|
|
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) |
| |
|
|
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 json html |
| Obsoleted by: | RFC 4867 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3267 |
|
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) |
| |
|
|
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, Ed., L. Wu, B. Davie, S. Davari, P. Vaananen, R. Krishnan, P. Cheval, J. Heinanen. |
| Date: | May 2002 |
| Formats: | txt html json |
| Updates: | RFC 3032 |
| Updated by: | RFC 5462 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3270 |
|
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 |
| |
|
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3274 |
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 html json |
| Obsoleted by: | RFC 5755 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3281 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3284 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3287 |
|
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 html json |
| Obsoleted by: | RFC 4227 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3288 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3289 |
|
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 html json |
| Obsoletes: | RFC 2851 |
| Obsoleted by: | RFC 4001 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3291 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3292 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3293 |
|
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 html json |
| Updated by: | RFC 9141 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3295 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3296 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3297 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3301 |
|
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 |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3307 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3308 |
|
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 |
| |
|
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3311 |
|
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) |
| |
|
|
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 html json |
| Obsoleted by: | RFC 8415 |
| Updated by: | RFC 4361, RFC 5494, RFC 6221, RFC 6422, RFC 6644, RFC 7083, RFC 7227, RFC 7283, RFC 7550 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3315 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3319 |
|
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 html json |
| Updated by: | RFC 4896 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3320 |
|
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 html json |
| Updated by: | RFC 4896 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3321 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3323 |
|
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) |
| |
|
|
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 json html |
| Updated by: | RFC 5626 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3327 |
|
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 html json |
| Updated by: | RFC 8996 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3329 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3331 |
|
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 json html |
| Obsoleted by: | RFC 4666 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3332 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3335 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3336 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3337 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3339 |
|
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 3344 | IP Mobility Support for IPv4 |
| |
|
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3347 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3355 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3361 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3362 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3367 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3368 |
|
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) |
| |
|
|
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 |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3371 |
|
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 html json |
| Updates: | RFC 2236 |
| Updated by: | RFC 4604 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3376 |
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 json html |
| Obsoleted by: | RFC 5888 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3388 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3389 |
|
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 |
| |
|
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3393 |
|
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 json html |
| Updates: | RFC 2895 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3395 |
|
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 html json |
| Updates: | RFC 2131 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3396 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3397 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3398 |
|
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 |
| |
|
|
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 |
| |
|
|
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) |
| |
|
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3407 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3408 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3419 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3420 |
|
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 |
| |
|
|
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 json html |
| Updated by: | RFC 8591 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3428 |
|
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 |
| |
|
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3432 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3433 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3434 |
|
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 html json |
| Updated by: | RFC 8996 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3436 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3437 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3440 |
|
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 json html |
| Updates: | RFC 2132 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3442 |
|
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 |
| |
|
|
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) |
| |
|
|
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 html json |
| Obsoleted by: | RFC 5348 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3448 |
|
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 html json |
| Obsoleted by: | RFC 7564 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3454 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3456 |
|
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 html json |
| Updated by: | RFC 3938 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3458 |
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 json html |
| 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, RFC 6780, RFC 8359 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3473 |
|
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 json html |
| Updated by: | RFC 6107 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3477 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3478 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3479 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3480 |
|
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) |
| |
|
|
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 html json |
| Updated by: | RFC 4896 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3485 |
|
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) |
| |
|
|
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 html json |
| Obsoleted by: | RFC 5389 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3489 |
|
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) |
| |
|
|
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 html json |
| Obsoleted by: | RFC 5891 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3491 |
|
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) |
| |
|
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3495 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3497 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3498 |
|
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 html json |
| Obsoletes: | RFC 2060 |
| Obsoleted by: | RFC 9051 |
| Updated by: | RFC 4466, RFC 4469, RFC 4551, RFC 5032, RFC 5182, RFC 5738, RFC 6186, RFC 6858, RFC 7817, RFC 8314, RFC 8437, RFC 8474, RFC 8996 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3501 |
|
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 |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3503 |
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 json html |
| Obsoleted by: | RFC 6675 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3517 |
|
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 html json |
| Obsoletes: | RFC 2878 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3518 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3519 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3520 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3524 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3526 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3527 |
|
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 html json |
| Obsoletes: | RFC 3010 |
| Obsoleted by: | RFC 7530 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3530 |
|
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 |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3537 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3539 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3543 |
|
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 json html |
| Obsoletes: | RFC 2509 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3544 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3545 |
|
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 html json |
| Obsoleted by: | RFC 4366 |
| Updates: | RFC 2246 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3546 |
|
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 html json |
| Obsoleted by: | RFC 6407 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3547 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3554 |
|
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 |
| |
|
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3556 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3557 |
|
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) |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3559 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3560 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3565 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3566 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3573 |
|
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) |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3578 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3581 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3585 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3586 |
|
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 |
| |
|
|
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 |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3591 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3594 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3595 |
|
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 |
| |
|
|
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 |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3601 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3602 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3605 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3606 |
|
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 json html |
| Updated by: | RFC 5630 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3608 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3611 |
|
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 |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3621 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3623 |
|
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 |
| |
|
|
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 |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3634 |
|
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 |
| |
|
|
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) |
| |
|
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3637 |
|
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 html json |
| Updated by: | RFC 5691 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3640 |
|
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 |
| |
|
|
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 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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3643 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3644 |
|
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 html json |
| Updates: | RFC 2845 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3645 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3646 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3648 |
|
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 |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3657 |
|
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) |
| |
|
|
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 |
| |
|
|
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) |
| |
|
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3670 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3671 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3672 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3673 |
|
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) |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3686 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3687 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3691 |
|
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 json html |
| Obsoleted by: | RFC 6437 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3697 |
|
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 |
| |
|
|
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 json html |
| Updated by: | RFC 4104 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3703 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3705 |
|
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 html json |
| Obsoleted by: | RFC 9399 |
| Updated by: | RFC 6170 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3709 |
|
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) |
| |
|
|
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) |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3722 |
|
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 json html |
| Updated by: | RFC 7146 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3723 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3727 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3728 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3729 |
|
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) |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3737 |
|
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 html json |
| Obsoletes: | RFC 3039 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3739 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3744 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3745 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3747 |
|
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) |
| |
|
|
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 |
| |
|
|
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) |
| |
|
|
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 |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3758 |
|
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) |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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) |
| |
|
|
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 |
| |
|
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3772 |
|
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 json html |
| Obsoleted by: | RFC 6275 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3775 |
|
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 html json |
| Updated by: | RFC 4877 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3776 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3779 |
|
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 |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3788 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3804 |
|
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 html json |
| Obsoletes: | RFC 1759 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3805 |
|
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 json html |
| Updates: | RFC 3057 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3807 |
|
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 |
| |
|
|
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 html json |
| Updated by: | RFC 7274 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3811 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3812 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3813 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3814 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3815 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3816 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3820 |
|
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 html json |
| Updated by: | RFC 7146 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3821 |
|
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) |
| |
|
|
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 html json |
| Obsoleted by: | RFC 6225 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3825 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3826 |
|
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 html json |
| Updated by: | RFC 6335 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3828 |
|
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 html json |
| Updated by: | RFC 4738, RFC 6309 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3830 |
|
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 |
| |
|
|
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 |
| |
|
|
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 html json |
| Updated by: | RFC 6381 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3839 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3840 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3841 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3842 |
|
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 html json |
| Updated by: | RFC 4815 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3843 |
|
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 |
| |
|
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3846 |
|
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 |
| |
|
|
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 |
| |
|
|
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) |
| |
|
|
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) |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3854 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3855 |
|
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) |
| |
|
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3857 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3858 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3859 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3860 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3861 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3862 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3863 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3865 |
|
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) |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3868 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3872 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3873 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3876 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3877 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3878 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3879 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3880 |
|
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 html json |
| Updates: | RFC 1793 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3883 |
|
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 json html |
| Updates: | RFC 3461 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3885 |
|
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 |
| |
|
|
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 |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3890 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3891 |
|
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 |
| |
|
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3893 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3894 |
|
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 |
| |
|
|
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 |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3898 |
|
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 |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3909 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3910 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3911 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3915 |
|
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 |
| |
|
|
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 json html |
| Obsoleted by: | RFC 6121 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3921 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3922 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3923 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3925 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3927 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3928 |
|
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 json html |
| Updated by: | RFC 5641 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3931 |
|
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 |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3939 |
|
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 |
| |
|
|
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 |
| |
|
|
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 json html |
| Obsoleted by: | RFC 4606 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3946 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3947 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3948 |
|
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 |
| |
|
|
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 |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3957 |
|
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 html json |
| Updated by: | RFC 8553 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3958 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3959 |
|
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 |
| |
|
|
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 |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3963 |
|
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 |
| |
|
|
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 |
| |
|
|
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) |
| |
|
|
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) |
| |
|
|
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) |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3982 |
|
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) |
| |
|
|
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 html json |
| Obsoleted by: | RFC 6184 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3984 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3987 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3993 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3994 |
|
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 |
| |
|
|
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 json html |
| Updates: | RFC 2911 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3996 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 3998 |
|
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 html json |
| Obsoletes: | RFC 3291 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4001 |
|
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 json html |
| Updated by: | RFC 6118 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4002 |
|
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 |
| |
|
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4004 |
|
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 html json |
| Obsoleted by: | RFC 7155 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4005 |
|
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 json html |
| Obsoleted by: | RFC 8506 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4006 |
|
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 json html |
| Updated by: | RFC 7346 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4007 |
|
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 html json |
| Obsoleted by: | RFC 7658 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4008 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4010 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4011 |
|
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) |
| |
|
|
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 |
| |
|
|
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 html json |
| Updated by: | RFC 9445 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4014 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4015 |
|
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 html json |
| Updated by: | RFC 7146 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4018 |
|
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 |
| |
|
|
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 |
| |
|
|
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) |
| |
|
|
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 json html |
| Updated by: | RFC 5332 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4023 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4025 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4028 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4030 |
|
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 json html |
| Updates: | RFC 3312 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4032 |
|
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 json html |
| 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, RFC 6840 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4033 |
|
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 html json |
| 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, RFC 6840, RFC 6944, RFC 9077 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4034 |
|
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 html json |
| 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, RFC 6840, RFC 8198, RFC 9077, RFC 9520 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4035 |
|
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 |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4037 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4039 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4040 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4043 |
|
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 |
| |
|
|
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) |
| |
|
|
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 |
| |
|
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4056 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4060 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4064 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4069 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4070 |
|
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 |
| |
|
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4073 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4075 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4077 |
|
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 |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4088 |
|
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 |
| |
|
|
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 json html |
| Obsoleted by: | RFC 5245 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4091 |
|
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 html json |
| Obsoleted by: | RFC 5245 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4092 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4095 |
|
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 |
| |
|
|
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 |
| |
|
|
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 json html |
| Updates: | RFC 3703 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4104 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4106 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4108 |
|
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) |
| |
|
|
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 |
| |
|
|
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) |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4114 |
|
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 |
| |
|
|
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 json html |
| Obsoletes: | RFC 1510 |
| Updated by: | RFC 4537, RFC 5021, RFC 5896, RFC 6111, RFC 6112, RFC 6113, RFC 6649, RFC 6806, RFC 7751, RFC 8062, RFC 8129, RFC 8429, RFC 8553 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4120 |
|
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 |
| |
|
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4122 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4124 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4129 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4130 |
|
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 json html |
| Updated by: | RFC 9141 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4131 |
|
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 html json |
| Obsoleted by: | RFC 5932 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4132 |
|
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) |
| |
|
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4141 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4142 |
|
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 json html |
| Updated by: | RFC 6118 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4143 |
|
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 html json |
| Updated by: | RFC 4572 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4145 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4149 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4150 |
|
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 json html |
| Updated by: | RFC 8996 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4162 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4164 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4165 |
|
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 html json |
| Updated by: | RFC 8996 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4168 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4171 |
|
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 json html |
| Updated by: | RFC 6172, RFC 7146 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4172 |
|
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 json html |
| Updated by: | RFC 7146 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4173 |
|
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 html json |
| Updated by: | RFC 7146 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4174 |
|
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 html json |
| Updated by: | RFC 4421 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4175 |
|
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 html json |
| Obsoletes: | RFC 2478 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4178 |
|
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 |
| |
|
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4184 |
|
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 html json |
| Obsoletes: | RFC 1493 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4188 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4191 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4193 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4194 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4196 |
|
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) |
| |
|
|
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) |
| |
|
|
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) |
| |
|
|
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) |
| |
|
|
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) |
| |
|
|
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 json html |
| Updated by: | RFC 6898 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4207 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4208 |
|
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 html json |
| Updated by: | RFC 6898 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4209 |
|
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) |
| |
|
|
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) |
| |
|
|
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 json html |
| Obsoletes: | RFC 2893 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4213 |
|
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 |
| |
|
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4220 |
|
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) |
| |
|
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4231 |
|
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 json html |
| Obsoletes: | RFC 3057 |
| Updated by: | RFC 5133 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4233 |
|
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) |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4236 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4237 |
|
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 |
| |
|
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4239 |
|
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 html json |
| Obsoleted by: | RFC 8415 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4242 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4243 |
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 json html |
| Updated by: | RFC 8308 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4254 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4255 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4256 |
|
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) |
| |
|
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4262 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4265 |
|
This document describes Textual Conventions used for managing VirtualPrivate Networks (VPNs). |
|
| |
| RFC 4266 | The gopher URI Scheme |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4268 |
|
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 |
| |
|
|
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 json html |
| Updated by: | RFC 8996 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4279 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4280 |
|
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 json html |
| Obsoleted by: | RFC 6381 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4281 |
|
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 html json |
| Obsoletes: | RFC 2486 |
| Obsoleted by: | RFC 7542 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4282 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4283 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4286 |
|
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 html json |
| Updated by: | RFC 5988 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4287 |
|
This document specifies Atom, an XML-based Web content and metadata syndication format. |
|
| |
| RFC 4292 | IP Forwarding Table MIB |
| |
|
|
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) |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4295 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4298 |
|
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 |
| |
|
|
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 |
| |
|
|
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) |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4304 |
|
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) |
| |
|
|
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 |
| |
|
|
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) |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4308 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4309 |
|
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) |
| |
|
|
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 |
| |
|
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4312 |
|
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 |
| |
|
|
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 |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4318 |
|
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 json html |
| Obsoletes: | RFC 3276 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4319 |
|
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 |
| |
|
|
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 html json |
| Updated by: | RFC 9141 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4323 |
|
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 |
| |
|
|
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 html json |
| Updated by: | RFC 7280 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4326 |
|
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 html json |
| Obsoleted by: | RFC 4631 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4327 |
|
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 |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4331 |
|
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 json html |
| Obsoletes: | RFC 3770 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4334 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4335 |
|
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 |
| |
|
|
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 |
| |
|
|
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) |
| |
|
|
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 |
| |
|
|
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) |
| |
|
|
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 |
| |
|
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4344 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4345 |
|
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 4348 | Real-Time Transport Protocol (RTP) Payload Format for the Variable-Rate Multimode Wideband (VMR-WB) Audio Codec |
| |
|
|
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 html json |
| Updated by: | RFC 5641 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4349 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4352 |
|
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 html json |
| Updated by: | RFC 6118 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4355 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4356 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4359 |
|
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 |
| |
|
|
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) |
| |
|
|
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 |
| |
|
|
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 json html |
| Obsoletes: | RFC 2674 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4363 |
|
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) |
| |
|
|
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 |
| |
|
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4368 |
|
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 html json |
| Obsoleted by: | RFC 6173 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4369 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4370 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4372 |
|
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 |
| |
|
|
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) |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4382 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4383 |
|
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 html json |
| Updated by: | RFC 5586 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4385 |
|
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 |
| |
|
|
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 html json |
| Updated by: | RFC 6148 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4388 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4390 |
|
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) |
| |
|
|
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 |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4396 |
|
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) |
| |
|
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4401 |
|
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 4404 | Definitions of Managed Objects for Fibre Channel Over TCP/IP (FCIP) |
| |
| Authors: | R. Natarajan, A. Rijhsinghani. |
| Date: | February 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4404 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4411 |
|
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 json html |
| Updated by: | RFC 7134 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4412 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4414 |
|
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 html json |
| Updated by: | RFC 6118 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4415 |
|
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 html json |
| Updated by: | RFC 8270 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4419 |
|
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) |
| |
|
|
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 |
| |
|
|
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 json html |
| Obsoletes: | RFC 2222 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4422 |
|
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 |
| |
|
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4425 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4426 |
|
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 |
| |
|
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4430 |
|
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 |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4433 |
|
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) |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4436 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4438 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4439 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4442 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4444 |
|
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) |
| |
|
|
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 |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4449 |
|
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 json html |
| Updated by: | RFC 5641 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4454 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4455 |
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 |
| |
|
|
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 json html |
| Obsoleted by: | RFC 8224 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4474 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4476 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4479 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4480 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4481 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4482 |
|
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 html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4483 |
|
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 |
| |
|
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4488 |
|
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 json html |
| Updates: | RFC 3306 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4489 |
|
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 json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4490 |
|
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 json html |
| Updates: | RFC 3279 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4491 |
|
This document supplements RFC 3279. It describes encoding formats, identifiers, and parameter formats for the algorithms GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 for use in Internet X.509Public Key Infrastructure (PKI). |
|
| |
| RFC 4494 | The AES-CMAC-96 Algorithm and Its Use with IPsec |
| |
| Authors: | JH. Song, R. Poovendran, J. Lee. |
| Date: | June 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4494 |
|
The National Institute of Standards and Technology (NIST) has recently specified the Cipher-based Message Authentication Code(CMAC), which is equivalent to the One-Key CBC-MAC1 (OMAC1) algorithm submitted by Iwata and Kurosawa. OMAC1 efficiently reduces the key size of Extended Cipher Block Chaining mode (XCBC). This memo specifies the use of CMAC mode on the authentication mechanism of theIPsec Encapsulating Security Payload (ESP) and the AuthenticationHeader (AH) protocols. This new algorithm is named AES-CMAC-96. |
|
| |
| RFC 4495 | A Resource Reservation Protocol (RSVP) Extension for the Reduction of Bandwidth of a Reservation Flow |
| |
|
|
This document proposes an extension to the Resource ReservationProtocol (RSVPv1) to reduce the guaranteed bandwidth allocated to an existing reservation. This mechanism can be used to affect individual reservations, aggregate reservations, or other forms ofRSVP tunnels. This specification is an extension of RFC 2205. |
|
| |
| RFC 4501 | Domain Name System Uniform Resource Identifiers |
| |
| Authors: | S. Josefsson. |
| Date: | May 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4501 |
|
This document defines Uniform Resource Identifiers for Domain NameSystem resources. |
|
| |
| RFC 4505 | Anonymous Simple Authentication and Security Layer (SASL) Mechanism |
| |
|
|
On the Internet, it is common practice 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 using optional trace information, such as an email address, as the password. As plain-text login commands are not permitted in new IETF protocols, a new way to provide anonymous login is needed within the context of the Simple Authentication and Security Layer (SASL) framework. |
|
| |
| RFC 4507 | Transport Layer Security (TLS) Session Resumption without Server-Side State |
| |
| Authors: | J. Salowey, H. Zhou, P. Eronen, H. Tschofenig. |
| Date: | May 2006 |
| Formats: | txt html json |
| Obsoleted by: | RFC 5077 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4507 |
|
This document describes a mechanism that enables the Transport LayerSecurity (TLS) server to resume sessions and avoid keeping per-client session state. The TLS server encapsulates the session state into a ticket and forwards it to the client. The client can subsequently resume a session using the obtained ticket. |
|
| |
| RFC 4508 | Conveying Feature Tags with the Session Initiation Protocol (SIP) REFER Method |
| |
|
|
The SIP "Caller Preferences" extension defined in RFC 3840 provides a mechanism that allows a SIP request to convey information relating to the originator's capabilities and preferences for handling of that request. The SIP REFER method defined in RFC 3515 provides a mechanism that allows one party to induce another to initiate a SIP request. This document extends the REFER method to use the mechanism of RFC 3840. By doing so, the originator of a REFER may inform the recipient as to the characteristics of the target that the induced request is expected to reach. |
|
| |
| RFC 4509 | Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs) |
| |
| Authors: | W. Hardaker. |
| Date: | May 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4509 |
|
This document specifies how to use the SHA-256 digest type in DNSDelegation Signer (DS) Resource Records (RRs). DS records, when stored in a parent zone, point to DNSKEYs in a child zone. |
|
| |
| RFC 4510 | Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map |
| |
| Authors: | K. Zeilenga, Ed.. |
| Date: | June 2006 |
| Formats: | txt json html |
| Obsoletes: | RFC 2251, RFC 2252, RFC 2253, RFC 2254, RFC 2255, RFC 2256, RFC 2829, RFC 2830, RFC 3377, RFC 3771 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4510 |
|
The Lightweight Directory Access Protocol (LDAP) is an Internet protocol for accessing distributed directory services that act in accordance with X.500 data and service models. This document provides a road map of the LDAP Technical Specification. |
|
| |
| RFC 4511 | Lightweight Directory Access Protocol (LDAP): The Protocol |
| |
|
|
This document describes the protocol elements, along with their semantics and encodings, of the Lightweight Directory Access Protocol(LDAP). LDAP provides access to distributed directory services that act in accordance with X.500 data and service models. These protocol elements are based on those described in the X.500 Directory AccessProtocol (DAP). |
|
| |
| RFC 4512 | Lightweight Directory Access Protocol (LDAP): Directory Information Models |
| |
|
|
The Lightweight Directory Access Protocol (LDAP) is an Internet protocol for accessing distributed directory services that act in accordance with X.500 data and service models. This document describes the X.500 Directory Information Models, as used in LDAP. |
|
| |
| RFC 4513 | Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms |
| |
|
|
This document describes authentication methods and security mechanisms of the Lightweight Directory Access Protocol (LDAP). This document details establishment of Transport Layer Security (TLS) using the StartTLS operation.
This document details the simple Bind authentication method including anonymous, unauthenticated, and name/password mechanisms and theSimple Authentication and Security Layer (SASL) Bind authentication method including the EXTERNAL mechanism.
This document discusses various authentication and authorization states through which a session to an LDAP server may pass and the actions that trigger these state changes.
This document, together with other documents in the LDAP TechnicalSpecification (see Section 1 of the specification's road map), obsoletes RFC 2251, RFC 2829, and RFC 2830. |
|
| |
| RFC 4514 | Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names |
| |
|
|
The X.500 Directory uses distinguished names (DNs) as primary keys to entries in the directory. This document defines the string representation used in the Lightweight Directory Access Protocol(LDAP) to transfer distinguished names. The string representation is designed to give a clean representation of commonly used distinguished names, while being able to represent any distinguished name. |
|
| |
| RFC 4515 | Lightweight Directory Access Protocol (LDAP): String Representation of Search Filters |
| |
| Authors: | M. Smith, Ed., T. Howes. |
| Date: | June 2006 |
| Formats: | txt json html |
| Obsoletes: | RFC 2254 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4515 |
|
Lightweight Directory Access Protocol (LDAP) search filters are transmitted in the LDAP protocol using a binary representation that is appropriate for use on the network. This document defines a human-readable string representation of LDAP search filters that is appropriate for use in LDAP URLs (RFC 4516) and in other applications. |
|
| |
| RFC 4516 | Lightweight Directory Access Protocol (LDAP): Uniform Resource Locator |
| |
| Authors: | M. Smith, Ed., T. Howes. |
| Date: | June 2006 |
| Formats: | txt html json |
| Obsoletes: | RFC 2255 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4516 |
|
This document describes a format for a Lightweight Directory AccessProtocol (LDAP) Uniform Resource Locator (URL). An LDAP URL describes an LDAP search operation that is used to retrieve information from an LDAP directory, or, in the context of an LDAP referral or reference, an LDAP URL describes a service where an LDAP operation may be progressed. |
|
| |
| RFC 4517 | Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules |
| |
|
|
Each attribute stored in a Lightweight Directory Access Protocol(LDAP) directory, whose values may be transferred in the LDAP protocol, has a defined syntax that constrains the structure and format of its values. The comparison semantics for values of a syntax are not part of the syntax definition but are instead provided through separately defined matching rules. Matching rules specify an argument, an assertion value, which also has a defined syntax. This document defines a base set of syntaxes and matching rules for use in defining attributes for LDAP directories. |
|
| |
| RFC 4518 | Lightweight Directory Access Protocol (LDAP): Internationalized String Preparation |
| |
| Authors: | K. Zeilenga. |
| Date: | June 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4518 |
|
The previous Lightweight Directory Access Protocol (LDAP) technical specifications did not precisely define how character string matching is to be performed. This led to a number of usability and interoperability problems. This document defines string preparation algorithms for character-based matching rules defined for use inLDAP. |
|
| |
| RFC 4519 | Lightweight Directory Access Protocol (LDAP): Schema for User Applications |
| |
|
|
This document is an integral part of the Lightweight Directory AccessProtocol (LDAP) technical specification. It provides a technical specification of attribute types and object classes intended for use by LDAP directory clients for many directory services, such as WhitePages. These objects are widely used as a basis for the schema in many LDAP directories. This document does not cover attributes used for the administration of directory servers, nor does it include directory objects defined for specific uses in other documents. |
|
| |
| RFC 4522 | Lightweight Directory Access Protocol (LDAP): The Binary Encoding Option |
| |
| Authors: | S. Legg. |
| Date: | June 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4522 |
|
Each attribute stored in a Lightweight Directory Access Protocol(LDAP) directory has a defined syntax (i.e., data type). A syntax definition specifies how attribute values conforming to the syntax are normally represented when transferred in LDAP operations. This representation is referred to as the LDAP-specific encoding to distinguish it from other methods of encoding attribute values. This document defines an attribute option, the binary option, that can be used to specify that the associated attribute values are instead encoded according to the Basic Encoding Rules (BER) used by X.500 directories. |
|
| |
| RFC 4523 | Lightweight Directory Access Protocol (LDAP) Schema Definitions for X.509 Certificates |
| |
|
| |
| RFC 4524 | COSINE LDAP/X.500 Schema |
| |
|
|
This document provides a collection of schema elements for use with the Lightweight Directory Access Protocol (LDAP) from the COSINE andInternet X.500 pilot projects.
This document obsoletes RFC 1274 and updates RFCs 2247 and 2798. |
|
| |
| RFC 4526 | Lightweight Directory Access Protocol (LDAP) Absolute True and False Filters |
| |
| Authors: | K. Zeilenga. |
| Date: | June 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4526 |
|
This document extends the Lightweight Directory Access Protocol(LDAP) to support absolute True and False filters based upon similar capabilities found in X.500 directory systems. The document also extends the String Representation of LDAP Search Filters to support these filters. |
|
| |
| RFC 4527 | Lightweight Directory Access Protocol (LDAP) Read Entry Controls |
| |
| Authors: | K. Zeilenga. |
| Date: | June 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4527 |
|
This document specifies an extension to the Lightweight DirectoryAccess Protocol (LDAP) to allow the client to read the target entry of an update operation. The client may request to read the entry before and/or after the modifications are applied. These reads are done as an atomic part of the update operation. |
|
| |
| RFC 4528 | Lightweight Directory Access Protocol (LDAP) Assertion Control |
| |
| Authors: | K. Zeilenga. |
| Date: | June 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4528 |
|
This document defines the Lightweight Directory Access Protocol(LDAP) Assertion Control, which allows a client to specify that a directory operation should only be processed if an assertion applied to the target entry of the operation is true. It can be used to construct "test and set", "test and clear", and other conditional operations. |
|
| |
| RFC 4530 | Lightweight Directory Access Protocol (LDAP) entryUUID Operational Attribute |
| |
| Authors: | K. Zeilenga. |
| Date: | June 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4530 |
|
This document describes the LDAP/X.500 'entryUUID' operational attribute and associated matching rules and syntax. The attribute holds a server-assigned Universally Unique Identifier (UUID) for the object. Directory clients may use this attribute to distinguish objects identified by a distinguished name or to locate an object after renaming. |
|
| |
| RFC 4532 | Lightweight Directory Access Protocol (LDAP) "Who am I?" Operation |
| |
| Authors: | K. Zeilenga. |
| Date: | June 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4532 |
|
This specification provides a mechanism for Lightweight DirectoryAccess Protocol (LDAP) clients to obtain the authorization identity the server has associated with the user or application entity. This mechanism is specified as an LDAP extended operation called the LDAP"Who am I?" operation. |
|
| |
| RFC 4534 | Group Security Policy Token v1 |
| |
| Authors: | A. Colegrove, H. Harney. |
| Date: | June 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4534 |
|
The Group Security Policy Token is a structure used to specify the security policy and configurable parameters for a cryptographic group, such as a secure multicast group. Because the security of a group is composed of the totality of multiple security services, mechanisms, and attributes throughout the communications infrastructure, an authenticatable representation of the features that must be supported throughout the system is needed to ensure consistent security. This document specifies the structure of such a token. |
|
| |
| RFC 4535 | GSAKMP: Group Secure Association Key Management Protocol |
| |
| Authors: | H. Harney, U. Meth, A. Colegrove, G. Gross. |
| Date: | June 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4535 |
|
This document specifies the Group Secure Association Key ManagementProtocol (GSAKMP). The GSAKMP provides a security framework for creating and managing cryptographic groups on a network. It provides mechanisms to disseminate group policy and authenticate users, rules to perform access control decisions during group establishment and recovery, capabilities to recover from the compromise of group members, delegation of group security functions, and capabilities to destroy the group. It also generates group keys. |
|
| |
| RFC 4537 | Kerberos Cryptosystem Negotiation Extension |
| |
| Authors: | L. Zhu, P. Leach, K. Jaganathan. |
| Date: | June 2006 |
| Formats: | txt html json |
| Updates: | RFC 4120 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4537 |
|
This document specifies an extension to the Kerberos protocol as defined in RFC 4120, in which the client can send a list of supported encryption types in decreasing preference order, and the server then selects an encryption type that is supported by both the client and the server. |
|
| |
| RFC 4538 | Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP) |
| |
| Authors: | J. Rosenberg. |
| Date: | June 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4538 |
|
This specification defines the Target-Dialog header field for theSession Initiation Protocol (SIP), and the corresponding option tag, tdialog. This header field is used in requests that create SIP dialogs. It indicates to the recipient that the sender is aware of an existing dialog with the recipient, either because the sender is on the other side of that dialog, or because it has access to the dialog identifiers. The recipient can then authorize the request based on this awareness. |
|
| |
| RFC 4543 | The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH |
| |
| Authors: | D. McGrew, J. Viega. |
| Date: | May 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4543 |
|
This memo describes the use of the Advanced Encryption Standard (AES)Galois Message Authentication Code (GMAC) as a mechanism to provide data origin authentication, but not confidentiality, within the IPsecEncapsulating Security Payload (ESP) and Authentication Header (AH).GMAC is based on the Galois/Counter Mode (GCM) of operation, and can be efficiently implemented in hardware for speeds of 10 gigabits per second and above, and is also well-suited to software implementations. |
|
| |
| RFC 4544 | Definitions of Managed Objects for Internet Small Computer System Interface (iSCSI) |
| |
| Authors: | M. Bakke, M. Krueger, T. McSweeney, J. Muchow. |
| Date: | May 2006 |
| Formats: | txt html json |
| Obsoleted by: | RFC 7147 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4544 |
|
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 using theInternet Small Computer System Interface (iSCSI) protocol (SCSI overTCP). |
|
| |
| RFC 4545 | Definitions of Managed Objects for IP Storage User Identity Authorization |
| |
| Authors: | M. Bakke, J. Muchow. |
| Date: | May 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4545 |
|
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 user identities and the names, addresses, and credentials required manage access control, for use with various protocols. This document was motivated by the need for the configuration of authorized user identities for the iSCSI protocol, but has been extended to be useful for other protocols that have similar requirements. It is important to note that this MIB module provides only the set of identities to be used within access lists; it is the responsibility of other MIB modules making use of this one to tie them to their own access lists or other authorization control methods. |
|
| |
| RFC 4546 | Radio Frequency (RF) Interface Management Information Base for Data over Cable Service Interface Specifications (DOCSIS) 2.0 Compliant RF Interfaces |
| |
|
|
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 Radio Frequency(RF) interfaces for systems compliant with the Data Over CableService Interface Specifications (DOCSIS). |
|
| |
| RFC 4547 | Event Notification Management Information Base for Data over Cable Service Interface Specifications (DOCSIS)-Compliant Cable Modems and Cable Modem Termination Systems |
| |
| Authors: | A. Ahmad, G. Nakanishi. |
| Date: | June 2006 |
| Formats: | txt json html |
| Updated by: | RFC 9141 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4547 |
|
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 SimpleNetwork Management Protocol (SNMP) based event notification management of Data Over Cable Service Interface Specification(DOCSIS) compliant Cable Modems and Cable Modem Termination Systems.This MIB is defined as an extension to the DOCSIS Cable Device MIB.
This memo specifies a MIB module in a manner that is compliant to theStructure of Management Information Version 2 (SMIv2). The set of objects is consistent with the SNMP framework and existing SNMP standards. |
|
| |
| RFC 4548 | Internet Code Point (ICP) Assignments for NSAP Addresses |
| |
|
|
This document is intended to accomplish two highly inter-related tasks: to establish an "initial" Internet Code Point (ICP) assignment for each of IPv4 and IPv6 address encoding in Network Service AccessPoint (NSAP) Addresses, and to recommend an IANA assignment policy for currently unassigned ICP values. In the first task, this document is a partial replacement for RFC 1888 -- particularly for section 6 of RFC 1888. In the second task, this document incorporates wording and specifications from ITU-T RecommendationX.213 and further recommends that IANA use the "IETF consensus" assignment policy in making future ICP assignments. |
|
| |
| RFC 4550 | Internet Email to Support Diverse Service Environments (Lemonade) Profile |
| |
| Authors: | S. Maes, A. Melnikov. |
| Date: | June 2006 |
| Formats: | txt html json |
| Obsoleted by: | RFC 5550 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4550 |
|
This document describes a profile (a set of required extensions, restrictions, and usage modes) of the IMAP and mail submission protocols. This profile allows clients (especially those that are constrained in memory, bandwidth, processing power, or other areas) to efficiently use IMAP and Submission to access and submit mail.This includes the ability to forward received mail without needing to download and upload the mail, to optimize submission, and to efficiently resynchronize in case of loss of connectivity with the server.
The Internet Email to Support Diverse Service Environments (Lemonade) profile relies upon extensions to IMAP and Mail Submission protocols; specifically, the URLAUTH and CATENATE IMAP protocol (RFC 3501) extensions and the BURL extension to the SUBMIT protocol (RFC 4409). |
|
| |
| RFC 4551 | IMAP Extension for Conditional STORE Operation or Quick Flag Changes Resynchronization |
| |
|
|
Often, multiple IMAP (RFC 3501) clients need to coordinate changes to a common IMAP mailbox. Examples include different clients working on behalf of the same user, and multiple users accessing shared mailboxes. These clients need a mechanism to synchronize state changes for messages within the mailbox. They must be able to guarantee that only one client can change message state (e.g., message flags) at any time. An example of such an application is use of an IMAP mailbox as a message queue with multiple dequeueing clients.
The Conditional Store facility provides a protected update mechanism for message state information that can detect and resolve conflicts between multiple writing mail clients.
The Conditional Store facility also allows a client to quickly resynchronize mailbox flag changes.
This document defines an extension to IMAP (RFC 3501). |
|
| |
| RFC 4552 | Authentication/Confidentiality for OSPFv3 |
| |
| Authors: | M. Gupta, N. Melam. |
| Date: | June 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4552 |
|
This document describes means and mechanisms to provide authentication/confidentiality to OSPFv3 using an IPv6 AuthenticationHeader/Encapsulating Security Payload (AH/ESP) extension header. |
|
| |
| RFC 4553 | Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP) |
| |
| Authors: | A. Vainshtein, Ed., YJ. Stein, Ed.. |
| Date: | June 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4553 |
|
This document describes a pseudowire encapsulation for Time DivisionMultiplexing (TDM) bit-streams (T1, E1, T3, E3) that disregards any structure that may be imposed on these streams, in particular the structure imposed by the standard TDM framing. |
|
| |
| RFC 4555 | IKEv2 Mobility and Multihoming Protocol (MOBIKE) |
| |
| Authors: | P. Eronen. |
| Date: | June 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4555 |
|
This document describes the MOBIKE protocol, a mobility and multihoming extension to Internet Key Exchange (IKEv2). MOBIKE allows the IP addresses associated with IKEv2 and tunnel mode IPsecSecurity Associations to change. A mobile Virtual Private Network(VPN) client could use MOBIKE to keep the connection with the VPN gateway active while moving from one address to another. Similarly, a multihomed host could use MOBIKE to move the traffic to a different interface if, for instance, the one currently being used stops working. |
|
| |
| RFC 4556 | Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) |
| |
|
|
This document describes protocol extensions (hereafter called PKINIT) to the Kerberos protocol specification. These extensions provide a method for integrating public key cryptography into the initial authentication exchange, by using asymmetric-key signature and/or encryption algorithms in pre-authentication data fields. |
|
| |
| RFC 4557 | Online Certificate Status Protocol (OCSP) Support for Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) |
| |
| Authors: | L. Zhu, K. Jaganathan, N. Williams. |
| Date: | June 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4557 |
|
This document defines a mechanism to enable in-band transmission ofOnline Certificate Status Protocol (OCSP) responses in the Kerberos network authentication protocol. These responses are used to verify the validity of the certificates used in Public Key Cryptography forInitial Authentication in Kerberos (PKINIT), which is the KerberosVersion 5 extension that provides for the use of public key cryptography. |
|
| |
| RFC 4558 | Node-ID Based Resource Reservation Protocol (RSVP) Hello: A Clarification Statement |
| |
| Authors: | Z. Ali, R. Rahman, D. Prairie, D. Papadimitriou. |
| Date: | June 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4558 |
|
Use of Node-ID based Resource Reservation Protocol (RSVP) Hello messages is implied in a number of cases, e.g., when data and control planes are separated, when TE links are unnumbered. Furthermore, when link level failure detection is performed by some means other than exchanging RSVP Hello messages, use of a Node-ID based Hello session is optimal for detecting signaling adjacency failure forResource reSerVation Protocol-Traffic Engineering (RSVP-TE).Nonetheless, this implied behavior is unclear, and this document formalizes use of the Node-ID based RSVP Hello session in some scenarios. The procedure described in this document applies to bothMulti-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) capable nodes. |
|
| |
| RFC 4560 | Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations |
| |
| Authors: | J. Quittek, Ed., K. White, Ed.. |
| Date: | June 2006 |
| Formats: | txt html json |
| Obsoletes: | RFC 2925 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4560 |
|
This memo defines Management Information Bases (MIBs) for performing ping, traceroute, and lookup operations at a host. When managing a network, it is useful to be able to initiate and retrieve the results of ping or traceroute operations when they are performed at a remote host. A lookup capability is defined in order to enable resolution of either an IP address to an DNS name or a DNS name to an IP 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 4561 | Definition of a Record Route Object (RRO) Node-Id Sub-Object |
| |
| Authors: | J.-P. Vasseur, Ed., Z. Ali, S. Sivabalan. |
| Date: | June 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4561 |
|
In the context of MPLS TE Fast Reroute, the Merge Point (MP) address is required at the Point of Local Repair (PLR) in order to select a backup tunnel intersecting a fast reroutable Traffic EngineeringLabel Switched Path (TE LSP) on a downstream Label Switching Router(LSR). However, existing protocol mechanisms are not sufficient to find an MP address in multi-domain routing networks where a domain is defined as an Interior Gateway Protocol (IGP) area or an AutonomousSystem (AS). Hence, the current MPLS Fast Reroute mechanism cannot be used in order to protect inter-domain TE LSPs from a failure of anArea Border Router (ABR) or Autonomous System Border Router (ASBR).This document specifies the use of existing Record Route Object (RRO)IPv4 and IPv6 sub-objects (with a new flag defined) thus defining the node-id sub-object in order to solve this issue. The MPLS FastReroute mechanism mentioned in this document refers to the "Facility backup" MPLS TE Fast Reroute method. |
|
| |
| RFC 4563 | The Key ID Information Type for the General Extension Payload in Multimedia Internet KEYing (MIKEY) |
| |
| Authors: | E. Carrara, V. Lehtovirta, K. Norrman. |
| Date: | June 2006 |
| Formats: | txt json html |
| Updated by: | RFC 6309 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4563 |
|
This memo specifies a new Type (the Key ID Information Type) for theGeneral Extension Payload in the Multimedia Internet KEYing (MIKEY)Protocol. This is used in, for example, the MultimediaBroadcast/Multicast Service specified in the Third GenerationPartnership Project. |
|
| |
| RFC 4566 | SDP: Session Description Protocol |
| |
|
|
This memo 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. |
|
| |
| RFC 4567 | Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP) |
| |
| Authors: | J. Arkko, F. Lindholm, M. Naslund, K. Norrman, E. Carrara. |
| Date: | July 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4567 |
|
This document defines general extensions for Session DescriptionProtocol (SDP) and Real Time Streaming Protocol (RTSP) to carry messages, as specified by a key management protocol, in order to secure the media. These extensions are presented as a framework, to be used by one or more key management protocols. As such, their use is meaningful only when complemented by an appropriate key management protocol.
General guidelines are also given on how the framework should be used together with SIP and RTSP. The usage with the Multimedia InternetKEYing (MIKEY) key management protocol is also defined. |
|
| |
| RFC 4568 | Session Description Protocol (SDP) Security Descriptions for Media Streams |
| |
| Authors: | F. Andreasen, M. Baugher, D. Wing. |
| Date: | July 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4568 |
|
This document defines a Session Description Protocol (SDP) cryptographic attribute for unicast media streams. The attribute describes a cryptographic key and other parameters that serve to configure security for a unicast media stream in either a single message or a roundtrip exchange. The attribute can be used with a variety of SDP media transports, and this document defines how to use it for the Secure Real-time Transport Protocol (SRTP) unicast media streams. The SDP crypto attribute requires the services of a data security protocol to secure the SDP message. |
|
| |
| RFC 4570 | Session Description Protocol (SDP) Source Filters |
| |
| Authors: | B. Quinn, R. Finlayson. |
| Date: | July 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4570 |
|
This document describes how to adapt the Session Description Protocol(SDP) to express one or more source addresses as a source filter for one or more destination "connection" addresses. It defines the syntax and semantics for an SDP "source-filter" attribute that may reference either IPv4 or IPv6 address(es) as either an inclusive or exclusive source list for either multicast or unicast destinations.In particular, an inclusive source-filter can be used to specify aSource-Specific Multicast (SSM) session. |
|
| |
| RFC 4571 | Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection-Oriented Transport |
| |
| Authors: | J. Lazzaro. |
| Date: | July 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4571 |
|
This memo defines a method for framing Real-time Transport Protocol(RTP) and RTP Control Protocol (RTCP) packets onto connection- oriented transport (such as TCP). The memo also defines how session descriptions may specify RTP streams that use the framing method. |
|
| |
| RFC 4572 | Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP) |
| |
|
|
This document specifies how to establish secure connection-oriented media transport sessions over the Transport Layer Security (TLS) protocol using the Session Description Protocol (SDP). It defines a new SDP protocol identifier, 'TCP/TLS'. It also defines the syntax and semantics for an SDP 'fingerprint' attribute that identifies the certificate that will be presented for the TLS session. This mechanism allows media transport over TLS connections to be established securely, so long as the integrity of session descriptions is assured.
This document extends and updates RFC 4145. |
|
| |
| RFC 4573 | MIME Type Registration for RTP Payload Format for H.224 |
| |
| Authors: | R. Even, A. Lochbaum. |
| Date: | July 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4573 |
|
In conversational video applications, far-end camera control protocol is used by participants to control the remote camera. The protocol that is commonly used is ITU H.281 over H.224. The document registers the H224 media type. It defines the syntax and the semantics of the Session Description Protocol (SDP) parameters needed to support far-end camera control protocol using H.224. |
|
| |
| RFC 4574 | The Session Description Protocol (SDP) Label Attribute |
| |
| Authors: | O. Levin, G. Camarillo. |
| Date: | August 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4574 |
|
This document defines a new Session Description Protocol (SDP) media-level attribute: "label". The "label" attribute carries a pointer to a media stream in the context of an arbitrary network application that uses SDP. The sender of the SDP document can attach the "label" attribute to a particular media stream or streams. The application can then use the provided pointer to refer to each particular media stream in its context. |
|
| |
| RFC 4575 | A Session Initiation Protocol (SIP) Event Package for Conference State |
| |
| Authors: | J. Rosenberg, H. Schulzrinne, O. Levin, Ed.. |
| Date: | August 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4575 |
|
This document defines a conference event package for tightly coupled conferences using the Session Initiation Protocol (SIP) events framework, along with a data format used in notifications for this package. The conference package allows users to subscribe to a conference Uniform Resource Identifier (URI). Notifications are sent about changes in the membership of this conference and optionally about changes in the state of additional conference components. |
|
| |
| RFC 4576 | Using a Link State Advertisement (LSA) Options Bit to Prevent Looping in BGP/MPLS IP Virtual Private Networks (VPNs) |
| |
| Authors: | E. Rosen, P. Psenak, P. Pillay-Esnault. |
| Date: | June 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4576 |
|
This document specifies a procedure that deals with a particular issue that may arise when a Service Provider (SP) provides "BGP/MPLSIP VPN" service to a customer and the customer uses OSPFv2 to advertise its routes to the SP. In this situation, a Customer Edge(CE) Router and a Provider Edge (PE) Router are OSPF peers, and customer routes are sent via OSPFv2 from the CE to the PE. The customer routes are converted into BGP routes, and BGP carries them across the backbone to other PE routers. The routes are then converted back to OSPF routes sent via OSPF to other CE routers. As a result of this conversion, some of the information needed to prevent loops may be lost. A procedure is needed to ensure that once a route is sent from a PE to a CE, the route will be ignored by anyPE that receives it back from a CE. This document specifies the necessary procedure, using one of the options bits in the LSA (LinkState Advertisements) to indicate that an LSA has already been forwarded by a PE and should be ignored by any other PEs that see it. |
|
| |
| RFC 4577 | OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs) |
| |
| Authors: | E. Rosen, P. Psenak, P. Pillay-Esnault. |
| Date: | June 2006 |
| Formats: | txt json html |
| Updates: | RFC 4364 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4577 |
|
Many Service Providers offer Virtual Private Network (VPN) services to their customers, using a technique in which customer edge routers(CE routers) are routing peers of provider edge routers (PE routers).The Border Gateway Protocol (BGP) is used to distribute the customer's routes across the provider's IP backbone network, andMultiprotocol Label Switching (MPLS) is used to tunnel customer packets across the provider's backbone. This is known as a "BGP/MPLSIP VPN". The base specification for BGP/MPLS IP VPNs presumes that the routing protocol on the interface between a PE router and a CE router is BGP. This document extends that specification by allowing the routing protocol on the PE/CE interface to be the Open ShortestPath First (OSPF) protocol.
This document updates RFC 4364. |
|
| |
| RFC 4580 | Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Subscriber-ID Option |
| |
| Authors: | B. Volz. |
| Date: | June 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4580 |
|
This memo defines a new Relay Agent Subscriber-ID option for theDynamic Host Configuration Protocol for IPv6 (DHCPv6). The option allows a DHCPv6 relay agent to associate a stable "Subscriber-ID" with DHCPv6 client messages in a way that is independent of the client and of the underlying physical network infrastructure. |
|
| |
| RFC 4581 | Cryptographically Generated Addresses (CGA) Extension Field Format |
| |
|
|
This document defines a Type-Length-Value format forCryptographically Generated Address (CGA) Extensions. This document updates RFC 3972. |
|
| |
| RFC 4582 | The Binary Floor Control Protocol (BFCP) |
| |
|
|
Floor control is a means to manage joint or exclusive access to shared resources in a (multiparty) conferencing environment.Thereby, floor control complements other functions -- such as conference and media session setup, conference policy manipulation, and media control -- that are realized by other protocols.
This document specifies the Binary Floor Control Protocol (BFCP).BFCP is used between floor participants and floor control servers, and between floor chairs (i.e., moderators) and floor control servers. |
|
| |
| RFC 4583 | Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams |
| |
|
|
This document specifies how to describe Binary Floor Control Protocol(BFCP) streams in Session Description Protocol (SDP) descriptions.User agents using the offer/answer model to establish BFCP streams use this format in their offers and answers. |
|
| |
| RFC 4585 | Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF) |
| |
|
|
Real-time media streams that use RTP are, to some degree, resilient against packet losses. Receivers may use the base mechanisms of theReal-time Transport Control Protocol (RTCP) to report packet reception statistics and thus allow a sender to adapt its transmission behavior in the mid-term. This is the sole means for feedback and feedback-based error repair (besides a few codec- specific mechanisms). This document defines an extension to theAudio-visual Profile (AVP) that enables receivers to provide, statistically, more immediate feedback to the senders and thus allows for short-term adaptation and efficient feedback-based repair mechanisms to be implemented. This early feedback profile (AVPF) maintains the AVP bandwidth constraints for RTCP and preserves scalability to large groups. |
|
| |
| RFC 4587 | RTP Payload Format for H.261 Video Streams |
| |
|
|
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.
The memo also describes the syntax and semantics of the SessionDescription Protocol (SDP) parameters needed to support the H.261 video codec. A media type registration is included for this payload format.
This specification obsoletes RFC 2032. |
|
| |
| RFC 4588 | RTP Retransmission Payload Format |
| |
| Authors: | J. Rey, D. Leon, A. Miyazaki, V. Varsa, R. Hakenberg. |
| Date: | July 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4588 |
|
RTP retransmission is an effective packet loss recovery technique for real-time applications with relaxed delay bounds. This document describes an RTP payload format for performing retransmissions.Retransmitted RTP packets are sent in a separate stream from the original RTP stream. It is assumed that feedback from receivers to senders is available. In particular, it is assumed that Real-timeTransport Control Protocol (RTCP) feedback as defined in the extendedRTP profile for RTCP-based feedback (denoted RTP/AVPF) is available in this memo. |
|
| |
| RFC 4589 | Location Types Registry |
| |
| Authors: | H. Schulzrinne, H. Tschofenig. |
| Date: | July 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4589 |
|
This document creates a registry for describing the types of places a human or end system might be found. The registry is then referenced by other protocols that need a common set of location terms as protocol constants. Examples of location terms defined in this document include aircraft, office, and train station. |
|
| |
| RFC 4590 | RADIUS Extension for Digest Authentication |
| |
| Authors: | B. Sterman, D. Sadolevsky, D. Schwartz, D. Williams, W. Beck. |
| Date: | July 2006 |
| Formats: | txt html json |
| Obsoleted by: | RFC 5090 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4590 |
|
This document defines an extension to the Remote AuthenticationDial-In User Service (RADIUS) protocol to enable support of DigestAuthentication, for use with HTTP-style protocols like the SessionInitiation Protocol (SIP) and HTTP. |
|
| |
| RFC 4591 | Frame Relay over Layer 2 Tunneling Protocol Version 3 (L2TPv3) |
| |
| Authors: | M. Townsley, G. Wilkie, S. Booth, S. Bryant, J. Lau. |
| Date: | August 2006 |
| Formats: | txt html json |
| Updated by: | RFC 5641 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4591 |
|
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 tunnelFrame Relay over L2TPv3, including frame encapsulation, virtual- circuit creation and deletion, and status change notification. |
|
| |
| RFC 4592 | The Role of Wildcards in the Domain Name System |
| |
|
|
This is an update to the wildcard definition of RFC 1034. The interaction with wildcards and CNAME is changed, an error condition is removed, and the words defining some concepts central to wildcards are changed. The overall goal is not to change wildcards, but to refine the definition of RFC 1034. |
|
| |
| RFC 4598 | Real-time Transport Protocol (RTP) Payload Format for Enhanced AC-3 (E-AC-3) Audio |
| |
| Authors: | B. Link. |
| Date: | July 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4598 |
|
This document describes a Real-time Transport Protocol (RTP) payload format for transporting Enhanced AC-3 (E-AC-3) encoded audio data.E-AC-3 is a high-quality, multichannel audio coding format and is an extension of the AC-3 audio coding format, which is used in US High-Definition Television (HDTV), DVD, cable and satellite television, and other media. E-AC-3 is an optional audio format in US and world wide digital television and high-definition DVD formats. The RTP payload format as presented in this document includes support for data fragmentation. |
|
| |
| RFC 4601 | Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised) |
| |
|
|
This document specifies Protocol Independent Multicast - Sparse Mode(PIM-SM). PIM-SM is a multicast routing protocol that can use the underlying unicast routing information base or a separate multicast- capable routing information base. It builds unidirectional shared trees rooted at a Rendezvous Point (RP) per group, and optionally creates shortest-path trees per source.
This document obsoletes RFC 2362, an Experimental version of PIM-SM. |
|
| |
| RFC 4604 | Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast |
| |
|
|
The Internet Group Management Protocol Version 3 (IGMPv3) and theMulticast Listener Discovery Protocol Version 2 (MLDv2) are protocols that allow a host to inform its neighboring routers of its desire to receive IPv4 and IPv6 multicast transmissions, respectively.Source-specific multicast (SSM) is a form of multicast in which a receiver is required to specify both the network-layer address of the source and the multicast destination address in order to receive the multicast transmission. This document defines the notion of an"SSM-aware" router and host, and clarifies and (in some cases) modifies the behavior of IGMPv3 and MLDv2 on SSM-aware routers and hosts to accommodate source-specific multicast. This document updates the IGMPv3 and MLDv2 specifications. |
|
| |
| RFC 4605 | Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying") |
| |
| Authors: | B. Fenner, H. He, B. Haberman, H. Sandick. |
| Date: | August 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4605 |
|
In certain topologies, it is not necessary to run a multicast routing protocol. It is sufficient for a device to learn and proxy group membership information and simply forward multicast packets based upon that information. This document describes a mechanism for forwarding based solely upon Internet Group Management Protocol(IGMP) or Multicast Listener Discovery (MLD) membership information. |
|
| |
| RFC 4606 | Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control |
| |
|
|
This document provides minor clarification to RFC 3946.
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 GMPLS signaling is used. |
|
| |
| RFC 4607 | Source-Specific Multicast for IP |
| |
| Authors: | H. Holbrook, B. Cain. |
| Date: | August 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4607 |
|
IP version 4 (IPv4) addresses in the 232/8 (232.0.0.0 to232.255.255.255) range are designated as source-specific multicast(SSM) destination addresses and are reserved for use by source- specific applications and protocols. For IP version 6 (IPv6), the address prefix FF3x::/32 is reserved for source-specific multicast use. This document defines an extension to the Internet network service that applies to datagrams sent to SSM addresses and defines the host and router requirements to support this extension. |
|
| |
| RFC 4610 | Anycast-RP Using Protocol Independent Multicast (PIM) |
| |
| Authors: | D. Farinacci, Y. Cai. |
| Date: | August 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4610 |
|
This specification allows Anycast-RP (Rendezvous Point) to be used inside a domain that runs Protocol Independent Multicast (PIM) only.Other multicast protocols (such as Multicast Source DiscoveryProtocol (MSDP), which has been used traditionally to solve this problem) are not required to support Anycast-RP. |
|
| |
| RFC 4615 | The Advanced Encryption Standard-Cipher-based Message Authentication Code-Pseudo-Random Function-128 (AES-CMAC-PRF-128) Algorithm for the Internet Key Exchange Protocol (IKE) |
| |
| Authors: | J. Song, R. Poovendran, J. Lee, T. Iwata. |
| Date: | August 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4615 |
|
Some implementations of IP Security (IPsec) may want to use a pseudo-random function (PRF) based on the Advanced EncryptionStandard (AES). This memo describes such an algorithm, calledAES-CMAC-PRF-128. It supports fixed and variable key sizes. |
|
| |
| RFC 4616 | The PLAIN Simple Authentication and Security Layer (SASL) Mechanism |
| |
|
|
This document defines a simple clear-text user/password SimpleAuthentication and Security Layer (SASL) mechanism called the PLAIN mechanism. The PLAIN mechanism is intended to be used, in combination with data confidentiality services provided by a lower layer, in protocols that lack a simple password authentication command. |
|
| |
| RFC 4618 | Encapsulation Methods for Transport of PPP/High-Level Data Link Control (HDLC) over MPLS Networks |
| |
| Authors: | L. Martini, E. Rosen, G. Heron, A. Malis. |
| Date: | September 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4618 |
|
A pseudowire (PW) can be used to carry Point to Point Protocol (PPP) or High-Level Data Link Control (HDLC) Protocol Data Units over aMultiprotocol Label Switching (MPLS) network without terminating thePPP/HDLC protocol. This enables service providers to offer"emulated" HDLC, or PPP link services over existing MPLS networks.This document specifies the encapsulation of PPP/HDLC Packet DataUnits (PDUs) within a pseudowire. |
|
| |
| RFC 4619 | Encapsulation Methods for Transport of Frame Relay over Multiprotocol Label Switching (MPLS) Networks |
| |
| Authors: | L. Martini, Ed., C. Kawa, Ed., A. Malis, Ed.. |
| Date: | September 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4619 |
|
A frame relay pseudowire is a mechanism that exists between a provider's edge network nodes and that supports as faithfully as possible frame relay services over an MPLS packet switched network(PSN). This document describes the detailed encapsulation necessary to transport frame relay packets over an MPLS network. |
|
| |
| RFC 4622 | Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP) |
| |
|
|
This document defines the use of Internationalized ResourceIdentifiers (IRIs) and Uniform Resource Identifiers (URIs) in identifying or interacting with entities that can communicate via theExtensible Messaging and Presence Protocol (XMPP). |
|
| |
| RFC 4623 | Pseudowire Emulation Edge-to-Edge (PWE3) Fragmentation and Reassembly |
| |
| Authors: | A. Malis, M. Townsley. |
| Date: | August 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4623 |
|
This document defines a generalized method of performing fragmentation for use by Pseudowire Emulation Edge-to-Edge (PWE3) protocols and services. |
|
| |
| RFC 4625 | Fibre Channel Routing Information MIB |
| |
| Authors: | C. DeSanti, K. McCloghrie, S. Kode, S. Gai. |
| Date: | September 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4625 |
|
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 routing within a Fibre Channel fabric, which is independent of the usage of a particular routing protocol. |
|
| |
| RFC 4626 | MIB for Fibre Channel's Fabric Shortest Path First (FSPF) Protocol |
| |
| Authors: | C. DeSanti, V. Gaonkar, K. McCloghrie, S. Gai. |
| Date: | September 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4626 |
|
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 network's Fabric Shortest Path First (FSPF) routing protocol. |
|
| |
| RFC 4629 | RTP Payload Format for ITU-T Rec |
| |
| Authors: | H.263 Video. J. Ott, C. Bormann, G. Sullivan, S. Wenger, R. Even, Ed.. |
| Date: | January 2007 |
| Formats: | txt html json |
| Obsoletes: | RFC 2429 |
| Updates: | RFC 3555 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4629 |
|
This document describes a scheme to packetize an H.263 video stream for transport using the Real-time Transport Protocol (RTP) with any of the underlying protocols that carry RTP.
The document also describes the syntax and semantics of the SessionDescription Protocol (SDP) parameters needed to support the H.263 video codec.
The document obsoletes RFC 2429 and updates the H263-1998 andH263-2000 MIME media type in RFC 3555. |
|
| |
| RFC 4630 | Update to DirectoryString Processing in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile |
| |
|
|
This document updates the handling of DirectoryString in the InternetX.509 Public Key Infrastructure Certificate and CertificateRevocation List (CRL) Profile, which is published in RFC 3280. The use of UTF8String and PrintableString are the preferred encoding.The requirement for exclusive use of UTF8String after December 31,2003 is removed. |
|
| |
| RFC 4631 | Link Management Protocol (LMP) Management Information Base (MIB) |
| |
| Authors: | M. Dubuc, T. Nadeau, J. Lang, E. McGinnis, A. Farrel. |
| Date: | September 2006 |
| Formats: | txt html json |
| Obsoletes: | RFC 4327 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4631 |
|
This document provides minor corrections to and obsoletes RFC 4327.
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 4635 | HMAC SHA (Hashed Message Authentication Code, Secure Hash Algorithm) TSIG Algorithm Identifiers |
| |
|
|
Use of the Domain Name System TSIG resource record requires specification of a cryptographic message authentication code.Currently, identifiers have been specified only for HMAC MD5 (HashedMessage Authentication Code, Message Digest 5) and GSS (GenericSecurity Service) TSIG algorithms. This document standardizes identifiers and implementation requirements for additional HMAC SHA(Secure Hash Algorithm) TSIG algorithms and standardizes how to specify and handle the truncation of HMAC values in TSIG. |
|
| |
| RFC 4636 | Foreign Agent Error Extension for Mobile IPv4 |
| |
|
|
This document specifies a new extension for use by Foreign Agents operating Mobile IP for IPv4. Currently, a foreign agent cannot supply status information without destroying the ability for a mobile node to verify authentication data supplied by the home agent. The new extension solves this problem by making a better place for the foreign agent to provide its status information to the mobile node. |
|
| |
| RFC 4639 | Cable Device Management Information Base for Data-Over-Cable Service Interface Specification (DOCSIS) Compliant Cable Modems and Cable Modem Termination Systems |
| |
|
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it defines a basic set of managed objects for SimpleNetwork Management Protocol (SNMP)-based management of Data OverCable Service Interface Specification (DOCSIS)-compliant Cable Modems and Cable Modem Termination Systems.
This memo obsoletes RFC 2669. |
|
| |
| RFC 4642 | Using Transport Layer Security (TLS) with Network News Transfer Protocol (NNTP) |
| |
|
|
This memo defines an extension to the Network News Transfer Protocol(NNTP) that allows an NNTP client and server to use Transport LayerSecurity (TLS). The primary goal is to provide encryption for single-link confidentiality purposes, but data integrity, (optional) certificate-based peer entity authentication, and (optional) data compression are also possible. |
|
| |
| RFC 4643 | Network News Transfer Protocol (NNTP) Extension for Authentication |
| |
| Authors: | J. Vinocur, K. Murchison. |
| Date: | October 2006 |
| Formats: | txt html json |
| Updates: | RFC 2980 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4643 |
|
This document defines an extension to the Network News TransferProtocol (NNTP) that allows a client to indicate an authentication mechanism to the server, to perform an authentication protocol exchange, and optionally to negotiate a security layer for subsequent protocol interactions during the remainder of an NNTP session.
This document updates and formalizes the AUTHINFO USER/PASS authentication method specified in RFC 2980 and deprecates theAUTHINFO SIMPLE and AUTHINFO GENERIC authentication methods.Additionally, this document defines a profile of the SimpleAuthentication and Security Layer (SASL) for NNTP. |
|
| |
| RFC 4644 | Network News Transfer Protocol (NNTP) Extension for Streaming Feeds |
| |
| Authors: | J. Vinocur, K. Murchison. |
| Date: | October 2006 |
| Formats: | txt json html |
| Updates: | RFC 2980 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4644 |
|
This memo defines an extension to the Network News Transfer Protocol(NNTP) to provide asynchronous (otherwise known as "streaming") transfer of articles. This allows servers to transfer articles to other servers with much greater efficiency.
This document updates and formalizes the CHECK and TAKETHIS commands specified in RFC 2980 and deprecates the MODE STREAM command. |
|
| |
| RFC 4648 | The Base16, Base32, and Base64 Data Encodings |
| |
|
|
This document describes the commonly used base 64, base 32, and base16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. |
|
| |
| RFC 4649 | Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Remote-ID Option |
| |
| Authors: | B. Volz. |
| Date: | August 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4649 |
|
This memo defines a new Relay Agent Remote-ID option for the DynamicHost Configuration Protocol for IPv6 (DHCPv6). This option is theDHCPv6 equivalent for the Dynamic Host Configuration Protocol forIPv4 (DHCPv4) Relay Agent Option's Remote-ID suboption as specified in RFC 3046. |
|
| |
| RFC 4650 | HMAC-Authenticated Diffie-Hellman for Multimedia Internet KEYing (MIKEY) |
| |
| Authors: | M. Euchner. |
| Date: | September 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4650 |
|
This document describes a lightweight point-to-point key management protocol variant for the multimedia Internet keying (MIKEY) protocolMIKEY, as defined in RFC 3830. In particular, this variant deploys the classic Diffie-Hellman key agreement protocol for key establishment featuring perfect forward secrecy in conjunction with a keyed hash message authentication code for achieving mutual authentication and message integrity of the key management messages exchanged. This protocol addresses the security and performance constraints of multimedia key management in MIKEY. |
|
| |
| RFC 4656 | A One-way Active Measurement Protocol (OWAMP) |
| |
|
|
The One-Way Active Measurement Protocol (OWAMP) measures unidirectional characteristics such as one-way delay and one-way loss. High-precision measurement of these one-way IP performance metrics became possible with wider availability of good time sources(such as GPS and CDMA). OWAMP enables the interoperability of these measurements. |
|
| |
| RFC 4659 | BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN |
| |
| Authors: | J. De Clercq, D. Ooms, M. Carugi, F. Le Faucheur. |
| Date: | September 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4659 |
|
This document describes a method by which a Service Provider may use its packet-switched backbone to provide Virtual Private Network (VPN) services for its IPv6 customers. This method reuses, and extends where necessary, the "BGP/MPLS IP VPN" method for support of IPv6.In BGP/MPLS IP VPN, "Multiprotocol BGP" is used for distributing IPv4VPN routes over the service provider backbone, and MPLS is used to forward IPv4 VPN packets over the backbone. This document defines anIPv6 VPN address family and describes the corresponding IPv6 VPN route distribution in "Multiprotocol BGP".
This document defines support of the IPv6 VPN service over both anIPv4 and an IPv6 backbone, and for using various tunneling techniques over the core, including MPLS, IP-in-IP, Generic RoutingEncapsulation (GRE) and IPsec protected tunnels. The inter-working between an IPv4 site and an IPv6 site is outside the scope of this document. |
|
| |
| RFC 4660 | Functional Description of Event Notification Filtering |
| |
| Authors: | H. Khartabil, E. Leppanen, M. Lonnfors, J. Costa-Requena. |
| Date: | September 2006 |
| Formats: | txt json html |
| Updated by: | RFC 6665 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4660 |
|
The SIP event notification framework describes the usage of theSession Initiation Protocol (SIP) for subscriptions and notifications of changes to the state of a resource. The document does not describe a mechanism whereby filtering of event notification information can be achieved.
This document describes the operations a subscriber performs in order to put filtering rules associated with a subscription to event notification information in place. The handling, by the subscriber, of responses to subscriptions carrying filtering rules and the handling of notifications with filtering rules applied to them are also described. Furthermore, the document conveys how the notifier behaves when receiving such filtering rules and how a notification is constructed. |
|
| |
| RFC 4661 | An Extensible Markup Language (XML)-Based Format for Event Notification Filtering |
| |
| Authors: | H. Khartabil, E. Leppanen, M. Lonnfors, J. Costa-Requena. |
| Date: | September 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4661 |
|
The SIP event notification framework describes the usage of theSession Initiation Protocol (SIP) for subscriptions and notifications of changes to a state of a resource. The document does not describe a mechanism whereby filtering of event notification information can be achieved. Filtering is a mechanism for defining the preferred notification information to be delivered and for specifying triggers that cause that information to be delivered. In order to enable this, a format is needed to enable the subscriber to describe the state changes of a resource that cause notifications to be sent to it and what those notifications are to contain. This document presents a format in the form of an XML document. |
|
| |
| RFC 4662 | A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists |
| |
| Authors: | A. B. Roach, B. Campbell, J. Rosenberg. |
| Date: | August 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4662 |
|
This document presents an extension to the Session InitiationProtocol (SIP)-Specific Event Notification mechanism for subscribing to a homogeneous list of resources. Instead of sending a SUBSCRIBE for each resource individually, the subscriber can subscribe to an entire list and then receive notifications when the state of any of the resources in the list changes. |
|
| |
| RFC 4666 | Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA) |
| |
| Authors: | K. Morneault, Ed., J. Pastor-Balbas, Ed.. |
| Date: | September 2006 |
| Formats: | txt html json |
| Obsoletes: | RFC 3332 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4666 |
|
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 two IP- 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. This document obsoletesRFC 3332. |
|
| |
| RFC 4667 | Layer 2 Virtual Private Network (L2VPN) Extensions for Layer 2 Tunneling Protocol (L2TP) |
| |
| Authors: | W. Luo. |
| Date: | September 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4667 |
|
The Layer 2 Tunneling Protocol (L2TP) provides a standard method for setting up and managing L2TP sessions to tunnel a variety of L2 protocols. One of the reference models supported by L2TP describes the use of an L2TP session to connect two Layer 2 circuits attached to a pair of peering L2TP Access Concentrators (LACs), which is a basic form of Layer 2 Virtual Private Network (L2VPN). This document defines the protocol extensions for L2TP to set up different types ofL2VPNs in a unified fashion. |
|
| |
| RFC 4668 | RADIUS Authentication Client MIB for IPv6 |
| |
|
|
This memo defines a set of extensions that 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.
This memo obsoletes RFC 2618 by deprecating the MIB table containingIPv4-only address formats and defining a new table to add support for version-neutral IP address formats. The remaining MIB objects fromRFC 2618 are carried forward into this document. The memo also addsUNITS and REFERENCE clauses to selected objects. |
|
| |
| RFC 4669 | RADIUS Authentication Server MIB for IPv6 |
| |
|
|
This memo defines a set of extensions that 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.
This memo obsoletes RFC 2619 by deprecating the MIB table containingIPv4-only address formats and defining a new table to add support for version-neutral IP address formats. The remaining MIB objects fromRFC 2619 are carried forward into this document. This memo also addsUNITS and REFERENCE clauses to selected objects. |
|
| |
| RFC 4675 | RADIUS Attributes for Virtual LAN and Priority Support |
| |
| Authors: | P. Congdon, M. Sanchez, B. Aboba. |
| Date: | September 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4675 |
|
This document proposes additional Remote Authentication Dial-In UserService (RADIUS) attributes for dynamic Virtual LAN assignment and prioritization, for use in provisioning of access to IEEE 802 local area networks. These attributes are usable within either RADIUS orDiameter. |
|
| |
| RFC 4676 | Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information |
| |
|
|
This document specifies a Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) option containing the civic location of the client or theDHCP server. The Location Configuration Information (LCI) includes information about the country, administrative units such as states, provinces, and cities, as well as street addresses, postal community names, and building information. The option allows multiple renditions of the same address in different scripts and languages. |
|
| |
| RFC 4680 | TLS Handshake Message for Supplemental Data |
| |
|
|
This specification defines a TLS handshake message for exchange of supplemental application data. TLS hello message extensions are used to determine which supplemental data types are supported by both theTLS client and the TLS server. Then, the supplemental data handshake message is used to exchange the data. Other documents will define the syntax of these extensions and the syntax of the associated supplemental data types. |
|
| |
| RFC 4681 | TLS User Mapping Extension |
| |
|
|
This document specifies a TLS extension that enables clients to send generic user mapping hints in a supplemental data handshake message defined in RFC 4680. One such mapping hint is defined in an informative section, the UpnDomainHint, which may be used by a server to locate a user in a directory database. Other mapping hints may be defined in other documents in the future. |
|
| |
| RFC 4682 | Multimedia Terminal Adapter (MTA) Management Information Base for PacketCable- and IPCablecom-Compliant Devices |
| |
| Authors: | E. Nechamkin, J-F. Mule. |
| Date: | December 2006 |
| Formats: | txt html json |
| Updated by: | RFC 9141 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4682 |
|
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 SimpleNetwork Management Protocol (SNMP)-based management of PacketCable- and IPCablecom-compliant Multimedia Terminal Adapter devices. |
|
| |
| RFC 4683 | Internet X.509 Public Key Infrastructure Subject Identification Method (SIM) |
| |
| Authors: | J. Park, J. Lee, H. Lee, S. Park, T. Polk. |
| Date: | October 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4683 |
|
This document defines the Subject Identification Method (SIM) for including a privacy-sensitive identifier in the subjectAltName extension of a certificate.
The SIM is an optional feature that may be used by relying parties to determine whether the subject of a particular certificate is also the person corresponding to a particular sensitive identifier. |
|
| |
| RFC 4684 | Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs) |
| |
| Authors: | P. Marques, R. Bonica, L. Fang, L. Martini, R. Raszuk, K. Patel, J. Guichard. |
| Date: | November 2006 |
| Formats: | txt json html |
| Updates: | RFC 4364 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4684 |
|
This document defines Multi-Protocol BGP (MP-BGP) procedures that allow BGP speakers to exchange Route Target reachability information.This information can be used to build a route distribution graph in order to limit the propagation of Virtual Private Network (VPN)Network Layer Reachability Information (NLRI) between different autonomous systems or distinct clusters of the same autonomous system. This document updates RFC 4364. |
|
| |
| RFC 4685 | Atom Threading Extensions |
| |
| Authors: | J. Snell. |
| Date: | September 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4685 |
|
This memo presents a mechanism that allows feeds publishers to express threaded discussions within the Atom Syndication Format. |
|
| |
| RFC 4694 | Number Portability Parameters for the "tel" URI |
| |
| Authors: | J. Yu. |
| Date: | October 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4694 |
|
This document defines five parameters in the "tel" Uniform ResourceIdentifier (URI) to carry the number portability (NP)-related information. Those parameters can be passed to the next-hop network node after an NP database dip has been performed. |
|
| |
| RFC 4695 | RTP Payload Format for MIDI |
| |
| Authors: | J. Lazzaro, J. Wawrzynek. |
| Date: | November 2006 |
| Formats: | txt json html |
| Obsoleted by: | RFC 6295 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4695 |
|
This memo describes a Real-time Transport Protocol (RTP) payload format for the MIDI (Musical Instrument Digital Interface) command language. The format encodes all commands that may legally appear on a MIDI 1.0 DIN cable. The format is suitable for interactive applications (such as network musical performance) and content- delivery applications (such as file streaming). The format may be used over unicast and multicast UDP and TCP, and it defines tools for graceful recovery from packet loss. Stream behavior, including theMIDI rendering method, may be customized during session setup. The format also serves as a mode for the mpeg4-generic format, to support the MPEG 4 Audio Object Types for General MIDI, Downloadable SoundsLevel 2, and Structured Audio. |
|
| |
| RFC 4698 | IRIS: An Address Registry (areg) Type for the Internet Registry Information Service |
| |
| Authors: | E. Gunduz, A. Newton, S. Kerr. |
| Date: | October 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4698 |
|
This document describes an IRIS registry schema for IP address andAutonomous System Number information. The schema extends the necessary query and result operations of IRIS to provide the functional information service needs for syntaxes and results used byInternet Protocol address registries. |
|
| |
| RFC 4701 | A DNS Resource Record (RR) for Encoding Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR) |
| |
| Authors: | M. Stapp, T. Lemon, A. Gustafsson. |
| Date: | October 2006 |
| Formats: | txt json html |
| Updated by: | RFC 5494 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4701 |
|
It is possible for Dynamic Host Configuration Protocol (DHCP) clients to attempt to update the same DNS Fully Qualified Domain Name (FQDN) or to update a DNS FQDN that has been added to the DNS for another purpose as they obtain DHCP leases. Whether the DHCP server or the clients themselves perform the DNS updates, conflicts can arise. To resolve such conflicts, RFC 4703 proposes storing client identifiers in the DNS to unambiguously associate domain names with the DHCP clients to which they refer. This memo defines a distinct ResourceRecord (RR) type for this purpose for use by DHCP clients and servers: the "DHCID" RR. |
|
| |
| RFC 4702 | The Dynamic Host Configuration Protocol (DHCP) Client Fully Qualified Domain Name (FQDN) Option |
| |
| Authors: | M. Stapp, B. Volz, Y. Rekhter. |
| Date: | October 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4702 |
|
This document describes a Dynamic Host Configuration Protocol forIPv4 (DHCPv4) option that can be used to exchange information about aDHCPv4 client's fully qualified domain name and about responsibility for updating the DNS RR related to the client's address assignment. |
|
| |
| RFC 4703 | Resolution of Fully Qualified Domain Name (FQDN) Conflicts among Dynamic Host Configuration Protocol (DHCP) Clients |
| |
| Authors: | M. Stapp, B. Volz. |
| Date: | October 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4703 |
|
The Dynamic Host Configuration Protocol (DHCP) provides a mechanism for host configuration that includes dynamic assignment of IP addresses and fully qualified domain names. To maintain accurate name-to-IP-address and IP-address-to-name mappings in the DNS, these dynamically assigned addresses and fully qualified domain names(FQDNs) require updates to the DNS. This document identifies situations in which conflicts in the use of fully qualified domain names may arise among DHCP clients and servers, and it describes a strategy for the use of the DHCID DNS resource record (RR) in resolving those conflicts. |
|
| |
| RFC 4704 | The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option |
| |
| Authors: | B. Volz. |
| Date: | October 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4704 |
|
This document specifies a new Dynamic Host Configuration Protocol forIPv6 (DHCPv6) option that can be used to exchange information about aDHCPv6 client's Fully Qualified Domain Name (FQDN) and about responsibility for updating DNS resource records (RRs) related to the client's address assignments. |
|
| |
| RFC 4706 | Definitions of Managed Objects for Asymmetric Digital Subscriber Line 2 (ADSL2) |
| |
| Authors: | M. Morgenstern, M. Dodge, S. Baillie, U. Bonollo. |
| Date: | November 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4706 |
|
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 parameters of the"Asymmetric Digital Subscriber Line" family of interface types: ADSL,ADSL2, ADSL2+, and their variants. |
|
| |
| RFC 4710 | Real-time Application Quality-of-Service Monitoring (RAQMON) Framework |
| |
| Authors: | A. Siddiqui, D. Romascanu, E. Golovinsky. |
| Date: | October 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4710 |
|
There is a need to monitor end-devices such as IP phones, pagers,Instant Messaging clients, mobile phones, and various other handheld computing devices. This memo extends the remote network monitoring(RMON) family of specifications to allow real-time quality-of-service(QoS) monitoring of various applications that run on these devices and allows this information to be integrated with the RMON family using the Simple Network Management Protocol (SNMP). This memo defines the framework, architecture, relevant metrics, and transport requirements for real-time QoS monitoring of applications. |
|
| |
| RFC 4711 | Real-time Application Quality-of-Service Monitoring (RAQMON) MIB |
| |
| Authors: | A. Siddiqui, D. Romascanu, E. Golovinsky. |
| Date: | October 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4711 |
|
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, RFC2819. In particular, it describes managed objects used for real-time application Quality of Service (QoS) monitoring. |
|
| |
| RFC 4712 | Transport Mappings for Real-time Application Quality-of-Service Monitoring (RAQMON) Protocol Data Unit (PDU) |
| |
| Authors: | A. Siddiqui, D. Romascanu, E. Golovinsky, M. Rahman, Y. Kim. |
| Date: | October 2006 |
| Formats: | txt html json |
| Updated by: | RFC 8996 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4712 |
|
This memo specifies two transport mappings of the Real-TimeApplication Quality-of-Service Monitoring (RAQMON) information model defined in RFC 4710 using TCP as a native transport and the SimpleNetwork Management Protocol (SNMP) to carry the RAQMON information from a RAQMON Data Source (RDS) to a RAQMON Report Collector (RRC). |
|
| |
| RFC 4717 | Encapsulation Methods for Transport of Asynchronous Transfer Mode (ATM) over MPLS Networks |
| |
| Authors: | L. Martini, J. Jayakumar, M. Bocci, N. El-Aawar, J. Brayley, G. Koleyni. |
| Date: | December 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4717 |
|
An Asynchronous Transfer Mode (ATM) Pseudowire (PW) is used to carryATM cells over an MPLS network. This enables service providers to offer "emulated" ATM services over existing MPLS networks. This document specifies methods for the encapsulation of ATM cells within a pseudowire. It also specifies the procedures for using a PW to provide an ATM service. |
|
| |
| RFC 4719 | Transport of Ethernet Frames over Layer 2 Tunneling Protocol Version 3 (L2TPv3) |
| |
| Authors: | R. Aggarwal, Ed., M. Townsley, Ed., M. Dos Santos, Ed.. |
| Date: | November 2006 |
| Formats: | txt json html |
| Updated by: | RFC 5641 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4719 |
|
This document describes the transport of Ethernet frames over theLayer 2 Tunneling Protocol, Version 3 (L2TPv3). This includes the transport of Ethernet port-to-port frames as well as the transport ofEthernet VLAN frames. The mechanism described in this document can be used in the creation of Pseudowires to transport Ethernet frames over an IP network. |
|
| |
| RFC 4720 | Pseudowire Emulation Edge-to-Edge (PWE3) Frame Check Sequence Retention |
| |
| Authors: | A. Malis, D. Allan, N. Del Regno. |
| Date: | November 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4720 |
|
This document defines a mechanism for preserving Frame Check Sequence(FCS) through Ethernet, Frame Relay, High-Level Data Link Control(HDLC), and PPP pseudowires. |
|
| |
| RFC 4721 | Mobile IPv4 Challenge/Response Extensions (Revised) |
| |
|
|
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, that extension does not provide the foreign agent any direct guarantee that the protocol is protected from replays and does not allow for the use of existing techniques (such as ChallengeHandshake Authentication Protocol (CHAP)) for authenticating portable computer devices.
In this specification, we define extensions for the Mobile IP AgentAdvertisements and the Registration Request that allow a foreign agent to use a challenge/response mechanism to authenticate the mobile node.
Furthermore, this document updates RFC 3344 by including a new authentication extension called the Mobile-Authentication,Authorization, and Accounting (AAA) Authentication extension. This new extension is provided so that a mobile node can supply credentials for authorization, using commonly available AAA infrastructure elements. This authorization-enabling extension MAY co-exist in the same Registration Request with authentication extensions defined for Mobile IP Registration by RFC 3344. This document obsoletes RFC 3012. |
|
| |
| RFC 4724 | Graceful Restart Mechanism for BGP |
| |
| Authors: | S. Sangli, E. Chen, R. Fernando, J. Scudder, Y. Rekhter. |
| Date: | January 2007 |
| Formats: | txt json html |
| Updated by: | RFC 8538 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4724 |
|
This document describes a mechanism for BGP that would help minimize the negative effects on routing caused by BGP restart. An End-of-RIB marker is specified and can be used to convey routing convergence information. A new BGP capability, termed "Graceful RestartCapability", is defined that would allow a BGP speaker to express its ability to preserve forwarding state during BGP restart. Finally, procedures are outlined for temporarily retaining routing information across a TCP session termination/re-establishment.
The mechanisms described in this document are applicable to all routers, both those with the ability to preserve forwarding state during BGP restart and those without (although the latter need to implement only a subset of the mechanisms described in this document). |
|
| |
| RFC 4727 | Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers |
| |
| Authors: | B. Fenner. |
| Date: | November 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4727 |
|
When experimenting with or extending protocols, it is often necessary to use some sort of protocol number or constant in order to actually test or experiment with the new function, even when testing in a closed environment. This document reserves some ranges of numbers for experimentation purposes in specific protocols where the need to support experimentation has been identified, and it describes the numbers that have already been reserved by other documents. |
|
| |
| RFC 4730 | A Session Initiation Protocol (SIP) Event Package for Key Press Stimulus (KPML) |
| |
| Authors: | E. Burger, M. Dolly. |
| Date: | November 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4730 |
|
This document describes a SIP Event Package "kpml" that enables monitoring of Dual Tone Multi-Frequency (DTMF) signals and usesExtensible Markup Language (XML) documents referred to as Key PressMarkup Language (KPML). The kpml Event Package may be used to support applications consistent with the principles defined in the document titled "A Framework for Application Interaction in theSession Initiation Protocol (SIP)". The event package uses SUBSCRIBE messages and allows for XML documents that define and describe filter specifications for capturing key presses (DTMF Tones) entered at a presentation-free User Interface SIP User Agent (UA). The event package uses NOTIFY messages and allows for XML documents to report the captured key presses (DTMF tones), consistent with the filter specifications, to an Application Server. The scope of this package is for collecting supplemental key presses or mid-call key presses(triggers). |
|
| |
| RFC 4731 | IMAP4 Extension to SEARCH Command for Controlling What Kind of Information Is Returned |
| |
| Authors: | A. Melnikov, D. Cridland. |
| Date: | November 2006 |
| Formats: | txt json html |
| Updated by: | RFC 9394 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4731 |
|
This document extends IMAP (RFC 3501) SEARCH and UID SEARCH commands with several result options, which can control what kind of information is returned. The following result options are defined: minimal value, maximal value, all found messages, and number of found messages. |
|
| |
| RFC 4733 | RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals |
| |
|
|
This memo describes how to carry dual-tone multifrequency (DTMF) signalling, other tone signals, and telephony events in RTP packets.It obsoletes RFC 2833.
This memo captures and expands upon the basic framework defined inRFC 2833, but retains only the most basic event codes. It sets up anIANA registry to which other event code assignments may be added.Companion documents add event codes to this registry relating to modem, fax, text telephony, and channel-associated signalling events.The remainder of the event codes defined in RFC 2833 are conditionally reserved in case other documents revive their use.
This document provides a number of clarifications to the original document. However, it specifically differs from RFC 2833 by removing the requirement that all compliant implementations support the DTMF events. Instead, compliant implementations taking part in out-of-band negotiations of media stream content indicate what events they support. This memo adds three new procedures to the RFC 2833 framework: subdivision of long events into segments, reporting of multiple events in a single packet, and the concept and reporting of state events. |
|
| |
| RFC 4734 | Definition of Events for Modem, Fax, and Text Telephony Signals |
| |
|
|
This memo updates RFC 4733 to add event codes for modem, fax, and text telephony signals when carried in the telephony event RTP payload. It supersedes the assignment of event codes for this purpose in RFC 2833, and therefore obsoletes that part of RFC 2833. |
|
| |
| RFC 4735 | Example Media Types for Use in Documentation |
| |
| Authors: | T. Taylor. |
| Date: | October 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4735 |
|
This document is registration for the 'example' media type and'example' subtypes within the standards tree. The 'example/*' and'*/example' media types are defined for documentation purposes only. |
|
| |
| RFC 4737 | Packet Reordering Metrics |
| |
| Authors: | A. Morton, L. Ciavattone, G. Ramachandran, S. Shalunov, J. Perser. |
| Date: | November 2006 |
| Formats: | txt html json |
| Updated by: | RFC 6248 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4737 |
|
This memo defines metrics to evaluate whether a network has maintained packet order on a packet-by-packet basis. It provides motivations for the new metrics and discusses the measurement issues, including the context information required for all metrics. The memo first defines a reordered singleton, and then uses it as the basis for sample metrics to quantify the extent of reordering in several useful dimensions for network characterization or receiver design.Additional metrics quantify the frequency of reordering and the distance between separate occurrences. We then define a metric oriented toward assessment of reordering effects on TCP. Several examples of evaluation using the various sample metrics are included.An appendix gives extended definitions for evaluating order with packet fragmentation. |
|
| |
| RFC 4738 | MIKEY-RSA-R: An Additional Mode of Key Distribution in Multimedia Internet KEYing (MIKEY) |
| |
| Authors: | D. Ignjatic, L. Dondeti, F. Audet, P. Lin. |
| Date: | November 2006 |
| Formats: | txt json html |
| Updates: | RFC 3830 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4738 |
|
The Multimedia Internet Keying (MIKEY) specification describes several modes of key distribution solution that address multimedia scenarios (e.g., SIP calls and Real Time Streaming Protocol (RTSP) sessions) using pre-shared keys, public keys, and optionally aDiffie-Hellman key exchange. In the public-key mode, the Initiator encrypts a random key with the Responder's public key and sends it to the Responder. In many communication scenarios, the Initiator may not know the Responder's public key, or in some cases the Responder'sID (e.g., call forwarding) in advance. We propose a new MIKEY mode that works well in such scenarios. This mode also enhances the group key management support in MIKEY; it supports member-initiated group key download (in contrast to group manager pushing the group keys to all members). This document updates RFC 3830 with the RSA-R mode. |
|
| |
| RFC 4740 | Diameter Session Initiation Protocol (SIP) Application |
| |
| Authors: | M. Garcia-Martin, Ed., M. Belinchon, M. Pallares-Lopez, C. Canales-Valenzuela, K. Tammi. |
| Date: | November 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4740 |
|
This document specifies the Diameter Session Initiation Protocol(SIP) application. This is a Diameter application that allows aDiameter client to request authentication and authorization information. This application is designed to be used in conjunction with SIP and provides a Diameter client co-located with a SIP server, with the ability to request the authentication of users and authorization of SIP resources usage from a Diameter server. |
|
| |
| RFC 4741 | NETCONF Configuration Protocol |
| |
|
|
The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible MarkupLanguage (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized on top of a simple Remote Procedure Call (RPC) layer. |
|
| |
| RFC 4742 | Using the NETCONF Configuration Protocol over Secure SHell (SSH) |
| |
| Authors: | M. Wasserman, T. Goddard. |
| Date: | December 2006 |
| Formats: | txt json html |
| Obsoleted by: | RFC 6242 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4742 |
|
This document describes a method for invoking and running the NetworkConfiguration Protocol (NETCONF) within a Secure Shell (SSH) session as an SSH subsystem. |
|
| |
| RFC 4745 | Common Policy: A Document Format for Expressing Privacy Preferences |
| |
| Authors: | H. Schulzrinne, H. Tschofenig, J. Morris, J. Cuellar, J. Polk, J. Rosenberg. |
| Date: | February 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4745 |
|
This document defines a framework for authorization policies controlling access to application-specific data. This framework combines common location- and presence-specific authorization aspects. An XML schema specifies the language in which common policy rules are represented. The common policy framework can be extended to other application domains. |
|
| |
| RFC 4747 | The Virtual Fabrics MIB |
| |
| Authors: | S. Kipp, G. Ramkumar, K. McCloghrie. |
| Date: | November 2006 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4747 |
|
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 network's Virtual Fabrics function. |
|
| |
| RFC 4749 | RTP Payload Format for the G.729.1 Audio Codec |
| |
|
|
This document specifies a Real-time Transport Protocol (RTP) payload format to be used for the International Telecommunication Union(ITU-T) G.729.1 audio codec. A media type registration is included for this payload format. |
|
| |
| RFC 4750 | OSPF Version 2 Management Information Base |
| |
| Authors: | D. Joyal, Ed., P. Galecki, Ed., S. Giacalone, Ed., R. Coltun, F. Baker. |
| Date: | December 2006 |
| Formats: | txt html json |
| Obsoletes: | RFC 1850 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4750 |
|
|
|
| |
| RFC 4752 | The Kerberos V5 ("GSSAPI") Simple Authentication and Security Layer (SASL) Mechanism |
| |
|
|
The Simple Authentication and Security Layer (SASL) is a framework for adding authentication support to connection-based protocols.This document describes the method for using the Generic SecurityService Application Program Interface (GSS-API) Kerberos V5 in theSASL.
This document replaces Section 7.2 of RFC 2222, the definition of the"GSSAPI" SASL mechanism. This document, together with RFC 4422, obsoletes RFC 2222. |
|
| |
| RFC 4754 | IKE and IKEv2 Authentication Using the Elliptic Curve Digital Signature Algorithm (ECDSA) |
| |
| Authors: | D. Fu, J. Solinas. |
| Date: | January 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4754 |
|
This document describes how the Elliptic Curve Digital SignatureAlgorithm (ECDSA) may be used as the authentication method within theInternet Key Exchange (IKE) and Internet Key Exchange version 2(IKEv2) protocols. ECDSA may provide benefits including computational efficiency, small signature sizes, and minimal bandwidth compared to other available digital signature methods.This document adds ECDSA capability to IKE and IKEv2 without introducing any changes to existing IKE operation. |
|
| |
| RFC 4755 | IP over InfiniBand: Connected Mode |
| |
| Authors: | V. Kashyap. |
| Date: | December 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4755 |
|
This document specifies transmission of IPv4/IPv6 packets and address resolution over the connected modes of InfiniBand. |
|
| |
| RFC 4756 | Forward Error Correction Grouping Semantics in Session Description Protocol |
| |
|
|
This document defines the semantics that allow for grouping ofForward Error Correction (FEC) streams with the protected payload streams in Session Description Protocol (SDP). The semantics defined in this document are to be used with "Grouping of Media Lines in theSession Description Protocol" (RFC 3388) to group together "m" lines in the same session. |
|
| |
| RFC 4759 | The ENUM Dip Indicator Parameter for the "tel" URI |
| |
| Authors: | R. Stastny, R. Shockey, L. Conroy. |
| Date: | December 2006 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4759 |
|
This document defines a new parameter "enumdi" for the "tel" UniformResource Identifier (URI) to support the handling of ENUM queries inVoice over Internet Protocol (VoIP) network elements. A VoIP network element may receive a URI containing an E.164 number, where that URI contains an "enumdi" parameter. The presence of the "enumdi" parameter indicates that an ENUM query has already been performed on the E.164 number by a previous VoIP network element. Equally, if aVoIP network element sends such a URI, it asserts that an ENUM query has been carried out on this number. |
|
| |
| RFC 4761 | Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling |
| |
|
|
Virtual Private LAN Service (VPLS), also known as Transparent LANService and Virtual Private Switched Network service, is a usefulService Provider offering. The service offers a Layer 2 VirtualPrivate Network (VPN); however, in the case of VPLS, the customers in the VPN are connected by a multipoint Ethernet LAN, in contrast to the usual Layer 2 VPNs, which are point-to-point in nature.
This document describes the functions required to offer VPLS, a mechanism for signaling a VPLS, and rules for forwarding VPLS frames across a packet switched network. |
|
| |
| RFC 4762 | Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling |
| |
| Authors: | M. Lasserre, Ed., V. Kompella, Ed.. |
| Date: | January 2007 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4762 |
|
This document describes a Virtual Private LAN Service (VPLS) solution using pseudowires, a service previously implemented over other tunneling technologies and known as Transparent LAN Services (TLS).A VPLS creates an emulated LAN segment for a given set of users; i.e., it creates a Layer 2 broadcast domain that is fully capable of learning and forwarding on Ethernet MAC addresses and that is closed to a given set of users. Multiple VPLS services can be supported from a single Provider Edge (PE) node.
This document describes the control plane functions of signaling pseudowire labels using Label Distribution Protocol (LDP), extendingRFC 4447. It is agnostic to discovery protocols. The data plane functions of forwarding are also described, focusing in particular on the learning of MAC addresses. The encapsulation of VPLS packets is described by RFC 4448. |
|
| |
| RFC 4769 | IANA Registration for an Enumservice Containing Public Switched Telephone Network (PSTN) Signaling Information |
| |
| Authors: | J. Livingood, R. Shockey. |
| Date: | November 2006 |
| Formats: | txt html json |
| Updated by: | RFC 6118 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4769 |
|
This document registers the Enumservice type "pstn" and subtype "tel" using the URI scheme 'tel', as well as the subtype "sip" using theURI scheme 'sip' as per the IANA registration process defined in theENUM specification, RFC 3761. This Enumservice is used to facilitate the routing of telephone calls in those countries where number portability exists. |
|
| |
| RFC 4770 | vCard Extensions for Instant Messaging (IM) |
| |
| Authors: | C. Jennings, J. Reschke, Ed.. |
| Date: | January 2007 |
| Formats: | txt html json |
| Obsoleted by: | RFC 6350 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4770 |
|
This document describes an extension to vCard to support InstantMessaging (IM) and Presence Protocol (PP) applications. IM and PP are becoming increasingly common ways of communicating, and users want to save this contact information in their address books. It allows a URI that is associated with IM or PP to be specified inside a vCard. |
|
| |
| RFC 4771 | Integrity Transform Carrying Roll-Over Counter for the Secure Real-time Transport Protocol (SRTP) |
| |
| Authors: | V. Lehtovirta, M. Naslund, K. Norrman. |
| Date: | January 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4771 |
|
This document defines an integrity transform for Secure Real-timeTransport Protocol (SRTP; see RFC 3711), which allows the roll-over counter (ROC) to be transmitted in SRTP packets as part of the authentication tag. The need for sending the ROC in SRTP packets arises in situations where the receiver joins an ongoing SRTP session and needs to quickly and robustly synchronize. The mechanism also enhances SRTP operation in cases where there is a risk of losing sender-receiver synchronization. |
|
| |
| RFC 4776 | Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information |
| |
|
|
This document specifies a Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) option containing the civic location of the client or theDHCP server. The Location Configuration Information (LCI) includes information about the country, administrative units such as states, provinces, and cities, as well as street addresses, postal community names, and building information. The option allows multiple renditions of the same address in different scripts and languages. |
|
| |
| RFC 4780 | Management Information Base for the Session Initiation Protocol (SIP) |
| |
| Authors: | K. Lingle, J-F. Mule, J. Maeng, D. Walker. |
| Date: | April 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4780 |
|
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 manage Session Initiation Protocol (SIP) entities, which include UserAgents, and Proxy, Redirect and Registrar servers. |
|
| |
| RFC 4781 | Graceful Restart Mechanism for BGP with MPLS |
| |
| Authors: | Y. Rekhter, R. Aggarwal. |
| Date: | January 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4781 |
|
A mechanism for BGP that helps minimize the negative effects on routing caused by BGP restart has already been developed and is described in a separate document ("Graceful Restart Mechanism forBGP"). This document extends this mechanism to minimize the negative effects on MPLS forwarding caused by the Label Switching Router's(LSR's) control plane restart, and specifically by the restart of itsBGP component when BGP is used to carry MPLS labels and the LSR is capable of preserving the MPLS forwarding state across the restart.
The mechanism described in this document is agnostic with respect to the types of the addresses carried in the BGP Network LayerReachability Information (NLRI) field. As such, it works in conjunction with any of the address families that could be carried inBGP (e.g., IPv4, IPv6, etc.). |
|
| |
| RFC 4783 | GMPLS - Communication of Alarm Information |
| |
|
|
This document describes an extension to Generalized MPLS (Multi-Protocol Label Switching) signaling to support communication of alarm information. GMPLS signaling already supports the control of alarm reporting, but not the communication of alarm information. This document presents both a functional description and GMPLS-RSVP specifics of such an extension. This document also proposes modification of the RSVP ERROR_SPEC object.
This document updates RFC 3473, "Generalized Multi-Protocol LabelSwitching (GMPLS) Signaling Resource ReserVation Protocol-TrafficEngineering (RSVP-TE) Extensions", through the addition of new, optional protocol elements. It does not change, and is fully backward compatible with, the procedures specified in RFC 3473. |
|
| |
| RFC 4785 | Pre-Shared Key (PSK) Ciphersuites with NULL Encryption for Transport Layer Security (TLS) |
| |
| Authors: | U. Blumenthal, P. Goel. |
| Date: | January 2007 |
| Formats: | txt html json |
| Updated by: | RFC 8996 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4785 |
|
This document specifies authentication-only ciphersuites (with no encryption) for the Pre-Shared Key (PSK) based Transport LayerSecurity (TLS) protocol. These ciphersuites are useful when authentication and integrity protection is desired, but confidentiality is not needed or not permitted. |
|
| |
| RFC 4788 | Enhancements to RTP Payload Formats for EVRC Family Codecs |
| |
|
|
This document updates the Enhanced Variable Rate Codec (EVRC) RTP payload formats defined in RFC 3558 with several enhancements and extensions. In particular, it defines support for the header-free and interleaved/bundled packet formats for the EVRC-B codec, a new compact bundled format for the EVRC and EVRC-B codecs, as well as discontinuous transmission (DTX) support for EVRC and EVRC-B-encoded speech transported via RTP. Voice over IP (VoIP) applications operating over low bandwidth dial-up and wireless networks require such enhancements for efficient use of the bandwidth. |
|
| |
| RFC 4789 | Simple Network Management Protocol (SNMP) over IEEE 802 Networks |
| |
|
|
This document specifies how Simple Network Management Protocol (SNMP) messages can be transmitted directly over IEEE 802 networks.
This document obsoletes RFC 1089. |
|
| |
| RFC 4790 | Internet Application Protocol Collation Registry |
| |
| Authors: | C. Newman, M. Duerst, A. Gulbrandsen. |
| Date: | March 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4790 |
|
Many Internet application protocols include string-based lookup, searching, or sorting operations. However, the problem space for searching and sorting international strings is large, not fully explored, and is outside the area of expertise for the InternetEngineering Task Force (IETF). Rather than attempt to solve such a large problem, this specification creates an abstraction framework so that application protocols can precisely identify a comparison function, and the repertoire of comparison functions can be extended in the future. |
|
| |
| RFC 4791 | Calendaring Extensions to WebDAV (CalDAV) |
| |
|
|
This document defines extensions to the Web Distributed Authoring andVersioning (WebDAV) protocol to specify a standard way of accessing, managing, and sharing calendaring and scheduling information based on the iCalendar format. This document defines the "calendar-access" feature of CalDAV. |
|
| |
| RFC 4792 | Encoding Instructions for the Generic String Encoding Rules (GSER) |
| |
|
|
Abstract Syntax Notation One (ASN.1) defines a general framework for annotating types in an ASN.1 specification with encoding instructions that alter how values of those types are encoded according to ASN.1 encoding rules. This document defines the supporting notation for encoding instructions that apply to the Generic String Encoding Rules(GSER) and, in particular, defines an encoding instruction to provide a machine-processable representation for the declaration of a GSERChoiceOfStrings type. |
|
| |
| RFC 4796 | The Session Description Protocol (SDP) Content Attribute |
| |
| Authors: | J. Hautakorpi, G. Camarillo. |
| Date: | February 2007 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4796 |
|
This document defines a new Session Description Protocol (SDP) media- level attribute, 'content'. The 'content' attribute defines the content of the media stream to a more detailed level than the media description line. The sender of an SDP session description can attach the 'content' attribute to one or more media streams. The receiving application can then treat each media stream differently(e.g., show it on a big or small screen) based on its content. |
|
| |
| RFC 4798 | Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE) |
| |
| Authors: | J. De Clercq, D. Ooms, S. Prevost, F. Le Faucheur. |
| Date: | February 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4798 |
|
This document explains how to interconnect IPv6 islands over aMultiprotocol Label Switching (MPLS)-enabled IPv4 cloud. This approach relies on IPv6 Provider Edge routers (6PE), which are DualStack in order to connect to IPv6 islands and to the MPLS core, which is only required to run IPv4 MPLS. The 6PE routers exchange the IPv6 reachability information transparently over the core using theMultiprotocol Border Gateway Protocol (MP-BGP) over IPv4. In doing so, the BGP Next Hop field is used to convey the IPv4 address of the6PE router so that dynamically established IPv4-signaled MPLS LabelSwitched Paths (LSPs) can be used without explicit tunnel configuration. |
|
| |
| RFC 4801 | Definitions of Textual Conventions for Generalized Multiprotocol Label Switching (GMPLS) Management |
| |
| Authors: | T. Nadeau, Ed., A. Farrel, Ed.. |
| Date: | February 2007 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4801 |
|
This document defines a Management Information Base (MIB) module that contains textual conventions (TCs) to represent commonly usedGeneralized Multiprotocol Label Switching (GMPLS) management information. The intent is that these textual conventions will be imported and used in GMPLS-related MIB modules that would otherwise define their own representations. |
|
| |
| RFC 4802 | Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base |
| |
| Authors: | T. Nadeau, Ed., A. Farrel, Ed.. |
| Date: | February 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4802 |
|
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 GeneralizedMultiprotocol Label Switching (GMPLS)-based traffic engineering. |
|
| |
| RFC 4803 | Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR) Management Information Base |
| |
| Authors: | T. Nadeau, Ed., A. Farrel, Ed.. |
| Date: | February 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4803 |
|
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 a Generalized Multiprotocol Label Switching (GMPLS) LabelSwitching Router (LSR). |
|
| |
| RFC 4804 | Aggregation of Resource ReSerVation Protocol (RSVP) Reservations over MPLS TE/DS-TE Tunnels |
| |
| Authors: | F. Le Faucheur, Ed.. |
| Date: | February 2007 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4804 |
|
RFC 3175 specifies aggregation of Resource ReSerVation Protocol(RSVP) end-to-end reservations over aggregate RSVP reservations.This document specifies aggregation of RSVP end-to-end reservations over MPLS Traffic Engineering (TE) tunnels or MPLS Diffserv-awareMPLS Traffic Engineering (DS-TE) tunnels. This approach is based onRFC 3175 and simply modifies the corresponding procedures for operations over MPLS TE tunnels instead of aggregate RSVP reservations. This approach can be used to achieve admission control of a very large number of flows in a scalable manner since the devices in the core of the network are unaware of the end-to-end RSVP reservations and are only aware of the MPLS TE tunnels. |
|
| |
| RFC 4805 | Definitions of Managed Objects for the DS1, J1, E1, DS2, and E2 Interface Types |
| |
|
|
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, J1, E1,DS2, and E2 interfaces. This document is a companion to the documents that define managed objects for the DS0, DS3/E3, andSynchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH)Interface Types.
This document obsoletes RFC 3895. |
|
| |
| RFC 4806 | Online Certificate Status Protocol (OCSP) Extensions to IKEv2 |
| |
| Authors: | M. Myers, H. Tschofenig. |
| Date: | February 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4806 |
|
While the Internet Key Exchange Protocol version 2 (IKEv2) supports public key based authentication, the corresponding use of in-bandCertificate Revocation Lists (CRL) is problematic due to unboundedCRL size. The size of an Online Certificate Status Protocol (OCSP) response is however well-bounded and small. This document defines the "OCSP Content" extension to IKEv2. A CERTREQ payload with "OCSPContent" identifies zero or more trusted OCSP responders and is a request for inclusion of an OCSP response in the IKEv2 handshake. A cooperative recipient of such a request responds with a CERT payload containing the appropriate OCSP response. This content is recognizable via the same "OCSP Content" identifier.
When certificates are used with IKEv2, the communicating peers need a mechanism to determine the revocation status of the peer's certificate. OCSP is one such mechanism. This document applies whenOCSP is desired and security policy prevents one of the IKEv2 peers from accessing the relevant OCSP responder directly. Firewalls are often deployed in a manner that prevents such access by IKEv2 peers outside of an enterprise network. |
|
| |
| RFC 4807 | IPsec Security Policy Database Configuration MIB |
| |
| Authors: | M. Baer, R. Charlet, W. Hardaker, R. Story, C. Wang. |
| Date: | March 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4807 |
|
This document defines a Structure of Management Information Version 2(SMIv2) Management Information Base (MIB) module for configuring the security policy database of a device implementing the IPsec protocol.The policy-based packet filtering and the corresponding execution of actions described in this document are of a more general nature than for IPsec configuration alone, such as for configuration of a firewall. This MIB module is designed to be extensible with other enterprise or standards-based defined packet filters and actions. |
|
| |
| RFC 4815 | RObust Header Compression (ROHC): Corrections and Clarifications to RFC 3095 |
| |
|
|
RFC 3095 defines the RObust Header Compression (ROHC) framework and profiles for IP (Internet Protocol), UDP (User Datagram Protocol),RTP (Real-Time Transport Protocol), and ESP (Encapsulating SecurityPayload). Some parts of the specification are unclear or contain errors that may lead to misinterpretations that may impair interoperability between different implementations. This document provides corrections, additions, and clarifications to RFC 3095; this document thus updates RFC 3095. In addition, other clarifications related to RFC 3241 (ROHC over PPP), RFC 3843 (ROHC IP profile) andRFC 4109 (ROHC UDP-Lite profiles) are also provided. |
|
| |
| RFC 4816 | Pseudowire Emulation Edge-to-Edge (PWE3) Asynchronous Transfer Mode (ATM) Transparent Cell Transport Service |
| |
| Authors: | A. Malis, L. Martini, J. Brayley, T. Walsh. |
| Date: | February 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4816 |
|
The document describes a transparent cell transport service that makes use of the "N-to-one" cell relay mode for Pseudowire EmulationEdge-to-Edge (PWE3) Asynchronous Transfer-Mode (ATM) cell encapsulation. |
|
| |
| RFC 4817 | Encapsulation of MPLS over Layer 2 Tunneling Protocol Version 3 |
| |
| Authors: | M. Townsley, C. Pignataro, S. Wainner, T. Seely, J. Young. |
| Date: | March 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4817 |
|
The Layer 2 Tunneling Protocol, Version 3 (L2TPv3) defines a protocol for tunneling a variety of payload types over IP networks. This document defines how to carry an MPLS label stack and its payload over the L2TPv3 data encapsulation. This enables an application that traditionally requires an MPLS-enabled core network, to utilize anL2TPv3 encapsulation over an IP network instead. |
|
| |
| RFC 4818 | RADIUS Delegated-IPv6-Prefix Attribute |
| |
| Authors: | J. Salowey, R. Droms. |
| Date: | April 2007 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4818 |
|
This document defines a RADIUS (Remote Authentication Dial In UserService) attribute that carries an IPv6 prefix that is to be delegated to the user. This attribute is usable within either RADIUS or Diameter. |
|
| |
| RFC 4819 | Secure Shell Public Key Subsystem |
| |
| Authors: | J. Galbraith, J. Van Dyke, J. Bright. |
| Date: | March 2007 |
| Formats: | txt json html |
| Updated by: | RFC 9519 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4819 |
|
Secure Shell defines a user authentication mechanism that is based on public keys, but does not define any mechanism for key distribution.No common key management solution exists in current implementations.This document describes a protocol that can be used to configure public keys in an implementation-independent fashion, allowing client software to take on the burden of this configuration.
The Public Key Subsystem provides a server-independent mechanism for clients to add public keys, remove public keys, and list the current public keys known by the server. Rights to manage public keys are specific and limited to the authenticated user.
A public key may also be associated with various restrictions, including a mandatory command or subsystem. |
|
| |
| RFC 4820 | Padding Chunk and Parameter for the Stream Control Transmission Protocol (SCTP) |
| |
| Authors: | M. Tuexen, R. Stewart, P. Lei. |
| Date: | March 2007 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4820 |
|
This document defines a padding chunk and a padding parameter and describes the required receiver side procedures. The padding chunk is used to pad a Stream Control Transmission Protocol (SCTP) packet to an arbitrary size. The padding parameter is used to pad an SCTPINIT chunk to an arbitrary size. |
|
| |
| RFC 4821 | Packetization Layer Path MTU Discovery |
| |
| Authors: | M. Mathis, J. Heffner. |
| Date: | March 2007 |
| Formats: | txt json html |
| Updated by: | RFC 8899 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4821 |
|
This document describes a robust method for Path MTU Discovery(PMTUD) that relies on TCP or some other Packetization Layer to probe an Internet path with progressively larger packets. This method is described as an extension to RFC 1191 and RFC 1981, which specifyICMP-based Path MTU Discovery for IP versions 4 and 6, respectively. |
|
| |
| RFC 4822 | RIPv2 Cryptographic Authentication |
| |
|
|
This note describes a revision to the RIPv2 CryptographicAuthentication mechanism originally specified in RFC 2082. This document obsoletes RFC 2082 and updates RFC 2453. This document adds details of how the SHA family of hash algorithms can be used withRIPv2 Cryptographic Authentication, whereas the original document only specified the use of Keyed-MD5. Also, this document clarifies a potential issue with an active attack on this mechanism and adds significant text to the Security Considerations section. |
|
| |
| RFC 4825 | The Extensible Markup Language (XML) Configuration Access Protocol (XCAP) |
| |
| Authors: | J. Rosenberg. |
| Date: | May 2007 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4825 |
|
This specification defines the Extensible Markup Language (XML)Configuration Access Protocol (XCAP). XCAP allows a client to read, write, and modify application configuration data stored in XML format on a server. XCAP maps XML document sub-trees and element attributes to HTTP URIs, so that these components can be directly accessed byHTTP. |
|
| |
| RFC 4826 | Extensible Markup Language (XML) Formats for Representing Resource Lists |
| |
| Authors: | J. Rosenberg. |
| Date: | May 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4826 |
|
In multimedia communications, presence, and instant messaging systems, there is a need to define Uniform Resource Identifiers(URIs) that represent services that are associated with a group of users. One example is a resource list service. If a user sends aSession Initiation Protocol (SIP) SUBSCRIBE message to the URI representing the resource list service, the server will obtain the state of the users in the associated group, and provide it to the sender. To facilitate definition of these services, this specification defines two Extensible Markup Language (XML) documents.One document contains service URIs, along with their service definition and a reference to the associated group of users. The second document contains the user lists that are referenced from the first. This list of users can be utilized by other applications and services. Both documents can be created and managed with the XMLConfiguration Access Protocol (XCAP). |
|
| |
| RFC 4827 | An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Usage for Manipulating Presence Document Contents |
| |
| Authors: | M. Isomaki, E. Leppanen. |
| Date: | May 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4827 |
|
This document describes a usage of the Extensible Markup Language(XML) Configuration Access Protocol (XCAP) for manipulating the contents of Presence Information Data Format (PIDF) based presence documents. It is intended to be used in Session Initiation Protocol(SIP) based presence systems, where the Event State Compositor can use the XCAP-manipulated presence document as one of the inputs on which it builds the overall presence state for the presentity. |
|
| |
| RFC 4833 | Timezone Options for DHCP |
| |
|
|
Two common ways to communicate timezone information are POSIX 1003.1 timezone strings and timezone database names. This memo specifiesDHCP options for each of those methods. The DHCPv4 time offset option is deprecated. |
|
| |
| RFC 4835 | Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH) |
| |
|
|
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 4836 | Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) |
| |
|
|
This document 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.3Medium Attachment Units (MAUs). This document obsoletes RFC 3636.It amends that specification by moving MAU type OBJECT-IDENTITY definitions and relevant textual conventions into a separate InternetAssigned Number Authority (IANA) maintained MIB module. In addition, management information is added to enable support for Ethernet in theFirst Mile (EFM) and 10GBASE-CX4 MAUs. |
|
| |
| RFC 4837 | Managed Objects of Ethernet Passive Optical Networks (EPON) |
| |
| Authors: | L. Khermosh. |
| Date: | July 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4837 |
|
This document defines a portion of the Management Information Base(MIB) for use with network management protocols in TCP/IP basedInternets. In particular, it defines objects for managing interfaces that conform to the Ethernet Passive Optical Networks (EPON) standard as defined in the IEEE Std 802.3ah-2004, which are extended capabilities to the Ethernet like interfaces. |
|
| |
| RFC 4842 | Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet (CEP) |
| |
| Authors: | A. Malis, P. Pate, R. Cohen, Ed., D. Zelig. |
| Date: | April 2007 |
| Formats: | txt json html |
| Obsoletes: | RFC 5143 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4842 |
|
This document provides encapsulation formats and semantics for emulating Synchronous Optical Network/Synchronous Digital Hierarchy(SONET/SDH) circuits and services over MPLS. |
|
| |
| RFC 4848 | Domain-Based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS) |
| |
| Authors: | L. Daigle. |
| Date: | April 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4848 |
|
The purpose of this document is to define a new, straightforwardDynamic Delegation Discovery Service (DDDS) application to allow mapping of domain names to URIs for particular application services and protocols. Although defined as a new DDDS application, dubbedU-NAPTR, this is effectively an extension of the StraightforwardNAPTR (S-NAPTR) DDDS Application. |
|
| |
| RFC 4849 | RADIUS Filter Rule Attribute |
| |
| Authors: | P. Congdon, M. Sanchez, B. Aboba. |
| Date: | April 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4849 |
|
While RFC 2865 defines the Filter-Id attribute, it requires that theNetwork Access Server (NAS) be pre-populated with the desired filters. However, in situations where the server operator does not know which filters have been pre-populated, it is useful to specify filter rules explicitly. This document defines the NAS-Filter-Rule attribute within the Remote Authentication Dial In User Service(RADIUS). This attribute is based on the Diameter NAS-Filter-RuleAttribute Value Pair (AVP) described in RFC 4005, and theIPFilterRule syntax defined in RFC 3588. |
|
| |
| RFC 4850 | Declarative Public Extension Key for Internet Small Computer Systems Interface (iSCSI) Node Architecture |
| |
|
|
The Internet Small Computer Systems Interface (iSCSI) protocol, described in RFC 3720, allows for extension items to the protocol in the form of Private or Public Extension Keys. This document describes a Public Extension Key for the purpose of enhancing iSCSI supportability. The key accomplishes this objective by allowing iSCSI nodes to communicate architecture details during the iSCSI login sequence. The receiving node can then use this information for enhanced logging and support. This document updates RFC 3720 to allow iSCSI extension items to be defined by standards track RFCs and experimental RFCs in addition to informational RFCs. |
|
| |
| RFC 4853 | Cryptographic Message Syntax (CMS) Multiple Signer Clarification |
| |
|
|
This document updates the Cryptographic Message Syntax (CMS), which is published in RFC 3852. This document clarifies the proper handling of the SignedData protected content type when more than one digital signature is present. |
|
| |
| RFC 4855 | Media Type Registration of RTP Payload Formats |
| |
|
|
This document specifies the procedure to register RTP payload formats as audio, video, or other media subtype names. This is useful in a text-based format description or control protocol to identify the type of an RTP transmission. |
|
| |
| RFC 4856 | Media Type Registration of Payload Formats in the RTP Profile for Audio and Video Conferences |
| |
|
|
This document specifies media type registrations for the RTP payload formats defined in the RTP Profile for Audio and Video Conferences.Some of these may also be used for transfer modes other than RTP. |
|
| |
| RFC 4860 | Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations |
| |
| Authors: | F. Le Faucheur, B. Davie, P. Bose, C. Christou, M. Davenport. |
| Date: | May 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4860 |
|
RFC 3175 defines aggregate Resource ReSerVation Protocol (RSVP) reservations allowing resources to be reserved in a Diffserv network for a given Per Hop Behavior (PHB), or given set of PHBs, from a given source to a given destination. RFC 3175 also defines how end- to-end RSVP reservations can be aggregated onto such aggregate reservations when transiting through a Diffserv cloud. There are situations where multiple such aggregate reservations are needed for the same source IP address, destination IP address, and PHB (or set of PHBs). However, this is not supported by the aggregate reservations defined in RFC 3175. In order to support this, the present document defines a more flexible type of aggregate RSVP reservations, referred to as generic aggregate reservation. Multiple such generic aggregate reservations can be established for a givenPHB (or set of PHBs) from a given source IP address to a given destination IP address. The generic aggregate reservations may be used to aggregate end-to-end RSVP reservations. This document also defines the procedures for such aggregation. The generic aggregate reservations may also be used end-to-end directly by end-systems attached to a Diffserv network. |
|
| |
| RFC 4863 | Wildcard Pseudowire Type |
| |
| Authors: | L. Martini, G. Swallow. |
| Date: | May 2007 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4863 |
|
Pseudowire signaling requires that the Pseudowire Type (PW Type) be identical in both directions. For certain applications the configuration of the PW Type is most easily accomplished by configuring this information at just one PW endpoint. In any form ofLDP-based signaling, each PW endpoint must initiate the creation of a unidirectional LSP. In order to allow the initiation of these twoLSPs to remain independent, a means is needed for allowing the PW endpoint (lacking a priori knowledge of the PW Type) to initiate the creation of an LSP. This document defines a Wildcard PW Type to satisfy this need. |
|
| |
| RFC 4865 | SMTP Submission Service Extension for Future Message Release |
| |
|
|
This memo defines an extension to the SMTP submission protocol for a client to indicate a future time for the message to be released for delivery. This extension permits a client to use server-based storage for a message that should be held in queue until an appointed time in the future. This is useful for clients which do not have local storage or are otherwise unable to release a message for delivery at an appointed time. |
|
| |
| RFC 4866 | Enhanced Route Optimization for Mobile IPv6 |
| |
| Authors: | J. Arkko, C. Vogt, W. Haddad. |
| Date: | May 2007 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4866 |
|
This document specifies an enhanced version of Mobile IPv6 route optimization, providing lower handoff delays, increased security, and reduced signaling overhead. |
|
| |
| RFC 4867 | 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: | April 2007 |
| Formats: | txt json html |
| Obsoletes: | RFC 3267 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4867 |
|
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 media type registrations are included, one for AMR and one for AMR-WB, specifying use of both the RTP payload format and the storage format. This document obsoletes RFC 3267. |
|
| |
| RFC 4868 | Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec |
| |
| Authors: | S. Kelly, S. Frankel. |
| Date: | May 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4868 |
|
This specification describes the use of Hashed Message AuthenticationMode (HMAC) in conjunction with the SHA-256, SHA-384, and SHA-512 algorithms in IPsec. These algorithms may be used as the basis for data origin authentication and integrity verification mechanisms for the Authentication Header (AH), Encapsulating Security Payload (ESP),Internet Key Exchange Protocol (IKE), and IKEv2 protocols, and also as Pseudo-Random Functions (PRFs) for IKE and IKEv2. Truncated output lengths are specified for the authentication-related variants, with the corresponding algorithms designated as HMAC-SHA-256-128,HMAC-SHA-384-192, and HMAC-SHA-512-256. The PRF variants are not truncated, and are called PRF-HMAC-SHA-256, PRF-HMAC-SHA-384, andPRF-HMAC-SHA-512. |
|
| |
| RFC 4871 | DomainKeys Identified Mail (DKIM) Signatures |
| |
| Authors: | E. Allman, J. Callas, M. Delany, M. Libbey, J. Fenton, M. Thomas. |
| Date: | May 2007 |
| Formats: | txt html json |
| Obsoletes: | RFC 4870 |
| Obsoleted by: | RFC 6376 |
| Updated by: | RFC 5672 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4871 |
|
DomainKeys Identified Mail (DKIM) defines a domain-level authentication framework for email using public-key cryptography and key server technology to permit verification of the source and contents of messages by either Mail Transfer Agents (MTAs) or MailUser Agents (MUAs). The ultimate goal of this framework is to permit a signing domain to assert responsibility for a message, thus protecting message signer identity and the integrity of the messages they convey while retaining the functionality of Internet email as it is known today. Protection of email identity may assist in the global control of "spam" and "phishing". |
|
| |
| RFC 4872 | RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery |
| |
|
|
This document describes protocol-specific procedures and extensions for Generalized Multi-Protocol Label Switching (GMPLS) ResourceReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling to support end-to-end Label Switched Path (LSP) recovery that denotes protection and restoration. A generic functional description ofGMPLS recovery can be found in a companion document, RFC 4426. |
|
| |
| RFC 4873 | GMPLS Segment Recovery |
| |
|
|
This document describes protocol specific procedures for GMPLS(Generalized Multi-Protocol Label Switching) RSVP-TE (ResourceReserVation Protocol - Traffic Engineering) signaling extensions to support label switched path (LSP) segment protection and restoration.These extensions are intended to complement and be consistent with the RSVP-TE Extensions for End-to-End GMPLS Recovery (RFC 4872).Implications and interactions with fast reroute are also addressed.This document also updates the handling of NOTIFY_REQUEST objects. |
|
| |
| RFC 4874 | Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) |
| |
|
|
This document specifies ways to communicate route exclusions during path setup using Resource ReserVation Protocol-Traffic Engineering(RSVP-TE).
The RSVP-TE specification, "RSVP-TE: Extensions to RSVP for LSPTunnels" (RFC 3209) and GMPLS extensions to RSVP-TE, "GeneralizedMulti-Protocol Label Switching (GMPLS) Signaling Resource ReserVationProtocol-Traffic Engineering (RSVP-TE) Extensions" (RFC 3473) allow abstract nodes and resources to be explicitly included in a path setup, but not to be explicitly excluded.
In some networks where precise explicit paths are not computed at the head end, it may be useful to specify and signal abstract nodes and resources that are to be explicitly excluded from routes. These exclusions may apply to the whole path, or to parts of a path between two abstract nodes specified in an explicit path. How Shared RiskLink Groups (SRLGs) can be excluded is also specified in this document. |
|
| |
| RFC 4875 | Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs) |
| |
| Authors: | R. Aggarwal, Ed., D. Papadimitriou, Ed., S. Yasukawa, Ed.. |
| Date: | May 2007 |
| Formats: | txt html json |
| Updated by: | RFC 6510 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4875 |
|
This document describes extensions to Resource Reservation Protocol -Traffic Engineering (RSVP-TE) for the set up of Traffic Engineered(TE) point-to-multipoint (P2MP) Label Switched Paths (LSPs) in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The solution relies on RSVP-TE without requiring a multicast routing protocol in the Service Provider core. Protocol elements and procedures for this solution are described.
There can be various applications for P2MP TE LSPs such as IP multicast. Specification of how such applications will use a P2MP TELSP is outside the scope of this document. |
|
| |
| RFC 4877 | Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture |
| |
| Authors: | V. Devarapalli, F. Dupont. |
| Date: | April 2007 |
| Formats: | txt json html |
| Updates: | RFC 3776 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4877 |
|
This document describes Mobile IPv6 operation with the revised IPsec architecture and IKEv2. |
|
| |
| RFC 4878 | Definitions and Managed Objects for Operations, Administration, and Maintenance (OAM) Functions on Ethernet-Like Interfaces |
| |
| Authors: | M. Squire. |
| Date: | June 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4878 |
|
This document defines objects for managing Operations,Administration, and Maintenance (OAM) capabilities on Ethernet-like interfaces conformant to the Ethernet OAM functionality defined in the Ethernet in the First Mile (EFM) clauses of the Ethernet standards. The Ethernet OAM functionality is complementary to theSimple Network Management Protocol (SNMP) in that it is focused on a small set of link-specific functions for directly connected Ethernet interfaces. This document defines objects for controlling those linkOAM functions and for providing results and status of the OAM functions to management entities. |
|
| |
| RFC 4880 | OpenPGP Message Format |
| |
|
|
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.
OpenPGP 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 4884 | Extended ICMP to Support Multi-Part Messages |
| |
|
|
This document redefines selected ICMP messages to support multi-part operation. A multi-part ICMP message carries all of the information that ICMP messages carried previously, as well as additional information that applications may require.
Multi-part messages are supported by an ICMP extension structure.The extension structure is situated at the end of the ICMP message.It includes an extension header followed by one or more extension objects. Each extension object contains an object header and object payload. All object headers share a common format.
This document further redefines the above mentioned ICMP messages by specifying a length attribute. All of the currently defined ICMP messages to which an extension structure can be appended include an"original datagram" field. The "original datagram" field contains the initial octets of the datagram that elicited the ICMP error message. Although the original datagram field is of variable length, the ICMP message does not include a field that specifies its length.Therefore, in order to facilitate message parsing, this document allocates eight previously reserved bits to reflect the length of the"original datagram" field.
The proposed modifications change the requirements for ICMP compliance. The impact of these changes on compliant implementations is discussed, and new requirements for future implementations are presented.
This memo updates RFC 792 and RFC 4443. |
|
| |
| RFC 4893 | BGP Support for Four-octet AS Number Space |
| |
|
|
Currently the Autonomous System (AS) number is encoded as a two-octet entity in BGP. This document describes extensions to BGP to carry theAutonomous System number as a four-octet entity. |
|
| |
| RFC 4895 | Authenticated Chunks for the Stream Control Transmission Protocol (SCTP) |
| |
| Authors: | M. Tuexen, R. Stewart, P. Lei, E. Rescorla. |
| Date: | August 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4895 |
|
This document describes a new chunk type, several parameters, and procedures for the Stream Control Transmission Protocol (SCTP). This new chunk type can be used to authenticate SCTP chunks by using shared keys between the sender and receiver. The new parameters are used to establish the shared keys. |
|
| |
| RFC 4896 | Signaling Compression (SigComp) Corrections and Clarifications |
| |
|
|
This document describes common misinterpretations and some ambiguities in the Signaling Compression Protocol (SigComp), and offers guidance to developers to resolve any resultant problems.SigComp defines a scheme for compressing messages generated by application protocols such as the Session Initiation Protocol (SIP).This document updates the following RFCs: RFC 3320, RFC 3321, and RFC3485. |
|
| |
| RFC 4898 | TCP Extended Statistics MIB |
| |
| Authors: | M. Mathis, J. Heffner, R. Raghunarayan. |
| Date: | May 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4898 |
|
This document describes extended performance statistics for TCP.They are designed to use TCP's ideal vantage point to diagnose performance problems in both the network and the application. If a network-based application is performing poorly, TCP can determine if the bottleneck is in the sender, the receiver, or the network itself.If the bottleneck is in the network, TCP can provide specific information about its nature. |
|
| |
| RFC 4901 | Protocol Extensions for Header Compression over MPLS |
| |
| Authors: | J. Ash, Ed., J. Hand, Ed., A. Malis, Ed.. |
| Date: | June 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4901 |
|
This specification defines how to use Multi-Protocol Label Switching(MPLS) to route Header-Compressed (HC) packets over an MPLS label switched path. HC can significantly reduce packet-header overhead and, in combination with MPLS, can also increases bandwidth efficiency and processing scalability in terms of the maximum number of simultaneous compressed flows that use HC at each router). Here we define how MPLS pseudowires are used to transport the HC context and control messages between the ingress and egress MPLS label switching routers. This is defined for a specific set of existing HC mechanisms that might be used, for example, to support voice over IP.This specification also describes extension mechanisms to allow support for future, as yet to be defined, HC protocols. In this specification, each HC protocol operates independently over a single pseudowire instance, very much as it would over a single point-to- point link. |
|
| |
| RFC 4904 | Representing Trunk Groups in tel/sip Uniform Resource Identifiers (URIs) |
| |
| Authors: | V. Gurbani, C. Jennings. |
| Date: | June 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4904 |
|
This document describes a standardized mechanism to convey trunk group parameters in sip and tel Uniform Resource Identifiers (URIs).An extension to the tel URI is defined for this purpose. |
|
| |
| RFC 4915 | Multi-Topology (MT) Routing in OSPF |
| |
| Authors: | P. Psenak, S. Mirtorabi, A. Roy, L. Nguyen, P. Pillay-Esnault. |
| Date: | June 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4915 |
|
This document describes an extension to Open Shortest Path First(OSPF) in order to define independent IP topologies called Multi-Topologies (MTs). The Multi-Topologies extension can be used for computing different paths for unicast traffic, multicast traffic, different classes of service based on flexible criteria, or an in- band network management topology.
An optional extension to exclude selected links from the default topology is also described. |
|
| |
| RFC 4916 | Connected Identity in the Session Initiation Protocol (SIP) |
| |
|
|
This document provides a means for a Session Initiation Protocol(SIP) User Agent (UA) that receives a dialog-forming request to supply its identity to the peer UA by means of a request in the reverse direction, and for that identity to be signed by anAuthentication Service. Because of retargeting of a dialog-forming request (changing the value of the Request-URI), the UA that receives it (the User Agent Server, UAS) can have a different identity from that in the To header field. The same mechanism can be used to indicate a change of identity during a dialog, e.g., because of some action in the Public Switched Telephone Network (PSTN) behind a gateway. This document normatively updates RFC 3261 (SIP). |
|
| |
| RFC 4917 | Mobile IPv4 Message String Extension |
| |
| Authors: | V. Sastry, K. Leung, A. Patel. |
| Date: | June 2007 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4917 |
|
This document specifies a new extension for use in Mobile IPv4. This extension can be added by the Home Agent and the Foreign Agent toRegistration Reply messages. This extension carries a text string that is intended for the user of the Mobile Node. |
|
| |
| RFC 4918 | HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV) |
| |
|
|
Web Distributed Authoring and Versioning (WebDAV) consists of 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, URL namespace manipulation, and resource locking (collision avoidance).
RFC 2518 was published in February 1999, and this specification obsoletes RFC 2518 with minor revisions mostly due to interoperability experience. |
|
| |
| RFC 4920 | Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE |
| |
| Authors: | A. Farrel, Ed., A. Satyanarayana, A. Iwata, N. Fujita, G. Ash. |
| Date: | July 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4920 |
|
In a distributed, constraint-based routing environment, the information used to compute a path may be out of date. This means that Multiprotocol Label Switching (MPLS) and Generalized MPLS(GMPLS) Traffic Engineered (TE) Label Switched Path (LSP) setup requests may be blocked by links or nodes without sufficient resources. Crankback is a scheme whereby setup failure information is returned from the point of failure to allow new setup attempts to be made avoiding the blocked resources. Crankback can also be applied to LSP recovery to indicate the location of the failed link or node.
This document specifies crankback signaling extensions for use inMPLS signaling using RSVP-TE as defined in "RSVP-TE: Extensions toRSVP for LSP Tunnels", RFC 3209, and GMPLS signaling as defined in"Generalized Multi-Protocol Label Switching (GMPLS) SignalingFunctional Description", RFC 3473. These extensions mean that theLSP setup request can be retried on an alternate path that detours around blocked links or nodes. This offers significant improvements in the successful setup and recovery ratios for LSPs, especially in situations where a large number of setup requests are triggered at the same time. |
|
| |
| RFC 4935 | Fibre Channel Fabric Configuration Server MIB |
| |
| Authors: | C. DeSanti, H.K. Vivek, K. McCloghrie, S. Gai. |
| Date: | August 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4935 |
|
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 Fabric Configuration Server function of a Fibre Channel network. |
|
| |
| RFC 4936 | Fibre Channel Zone Server MIB |
| |
| Authors: | C. DeSanti, H.K. Vivek, K. McCloghrie, S. Gai. |
| Date: | August 2007 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4936 |
|
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 Zone Server. |
|
| |
| RFC 4939 | Definitions of Managed Objects for iSNS (Internet Storage Name Service) |
| |
| Authors: | K. Gibbons, G. Ramkumar, S. Kipp. |
| Date: | July 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4939 |
|
The iSNS (Internet Storage Name Service) protocol provides storage name service functionality on an IP network that is being used for iSCSI (Internet Small Computer System Interface) or iFCP (InternetFibre Channel Protocol) storage. This document provides a mechanism to monitor multiple iSNS Servers, including information about registered objects in an iSNS Server. |
|
| |
| RFC 4944 | Transmission of IPv6 Packets over IEEE 802.15.4 Networks |
| |
|
|
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 IEEE 802.15.4 networks.Additional specifications include a simple header compression scheme using shared context and provisions for packet delivery in IEEE802.15.4 meshes. |
|
| |
| RFC 4945 | The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX |
| |
| Authors: | B. Korver. |
| Date: | August 2007 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4945 |
|
The Internet Key Exchange (IKE) and Public Key Infrastructure forX.509 (PKIX) certificate profile both provide frameworks that must be profiled for use in a given application. This document provides a profile of IKE and PKIX that defines the requirements for using PKI technology in the context of IKE/IPsec. The document complements protocol specifications such as IKEv1 and IKEv2, which assume the existence of public key certificates and related keying materials, but which do not address PKI issues explicitly. This document addresses those issues. The intended audience is implementers of PKI for IPsec. |
|
| |
| RFC 4950 | ICMP Extensions for Multiprotocol Label Switching |
| |
| Authors: | R. Bonica, D. Gan, D. Tappan, C. Pignataro. |
| Date: | August 2007 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4950 |
|
This memo defines an extension object that can be appended to selected multi-part ICMP messages. This extension permits LabelSwitching Routers to append MPLS information to ICMP messages, and has already been widely deployed. |
|
| |
| RFC 4951 | Fail Over Extensions for Layer 2 Tunneling Protocol (L2TP) "failover" |
| |
| Authors: | V. Jain, Ed.. |
| Date: | August 2007 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4951 |
|
Layer 2 Tunneling Protocol (L2TP) is a connection-oriented protocol that has a shared state between active endpoints. Some of this shared state is vital for operation, but may be volatile in nature, such as packet sequence numbers used on the L2TP Control Connection.When failure of one side of a control connection occurs, a new control connection is created and associated with the old connection by exchanging information about the old connection. Such a mechanism is not intended as a replacement for an active fail over with some mirrored connection states, but as an aid for those parameters that are particularly difficult to have immediately available. Protocol extensions to L2TP defined in this document are intended to facilitate state recovery, providing additional resiliency in an L2TP network, and improving a remote system's layer 2 connectivity. |
|
| |
| RFC 4954 | SMTP Service Extension for Authentication |
| |
|
|
This document defines a Simple Mail Transport Protocol (SMTP) extension 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 during this session. This extension includes a profile of the Simple Authentication and Security Layer (SASL) for SMTP.
This document obsoletes RFC 2554. |
|
| |
| RFC 4955 | DNS Security (DNSSEC) Experiments |
| |
| Authors: | D. Blacka. |
| Date: | July 2007 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4955 |
|
This document describes a methodology for deploying alternate, non- backwards-compatible, DNS Security (DNSSEC) methodologies in an experimental fashion without disrupting the deployment of standardDNSSEC. |
|
| |
| RFC 4959 | IMAP Extension for Simple Authentication and Security Layer (SASL) Initial Client Response |
| |
| Authors: | R. Siemborski, A. Gulbrandsen. |
| Date: | September 2007 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4959 |
|
To date, the Internet Message Access Protocol (IMAP) has used aSimple Authentication and Security Layer (SASL) profile which always required at least one complete round trip for an authentication, as it did not support an initial client response argument. This additional round trip at the beginning of the session is undesirable, especially when round-trip costs are high.
This document defines an extension to IMAP which allows clients and servers to avoid this round trip by allowing an initial client response argument to the IMAP AUTHENTICATE command. |
|
| |
| RFC 4960 | Stream Control Transmission Protocol |
| |
|
|
This document obsoletes RFC 2960 and RFC 3309. It describes theStream Control Transmission Protocol (SCTP). SCTP is designed to transport Public Switched Telephone Network (PSTN) signaling messages over IP 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 4967 | Dial String Parameter for the Session Initiation Protocol Uniform Resource Identifier |
| |
| Authors: | B. Rosen. |
| Date: | July 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4967 |
|
RFC 3966 explicitly states that 'tel' URIs may not represent a dial string. That leaves no way specify a dial string in a standardized way. Great confusion exists with the SIP URI parameter "user=phone", and specifically, if it can represent a dial string. This memo creates a new value for the user parameter "dialstring", so that one may specify "user=dialstring" to encode a dial string as a 'sip:' or'sips:' URI. |
|
| |
| RFC 4969 | IANA Registration for vCard Enumservice |
| |
|
|
This memo registers the Enumservice "vCard" using the URI schemes"http" and "https". This Enumservice is to be used to refer from anENUM domain name to a vCard instance describing the user of the respective E.164 number.
Information gathered from those vCards could be used before, during, or after inbound or outbound communication takes place. For example, a callee might be presented with the name and association of the caller before picking up the call. |
|
| |
| RFC 4970 | Extensions to OSPF for Advertising Optional Router Capabilities |
| |
| Authors: | A. Lindem, Ed., N. Shen, JP. Vasseur, R. Aggarwal, S. Shaffer. |
| Date: | July 2007 |
| Formats: | txt json html |
| Obsoleted by: | RFC 7770 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4970 |
|
It is useful for routers in an OSPFv2 or OSPFv3 routing domain to know the capabilities of their neighbors and other routers in the routing domain. This document proposes extensions to OSPFv2 andOSPFv3 for advertising optional router capabilities. A new RouterInformation (RI) Link State Advertisement (LSA) is proposed for this purpose. In OSPFv2, the RI LSA will be implemented with a new opaqueLSA type ID. In OSPFv3, the RI LSA will be implemented with a newLSA type function code. In both protocols, the RI LSA can be advertised at any of the defined flooding scopes (link, area, or autonomous system (AS)). |
|
| |
| RFC 4971 | Intermediate System to Intermediate System (IS-IS) Extensions for Advertising Router Information |
| |
| Authors: | JP. Vasseur, Ed., N. Shen, Ed., R. Aggarwal, Ed.. |
| Date: | July 2007 |
| Formats: | txt json html |
| Obsoleted by: | RFC 7981 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4971 |
|
This document defines a new optional Intermediate System toIntermediate System (IS-IS) TLV named CAPABILITY, formed of multiple sub-TLVs, which allows a router to announce its capabilities within an IS-IS level or the entire routing domain. |
|
| |
| RFC 4972 | Routing Extensions for Discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering (TE) Mesh Membership |
| |
| Authors: | JP. Vasseur, Ed., JL. Leroux, Ed., S. Yasukawa, S. Previdi, P. Psenak, P. Mabbey. |
| Date: | July 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4972 |
|
The setup of a full mesh of Multi-Protocol Label Switching (MPLS)Traffic Engineering (TE) Label Switched Paths (LSP) among a set ofLabel Switch Routers (LSR) is a common deployment scenario of MPLSTraffic Engineering either for bandwidth optimization, bandwidth guarantees or fast rerouting with MPLS Fast Reroute. Such deployment may require the configuration of a potentially large number of TELSPs (on the order of the square of the number of LSRs). This document specifies Interior Gateway Protocol (IGP) routing extensions for Intermediate System-to-Intermediate System (IS-IS) and OpenShortest Path First (OSPF) so as to provide an automatic discovery of the set of LSRs members of a mesh in order to automate the creation of such mesh of TE LSPs. |
|
| |
| RFC 4974 | Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in Support of Calls |
| |
|
|
In certain networking topologies, it may be advantageous to maintain associations between endpoints and key transit points to support an instance of a service. Such associations are known as Calls.
A Call does not provide the actual connectivity for transmitting user traffic, but only builds a relationship by which subsequentConnections may be made. In Generalized MPLS (GMPLS) suchConnections are known as Label Switched Paths (LSPs).
This document specifies how GMPLS Resource Reservation Protocol -Traffic Engineering (RSVP-TE) signaling may be used and extended to support Calls. These mechanisms provide full and logicalCall/Connection separation.
The mechanisms proposed in this document are applicable to any environment (including multi-area), and for any type of interface: packet, layer-2, time-division multiplexed, lambda, or fiber switching. |
|
| |
| RFC 4975 | The Message Session Relay Protocol (MSRP) |
| |
|
|
This document describes the Message Session Relay Protocol, a protocol for transmitting a series of related instant messages in the context of a session. Message sessions are treated like any other media stream when set up via a rendezvous or session creation protocol such as the Session Initiation Protocol. |
|
| |
| RFC 4976 | Relay Extensions for the Message Sessions Relay Protocol (MSRP) |
| |
|
|
Two separate models for conveying instant messages have been defined.Page-mode messages stand alone and are not part of a SessionInitiation Protocol (SIP) session, whereas session-mode messages are set up as part of a session using SIP. The Message Session RelayProtocol (MSRP) is a protocol for near real-time, peer-to-peer exchanges of binary content without intermediaries, which is designed to be signaled using a separate rendezvous protocol such as SIP.This document introduces the notion of message relay intermediaries to MSRP and describes the extensions necessary to use them. |
|
| |
| RFC 4978 | The IMAP COMPRESS Extension |
| |
| Authors: | A. Gulbrandsen. |
| Date: | August 2007 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4978 |
|
The COMPRESS extension allows an IMAP connection to be effectively and efficiently compressed. |
|
| |
| RFC 4979 | IANA Registration for Enumservice 'XMPP' |
| |
|
|
This document requests IANA registration of an Enumservice for XMPP, the Extensible Messaging and Presence Protocol. This Enumservice specifically allows the use of 'xmpp' Uniform Resource Identifiers(URIs) in the context of E.164 Number Mapping (ENUM). |
|
| |
| RFC 4982 | Support for Multiple Hash Algorithms in Cryptographically Generated Addresses (CGAs) |
| |
|
|
This document analyzes the implications of recent attacks on commonly used hash functions on Cryptographically Generated Addresses (CGAs) and updates the CGA specification to support multiple hash algorithms. |
|
| |
| RFC 4983 | Fibre Channel Registered State Change Notification (RSCN) MIB |
| |
| Authors: | C. DeSanti, H.K. Vivek, K. McCloghrie, S. Gai. |
| Date: | August 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4983 |
|
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 management of Fibre Channel's Registered State ChangeNotifications (RSCNs). |
|
| |
| RFC 4985 | Internet X.509 Public Key Infrastructure Subject Alternative Name for Expression of Service Name |
| |
| Authors: | S. Santesson. |
| Date: | August 2007 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4985 |
|
This document defines a new name form for inclusion in the otherName field of an X.509 Subject Alternative Name extension that allows a certificate subject to be associated with the service name and domain name components of a DNS Service Resource Record. |
|
| |
| RFC 4991 | A Common Schema for Internet Registry Information Service Transfer Protocols |
| |
| Authors: | A. Newton. |
| Date: | August 2007 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4991 |
|
This document describes an XML Schema for use by Internet RegistryInformation Service (IRIS) application transfer protocols that share common characteristics. It describes common information about the transfer protocol, such as version, supported extensions, and supported security mechanisms. |
|
| |
| RFC 4992 | XML Pipelining with Chunks for the Internet Registry Information Service |
| |
|
|
This document describes a simple TCP transfer protocol for theInternet Registry Information Service (IRIS). Data is transferred between clients and servers using chunks to achieve pipelining. |
|
| |
| RFC 4993 | A Lightweight UDP Transfer Protocol for the Internet Registry Information Service |
| |
| Authors: | A. Newton. |
| Date: | August 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4993 |
|
This document describes a lightweight UDP transfer protocol for theInternet Registry Information Service (IRIS). This transfer protocol uses a single packet for every request and response, and optionally employs compression over the contents of the packet. |
|
| |
| RFC 4994 | DHCPv6 Relay Agent Echo Request Option |
| |
| Authors: | S. Zeng, B. Volz, K. Kinnear, J. Brzozowski. |
| Date: | September 2007 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4994 |
|
This memo defines a Relay Agent Echo Request option for the DynamicHost Configuration Protocol for IPv6 (DHCPv6). The option allows aDHCPv6 relay agent to request a list of relay agent options that the server echoes back to the relay agent. |
|
| |
| RFC 4995 | The RObust Header Compression (ROHC) Framework |
| |
| Authors: | L-E. Jonsson, G. Pelletier, K. Sandlund. |
| Date: | July 2007 |
| Formats: | txt json html |
| Obsoleted by: | RFC 5795 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4995 |
|
The Robust Header Compression (ROHC) protocol provides an efficient, flexible, and future-proof header compression concept. It is designed to operate efficiently and robustly over various link technologies with different characteristics.
The ROHC framework, along with a set of compression profiles, was initially defined in RFC 3095. To improve and simplify the ROHC specifications, this document explicitly defines the ROHC framework and the profile for uncompressed separately. More specifically, the definition of the framework does not modify or update the definition of the framework specified by RFC 3095. |
|
| |
| RFC 4996 | RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP) |
| |
| Authors: | G. Pelletier, K. Sandlund, L-E. Jonsson, M. West. |
| Date: | July 2007 |
| Formats: | txt html json |
| Obsoleted by: | RFC 6846 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4996 |
|
This document specifies a ROHC (Robust Header Compression) profile for compression of TCP/IP packets. The profile, called ROHC-TCP, provides efficient and robust compression of TCP headers, including frequently used TCP options such as SACK (Selective Acknowledgments) and Timestamps.
ROHC-TCP works 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. |
|
| |
| RFC 4997 | Formal Notation for RObust Header Compression (ROHC-FN) |
| |
| Authors: | R. Finking, G. Pelletier. |
| Date: | July 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4997 |
|
This document defines Robust Header Compression - Formal Notation(ROHC-FN), a formal notation to specify field encodings for compressed formats when defining new profiles within the ROHC framework. ROHC-FN offers a library of encoding methods that are often used in ROHC profiles and can thereby help to simplify future profile development work. |
|
| |
| RFC 4998 | Evidence Record Syntax (ERS) |
| |
| Authors: | T. Gondrom, R. Brandner, U. Pordesch. |
| Date: | August 2007 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 4998 |
|
In many scenarios, users must be able prove the existence and integrity of data, including digitally signed data, in a common and reproducible way over a long and possibly undetermined period of time. This document specifies the syntax and processing of anEvidence Record, a structure designed to support long-term non- repudiation of existence of data. |
|
| |
| RFC 5001 | DNS Name Server Identifier (NSID) Option |
| |
| Authors: | R. Austein. |
| Date: | August 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5001 |
|
With the increased use of DNS anycast, load balancing, and other mechanisms allowing more than one DNS name server to share a singleIP address, it is sometimes difficult to tell which of a pool of name servers has answered a particular query. While existing ad-hoc mechanisms allow an operator to send follow-up queries when it is necessary to debug such a configuration, the only completely reliable way to obtain the identity of the name server that responded is to have the name server include this information in the response itself.This note defines a protocol extension to support this functionality. |
|
| |
| RFC 5003 | Attachment Individual Identifier (AII) Types for Aggregation |
| |
| Authors: | C. Metz, L. Martini, F. Balus, J. Sugimoto. |
| Date: | September 2007 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5003 |
|
The signaling protocols used to establish point-to-point pseudowires include type-length-value (TLV) fields that identify pseudowire endpoints called attachment individual identifiers (AIIs). This document defines AII structures in the form of new AII TLV fields that support AII aggregation for improved scalability and VirtualPrivate Network (VPN) auto-discovery. It is envisioned that this would be useful in large inter-domain virtual private wire service networks where pseudowires are established between selected local and remote provider edge (PE) nodes based on customer need. |
|
| |
| RFC 5004 | Avoid BGP Best Path Transitions from One External to Another |
| |
| Authors: | E. Chen, S. Sangli. |
| Date: | September 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5004 |
|
In this document, we propose an extension to the BGP route selection rules that would avoid unnecessary best path transitions between external paths under certain conditions. The proposed extension would help the overall network stability, and more importantly, would eliminate certain BGP route oscillations in which more than one external path from one BGP speaker contributes to the churn. |
|
| |
| RFC 5005 | Feed Paging and Archiving |
| |
| Authors: | M. Nottingham. |
| Date: | September 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5005 |
|
This specification defines three types of syndicated Web feeds that enable publication of entries across one or more feed documents.This includes "paged" feeds for piecemeal access, "archived" feeds that allow reconstruction of the feed's contents, and feeds that are explicitly "complete". |
|
| |
| RFC 5007 | DHCPv6 Leasequery |
| |
| Authors: | J. Brzozowski, K. Kinnear, B. Volz, S. Zeng. |
| Date: | September 2007 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5007 |
|
This document specifies a leasequery exchange for the Dynamic HostConfiguration Protocol for IPv6 (DHCPv6) that can be used to obtain lease information about DHCPv6 clients from a DHCPv6 server. This document specifies the scope of data that can be retrieved as well as both DHCPv6 leasequery requestor and server behavior. This document extends DHCPv6. |
|
| |
| RFC 5010 | The Dynamic Host Configuration Protocol Version 4 (DHCPv4) Relay Agent Flags Suboption |
| |
| Authors: | K. Kinnear, M. Normoyle, M. Stapp. |
| Date: | September 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5010 |
|
This memo defines a new suboption of the Dynamic Host ConfigurationProtocol (DHCP) relay agent information option that allows the DHCP relay to specify flags for the forwarded packet. One flag is defined to indicate whether the DHCP relay received the packet via a unicast or broadcast packet. This information may be used by the DHCP server to better serve clients based on whether their request was originally broadcast or unicast. |
|
| |
| RFC 5015 | Bidirectional Protocol Independent Multicast (BIDIR-PIM) |
| |
| Authors: | M. Handley, I. Kouvelas, T. Speakman, L. Vicisano. |
| Date: | October 2007 |
| Formats: | txt html json |
| Updated by: | RFC 8736, RFC 9436 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5015 |
|
This document discusses Bidirectional PIM (BIDIR-PIM), a variant ofPIM Sparse-Mode that builds bidirectional shared trees connecting multicast sources and receivers. Bidirectional trees are built using a fail-safe Designated Forwarder (DF) election mechanism operating on each link of a multicast topology. With the assistance of the DF, multicast data is natively forwarded from sources to the Rendezvous-Point (RP) and hence along the shared tree to receivers without requiring source-specific state. The DF election takes place at RP discovery time and provides the route to the RP, thus eliminating the requirement for data-driven protocol events. |
|
| |
| RFC 5017 | MIB Textual Conventions for Uniform Resource Identifiers (URIs) |
| |
| Authors: | D. McWalter, Ed.. |
| Date: | September 2007 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5017 |
|
This MIB module defines textual conventions to represent STD 66Uniform Resource Identifiers (URIs). The intent is that these textual conventions will be imported and used in MIB modules that would otherwise define their own representation(s). |
|
| |
| RFC 5018 | Connection Establishment in the Binary Floor Control Protocol (BFCP) |
| |
|
|
This document specifies how a Binary Floor Control Protocol (BFCP) client establishes a connection to a BFCP floor control server outside the context of an offer/answer exchange. Client and server authentication are based on Transport Layer Security (TLS). |
|
| |
| RFC 5019 | The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments |
| |
| Authors: | A. Deacon, R. Hurst. |
| Date: | September 2007 |
| Formats: | txt html json |
| Updated by: | RFC 8996 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5019 |
|
This specification defines a profile of the Online Certificate StatusProtocol (OCSP) that addresses the scalability issues inherent when using OCSP in large scale (high volume) Public Key Infrastructure(PKI) environments and/or in PKI environments that require a lightweight solution to minimize communication bandwidth and client- side processing. |
|
| |
| RFC 5020 | The Lightweight Directory Access Protocol (LDAP) entryDN Operational Attribute |
| |
| Authors: | K. Zeilenga. |
| Date: | August 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5020 |
|
This document describes the Lightweight Directory Access Protocol(LDAP) / X.500 'entryDN' operational attribute. The attribute provides a copy of the entry's distinguished name for use in attribute value assertions. |
|
| |
| RFC 5021 | Extended Kerberos Version 5 Key Distribution Center (KDC) Exchanges over TCP |
| |
|
|
This document describes an extensibility mechanism for the KerberosV5 protocol when used over TCP transports. The mechanism uses the reserved high-bit in the length field. It can be used to negotiateTCP-specific Kerberos extensions. |
|
| |
| RFC 5023 | The Atom Publishing Protocol |
| |
| Authors: | J. Gregorio, Ed., B. de hOra, Ed.. |
| Date: | October 2007 |
| Formats: | txt json html |
| Updated by: | RFC 8996 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5023 |
|
The Atom Publishing Protocol (AtomPub) is an application-level protocol for publishing and editing Web resources. The protocol is based on HTTP transfer of Atom-formatted representations. The Atom format is documented in the Atom Syndication Format. |
|
| |
| RFC 5025 | Presence Authorization Rules |
| |
| Authors: | J. Rosenberg. |
| Date: | December 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5025 |
|
Authorization is a key function in presence systems. Authorization policies, also known as authorization rules, specify what presence information can be given to which watchers, and when. This specification defines an Extensible Markup Language (XML) document format for expressing presence authorization rules. Such a document can be manipulated by clients using the XML Configuration AccessProtocol (XCAP), although other techniques are permitted. |
|
| |
| RFC 5026 | Mobile IPv6 Bootstrapping in Split Scenario |
| |
| Authors: | G. Giaretta, Ed., J. Kempf, V. Devarapalli, Ed.. |
| Date: | October 2007 |
| Formats: | txt json html |
| Updated by: | RFC 8553 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5026 |
|
A Mobile IPv6 node requires a Home Agent address, a home address, andIPsec security associations with its Home Agent before it can start utilizing Mobile IPv6 service. RFC 3775 requires that some or all of these are statically configured. This document defines how a MobileIPv6 node can bootstrap this information from non-topological information and security credentials pre-configured on the MobileNode. The solution defined in this document solves the split scenario described in the Mobile IPv6 bootstrapping problem statement in RFC 4640. The split scenario refers to the case where the MobileNode's mobility service is authorized by a different service provider than basic network access. The solution described in this document is also generically applicable to any bootstrapping case, since other scenarios are more specific realizations of the split scenario. |
|
| |
| RFC 5027 | Security Preconditions for Session Description Protocol (SDP) Media Streams |
| |
|
|
This document defines a new security precondition for the SessionDescription Protocol (SDP) precondition framework described in RFCs3312 and 4032. A security precondition can be used to delay session establishment or modification until media stream security for a secure media stream has been negotiated successfully. |
|
| |
| RFC 5028 | A Telephone Number Mapping (ENUM) Service Registration for Instant Messaging (IM) Services |
| |
|
|
This document registers a Telephone Number Mapping (ENUM) service forInstant Messaging (IM). Specifically, this document focuses on provisioning 'im:' URIs (Uniform Resource Identifiers) in ENUM. |
|
| |
| RFC 5029 | Definition of an IS-IS Link Attribute Sub-TLV |
| |
| Authors: | JP. Vasseur, S. Previdi. |
| Date: | September 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5029 |
|
This document defines a sub-TLV called "Link-attributes" carried within the TLV 22 and used to flood some link characteristics. |
|
| |
| RFC 5031 | A Uniform Resource Name (URN) for Emergency and Other Well-Known Services |
| |
|
|
The content of many communication services depends on the context, such as the user's location. We describe a 'service' URN that allows well-known context-dependent services that can be resolved in a distributed manner to be identified. Examples include emergency services, directory assistance, and call-before-you-dig hot lines. |
|
| |
| RFC 5032 | WITHIN Search Extension to the IMAP Protocol |
| |
|
|
This document describes the WITHIN extension to IMAP SEARCH. IMAPSEARCH returns messages whose internal date is within or outside a specified interval. The mechanism described here, OLDER and YOUNGER, differs from BEFORE and SINCE in that the client specifies an interval, rather than a date. WITHIN is useful for persistent searches where either the device does not have the capacity to perform the search at regular intervals or the network is of limited bandwidth and thus there is a desire to reduce network traffic from sending repeated requests and redundant responses. |
|
| |
| RFC 5034 | The Post Office Protocol (POP3) Simple Authentication and Security Layer (SASL) Authentication Mechanism |
| |
|
|
This document defines a profile of the Simple Authentication andSecurity Layer (SASL) for the Post Office Protocol (POP3). This extension allows a POP3 client to indicate an authentication mechanism to the server, perform an authentication protocol exchange, and optionally negotiate a security layer for subsequent protocol interactions during this session.
This document seeks to consolidate the information related to POP3AUTH into a single document. To this end, this document obsoletes and replaces RFC 1734, and updates the information contained inSection 6.3 of RFC 2449. |
|
| |
| RFC 5035 | Enhanced Security Services (ESS) Update: Adding CertID Algorithm Agility |
| |
|
|
In the original Enhanced Security Services for S/MIME document (RFC2634), a structure for cryptographically linking the certificate to be used in validation with the signature was introduced; this structure was hardwired to use SHA-1. This document allows for the structure to have algorithm agility and defines a new attribute for this purpose. |
|
| |
| RFC 5040 | A Remote Direct Memory Access Protocol Specification |
| |
| Authors: | R. Recio, B. Metzler, P. Culley, J. Hilland, D. Garcia. |
| Date: | October 2007 |
| Formats: | txt json html |
| Updated by: | RFC 7146 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5040 |
|
This document defines a Remote Direct Memory Access Protocol (RDMAP) that operates over the Direct Data Placement Protocol (DDP protocol).RDMAP provides read and write services directly to applications and enables data to be transferred directly into Upper Layer Protocol(ULP) Buffers without intermediate data copies. It also enables a kernel bypass implementation. |
|
| |
| RFC 5041 | Direct Data Placement over Reliable Transports |
| |
| Authors: | H. Shah, J. Pinkerton, R. Recio, P. Culley. |
| Date: | October 2007 |
| Formats: | txt json html |
| Updated by: | RFC 7146 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5041 |
|
The Direct Data Placement protocol provides information to Place the incoming data directly into an upper layer protocol's receive buffer without intermediate buffers. This removes excess CPU and memory utilization associated with transferring data through the intermediate buffers. |
|
| |
| RFC 5042 | Direct Data Placement Protocol (DDP) / Remote Direct Memory Access Protocol (RDMAP) Security |
| |
| Authors: | J. Pinkerton, E. Deleganes. |
| Date: | October 2007 |
| Formats: | txt html json |
| Updated by: | RFC 7146 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5042 |
|
This document analyzes security issues around implementation and use of the Direct Data Placement Protocol (DDP) and Remote Direct MemoryAccess Protocol (RDMAP). It first defines an architectural model for an RDMA Network Interface Card (RNIC), which can implement DDP orRDMAP and DDP. The document reviews various attacks against the resources defined in the architectural model and the countermeasures that can be used to protect the system. Attacks are grouped into those that can be mitigated by using secure communication channels across the network, attacks from Remote Peers, and attacks from LocalPeers. Attack categories include spoofing, tampering, information disclosure, denial of service, and elevation of privilege. |
|
| |
| RFC 5043 | Stream Control Transmission Protocol (SCTP) Direct Data Placement (DDP) Adaptation |
| |
|
|
This document specifies an adaptation layer to provide a Lower LayerProtocol (LLP) service for Direct Data Placement (DDP) using theStream Control Transmission Protocol (SCTP). |
|
| |
| RFC 5044 | Marker PDU Aligned Framing for TCP Specification |
| |
| Authors: | P. Culley, U. Elzur, R. Recio, S. Bailey, J. Carrier. |
| Date: | October 2007 |
| Formats: | txt json html |
| Updated by: | RFC 6581, RFC 7146 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5044 |
|
Marker PDU Aligned Framing (MPA) is designed to work as an"adaptation layer" between TCP and the Direct Data Placement protocol(DDP) as described in RFC 5041. It preserves the reliable, in-order delivery of TCP, while adding the preservation of higher-level protocol record boundaries that DDP requires. MPA is fully compliant with applicable TCP RFCs and can be utilized with existing TCP implementations. MPA also supports integrated implementations that combine TCP, MPA and DDP to reduce buffering requirements in the implementation and improve performance at the system level. |
|
| |
| RFC 5046 | Internet Small Computer System Interface (iSCSI) Extensions for Remote Direct Memory Access (RDMA) |
| |
| Authors: | M. Ko, M. Chadalapaka, J. Hufferd, U. Elzur, H. Shah, P. Thaler. |
| Date: | October 2007 |
| Formats: | txt html json |
| Obsoleted by: | RFC 7145 |
| Updated by: | RFC 7146 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5046 |
|
Internet Small Computer System Interface (iSCSI) Extensions forRemote Direct Memory Access (RDMA) provides the RDMA data transfer capability to iSCSI by layering iSCSI on top of an RDMA-CapableProtocol, such as the iWARP protocol suite. An RDMA-Capable Protocol provides RDMA Read and Write services, which enable data to be transferred directly into SCSI I/O Buffers without intermediate data copies. This document describes the extensions to the iSCSI protocol to support RDMA services as provided by an RDMA-Capable Protocol, such as the iWARP protocol suite. |
|
| |
| RFC 5048 | Internet Small Computer System Interface (iSCSI) Corrections and Clarifications |
| |
|
|
The Internet Small Computer System Interface (iSCSI) is a SCSI transport protocol and maps the SCSI architecture and command sets onto TCP/IP. RFC 3720 defines the iSCSI protocol. This document compiles the clarifications to the original protocol definition inRFC 3720 to serve as a companion document for the iSCSI implementers.This document updates RFC 3720 and the text in this document supersedes the text in RFC 3720 when the two differ. |
|
| |
| RFC 5049 | Applying Signaling Compression (SigComp) to the Session Initiation Protocol (SIP) |
| |
| Authors: | C. Bormann, Z. Liu, R. Price, G. Camarillo, Ed.. |
| Date: | December 2007 |
| Formats: | txt json html |
| Updates: | RFC 3486 |
| Updated by: | RFC 8996 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5049 |
|
This document describes some specifics that apply when SignalingCompression (SigComp) is applied to the Session Initiation Protocol(SIP), such as default minimum values of SigComp parameters, compartment and state management, and a few issues on SigComp overTCP. Any implementation of SigComp for use with SIP must conform to this document and SigComp, and in addition, support the SIP andSession Description Protocol (SDP) static dictionary. |
|
| |
| RFC 5051 | i;unicode-casemap - Simple Unicode Collation Algorithm |
| |
| Authors: | M. Crispin. |
| Date: | October 2007 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5051 |
|
This document describes "i;unicode-casemap", a simple case- insensitive collation for Unicode strings. It provides equality, substring, and ordering operations. |
|
| |
| RFC 5052 | Forward Error Correction (FEC) Building Block |
| |
| Authors: | M. Watson, M. Luby, L. Vicisano. |
| Date: | August 2007 |
| Formats: | txt html json |
| Obsoletes: | RFC 3452 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5052 |
|
This document describes how to use Forward Error Correction (FEC) codes to efficiently provide and/or augment reliability for bulk data transfer over IP multicast. This document defines a framework for the definition of the information that needs to be communicated in order to use an FEC code for bulk data transfer, in addition to the encoded data itself, and for definition of formats and codes for communication of that information. Both information communicated with the encoded data itself and information that needs to be communicated 'out-of-band' are considered. The procedures for specifying new FEC codes, defining the information communication requirements associated with those codes and registering them with the Internet Assigned Numbers Authority (IANA) are also described.The requirements on Content Delivery Protocols that wish to use FEC codes defined within this framework are also defined. The companion document titled "The Use of Forward Error Correction (FEC) inReliable Multicast" describes some applications of FEC codes for delivering content. This document obsoletes RFC 3452. |
|
| |
| RFC 5053 | Raptor Forward Error Correction Scheme for Object Delivery |
| |
| Authors: | M. Luby, A. Shokrollahi, M. Watson, T. Stockhammer. |
| Date: | October 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5053 |
|
This document describes a Fully-Specified Forward Error Correction(FEC) scheme, corresponding to FEC Encoding ID 1, for the Raptor forward error correction code and its application to reliable delivery of data objects.
Raptor is a fountain code, i.e., as many encoding symbols as needed can be generated by the encoder on-the-fly from the source symbols of a source block of data. The decoder is able to recover the source block from any set of encoding symbols only slightly more in number than the number of source symbols.
The Raptor code described here is a systematic code, meaning that all the source symbols are among the encoding symbols that can be generated. |
|
| |
| RFC 5055 | Server-Based Certificate Validation Protocol (SCVP) |
| |
| Authors: | T. Freeman, R. Housley, A. Malpani, D. Cooper, W. Polk. |
| Date: | December 2007 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5055 |
|
The Server-Based Certificate Validation Protocol (SCVP) allows a client to delegate certification path construction and certification path validation to a server. The path construction or validation(e.g., making sure that none of the certificates in the path are revoked) is performed according to a validation policy, which contains one or more trust anchors. It allows simplification of client implementations and use of a set of predefined validation policies. |
|
| |
| RFC 5056 | On the Use of Channel Bindings to Secure Channels |
| |
| Authors: | N. Williams. |
| Date: | November 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5056 |
|
The concept of channel binding allows applications to establish that the two end-points of a secure channel at one network layer are the same as at a higher layer by binding authentication at the higher layer to the channel at the lower layer. This allows applications to delegate session protection to lower layers, which has various performance benefits.
This document discusses and formalizes the concept of channel binding to secure channels. |
|
| |
| RFC 5059 | Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM) |
| |
|
|
This document specifies the Bootstrap Router (BSR) mechanism for the class of multicast routing protocols in the PIM (Protocol IndependentMulticast) family that use the concept of a Rendezvous Point as a means for receivers to discover the sources that send to a particular multicast group. BSR is one way that a multicast router can learn the set of group-to-RP mappings required in order to function. The mechanism is dynamic, largely self-configuring, and robust to router failure. |
|
| |
| RFC 5060 | Protocol Independent Multicast MIB |
| |
| Authors: | R. Sivaramu, J. Lingard, D. McWalter, B. Joshi, A. Kessler. |
| Date: | January 2008 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5060 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes managed objects used for managing theProtocol Independent Multicast (PIM) protocols: PIM-SM (Sparse Mode),BIDIR-PIM (Bidirectional), and PIM-DM (Dense Mode). This document is part of work in progress to obsolete RFC 2934, and is to be preferred where the two documents overlap. This document does not obsolete RFC2934. |
|
| |
| RFC 5061 | Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration |
| |
| Authors: | R. Stewart, Q. Xie, M. Tuexen, S. Maruyama, M. Kozuka. |
| Date: | September 2007 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5061 |
|
A local host may have multiple points of attachment to the Internet, giving it a degree of fault tolerance from hardware failures. StreamControl Transmission Protocol (SCTP) (RFC 4960) was developed to take full advantage of such a multi-homed host to provide a fast failover and association survivability in the face of such hardware failures.This document describes an extension to SCTP that will allow an SCTP stack to dynamically add an IP address to an SCTP association, dynamically delete an IP address from an SCTP association, and to request to set the primary address the peer will use when sending to an endpoint. |
|
| |
| RFC 5063 | Extensions to GMPLS Resource Reservation Protocol (RSVP) Graceful Restart |
| |
|
|
This document describes extensions to the Resource ReservationProtocol (RSVP) Graceful Restart mechanisms defined in RFC 3473. The extensions enable the recovery of RSVP signaling state based on thePath message last sent by the node being restarted.
Previously defined Graceful Restart mechanisms, also called recovery from nodal faults, permit recovery of signaling state from adjacent nodes when the data plane has retained the associated forwarding state across a restart. Those mechanisms do not fully support signaling state recovery on ingress nodes or recovery of all RSVP objects.
The extensions defined in this document build on the RSVP Hello extensions defined in RFC 3209, and extensions for state recovery on nodal faults defined in RFC 3473. Using these extensions, the restarting node can recover all previously transmitted Path state, including the Explicit Route Object and the downstream (outgoing) interface identifiers. The extensions can also be used to recover signaling state after the restart of an ingress node.
These extensions are not used to create or restore data plane state.
The extensions optionally support the use of Summary Refresh, defined in RFC 2961, to reduce the number of messages exchanged during theRecovery Phase when the restarting node has recovered signaling state locally for one or more Label Switched Paths (LSPs). |
|
| |
| RFC 5064 | The Archived-At Message Header Field |
| |
| Authors: | M. Duerst. |
| Date: | December 2007 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5064 |
|
This memo defines a new email header field, Archived-At:, to provide a direct link to the archived form of an individual email message. |
|
| |
| RFC 5066 | Ethernet in the First Mile Copper (EFMCu) Interfaces MIB |
| |
|
|
This document defines Management Information Base (MIB) modules for use with network management protocols in TCP/IP-based internets.This document describes extensions to the Ethernet-like InterfacesMIB and Medium Attachment Unit (MAU) MIB modules with a set of objects for managing Ethernet in the First Mile Copper (EFMCu) interfaces 10PASS-TS and 2BASE-TL, defined in IEEE Std 802.3ah-2004(note: IEEE Std 802.3ah-2004 has been integrated into IEEE Std 802.3-2005). In addition, a set of objects is defined, describing cross- connect capability of a managed device with multi-layer (stacked) interfaces, extending the stack management objects in the InterfacesGroup MIB and the Inverted Stack Table MIB modules. |
|
| |
| RFC 5070 | The Incident Object Description Exchange Format |
| |
|
|
The Incident Object Description Exchange Format (IODEF) defines a data representation that provides a framework for sharing information commonly exchanged by Computer Security Incident Response Teams(CSIRTs) about computer security incidents. This document describes the information model for the IODEF and provides an associated data model specified with XML Schema. |
|
| |
| RFC 5073 | IGP Routing Protocol Extensions for Discovery of Traffic Engineering Node Capabilities |
| |
| Authors: | J.P. Vasseur, Ed., J.L. Le Roux, Ed.. |
| Date: | December 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5073 |
|
It is highly desired, in several cases, to take into account TrafficEngineering (TE) node capabilities during Multi Protocol LabelSwitching (MPLS) and Generalized MPLS (GMPLS) Traffic EngineeredLabel Switched Path (TE-LSP) selection, such as, for instance, the capability to act as a branch Label Switching Router (LSR) of aPoint-To-MultiPoint (P2MP) LSP. This requires advertising these capabilities within the Interior Gateway Protocol (IGP). For that purpose, this document specifies Open Shortest Path First (OSPF) andIntermediate System-Intermediate System (IS-IS) traffic engineering extensions for the advertisement of control plane and data plane traffic engineering node capabilities. |
|
| |
| RFC 5075 | IPv6 Router Advertisement Flags Option |
| |
| Authors: | B. Haberman, Ed., R. Hinden. |
| Date: | November 2007 |
| Formats: | txt json html |
| Obsoleted by: | RFC 5175 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5075 |
|
The IPv6 Neighbor Discovery's Router Advertisement message contains an 8-bit field reserved for single-bit flags. Several protocols have reserved flags in this field and others are preparing to reserve a sufficient number of flags to exhaust the field. This document defines an option to the Router Advertisement message that expands the available number of flag bits available. |
|
| |
| RFC 5076 | ENUM Validation Information Mapping for the Extensible Provisioning Protocol |
| |
| Authors: | B. Hoeneisen. |
| Date: | December 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5076 |
|
This document describes an Extensible Provisioning Protocol (EPP) extension framework for mapping information about the validation process that has been applied for the E.164 number (or number range) that the E.164 Number Mapping (ENUM) domain name is based on.Specified in the Extensible Markup Language (XML), this mapping extends the EPP domain name mapping to provide an additional feature required for the provisioning of ENUM Domain Names. |
|
| |
| RFC 5077 | Transport Layer Security (TLS) Session Resumption without Server-Side State |
| |
|
|
This document describes a mechanism that enables the Transport LayerSecurity (TLS) server to resume sessions and avoid keeping per-client session state. The TLS server encapsulates the session state into a ticket and forwards it to the client. The client can subsequently resume a session using the obtained ticket. This document obsoletesRFC 4507. |
|
| |
| RFC 5079 | Rejecting Anonymous Requests in the Session Initiation Protocol (SIP) |
| |
| Authors: | J. Rosenberg. |
| Date: | December 2007 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5079 |
|
The Session Initiation Protocol (SIP) allows for users to make anonymous calls. However, users receiving such calls have the right to reject them because they are anonymous. SIP has no way to indicate to the caller that the reason for call rejection was that the call was anonymous. Such an indication is useful to allow the call to be retried without anonymity. This specification defines a new SIP response code for this purpose. |
|
| |
| RFC 5080 | Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes |
| |
|
|
This document describes common issues seen in Remote AuthenticationDial In User Service (RADIUS) implementations and suggests some fixes. Where applicable, ambiguities and errors in previous RADIUS specifications are clarified. |
|
| |
| RFC 5082 | The Generalized TTL Security Mechanism (GTSM) |
| |
| Authors: | V. Gill, J. Heasley, D. Meyer, P. Savola, Ed., C. Pignataro. |
| Date: | October 2007 |
| Formats: | txt html json |
| Obsoletes: | RFC 3682 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5082 |
|
The use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to verify whether the packet was originated by an adjacent node on a connected link has been used in many recent protocols. This document generalizes this technique. This document obsoletes Experimental RFC3682. |
|
| |
| RFC 5083 | Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type |
| |
|
|
This document describes an additional content type for theCryptographic Message Syntax (CMS). The authenticated-enveloped-data content type is intended for use with authenticated encryption modes.All of the various key management techniques that are supported in the CMS enveloped-data content type are also supported by the CMS authenticated-enveloped-data content type. |
|
| |
| RFC 5084 | Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax (CMS) |
| |
| Authors: | R. Housley. |
| Date: | November 2007 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5084 |
|
This document specifies the conventions for using the AES-CCM and theAES-GCM authenticated encryption algorithms with the CryptographicMessage Syntax (CMS) authenticated-enveloped-data content type. |
|
| |
| RFC 5085 | Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires |
| |
| Authors: | T. Nadeau, Ed., C. Pignataro, Ed.. |
| Date: | December 2007 |
| Formats: | txt json html |
| Updated by: | RFC 5586 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5085 |
|
This document describes Virtual Circuit Connectivity Verification(VCCV), which provides a control channel that is associated with a pseudowire (PW), as well as the corresponding operations and management functions (such as connectivity verification) to be used over that control channel. VCCV applies to all supported access circuit and transport types currently defined for PWs. |
|
| |
| RFC 5088 | OSPF Protocol Extensions for Path Computation Element (PCE) Discovery |
| |
| Authors: | JL. Le Roux, Ed., JP. Vasseur, Ed., Y. Ikejiri, R. Zhang. |
| Date: | January 2008 |
| Formats: | txt json html |
| Updated by: | RFC 9353 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5088 |
|
There are various circumstances where it is highly desirable for aPath Computation Client (PCC) to be able to dynamically and automatically discover a set of Path Computation Elements (PCEs), along with information that can be used by the PCC for PCE selection.When the PCE is a Label Switching Router (LSR) participating in theInterior Gateway Protocol (IGP), or even a server participating passively in the IGP, a simple and efficient way to announce PCEs consists of using IGP flooding. For that purpose, this document defines extensions to the Open Shortest Path First (OSPF) routing protocol for the advertisement of PCE Discovery information within anOSPF area or within the entire OSPF routing domain. |
|
| |
| RFC 5089 | IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery |
| |
| Authors: | JL. Le Roux, Ed., JP. Vasseur, Ed., Y. Ikejiri, R. Zhang. |
| Date: | January 2008 |
| Formats: | txt json html |
| Updated by: | RFC 9353 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5089 |
|
There are various circumstances where it is highly desirable for aPath Computation Client (PCC) to be able to dynamically and automatically discover a set of Path Computation Elements (PCEs), along with information that can be used by the PCC for PCE selection.When the PCE is a Label Switching Router (LSR) participating in theInterior Gateway Protocol (IGP), or even a server participating passively in the IGP, a simple and efficient way to announce PCEs consists of using IGP flooding. For that purpose, this document defines extensions to the Intermediate System to Intermediate System(IS-IS) routing protocol for the advertisement of PCE Discovery information within an IS-IS area or within the entire IS-IS routing domain. |
|
| |
| RFC 5090 | RADIUS Extension for Digest Authentication |
| |
| Authors: | B. Sterman, D. Sadolevsky, D. Schwartz, D. Williams, W. Beck. |
| Date: | February 2008 |
| Formats: | txt json html |
| Obsoletes: | RFC 4590 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5090 |
|
This document defines an extension to the Remote AuthenticationDial-In User Service (RADIUS) protocol to enable support of DigestAuthentication, for use with HTTP-style protocols like the SessionInitiation Protocol (SIP) and HTTP. |
|
| |
| RFC 5092 | IMAP URL Scheme |
| |
|
|
IMAP (RFC 3501) 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 an IMAP server.
This document obsoletes RFC 2192. It also updates RFC 4467. |
|
| |
| RFC 5094 | Mobile IPv6 Vendor Specific Option |
| |
| Authors: | V. Devarapalli, A. Patel, K. Leung. |
| Date: | December 2007 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5094 |
|
There is a need for vendor-specific extensions to Mobility Header messages so that Mobile IPv6 vendors are able to extend the protocol for research or deployment purposes. This document defines a new vendor-specific mobility option. |
|
| |
| RFC 5095 | Deprecation of Type 0 Routing Headers in IPv6 |
| |
|
|
The functionality provided by IPv6's Type 0 Routing Header can be exploited in order to achieve traffic amplification over a remote path for the purposes of generating denial-of-service traffic. This document updates the IPv6 specification to deprecate the use of IPv6Type 0 Routing Headers, in light of this security concern. |
|
| |
| RFC 5096 | Mobile IPv6 Experimental Messages |
| |
| Authors: | V. Devarapalli. |
| Date: | December 2007 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5096 |
|
This document defines a new experimental Mobility Header message and a Mobility option that can be used for experimental extensions to theMobile IPv6 protocol. |
|
| |
| RFC 5097 | MIB for the UDP-Lite protocol |
| |
| Authors: | G. Renker, G. Fairhurst. |
| Date: | January 2008 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5097 |
|
This document specifies a Management Information Base (MIB) module for the Lightweight User Datagram Protocol (UDP-Lite). It defines a set of new MIB objects to characterise the behaviour and performance of transport layer endpoints deploying UDP-Lite. UDP-Lite resemblesUDP, but differs from the semantics of UDP by the addition of a single option. This adds the capability for variable-length data checksum coverage, which can benefit a class of applications that prefer delivery of (partially) corrupted datagram payload data in preference to discarding the datagram. |
|
| |
| RFC 5098 | Signaling MIB for PacketCable and IPCablecom Multimedia Terminal Adapters (MTAs) |
| |
| Authors: | G. Beacham, S. Kumar, S. Channabasappa. |
| Date: | February 2008 |
| Formats: | txt json html |
| Updated by: | RFC 9141 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5098 |
|
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 SimpleNetwork Management Protocol (SNMP)-based management of PacketCable- and IPCablecom-compliant Multimedia Terminal Adapter devices. |
|
| |
| RFC 5101 | Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information |
| |
|
|
This document specifies the IP Flow Information Export (IPFIX) protocol that serves for transmitting IP Traffic Flow information over the network. In order to transmit IP Traffic Flow information from an Exporting Process to an information Collecting Process, a common representation of flow data and a standard means of communicating them is required. This document describes how theIPFIX Data and Template Records are carried over a number of transport protocols from an IPFIX Exporting Process to an IPFIXCollecting Process. |
|
| |
| RFC 5102 | Information Model for IP Flow Information Export |
| |
| Authors: | J. Quittek, S. Bryant, B. Claise, P. Aitken, J. Meyer. |
| Date: | January 2008 |
| Formats: | txt html json |
| Obsoleted by: | RFC 7012 |
| Updated by: | RFC 6313 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5102 |
|
This memo defines an information model for the IP Flow Information eXport (IPFIX) protocol. It is used by the IPFIX protocol for encoding measured traffic information and information related to the traffic Observation Point, the traffic Metering Process, and theExporting Process. Although developed for the IPFIX protocol, the model is defined in an open way that easily allows using it in other protocols, interfaces, and applications. |
|
| |
| RFC 5103 | Bidirectional Flow Export Using IP Flow Information Export (IPFIX) |
| |
| Authors: | B. Trammell, E. Boschi. |
| Date: | January 2008 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5103 |
|
This document describes an efficient method for exporting bidirectional flow (Biflow) information using the IP Flow InformationExport (IPFIX) protocol, representing each Biflow using a single FlowRecord. |
|
| |
| RFC 5104 | Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF) |
| |
|
|
This document specifies a few extensions to the messages defined in the Audio-Visual Profile with Feedback (AVPF). They are helpful primarily in conversational multimedia scenarios where centralized multipoint functionalities are in use. However, some are also usable in smaller multicast environments and point-to-point calls.
The extensions discussed are messages related to the ITU-T Rec. H.271Video Back Channel, Full Intra Request, Temporary Maximum MediaStream Bit Rate, and Temporal-Spatial Trade-off. |
|
| |
| RFC 5105 | ENUM Validation Token Format Definition |
| |
| Authors: | O. Lendl. |
| Date: | December 2007 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5105 |
|
An ENUM domain name is tightly coupled with the underlying E.164 number. The process of verifying whether the Registrant of an ENUM domain name is identical to the Assignee of the corresponding E.164 number is commonly called "validation". This document describes a signed XML data format -- the Validation Token -- with whichValidation Entities can convey successful completion of a validation procedure in a secure fashion. |
|
| |
| RFC 5107 | DHCP Server Identifier Override Suboption |
| |
| Authors: | R. Johnson, J. Kumarasamy, K. Kinnear, M. Stapp. |
| Date: | February 2008 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5107 |
|
This memo defines a new suboption of the DHCP relay information option that allows the DHCP relay to specify a new value for theServer Identifier option, which is inserted by the DHCP Server. This allows the DHCP relay to act as the actual DHCP server such thatRENEW DHCPREQUESTs will come to the relay instead of going to the server directly. This gives the relay the opportunity to include theRelay Agent option with appropriate suboptions even on DHCP RENEW messages. |
|
| |
| RFC 5109 | RTP Payload Format for Generic Forward Error Correction |
| |
|
|
This document specifies a payload format for generic Forward ErrorCorrection (FEC) for media data encapsulated in RTP. It is based on the exclusive-or (parity) operation. The payload format described in this document allows end systems to apply protection using various protection lengths and levels, in addition to using various protection group sizes to adapt to different media and channel characteristics. It enables complete recovery of the protected packets or partial recovery of the critical parts of the payload depending on the packet loss situation. This scheme is completely compatible with non-FEC-capable hosts, so the receivers in a multicast group that do not implement FEC can still work by simply ignoring the protection data. This specification obsoletes RFC 2733 and RFC 3009. The FEC specified in this document is not backward compatible with RFC 2733 and RFC 3009. |
|
| |
| RFC 5112 | The Presence-Specific Static Dictionary for Signaling Compression (Sigcomp) |
| |
| Authors: | M. Garcia-Martin. |
| Date: | January 2008 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5112 |
|
The Session Initiation Protocol (SIP) is a text-based protocol for initiating and managing communication sessions. The protocol is extended by the SIP-events notification framework to provide subscriptions and notifications of SIP events. One example of such event notification mechanism is presence, which is expressed in XML documents called presence documents. SIP can be compressed by usingSignaling Compression (SigComp), which is enhanced by using the SIP/Session Description Protocol (SDP) dictionary to achieve better compression rates. However, the SIP/SDP dictionary is not able to increase the compression factor of (typically lengthy) presence documents. This memo defines the presence-specific static dictionary that SigComp can use in order to compress presence documents to achieve higher efficiency. The dictionary is compression-algorithm independent. |
|
| |
| RFC 5115 | Telephony Routing over IP (TRIP) Attribute for Resource Priority |
| |
| Authors: | K. Carlberg, P. O'Hanlon. |
| Date: | January 2008 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5115 |
|
This document defines a new attribute for the Telephony Routing overIP (TRIP) protocol. The attribute associates protocols/services in the PSTN offering authorized prioritization during call setup that are reachable through a TRIP gateway. Current examples of preferential service in the Public Switched Telephone Network (PSTN) are Government Emergency Telecommunications Service (GETS) in theU.S. and Government Telephone Preference Scheme (GTPS) in the U.K.The proposed attribute for TRIP is based on the NameSpace.Value tuple defined for the SIP Resource-Priority field. |
|
| |
| RFC 5116 | An Interface and Algorithms for Authenticated Encryption |
| |
| Authors: | D. McGrew. |
| Date: | January 2008 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5116 |
|
This document defines algorithms for Authenticated Encryption withAssociated Data (AEAD), and defines a uniform interface and a registry for such algorithms. The interface and registry can be used as an application-independent set of cryptoalgorithm suites. This approach provides advantages in efficiency and security, and promotes the reuse of crypto implementations. |
|
| |
| RFC 5120 | M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs) |
| |
| Authors: | T. Przygienda, N. Shen, N. Sheth. |
| Date: | February 2008 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5120 |
|
This document describes an optional mechanism within IntermediateSystem to Intermediate Systems (IS-ISs) used today by many ISPs forIGP routing within their clouds. This document describes how to run, within a single IS-IS domain, a set of independent IP topologies that we call Multi-Topologies (MTs). This MT extension can be used for a variety of purposes, such as an in-band management network "on top" of the original IGP topology, maintaining separate IGP routing domains for isolated multicast or IPv6 islands within the backbone, or forcing a subset of an address space to follow a different topology. |
|
| |
| RFC 5121 | Transmission of IPv6 via the IPv6 Convergence Sublayer over IEEE 802.16 Networks |
| |
| Authors: | B. Patil, F. Xia, B. Sarikaya, JH. Choi, S. Madanapalli. |
| Date: | February 2008 |
| Formats: | txt json html |
| Updated by: | RFC 8064 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5121 |
|
IEEE Std 802.16 is an air interface specification for fixed and mobile Broadband Wireless Access Systems. Service-specific convergence sublayers to which upper-layer protocols interface are a part of the IEEE 802.16 MAC (Medium Access Control). The Packet convergence sublayer (CS) is used for the transport of all packet- based protocols such as Internet Protocol (IP) and IEEE 802.3 LAN/MANCSMA/CD Access Method (Ethernet). IPv6 packets can be sent and received via the IP-specific part of the Packet CS. This document specifies the addressing and operation of IPv6 over the IP-specific part of the Packet CS for hosts served by a network that utilizes theIEEE Std 802.16 air interface. It recommends the assignment of a unique prefix (or prefixes) to each host and allows the host to use multiple identifiers within that prefix, including support for randomly generated interface identifiers. |
|
| |
| RFC 5122 | Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP) |
| |
|
|
This document defines the use of Internationalized ResourceIdentifiers (IRIs) and Uniform Resource Identifiers (URIs) in identifying or interacting with entities that can communicate via theExtensible Messaging and Presence Protocol (XMPP).
This document obsoletes RFC 4622. |
|
| |
| RFC 5124 | Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF) |
| |
| Authors: | J. Ott, E. Carrara. |
| Date: | February 2008 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5124 |
|
An RTP profile (SAVP) for secure real-time communications and another profile (AVPF) to provide timely feedback from the receivers to a sender are defined in RFC 3711 and RFC 4585, respectively. This memo specifies the combination of both profiles to enable secure RTP communications with feedback. |
|
| |
| RFC 5129 | Explicit Congestion Marking in MPLS |
| |
|
|
RFC 3270 defines how to support the Diffserv architecture in MPLS networks, including how to encode Diffserv Code Points (DSCPs) in anMPLS header. DSCPs may be encoded in the EXP field, while other uses of that field are not precluded. RFC 3270 makes no statement about how Explicit Congestion Notification (ECN) marking might be encoded in the MPLS header. This document defines how an operator might define some of the EXP codepoints for explicit congestion notification, without precluding other uses. |
|
| |
| RFC 5130 | A Policy Control Mechanism in IS-IS Using Administrative Tags |
| |
| Authors: | S. Previdi, M. Shand, Ed., C. Martin. |
| Date: | February 2008 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5130 |
|
This document describes an extension to the IS-IS protocol to add operational capabilities that allow for ease of management and control over IP prefix distribution within an IS-IS domain. This document enhances the IS-IS protocol by extending the information that an Intermediate System (IS) router can place in Link StateProtocol (LSP) Data Units for policy use. This extension will provide operators with a mechanism to control IP prefix distribution throughout multi-level IS-IS domains. |
|
| |
| RFC 5131 | A MIB Textual Convention for Language Tags |
| |
| Authors: | D. McWalter, Ed.. |
| Date: | December 2007 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5131 |
|
This MIB module defines a textual convention to represent BCP 47 language tags. The intent is that this textual convention will be imported and used in MIB modules that would otherwise define their own representation. |
|
| |
| RFC 5132 | IP Multicast MIB |
| |
| Authors: | D. McWalter, D. Thaler, A. Kessler. |
| Date: | December 2007 |
| Formats: | txt html json |
| Obsoletes: | RFC 2932 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5132 |
|
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 multicast function, independent of the specific multicast protocol(s) in use.This document obsoletes RFC 2932. |
|
| |
| RFC 5133 | Terminal Endpoint Identifier (TEI) Query Request Number Change |
| |
| Authors: | M. Tuexen, K. Morneault. |
| Date: | December 2007 |
| Formats: | txt html json |
| Updates: | RFC 4233 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5133 |
|
The Integrated Services Digital Network (ISDN) Q.921-User AdaptationLayer (IUA) Protocol, described in RFC 4233, defines the message type of Terminal Endpoint Identifier (TEI) Query Request messages as 5.However, this number is already being used by the Digital PrivateNetwork Signaling System (DPNSS)/Digital Access Signaling System 2(DASS 2) Extensions (DUA) to the IUA Protocol described in RFC 4129.This document updates RFC 4233 such that the message type of TEIQuery Request messages is 8. |
|
| |
| RFC 5139 | Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO) |
| |
| Authors: | M. Thomson, J. Winterbottom. |
| Date: | February 2008 |
| Formats: | txt json html |
| Updates: | RFC 4119 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5139 |
|
This document defines an XML format for the representation of civic location. This format is designed for use with Presence InformationData Format Location Object (PIDF-LO) documents and replaces the civic location format in RFC 4119. The format is based on the civic address definition in PIDF-LO, but adds several new elements based on the civic types defined for Dynamic Host Configuration Protocol(DHCP), and adds a hierarchy to address complex road identity schemes. The format also includes support for the xml:lang language tag and restricts the types of elements where appropriate. |
|
| |
| RFC 5140 | A Telephony Gateway REgistration Protocol (TGREP) |
| |
| Authors: | M. Bangalore, R. Kumar, J. Rosenberg, H. Salama, D.N. Shah. |
| Date: | March 2008 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5140 |
|
This document describes the Telephony Gateway Registration Protocol(TGREP) for registration of telephony prefixes supported by telephony gateways and soft switches. The registration mechanism can also be used to export resource information. The prefix and resource information can then be passed on to a Telephony Routing over IP(TRIP) Location Server, which in turn can propagate that routing information within and between Internet Telephony AdministrativeDomains (ITADs). TGREP shares a lot of similarities with the TRIP protocol. It has similar procedures and finite state machine for session establishment. It also shares the same format for messages and a subset of attributes with TRIP. |
|
| |
| RFC 5142 | Mobility Header Home Agent Switch Message |
| |
| Authors: | B. Haley, V. Devarapalli, H. Deng, J. Kempf. |
| Date: | January 2008 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5142 |
|
This document specifies a new Mobility Header message type that can be used between a home agent and mobile node to signal to a mobile node that it should acquire a new home agent. |
|
| |
| RFC 5144 | A Domain Availability Check (DCHK) Registry Type for the Internet Registry Information Service (IRIS) |
| |
| Authors: | A. Newton, M. Sanz. |
| Date: | February 2008 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5144 |
|
This document describes a lightweight domain availability service using the Internet Registry Information Service (IRIS) framework and the data model of the IRIS Domain Registry (DREG) service. |
|
| |
| RFC 5147 | URI Fragment Identifiers for the text/plain Media Type |
| |
|
|
This memo defines URI fragment identifiers for text/plain MIME entities. These fragment identifiers make it possible to refer to parts of a text/plain MIME entity, either identified by character position or range, or by line position or range. Fragment identifiers may also contain information for integrity checks to make them more robust. |
|
| |
| RFC 5150 | Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE) |
| |
| Authors: | A. Ayyangar, K. Kompella, JP. Vasseur, A. Farrel. |
| Date: | February 2008 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5150 |
|
In certain scenarios, there may be a need to combine severalGeneralized Multiprotocol Label Switching (GMPLS) Label SwitchedPaths (LSPs) such that a single end-to-end (e2e) LSP is realized and all traffic from one constituent LSP is switched onto the next LSP.We will refer to this as "LSP stitching", the key requirement being that a constituent LSP not be allocated to more than one e2e LSP.The constituent LSPs will be referred to as "LSP segments" (S-LSPs).
This document describes extensions to the existing GMPLS signaling protocol (Resource Reservation Protocol-Traffic Engineering (RSVP-TE)) to establish e2e LSPs created from S-LSPs, and describes how theLSPs can be managed using the GMPLS signaling and routing protocols.
It may be possible to configure a GMPLS node to switch the traffic from an LSP for which it is the egress, to another LSP for which it is the ingress, without requiring any signaling or routing extensions whatsoever and such that the operation is completely transparent to other nodes. This will also result in LSP stitching in the data plane. However, this document does not cover this scenario of LSP stitching. |
|
| |
| RFC 5151 | Inter-Domain MPLS and GMPLS Traffic Engineering -- Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions |
| |
|
|
This document describes procedures and protocol extensions for the use of Resource Reservation Protocol-Traffic Engineering (RSVP-TE) signaling in Multiprotocol Label Switching-Traffic Engineering(MPLS-TE) packet networks and Generalized MPLS (GMPLS) packet and non-packet networks to support the establishment and maintenance ofLabel Switched Paths that cross domain boundaries.
For the purpose of this document, a domain is considered to be any collection of network elements within a common realm of address space or path computation responsibility. Examples of such domains includeAutonomous Systems, Interior Gateway Protocol (IGP) routing areas, and GMPLS overlay networks. |
|
| |
| RFC 5152 | A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs) |
| |
| Authors: | JP. Vasseur, Ed., A. Ayyangar, Ed., R. Zhang. |
| Date: | February 2008 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5152 |
|
This document specifies a per-domain path computation technique for establishing inter-domain Traffic Engineering (TE) MultiprotocolLabel Switching (MPLS) and Generalized MPLS (GMPLS) Label SwitchedPaths (LSPs). In this document, a domain refers to a collection of network elements within a common sphere of address management or path computational responsibility such as Interior Gateway Protocol (IGP) areas and Autonomous Systems.
Per-domain computation applies where the full path of an inter-domainTE LSP cannot be or is not determined at the ingress node of the TELSP, and is not signaled across domain boundaries. This is most likely to arise owing to TE visibility limitations. The signaling message indicates the destination and nodes up to the next domain boundary. It may also indicate further domain boundaries or domain identifiers. The path through each domain, possibly including the choice of exit point from the domain, must be determined within the domain. |
|
| |
| RFC 5155 | DNS Security (DNSSEC) Hashed Authenticated Denial of Existence |
| |
|
|
The Domain Name System Security (DNSSEC) Extensions introduced theNSEC resource record (RR) for authenticated denial of existence.This document introduces an alternative resource record, NSEC3, which similarly provides authenticated denial of existence. However, it also provides measures against zone enumeration and permits gradual expansion of delegation-centric zones. |
|
| |
| RFC 5161 | The IMAP ENABLE Extension |
| |
| Authors: | A. Gulbrandsen, Ed., A. Melnikov, Ed.. |
| Date: | March 2008 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5161 |
|
Most IMAP extensions are used by the client when it wants to and the server supports it. However, a few extensions require the server to know whether a client supports that extension. The ENABLE extension allows an IMAP client to say which extensions it supports. |
|
| |
| RFC 5162 | IMAP4 Extensions for Quick Mailbox Resynchronization |
| |
| Authors: | A. Melnikov, D. Cridland, C. Wilson. |
| Date: | March 2008 |
| Formats: | txt json html |
| Obsoleted by: | RFC 7162 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5162 |
|
This document defines an IMAP4 extension, which gives an IMAP client the ability to quickly resynchronize any previously opened mailbox as part of the SELECT command, without the need for server-side state or additional client round-trips. This extension also introduces a new response that allows for a more compact representation of a list of expunged messages (and always includes the Unique Identifiers (UIDs) expunged). |
|
| |
| RFC 5163 | Extension Formats for Unidirectional Lightweight Encapsulation (ULE) and the Generic Stream Encapsulation (GSE) |
| |
| Authors: | G. Fairhurst, B. Collini-Nocker. |
| Date: | April 2008 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5163 |
|
This document describes a set of Extension Headers for theUnidirectional Lightweight Encapsulation (ULE), RFC 4326.
The Extension Header formats specified in this document define extensions appropriate to both ULE and the Generic StreamEncapsulation (GSE) for the second-generation framing structure defined by the Digital Video Broadcasting (DVB) family of specifications. |
|
| |
| RFC 5170 | Low Density Parity Check (LDPC) Staircase and Triangle Forward Error Correction (FEC) Schemes |
| |
| Authors: | V. Roca, C. Neumann, D. Furodet. |
| Date: | June 2008 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5170 |
|
This document describes two Fully-Specified Forward Error Correction(FEC) Schemes, Low Density Parity Check (LDPC) Staircase and LDPCTriangle, and their application to the reliable delivery of data objects on the packet erasure channel (i.e., a communication path where packets are either received without any corruption or discarded during transmission). These systematic FEC codes belong to the well- known class of "Low Density Parity Check" codes, and are large blockFEC codes in the sense of RFC 3453. |
|
| |
| RFC 5172 | Negotiation for IPv6 Datagram Compression Using IPv6 Control Protocol |
| |
|
|
The Point-to-Point Protocol (PPP) 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.
The IPv6 Control Protocol (IPV6CP), which is an NCP for a PPP link, allows for the negotiation of desirable parameters for an IPv6 interface over PPP.
This document defines the IPv6 datagram compression option that can be negotiated by a node on the link through the IPV6CP. |
|
| |
| RFC 5173 | Sieve Email Filtering: Body Extension |
| |
|
|
This document defines a new command for the "Sieve" email filtering language that tests for the occurrence of one or more strings in the body of an email message. |
|
| |
| RFC 5175 | IPv6 Router Advertisement Flags Option |
| |
| Authors: | B. Haberman, Ed., R. Hinden. |
| Date: | March 2008 |
| Formats: | txt html json |
| Obsoletes: | RFC 5075 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5175 |
|
The IPv6 Neighbor Discovery's Router Advertisement message contains an 8-bit field reserved for single-bit flags. Several protocols have reserved flags in this field and others are preparing to reserve a sufficient number of flags to exhaust the field. This document defines an option to the Router Advertisement message that expands the number of flag bits available. |
|
| |
| RFC 5177 | Network Mobility (NEMO) Extensions for Mobile IPv4 |
| |
| Authors: | K. Leung, G. Dommety, V. Narayanan, A. Petrescu. |
| Date: | April 2008 |
| Formats: | txt json html |
| Updated by: | RFC 6626 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5177 |
|
This document describes a protocol for supporting Mobile Networks between a Mobile Router and a Home Agent by extending the Mobile IPv4 protocol. A Mobile Router is responsible for the mobility of one or more network segments or subnets moving together. The Mobile Router hides its mobility from the nodes on the Mobile Network. The nodes on the Mobile Network may be fixed in relationship to the MobileRouter and may not have any mobility function.
Extensions to Mobile IPv4 are introduced to support Mobile Networks. |
|
| |
| RFC 5178 | Generic Security Service Application Program Interface (GSS-API) Internationalization and Domain-Based Service Names and Name Type |
| |
| Authors: | N. Williams, A. Melnikov. |
| Date: | May 2008 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5178 |
|
This document describes domain-name-based service principal names and the corresponding name type for the Generic Security ServiceApplication Programming Interface (GSS-API). Internationalization of the GSS-API is also covered.
Domain-based service names are similar to host-based service names, but using a domain name (not necessarily an Internet domain name) in addition to a hostname. The primary purpose of domain-based names is to provide a measure of protection to applications that utilize insecure service discovery protocols. This is achieved by providing a way to name clustered services after the "domain" which they service, thereby allowing their clients to authorize the service's servers based on authentication of their service names. |
|
| |
| RFC 5179 | Generic Security Service Application Program Interface (GSS-API) Domain-Based Service Names Mapping for the Kerberos V GSS Mechanism |
| |
| Authors: | N. Williams. |
| Date: | May 2008 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5179 |
|
This document describes the mapping of Generic Security ServiceApplication Program Interface (GSS-API) domain-name-based service principal names onto Kerberos V principal names. |
|
| |
| RFC 5182 | IMAP Extension for Referencing the Last SEARCH Result |
| |
|
|
Many IMAP clients use the result of a SEARCH command as the input to perform another operation, for example, fetching the found messages, deleting them, or copying them to another mailbox.
This can be achieved using standard IMAP operations described in RFC3501; however, this would be suboptimal. The server will send the list of found messages to the client; after that, the client will have to parse the list, reformat it, and send it back to the server.The client can't pipeline the SEARCH command with the subsequent command, and, as a result, the server might not be able to perform some optimizations.
This document proposes an IMAP extension that allows a client to tell a server to use the result of a SEARCH (or Unique Identifier (UID)SEARCH) command as an input to any subsequent command. |
|
| |
| RFC 5183 | Sieve Email Filtering: Environment Extension |
| |
| Authors: | N. Freed. |
| Date: | May 2008 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5183 |
|
This document describes the "environment" extension to the Sieve email filtering language. The "environment" extension gives a Sieve script access to information about the Sieve interpreter itself, where it is running, and about any transport connection currently involved in transferring the message. |
|
| |
| RFC 5185 | OSPF Multi-Area Adjacency |
| |
| Authors: | S. Mirtorabi, P. Psenak, A. Lindem, Ed., A. Oswal. |
| Date: | May 2008 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5185 |
|
This document describes an extension to the Open Shortest Path First(OSPF) protocol to allow a single physical link to be shared by multiple areas. This is necessary to allow the link to be considered an intra-area link in multiple areas. This would create an intra- area path in each of the corresponding areas sharing the same link. |
|
| |
| RFC 5187 | OSPFv3 Graceful Restart |
| |
| Authors: | P. Pillay-Esnault, A. Lindem. |
| Date: | June 2008 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5187 |
|
This document describes the OSPFv3 graceful restart. The OSPFv3 graceful restart is identical to that of OSPFv2 except for the differences described in this document. These differences include the format of the grace Link State Advertisements (LSAs) and other considerations. |
|
| |
| RFC 5188 | RTP Payload Format for the Enhanced Variable Rate Wideband Codec (EVRC-WB) and the Media Subtype Updates for EVRC-B Codec |
| |
|
|
This document specifies Real-time Transport Protocol (RTP) payload formats to be used for the Enhanced Variable Rate Wideband Codec(EVRC-WB) and updates the media type registrations for EVRC-B codec.Several media type registrations are included for EVRC-WB RTP payload formats. In addition, a file format is specified for transport ofEVRC-WB speech data in storage mode applications such as email. |
|
| |
| RFC 5189 | Middlebox Communication (MIDCOM) Protocol Semantics |
| |
| Authors: | M. Stiemerling, J. Quittek, T. Taylor. |
| Date: | March 2008 |
| Formats: | txt html json |
| Obsoletes: | RFC 3989 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5189 |
|
This document specifies semantics for a Middlebox Communication(MIDCOM) protocol to be used by MIDCOM agents for interacting with middleboxes such as firewalls and Network Address Translators (NATs).The semantics discussion does not include any specification of a concrete syntax or a transport protocol. However, a concrete protocol is expected to implement the specified semantics or, more likely, a superset of it. The MIDCOM protocol semantics is derived from the MIDCOM requirements, from the MIDCOM framework, and from working group decisions. This document obsoletes RFC 3989. |
|
| |
| RFC 5190 | Definitions of Managed Objects for Middlebox Communication |
| |
| Authors: | J. Quittek, M. Stiemerling, P. Srisuresh. |
| Date: | March 2008 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5190 |
|
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 configuring middleboxes, such as firewalls and network address translators, in order to enable communication across these devices.The definitions of managed objects in this documents follow closely the MIDCOM semantics defined in RFC 5189. |
|
| |
| RFC 5191 | Protocol for Carrying Authentication for Network Access (PANA) |
| |
| Authors: | D. Forsberg, Y. Ohba, Ed., B. Patil, H. Tschofenig, A. Yegin. |
| Date: | May 2008 |
| Formats: | txt html json |
| Updated by: | RFC 5872 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5191 |
|
This document defines the Protocol for Carrying Authentication forNetwork Access (PANA), a network-layer transport for ExtensibleAuthentication Protocol (EAP) to enable network access authentication between clients and access networks. In EAP terms, PANA is aUDP-based EAP lower layer that runs between the EAP peer and the EAP authenticator. |
|
| |
| RFC 5192 | DHCP Options for Protocol for Carrying Authentication for Network Access (PANA) Authentication Agents |
| |
| Authors: | L. Morand, A. Yegin, S. Kumar, S. Madanapalli. |
| Date: | May 2008 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5192 |
|
This document defines new DHCPv4 and DHCPv6 options that contain a list of IP addresses to locate one or more PANA (Protocol for carrying Authentication for Network Access) Authentication Agents(PAAs). This is one of the methods that a PANA Client (PaC) can use to locate PAAs. |
|
| |
| RFC 5195 | BGP-Based Auto-Discovery for Layer-1 VPNs |
| |
| Authors: | H. Ould-Brahim, D. Fedyk, Y. Rekhter. |
| Date: | June 2008 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5195 |
|
The purpose of this document is to define a BGP-based auto-discovery mechanism for Layer-1 VPNs (L1VPNs). The auto-discovery mechanism for L1VPNs allows the provider network devices to dynamically discover the set of Provider Edges (PEs) having ports attached toCustomer Edge (CE) members of the same VPN. That information is necessary for completing the signaling phase of L1VPN connections.One main objective of a L1VPN auto-discovery mechanism is to support the "single-end provisioning" model, where addition of a new port to a given L1VPN would involve configuration changes only on the PE that has this port and on the CE that is connected to the PE via this port. |
|
| |
| RFC 5196 | Session Initiation Protocol (SIP) User Agent Capability Extension to Presence Information Data Format (PIDF) |
| |
| Authors: | M. Lonnfors, K. Kiss. |
| Date: | September 2008 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5196 |
|
Presence Information Data Format (PIDF) defines a common presence data format for Common Profile for Presence (CPP) compliant presence protocols. This memo defines a PIDF extension to represent SIP UserAgent capabilities. |
|
| |
| RFC 5198 | Unicode Format for Network Interchange |
| |
|
|
The Internet today is in need of a standardized form for the transmission of internationalized "text" information, paralleling the specifications for the use of ASCII that date from the early days of the ARPANET. This document specifies that format, using UTF-8 with normalization and specific line-ending sequences. |
|
| |
| RFC 5213 | Proxy Mobile IPv6 |
| |
| Authors: | S. Gundavelli, Ed., K. Leung, V. Devarapalli, K. Chowdhury, B. Patil. |
| Date: | August 2008 |
| Formats: | txt json html |
| Updated by: | RFC 6543, RFC 7864 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5213 |
|
Network-based mobility management enables IP mobility for a host without requiring its participation in any mobility-related signaling. The network is responsible for managing IP mobility on behalf of the host. The mobility entities in the network are responsible for tracking the movements of the host and initiating the required mobility signaling on its behalf. This specification describes a network-based mobility management protocol and is referred to as Proxy Mobile IPv6. |
|
| |
| RFC 5215 | RTP Payload Format for Vorbis Encoded Audio |
| |
| Authors: | L. Barbato. |
| Date: | August 2008 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5215 |
|
This document describes an RTP payload format for transporting Vorbis encoded audio. It details the RTP encapsulation mechanism for rawVorbis data and the delivery mechanisms for the decoder probability model (referred to as a codebook), as well as other setup information.
Also included within this memo are media type registrations and the details necessary for the use of Vorbis with the Session DescriptionProtocol (SDP). |
|
| |
| RFC 5216 | The EAP-TLS Authentication Protocol |
| |
|
|
The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides support for multiple authentication methods. TransportLayer Security (TLS) provides for mutual authentication, integrity- protected ciphersuite negotiation, and key exchange between two endpoints. This document defines EAP-TLS, which includes support for certificate-based mutual authentication and key derivation.
This document obsoletes RFC 2716. A summary of the changes between this document and RFC 2716 is available in Appendix A. |
|
| |
| RFC 5219 | A More Loss-Tolerant RTP Payload Format for MP3 Audio |
| |
|
|
This document describes an RTP (Real-Time Protocol) payload format for transporting MPEG (Moving Picture Experts Group) 1 or 2, layerIII audio (commonly known as "MP3"). This format is an alternative to that described in RFC 2250, and performs better if there is packet loss. This document obsoletes RFC 3119, correcting typographical errors in the "SDP usage" section and pseudo-code appendices. |
|
| |
| RFC 5222 | LoST: A Location-to-Service Translation Protocol |
| |
|
|
This document describes an XML-based protocol for mapping service identifiers and geodetic or civic location information to service contact URIs. In particular, it can be used to determine the location-appropriate Public Safety Answering Point (PSAP) for emergency services. |
|
| |
| RFC 5223 | Discovering Location-to-Service Translation (LoST) Servers Using the Dynamic Host Configuration Protocol (DHCP) |
| |
| Authors: | H. Schulzrinne, J. Polk, H. Tschofenig. |
| Date: | August 2008 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5223 |
|
The Location-to-Service Translation (LoST) Protocol describes an XML- based protocol for mapping service identifiers and geospatial or civic location information to service contact Uniform ResourceLocators (URLs). LoST servers can be located anywhere, but a placement closer to the end host, e.g., in the access network, is desirable. In disaster situations with intermittent network connectivity, such a LoST server placement provides benefits regarding the resiliency of emergency service communication.
This document describes how a LoST client can discover a LoST server using the Dynamic Host Configuration Protocol (DHCP). |
|
| |
| RFC 5225 | RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and UDP-Lite |
| |
| Authors: | G. Pelletier, K. Sandlund. |
| Date: | April 2008 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5225 |
|
This document specifies ROHC (Robust Header Compression) profiles that efficiently compress RTP/UDP/IP (Real-Time Transport Protocol,User Datagram Protocol, Internet Protocol), RTP/UDP-Lite/IP (UserDatagram Protocol Lite), UDP/IP, UDP-Lite/IP, IP and ESP/IP(Encapsulating Security Payload) headers.
This specification defines a second version of the profiles found inRFC 3095, RFC 3843 and RFC 4019; it supersedes their definition, but does not obsolete them.
The ROHCv2 profiles introduce a number of simplifications to the rules and algorithms that govern the behavior of the compression endpoints. It also defines robustness mechanisms that may be used by a compressor implementation to increase the probability of decompression success when packets can be lost and/or reordered on the ROHC channel. Finally, the ROHCv2 profiles define their own specific set of header formats, using the ROHC formal notation. |
|
| |
| RFC 5227 | IPv4 Address Conflict Detection |
| |
|
|
When two hosts on the same link attempt to use the same IPv4 address at the same time (except in rare special cases where this has been arranged by prior coordination), problems ensue for one or both hosts. This document describes (i) a simple precaution that a host can take in advance to help prevent this misconfiguration from happening, and (ii) if this misconfiguration does occur, a simple mechanism by which a host can passively detect, after the fact, that it has happened, so that the host or administrator may respond to rectify the problem. |
|
| |
| RFC 5228 | Sieve: An Email Filtering Language |
| |
|
|
This document describes a language for filtering email 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 the base language has no variables, loops, or ability to shell out to external programs. |
|
| |
| RFC 5229 | Sieve Email Filtering: Variables Extension |
| |
|
|
In advanced mail filtering rule sets, it is useful to keep state or configuration details across rules. This document updates the Sieve filtering language (RFC 5228) with an extension to support variables.The extension changes the interpretation of strings, adds an action to store data in variables, and supplies a new test so that the value of a string can be examined. |
|
| |
| RFC 5230 | Sieve Email Filtering: Vacation Extension |
| |
| Authors: | T. Showalter, N. Freed, Ed.. |
| Date: | January 2008 |
| Formats: | txt html json |
| Updated by: | RFC 8580 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5230 |
|
This document describes an extension to the Sieve email filtering language for an autoresponder similar to that of the Unix "vacation" command for replying to messages. Various safety features are included to prevent problems such as message loops. |
|
| |
| RFC 5231 | Sieve Email Filtering: Relational Extension |
| |
| Authors: | W. Segmuller, B. Leiba. |
| Date: | January 2008 |
| Formats: | txt html json |
| Obsoletes: | RFC 3431 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5231 |
|
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.
This document obsoletes RFC 3431. |
|
| |
| RFC 5232 | Sieve Email Filtering: Imap4flags Extension |
| |
| Authors: | A. Melnikov. |
| Date: | January 2008 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5232 |
|
Recent discussions have shown that it is desirable to set differentIMAP (RFC 3501) flags on message delivery. This can be done, for example, by a Sieve interpreter that works as a part of a MailDelivery Agent.
This document describes an extension to the Sieve mail filtering language for setting IMAP flags. The extension allows setting of both IMAP system flags and IMAP keywords. |
|
| |
| RFC 5233 | Sieve Email Filtering: Subaddress Extension |
| |
|
|
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 Email FilteringLanguage that allows users to compare against the user and detail sub-parts of an address. |
|
| |
| RFC 5235 | Sieve Email Filtering: Spamtest and Virustest Extensions |
| |
|
|
The Sieve email filtering language "spamtest", "spamtestplus", 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 proper input to the tests. |
|
| |
| RFC 5238 | Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP) |
| |
|
|
This document specifies the use of Datagram Transport Layer Security(DTLS) over the Datagram Congestion Control Protocol (DCCP). DTLS provides communications privacy for applications that use datagram transport protocols and allows client/server applications to communicate in a way that is designed to prevent eavesdropping and detect tampering or message forgery. DCCP is a transport protocol that provides a congestion-controlled unreliable datagram service. |
|
| |
| RFC 5239 | A Framework for Centralized Conferencing |
| |
| Authors: | M. Barnes, C. Boulton, O. Levin. |
| Date: | June 2008 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5239 |
|
This document defines the framework for Centralized Conferencing.The framework allows participants using various call signaling protocols, such as SIP, H.323, Jabber, Q.931 or ISDN User Part(ISUP), to exchange media in a centralized unicast conference. TheCentralized Conferencing Framework defines logical entities and naming conventions. The framework also outlines a set of conferencing protocols, which are complementary to the call signaling protocols, for building advanced conferencing applications. The framework binds all the defined components together for the benefit of builders of conferencing systems. |
|
| |
| RFC 5240 | Protocol Independent Multicast (PIM) Bootstrap Router MIB |
| |
| Authors: | B. Joshi, R. Bijlani. |
| Date: | June 2008 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5240 |
|
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 used for managing the Bootstrap Router (BSR) mechanism for PIM (ProtocolIndependent Multicast). |
|
| |
| RFC 5244 | Definition of Events for Channel-Oriented Telephony Signalling |
| |
| Authors: | H. Schulzrinne, T. Taylor. |
| Date: | June 2008 |
| Formats: | txt json html |
| Updates: | RFC 4733 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5244 |
|
This memo updates RFC 4733 to add event codes for telephony signals used for channel-associated signalling when carried in the telephony event RTP payload. It supersedes and adds to the original assignment of event codes for this purpose in Section 3.14 of RFC 2833. As documented in Appendix A of RFC 4733, some of the RFC 2833 events have been deprecated because their specification was ambiguous, erroneous, or redundant. In fact, the degree of change from Section3.14 of RFC 2833 is such that implementations of the present document will be fully backward compatible with RFC 2833 implementations only in the case of full ABCD-bit signalling. This document expands and improves the coverage of signalling systems compared to RFC 2833. |
|
| |
| RFC 5245 | Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols |
| |
|
|
This document describes a protocol for Network Address Translator(NAT) traversal for UDP-based multimedia sessions established with the offer/answer model. This protocol is called InteractiveConnectivity Establishment (ICE). ICE makes use of the SessionTraversal Utilities for NAT (STUN) protocol and its extension,Traversal Using Relay NAT (TURN). ICE can be used by any protocol utilizing the offer/answer model, such as the Session InitiationProtocol (SIP). |
|
| |
| RFC 5246 | The Transport Layer Security (TLS) Protocol Version 1.2 |
| |
| Authors: | T. Dierks, E. Rescorla. |
| Date: | August 2008 |
| Formats: | txt html json |
| Obsoletes: | RFC 3268, RFC 4346, RFC 4366 |
| Obsoleted by: | RFC 8446 |
| Updates: | RFC 4492 |
| Updated by: | RFC 5746, RFC 5878, RFC 6176, RFC 7465, RFC 7507, RFC 7568, RFC 7627, RFC 7685, RFC 7905, RFC 7919, RFC 8447, RFC 9155 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5246 |
|
This document specifies Version 1.2 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 5247 | Extensible Authentication Protocol (EAP) Key Management Framework |
| |
|
|
The Extensible Authentication Protocol (EAP), defined in RFC 3748, enables extensible network access authentication. This document specifies the EAP key hierarchy and provides a framework for the transport and usage of keying material and parameters generated byEAP authentication algorithms, known as "methods". It also provides a detailed system-level security analysis, describing the conditions under which the key management guidelines described in RFC 4962 can be satisfied. |
|
| |
| RFC 5250 | The OSPF Opaque LSA Option |
| |
| Authors: | L. Berger, I. Bryskin, A. Zinin, R. Coltun. |
| Date: | July 2008 |
| Formats: | txt json html |
| Obsoletes: | RFC 2370 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5250 |
|
This document defines enhancements to the OSPF protocol to support a new class of link state advertisements (LSAs) called Opaque LSAs.Opaque LSAs provide a generalized mechanism to allow for the future extensibility of OSPF. Opaque LSAs consist of a standard LSA header followed by application-specific information. The information field may be used directly by OSPF or by other applications. Standard OSPF link-state database flooding mechanisms are used to distribute OpaqueLSAs to all or some limited portion of the OSPF topology.
This document replaces RFC 2370 and adds to it a mechanism to enable an OSPF router to validate Autonomous System (AS)-scope Opaque LSAs originated outside of the router's OSPF area. |
|
| |
| RFC 5251 | Layer 1 VPN Basic Mode |
| |
| Authors: | D. Fedyk, Ed., Y. Rekhter, Ed., D. Papadimitriou, R. Rabbat, L. Berger. |
| Date: | July 2008 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5251 |
|
This document describes the Basic Mode of Layer 1 VPNs (L1VPNs).L1VPN Basic Mode (L1VPN BM) is a port-based VPN. In L1VPN BasicMode, the basic unit of service is a Label Switched Path (LSP) between a pair of customer ports within a given VPN port topology.This document defines the operational model using either provisioning or a VPN auto-discovery mechanism, and the signaling extensions for the L1VPN BM. |
|
| |
| RFC 5252 | OSPF-Based Layer 1 VPN Auto-Discovery |
| |
| Authors: | I. Bryskin, L. Berger. |
| Date: | July 2008 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5252 |
|
This document defines an Open Shortest Path First (OSPF) based Layer1 Virtual Private Network (L1VPN) auto-discovery mechanism. This mechanism enables provider edge (PE) devices using OSPF to dynamically learn about the existence of each other, and attributes of configured customer edge (CE) links and their associations withL1VPNs. This document builds on the L1VPN framework and requirements and provides a L1VPN basic mode auto-discovery mechanism. |
|
| |
| RFC 5255 | Internet Message Access Protocol Internationalization |
| |
| Authors: | C. Newman, A. Gulbrandsen, A. Melnikov. |
| Date: | June 2008 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5255 |
|
Internet Message Access Protocol (IMAP) version 4rev1 has basic support for non-ASCII characters in mailbox names and search substrings. It also supports non-ASCII message headers and content encoded as specified by Multipurpose Internet Mail Extensions (MIME).This specification defines a collection of IMAP extensions that improve international support including language negotiation for international error text, translations for namespace prefixes, and comparator negotiation for search, sort, and thread. |
|
| |
| RFC 5256 | Internet Message Access Protocol - SORT and THREAD Extensions |
| |
| Authors: | M. Crispin, K. Murchison. |
| Date: | June 2008 |
| Formats: | txt html json |
| Updated by: | RFC 5957 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5256 |
|
This document describes the base-level server-based sorting and threading extensions to the IMAP protocol. These extensions provide substantial performance improvements for IMAP clients that offer sorted and threaded views. |
|
| |
| RFC 5258 | Internet Message Access Protocol version 4 - LIST Command Extensions |
| |
| Authors: | B. Leiba, A. Melnikov. |
| Date: | June 2008 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5258 |
|
IMAP4 has two commands for listing mailboxes: LIST and LSUB. As we have added extensions, such as Mailbox Referrals, that have required specialized lists we have had to expand the number of list commands, since each extension must add its function to both LIST and LSUB, and these commands are not, as they are defined, extensible. If we've needed the extensions to work together, we've had to add a set of commands to mix the different options, the set increasing in size with each new extension. This document describes an extension to the base LIST command that will allow these additions to be done with mutually compatible options to the LIST command, avoiding the exponential increase in specialized list commands. |
|
| |
| RFC 5259 | Internet Message Access Protocol - CONVERT Extension |
| |
| Authors: | A. Melnikov, Ed., P. Coates, Ed.. |
| Date: | July 2008 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5259 |
|
CONVERT defines extensions to IMAP allowing clients to request adaptation and/or transcoding of attachments. Clients can specify the conversion details or allow servers to decide based on knowledge of client capabilities, on user or administrator preferences, or on server settings. |
|
| |
| RFC 5260 | Sieve Email Filtering: Date and Index Extensions |
| |
| Authors: | N. Freed. |
| Date: | July 2008 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5260 |
|
This document describes the "date" and "index" extensions to theSieve email filtering language. The "date" extension gives Sieve the ability to test date and time values in various ways. The "index" extension provides a means to limit header and address tests to specific instances of header fields when header fields are repeated. |
|
| |
| RFC 5261 | An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors |
| |
| Authors: | J. Urpalainen. |
| Date: | September 2008 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5261 |
|
Extensible Markup Language (XML) documents are widely used as containers for the exchange and storage of arbitrary data in today's systems. In order to send changes to an XML document, an entire copy of the new version must be sent, unless there is a means of indicating only the portions that have changed. This document describes an XML patch framework utilizing XML Path language (XPath) selectors. These selector values and updated new data content constitute the basis of patch operations described in this document.In addition to them, with basic <add&rt;, <replace&rt;, and <remove&rt; directives a set of patches can then be applied to update an existingXML document. |
|
| |
| RFC 5262 | Presence Information Data Format (PIDF) Extension for Partial Presence |
| |
| Authors: | M. Lonnfors, E. Leppanen, H. Khartabil, J. Urpalainen. |
| Date: | September 2008 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5262 |
|
The Presence Information Document Format (PIDF) specifies the baseline XML-based format for describing presence information. One of the characteristics of the PIDF is that the document always needs to carry all presence information available for the presentity. In some environments where low bandwidth and high latency links can exist, it is often beneficial to limit the amount of transported information over the network. This document introduces a new MIME type that enables transporting of either only the changed parts or the full PIDF-based presence information. |
|
| |
| RFC 5263 | Session Initiation Protocol (SIP) Extension for Partial Notification of Presence Information |
| |
| Authors: | M. Lonnfors, J. Costa-Requena, E. Leppanen, H. Khartabil. |
| Date: | September 2008 |
| Formats: | txt html json |
| Updated by: | RFC 8996 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5263 |
|
By default, presence delivered using the presence event package for the Session Initiation Protocol (SIP) is represented in the PresenceInformation Data Format (PIDF). A PIDF document contains a set of elements, each representing a different aspect of the presence being reported. When any subset of the elements change, even just a single element, a new document containing the full set of elements is delivered. This memo defines an extension allowing delivery of only the presence data that has actually changed. |
|
| |
| RFC 5264 | Publication of Partial Presence Information |
| |
| Authors: | A. Niemi, M. Lonnfors, E. Leppanen. |
| Date: | September 2008 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5264 |
|
The Session Initiation Protocol (SIP) Extension for Event StatePublication describes a mechanism with which a presence user agent is able to publish presence information to a presence agent. Using thePresence Information Data Format (PIDF), each presence publication contains full state, regardless of how much of that information has actually changed since the previous update. As a consequence, updating a sizeable presence document with small changes bears a considerable overhead and is therefore inefficient. Especially with low bandwidth and high latency links, this can constitute a considerable burden to the system. This memo defines a solution that aids in reducing the impact of those constraints and increases transport efficiency by introducing a mechanism that allows for publication of partial presence information. |
|
| |
| RFC 5265 | Mobile IPv4 Traversal across IPsec-Based VPN Gateways |
| |
| Authors: | S. Vaarala, E. Klovning. |
| Date: | June 2008 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5265 |
|
This document outlines a solution for the Mobile IPv4 (MIPv4) andIPsec coexistence problem for enterprise users. The solution consists of an applicability statement for using Mobile IPv4 andIPsec for session mobility in corporate remote access scenarios, and a required mechanism for detecting the trusted internal network securely. |
|
| |
| RFC 5267 | Contexts for IMAP4 |
| |
|
|
The IMAP4rev1 protocol has powerful search facilities as part of the core protocol, but lacks the ability to create live, updated results that can be easily handled. This memo provides such an extension, and shows how it can be used to provide a facility similar to virtual mailboxes. |
|
| |
| RFC 5268 | Mobile IPv6 Fast Handovers |
| |
|
|
Mobile IPv6 enables a Mobile Node (MN) to maintain its connectivity to the Internet when moving from one Access Router to another, a process referred to as handover. During handover, there is a period during which the Mobile Node is unable to send or receive packets because of link switching delay and IP protocol operations. This"handover latency" resulting from standard Mobile IPv6 procedures, namely movement detection, new Care-of Address configuration, andBinding Update, is often unacceptable to real-time traffic such asVoice over IP (VoIP). Reducing the handover latency could be beneficial to non-real-time, throughput-sensitive applications as well. This document specifies a protocol to improve handover latency due to Mobile IPv6 procedures. This document does not address improving the link switching latency. |
|
| |
| RFC 5269 | Distributing a Symmetric Fast Mobile IPv6 (FMIPv6) Handover Key Using SEcure Neighbor Discovery (SEND) |
| |
| Authors: | J. Kempf, R. Koodli. |
| Date: | June 2008 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5269 |
|
Fast Mobile IPv6 requires that a Fast Binding Update is secured using a security association shared between an Access Router and a MobileNode in order to avoid certain attacks. In this document, a method for provisioning a shared key from the Access Router to the MobileNode is defined to protect this signaling. The Mobile Node generates a public/private key pair using the same public key algorithm as forSEND (RFC 3971). The Mobile Node sends the public key to the AccessRouter. The Access Router encrypts a shared handover key using the public key and sends it back to the Mobile Node. The Mobile Node decrypts the shared handover key using the matching private key, and the handover key is then available for generating an authenticator on a Fast Binding Update. The Mobile Node and Access Router use theRouter Solicitation for Proxy Advertisement and Proxy RouterAdvertisement from Fast Mobile IPv6 for the key exchange. The key exchange messages are required to have SEND security; that is, the source address is a Cryptographically Generated Address (CGA) and the messages are signed using the CGA private key of the sending node.This allows the Access Router, prior to providing the shared handover key, to verify the authorization of the Mobile Node to claim the address so that the previous care-of CGA in the Fast Binding Update can act as the name of the key. |
|
| |
| RFC 5272 | Certificate Management over CMS (CMC) |
| |
|
|
This document defines the base syntax for CMC, a CertificateManagement protocol using the Cryptographic Message Syntax (CMS).This protocol addresses two immediate needs within the InternetPublic Key Infrastructure (PKI) community:
1. The need for an interface to public key certification products and services based on CMS and PKCS #10 (Public Key CryptographyStandard), and
2. The need for a PKI enrollment protocol for encryption only keys due to algorithm or hardware design.
CMC also requires the use of the transport document and the requirements usage document along with this document for a full definition. |
|
| |
| RFC 5273 | Certificate Management over CMS (CMC): Transport Protocols |
| |
|
|
This document defines a number of transport mechanisms that are used to move CMC (Certificate Management over CMS (Cryptographic MessageSyntax)) messages. The transport mechanisms described in this document are HTTP, file, mail, and TCP. |
|
| |
| RFC 5274 | Certificate Management Messages over CMS (CMC): Compliance Requirements |
| |
|
|
This document provides a set of compliance statements about the CMC(Certificate Management over CMS) enrollment protocol. The ASN.1 structures and the transport mechanisms for the CMC enrollment protocol are covered in other documents. This document provides the information needed to make a compliant version of CMC. |
|
| |
| RFC 5275 | CMS Symmetric Key Management and Distribution |
| |
| Authors: | S. Turner. |
| Date: | June 2008 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5275 |
|
This document describes a mechanism to manage (i.e., set up, distribute, and rekey) keys used with symmetric cryptographic algorithms. Also defined herein is a mechanism to organize users into groups to support distribution of encrypted content using symmetric cryptographic algorithms. The mechanism uses theCryptographic Message Syntax (CMS) protocol and CertificateManagement over CMS (CMC) protocol to manage the symmetric keys. Any member of the group can then later use this distributed shared key to decrypt other CMS encrypted objects with the symmetric key. This mechanism has been developed to support Secure/Multipurpose InternetMail Extensions (S/MIME) Mail List Agents (MLAs). |
|
| |
| RFC 5276 | Using the Server-Based Certificate Validation Protocol (SCVP) to Convey Long-Term Evidence Records |
| |
| Authors: | C. Wallace. |
| Date: | August 2008 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5276 |
|
The Server-based Certificate Validation Protocol (SCVP) defines an extensible means of delegating the development and validation of certification paths to a server. It can be used to support the development and validation of certification paths well after the expiration of the certificates in the path by specifying a time of interest in the past. The Evidence Record Syntax (ERS) defines structures, called evidence records, to support the non-repudiation of the existence of data. Evidence records can be used to preserve materials that comprise a certification path such that trust in the certificates can be established after the expiration of the certificates in the path and after the cryptographic algorithms used to sign the certificates in the path are no longer secure. This document describes usage of the SCVP WantBack feature to convey evidence records, enabling SCVP responders to provide preservation evidence for certificates and certificate revocation lists (CRLs). |
|
| |
| RFC 5277 | NETCONF Event Notifications |
| |
| Authors: | S. Chisholm, H. Trevino. |
| Date: | July 2008 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5277 |
|
This document defines mechanisms that provide an asynchronous message notification delivery service for the Network Configuration protocol(NETCONF). This is an optional capability built on top of the baseNETCONF definition. This document defines the capabilities and operations necessary to support this service. |
|
| |
| RFC 5278 | IANA Registration of Enumservices for Voice and Video Messaging |
| |
| Authors: | J. Livingood, D. Troshynski. |
| Date: | July 2008 |
| Formats: | txt json html |
| Updated by: | RFC 6118 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5278 |
|
This document registers the Enumservice named "vmsg", which is used to facilitate the real-time routing of voice, video, and unified communications to a messaging system. This vmsg Enumservice registers three Enumservice types: "voicemsg", "videomsg", and"unifmsg". Each type also registers the subtypes "sip", "sips","http", and "https", as well as the subtype "tel" for the "voicemsg" type. |
|
| |
| RFC 5280 | Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile |
| |
| Authors: | D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, W. Polk. |
| Date: | May 2008 |
| Formats: | txt json html |
| Obsoletes: | RFC 3280, RFC 4325, RFC 4630 |
| Updated by: | RFC 6818, RFC 8398, RFC 8399, RFC 9549 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5280 |
|
This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is 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 along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. |
|
| |
| RFC 5282 | Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol |
| |
|
|
An authenticated encryption algorithm combines encryption and integrity into a single operation; such algorithms may also be referred to as combined modes of an encryption cipher or as combined mode algorithms. This document describes the use of authenticated encryption algorithms with the Encrypted Payload of the Internet KeyExchange version 2 (IKEv2) protocol.
The use of two specific authenticated encryption algorithms with theIKEv2 Encrypted Payload is also described; these two algorithms are the Advanced Encryption Standard (AES) in Galois/Counter Mode (AESGCM) and AES in Counter with CBC-MAC Mode (AES CCM). Additional documents may describe the use of other authenticated encryption algorithms with the IKEv2 Encrypted Payload. |
|
| |
| RFC 5283 | LDP Extension for Inter-Area Label Switched Paths (LSPs) |
| |
| Authors: | B. Decraene, JL. Le Roux, I. Minei. |
| Date: | July 2008 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5283 |
|
To facilitate the establishment of Label Switched Paths (LSPs) that would span multiple IGP areas in a given Autonomous System (AS), this document describes a new optional Longest-Match Label MappingProcedure for the Label Distribution Protocol (LDP).
This procedure allows the use of a label if the ForwardingEquivalence Class (FEC) Element matches an entry in the RoutingInformation Base (RIB). Matching is defined by an IP longest-match search and does not mandate an exact match. |
|
| |
| RFC 5284 | User-Defined Errors for RSVP |
| |
| Authors: | G. Swallow, A. Farrel. |
| Date: | August 2008 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5284 |
|
The Resource ReserVation Protocol (RSVP) defines an ERROR_SPEC object for communicating errors. That object has a defined format that permits the definition of 256 error codes. As RSVP has been developed and extended, the convention has been to be conservative in defining new error codes. Further, no provision for user-defined errors exists in RSVP.
This document defines a USER_ERROR_SPEC to be used in addition to theERROR_SPEC to carry additional user information related to errors. |
|
| |
| RFC 5285 | A General Mechanism for RTP Header Extensions |
| |
| Authors: | D. Singer, H. Desineni. |
| Date: | July 2008 |
| Formats: | txt json html |
| Obsoleted by: | RFC 8285 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5285 |
|
This document provides a general mechanism to use the header extension feature of RTP (the Real-Time Transport Protocol). It provides the option to use a small number of small extensions in eachRTP packet, where the universe of possible extensions is large and registration is de-centralized. The actual extensions in use in a session are signaled in the setup information for that session. |
|
| |
| RFC 5286 | Basic Specification for IP Fast Reroute: Loop-Free Alternates |
| |
| Authors: | A. Atlas, Ed., A. Zinin, Ed.. |
| Date: | September 2008 |
| Formats: | txt html json |
| Updated by: | RFC 8518 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5286 |
|
This document describes the use of loop-free alternates to provide local protection for unicast traffic in pure IP and MPLS/LDP networks in the event of a single failure, whether link, node, or shared risk link group (SRLG). The goal of this technology is to reduce the packet loss that happens while routers converge after a topology change due to a failure. Rapid failure repair is achieved through use of precalculated backup next-hops that are loop-free and safe to use until the distributed network convergence process completes.This simple approach does not require any support from other routers.The extent to which this goal can be met by this specification is dependent on the topology of the network. |
|
| |
| RFC 5287 | Control Protocol Extensions for the Setup of Time-Division Multiplexing (TDM) Pseudowires in MPLS Networks |
| |
| Authors: | A. Vainshtein, Y(J). Stein. |
| Date: | August 2008 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5287 |
|
This document defines extension to the Pseudowire Emulation Edge-to-Edge (PWE3) control protocol RFC 4447 and PWE3 IANA allocations RFC4446 required for the setup of Time-Division Multiplexing (TDM) pseudowires in MPLS networks. |
|
| |
| RFC 5288 | AES Galois Counter Mode (GCM) Cipher Suites for TLS |
| |
| Authors: | J. Salowey, A. Choudhury, D. McGrew. |
| Date: | August 2008 |
| Formats: | txt json html |
| Updated by: | RFC 9325 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5288 |
|
This memo describes the use of the Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) as a Transport Layer Security (TLS) authenticated encryption operation. GCM provides both confidentiality and data origin authentication, can be efficiently implemented in hardware for speeds of 10 gigabits per second and above, and is also well-suited to software implementations. This memo defines TLS cipher suites that use AES-GCM with RSA, DSA, andDiffie-Hellman-based key exchange mechanisms. |
|
| |
| RFC 5289 | TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM) |
| |
| Authors: | E. Rescorla. |
| Date: | August 2008 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5289 |
|
RFC 4492 describes elliptic curve cipher suites for Transport LayerSecurity (TLS). However, all those cipher suites use HMAC-SHA-1 as their Message Authentication Code (MAC) algorithm. This document describes sixteen new cipher suites for TLS that specify stronger MAC algorithms. Eight use Hashed Message Authentication Code (HMAC) withSHA-256 or SHA-384, and eight use AES in Galois Counter Mode (GCM). |
|
| |
| RFC 5291 | Outbound Route Filtering Capability for BGP-4 |
| |
| Authors: | E. Chen, Y. Rekhter. |
| Date: | August 2008 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5291 |
|
This document defines a BGP-based mechanism that allows a BGP speaker to send to its BGP peer a set of Outbound Route Filters (ORFs) that the peer would use to constrain/filter its outbound routing updates to the speaker. |
|
| |
| RFC 5292 | Address-Prefix-Based Outbound Route Filter for BGP-4 |
| |
| Authors: | E. Chen, S. Sangli. |
| Date: | August 2008 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5292 |
|
This document defines a new Outbound Router Filter (ORF) type forBGP, termed "Address Prefix Outbound Route Filter", that can be used to perform address-prefix-based route filtering. This ORF-type supports prefix-length- or range-based matching, wild-card-based address prefix matching, as well as the exact address prefix matching for address families. |
|
| |
| RFC 5293 | Sieve Email Filtering: Editheader Extension |
| |
| Authors: | J. Degener, P. Guenther. |
| Date: | August 2008 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5293 |
|
This document defines two new actions for the "Sieve" email filtering language that add and delete email header fields. |
|
| |
| RFC 5295 | Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK) |
| |
| Authors: | J. Salowey, L. Dondeti, V. Narayanan, M. Nakhjiri. |
| Date: | August 2008 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5295 |
|
The Extensible Authentication Protocol (EAP) defined the ExtendedMaster Session Key (EMSK) generation, but reserved it for unspecified future uses. This memo reserves the EMSK for the sole purpose of deriving root keys. Root keys are master keys that can be used for multiple purposes, identified by usage definitions. This document also specifies a mechanism for avoiding conflicts between root keys by deriving them in a manner that guarantees cryptographic separation. Finally, this document also defines one such root key usage: Domain-Specific Root Keys are root keys made available to and used within specific key management domains. |
|
| |
| RFC 5296 | EAP Extensions for EAP Re-authentication Protocol (ERP) |
| |
| Authors: | V. Narayanan, L. Dondeti. |
| Date: | August 2008 |
| Formats: | txt html json |
| Obsoleted by: | RFC 6696 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5296 |
|
The Extensible Authentication Protocol (EAP) is a generic framework supporting multiple types of authentication methods. In systems where EAP is used for authentication, it is desirable to not repeat the entire EAP exchange with another authenticator. This document specifies extensions to EAP and the EAP keying hierarchy to support an EAP method-independent protocol for efficient re-authentication between the peer and an EAP re-authentication server through any authenticator. The re-authentication server may be in the home network or in the local network to which the peer is connecting. |
|
| |
| RFC 5301 | Dynamic Hostname Exchange Mechanism for IS-IS |
| |
|
|
RFC 2763 defined a simple and dynamic mechanism for routers runningIS-IS to learn about symbolic hostnames. RFC 2763 defined a new TLV that allows the IS-IS routers to flood their name-to-systemID mapping information across the IS-IS network.
This document obsoletes RFC 2763. This document moves the capability provided by RFC 2763 to the Standards Track. |
|
| |
| RFC 5302 | Domain-Wide Prefix Distribution with Two-Level IS-IS |
| |
|
|
This document describes extensions to the Intermediate System toIntermediate System (IS-IS) protocol to support optimal routing within a two-level domain. The IS-IS protocol is specified in ISO10589, with extensions for supporting IPv4 (Internet Protocol) specified in RFC 1195. This document replaces RFC 2966.
This document extends the semantics presented in RFC 1195 so that a routing domain running with both level 1 and level 2 IntermediateSystems (IS) (routers) can distribute IP prefixes between level 1 and level 2, and vice versa. This distribution requires certain restrictions to ensure that persistent forwarding loops do not form.The goal of this domain-wide prefix distribution is to increase the granularity of the routing information within the domain. |
|
| |
| RFC 5303 | Three-Way Handshake for IS-IS Point-to-Point Adjacencies |
| |
| Authors: | D. Katz, R. Saluja, D. Eastlake 3rd. |
| Date: | October 2008 |
| Formats: | txt html json |
| Obsoletes: | RFC 3373 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5303 |
|
The IS-IS routing protocol (Intermediate System to IntermediateSystem, ISO 10589) requires reliable protocols at the link layer for point-to-point links. As a result, it does not use a three-way handshake when establishing adjacencies on point-to-point media.This paper defines a backward-compatible extension to the protocol that provides for a three-way handshake. It is fully interoperable with systems that do not support the extension.
Additionally, the extension allows the robust operation of more than256 point-to-point links on a single router.
This extension has been implemented by multiple router vendors; this paper is provided to the Internet community in order to allow interoperable implementations to be built by other vendors. |
|
| |
| RFC 5304 | IS-IS Cryptographic Authentication |
| |
|
|
This document describes the authentication of Intermediate System toIntermediate System (IS-IS) Protocol Data Units (PDUs) using theHashed Message Authentication Codes - Message Digest 5 (HMAC-MD5) algorithm as found in RFC 2104. IS-IS is specified in InternationalStandards Organization (ISO) 10589, with extensions to supportInternet Protocol version 4 (IPv4) described in RFC 1195. The base specification includes an authentication mechanism that allows for multiple authentication algorithms. The base specification only specifies the algorithm for cleartext passwords. This document replaces RFC 3567.
This document proposes an extension to that specification that allows the use of the HMAC-MD5 authentication algorithm to be used in conjunction with the existing authentication mechanisms. |
|
| |
| RFC 5305 | IS-IS Extensions for Traffic Engineering |
| |
|
|
This document describes extensions to the Intermediate System toIntermediate System (IS-IS) protocol to support Traffic Engineering(TE). This document extends the IS-IS protocol by specifying new information that an Intermediate System (router) can place in LinkState Protocol Data Units (LSP). This information describes additional details regarding the state of the network that are useful for traffic engineering computations. |
|
| |
| RFC 5306 | Restart Signaling for IS-IS |
| |
|
|
This document describes a mechanism for a restarting router to signal to its neighbors that it is restarting, allowing them to reestablish their adjacencies without cycling through the down state, while still correctly initiating database synchronization.
This document additionally describes a mechanism for a restarting router to determine when it has achieved Link State Protocol DataUnit (LSP) database synchronization with its neighbors and a mechanism to optimize LSP database synchronization, while minimizing transient routing disruption when a router starts. This document obsoletes RFC 3847. |
|
| |
| RFC 5307 | IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) |
| |
|
|
This document specifies encoding of extensions to the IS-IS routing protocol in support of Generalized Multi-Protocol Label Switching(GMPLS). |
|
| |
| RFC 5308 | Routing IPv6 with IS-IS |
| |
|
|
This document specifies a method for exchanging IPv6 routing information using the IS-IS routing protocol. The described method utilizes two new TLVs: a reachability TLV and an interface addressTLV to distribute the necessary IPv6 information throughout a routing domain. Using this method, one can route IPv6 along with IPv4 andOSI using a single intra-domain routing protocol. |
|
| |
| RFC 5310 | IS-IS Generic Cryptographic Authentication |
| |
| Authors: | M. Bhatia, V. Manral, T. Li, R. Atkinson, R. White, M. Fanto. |
| Date: | February 2009 |
| Formats: | txt json html |
| Updated by: | RFC 6233, RFC 6232 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5310 |
|
This document proposes an extension to Intermediate System toIntermediate System (IS-IS) to allow the use of any cryptographic authentication algorithm in addition to the already-documented authentication schemes, described in the base specification and RFC5304. IS-IS is specified in International Standards Organization(ISO) 10589, with extensions to support Internet Protocol version 4(IPv4) described in RFC 1195.
Although this document has been written specifically for using theHashed Message Authentication Code (HMAC) construct along with theSecure Hash Algorithm (SHA) family of cryptographic hash functions, the method described in this document is generic and can be used to extend IS-IS to support any cryptographic hash function in the future. |
|
| |
| RFC 5311 | Simplified Extension of Link State PDU (LSP) Space for IS-IS |
| |
| Authors: | D. McPherson, Ed., L. Ginsberg, S. Previdi, M. Shand. |
| Date: | February 2009 |
| Formats: | txt json html |
| Obsoletes: | RFC 3786 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5311 |
|
This document describes a simplified method for extending the LinkState PDU (LSP) space beyond the 256 LSP limit. This method is intended as a preferred replacement for the method defined in RFC3786. |
|
| |
| RFC 5316 | ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering |
| |
| Authors: | M. Chen, R. Zhang, X. Duan. |
| Date: | December 2008 |
| Formats: | txt html json |
| Obsoleted by: | RFC 9346 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5316 |
|
This document describes extensions to the ISIS (ISIS) protocol to support Multiprotocol Label Switching (MPLS) and Generalized MPLS(GMPLS) Traffic Engineering (TE) for multiple Autonomous Systems(ASes). It defines ISIS-TE extensions for the flooding of TE information about inter-AS links, which can be used to perform inter-AS TE path computation.
No support for flooding information from within one AS to another AS is proposed or defined in this document. |
|
| |
| RFC 5323 | Web Distributed Authoring and Versioning (WebDAV) SEARCH |
| |
| Authors: | J. Reschke, Ed., S. Reddy, J. Davis, A. Babich. |
| Date: | November 2008 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5323 |
|
This document specifies a set of methods, headers, and properties composing Web Distributed Authoring and Versioning (WebDAV) SEARCH, an application of the HTTP/1.1 protocol to efficiently search for DAV resources based upon a set of client-supplied criteria. |
|
| |
| RFC 5324 | MIB for Fibre-Channel Security Protocols (FC-SP) |
| |
| Authors: | C. DeSanti, F. Maino, K. McCloghrie. |
| Date: | September 2008 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5324 |
|
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 FC-SP, the Security Protocols defined for Fibre Channel. |
|
| |
| RFC 5329 | Traffic Engineering Extensions to OSPF Version 3 |
| |
| Authors: | K. Ishiguro, V. Manral, A. Davey, A. Lindem, Ed.. |
| Date: | September 2008 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5329 |
|
This document describes extensions to OSPFv3 to support intra-areaTraffic Engineering (TE). This document extends OSPFv2 TE to handleIPv6 networks. A new TLV and several new sub-TLVs are defined to support IPv6 networks. |
|
| |
| RFC 5330 | A Link-Type sub-TLV to Convey the Number of Traffic Engineering Label Switched Paths Signalled with Zero Reserved Bandwidth across a Link |
| |
| Authors: | JP. Vasseur, Ed., M. Meyer, K. Kumaki, A. Bonda. |
| Date: | October 2008 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5330 |
|
Several Link-type sub-Type-Length-Values (sub-TLVs) have been defined for Open Shortest Path First (OSPF) and Intermediate System toIntermediate System (IS-IS) in the context of Multiprotocol LabelSwitching (MPLS) Traffic Engineering (TE), in order to advertise some link characteristics such as the available bandwidth, traffic engineering metric, administrative group, and so on. By making statistical assumptions about the aggregated traffic carried onto a set of TE Label Switched Paths (LSPs) signalled with zero bandwidth(referred to as "unconstrained TE LSP" in this document), algorithms can be designed to load balance (existing or newly configured) unconstrained TE LSP across a set of equal cost paths. This requires knowledge of the number of unconstrained TE LSPs signalled across a link. This document specifies a new Link-type Traffic Engineering sub-TLV used to advertise the number of unconstrained TE LSPs signalled across a link. |
|
| |
| RFC 5331 | MPLS Upstream Label Assignment and Context-Specific Label Space |
| |
| Authors: | R. Aggarwal, Y. Rekhter, E. Rosen. |
| Date: | August 2008 |
| Formats: | txt json html |
| Updated by: | RFC 7274 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5331 |
|
RFC 3031 limits the MPLS architecture to downstream-assigned MPLS labels. This document introduces the notion of upstream-assignedMPLS labels. It describes the procedures for upstream MPLS label assignment and introduces the concept of a "Context-Specific LabelSpace". |
|
| |
| RFC 5332 | MPLS Multicast Encapsulations |
| |
|
|
RFC 3032 established two data link layer codepoints for MPLS, used to distinguish whether the data link layer frame is carrying an MPLS unicast or an MPLS multicast packet. However, this usage was never deployed. This specification updates RFC 3032 by redefining the meaning of these two codepoints. Both codepoints can now be used to carry multicast packets. The second codepoint (formerly the"multicast codepoint") is now to be used only on multiaccess media, and it is to mean "the top label of the following label stack is an upstream-assigned label".
RFC 3032 does not specify the destination address to be placed in the"MAC DA" (Medium Access Layer Destination Address) field of an ethernet frame that carries an MPLS multicast packet. This document provides that specification.
This document updates RFC 3032 and RFC 4023. |
|
| |
| RFC 5333 | IANA Registration of Enumservices for Internet Calendaring |
| |
| Authors: | R. Mahy, B. Hoeneisen. |
| Date: | October 2009 |
| Formats: | txt html json |
| Updated by: | RFC 6118 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5333 |
|
This document registers Enumservices for Internet calendaring.Specifically, this document focuses on Enumservices for scheduling with iMIP (iCalendar Message-Based Interoperability Protocol) and for accessing Internet calendaring information with CalDAV (CalendaringExtensions to WebDAV). |
|
| |
| RFC 5334 | Ogg Media Types |
| |
| Authors: | I. Goncalves, S. Pfeiffer, C. Montgomery. |
| Date: | September 2008 |
| Formats: | txt json html |
| Obsoletes: | RFC 3534 |
| Updated by: | RFC 7845 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5334 |
|
This document describes the registration of media types for the Ogg container format and conformance requirements for implementations of these types. This document obsoletes RFC 3534. |
|
| |
| RFC 5340 | OSPF for IPv6 |
| |
|
|
This document describes the modifications to OSPF to support version6 of the Internet Protocol (IPv6). The fundamental mechanisms ofOSPF (flooding, Designated Router (DR) election, area support, ShortPath First (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. These modifications will necessitate incrementing the protocol version from version 2 to version 3. OSPF for IPv6 is also referred to as OSPF version 3 (OSPFv3).
Changes between OSPF for IPv4, OSPF Version 2, and OSPF for IPv6 as described herein include the following. Addressing semantics have been removed from OSPF packets and the basic Link StateAdvertisements (LSAs). New LSAs have been created to carry IPv6 addresses and prefixes. OSPF now runs on a per-link basis rather than on a per-IP-subnet basis. Flooding scope for LSAs has been generalized. Authentication has been removed from the OSPF protocol and instead relies on IPv6's Authentication Header and EncapsulatingSecurity Payload (ESP).
Even with larger IPv6 addresses, most packets in OSPF for IPv6 are almost as compact as those in OSPF for IPv4. Most fields and 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 demand circuit support and Not-So-Stubby Areas (NSSAs), are also supported in OSPF for IPv6. |
|
| |
| RFC 5341 | The Internet Assigned Number Authority (IANA) tel Uniform Resource Identifier (URI) Parameter Registry |
| |
| Authors: | C. Jennings, V. Gurbani. |
| Date: | September 2008 |
| Formats: | txt html json |
| Updates: | RFC 3966 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5341 |
|
This document creates an Internet Assigned Number Authority (IANA) registry for tel Uniform Resource Identifier (URI) parameters and their values. It populates the registry with the parameters defined in the tel URI specification, along with the parameters in tel URI extensions defined for number portability and trunk groups. |
|
| |
| RFC 5348 | TCP Friendly Rate Control (TFRC): Protocol Specification |
| |
| Authors: | S. Floyd, M. Handley, J. Padhye, J. Widmer. |
| Date: | September 2008 |
| Formats: | txt html json |
| Obsoletes: | RFC 3448 |
| Updates: | RFC 4342 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5348 |
|
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 streaming media where a relatively smooth sending rate is of importance.
This document obsoletes RFC 3448 and updates RFC 4342. |
|
| |
| RFC 5350 | IANA Considerations for the IPv4 and IPv6 Router Alert Options |
| |
|
|
This document updates the IANA allocation rules and registry of IPv4 and IPv6 Router Alert Option Values. |
|
| |
| RFC 5357 | A Two-Way Active Measurement Protocol (TWAMP) |
| |
|
|
The One-way Active Measurement Protocol (OWAMP), specified in RFC4656, provides a common protocol for measuring one-way metrics between network devices. OWAMP can be used bi-directionally to measure one-way metrics in both directions between two network elements. However, it does not accommodate round-trip or two-way measurements. This memo specifies a Two-Way Active MeasurementProtocol (TWAMP), based on the OWAMP, that adds two-way or round-trip measurement capabilities. The TWAMP measurement architecture is usually comprised of two hosts with specific roles, and this allows for some protocol simplifications, making it an attractive alternative in some circumstances. |
|
| |
| RFC 5360 | A Framework for Consent-Based Communications in the Session Initiation Protocol (SIP) |
| |
| Authors: | J. Rosenberg, G. Camarillo, Ed., D. Willis. |
| Date: | October 2008 |
| Formats: | txt html json |
| Updated by: | RFC 8217 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5360 |
|
SIP supports communications for several services, including real-time audio, video, text, instant messaging, and presence. In its current form, it allows session invitations, instant messages, and other requests to be delivered from one party to another without requiring explicit consent of the recipient. Without such consent, it is possible for SIP to be used for malicious purposes, including amplification and DoS (Denial of Service) attacks. This document identifies a framework for consent-based communications in SIP. |
|
| |
| RFC 5361 | A Document Format for Requesting Consent |
| |
| Authors: | G. Camarillo. |
| Date: | October 2008 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5361 |
|
This document defines an Extensible Markup Language (XML) format for a permission document used to request consent. A permission document written in this format is used by a relay to request a specific recipient permission to perform a particular routing translation. |
|
| |
| RFC 5362 | The Session Initiation Protocol (SIP) Pending Additions Event Package |
| |
| Authors: | G. Camarillo. |
| Date: | October 2008 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5362 |
|
This document defines the SIP Pending Additions event package. This event package is used by SIP relays to inform user agents about the consent-related status of the entries to be added to a resource list. |
|
| |
| RFC 5363 | Framework and Security Considerations for Session Initiation Protocol (SIP) URI-List Services |
| |
| Authors: | G. Camarillo, A.B. Roach. |
| Date: | October 2008 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5363 |
|
This document describes the need for SIP URI-list services and provides requirements for their invocation. Additionally, it defines a framework for SIP URI-list services, which includes security considerations applicable to these services. |
|
| |
| RFC 5364 | Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists |
| |
| Authors: | M. Garcia-Martin, G. Camarillo. |
| Date: | October 2008 |
| Formats: | txt html json |
| Updated by: | RFC 8996 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5364 |
|
In certain types of multimedia communications, a Session InitiationProtocol (SIP) request is distributed to a group of SIP User Agents(UAs). The sender sends a single SIP request to a server which further distributes the request to the group. This SIP request contains a list of Uniform Resource Identifiers (URIs), which identify the recipients of the SIP request. This URI list is expressed as a resource list XML document. This specification defines an XML extension to the XML resource list format that allows the sender of the request to qualify a recipient with a copy control level similar to the copy control level of existing email systems. |
|
| |
| RFC 5365 | Multiple-Recipient MESSAGE Requests in the Session Initiation Protocol (SIP) |
| |
| Authors: | M. Garcia-Martin, G. Camarillo. |
| Date: | October 2008 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5365 |
|
This document specifies a mechanism that allows a SIP User AgentClient (UAC) to send a SIP MESSAGE request to a set of destinations, by using a SIP URI-list (Uniform Resource Identifier list) service.The UAC sends a SIP MESSAGE request that includes the payload along with the URI list to the MESSAGE URI-list service, which sends aMESSAGE request including the payload to each of the URIs included in the list. |
|
| |
| RFC 5366 | Conference Establishment Using Request-Contained Lists in the Session Initiation Protocol (SIP) |
| |
| Authors: | G. Camarillo, A. Johnston. |
| Date: | October 2008 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5366 |
|
This document describes how to create a conference using SIP URI-list services. In particular, it describes a mechanism that allows a UserAgent Client to provide a conference server with the initial list of participants using an INVITE-contained URI list. |
|
| |
| RFC 5367 | Subscriptions to Request-Contained Resource Lists in the Session Initiation Protocol (SIP) |
| |
| Authors: | G. Camarillo, A.B. Roach, O. Levin. |
| Date: | October 2008 |
| Formats: | txt json html |
| Updates: | RFC 3265 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5367 |
|
This document specifies a way to create subscription to a list of resources in SIP. This is achieved by including the list of resources in the body of a SUBSCRIBE request. Instead of having a subscriber send a SUBSCRIBE request for each resource individually, the subscriber defines the resource list, subscribes to it, and gets notifications about changes in the resources' states using a singleSUBSCRIBE dialog. |
|
| |
| RFC 5368 | Referring to Multiple Resources in the Session Initiation Protocol (SIP) |
| |
| Authors: | G. Camarillo, A. Niemi, M. Isomaki, M. Garcia-Martin, H. Khartabil. |
| Date: | October 2008 |
| Formats: | txt html json |
| Updated by: | RFC 8262 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5368 |
|
This document defines extensions to the SIP REFER method so that it can be used to refer to multiple resources in a single request.These extensions include the use of pointers to Uniform ResourceIdentifier (URI) lists in the Refer-To header field and the"multiple-refer" SIP option-tag. |
|
| |
| RFC 5370 | The Session Initiation Protocol (SIP) Conference Bridge Transcoding Model |
| |
| Authors: | G. Camarillo. |
| Date: | October 2008 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5370 |
|
This document describes how to invoke transcoding services using the conference bridge model. This way of invocation meets the requirements for SIP regarding transcoding services invocation to support deaf, hard of hearing, and speech-impaired individuals. |
|
| |
| RFC 5371 | RTP Payload Format for JPEG 2000 Video Streams |
| |
| Authors: | S. Futemma, E. Itakura, A. Leung. |
| Date: | October 2008 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5371 |
|
This memo describes an RTP payload format for the ISO/IECInternational Standard 15444-1 | ITU-T Rec. T.800, better known asJPEG 2000. JPEG 2000 features are considered in the design of this payload format. JPEG 2000 is a truly scalable compression technology allowing applications to encode once and decode many different ways.The JPEG 2000 video stream is formed by extending from a single image to a series of JPEG 2000 images. |
|
| |
| RFC 5372 | Payload Format for JPEG 2000 Video: Extensions for Scalability and Main Header Recovery |
| |
| Authors: | A. Leung, S. Futemma, E. Itakura. |
| Date: | October 2008 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5372 |
|
This memo describes extended uses for the payload header in "RTPPayload Format for JPEG 2000 Video Streams" as specified in RFC 5371, for better support of JPEG 2000 features such as scalability and main header recovery.
This memo must be accompanied with a complete implementation of "RTPPayload Format for JPEG 2000 Video Streams". That document is a complete description of the payload header and signaling, this document only describes additional processing for the payload header.There is an additional media type and Session Description Protocol(SDP) marker signaling for implementations of this document. |
|
| |
| RFC 5373 | Requesting Answering Modes for the Session Initiation Protocol (SIP) |
| |
| Authors: | D. Willis, Ed., A. Allen. |
| Date: | November 2008 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5373 |
|
This document extends SIP with two header fields and associated option tags that can be used in INVITE requests to convey the requester's preference for user-interface handling related to answering of that request. The first header, "Answer-Mode", expresses a preference as to whether the target node's user interface waits for user input before accepting the request or, instead, accepts the request without waiting on user input. The second header, "Priv-Answer-Mode", is similar to the first, except that it requests administrative-level access and has consequent additional authentication and authorization requirements. These behaviors have applicability to applications such as push-to-talk and to diagnostics like loop-back. Usage of each header field in a response to indicate how the request was handled is also defined. |
|
| |
| RFC 5374 | Multicast Extensions to the Security Architecture for the Internet Protocol |
| |
| Authors: | B. Weis, G. Gross, D. Ignjatic. |
| Date: | November 2008 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5374 |
|
The Security Architecture for the Internet Protocol describes security services for traffic at the IP layer. That architecture primarily defines services for Internet Protocol (IP) unicast packets. This document describes how the IPsec security services are applied to IP multicast packets. These extensions are relevant only for an IPsec implementation that supports multicast. |
|
| |
| RFC 5380 | Hierarchical Mobile IPv6 (HMIPv6) Mobility Management |
| |
| Authors: | H. Soliman, C. Castelluccia, K. ElMalki, L. Bellier. |
| Date: | October 2008 |
| Formats: | txt html json |
| Obsoletes: | RFC 4140 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5380 |
|
This document introduces extensions to Mobile IPv6 and IPv6 NeighbourDiscovery to allow for local mobility handling. Hierarchical mobility management for Mobile IPv6 is designed to reduce the amount of signalling between the mobile node, its correspondent nodes, and its home agent. The Mobility Anchor Point (MAP) described in this document can also be used to improve the performance of Mobile IPv6 in terms of handover speed. |
|
| |
| RFC 5384 | The Protocol Independent Multicast (PIM) Join Attribute Format |
| |
| Authors: | A. Boers, I. Wijnands, E. Rosen. |
| Date: | November 2008 |
| Formats: | txt html json |
| Updated by: | RFC 7887 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5384 |
|
A "Protocol Independent Multicast - Sparse Mode" Join message sent by a given node identifies one or more multicast distribution trees that that node wishes to join. Each tree is identified by the combination of a multicast group address and a source address (where the source address is possibly a "wild card"). Under certain conditions it can be useful, when joining a tree, to specify additional information related to the construction of the tree. However, there has been no way to do so until now. This document describes a modification of the Join message that allows a node to associate attributes with a particular tree. The attributes are encoded in Type-Length-Value format. |
|
| |
| RFC 5386 | Better-Than-Nothing Security: An Unauthenticated Mode of IPsec |
| |
| Authors: | N. Williams, M. Richardson. |
| Date: | November 2008 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5386 |
|
This document specifies how to use the Internet Key Exchange (IKE) protocols, such as IKEv1 and IKEv2, to setup "unauthenticated" security associations (SAs) for use with the IPsec EncapsulatingSecurity Payload (ESP) and the IPsec Authentication Header (AH). No changes to IKEv2 bits-on-the-wire are required, but PeerAuthorization Database (PAD) and Security Policy Database (SPD) extensions are specified. Unauthenticated IPsec is herein referred to by its popular acronym, "BTNS" (Better-Than-Nothing Security). |
|
| |
| RFC 5388 | Information Model and XML Data Model for Traceroute Measurements |
| |
| Authors: | S. Niccolini, S. Tartarelli, J. Quittek, T. Dietz, M. Swany. |
| Date: | December 2008 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5388 |
|
This document describes a standard way to store the configuration and the results of traceroute measurements. This document first describes the terminology used in this document and the traceroute tool itself; afterwards, the common information model is defined, dividing the information elements into two semantically separated groups (configuration elements and results elements). Moreover, an additional element is defined to relate configuration elements and results elements by means of a common unique identifier. On the basis of the information model, a data model based on XML is defined to store the results of traceroute measurements. |
|
| |
| RFC 5389 | Session Traversal Utilities for NAT (STUN) |
| |
|
|
Session Traversal Utilities for NAT (STUN) is a protocol that serves as a tool for other protocols in dealing with Network AddressTranslator (NAT) traversal. It can be used by an endpoint to determine the IP address and port allocated to it by a NAT. It can also be used to check connectivity between two endpoints, and as a keep-alive protocol to maintain NAT bindings. STUN works with many existing NATs, and does not require any special behavior from them.
STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution. This is an important change from the previous version of this specification (RFC3489), which presented STUN as a complete solution.
This document obsoletes RFC 3489. |
|
| |
| RFC 5391 | RTP Payload Format for ITU-T Recommendation G.711.1 |
| |
| Authors: | A. Sollaud. |
| Date: | November 2008 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5391 |
|
This document specifies a Real-time Transport Protocol (RTP) payload format to be used for the ITU Telecommunication StandardizationSector (ITU-T) G.711.1 audio codec. Two media type registrations are also included. |
|
| |
| RFC 5392 | OSPF Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering |
| |
| Authors: | M. Chen, R. Zhang, X. Duan. |
| Date: | January 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5392 |
|
This document describes extensions to the OSPF version 2 and 3 protocols to support Multiprotocol Label Switching (MPLS) andGeneralized MPLS (GMPLS) Traffic Engineering (TE) for multipleAutonomous Systems (ASes). OSPF-TE v2 and v3 extensions are defined for the flooding of TE information about inter-AS links that can be used to perform inter-AS TE path computation.
No support for flooding information from within one AS to another AS is proposed or defined in this document. |
|
| |
| RFC 5393 | Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Forking Proxies |
| |
| Authors: | R. Sparks, Ed., S. Lawrence, A. Hawrylyshen, B. Campen. |
| Date: | December 2008 |
| Formats: | txt json html |
| Updates: | RFC 3261 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5393 |
|
This document normatively updates RFC 3261, the Session InitiationProtocol (SIP), to address a security vulnerability identified in SIP proxy behavior. This vulnerability enables an attack against SIP networks where a small number of legitimate, even authorized, SIP requests can stimulate massive amounts of proxy-to-proxy traffic.
This document strengthens loop-detection requirements on SIP proxies when they fork requests (that is, forward a request to more than one destination). It also corrects and clarifies the description of the loop-detection algorithm such proxies are required to implement.Additionally, this document defines a Max-Breadth mechanism for limiting the number of concurrent branches pursued for any given request. |
|
| |
| RFC 5396 | Textual Representation of Autonomous System (AS) Numbers |
| |
| Authors: | G. Huston, G. Michaelson. |
| Date: | December 2008 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5396 |
|
A textual representation for Autonomous System (AS) numbers is defined as the decimal value of the AS number. This textual representation is to be used by all documents, systems, and user interfaces referring to AS numbers. |
|
| |
| RFC 5397 | WebDAV Current Principal Extension |
| |
| Authors: | W. Sanchez, C. Daboo. |
| Date: | December 2008 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5397 |
|
This specification defines a new WebDAV property that allows clients to quickly determine the principal corresponding to the current authenticated user. |
|
| |
| RFC 5401 | Multicast Negative-Acknowledgment (NACK) Building Blocks |
| |
| Authors: | B. Adamson, C. Bormann, M. Handley, J. Macker. |
| Date: | November 2008 |
| Formats: | txt html json |
| Obsoletes: | RFC 3941 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5401 |
|
This document discusses the creation of reliable multicast protocols that utilize negative-acknowledgment (NACK) feedback. The rationale for protocol design goals and assumptions are presented. Technical challenges for NACK-based (and in some cases general) reliable multicast protocol operation are identified. These goals and challenges are resolved into a set of functional "building blocks" that address different aspects of reliable multicast protocol operation. It is anticipated that these building blocks will be useful in generating different instantiations of reliable multicast protocols. This document obsoletes RFC 3941. |
|
| |
| RFC 5403 | RPCSEC_GSS Version 2 |
| |
|
|
This document describes version 2 of the RPCSEC_GSS protocol.Version 2 is the same as version 1 (specified in RFC 2203) except that support for channel bindings has been added. RPCSEC_GSS allows remote procedure call (RPC) protocols to access the Generic SecurityServices Application Programming Interface (GSS-API). |
|
| |
| RFC 5404 | RTP Payload Format for G.719 |
| |
| Authors: | M. Westerlund, I. Johansson. |
| Date: | January 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5404 |
|
This document specifies the payload format for packetization of theG.719 full-band codec encoded audio signals into the Real-timeTransport Protocol (RTP). The payload format supports transmission of multiple channels, multiple frames per payload, and interleaving. |
|
| |
| RFC 5415 | Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification |
| |
|
|
This specification defines the Control And Provisioning of WirelessAccess Points (CAPWAP) Protocol, meeting the objectives defined by the CAPWAP Working Group in RFC 4564. The CAPWAP protocol is designed to be flexible, allowing it to be used for a variety of wireless technologies. This document describes the base CAPWAP protocol, while separate binding extensions will enable its use with additional wireless technologies. |
|
| |
| RFC 5416 | Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Binding for IEEE 802.11 |
| |
| Authors: | P. Calhoun, Ed., M. Montemurro, Ed., D. Stanley, Ed.. |
| Date: | March 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5416 |
|
Wireless LAN product architectures have evolved from single autonomous access points to systems consisting of a centralizedAccess Controller (AC) and Wireless Termination Points (WTPs). The general goal of centralized control architectures is to move access control, including user authentication and authorization, mobility management, and radio management from the single access point to a centralized controller.
This specification defines the Control And Provisioning of WirelessAccess Points (CAPWAP) Protocol Binding Specification for use with the IEEE 802.11 Wireless Local Area Network protocol. |
|
| |
| RFC 5417 | Control And Provisioning of Wireless Access Points (CAPWAP) Access Controller DHCP Option |
| |
| Authors: | P. Calhoun. |
| Date: | March 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5417 |
|
The Control And Provisioning of Wireless Access Points Protocol allows a Wireless Termination Point to use DHCP to discover theAccess Controllers to which it is to connect. This document describes the DHCP options to be used by the CAPWAP Protocol. |
|
| |
| RFC 5420 | Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE) |
| |
|
|
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.
This document replaces and obsoletes the previous version of this work, published as RFC 4420. The only change is in the encoding of the Type-Length-Variable (TLV) data structures. |
|
| |
| RFC 5423 | Internet Message Store Events |
| |
| Authors: | R. Gellens, C. Newman. |
| Date: | March 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5423 |
|
One of the missing features in the existing Internet mail and messaging standards is a facility for server-to-server and server-to- client event notifications related to message store events. As the scope of Internet mail expands to support more diverse media (such as voice mail) and devices (such as cell phones) and to provide rich interactions with other services (such as web portals and legal compliance systems), the need for an interoperable notification system increases. This document attempts to enumerate the types of events that interest real-world consumers of such a system.
This document describes events and event parameters that are useful for several cases, including notification to administrative systems and end users. This is not intended as a replacement for a message access facility such as IMAP. |
|
| |
| RFC 5424 | The Syslog Protocol |
| |
|
|
This document describes the syslog protocol, which is used to convey event notification messages. This protocol utilizes a layered architecture, which allows the use of any number of transport protocols for transmission of syslog messages. It also provides a message format that allows vendor-specific extensions to be provided in a structured way.
This document has been written with the original design goals for traditional syslog in mind. The need for a new layered specification has arisen because standardization efforts for reliable and secure syslog extensions suffer from the lack of a Standards-Track and transport-independent RFC. Without this document, each other standard needs to define its own syslog packet format and transport mechanism, which over time will introduce subtle compatibility issues. This document tries to provide a foundation that syslog extensions can build on. This layered architecture approach also provides a solid basis that allows code to be written once for each syslog feature rather than once for each transport.
This document obsoletes RFC 3164. |
|
| |
| RFC 5425 | Transport Layer Security (TLS) Transport Mapping for Syslog |
| |
| Authors: | F. Miao, Ed., Y. Ma, Ed., J. Salowey, Ed.. |
| Date: | March 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5425 |
|
This document describes the use of Transport Layer Security (TLS) to provide a secure connection for the transport of syslog messages.This document describes the security threats to syslog and how TLS can be used to counter such threats. |
|
| |
| RFC 5426 | Transmission of Syslog Messages over UDP |
| |
| Authors: | A. Okmianski. |
| Date: | March 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5426 |
|
This document describes the transport for syslog messages over UDP/IPv4 or UDP/IPv6. The syslog protocol layered architecture provides for support of any number of transport mappings. However, for interoperability purposes, syslog protocol implementers are required to support this transport mapping. |
|
| |
| RFC 5427 | Textual Conventions for Syslog Management |
| |
| Authors: | G. Keeni. |
| Date: | March 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5427 |
|
This MIB module defines textual conventions to represent Facility andSeverity information commonly used in syslog messages. The intent is that these textual conventions will be imported and used in MIB modules that would otherwise define their own representations. |
|
| |
| RFC 5428 | Management Event Management Information Base (MIB) for PacketCable- and IPCablecom-Compliant Devices |
| |
| Authors: | S. Channabasappa, W. De Ketelaere, E. Nechamkin. |
| Date: | April 2009 |
| Formats: | txt html json |
| Updated by: | RFC 9141 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5428 |
|
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 SimpleNetwork Management Protocol (SNMP)-based management of events that can be generated by PacketCable- and IPCablecom-compliant MultimediaTerminal Adapter devices. |
|
| |
| RFC 5429 | Sieve Email Filtering: Reject and Extended Reject Extensions |
| |
|
|
This memo updates the definition of the Sieve mail filtering language"reject" extension, originally defined in RFC 3028.
A "Joe-job" is a spam run forged to appear as though it came from an innocent party, who is then generally flooded by automated bounces,Message Disposition Notifications (MDNs), and personal messages with complaints. The original Sieve "reject" action defined in RFC 3028 required use of MDNs for rejecting messages, thus contributing to the flood of Joe-job spam to victims of Joe-jobs.
This memo updates the definition of the "reject" action to allow messages to be refused during the SMTP transaction, and defines the"ereject" action to require messages to be refused during the SMTP transaction, if possible.
The "ereject" action is intended to replace the "reject" action wherever possible. The "ereject" action is similar to "reject", but will always favor protocol-level message rejection. |
|
| |
| RFC 5432 | Quality of Service (QoS) Mechanism Selection in the Session Description Protocol (SDP) |
| |
| Authors: | J. Polk, S. Dhesikan, G. Camarillo. |
| Date: | March 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5432 |
|
The offer/answer model for the Session Description Protocol (SDP) assumes that endpoints somehow establish the Quality of Service (QoS) required for the media streams they establish. Endpoints in closed environments typically agree out-of-band (e.g., using configuration information) regarding which QoS mechanism to use. However, on theInternet, there is more than one QoS service available.Consequently, there is a need for a mechanism to negotiate which QoS mechanism to use for a particular media stream. This document defines such a mechanism. |
|
| |
| RFC 5433 | Extensible Authentication Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method |
| |
| Authors: | T. Clancy, H. Tschofenig. |
| Date: | February 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5433 |
|
This memo defines an Extensible Authentication Protocol (EAP) method called EAP Generalized Pre-Shared Key (EAP-GPSK). This method is a lightweight shared-key authentication protocol supporting mutual authentication and key derivation. |
|
| |
| RFC 5435 | Sieve Email Filtering: Extension for Notifications |
| |
| Authors: | A. Melnikov, Ed., B. Leiba, Ed., W. Segmuller, T. Martin. |
| Date: | January 2009 |
| Formats: | txt html json |
| Updated by: | RFC 8580 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5435 |
|
Users go to great lengths to be notified as quickly as possible that they have received new mail. Most of these methods involve polling to check for new messages periodically. A push method handled by the final delivery agent gives users quicker notifications and saves server resources. This document does not specify the notification method, but it is expected that using existing instant messaging infrastructure such as Extensible Messaging and Presence Protocol(XMPP), or Global System for Mobile Communications (GSM) ShortMessage Service (SMS) messages will be popular. This document describes an extension to the Sieve mail filtering language that allows users to give specific rules for how and when notifications should be sent. |
|
| |
| RFC 5436 | Sieve Notification Mechanism: mailto |
| |
|
|
This document describes a profile of the Sieve extension for notifications, to allow notifications to be sent by electronic mail. |
|
| |
| RFC 5437 | Sieve Notification Mechanism: Extensible Messaging and Presence Protocol (XMPP) |
| |
| Authors: | P. Saint-Andre, A. Melnikov. |
| Date: | January 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5437 |
|
This document describes a profile of the Sieve extension for notifications, to allow notifications to be sent over the ExtensibleMessaging and Presence Protocol (XMPP), also known as Jabber. |
|
| |
| RFC 5438 | Instant Message Disposition Notification (IMDN) |
| |
| Authors: | E. Burger, H. Khartabil. |
| Date: | February 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5438 |
|
Instant Messaging (IM) refers to the transfer of messages between users in real-time. This document provides a mechanism whereby endpoints can request Instant Message Disposition Notifications(IMDN), including delivery, processing, and display notifications, for page-mode instant messages.
The Common Presence and Instant Messaging (CPIM) data format specified in RFC 3862 is extended with new header fields that enable endpoints to request IMDNs. A new message format is also defined to convey IMDNs.
This document also describes how SIP entities behave using this extension. |
|
| |
| RFC 5440 | Path Computation Element (PCE) Communication Protocol (PCEP) |
| |
|
|
This document specifies the Path Computation Element (PCE)Communication Protocol (PCEP) for communications between a PathComputation Client (PCC) and a PCE, or between two PCEs. Such interactions include path computation requests and path computation replies as well as notifications of specific states related to the use of a PCE in the context of Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering. PCEP is designed to be flexible and extensible so as to easily allow for the addition of further messages and objects, should further requirements be expressed in the future. |
|
| |
| RFC 5441 | A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths |
| |
| Authors: | JP. Vasseur, Ed., R. Zhang, N. Bitar, JL. Le Roux. |
| Date: | April 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5441 |
|
The ability to compute shortest constrained Traffic Engineering LabelSwitched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) andGeneralized MPLS (GMPLS) networks across multiple domains has been identified as a key requirement. In this context, a domain is a collection of network elements within a common sphere of address management or path computational responsibility such as an IGP area or an Autonomous Systems. This document specifies a procedure relying on the use of multiple Path Computation Elements (PCEs) to compute such inter-domain shortest constrained paths across a predetermined sequence of domains, using a backward-recursive path computation technique. This technique preserves confidentiality across domains, which is sometimes required when domains are managed by different service providers. |
|
| |
| RFC 5444 | Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format |
| |
|
|
This document specifies a packet format capable of carrying multiple messages that may be used by mobile ad hoc network routing protocols. |
|
| |
| RFC 5445 | Basic Forward Error Correction (FEC) Schemes |
| |
|
|
This document provides Forward Error Correction (FEC) Scheme specifications according to the Reliable Multicast Transport (RMT)FEC building block for the Compact No-Code FEC Scheme, the SmallBlock, Large Block, and Expandable FEC Scheme, the Small BlockSystematic FEC Scheme, and the Compact FEC Scheme. This document obsoletes RFC 3695 and assumes responsibility for the FEC Schemes defined in RFC 3452. |
|
| |
| RFC 5447 | Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction |
| |
| Authors: | J. Korhonen, Ed., J. Bournelle, H. Tschofenig, C. Perkins, K. Chowdhury. |
| Date: | February 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5447 |
|
A Mobile IPv6 node requires a home agent address, a home address, and a security association with its home agent before it can start utilizing Mobile IPv6. RFC 3775 requires that some or all of these parameters be statically configured. Mobile IPv6 bootstrapping work aims to make this information dynamically available to the mobile node. An important aspect of the Mobile IPv6 bootstrapping solution is to support interworking with existing Authentication,Authorization, and Accounting (AAA) infrastructures. This document describes MIPv6 bootstrapping using the Diameter Network AccessServer to home AAA server interface. |
|
| |
| RFC 5450 | Transmission Time Offsets in RTP Streams |
| |
| Authors: | D. Singer, H. Desineni. |
| Date: | March 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5450 |
|
This document describes a method to inform Real-time TransportProtocol (RTP) clients when RTP packets are transmitted at a time other than their 'nominal' transmission time. It also provides a mechanism to provide improved inter-arrival jitter reports from the clients, that take into account the reported transmission times. |
|
| |
| RFC 5451 | Message Header Field for Indicating Message Authentication Status |
| |
|
|
This memo defines a new header field for use with electronic mail messages to indicate the results of message authentication efforts.Any receiver-side software, such as mail filters or Mail User Agents(MUAs), may use this message header field to relay that information in a convenient way to users or to make sorting and filtering decisions. |
|
| |
| RFC 5452 | Measures for Making DNS More Resilient against Forged Answers |
| |
| Authors: | A. Hubert, R. van Mook. |
| Date: | January 2009 |
| Formats: | txt html json |
| Updates: | RFC 2181 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5452 |
|
The current Internet climate poses serious threats to the Domain NameSystem. In the interim period before the DNS protocol can be secured more fully, measures can already be taken to harden the DNS to make'spoofing' a recursing nameserver many orders of magnitude harder.
Even a cryptographically secured DNS benefits from having the ability to discard bogus responses quickly, as this potentially saves large amounts of computation.
By describing certain behavior that has previously not been standardized, this document sets out how to make the DNS more resilient against accepting incorrect responses. This document updates RFC 2181. |
|
| |
| RFC 5453 | Reserved IPv6 Interface Identifiers |
| |
| Authors: | S. Krishnan. |
| Date: | February 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5453 |
|
Interface identifiers in IPv6 unicast addresses are used to identify interfaces on a link. They are required to be unique within a subnet. Several RFCs have specified interface identifiers or identifier ranges that have a special meaning attached to them. AnIPv6 node autoconfiguring an interface identifier in these ranges will encounter unexpected consequences. Since there is no centralized repository for such reserved identifiers, this document aims to create one. |
|
| |
| RFC 5454 | Dual-Stack Mobile IPv4 |
| |
| Authors: | G. Tsirtsis, V. Park, H. Soliman. |
| Date: | March 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5454 |
|
This specification provides IPv6 extensions to the Mobile IPv4 protocol. The extensions allow a dual-stack node to use IPv4 andIPv6 home addresses as well as to move between IPv4 and dual stack network infrastructures. |
|
| |
| RFC 5455 | Diffserv-Aware Class-Type Object for the Path Computation Element Communication Protocol |
| |
| Authors: | S. Sivabalan, Ed., J. Parker, S. Boutros, K. Kumaki. |
| Date: | March 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5455 |
|
This document specifies a CLASSTYPE object to support Diffserv-AwareTraffic Engineering (DS-TE) where path computation is performed with the aid of a Path Computation Element (PCE). |
|
| |
| RFC 5459 | G.729.1 RTP Payload Format Update: Discontinuous Transmission (DTX) Support |
| |
|
|
This document updates the Real-time Transport Protocol (RTP) payload format to be used for the International Telecommunication Union(ITU-T) Recommendation G.729.1 audio codec. It adds DiscontinuousTransmission (DTX) support to the RFC 4749 specification, in a backward-compatible way. An updated media type registration is included for this payload format. |
|
| |
| RFC 5460 | DHCPv6 Bulk Leasequery |
| |
|
|
The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) has been extended with a Leasequery capability that allows a client to request information about DHCPv6 bindings. That mechanism is limited to queries for individual bindings. In some situations individual binding queries may not be efficient, or even possible. This document expands on the Leasequery protocol, adding new query types and allowing for bulk transfer of DHCPv6 binding data via TCP. |
|
| |
| RFC 5462 | Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field |
| |
| Authors: | L. Andersson, R. Asati. |
| Date: | February 2009 |
| Formats: | txt html json |
| Updates: | RFC 3032, RFC 3270, RFC 3272, RFC 3443, RFC 3469, RFC 3564, RFC 3985, RFC 4182, RFC 4364, RFC 4379, RFC 4448, RFC 4761, RFC 5129 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5462 |
|
The early Multiprotocol Label Switching (MPLS) documents defined the form of the MPLS label stack entry. This includes a three-bit field called the "EXP field". The exact use of this field was not defined by these documents, except to state that it was to be "reserved for experimental use".
Although the intended use of the EXP field was as a "Class ofService" (CoS) field, it was not named a CoS field by these early documents because the use of such a CoS field was not considered to be sufficiently defined. Today a number of standards documents define its usage as a CoS field.
To avoid misunderstanding about how this field may be used, it has become increasingly necessary to rename this field. This document changes the name of the field to the "Traffic Class field" ("TC field"). In doing so, it also updates documents that define the current use of the EXP field. |
|
| |
| RFC 5463 | Sieve Email Filtering: Ihave Extension |
| |
| Authors: | N. Freed. |
| Date: | March 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5463 |
|
This document describes the "ihave" extension to the Sieve email filtering language. The "ihave" extension provides a means to write scripts that can take advantage of optional Sieve features but can still run when those optional features are not available. The extension also defines a new error control command intended to be used to report situations where no combination of available extensions satisfies the needs of the script. |
|
| |
| RFC 5464 | The IMAP METADATA Extension |
| |
| Authors: | C. Daboo. |
| Date: | February 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5464 |
|
The METADATA extension to the Internet Message Access Protocol permits clients and servers to maintain "annotations" or "metadata" on IMAP servers. It is possible to have annotations on a per-mailbox basis or on the server as a whole. For example, this would allow comments about the purpose of a particular mailbox to be "attached" to that mailbox, or a "message of the day" containing server status information to be made available to anyone logging in to the server. |
|
| |
| RFC 5465 | The IMAP NOTIFY Extension |
| |
| Authors: | A. Gulbrandsen, C. King, A. Melnikov. |
| Date: | February 2009 |
| Formats: | txt json html |
| Updates: | RFC 5267 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5465 |
|
This document defines an IMAP extension that allows a client to request specific kinds of unsolicited notifications for specified mailboxes, such as messages being added to or deleted from such mailboxes. |
|
| |
| RFC 5466 | IMAP4 Extension for Named Searches (Filters) |
| |
| Authors: | A. Melnikov, C. King. |
| Date: | February 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5466 |
|
The document defines a way to persistently store named IMAP (RFC3501) searches on the server. Such named searches can be subsequently referenced in a SEARCH or any other command that accepts a search criterion as a parameter. |
|
| |
| RFC 5475 | Sampling and Filtering Techniques for IP Packet Selection |
| |
| Authors: | T. Zseby, M. Molina, N. Duffield, S. Niccolini, F. Raspall. |
| Date: | March 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5475 |
|
This document describes Sampling and Filtering techniques for IP packet selection. It provides a categorization of schemes and defines what parameters are needed to describe the most common selection schemes. Furthermore, it shows how techniques can be combined to build more elaborate packet Selectors. The document provides the basis for the definition of information models for configuring selection techniques in Metering Processes and for reporting the technique in use to a Collector. |
|
| |
| RFC 5476 | Packet Sampling (PSAMP) Protocol Specifications |
| |
| Authors: | B. Claise, Ed., A. Johnson, J. Quittek. |
| Date: | March 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5476 |
|
This document specifies the export of packet information from aPacket SAMPling (PSAMP) Exporting Process to a PSAMP CollectingProcess. For export of packet information, the IP Flow Information eXport (IPFIX) protocol is used, as both the IPFIX and PSAMP architecture match very well, and the means provided by the IPFIX protocol are sufficient. The document specifies in detail how theIPFIX protocol is used for PSAMP export of packet information. |
|
| |
| RFC 5477 | Information Model for Packet Sampling Exports |
| |
| Authors: | T. Dietz, B. Claise, P. Aitken, F. Dressler, G. Carle. |
| Date: | March 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5477 |
|
This memo defines an information model for the Packet SAMPling(PSAMP) protocol. It is used by the PSAMP protocol for encoding sampled packet data and information related to the Sampling process.As the PSAMP protocol is based on the IP Flow Information eXport(IPFIX) protocol, this information model is an extension to the IPFIX information model. |
|
| |
| RFC 5478 | IANA Registration of New Session Initiation Protocol (SIP) Resource-Priority Namespaces |
| |
| Authors: | J. Polk. |
| Date: | March 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5478 |
|
This document creates additional Session Initiation Protocol (SIP)Resource-Priority namespaces to meet the requirements of the USDefense Information Systems Agency, and places these namespaces in the IANA registry. |
|
| |
| RFC 5480 | Elliptic Curve Cryptography Subject Public Key Information |
| |
| Authors: | S. Turner, D. Brown, K. Yiu, R. Housley, T. Polk. |
| Date: | March 2009 |
| Formats: | txt json html |
| Updates: | RFC 3279 |
| Updated by: | RFC 8813 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5480 |
|
This document specifies the syntax and semantics for the SubjectPublic Key Information field in certificates that support EllipticCurve Cryptography. This document updates Sections 2.3.5 and 5, and the ASN.1 module of "Algorithms and Identifiers for the InternetX.509 Public Key Infrastructure Certificate and CertificateRevocation List (CRL) Profile", RFC 3279. |
|
| |
| RFC 5482 | TCP User Timeout Option |
| |
| Authors: | L. Eggert, F. Gont. |
| Date: | March 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5482 |
|
The TCP user timeout controls how long transmitted data may remain unacknowledged before a connection is forcefully closed. It is a local, per-connection parameter. This document specifies a new TCP option -- the TCP User Timeout Option -- that allows one end of a TCP connection to advertise its current user timeout value. This information provides advice to the other end of the TCP connection to adapt its user timeout accordingly. Increasing the user timeouts on both ends of a TCP connection allows it to survive extended periods without end-to-end connectivity. Decreasing the user timeouts allows busy servers to explicitly notify their clients that they will maintain the connection state only for a short time without connectivity. |
|
| |
| RFC 5484 | Associating Time-Codes with RTP Streams |
| |
| Authors: | D. Singer. |
| Date: | March 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5484 |
|
This document describes a mechanism for associating time-codes, as defined by the Society of Motion Picture and Television Engineers(SMPTE), with media streams in a way that is independent of the RTP payload format of the media stream itself. |
|
| |
| RFC 5487 | Pre-Shared Key Cipher Suites for TLS with SHA-256/384 and AES Galois Counter Mode |
| |
| Authors: | M. Badra. |
| Date: | March 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5487 |
|
RFC 4279 and RFC 4785 describe pre-shared key cipher suites forTransport Layer Security (TLS). However, all those cipher suites useSHA-1 in their Message Authentication Code (MAC) algorithm. This document describes a set of pre-shared key cipher suites for TLS that uses stronger digest algorithms (i.e., SHA-256 or SHA-384) and another set that uses the Advanced Encryption Standard (AES) inGalois Counter Mode (GCM). |
|
| |
| RFC 5488 | Network Mobility (NEMO) Management Information Base |
| |
| Authors: | S. Gundavelli, G. Keeni, K. Koide, K. Nagami. |
| Date: | April 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5488 |
|
This memo defines a portion of the Management Information Base (MIB), the Network Mobility (NEMO) support MIB, for use with network management protocols in the Internet community. In particular, theNEMO MIB will be used to monitor and control a Mobile IPv6 node withNEMO functionality. |
|
| |
| RFC 5490 | The Sieve Mail-Filtering Language -- Extensions for Checking Mailbox Status and Accessing Mailbox Metadata |
| |
| Authors: | A. Melnikov. |
| Date: | March 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5490 |
|
This memo defines an extension to the Sieve mail filtering language(RFC 5228) for accessing mailbox and server annotations, checking for mailbox existence, and controlling mailbox creation on "fileinto" action. |
|
| |
| RFC 5491 | GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations |
| |
|
|
The Presence Information Data Format Location Object (PIDF-LO) specification provides a flexible and versatile means to represent location information. There are, however, circumstances that arise when information needs to be constrained in how it is represented.In these circumstances, the range of options that need to be implemented are reduced. There is growing interest in being able to use location information contained in a PIDF-LO for routing applications. To allow successful interoperability between applications, location information needs to be normative and more tightly constrained than is currently specified in RFC 4119 (PIDF-LO). This document makes recommendations on how to constrain, represent, and interpret locations in a PIDF-LO. It further recommends a subset of Geography Markup Language (GML) 3.1.1 that is mandatory to implement by applications involved in location-based routing. |
|
| |
| RFC 5494 | IANA Allocation Guidelines for the Address Resolution Protocol (ARP) |
| |
| Authors: | J. Arkko, C. Pignataro. |
| Date: | April 2009 |
| Formats: | txt json html |
| Updates: | RFC 0826, RFC 0951, RFC 1044, RFC 1329, RFC 2131, RFC 2132, RFC 2176, RFC 2225, RFC 2834, RFC 2835, RFC 3315, RFC 4338, RFC 4361, RFC 4701 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5494 |
|
This document specifies the IANA guidelines for allocating new values in the Address Resolution Protocol (ARP). This document also reserves some numbers for experimentation purposes. The changes also affect other protocols that employ values from the ARP name spaces. |
|
| |
| RFC 5496 | The Reverse Path Forwarding (RPF) Vector TLV |
| |
| Authors: | IJ. Wijnands, A. Boers, E. Rosen. |
| Date: | March 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5496 |
|
This document describes a use of the Protocol Independent Multicast(PIM) Join Attribute as defined in RFC 5384, which enables PIM to build multicast trees through an MPLS-enabled network, even if that network's IGP does not have a route to the source of the tree. |
|
| |
| RFC 5497 | Representing Multi-Value Time in Mobile Ad Hoc Networks (MANETs) |
| |
| Authors: | T. Clausen, C. Dearlove. |
| Date: | March 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5497 |
|
This document describes a general and flexible TLV (type-length-value structure) for representing time-values, such as an interval or a duration, using the generalized Mobile Ad hoc NETwork (MANET) packet/ message format. It defines two Message TLVs and two Address BlockTLVs for representing validity and interval times for MANET routing protocols. |
|
| |
| RFC 5498 | IANA Allocations for Mobile Ad Hoc Network (MANET) Protocols |
| |
| Authors: | I. Chakeres. |
| Date: | March 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5498 |
|
This document enumerates several common IANA allocations for use byMobile Ad hoc NETwork (MANET) protocols. The following well-known numbers are required: a UDP port number, an IP protocol number, and a link-local multicast group address. |
|
| |
| RFC 5506 | Support for Reduced-Size Real-Time Transport Control Protocol (RTCP): Opportunities and Consequences |
| |
|
|
This memo discusses benefits and issues that arise when allowingReal-time Transport Protocol (RTCP) packets to be transmitted with reduced size. The size can be reduced if the rules on how to create compound packets outlined in RFC 3550 are removed or changed. Based on that analysis, this memo defines certain changes to the rules to allow feedback messages to be sent as Reduced-Size RTCP packets under certain conditions when using the RTP/AVPF (Real-time TransportProtocol / Audio-Visual Profile with Feedback) profile (RFC 4585).This document updates RFC 3550, RFC 3711, and RFC 4585. |
|
| |
| RFC 5509 | Internet Assigned Numbers Authority (IANA) Registration of Instant Messaging and Presence DNS SRV RRs for the Session Initiation Protocol (SIP) |
| |
| Authors: | S. Loreto. |
| Date: | April 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5509 |
|
This document registers with IANA two new DNS SRV protocol labels for resolving Instant Messaging and Presence services with SIP. |
|
| |
| RFC 5510 | Reed-Solomon Forward Error Correction (FEC) Schemes |
| |
| Authors: | J. Lacan, V. Roca, J. Peltotalo, S. Peltotalo. |
| Date: | April 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5510 |
|
This document describes a Fully-Specified Forward Error Correction(FEC) Scheme for the Reed-Solomon FEC codes over GF(2^^m), where m is in {2..16}, and its application to the reliable delivery of data objects on the packet erasure channel (i.e., a communication path where packets are either received without any corruption or discarded during transmission). This document also describes a Fully-SpecifiedFEC Scheme for the special case of Reed-Solomon codes over GF(2^^8) when there is no encoding symbol group. Finally, in the context of the Under-Specified Small Block Systematic FEC Scheme (FEC EncodingID 129), this document assigns an FEC Instance ID to the special case of Reed-Solomon codes over GF(2^^8).
Reed-Solomon codes belong to the class of Maximum Distance Separable(MDS) codes, i.e., they enable a receiver to recover the k source symbols from any set of k received symbols. The schemes described here are compatible with the implementation from Luigi Rizzo. |
|
| |
| RFC 5511 | Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications |
| |
| Authors: | A. Farrel. |
| Date: | April 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5511 |
|
Several protocols have been specified in the Routing Area of the IETF using a common variant of the Backus-Naur Form (BNF) of representing message syntax. However, there is no formal definition of this version of BNF.
There is value in using the same variant of BNF for the set of protocols that are commonly used together. This reduces confusion and simplifies implementation.
Updating existing documents to use some other variant of BNF that is already formally documented would be a substantial piece of work.
This document provides a formal definition of the variant of BNF that has been used (that we call Routing BNF) and makes it available for use by new protocols. |
|
| |
| RFC 5512 | The BGP Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute |
| |
| Authors: | P. Mohapatra, E. Rosen. |
| Date: | April 2009 |
| Formats: | txt html json |
| Obsoleted by: | RFC 9012 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5512 |
|
In certain situations, transporting a packet from one Border GatewayProtocol (BGP) speaker to another (the BGP next hop) requires that the packet be encapsulated by the first BGP speaker and decapsulated by the second. To support these situations, there needs to be some agreement between the two BGP speakers with regard to the"encapsulation information", i.e., the format of the encapsulation header as well as the contents of various fields of the header.
The encapsulation information need not be signaled for all encapsulation types. In cases where signaling is required (such asLayer Two Tunneling Protocol - Version 3 (L2TPv3) or Generic RoutingEncapsulation (GRE) with key), this document specifies a method by which BGP speakers can signal encapsulation information to each other. The signaling is done by sending BGP updates using theEncapsulation Subsequent Address Family Identifier (SAFI) and theIPv4 or IPv6 Address Family Identifier (AFI). In cases where no encapsulation information needs to be signaled (such as GRE without key), this document specifies a BGP extended community that can be attached to BGP UPDATE messages that carry payload prefixes in order to indicate the encapsulation protocol type to be used. |
|
| |
| RFC 5518 | Vouch By Reference |
| |
| Authors: | P. Hoffman, J. Levine, A. Hathcock. |
| Date: | April 2009 |
| Formats: | txt json html |
| Updated by: | RFC 8553 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5518 |
|
This document describes the Vouch By Reference (VBR) protocol. VBR is a protocol for adding third-party certification to email. It permits independent third parties to certify the owner of a domain name that is associated with received mail. |
|
| |
| RFC 5519 | Multicast Group Membership Discovery MIB |
| |
|
|
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) and the Multicast Listener Discovery(MLD) protocol. |
|
| |
| RFC 5520 | Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism |
| |
| Authors: | R. Bradford, Ed., JP. Vasseur, A. Farrel. |
| Date: | April 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5520 |
|
Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS)Traffic Engineering (TE) Label Switched Paths (LSPs) may be computed by Path Computation Elements (PCEs). Where the TE LSP crosses multiple domains, such as Autonomous Systems (ASes), the path may be computed by multiple PCEs that cooperate, with each responsible for computing a segment of the path. However, in some cases (e.g., whenASes are administered by separate Service Providers), it would break confidentiality rules for a PCE to supply a path segment to a PCE in another domain, thus disclosing AS-internal topology information.This issue may be circumvented by returning a loose hop and by invoking a new path computation from the domain boundary LabelSwitching Router (LSR) during TE LSP setup as the signaling message enters the second domain, but this technique has several issues including the problem of maintaining path diversity.
This document defines a mechanism to hide the contents of a segment of a path, called the Confidential Path Segment (CPS). The CPS may be replaced by a path-key that can be conveyed in the PCECommunication Protocol (PCEP) and signaled within in a ResourceReservation Protocol TE (RSVP-TE) explicit route object. |
|
| |
| RFC 5521 | Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions |
| |
| Authors: | E. Oki, T. Takeda, A. Farrel. |
| Date: | April 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5521 |
|
The Path Computation Element (PCE) provides functions of path computation in support of traffic engineering (TE) in Multi-ProtocolLabel Switching (MPLS) and Generalized MPLS (GMPLS) networks.
When a Path Computation Client (PCC) requests a PCE for a route, it may be useful for the PCC to specify, as constraints to the path computation, abstract nodes, resources, and Shared Risk Link Groups(SRLGs) that are to be explicitly excluded from the computed route.Such constraints are termed "route exclusions".
The PCE Communication Protocol (PCEP) is designed as a communication protocol between PCCs and PCEs. This document presents PCEP extensions for route exclusions. |
|
| |
| RFC 5524 | Extended URLFETCH for Binary and Converted Parts |
| |
| Authors: | D. Cridland. |
| Date: | May 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5524 |
|
The URLFETCH command defined as part of URLAUTH provides a mechanism for third parties to gain access to data held within messages in a user's private store; however, this data is sent verbatim, which is not suitable for a number of applications. This memo specifies a method for obtaining data in forms suitable for non-mail applications. |
|
| |
| RFC 5529 | Modes of Operation for Camellia for Use with IPsec |
| |
| Authors: | A. Kato, M. Kanda, S. Kanno. |
| Date: | April 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5529 |
|
This document describes the use of the Camellia block cipher algorithm in Cipher Block Chaining (CBC) mode, Counter (CTR) mode, and Counter with CBC-MAC (CCM) mode as additional, optional-to- implement Internet Key Exchange Protocol version 2 (IKEv2) andEncapsulating Security Payload (ESP) mechanisms to provide confidentiality, data origin authentication, and connectionless integrity. |
|
| |
| RFC 5530 | IMAP Response Codes |
| |
| Authors: | A. Gulbrandsen. |
| Date: | May 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5530 |
|
IMAP responses consist of a response type (OK, NO, BAD), an optional machine-readable response code, and a human-readable text.
This document collects and documents a variety of machine-readable response codes, for better interoperation and error reporting. |
|
| |
| RFC 5533 | Shim6: Level 3 Multihoming Shim Protocol for IPv6 |
| |
| Authors: | E. Nordmark, M. Bagnulo. |
| Date: | June 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5533 |
|
This document defines the Shim6 protocol, a layer 3 shim for providing locator agility below the transport protocols, so that multihoming can be provided for IPv6 with failover and load-sharing properties, without assuming that a multihomed site will have a provider-independent IPv6 address prefix announced in the global IPv6 routing table. The hosts in a site that has multiple provider- allocated IPv6 address prefixes will use the Shim6 protocol specified in this document to set up state with peer hosts so that the state can later be used to failover to a different locator pair, should the original one stop working. |
|
| |
| RFC 5534 | Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming |
| |
| Authors: | J. Arkko, I. van Beijnum. |
| Date: | June 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5534 |
|
This document specifies how the level 3 multihoming Shim6 protocol(Shim6) detects failures between two communicating nodes. It also specifies an exploration protocol for switching to another pair of interfaces and/or addresses between the same nodes if a failure occurs and an operational pair can be found. |
|
| |
| RFC 5535 | Hash-Based Addresses (HBA) |
| |
| Authors: | M. Bagnulo. |
| Date: | June 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5535 |
|
This memo describes a mechanism to provide a secure binding between the multiple addresses with different prefixes available to a host within a multihomed site. This mechanism employs eitherCryptographically Generated Addresses (CGAs) or a new variant of the same theme that uses the same format in the addresses. The main idea in the new variant is that information about the multiple prefixes is included within the addresses themselves. This is achieved by generating the interface identifiers of the addresses of a host as hashes of the available prefixes and a random number. Then, the multiple addresses are generated by prepending the different prefixes to the generated interface identifiers. The result is a set of addresses, called Hash-Based Addresses (HBAs), that are inherently bound to each other. |
|
| |
| RFC 5536 | Netnews Article Format |
| |
|
|
This document specifies the syntax of Netnews articles in the context of the Internet Message Format (RFC 5322) and Multipurpose InternetMail Extensions (MIME) (RFC 2045). This document obsoletes RFC 1036, providing an updated specification to reflect current practice and incorporating incremental changes specified in other documents. |
|
| |
| RFC 5537 | Netnews Architecture and Protocols |
| |
|
|
This document defines the architecture of Netnews systems and specifies the correct manipulation and interpretation of Netnews articles by software that originates, distributes, stores, and displays them. It also specifies the requirements that must be met by any protocol used to transport and serve Netnews articles. |
|
| |
| RFC 5538 | The 'news' and 'nntp' URI Schemes |
| |
| Authors: | F. Ellermann. |
| Date: | April 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5538 |
|
This memo specifies the 'news' and 'nntp' Uniform Resource Identifier(URI) schemes that were originally defined in RFC 1738. The purpose of this document is to allow RFC 1738 to be made obsolete while keeping the information about these schemes on the Standards Track. |
|
| |
| RFC 5539 | NETCONF over Transport Layer Security (TLS) |
| |
|
|
The Network Configuration Protocol (NETCONF) provides mechanisms to install, manipulate, and delete the configuration of network devices.This document describes how to use the Transport Layer Security (TLS) protocol to secure NETCONF exchanges. |
|
| |
| RFC 5541 | Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP) |
| |
| Authors: | JL. Le Roux, JP. Vasseur, Y. Lee. |
| Date: | June 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5541 |
|
The computation of one or a set of Traffic Engineering Label SwitchedPaths (TE LSPs) in MultiProtocol Label Switching (MPLS) andGeneralized MPLS (GMPLS) networks is subject to a set of one or more specific optimization criteria, referred to as objective functions(e.g., minimum cost path, widest path, etc.).
In the Path Computation Element (PCE) architecture, a PathComputation Client (PCC) may want a path to be computed for one or more TE LSPs according to a specific objective function. Thus, thePCC needs to instruct the PCE to use the correct objective function.Furthermore, it is possible that not all PCEs support the same set of objective functions; therefore, it is useful for the PCC to be able to automatically discover the set of objective functions supported by each PCE.
This document defines extensions to the PCE communication Protocol(PCEP) to allow a PCE to indicate the set of objective functions it supports. Extensions are also defined so that a PCC can indicate in a path computation request the required objective function, and a PCE can report in a path computation reply the objective function that was used for path computation.
This document defines objective function code types for six objective functions previously listed in the PCE requirements work, and provides the definition of four new metric types that apply to a set of synchronized requests. |
|
| |
| RFC 5542 | Definitions of Textual Conventions for Pseudowire (PW) Management |
| |
| Authors: | T. Nadeau, Ed., D. Zelig, Ed., O. Nicklass, Ed.. |
| Date: | May 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5542 |
|
This memo defines a Management Information Base (MIB) module that contains textual conventions (TCs) to represent commonly used pseudowire (PW) management information. The intent is that these TCs will be imported and used in PW-related MIB modules that would otherwise define their own representations. |
|
| |
| RFC 5543 | BGP Traffic Engineering Attribute |
| |
| Authors: | H. Ould-Brahim, D. Fedyk, Y. Rekhter. |
| Date: | May 2009 |
| Formats: | txt json html |
| Updated by: | RFC 7606 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5543 |
|
This document defines a new BGP attribute, the Traffic Engineering attribute, that enables BGP to carry Traffic Engineering information.
The scope and applicability of this attribute currently excludes its use for non-VPN reachability information. |
|
| |
| RFC 5545 | Internet Calendaring and Scheduling Core Object Specification (iCalendar) |
| |
|
| |
| RFC 5546 | iCalendar Transport-Independent Interoperability Protocol (iTIP) |
| |
|
|
This document specifies a protocol that uses the iCalendar object specification to provide scheduling interoperability between different calendaring systems. This is done without reference to a specific transport protocol so as to allow multiple methods of communication between systems. Subsequent documents will define profiles of this protocol that use specific, interoperable methods of communication between systems.
The iCalendar Transport-Independent Interoperability Protocol (iTIP) complements the iCalendar object specification by adding semantics for group scheduling methods commonly available in current calendaring systems. These scheduling methods permit two or more calendaring systems to perform transactions such as publishing, scheduling, rescheduling, responding to scheduling requests, negotiating changes, or canceling. |
|
| |
| RFC 5547 | A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer |
| |
| Authors: | M. Garcia-Martin, M. Isomaki, G. Camarillo, S. Loreto, P. Kyzivat. |
| Date: | May 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5547 |
|
This document provides a mechanism to negotiate the transfer of one or more files between two endpoints by using the Session DescriptionProtocol (SDP) offer/answer model specified in RFC 3264. SDP is extended to describe the attributes of the files to be transferred.The offerer can describe either the files it wants to send or the files it would like to receive. The answerer can either accept or reject the offer separately for each individual file. The transfer of one or more files is initiated after a successful negotiation.The Message Session Relay Protocol (MSRP) is defined as the default mechanism to actually carry the files between the endpoints. The conventions on how to use MSRP for file transfer are also provided in this document. |
|
| |
| RFC 5549 | Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop |
| |
| Authors: | F. Le Faucheur, E. Rosen. |
| Date: | May 2009 |
| Formats: | txt html json |
| Obsoleted by: | RFC 8950 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5549 |
|
Multiprotocol BGP (MP-BGP) specifies that the set of network-layer protocols to which the address carried in the Next Hop field may belong is determined by the Address Family Identifier (AFI) and theSubsequent Address Family Identifier (SAFI). The current AFI/SAFI definitions for the IPv4 address family only have provisions for advertising a Next Hop address that belongs to the IPv4 protocol when advertising IPv4 Network Layer Reachability Information (NLRI) orVPN-IPv4 NLRI. This document specifies the extensions necessary to allow advertising IPv4 NLRI or VPN-IPv4 NLRI with a Next Hop address that belongs to the IPv6 protocol. This comprises an extension of the AFI/SAFI definitions to allow the address of the Next Hop forIPv4 NLRI or VPN-IPv4 NLRI to also belong to the IPv6 protocol, the encoding of the Next Hop in order to determine which of the protocols the address actually belongs to, and a new BGP Capability allowingMP-BGP Peers to dynamically discover whether they can exchange IPv4NLRI and VPN-IPv4 NLRI with an IPv6 Next Hop. |
|
| |
| RFC 5550 | The Internet Email to Support Diverse Service Environments (Lemonade) Profile |
| |
|
|
This document describes a profile (a set of required extensions, restrictions, and usage modes), dubbed Lemonade, of the IMAP, mail submission, and Sieve protocols. This profile allows clients(especially those that are constrained in memory, bandwidth, processing power, or other areas) to efficiently use IMAP andSubmission to access and submit mail. This includes the ability to forward received mail without needing to download and upload the mail, to optimize submission, and to efficiently resynchronize in case of loss of connectivity with the server.
The Lemonade Profile relies upon several extensions to IMAP, Sieve, and Mail Submission protocols. The document also defines a new IMAP extension and registers several new IMAP keywords. |
|
| |
| RFC 5552 | SIP Interface to VoiceXML Media Services |
| |
| Authors: | D. Burke, M. Scott. |
| Date: | May 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5552 |
|
This document describes a SIP interface to VoiceXML media services.Commonly, Application Servers controlling Media Servers use this protocol for pure VoiceXML processing capabilities. This protocol is an adjunct to the full MEDIACTRL protocol and packages mechanism. |
|
| |
| RFC 5553 | Resource Reservation Protocol (RSVP) Extensions for Path Key Support |
| |
| Authors: | A. Farrel, Ed., R. Bradford, JP. Vasseur. |
| Date: | May 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5553 |
|
The paths taken by Multiprotocol Label Switching (MPLS) andGeneralized MPLS (GMPLS) Traffic Engineering (TE) Label SwitchedPaths (LSPs) may be computed by Path Computation Elements (PCEs).Where the TE LSP crosses multiple domains, such as Autonomous Systems(ASes), the path may be computed by multiple PCEs that cooperate, with each responsible for computing a segment of the path.
To preserve confidentiality of topology within each AS, the PCEs support a mechanism to hide the contents of a segment of a path (such as the segment of the path that traverses an AS), called theConfidential Path Segment (CPS), by encoding the contents as a PathKey Subobject (PKS) and embedding this subobject within the result of its path computation.
This document describes how to carry Path Key Subobjects in theResource Reservation Protocol (RSVP) Explicit Route Objects (EROs) and Record Route Objects (RROs) so as to facilitate confidentiality in the signaling of inter-domain TE LSPs. |
|
| |
| RFC 5554 | Clarifications and Extensions to the Generic Security Service Application Program Interface (GSS-API) for the Use of Channel Bindings |
| |
|
|
This document clarifies and generalizes the Generic Security ServiceApplication Programming Interface (GSS-API) "channel bindings" facility, and imposes requirements on future GSS-API mechanisms and programming language bindings of the GSS-API. |
|
| |
| RFC 5555 | Mobile IPv6 Support for Dual Stack Hosts and Routers |
| |
|
|
The current Mobile IPv6 and Network Mobility (NEMO) specifications support IPv6 only. This specification extends those standards to allow the registration of IPv4 addresses and prefixes, respectively, and the transport of both IPv4 and IPv6 packets over the tunnel to the home agent. This specification also allows the mobile node to roam over both IPv6 and IPv4, including the case where NetworkAddress Translation is present on the path between the mobile node and its home agent. |
|
| |
| RFC 5557 | Path Computation Element Communication Protocol (PCEP) Requirements and Protocol Extensions in Support of Global Concurrent Optimization |
| |
| Authors: | Y. Lee, JL. Le Roux, D. King, E. Oki. |
| Date: | July 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5557 |
|
The Path Computation Element Communication Protocol (PCEP) allowsPath Computation Clients (PCCs) to request path computations fromPath Computation Elements (PCEs), and lets the PCEs return responses.When computing or reoptimizing the routes of a set of TrafficEngineering Label Switched Paths (TE LSPs) through a network, it may be advantageous to perform bulk path computations in order to avoid blocking problems and to achieve more optimal network-wide solutions.Such bulk optimization is termed Global Concurrent Optimization(GCO). A GCO is able to simultaneously consider the entire topology of the network and the complete set of existing TE LSPs, and their respective constraints, and look to optimize or reoptimize the entire network to satisfy all constraints for all TE LSPs. A GCO may also be applied to some subset of the TE LSPs in a network. The GCO application is primarily a Network Management System (NMS) solution.
This document provides application-specific requirements and the PCEP extensions in support of GCO applications. |
|
| |
| RFC 5560 | A One-Way Packet Duplication Metric |
| |
|
|
When a packet is sent from one host to the other, one normally expects that exactly one copy of the packet that was sent arrives at the destination. It is, however, possible that a packet is either lost or that multiple copies arrive.
In earlier work, a metric for packet loss was defined. This metric quantifies the case where a packet that is sent does not arrive at its destination within a reasonable time. In this memo, a metric for another case is defined: a packet is sent, but multiple copies arrive. The document also discusses streams and methods to summarize the results of streams. |
|
| |
| RFC 5561 | LDP Capabilities |
| |
| Authors: | B. Thomas, K. Raza, S. Aggarwal, R. Aggarwal, JL. Le Roux. |
| Date: | July 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5561 |
|
A number of enhancements to the Label Distribution Protocol (LDP) have been proposed. Some have been implemented, and some are advancing toward standardization. It is likely that additional enhancements will be proposed in the future. This document defines a mechanism for advertising LDP enhancements at session initialization time, as well as a mechanism to enable and disable enhancements afterLDP session establishment. |
|
| |
| RFC 5565 | Softwire Mesh Framework |
| |
| Authors: | J. Wu, Y. Cui, C. Metz, E. Rosen. |
| Date: | June 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5565 |
|
The Internet needs to be able to handle both IPv4 and IPv6 packets.However, it is expected that some constituent networks of theInternet will be "single-protocol" networks. One kind of single- protocol network can parse only IPv4 packets and can process onlyIPv4 routing information; another kind can parse only IPv6 packets and can process only IPv6 routing information. It is nevertheless required that either kind of single-protocol network be able to provide transit service for the "other" protocol. This is done by passing the "other kind" of routing information from one edge of the single-protocol network to the other, and by tunneling the "other kind" of data packet from one edge to the other. The tunnels are known as "softwires". This framework document explains how the routing information and the data packets of one protocol are passed through a single-protocol network of the other protocol. The document is careful to specify when this can be done with existing technology and when it requires the development of new or modified technology. |
|
| |
| RFC 5566 | BGP IPsec Tunnel Encapsulation Attribute |
| |
| Authors: | L. Berger, R. White, E. Rosen. |
| Date: | June 2009 |
| Formats: | txt json html |
| Obsoleted by: | RFC 9012 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5566 |
|
The BGP Encapsulation Subsequent Address Family Identifier (SAFI) provides a method for the dynamic exchange of encapsulation information and for the indication of encapsulation protocol types to be used for different next hops. Currently, support for GenericRouting Encapsulation (GRE), Layer 2 Tunneling Protocol (L2TPv3), andIP in IP tunnel types are defined. This document defines support forIPsec tunnel types. |
|
| |
| RFC 5568 | Mobile IPv6 Fast Handovers |
| |
|
|
Mobile IPv6 enables a mobile node (MN) to maintain its connectivity to the Internet when moving from one Access Router to another, a process referred to as handover. During handover, there is a period during which the mobile node is unable to send or receive packets because of link-switching delay and IP protocol operations. This"handover latency" resulting from standard Mobile IPv6 procedures(namely, movement detection, new Care-of Address configuration, andBinding Update) is often unacceptable to real-time traffic such asVoice over IP (VoIP). Reducing the handover latency could be beneficial to non-real-time, throughput-sensitive applications as well. This document specifies a protocol to improve handover latency due to Mobile IPv6 procedures. This document does not address improving the link-switching latency.
This document updates the packet formats for the Handover Initiate(HI) and Handover Acknowledge (HAck) messages to the Mobility HeaderType. |
|
| |
| RFC 5571 | Softwire Hub and Spoke Deployment Framework with Layer Two Tunneling Protocol Version 2 (L2TPv2) |
| |
| Authors: | B. Storer, C. Pignataro, Ed., M. Dos Santos, B. Stevant, Ed., L. Toutain, J. Tremblay. |
| Date: | June 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5571 |
|
This document describes the framework of the Softwire "Hub and Spoke" solution with the Layer Two Tunneling Protocol version 2 (L2TPv2).The implementation details specified in this document should be followed to achieve interoperability among different vendor implementations. |
|
| |
| RFC 5574 | RTP Payload Format for the Speex Codec |
| |
| Authors: | G. Herlein, J. Valin, A. Heggestad, A. Moizard. |
| Date: | June 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5574 |
|
Speex is an open-source voice codec suitable for use in VoIP (Voice over IP) type applications. This document describes the payload format for Speex-generated bit streams within an RTP packet. Also included here are the necessary details for the use of Speex with theSession Description Protocol (SDP). |
|
| |
| RFC 5575 | Dissemination of Flow Specification Rules |
| |
| Authors: | P. Marques, N. Sheth, R. Raszuk, B. Greene, J. Mauch, D. McPherson. |
| Date: | August 2009 |
| Formats: | txt html json |
| Obsoleted by: | RFC 8955 |
| Updated by: | RFC 7674 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5575 |
|
This document defines a new Border Gateway Protocol Network LayerReachability Information (BGP NLRI) encoding format that can be used to distribute traffic flow specifications. This allows the routing system to propagate information regarding more specific components of the traffic aggregate defined by an IP destination prefix.
Additionally, it defines two applications of that encoding format: one that can be used to automate inter-domain coordination of traffic filtering, such as what is required in order to mitigate(distributed) denial-of-service attacks, and a second application to provide traffic filtering in the context of a BGP/MPLS VPN service.
The information is carried via the BGP, thereby reusing protocol algorithms, operational experience, and administrative processes such as inter-provider peering agreements. |
|
| |
| RFC 5576 | Source-Specific Media Attributes in the Session Description Protocol (SDP) |
| |
| Authors: | J. Lennox, J. Ott, T. Schierl. |
| Date: | June 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5576 |
|
The Session Description Protocol (SDP) provides mechanisms to describe attributes of multimedia sessions and of individual media streams (e.g., Real-time Transport Protocol (RTP) sessions) within a multimedia session, but does not provide any mechanism to describe individual media sources within a media stream. This document defines a mechanism to describe RTP media sources, which are identified by their synchronization source (SSRC) identifiers, inSDP, to associate attributes with these sources, and to express relationships among sources. It also defines several source-level attributes that can be used to describe properties of media sources. |
|
| |
| RFC 5577 | RTP Payload Format for ITU-T Recommendation G.722.1 |
| |
|
|
International Telecommunication Union (ITU-T) Recommendation G.722.1 is a wide-band audio codec. This document describes the payload format for including G.722.1-generated bit streams within an RTP packet. The document also describes the syntax and semantics of theSession Description Protocol (SDP) parameters needed to supportG.722.1 audio codec. |
|
| |
| RFC 5580 | Carrying Location Objects in RADIUS and Diameter |
| |
| Authors: | H. Tschofenig, Ed., F. Adrangi, M. Jones, A. Lior, B. Aboba. |
| Date: | August 2009 |
| Formats: | txt html json |
| Updated by: | RFC 8559 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5580 |
|
This document describes procedures for conveying access-network ownership and location information based on civic and geospatial location formats in Remote Authentication Dial-In User Service(RADIUS) and Diameter.
The distribution of location information is a privacy-sensitive task.Dealing with mechanisms to preserve the user's privacy is important and is addressed in this document. |
|
| |
| RFC 5583 | Signaling Media Decoding Dependency in the Session Description Protocol (SDP) |
| |
| Authors: | T. Schierl, S. Wenger. |
| Date: | July 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5583 |
|
This memo defines semantics that allow for signaling the decoding dependency of different media descriptions with the same media type in the Session Description Protocol (SDP). This is required, for example, if media data is separated and transported in different network streams as a result of the use of a layered or multiple descriptive media coding process.
A new grouping type "DDP" -- decoding dependency -- is defined, to be used in conjunction with RFC 3388 entitled "Grouping of Media Lines in the Session Description Protocol". In addition, an attribute is specified describing the relationship of the media streams in a "DDP" group indicated by media identification attribute(s) and media format description(s). |
|
| |
| RFC 5584 | RTP Payload Format for the Adaptive TRansform Acoustic Coding (ATRAC) Family |
| |
| Authors: | M. Hatanaka, J. Matsumoto. |
| Date: | July 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5584 |
|
This document describes an RTP payload format for efficient and flexible transporting of audio data encoded with the AdaptiveTRansform Audio Coding (ATRAC) family of codecs. Recent enhancements to the ATRAC family of codecs support high-quality audio coding with multiple channels. The RTP payload format as presented in this document also includes support for data fragmentation, elementary redundancy measures, and a variation on scalable streaming. |
|
| |
| RFC 5586 | MPLS Generic Associated Channel |
| |
| Authors: | M. Bocci, Ed., M. Vigoureux, Ed., S. Bryant, Ed.. |
| Date: | June 2009 |
| Formats: | txt json html |
| Updates: | RFC 3032, RFC 4385, RFC 5085 |
| Updated by: | RFC 6423, RFC 7026, RFC 7214, RFC 7274 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5586 |
|
This document generalizes the applicability of the pseudowire (PW)Associated Channel Header (ACH), enabling the realization of a control channel associated to MPLS Label Switched Paths (LSPs) andMPLS Sections in addition to MPLS pseudowires. In order to identify the presence of this Associated Channel Header in the label stack, this document also assigns one of the reserved MPLS label values to the Generic Associated Channel Label (GAL), to be used as a label based exception mechanism. |
|
| |
| RFC 5587 | Extended Generic Security Service Mechanism Inquiry APIs |
| |
| Authors: | N. Williams. |
| Date: | July 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5587 |
|
This document introduces new application programming interfaces(APIs) to the Generic Security Services API (GSS-API) for extended mechanism attribute inquiry. These interfaces are primarily intended to reduce instances of hardcoding of mechanism identifiers in GSS applications.
These interfaces include mechanism attributes and attribute sets, a function for inquiring the attributes of a mechanism, a function for indicating mechanisms that possess given attributes, and a function for displaying mechanism attributes. |
|
| |
| RFC 5588 | Generic Security Service Application Program Interface (GSS-API) Extension for Storing Delegated Credentials |
| |
| Authors: | N. Williams. |
| Date: | July 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5588 |
|
This document defines a new function for the Generic Security ServiceApplication Program Interface (GSS-API), which allows applications to store delegated (and other) credentials in the implicit GSS-API credential store. This is needed for GSS-API applications to use delegated credentials as they would use other credentials. |
|
| |
| RFC 5592 | Secure Shell Transport Model for the Simple Network Management Protocol (SNMP) |
| |
| Authors: | D. Harrington, J. Salowey, W. Hardaker. |
| Date: | June 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5592 |
|
This memo describes a Transport Model for the Simple NetworkManagement Protocol (SNMP), using the Secure Shell (SSH) protocol.
This memo also 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 monitoring and managing the Secure Shell Transport Model for SNMP. |
|
| |
| RFC 5593 | Internet Message Access Protocol (IMAP) - URL Access Identifier Extension |
| |
|
|
The existing IMAP URL specification (RFC 5092) lists several <access&rt; identifiers and <access&rt; identifier prefixes that can be used to restrict access to URLAUTH-generated URLs. However, these identifiers do not provide facilities for new services such as streaming. This document proposes a set of new <access&rt; identifiers as well as an IANA mechanism to register new <access&rt; identifiers for future applications.
This document updates RFC 5092. |
|
| |
| RFC 5595 | The Datagram Congestion Control Protocol (DCCP) Service Codes |
| |
|
|
This document describes the usage of Service Codes by the DatagramCongestion Control Protocol, RFC 4340. It motivates the setting of aService Code by applications. Service Codes provide a method to identify the intended service/application to process a DCCP connection request. This provides improved flexibility in the use and assignment of port numbers for connection multiplexing. The use of a DCCP Service Code can also enable more explicit coordination of services with middleboxes (e.g., network address translators and firewalls). This document updates the specification provided in RFC4340. |
|
| |
| RFC 5596 | Datagram Congestion Control Protocol (DCCP) Simultaneous-Open Technique to Facilitate NAT/Middlebox Traversal |
| |
|
|
This document specifies an update to the Datagram Congestion ControlProtocol (DCCP), a connection-oriented and datagram-based transport protocol. The update adds support for the DCCP-Listen packet. This assists DCCP applications to communicate through middleboxes (e.g., aNetwork Address Port Translator or a DCCP server behind a firewall), where peering endpoints need to initiate communication in a near- simultaneous manner to establish necessary middlebox state. |
|
| |
| RFC 5601 | Pseudowire (PW) Management Information Base (MIB) |
| |
| Authors: | T. Nadeau, Ed., D. Zelig, Ed.. |
| Date: | July 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5601 |
|
This memo defines a Standards Track portion of the ManagementInformation Base for use with network management protocols in theInternet community. In particular, it describes managed objects for modeling of Pseudowire Edge-to-Edge services carried over a generalPacket Switched Network. |
|
| |
| RFC 5602 | Pseudowire (PW) over MPLS PSN Management Information Base (MIB) |
| |
| Authors: | D. Zelig, Ed., T. Nadeau, Ed.. |
| Date: | July 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5602 |
|
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 MIB module for PW operation overMultiprotocol Label Switching (MPLS) Label Switching Routers (LSRs). |
|
| |
| RFC 5603 | Ethernet Pseudowire (PW) Management Information Base (MIB) |
| |
| Authors: | D. Zelig, Ed., T. Nadeau, Ed.. |
| Date: | July 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5603 |
|
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 of Ethernet pseudowire (PW) services. |
|
| |
| RFC 5604 | Managed Objects for Time Division Multiplexing (TDM) over Packet Switched Networks (PSNs) |
| |
| Authors: | O. Nicklass. |
| Date: | July 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5604 |
|
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 pseudowire encapsulation for structured or unstructured Time-DivisionMultiplexing (TDM) (T1, E1, T3, E3) circuits over a Packet SwitchedNetwork (PSN). |
|
| |
| RFC 5605 | Managed Objects for ATM over Packet Switched Networks (PSNs) |
| |
| Authors: | O. Nicklass, T. Nadeau. |
| Date: | July 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5605 |
|
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 ATMPseudowire (PW) carrying ATM cells over Packet Switched Networks(PSNs). |
|
| |
| RFC 5607 | Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management |
| |
| Authors: | D. Nelson, G. Weber. |
| Date: | July 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5607 |
|
This document specifies Remote Authentication Dial-In User Service(RADIUS) attributes for authorizing management access to a NetworkAccess Server (NAS). Both local and remote management are supported, with granular access rights and management privileges. Specific provisions are made for remote management via Framed Management protocols and for management access over a secure transport protocol. |
|
| |
| RFC 5608 | Remote Authentication Dial-In User Service (RADIUS) Usage for Simple Network Management Protocol (SNMP) Transport Models |
| |
| Authors: | K. Narayan, D. Nelson. |
| Date: | August 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5608 |
|
This memo describes the use of a Remote Authentication Dial-In UserService (RADIUS) authentication and authorization service with SimpleNetwork Management Protocol (SNMP) secure Transport Models to authenticate users and authorize creation of secure transport sessions. While the recommendations of this memo are generally applicable to a broad class of SNMP Transport Models, the examples focus on the Secure Shell (SSH) Transport Model. |
|
| |
| RFC 5610 | Exporting Type Information for IP Flow Information Export (IPFIX) Information Elements |
| |
| Authors: | E. Boschi, B. Trammell, L. Mark, T. Zseby. |
| Date: | July 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5610 |
|
This document describes an extension to the IP Flow InformationExport (IPFIX) protocol, which is used to represent and transmit data from IP flow measurement devices for collection, storage, and analysis, to allow the encoding of IPFIX Information Model properties within an IPFIX Message stream. This enables the export of extended type information for enterprise-specific Information Elements and the storage of such information within IPFIX Files, facilitating interoperability and reusability among a wide variety of applications and tools. |
|
| |
| RFC 5611 | Layer Two Tunneling Protocol version 3 - Setup of Time-Division Multiplexing (TDM) Pseudowires |
| |
| Authors: | A. Vainshtein, S. Galtzur. |
| Date: | August 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5611 |
|
This document defines extensions to the Layer Two Tunneling Protocol version 3 (L2TPv3) for support of structure-agnostic and structure- aware (Circuit Emulation Service over Packet Switched Network(CESoPSN) style) Time-Division Multiplexing (TDM) pseudowires.Support of structure-aware (Time-Division Multiplexing over IP(TDMoIP) style) pseudowires over L2TPv3 is left for further study. |
|
| |
| RFC 5613 | OSPF Link-Local Signaling |
| |
| Authors: | A. Zinin, A. Roy, L. Nguyen, B. Friedman, D. Yeung. |
| Date: | August 2009 |
| Formats: | txt json html |
| Obsoletes: | RFC 4813 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5613 |
|
OSPF is a link-state intra-domain routing protocol. OSPF routers exchange information on a link using packets that follow a well- defined fixed format. The format is not flexible enough to enable new features that need to exchange arbitrary data. This document describes a backward-compatible technique to perform link-local signaling, i.e., exchange arbitrary data on a link. This document replaces the experimental specification published in RFC 4813 to bring it on the Standards Track. |
|
| |
| RFC 5618 | Mixed Security Mode for the Two-Way Active Measurement Protocol (TWAMP) |
| |
|
|
This memo describes a simple extension to TWAMP (the Two-Way ActiveMeasurement Protocol). The extension adds the option to use different security modes in the TWAMP-Control and TWAMP-Test protocols simultaneously. The memo also describes a new IANA registry for additional features, called the TWAMP Modes registry. |
|
| |
| RFC 5619 | Softwire Security Analysis and Requirements |
| |
| Authors: | S. Yamamoto, C. Williams, H. Yokota, F. Parent. |
| Date: | August 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5619 |
|
This document describes security guidelines for the softwire "Hubs and Spokes" and "Mesh" solutions. Together with discussion of the softwire deployment scenarios, the vulnerability to security attacks is analyzed to provide security protection mechanisms such as authentication, integrity, and confidentiality to the softwire control and data packets. |
|
| |
| RFC 5621 | Message Body Handling in the Session Initiation Protocol (SIP) |
| |
|
|
This document specifies how message bodies are handled in SIP.Additionally, this document specifies SIP user agent support for MIME(Multipurpose Internet Mail Extensions) in message bodies. |
|
| |
| RFC 5624 | Quality of Service Parameters for Usage with Diameter |
| |
| Authors: | J. Korhonen, Ed., H. Tschofenig, E. Davies. |
| Date: | August 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5624 |
|
This document defines a number of Quality of Service (QoS) parameters that can be reused for conveying QoS information within Diameter.
The defined QoS information includes data traffic parameters for describing a token bucket filter, a bandwidth parameter, and a per- hop behavior class object. |
|
| |
| RFC 5626 | Managing Client-Initiated Connections in the Session Initiation Protocol (SIP) |
| |
|
|
The Session Initiation Protocol (SIP) allows proxy servers to initiate TCP connections or to send asynchronous UDP datagrams toUser Agents in order to deliver requests. However, in a large number of real deployments, many practical considerations, such as the existence of firewalls and Network Address Translators (NATs) or the use of TLS with server-provided certificates, prevent servers from connecting to User Agents in this way. This specification defines behaviors for User Agents, registrars, and proxy servers that allow requests to be delivered on existing connections established by theUser Agent. It also defines keep-alive behaviors needed to keep NAT bindings open and specifies the usage of multiple connections from the User Agent to its registrar. |
|
| |
| RFC 5627 | Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP) |
| |
| Authors: | J. Rosenberg. |
| Date: | October 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5627 |
|
Several applications of the Session Initiation Protocol (SIP) require a user agent (UA) to construct and distribute a URI that can be used by anyone on the Internet to route a call to that specific UA instance. A URI that routes to a specific UA instance is called aGlobally Routable UA URI (GRUU). This document describes an extension to SIP for obtaining a GRUU from a registrar and for communicating a GRUU to a peer within a dialog. |
|
| |
| RFC 5628 | Registration Event Package Extension for Session Initiation Protocol (SIP) Globally Routable User Agent URIs (GRUUs) |
| |
| Authors: | P. Kyzivat. |
| Date: | October 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5628 |
|
RFC 3680 defines a Session Initiation Protocol (SIP) event package for registration state. This package allows a watcher to learn about information stored by a SIP registrar, including its registered contact.
However, the registered contact is frequently unreachable and thus not useful for watchers. The Globally Routable User Agent URI(GRUU), defined in RFC 5627, is a URI that is capable of reaching a particular contact. However this URI is not included in the document format defined in RFC 3680. This specification defines an extension to the registration event package to include GRUUs assigned by the registrar. |
|
| |
| RFC 5629 | A Framework for Application Interaction in the Session Initiation Protocol (SIP) |
| |
| Authors: | J. Rosenberg. |
| Date: | October 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5629 |
|
This document describes a framework for the interaction between users and Session Initiation Protocol (SIP) based applications. By interacting with applications, users can guide the way in which they operate. The focus of this framework is stimulus signaling, which allows a user agent (UA) to interact with an application without knowledge of the semantics of that application. Stimulus signaling can occur to a user interface running locally with the client, or to a remote user interface, through media streams. Stimulus signaling encompasses a wide range of mechanisms, ranging from clicking on hyperlinks, to pressing buttons, to traditional Dual-Tone Multi-Frequency (DTMF) input. In all cases, stimulus signaling is supported through the use of markup languages, which play a key role in this framework. |
|
| |
| RFC 5630 | The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP) |
| |
|
|
This document provides clarifications and guidelines concerning the use of the SIPS URI scheme in the Session Initiation Protocol (SIP).It also makes normative changes to SIP. |
|
| |
| RFC 5640 | Load-Balancing for Mesh Softwires |
| |
| Authors: | C. Filsfils, P. Mohapatra, C. Pignataro. |
| Date: | August 2009 |
| Formats: | txt json html |
| Updated by: | RFC 9012 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5640 |
|
Payloads transported over a Softwire mesh service (as defined by BGPEncapsulation Subsequent Address Family Identifier (SAFI) information exchange) often carry a number of identifiable, distinct flows. It can, in some circumstances, be desirable to distribute these flows over the equal cost multiple paths (ECMPs) that exist in the packet switched network. Currently, the payload of a packet entering theSoftwire can only be interpreted by the ingress and egress routers.Thus, the load-balancing decision of a core router is only based on the encapsulating header, presenting much less entropy than available in the payload or the encapsulated header since the Softwire encapsulation acts in a tunneling fashion. This document describes a method for achieving comparable load-balancing efficiency in a network carrying Softwire mesh service over Layer Two TunnelingProtocol - Version 3 (L2TPv3) over IP or Generic RoutingEncapsulation (GRE) encapsulation to what would be achieved without such encapsulation. |
|
| |
| RFC 5641 | Layer 2 Tunneling Protocol Version 3 (L2TPv3) Extended Circuit Status Values |
| |
|
|
This document defines additional Layer 2 Tunneling Protocol Version 3(L2TPv3) bit values to be used within the "Circuit Status" AttributeValue Pair (AVP) to communicate finer-grained error states forAttachment Circuits (ACs) and pseudowires (PWs). It also generalizes the Active bit and deprecates the use of the New bit in the CircuitStatus AVP, updating RFC 3931, RFC 4349, RFC 4454, RFC 4591, and RFC4719. |
|
| |
| RFC 5642 | Dynamic Hostname Exchange Mechanism for OSPF |
| |
| Authors: | S. Venkata, S. Harwani, C. Pignataro, D. McPherson. |
| Date: | August 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5642 |
|
This document defines a new OSPF Router Information (RI) TLV that allows OSPF routers to flood their hostname-to-Router-ID mapping information across an OSPF network to provide a simple and dynamic mechanism for routers running OSPF to learn about symbolic hostnames, just like for routers running IS-IS. This mechanism is applicable to both OSPFv2 and OSPFv3. |
|
| |
| RFC 5643 | Management Information Base for OSPFv3 |
| |
| Authors: | D. Joyal, Ed., V. Manral, Ed.. |
| Date: | August 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5643 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in IPv6-based internets.In particular, it defines objects for managing the Open Shortest PathFirst (OSPF) Routing Protocol for IPv6, otherwise known as OSPF version 3 (OSPFv3). |
|
| |
| RFC 5644 | IP Performance Metrics (IPPM): Spatial and Multicast |
| |
| Authors: | E. Stephan, L. Liang, A. Morton. |
| Date: | October 2009 |
| Formats: | txt json html |
| Updated by: | RFC 6248 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5644 |
|
The IETF has standardized IP Performance Metrics (IPPM) for measuring end-to-end performance between two points. This memo defines two new categories of metrics that extend the coverage to multiple measurement points. It defines spatial metrics for measuring the performance of segments of a source to destination path, and metrics for measuring the performance between a source and many destinations in multiparty communications (e.g., a multicast tree). |
|
| |
| RFC 5648 | Multiple Care-of Addresses Registration |
| |
| Authors: | R. Wakikawa, Ed., V. Devarapalli, G. Tsirtsis, T. Ernst, K. Nagami. |
| Date: | October 2009 |
| Formats: | txt json html |
| Updated by: | RFC 6089 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5648 |
|
According to the current Mobile IPv6 specification, a mobile node may have several care-of addresses but only one, called the primary care-of address, can be registered with its home agent and the correspondent nodes. However, for matters of cost, bandwidth, delay, etc, it is useful for the mobile node to get Internet access through multiple accesses simultaneously, in which case the mobile node would be configured with multiple active IPv6 care-of addresses. This document proposes extensions to the Mobile IPv6 protocol to register and use multiple care-of addresses. The extensions proposed in this document can be used by mobile routers using the NEMO (NetworkMobility) Basic Support protocol as well. |
|
| |
| RFC 5650 | Definitions of Managed Objects for Very High Speed Digital Subscriber Line 2 (VDSL2) |
| |
| Authors: | M. Morgenstern, S. Baillie, U. Bonollo. |
| Date: | September 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5650 |
|
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 parameters of the"Very High Speed Digital Subscriber Line 2 (VDSL2)" interface type, which are also applicable for managing Asymmetric Digital SubscriberLine (ADSL), ADSL2, and ADSL2+ interfaces. |
|
| |
| RFC 5651 | Layered Coding Transport (LCT) Building Block |
| |
| Authors: | M. Luby, M. Watson, L. Vicisano. |
| Date: | October 2009 |
| Formats: | txt json html |
| Obsoletes: | RFC 3451 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5651 |
|
The Layered Coding Transport (LCT) Building Block provides transport level support for reliable content delivery and stream delivery protocols. LCT is specifically designed to support protocols usingIP multicast, but it also provides support to protocols that use unicast. LCT is compatible with congestion control that provides multiple rate delivery to receivers and is also compatible with coding techniques that provide reliable delivery of content. This document obsoletes RFC 3451. |
|
| |
| RFC 5653 | Generic Security Service API Version 2: Java Bindings Update |
| |
|
|
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 updates the Java bindings for the GSS-API that are specified in"Generic Security Service API Version 2 : Java Bindings" (RFC 2853).This document obsoletes RFC 2853 by making specific and incremental clarifications and corrections to it in response to identification of transcription errors and implementation experience.
The GSS-API is described at a language-independent conceptual level in "Generic Security Service Application Program Interface Version 2,Update 1" (RFC 2743). 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 "The Simple Public-Key GSS-API Mechanism" (RFC 2025) and "TheKerberos Version 5 Generic Security Service Application ProgramInterface (GSS-API) Mechanism: Version 2" (RFC 4121). |
|
| |
| RFC 5654 | Requirements of an MPLS Transport Profile |
| |
| Authors: | B. Niven-Jenkins, Ed., D. Brungard, Ed., M. Betts, Ed., N. Sprecher, S. Ueno. |
| Date: | September 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5654 |
|
This document specifies the requirements of an MPLS Transport Profile(MPLS-TP). This document is a product of a joint effort of theInternational Telecommunications Union (ITU) and IETF to include anMPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network as defined by International Telecommunications Union -Telecommunications Standardization Sector (ITU-T).
This work is based on two sources of requirements: MPLS and PWE3 architectures as defined by IETF, and packet transport networks as defined by ITU-T.
The requirements expressed in this document are for the behavior of the protocol mechanisms and procedures that constitute building blocks out of which the MPLS Transport Profile is constructed. The requirements are not implementation requirements. |
|
| |
| RFC 5655 | Specification of the IP Flow Information Export (IPFIX) File Format |
| |
| Authors: | B. Trammell, E. Boschi, L. Mark, T. Zseby, A. Wagner. |
| Date: | October 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5655 |
|
This document describes a file format for the storage of flow data based upon the IP Flow Information Export (IPFIX) protocol. It proposes a set of requirements for flat-file, binary flow data file formats, then specifies the IPFIX File format to meet these requirements based upon IPFIX Messages. This IPFIX File format is designed to facilitate interoperability and reusability among a wide variety of flow storage, processing, and analysis tools. |
|
| |
| RFC 5656 | Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer |
| |
| Authors: | D. Stebila, J. Green. |
| Date: | December 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5656 |
|
This document describes algorithms based on Elliptic CurveCryptography (ECC) for use within the Secure Shell (SSH) transport protocol. In particular, it specifies Elliptic Curve Diffie-Hellman(ECDH) key agreement, Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key agreement, and Elliptic Curve Digital Signature Algorithm (ECDSA) for use in the SSH Transport Layer protocol. |
|
| |
| RFC 5658 | Addressing Record-Route Issues in the Session Initiation Protocol (SIP) |
| |
| Authors: | T. Froment, C. Lebel, B. Bonnaerens. |
| Date: | October 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5658 |
|
A typical function of a Session Initiation Protocol (SIP) Proxy is to insert a Record-Route header into initial, dialog-creating requests in order to make subsequent, in-dialog requests pass through it.This header contains a SIP Uniform Resource Identifier (URI) or SIPS(secure SIP) URI indicating where and how the subsequent requests should be sent to reach the proxy. These SIP or SIPS URIs can contain IPv4 or IPv6 addresses and URI parameters that could influence the routing such as the transport parameter (for example, transport=tcp), or a compression indication like "comp=sigcomp".When a proxy has to change some of those parameters between its incoming and outgoing interfaces (multi-homed proxies, transport protocol switching, or IPv4 to IPv6 scenarios, etc.), the question arises on what should be put in Record-Route header(s). It is not possible to make one header have the characteristics of both interfaces at the same time. This document aims to clarify these scenarios and fix bugs already identified on this topic; it formally recommends the use of the double Record-Route technique as an alternative to the current RFC 3261 text, which describes only aRecord-Route rewriting solution. |
|
| |
| RFC 5660 | IPsec Channels: Connection Latching |
| |
| Authors: | N. Williams. |
| Date: | October 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5660 |
|
This document specifies, abstractly, how to interface applications and transport protocols with IPsec so as to create "channels" by latching "connections" (packet flows) to certain IPsec SecurityAssociation (SA) parameters for the lifetime of the connections.Connection latching is layered on top of IPsec and does not modify the underlying IPsec architecture.
Connection latching can be used to protect applications against accidentally exposing live packet flows to unintended peers, whether as the result of a reconfiguration of IPsec or as the result of using weak peer identity to peer address associations. Weak association of peer ID and peer addresses is at the core of Better Than NothingSecurity (BTNS); thus, connection latching can add a significant measure of protection to BTNS IPsec nodes.
Finally, the availability of IPsec channels will make it possible to use channel binding to IPsec channels. |
|
| |
| RFC 5661 | Network File System (NFS) Version 4 Minor Version 1 Protocol |
| |
|
|
This document describes the Network File System (NFS) version 4 minor version 1, including features retained from the base protocol (NFS version 4 minor version 0, which is specified in RFC 3530) and protocol extensions made subsequently. Major extensions introduced in NFS version 4 minor version 1 include Sessions, DirectoryDelegations, and parallel NFS (pNFS). NFS version 4 minor version 1 has no dependencies on NFS version 4 minor version 0, and it is considered a separate protocol. Thus, this document neither updates nor obsoletes RFC 3530. NFS minor version 1 is deemed superior toNFS minor version 0 with no loss of functionality, and its use is preferred over version 0. Both NFS minor versions 0 and 1 can be used simultaneously on the same network, between the same client and server. |
|
| |
| RFC 5662 | Network File System (NFS) Version 4 Minor Version 1 External Data Representation Standard (XDR) Description |
| |
| Authors: | S. Shepler, Ed., M. Eisler, Ed., D. Noveck, Ed.. |
| Date: | January 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5662 |
|
This document provides the External Data Representation Standard(XDR) description for Network File System version 4 (NFSv4) minor version 1. |
|
| |
| RFC 5663 | Parallel NFS (pNFS) Block/Volume Layout |
| |
| Authors: | D. Black, S. Fridella, J. Glasgow. |
| Date: | January 2010 |
| Formats: | txt html json |
| Updated by: | RFC 6688 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5663 |
|
Parallel NFS (pNFS) extends Network File Sharing version 4 (NFSv4) to allow clients to directly access file data on the storage used by theNFSv4 server. This ability to bypass the server for data access can increase both performance and parallelism, but requires additional client functionality for data access, some of which is dependent on the class of storage used. The main pNFS operations document specifies storage-class-independent extensions to NFS; this document specifies the additional extensions (primarily data structures) for use of pNFS with block- and volume-based storage. |
|
| |
| RFC 5664 | Object-Based Parallel NFS (pNFS) Operations |
| |
| Authors: | B. Halevy, B. Welch, J. Zelenka. |
| Date: | January 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5664 |
|
Parallel NFS (pNFS) extends Network File System version 4 (NFSv4) to allow clients to directly access file data on the storage used by theNFSv4 server. This ability to bypass the server for data access can increase both performance and parallelism, but requires additional client functionality for data access, some of which is dependent on the class of storage used, a.k.a. the Layout Type. The main pNFS operations and data types in NFSv4 Minor version 1 specify a layout- type-independent layer; layout-type-specific information is conveyed using opaque data structures whose internal structure is further defined by the particular layout type specification. This document specifies the NFSv4.1 Object-Based pNFS Layout Type as a companion to the main NFSv4 Minor version 1 specification. |
|
| |
| RFC 5665 | IANA Considerations for Remote Procedure Call (RPC) Network Identifiers and Universal Address Formats |
| |
|
|
This document lists IANA Considerations for Remote Procedure Call(RPC) Network Identifiers (netids) and RPC Universal NetworkAddresses (uaddrs). This document updates, but does not replace, RFC1833. |
|
| |
| RFC 5666 | Remote Direct Memory Access Transport for Remote Procedure Call |
| |
| Authors: | T. Talpey, B. Callaghan. |
| Date: | January 2010 |
| Formats: | txt html json |
| Obsoleted by: | RFC 8166 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5666 |
|
This document describes a protocol providing Remote Direct MemoryAccess (RDMA) as a new transport for Remote Procedure Call (RPC).The RDMA transport binding conveys the benefits of efficient, bulk- data transport over high-speed networks, while providing for minimal change to RPC applications and with no required revision of the application RPC protocol, or the RPC protocol itself. |
|
| |
| RFC 5667 | Network File System (NFS) Direct Data Placement |
| |
| Authors: | T. Talpey, B. Callaghan. |
| Date: | January 2010 |
| Formats: | txt html json |
| Obsoleted by: | RFC 8267 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5667 |
|
This document defines the bindings of the various Network File System(NFS) versions to the Remote Direct Memory Access (RDMA) operations supported by the RPC/RDMA transport protocol. It describes the use of direct data placement by means of server-initiated RDMA operations into client-supplied buffers for implementations of NFS versions 2,3, 4, and 4.1 over such an RDMA transport. |
|
| |
| RFC 5668 | 4-Octet AS Specific BGP Extended Community |
| |
| Authors: | Y. Rekhter, S. Sangli, D. Tappan. |
| Date: | October 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5668 |
|
This document defines a new type of a BGP extended community, which carries a 4-octet Autonomous System (AS) number. |
|
| |
| RFC 5669 | The SEED Cipher Algorithm and Its Use with the Secure Real-Time Transport Protocol (SRTP) |
| |
| Authors: | S. Yoon, J. Kim, H. Park, H. Jeong, Y. Won. |
| Date: | August 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5669 |
|
This document describes the use of the SEED block cipher algorithm in the Secure Real-time Transport Protocol (SRTP) for providing confidentiality for Real-time Transport Protocol (RTP) traffic and for the control traffic for RTP, the Real-time Transport ControlProtocol (RTCP). |
|
| |
| RFC 5670 | Metering and Marking Behaviour of PCN-Nodes |
| |
| Authors: | P. Eardley, Ed.. |
| Date: | November 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5670 |
|
The objective of Pre-Congestion Notification (PCN) is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain in a simple, scalable, and robust fashion. This document defines the two metering and marking behaviours of PCN-nodes. Threshold-metering and -marking marks all PCN-packets if the rate of PCN-traffic is greater than a configured rate ("PCN-threshold-rate"). Excess- traffic-metering and -marking marks a proportion of PCN-packets, such that the amount marked equals the rate of PCN-traffic in excess of a configured rate ("PCN-excess-rate"). The level of marking allowsPCN-boundary-nodes to make decisions about whether to admit or terminate PCN-flows. |
|
| |
| RFC 5672 | RFC 4871 DomainKeys Identified Mail (DKIM) Signatures -- Update |
| |
|
|
This document updates RFC 4871, "DomainKeys Identified Mail (DKIM)Signatures". Specifically, the document clarifies the nature, roles, and relationship of the two DKIM identifier tag values that are candidates for payload delivery to a receiving processing module.The Update is in the style of an Errata entry, albeit a rather long one. |
|
| |
| RFC 5674 | Alarms in Syslog |
| |
| Authors: | S. Chisholm, R. Gerhards. |
| Date: | October 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5674 |
|
This document describes how to send alarm information in syslog. It includes the mapping of ITU perceived severities onto syslog message fields. It also includes a number of alarm-specific SD-PARAM definitions from X.733 and the IETF Alarm MIB. |
|
| |
| RFC 5675 | Mapping Simple Network Management Protocol (SNMP) Notifications to SYSLOG Messages |
| |
| Authors: | V. Marinov, J. Schoenwaelder. |
| Date: | October 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5675 |
|
This memo defines a mapping from Simple Network Management Protocol(SNMP) notifications to SYSLOG messages. |
|
| |
| RFC 5676 | Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications |
| |
| Authors: | J. Schoenwaelder, A. Clemm, A. Karmakar. |
| Date: | October 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5676 |
|
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 mapping of SYSLOG messages to SimpleNetwork Management Protocol (SNMP) notifications. |
|
| |
| RFC 5677 | IEEE 802.21 Mobility Services Framework Design (MSFD) |
| |
| Authors: | T. Melia, Ed., G. Bajko, S. Das, N. Golmie, JC. Zuniga. |
| Date: | December 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5677 |
|
This document describes a mobility services framework design (MSFD) for the IEEE 802.21 Media Independent Handover (MIH) protocol that addresses identified issues associated with the transport of MIH messages. The document also describes mechanisms for MobilityServices (MoS) discovery and transport-layer mechanisms for the reliable delivery of MIH messages. This document does not provide mechanisms for securing the communication between a mobile node (MN) and the Mobility Server. Instead, it is assumed that either lower- layer (e.g., link-layer) security mechanisms or overall system- specific proprietary security solutions are used. |
|
| |
| RFC 5678 | Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for IEEE 802.21 Mobility Services (MoS) Discovery |
| |
| Authors: | G. Bajko, S. Das. |
| Date: | December 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5678 |
|
This document defines new Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) options that contain a list of IP addresses and a list of domain names that can be mapped to servers providing IEEE 802.21 type of Mobility Service (MoS) (see RFC 5677). These Mobility Services are used to assist a mobile node (MN) in handover preparation(network discovery) and handover decision (network selection). The services addressed in this document are the Media IndependentHandover Services defined in IEEE 802.21. |
|
| |
| RFC 5679 | Locating IEEE 802.21 Mobility Services Using DNS |
| |
|
|
This document defines application service tags that allow service location without relying on rigid domain naming conventions, and DNS procedures for discovering servers that provide IEEE 802.21-definedMobility Services. Such Mobility Services are used to assist aMobile Node (MN) supporting IEEE 802.21, in handover preparation(network discovery) and handover decision (network selection). The services addressed by this document are the Media IndependentHandover Services defined in IEEE 802.21. |
|
| |
| RFC 5682 | Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP |
| |
| Authors: | P. Sarolahti, M. Kojo, K. Yamamoto, M. Hata. |
| Date: | September 2009 |
| Formats: | txt html json |
| Updates: | RFC 4138 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5682 |
|
The purpose of this document is to move the F-RTO (ForwardRTO-Recovery) functionality for TCP in RFC 4138 fromExperimental to Standards Track status. The F-RTO support for StreamControl Transmission Protocol (SCTP) in RFC 4138 remains withExperimental status. See Appendix B for the differences between this document and RFC 4138.
Spurious retransmission timeouts cause suboptimal TCP performance because they often result in unnecessary retransmission of the last window of data. This document describes the F-RTO detection algorithm for detecting spurious TCP retransmission timeouts. F-RTO is a TCP sender-only algorithm that does not require any TCP options to operate. After retransmitting the first unacknowledged segment triggered by a timeout, the F-RTO algorithm of the TCP sender monitors the incoming acknowledgments to determine whether the timeout was spurious. It then decides whether to send new segments or retransmit unacknowledged segments. The algorithm effectively helps to avoid additional unnecessary retransmissions and thereby improves TCP performance in the case of a spurious timeout. |
|
| |
| RFC 5685 | Redirect Mechanism for the Internet Key Exchange Protocol Version 2 (IKEv2) |
| |
| Authors: | V. Devarapalli, K. Weniger. |
| Date: | November 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5685 |
|
The Internet Key Exchange Protocol version 2 (IKEv2) is a protocol for setting up Virtual Private Network (VPN) tunnels from a remote location to a gateway so that the VPN client can access services in the network behind the gateway. This document defines an IKEv2 extension that allows an overloaded VPN gateway or a VPN gateway that is being shut down for maintenance to redirect the VPN client to attach to another gateway. The proposed mechanism can also be used in Mobile IPv6 to enable the home agent to redirect the mobile node to another home agent. |
|
| |
| RFC 5686 | RTP Payload Format for mU-law EMbedded Codec for Low-delay IP Communication (UEMCLIP) Speech Codec |
| |
| Authors: | Y. Hiwasaki, H. Ohmuro. |
| Date: | October 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5686 |
|
This document describes the RTP payload format of a mU-law EMbeddedCoder for Low-delay IP communication (UEMCLIP), an enhanced speech codec of ITU-T G.711. The bitstream has a scalable structure with an embedded u-law bitstream, also known as PCMU, thus providing a handy transcoding operation between narrowband and wideband speech. |
|
| |
| RFC 5688 | A Session Initiation Protocol (SIP) Media Feature Tag for MIME Application Subtypes |
| |
| Authors: | J. Rosenberg. |
| Date: | January 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5688 |
|
The caller preferences specification for the Session InitiationProtocol (SIP) allows a caller to express preferences that the call be routed to a User Agent (UA) with particular capabilities.Similarly, a specification exists to allow a UA to indicate its capabilities in a registration. Amongst those capabilities are the type of media streams the agent supports, described as top-level MIME types. The 'application' MIME type is used to describe a broad range of stream types, and it provides insufficient granularity as a capability. This specification allows a UA to indicate which application subtypes the agent supports. |
|
| |
| RFC 5689 | Extended MKCOL for Web Distributed Authoring and Versioning (WebDAV) |
| |
|
|
This specification extends the Web Distributed Authoring andVersioning (WebDAV) MKCOL (Make Collection) method to allow collections of arbitrary resourcetype to be created and to allow properties to be set at the same time. |
|
| |
| RFC 5691 | RTP Payload Format for Elementary Streams with MPEG Surround Multi-Channel Audio |
| |
| Authors: | F. de Bont, S. Doehla, M. Schmidt, R. Sperschneider. |
| Date: | October 2009 |
| Formats: | txt json html |
| Updates: | RFC 3640 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5691 |
|
This memo describes extensions for the RTP payload format defined inRFC 3640 for the transport of MPEG Surround multi-channel audio.Additional Media Type parameters are defined to signal backwards- compatible transmission inside an MPEG-4 Audio elementary stream. In addition, a layered transmission scheme that doesn't use the MPEG-4 systems framework is presented to transport an MPEG Surround elementary stream via RTP in parallel with an RTP stream containing the downmixed audio data. |
|
| |
| RFC 5692 | Transmission of IP over Ethernet over IEEE 802.16 Networks |
| |
| Authors: | H. Jeon, S. Jeong, M. Riegel. |
| Date: | October 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5692 |
|
This document describes the transmission of IPv4 over Ethernet, as well as IPv6 over Ethernet, in an access network deploying the IEEE802.16 cellular radio transmission technology. The Ethernet on top of IEEE 802.16 is realized by bridging connections that IEEE 802.16 provides between a base station and its associated subscriber stations. Due to the resource constraints of radio transmission systems and the limitations of the IEEE 802.16 Media Access Control(MAC) functionality for the realization of an Ethernet, the transmission of IP over Ethernet over IEEE 802.16 may considerably benefit by adding IP-specific support functions in the Ethernet overIEEE 802.16 while maintaining full compatibility with standard IP over Ethernet behavior. |
|
| |
| RFC 5696 | Baseline Encoding and Transport of Pre-Congestion Information |
| |
| Authors: | T. Moncaster, B. Briscoe, M. Menth. |
| Date: | November 2009 |
| Formats: | txt html json |
| Obsoleted by: | RFC 6660 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5696 |
|
The objective of the Pre-Congestion Notification (PCN) architecture is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain. It achieves this by marking packets belonging toPCN-flows when the rate of traffic exceeds certain configured thresholds on links in the domain. These marks can then be evaluated to determine how close the domain is to being congested. This document specifies how such marks are encoded into the IP header by redefining the Explicit Congestion Notification (ECN) codepoints within such domains. The baseline encoding described here provides only two PCN encoding states: Not-marked and PCN-marked. Future extensions to this encoding may be needed in order to provide more than one level of marking severity. |
|
| |
| RFC 5698 | Data Structure for the Security Suitability of Cryptographic Algorithms (DSSC) |
| |
| Authors: | T. Kunz, S. Okunick, U. Pordesch. |
| Date: | November 2009 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5698 |
|
Since cryptographic algorithms can become weak over the years, it is necessary to evaluate their security suitability. When signing or verifying data, or when encrypting or decrypting data, these evaluations must be considered. This document specifies a data structure that enables an automated analysis of the security suitability of a given cryptographic algorithm at a given point of time, which may be in the past, the present, or the future. |
|
| |
| RFC 5701 | IPv6 Address Specific BGP Extended Community Attribute |
| |
|
|
Current specifications of BGP Extended Communities (RFC 4360) support the IPv4 Address Specific Extended Community, but do not support anIPv6 Address Specific Extended Community. The lack of an IPv6Address Specific Extended Community may be a problem when an application uses the IPv4 Address Specific Extended Community, and one wants to use this application in a pure IPv6 environment. This document defines a new BGP attribute, the IPv6 Address SpecificExtended Community, that addresses this problem. The IPv6 AddressSpecific Extended Community is similar to the IPv4 Address SpecificExtended Community, except that it carries an IPv6 address rather than an IPv4 address. |
|
| |
| RFC 5702 | Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC |
| |
|
|
This document describes how to produce RSA/SHA-256 and RSA/SHA-512DNSKEY and RRSIG resource records for use in the Domain Name SystemSecurity Extensions (RFC 4033, RFC 4034, and RFC 4035). |
|
| |
| RFC 5703 | Sieve Email Filtering: MIME Part Tests, Iteration, Extraction, Replacement, and Enclosure |
| |
| Authors: | T. Hansen, C. Daboo. |
| Date: | October 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5703 |
|
This document defines extensions to the Sieve email filtering language to permit analysis and manipulation of the MIME body parts of an email message. |
|
| |
| RFC 5705 | Keying Material Exporters for Transport Layer Security (TLS) |
| |
|
|
A number of protocols wish to leverage Transport Layer Security (TLS) to perform key establishment but then use some of the keying material for their own purposes. This document describes a general mechanism for allowing that. |
|
| |
| RFC 5709 | OSPFv2 HMAC-SHA Cryptographic Authentication |
| |
| Authors: | M. Bhatia, V. Manral, M. Fanto, R. White, M. Barnes, T. Li, R. Atkinson. |
| Date: | October 2009 |
| Formats: | txt json html |
| Updates: | RFC 2328 |
| Updated by: | RFC 7474 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5709 |
|
This document describes how the National Institute of Standards andTechnology (NIST) Secure Hash Standard family of algorithms can be used with OSPF version 2's built-in, cryptographic authentication mechanism. This updates, but does not supercede, the cryptographic authentication mechanism specified in RFC 2328. |
|
| |
| RFC 5710 | PathErr Message Triggered MPLS and GMPLS LSP Reroutes |
| |
| Authors: | L. Berger, D. Papadimitriou, JP. Vasseur. |
| Date: | January 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5710 |
|
This document describes how Resource ReserVation Protocol (RSVP)PathErr messages may be used to trigger rerouting of Multi-ProtocolLabel Switching (MPLS) and Generalized MPLS (GMPLS) point-to-pointTraffic Engineering (TE) Label Switched Paths (LSPs) without first removing LSP state or resources. Such LSP rerouting may be desirable in a number of cases, including, for example, soft-preemption and graceful shutdown. This document describes the usage of existingStandards Track mechanisms to support LSP rerouting. In this case, it relies on mechanisms already defined as part of RSVP-TE and simply describes a sequence of actions to be executed. While existing protocol definitions can be used to support reroute applications, this document also defines a new reroute-specific error code to allow for the future definition of reroute-application-specific error values. |
|
| |
| RFC 5711 | Node Behavior upon Originating and Receiving Resource Reservation Protocol (RSVP) Path Error Messages |
| |
| Authors: | JP. Vasseur, Ed., G. Swallow, I. Minei. |
| Date: | January 2010 |
| Formats: | txt json html |
| Updates: | RFC 3209 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5711 |
|
The aim of this document is to describe a common practice with regard to the behavior of nodes that send and receive a Resource ReservationProtocol (RSVP) Traffic Engineering (TE) Path Error messages for a preempted Multiprotocol Label Switching (MPLS) or Generalized MPLS(GMPLS) Traffic Engineering Label Switched Path (TE LSP). (For reference to the notion of TE LSP preemption, see RFC 3209.) This document does not define any new protocol extensions. |
|
| |
| RFC 5712 | MPLS Traffic Engineering Soft Preemption |
| |
| Authors: | M. Meyer, Ed., JP. Vasseur, Ed.. |
| Date: | January 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5712 |
|
This document specifies Multiprotocol Label Switching (MPLS) TrafficEngineering Soft Preemption, a suite of protocol modifications extending the concept of preemption with the goal of reducing or eliminating traffic disruption of preempted Traffic Engineering LabelSwitched Paths (TE LSPs). Initially, MPLS RSVP-TE was defined with support for only immediate TE LSP displacement upon preemption. The utilization of a reroute request notification helps more gracefully mitigate the reroute process of preempted TE LSP. For the brief period soft preemption is activated, reservations (though not necessarily traffic levels) are in effect under-provisioned until theTE LSP(s) can be rerouted. For this reason, the feature is primarily, but not exclusively, interesting in MPLS-enabled IP networks with Differentiated Services and Traffic Engineering capabilities. |
|
| |
| RFC 5717 | Partial Lock Remote Procedure Call (RPC) for NETCONF |
| |
| Authors: | B. Lengyel, M. Bjorklund. |
| Date: | December 2009 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5717 |
|
The Network Configuration protocol (NETCONF) defines the lock and unlock Remote Procedure Calls (RPCs), used to lock entire configuration datastores. In some situations, a way to lock only parts of a configuration datastore is required. This document defines a capability-based extension to the NETCONF protocol for locking portions of a configuration datastore. |
|
| |
| RFC 5718 | An In-Band Data Communication Network For the MPLS Transport Profile |
| |
| Authors: | D. Beller, A. Farrel. |
| Date: | January 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5718 |
|
The Generic Associated Channel (G-ACh) has been defined as a generalization of the pseudowire (PW) associated control channel to enable the realization of a control/communication channel that is associated with Multiprotocol Label Switching (MPLS) Label SwitchedPaths (LSPs), MPLS PWs, MPLS LSP segments, and MPLS sections between adjacent MPLS-capable devices.
The MPLS Transport Profile (MPLS-TP) is a profile of the MPLS architecture that identifies elements of the MPLS toolkit that may be combined to build a carrier-grade packet transport network based onMPLS packet switching technology.
This document describes how the G-ACh may be used to provide the infrastructure that forms part of the Management CommunicationNetwork (MCN) and a Signaling Communication Network (SCN).Collectively, the MCN and SCN may be referred to as the DataCommunication Network (DCN). This document explains how MCN and SCN messages are encapsulated, carried on the G-ACh, and demultiplexed for delivery to the management or signaling/routing control plane components on an MPLS-TP node. |
|
| |
| RFC 5719 | Updated IANA Considerations for Diameter Command Code Allocations |
| |
|
|
The Diameter base specification, described in RFC 3588, provides a number of ways to extend Diameter, with new Diameter commands (i.e., messages used by Diameter applications) and applications as the most extensive enhancements. RFC 3588 illustrates the conditions that lead to the need to define a new Diameter application or a new command code. Depending on the scope of the Diameter extension, IETF actions are necessary. Although defining new Diameter applications does not require IETF consensus, defining new Diameter commands requires IETF consensus per RFC 3588. This has led to questionable design decisions by other Standards Development Organizations, which chose to define new applications on existing commands -- rather than asking for assignment of new command codes -- for the pure purpose of avoiding bringing their specifications to the IETF. In some cases, interoperability problems were an effect of the poor design caused by overloading existing commands.
This document aligns the extensibility rules of the Diameter application with the Diameter commands, offering ways to delegate work on Diameter to other SDOs to extend Diameter in a way that does not lead to poor design choices. |
|
| |
| RFC 5722 | Handling of Overlapping IPv6 Fragments |
| |
|
|
The fragmentation and reassembly algorithm specified in the base IPv6 specification allows fragments to overlap. This document demonstrates the security issues associated with allowing overlapping fragments and updates the IPv6 specification to explicitly forbid overlapping fragments. |
|
| |
| RFC 5723 | Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption |
| |
| Authors: | Y. Sheffer, H. Tschofenig. |
| Date: | January 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5723 |
|
The Internet Key Exchange version 2 (IKEv2) protocol has a certain computational and communication overhead with respect to the number of round trips required and the cryptographic operations involved.In remote access situations, the Extensible Authentication Protocol(EAP) is used for authentication, which adds several more round trips and consequently latency.
To re-establish security associations (SAs) upon a failure recovery condition is time consuming especially when an IPsec peer (such as aVPN gateway) needs to re-establish a large number of SAs with various endpoints. A high number of concurrent sessions might cause additional problems for an IPsec peer during SA re-establishment.
In order to avoid the need to re-run the key exchange protocol from scratch, it would be useful to provide an efficient way to resume anIKE/IPsec session. This document proposes an extension to IKEv2 that allows a client to re-establish an IKE SA with a gateway in a highly efficient manner, utilizing a previously established IKE SA.
A client can reconnect to a gateway from which it was disconnected.The proposed approach encodes partial IKE state into an opaque ticket, which can be stored on the client or in a centralized store, and is later made available to the IKEv2 responder for re- authentication. We use the term ticket to refer to the opaque data that is created by the IKEv2 responder. This document does not specify the format of the ticket but examples are provided. |
|
| |
| RFC 5724 | URI Scheme for Global System for Mobile Communications (GSM) Short Message Service (SMS) |
| |
| Authors: | E. Wilde, A. Vaha-Sipila. |
| Date: | January 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5724 |
|
This memo specifies the Uniform Resource Identifier (URI) scheme"sms" for specifying one or more recipients for an SMS message. SMS messages are two-way paging messages that can be sent from and received by a mobile phone or a suitably equipped networked device. |
|
| |
| RFC 5725 | Post-Repair Loss RLE Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs) |
| |
| Authors: | A. Begen, D. Hsu, M. Lague. |
| Date: | February 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5725 |
|
This document defines a new report block type within the framework ofRTP Control Protocol (RTCP) Extended Reports (XRs). One of the initial XR report block types is the Loss Run Length Encoding (RLE)Report Block. This report conveys information regarding the individual Real-time Transport Protocol (RTP) packet receipt and loss events experienced during the RTCP interval preceding the transmission of the report. The new report, which is referred to as the Post-repair Loss RLE report, carries information regarding the packets that remain lost after all loss-repair methods are applied.By comparing the RTP packet receipts/losses before and after the loss repair is completed, one can determine the effectiveness of the loss- repair methods in an aggregated fashion. This document also defines the signaling of the Post-repair Loss RLE report in the SessionDescription Protocol (SDP). |
|
| |
| RFC 5729 | Clarifications on the Routing of Diameter Requests Based on the Username and the Realm |
| |
| Authors: | J. Korhonen, Ed., M. Jones, L. Morand, T. Tsou. |
| Date: | December 2009 |
| Formats: | txt json html |
| Updates: | RFC 3588 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5729 |
|
This specification defines the behavior required of Diameter agents to route requests when the User-Name Attribute Value Pair contains aNetwork Access Identifier formatted with multiple realms. These multi-realm, or "Decorated", Network Access Identifiers are used in order to force the routing of request messages through a predefined list of mediating realms. |
|
| |
| RFC 5740 | NACK-Oriented Reliable Multicast (NORM) Transport Protocol |
| |
| Authors: | B. Adamson, C. Bormann, M. Handley, J. Macker. |
| Date: | November 2009 |
| Formats: | txt html json |
| Obsoletes: | RFC 3940 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5740 |
|
This document describes the messages and procedures of the Negative-ACKnowledgment (NACK) Oriented Reliable Multicast (NORM) protocol.This protocol can provide end-to-end reliable transport of bulk data objects or streams over generic IP multicast routing and forwarding services. NORM uses a selective, negative acknowledgment mechanism for transport reliability and offers additional protocol mechanisms to allow for operation with minimal a priori coordination among senders and receivers. A congestion control scheme is specified to allow the NORM protocol to fairly share available network bandwidth with other transport protocols such as Transmission Control Protocol(TCP). It is capable of operating with both reciprocal multicast routing among senders and receivers and with asymmetric connectivity(possibly a unicast return path) between the senders and receivers.The protocol offers a number of features to allow different types of applications or possibly other higher-level transport protocols to utilize its service in different ways. The protocol leverages the use of FEC-based (forward error correction) repair and other IETFReliable Multicast Transport (RMT) building blocks in its design.This document obsoletes RFC 3940. |
|
| |
| RFC 5746 | Transport Layer Security (TLS) Renegotiation Indication Extension |
| |
|
|
Secure Socket Layer (SSL) and Transport Layer Security (TLS) renegotiation are vulnerable to an attack in which the attacker forms a TLS connection with the target server, injects content of his choice, and then splices in a new TLS connection from a client. The server treats the client's initial TLS handshake as a renegotiation and thus believes that the initial data transmitted by the attacker is from the same entity as the subsequent client data. This specification defines a TLS extension to cryptographically tie renegotiations to the TLS connections they are being performed over, thus preventing this attack. |
|
| |
| RFC 5749 | Distribution of EAP-Based Keys for Handover and Re-Authentication |
| |
| Authors: | K. Hoeper, Ed., M. Nakhjiri, Y. Ohba, Ed.. |
| Date: | March 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5749 |
|
This document describes an abstract mechanism for delivering root keys from an Extensible Authentication Protocol (EAP) server to another network server that requires the keys for offering security protected services, such as re-authentication, to an EAP peer. The distributed root key can be either a usage-specific root key (USRK), a domain-specific root key (DSRK), or a domain-specific usage- specific root key (DSUSRK) that has been derived from an ExtendedMaster Session Key (EMSK) hierarchy previously established between the EAP server and an EAP peer. This document defines a template for a key distribution exchange (KDE) protocol that can distribute these different types of root keys using a AAA (Authentication,Authorization, and Accounting) protocol and discusses its security requirements. The described protocol template does not specify message formats, data encoding, or other implementation details. It thus needs to be instantiated with a specific protocol (e.g., RADIUS or Diameter) before it can be used. |
|
| |
| RFC 5750 | Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Certificate Handling |
| |
|
|
This document specifies conventions for X.509 certificate usage bySecure/Multipurpose Internet Mail Extensions (S/MIME) v3.2 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 5280, theInternet X.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 5280. This document obsoletesRFC 3850. |
|
| |
| RFC 5751 | Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification |
| |
|
|
This document defines Secure/Multipurpose Internet Mail Extensions(S/MIME) version 3.2. 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 3851. |
|
| |
| RFC 5752 | Multiple Signatures in Cryptographic Message Syntax (CMS) |
| |
| Authors: | S. Turner, J. Schaad. |
| Date: | January 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5752 |
|
Cryptographic Message Syntax (CMS) SignedData includes the SignerInfo structure to convey per-signer information. SignedData supports multiple signers and multiple signature algorithms per signer with multiple SignerInfo structures. If a signer attaches more than oneSignerInfo, there are concerns that an attacker could perform a downgrade attack by removing the SignerInfo(s) with the 'strong' algorithm(s). This document defines the multiple-signatures attribute, its generation rules, and its processing rules to allow signers to convey multiple SignerInfo objects while protecting against downgrade attacks. Additionally, this attribute may assist during periods of algorithm migration. |
|
| |
| RFC 5754 | Using SHA2 Algorithms with Cryptographic Message Syntax |
| |
|
|
This document describes the conventions for using the Secure HashAlgorithm (SHA) message digest algorithms (SHA-224, SHA-256, SHA-384,SHA-512) with the Cryptographic Message Syntax (CMS). It also describes the conventions for using these algorithms with the CMS and the Digital Signature Algorithm (DSA), Rivest Shamir Adleman (RSA), and Elliptic Curve DSA (ECDSA) signature algorithms. Further, it provides SMIMECapabilities attribute values for each algorithm. |
|
| |
| RFC 5755 | An Internet Attribute Certificate Profile for Authorization |
| |
| Authors: | S. Farrell, R. Housley, S. Turner. |
| Date: | January 2010 |
| Formats: | txt html json |
| Obsoletes: | RFC 3281 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5755 |
|
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. This document obsoletes RFC 3281. |
|
| |
| RFC 5756 | Updates for RSAES-OAEP and RSASSA-PSS Algorithm Parameters |
| |
| Authors: | S. Turner, D. Brown, K. Yiu, R. Housley, T. Polk. |
| Date: | January 2010 |
| Formats: | txt json html |
| Updates: | RFC 4055 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5756 |
|
This document updates RFC 4055. It updates the conventions for using the RSA Encryption Scheme - Optimal Asymmetric Encryption Padding(RSAES-OAEP) key transport algorithm in the Internet X.509 Public KeyInfrastructure (PKI). Specifically, it updates the conventions for algorithm parameters in an X.509 certificate's subjectPublicKeyInfo field. |
|
| |
| RFC 5758 | Internet X.509 Public Key Infrastructure: Additional Algorithms and Identifiers for DSA and ECDSA |
| |
| Authors: | Q. Dang, S. Santesson, K. Moriarty, D. Brown, T. Polk. |
| Date: | January 2010 |
| Formats: | txt html json |
| Updates: | RFC 3279 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5758 |
|
This document updates RFC 3279 to specify algorithm identifiers andASN.1 encoding rules for the Digital Signature Algorithm (DSA) andElliptic Curve Digital Signature Algorithm (ECDSA) digital signatures when using SHA-224, SHA-256, SHA-384, or SHA-512 as the hashing algorithm. This specification applies to the Internet X.509 PublicKey infrastructure (PKI) when digital signatures are used to sign certificates and certificate revocation lists (CRLs). This document also identifies all four SHA2 hash algorithms for use in the InternetX.509 PKI. |
|
| |
| RFC 5760 | RTP Control Protocol (RTCP) Extensions for Single-Source Multicast Sessions with Unicast Feedback |
| |
| Authors: | J. Ott, J. Chesterfield, E. Schooler. |
| Date: | February 2010 |
| Formats: | txt html json |
| Updated by: | RFC 6128 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5760 |
|
This document specifies an extension to the Real-time TransportControl Protocol (RTCP) to use unicast feedback to a multicast sender. The proposed extension is useful for single-source multicast sessions such as Source-Specific Multicast (SSM) communication where the traditional model of many-to-many group communication is either not available or not desired. In addition, it can be applied to any group that might benefit from a sender-controlled summarized reporting mechanism. |
|
| |
| RFC 5761 | Multiplexing RTP Data and Control Packets on a Single Port |
| |
|
|
This memo discusses issues that arise when multiplexing RTP data packets and RTP Control Protocol (RTCP) packets on a single UDP port.It updates RFC 3550 and RFC 3551 to describe when such multiplexing is and is not appropriate, and it explains how the SessionDescription Protocol (SDP) can be used to signal multiplexed sessions. |
|
| |
| RFC 5762 | RTP and the Datagram Congestion Control Protocol (DCCP) |
| |
|
|
The Real-time Transport Protocol (RTP) is a widely used transport for real-time multimedia on IP networks. The Datagram Congestion ControlProtocol (DCCP) is a transport protocol that provides desirable services for real-time applications. This memo specifies a mapping of RTP onto DCCP, along with associated signalling, such that real- time applications can make use of the services provided by DCCP. |
|
| |
| RFC 5763 | Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS) |
| |
| Authors: | J. Fischl, H. Tschofenig, E. Rescorla. |
| Date: | May 2010 |
| Formats: | txt json html |
| Updated by: | RFC 8842 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5763 |
|
This document specifies how to use the Session Initiation Protocol(SIP) to establish a Secure Real-time Transport Protocol (SRTP) security context using the Datagram Transport Layer Security (DTLS) protocol. It describes a mechanism of transporting a fingerprint attribute in the Session Description Protocol (SDP) that identifies the key that will be presented during the DTLS handshake. The key exchange travels along the media path as opposed to the signaling path. The SIP Identity mechanism can be used to protect the integrity of the fingerprint attribute from modification by intermediate proxies. |
|
| |
| RFC 5764 | Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP) |
| |
|
|
This document describes a Datagram Transport Layer Security (DTLS) extension to establish keys for Secure RTP (SRTP) and Secure RTPControl Protocol (SRTCP) flows. DTLS keying happens on the media path, independent of any out-of-band signalling channel present. |
|
| |
| RFC 5766 | Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) |
| |
|
|
If a host is located behind a NAT, then in certain situations it can be impossible for that host to communicate directly with other hosts(peers). In these situations, it is necessary for the host to use the services of an intermediate node that acts as a communication relay. This specification defines a protocol, called TURN (TraversalUsing Relays around NAT), that allows the host to control the operation of the relay and to exchange packets with its peers using the relay. TURN differs from some other relay control protocols in that it allows a client to communicate with multiple peers using a single relay address.
The TURN protocol was designed to be used as part of the ICE(Interactive Connectivity Establishment) approach to NAT traversal, though it also can be used without ICE. |
|
| |
| RFC 5768 | Indicating Support for Interactive Connectivity Establishment (ICE) in the Session Initiation Protocol (SIP) |
| |
| Authors: | J. Rosenberg. |
| Date: | April 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5768 |
|
This specification defines a media feature tag and an option tag for use with the Session Initiation Protocol (SIP). The media feature tag allows a User Agent (UA) to communicate to its registrar that it supports ICE. The option tag allows a UA to require support for ICE in order for a call to proceed. |
|
| |
| RFC 5775 | Asynchronous Layered Coding (ALC) Protocol Instantiation |
| |
| Authors: | M. Luby, M. Watson, L. Vicisano. |
| Date: | April 2010 |
| Formats: | txt html json |
| Obsoletes: | RFC 3450 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5775 |
|
This document describes the Asynchronous Layered Coding (ALC) protocol, a massively scalable reliable content delivery protocol.Asynchronous Layered Coding combines the Layered Coding Transport(LCT) building block, a multiple rate congestion control building block and the Forward Error Correction (FEC) building block to provide congestion controlled reliable asynchronous delivery of content to an unlimited number of concurrent receivers from a single sender. This document obsoletes RFC 3450. |
|
| |
| RFC 5777 | Traffic Classification and Quality of Service (QoS) Attributes for Diameter |
| |
| Authors: | J. Korhonen, H. Tschofenig, M. Arumaithurai, M. Jones, Ed., A. Lior. |
| Date: | February 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5777 |
|
This document defines a number of Diameter attribute-value pairs(AVPs) for traffic classification with actions for filtering andQuality of Service (QoS) treatment. These AVPs can be used in existing and future Diameter applications where permitted by theAugmented Backus-Naur Form (ABNF) specification of the respectiveDiameter command extension policy. |
|
| |
| RFC 5778 | Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction |
| |
| Authors: | J. Korhonen, Ed., H. Tschofenig, J. Bournelle, G. Giaretta, M. Nakhjiri. |
| Date: | February 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5778 |
|
Mobile IPv6 deployments may want to bootstrap their operations dynamically based on an interaction between the home agent and theDiameter server of the Mobile Service Provider. This document specifies the interaction between a Mobile IP home agent and aDiameter server.
This document defines the home agent to the Diameter server communication when the mobile node authenticates using the InternetKey Exchange v2 protocol with the Extensible Authentication Protocol or using the Mobile IPv6 Authentication Protocol. In addition to authentication and authorization, the configuration of Mobile IPv6- specific parameters and accounting is specified in this document. |
|
| |
| RFC 5779 | Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility Anchor Interaction with Diameter Server |
| |
| Authors: | J. Korhonen, Ed., J. Bournelle, K. Chowdhury, A. Muhanna, U. Meyer. |
| Date: | February 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5779 |
|
This specification defines Authentication, Authorization, andAccounting (AAA) interactions between Proxy Mobile IPv6 entities(both Mobile Access Gateway and Local Mobility Anchor) and a AAA server within a Proxy Mobile IPv6 Domain. These AAA interactions are primarily used to download and update mobile node specific policy profile information between Proxy Mobile IPv6 entities and a remote policy store. |
|
| |
| RFC 5784 | Sieve Email Filtering: Sieves and Display Directives in XML |
| |
| Authors: | N. Freed, S. Vedam. |
| Date: | March 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5784 |
|
This document describes a way to represent Sieve email filtering language scripts in XML. Representing Sieves in XML is intended not as an alternate storage format for Sieve but rather as a means to facilitate manipulation of scripts using XML tools.
The XML representation also defines additional elements that have no counterparts in the regular Sieve language. These elements are intended for use by graphical user interfaces and provide facilities for labeling or grouping sections of a script so they can be displayed more conveniently. These elements are represented as specially structured comments in regular Sieve format. |
|
| |
| RFC 5785 | Defining Well-Known Uniform Resource Identifiers (URIs) |
| |
|
|
This memo defines a path prefix for "well-known locations","/.well-known/", in selected Uniform Resource Identifier (URI) schemes. |
|
| |
| RFC 5786 | Advertising a Router's Local Addresses in OSPF Traffic Engineering (TE) Extensions |
| |
|
|
OSPF Traffic Engineering (TE) extensions are used to advertise TELink State Advertisements (LSAs) containing information about TE- enabled links. The only addresses belonging to a router that are advertised in TE LSAs are the local addresses corresponding to TE- enabled links, and the local address corresponding to the Router ID.
In order to allow other routers in a network to compute MultiprotocolLabel Switching (MPLS) Traffic Engineered Label Switched Paths (TELSPs) to a given router's local addresses, those addresses must also be advertised by OSPF TE.
This document describes procedures that enhance OSPF TE to advertise a router's local addresses. |
|
| |
| RFC 5788 | IMAP4 Keyword Registry |
| |
| Authors: | A. Melnikov, D. Cridland. |
| Date: | March 2010 |
| Formats: | txt html json |
| Updated by: | RFC 8621 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5788 |
|
The aim of this document is to establish a new IANA registry for IMAP keywords and to define a procedure for keyword registration, in order to improve interoperability between different IMAP clients. |
|
| |
| RFC 5789 | PATCH Method for HTTP |
| |
| Authors: | L. Dusseault, J. Snell. |
| Date: | March 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5789 |
|
Several applications extending the Hypertext Transfer Protocol (HTTP) require a feature to do partial resource modification. The existingHTTP PUT method only allows a complete replacement of a document.This proposal adds a new HTTP method, PATCH, to modify an existingHTTP resource. |
|
| |
| RFC 5790 | Lightweight Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) Protocols |
| |
| Authors: | H. Liu, W. Cao, H. Asaeda. |
| Date: | February 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5790 |
|
This document describes lightweight IGMPv3 and MLDv2 protocols (LW-IGMPv3 and LW-MLDv2), which simplify the standard (full) versions ofIGMPv3 and MLDv2. The interoperability with the full versions and the previous versions of IGMP and MLD is also taken into account. |
|
| |
| RFC 5792 | PA-TNC: A Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC) |
| |
| Authors: | P. Sangster, K. Narayan. |
| Date: | March 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5792 |
|
This document specifies PA-TNC, a Posture Attribute protocol identical to the Trusted Computing Group's IF-M 1.0 protocol. The document then evaluates PA-TNC against the requirements defined in the NEA Requirements specification. |
|
| |
| RFC 5793 | PB-TNC: A Posture Broker (PB) Protocol Compatible with Trusted Network Connect (TNC) |
| |
| Authors: | R. Sahita, S. Hanna, R. Hurst, K. Narayan. |
| Date: | March 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5793 |
|
This document specifies PB-TNC, a Posture Broker protocol identical to the Trusted Computing Group's IF-TNCCS 2.0 protocol. The document then evaluates PB-TNC against the requirements defined in the NEARequirements specification. |
|
| |
| RFC 5795 | The RObust Header Compression (ROHC) Framework |
| |
| Authors: | K. Sandlund, G. Pelletier, L-E. Jonsson. |
| Date: | March 2010 |
| Formats: | txt html json |
| Obsoletes: | RFC 4995 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5795 |
|
The Robust Header Compression (ROHC) protocol provides an efficient, flexible, and future-proof header compression concept. It is designed to operate efficiently and robustly over various link technologies with different characteristics.
The ROHC framework, along with a set of compression profiles, was initially defined in RFC 3095. To improve and simplify the ROHC specifications, this document explicitly defines the ROHC framework and the profile for uncompressed separately. More specifically, the definition of the framework does not modify or update the definition of the framework specified by RFC 3095.
This specification obsoletes RFC 4995. It fixes one interoperability issue that was erroneously introduced in RFC 4995, and adds some minor clarifications. |
|
| |
| RFC 5796 | Authentication and Confidentiality in Protocol Independent Multicast Sparse Mode (PIM-SM) Link-Local Messages |
| |
| Authors: | W. Atwood, S. Islam, M. Siami. |
| Date: | March 2010 |
| Formats: | txt json html |
| Updates: | RFC 4601 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5796 |
|
RFC 4601 mandates the use of IPsec to ensure authentication of the link-local messages in the Protocol Independent Multicast - SparseMode (PIM-SM) routing protocol. This document specifies mechanisms to authenticate the PIM-SM link-local messages using the IP security(IPsec) Encapsulating Security Payload (ESP) or (optionally) theAuthentication Header (AH). It specifies optional mechanisms to provide confidentiality using the ESP. Manual keying is specified as the mandatory and default group key management solution. To deal with issues of scalability and security that exist with manual keying, optional support for an automated group key management mechanism is provided. However, the procedures for implementing automated group key management are left to other documents. This document updates RFC 4601. |
|
| |
| RFC 5797 | FTP Command and Extension Registry |
| |
|
|
Every version of the FTP specification has added a few new commands, with the early ones summarized in RFC 959. RFC 2389 established a mechanism for specifying and negotiating FTP extensions. The number of extensions, both those supported by the mechanism and some that are not, continues to increase. An IANA registry of FTP Command andFeature names is established to reduce the likelihood of conflict of names and the consequent ambiguity. This specification establishes that registry. |
|
| |
| RFC 5798 | Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6 |
| |
|
|
This memo defines the Virtual Router Redundancy Protocol (VRRP) forIPv4 and IPv6. It is version three (3) of the protocol, and it is based on VRRP (version 2) for IPv4 that is defined in RFC 3768 and in"Virtual Router Redundancy Protocol for IPv6". VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. The VRRP router controlling the IPv4 or IPv6 address(es) associated with a virtual router is called the Master, and it forwards packets sent to theseIPv4 or IPv6 addresses. VRRP Master routers are configured with virtual IPv4 or IPv6 addresses, and VRRP Backup routers infer the address family of the virtual addresses being carried based on the transport protocol. Within a VRRP router, the virtual routers in each of the IPv4 and IPv6 address families are a domain unto themselves and do not overlap. The election process provides dynamic failover in the forwarding responsibility should the Master become unavailable. For IPv4, 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. ForIPv6, the advantage gained from using VRRP for IPv6 is a quicker switchover to Backup routers than can be obtained with standard IPv6Neighbor Discovery mechanisms. |
|
| |
| RFC 5801 | Using Generic Security Service Application Program Interface (GSS-API) Mechanisms in Simple Authentication and Security Layer (SASL): The GS2 Mechanism Family |
| |
| Authors: | S. Josefsson, N. Williams. |
| Date: | July 2010 |
| Formats: | txt json html |
| Updated by: | RFC 9266 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5801 |
|
This document describes how to use a Generic Security ServiceApplication Program Interface (GSS-API) mechanism in the SimpleAuthentication and Security Layer (SASL) framework. This is done by defining a new SASL mechanism family, called GS2. This mechanism family offers a number of improvements over the previous "SASL/GSSAPI" mechanism: it is more general, uses fewer messages for the authentication phase in some cases, and supports negotiable use of channel binding. Only GSS-API mechanisms that support channel binding and mutual authentication are supported. |
|
| |
| RFC 5802 | Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms |
| |
|
|
The secure authentication mechanism most widely deployed and used byInternet application protocols is the transmission of clear-text passwords over a channel protected by Transport Layer Security (TLS).There are some significant security concerns with that mechanism, which could be addressed by the use of a challenge response authentication mechanism protected by TLS. Unfortunately, the challenge response mechanisms presently on the standards track all fail to meet requirements necessary for widespread deployment, and have had success only in limited use.
This specification describes a family of Simple Authentication andSecurity Layer (SASL; RFC 4422) authentication mechanisms called theSalted Challenge Response Authentication Mechanism (SCRAM), which addresses the security concerns and meets the deployability requirements. When used in combination with TLS or an equivalent security layer, a mechanism from this family could improve the status quo for application protocol authentication and provide a suitable choice for a mandatory-to-implement mechanism for future application protocol standards. |
|
| |
| RFC 5804 | A Protocol for Remotely Managing Sieve Scripts |
| |
|
|
Sieve scripts allow users to filter incoming email. Message stores are commonly sealed servers so users cannot log into them, yet users must be able to update their scripts on them. This document describes a protocol "ManageSieve" for securely managing Sieve scripts on a remote server. This protocol allows a user to have multiple scripts, and also alerts a user to syntactically flawed scripts. |
|
| |
| RFC 5807 | Definition of Master Key between PANA Client and Enforcement Point |
| |
| Authors: | Y. Ohba, A. Yegin. |
| Date: | March 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5807 |
|
This document defines a master key used between a client of theProtocol for carrying Authentication for Network Access (PANA) and an enforcement point, for bootstrapping lower-layer ciphering. The master key is derived from the Master Session Key of the ExtensibleAuthentication Protocol as a result of successful PANA authentication. The master key guarantees cryptographic independence among enforcement points bootstrapped from PANA authentication across different address families. |
|
| |
| RFC 5810 | Forwarding and Control Element Separation (ForCES) Protocol Specification |
| |
| Authors: | A. Doria, Ed., J. Hadi Salim, Ed., R. Haas, Ed., H. Khosravi, Ed., W. Wang, Ed., L. Dong, R. Gopal, J. Halpern. |
| Date: | March 2010 |
| Formats: | txt json html |
| Updated by: | RFC 7121, RFC 7391 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5810 |
|
This document specifies the Forwarding and Control Element Separation(ForCES) protocol. The ForCES protocol is used for communications between Control Elements(CEs) and Forwarding Elements (FEs) in aForCES Network Element (ForCES NE). This specification is intended to meet the ForCES protocol requirements defined in RFC 3654.Besides the ForCES protocol, this specification also defines the requirements for the Transport Mapping Layer (TML). |
|
| |
| RFC 5811 | SCTP-Based Transport Mapping Layer (TML) for the Forwarding and Control Element Separation (ForCES) Protocol |
| |
| Authors: | J. Hadi Salim, K. Ogawa. |
| Date: | March 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5811 |
|
This document defines the SCTP-based TML (Transport Mapping Layer) for the ForCES (Forwarding and Control Element Separation) protocol.It explains the rationale for choosing the SCTP (Stream ControlTransmission Protocol) and also describes how this TML addresses all the requirements required by and the ForCES protocol. |
|
| |
| RFC 5812 | Forwarding and Control Element Separation (ForCES) Forwarding Element Model |
| |
| Authors: | J. Halpern, J. Hadi Salim. |
| Date: | March 2010 |
| Formats: | txt html json |
| Updated by: | RFC 7408 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5812 |
|
This document defines the forwarding element (FE) model used in theForwarding and Control Element Separation (ForCES) protocol. The model represents the capabilities, state, and configuration of forwarding elements within the context of the ForCES protocol, so that control elements (CEs) can control the FEs accordingly. More specifically, the model describes the logical functions that are present in an FE, what capabilities these functions support, and how these functions are or can be interconnected. This FE model is intended to satisfy the model requirements specified in RFC 3654. |
|
| |
| RFC 5813 | Forwarding and Control Element Separation (ForCES) MIB |
| |
| Authors: | R. Haas. |
| Date: | March 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5813 |
|
This memo defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it defines managed objects for the Forwarding and ControlElement Separation (ForCES) Network Element (NE). |
|
| |
| RFC 5814 | Label Switched Path (LSP) Dynamic Provisioning Performance Metrics in Generalized MPLS Networks |
| |
| Authors: | W. Sun, Ed., G. Zhang, Ed.. |
| Date: | March 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5814 |
|
Generalized Multi-Protocol Label Switching (GMPLS) is one of the most promising candidate technologies for a future data transmission network. GMPLS has been developed to control and operate different kinds of network elements, such as conventional routers, switches,Dense Wavelength Division Multiplexing (DWDM) systems, Add-DropMultiplexers (ADMs), photonic cross-connects (PXCs), optical cross- connects (OXCs), etc. These physically diverse devices differ drastically from one another in dynamic provisioning ability. At the same time, the need for dynamically provisioned connections is increasing because optical networks are being deployed in metro areas. As different applications have varied requirements in the provisioning performance of optical networks, it is imperative to define standardized metrics and procedures such that the performance of networks and application needs can be mapped to each other.
This document provides a series of performance metrics to evaluate the dynamic Label Switched Path (LSP) provisioning performance inGMPLS networks, specifically the dynamic LSP setup/release performance. These metrics can be used to characterize the features of GMPLS networks in LSP dynamic provisioning. |
|
| |
| RFC 5815 | Definitions of Managed Objects for IP Flow Information Export |
| |
| Authors: | T. Dietz, Ed., A. Kobayashi, B. Claise, G. Muenz. |
| Date: | April 2010 |
| Formats: | txt json html |
| Obsoleted by: | RFC 6615 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5815 |
|
This document defines managed objects for IP Flow Information eXport(IPFIX). These objects provide information for monitoring IPFIXExporters and IPFIX Collectors including the basic configuration information. |
|
| |
| RFC 5816 | ESSCertIDv2 Update for RFC 3161 |
| |
|
|
This document updates RFC 3161. It allows the use of ESSCertIDv2, as defined in RFC 5035, to specify the hash of a signer certificate when the hash is calculated with a function other than the Secure HashAlgorithm (SHA-1). |
|
| |
| RFC 5818 | Data Channel Status Confirmation Extensions for the Link Management Protocol |
| |
| Authors: | D. Li, H. Xu, S. Bardalai, J. Meuric, D. Caviglia. |
| Date: | April 2010 |
| Formats: | txt json html |
| Updated by: | RFC 6898 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5818 |
|
This document defines simple additions to the Link ManagementProtocol (LMP) to provide a control plane tool that can assist in the location of stranded resources by allowing adjacent Label-SwitchingRouters (LSRs) to confirm data channel statuses and provide triggers for notifying the management plane if any discrepancies are found.As LMP is already used to verify data plane connectivity, it is considered to be an appropriate candidate to support this feature. |
|
| |
| RFC 5819 | IMAP4 Extension for Returning STATUS Information in Extended LIST |
| |
| Authors: | A. Melnikov, T. Sirainen. |
| Date: | March 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5819 |
|
Many IMAP clients display information about total number of messages / total number of unseen messages in IMAP mailboxes. In order to do that, they are forced to issue a LIST or LSUB command and to list all available mailboxes, followed by a STATUS command for each mailbox found. This document provides an extension to LIST command that allows the client to request STATUS information for mailboxes together with other information typically returned by theLIST command. |
|
| |
| RFC 5837 | Extending ICMP for Interface and Next-Hop Identification |
| |
| Authors: | A. Atlas, Ed., R. Bonica, Ed., C. Pignataro, Ed., N. Shen, JR. Rivers. |
| Date: | April 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5837 |
|
This memo defines a data structure that can be appended to selectedICMP messages. The ICMP extension defined herein can be used to identify any combination of the following: the IP interface upon which a datagram arrived, the sub-IP component of an IP interface upon which a datagram arrived, the IP interface through which the datagram would have been forwarded had it been forwardable, and theIP next hop to which the datagram would have been forwarded.
Devices can use this ICMP extension to identify interfaces and their components by any combination of the following: ifIndex, IPv4 address, IPv6 address, name, and MTU. ICMP-aware devices can use these extensions to identify both numbered and unnumbered interfaces. |
|
| |
| RFC 5838 | Support of Address Families in OSPFv3 |
| |
|
|
This document describes a mechanism for supporting multiple address families (AFs) in OSPFv3 using multiple instances. It maps an AF to an OSPFv3 instance using the Instance ID field in the OSPFv3 packet header. This approach is fairly simple and minimizes extensions toOSPFv3 for supporting multiple AFs. |
|
| |
| RFC 5839 | An Extension to Session Initiation Protocol (SIP) Events for Conditional Event Notification |
| |
| Authors: | A. Niemi, D. Willis, Ed.. |
| Date: | May 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5839 |
|
The Session Initiation Protocol (SIP) events framework enables receiving asynchronous notification of various events from other SIP user agents. This framework defines the procedures for creating, refreshing, and terminating subscriptions, as well as fetching and periodic polling of resource state. These procedures provide no tools to avoid replaying event notifications that have already been received by a user agent. This memo defines an extension to SIP events that allows the subscriber to condition the subscription request to whether the state has changed since the previous notification was received. When such a condition is true, either the body of a resulting event notification or the entire notification message is suppressed. |
|
| |
| RFC 5840 | Wrapped Encapsulating Security Payload (ESP) for Traffic Visibility |
| |
| Authors: | K. Grewal, G. Montenegro, M. Bhatia. |
| Date: | April 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5840 |
|
This document describes the Wrapped Encapsulating Security Payload(WESP) protocol, which builds on the Encapsulating Security Payload(ESP) RFC 4303 and is designed to allow intermediate devices to (1) ascertain if data confidentiality is being employed within ESP, and if not, (2) inspect the IPsec packets for network monitoring and access control functions. Currently, in the IPsec ESP standard, there is no deterministic way to differentiate between encrypted and unencrypted payloads by simply examining a packet. This poses certain challenges to the intermediate devices that need to deep inspect the packet before making a decision on what should be done with that packet (Inspect and/or Allow/Drop). The mechanism described in this document can be used to easily disambiguate integrity-only ESP from ESP-encrypted packets, without compromising on the security provided by ESP. |
|
| |
| RFC 5844 | IPv4 Support for Proxy Mobile IPv6 |
| |
| Authors: | R. Wakikawa, S. Gundavelli. |
| Date: | May 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5844 |
|
This document specifies extensions to the Proxy Mobile IPv6 protocol for adding IPv4 protocol support. The scope of IPv4 protocol support is two-fold: 1) enable IPv4 home address mobility support to the mobile node, and 2) allow the mobility entities in the Proxy MobileIPv6 domain to exchange signaling messages over an IPv4 transport network. |
|
| |
| RFC 5845 | Generic Routing Encapsulation (GRE) Key Option for Proxy Mobile IPv6 |
| |
| Authors: | A. Muhanna, M. Khalil, S. Gundavelli, K. Leung. |
| Date: | June 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5845 |
|
This specification defines a new mobility option for allowing the mobile access gateway and the local mobility anchor to negotiateGeneric Routing Encapsulation (GRE) encapsulation mode and exchange the downlink and uplink GRE keys that are used for marking the downlink and uplink traffic that belong to a specific mobility session. In addition, the same mobility option can be used to negotiate the GRE encapsulation mode without exchanging the GRE keys. |
|
| |
| RFC 5846 | Binding Revocation for IPv6 Mobility |
| |
| Authors: | A. Muhanna, M. Khalil, S. Gundavelli, K. Chowdhury, P. Yegani. |
| Date: | June 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5846 |
|
This document defines a binding revocation mechanism to terminate a mobile node's mobility session and the associated resources. This mechanism can be used both with base Mobile IPv6 and its extensions, such as Proxy Mobile IPv6. The mechanism allows the mobility entity which initiates the revocation procedure to request its peer to terminate either one, multiple or all specified Binding Cache entries. |
|
| |
| RFC 5847 | Heartbeat Mechanism for Proxy Mobile IPv6 |
| |
| Authors: | V. Devarapalli, Ed., R. Koodli, Ed., H. Lim, N. Kant, S. Krishnan, J. Laganier. |
| Date: | June 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5847 |
|
Proxy Mobile IPv6 (PMIPv6) is a network-based mobility management protocol. The mobility entities involved in the Proxy Mobile IPv6 protocol, the mobile access gateway (MAG) and the local mobility anchor (LMA), set up tunnels dynamically to manage mobility for a mobile node within the Proxy Mobile IPv6 domain. This document describes a heartbeat mechanism between the MAG and the LMA to detect failures, quickly inform peers in the event of a recovery from node failures, and allow a peer to take appropriate action. |
|
| |
| RFC 5848 | Signed Syslog Messages |
| |
| Authors: | J. Kelsey, J. Callas, A. Clemm. |
| Date: | May 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5848 |
|
This document describes a mechanism to add origin authentication, message integrity, replay resistance, message sequencing, and detection of missing messages to the transmitted syslog messages.This specification is intended to be used in conjunction with the work defined in RFC 5424, "The Syslog Protocol". |
|
| |
| RFC 5852 | RSVP-TE Signaling Extension for LSP Handover from the Management Plane to the Control Plane in a GMPLS-Enabled Transport Network |
| |
| Authors: | D. Caviglia, D. Ceccarelli, D. Bramanti, D. Li, S. Bardalai. |
| Date: | April 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5852 |
|
In a transport network scenario, Data Plane connections controlled by either a Generalized Multiprotocol Label Switching (GMPLS) ControlPlane (Soft Permanent Connections - SPC) or a Management System(Permanent Connections - PC) may independently coexist. The ability of transforming an existing PC into an SPC and vice versa -- without actually affecting Data Plane traffic being carried over it -- is a requirement. The requirements for the conversion between permanent connections and switched connections in a GMPLS Network are defined in RFC 5493.
This memo describes an extension to GMPLS Resource ReservationProtocol - Traffic Engineering (RSVP-TE) signaling that enables the transfer of connection ownership between the Management and theControl Planes. Such a transfer is referred to as a Handover. This document defines all Handover-related procedures. This includes the handling of failure conditions and subsequent reversion to original state. A basic premise of the extension is that the Handover procedures must never impact an already established Data Plane connection. |
|
| |
| RFC 5854 | The Metalink Download Description Format |
| |
| Authors: | A. Bryan, T. Tsujikawa, N. McNab, P. Poeml. |
| Date: | June 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5854 |
|
This document specifies Metalink, an XML-based download description format. Metalink describes download locations (mirrors), cryptographic hashes, and other information. Clients can transparently use this information to reliably transfer files. |
|
| |
| RFC 5857 | IKEv2 Extensions to Support Robust Header Compression over IPsec |
| |
| Authors: | E. Ertekin, C. Christou, R. Jasani, T. Kivinen, C. Bormann. |
| Date: | May 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5857 |
|
In order to integrate Robust Header Compression (ROHC) with IPsec, a mechanism is needed to signal ROHC channel parameters between endpoints. Internet Key Exchange (IKE) is a mechanism that can be leveraged to exchange these parameters. This document specifies extensions to IKEv2 that will allow ROHC and its associated channel parameters to be signaled for IPsec Security Associations (SAs). |
|
| |
| RFC 5858 | IPsec Extensions to Support Robust Header Compression over IPsec |
| |
| Authors: | E. Ertekin, C. Christou, C. Bormann. |
| Date: | May 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5858 |
|
Integrating Robust Header Compression (ROHC) with IPsec (ROHCoIPsec) offers the combined benefits of IP security services and efficient bandwidth utilization. However, in order to integrate ROHC withIPsec, extensions to the Security Policy Database (SPD) and SecurityAssociation Database (SAD) are required. This document describes theIPsec extensions required to support ROHCoIPsec. |
|
| |
| RFC 5860 | Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks |
| |
| Authors: | M. Vigoureux, Ed., D. Ward, Ed., M. Betts, Ed.. |
| Date: | May 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5860 |
|
This document lists architectural and functional requirements for theOperations, Administration, and Maintenance of MPLS TransportProfile. These requirements apply to pseudowires, Label SwitchedPaths, and Sections. |
|
| |
| RFC 5864 | DNS SRV Resource Records for AFS |
| |
|
|
This document specifies how to use DNS (Domain Name Service) SRV RRs(Resource Records) to locate services for the AFS distributed file system and how the priority and weight values of the SRV RR should be interpreted in the server ranking system used by AFS. It updates RFC1183 to deprecate the use of the AFSDB RR to locate AFS cell database servers and provides guidance for backward compatibility. |
|
| |
| RFC 5865 | A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic |
| |
|
|
This document requests one Differentiated Services Code Point (DSCP) from the Internet Assigned Numbers Authority (IANA) for a class of real-time traffic. This traffic class conforms to the ExpeditedForwarding Per-Hop Behavior. This traffic is also admitted by the network using a Call Admission Control (CAC) procedure involving authentication, authorization, and capacity admission. This differs from a real-time traffic class that conforms to the ExpeditedForwarding Per-Hop Behavior but is not subject to capacity admission or subject to very coarse capacity admission. |
|
| |
| RFC 5866 | Diameter Quality-of-Service Application |
| |
| Authors: | D. Sun, Ed., P. McCann, H. Tschofenig, T. Tsou, A. Doria, G. Zorn, Ed.. |
| Date: | May 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5866 |
|
This document describes the framework, messages, and procedures for the Diameter Quality-of-Service (QoS) application. The Diameter QoS application allows network elements to interact with Diameter servers when allocating QoS resources in the network. In particular, two modes of operation, namely "Pull" and "Push", are defined. |
|
| |
| RFC 5870 | A Uniform Resource Identifier for Geographic Locations ('geo' URI) |
| |
| Authors: | A. Mayrhofer, C. Spanring. |
| Date: | June 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5870 |
|
This document specifies a Uniform Resource Identifier (URI) for geographic locations using the 'geo' scheme name. A 'geo' URI identifies a physical location in a two- or three-dimensional coordinate reference system in a compact, simple, human-readable, and protocol-independent way. The default coordinate reference system used is the World Geodetic System 1984 (WGS-84). |
|
| |
| RFC 5871 | IANA Allocation Guidelines for the IPv6 Routing Header |
| |
|
|
This document specifies the IANA guidelines for allocating new values for the Routing Type field in the IPv6 Routing Header. |
|
| |
| RFC 5872 | IANA Rules for the Protocol for Carrying Authentication for Network Access (PANA) |
| |
|
|
This document relaxes the IANA rules for the Protocol for CarryingAuthentication for Network Access (PANA). |
|
| |
| RFC 5874 | An Extensible Markup Language (XML) Document Format for Indicating a Change in XML Configuration Access Protocol (XCAP) Resources |
| |
| Authors: | J. Rosenberg, J. Urpalainen. |
| Date: | May 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5874 |
|
This specification defines a document format that can be used to indicate that a change has occurred in a document managed by theExtensible Markup Language (XML) Configuration Access Protocol(XCAP). This format reports which document has changed and its former and new entity tags. It can report the differences between versions of the document, using an XML patch format. It can report existing element and attribute content when versions of an XCAP server document change. XCAP diff documents can be delivered to diff clients using a number of means, including a Session InitiationProtocol (SIP) event package. |
|
| |
| RFC 5875 | An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Diff Event Package |
| |
| Authors: | J. Urpalainen, D. Willis, Ed.. |
| Date: | May 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5875 |
|
This document describes an "xcap-diff" SIP (Session InitiationProtocol) event package for the SIP Event Notification Framework, which clients can use to receive notifications of changes toExtensible Markup Language (XML) Configuration Access Protocol (XCAP) resources. The initial synchronization information exchange and document updates are based on the XCAP Diff format. |
|
| |
| RFC 5880 | Bidirectional Forwarding Detection (BFD) |
| |
|
|
This document describes a protocol intended to detect faults in the bidirectional path between two forwarding engines, including interfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. It operates independently of media, data protocols, and routing protocols. |
|
| |
| RFC 5881 | Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop) |
| |
| Authors: | D. Katz, D. Ward. |
| Date: | June 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5881 |
|
This document describes the use of the Bidirectional ForwardingDetection (BFD) protocol over IPv4 and IPv6 for single IP hops. |
|
| |
| RFC 5882 | Generic Application of Bidirectional Forwarding Detection (BFD) |
| |
| Authors: | D. Katz, D. Ward. |
| Date: | June 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5882 |
|
This document describes the generic application of the BidirectionalForwarding Detection (BFD) protocol. |
|
| |
| RFC 5883 | Bidirectional Forwarding Detection (BFD) for Multihop Paths |
| |
| Authors: | D. Katz, D. Ward. |
| Date: | June 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5883 |
|
This document describes the use of the Bidirectional ForwardingDetection (BFD) protocol over multihop paths, including unidirectional links. |
|
| |
| RFC 5884 | Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs) |
| |
| Authors: | R. Aggarwal, K. Kompella, T. Nadeau, G. Swallow. |
| Date: | June 2010 |
| Formats: | txt html json |
| Updates: | RFC 1122 |
| Updated by: | RFC 7726 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5884 |
|
One desirable application of Bidirectional Forwarding Detection (BFD) is to detect a Multiprotocol Label Switching (MPLS) Label SwitchedPath (LSP) data plane failure. LSP Ping is an existing mechanism for detecting MPLS data plane failures and for verifying the MPLS LSP data plane against the control plane. BFD can be used for the former, but not for the latter. However, the control plane processing required for BFD Control packets is relatively smaller than the processing required for LSP Ping messages. A combination ofLSP Ping and BFD can be used to provide faster data plane failure detection and/or make it possible to provide such detection on a greater number of LSPs. This document describes the applicability ofBFD in relation to LSP Ping for this application. It also describes procedures for using BFD in this environment. |
|
| |
| RFC 5885 | Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV) |
| |
|
|
This document describes Connectivity Verification (CV) Types usingBidirectional Forwarding Detection (BFD) with Virtual CircuitConnectivity Verification (VCCV). VCCV provides a control channel that is associated with a pseudowire (PW), as well as the corresponding operations and management functions such as connectivity verification to be used over that control channel. |
|
| |
| RFC 5886 | A Set of Monitoring Tools for Path Computation Element (PCE)-Based Architecture |
| |
| Authors: | JP. Vasseur, Ed., JL. Le Roux, Y. Ikejiri. |
| Date: | June 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5886 |
|
A Path Computation Element (PCE)-based architecture has been specified for the computation of Traffic Engineering (TE) LabelSwitched Paths (LSPs) in Multiprotocol Label Switching (MPLS) andGeneralized MPLS (GMPLS) networks in the context of single or multiple domains (where a domain refers to a collection of network elements within a common sphere of address management or path computational responsibility such as Interior Gateway Protocol (IGP) areas and Autonomous Systems). Path Computation Clients (PCCs) send computation requests to PCEs, and these may forward the requests to and cooperate with other PCEs forming a "path computation chain".
In PCE-based environments, it is thus critical to monitor the state of the path computation chain for troubleshooting and performance monitoring purposes: liveness of each element (PCE) involved in thePCE chain and detection of potential resource contention states and statistics in terms of path computation times are examples of such metrics of interest. This document specifies procedures and extensions to the Path Computation Element Protocol (PCEP) in order to gather such information. |
|
| |
| RFC 5888 | The Session Description Protocol (SDP) Grouping Framework |
| |
|
|
In this specification, we define a framework to group "m" lines in the Session Description Protocol (SDP) for different purposes. This framework uses the "group" and "mid" SDP attributes, both of which are defined in this specification. Additionally, we specify how to use the framework for two different purposes: for lip synchronization and for receiving a media flow consisting of several media streams on different transport addresses. This document obsoletes RFC 3388. |
|
| |
| RFC 5890 | Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework |
| |
|
|
This document is one of a collection that, together, describe the protocol and usage context for a revision of Internationalized DomainNames for Applications (IDNA), superseding the earlier version. It describes the document collection and provides definitions and other material that are common to the set. |
|
| |
| RFC 5891 | Internationalized Domain Names in Applications (IDNA): Protocol |
| |
|
|
This document is the revised protocol definition forInternationalized Domain Names (IDNs). The rationale for changes, the relationship to the older specification, and important terminology are provided in other documents. This document specifies the protocol mechanism, called Internationalized Domain Names inApplications (IDNA), for registering and looking up IDNs in a way that does not require changes to the DNS itself. IDNA is only meant for processing domain names, not free text. |
|
| |
| RFC 5892 | The Unicode Code Points and Internationalized Domain Names for Applications (IDNA) |
| |
|
|
This document specifies rules for deciding whether a code point, considered in isolation or in context, is a candidate for inclusion in an Internationalized Domain Name (IDN).
It is part of the specification of Internationalizing Domain Names inApplications 2008 (IDNA2008). |
|
| |
| RFC 5893 | Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA) |
| |
| Authors: | H. Alvestrand, Ed., C. Karp. |
| Date: | August 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5893 |
|
The use of right-to-left scripts in Internationalized Domain Names(IDNs) has presented several challenges. This memo provides a newBidi rule for Internationalized Domain Names for Applications (IDNA) labels, based on the encountered problems with some scripts and some shortcomings in the 2003 IDNA Bidi criterion. |
|
| |
| RFC 5896 | Generic Security Service Application Program Interface (GSS-API): Delegate if Approved by Policy |
| |
|
|
Several Generic Security Service Application Program Interface(GSS-API) applications work in a multi-tiered architecture, where the server takes advantage of delegated user credentials to act on behalf of the user and contact additional servers. In effect, the server acts as an agent on behalf of the user. Examples include web applications that need to access e-mail or file servers, includingCIFS (Common Internet File System) file servers. However, delegating the user credentials to a party who is not sufficiently trusted is problematic from a security standpoint. Kerberos provides a flag called OK-AS-DELEGATE that allows the administrator of a Kerberos realm to communicate that a particular service is trusted for delegation. This specification adds support for this flag and similar facilities in other authentication mechanisms to GSS-API (RFC2743). |
|
| |
| RFC 5898 | Connectivity Preconditions for Session Description Protocol (SDP) Media Streams |
| |
| Authors: | F. Andreasen, G. Camarillo, D. Oran, D. Wing. |
| Date: | July 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5898 |
|
This document defines a new connectivity precondition for the SessionDescription Protocol (SDP) precondition framework. A connectivity precondition can be used to delay session establishment or modification until media stream connectivity has been successfully verified. The method of verification may vary depending on the type of transport used for the media. For unreliable datagram transports such as UDP, verification involves probing the stream with data or control packets. For reliable connection-oriented transports such asTCP, verification can be achieved simply by successful connection establishment or by probing the connection with data or control packets, depending on the situation. |
|
| |
| RFC 5901 | Extensions to the IODEF-Document Class for Reporting Phishing |
| |
| Authors: | P. Cain, D. Jevans. |
| Date: | July 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5901 |
|
This document extends the Incident Object Description Exchange Format(IODEF) defined in RFC 5070 to support the reporting of phishing events, which is a particular type of fraud. These extensions are flexible enough to support information gleaned from activities throughout the entire electronic fraud cycle -- from receipt of the phishing lure to the disablement of the collection site. Both simple reporting and complete forensic reporting are possible, as is consolidating multiple incidents. |
|
| |
| RFC 5905 | Network Time Protocol Version 4: Protocol and Algorithms Specification |
| |
|
|
The Network Time Protocol (NTP) is widely used to synchronize computer clocks in the Internet. This document describes NTP version4 (NTPv4), which is backwards compatible with NTP version 3 (NTPv3), described in RFC 1305, as well as previous versions of the protocol.NTPv4 includes a modified protocol header to accommodate the InternetProtocol version 6 address family. NTPv4 includes fundamental improvements in the mitigation and discipline algorithms that extend the potential accuracy to the tens of microseconds with modern workstations and fast LANs. It includes a dynamic server discovery scheme, so that in many cases, specific server configuration is not required. It corrects certain errors in the NTPv3 design and implementation and includes an optional extension mechanism. |
|
| |
| RFC 5907 | Definitions of Managed Objects for Network Time Protocol Version 4 (NTPv4) |
| |
| Authors: | H. Gerstung, C. Elliott, B. Haberman, Ed.. |
| Date: | June 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5907 |
|
The Network Time Protocol (NTP) is used in networks of all types and sizes for time synchronization of servers, workstations, and other networked equipment. As time synchronization is more and more a mission-critical service, standardized means for monitoring and management of this subsystem of a networked host are required to allow operators of such a service to set up a monitoring system that is platform- and vendor-independent. This document provides a standardized collection of data objects for monitoring the NTP entity of such a network participant and it is part of the NTP version 4 standardization effort. |
|
| |
| RFC 5908 | Network Time Protocol (NTP) Server Option for DHCPv6 |
| |
| Authors: | R. Gayraud, B. Lourdelet. |
| Date: | June 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5908 |
|
The NTP Server Option for Dynamic Host Configuration Protocol forIPv6 (DHCPv6) provides NTPv4 (Network Time Protocol version 4) server location information to DHCPv6 hosts. |
|
| |
| RFC 5910 | Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP) |
| |
|
|
This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of Domain NameSystem security (DNSSEC) extensions 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. This document obsoletes RFC 4310. |
|
| |
| RFC 5913 | Clearance Attribute and Authority Clearance Constraints Certificate Extension |
| |
| Authors: | S. Turner, S. Chokhani. |
| Date: | June 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5913 |
|
This document defines the syntax and semantics for the Clearance attribute and the Authority Clearance Constraints extension in X.509 certificates. The Clearance attribute is used to indicate the clearance held by the subject. The Clearance attribute may appear in the subject directory attributes extension of a public key certificate or in the attributes field of an attribute certificate.The Authority Clearance Constraints certificate extension values in aTrust Anchor (TA), in Certification Authority (CA) public key certificates, and in an Attribute Authority (AA) public key certificate in a certification path for a given subject constrain the effective Clearance of the subject. |
|
| |
| RFC 5914 | Trust Anchor Format |
| |
| Authors: | R. Housley, S. Ashmore, C. Wallace. |
| Date: | June 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5914 |
|
This document describes a structure for representing trust anchor information. A trust anchor is an authoritative entity represented by a public key and associated data. The public key is used to verify digital signatures, and the associated data is used to constrain the types of information or actions for which the trust anchor is authoritative. The structures defined in this document are intended to satisfy the format-related requirements defined in TrustAnchor Management Requirements. |
|
| |
| RFC 5918 | Label Distribution Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class (FEC) |
| |
| Authors: | R. Asati, I. Minei, B. Thomas. |
| Date: | August 2010 |
| Formats: | txt html json |
| Updated by: | RFC 7358 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5918 |
|
The Label Distribution Protocol (LDP) specification for the WildcardForward Equivalence Class (FEC) element has several limitations.This document addresses those limitations by defining a TypedWildcard FEC Element and associated procedures. In addition, it defines a new LDP capability to address backward compatibility. |
|
| |
| RFC 5919 | Signaling LDP Label Advertisement Completion |
| |
| Authors: | R. Asati, P. Mohapatra, E. Chen, B. Thomas. |
| Date: | August 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5919 |
|
There are situations following Label Distribution Protocol (LDP) session establishment where it would be useful for an LDP speaker to know when its peer has advertised all of its labels. The LDP specification provides no mechanism for an LDP speaker to notify a peer when it has completed its initial label advertisements to that peer. This document specifies means for an LDP speaker to signal completion of its initial label advertisements following session establishment. |
|
| |
| RFC 5922 | Domain Certificates in the Session Initiation Protocol (SIP) |
| |
| Authors: | V. Gurbani, S. Lawrence, A. Jeffrey. |
| Date: | June 2010 |
| Formats: | txt json html |
| Updates: | RFC 3261 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5922 |
|
This document describes how to construct and interpret certain information in a PKIX-compliant (Public Key Infrastructure usingX.509) certificate for use in a Session Initiation Protocol (SIP) over Transport Layer Security (TLS) connection. More specifically, this document describes how to encode and extract the identity of aSIP domain in a certificate and how to use that identity for SIP domain authentication. As such, this document is relevant both to implementors of SIP and to issuers of certificates. |
|
| |
| RFC 5923 | Connection Reuse in the Session Initiation Protocol (SIP) |
| |
| Authors: | V. Gurbani, Ed., R. Mahy, B. Tate. |
| Date: | June 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5923 |
|
This document enables a pair of communicating proxies to reuse a congestion-controlled connection between themselves for sending requests in the forwards and backwards direction. Because the connection is essentially aliased for requests going in the backwards direction, reuse is predicated upon both the communicating endpoints authenticating themselves using X.509 certificates through TransportLayer Security (TLS). For this reason, we only consider connection reuse for TLS over TCP and TLS over Stream Control TransmissionProtocol (SCTP). This document also provides guidelines on connection reuse and virtual SIP servers and the interaction of connection reuse and DNS SRV lookups in SIP. |
|
| |
| RFC 5925 | The TCP Authentication Option |
| |
| Authors: | J. Touch, A. Mankin, R. Bonica. |
| Date: | June 2010 |
| Formats: | txt html json |
| Obsoletes: | RFC 2385 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5925 |
|
This document specifies the TCP Authentication Option (TCP-AO), which obsoletes the TCP MD5 Signature option of RFC 2385 (TCP MD5). TCP-AO specifies the use of stronger Message Authentication Codes (MACs), protects against replays even for long-lived TCP connections, and provides more details on the association of security with TCP connections than TCP MD5. TCP-AO is compatible with either a staticMaster Key Tuple (MKT) configuration or an external, out-of-band MKT management mechanism; in either case, TCP-AO also protects connections when using the same MKT across repeated instances of a connection, using traffic keys derived from the MKT, and coordinatesMKT changes between endpoints. The result is intended to support current infrastructure uses of TCP MD5, such as to protect long-lived connections (as used, e.g., in BGP and LDP), and to support a larger set of MACs with minimal other system and operational changes. TCP-AO uses a different option identifier than TCP MD5, even though TCP-AO and TCP MD5 are never permitted to be used simultaneously. TCP-AO supports IPv6, and is fully compatible with the proposed requirements for the replacement of TCP MD5. |
|
| |
| RFC 5926 | Cryptographic Algorithms for the TCP Authentication Option (TCP-AO) |
| |
| Authors: | G. Lebovitz, E. Rescorla. |
| Date: | June 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5926 |
|
The TCP Authentication Option (TCP-AO) relies on security algorithms to provide authentication between two end-points. There are many such algorithms available, and two TCP-AO systems cannot interoperate unless they are using the same algorithms. This document specifies the algorithms and attributes that can be used in TCP-AO's current manual keying mechanism and provides the interface for future message authentication codes (MACs). |
|
| |
| RFC 5928 | Traversal Using Relays around NAT (TURN) Resolution Mechanism |
| |
|
|
This document defines a resolution mechanism to generate a list of server transport addresses that can be tried to create a TraversalUsing Relays around NAT (TURN) allocation. |
|
| |
| RFC 5929 | Channel Bindings for TLS |
| |
| Authors: | J. Altman, N. Williams, L. Zhu. |
| Date: | July 2010 |
| Formats: | txt html json |
| Updated by: | RFC 9266 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5929 |
|
This document defines three channel binding types for Transport LayerSecurity (TLS), tls-unique, tls-server-end-point, and tls-unique-for- telnet, in accordance with RFC 5056 (On Channel Binding).
Note that based on implementation experience, this document changes the original definition of 'tls-unique' channel binding type in the channel binding type IANA registry. |
|
| |
| RFC 5932 | Camellia Cipher Suites for TLS |
| |
| Authors: | A. Kato, M. Kanda, S. Kanno. |
| Date: | June 2010 |
| Formats: | txt json html |
| Obsoletes: | RFC 4132 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5932 |
|
This document specifies a set of cipher suites for the TransportSecurity Layer (TLS) protocol to support the Camellia encryption algorithm as a block cipher. It amends the cipher suites originally specified in RFC 4132 by introducing counterparts using the newer cryptographic hash algorithms from the SHA-2 family. This document obsoletes RFC 4132. |
|
| |
| RFC 5933 | Use of GOST Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC |
| |
| Authors: | V. Dolmatov, Ed., A. Chuprina, I. Ustinov. |
| Date: | July 2010 |
| Formats: | txt json html |
| Updated by: | RFC 6944 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5933 |
|
This document describes how to produce digital signatures and hash functions using the GOST R 34.10-2001 and GOST R 34.11-94 algorithms for DNSKEY, RRSIG, and DS resource records, for use in the DomainName System Security Extensions (DNSSEC). |
|
| |
| RFC 5934 | Trust Anchor Management Protocol (TAMP) |
| |
| Authors: | R. Housley, S. Ashmore, C. Wallace. |
| Date: | August 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5934 |
|
This document describes a transport independent protocol for the management of trust anchors (TAs) and community identifiers stored in a trust anchor store. The protocol makes use of the CryptographicMessage Syntax (CMS), and a digital signature is used to provide integrity protection and data origin authentication. The protocol can be used to manage trust anchor stores containing trust anchors represented as Certificate, TBSCertificate, or TrustAnchorInfo objects. |
|
| |
| RFC 5935 | Expressing SNMP SMI Datatypes in XML Schema Definition Language |
| |
| Authors: | M. Ellison, B. Natale. |
| Date: | August 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5935 |
|
This memo defines the IETF standard expression of Structure ofManagement Information (SMI) base datatypes in XML Schema Definition(XSD) language. The primary objective of this memo is to enable the production of XML documents that are as faithful to the SMI as possible, using XSD as the validation mechanism. |
|
| |
| RFC 5936 | DNS Zone Transfer Protocol (AXFR) |
| |
|
|
The standard means within the Domain Name System protocol for maintaining coherence among a zone's authoritative name servers consists of three mechanisms. Authoritative Transfer (AXFR) is one of the mechanisms and is defined in RFC 1034 and RFC 1035.
The definition of AXFR has proven insufficient in detail, thereby forcing implementations intended to be compliant to make assumptions, impeding interoperability. Yet today we have a satisfactory set of implementations that do interoperate. This document is a new definition of AXFR -- new in the sense that it records an accurate definition of an interoperable AXFR mechanism. |
|
| |
| RFC 5938 | Individual Session Control Feature for the Two-Way Active Measurement Protocol (TWAMP) |
| |
|
|
The IETF has completed its work on the core specification of TWAMP -- the Two-Way Active Measurement Protocol. This memo describes anOPTIONAL feature for TWAMP, that gives the controlling host the ability to start and stop one or more individual test sessions usingSession Identifiers. The base capability of the TWAMP protocol requires all test sessions that were previously requested and accepted to start and stop at the same time. |
|
| |
| RFC 5939 | Session Description Protocol (SDP) Capability Negotiation |
| |
|
|
The Session Description Protocol (SDP) was intended to describe multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. SDP was not intended to provide capability indication or capability negotiation; however, over the years, SDP has seen widespread adoption and as a result it has been gradually extended to provide limited support for these, notably in the form of the offer/answer model defined in RFC 3264. SDP does not define how to negotiate one or more alternative transport protocols (e.g., RTP profiles) or attributes. This makes it difficult to deploy new RTP profiles such as Secure RTP or RTP with RTCP-based feedback, negotiate use of different security keying mechanisms, etc. It also presents problems for some forms of media negotiation.
The purpose of this document is to address these shortcomings by extending SDP with capability negotiation parameters and associated offer/answer procedures to use those parameters in a backwards compatible manner.
The document defines a general SDP Capability Negotiation framework.It also specifies how to provide attributes and transport protocols as capabilities and negotiate them using the framework. Extensions for other types of capabilities (e.g., media types and media formats) may be provided in other documents. |
|
| |
| RFC 5940 | Additional Cryptographic Message Syntax (CMS) Revocation Information Choices |
| |
| Authors: | S. Turner, R. Housley. |
| Date: | August 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5940 |
|
The Cryptographic Message Syntax (CMS) allows revocation information to be conveyed as part of the SignedData, EnvelopedData,AuthenticatedData, and AuthEnvelopedData content types. The preferred format for revocation information is the CertificateRevocation List (CRL), but an extension mechanism supports other revocation information formats. This document defines two additional revocation information formats for Online Certificate Status Protocol(OCSP) responses and Server-Based Certificate Validation Protocol(SCVP) requests and responses. |
|
| |
| RFC 5942 | IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes |
| |
| Authors: | H. Singh, W. Beebee, E. Nordmark. |
| Date: | July 2010 |
| Formats: | txt html json |
| Updates: | RFC 4861 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5942 |
|
IPv6 specifies a model of a subnet that is different than the IPv4 subnet model. The subtlety of the differences has resulted in incorrect implementations that do not interoperate. This document spells out the most important difference: that an IPv6 address isn't automatically associated with an IPv6 on-link prefix. This document also updates (partially due to security concerns caused by incorrect implementations) a part of the definition of "on-link" from RFC 4861. |
|
| |
| RFC 5943 | A Dedicated Routing Policy Specification Language Interface Identifier for Operational Testing |
| |
| Authors: | B. Haberman, Ed.. |
| Date: | August 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5943 |
|
The deployment of new IP connectivity typically results in intermittent reachability for numerous reasons that are outside the scope of this document. In order to aid in the debugging of these persistent problems, this document proposes the creation of a newRouting Policy Specification Language attribute that allows a network to advertise an IP address that is reachable and can be used as a target for diagnostic tests (e.g., pings). |
|
| |
| RFC 5944 | IP Mobility Support for IPv4, Revised |
| |
|
|
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 5946 | Resource Reservation Protocol (RSVP) Extensions for Path-Triggered RSVP Receiver Proxy |
| |
| Authors: | F. Le Faucheur, J. Manner, A. Narayanan, A. Guillou, H. Malik. |
| Date: | October 2010 |
| Formats: | txt html json |
| Updates: | RFC 2205 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5946 |
|
Resource Reservation Protocol (RSVP) signaling can be used to make end-to-end resource reservations in an IP network in order to guarantee the Quality of Service (QoS) required by certain flows.With conventional RSVP, both the data sender and receiver of a given flow take part in RSVP signaling. Yet, there are many use cases where resource reservation is required, but the receiver, the sender, or both, is not RSVP-capable. Where the receiver is not RSVP- capable, an RSVP router may behave as an RSVP Receiver Proxy, thereby performing RSVP signaling on behalf of the receiver. This allows resource reservations to be established on the segment of the end-to- end path from the sender to the RSVP Receiver Proxy. However, as discussed in the companion document "RSVP Proxy Approaches", RSVP extensions are needed to facilitate operations with an RSVP ReceiverProxy whose signaling is triggered by receipt of RSVP Path messages from the sender. This document specifies these extensions. |
|
| |
| RFC 5948 | Transmission of IPv4 Packets over the IP Convergence Sublayer of IEEE 802.16 |
| |
| Authors: | S. Madanapalli, S. Park, S. Chakrabarti, G. Montenegro. |
| Date: | August 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5948 |
|
IEEE 802.16 is an air interface specification for wireless broadband access. IEEE 802.16 has specified multiple service-specificConvergence Sublayers for transmitting upper-layer protocols. ThePacket CS (Packet Convergence Sublayer) is used for the transport of all packet-based protocols such as the Internet Protocol (IP) andIEEE 802.3 (Ethernet). The IP-specific part of the Packet CS enables the transport of IPv4 packets directly over the IEEE 802.16 MediaAccess Control (MAC) layer.
This document specifies the frame format, the Maximum TransmissionUnit (MTU), and the address assignment procedures for transmittingIPv4 packets over the IP-specific part of the Packet ConvergenceSublayer of IEEE 802.16. |
|
| |
| RFC 5949 | Fast Handovers for Proxy Mobile IPv6 |
| |
| Authors: | H. Yokota, K. Chowdhury, R. Koodli, B. Patil, F. Xia. |
| Date: | September 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5949 |
|
Mobile IPv6 (MIPv6; RFC 3775) provides a mobile node with IP mobility when it performs a handover from one access router to another, and fast handovers for Mobile IPv6 (FMIPv6) are specified to enhance the handover performance in terms of latency and packet loss. WhileMIPv6 (and FMIPv6 as well) requires the participation of the mobile node in the mobility-related signaling, Proxy Mobile IPv6 (PMIPv6;RFC 5213) provides IP mobility to nodes that either have or do not have MIPv6 functionality without such involvement. Nevertheless, the basic performance of PMIPv6 in terms of handover latency and packet loss is considered no different from that of MIPv6.
When the fast handover is considered in such an environment, several modifications are needed to FMIPv6 to adapt to the network-based mobility management. This document specifies the usage of fast handovers for Mobile IPv6 (FMIPv6; RFC 5568) when Proxy Mobile IPv6 is used as the mobility management protocol. Necessary extensions are specified for FMIPv6 to support the scenario when the mobile node does not have IP mobility functionality and hence is not involved with either MIPv6 or FMIPv6 operations. |
|
| |
| RFC 5951 | Network Management Requirements for MPLS-based Transport Networks |
| |
| Authors: | K. Lam, S. Mansfield, E. Gray. |
| Date: | September 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5951 |
|
This document specifies the requirements for the management of equipment used in networks supporting an MPLS Transport Profile(MPLS-TP). The requirements are defined for specification of network management aspects of protocol mechanisms and procedures that constitute the building blocks out of which the MPLSTransport Profile is constructed. That is, these requirements indicate what management capabilities need to be available inMPLS for use in managing the MPLS-TP. This document is intended to identify essential network management capabilities, not to specify what functions any particular MPLS implementation supports. |
|
| |
| RFC 5952 | A Recommendation for IPv6 Address Text Representation |
| |
| Authors: | S. Kawamura, M. Kawashima. |
| Date: | August 2010 |
| Formats: | txt html json |
| Updates: | RFC 4291 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5952 |
|
As IPv6 deployment increases, there will be a dramatic increase in the need to use IPv6 addresses in text. While the IPv6 address architecture in Section 2.2 of RFC 4291 describes a flexible model for text representation of an IPv6 address, this flexibility has been causing problems for operators, system engineers, and users. This document defines a canonical textual representation format. It does not define a format for internal storage, such as within an application or database. It is expected that the canonical format will be followed by humans and systems when representing IPv6 addresses as text, but all implementations must accept and be able to handle any legitimate RFC 4291 format. |
|
| |
| RFC 5953 | Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP) |
| |
|
|
This document describes a Transport Model for the Simple NetworkManagement Protocol (SNMP), that uses either the Transport LayerSecurity protocol or the Datagram Transport Layer Security (DTLS) protocol. The TLS and DTLS protocols provide authentication and privacy services for SNMP applications. This document describes how the TLS Transport Model (TLSTM) implements the needed features of aSNMP Transport Subsystem to make this protection possible in an interoperable way.
This Transport Model is designed to meet the security and operational needs of network administrators. It supports the sending of SNMP messages over TLS/TCP and DTLS/UDP. The TLS mode can make use ofTCP's improved support for larger packet sizes and the DTLS mode provides potentially superior operation in environments where a connectionless (e.g., UDP) transport is preferred. Both TLS and DTLS integrate well into existing public keying infrastructures.
This document also defines a portion of the Management InformationBase (MIB) for use with network management protocols. In particular, it defines objects for managing the TLS Transport Model for SNMP. |
|
| |
| RFC 5954 | Essential Correction for IPv6 ABNF and URI Comparison in RFC 3261 |
| |
| Authors: | V. Gurbani, Ed., B. Carpenter, Ed., B. Tate, Ed.. |
| Date: | August 2010 |
| Formats: | txt json html |
| Updates: | RFC 3261 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5954 |
|
This document corrects the Augmented Backus-Naur Form (ABNF) production rule associated with generating IPv6 literals in RFC 3261.It also clarifies the rule for Uniform Resource Identifier (URI) comparison when the URIs contain textual representation of IP addresses. |
|
| |
| RFC 5956 | Forward Error Correction Grouping Semantics in the Session Description Protocol |
| |
|
|
This document defines the semantics for grouping the associated source and FEC-based (Forward Error Correction) repair flows in theSession Description Protocol (SDP). The semantics defined in this document are to be used with the SDP Grouping Framework (RFC 5888).These semantics allow the description of grouping relationships between the source and repair flows when one or more source and/or repair flows are associated in the same group, and they provide support for additive repair flows. SSRC-level (SynchronizationSource) grouping semantics are also defined in this document forReal-time Transport Protocol (RTP) streams using SSRC multiplexing. |
|
| |
| RFC 5957 | Display-Based Address Sorting for the IMAP4 SORT Extension |
| |
|
|
This document describes an IMAP protocol extension enabling server- side message sorting on the commonly displayed portion of the From and To header fields. |
|
| |
| RFC 5958 | Asymmetric Key Packages |
| |
|
|
This document defines the syntax for private-key information and a content type for it. Private-key information includes a private key for a specified public-key algorithm and a set of attributes. TheCryptographic Message Syntax (CMS), as defined in RFC 5652, can be used to digitally sign, digest, authenticate, or encrypt the asymmetric key format content type. This document obsoletes RFC5208. |
|
| |
| RFC 5959 | Algorithms for Asymmetric Key Package Content Type |
| |
|
|
This document describes the conventions for using several cryptographic algorithms with the EncryptedPrivateKeyInfo structure, as defined in RFC 5958. It also includes conventions necessary to protect the AsymmetricKeyPackage content type with SignedData,EnvelopedData, EncryptedData, AuthenticatedData, andAuthEnvelopedData. |
|
| |
| RFC 5960 | MPLS Transport Profile Data Plane Architecture |
| |
| Authors: | D. Frost, Ed., S. Bryant, Ed., M. Bocci, Ed.. |
| Date: | August 2010 |
| Formats: | txt json html |
| Updated by: | RFC 7274 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5960 |
|
The Multiprotocol Label Switching Transport Profile (MPLS-TP) is the set of MPLS protocol functions applicable to the construction and operation of packet-switched transport networks. This document specifies the subset of these functions that comprises the MPLS-TP data plane: the architectural layer concerned with the encapsulation and forwarding of packets within an MPLS-TP network.
This document is a product of a joint Internet Engineering Task Force(IETF) / International Telecommunication Union TelecommunicationStandardization Sector (ITU-T) effort to include an MPLS TransportProfile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge(PWE3) architectures to support the capabilities and functionalities of a packet transport network. |
|
| |
| RFC 5961 | Improving TCP's Robustness to Blind In-Window Attacks |
| |
| Authors: | A. Ramaiah, R. Stewart, M. Dalal. |
| Date: | August 2010 |
| Formats: | txt json html |
| Updated by: | RFC 9293 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5961 |
|
TCP has historically been considered to be protected against spoofed off-path packet injection attacks by relying on the fact that it is difficult to guess the 4-tuple (the source and destination IP addresses and the source and destination ports) in combination with the 32-bit sequence number(s). A combination of increasing window sizes and applications using longer-term connections (e.g., H-323 orBorder Gateway Protocol (BGP) [RFC4271]) have left modern TCP implementations more vulnerable to these types of spoofed packet injection attacks.
Many of these long-term TCP applications tend to have predictable IP addresses and ports that makes it far easier for the 4-tuple (4-tuple is the same as the socket pair mentioned in RFC 793) to be guessed.Having guessed the 4-tuple correctly, an attacker can inject a TCP segment with the RST bit set, the SYN bit set or data into a TCP connection by systematically guessing the sequence number of the spoofed segment to be in the current receive window. This can cause the connection to abort or cause data corruption. This document specifies small modifications to the way TCP handles inbound segments that can reduce the chances of a successful attack. |
|
| |
| RFC 5962 | Dynamic Extensions to the Presence Information Data Format Location Object (PIDF-LO) |
| |
| Authors: | H. Schulzrinne, V. Singh, H. Tschofenig, M. Thomson. |
| Date: | September 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5962 |
|
The Geopriv Location Object introduced by the Presence InformationData Format - Location Object (PIDF-LO), RFC 4119, defines a basicXML format for carrying geographical information of a presentity.This document defines PIDF-LO extensions to convey information about moving objects. Elements are defined that enable expression of spatial orientation, speed, and heading of the presentity. |
|
| |
| RFC 5964 | Specifying Holes in Location-to-Service Translation (LoST) Service Boundaries |
| |
| Authors: | J. Winterbottom, M. Thomson. |
| Date: | August 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5964 |
|
This document describes how holes can be specified in geodetic service boundaries. One means of implementing a search solution in a service database, such as one might provide with a Location-to-Service Translation (LoST) server, is described. |
|
| |
| RFC 5965 | An Extensible Format for Email Feedback Reports |
| |
| Authors: | Y. Shafranovich, J. Levine, M. Kucherawy. |
| Date: | August 2010 |
| Formats: | txt json html |
| Updated by: | RFC 6650 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5965 |
|
This document defines an extensible format and MIME type that may be used by mail operators to report feedback about received email to other parties. This format is intended as a machine-readable replacement for various existing report formats currently used inInternet email. |
|
| |
| RFC 5966 | DNS Transport over TCP - Implementation Requirements |
| |
|
|
This document updates the requirements for the support of TCP as a transport protocol for DNS implementations. |
|
| |
| RFC 5969 | IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification |
| |
| Authors: | W. Townsley, O. Troan. |
| Date: | August 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5969 |
|
This document specifies an automatic tunneling mechanism tailored to advance deployment of IPv6 to end users via a service provider's IPv4 network infrastructure. Key aspects include automatic IPv6 prefix delegation to sites, stateless operation, simple provisioning, and service, which is equivalent to native IPv6 at the sites that are served by the mechanism. |
|
| |
| RFC 5970 | DHCPv6 Options for Network Boot |
| |
| Authors: | T. Huth, J. Freimann, V. Zimmer, D. Thaler. |
| Date: | September 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5970 |
|
The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) provides a framework for passing configuration information to nodes on a network. This document describes new options for DHCPv6 that SHOULD be used for booting a node from the network. |
|
| |
| RFC 5985 | HTTP-Enabled Location Delivery (HELD) |
| |
|
|
This document defines a Layer 7 Location Configuration Protocol (L7LCP) and describes the use of HTTP and HTTP/TLS as transports for theL7 LCP. The L7 LCP is used for retrieving location information from a server within an access network. It includes options for retrieving location information in two forms: by value and by reference. The protocol is an extensible application-layer protocol that is independent of the session layer. |
|
| |
| RFC 5986 | Discovering the Local Location Information Server (LIS) |
| |
| Authors: | M. Thomson, J. Winterbottom. |
| Date: | September 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5986 |
|
Discovery of the correct Location Information Server (LIS) in the local access network is necessary for Devices that wish to acquire location information from the network. A method is described for the discovery of a LIS in the access network serving a Device. DynamicHost Configuration Protocol (DHCP) options for IP versions 4 and 6 are defined that specify a domain name. This domain name is then used as input to a URI-enabled NAPTR (U-NAPTR) resolution process. |
|
| |
| RFC 5988 | Web Linking |
| |
|
|
This document specifies relation types for Web links, and defines a registry for them. It also defines the use of such links in HTTP headers with the Link header field. |
|
| |
| RFC 5989 | A SIP Event Package for Subscribing to Changes to an HTTP Resource |
| |
| Authors: | A.B. Roach. |
| Date: | October 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5989 |
|
The Session Initiation Protocol (SIP) is increasingly being used in systems that are tightly coupled with Hypertext Transport Protocol(HTTP) servers for a variety of reasons. In many of these cases, applications can benefit from being able to discover, in near real- time, when a specific HTTP resource is created, changed, or deleted.This document proposes a mechanism, based on the SIP Event Framework, for doing so. |
|
| |
| RFC 5990 | Use of the RSA-KEM Key Transport Algorithm in the Cryptographic Message Syntax (CMS) |
| |
| Authors: | J. Randall, B. Kaliski, J. Brainard, S. Turner. |
| Date: | September 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5990 |
|
The RSA-KEM Key Transport Algorithm is a one-pass (store-and-forward) mechanism for transporting keying data to a recipient using the recipient's RSA public key. ("KEM" stands for "key encapsulation mechanism".) This document specifies the conventions for using theRSA-KEM Key Transport Algorithm with the Cryptographic Message Syntax(CMS). The ASN.1 syntax is aligned with an expected forthcoming change to American National Standard (ANS) X9.44. |
|
| |
| RFC 5991 | Teredo Security Updates |
| |
| Authors: | D. Thaler, S. Krishnan, J. Hoagland. |
| Date: | September 2010 |
| Formats: | txt json html |
| Updates: | RFC 4380 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5991 |
|
The Teredo protocol defines a set of flags that are embedded in everyTeredo IPv6 address. This document specifies a set of security updates that modify the use of this flags field, but are backward compatible. |
|
| |
| RFC 5993 | RTP Payload Format for Global System for Mobile Communications Half Rate (GSM-HR) |
| |
| Authors: | X. Duan, S. Wang, M. Westerlund, K. Hellwig, I. Johansson. |
| Date: | October 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5993 |
|
This document specifies the payload format for packetization ofGlobal System for Mobile Communications Half Rate (GSM-HR) speech codec data into the Real-time Transport Protocol (RTP). The payload format supports transmission of multiple frames per payload and packet loss robustness methods using redundancy. |
|
| |
| RFC 5995 | Using POST to Add Members to Web Distributed Authoring and Versioning (WebDAV) Collections |
| |
| Authors: | J. Reschke. |
| Date: | September 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5995 |
|
The Hypertext Transfer Protocol (HTTP) Extensions for the WebDistributed Authoring and Versioning (WebDAV) do not define the behavior for the "POST" method when applied to collections, as the base specification (HTTP) leaves implementers lots of freedom for the semantics of "POST".
This has led to a situation where many WebDAV servers do not implement POST for collections at all, although it is well suited to be used for the purpose of adding new members to a collection, where the server remains in control of the newly assigned URL. In fact, the Atom Publishing Protocol (AtomPub) uses POST exactly for that purpose. On the other hand, WebDAV-based protocols, such as theCalendaring Extensions to WebDAV (CalDAV), frequently require clients to pick a unique URL, although the server could easily perform that task.
This specification defines a discovery mechanism through which servers can advertise support for POST requests with the aforementioned "add collection member" semantics. |
|
| |
| RFC 5996 | Internet Key Exchange Protocol Version 2 (IKEv2) |
| |
|
|
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 document replaces and updates RFC 4306, and includes all of the clarifications from RFC 4718. |
|
| |
| RFC 5998 | An Extension for EAP-Only Authentication in IKEv2 |
| |
| Authors: | P. Eronen, H. Tschofenig, Y. Sheffer. |
| Date: | September 2010 |
| Formats: | txt json html |
| Updates: | RFC 5996 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5998 |
|
IKEv2 specifies that Extensible Authentication Protocol (EAP) authentication must be used together with responder authentication based on public key signatures. This is necessary with old EAP methods that provide only unilateral authentication using, e.g., one- time passwords or token cards.
This document specifies how EAP methods that provide mutual authentication and key agreement can be used to provide extensible responder authentication for IKEv2 based on methods other than public key signatures. |
|
| |
| RFC 6001 | Generalized MPLS (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN) |
| |
|
|
There are specific requirements for the support of networks comprising Label Switching Routers (LSRs) participating in different data plane switching layers controlled by a single Generalized Multi-Protocol Label Switching (GMPLS) control plane instance, referred to as GMPLS Multi-Layer Networks / Multi-Region Networks (MLN/MRN).
This document defines extensions to GMPLS routing and signaling protocols so as to support the operation of GMPLS Multi-Layer /Multi-Region Networks. It covers the elements of a single GMPLS control plane instance controlling multiple Label Switched Path (LSP) regions or layers within a single Traffic Engineering (TE) domain. |
|
| |
| RFC 6002 | Generalized MPLS (GMPLS) Data Channel Switching Capable (DCSC) and Channel Set Label Extensions |
| |
|
|
This document describes two technology-independent extensions toGeneralized Multi-Protocol Label Switching (GMPLS). The first extension defines the new switching type Data Channel SwitchingCapable. Data Channel Switching Capable interfaces are able to support switching of the whole digital channel presented on single channel interfaces. The second extension defines a new type of generalized label and updates related objects. The new label is called the Generalized Channel_Set Label and allows more than one data plane label to be controlled as part of a Label Switched Path(LSP). |
|
| |
| RFC 6003 | Ethernet Traffic Parameters |
| |
|
|
This document describes the support of Metro Ethernet Forum (MEF)Ethernet traffic parameters as described in MEF10.1 when usingGeneralized Multi-Protocol Label Switching (GMPLS) ResourceReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling. |
|
| |
| RFC 6004 | Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 Ethernet Service Switching |
| |
| Authors: | L. Berger, D. Fedyk. |
| Date: | October 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6004 |
|
This document describes a method for controlling two specific types of Ethernet switching via Generalized Multi-Protocol Label Switching(GMPLS). This document supports the types of switching corresponding to the Ethernet services that have been defined in the context of theMetro Ethernet Forum (MEF) and International Telecommunication Union(ITU) G.8011. Specifically, switching in support of Ethernet private line and Ethernet virtual private line services are covered. Support for MEF- and ITU-defined parameters is also covered. |
|
| |
| RFC 6005 | Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 User Network Interface (UNI) |
| |
| Authors: | L. Berger, D. Fedyk. |
| Date: | October 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6005 |
|
This document describes a method for controlling two specific types of Ethernet switching via a GMPLS-based User Network Interface (UNI).This document supports the types of switching required by theEthernet services that have been defined in the context of the MetroEthernet Forum (MEF) and International Telecommunication Union (ITU)G.8011. This document is the UNI companion to "Generalized MPLS(GMPLS) Support for Metro Ethernet Forum and G.8011 Ethernet ServiceSwitching". This document does not define or limit the underlying intra-domain or Internal NNI (I-NNI) technology used to support theUNI. |
|
| |
| RFC 6006 | Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths |
| |
| Authors: | Q. Zhao, Ed., D. King, Ed., F. Verhaeghe, T. Takeda, Z. Ali, J. Meuric. |
| Date: | September 2010 |
| Formats: | txt html json |
| Obsoleted by: | RFC 8306 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6006 |
|
Point-to-point Multiprotocol Label Switching (MPLS) and GeneralizedMPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may be established using signaling techniques, but their paths may first need to be determined. The Path Computation Element (PCE) has been identified as an appropriate technology for the determination of the paths of point-to-multipoint (P2MP) TE LSPs.
This document describes extensions to the PCE communication Protocol(PCEP) to handle requests and responses for the computation of paths for P2MP TE LSPs. |
|
| |
| RFC 6008 | Authentication-Results Registration for Differentiating among Cryptographic Results |
| |
| Authors: | M. Kucherawy. |
| Date: | September 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6008 |
|
This memo updates the registry of properties in Authentication-Results: message header fields to allow a multiple-result report to distinguish among one or more cryptographic signatures on a message, thus associating specific results with the signatures they represent. |
|
| |
| RFC 6009 | Sieve Email Filtering: Delivery Status Notifications and Deliver-By Extensions |
| |
| Authors: | N. Freed. |
| Date: | October 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6009 |
|
This document describes the "envelope-dsn", "redirect-dsn","envelope-deliverby", and "redirect-deliverby" extensions to theSieve email filtering language. The "envelope-dsn" and "envelope- deliverby" extensions provide access to additional envelope information provided by the delivery status notification (DSN) andDeliver-By SMTP extensions, respectively. The "redirect-dsn" and"redirect-deliverby" extensions extend Sieve's redirect action to provide control over delivery status notification and Deliver-By parameters, respectively. |
|
| |
| RFC 6010 | Cryptographic Message Syntax (CMS) Content Constraints Extension |
| |
| Authors: | R. Housley, S. Ashmore, C. Wallace. |
| Date: | September 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6010 |
|
This document specifies the syntax and semantics for theCryptographic Message Syntax (CMS) content constraints extension.This extension is used to determine whether a public key is appropriate to use in the processing of a protected content. In particular, the CMS content constraints extension is one part of the authorization decision; it is used when validating a digital signature on a CMS SignedData content or validating a message authentication code (MAC) on a CMS AuthenticatedData content or CMSAuthEnvelopedData content. The signed or authenticated content type is identified by an ASN.1 object identifier, and this extension indicates the content types that the public key is authorized to validate. If the authorization check is successful, the CMS content constraints extension also provides default values for absent attributes. |
|
| |
| RFC 6012 | Datagram Transport Layer Security (DTLS) Transport Mapping for Syslog |
| |
| Authors: | J. Salowey, T. Petch, R. Gerhards, H. Feng. |
| Date: | October 2010 |
| Formats: | txt html json |
| Updated by: | RFC 8996 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6012 |
|
This document describes the transport of syslog messages over theDatagram Transport Layer Security (DTLS) protocol. It provides a secure transport for syslog messages in cases where a connectionless transport is desired. |
|
| |
| RFC 6014 | Cryptographic Algorithm Identifier Allocation for DNSSEC |
| |
|
|
This document specifies how DNSSEC cryptographic algorithm identifiers in the IANA registries are allocated. It changes the requirement from "standard required" to "RFC Required". It does not change the list of algorithms that are recommended or required forDNSSEC implementations. |
|
| |
| RFC 6015 | RTP Payload Format for 1-D Interleaved Parity Forward Error Correction (FEC) |
| |
| Authors: | A. Begen. |
| Date: | October 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6015 |
|
This document defines a new RTP payload format for the Forward ErrorCorrection (FEC) that is generated by the 1-D interleaved parity code from a source media encapsulated in RTP. The 1-D interleaved parity code is a systematic code, where a number of repair symbols are generated from a set of source symbols and sent in a repair flow separate from the source flow that carries the source symbols. The1-D interleaved parity code offers a good protection against bursty packet losses at a cost of reasonable complexity. The new payload format defined in this document should only be used (with some exceptions) as a part of the Digital Video Broadcasting-IPTV (DVB-IPTV) Application-layer FEC specification. |
|
| |
| RFC 6016 | Support for the Resource Reservation Protocol (RSVP) in Layer 3 VPNs |
| |
| Authors: | B. Davie, F. Le Faucheur, A. Narayanan. |
| Date: | October 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6016 |
|
RFC 4364 and RFC 4659 define an approach to building provider- provisioned Layer 3 VPNs (L3VPNs) for IPv4 and IPv6. It may be desirable to use Resource Reservation Protocol (RSVP) to perform admission control on the links between Customer Edge (CE) routers andProvider Edge (PE) routers. This document specifies procedures by which RSVP messages traveling from CE to CE across an L3VPN may be appropriately handled by PE routers so that admission control can be performed on PE-CE links. Optionally, admission control across the provider's backbone may also be supported. |
|
| |
| RFC 6019 | BinaryTime: An Alternate Format for Representing Date and Time in ASN.1 |
| |
|
|
This document specifies a new ASN.1 type for representing time:BinaryTime. This document also specifies an alternate to the signing-time attribute for use with the Cryptographic Message Syntax(CMS) SignedData and AuthenticatedData content types; the binary- signing-time attribute uses BinaryTime. CMS and the signing-time attribute are defined in RFC 5652. |
|
| |
| RFC 6020 | YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF) |
| |
| Authors: | M. Bjorklund, Ed.. |
| Date: | October 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6020 |
|
YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol(NETCONF), NETCONF remote procedure calls, and NETCONF notifications. |
|
| |
| RFC 6021 | Common YANG Data Types |
| |
| Authors: | J. Schoenwaelder, Ed.. |
| Date: | October 2010 |
| Formats: | txt json html |
| Obsoleted by: | RFC 6991 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6021 |
|
This document introduces a collection of common data types to be used with the YANG data modeling language. |
|
| |
| RFC 6022 | YANG Module for NETCONF Monitoring |
| |
| Authors: | M. Scott, M. Bjorklund. |
| Date: | October 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6022 |
|
This document defines a Network Configuration Protocol (NETCONF) data model to be used to monitor the NETCONF protocol. The monitoring data model includes information about NETCONF datastores, sessions, locks, and statistics. This data facilitates the management of aNETCONF server. This document also defines methods for NETCONF clients to discover data models supported by a NETCONF server and defines a new NETCONF <get-schema&rt; operation to retrieve them. |
|
| |
| RFC 6026 | Correct Transaction Handling for 2xx Responses to Session Initiation Protocol (SIP) INVITE Requests |
| |
| Authors: | R. Sparks, T. Zourzouvillys. |
| Date: | September 2010 |
| Formats: | txt html json |
| Updates: | RFC 3261 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6026 |
|
This document normatively updates RFC 3261, the Session InitiationProtocol (SIP), to address an error in the specified handling of success (2xx class) responses to INVITE requests. Elements followingRFC 3261 exactly will misidentify retransmissions of the request as a new, unassociated request. The correction involves modifying theINVITE transaction state machines. The correction also changes the way responses that cannot be matched to an existing transaction are handled to address a security risk. |
|
| |
| RFC 6030 | Portable Symmetric Key Container (PSKC) |
| |
| Authors: | P. Hoyer, M. Pei, S. Machani. |
| Date: | October 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6030 |
|
This document specifies a symmetric key format for the transport and provisioning of symmetric keys to different types of crypto modules.For example, One-Time Password (OTP) shared secrets or symmetric cryptographic keys to strong authentication devices. A standard key transport format enables enterprises to deploy best-of-breed solutions combining components from different vendors into the same infrastructure. |
|
| |
| RFC 6031 | Cryptographic Message Syntax (CMS) Symmetric Key Package Content Type |
| |
| Authors: | S. Turner, R. Housley. |
| Date: | December 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6031 |
|
This document defines the symmetric key format content type. It is transport independent. The Cryptographic Message Syntax (CMS) can be used to digitally sign, digest, authenticate, or encrypt this content type. |
|
| |
| RFC 6032 | Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type |
| |
| Authors: | S. Turner, R. Housley. |
| Date: | December 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6032 |
|
This document defines the Cryptographic Message Syntax (CMS) encrypted key package content type, which can be used to encrypt a content that includes a key package, such as a symmetric key package or an asymmetric key package. It is transport independent. CMS can be used to digitally sign, digest, authenticate, or further encrypt this content type. It is designed to be used with the CMS ContentConstraints (CCC) extension, which does not constrain theEncryptedData, EnvelopedData, and AuthEnvelopedData. |
|
| |
| RFC 6033 | Algorithms for Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type |
| |
|
|
This document describes the conventions for using several cryptographic algorithms with the Cryptographic Message Syntax (CMS) encrypted key package content type. Specifically, it includes conventions necessary to implement EnvelopedData, EncryptedData, andAuthEnvelopedData. |
|
| |
| RFC 6034 | Unicast-Prefix-Based IPv4 Multicast Addresses |
| |
| Authors: | D. Thaler. |
| Date: | October 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6034 |
|
This specification defines an extension to the multicast addressing architecture of the IP Version 4 protocol. The extension presented in this document allows for unicast-prefix-based assignment 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 6035 | Session Initiation Protocol Event Package for Voice Quality Reporting |
| |
| Authors: | A. Pendleton, A. Clark, A. Johnston, H. Sinnreich. |
| Date: | November 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6035 |
|
This document defines a Session Initiation Protocol (SIP) event package that enables the collection and reporting of metrics that measure the quality for Voice over Internet Protocol (VoIP) sessions.Voice call quality information derived from RTP Control ProtocolExtended Reports (RTCP-XR) and call information from SIP is conveyed from a User Agent (UA) in a session, known as a reporter, to a third party, known as a collector. A registration for the application/ vq- rtcpxr media type is also included. |
|
| |
| RFC 6038 | Two-Way Active Measurement Protocol (TWAMP) Reflect Octets and Symmetrical Size Features |
| |
| Authors: | A. Morton, L. Ciavattone. |
| Date: | October 2010 |
| Formats: | txt json html |
| Updates: | RFC 5357 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6038 |
|
This memo describes two closely related features for the core specification of the Two-Way Active Measurement Protocol (TWAMP): an optional capability where the responding host returns some of the command octets or padding octets to the sender, and an optional sender packet format that ensures equal test packet sizes are used in both directions. |
|
| |
| RFC 6040 | Tunnelling of Explicit Congestion Notification |
| |
|
|
This document redefines how the explicit congestion notification(ECN) field of the IP header should be constructed on entry to and exit from any IP-in-IP tunnel. On encapsulation, it updates RFC 3168 to bring all IP-in-IP tunnels (v4 or v6) into line with RFC 4301IPsec ECN processing. On decapsulation, it updates both RFC 3168 andRFC 4301 to add new behaviours for previously unused combinations of inner and outer headers. The new rules ensure the ECN field is correctly propagated across a tunnel whether it is used to signal one or two severity levels of congestion; whereas before, only one severity level was supported. Tunnel endpoints can be updated in any order without affecting pre-existing uses of the ECN field, thus ensuring backward compatibility. Nonetheless, operators wanting to support two severity levels (e.g., for pre-congestion notification --PCN) can require compliance with this new specification. A thorough analysis of the reasoning for these changes and the implications is included. In the unlikely event that the new rules do not meet a specific need, RFC 4774 gives guidance on designing alternate ECN semantics, and this document extends that to include tunnelling issues. |
|
| |
| RFC 6047 | iCalendar Message-Based Interoperability Protocol (iMIP) |
| |
|
|
This document, "iCalendar Message-Based Interoperability Protocol(iMIP)", specifies a binding from the iCalendar Transport-independentInteroperability Protocol (iTIP) to Internet email-based transports.Calendaring entries defined by the iCalendar Object Model (iCalendar) are wrapped using constructs from RFC 5322 and MIME (RFC 2045, RFC2046, RFC 2047, and RFC 2049), and then transported over SMTP. |
|
| |
| RFC 6048 | Network News Transfer Protocol (NNTP) Additions to LIST Command |
| |
|
|
This document defines a set of enhancements to the Network NewsTransfer Protocol (NNTP) that allow a client to request extended information from NNTP servers regarding server status, policy, and other aspects of local configuration. These enhancements are made as new keywords to the existing LIST capability described in RFC 3977.
This memo updates and formalizes the LIST DISTRIBUTIONS and LISTSUBSCRIPTIONS commands defined in RFC 2980. It also adds the LISTCOUNTS, LIST MODERATORS, and LIST MOTD commands, and specifies additional values returned by the existing LIST ACTIVE command for the status of a newsgroup. |
|
| |
| RFC 6049 | Spatial Composition of Metrics |
| |
| Authors: | A. Morton, E. Stephan. |
| Date: | January 2011 |
| Formats: | txt html json |
| Updated by: | RFC 6248 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6049 |
|
This memo utilizes IP performance metrics that are applicable to both complete paths and sub-paths, and it defines relationships to compose a complete path metric from the sub-path metrics with some accuracy with regard to the actual metrics. This is called "spatial composition" in RFC 2330. The memo refers to the framework for metric composition, and provides background and motivation for combining metrics to derive others. The descriptions of several composed metrics and statistics follow. |
|
| |
| RFC 6051 | Rapid Synchronisation of RTP Flows |
| |
| Authors: | C. Perkins, T. Schierl. |
| Date: | November 2010 |
| Formats: | txt html json |
| Updates: | RFC 3550 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6051 |
|
This memo outlines how RTP sessions are synchronised, and discusses how rapidly such synchronisation can occur. We show that most RTP sessions can be synchronised immediately, but that the use of video switching multipoint conference units (MCUs) or large source-specific multicast (SSM) groups can greatly increase the synchronisation delay. This increase in delay can be unacceptable to some applications that use layered and/or multi-description codecs.
This memo introduces three mechanisms to reduce the synchronisation delay for such sessions. First, it updates the RTP Control Protocol(RTCP) timing rules to reduce the initial synchronisation delay forSSM sessions. Second, a new feedback packet is defined for use with the extended RTP profile for RTCP-based feedback (RTP/AVPF), allowing video switching MCUs to rapidly request resynchronisation. Finally, new RTP header extensions are defined to allow rapid synchronisation of late joiners, and guarantee correct timestamp-based decoding order recovery for layered codecs in the presence of clock skew. |
|
| |
| RFC 6052 | IPv6 Addressing of IPv4/IPv6 Translators |
| |
| Authors: | C. Bao, C. Huitema, M. Bagnulo, M. Boucadair, X. Li. |
| Date: | October 2010 |
| Formats: | txt json html |
| Updates: | RFC 4291 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6052 |
|
This document discusses the algorithmic translation of an IPv6 address to a corresponding IPv4 address, and vice versa, using only statically configured information. It defines a well-known prefix for use in algorithmic translations, while allowing organizations to also use network-specific prefixes when appropriate. Algorithmic translation is used in IPv4/IPv6 translators, as well as other types of proxies and gateways (e.g., for DNS) used in IPv4/IPv6 scenarios. |
|
| |
| RFC 6054 | Using Counter Modes with Encapsulating Security Payload (ESP) and Authentication Header (AH) to Protect Group Traffic |
| |
| Authors: | D. McGrew, B. Weis. |
| Date: | November 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6054 |
|
Counter modes have been defined for block ciphers such as theAdvanced Encryption Standard (AES). Counter modes use a counter, which is typically assumed to be incremented by a single sender.This memo describes the use of counter modes when applied to theEncapsulating Security Payload (ESP) and Authentication Header (AH) in multiple-sender group applications. |
|
| |
| RFC 6059 | Simple Procedures for Detecting Network Attachment in IPv6 |
| |
| Authors: | S. Krishnan, G. Daley. |
| Date: | November 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6059 |
|
Detecting Network Attachment allows hosts to assess if its existing addressing or routing configuration is valid for a newly connected network. This document provides simple procedures for DetectingNetwork Attachment in IPv6 hosts, and procedures for routers to support such services. |
|
| |
| RFC 6060 | Generalized Multiprotocol Label Switching (GMPLS) Control of Ethernet Provider Backbone Traffic Engineering (PBB-TE) |
| |
| Authors: | D. Fedyk, H. Shah, N. Bitar, A. Takacs. |
| Date: | March 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6060 |
|
This specification is complementary to the GMPLS Ethernet LabelSwitching Architecture and Framework and describes the technology- specific aspects of GMPLS control for Provider Backbone BridgeTraffic Engineering (PBB-TE). The necessary GMPLS extensions and mechanisms are described to establish Ethernet PBB-TE point-to-point(P2P) and point-to-multipoint (P2MP) connections. This document supports, but does not modify, the standard IEEE data plane. |
|
| |
| RFC 6062 | Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations |
| |
| Authors: | S. Perreault, Ed., J. Rosenberg. |
| Date: | November 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6062 |
|
This specification defines an extension of Traversal Using Relays around NAT (TURN), a relay protocol for Network Address Translator(NAT) traversal. This extension allows a TURN client to request TCP allocations, and defines new requests and indications for the TURN server to open and accept TCP connections with the client's peers.TURN and this extension both purposefully restrict the ways in which the relayed address can be used. In particular, it prevents users from running general-purpose servers from ports obtained from theTURN server. |
|
| |
| RFC 6063 | Dynamic Symmetric Key Provisioning Protocol (DSKPP) |
| |
| Authors: | A. Doherty, M. Pei, S. Machani, M. Nystrom. |
| Date: | December 2010 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6063 |
|
The Dynamic Symmetric Key Provisioning Protocol (DSKPP) is a client- server protocol for initialization (and configuration) of symmetric keys to locally and remotely accessible cryptographic modules. The protocol can be run with or without private key capabilities in the cryptographic modules and with or without an established public key infrastructure.
Two variations of the protocol support multiple usage scenarios.With the four-pass variant, keys are mutually generated by the provisioning server and cryptographic module; provisioned keys are not transferred over-the-wire or over-the-air. The two-pass variant enables secure and efficient download and installation of pre- generated symmetric keys to a cryptographic module. |
|
| |
| RFC 6065 | Using Authentication, Authorization, and Accounting Services to Dynamically Provision View-Based Access Control Model User-to-Group Mappings |
| |
| Authors: | K. Narayan, D. Nelson, R. Presuhn, Ed.. |
| Date: | December 2010 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6065 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. It describes the use of information provided by Authentication, Authorization, and Accounting(AAA) services, such as the Remote Authentication Dial-In UserService (RADIUS), to dynamically update user-to-group mappings in theView-based Access Control Model (VACM). |
|
| |
| RFC 6066 | Transport Layer Security (TLS) Extensions: Extension Definitions |
| |
|
|
This document provides specifications for existing TLS extensions.It is a companion document for RFC 5246, "The Transport LayerSecurity (TLS) Protocol Version 1.2". The extensions specified are server_name, max_fragment_length, client_certificate_url, trusted_ca_keys, truncated_hmac, and status_request. |
|
| |
| RFC 6068 | The 'mailto' URI Scheme |
| |
| Authors: | M. Duerst, L. Masinter, J. Zawinski. |
| Date: | October 2010 |
| Formats: | txt html json |
| Obsoletes: | RFC 2368 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6068 |
|
This document defines the format of Uniform Resource Identifiers(URIs) to identify resources that are reached using Internet mail.It adds better internationalization and compatibility withInternationalized Resource Identifiers (IRIs; RFC 3987) to the previous syntax of 'mailto' URIs (RFC 2368). |
|
| |
| RFC 6072 | Certificate Management Service for the Session Initiation Protocol (SIP) |
| |
| Authors: | C. Jennings, J. Fischl, Ed.. |
| Date: | February 2011 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6072 |
|
This document defines a credential service that allows SessionInitiation Protocol (SIP) User Agents (UAs) to use a SIP event package to discover the certificates of other users. This mechanism allows User Agents that want to contact a given Address-of-Record(AOR) to retrieve that AOR's certificate by subscribing to the credential service, which returns an authenticated response containing that certificate. The credential service also allows users to store and retrieve their own certificates and private keys. |
|
| |
| RFC 6073 | Segmented Pseudowire |
| |
| Authors: | L. Martini, C. Metz, T. Nadeau, M. Bocci, M. Aissaoui. |
| Date: | January 2011 |
| Formats: | txt json html |
| Updated by: | RFC 6723, RFC 7267 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6073 |
|
This document describes how to connect pseudowires (PWs) between different Packet Switched Network (PSN) domains or between two or more distinct PW control plane domains, where a control plane domain uses a common control plane protocol or instance of that protocol for a given PW. The different PW control plane domains may belong to independent autonomous systems, or the PSN technology is heterogeneous, or a PW might need to be aggregated at a specific PSN point. The PW packet data units are simply switched from one PW to another without changing the PW payload. |
|
| |
| RFC 6074 | Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs) |
| |
| Authors: | E. Rosen, B. Davie, V. Radoaca, W. Luo. |
| Date: | January 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6074 |
|
Provider Provisioned Layer 2 Virtual Private Networks (L2VPNs) may have different "provisioning models", i.e., models for what information needs to be configured in what entities. Once configured, the provisioning information is distributed by a"discovery process". When the discovery process is complete, a signaling protocol is automatically invoked to set up the mesh of pseudowires (PWs) that form the (virtual) backbone of the L2VPN.This document specifies a number of L2VPN provisioning models, and further specifies the semantic structure of the endpoint identifiers required by each model. It discusses the distribution of these identifiers by the discovery process, especially when discovery is based on the Border Gateway Protocol (BGP). It then specifies how the endpoint identifiers are carried in the two signaling protocols that are used to set up PWs, the Label Distribution Protocol (LDP), and the Layer 2 Tunneling Protocol version 3 (L2TPv3). |
|
| |
| RFC 6075 | The Internet Assigned Number Authority (IANA) Application Configuration Access Protocol (ACAP) Vendor Subtrees Registry |
| |
|
|
The original Application Configuration Access Protocol (ACAP) specification included a vendor registry now used in other protocols.This document updates the description of this registry, removing the need for a direct normative reference to ACAP and removing ambiguity. |
|
| |
| RFC 6076 | Basic Telephony SIP End-to-End Performance Metrics |
| |
| Authors: | D. Malas, A. Morton. |
| Date: | January 2011 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6076 |
|
This document defines a set of metrics and their usage to evaluate the performance of end-to-end Session Initiation Protocol (SIP) for telephony services in both production and testing environments. The purpose of this document is to combine a standard set of common metrics, allowing interoperable performance measurements, easing the comparison of industry implementations. |
|
| |
| RFC 6080 | A Framework for Session Initiation Protocol User Agent Profile Delivery |
| |
| Authors: | D. Petrie, S. Channabasappa, Ed.. |
| Date: | March 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6080 |
|
This document specifies a framework to enable configuration ofSession Initiation Protocol (SIP) user agents (UAs) in SIP deployments. The framework provides a means to deliver profile data that user agents need to be functional, automatically and with minimal or no User and Administrative intervention. The framework describes how SIP user agents can discover sources, request profiles, and receive notifications related to profile modifications. As part of this framework, a new SIP event package is defined for notification of profile changes. The framework provides minimal data retrieval options to ensure interoperability. The framework does not include specification of the profile data within its scope. |
|
| |
| RFC 6081 | Teredo Extensions |
| |
|
|
This document specifies a set of extensions to the Teredo protocol.These extensions provide additional capabilities to Teredo, including support for more types of Network Address Translations (NATs) and support for more efficient communication. |
|
| |
| RFC 6083 | Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP) |
| |
| Authors: | M. Tuexen, R. Seggelmann, E. Rescorla. |
| Date: | January 2011 |
| Formats: | txt json html |
| Updated by: | RFC 8996 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6083 |
|
This document describes the usage of the Datagram Transport LayerSecurity (DTLS) protocol over the Stream Control TransmissionProtocol (SCTP).
DTLS over SCTP provides communications privacy for applications that use SCTP as their transport protocol and allows client/server applications to communicate in a way that is designed to prevent eavesdropping and detect tampering or message forgery.
Applications using DTLS over SCTP can use almost all transport features provided by SCTP and its extensions. |
|
| |
| RFC 6085 | Address Mapping of IPv6 Multicast Packets on Ethernet |
| |
| Authors: | S. Gundavelli, M. Townsley, O. Troan, W. Dec. |
| Date: | January 2011 |
| Formats: | txt html json |
| Updates: | RFC 2464 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6085 |
|
When transmitting an IPv6 packet with a multicast destination address, the IPv6 destination address is mapped to an Ethernet link- layer multicast address. This document clarifies that a mapping of an IPv6 packet with a multicast destination address may in some circumstances map to an Ethernet link-layer unicast address. |
|
| |
| RFC 6086 | Session Initiation Protocol (SIP) INFO Method and Package Framework |
| |
| Authors: | C. Holmberg, E. Burger, H. Kaplan. |
| Date: | January 2011 |
| Formats: | txt json html |
| Obsoletes: | RFC 2976 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6086 |
|
This document defines a method, INFO, for the Session InitiationProtocol (SIP), and an Info Package mechanism. This document obsoletes RFC 2976. For backward compatibility, this document also specifies a "legacy" mode of usage of the INFO method that is compatible with the usage previously defined in RFC 2976, referred to as "legacy INFO Usage" in this document. |
|
| |
| RFC 6088 | Traffic Selectors for Flow Bindings |
| |
| Authors: | G. Tsirtsis, G. Giarreta, H. Soliman, N. Montavont. |
| Date: | January 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6088 |
|
This document defines binary formats for IPv4 and IPv6 traffic selectors to be used in conjunction with flow bindings for MobileIPv6. |
|
| |
| RFC 6089 | Flow Bindings in Mobile IPv6 and Network Mobility (NEMO) Basic Support |
| |
| Authors: | G. Tsirtsis, H. Soliman, N. Montavont, G. Giaretta, K. Kuladinithi. |
| Date: | January 2011 |
| Formats: | txt html json |
| Updates: | RFC 5648 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6089 |
|
This document introduces extensions to Mobile IPv6 that allow nodes to bind one or more flows to a care-of address. These extensions allow multihomed nodes to instruct home agents and other Mobile IPv6 entities to direct inbound flows to specific addresses. |
|
| |
| RFC 6093 | On the Implementation of the TCP Urgent Mechanism |
| |
|
|
This document analyzes how current TCP implementations process TCP urgent indications and how the behavior of some widely deployed middleboxes affects how end systems process urgent indications. This document updates the relevant specifications such that they accommodate current practice in processing TCP urgent indications, raises awareness about the reliability of TCP urgent indications in the Internet, and recommends against the use of urgent indications(but provides advice to applications that do). |
|
| |
| RFC 6096 | Stream Control Transmission Protocol (SCTP) Chunk Flags Registration |
| |
|
|
This document defines the procedure for registering chunk flags with the Internet Assigned Numbers Authority (IANA) for the Stream ControlTransmission Protocol (SCTP). It updates RFC 4960 and also defines the IANA registry for contents for currently defined chunk types. It does not change SCTP in any other way. |
|
| |
| RFC 6098 | Generic Notification Message for Mobile IPv4 |
| |
| Authors: | H. Deng, H. Levkowetz, V. Devarapalli, S. Gundavelli, B. Haley. |
| Date: | April 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6098 |
|
This document specifies protocol enhancements that allow Mobile IPv4 entities to send and receive explicit notification messages using aMobile IPv4 message type designed for this purpose. |
|
| |
| RFC 6106 | IPv6 Router Advertisement Options for DNS Configuration |
| |
| Authors: | J. Jeong, S. Park, L. Beloeil, S. Madanapalli. |
| Date: | November 2010 |
| Formats: | txt json html |
| Obsoletes: | RFC 5006 |
| Obsoleted by: | RFC 8106 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6106 |
|
This document specifies IPv6 Router Advertisement options to allowIPv6 routers to advertise a list of DNS recursive server addresses and a DNS Search List to IPv6 hosts. |
|
| |
| RFC 6107 | Procedures for Dynamically Signaled Hierarchical Label Switched Paths |
| |
|
|
Label Switched Paths (LSPs) set up in Multiprotocol Label Switching(MPLS) or Generalized MPLS (GMPLS) networks can be used to form links to carry traffic in those networks or in other (client) networks.
Protocol mechanisms already exist to facilitate the establishment of such LSPs and to bundle traffic engineering (TE) links to reduce the load on routing protocols. This document defines extensions to those mechanisms to support identifying the use to which such LSPs are to be put and to enable the TE link endpoints to be assigned addresses or unnumbered identifiers during the signaling process.
The mechanisms defined in this document deprecate the technique for the signaling of LSPs that are to be used as numbered TE links described in RFC 4206. |
|
| |
| RFC 6110 | Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content |
| |
|
|
This document specifies the mapping rules for translating YANG data models into Document Schema Definition Languages (DSDL), a coordinated set of XML schema languages standardized as ISO/IEC19757. The following DSDL schema languages are addressed by the mapping: Regular Language for XML Next Generation (RELAX NG),Schematron, and Schematron and Document Schema Renaming Language(DSRL). The mapping takes one or more YANG modules and produces a set of DSDL schemas for a selected target document type -- datastore content, Network Configuration Protocol (NETCONF) messages, etc.Procedures for schema-based validation of such documents are also discussed. |
|
| |
| RFC 6111 | Additional Kerberos Naming Constraints |
| |
|
|
This document defines new naming constraints for well-known Kerberos principal names and well-known Kerberos realm names. |
|
| |
| RFC 6113 | A Generalized Framework for Kerberos Pre-Authentication |
| |
|
|
Kerberos is a protocol for verifying the identity of principals(e.g., a workstation user or a network server) on an open network.The Kerberos protocol provides a facility called pre-authentication.Pre-authentication mechanisms can use this facility to extend theKerberos protocol and prove the identity of a principal.
This document describes a more formal model for this facility. The model describes what state in the Kerberos request a pre- authentication mechanism is likely to change. It also describes how multiple pre-authentication mechanisms used in the same request will interact.
This document also provides common tools needed by multiple pre- authentication mechanisms. One of these tools is a secure channel between the client and the key distribution center with a reply key strengthening mechanism; this secure channel can be used to protect the authentication exchange and thus eliminate offline dictionary attacks. With these tools, it is relatively straightforward to chain multiple authentication mechanisms, utilize a different key management system, or support a new key agreement algorithm. |
|
| |
| RFC 6116 | The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM) |
| |
| Authors: | S. Bradner, L. Conroy, K. Fujiwara. |
| Date: | March 2011 |
| Formats: | txt json html |
| Obsoletes: | RFC 3761 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6116 |
|
This document discusses the use of the Domain Name System (DNS) for storage of data associated with E.164 numbers, and for resolving those numbers into URIs that can be used (for example) in telephony call setup. This document also describes how the DNS can be used to identify the services associated with an E.164 number. This document obsoletes RFC 3761. |
|
| |
| RFC 6117 | IANA Registration of Enumservices: Guide, Template, and IANA Considerations |
| |
| Authors: | B. Hoeneisen, A. Mayrhofer, J. Livingood. |
| Date: | March 2011 |
| Formats: | txt json html |
| Obsoletes: | RFC 3761 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6117 |
|
This document specifies a revision of the IANA RegistrationGuidelines for Enumservices, describes corresponding registration procedures, and provides a guideline for creating EnumserviceSpecifications. |
|
| |
| RFC 6118 | Update of Legacy IANA Registrations of Enumservices |
| |
| Authors: | B. Hoeneisen, A. Mayrhofer. |
| Date: | March 2011 |
| Formats: | txt html json |
| Updates: | RFC 3762, RFC 3764, RFC 3953, RFC 4143, RFC 4002, RFC 4238, RFC 4355, RFC 4415, RFC 4769, RFC 4969, RFC 4979, RFC 5028, RFC 5278, RFC 5333 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6118 |
|
This document revises all Enumservices that were IANA registered under the now obsolete specification of the Enumservice registry defined in RFC 3761. |
|
| |
| RFC 6119 | IPv6 Traffic Engineering in IS-IS |
| |
| Authors: | J. Harrison, J. Berger, M. Bartlett. |
| Date: | February 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6119 |
|
This document specifies a method for exchanging IPv6 traffic engineering information using the IS-IS routing protocol. This information enables routers in an IS-IS network to calculate traffic- engineered routes using IPv6 addresses. |
|
| |
| RFC 6120 | Extensible Messaging and Presence Protocol (XMPP): Core |
| |
|
|
The Extensible Messaging and Presence Protocol (XMPP) is an application profile of the Extensible Markup Language (XML) that enables the near-real-time exchange of structured yet extensible data between any two or more network entities. This document definesXMPP's core protocol methods: setup and teardown of XML streams, channel encryption, authentication, error handling, and communication primitives for messaging, network availability ("presence"), and request-response interactions. This document obsoletes RFC 3920. |
|
| |
| RFC 6121 | Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence |
| |
|
|
This document defines extensions to core features of the ExtensibleMessaging and Presence Protocol (XMPP) that provide basic instant messaging (IM) and presence functionality in conformance with the requirements in RFC 2779. This document obsoletes RFC 3921. |
|
| |
| RFC 6122 | Extensible Messaging and Presence Protocol (XMPP): Address Format |
| |
|
|
This document defines the format for addresses used in the ExtensibleMessaging and Presence Protocol (XMPP), including support for non-ASCII characters. This document updates RFC 3920. |
|
| |
| RFC 6125 | Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS) |
| |
| Authors: | P. Saint-Andre, J. Hodges. |
| Date: | March 2011 |
| Formats: | txt html json |
| Obsoleted by: | RFC 9525 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6125 |
|
Many application technologies enable secure communication between two entities by means of Internet Public Key Infrastructure Using X.509(PKIX) certificates in the context of Transport Layer Security (TLS).This document specifies procedures for representing and verifying the identity of application services in such interactions. |
|
| |
| RFC 6128 | RTP Control Protocol (RTCP) Port for Source-Specific Multicast (SSM) Sessions |
| |
|
|
The Session Description Protocol (SDP) has an attribute that allowsRTP applications to specify an address and a port associated with theRTP Control Protocol (RTCP) traffic. In RTP-based source-specific multicast (SSM) sessions, the same attribute is used to designate the address and the RTCP port of the Feedback Target in the SDP description. However, the RTCP port associated with the SSM session itself cannot be specified by the same attribute to avoid ambiguity, and thus, is required to be derived from the "m=" line of the media description. Deriving the RTCP port from the "m=" line imposes an unnecessary restriction. This document removes this restriction by introducing a new SDP attribute. |
|
| |
| RFC 6130 | Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP) |
| |
|
|
This document describes a 1-hop and symmetric 2-hop neighborhood discovery protocol (NHDP) for mobile ad hoc networks (MANETs). |
|
| |
| RFC 6131 | Sieve Vacation Extension: "Seconds" Parameter |
| |
| Authors: | R. George, B. Leiba. |
| Date: | July 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6131 |
|
This document describes a further extension to the Sieve Vacation extension, allowing multiple auto-replies to the same sender in a single day by adding a ":seconds" parameter. |
|
| |
| RFC 6132 | Sieve Notification Using Presence Information |
| |
| Authors: | R. George, B. Leiba. |
| Date: | July 2011 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6132 |
|
This is a further extension to the Sieve mail filtering languageNotification extension, defining presence information that may be checked through the notify_method_capability feature. |
|
| |
| RFC 6134 | Sieve Extension: Externally Stored Lists |
| |
| Authors: | A. Melnikov, B. Leiba. |
| Date: | July 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6134 |
|
The Sieve email filtering language can be used to implement email whitelisting, blacklisting, personal distribution lists, and other sorts of list matching. Currently, this requires that all members of such lists be hard-coded in the script itself. Whenever a member of a list is added or deleted, the script needs to be updated and possibly uploaded to a mail server.
This document defines a Sieve extension for accessing externally stored lists -- lists whose members are stored externally to the script, such as using the Lightweight Directory Access Protocol(LDAP), the Application Configuration Access Protocol (ACAP), vCardExtensions to WebDAV (CardDAV), or relational databases. |
|
| |
| RFC 6135 | An Alternative Connection Model for the Message Session Relay Protocol (MSRP) |
| |
| Authors: | C. Holmberg, S. Blau. |
| Date: | February 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6135 |
|
This document defines an alternative connection model for MessageSession Relay Protocol (MSRP) User Agents (UAs); this model uses the connection-oriented media (COMEDIA) mechanism in order to create theMSRP transport connection. The model allows MSRP UAs behind NetworkAddress Translators (NATs) to negotiate which endpoint initiates the establishment of the Transmission Control Protocol (TCP) connection, in order for MSRP messages to traverse the NAT. |
|
| |
| RFC 6140 | Registration for Multiple Phone Numbers in the Session Initiation Protocol (SIP) |
| |
|
|
This document defines a mechanism by which a Session InitiationProtocol (SIP) server acting as a traditional Private Branch Exchange(PBX) can register with a SIP Service Provider (SSP) to receive phone calls for SIP User Agents (UAs). In order to function properly, this mechanism requires that each of the Addresses of Record (AORs) registered in bulk map to a unique set of contacts. This requirement is satisfied by AORs representing phone numbers regardless of the domain, since phone numbers are fully qualified and globally unique.This document therefore focuses on this use case. |
|
| |
| RFC 6141 | Re-INVITE and Target-Refresh Request Handling in the Session Initiation Protocol (SIP) |
| |
| Authors: | G. Camarillo, Ed., C. Holmberg, Y. Gao. |
| Date: | March 2011 |
| Formats: | txt json html |
| Updates: | RFC 3261 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6141 |
|
The procedures for handling SIP re-INVITEs are described in RFC 3261.Implementation and deployment experience has uncovered a number of issues with the original documentation, and this document provides additional procedures that update the original specification to address those issues. In particular, this document defines in which situations a UAS (User Agent Server) should generate a success response and in which situations a UAS should generate an error response to a re-INVITE. Additionally, this document defines further details of procedures related to target-refresh requests. |
|
| |
| RFC 6145 | IP/ICMP Translation Algorithm |
| |
|
|
This document describes the Stateless IP/ICMP Translation Algorithm(SIIT), which translates between IPv4 and IPv6 packet headers(including ICMP headers). This document obsoletes RFC 2765. |
|
| |
| RFC 6146 | Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers |
| |
| Authors: | M. Bagnulo, P. Matthews, I. van Beijnum. |
| Date: | April 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6146 |
|
This document describes stateful NAT64 translation, which allowsIPv6-only clients to contact IPv4 servers using unicast UDP, TCP, orICMP. One or more public IPv4 addresses assigned to a NAT64 translator are shared among several IPv6-only clients. When statefulNAT64 is used in conjunction with DNS64, no changes are usually required in the IPv6 client or the IPv4 server. |
|
| |
| RFC 6147 | DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers |
| |
| Authors: | M. Bagnulo, A. Sullivan, P. Matthews, I. van Beijnum. |
| Date: | April 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6147 |
|
DNS64 is a mechanism for synthesizing AAAA records from A records.DNS64 is used with an IPv6/IPv4 translator to enable client-server communication between an IPv6-only client and an IPv4-only server, without requiring any changes to either the IPv6 or the IPv4 node, for the class of applications that work through NATs. This document specifies DNS64, and provides suggestions on how it should be deployed in conjunction with IPv6/IPv4 translators. |
|
| |
| RFC 6148 | DHCPv4 Lease Query by Relay Agent Remote ID |
| |
| Authors: | P. Kurapati, R. Desetti, B. Joshi. |
| Date: | February 2011 |
| Formats: | txt json html |
| Updates: | RFC 4388 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6148 |
|
Some relay agents extract lease information from the DHCP messages exchanged between the client and DHCP server. This lease information is used by relay agents for various purposes like antispoofing and prevention of flooding. RFC 4388 defines a mechanism for relay agents to retrieve the lease information from the DHCP server when this information is lost. The existing lease query mechanism is data-driven, which means that a relay agent can initiate the lease query only when it starts receiving data to and from the clients. In certain scenarios, this model is not scalable. This document first looks at issues in the existing mechanism and then proposes a new query type, query by Remote ID, to address these issues. |
|
| |
| RFC 6153 | DHCPv4 and DHCPv6 Options for Access Network Discovery and Selection Function (ANDSF) Discovery |
| |
| Authors: | S. Das, G. Bajko. |
| Date: | February 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6153 |
|
This document defines new Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) options to enable a mobile node to discover AccessNetwork Discovery and Selection Function (ANDSF) entities in an IP network. ANDSF is being developed in the Third GenerationPartnership Project (3GPP) and provides inter-system mobility policies and access-network-specific information to the mobile nodes(MNs). |
|
| |
| RFC 6154 | IMAP LIST Extension for Special-Use Mailboxes |
| |
| Authors: | B. Leiba, J. Nicolson. |
| Date: | March 2011 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6154 |
|
Some IMAP message stores include special-use mailboxes, such as those used to hold draft messages or sent messages. Many mail clients allow users to specify where draft or sent messages should be put, but configuring them requires that the user know which mailboxes the server has set aside for these purposes. This extension adds new optional mailbox attributes that a server may include in IMAP LIST command responses to identify special-use mailboxes to the client, easing configuration. |
|
| |
| RFC 6155 | Use of Device Identity in HTTP-Enabled Location Delivery (HELD) |
| |
| Authors: | J. Winterbottom, M. Thomson, H. Tschofenig, R. Barnes. |
| Date: | March 2011 |
| Formats: | txt json html |
| Updated by: | RFC 6915 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6155 |
|
When a Location Information Server receives a request for location information (using the locationRequest message), described in the base HTTP-Enabled Location Delivery (HELD) specification, it uses the source IP address of the arriving message as a pointer to the location determination process. This is sufficient in environments where the location of a Device can be determined based on its IP address.
Two additional use cases are addressed by this document. In the first, location configuration requires additional or alternative identifiers from the source IP address provided in the request. In the second, an entity other than the Device requests the location of the Device.
This document extends the HELD protocol to allow the location request message to carry Device identifiers. Privacy and security considerations describe the conditions where requests containing identifiers are permitted. |
|
| |
| RFC 6156 | Traversal Using Relays around NAT (TURN) Extension for IPv6 |
| |
| Authors: | G. Camarillo, O. Novo, S. Perreault, Ed.. |
| Date: | April 2011 |
| Formats: | txt html json |
| Obsoleted by: | RFC 8656 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6156 |
|
This document adds IPv6 support to Traversal Using Relays around NAT(TURN). IPv6 support in TURN includes IPv4-to-IPv6, IPv6-to-IPv6, and IPv6-to-IPv4 relaying. This document defines the REQUESTED-ADDRESS-FAMILY attribute for TURN. The REQUESTED-ADDRESS-FAMILY attribute allows a client to explicitly request the address type theTURN server will allocate (e.g., an IPv4-only node may request theTURN server to allocate an IPv6 address). |
|
| |
| RFC 6157 | IPv6 Transition in the Session Initiation Protocol (SIP) |
| |
| Authors: | G. Camarillo, K. El Malki, V. Gurbani. |
| Date: | April 2011 |
| Formats: | txt html json |
| Updates: | RFC 3264 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6157 |
|
This document describes how the IPv4 Session Initiation Protocol(SIP) user agents can communicate with IPv6 SIP user agents (and vice versa) at the signaling layer as well as exchange media once the session has been successfully set up. Both single- and dual-stack(i.e., IPv4-only and IPv4/IPv6) user agents are considered. |
|
| |
| RFC 6160 | Algorithms for Cryptographic Message Syntax (CMS) Protection of Symmetric Key Package Content Types |
| |
| Authors: | S. Turner. |
| Date: | April 2011 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6160 |
|
This document describes the conventions for using several cryptographic algorithms with the Cryptographic Message Syntax (CMS) to protect the symmetric key package content type. Specifically, it includes conventions necessary to implement SignedData,EnvelopedData, EncryptedData, and AuthEnvelopedData. |
|
| |
| RFC 6161 | Elliptic Curve Algorithms for Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type |
| |
|
|
This document describes the conventions for using several EllipticCurve cryptographic algorithms with the Cryptographic Message Syntax(CMS) encrypted key package content type. Specifically, it includes conventions necessary to implement Elliptic Curve Diffie-Hellman(ECDH) with EnvelopedData and Elliptic Curve Digital SignatureAlgorithm (ECDSA) with SignedData. This document extends RFC 6033. |
|
| |
| RFC 6162 | Elliptic Curve Algorithms for Cryptographic Message Syntax (CMS) Asymmetric Key Package Content Type |
| |
|
|
This document describes conventions for using Elliptic Curve cryptographic algorithms with SignedData and EnvelopedData to protect the AsymmetricKeyPackage content type. Specifically, it includes conventions necessary to implement Elliptic Curve Diffie-Hellman(ECDH) with EnvelopedData and Elliptic Curve Digital SignatureAlgorithm (ECDSA) with SignedData. This document extends RFC 5959. |
|
| |
| RFC 6164 | Using 127-Bit IPv6 Prefixes on Inter-Router Links |
| |
| Authors: | M. Kohno, B. Nitzan, R. Bush, Y. Matsuzaki, L. Colitti, T. Narten. |
| Date: | April 2011 |
| Formats: | txt json html |
| Updated by: | RFC 6547 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6164 |
|
On inter-router point-to-point links, it is useful, for security and other reasons, to use 127-bit IPv6 prefixes. Such a practice parallels the use of 31-bit prefixes in IPv4. This document specifies the motivation for, and usages of, 127-bit IPv6 prefix lengths on inter-router point-to-point links. |
|
| |
| RFC 6165 | Extensions to IS-IS for Layer-2 Systems |
| |
| Authors: | A. Banerjee, D. Ward. |
| Date: | April 2011 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6165 |
|
This document specifies the Intermediate System to IntermediateSystem (IS-IS) extensions necessary to support link state routing for any protocols running directly over Layer-2. While supporting this concept involves several pieces, this document only describes extensions to IS-IS. Furthermore, the Type, Length, Value pairs(TLVs) described in this document are generic Layer-2 additions, and specific ones as needed are defined in the IS-IS technology-specific extensions. We leave it to the systems using these IS-IS extensions to explain how the information carried in IS-IS is used. |
|
| |
| RFC 6166 | A Registry for PIM Message Types |
| |
|
|
This document provides instructions to IANA for the creation of a registry for PIM message types. It specifies the initial content of the registry, based on existing RFCs specifying PIM message types.It also specifies a procedure for registering new types.
In addition to this, one message type is reserved, and may be used for a future extension of the message type space. |
|
| |
| RFC 6170 | Internet X.509 Public Key Infrastructure -- Certificate Image |
| |
| Authors: | S. Santesson, R. Housley, S. Bajaj, L. Rosenthol. |
| Date: | May 2011 |
| Formats: | txt json html |
| Obsoleted by: | RFC 9399 |
| Updates: | RFC 3709 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6170 |
|
This document specifies a method to bind a visual representation of a certificate in the form of a certificate image to a public key certificate as defined in RFC 5280, by defining a new "otherLogos" image type according to RFC 3709. |
|
| |
| RFC 6171 | The Lightweight Directory Access Protocol (LDAP) Don't Use Copy Control |
| |
| Authors: | K. Zeilenga. |
| Date: | March 2011 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6171 |
|
This document defines the Lightweight Directory Access Protocol(LDAP) Don't Use Copy control extension, which allows a client to specify that copied information should not be used in providing service. This control is based upon the X.511 dontUseCopy service control option. |
|
| |
| RFC 6172 | Deprecation of the Internet Fibre Channel Protocol (iFCP) Address Translation Mode |
| |
|
|
Changes to Fibre Channel have caused the specification of theInternet Fibre Channel Protocol (iFCP) address translation mode to become incorrect. Due to the absence of usage of iFCP address translation mode, it is deprecated by this document. iFCP address transparent mode remains correctly specified. iFCP address transparent mode has been implemented and is in current use; therefore, it is not affected by this document.
This document also records the state of Protocol Number 133, which was allocated for a pre-standard version of the Fibre ChannelInternet Protocol (FCIP). |
|
| |
| RFC 6173 | Definitions of Managed Objects for the Internet Fibre Channel Protocol (iFCP) |
| |
|
|
This document defines Management Information Base (MIB) objects to monitor and control the Internet Fibre Channel Protocol (iFCP) gateway instances and their associated sessions, for use with network management protocols.
This document obsoletes RFC 4369. |
|
| |
| RFC 6176 | Prohibiting Secure Sockets Layer (SSL) Version 2.0 |
| |
|
|
This document requires that when Transport Layer Security (TLS) clients and servers establish connections, they never negotiate the use of Secure Sockets Layer (SSL) version 2.0. This document updates the backward compatibility sections found in the Transport LayerSecurity (TLS). |
|
| |
| RFC 6178 | Label Edge Router Forwarding of IPv4 Option Packets |
| |
| Authors: | D. Smith, J. Mullooly, W. Jaeger, T. Scholl. |
| Date: | March 2011 |
| Formats: | txt json html |
| Updates: | RFC 3031 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6178 |
|
This document specifies how Label Edge Routers (LERs) should behave when determining whether to MPLS encapsulate an IPv4 packet with header options. Lack of a formal standard has resulted in differentLER forwarding behaviors for IPv4 packets with header options despite being associated with a prefix-based Forwarding Equivalence Class(FEC). IPv4 option packets that belong to a prefix-based FEC, yet are forwarded into an IPv4/MPLS network without being MPLS- encapsulated, present a security risk against the MPLS infrastructure. Further, LERs that are unable to MPLS encapsulateIPv4 packets with header options cannot operate in certain MPLS environments. While this newly defined LER behavior is mandatory to implement, it is optional to invoke. |
|
| |
| RFC 6184 | RTP Payload Format for H.264 Video |
| |
| Authors: | Y.-K. Wang, R. Even, T. Kristensen, R. Jesup. |
| Date: | May 2011 |
| Formats: | txt json html |
| Obsoletes: | RFC 3984 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6184 |
|
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, excluding theScalable Video Coding (SVC) extension and the Multiview Video Coding extension, for which the RTP payload formats are defined elsewhere.The RTP payload format allows for packetization of one or moreNetwork Abstraction Layer 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 bitrate conversational usage, to Internet video streaming with interleaved transmission, to high bitrate video-on-demand.
This memo obsoletes RFC 3984. Changes from RFC 3984 are summarized in Section 14. Issues on backward compatibility to RFC 3984 are discussed in Section 15. |
|
| |
| RFC 6185 | RTP Payload Format for H.264 Reduced-Complexity Decoding Operation (RCDO) Video |
| |
| Authors: | T. Kristensen, P. Luthi. |
| Date: | May 2011 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6185 |
|
This document describes an RTP payload format for the Reduced-Complexity Decoding Operation (RCDO) for H.264 Baseline profile bitstreams, as specified in ITU-T Recommendation H.241. RCDO reduces the decoding cost and resource consumption of the video processing.The RCDO RTP payload format is based on the H.264 RTP payload format. |
|
| |
| RFC 6186 | Use of SRV Records for Locating Email Submission/Access Services |
| |
|
|
This specification describes how SRV records can be used to locate email services. |
|
| |
| RFC 6187 | X.509v3 Certificates for Secure Shell Authentication |
| |
| Authors: | K. Igoe, D. Stebila. |
| Date: | March 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6187 |
|
X.509 public key certificates use a signature by a trusted certification authority to bind a given public key to a given digital identity. This document specifies how to use X.509 version 3 public key certificates in public key algorithms in the Secure Shell protocol. |
|
| |
| RFC 6188 | The Use of AES-192 and AES-256 in Secure RTP |
| |
| Authors: | D. McGrew. |
| Date: | March 2011 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6188 |
|
This memo describes the use of the Advanced Encryption Standard (AES) with 192- and 256-bit keys within the Secure RTP (SRTP) protocol. It details counter mode encryption for SRTP and Secure RealtimeTransport Control Protocol (SRTCP) and a new SRTP Key DerivationFunction (KDF) for AES-192 and AES-256. |
|
| |
| RFC 6190 | RTP Payload Format for Scalable Video Coding |
| |
| Authors: | S. Wenger, Y.-K. Wang, T. Schierl, A. Eleftheriadis. |
| Date: | May 2011 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6190 |
|
This memo describes an RTP payload format for Scalable Video Coding(SVC) as defined in Annex G of ITU-T Recommendation H.264, which is technically identical to Amendment 3 of ISO/IEC InternationalStandard 14496-10. The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload, as well as fragmentation of a NAL unit in multipleRTP packets. Furthermore, it supports transmission of an SVC stream over a single as well as multiple RTP sessions. The payload format defines a new media subtype name "H264-SVC", but is still backward compatible to RFC 6184 since the base layer, when encapsulated in its own RTP stream, must use the H.264 media subtype name ("H264") and the packetization method specified in RFC 6184. The payload format has wide applicability in videoconferencing, Internet video streaming, and high-bitrate entertainment-quality video, among others. |
|
| |
| RFC 6196 | Moving mailserver: URI Scheme to Historic |
| |
|
|
This document registers the mailserver: URI scheme as historic in theIANA URI registry. |
|
| |
| RFC 6203 | IMAP4 Extension for Fuzzy Search |
| |
| Authors: | T. Sirainen. |
| Date: | March 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6203 |
|
This document describes an IMAP protocol extension enabling a server to perform searches with inexact matching and assigning relevancy scores for matched messages. |
|
| |
| RFC 6205 | Generalized Labels for Lambda-Switch-Capable (LSC) Label Switching Routers |
| |
|
|
Technology in the optical domain is constantly evolving, and, as a consequence, new equipment providing lambda switching capability has been developed and is currently being deployed.
Generalized MPLS (GMPLS) is a family of protocols that can be used to operate networks built from a range of technologies including wavelength (or lambda) switching. For this purpose, GMPLS defined a wavelength label as only having significance between two neighbors.Global wavelength semantics are not considered.
In order to facilitate interoperability in a network composed of next generation lambda-switch-capable equipment, this document defines a standard lambda label format that is compliant with the DenseWavelength Division Multiplexing (DWDM) and Coarse WavelengthDivision Multiplexing (CWDM) grids defined by the InternationalTelecommunication Union Telecommunication Standardization Sector.The label format defined in this document can be used in GMPLS signaling and routing protocols. |
|
| |
| RFC 6206 | The Trickle Algorithm |
| |
| Authors: | P. Levis, T. Clausen, J. Hui, O. Gnawali, J. Ko. |
| Date: | March 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6206 |
|
The Trickle algorithm allows nodes in a lossy shared medium (e.g., low-power and lossy networks) to exchange information in a highly robust, energy efficient, simple, and scalable manner. Dynamically adjusting transmission windows allows Trickle to spread new information on the scale of link-layer transmission times while sending only a few messages per hour when information does not change. A simple suppression mechanism and transmission point selection allow Trickle's communication rate to scale logarithmically with density. This document describes the Trickle algorithm and considerations in its use. |
|
| |
| RFC 6211 | Cryptographic Message Syntax (CMS) Algorithm Identifier Protection Attribute |
| |
| Authors: | J. Schaad. |
| Date: | April 2011 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6211 |
|
The Cryptographic Message Syntax (CMS), unlike X.509/PKIX certificates, is vulnerable to algorithm substitution attacks. In an algorithm substitution attack, the attacker changes either the algorithm being used or the parameters of the algorithm in order to change the result of a signature verification process. In X.509 certificates, the signature algorithm is protected because it is duplicated in the TBSCertificate.signature field with the proviso that the validator is to compare both fields as part of the signature validation process. This document defines a new attribute that contains a copy of the relevant algorithm identifiers so that they are protected by the signature or authentication process. |
|
| |
| RFC 6212 | Authentication-Results Registration for Vouch by Reference Results |
| |
| Authors: | M. Kucherawy. |
| Date: | April 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6212 |
|
This memo updates the registry of properties in Authentication-Results: message header fields to allow relaying of the results of aVouch By Reference query. |
|
| |
| RFC 6213 | IS-IS BFD-Enabled TLV |
| |
| Authors: | C. Hopps, L. Ginsberg. |
| Date: | April 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6213 |
|
This document describes a type-length-value (TLV) for use in the IS-IS routing protocol that allows for the proper use of theBidirectional Forwarding Detection (BFD) protocol. There exist certain scenarios in which IS-IS will not react appropriately to aBFD-detected forwarding plane failure without use of either this TLV or some other method. |
|
| |
| RFC 6221 | Lightweight DHCPv6 Relay Agent |
| |
| Authors: | D. Miles, Ed., S. Ooghe, W. Dec, S. Krishnan, A. Kavanagh. |
| Date: | May 2011 |
| Formats: | txt json html |
| Updates: | RFC 3315 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6221 |
|
This document proposes a Lightweight DHCPv6 Relay Agent (LDRA) that is used to insert relay agent options in DHCPv6 message exchanges identifying client-facing interfaces. The LDRA can be implemented in existing access nodes (such as Digital Subscriber Link AccessMultiplexers (DSLAMs) and Ethernet switches) that do not support IPv6 control or routing functions. |
|
| |
| RFC 6222 | Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs) |
| |
|
|
The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a persistent transport-level identifier for an RTP endpoint. While theSynchronization Source (SSRC) identifier of an RTP endpoint may change if a collision is detected or when the RTP application is restarted, its RTCP CNAME is meant to stay unchanged, so that RTP endpoints can be uniquely identified and associated with their RTP media streams. For proper functionality, RTCP CNAMEs should be unique within the participants of an RTP session. However, the existing guidelines for choosing the RTCP CNAME provided in the RTP standard are insufficient to achieve this uniqueness. This memo updates those guidelines to allow endpoints to choose unique RTCPCNAMEs. |
|
| |
| RFC 6223 | Indication of Support for Keep-Alive |
| |
| Authors: | C. Holmberg. |
| Date: | April 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6223 |
|
This specification defines a new Session Initiation Protocol (SIP)Via header field parameter, "keep", which allows adjacent SIP entities to explicitly negotiate usage of the Network AddressTranslation (NAT) keep-alive mechanisms defined in SIP Outbound, in cases where SIP Outbound is not supported, cannot be applied, or where usage of keep-alives is not implicitly negotiated as part of the SIP Outbound negotiation. |
|
| |
| RFC 6225 | Dynamic Host Configuration Protocol Options for Coordinate-Based Location Configuration Information |
| |
| Authors: | J. Polk, M. Linsner, M. Thomson, B. Aboba, Ed.. |
| Date: | July 2011 |
| Formats: | txt json html |
| Obsoletes: | RFC 3825 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6225 |
|
This document specifies Dynamic Host Configuration Protocol options(both DHCPv4 and DHCPv6) for the coordinate-based geographic location of the client. The Location Configuration Information (LCI) includesLatitude, Longitude, and Altitude, with resolution or uncertainty indicators for each. Separate parameters indicate the reference datum for each of these values. This document obsoletes RFC 3825. |
|
| |
| RFC 6226 | PIM Group-to-Rendezvous-Point Mapping |
| |
| Authors: | B. Joshi, A. Kessler, D. McWalter. |
| Date: | May 2011 |
| Formats: | txt html json |
| Updates: | RFC 4601 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6226 |
|
Each Protocol Independent Multicast - Sparse Mode (PIM-SM) router in a PIM domain that supports Any Source Multicast (ASM) maintainsGroup-to-RP mappings that are used to identify a Rendezvous Point(RP) for a specific multicast group. PIM-SM has defined an algorithm to choose a RP from the Group-to-RP mappings learned using various mechanisms. This algorithm does not consider the PIM mode and the mechanism through which a Group-to-RP mapping was learned.
This document defines a standard algorithm to deterministically choose between several Group-to-RP mappings for a specific group.This document first explains the requirements to extend the Group-to-RP mapping algorithm and then proposes the new algorithm. |
|
| |
| RFC 6228 | Session Initiation Protocol (SIP) Response Code for Indication of Terminated Dialog |
| |
| Authors: | C. Holmberg. |
| Date: | May 2011 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6228 |
|
This specification defines a new Session Initiation Protocol (SIP) response code, 199 Early Dialog Terminated, that a SIP forking proxy and a User Agent Server (UAS) can use to indicate to upstream SIP entities (including the User Agent Client (UAC)) that an early dialog has been terminated, before a final response is sent towards the SIP entities. |
|
| |
| RFC 6230 | Media Control Channel Framework |
| |
| Authors: | C. Boulton, T. Melanchuk, S. McGlashan. |
| Date: | May 2011 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6230 |
|
This document describes a framework and protocol for application deployment where the application programming logic and media processing are distributed. This implies that application programming logic can seamlessly gain access to appropriate resources that are not co-located on the same physical network entity. The framework uses the Session Initiation Protocol (SIP) to establish an application-level control mechanism between application servers and associated external servers such as media servers.
The motivation for the creation of this framework is to provide an interface suitable to meet the requirements of a centralized conference system, where the conference system can be distributed, as defined by the XCON working group in the IETF. It is not, however, limited to this scope. |
|
| |
| RFC 6231 | An Interactive Voice Response (IVR) Control Package for the Media Control Channel Framework |
| |
| Authors: | S. McGlashan, T. Melanchuk, C. Boulton. |
| Date: | May 2011 |
| Formats: | txt json html |
| Updated by: | RFC 6623 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6231 |
|
This document defines a Media Control Channel Framework Package forInteractive Voice Response (IVR) dialog interaction on media connections and conferences. The package defines dialog management request elements for preparing, starting, and terminating dialog interactions, as well as associated responses and notifications.Dialog interactions are specified in a dialog language. This package defines a lightweight IVR dialog language (supporting prompt playback, runtime controls, Dual-Tone Multi-Frequency (DTMF) collection, and media recording) and allows other dialog languages to be used. The package also defines elements for auditing package capabilities and IVR dialogs. |
|
| |
| RFC 6232 | Purge Originator Identification TLV for IS-IS |
| |
|
|
At present, an IS-IS purge does not contain any information identifying the Intermediate System (IS) that generates the purge.This makes it difficult to locate the source IS.
To address this issue, this document defines a TLV to be added to purges to record the system ID of the IS generating it. Since normalLink State Protocol Data Unit (LSP) flooding does not change LSP contents, this TLV should propagate with the purge.
This document updates RFC 5301, RFC 5304, and RFC 5310. |
|
| |
| RFC 6233 | IS-IS Registry Extension for Purges |
| |
|
|
IANA maintains the "IS-IS TLV Codepoints" registry. This registry documents which TLVs can appear in different types of IS-IS ProtocolData Units (PDUs), but does not document which TLVs can be found in zero Remaining Lifetime Link State PDUs (LSPs), a.k.a. purges. This document extends the existing registry to record the set of TLVs that are permissible in purges and updates the rules for generating and processing purges in the presence of authentication. This document updates RFC 3563, RFC 5304, and RFC 5310. |
|
| |
| RFC 6236 | Negotiation of Generic Image Attributes in the Session Description Protocol (SDP) |
| |
| Authors: | I. Johansson, K. Jung. |
| Date: | May 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6236 |
|
This document proposes a new generic session setup attribute to make it possible to negotiate different image attributes such as image size. A possible use case is to make it possible for a low-end hand- held terminal to display video without the need to rescale the image, something that may consume large amounts of memory and processing power. The document also helps to maintain an optimal bitrate for video as only the image size that is desired by the receiver is transmitted. |
|
| |
| RFC 6240 | Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet (CEP) MIB Using SMIv2 |
| |
| Authors: | D. Zelig, Ed., R. Cohen, Ed., T. Nadeau, Ed.. |
| Date: | May 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6240 |
|
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 SynchronousOptical Network/Synchronous Digital Hierarchy (SONET/SDH) circuits over a Packet Switch Network (PSN). |
|
| |
| RFC 6241 | Network Configuration Protocol (NETCONF) |
| |
|
|
The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible MarkupLanguage (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletesRFC 4741. |
|
| |
| RFC 6242 | Using the NETCONF Protocol over Secure Shell (SSH) |
| |
|
|
This document describes a method for invoking and running the NetworkConfiguration Protocol (NETCONF) within a Secure Shell (SSH) session as an SSH subsystem. This document obsoletes RFC 4742. |
|
| |
| RFC 6243 | With-defaults Capability for NETCONF |
| |
| Authors: | A. Bierman, B. Lengyel. |
| Date: | June 2011 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6243 |
|
The Network Configuration Protocol (NETCONF) defines ways to read and edit configuration data from a NETCONF server. In some cases, part of this data may not be set by the NETCONF client, but rather a default value known to the server is used instead. In many situations the NETCONF client has a priori knowledge about default data, so the NETCONF server does not need to save it in a NETCONF configuration datastore or send it to the client in a retrieval operation reply. In other situations the NETCONF client will need this data from the server. Not all server implementations treat this default data the same way. This document defines a capability-based extension to the NETCONF protocol that allows the NETCONF client to identify how defaults are processed by the server, and also defines new mechanisms for client control of server processing of default data. |
|
| |
| RFC 6245 | Generic Routing Encapsulation (GRE) Key Extension for Mobile IPv4 |
| |
| Authors: | P. Yegani, K. Leung, A. Lior, K. Chowdhury, J. Navali. |
| Date: | May 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6245 |
|
The Generic Routing Encapsulation (GRE) specification contains a Key field, which MAY contain a value that is used to identify a particular GRE data stream. This specification defines a new MobileIP extension that is used to exchange the value to be used in the GREKey field. This extension further allows the Mobility Agents to set up the necessary protocol interfaces prior to receiving the mobile node traffic. The new extension allows a Foreign Agent to requestGRE tunneling without disturbing the Home Agent behavior specified for Mobile IPv4. GRE tunneling with the Key field allows the operators to have home networks that consist of multiple VirtualPrivate Networks (VPNs), which may have overlapping home addresses.When the tuple <Care of Address, Home Address, and Home AgentAddress&rt; is the same across multiple subscriber sessions, GRE tunneling will provide a means for the Foreign Agent and Home Agent to identify data streams for the individual sessions based on the GRE key. In the absence of this key identifier, the data streams cannot be distinguished from each other -- a significant drawback when usingIP-in-IP tunneling. |
|
| |
| RFC 6249 | Metalink/HTTP: Mirrors and Hashes |
| |
| Authors: | A. Bryan, N. McNab, T. Tsujikawa, P. Poeml, H. Nordstrom. |
| Date: | June 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6249 |
|
This document specifies Metalink/HTTP: Mirrors and CryptographicHashes in HTTP header fields, a different way to get information that is usually contained in the Metalink XML-based download description format. Metalink/HTTP describes multiple download locations(mirrors), Peer-to-Peer, cryptographic hashes, digital signatures, and other information using existing standards for HTTP header fields. Metalink clients can use this information to make file transfers more robust and reliable. Normative requirements forMetalink/HTTP clients and servers are described here. |
|
| |
| RFC 6262 | RTP Payload Format for IP-MR Speech Codec |
| |
| Authors: | S. Ikonin. |
| Date: | August 2011 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6262 |
|
This document specifies the payload format for packetization ofSPIRIT IP-MR encoded speech signals into the Real-time TransportProtocol (RTP). The payload format supports transmission of multiple frames per packet and introduces redundancy for robustness against packet loss and bit errors. |
|
| |
| RFC 6263 | Application Mechanism for Keeping Alive the NAT Mappings Associated with RTP / RTP Control Protocol (RTCP) Flows |
| |
| Authors: | X. Marjou, A. Sollaud. |
| Date: | June 2011 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6263 |
|
This document lists the different mechanisms that enable applications using the Real-time Transport Protocol (RTP) and the RTP ControlProtocol (RTCP) to keep their RTP Network Address Translator (NAT) mappings alive. It also makes a recommendation for a preferred mechanism. This document is not applicable to InteractiveConnectivity Establishment (ICE) agents. |
|
| |
| RFC 6265 | HTTP State Management Mechanism |
| |
|
|
This document defines the HTTP Cookie and Set-Cookie header fields.These header fields can be used by HTTP servers to store state(called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol. Although cookies have many historical infelicities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet. This document obsoletes RFC 2965. |
|
| |
| RFC 6266 | Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP) |
| |
|
|
RFC 2616 defines the Content-Disposition response header field, but points out that it is not part of the HTTP/1.1 Standard. This specification takes over the definition and registration of Content-Disposition, as used in HTTP, and clarifies internationalization aspects. |
|
| |
| RFC 6270 | The 'tn3270' URI Scheme |
| |
|
|
This document is the specification of the 'tn3270' Uniform ResourceIdentifier (URI) scheme, which is used to designate the access to the resources available via Telnet 3270 mode (TN3270) and Telnet 3270Enhanced mode (TN3270E). It updates RFC 1041 and RFC 2355, which specify these protocols, and RFC 1738, which firstly mentioned thisURI scheme without defining its syntax and semantics. |
|
| |
| RFC 6275 | Mobility Support in IPv6 |
| |
| Authors: | C. Perkins, Ed., D. Johnson, J. Arkko. |
| Date: | July 2011 |
| Formats: | txt html json |
| Obsoletes: | RFC 3775 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6275 |
|
This document specifies Mobile IPv6, a protocol that 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 enablesIPv6 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. This document obsoletes RFC 3775. |
|
| |
| RFC 6276 | DHCPv6 Prefix Delegation for Network Mobility (NEMO) |
| |
| Authors: | R. Droms, P. Thubert, F. Dupont, W. Haddad, C. Bernardos. |
| Date: | July 2011 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6276 |
|
One aspect of network mobility support is the assignment of a prefix or prefixes to a mobile router for use on the links in the mobile network. This document specifies how DHCPv6 prefix delegation can be used for this configuration task. The mobile router plays the role of requesting router, while the home agent assumes the role of delegating router. When the mobile router is outside its home network, the mobile router also assumes the role of DHCPv6 relay agent, co-located with the requesting router function. |
|
| |
| RFC 6277 | Online Certificate Status Protocol Algorithm Agility |
| |
|
|
The Online Certificate Status Protocol (OCSP) requires server responses to be signed but does not specify a mechanism for selecting the signature algorithm to be used. This may lead to avoidable interoperability failures in contexts where multiple signature algorithms are in use. This document specifies rules for server signature algorithm selection and an extension that allows a client to advise a server that specific signature algorithms are supported. |
|
| |
| RFC 6282 | Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks |
| |
|
|
This document updates RFC 4944, "Transmission of IPv6 Packets overIEEE 802.15.4 Networks". This document specifies an IPv6 header compression format for IPv6 packet delivery in Low Power WirelessPersonal Area Networks (6LoWPANs). The compression format relies on shared context to allow compression of arbitrary prefixes. How the information is maintained in that shared context is out of scope.This document specifies compression of multicast addresses and a framework for compressing next headers. UDP header compression is specified within this framework. |
|
| |
| RFC 6283 | Extensible Markup Language Evidence Record Syntax (XMLERS) |
| |
| Authors: | A. Jerman Blazic, S. Saljic, T. Gondrom. |
| Date: | July 2011 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6283 |
|
In many scenarios, users must be able to demonstrate the (time of) existence, integrity, and validity of data including signed data for long or undetermined periods of time. This document specifies XML syntax and processing rules for creating evidence for long-term non- repudiation of existence and integrity of data. The ExtensibleMarkup Language Evidence Record Syntax XMLERS provides alternative syntax and processing rules to the ASN.1 (Abstract Syntax NotationOne) ERS (Evidence Record Syntax) (RFC 4998) syntax by using XML. |
|
| |
| RFC 6284 | Port Mapping between Unicast and Multicast RTP Sessions |
| |
| Authors: | A. Begen, D. Wing, T. Van Caenegem. |
| Date: | June 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6284 |
|
This document presents a port mapping solution that allows RTP receivers to choose their own ports for an auxiliary unicast session in RTP applications using both unicast and multicast services. The solution provides protection against denial-of-service or packet amplification attacks that could be used to cause one or more RTP packets to be sent to a victim client. |
|
| |
| RFC 6285 | Unicast-Based Rapid Acquisition of Multicast RTP Sessions |
| |
| Authors: | B. Ver Steeg, A. Begen, T. Van Caenegem, Z. Vax. |
| Date: | June 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6285 |
|
When an RTP receiver joins a multicast session, it may need to acquire and parse certain Reference Information before it can process any data sent in the multicast session. Depending on the join time, length of the Reference Information repetition (or appearance) interval, size of the Reference Information, and the application and transport properties, the time lag before an RTP receiver can usefully consume the multicast data, which we refer to as theAcquisition Delay, varies and can be large. This is an undesirable phenomenon for receivers that frequently switch among different multicast sessions, such as video broadcasts.
In this document, we describe a method using the existing RTP and RTPControl Protocol (RTCP) machinery that reduces the acquisition delay.In this method, an auxiliary unicast RTP session carrying theReference Information to the receiver precedes or accompanies the multicast stream. This unicast RTP flow can be transmitted at a faster than natural bitrate to further accelerate the acquisition.The motivating use case for this capability is multicast applications that carry real-time compressed audio and video. However, this method can also be used in other types of multicast applications where the acquisition delay is long enough to be a problem. |
|
| |
| RFC 6286 | Autonomous-System-Wide Unique BGP Identifier for BGP-4 |
| |
|
|
To accommodate situations where the current requirements for the BGPIdentifier are not met, this document relaxes the definition of theBGP Identifier to be a 4-octet, unsigned, non-zero integer and relaxes the "uniqueness" requirement so that only Autonomous-System- wide (AS-wide) uniqueness of the BGP Identifiers is required. These revisions to the base BGP specification do not introduce any backward compatibility issues. This document updates RFC 4271. |
|
| |
| RFC 6290 | A Quick Crash Detection Method for the Internet Key Exchange Protocol (IKE) |
| |
| Authors: | Y. Nir, Ed., D. Wierbowski, F. Detienne, P. Sethi. |
| Date: | June 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6290 |
|
This document describes an extension to the Internet Key ExchangeProtocol version 2 (IKEv2) that allows for faster detection ofSecurity Association (SA) desynchronization using a saved token.
When an IPsec tunnel between two IKEv2 peers is disconnected due to a restart of one peer, it can take as much as several minutes for the other peer to discover that the reboot has occurred, thus delaying recovery. In this text, we propose an extension to the protocol that allows for recovery immediately following the restart. |
|
| |
| RFC 6295 | RTP Payload Format for MIDI |
| |
| Authors: | J. Lazzaro, J. Wawrzynek. |
| Date: | June 2011 |
| Formats: | txt html json |
| Obsoletes: | RFC 4695 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6295 |
|
This memo describes a Real-time Transport Protocol (RTP) payload format for the MIDI (Musical Instrument Digital Interface) command language. The format encodes all commands that may legally appear on a MIDI 1.0 DIN cable. The format is suitable for interactive applications (such as network musical performance) and content- delivery applications (such as file streaming). The format may be used over unicast and multicast UDP and TCP, and it defines tools for graceful recovery from packet loss. Stream behavior, including theMIDI rendering method, may be customized during session setup. The format also serves as a mode for the mpeg4-generic format, to support the MPEG 4 Audio Object Types for General MIDI, Downloadable SoundsLevel 2, and Structured Audio. This document obsoletes RFC 4695. |
|
| |
| RFC 6298 | Computing TCP's Retransmission Timer |
| |
|
|
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 inSection 4.2.3.1 of RFC 1122 and upgrades the requirement of supporting the algorithm from a SHOULD to a MUST. This document obsoletes RFC 2988. |
|
| |
| RFC 6307 | Encapsulation Methods for Transport of Fibre Channel Traffic over MPLS Networks |
| |
| Authors: | D. Black, Ed., L. Dunbar, Ed., M. Roth, R. Solomon. |
| Date: | April 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6307 |
|
A Fibre Channel pseudowire (PW) is used to carry Fibre Channel traffic over an MPLS network. This enables service providers to take advantage of MPLS to offer "emulated" Fibre Channel services. This document specifies the encapsulation of Fibre Channel traffic within a pseudowire. It also specifies the common procedures for using a PW to provide a Fibre Channel service. |
|
| |
| RFC 6309 | IANA Rules for MIKEY (Multimedia Internet KEYing) |
| |
|
|
This document clarifies and relaxes the IANA rules for MultimediaInternet KEYing (MIKEY). This document updates RFCs 3830, 4563,5410, and 6043; it obsoletes RFC 4909. |
|
| |
| RFC 6310 | Pseudowire (PW) Operations, Administration, and Maintenance (OAM) Message Mapping |
| |
| Authors: | M. Aissaoui, P. Busschbach, L. Martini, M. Morrow, T. Nadeau, Y(J). Stein. |
| Date: | July 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6310 |
|
This document specifies the mapping and notification of defect states between a pseudowire (PW) and the Attachment Circuits (ACs) of the end-to-end emulated service. It standardizes the behavior ofProvider Edges (PEs) with respect to PW and AC defects. It addressesATM, Frame Relay, Time Division Multiplexing (TDM), and SynchronousOptical Network / Synchronous Digital Hierarchy (SONET/SDH) PW services, carried over MPLS, MPLS/IP, and Layer 2 Tunneling Protocol version 3/IP (L2TPv3/IP) Packet Switched Networks (PSNs). |
|
| |
| RFC 6311 | Protocol Support for High Availability of IKEv2/IPsec |
| |
| Authors: | R. Singh, Ed., G. Kalyani, Y. Nir, Y. Sheffer, D. Zhang. |
| Date: | July 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6311 |
|
The IPsec protocol suite is widely used for business-critical network traffic. In order to make IPsec deployments highly available, more scalable, and failure-resistant, they are often implemented as IPsecHigh Availability (HA) clusters. However, there are many issues inIPsec HA clustering, and in particular in Internet Key ExchangeProtocol version 2 (IKEv2) clustering. An earlier document, "IPsecCluster Problem Statement", enumerates the issues encountered in theIKEv2/IPsec HA cluster environment. This document resolves these issues with the least possible change to the protocol.
This document defines an extension to the IKEv2 protocol to solve the main issues of "IPsec Cluster Problem Statement" in the commonly deployed hot standby cluster, and provides implementation advice for other issues. The main issues solved are the synchronization ofIKEv2 Message ID counters, and of IPsec replay counters. |
|
| |
| RFC 6313 | Export of Structured Data in IP Flow Information Export (IPFIX) |
| |
| Authors: | B. Claise, G. Dhandapani, P. Aitken, S. Yates. |
| Date: | July 2011 |
| Formats: | txt json html |
| Updates: | RFC 5102 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6313 |
|
This document specifies an extension to the IP Flow InformationExport (IPFIX) protocol specification in RFC 5101 and the IPFIX information model specified in RFC 5102 to support hierarchical structured data and lists (sequences) of Information Elements in data records. This extension allows definition of complex data structures such as variable-length lists and specification of hierarchical containment relationships between Templates. Finally, the semantics are provided in order to express the relationship among multiple list elements in a structured data record. |
|
| |
| RFC 6320 | Protocol for Access Node Control Mechanism in Broadband Networks |
| |
| Authors: | S. Wadhwa, J. Moisand, T. Haag, N. Voigt, T. Taylor, Ed.. |
| Date: | October 2011 |
| Formats: | txt html json |
| Updated by: | RFC 7256 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6320 |
|
This document describes the Access Node Control Protocol (ANCP).ANCP operates between a Network Access Server (NAS) and an AccessNode (e.g., a Digital Subscriber Line Access Multiplexer (DSLAM)) in a multi-service reference architecture in order to perform operations related to Quality of Service, service, and subscribers. Use cases for ANCP are documented in RFC 5851. As well as describing the baseANCP protocol, this document specifies capabilities for DigitalSubscriber Line (DSL) topology discovery, line configuration, and remote line connectivity testing. The design of ANCP allows for protocol extensions in other documents if they are needed to support other use cases and other access technologies.
ANCP is based on the General Switch Management Protocol version 3(GSMPv3) described in RFC 3292, but with many modifications and extensions, to the point that the two protocols are not interoperable. For this reason, ANCP was assigned a separate version number to distinguish it. |
|
| |
| RFC 6321 | xCal: The XML Format for iCalendar |
| |
|
|
This specification defines "xCal", an XML format for iCalendar data. |
|
| |
| RFC 6323 | Sender RTT Estimate Option for the Datagram Congestion Control Protocol (DCCP) |
| |
|
|
This document specifies an update to the round-trip time (RTT) estimation algorithm used for TFRC (TCP-Friendly Rate Control) congestion control by the Datagram Congestion Control Protocol(DCCP). It updates specifications for the CCID-3 and CCID-4Congestion Control IDs of DCCP.
The update addresses parameter-estimation problems occurring withTFRC-based DCCP congestion control. It uses a recommendation made in the original TFRC specification to avoid the inherent problems of receiver-based RTT sampling, by utilising higher-accuracy RTT samples already available at the sender.
It is integrated into the feature set of DCCP as an end-to-end negotiable extension. |
|
| |
| RFC 6325 | Routing Bridges (RBridges): Base Protocol Specification |
| |
| Authors: | R. Perlman, D. Eastlake 3rd, D. Dutt, S. Gai, A. Ghanwani. |
| Date: | July 2011 |
| Formats: | txt html json |
| Updated by: | RFC 6327, RFC 6439, RFC 7172, RFC 7177, RFC 7357, RFC 7179, RFC 7180, RFC 7455, RFC 7780, RFC 7783, RFC 8139, RFC 8249, RFC 8361, RFC 8377 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6325 |
|
Routing Bridges (RBridges) provide optimal pair-wise forwarding without configuration, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. They achieve these goals using IS-IS routing and encapsulation of traffic with a header that includes a hop count.
RBridges are compatible with previous IEEE 802.1 customer bridges as well as IPv4 and IPv6 routers and end nodes. They are as invisible to current IP routers as bridges are and, like routers, they terminate the bridge spanning tree protocol.
The design supports VLANs and the optimization of the distribution of multi-destination frames based on VLAN ID and based on IP-derived multicast groups. It also allows unicast forwarding tables at transit RBridges to be sized according to the number of RBridges(rather than the number of end nodes), which allows their forwarding tables to be substantially smaller than in conventional customer bridges. |
|
| |
| RFC 6326 | Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS |
| |
| Authors: | D. Eastlake, A. Banerjee, D. Dutt, R. Perlman, A. Ghanwani. |
| Date: | July 2011 |
| Formats: | txt json html |
| Obsoleted by: | RFC 7176 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6326 |
|
The IETF has standardized the Transparent Interconnection of Lots ofLinks (TRILL) protocol, which provides transparent Layer 2 forwarding using encapsulation with a hop count and IS-IS link state routing.This document specifies the data formats and code points for theIS-IS extensions to support TRILL. |
|
| |
| RFC 6327 | Routing Bridges (RBridges): Adjacency |
| |
|
|
The IETF TRILL (TRansparent Interconnection of Lots of Links) protocol provides optimal pair-wise data forwarding without configuration, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. TRILL accomplishes this by using IS-IS (Intermediate System to Intermediate System) link state routing and by encapsulating traffic using a header that includes a hop count. Devices that implement TRILL are called Routing Bridges (RBridges).
TRILL supports multi-access LAN (Local Area Network) links that can have multiple end stations and RBridges attached. This document describes four aspects of the TRILL LAN Hello protocol used on such links, particularly adjacency, designated RBridge selection, and MTU(Maximum Transmission Unit) and pseudonode procedures, with state machines. There is no change for IS-IS point-to-point Hellos used on links configured as point-to-point in TRILL. |
|
| |
| RFC 6329 | IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging |
| |
| Authors: | D. Fedyk, Ed., P. Ashwood-Smith, Ed., D. Allan, A. Bragg, P. Unbehagen. |
| Date: | April 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6329 |
|
802.1aq Shortest Path Bridging (SPB) has been standardized by theIEEE as the next step in the evolution of the various spanning tree and registration protocols. 802.1aq allows for true shortest path forwarding in a mesh Ethernet network context utilizing multiple equal cost paths. This permits it to support much larger Layer 2 topologies, with faster convergence, and vastly improved use of the mesh topology. Combined with this is single point provisioning for logical connectivity membership, which includes point-to-point, point-to-multipoint, and multipoint-to-multipoint variations. This memo documents the IS-IS changes required to support this IEEE protocol and provides some context and examples. |
|
| |
| RFC 6330 | RaptorQ Forward Error Correction Scheme for Object Delivery |
| |
| Authors: | M. Luby, A. Shokrollahi, M. Watson, T. Stockhammer, L. Minder. |
| Date: | August 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6330 |
|
This document describes a Fully-Specified Forward Error Correction(FEC) scheme, corresponding to FEC Encoding ID 6, for the RaptorQ FEC code and its application to reliable delivery of data objects.
RaptorQ codes are a new family of codes that provide superior flexibility, support for larger source block sizes, and better coding efficiency than Raptor codes in RFC 5053. RaptorQ is also a fountain code, i.e., as many encoding symbols as needed can be generated on the fly by the encoder from the source symbols of a source block of data. The decoder is able to recover the source block from almost any set of encoding symbols of sufficient cardinality -- in most cases, a set of cardinality equal to the number of source symbols is sufficient; in rare cases, a set of cardinality slightly more than the number of source symbols is required.
The RaptorQ code described here is a systematic code, meaning that all the source symbols are among the encoding symbols that can be generated. |
|
| |
| RFC 6332 | Multicast Acquisition Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs) |
| |
| Authors: | A. Begen, E. Friedrich. |
| Date: | July 2011 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6332 |
|
In most RTP-based multicast applications, the RTP source sends inter- related data. Due to this interdependency, randomly joining RTP receivers usually cannot start consuming the multicast data right after they join the session. Thus, they often experience a random acquisition delay. An RTP receiver can use one or more different approaches to achieve rapid acquisition. Yet, due to various factors, performance of the rapid acquisition methods usually varies.Furthermore, in some cases, the RTP receiver can do a simple multicast join (in other cases, it is compelled to do so). For quality reporting, monitoring, and diagnostic purposes, it is important to collect detailed information from the RTP receivers about their acquisition and presentation experiences. This document addresses this issue by defining a new report block type, called theMulticast Acquisition (MA) report block, within the framework of RTPControl Protocol (RTCP) Extended Reports (XRs) (RFC 3611). This document also defines the necessary signaling of the new MA report block type in the Session Description Protocol (SDP). |
|
| |
| RFC 6333 | Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion |
| |
| Authors: | A. Durand, R. Droms, J. Woodyatt, Y. Lee. |
| Date: | August 2011 |
| Formats: | txt json html |
| Updated by: | RFC 7335 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6333 |
|
This document revisits the dual-stack model and introduces the Dual-Stack Lite technology aimed at better aligning the costs and benefits of deploying IPv6 in service provider networks. Dual-Stack Lite enables a broadband service provider to share IPv4 addresses among customers by combining two well-known technologies: IP in IP (IPv4- in-IPv6) and Network Address Translation (NAT). |
|
| |
| RFC 6334 | Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite |
| |
| Authors: | D. Hankins, T. Mrugalski. |
| Date: | August 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6334 |
|
This document specifies a DHCPv6 option that is meant to be used by aDual-Stack Lite Basic Bridging BroadBand (B4) element to discover theIPv6 address of its corresponding Address Family Transition Router(AFTR). |
|
| |
| RFC 6336 | IANA Registry for Interactive Connectivity Establishment (ICE) Options |
| |
|
|
It has been identified that "Interactive Connectivity Establishment(ICE): A Protocol for Network Address Translator (NAT) Traversal forOffer/Answer Protocols" (RFC 5245) is missing a registry for ICE options. This document defines this missing IANA registry and updates RFC 5245. |
|
| |
| RFC 6339 | Context Token Encapsulate/Decapsulate and OID Comparison Functions for the Generic Security Service Application Program Interface (GSS-API) |
| |
| Authors: | S. Josefsson, L. Hornquist Astrand. |
| Date: | August 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6339 |
|
This document describes three abstract Generic Security ServiceApplication Program Interface (GSS-API) interfaces used to encapsulate/decapsulate context tokens and compare OIDs. This document also specifies C bindings for the abstract interfaces. |
|
| |
| RFC 6340 | Textual Conventions for the Representation of Floating-Point Numbers |
| |
| Authors: | R. Presuhn. |
| Date: | August 2011 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6340 |
|
This memo defines a Management Information Base (MIB) module containing textual conventions (TCs) to represent floating-point numbers. |
|
| |
| RFC 6344 | Operating Virtual Concatenation (VCAT) and the Link Capacity Adjustment Scheme (LCAS) with Generalized Multi-Protocol Label Switching (GMPLS) |
| |
| Authors: | G. Bernstein, Ed., D. Caviglia, R. Rabbat, H. van Helvoort. |
| Date: | August 2011 |
| Formats: | txt json html |
| Updates: | RFC 4606 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6344 |
|
This document describes requirements for, and the use of, theGeneralized Multi-Protocol Label Switching (GMPLS) control plane in support of the Virtual Concatenation (VCAT) layer 1 inverse multiplexing data plane mechanism and its companion Link CapacityAdjustment Scheme (LCAS). LCAS can be used for hitless dynamic resizing of the inverse multiplex group. These techniques apply toOptical Transport Network (OTN), Synchronous Optical Network (SONET),Synchronous Digital Hierarchy (SDH), and Plesiochronous DigitalHierarchy (PDH) signals. This document updates RFC 4606 by making modifications to the procedures for supporting virtual concatenation. |
|
| |
| RFC 6345 | Protocol for Carrying Authentication for Network Access (PANA) Relay Element |
| |
| Authors: | P. Duffy, S. Chakrabarti, R. Cragie, Y. Ohba, Ed., A. Yegin. |
| Date: | August 2011 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6345 |
|
This document specifies Protocol for carrying Authentication forNetwork Access (PANA) Relay Element functionality, which enables PANA messaging between a PANA Client (PaC) and a PANA Authentication Agent(PAA) where the two nodes cannot reach each other by means of regularIP routing. |
|
| |
| RFC 6347 | Datagram Transport Layer Security Version 1.2 |
| |
|
|
This document specifies version 1.2 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. This document updatesDTLS 1.0 to work with TLS version 1.2. |
|
| |
| RFC 6350 | vCard Format Specification |
| |
|
|
This document defines the vCard data format for representing and exchanging a variety of information about individuals and other entities (e.g., formatted and structured name and delivery addresses, email address, multiple telephone numbers, photograph, logo, audio clips, etc.). This document obsoletes RFCs 2425, 2426, and 4770, and updates RFC 2739. |
|
| |
| RFC 6351 | xCard: vCard XML Representation |
| |
|
|
This document defines the XML schema of the vCard data format. |
|
| |
| RFC 6352 | CardDAV: vCard Extensions to Web Distributed Authoring and Versioning (WebDAV) |
| |
|
|
This document defines extensions to the Web Distributed Authoring andVersioning (WebDAV) protocol to specify a standard way of accessing, managing, and sharing contact information based on the vCard format. |
|
| |
| RFC 6354 | Forward-Shifted RTP Redundancy Payload Support |
| |
|
|
This document defines a simple enhancement to support RTP sessions with forward-shifted redundant encodings, i.e., redundant data sent before the corresponding primary data. Forward-shifted redundancy can be used to conceal losses of a large number of consecutive media frames (e.g., consecutive loss of seconds or even tens of seconds of media). |
|
| |
| RFC 6355 | Definition of the UUID-Based DHCPv6 Unique Identifier (DUID-UUID) |
| |
| Authors: | T. Narten, J. Johnson. |
| Date: | August 2011 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6355 |
|
This document defines a new DHCPv6 Unique Identifier (DUID) type called DUID-UUID. DUID-UUIDs are derived from the already- standardized Universally Unique IDentifier (UUID) format. DUID-UUID makes it possible for devices to use UUIDs to identify themselves toDHC servers and vice versa. UUIDs are globally unique and readily available on many systems, making them convenient identifiers to leverage within DHCP. |
|
| |
| RFC 6361 | PPP Transparent Interconnection of Lots of Links (TRILL) Protocol Control Protocol |
| |
| Authors: | J. Carlson, D. Eastlake 3rd. |
| Date: | August 2011 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6361 |
|
The Point-to-Point Protocol (PPP) defines a Link Control Protocol(LCP) and a method for negotiating the use of multiprotocol traffic over point-to-point links. This document describes PPP support for the Transparent Interconnection of Lots of Links (TRILL) Protocol, allowing direct communication between Routing Bridges (RBridges) viaPPP links. |
|
| |
| RFC 6363 | Forward Error Correction (FEC) Framework |
| |
| Authors: | M. Watson, A. Begen, V. Roca. |
| Date: | October 2011 |
| Formats: | txt html json |
| Updated by: | RFC 8680 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6363 |
|
This document describes a framework for using Forward ErrorCorrection (FEC) codes with applications in public and private IP networks to provide protection against packet loss. The framework supports applying FEC to arbitrary packet flows over unreliable transport and is primarily intended for real-time, or streaming, media. This framework can be used to define Content DeliveryProtocols that provide FEC for streaming media delivery or other packet flows. Content Delivery Protocols defined using this framework can support any FEC scheme (and associated FEC codes) that is compliant with various requirements defined in this document.Thus, Content Delivery Protocols can be defined that are not specific to a particular FEC scheme, and FEC schemes can be defined that are not specific to a particular Content Delivery Protocol. |
|
| |
| RFC 6364 | Session Description Protocol Elements for the Forward Error Correction (FEC) Framework |
| |
| Authors: | A. Begen. |
| Date: | October 2011 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6364 |
|
This document specifies the use of the Session Description Protocol(SDP) to describe the parameters required to signal the Forward ErrorCorrection (FEC) Framework Configuration Information between the sender(s) and receiver(s). This document also provides examples that show the semantics for grouping multiple source and repair flows together for the applications that simultaneously use multiple instances of the FEC Framework. |
|
| |
| RFC 6368 | Internal BGP as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs) |
| |
| Authors: | P. Marques, R. Raszuk, K. Patel, K. Kumaki, T. Yamagata. |
| Date: | September 2011 |
| Formats: | txt json html |
| Updated by: | RFC 7606, RFC 9494 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6368 |
|
This document defines protocol extensions and procedures for BGPProvider/Customer Edge router iteration in BGP/MPLS IP VPNs. These extensions and procedures have the objective of making the usage of the BGP/MPLS IP VPN transparent to the customer network, as far as routing information is concerned. |
|
| |
| RFC 6370 | MPLS Transport Profile (MPLS-TP) Identifiers |
| |
| Authors: | M. Bocci, G. Swallow, E. Gray. |
| Date: | September 2011 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6370 |
|
This document specifies an initial set of identifiers to be used in the Transport Profile of Multiprotocol Label Switching (MPLS-TP).The MPLS-TP requirements (RFC 5654) require that the elements and objects in an MPLS-TP environment are able to be configured and managed without a control plane. In such an environment, many conventions for defining identifiers are possible. This document defines identifiers for MPLS-TP management and Operations,Administration, and Maintenance (OAM) functions compatible with IP/MPLS conventions.
This document is a product of a joint Internet Engineering Task Force(IETF) / International Telecommunication Union TelecommunicationStandardization Sector (ITU-T) effort to include an MPLS TransportProfile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge(PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. |
|
| |
| RFC 6374 | Packet Loss and Delay Measurement for MPLS Networks |
| |
| Authors: | D. Frost, S. Bryant. |
| Date: | September 2011 |
| Formats: | txt json html |
| Updated by: | RFC 7214 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6374 |
|
Many service provider service level agreements (SLAs) depend on the ability to measure and monitor performance metrics for packet loss and one-way and two-way delay, as well as related metrics such as delay variation and channel throughput. This measurement capability also provides operators with greater visibility into the performance characteristics of their networks, thereby facilitating planning, troubleshooting, and network performance evaluation. This document specifies protocol mechanisms to enable the efficient and accurate measurement of these performance metrics in MPLS networks. |
|
| |
| RFC 6378 | MPLS Transport Profile (MPLS-TP) Linear Protection |
| |
|
|
This document is a product of a joint Internet Engineering Task Force(IETF) / International Telecommunications Union TelecommunicationsStandardization Sector (ITU-T) effort to include an MPLS TransportProfile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge(PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T.
This document addresses the functionality described in the MPLS-TPSurvivability Framework document (RFC 6372) and defines a protocol that may be used to fulfill the function of the Protection StateCoordination for linear protection, as described in that document. |
|
| |
| RFC 6381 | The 'Codecs' and 'Profiles' Parameters for "Bucket" Media Types |
| |
|
|
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 is helpful to know from the Content-Type alone if the content can be rendered.
This document specifies two parameters, 'codecs' and 'profiles', that are used with various MIME types or type/subtype combinations to allow for unambiguous specification of the codecs employed by the media formats contained within, or the profile(s) of the overall container format. This document obsoletes RFC 4281; RFC 4281 defines the 'codecs' parameter, which this document retains in a backwards compatible manner with minor clarifications; the 'profiles' parameter is added by this document.
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.).
Similarly, the profiles can provide an overall indication, to the receiver, of the specifications with which the content complies.This is an indication of the compatibility of the container format and its contents to some specification. The receiver may be able to work out the extent to which it can handle and render the content by examining to see which of the declared profiles it supports, and what they mean. |
|
| |
| RFC 6384 | An FTP Application Layer Gateway (ALG) for IPv6-to-IPv4 Translation |
| |
| Authors: | I. van Beijnum. |
| Date: | October 2011 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6384 |
|
The File Transfer Protocol (FTP) has a very long history, and despite the fact that today other options exist to perform file transfers,FTP is still in common use. As such, in situations where some client computers only have IPv6 connectivity while many servers are stillIPv4-only and IPv6-to-IPv4 translators are used to bridge that gap, it is important that FTP is made to work through these translators to the best possible extent.
FTP has an active and a passive mode, both as original commands that are IPv4-specific and as extended, IP version agnostic commands. The only FTP mode that works without changes through an IPv6-to-IPv4 translator is extended passive. However, many existing FTP servers do not support this mode, and some clients do not ask for it. This document specifies a middlebox that may solve this mismatch. |
|
| |
| RFC 6387 | GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs) |
| |
| Authors: | A. Takacs, L. Berger, D. Caviglia, D. Fedyk, J. Meuric. |
| Date: | September 2011 |
| Formats: | txt html json |
| Obsoletes: | RFC 5467 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6387 |
|
This document defines a method for the support of GMPLS asymmetric bandwidth bidirectional Label Switched Paths (LSPs). The approach presented is applicable to any switching technology and builds on the original Resource Reservation Protocol (RSVP) model for the transport of traffic-related parameters. This document moves the experiment documented in RFC 5467 to the standards track and obsoletes RFC 5467. |
|
| |
| RFC 6388 | Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths |
| |
| Authors: | IJ. Wijnands, Ed., I. Minei, Ed., K. Kompella, B. Thomas. |
| Date: | November 2011 |
| Formats: | txt json html |
| Updated by: | RFC 7358 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6388 |
|
This document describes extensions to the Label Distribution Protocol(LDP) for the setup of point-to-multipoint (P2MP) and multipoint-to- multipoint (MP2MP) Label Switched Paths (LSPs) in MPLS networks.These extensions are also referred to as multipoint LDP. MultipointLDP constructs the P2MP or MP2MP LSPs without interacting with or relying upon any other multicast tree construction protocol.Protocol elements and procedures for this solution are described for building such LSPs in a receiver-initiated manner. There can be various applications for multipoint LSPs, for example IP multicast or support for multicast in BGP/MPLS Layer 3 Virtual Private Networks(L3VPNs). Specification of how such applications can use an LDP signaled multipoint LSP is outside the scope of this document. |
|
| |
| RFC 6389 | MPLS Upstream Label Assignment for LDP |
| |
| Authors: | R. Aggarwal, JL. Le Roux. |
| Date: | November 2011 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6389 |
|
This document describes procedures for distributing upstream-assigned labels for the Label Distribution Protocol (LDP). It also describes how these procedures can be used for avoiding branch Label SwitchingRouter (LSR) traffic replication on a LAN for LDP point-to-multipoint(P2MP) Label Switched Paths (LSPs). |
|
| |
| RFC 6391 | Flow-Aware Transport of Pseudowires over an MPLS Packet Switched Network |
| |
| Authors: | S. Bryant, Ed., C. Filsfils, U. Drafz, V. Kompella, J. Regan, S. Amante. |
| Date: | November 2011 |
| Formats: | txt json html |
| Updated by: | RFC 7274 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6391 |
|
Where the payload of a pseudowire comprises a number of distinct flows, it can be desirable to carry those flows over the Equal CostMultiple Paths (ECMPs) that exist in the packet switched network.Most forwarding engines are able to generate a hash of the MPLS label stack and use this mechanism to balance MPLS flows over ECMPs.
This document describes a method of identifying the flows, or flow groups, within pseudowires such that Label Switching Routers can balance flows at a finer granularity than individual pseudowires.The mechanism uses an additional label in the MPLS label stack. |
|
| |
| RFC 6395 | An Interface Identifier (ID) Hello Option for PIM |
| |
| Authors: | S. Gulrajani, S. Venaas. |
| Date: | October 2011 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6395 |
|
This document defines a new PIM Hello option to advertise anInterface Identifier that can be used by PIM protocols to uniquely identify an interface of a neighboring router. |
|
| |
| RFC 6396 | Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format |
| |
| Authors: | L. Blunk, M. Karir, C. Labovitz. |
| Date: | October 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6396 |
|
This document describes the MRT format for routing information export. This format was developed in concert with the Multi-threadedRouting Toolkit (MRT) from whence the format takes it name. The format can be used to export routing protocol messages, state changes, and routing information base contents. |
|
| |
| RFC 6397 | Multi-Threaded Routing Toolkit (MRT) Border Gateway Protocol (BGP) Routing Information Export Format with Geo-Location Extensions |
| |
| Authors: | T. Manderson. |
| Date: | October 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6397 |
|
This document updates the Multi-threaded Routing Toolkit (MRT) export format for Border Gateway Protocol (BGP) routing information by extending it to include optional terrestrial coordinates of a BGP collector and its BGP peers. |
|
| |
| RFC 6401 | RSVP Extensions for Admission Priority |
| |
| Authors: | F. Le Faucheur, J. Polk, K. Carlberg. |
| Date: | October 2011 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6401 |
|
Some applications require the ability to provide an elevated probability of session establishment to specific sessions in times of network congestion. When supported over the Internet Protocol suite, this may be facilitated through a network-layer admission control solution that supports prioritized access to resources (e.g., bandwidth). These resources may be explicitly set aside for prioritized sessions, or may be shared with other sessions. This document specifies extensions to the Resource reSerVation Protocol(RSVP) that can be used to support such an admission priority capability at the network layer.
Based on current security concerns, these extensions are intended for use in a single administrative domain. |
|
| |
| RFC 6402 | Certificate Management over CMS (CMC) Updates |
| |
|
|
This document contains a set of updates to the base syntax for CMC, aCertificate Management protocol using the Cryptographic MessageSyntax (CMS). This document updates RFC 5272, RFC 5273, and RFC5274.
The new items in this document are: new controls for future work in doing server side key generation, definition of a Subject InformationAccess value to identify CMC servers, and the registration of a port number for TCP/IP for the CMC service to run on. |
|
| |
| RFC 6407 | The Group Domain of Interpretation |
| |
| Authors: | B. Weis, S. Rowles, T. Hardjono. |
| Date: | October 2011 |
| Formats: | txt html json |
| Obsoletes: | RFC 3547 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6407 |
|
This document describes the Group Domain of Interpretation (GDOI) protocol specified in RFC 3547. The GDOI provides group key management to support secure group communications according to the architecture specified in RFC 4046. The GDOI manages group security associations, which are used by IPsec and potentially other data security protocols. This document replaces RFC 3547. |
|
| |
| RFC 6408 | Diameter Straightforward-Naming Authority Pointer (S-NAPTR) Usage |
| |
| Authors: | M. Jones, J. Korhonen, L. Morand. |
| Date: | November 2011 |
| Formats: | txt json html |
| Updates: | RFC 3588 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6408 |
|
The Diameter base protocol specifies mechanisms whereby a given realm may advertise Diameter nodes and the supported transport protocol.However, these mechanisms do not reveal the Diameter applications that each node supports. A peer outside the realm would have to perform a Diameter capability exchange with every node until it discovers one that supports the required application. This document updates RFC 3588, "Diameter Base Protocol", and describes an improvement using an extended format for the Straightforward-NamingAuthority Pointer (S-NAPTR) application service tag that allows for discovery of the supported applications without doing Diameter capability exchange beforehand. |
|
| |
| RFC 6415 | Web Host Metadata |
| |
| Authors: | E. Hammer-Lahav, Ed., B. Cook. |
| Date: | October 2011 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6415 |
|
This specification describes a method for locating host metadata as well as information about individual resources controlled by the host. |
|
| |
| RFC 6416 | RTP Payload Format for MPEG-4 Audio/Visual Streams |
| |
| Authors: | M. Schmidt, F. de Bont, S. Doehla, J. Kim. |
| Date: | October 2011 |
| Formats: | txt html json |
| Obsoletes: | RFC 3016 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6416 |
|
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. This document obsoletes RFC3016. It contains a summary of changes from RFC 3016 and discusses backward compatibility to RFC 3016. It is a necessary revision ofRFC 3016 in order to correct misalignments with the 3GPP Packet- switched Streaming Service (PSS) specification regarding the RTP payload format for MPEG-4 Audio.
For the purpose of directly mapping MPEG-4 Audio/Visual bitstreams onto RTP packets, this document provides specifications for the use of RTP header fields and also specifies fragmentation rules. It also provides specifications for Media Type registration and the use of the Session Description Protocol (SDP). The audio payload format described in this document has some limitations related to the signaling of audio codec parameters for the required multiplexing format. Therefore, new system designs should utilize RFC 3640, which does not have these restrictions. Nevertheless, this revision of RFC3016 is provided to update and complete the specification and to enable interoperable implementations. |
|
| |
| RFC 6420 | PIM Multi-Topology ID (MT-ID) Join Attribute |
| |
| Authors: | Y. Cai, H. Ou. |
| Date: | November 2011 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6420 |
|
This document introduces a new type of PIM Join Attribute that extends PIM signaling to identify a topology that should be used when constructing a particular multicast distribution tree. |
|
| |
| RFC 6422 | Relay-Supplied DHCP Options |
| |
|
|
DHCPv6 relay agents cannot communicate with DHCPv6 clients directly.However, in some cases, the relay agent possesses some information that would be useful to the DHCPv6 client. This document describes a mechanism whereby the DHCPv6 relay agent can provide such information to the DHCPv6 server, which can, in turn, pass this information on to the DHCP client.
This document updates RFC 3315 (DHCPv6) by making explicit the implicit requirement that relay agents not modify the content of encapsulation payloads as they are relayed back toward clients. |
|
| |
| RFC 6423 | Using the Generic Associated Channel Label for Pseudowire in the MPLS Transport Profile (MPLS-TP) |
| |
| Authors: | H. Li, L. Martini, J. He, F. Huang. |
| Date: | November 2011 |
| Formats: | txt html json |
| Updates: | RFC 5586 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6423 |
|
This document describes the requirements for using the GenericAssociated Channel Label (GAL) in pseudowires (PWs) in MPLS TransportProfile (MPLS-TP) networks, and provides an update to the description of GAL usage in RFC 5586 by removing the restriction that is imposed on using GAL for PWs, especially in MPLS-TP environments. |
|
| |
| RFC 6424 | Mechanism for Performing Label Switched Path Ping (LSP Ping) over MPLS Tunnels |
| |
|
|
This document describes methods for performing LSP ping (specified inRFC 4379) traceroute over MPLS tunnels and for traceroute of stitchedMPLS Label Switched Paths (LSPs). The techniques outlined in RFC4379 are insufficient to perform traceroute Forwarding EquivalencyClass (FEC) validation and path discovery for an LSP that goes over other MPLS tunnels or for a stitched LSP. This document deprecates the Downstream Mapping TLV (defined in RFC 4379) in favor of a newTLV that, along with other procedures outlined in this document, can be used to trace such LSPs. |
|
| |
| RFC 6425 | Detecting Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP Ping |
| |
| Authors: | S. Saxena, Ed., G. Swallow, Z. Ali, A. Farrel, S. Yasukawa, T. Nadeau. |
| Date: | November 2011 |
| Formats: | txt json html |
| Updates: | RFC 4379 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6425 |
|
Recent proposals have extended the scope of Multiprotocol LabelSwitching (MPLS) Label Switched Paths (LSPs) to encompass point-to- multipoint (P2MP) LSPs.
The requirement for a simple and efficient mechanism that can be used to detect data-plane failures in point-to-point (P2P) MPLS LSPs has been recognized and has led to the development of techniques for fault detection and isolation commonly referred to as "LSP ping".
The scope of this document is fault detection and isolation for P2MPMPLS LSPs. This documents does not replace any of the mechanisms ofLSP ping, but clarifies their applicability to MPLS P2MP LSPs, and extends the techniques and mechanisms of LSP ping to the MPLS P2MP environment.
This document updates RFC 4379. |
|
| |
| RFC 6426 | MPLS On-Demand Connectivity Verification and Route Tracing |
| |
| Authors: | E. Gray, N. Bahadur, S. Boutros, R. Aggarwal. |
| Date: | November 2011 |
| Formats: | txt html json |
| Updates: | RFC 4379 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6426 |
|
Label Switched Path Ping (LSP ping) is an existing and widely deployed Operations, Administration, and Maintenance (OAM) mechanism for Multi-Protocol Label Switching (MPLS) Label Switched Paths(LSPs). This document describes extensions to LSP ping so that LSP ping can be used for on-demand connectivity verification of MPLSTransport Profile (MPLS-TP) LSPs and pseudowires. This document also clarifies procedures to be used for processing the related OAM packets. Further, it describes procedures for using LSP ping to perform connectivity verification and route tracing functions inMPLS-TP networks. Finally, this document updates RFC 4379 by adding a new address type and creating an IANA registry. |
|
| |
| RFC 6427 | MPLS Fault Management Operations, Administration, and Maintenance (OAM) |
| |
| Authors: | G. Swallow, Ed., A. Fulignoli, Ed., M. Vigoureux, Ed., S. Boutros, D. Ward. |
| Date: | November 2011 |
| Formats: | txt html json |
| Updated by: | RFC 7214 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6427 |
|
This document specifies Operations, Administration, and Maintenance(OAM) messages to indicate service disruptive conditions for MPLS- based transport network Label Switched Paths. The notification mechanism employs a generic method for a service disruptive condition to be communicated to a Maintenance Entity Group End Point. This document defines an MPLS OAM channel, along with messages to communicate various types of service disruptive conditions. |
|
| |
| RFC 6428 | Proactive Connectivity Verification, Continuity Check, and Remote Defect Indication for the MPLS Transport Profile |
| |
| Authors: | D. Allan, Ed., G. Swallow, Ed., J. Drake, Ed.. |
| Date: | November 2011 |
| Formats: | txt json html |
| Updated by: | RFC 7214 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6428 |
|
Continuity Check, Proactive Connectivity Verification, and RemoteDefect Indication functionalities are required for MPLS TransportProfile (MPLS-TP) Operations, Administration, and Maintenance (OAM).
Continuity Check monitors a Label Switched Path for any loss of continuity defect. Connectivity Verification augments ContinuityCheck in order to provide confirmation that the desired source is connected to the desired sink. Remote Defect Indication enables an end point to report, to its associated end point, a fault or defect condition that it detects on a pseudowire, Label Switched Path, orSection.
This document specifies specific extensions to BidirectionalForwarding Detection (BFD) and methods for proactive ContinuityCheck, Continuity Verification, and Remote Defect Indication forMPLS-TP pseudowires, Label Switched Paths, and Sections using BFD as extended by this memo. |
|
| |
| RFC 6430 | Email Feedback Report Type Value: not-spam |
| |
| Authors: | K. Li, B. Leiba. |
| Date: | November 2011 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6430 |
|
This document defines a new Abuse Reporting Format (ARF) feedback report type value: "not-spam". It can be used to report an email message that was mistakenly marked as spam. |
|
| |
| RFC 6432 | Carrying Q.850 Codes in Reason Header Fields in SIP (Session Initiation Protocol) Responses |
| |
| Authors: | R. Jesske, L. Liess. |
| Date: | November 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6432 |
|
Although the use of the SIP (Session Initiation Protocol) Reason header field in responses is considered in general in RFC 3326, its use is not specified for any particular response code. Nonetheless, existing deployments have been using Reason header fields to carry failure-related Q.850 cause codes in SIP responses to INVITE requests that have been gatewayed to Public Switched Telephone Network (PSTN) systems. This document normatively describes the use of the Reason header field in carrying Q.850 cause codes in SIP responses. |
|
| |
| RFC 6435 | MPLS Transport Profile Lock Instruct and Loopback Functions |
| |
| Authors: | S. Boutros, Ed., S. Sivabalan, Ed., R. Aggarwal, Ed., M. Vigoureux, Ed., X. Dai, Ed.. |
| Date: | November 2011 |
| Formats: | txt json html |
| Updates: | RFC 6371 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6435 |
|
Two useful Operations, Administration, and Maintenance (OAM) functions in a transport network are "lock" and "loopback". The lock function enables an operator to lock a transport path such that it does not carry client traffic, but can continue to carry OAM messages and may carry test traffic. The loopback function allows an operator to set a specific node on the transport path into loopback mode such that it returns all received data.
This document specifies the lock function for MPLS networks and describes how the loopback function operates in MPLS networks.
This document updates Sections 7.1.1 and 7.1.2 of RFC 6371. |
|
| |
| RFC 6437 | IPv6 Flow Label Specification |
| |
|
|
This document specifies the IPv6 Flow Label field and the minimum requirements for IPv6 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 the 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 6438 | Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels |
| |
| Authors: | B. Carpenter, S. Amante. |
| Date: | November 2011 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6438 |
|
The IPv6 flow label has certain restrictions on its use. This document describes how those restrictions apply when using the flow label for load balancing by equal cost multipath routing and for link aggregation, particularly for IP-in-IPv6 tunneled traffic. |
|
| |
| RFC 6439 | Routing Bridges (RBridges): Appointed Forwarders |
| |
|
|
The IETF TRILL (TRansparent Interconnection of Lots of Links) protocol provides least cost pair-wise data forwarding without configuration in multi-hop networks with arbitrary topology, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. TRILL accomplishes this by using IS-IS (Intermediate System to IntermediateSystem) link state routing and by encapsulating traffic using a header that includes a hop count. Devices that implement TRILL are called "RBridges" (Routing Bridges).
TRILL supports multi-access LAN (Local Area Network) links that can have multiple end stations and RBridges attached. Where multipleRBridges are attached to a link, native traffic to and from end stations on that link is handled by a subset of those RBridges called"Appointed Forwarders", with the intent that native traffic in eachVLAN (Virtual LAN) be handled by at most one RBridge. The purpose of this document is to improve the documentation of the AppointedForwarder mechanism; thus, it updates RFC 6325. |
|
| |
| RFC 6440 | The EAP Re-authentication Protocol (ERP) Local Domain Name DHCPv6 Option |
| |
| Authors: | G. Zorn, Q. Wu, Y. Wang. |
| Date: | December 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6440 |
|
In order to derive a Domain-Specific Root Key (DSRK) from theExtended Master Session Key (EMSK) generated as a side effect of anExtensible Authentication Protocol (EAP) method, the EAP peer must discover the name of the domain to which it is attached.
This document specifies a Dynamic Host Configuration ProtocolVersion 6 (DHCPv6) option designed to allow a DHCPv6 server to inform clients using the EAP Re-authentication Protocol (ERP) EAP method of the name of the local domain for ERP. |
|
| |
| RFC 6442 | Location Conveyance for the Session Initiation Protocol |
| |
|
|
This document defines an extension to the Session Initiation Protocol(SIP) to convey geographic location information from one SIP entity to another SIP entity. The SIP extension covers end-to-end conveyance as well as location-based routing, where SIP intermediaries make routing decisions based upon the location of theLocation Target. |
|
| |
| RFC 6445 | Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base for Fast Reroute |
| |
| Authors: | T. Nadeau, Ed., A. Koushik, Ed., R. Cetin, Ed.. |
| Date: | November 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6445 |
|
This memo defines a portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects used to support two fast reroute (FRR) methods for Multiprotocol Label Switching (MPLS)-based traffic engineering (TE). The two methods are the one-to-one backup method and the facility backup method. |
|
| |
| RFC 6446 | Session Initiation Protocol (SIP) Event Notification Extension for Notification Rate Control |
| |
| Authors: | A. Niemi, K. Kiss, S. Loreto. |
| Date: | January 2012 |
| Formats: | txt json html |
| Updates: | RFC 3265 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6446 |
|
This document specifies mechanisms for adjusting the rate of SessionInitiation Protocol (SIP) event notifications. These mechanisms can be applied in subscriptions to all SIP event packages. This document updates RFC 3265. |
|
| |
| RFC 6447 | Filtering Location Notifications in the Session Initiation Protocol (SIP) |
| |
| Authors: | R. Mahy, B. Rosen, H. Tschofenig. |
| Date: | January 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6447 |
|
This document describes filters that limit asynchronous location notifications to compelling events. These filters are designed as an extension to RFC 4661, an XML-based format for event notification filtering, and based on RFC 3856, the SIP presence event package.The resulting location information is conveyed in existing location formats wrapped in the Presence Information Data Format LocationObject (PIDF-LO). |
|
| |
| RFC 6448 | The Unencrypted Form of Kerberos 5 KRB-CRED Message |
| |
| Authors: | R. Yount. |
| Date: | November 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6448 |
|
The Kerberos 5 KRB-CRED message is used to transfer Kerberos credentials between applications. When used with a secure transport, the unencrypted form of the KRB-CRED message may be desirable. This document describes the unencrypted form of the KRB-CRED message. |
|
| |
| RFC 6450 | Multicast Ping Protocol |
| |
| Authors: | S. Venaas. |
| Date: | December 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6450 |
|
The Multicast Ping Protocol specified in this document allows for checking whether an endpoint can receive multicast -- both Source-Specific Multicast (SSM) and Any-Source Multicast (ASM). It can also be used to obtain additional multicast-related information, such as multicast tree setup time. This protocol is based on an implementation of tools called "ssmping" and "asmping". |
|
| |
| RFC 6452 | The Unicode Code Points and Internationalized Domain Names for Applications (IDNA) - Unicode 6.0 |
| |
| Authors: | P. Faltstrom, Ed., P. Hoffman, Ed.. |
| Date: | November 2011 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6452 |
|
This memo documents IETF consensus for Internationalized Domain Names for Applications (IDNA) derived character properties related to the three code points, existing in Unicode 5.2, that changed property values when version 6.0 was released. The consensus is that no update is needed to RFC 5892 based on the changes made in Unicode6.0. |
|
| |
| RFC 6454 | The Web Origin Concept |
| |
| Authors: | A. Barth. |
| Date: | December 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6454 |
|
This document defines the concept of an "origin", which is often used as the scope of authority or privilege by user agents. Typically, user agents isolate content retrieved from different origins to prevent malicious web site operators from interfering with the operation of benign web sites. In addition to outlining the principles that underlie the concept of origin, this document details how to determine the origin of a URI and how to serialize an origin into a string. It also defines an HTTP header field, named "Origin", that indicates which origins are associated with an HTTP request. |
|
| |
| RFC 6455 | The WebSocket Protocol |
| |
|
|
The WebSocket Protocol enables two-way communication between a client running untrusted code in a controlled environment to a remote host that has opted-in to communications from that code. The security model used for this is the origin-based security model commonly used by web browsers. The protocol consists of an opening handshake followed by basic message framing, layered over TCP. The goal of this technology is to provide a mechanism for browser-based applications that need two-way communication with servers that does not rely on opening multiple HTTP connections (e.g., usingXMLHttpRequest or <iframe&rt;s and long polling). |
|
| |
| RFC 6463 | Runtime Local Mobility Anchor (LMA) Assignment Support for Proxy Mobile IPv6 |
| |
| Authors: | J. Korhonen, Ed., S. Gundavelli, H. Yokota, X. Cui. |
| Date: | February 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6463 |
|
This document describes a runtime local mobility anchor assignment functionality and corresponding mobility options for Proxy MobileIPv6. The runtime local mobility anchor assignment takes place during a Proxy Binding Update and a Proxy Binding Acknowledgement message exchange between a mobile access gateway and a local mobility anchor. The runtime local mobility anchor assignment functionality defined in this specification can be used, for example, for load- balancing purposes. |
|
| |
| RFC 6464 | A Real-time Transport Protocol (RTP) Header Extension for Client-to-Mixer Audio Level Indication |
| |
| Authors: | J. Lennox, Ed., E. Ivov, E. Marocco. |
| Date: | December 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6464 |
|
This document defines a mechanism by which packets of Real-timeTransport Protocol (RTP) audio streams can indicate, in an RTP header extension, the audio level of the audio sample carried in the RTP packet. In large conferences, this can reduce the load on an audio mixer or other middlebox that wants to forward only a few of the loudest audio streams, without requiring it to decode and measure every stream that is received. |
|
| |
| RFC 6465 | A Real-time Transport Protocol (RTP) Header Extension for Mixer-to-Client Audio Level Indication |
| |
| Authors: | E. Ivov, Ed., E. Marocco, Ed., J. Lennox. |
| Date: | December 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6465 |
|
This document describes a mechanism for RTP-level mixers in audio conferences to deliver information about the audio level of individual participants. Such audio level indicators are transported in the same RTP packets as the audio data they pertain to. |
|
| |
| RFC 6466 | IANA Registration of the 'image' Media Type for the Session Description Protocol (SDP) |
| |
| Authors: | G. Salgueiro. |
| Date: | December 2011 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6466 |
|
This document describes the usage of the 'image' media type and registers it with IANA as a top-level media type for the SessionDescription Protocol (SDP). This media type is primarily used by SDP to negotiate and establish T.38 media streams. |
|
| |
| RFC 6468 | Sieve Notification Mechanism: SIP MESSAGE |
| |
| Authors: | A. Melnikov, B. Leiba, K. Li. |
| Date: | February 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6468 |
|
This document describes a profile of the Sieve extension for notifications, to allow notifications to be sent over SIP MESSAGE. |
|
| |
| RFC 6469 | RTP Payload Format for DV (IEC 61834) Video |
| |
| Authors: | K. Kobayashi, K. Mishima, S. Casner, C. Bormann. |
| Date: | December 2011 |
| Formats: | txt html json |
| Obsoletes: | RFC 3189 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6469 |
|
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). This document obsoletes RFC 3189. |
|
| |
| RFC 6470 | Network Configuration Protocol (NETCONF) Base Notifications |
| |
| Authors: | A. Bierman. |
| Date: | February 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6470 |
|
The Network Configuration Protocol (NETCONF) provides mechanisms to manipulate configuration datastores. However, client applications often need to be aware of common events, such as a change in NETCONF server capabilities, that may impact management applications.Standard mechanisms are needed to support the monitoring of the base system events within the NETCONF server. This document defines aYANG module that allows a NETCONF client to receive notifications for some common system events. |
|
| |
| RFC 6473 | vCard KIND:application |
| |
| Authors: | P. Saint-Andre. |
| Date: | December 2011 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6473 |
|
This document defines a value of "application" for the vCard KIND property so that vCards can be used to represent software applications. |
|
| |
| RFC 6474 | vCard Format Extensions: Place of Birth, Place and Date of Death |
| |
| Authors: | K. Li, B. Leiba. |
| Date: | December 2011 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6474 |
|
The base vCard 4.0 specification defines a large number of properties, including date of birth. This specification adds three new properties to vCard 4.0: place of birth, place of death, and date of death. |
|
| |
| RFC 6475 | Proxy Mobile IPv6 Management Information Base |
| |
| Authors: | G. Keeni, K. Koide, S. Gundavelli, R. Wakikawa. |
| Date: | May 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6475 |
|
This memo defines a portion of the Proxy Mobile IPv6 ManagementInformation Base (MIB) for use with network management protocols in the Internet community. In particular, the Proxy Mobile IPv6 MIB can be used to monitor and control the mobile access gateway (MAG) and the local mobility anchor (LMA) functions of a Proxy Mobile IPv6(PMIPv6) entity. |
|
| |
| RFC 6476 | Using Message Authentication Code (MAC) Encryption in the Cryptographic Message Syntax (CMS) |
| |
| Authors: | P. Gutmann. |
| Date: | January 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6476 |
|
This document specifies the conventions for using MessageAuthentication Code (MAC) encryption with the Cryptographic MessageSyntax (CMS) authenticated-enveloped-data content type. This mirrors the use of a MAC combined with an encryption algorithm that's already employed in IPsec, Secure Socket Layer / Transport Layer Security(SSL/TLS) and Secure SHell (SSH), which is widely supported in existing crypto libraries and hardware and has been extensively analysed by the crypto community. |
|
| |
| RFC 6478 | Pseudowire Status for Static Pseudowires |
| |
|
|
This document specifies a mechanism to signal Pseudowire (PW) status messages using a PW associated channel (ACh). Such a mechanism is suitable for use where no PW dynamic control plane exits, known as static PWs, or where a Terminating Provider Edge (T-PE) needs to send a PW status message directly to a far-end T-PE. The mechanism allowsPW Operations, Administration, and Maintenance (OAM) message mapping and PW redundancy to operate on static PWs. This document also updates RFC 5885 in the case when Bi-directional Forwarding Detection(BFD) is used to convey PW status-signaling information. |
|
| |
| RFC 6481 | A Profile for Resource Certificate Repository Structure |
| |
| Authors: | G. Huston, R. Loomans, G. Michaelson. |
| Date: | February 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6481 |
|
This document defines a profile for the structure of the ResourcePublic Key Infrastructure (RPKI) distributed repository. Each individual repository publication point is a directory that contains files that correspond to X.509/PKIX Resource Certificates,Certificate Revocation Lists and signed objects. This profile defines the object (file) naming scheme, the contents of repository publication points (directories), and a suggested internal structure of a local repository cache that is intended to facilitate synchronization across a distributed collection of repository publication points and to facilitate certification path construction. |
|
| |
| RFC 6482 | A Profile for Route Origin Authorizations (ROAs) |
| |
| Authors: | M. Lepinski, S. Kent, D. Kong. |
| Date: | February 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6482 |
|
This document defines a standard profile for Route OriginAuthorizations (ROAs). A ROA is a digitally signed object that provides a means of verifying that an IP address block holder has authorized an Autonomous System (AS) to originate routes to one or more prefixes within the address block. |
|
| |
| RFC 6485 | The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure (RPKI) |
| |
|
|
This document specifies the algorithms, algorithms' parameters, asymmetric key formats, asymmetric key size, and signature format for the Resource Public Key Infrastructure (RPKI) subscribers that generate digital signatures on certificates, Certificate RevocationLists, and signed objects as well as for the relying parties (RPs) that verify these digital signatures. |
|
| |
| RFC 6486 | Manifests for the Resource Public Key Infrastructure (RPKI) |
| |
| Authors: | R. Austein, G. Huston, S. Kent, M. Lepinski. |
| Date: | February 2012 |
| Formats: | txt json html |
| Obsoleted by: | RFC 9286 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6486 |
|
This document defines a "manifest" for use in the Resource Public KeyInfrastructure (RPKI). A manifest is a signed object (file) that contains a listing of all the signed objects (files) in the repository publication point (directory) associated with an authority responsible for publishing in the repository. For each certificate,Certificate Revocation List (CRL), or other type of signed objects issued by the authority that are published at this repository publication point, the manifest contains both the name of the file containing the object and a hash of the file content. Manifests are intended to enable a relying party (RP) to detect certain forms of attacks against a repository. Specifically, if an RP checks a manifest's contents against the signed objects retrieved from a repository publication point, then the RP can detect "stale" (valid) data and deletion of signed objects. |
|
| |
| RFC 6487 | A Profile for X.509 PKIX Resource Certificates |
| |
|
|
This document defines a standard profile for X.509 certificates for the purpose of supporting validation of assertions of "right-of-use" of Internet Number Resources (INRs). The certificates issued under this profile are used to convey the issuer's authorization of the subject to be regarded as the current holder of a "right-of-use" of the INRs that are described in the certificate. This document contains the normative specification of Certificate and CertificateRevocation List (CRL) syntax in the Resource Public KeyInfrastructure (RPKI). This document also specifies profiles for the format of certificate requests and specifies the Relying Party RPKI certificate path validation procedure. |
|
| |
| RFC 6488 | Signed Object Template for the Resource Public Key Infrastructure (RPKI) |
| |
| Authors: | M. Lepinski, A. Chi, S. Kent. |
| Date: | February 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6488 |
|
This document defines a generic profile for signed objects used in the Resource Public Key Infrastructure (RPKI). These RPKI signed objects make use of Cryptographic Message Syntax (CMS) as a standard encapsulation format. |
|
| |
| RFC 6490 | Resource Public Key Infrastructure (RPKI) Trust Anchor Locator |
| |
| Authors: | G. Huston, S. Weiler, G. Michaelson, S. Kent. |
| Date: | February 2012 |
| Formats: | txt html json |
| Obsoleted by: | RFC 7730 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6490 |
|
This document defines a Trust Anchor Locator (TAL) for the ResourcePublic Key Infrastructure (RPKI). |
|
| |
| RFC 6491 | Resource Public Key Infrastructure (RPKI) Objects Issued by IANA |
| |
| Authors: | T. Manderson, L. Vegoda, S. Kent. |
| Date: | February 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6491 |
|
This document provides specific direction to IANA as to the ResourcePublic Key Infrastructure (RPKI) objects it should issue. |
|
| |
| RFC 6492 | A Protocol for Provisioning Resource Certificates |
| |
| Authors: | G. Huston, R. Loomans, B. Ellacott, R. Austein. |
| Date: | February 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6492 |
|
This document defines a framework for certificate management interactions between an Internet Number Resource issuer ("issuer") and an Internet Number Resource recipient ("subject") through the specification of a protocol for interaction between the two parties.The protocol supports the transmission of requests from the subject, and corresponding responses from the issuer encompassing the actions of certificate issuance, certificate revocation, and certificate status information reports. This protocol is intended to be limited to the application of Internet Number Resource Certificate management and is not intended to be used as part of a more general certificate management framework. |
|
| |
| RFC 6493 | The Resource Public Key Infrastructure (RPKI) Ghostbusters Record |
| |
| Authors: | R. Bush. |
| Date: | February 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6493 |
|
In the Resource Public Key Infrastructure (RPKI), resource certificates completely obscure names or any other information that might be useful for contacting responsible parties to deal with issues of certificate expiration, maintenance, roll-overs, compromises, etc. This document describes the RPKI GhostbustersRecord containing human contact information that may be verified(indirectly) by a Certification Authority (CA) certificate. The data in the record are those of a severely profiled vCard. |
|
| |
| RFC 6494 | Certificate Profile and Certificate Management for SEcure Neighbor Discovery (SEND) |
| |
| Authors: | R. Gagliano, S. Krishnan, A. Kukec. |
| Date: | February 2012 |
| Formats: | txt html json |
| Updates: | RFC 3971 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6494 |
|
SEcure Neighbor Discovery (SEND) utilizes X.509v3 certificates for performing router authorization. This document specifies a certificate profile for SEND based on resource certificates along with extended key usage values required for SEND. |
|
| |
| RFC 6495 | Subject Key Identifier (SKI) SEcure Neighbor Discovery (SEND) Name Type Fields |
| |
| Authors: | R. Gagliano, S. Krishnan, A. Kukec. |
| Date: | February 2012 |
| Formats: | txt html json |
| Updates: | RFC 3971 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6495 |
|
SEcure Neighbor Discovery (SEND) defines the Name Type field in theICMPv6 Trust Anchor option. This document specifies new Name Type fields based on certificate Subject Key Identifiers (SKIs). |
|
| |
| RFC 6501 | Conference Information Data Model for Centralized Conferencing (XCON) |
| |
| Authors: | O. Novo, G. Camarillo, D. Morgan, J. Urpalainen. |
| Date: | March 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6501 |
|
RFC 5239 defines centralized conferencing (XCON) as an association of participants with a central focus. The state of a conference is represented by a conference object. This document defines an XML- based conference information data model to be used for conference objects. A conference information data model is designed to convey information about the conference and about participation in the conference. The conference information data model defined in this document constitutes an extension of the data format specified in theSession Initiation Protocol (SIP) event package for conference State. |
|
| |
| RFC 6502 | Conference Event Package Data Format Extension for Centralized Conferencing (XCON) |
| |
| Authors: | G. Camarillo, S. Srinivasan, R. Even, J. Urpalainen. |
| Date: | March 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6502 |
|
This document specifies the notification mechanism for XCON(centralized conferencing). This mechanism reuses the SIP (SessionInitiation Protocol) event package for conference state.Additionally, the notification mechanism includes support for theXCON data model and for partial notifications. |
|
| |
| RFC 6503 | Centralized Conferencing Manipulation Protocol |
| |
| Authors: | M. Barnes, C. Boulton, S. Romano, H. Schulzrinne. |
| Date: | March 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6503 |
|
The Centralized Conferencing Manipulation Protocol (CCMP) allows aCentralized Conferencing (XCON) system client to create, retrieve, change, and delete objects that describe a centralized conference.CCMP is a means to control basic and advanced conference features such as conference state and capabilities, participants, relative roles, and details. CCMP is a stateless, XML-based, client server protocol that carries, in its request and response messages, conference information in the form of XML documents and fragments conforming to the centralized conferencing data model schema. |
|
| |
| RFC 6505 | A Mixer Control Package for the Media Control Channel Framework |
| |
| Authors: | S. McGlashan, T. Melanchuk, C. Boulton. |
| Date: | March 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6505 |
|
This document defines a Media Control Channel Framework Package for managing mixers for media conferences and connections. The package defines request elements for managing conference mixers, managing mixers between conferences and/or connections, as well as associated responses and notifications. The package also defines elements for auditing package capabilities and mixers. |
|
| |
| RFC 6506 | Supporting Authentication Trailer for OSPFv3 |
| |
| Authors: | M. Bhatia, V. Manral, A. Lindem. |
| Date: | February 2012 |
| Formats: | txt json html |
| Obsoleted by: | RFC 7166 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6506 |
|
Currently, OSPF for IPv6 (OSPFv3) uses IPsec as the only mechanism for authenticating protocol packets. This behavior is different from authentication mechanisms present in other routing protocols (OSPFv2,Intermediate System to Intermediate System (IS-IS), RIP, and RoutingInformation Protocol Next Generation (RIPng)). In some environments, it has been found that IPsec is difficult to configure and maintain and thus cannot be used. This document defines an alternative mechanism to authenticate OSPFv3 protocol packets so that OSPFv3 does not only depend upon IPsec for authentication. |
|
| |
| RFC 6510 | Resource Reservation Protocol (RSVP) Message Formats for Label Switched Path (LSP) Attributes Objects |
| |
|
|
Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) established using the Resource Reservation Protocol TrafficEngineering (RSVP-TE) extensions may be signaled with a set of LSP- specific attributes. These attributes may be carried in both Path and Resv messages. This document specifies how LSP attributes are to be carried in RSVP Path and Resv messages using the Routing Backus-Naur Form and clarifies related Resv message formats. This document updates RFC 4875 and RFC 5420. |
|
| |
| RFC 6511 | Non-Penultimate Hop Popping Behavior and Out-of-Band Mapping for RSVP-TE Label Switched Paths |
| |
| Authors: | Z. Ali, G. Swallow, R. Aggarwal. |
| Date: | February 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6511 |
|
There are many deployment scenarios that require an egress LabelSwitching Router (LSR) to receive binding of the Resource ReservationProtocol - Traffic Engineering (RSVP-TE) Label Switched Path (LSP) to an application and a payload identifier using some "out-of-band"(OOB) mechanism. This document defines protocol mechanisms to address this requirement. The procedures described in this document are equally applicable for point-to-point (P2P) and point-to- multipoint (P2MP) LSPs. |
|
| |
| RFC 6512 | Using Multipoint LDP When the Backbone Has No Route to the Root |
| |
| Authors: | IJ. Wijnands, E. Rosen, M. Napierala, N. Leymann. |
| Date: | February 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6512 |
|
The control protocol used for constructing Point-to-Multipoint andMultipoint-to-Multipoint Label Switched Paths ("MP LSPs") contains a field that identifies the address of a "root node". Intermediate nodes are expected to be able to look up that address in their routing tables. However, this is not possible if the route to the root node is a BGP route and the intermediate nodes are part of aBGP-free core. This document specifies procedures that enable an MPLSP to be constructed through a BGP-free core. In these procedures, the root node address is temporarily replaced by an address that is known to the intermediate nodes and is on the path to the true root node. |
|
| |
| RFC 6513 | Multicast in MPLS/BGP IP VPNs |
| |
|
|
In order for IP multicast traffic within a BGP/MPLS IP VPN (VirtualPrivate Network) to travel from one VPN site to another, special protocols and procedures must be implemented by the VPN ServiceProvider. These protocols and procedures are specified in this document. |
|
| |
| RFC 6514 | BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs |
| |
| Authors: | R. Aggarwal, E. Rosen, T. Morin, Y. Rekhter. |
| Date: | February 2012 |
| Formats: | txt html json |
| Updated by: | RFC 6515, RFC 6625, RFC 7385, RFC 7441, RFC 7582, RFC 7899, RFC 7900, RFC 7902, RFC 7988, RFC 8534, RFC 9081 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6514 |
|
This document describes the BGP encodings and procedures for exchanging the information elements required by Multicast in MPLS/BGPIP VPNs, as specified in RFC 6513. |
|
| |
| RFC 6515 | IPv4 and IPv6 Infrastructure Addresses in BGP Updates for Multicast VPN |
| |
| Authors: | R. Aggarwal, E. Rosen. |
| Date: | February 2012 |
| Formats: | txt html json |
| Updates: | RFC 6514 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6515 |
|
To provide Multicast VPN (MVPN) service, Provider Edge routers originate BGP Update messages that carry Multicast-VPN ("MCAST-VPN")BGP routes; they also originate unicast VPN routes that carry MVPN- specific attributes. These routes encode addresses from the customer's address space, as well as addresses from the provider's address space. These two address spaces are independent, and the address family (IPv4 or IPv6) of the two spaces may or may not be the same. These routes always contain an "address family" field that specifies whether the customer addresses are IPv4 addresses or whether they are IPv6 addresses. However, there is no field that explicitly specifies the address family of the provider addresses.To ensure interoperability, this document specifies that providerIPv4 addresses are always encoded in these update messages as 4-octet addresses, and that the distinction between IPv4 and IPv6 is signaled solely by the length of the address field. Specific cases are explained in detail. This document updates RFC 6514. |
|
| |
| RFC 6516 | IPv6 Multicast VPN (MVPN) Support Using PIM Control Plane and Selective Provider Multicast Service Interface (S-PMSI) Join Messages |
| |
| Authors: | Y. Cai, E. Rosen, Ed., I. Wijnands. |
| Date: | February 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6516 |
|
The specification for Multicast Virtual Private Networks (MVPNs) contains an option that allows the use of PIM as the control protocol between provider edge routers. It also contains an option that allows UDP-based messages, known as Selective Provider MulticastService Interface (S-PMSI) Join messages, to be used to bind particular customer multicast flows to particular tunnels through a service provider's network. This document extends the MVPN specification (RFC 6513) so that these options can be used when the customer multicast flows are IPv6 flows. |
|
| |
| RFC 6519 | RADIUS Extensions for Dual-Stack Lite |
| |
| Authors: | R. Maglione, A. Durand. |
| Date: | February 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6519 |
|
Dual-Stack Lite is a solution to offer both IPv4 and IPv6 connectivity to customers that are addressed only with an IPv6 prefix. Dual-Stack Lite requires pre-configuration of the Dual-StackLite Address Family Transition Router (AFTR) tunnel information on the Basic Bridging BroadBand (B4) element. In many networks, the customer profile information may be stored in Authentication,Authorization, and Accounting (AAA) servers, while client configurations are mainly provided through the Dynamic HostConfiguration Protocol (DHCP). This document specifies a new RemoteAuthentication Dial-In User Service (RADIUS) attribute to carry theDual-Stack Lite AFTR tunnel name; the RADIUS attribute is defined based on the equivalent DHCPv6 OPTION_AFTR_NAME option. This RADIUS attribute is meant to be used between the RADIUS server and theNetwork Access Server (NAS); it is not intended to be used directly between the B4 element and the RADIUS server. |
|
| |
| RFC 6520 | Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension |
| |
| Authors: | R. Seggelmann, M. Tuexen, M. Williams. |
| Date: | February 2012 |
| Formats: | txt html json |
| Updated by: | RFC 8447 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6520 |
|
This document describes the Heartbeat Extension for the TransportLayer Security (TLS) and Datagram Transport Layer Security (DTLS) protocols.
The Heartbeat Extension provides a new protocol for TLS/DTLS allowing the usage of keep-alive functionality without performing a renegotiation and a basis for path MTU (PMTU) discovery for DTLS. |
|
| |
| RFC 6525 | Stream Control Transmission Protocol (SCTP) Stream Reconfiguration |
| |
| Authors: | R. Stewart, M. Tuexen, P. Lei. |
| Date: | February 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6525 |
|
Many applications that use the Stream Control Transmission Protocol(SCTP) want the ability to "reset" a stream. The intention of resetting a stream is to set the numbering sequence of the stream back to 'zero' with a corresponding notification to the application layer that the reset has been performed. Applications requiring this feature want it so that they can "reuse" streams for different purposes but still utilize the stream sequence number so that the application can track the message flows. Thus, without this feature, a new use of an old stream would result in message numbers greater than expected, unless there is a protocol mechanism to "reset the streams back to zero". This document also includes methods for resetting the transmission sequence numbers, adding additional streams, and resetting all stream sequence numbers. |
|
| |
| RFC 6526 | IP Flow Information Export (IPFIX) Per Stream Control Transmission Protocol (SCTP) Stream |
| |
| Authors: | B. Claise, P. Aitken, A. Johnson, G. Muenz. |
| Date: | March 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6526 |
|
This document specifies an extension to the specifications in RFC5101, IP Flow Information Export (IPFIX), when using the PartialReliability extension of SCTP (PR-SCTP, Partial Reliability StreamControl Transmission Protocol).
When implemented at both the Exporting Process and CollectingProcess, this method offers several advantages, such as the ability to calculate Data Record losses for PR-SCTP per Template, immediate export of Template Withdrawal Messages, immediate reuse of TemplateIDs within an SCTP stream, reduced likelihood of Data Record loss, and reduced demands on the Collecting Process. When implemented in only the Collecting Process or Exporting Process, then normal IPFIX behavior will be seen without all of the additional benefits. |
|
| |
| RFC 6527 | Definitions of Managed Objects for Virtual Router Redundancy Protocol Version 3 (VRRPv3) |
| |
|
|
This specification defines a portion of the Management InformationBase (MIB) for use with network management based on the SimpleNetwork Management Protocol (SNMP). In particular, it defines objects for configuring, monitoring, and controlling routers that employ the Virtual Router Redundancy Protocol Version 3 (VRRPv3) for both IPv4 and IPv6 as defined in RFC 5798. This memo obsoletes RFC2787. |
|
| |
| RFC 6528 | Defending against Sequence Number Attacks |
| |
|
|
This document specifies an algorithm for the generation of TCPInitial Sequence Numbers (ISNs), such that the chances of an off-path attacker guessing the sequence numbers in use by a target connection are reduced. This document revises (and formally obsoletes) RFC1948, and takes the ISN generation algorithm originally proposed in that document to Standards Track, formally updating RFC 793. |
|
| |
| RFC 6530 | Overview and Framework for Internationalized Email |
| |
|
|
Full use of electronic mail throughout the world requires that(subject to other constraints) people be able to use close variations on their own names (written correctly in their own languages and scripts) as mailbox names in email addresses. This document introduces a series of specifications that define mechanisms and protocol extensions needed to fully support internationalized email addresses. These changes include an SMTP extension and extension of email header syntax to accommodate UTF-8 data. The document set also includes discussion of key assumptions and issues in deploying fully internationalized email. This document is a replacement for RFC4952; it reflects additional issues identified since that document was published. |
|
| |
| RFC 6531 | SMTP Extension for Internationalized Email |
| |
|
|
This document specifies an SMTP extension for transport and delivery of email messages with internationalized email addresses or header information. |
|
| |
| RFC 6532 | Internationalized Email Headers |
| |
|
|
Internet mail was originally limited to 7-bit ASCII. MIME added support for the use of 8-bit character sets in body parts, and also defined an encoded-word construct so other character sets could be used in certain header field values. However, full internationalization of electronic mail requires additional enhancements to allow the use of Unicode, including characters outside the ASCII repertoire, in mail addresses as well as direct use of Unicode in header fields like "From:", "To:", and "Subject:", without requiring the use of complex encoded-word constructs. This document specifies an enhancement to the Internet Message Format and to MIME that allows use of Unicode in mail addresses and most header field content.
This specification updates Section 6.4 of RFC 2045 to eliminate the restriction prohibiting the use of non-identity content-transfer- encodings on subtypes of "message/". |
|
| |
| RFC 6533 | Internationalized Delivery Status and Disposition Notifications |
| |
|
|
Delivery status notifications (DSNs) are critical to the correct operation of an email system. However, the existing Draft Standards(RFC 3461, RFC 3464, RFC 6522) are presently limited to ASCII text in the machine-readable portions of the protocol. This specification adds a new address type for international email addresses so an original recipient address with non-ASCII characters can be correctly preserved even after downgrading. This also provides updated content return media types for delivery status notifications and message disposition notifications to support use of the new address type.
This document extends RFC 3461, RFC 3464, RFC 3798, and RFC 6522. |
|
| |
| RFC 6534 | Loss Episode Metrics for IP Performance Metrics (IPPM) |
| |
| Authors: | N. Duffield, A. Morton, J. Sommers. |
| Date: | May 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6534 |
|
The IETF has developed a one-way packet loss metric that measures the loss rate on a Poisson and Periodic probe streams between two hosts.However, the impact of packet loss on applications is, in general, sensitive not just to the average loss rate but also to the way in which packet losses are distributed in loss episodes (i.e., maximal sets of consecutively lost probe packets). This document defines one-way packet loss episode metrics, specifically, the frequency and average duration of loss episodes and a probing methodology under which the loss episode metrics are to be measured. |
|
| |
| RFC 6535 | Dual-Stack Hosts Using "Bump-in-the-Host" (BIH) |
| |
|
|
Bump-in-the-Host (BIH) is a host-based IPv4 to IPv6 protocol translation mechanism that allows a class of IPv4-only applications that work through NATs to communicate with IPv6-only peers. The host on which applications are running may be connected to IPv6-only or dual-stack access networks. BIH hides IPv6 and makes the IPv4-only applications think they are talking with IPv4 peers by local synthesis of IPv4 addresses. This document obsoletes RFC 2767 andRFC 3338. |
|
| |
| RFC 6536 | Network Configuration Protocol (NETCONF) Access Control Model |
| |
| Authors: | A. Bierman, M. Bjorklund. |
| Date: | March 2012 |
| Formats: | txt json html |
| Obsoleted by: | RFC 8341 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6536 |
|
The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF protocol access for particular users to a pre-configured subset of all available NETCONF protocol operations and content. This document defines such an access control model. |
|
| |
| RFC 6542 | Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Channel Binding Hash Agility |
| |
|
|
Currently, channel bindings are implemented using an MD5 hash in theKerberos Version 5 Generic Security Service Application ProgrammingInterface (GSS-API) mechanism (RFC 4121). This document updates RFC4121 to allow channel bindings using algorithms negotiated based onKerberos crypto framework as defined in RFC 3961. In addition, because this update makes use of the last extensible field in theKerberos client-server exchange message, extensions are defined to allow future protocol extensions. |
|
| |
| RFC 6543 | Reserved IPv6 Interface Identifier for Proxy Mobile IPv6 |
| |
|
|
Proxy Mobile IPv6 (RFC 5213) requires that all mobile access gateways use a fixed link-local address and a fixed link-layer address on any of their access links that they share with mobile nodes. This requirement was intended to ensure that a mobile node does not detect any change with respect to its Layer 3 attachment, even after it roams from one mobile access gateway to another. In the absence of any reserved addresses for this use, coordination across vendors and manual configuration of these addresses on all of the mobility elements in a Proxy Mobile IPv6 domain are required. This document attempts to simplify this operational requirement by making a reservation for special addresses that can be used for this purpose.This document also updates RFC 5213. |
|
| |
| RFC 6544 | TCP Candidates with Interactive Connectivity Establishment (ICE) |
| |
| Authors: | J. Rosenberg, A. Keranen, B. B. Lowekamp, A. B. Roach. |
| Date: | March 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6544 |
|
Interactive Connectivity Establishment (ICE) defines a mechanism forNAT traversal for multimedia communication protocols based on the offer/answer model of session negotiation. ICE works by providing a set of candidate transport addresses for each media stream, which are then validated with peer-to-peer connectivity checks based on SessionTraversal Utilities for NAT (STUN). ICE provides a general framework for describing candidates but only defines UDP-based media streams.This specification extends ICE to TCP-based media, including the ability to offer a mix of TCP and UDP-based candidates for a single stream. |
|
| |
| RFC 6545 | Real-time Inter-network Defense (RID) |
| |
|
|
Security incidents, such as system compromises, worms, viruses, phishing incidents, and denial of service, typically result in the loss of service, data, and resources both human and system. Service providers and Computer Security Incident Response Teams need to be equipped and ready to assist in communicating and tracing security incidents with tools and procedures in place before the occurrence of an attack. Real-time Inter-network Defense (RID) outlines a proactive inter-network communication method to facilitate sharing incident-handling data while integrating existing detection, tracing, source identification, and mitigation mechanisms for a complete incident-handling solution. Combining these capabilities in a communication system provides a way to achieve higher security levels on networks. Policy guidelines for handling incidents are recommended and can be agreed upon by a consortium using the security recommendations and considerations. This document obsoletes RFC6045. |
|
| |
| RFC 6546 | Transport of Real-time Inter-network Defense (RID) Messages over HTTP/TLS |
| |
|
|
The Incident Object Description Exchange Format (IODEF) defines a common XML format for document exchange, and Real-time Inter-networkDefense (RID) defines extensions to IODEF intended for the cooperative handling of security incidents within consortia of network operators and enterprises. This document specifies an application-layer protocol for RID based upon the passing of RID messages over HTTP/TLS. |
|
| |
| RFC 6549 | OSPFv2 Multi-Instance Extensions |
| |
| Authors: | A. Lindem, A. Roy, S. Mirtorabi. |
| Date: | March 2012 |
| Formats: | txt json html |
| Updates: | RFC 2328 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6549 |
|
OSPFv3 includes a mechanism to support multiple instances of the protocol running on the same interface. OSPFv2 can utilize such a mechanism in order to support multiple routing domains on the same subnet.
This document defines the OSPFv2 Instance ID to enable separateOSPFv2 protocol instances on the same interface. Unlike OSPFv3 where the Instance ID can be used for multiple purposes, such as putting the same interface in multiple areas, the OSPFv2 Instance ID is reserved for identifying protocol instances.
This document updates RFC 2328. |
|
| |
| RFC 6550 | RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks |
| |
| Authors: | T. Winter, Ed., P. Thubert, Ed., A. Brandt, J. Hui, R. Kelsey, P. Levis, K. Pister, R. Struik, JP. Vasseur, R. Alexander. |
| Date: | March 2012 |
| Formats: | txt json html |
| Updated by: | RFC 9008, RFC 9010 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6550 |
|
Low-Power and Lossy Networks (LLNs) are a class of network in which both the routers and their interconnect are constrained. LLN routers typically operate with constraints on processing power, memory, and energy (battery power). Their interconnects are characterized by high loss rates, low data rates, and instability. LLNs are comprised of anything from a few dozen to thousands of routers. Supported traffic flows include point-to-point (between devices inside theLLN), point-to-multipoint (from a central control point to a subset of devices inside the LLN), and multipoint-to-point (from devices inside the LLN towards a central control point). This document specifies the IPv6 Routing Protocol for Low-Power and Lossy Networks(RPL), which provides a mechanism whereby multipoint-to-point traffic from devices inside the LLN towards a central control point as well as point-to-multipoint traffic from the central control point to the devices inside the LLN are supported. Support for point-to-point traffic is also available. |
|
| |
| RFC 6551 | Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks |
| |
| Authors: | JP. Vasseur, Ed., M. Kim, Ed., K. Pister, N. Dejean, D. Barthel. |
| Date: | March 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6551 |
|
Low-Power and Lossy Networks (LLNs) have unique characteristics compared with traditional wired and ad hoc networks that require the specification of new routing metrics and constraints. By contrast, with typical Interior Gateway Protocol (IGP) routing metrics using hop counts or link metrics, this document specifies a set of link and node routing metrics and constraints suitable to LLNs to be used by the Routing Protocol for Low-Power and Lossy Networks (RPL). |
|
| |
| RFC 6552 | Objective Function Zero for the Routing Protocol for Low-Power and Lossy Networks (RPL) |
| |
| Authors: | P. Thubert, Ed.. |
| Date: | March 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6552 |
|
The Routing Protocol for Low-Power and Lossy Networks (RPL) specification defines a generic Distance Vector protocol that is adapted to a variety of network types by the application of specificObjective Functions (OFs). An OF states the outcome of the process used by a RPL node to select and optimize routes within a RPLInstance based on the Information Objects available; an OF is not an algorithm.
This document specifies a basic Objective Function that relies only on the objects that are defined in the RPL and does not use any protocol extensions. |
|
| |
| RFC 6553 | The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams |
| |
|
|
The Routing Protocol for Low-Power and Lossy Networks (RPL) includes routing information in data-plane datagrams to quickly identify inconsistencies in the routing topology. This document describes theRPL Option for use among RPL routers to include such routing information. |
|
| |
| RFC 6554 | An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL) |
| |
| Authors: | J. Hui, JP. Vasseur, D. Culler, V. Manral. |
| Date: | March 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6554 |
|
In Low-Power and Lossy Networks (LLNs), memory constraints on routers may limit them to maintaining, at most, a few routes. In some configurations, it is necessary to use these memory-constrained routers to deliver datagrams to nodes within the LLN. The RoutingProtocol for Low-Power and Lossy Networks (RPL) can be used in some deployments to store most, if not all, routes on one (e.g., theDirected Acyclic Graph (DAG) root) or a few routers and forward theIPv6 datagram using a source routing technique to avoid large routing tables on memory-constrained routers. This document specifies a newIPv6 Routing header type for delivering datagrams within a RPL routing domain. |
|
| |
| RFC 6555 | Happy Eyeballs: Success with Dual-Stack Hosts |
| |
| Authors: | D. Wing, A. Yourtchenko. |
| Date: | April 2012 |
| Formats: | txt json html |
| Obsoleted by: | RFC 8305 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6555 |
|
When a server's IPv4 path and protocol are working, but the server'sIPv6 path and protocol are not working, a dual-stack client application experiences significant connection delay compared to anIPv4-only client. This is undesirable because it causes the dual- stack client to have a worse user experience. This document specifies requirements for algorithms that reduce this user-visible delay and provides an algorithm. |
|
| |
| RFC 6558 | Sieve Extension for Converting Messages before Delivery |
| |
| Authors: | A. Melnikov, B. Leiba, K. Li. |
| Date: | March 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6558 |
|
This document describes how the "CONVERT" IMAP extension can be used within the Sieve mail filtering language to transform messages before final delivery. |
|
| |
| RFC 6560 | One-Time Password (OTP) Pre-Authentication |
| |
| Authors: | G. Richards. |
| Date: | April 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6560 |
|
The Kerberos protocol provides a framework authenticating a client using the exchange of pre-authentication data. This document describes the use of this framework to carry out One-Time Password(OTP) authentication. |
|
| |
| RFC 6562 | Guidelines for the Use of Variable Bit Rate Audio with Secure RTP |
| |
| Authors: | C. Perkins, JM. Valin. |
| Date: | March 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6562 |
|
This memo discusses potential security issues that arise when using variable bit rate (VBR) audio with the secure RTP profile.Guidelines to mitigate these issues are suggested. |
|
| |
| RFC 6564 | A Uniform Format for IPv6 Extension Headers |
| |
| Authors: | S. Krishnan, J. Woodyatt, E. Kline, J. Hoagland, M. Bhatia. |
| Date: | April 2012 |
| Formats: | txt json html |
| Updates: | RFC 2460 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6564 |
|
In IPv6, optional internet-layer information is encoded in separate headers that may be placed between the IPv6 header and the transport- layer header. There are a small number of such extension headers currently defined. This document describes the issues that can arise when defining new extension headers and discusses the alternate extension mechanisms in IPv6. It also provides a common format for defining any new IPv6 extension headers, if they are needed. |
|
| |
| RFC 6565 | OSPFv3 as a Provider Edge to Customer Edge (PE-CE) Routing Protocol |
| |
| Authors: | P. Pillay-Esnault, P. Moyer, J. Doyle, E. Ertekin, M. Lundberg. |
| Date: | June 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6565 |
|
Many Service Providers (SPs) offer Virtual Private Network (VPN) services to their customers using a technique in which Customer Edge(CE) routers are routing peers of Provider Edge (PE) routers. TheBorder Gateway Protocol (BGP) is used to distribute the customer's routes across the provider's IP backbone network, and MultiprotocolLabel Switching (MPLS) is used to tunnel customer packets across the provider's backbone. Support currently exists for both IPv4 and IPv6VPNs; however, only Open Shortest Path First version 2 (OSPFv2) asPE-CE protocol is specified. This document extends those specifications to support OSPF version 3 (OSPFv3) as a PE-CE routing protocol. The OSPFv3 PE-CE functionality is identical to that ofOSPFv2 except for the differences described in this document. |
|
| |
| RFC 6570 | URI Template |
| |
| Authors: | J. Gregorio, R. Fielding, M. Hadley, M. Nottingham, D. Orchard. |
| Date: | March 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6570 |
|
A URI Template is a compact sequence of characters for describing a range of Uniform Resource Identifiers through variable expansion.This specification defines the URI Template syntax and the process for expanding a URI Template into a URI reference, along with guidelines for the use of URI Templates on the Internet. |
|
| |
| RFC 6572 | RADIUS Support for Proxy Mobile IPv6 |
| |
| Authors: | F. Xia, B. Sarikaya, J. Korhonen, Ed., S. Gundavelli, D. Damic. |
| Date: | June 2012 |
| Formats: | txt html json |
| Updated by: | RFC 8044 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6572 |
|
This document defines new attributes to facilitate Proxy Mobile IPv6 operations using the RADIUS infrastructure. The protocol defined in this document uses RADIUS-based interfaces of the mobile access gateway and the local mobility anchor with the AAA server for authentication, authorization, and policy functions. The RADIUS interactions between the mobile access gateway and the RADIUS-basedAAA server take place when the mobile node (MN) attaches, authenticates, and authorizes to a Proxy Mobile IPv6 domain.Furthermore, this document defines the RADIUS-based interface between the local mobility anchor and the AAA RADIUS server for authorizing received Proxy Binding Update messages for the mobile node's mobility session. In addition to the interactions related to mobility session setup, this document defines the baseline for the mobile access gateway and the local mobility anchor generated accounting. |
|
| |
| RFC 6575 | Address Resolution Protocol (ARP) Mediation for IP Interworking of Layer 2 VPNs |
| |
| Authors: | H. Shah, Ed., E. Rosen, Ed., G. Heron, Ed., V. Kompella, Ed.. |
| Date: | June 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6575 |
|
The Virtual Private Wire Service (VPWS), detailed in RFC 4664, provides point-to-point connections between pairs of Customer Edge(CE) devices. It does so by binding two Attachment Circuits (each connecting a CE device with a Provider Edge (PE) device) to a pseudowire (connecting the two PEs). In general, the AttachmentCircuits must be of the same technology (e.g., both Ethernet or bothATM), and the pseudowire must carry the frames of that technology.However, if it is known that the frames' payload consists solely ofIP datagrams, it is possible to provide a point-to-point connection in which the pseudowire connects Attachment Circuits of different technologies. This requires the PEs to perform a function known as"Address Resolution Protocol (ARP) Mediation". ARP Mediation refers to the process of resolving Layer 2 addresses when different resolution protocols are used on either Attachment Circuit. The methods described in this document are applicable even when the CEs run a routing protocol between them, as long as the routing protocol runs over IP. |
|
| |
| RFC 6577 | Authentication-Results Registration Update for Sender Policy Framework (SPF) Results |
| |
|
|
This memo updates the registry of authentication method results inAuthentication-Results: message header fields, correcting a discontinuity between the original registry creation and the SenderPolicy Framework (SPF) specification.
This memo updates RFC 5451. |
|
| |
| RFC 6578 | Collection Synchronization for Web Distributed Authoring and Versioning (WebDAV) |
| |
| Authors: | C. Daboo, A. Quillaud. |
| Date: | March 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6578 |
|
This specification defines an extension to Web Distributed Authoring and Versioning (WebDAV) that allows efficient synchronization of the contents of a WebDAV collection. |
|
| |
| RFC 6580 | IANA Registries for the Remote Direct Data Placement (RDDP) Protocols |
| |
| Authors: | M. Ko, D. Black. |
| Date: | April 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6580 |
|
The original RFCs that specified the Remote Direct Data Placement(RDDP) protocol suite did not create IANA registries for RDDP error codes, operation codes, and function codes. Extensions to the RDDP protocols now require these registries to be created. This memo creates the RDDP registries, populates them with values defined in the original RDDP RFCs, and provides guidance to IANA for future assignment of code points within these registries. |
|
| |
| RFC 6581 | Enhanced Remote Direct Memory Access (RDMA) Connection Establishment |
| |
|
|
This document updates RFC 5043 and RFC 5044 by extending MarkerProtocol Data Unit (PDU) Aligned Framing (MPA) negotiation for RemoteDirect Memory Access (RDMA) connection establishment. The first enhancement extends RFC 5044, enabling peer-to-peer connection establishment over MPA / Transmission Control Protocol (TCP). The second enhancement extends both RFC 5043 and RFC 5044, by providing an option for standardized exchange of RDMA-layer connection configuration. |
|
| |
| RFC 6582 | The NewReno Modification to TCP's Fast Recovery Algorithm |
| |
| Authors: | T. Henderson, S. Floyd, A. Gurtov, Y. Nishida. |
| Date: | April 2012 |
| Formats: | txt html json |
| Obsoletes: | RFC 3782 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6582 |
|
RFC 5681 documents the following four intertwined TCP congestion control algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery. RFC 5681 explicitly allows certain modifications of these algorithms, including modifications that use the TCP Selective Acknowledgment (SACK) option (RFC 2883), and modifications that respond to "partial acknowledgments" (ACKs that cover new data, but not all the data outstanding when loss was detected) in the absence of SACK. This document describes a specific algorithm for responding to partial acknowledgments, referred to as"NewReno". This response to partial acknowledgments was first proposed by Janey Hoe. This document obsoletes RFC 3782. |
|
| |
| RFC 6584 | Simple Authentication Schemes for the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols |
| |
| Authors: | V. Roca. |
| Date: | April 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6584 |
|
This document introduces four schemes that provide per-packet authentication, integrity, and anti-replay services in the context of the Asynchronous Layered Coding (ALC) and NACK-Oriented ReliableMulticast (NORM) protocols. The first scheme is based on RSA DigitalSignatures. The second scheme relies on the Elliptic Curve DigitalSignature Algorithm (ECDSA). The third scheme relies on a Group- keyed Message Authentication Code (MAC). Finally, the fourth scheme merges the Digital Signature and group schemes. These schemes have different target use cases, and they do not all provide the same service. |
|
| |
| RFC 6585 | Additional HTTP Status Codes |
| |
| Authors: | M. Nottingham, R. Fielding. |
| Date: | April 2012 |
| Formats: | txt json html |
| Updates: | RFC 2616 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6585 |
|
This document specifies additional HyperText Transfer Protocol (HTTP) status codes for a variety of common situations. |
|
| |
| RFC 6590 | Redaction of Potentially Sensitive Data from Mail Abuse Reports |
| |
| Authors: | J. Falk, Ed., M. Kucherawy, Ed.. |
| Date: | April 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6590 |
|
Email messages often contain information that might be considered private or sensitive, per either regulation or social norms. When such a message becomes the subject of a report intended to be shared with other entities, the report generator may wish to redact or elide the sensitive portions of the message. This memo suggests one method for doing so effectively. |
|
| |
| RFC 6591 | Authentication Failure Reporting Using the Abuse Reporting Format |
| |
|
|
This memo registers an extension report type for the Abuse ReportingFormat (ARF), affecting multiple registries, for use in generating receipt-time reports about messages that fail one or more email message authentication checks. |
|
| |
| RFC 6594 | Use of the SHA-256 Algorithm with RSA, Digital Signature Algorithm (DSA), and Elliptic Curve DSA (ECDSA) in SSHFP Resource Records |
| |
| Authors: | O. Sury. |
| Date: | April 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6594 |
|
This document updates the IANA registries in RFC 4255, which definesSSHFP, a DNS Resource Record (RR) that contains a standard SecureShell (SSH) key fingerprint used to verify SSH host keys using DNSSecurity Extensions (DNSSEC). This document defines additional options supporting SSH public keys applying the Elliptic CurveDigital Signature Algorithm (ECDSA) and the implementation of fingerprints computed using the SHA-256 message digest algorithm inSSHFP Resource Records. |
|
| |
| RFC 6595 | A Simple Authentication and Security Layer (SASL) and GSS-API Mechanism for the Security Assertion Markup Language (SAML) |
| |
| Authors: | K. Wierenga, E. Lear, S. Josefsson. |
| Date: | April 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6595 |
|
The Security Assertion Markup Language (SAML) has found its usage on the Internet for Web Single Sign-On. The Simple Authentication andSecurity Layer (SASL) and the Generic Security Service ApplicationProgram Interface (GSS-API) are application frameworks to generalize authentication. This memo specifies a SASL mechanism and a GSS-API mechanism for SAML 2.0 that allows the integration of existing SAMLIdentity Providers with applications using SASL and GSS-API. |
|
| |
| RFC 6597 | RTP Payload Format for Society of Motion Picture and Television Engineers (SMPTE) ST 336 Encoded Data |
| |
| Authors: | J. Downs, Ed., J. Arbeiter, Ed.. |
| Date: | April 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6597 |
|
This document specifies the payload format for packetization of KLV(Key-Length-Value) Encoded Data, as defined by the Society of MotionPicture and Television Engineers (SMPTE) in SMPTE ST 336, into theReal-time Transport Protocol (RTP). |
|
| |
| RFC 6602 | Bulk Binding Update Support for Proxy Mobile IPv6 |
| |
| Authors: | F. Abinader, Ed., S. Gundavelli, Ed., K. Leung, S. Krishnan, D. Premec. |
| Date: | May 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6602 |
|
For extending the lifetime of a mobility session, the Proxy MobileIPv6 specification requires the mobile access gateway to send a ProxyBinding Update message to the local mobility anchor on a per-session basis. In the absence of signaling semantics for performing operations with group-specific scope, this results in a significant amount of signaling traffic on a periodic basis between a given mobile access gateway and a local mobility anchor. This document defines optimizations to the binding update and revocation operations in Proxy Mobile IPv6 for performing operations with group-specific scope with the use of a group identifier. |
|
| |
| RFC 6603 | Prefix Exclude Option for DHCPv6-based Prefix Delegation |
| |
| Authors: | J. Korhonen, Ed., T. Savolainen, S. Krishnan, O. Troan. |
| Date: | May 2012 |
| Formats: | txt html json |
| Updates: | RFC 3633 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6603 |
|
This specification defines an optional mechanism to allow exclusion of one specific prefix from a delegated prefix set when usingDHCPv6-based prefix delegation. The new mechanism updates RFC 3633. |
|
| |
| RFC 6604 | xNAME RCODE and Status Bits Clarification |
| |
|
|
The Domain Name System (DNS) has long provided means, such as theCNAME (Canonical Name), whereby a DNS query can be redirected to a different name. A DNS response header has an RCODE (Response Code) field, used for indicating errors, and response status bits. This document clarifies, in the case of such redirected queries, how theRCODE and status bits correspond to the initial query cycle (where the CNAME or the like was detected) and subsequent or final query cycles. |
|
| |
| RFC 6605 | Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC |
| |
| Authors: | P. Hoffman, W.C.A. Wijngaards. |
| Date: | April 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6605 |
|
This document describes how to specify Elliptic Curve DigitalSignature Algorithm (DSA) keys and signatures in DNS Security(DNSSEC). It lists curves of different sizes and uses the SHA-2 family of hashes for signatures. |
|
| |
| RFC 6607 | Virtual Subnet Selection Options for DHCPv4 and DHCPv6 |
| |
| Authors: | K. Kinnear, R. Johnson, M. Stapp. |
| Date: | April 2012 |
| Formats: | txt html json |
| Updates: | RFC 3046 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6607 |
|
This memo defines a DHCPv4 Virtual Subnet Selection (VSS) option, aDHCPv6 VSS option, and the DHCPv4 VSS and VSS-Control sub-options carried in the DHCPv4 Relay Agent Information option. These are intended for use by DHCP clients, relay agents, and proxy clients in situations where VSS information needs to be passed to the DHCP server for proper address or prefix allocation to take place.
For the DHCPv4 option and Relay Agent Information sub-options, this memo documents and extends existing usage as per RFC 3942. This memo updates RFC 3046 regarding details relating to the copying of sub- options (see Section 8). |
|
| |
| RFC 6608 | Subcodes for BGP Finite State Machine Error |
| |
| Authors: | J. Dong, M. Chen, A. Suryanarayana. |
| Date: | May 2012 |
| Formats: | txt json html |
| Updates: | RFC 4271 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6608 |
|
This document defines several subcodes for the BGP Finite StateMachine (FSM) Error that could provide more information to help network operators in diagnosing BGP FSM issues and correlating network events. This document updates RFC 4271. |
|
| |
| RFC 6609 | Sieve Email Filtering: Include Extension |
| |
| Authors: | C. Daboo, A. Stone. |
| Date: | May 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6609 |
|
The Sieve Email Filtering "include" extension permits users to include one Sieve script inside another. This can make managing large scripts or multiple sets of scripts much easier, and allows a site and its users to build up libraries of scripts. Users are able to include their own personal scripts or site-wide scripts. |
|
| |
| RFC 6610 | DHCP Options for Home Information Discovery in Mobile IPv6 (MIPv6) |
| |
| Authors: | H. Jang, A. Yegin, K. Chowdhury, J. Choi, T. Lemon. |
| Date: | May 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6610 |
|
This document defines a DHCP-based scheme to enable dynamic discovery of Mobile IPv6 home network information. New DHCP options are defined that allow a mobile node to request the home agent IP address, Fully Qualified Domain Name (FQDN), or home network prefix and obtain it via the DHCP response. |
|
| |
| RFC 6611 | Mobile IPv6 (MIPv6) Bootstrapping for the Integrated Scenario |
| |
| Authors: | K. Chowdhury, Ed., A. Yegin. |
| Date: | May 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6611 |
|
Mobile IPv6 bootstrapping can be categorized into two primary scenarios: the split scenario and the integrated scenario. In the split scenario, the mobile node's mobility service is authorized by a different service authorizer than the network access authorizer. In the integrated scenario, the mobile node's mobility service is authorized by the same service authorizer as the network access service authorizer. This document defines a method for home agent information discovery for the integrated scenario. |
|
| |
| RFC 6615 | Definitions of Managed Objects for IP Flow Information Export |
| |
| Authors: | T. Dietz, Ed., A. Kobayashi, B. Claise, G. Muenz. |
| Date: | June 2012 |
| Formats: | txt json html |
| Obsoletes: | RFC 5815 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6615 |
|
This document defines managed objects for IP Flow Information eXport(IPFIX). These objects provide information for monitoring IPFIXExporters and IPFIX Collectors, including basic configuration information. |
|
| |
| RFC 6616 | A Simple Authentication and Security Layer (SASL) and Generic Security Service Application Program Interface (GSS-API) Mechanism for OpenID |
| |
| Authors: | E. Lear, H. Tschofenig, H. Mauldin, S. Josefsson. |
| Date: | May 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6616 |
|
OpenID has found its usage on the Internet for Web Single Sign-On.Simple Authentication and Security Layer (SASL) and the GenericSecurity Service Application Program Interface (GSS-API) are application frameworks to generalize authentication. This memo specifies a SASL and GSS-API mechanism for OpenID that allows the integration of existing OpenID Identity Providers with applications using SASL and GSS-API. |
|
| |
| RFC 6619 | Scalable Operation of Address Translators with Per-Interface Bindings |
| |
| Authors: | J. Arkko, L. Eggert, M. Townsley. |
| Date: | June 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6619 |
|
This document explains how to employ address translation in networks that serve a large number of individual customers without requiring a correspondingly large amount of private IPv4 address space. |
|
| |
| RFC 6620 | FCFS SAVI: First-Come, First-Served Source Address Validation Improvement for Locally Assigned IPv6 Addresses |
| |
| Authors: | E. Nordmark, M. Bagnulo, E. Levy-Abegnoli. |
| Date: | May 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6620 |
|
This memo describes First-Come, First-Served Source AddressValidation Improvement (FCFS SAVI), a mechanism that provides source address validation for IPv6 networks using the FCFS principle. The proposed mechanism is intended to complement ingress filtering techniques to help detect and prevent source address spoofing. |
|
| |
| RFC 6622 | Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs) |
| |
| Authors: | U. Herberg, T. Clausen. |
| Date: | May 2012 |
| Formats: | txt html json |
| Obsoleted by: | RFC 7182 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6622 |
|
This document describes general and flexible TLVs for representing cryptographic Integrity Check Values (ICVs) (i.e., digital signatures or Message Authentication Codes (MACs)) as well as timestamps, using the generalized Mobile Ad Hoc Network (MANET) packet/message format defined in RFC 5444. It defines two Packet TLVs, two Message TLVs, and two Address Block TLVs for affixing ICVs and timestamps to a packet, a message, and an address, respectively. |
|
| |
| RFC 6623 | IANA Registry for MEDIACTRL Interactive Voice Response Control Package |
| |
|
|
This document creates an IANA registry for the response codes for theMEDIACTRL Interactive Voice Response Control Package, as described inRFC 6231. |
|
| |
| RFC 6625 | Wildcards in Multicast VPN Auto-Discovery Routes |
| |
|
|
In Multicast Virtual Private Networks (MVPNs), customer multicast flows are carried in "tunnels" through a service provider's network.The base specifications for MVPN define BGP multicast VPN "auto- discovery routes" and specify how to use an auto-discovery route to advertise the fact that an individual customer multicast flow is being carried in a particular tunnel. However, those specifications do not provide a way to specify, in a single such route, that multiple customer flows are being carried in a single tunnel. Those specifications also do not provide a way to advertise that a particular tunnel is to be used by default to carry all customer flows, except in the case where that tunnel is joined by all the provider edge routers of the MVPN. This document eliminates these restrictions by specifying the use of "wildcard" elements in the customer flow identifiers. With wildcard elements, a single auto- discovery route can refer to multiple customer flows or even to all customer flows. |
|
| |
| RFC 6626 | Dynamic Prefix Allocation for Network Mobility for Mobile IPv4 (NEMOv4) |
| |
| Authors: | G. Tsirtsis, V. Park, V. Narayanan, K. Leung. |
| Date: | May 2012 |
| Formats: | txt html json |
| Updates: | RFC 5177 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6626 |
|
The base Network Mobility for Mobile IPv4 (NEMOv4) specification defines extensions to Mobile IPv4 for mobile networks. This specification defines a dynamic prefix allocation mechanism forNEMOv4. |
|
| |
| RFC 6630 | EAP Re-authentication Protocol Extensions for Authenticated Anticipatory Keying (ERP/AAK) |
| |
| Authors: | Z. Cao, H. Deng, Q. Wu, G. Zorn, Ed.. |
| Date: | June 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6630 |
|
The Extensible Authentication Protocol (EAP) is a generic framework supporting multiple types of authentication methods.
The EAP Re-authentication Protocol (ERP) specifies extensions to EAP and the EAP keying hierarchy to support an EAP method-independent protocol for efficient re-authentication between the peer and an EAP re-authentication server through any authenticator.
Authenticated Anticipatory Keying (AAK) is a method by which cryptographic keying material may be established upon one or moreCandidate Attachment Points (CAPs) prior to handover. AAK uses theAAA infrastructure for key transport.
This document specifies the extensions necessary to enable AAK support in ERP. |
|
| |
| RFC 6633 | Deprecation of ICMP Source Quench Messages |
| |
|
|
This document formally deprecates the use of ICMP Source Quench messages by transport protocols, formally updating RFC 792, RFC 1122, and RFC 1812. |
|
| |
| RFC 6637 | Elliptic Curve Cryptography (ECC) in OpenPGP |
| |
| Authors: | A. Jivsov. |
| Date: | June 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6637 |
|
This document defines an Elliptic Curve Cryptography extension to theOpenPGP public key format and specifies three Elliptic Curves that enjoy broad support by other standards, including standards published by the US National Institute of Standards and Technology. The document specifies the conventions for interoperability between compliant OpenPGP implementations that make use of this extension and these Elliptic Curves. |
|
| |
| RFC 6638 | Scheduling Extensions to CalDAV |
| |
|
|
This document defines extensions to the Calendaring Extensions toWebDAV (CalDAV) "calendar-access" feature to specify a standard way of performing scheduling operations with iCalendar-based calendar components. This document defines the "calendar-auto-schedule" feature of CalDAV. |
|
| |
| RFC 6641 | Using DNS SRV to Specify a Global File Namespace with NFS Version 4 |
| |
| Authors: | C. Everhart, W. Adamson, J. Zhang. |
| Date: | June 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6641 |
|
The NFS version 4 (NFSv4) protocol provides a mechanism for a collection of NFS file servers to collaborate in providing an organization-wide file namespace. The DNS SRV Resource Record (RR) allows a simple way for an organization to publish the root of its file system namespace, even to clients that might not be intimately associated with such an organization. The DNS SRV RR can be used to join these organization-wide file namespaces together to allow construction of a global, uniform NFS file namespace. |
|
| |
| RFC 6642 | RTP Control Protocol (RTCP) Extension for a Third-Party Loss Report |
| |
| Authors: | Q. Wu, Ed., F. Xia, R. Even. |
| Date: | June 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6642 |
|
In a large RTP session using the RTP Control Protocol (RTCP) feedback mechanism defined in RFC 4585, a feedback target may experience transient overload if some event causes a large number of receivers to send feedback at once. This overload is usually avoided by ensuring that feedback reports are forwarded to all receivers, allowing them to avoid sending duplicate feedback reports. However, there are cases where it is not recommended to forward feedback reports, and this may allow feedback implosion. This memo discusses these cases and defines a new RTCP Third-Party Loss Report that can be used to inform receivers that the feedback target is aware of some loss event, allowing them to suppress feedback. Associated SessionDescription Protocol (SDP) signaling is also defined. |
|
| |
| RFC 6643 | Translation of Structure of Management Information Version 2 (SMIv2) MIB Modules to YANG Modules |
| |
| Authors: | J. Schoenwaelder. |
| Date: | July 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6643 |
|
YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol(NETCONF), NETCONF remote procedure calls, and NETCONF notifications.The Structure of Management Information (SMIv2) defines fundamental data types, an object model, and the rules for writing and revisingMIB modules for use with the Simple Network Management Protocol(SNMP). This document defines a translation of SMIv2 MIB modules into YANG modules, enabling read-only (config false) access to data objects defined in SMIv2 MIB modules via NETCONF. |
|
| |
| RFC 6644 | Rebind Capability in DHCPv6 Reconfigure Messages |
| |
| Authors: | D. Evans, R. Droms, S. Jiang. |
| Date: | July 2012 |
| Formats: | txt html json |
| Updates: | RFC 3315 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6644 |
|
This document updates RFC 3315 (DHCPv6) to allow the Rebind message type to appear in the Reconfigure Message option of a Reconfigure message. It extends the Reconfigure message to allow a DHCPv6 server to cause a DHCPv6 client to send a Rebind message. The document also clarifies how a DHCPv6 client responds to a received Reconfigure message. |
|
| |
| RFC 6647 | Email Greylisting: An Applicability Statement for SMTP |
| |
| Authors: | M. Kucherawy, D. Crocker. |
| Date: | June 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6647 |
|
This document describes the art of email greylisting, the practice of providing temporarily degraded service to unknown email clients as an anti-abuse mechanism.
Greylisting is an established mechanism deemed essential to the repertoire of current anti-abuse email filtering systems. |
|
| |
| RFC 6650 | Creation and Use of Email Feedback Reports: An Applicability Statement for the Abuse Reporting Format (ARF) |
| |
| Authors: | J. Falk, M. Kucherawy, Ed.. |
| Date: | June 2012 |
| Formats: | txt html json |
| Updates: | RFC 5965 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6650 |
|
RFC 5965 defines an extensible, machine-readable format intended for mail operators to report feedback about received email to other parties. This applicability statement describes common methods for utilizing this format for reporting both abuse and authentication failure events. Mailbox Providers of any size, mail-sending entities, and end users can use these methods as a basis to create procedures that best suit them. Some related optional mechanisms are also discussed. |
|
| |
| RFC 6651 | Extensions to DomainKeys Identified Mail (DKIM) for Failure Reporting |
| |
| Authors: | M. Kucherawy. |
| Date: | June 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6651 |
|
This document presents extensions to the DomainKeys Identified Mail(DKIM) specification to allow for detailed reporting of message authentication failures in an on-demand fashion. |
|
| |
| RFC 6652 | Sender Policy Framework (SPF) Authentication Failure Reporting Using the Abuse Reporting Format |
| |
|
|
This memo presents extensions to the Abuse Reporting Format (ARF) andSender Policy Framework (SPF) specifications to allow for detailed reporting of message authentication failures in an on-demand fashion.
This memo updates RFC 4408 by providing an IANA registry for SPF modifiers. |
|
| |
| RFC 6655 | AES-CCM Cipher Suites for Transport Layer Security (TLS) |
| |
| Authors: | D. McGrew, D. Bailey. |
| Date: | July 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6655 |
|
This memo describes the use of the Advanced Encryption Standard (AES) in the Counter with Cipher Block Chaining - Message AuthenticationCode (CBC-MAC) Mode (CCM) of operation within Transport LayerSecurity (TLS) and Datagram TLS (DTLS) to provide confidentiality and data origin authentication. The AES-CCM algorithm is amenable to compact implementations, making it suitable for constrained environments. |
|
| |
| RFC 6657 | Update to MIME regarding "charset" Parameter Handling in Textual Media Types |
| |
|
|
This document changes RFC 2046 rules regarding default "charset" parameter values for "text/*" media types to better align with common usage by existing clients and servers. |
|
| |
| RFC 6658 | Packet Pseudowire Encapsulation over an MPLS PSN |
| |
| Authors: | S. Bryant, Ed., L. Martini, G. Swallow, A. Malis. |
| Date: | July 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6658 |
|
This document describes a pseudowire mechanism that is used to transport a packet service over an MPLS PSN in the case where the client Label Switching Router (LSR) and the server Provider Edge equipments are co-resident in the same equipment. This pseudowire mechanism may be used to carry all of the required layer 2 and layer3 protocols between the pair of client LSRs. |
|
| |
| RFC 6660 | Encoding Three Pre-Congestion Notification (PCN) States in the IP Header Using a Single Diffserv Codepoint (DSCP) |
| |
| Authors: | B. Briscoe, T. Moncaster, M. Menth. |
| Date: | July 2012 |
| Formats: | txt html json |
| Obsoletes: | RFC 5696 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6660 |
|
The objective of Pre-Congestion Notification (PCN) is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain.The overall rate of PCN-traffic is metered on every link in the PCN- domain, and PCN-packets are appropriately marked when certain configured rates are exceeded. Egress nodes pass information about these PCN-marks to Decision Points that then decide whether to admit or block new flow requests or to terminate some already admitted flows during serious pre-congestion.
This document specifies how PCN-marks are to be encoded into the IP header by reusing the Explicit Congestion Notification (ECN) codepoints within a PCN-domain. The PCN wire protocol for non-IP protocol headers will need to be defined elsewhere. Nonetheless, this document clarifies the PCN encoding for MPLS in an informational appendix. The encoding for IP provides for up to three different PCN marking states using a single Diffserv codepoint (DSCP): not-marked(NM), threshold-marked (ThM), and excess-traffic-marked (ETM).Hence, it is called the 3-in-1 PCN encoding. This document obsoletesRFC 5696. |
|
| |
| RFC 6665 | SIP-Specific Event Notification |
| |
|
|
This document describes an extension to the Session InitiationProtocol (SIP) defined by RFC 3261. 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.
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.
This document represents a backwards-compatible improvement on the original mechanism described by RFC 3265, taking into account several years of implementation experience. Accordingly, this document obsoletes RFC 3265. This document also updates RFC 4660 slightly to accommodate some small changes to the mechanism that were discussed in that document. |
|
| |
| RFC 6667 | LDP 'Typed Wildcard' Forwarding Equivalence Class (FEC) for PWid and Generalized PWid FEC Elements |
| |
| Authors: | K. Raza, S. Boutros, C. Pignataro. |
| Date: | July 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6667 |
|
The "Typed Wildcard Forwarding Equivalence Class (FEC) Element" defines an extension to the Label Distribution Protocol (LDP) that can be used when requesting, withdrawing, or releasing all label bindings for a given FEC Element type is desired. However, a TypedWildcard FEC Element must be individually defined for each FECElement type. This specification defines the Typed Wildcard FECElements for the Pseudowire Identifier (PWid) (0x80) and GeneralizedPWid (0x81) FEC Element types. |
|
| |
| RFC 6668 | SHA-2 Data Integrity Verification for the Secure Shell (SSH) Transport Layer Protocol |
| |
|
|
This memo defines algorithm names and parameters for use in some of the SHA-2 family of secure hash algorithms for data integrity verification in the Secure Shell (SSH) protocol. It also updates RFC4253 by specifying a new RECOMMENDED data integrity algorithm. |
|
| |
| RFC 6672 | DNAME Redirection in the DNS |
| |
|
|
The DNAME record provides redirection for a subtree of the domain name tree in the DNS. That is, all names that end with a particular suffix are redirected to another part of the DNS. This document obsoletes the original specification in RFC 2672 as well as updates the document on representing IPv6 addresses in DNS (RFC 3363). |
|
| |
| RFC 6673 | Round-Trip Packet Loss Metrics |
| |
| Authors: | A. Morton. |
| Date: | August 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6673 |
|
Many user applications (and the transport protocols that make them possible) require two-way communications. To assess this capability, and to achieve test system simplicity, round-trip loss measurements are frequently conducted in practice. The Two-Way Active MeasurementProtocol specified in RFC 5357 establishes a round-trip loss measurement capability for the Internet. However, there is currently no round-trip packet loss metric specified according to the RFC 2330 framework.
This memo adds round-trip loss to the set of IP Performance Metrics(IPPM). |
|
| |
| RFC 6674 | Gateway-Initiated Dual-Stack Lite Deployment |
| |
| Authors: | F. Brockners, S. Gundavelli, S. Speicher, D. Ward. |
| Date: | July 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6674 |
|
Gateway-Initiated Dual-Stack Lite (GI-DS-Lite) is a variant of Dual-Stack Lite (DS-Lite) applicable to certain tunnel-based access architectures. GI-DS-Lite extends existing access tunnels beyond the access gateway to an IPv4-IPv4 NAT using softwires with an embeddedContext Identifier that uniquely identifies the end-system to which the tunneled packets belong. The access gateway determines which portion of the traffic requires NAT using local policies and sends/ receives this portion to/from this softwire. |
|
| |
| RFC 6675 | A Conservative Loss Recovery Algorithm Based on Selective Acknowledgment (SACK) for TCP |
| |
| Authors: | E. Blanton, M. Allman, L. Wang, I. Jarvinen, M. Kojo, Y. Nishida. |
| Date: | August 2012 |
| Formats: | txt html json |
| Obsoletes: | RFC 3517 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6675 |
|
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 5681), but allows TCP senders to recover more effectively when multiple segments are lost from a single flight of data. This document obsoletes RFC 3517 and describes changes from it. |
|
| |
| RFC 6677 | Channel-Binding Support for Extensible Authentication Protocol (EAP) Methods |
| |
| Authors: | S. Hartman, Ed., T. Clancy, K. Hoeper. |
| Date: | July 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6677 |
|
This document defines how to implement channel bindings forExtensible Authentication Protocol (EAP) methods to address the"lying Network Access Service (NAS)" problem as well as the "lying provider" problem. |
|
| |
| RFC 6679 | Explicit Congestion Notification (ECN) for RTP over UDP |
| |
| Authors: | M. Westerlund, I. Johansson, C. Perkins, P. O'Hanlon, K. Carlberg. |
| Date: | August 2012 |
| Formats: | txt html json |
| Updated by: | RFC 8311 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6679 |
|
This memo specifies how Explicit Congestion Notification (ECN) can be used with the Real-time Transport Protocol (RTP) running over UDP, using the RTP Control Protocol (RTCP) as a feedback mechanism. It defines a new RTCP Extended Report (XR) block for periodic ECN feedback, a new RTCP transport feedback message for timely reporting of congestion events, and a Session Traversal Utilities for NAT(STUN) extension used in the optional initialisation method usingInteractive Connectivity Establishment (ICE). Signalling and procedures for negotiation of capabilities and initialisation methods are also defined. |
|
| |
| RFC 6680 | Generic Security Service Application Programming Interface (GSS-API) Naming Extensions |
| |
| Authors: | N. Williams, L. Johansson, S. Hartman, S. Josefsson. |
| Date: | August 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6680 |
|
The Generic Security Service Application Programming Interface(GSS-API) provides a simple naming architecture that supports name- based authorization. This document introduces new APIs that extend the GSS-API naming model to support name attribute transfer betweenGSS-API peers. |
|
| |
| RFC 6681 | Raptor Forward Error Correction (FEC) Schemes for FECFRAME |
| |
| Authors: | M. Watson, T. Stockhammer, M. Luby. |
| Date: | August 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6681 |
|
This document describes Fully-Specified Forward Error Correction(FEC) Schemes for the Raptor and RaptorQ codes and their application to reliable delivery of media streams in the context of the FECFramework. The Raptor and RaptorQ codes are systematic codes, where a number of repair symbols are generated from a set of source symbols and sent in one or more repair flows in addition to the source symbols that are sent to the receiver(s) within a source flow. TheRaptor and RaptorQ codes offer close to optimal protection against arbitrary packet losses at a low computational complexity. Six FECSchemes are defined: two for the protection of arbitrary packet flows, two that are optimized for small source blocks, and two for the protection of a single flow that already contains a sequence number. Repair data may be sent over arbitrary datagram transport(e.g., UDP) or using RTP. |
|
| |
| RFC 6682 | RTP Payload Format for Raptor Forward Error Correction (FEC) |
| |
| Authors: | M. Watson, T. Stockhammer, M. Luby. |
| Date: | August 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6682 |
|
This document specifies an RTP payload format for the Forward ErrorCorrection (FEC) repair data produced by the Raptor FEC Schemes.Raptor FEC Schemes are specified for use with the IETF FEC Framework that supports the transport of repair data over both UDP and RTP.This document specifies the payload format that is required for the use of RTP to carry Raptor repair flows. |
|
| |
| RFC 6685 | Expert Review for Incident Object Description Exchange Format (IODEF) Extensions in IANA XML Registry |
| |
|
|
This document specifies restrictions on additions to the subset of the IANA XML Namespace and Schema registries, to require ExpertReview for extensions to Incident Object Description Exchange Format(IODEF). |
|
| |
| RFC 6688 | Parallel NFS (pNFS) Block Disk Protection |
| |
| Authors: | D. Black, Ed., J. Glasgow, S. Faibish. |
| Date: | July 2012 |
| Formats: | txt html json |
| Updates: | RFC 5663 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6688 |
|
Parallel NFS (pNFS) extends the Network File System version 4 (NFSv4) to enable direct client access to file data on storage devices and bypass the NFSv4 server. This can increase both performance and parallelism, but it requires additional client functionality, some of which depends upon the type of storage used. The pNFS specification for block storage (RFC 5663) describes how clients can identify the volumes used for pNFS, but this mechanism requires communication with the NFSv4 server. This document updates RFC 5663 to add a mechanism that enables identification of block storage devices used by pNFS file systems without communicating with the server. This enables clients to control access to pNFS block devices when the client initially boots, as opposed to waiting until the client can communicate with the NFSv4 server. |
|
| |
| RFC 6690 | Constrained RESTful Environments (CoRE) Link Format |
| |
| Authors: | Z. Shelby. |
| Date: | August 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6690 |
|
This specification defines Web Linking using a link format for use by constrained web servers to describe hosted resources, their attributes, and other relationships between links. Based on the HTTPLink Header field defined in RFC 5988, the Constrained RESTfulEnvironments (CoRE) Link Format is carried as a payload and is assigned an Internet media type. "RESTful" refers to theRepresentational State Transfer (REST) architecture. A well-knownURI is defined as a default entry point for requesting the links hosted by a server. |
|
| |
| RFC 6692 | Source Ports in Abuse Reporting Format (ARF) Reports |
| |
|
|
This document defines an additional header field for use in AbuseReporting Format (ARF) reports to permit the identification of the source port of the connection involved in an abuse incident.
This document updates RFC 6591. |
|
| |
| RFC 6696 | EAP Extensions for the EAP Re-authentication Protocol (ERP) |
| |
| Authors: | Z. Cao, B. He, Y. Shi, Q. Wu, Ed., G. Zorn, Ed.. |
| Date: | July 2012 |
| Formats: | txt json html |
| Obsoletes: | RFC 5296 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6696 |
|
The Extensible Authentication Protocol (EAP) is a generic framework supporting multiple types of authentication methods. In systems where EAP is used for authentication, it is desirable to avoid repeating the entire EAP exchange with another authenticator. This document specifies extensions to EAP and the EAP keying hierarchy to support an EAP method-independent protocol for efficient re- authentication between the peer and an EAP re-authentication server through any authenticator. The re-authentication server may be in the home network or in the local network to which the peer is connecting.
This memo obsoletes RFC 5296. |
|
| |
| RFC 6698 | The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA |
| |
|
|
Encrypted communication on the Internet often uses Transport LayerSecurity (TLS), which depends on third parties to certify the keys used. This document improves on that situation by enabling the administrators of domain names to specify the keys used in that domain's TLS servers. This requires matching improvements in TLS client software, but no change in TLS server software. |
|
| |
| RFC 6704 | Forcerenew Nonce Authentication |
| |
| Authors: | D. Miles, W. Dec, J. Bristow, R. Maglione. |
| Date: | August 2012 |
| Formats: | txt html json |
| Updates: | RFC 3203 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6704 |
|
Dynamic Host Configuration Protocol (DHCP) FORCERENEW allows for the reconfiguration of a single host by forcing the DHCP client into aRenew state on a trigger from the DHCP server. In the ForcerenewNonce Authentication protocol, the server sends a nonce to the client in the initial DHCP ACK that is used for subsequent validation of aFORCERENEW message. This document updates RFC 3203. |
|
| |
| RFC 6705 | Localized Routing for Proxy Mobile IPv6 |
| |
| Authors: | S. Krishnan, R. Koodli, P. Loureiro, Q. Wu, A. Dutta. |
| Date: | September 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6705 |
|
Proxy Mobile IPv6 (PMIPv6) is a network based mobility management protocol that enables IP mobility for a host without requiring its participation in any mobility-related signaling. PMIPv6 requires all communications to go through the local mobility anchor. As this can be suboptimal, Localized Routing (LR) allows Mobile Nodes (MNs) attached to the same or different Mobile Access Gateways (MAGs) to route traffic by using localized forwarding or a direct tunnel between the gateways. This document proposes initiation, utilization, and termination mechanisms for localized routing between mobile access gateways within a proxy mobile IPv6 domain. It defines two new signaling messages, Localized Routing Initiation (LRI) andLocal Routing Acknowledgment (LRA), that are used to realize this mechanism. |
|
| |
| RFC 6710 | Simple Mail Transfer Protocol Extension for Message Transfer Priorities |
| |
| Authors: | A. Melnikov, K. Carlberg. |
| Date: | August 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6710 |
|
This memo defines an extension to the SMTP (Simple Mail TransferProtocol) service whereby messages are given a label to indicate preferential handling, to enable mail handling nodes to take this information into account for onward processing. |
|
| |
| RFC 6712 | Internet X.509 Public Key Infrastructure -- HTTP Transfer for the Certificate Management Protocol (CMP) |
| |
|
|
This document describes how to layer the Certificate ManagementProtocol (CMP) over HTTP. It is the "CMPtrans" document referenced in RFC 4210; therefore, this document updates the reference given therein. |
|
| |
| RFC 6714 | Connection Establishment for Media Anchoring (CEMA) for the Message Session Relay Protocol (MSRP) |
| |
| Authors: | C. Holmberg, S. Blau, E. Burger. |
| Date: | August 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6714 |
|
This document defines a Message Session Relay Protocol (MSRP) extension, Connection Establishment for Media Anchoring (CEMA).Support of this extension is OPTIONAL. The extension allows middleboxes to anchor the MSRP connection, without the need for middleboxes to modify the MSRP messages; thus, it also enables secure end-to-end MSRP communication in networks where such middleboxes are deployed. This document also defines a Session Description Protocol(SDP) attribute, 'msrp-cema', that MSRP endpoints use to indicate support of the CEMA extension. |
|
| |
| RFC 6715 | vCard Format Extensions: Representing vCard Extensions Defined by the Open Mobile Alliance (OMA) Converged Address Book (CAB) Group |
| |
| Authors: | D. Cauchie, B. Leiba, K. Li. |
| Date: | August 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6715 |
|
This document defines extensions to the vCard data format for representing and exchanging certain contact information. The properties covered here have been defined by the Open Mobile Alliance(OMA) Converged Address Book group, in order to synchronize, usingOMA Data Synchronization, contact fields that were not already defined in the base vCard 4.0 specification. |
|
| |
| RFC 6716 | Definition of the Opus Audio Codec |
| |
| Authors: | JM. Valin, K. Vos, T. Terriberry. |
| Date: | September 2012 |
| Formats: | txt json html |
| Updated by: | RFC 8251 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6716 |
|
This document defines the Opus interactive speech and audio codec.Opus is designed to handle a wide range of interactive audio applications, including Voice over IP, videoconferencing, in-game chat, and even live, distributed music performances. It scales from low bitrate narrowband speech at 6 kbit/s to very high quality stereo music at 510 kbit/s. Opus uses both Linear Prediction (LP) and theModified Discrete Cosine Transform (MDCT) to achieve good compression of both speech and music. |
|
| |
| RFC 6719 | The Minimum Rank with Hysteresis Objective Function |
| |
| Authors: | O. Gnawali, P. Levis. |
| Date: | September 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6719 |
|
The Routing Protocol for Low-Power and Lossy Networks (RPL) constructs routes by using Objective Functions that optimize or constrain the routes it selects and uses. This specification describes the Minimum Rank with Hysteresis Objective Function(MRHOF), an Objective Function that selects routes that minimize a metric, while using hysteresis to reduce churn in response to small metric changes. MRHOF works with additive metrics along a route, and the metrics it uses are determined by the metrics that the RPLDestination Information Object (DIO) messages advertise. |
|
| |
| RFC 6720 | The Generalized TTL Security Mechanism (GTSM) for the Label Distribution Protocol (LDP) |
| |
|
|
The Generalized TTL Security Mechanism (GTSM) describes a generalized use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to verify that the packet was sourced by a node on a connected link, thereby protecting the router's IP control plane from CPU utilization-based attacks. This technique improves security and is used by many protocols. This document defines the GTSM use for theLabel Distribution Protocol (LDP).
This specification uses a bit reserved in RFC 5036 and therefore updates RFC 5036. |
|
| |
| RFC 6721 | The Atom "deleted-entry" Element |
| |
| Authors: | J. Snell. |
| Date: | September 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6721 |
|
This specification adds mechanisms to the Atom Syndication Format that publishers of Atom Feed and Entry documents can use to explicitly identify Atom entries that have been removed. |
|
| |
| RFC 6723 | Update of the Pseudowire Control-Word Negotiation Mechanism |
| |
|
|
The control-word negotiation mechanism specified in RFC 4447 has a problem when a PE (Provider Edge) changes the preference for the use of the control word from NOT PREFERRED to PREFERRED. This document updates RFC 4447 and RFC 6073 by adding the Label Request message to resolve this control-word negotiation issue for single-segment and multi-segment pseudowires. |
|
| |
| RFC 6724 | Default Address Selection for Internet Protocol Version 6 (IPv6) |
| |
| Authors: | D. Thaler, Ed., R. Draves, A. Matsumoto, T. Chown. |
| Date: | September 2012 |
| Formats: | txt html json |
| Obsoletes: | RFC 3484 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6724 |
|
This document describes two algorithms, one for source address selection and one 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.
Default address selection as defined in this specification applies to all IPv6 nodes, including both hosts and routers. This document obsoletes RFC 3484. |
|
| |
| RFC 6725 | DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry Updates |
| |
| Authors: | S. Rose. |
| Date: | August 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6725 |
|
The DNS Security Extensions (DNSSEC) require the use of cryptographic algorithm suites for generating digital signatures over DNS data.The algorithms specified for use with DNSSEC are reflected in anIANA-maintained registry. This document presents a set of changes for some entries of the registry. |
|
| |
| RFC 6726 | FLUTE - File Delivery over Unidirectional Transport |
| |
| Authors: | T. Paila, R. Walsh, M. Luby, V. Roca, R. Lehtonen. |
| Date: | November 2012 |
| Formats: | txt json html |
| Obsoletes: | RFC 3926 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6726 |
|
This document defines File Delivery over Unidirectional Transport(FLUTE), a protocol for the unidirectional delivery of files over theInternet, which is particularly suited to multicast networks. The specification builds on Asynchronous Layered Coding, the base protocol designed for massively scalable multicast distribution.This document obsoletes RFC 3926. |
|
| |
| RFC 6727 | Definitions of Managed Objects for Packet Sampling |
| |
| Authors: | T. Dietz, Ed., B. Claise, J. Quittek. |
| Date: | October 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6727 |
|
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 IPFIX-SELECTOR-MIB module. For IP Flow Information eXport (IPFIX) implementations that use Packet Sampling (PSAMP) techniques, this memo defines the PSAMP-MIB module containing managed objects for providing information on applied packet selection functions and their parameters. |
|
| |
| RFC 6728 | Configuration Data Model for the IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Protocols |
| |
| Authors: | G. Muenz, B. Claise, P. Aitken. |
| Date: | October 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6728 |
|
This document specifies a data model for the IP Flow InformationExport (IPFIX) and Packet Sampling (PSAMP) protocols. It is for configuring and monitoring Selection Processes, Caches, ExportingProcesses, and Collecting Processes of IPFIX- and PSAMP-compliantMonitoring Devices using the Network Configuration Protocol(NETCONF). The data model is defined using UML (Unified ModelingLanguage) class diagrams and formally specified using YANG. The configuration data is encoded in Extensible Markup Language (XML). |
|
| |
| RFC 6729 | Indicating Email Handling States in Trace Fields |
| |
| Authors: | D. Crocker, M. Kucherawy. |
| Date: | September 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6729 |
|
This document registers a trace field clause for use in indicating transitions between handling queues or processing states, including enacting inter- and intra-host message transitions. This might include message quarantining, mailing list moderation, timed delivery, queuing for further analysis, content conversion, or other similar causes, as well as optionally identifying normal handling queues. |
|
| |
| RFC 6731 | Improved Recursive DNS Server Selection for Multi-Interfaced Nodes |
| |
| Authors: | T. Savolainen, J. Kato, T. Lemon. |
| Date: | December 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6731 |
|
A multi-interfaced node is connected to multiple networks, some of which might be utilizing private DNS namespaces. A node commonly receives recursive DNS server configuration information from all connected networks. Some of the recursive DNS servers might have information about namespaces other servers do not have. When a multi-interfaced node needs to utilize DNS, the node has to choose which of the recursive DNS servers to use. This document describesDHCPv4 and DHCPv6 options that can be used to configure nodes with information required to perform informed recursive DNS server selection decisions. |
|
| |
| RFC 6733 | Diameter Base Protocol |
| |
|
|
The Diameter base protocol is intended to provide an Authentication,Authorization, and Accounting (AAA) framework for applications such as network access or IP mobility in both local and roaming situations. This document specifies the message format, transport, error reporting, accounting, and security services used by allDiameter applications. The Diameter base protocol as defined in this document obsoletes RFC 3588 and RFC 5719, and it must be supported by all new Diameter implementations. |
|
| |
| RFC 6734 | Diameter Attribute-Value Pairs for Cryptographic Key Transport |
| |
| Authors: | G. Zorn, Q. Wu, V. Cakulev. |
| Date: | October 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6734 |
|
Some Authentication, Authorization, and Accounting (AAA) applications require the transport of cryptographic keying material. This document specifies a set of Attribute-Value Pairs (AVPs) providing native Diameter support of cryptographic key delivery. |
|
| |
| RFC 6735 | Diameter Priority Attribute-Value Pairs |
| |
| Authors: | K. Carlberg, Ed., T. Taylor. |
| Date: | October 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6735 |
|
This document defines Attribute-Value Pair (AVP) containers for various priority parameters for use with Diameter and theAuthentication, Authorization, and Accounting (AAA) framework. The parameters themselves are defined in several different protocols that operate at either the network or application layer. |
|
| |
| RFC 6736 | Diameter Network Address and Port Translation Control Application |
| |
| Authors: | F. Brockners, S. Bhandari, V. Singh, V. Fajardo. |
| Date: | October 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6736 |
|
This document describes the framework, messages, and procedures for the Diameter Network address and port translation ControlApplication. This Diameter application allows per-endpoint control of Network Address Translators and Network Address and PortTranslators, which are added to networks to cope with IPv4 address space depletion. This Diameter application allows external devices to configure and manage a Network Address Translator device -- expanding the existing Diameter-based Authentication, Authorization, and Accounting (AAA) and policy control capabilities with a NetworkAddress Translator and Network Address and Port Translator control component. These external devices can be network elements in the data plane such as a Network Access Server, or can be more centralized control plane devices such as AAA-servers. This Diameter application establishes a context to commonly identify and manage endpoints on a gateway or server and a Network Address Translator andNetwork Address and Port Translator device. This includes, for example, the control of the total number of Network AddressTranslator bindings allowed or the allocation of a specific NetworkAddress Translator binding for a particular endpoint. In addition, it allows Network Address Translator devices to provide information relevant to accounting purposes. |
|
| |
| RFC 6737 | The Diameter Capabilities Update Application |
| |
| Authors: | K. Jiao, G. Zorn. |
| Date: | October 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6737 |
|
This document defines a new Diameter application and associatedCommand Codes. The Capabilities Update application is intended to allow the dynamic update of certain Diameter peer capabilities while the peer-to-peer connection is in the open state. |
|
| |
| RFC 6738 | Diameter IKEv2 SK: Using Shared Keys to Support Interaction between IKEv2 Servers and Diameter Servers |
| |
| Authors: | V. Cakulev, A. Lior, S. Mizikovsky. |
| Date: | October 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6738 |
|
The Internet Key Exchange Protocol version 2 (IKEv2) is a component of the IPsec architecture and is used to perform mutual authentication as well as to establish and to maintain IPsec SecurityAssociations (SAs) between the respective parties. IKEv2 supports several different authentication mechanisms, such as the ExtensibleAuthentication Protocol (EAP), certificates, and Shared Key (SK).
Diameter interworking for Mobile IPv6 between the Home Agent (HA), as a Diameter client, and the Diameter server has been specified.However, that specification focused on the usage of EAP and did not include support for SK-based authentication available with IKEv2.This document specifies the IKEv2-server-to-Diameter-server communication when the IKEv2 peer authenticates using IKEv2 with SK. |
|
| |
| RFC 6749 | The OAuth 2.0 Authorization Framework |
| |
|
|
The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. |
|
| |
| RFC 6750 | The OAuth 2.0 Authorization Framework: Bearer Token Usage |
| |
|
|
This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport. |
|
| |
| RFC 6753 | A Location Dereference Protocol Using HTTP-Enabled Location Delivery (HELD) |
| |
| Authors: | J. Winterbottom, H. Tschofenig, H. Schulzrinne, M. Thomson. |
| Date: | October 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6753 |
|
This document describes how to use the Hypertext Transfer Protocol(HTTP) over Transport Layer Security (TLS) as a dereference protocol to resolve a reference to a Presence Information Data Format LocationObject (PIDF-LO). This document assumes that a Location Recipient possesses a URI that can be used in conjunction with the HTTP-EnabledLocation Delivery (HELD) protocol to request the location of theTarget. |
|
| |
| RFC 6754 | Protocol Independent Multicast Equal-Cost Multipath (ECMP) Redirect |
| |
|
|
A Protocol Independent Multicast (PIM) router uses the Reverse PathForwarding (RPF) procedure to select an upstream interface and router in order to build forwarding state. When there are equal-cost multipaths (ECMPs), existing implementations often use hash algorithms to select a path. Such algorithms do not allow the spread of traffic among the ECMPs according to administrative metrics. This usually leads to inefficient or ineffective use of network resources.This document introduces the ECMP Redirect, a mechanism to improve the RPF procedure over ECMPs. It allows ECMP selection to be based on administratively selected metrics, such as data transmission delays, path preferences, and routing metrics. |
|
| |
| RFC 6757 | Access Network Identifier (ANI) Option for Proxy Mobile IPv6 |
| |
| Authors: | S. Gundavelli, Ed., J. Korhonen, Ed., M. Grayson, K. Leung, R. Pazhyannur. |
| Date: | October 2012 |
| Formats: | txt html json |
| Updated by: | RFC 7563 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6757 |
|
The local mobility anchor in a Proxy Mobile IPv6 (PMIPv6) domain is able to provide access-network- and access-operator-specific handling or policing of the mobile node traffic using information about the access network to which the mobile node is attached. This specification defines a mechanism and a related mobility option for carrying the access network identifier and the access operator identification information from the mobile access gateway to the local mobility anchor over Proxy Mobile IPv6. |
|
| |
| RFC 6761 | Special-Use Domain Names |
| |
|
|
This document describes what it means to say that a Domain Name (DNS name) is reserved for special use, when reserving such a name is appropriate, and the procedure for doing so. It establishes an IANA registry for such domain names, and seeds it with entries for some of the already established special domain names. |
|
| |
| RFC 6762 | Multicast DNS |
| |
| Authors: | S. Cheshire, M. Krochmal. |
| Date: | February 2013 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6762 |
|
As networked devices become smaller, more portable, and more ubiquitous, the ability to operate with less configured infrastructure is increasingly important. In particular, the ability to look up DNS resource record data types (including, but not limited to, host names) in the absence of a conventional managed DNS server is useful.
Multicast DNS (mDNS) provides the ability to perform DNS-like operations on the local link in the absence of any conventionalUnicast DNS server. In addition, Multicast DNS designates a portion of the DNS namespace to be free for local use, without the need to pay any annual fee, and without the need to set up delegations or otherwise configure a conventional DNS server to answer for those names.
The primary benefits of Multicast DNS names are that (i) they require little or no administration or configuration to set them up, (ii) they work when no infrastructure is present, and (iii) they work during infrastructure failures. |
|
| |
| RFC 6763 | DNS-Based Service Discovery |
| |
| Authors: | S. Cheshire, M. Krochmal. |
| Date: | February 2013 |
| Formats: | txt html json |
| Updated by: | RFC 8553 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6763 |
|
This document specifies how DNS resource records are named and structured to facilitate service discovery. Given a type of service that a client is looking for, and a domain in which the client is looking for that service, this mechanism allows clients to discover a list of named instances of that desired service, using standardDNS queries. This mechanism is referred to as DNS-based ServiceDiscovery, or DNS-SD. |
|
| |
| RFC 6764 | Locating Services for Calendaring Extensions to WebDAV (CalDAV) and vCard Extensions to WebDAV (CardDAV) |
| |
|
|
This specification describes how DNS SRV records, DNS TXT records, and well-known URIs can be used together or separately to locateCalDAV (Calendaring Extensions to Web Distributed Authoring andVersioning (WebDAV)) or CardDAV (vCard Extensions to WebDAV) services. |
|
| |
| RFC 6765 | xDSL Multi-Pair Bonding (G.Bond) MIB |
| |
| Authors: | E. Beili, M. Morgenstern. |
| Date: | February 2013 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6765 |
|
This document defines a Management Information Base (MIB) module for use with network management protocols in TCP/IP-based internets.This document defines an extension to the Interfaces Group MIB with a set of common objects for managing multi-pair bonded DigitalSubscriber Line (xDSL) interfaces, as defined in ITU-TRecommendations G.998.1, G.998.2, and G.998.3. The textual conventions defining the bonding schemes are contained in a separateMIB module maintained by Internet Assigned Numbers Authority (IANA).The MIB modules specific to each bonding technology are defined inG9981-MIB, G9982-MIB, and G9983-MIB, respectively. |
|
| |
| RFC 6766 | xDSL Multi-Pair Bonding Using Time-Division Inverse Multiplexing (G.Bond/TDIM) MIB |
| |
| Authors: | E. Beili. |
| Date: | February 2013 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6766 |
|
This document defines a Management Information Base (MIB) module for use with network management protocols in TCP/IP-based internets.This document proposes an extension to the GBOND-MIB module with a set of objects for managing multi-pair bonded xDSL interfaces usingTime-Division Inverse Multiplexing (TDIM), as defined in ITU-TRecommendation G.998.3. |
|
| |
| RFC 6767 | Ethernet-Based xDSL Multi-Pair Bonding (G.Bond/Ethernet) MIB |
| |
| Authors: | E. Beili, M. Morgenstern. |
| Date: | February 2013 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6767 |
|
This document defines a Management Information Base (MIB) module for use with network management protocols in TCP/IP-based internets.This document defines an extension to the GBOND-MIB module with a set of objects for managing Ethernet-based multi-pair bonded DigitalSubscriber Line (xDSL) interfaces, as defined in ITU-T RecommendationG.998.2. |
|
| |
| RFC 6768 | ATM-Based xDSL Bonded Interfaces MIB |
| |
| Authors: | E. Beili. |
| Date: | February 2013 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6768 |
|
This document defines a Management Information Base (MIB) module for use with network management protocols in TCP/IP-based internets.This document proposes an extension to the GBOND-MIB module with a set of objects for managing ATM-based multi-pair bonded xDSL interfaces, as defined in ITU-T Recommendation G.998.1. |
|
| |
| RFC 6772 | Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information |
| |
| Authors: | H. Schulzrinne, Ed., H. Tschofenig, Ed., J. Cuellar, J. Polk, J. Morris, M. Thomson. |
| Date: | January 2013 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6772 |
|
This document defines an authorization policy language for controlling access to location information. It extends the CommonPolicy authorization framework to provide location-specific access control. More specifically, this document defines condition elements specific to location information in order to restrict access to data based on the current location of the Target.
Furthermore, this document defines two algorithms for reducing the granularity of returned location information. The first algorithm is defined for usage with civic location information, whereas the other one applies to geodetic location information. Both algorithms come with limitations. There are circumstances where the amount of location obfuscation provided is less than what is desired. These algorithms might not be appropriate for all application domains. |
|
| |
| RFC 6773 | DCCP-UDP: A Datagram Congestion Control Protocol UDP Encapsulation for NAT Traversal |
| |
|
|
This document specifies an alternative encapsulation of the DatagramCongestion Control Protocol (DCCP), referred to as DCCP-UDP. This encapsulation allows DCCP to be carried through the current generation of Network Address Translation (NAT) middleboxes without modification of those middleboxes. This document also updates theSession Description Protocol (SDP) information for DCCP defined inRFC 5762. |
|
| |
| RFC 6775 | Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) |
| |
|
|
The IETF work in IPv6 over Low-power Wireless Personal Area Network(6LoWPAN) defines 6LoWPANs such as IEEE 802.15.4. This and other similar link technologies have limited or no usage of multicast signaling due to energy conservation. In addition, the wireless network may not strictly follow the traditional concept of IP subnets and IP links. IPv6 Neighbor Discovery was not designed for non- transitive wireless links, as its reliance on the traditional IPv6 link concept and its heavy use of multicast make it inefficient and sometimes impractical in a low-power and lossy network. This document describes simple optimizations to IPv6 Neighbor Discovery, its addressing mechanisms, and duplicate address detection for Low- power Wireless Personal Area Networks and similar networks. The document thus updates RFC 4944 to specify the use of the optimizations defined here. |
|
| |
| RFC 6776 | Measurement Identity and Information Reporting Using a Source Description (SDES) Item and an RTCP Extended Report (XR) Block |
| |
| Authors: | A. Clark, Q. Wu. |
| Date: | October 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6776 |
|
This document defines an RTP Control Protocol (RTCP) SourceDescription (SDES) item and an RTCP Extended Report (XR) block carrying parameters that identify and describe a measurement period to which one or more other RTCP XR blocks may refer. |
|
| |
| RFC 6777 | Label Switched Path (LSP) Data Path Delay Metrics in Generalized MPLS and MPLS Traffic Engineering (MPLS-TE) Networks |
| |
| Authors: | W. Sun, Ed., G. Zhang, Ed., J. Gao, G. Xie, R. Papneja. |
| Date: | November 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6777 |
|
When setting up a Label Switched Path (LSP) in Generalized MPLS(GMPLS) and MPLS Traffic Engineering (MPLS-TE) networks, the completion of the signaling process does not necessarily mean that the cross-connection along the LSP has been programmed accordingly and in a timely manner. Meanwhile, the completion of the signaling process may be used by LSP users or applications that control their use as an indication that the data path has become usable. The existence of the inconsistency between the signaling messages and cross-connection programming, and the possible failure of cross- connection programming, if not properly treated, will result in data loss or even application failure. Characterization of this performance can thus help designers to improve the way in which LSPs are used and to make applications or tools that depend on and useLSPs more robust. This document defines a series of performance metrics to evaluate the connectivity of the data path in the signaling process. |
|
| |
| RFC 6779 | Definition of Managed Objects for the Neighborhood Discovery Protocol |
| |
| Authors: | U. Herberg, R. Cole, I. Chakeres. |
| Date: | October 2012 |
| Formats: | txt json html |
| Obsoleted by: | RFC 7939 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6779 |
|
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 objects for configuring parameters of the Neighborhood Discovery Protocol (NHDP) process on a router. The MIB module defined in this document, denoted NHDP-MIB, also reports state, performance information, and notifications aboutNHDP. This additional state and performance information is useful to troubleshoot problems and performance issues during neighbor discovery. |
|
| |
| RFC 6780 | RSVP ASSOCIATION Object Extensions |
| |
|
|
The RSVP ASSOCIATION object was defined in the context of GMPLS- controlled Label Switched Paths (LSPs). In this context, the object is used to associate recovery LSPs with the LSP they are protecting.This object also has broader applicability as a mechanism to associate RSVP state. This document defines how the ASSOCIATION object can be more generally applied. This document also definesExtended ASSOCIATION objects that, in particular, can be used in the context of the MPLS Transport Profile (MPLS-TP). This document updates RFC 2205, RFC 3209, and RFC 3473. It also generalizes the definition of the Association ID field defined in RFC 4872. |
|
| |
| RFC 6784 | Kerberos Options for DHCPv6 |
| |
| Authors: | S. Sakane, M. Ishiyama. |
| Date: | November 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6784 |
|
This document defines four new options for the Dynamic HostConfiguration Protocol for IPv6 (DHCPv6). These options are used to carry configuration information for Kerberos. |
|
| |
| RFC 6785 | Support for Internet Message Access Protocol (IMAP) Events in Sieve |
| |
|
|
Sieve defines an email filtering language that can, in principle, plug into any point in the processing of an email message. As defined in the base specification, it plugs into mail delivery. This document defines how Sieve can plug into points in IMAP where messages are created or changed, adding the option of user-defined or installation-defined filtering (or, with Sieve extensions, features such as notifications). Because this requires future Sieve extensions to specify their interactions with this one, this document updates the base Sieve specification, RFC 5228. |
|
| |
| RFC 6786 | Encrypting the Protocol for Carrying Authentication for Network Access (PANA) Attribute-Value Pairs |
| |
| Authors: | A. Yegin, R. Cragie. |
| Date: | November 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6786 |
|
This document specifies a mechanism for delivering the Protocol forCarrying Authentication for Network Access (PANA) Attribute-ValuePairs (AVPs) in encrypted form. |
|
| |
| RFC 6787 | Media Resource Control Protocol Version 2 (MRCPv2) |
| |
| Authors: | D. Burnett, S. Shanmugham. |
| Date: | November 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6787 |
|
The Media Resource Control Protocol Version 2 (MRCPv2) allows client hosts to control media service resources such as speech synthesizers, recognizers, verifiers, and identifiers residing in servers on the network. MRCPv2 is not a "stand-alone" protocol -- it relies on other protocols, such as the Session Initiation Protocol (SIP), to coordinate MRCPv2 clients and servers and manage sessions between them, and the Session Description Protocol (SDP) to describe, discover, and exchange capabilities. It also depends on SIP and SDP to establish the media sessions and associated parameters between the media source or sink and the media server. Once this is done, theMRCPv2 exchange operates over the control session established above, allowing the client to control the media processing resources on the speech resource server. |
|
| |
| RFC 6788 | The Line-Identification Option |
| |
| Authors: | S. Krishnan, A. Kavanagh, B. Varga, S. Ooghe, E. Nordmark. |
| Date: | November 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6788 |
|
In Ethernet-based aggregation networks, several subscriber premises may be logically connected to the same interface of an Edge Router.This document proposes a method for the Edge Router to identify the subscriber premises using the contents of the received RouterSolicitation messages. The applicability is limited to broadband network deployment scenarios in which multiple user ports are mapped to the same virtual interface on the Edge Router. |
|
| |
| RFC 6790 | The Use of Entropy Labels in MPLS Forwarding |
| |
|
|
Load balancing is a powerful tool for engineering traffic across a network. This memo suggests ways of improving load balancing acrossMPLS networks using the concept of "entropy labels". It defines the concept, describes why entropy labels are useful, enumerates properties of entropy labels that allow maximal benefit, and shows how they can be signaled and used for various applications. This document updates RFCs 3031, 3107, 3209, and 5036. |
|
| |
| RFC 6791 | Stateless Source Address Mapping for ICMPv6 Packets |
| |
| Authors: | X. Li, C. Bao, D. Wing, R. Vaithianathan, G. Huston. |
| Date: | November 2012 |
| Formats: | txt json html |
| Updates: | RFC 6145 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6791 |
|
A stateless IPv4/IPv6 translator may receive ICMPv6 packets containing non-IPv4-translatable addresses as the source. These packets should be passed across the translator as ICMP packets directed to the IPv4 destination. This document presents recommendations for source address translation in ICMPv6 headers to handle such cases. |
|
| |
| RFC 6793 | BGP Support for Four-Octet Autonomous System (AS) Number Space |
| |
|
|
The Autonomous System number is encoded as a two-octet entity in the base BGP specification. This document describes extensions to BGP to carry the Autonomous System numbers as four-octet entities. This document obsoletes RFC 4893 and updates RFC 4271. |
|
| |
| RFC 6794 | A Framework for Session Initiation Protocol (SIP) Session Policies |
| |
| Authors: | V. Hilt, G. Camarillo, J. Rosenberg. |
| Date: | December 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6794 |
|
Proxy servers play a central role as an intermediary in the SessionInitiation Protocol (SIP) as they define and impact policies on call routing, rendezvous, and other call features. This document specifies a framework for SIP session policies that provides a standard mechanism by which a proxy can define or influence policies on sessions, such as the codecs or media types to be used. It defines a model, an overall architecture and new protocol mechanisms for session policies. |
|
| |
| RFC 6795 | A Session Initiation Protocol (SIP) Event Package for Session-Specific Policies |
| |
| Authors: | V. Hilt, G. Camarillo. |
| Date: | December 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6795 |
|
This specification defines a Session Initiation Protocol (SIP) event package for session-specific policies. This event package enables user agents (UAs) to subscribe to session policies for a SIP session and to receive notifications if these policies change. |
|
| |
| RFC 6796 | A User Agent Profile Data Set for Media Policy |
| |
| Authors: | V. Hilt, G. Camarillo, J. Rosenberg, D. Worley. |
| Date: | December 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6796 |
|
This specification defines an XML document format to describe the media properties of Session Initiation Protocol (SIP) sessions.Examples for media properties are the codecs or media types used in the session. This document also defines an XML document format to describe policies that limit the media properties of SIP sessions. |
|
| |
| RFC 6797 | HTTP Strict Transport Security (HSTS) |
| |
| Authors: | J. Hodges, C. Jackson, A. Barth. |
| Date: | November 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6797 |
|
This specification defines a mechanism enabling web sites to declare themselves accessible only via secure connections and/or for users to be able to direct their user agent(s) to interact with given sites only over secure connections. This overall policy is referred to asHTTP Strict Transport Security (HSTS). The policy is declared by web sites via the Strict-Transport-Security HTTP response header field and/or by other means, such as user agent configuration, for example. |
|
| |
| RFC 6798 | RTP Control Protocol (RTCP) Extended Report (XR) Block for Packet Delay Variation Metric Reporting |
| |
| Authors: | A. Clark, Q. Wu. |
| Date: | November 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6798 |
|
This document defines an RTP Control Protocol (RTCP) Extended Report(XR) block that allows the reporting of packet delay variation metrics for a range of RTP applications. |
|
| |
| RFC 6806 | Kerberos Principal Name Canonicalization and Cross-Realm Referrals |
| |
| Authors: | S. Hartman, Ed., K. Raeburn, L. Zhu. |
| Date: | November 2012 |
| Formats: | txt json html |
| Updates: | RFC 4120 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6806 |
|
This memo documents a method for a Kerberos Key Distribution Center(KDC) to respond to client requests for Kerberos tickets when the client does not have detailed configuration information on the realms of users or services. The KDC will handle requests for principals in other realms by returning either a referral error or a cross-realmTicket-Granting Ticket (TGT) to another realm on the referral path.The clients will use this referral information to reach the realm of the target principal and then receive the ticket. This memo also provides a mechanism for verifying that a request has not been tampered with in transit. This memo updates RFC 4120. |
|
| |
| RFC 6809 | Mechanism to Indicate Support of Features and Capabilities in the Session Initiation Protocol (SIP) |
| |
| Authors: | C. Holmberg, I. Sedlacek, H. Kaplan. |
| Date: | November 2012 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6809 |
|
This specification defines a new SIP header field, Feature-Caps. TheFeature-Caps header field conveys feature-capability indicators that are used to indicate support of features and capabilities for SIP entities that are not represented by the Uniform Resource Identifier(URI) of the Contact header field.
SIP entities that are represented by the URI of the SIP Contact header field can convey media feature tags in the Contact header field to indicate support of features and capabilities.
This specification also defines feature-capability indicators and creates a new IANA registry, "Proxy-Feature Feature-CapabilityIndicator Trees", for registering feature-capability indicators. |
|
| |
| RFC 6810 | The Resource Public Key Infrastructure (RPKI) to Router Protocol |
| |
| Authors: | R. Bush, R. Austein. |
| Date: | January 2013 |
| Formats: | txt html json |
| Updated by: | RFC 8210 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6810 |
|
In order to verifiably validate the origin Autonomous Systems of BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure (RFC 6480) prefix origin data from a trusted cache. This document describes a protocol to deliver validated prefix origin data to routers. |
|
| |
| RFC 6811 | BGP Prefix Origin Validation |
| |
| Authors: | P. Mohapatra, J. Scudder, D. Ward, R. Bush, R. Austein. |
| Date: | January 2013 |
| Formats: | txt html json |
| Updated by: | RFC 8481, RFC 8893 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6811 |
|
To help reduce well-known threats against BGP including prefix mis- announcing and monkey-in-the-middle attacks, one of the security requirements is the ability to validate the origination AutonomousSystem (AS) of BGP routes. More specifically, one needs to validate that the AS number claiming to originate an address prefix (as derived from the AS_PATH attribute of the BGP route) is in fact authorized by the prefix holder to do so. This document describes a simple validation mechanism to partially satisfy this requirement. |
|
| |
| RFC 6814 | Formally Deprecating Some IPv4 Options |
| |
|
|
A number of IPv4 options have become obsolete in practice, but have never been formally deprecated. This document deprecates such IPv4 options, thus cleaning up the corresponding IANA registry.Additionally, it obsoletes RFCs 1385, 1393, 1475, and 1770, and requests that the RFC Editor change their status to Historic. |
|
| |
| RFC 6816 | Simple Low-Density Parity Check (LDPC) Staircase Forward Error Correction (FEC) Scheme for FECFRAME |
| |
| Authors: | V. Roca, M. Cunche, J. Lacan. |
| Date: | December 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6816 |
|
This document describes a fully specified simple Forward ErrorCorrection (FEC) scheme for Low-Density Parity Check (LDPC) Staircase codes that can be used to protect media streams along the lines defined by FECFRAME. These codes have many interesting properties: they are systematic codes, they perform close to ideal codes in many use-cases, and they also feature very high encoding and decoding throughputs. LDPC-Staircase codes are therefore a good solution to protect a single high bitrate source flow or to protect globally several mid-rate flows within a single FECFRAME instance. They are also a good solution whenever the processing load of a software encoder or decoder must be kept to a minimum. |
|
| |
| RFC 6818 | Updates to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile |
| |
|
|
This document updates RFC 5280, the "Internet X.509 Public KeyInfrastructure Certificate and Certificate Revocation List (CRL)Profile". This document changes the set of acceptable encoding methods for the explicitText field of the user notice policy qualifier and clarifies the rules for converting internationalized domain name labels to ASCII. This document also provides some clarifications on the use of self-signed certificates, trust anchors, and some updated security considerations. |
|
| |
| RFC 6822 | IS-IS Multi-Instance |
| |
| Authors: | S. Previdi, Ed., L. Ginsberg, M. Shand, A. Roy, D. Ward. |
| Date: | December 2012 |
| Formats: | txt json html |
| Obsoleted by: | RFC 8202 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6822 |
|
This document describes a mechanism that allows a single router to share one or more circuits among multiple Intermediate System toIntermediate System (IS-IS) routing protocol instances.
Multiple instances allow the isolation of resources associated with each instance. Routers will form instance-specific adjacencies.Each instance can support multiple topologies. Each topology has a unique Link State Database (LSDB). Each Protocol Data Unit (PDU) will contain a new Type-Length-Value (TLV) identifying the instance and the topology (or topologies) to which the PDU belongs. |
|
| |
| RFC 6823 | Advertising Generic Information in IS-IS |
| |
| Authors: | L. Ginsberg, S. Previdi, M. Shand. |
| Date: | December 2012 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6823 |
|
This document describes the manner in which generic application information (i.e., information not directly related to the operation of the Intermediate System to Intermediate System (IS-IS) protocol) should be advertised in IS-IS Link State Protocol Data Units (LSPs) and defines guidelines that should be used when flooding such information. |
|
| |
| RFC 6825 | Traffic Engineering Database Management Information Base in Support of MPLS-TE/GMPLS |
| |
| Authors: | M. Miyazawa, T. Otani, K. Kumaki, T. Nadeau. |
| Date: | January 2013 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6825 |
|
This memo defines the Management Information Base (MIB) objects for managing the Traffic Engineering Database (TED) information with extensions in support of the Multiprotocol Label Switching (MPLS) with Traffic Engineering (TE) as well as Generalized MPLS (GMPLS) for use with network management protocols. |
|
| |
| RFC 6826 | Multipoint LDP In-Band Signaling for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths |
| |
| Authors: | IJ. Wijnands, Ed., T. Eckert, N. Leymann, M. Napierala. |
| Date: | January 2013 |
| Formats: | txt json html |
| Updated by: | RFC 7438 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6826 |
|
Consider an IP multicast tree, constructed by Protocol IndependentMulticast (PIM), that needs to pass through an MPLS domain in whichMultipoint LDP (mLDP) point-to-multipoint and/or multipoint-to- multipoint Labels Switched Paths (LSPs) can be created. The part of the IP multicast tree that traverses the MPLS domain can be instantiated as a multipoint LSP. When a PIM Join message is received at the border of the MPLS domain, information from that message is encoded into mLDP messages. When the mLDP messages reach the border of the next IP domain, the encoded information is used to generate PIM messages that can be sent through the IP domain. The result is an IP multicast tree consisting of a set of IP multicast sub-trees that are spliced together with a multipoint LSP. This document describes procedures regarding how IP multicast trees are spliced together with multipoint LSPs. |
|
| |
| RFC 6827 | Automatically Switched Optical Network (ASON) Routing for OSPFv2 Protocols |
| |
| Authors: | A. Malis, Ed., A. Lindem, Ed., D. Papadimitriou, Ed.. |
| Date: | January 2013 |
| Formats: | txt json html |
| Obsoletes: | RFC 5787 |
| Updates: | RFC 5786 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6827 |
|
The ITU-T has defined an architecture and requirements for operating an Automatically Switched Optical Network (ASON).
The Generalized Multiprotocol Label Switching (GMPLS) protocol suite is designed to provide a control plane for a range of network technologies. These include optical networks such as time division multiplexing (TDM) networks including the Synchronous OpticalNetwork/Synchronous Digital Hierarchy (SONET/SDH), Optical TransportNetworks (OTNs), and lambda switching optical networks.
The requirements for GMPLS routing to satisfy the requirements ofASON routing and an evaluation of existing GMPLS routing protocols are provided in other documents. This document defines extensions to the OSPFv2 Link State Routing Protocol to meet the requirements for routing in an ASON.
Note that this work is scoped to the requirements and evaluation expressed in RFC 4258 and RFC 4652 and the ITU-T Recommendations that were current when those documents were written. Future extensions or revisions of this work may be necessary if the ITU-T Recommendations are revised or if new requirements are introduced into a revision ofRFC 4258. This document obsoletes RFC 5787 and updates RFC 5786. |
|
| |
| RFC 6829 | Label Switched Path (LSP) Ping for Pseudowire Forwarding Equivalence Classes (FECs) Advertised over IPv6 |
| |
|
|
The Multiprotocol Label Switching (MPLS) Label Switched Path (LSP)Ping and traceroute mechanisms are commonly used to detect and isolate data-plane failures in all MPLS LSPs, including LSPs used for each direction of an MPLS Pseudowire (PW). However, the LSP Ping and traceroute elements used for PWs are not specified for IPv6 address usage.
This document extends the PW LSP Ping and traceroute mechanisms so they can be used with PWs that are set up and maintained using IPv6LDP sessions. This document updates RFC 4379. |
|
| |
| RFC 6840 | Clarifications and Implementation Notes for DNS Security (DNSSEC) |
| |
|
|
This document is a collection of technical clarifications to the DNSSecurity (DNSSEC) document set. It is meant to serve as a resource to implementors as well as a collection of DNSSEC errata that existed at the time of writing.
This document updates the core DNSSEC documents (RFC 4033, RFC 4034, and RFC 4035) as well as the NSEC3 specification (RFC 5155). It also defines NSEC3 and SHA-2 (RFC 4509 and RFC 5702) as core parts of theDNSSEC specification. |
|
| |
| RFC 6842 | Client Identifier Option in DHCP Server Replies |
| |
| Authors: | N. Swamy, G. Halwasia, P. Jhingran. |
| Date: | January 2013 |
| Formats: | txt html json |
| Updates: | RFC 2131 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6842 |
|
This document updates RFC 2131 "Dynamic Host Configuration Protocol" by addressing the issues arising from that document's specification that the server MUST NOT return the 'client identifier' option to the client. |
|
| |
| RFC 6843 | RTP Control Protocol (RTCP) Extended Report (XR) Block for Delay Metric Reporting |
| |
| Authors: | A. Clark, K. Gross, Q. Wu. |
| Date: | January 2013 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6843 |
|
This document defines an RTP Control Protocol (RTCP) Extended Report(XR) block that allows the reporting of delay metrics for use in a range of Real-time Transport Protocol (RTP) applications. |
|
| |
| RFC 6844 | DNS Certification Authority Authorization (CAA) Resource Record |
| |
| Authors: | P. Hallam-Baker, R. Stradling. |
| Date: | January 2013 |
| Formats: | txt json html |
| Obsoleted by: | RFC 8659 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6844 |
|
The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify one or more CertificationAuthorities (CAs) authorized to issue certificates for that domain.CAA Resource Records allow a public Certification Authority to implement additional controls to reduce the risk of unintended certificate mis-issue. This document defines the syntax of the CAA record and rules for processing CAA records by certificate issuers. |
|
| |
| RFC 6845 | OSPF Hybrid Broadcast and Point-to-Multipoint Interface Type |
| |
|
|
This document describes a mechanism to model a broadcast network as a hybrid of broadcast and point-to-multipoint networks for purposes ofOSPF operation. Neighbor discovery and maintenance as well as LinkState Advertisement (LSA) database synchronization are performed using the broadcast model, but the network is represented using the point-to-multipoint model in the router-LSAs of the routers connected to it. This allows an accurate representation of the cost of communication between different routers on the network, while maintaining the network efficiency of broadcast operation. This approach is relatively simple and requires minimal changes to OSPF.
This document updates both OSPFv2 (RFC 2328) and OSPFv3 (RFC 5340). |
|
| |
| RFC 6846 | RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP) |
| |
| Authors: | G. Pelletier, K. Sandlund, L-E. Jonsson, M. West. |
| Date: | January 2013 |
| Formats: | txt html json |
| Obsoletes: | RFC 4996 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6846 |
|
This document specifies a RObust Header Compression (ROHC) profile for compression of TCP/IP packets. The profile, called ROHC-TCP, provides efficient and robust compression of TCP headers, including frequently used TCP options such as selective acknowledgments (SACKs) and Timestamps.
ROHC-TCP works 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 specification obsoletes RFC 4996. It fixes a technical issue with the SACK compression and clarifies other compression methods used. |
|
| |
| RFC 6848 | Specifying Civic Address Extensions in the Presence Information Data Format Location Object (PIDF-LO) |
| |
| Authors: | J. Winterbottom, M. Thomson, R. Barnes, B. Rosen, R. George. |
| Date: | January 2013 |
| Formats: | txt json html |
| Updates: | RFC 4776, RFC 5222 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6848 |
|
New fields are occasionally added to civic addresses. A backward- compatible mechanism for adding civic address elements to the Geopriv civic address format is described. A formal mechanism for handling unsupported extensions when translating between XML and DHCP civic address forms is defined for entities that need to perform this translation. Initial extensions for some new elements are also defined. The Location-to-Service Translation (LoST) protocol mechanism (defined in RFC 5222) that returns civic address element names used for validation of location information is clarified and is normatively updated to require a qualifying namespace identifier on each civic address element returned as part of the validation process. |
|
| |
| RFC 6849 | An Extension to the Session Description Protocol (SDP) and Real-time Transport Protocol (RTP) for Media Loopback |
| |
| Authors: | H. Kaplan, Ed., K. Hedayat, N. Venna, P. Jones, N. Stratton. |
| Date: | February 2013 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6849 |
|
The wide deployment of Voice over IP (VoIP), real-time text, andVideo over IP services has introduced new challenges in managing and maintaining real-time voice/text/video quality, reliability, and overall performance. In particular, media delivery is an area that needs attention. One method of meeting these challenges is monitoring the media delivery performance by looping media back to the transmitter. This is typically referred to as "active monitoring" of services. Media loopback is especially popular in ensuring the quality of transport to the edge of a given VoIP, real- time text, or Video over IP service. Today, in networks that deliver real-time media, short of running 'ping' and 'traceroute' to the edge, administrators are left without the necessary tools to actively monitor, manage, and diagnose quality issues with their service. The extension defined herein adds new Session Description Protocol (SDP) media types and attributes that enable establishment of media sessions where the media is looped back to the transmitter. Such media sessions will serve as monitoring and troubleshooting tools by providing the means for measurement of more advanced VoIP, real-time text, and Video over IP performance metrics. |
|
| |
| RFC 6850 | Definitions of Managed Objects for Routing Bridges (RBridges) |
| |
| Authors: | A. Rijhsinghani, K. Zebrose. |
| Date: | January 2013 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6850 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it defines objects for managing a Routing Bridge (RBridge), also known as aTRILL Switch, based on the IETF TRILL (Transparent Interconnection ofLots of Links) protocol. |
|
| |
| RFC 6851 | Internet Message Access Protocol (IMAP) - MOVE Extension |
| |
| Authors: | A. Gulbrandsen, N. Freed, Ed.. |
| Date: | January 2013 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6851 |
|
This document defines an IMAP extension consisting of two new commands, MOVE and UID MOVE, that are used to move messages from one mailbox to another. |
|
| |
| RFC 6854 | Update to Internet Message Format to Allow Group Syntax in the "From:" and "Sender:" Header Fields |
| |
|
|
The Internet Message Format (RFC 5322) allows "group" syntax in some email header fields, such as "To:" and "CC:", but not in "From:" or"Sender:". This document updates RFC 5322 to relax that restriction, allowing group syntax in those latter fields, as well as in"Resent-From:" and "Resent-Sender:", in certain situations. |
|
| |
| RFC 6855 | IMAP Support for UTF-8 |
| |
| Authors: | P. Resnick, Ed., C. Newman, Ed., S. Shen, Ed.. |
| Date: | March 2013 |
| Formats: | txt json html |
| Obsoletes: | RFC 5738 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6855 |
|
This specification extends the Internet Message Access Protocol(IMAP) to support UTF-8 encoded international characters in user names, mail addresses, and message headers. This specification replaces RFC 5738. |
|
| |
| RFC 6856 | Post Office Protocol Version 3 (POP3) Support for UTF-8 |
| |
| Authors: | R. Gellens, C. Newman, J. Yao, K. Fujiwara. |
| Date: | March 2013 |
| Formats: | txt html json |
| Obsoletes: | RFC 5721 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6856 |
|
This specification extends the Post Office Protocol version 3 (POP3) to support international strings encoded in UTF-8 in usernames, passwords, mail addresses, message headers, and protocol-level text strings. |
|
| |
| RFC 6857 | Post-Delivery Message Downgrading for Internationalized Email Messages |
| |
| Authors: | K. Fujiwara. |
| Date: | March 2013 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6857 |
|
The Email Address Internationalization (SMTPUTF8) extension to SMTP allows Unicode characters encoded in UTF-8 and outside the ASCII repertoire in mail header fields. Upgraded POP and IMAP servers support internationalized messages. If a POP or IMAP client does not support Email Address Internationalization, a POP or IMAP server cannot deliver internationalized messages to the client and cannot remove the message. To avoid that situation, this document describes a mechanism for converting internationalized messages into the traditional message format. As part of the conversion process, message elements that require internationalized treatment are recoded or removed, and receivers are able to recognize that they received messages containing such elements, even if they cannot process the internationalized elements. |
|
| |
| RFC 6858 | Simplified POP and IMAP Downgrading for Internationalized Email |
| |
|
|
This document specifies a method for IMAP and POP servers to serve internationalized messages to conventional clients. The specification is simple, easy to implement, and provides only rudimentary results. |
|
| |
| RFC 6860 | Hiding Transit-Only Networks in OSPF |
| |
|
|
A transit-only network is defined as a network connecting routers only. In OSPF, transit-only networks are usually configured with routable IP addresses, which are advertised in Link StateAdvertisements (LSAs) but are not needed for data traffic. In addition, remote attacks can be launched against routers by sending packets to these transit-only networks. This document presents a mechanism to hide transit-only networks to speed up network convergence and reduce vulnerability to remote attacks.
In the context of this document, 'hiding' implies that the prefixes are not installed in the routing tables on OSPF routers. In some cases, IP addresses may still be visible when using OSPFv2.
This document updates RFCs 2328 and 5340. |
|
| |
| RFC 6864 | Updated Specification of the IPv4 ID Field |
| |
|
|
The IPv4 Identification (ID) field enables fragmentation and reassembly and, as currently specified, is required to be unique within the maximum lifetime for all datagrams with a given source address/destination address/protocol tuple. If enforced, this uniqueness requirement would limit all connections to 6.4 Mbps for typical datagram sizes. Because individual connections commonly exceed this speed, it is clear that existing systems violate the current specification. This document updates the specification of the IPv4 ID field in RFCs 791, 1122, and 2003 to more closely reflect current practice and to more closely match IPv6 so that the field's value is defined only when a datagram is actually fragmented. It also discusses the impact of these changes on how datagrams are used. |
|
| |
| RFC 6865 | Simple Reed-Solomon Forward Error Correction (FEC) Scheme for FECFRAME |
| |
| Authors: | V. Roca, M. Cunche, J. Lacan, A. Bouabdallah, K. Matsuzono. |
| Date: | February 2013 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6865 |
|
This document describes a fully-specified simple Forward ErrorCorrection (FEC) scheme for Reed-Solomon codes over the finite field(also known as the Galois Field) GF(2^^m), with 2 <= m <= 16, that can be used to protect arbitrary media streams along the lines defined by FECFRAME. The Reed-Solomon codes considered have attractive properties, since they offer optimal protection against packet erasures and the source symbols are part of the encoding symbols, which can greatly simplify decoding. However, the price to pay is a limit on the maximum source block size, on the maximum number of encoding symbols, and a computational complexity higher than that of the Low-Density Parity Check (LDPC) codes, for instance. |
|
| |
| RFC 6868 | Parameter Value Encoding in iCalendar and vCard |
| |
|
|
This specification updates the data formats for iCalendar (RFC 5545) and vCard (RFC 6350) to allow parameter values to include certain characters forbidden by the existing specifications. |
|
| |
| RFC 6869 | vCard KIND:device |
| |
| Authors: | G. Salgueiro, J. Clarke, P. Saint-Andre. |
| Date: | February 2013 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6869 |
|
This document defines a value of "device" for the vCard KIND property so that the vCard format can be used to represent computing devices such as appliances, computers, or network elements (e.g., a server, router, switch, printer, sensor, or phone). |
|
| |
| RFC 6870 | Pseudowire Preferential Forwarding Status Bit |
| |
|
|
This document describes a mechanism for signaling the active and standby status of redundant Pseudowires (PWs) between their termination points. A set of Redundant PWs is configured betweenProvider Edge (PE) nodes in single-segment pseudowire (SS-PW) applications or between Terminating Provider Edge (T-PE) nodes inMulti-Segment Pseudowire (MS-PW) applications.
In order for the PE/T-PE nodes to indicate the preferred PW to use for forwarding PW packets to one another, a new status bit is defined. This bit indicates a Preferential Forwarding status with a value of active or standby for each PW in a redundant set.
In addition, a second status bit is defined to allow peer PE nodes to coordinate a switchover operation of the PW.
Finally, this document updates RFC 4447 by adding details to the handling of the PW status code bits in the PW Status TLV. |
|
| |
| RFC 6871 | Session Description Protocol (SDP) Media Capabilities Negotiation |
| |
| Authors: | R. Gilman, R. Even, F. Andreasen. |
| Date: | February 2013 |
| Formats: | txt json html |
| Updates: | RFC 5939 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6871 |
|
Session Description Protocol (SDP) capability negotiation provides a general framework for indicating and negotiating capabilities in SDP.The base framework defines only capabilities for negotiating transport protocols and attributes. This documents extends the framework by defining media capabilities that can be used to negotiate media types and their associated parameters.
This document updates the IANA Considerations of RFC 5939. |
|
| |
| RFC 6872 | The Common Log Format (CLF) for the Session Initiation Protocol (SIP): Framework and Information Model |
| |
| Authors: | V. Gurbani, Ed., E. Burger, Ed., T. Anjali, H. Abdelnur, O. Festor. |
| Date: | February 2013 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6872 |
|
Well-known web servers such as Apache and web proxies like Squid support event logging using a common log format. The logs produced using these de facto standard formats are invaluable to system administrators for troubleshooting a server and tool writers to craft tools that mine the log files and produce reports and trends.Furthermore, these log files can also be used to train anomaly detection systems and feed events into a security event management system. The Session Initiation Protocol (SIP) does not have a common log format, and, as a result, each server supports a distinct log format that makes it unnecessarily complex to produce tools to do trend analysis and security detection. This document describes a framework, including requirements and analysis of existing approaches, and specifies an information model for development of aSIP common log file format that can be used uniformly by user agents, proxies, registrars, and redirect servers as well as back-to-back user agents. |
|
| |
| RFC 6873 | Format for the Session Initiation Protocol (SIP) Common Log Format (CLF) |
| |
| Authors: | G. Salgueiro, V. Gurbani, A. B. Roach. |
| Date: | February 2013 |
| Formats: | txt html json |
| Updated by: | RFC 7355 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6873 |
|
The SIPCLF working group has defined a Common Log Format (CLF) framework for Session Initiation Protocol (SIP) servers. This CLF mimics the successful event logging format found in well-known web servers like Apache and web proxies like Squid. This document proposes an indexed text encoding format for the SIP CLF that retains the key advantages of a text-based format while significantly increasing processing performance over a purely text-based implementation. This file format adheres to the SIP CLF information model and provides an effective encoding scheme for all mandatory and optional fields that appear in a SIP CLF record. |
|
| |
| RFC 6874 | Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers |
| |
| Authors: | B. Carpenter, S. Cheshire, R. Hinden. |
| Date: | February 2013 |
| Formats: | txt json html |
| Updates: | RFC 3986 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6874 |
|
This document describes how the zone identifier of an IPv6 scoped address, defined as <zone_id&rt; in the IPv6 Scoped Address Architecture(RFC 4007), can be represented in a literal IPv6 address and in aUniform Resource Identifier that includes such a literal address. It updates the URI Generic Syntax specification (RFC 3986) accordingly. |
|
| |
| RFC 6876 | A Posture Transport Protocol over TLS (PT-TLS) |
| |
| Authors: | P. Sangster, N. Cam-Winget, J. Salowey. |
| Date: | February 2013 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6876 |
|
This document specifies PT-TLS, a TLS-based Posture Transport (PT) protocol. The PT-TLS protocol carries the Network EndpointAssessment (NEA) message exchange under the protection of a TransportLayer Security (TLS) secured tunnel. |
|
| |
| RFC 6878 | IANA Registry for the Session Initiation Protocol (SIP) "Priority" Header Field |
| |
|
|
This document defines a new IANA registry to keep track of the values defined for the Session Initiation Protocol (SIP) "Priority" header field. It updates RFC 3261. |
|
| |
| RFC 6880 | An Information Model for Kerberos Version 5 |
| |
| Authors: | L. Johansson. |
| Date: | March 2013 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6880 |
|
This document describes an information model for Kerberos version 5 from the point of view of an administrative service. There is no standard for administrating a Kerberos 5 Key Distribution Center(KDC). This document describes the services exposed by an administrative interface to a KDC. |
|
| |
| RFC 6884 | RTP Payload Format for the Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW) |
| |
| Authors: | Z. Fang. |
| Date: | March 2013 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6884 |
|
This document specifies Real-time Transport Protocol (RTP) payload formats to be used for the Enhanced Variable Rate Narrowband-WidebandCodec (EVRC-NW). Three media type registrations are included forEVRC-NW RTP payload formats. In addition, a file format is specified for transport of EVRC-NW speech data in storage mode applications such as email. |
|
| |
| RFC 6887 | Port Control Protocol (PCP) |
| |
|
|
The Port Control Protocol allows an IPv6 or IPv4 host to control how incoming IPv6 or IPv4 packets are translated and forwarded by aNetwork Address Translator (NAT) or simple firewall, and also allows a host to optimize its outgoing NAT keepalive messages. |
|
| |
| RFC 6898 | Link Management Protocol Behavior Negotiation and Configuration Modifications |
| |
|
|
The Link Management Protocol (LMP) is used to coordinate the properties, use, and faults of data links in networks controlled byGeneralized Multiprotocol Label Switching (GMPLS). This document defines an extension to LMP to negotiate capabilities and indicate support for LMP extensions. The defined extension is compatible with non-supporting implementations.
This document updates RFC 4204, RFC 4207, RFC 4209, and RFC 5818. |
|
| |
| RFC 6901 | JavaScript Object Notation (JSON) Pointer |
| |
| Authors: | P. Bryan, Ed., K. Zyp, M. Nottingham, Ed.. |
| Date: | April 2013 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6901 |
|
JSON Pointer defines a string syntax for identifying a specific value within a JavaScript Object Notation (JSON) document. |
|
| |
| RFC 6902 | JavaScript Object Notation (JSON) Patch |
| |
| Authors: | P. Bryan, Ed., M. Nottingham, Ed.. |
| Date: | April 2013 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6902 |
|
JSON Patch defines a JSON document structure for expressing a sequence of operations to apply to a JavaScript Object Notation(JSON) document; it is suitable for use with the HTTP PATCH method.The "application/json-patch+json" media type is used to identify such patch documents. |
|
| |
| RFC 6904 | Encryption of Header Extensions in the Secure Real-time Transport Protocol (SRTP) |
| |
|
|
The Secure Real-time Transport Protocol (SRTP) provides authentication, but not encryption, of the headers of Real-timeTransport Protocol (RTP) packets. However, RTP header extensions may carry sensitive information for which participants in multimedia sessions want confidentiality. This document provides a mechanism, extending the mechanisms of SRTP, to selectively encrypt RTP header extensions in SRTP.
This document updates RFC 3711, the Secure Real-time TransportProtocol specification, to require that all future SRTP encryption transforms specify how RTP header extensions are to be encrypted. |
|
| |
| RFC 6909 | IPv4 Traffic Offload Selector Option for Proxy Mobile IPv6 |
| |
| Authors: | S. Gundavelli, Ed., X. Zhou, J. Korhonen, G. Feige, R. Koodli. |
| Date: | April 2013 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6909 |
|
This specification defines a new mobility option, the IPv4 TrafficOffload Selector option, for Proxy Mobile IPv6. This option can be used by the local mobility anchor and the mobile access gateway for negotiating IPv4 traffic offload policy for a mobility session.Based on the negotiated IPv4 traffic offload policy, a mobile access gateway can selectively offload some of the IPv4 traffic flows in the access network instead of tunneling back to the local mobility anchor in the home network. |
|
| |
| RFC 6910 | Completion of Calls for the Session Initiation Protocol (SIP) |
| |
| Authors: | D. Worley, M. Huelsemann, R. Jesske, D. Alexeitsev. |
| Date: | April 2013 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6910 |
|
The "completion of calls" feature defined in this specification allows the caller of a failed call to be notified when the callee becomes available to receive a call.
For the realization of a basic solution without queuing, this document references the usage of the dialog event package (RFC 4235) that is described as 'Automatic Redial' in "Session InitiationProtocol Service Examples" (RFC 5359).
For the realization of a more comprehensive solution with queuing, this document introduces an architecture for implementing these features in the Session Initiation Protocol where "completion of calls" implementations associated with the caller's and callee's endpoints cooperate to place the caller's request for completion of calls into a queue at the callee's endpoint; when a caller's request is ready to be serviced, re-attempt of the original, failed call is then made.
The architecture is designed to interoperate well with existing completion of calls solutions in other networks. |
|
| |
| RFC 6911 | RADIUS Attributes for IPv6 Access Networks |
| |
| Authors: | W. Dec, Ed., B. Sarikaya, G. Zorn, Ed., D. Miles, B. Lourdelet. |
| Date: | April 2013 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6911 |
|
This document specifies additional IPv6 RADIUS Attributes useful in residential broadband network deployments. The Attributes, which are used for authorization and accounting, enable assignment of a hostIPv6 address and an IPv6 DNS server address via DHCPv6, assignment of an IPv6 route announced via router advertisement, assignment of a named IPv6 delegated prefix pool, and assignment of a named IPv6 pool for host DHCPv6 addressing. |
|
| |
| RFC 6913 | Indicating Fax over IP Capability in the Session Initiation Protocol (SIP) |
| |
| Authors: | D. Hanes, G. Salgueiro, K. Fleming. |
| Date: | March 2013 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6913 |
|
This document defines and registers with IANA the new "fax" media feature tag for use with the Session Initiation Protocol (SIP).Currently, fax calls are indistinguishable from voice calls at call initiation. Consequently, fax calls can be routed to SIP user agents that are not fax capable. A "fax" media feature tag implemented in conjunction with caller preferences allows for more accurate fax call routing. |
|
| |
| RFC 6915 | Flow Identity Extension for HTTP-Enabled Location Delivery (HELD) |
| |
|
|
RFC 6155 specifies an extension for the HTTP-Enabled LocationDelivery (HELD) protocol, allowing the use of an IP address and port number to request a Device location based on an individual packet flow.
However, certain kinds of NAT require that identifiers for both ends of the packet flow must be specified in order to unambiguously satisfy the location request.
This document specifies an XML Schema and a URN Sub-Namespace for aFlow Identity Extension for HELD to support this requirement.
This document updates RFC 6155 by deprecating the port number elements specified therein. |
|
| |
| RFC 6917 | Media Resource Brokering |
| |
| Authors: | C. Boulton, L. Miniero, G. Munson. |
| Date: | April 2013 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6917 |
|
The MediaCtrl working group in the IETF has proposed an architecture for controlling media services. The Session Initiation Protocol(SIP) is used as the signaling protocol that provides many inherent capabilities for message routing. In addition to such signaling properties, a need exists for intelligent, application-level media service selection based on non-static signaling properties. This is especially true when considered in conjunction with deployment architectures that include 1:M and M:N combinations of ApplicationServers and Media Servers. This document introduces a Media ResourceBroker (MRB) entity, which manages the availability of Media Servers and the media resource demands of Application Servers. The document includes potential deployment options for an MRB and appropriate interfaces to Application Servers and Media Servers. |
|
| |
| RFC 6918 | Formally Deprecating Some ICMPv4 Message Types |
| |
|
|
A number of ICMPv4 message types have become obsolete in practice, but have never been formally deprecated. This document deprecates such ICMPv4 message types, thus cleaning up the corresponding IANA registry. Additionally, it updates RFC 792 and RFC 950, obsoletesRFC 1788, and requests the RFC Editor to change the status of RFC1788 to Historic. |
|
| |
| RFC 6920 | Naming Things with Hashes |
| |
| Authors: | S. Farrell, D. Kutscher, C. Dannewitz, B. Ohlman, A. Keranen, P. Hallam-Baker. |
| Date: | April 2013 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6920 |
|
This document defines a set of ways to identify a thing (a digital object in this case) using the output from a hash function. It specifies a new URI scheme for this purpose, a way to map these toHTTP URLs, and binary and human-speakable formats for these names.The various formats are designed to support, but not require, a strong link to the referenced object, such that the referenced object may be authenticated to the same degree as the reference to it. The reason for this work is to standardise current uses of hash outputs in URLs and to support new information-centric applications and other uses of hash outputs in protocols. |
|
| |
| RFC 6923 | MPLS Transport Profile (MPLS-TP) Identifiers Following ITU-T Conventions |
| |
| Authors: | R. Winter, E. Gray, H. van Helvoort, M. Betts. |
| Date: | May 2013 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6923 |
|
This document specifies an extension to the identifiers to be used in the Transport Profile of Multiprotocol Label Switching (MPLS-TP).Identifiers that follow IP/MPLS conventions have already been defined. This memo augments that set of identifiers for MPLS-TP management and Operations, Administration, and Maintenance (OAM) functions to include identifier information in a format typically used by the International Telecommunication Union TelecommunicationStandardization Sector (ITU-T). |
|
| |
| RFC 6925 | The DHCPv4 Relay Agent Identifier Sub-Option |
| |
| Authors: | B. Joshi, R. Desetti, M. Stapp. |
| Date: | April 2013 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6925 |
|
This document defines a new Relay Agent Identifier sub-option for theDynamic Host Configuration Protocol (DHCP) Relay Agent Information option. The sub-option carries a value that uniquely identifies the relay agent device within the administrative domain. The value is normally administratively configured in the relay agent. The sub- option allows a DHCP relay agent to include the identifier in theDHCP messages it sends. |
|
| |
| RFC 6926 | DHCPv4 Bulk Leasequery |
| |
| Authors: | K. Kinnear, M. Stapp, R. Desetti, B. Joshi, N. Russell, P. Kurapati, B. Volz. |
| Date: | April 2013 |
| Formats: | txt html json |
| Updated by: | RFC 7724 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6926 |
|
The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Leasequery protocol allows a requestor to request information about DHCPv4 bindings. This protocol is limited to queries for individual bindings. In some situations, individual binding queries may not be efficient or even possible. This document extends the DHCPv4Leasequery protocol to allow for bulk transfer of DHCPv4 address binding data via TCP. |
|
| |
| RFC 6929 | Remote Authentication Dial In User Service (RADIUS) Protocol Extensions |
| |
|
|
The Remote Authentication Dial-In User Service (RADIUS) protocol is nearing exhaustion of its current 8-bit Attribute Type space. In addition, experience shows a growing need for complex grouping, along with attributes that can carry more than 253 octets of data. This document defines changes to RADIUS that address all of the above problems. |
|
| |
| RFC 6930 | RADIUS Attribute for IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) |
| |
| Authors: | D. Guo, S. Jiang, Ed., R. Despres, R. Maglione. |
| Date: | April 2013 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6930 |
|
The IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) provides bothIPv4 and IPv6 connectivity services simultaneously during theIPv4/IPv6 coexistence period. The Dynamic Host ConfigurationProtocol (DHCP) 6rd option has been defined to configure the 6rdCustomer Edge (CE). However, in many networks, the configuration information may be stored in the Authentication Authorization andAccounting (AAA) servers, while user configuration is mainly acquired from a Broadband Network Gateway (BNG) through the DHCP protocol.This document defines a Remote Authentication Dial-In User Service(RADIUS) attribute that carries 6rd configuration information from the AAA server to BNGs. |
|
| |
| RFC 6931 | Additional XML Security Uniform Resource Identifiers (URIs) |
| |
|
|
This document expands, updates, and establishes an IANA registry for the list of URIs intended for use with XML digital signatures, encryption, canonicalization, and key management. These URIs identify algorithms and types of information. This document obsoletes RFC 4051. |
|
| |
| RFC 6933 | Entity MIB (Version 4) |
| |
| Authors: | A. Bierman, D. Romascanu, J. Quittek, M. Chandramouli. |
| Date: | May 2013 |
| Formats: | txt html json |
| Obsoletes: | RFC 4133 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6933 |
|
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 SimpleNetwork Management Protocol (SNMP) agent. This document specifies version 4 of the Entity MIB. This memo obsoletes version 3 of theEntity MIB module published as RFC 4133. |
|
| |
| RFC 6935 | IPv6 and UDP Checksums for Tunneled Packets |
| |
| Authors: | M. Eubanks, P. Chimento, M. Westerlund. |
| Date: | April 2013 |
| Formats: | txt json html |
| Updates: | RFC 2460 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6935 |
|
This document updates the IPv6 specification (RFC 2460) to improve performance when a tunnel protocol uses UDP with IPv6 to tunnel packets. The performance improvement is obtained by relaxing theIPv6 UDP checksum requirement for tunnel protocols whose header information is protected on the "inner" packet being carried.Relaxing this requirement removes the overhead associated with the computation of UDP checksums on IPv6 packets that carry the tunnel protocol packets. This specification describes how the IPv6 UDP checksum requirement can be relaxed when the encapsulated packet itself contains a checksum. It also describes the limitations and risks of this approach and discusses the restrictions on the use of this method. |
|
| |
| RFC 6936 | Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums |
| |
| Authors: | G. Fairhurst, M. Westerlund. |
| Date: | April 2013 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6936 |
|
This document provides an applicability statement for the use of UDP transport checksums with IPv6. It defines recommendations and requirements for the use of IPv6 UDP datagrams with a zero UDP checksum. It describes the issues and design principles that need to be considered when UDP is used with IPv6 to support tunnel encapsulations, and it examines the role of the IPv6 UDP transport checksum. The document also identifies issues and constraints for deployment on network paths that include middleboxes. An appendix presents a summary of the trade-offs that were considered in evaluating the safety of the update to RFC 2460 that changes the use of the UDP checksum with IPv6. |
|
| |
| RFC 6938 | Deprecation of BGP Path Attributes: DPA, ADVERTISER, and RCID_PATH / CLUSTER_ID |
| |
| Authors: | J. Scudder. |
| Date: | May 2013 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6938 |
|
This document requests IANA to deprecate the following BGP path attributes: DPA, ADVERTISER, and RCID_PATH / CLUSTER_ID, associated with an abandoned Internet-Draft and a Historic RFC. |
|
| |
| RFC 6939 | Client Link-Layer Address Option in DHCPv6 |
| |
| Authors: | G. Halwasia, S. Bhandari, W. Dec. |
| Date: | May 2013 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6939 |
|
This document specifies the format and mechanism that is to be used for encoding the client link-layer address in DHCPv6 Relay-Forward messages by defining a new DHCPv6 Client Link-Layer Address option. |
|
| |
| RFC 6940 | REsource LOcation And Discovery (RELOAD) Base Protocol |
| |
| Authors: | C. Jennings, B. Lowekamp, Ed., E. Rescorla, S. Baset, H. Schulzrinne. |
| Date: | January 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6940 |
|
This specification defines REsource LOcation And Discovery (RELOAD), a peer-to-peer (P2P) signaling protocol for use on the Internet. AP2P signaling protocol provides its clients with an abstract storage and messaging service between a set of cooperating peers that form the overlay network. RELOAD is designed to support a P2P SessionInitiation Protocol (P2PSIP) network, but can be utilized by other applications with similar requirements by defining new usages that specify the Kinds of data that need to be stored for a particular application. RELOAD defines a security model based on a certificate enrollment service that provides unique identities. NAT traversal is a fundamental service of the protocol. RELOAD also allows access from "client" nodes that do not need to route traffic or store data for others. |
|
| |
| RFC 6942 | Diameter Support for the EAP Re-authentication Protocol (ERP) |
| |
| Authors: | J. Bournelle, L. Morand, S. Decugis, Q. Wu, G. Zorn. |
| Date: | May 2013 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6942 |
|
The EAP Re-authentication Protocol (ERP) defines extensions to theExtensible Authentication Protocol (EAP) to support efficient re-authentication between the peer and an EAP Re-authentication (ER) server through a compatible authenticator. This document specifiesDiameter support for ERP. It defines a new Diameter ERP application to transport ERP messages between an ER authenticator and the ER server, and a set of new Attribute-Value Pairs (AVPs) that can be used to transport the cryptographic material needed by the re-authentication server. |
|
| |
| RFC 6944 | Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm Implementation Status |
| |
|
|
The DNS Security Extensions (DNSSEC) requires the use of cryptographic algorithm suites for generating digital signatures overDNS data. There is currently an IANA registry for these algorithms, but there is no record of the recommended implementation status of each algorithm. This document provides an applicability statement on algorithm implementation status for DNSSEC component software. This document lists each algorithm's status based on the current reference. In the case that an algorithm is specified without an implementation status, this document assigns one. This document updates RFCs 2536, 2539, 3110, 4034, 4398, 5155, 5702, and 5933. |
|
| |
| RFC 6945 | Definitions of Managed Objects for the Resource Public Key Infrastructure (RPKI) to Router Protocol |
| |
| Authors: | R. Bush, B. Wijnen, K. Patel, M. Baer. |
| Date: | May 2013 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6945 |
|
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 objects used for monitoring the Resource Public Key Infrastructure (RPKI) to Router Protocol. |
|
| |
| RFC 6946 | Processing of IPv6 "Atomic" Fragments |
| |
|
|
The IPv6 specification allows packets to contain a Fragment Header without the packet being actually fragmented into multiple pieces (we refer to these packets as "atomic fragments"). Such packets are typically sent by hosts that have received an ICMPv6 "Packet Too Big" error message that advertises a Next-Hop MTU smaller than 1280 bytes, and are currently processed by some implementations as normal"fragmented traffic" (i.e., they are "reassembled" with any other queued fragments that supposedly correspond to the same original packet). Thus, an attacker can cause hosts to employ atomic fragments by forging ICMPv6 "Packet Too Big" error messages, and then launch any fragmentation-based attacks against such traffic. This document discusses the generation of the aforementioned atomic fragments and the corresponding security implications. Additionally, this document formally updates RFC 2460 and RFC 5722, such that IPv6 atomic fragments are processed independently of any other fragments, thus completely eliminating the aforementioned attack vector. |
|
| |
| RFC 6951 | UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication |
| |
|
|
This document describes a simple method of encapsulating StreamControl Transmission Protocol (SCTP) packets into UDP packets and its limitations. This allows the usage of SCTP in networks with legacyNATs that do not support SCTP. It can also be used to implement SCTP on hosts without directly accessing the IP layer, for example, implementing it as part of the application without requiring special privileges.
Please note that this document only describes the functionality required within an SCTP stack to add on UDP encapsulation, providing only those mechanisms for two end-hosts to communicate with each other over UDP ports. In particular, it does not provide mechanisms to determine whether UDP encapsulation is being used by the peer, nor the mechanisms for determining which remote UDP port number can be used. These functions are out of scope for this document.
This document covers only end-hosts and not tunneling (egress or ingress) endpoints. |
|
| |
| RFC 6955 | Diffie-Hellman Proof-of-Possession Algorithms |
| |
| Authors: | J. Schaad, H. Prafullchandra. |
| Date: | May 2013 |
| Formats: | txt html json |
| Obsoletes: | RFC 2875 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6955 |
|
This document describes two methods for producing an integrity check value from a Diffie-Hellman key pair and one method for producing an integrity check value from an Elliptic Curve key pair. This behavior is needed for such operations as creating the signature of a Public-Key Cryptography Standards (PKCS) #10 Certification Request. These algorithms are designed to provide a Proof-of-Possession of the private key and not to be a general purpose signing algorithm.
This document obsoletes RFC 2875. |
|
| |
| RFC 6956 | Forwarding and Control Element Separation (ForCES) Logical Function Block (LFB) Library |
| |
| Authors: | W. Wang, E. Haleplidis, K. Ogawa, C. Li, J. Halpern. |
| Date: | June 2013 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6956 |
|
This document defines basic classes of Logical Function Blocks (LFBs) used in Forwarding and Control Element Separation (ForCES). The basic LFB classes are defined according to the ForCES ForwardingElement (FE) model and ForCES protocol specifications; they are scoped to meet requirements of typical router functions and are considered the basic LFB library for ForCES. The library includes the descriptions of the LFBs and the XML definitions. |
|
| |
| RFC 6957 | Duplicate Address Detection Proxy |
| |
| Authors: | F. Costa, J-M. Combes, Ed., X. Pougnard, H. Li. |
| Date: | June 2013 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6957 |
|
The document describes a proxy-based mechanism allowing the use ofDuplicate Address Detection (DAD) by IPv6 nodes in a point-to- multipoint architecture with a "split-horizon" forwarding scheme, primarily deployed for Digital Subscriber Line (DSL) and Fiber access architectures. Based on the DAD signaling, the first-hop router stores in a Binding Table all known IPv6 addresses used on a point- to-multipoint domain (e.g., VLAN). When a node performs DAD for an address already used by another node, the first-hop router defends the address rather than the device using the address. |
|
| |
| RFC 6958 | RTP Control Protocol (RTCP) Extended Report (XR) Block for Burst/Gap Loss Metric Reporting |
| |
| Authors: | A. Clark, S. Zhang, J. Zhao, Q. Wu, Ed.. |
| Date: | May 2013 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6958 |
|
This document defines an RTP Control Protocol (RTCP) Extended Report(XR) Block that allows the reporting of burst and gap loss metrics for use in a range of RTP applications. |
|
| |
| RFC 6960 | X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP |
| |
|
|
This document specifies a protocol useful in determining the current status of a digital certificate without requiring CertificateRevocation Lists (CRLs). Additional mechanisms addressing PKIX operational requirements are specified in separate documents. This document obsoletes RFCs 2560 and 6277. It also updates RFC 5912. |
|
| |
| RFC 6961 | The Transport Layer Security (TLS) Multiple Certificate Status Request Extension |
| |
|
|
This document defines the Transport Layer Security (TLS) CertificateStatus Version 2 Extension to allow clients to specify and support several certificate status methods. (The use of the CertificateStatus extension is commonly referred to as "OCSP stapling".) Also defined is a new method based on the Online Certificate StatusProtocol (OCSP) that servers can use to provide status information about not only the server's own certificate but also the status of intermediate certificates in the chain. |
|
| |
| RFC 6969 | OSPFv3 Instance ID Registry Update |
| |
|
|
This document modifies the "Unassigned" number space in the IANA"OSPFv3 Instance ID Address Family Values" registry by dividing it in two halves -- one half Unassigned but managed via Standards Action, and the other Reserved for Private Use. It updates RFC 5838. |
|
| |
| RFC 6970 | Universal Plug and Play (UPnP) Internet Gateway Device - Port Control Protocol Interworking Function (IGD-PCP IWF) |
| |
| Authors: | M. Boucadair, R. Penno, D. Wing. |
| Date: | July 2013 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6970 |
|
This document specifies the behavior of the Universal Plug and Play(UPnP) Internet Gateway Device - Port Control Protocol InterworkingFunction (IGD-PCP IWF). A UPnP IGD-PCP IWF is required to be embedded in Customer Premises (CP) routers to allow for transparentNAT control in environments where a UPnP IGD is used on the LAN side and PCP is used on the external side of the CP router. |
|
| |
| RFC 6975 | Signaling Cryptographic Algorithm Understanding in DNS Security Extensions (DNSSEC) |
| |
| Authors: | S. Crocker, S. Rose. |
| Date: | July 2013 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6975 |
|
The DNS Security Extensions (DNSSEC) were developed to provide origin authentication and integrity protection for DNS data by using digital signatures. These digital signatures can be generated using different algorithms. This document specifies a way for validating end-system resolvers to signal to a server which digital signature and hash algorithms they support. The extensions allow the signaling of new algorithm uptake in client code to allow zone administrators to know when it is possible to complete an algorithm rollover in aDNSSEC-signed zone. |
|
| |
| RFC 6977 | Triggering DHCPv6 Reconfiguration from Relay Agents |
| |
| Authors: | M. Boucadair, X. Pougnard. |
| Date: | July 2013 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6977 |
|
This document defines two new DHCPv6 messages: Reconfigure-Request and Reconfigure-Reply. The Reconfigure-Request message is sent by aDHCPv6 relay agent to notify a DHCPv6 server about a configuration information change, so that the DHCPv6 server can send a Reconfigure message accordingly. The Reconfigure-Reply message is used by the server to acknowledge the receipt of the Reconfigure-Request message. |
|
| |
| RFC 6980 | Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery |
| |
|
|
This document analyzes the security implications of employing IPv6 fragmentation with Neighbor Discovery (ND) messages. It updates RFC4861 such that use of the IPv6 Fragmentation Header is forbidden in all Neighbor Discovery messages, thus allowing for simple and effective countermeasures for Neighbor Discovery attacks. Finally, it discusses the security implications of using IPv6 fragmentation with SEcure Neighbor Discovery (SEND) and formally updates RFC 3971 to provide advice regarding how the aforementioned security implications can be mitigated. |
|
| |
| RFC 6989 | Additional Diffie-Hellman Tests for the Internet Key Exchange Protocol Version 2 (IKEv2) |
| |
|
|
This document adds a small number of mandatory tests required for the secure operation of the Internet Key Exchange Protocol version 2(IKEv2) with elliptic curve groups. No change is required to IKE implementations that use modular exponential groups, other than a few rarely used so-called Digital Signature Algorithm (DSA) groups. This document updates the IKEv2 protocol, RFC 5996. |
|
| |
| RFC 6990 | RTP Control Protocol (RTCP) Extended Report (XR) Block for MPEG-2 Transport Stream (TS) Program Specific Information (PSI) Independent Decodability Statistics Metrics Reporting |
| |
| Authors: | R. Huang, Q. Wu, H. Asaeda, G. Zorn. |
| Date: | August 2013 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6990 |
|
An MPEG-2 Transport Stream (TS) is a standard container format used in the transmission and storage of multimedia data. Unicast/ multicast MPEG-2 TS over RTP is widely deployed in IPTV systems.This document defines an RTP Control Protocol (RTCP) Extended Report(XR) block that allows the reporting of MPEG-2 TS decodability statistics metrics related to transmissions of MPEG-2 TS over RTP.The metrics specified in the RTCP XR block are not dependent onProgram Specific Information (PSI) carried in MPEG-2 TS. |
|
| |
| RFC 6991 | Common YANG Data Types |
| |
|
|
This document introduces a collection of common data types to be used with the YANG data modeling language. This document obsoletes RFC6021. |
|
| |
| RFC 6994 | Shared Use of Experimental TCP Options |
| |
| Authors: | J. Touch. |
| Date: | August 2013 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 6994 |
|
This document describes how the experimental TCP option codepoints can concurrently support multiple TCP extensions, even within the same connection, using a new IANA TCP experiment identifier. This approach is robust to experiments that are not registered and to those that do not use this sharing mechanism. It is recommended for all new TCP options that use these codepoints. |
|
| |
| RFC 7001 | Message Header Field for Indicating Message Authentication Status |
| |
|
|
This document specifies a message header field called Authentication-Results for use with electronic mail messages to indicate the results of message authentication efforts. Any receiver-side software, such as mail filters or Mail User Agents (MUAs), can use this header field to relay that information in a convenient and meaningful way to users or to make sorting and filtering decisions. |
|
| |
| RFC 7002 | RTP Control Protocol (RTCP) Extended Report (XR) Block for Discard Count Metric Reporting |
| |
| Authors: | A. Clark, G. Zorn, Q. Wu. |
| Date: | September 2013 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7002 |
|
This document defines an RTP Control Protocol (RTCP) Extended Report(XR) block that allows the reporting of a simple discard count metric for use in a range of RTP applications. |
|
| |
| RFC 7003 | RTP Control Protocol (RTCP) Extended Report (XR) Block for Burst/Gap Discard Metric Reporting |
| |
| Authors: | A. Clark, R. Huang, Q. Wu, Ed.. |
| Date: | September 2013 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7003 |
|
This document defines an RTP Control Protocol (RTCP) Extended Report(XR) block that allows the reporting of burst and gap discard metrics for use in a range of RTP applications. |
|
| |
| RFC 7004 | RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Summary Statistics Metrics Reporting |
| |
| Authors: | G. Zorn, R. Schott, Q. Wu, Ed., R. Huang. |
| Date: | September 2013 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7004 |
|
This document defines three RTP Control Protocol (RTCP) ExtendedReport (XR) blocks that allow the reporting of loss, duplication, and discard summary statistics metrics in a range of RTP applications. |
|
| |
| RFC 7005 | RTP Control Protocol (RTCP) Extended Report (XR) Block for De-Jitter Buffer Metric Reporting |
| |
| Authors: | A. Clark, V. Singh, Q. Wu. |
| Date: | September 2013 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7005 |
|
This document defines an RTP Control Protocol (RTCP) Extended Report(XR) block that allows the reporting of de-jitter buffer metrics for a range of RTP applications. |
|
| |
| RFC 7006 | Miscellaneous Capabilities Negotiation in the Session Description Protocol (SDP) |
| |
| Authors: | M. Garcia-Martin, S. Veikkolainen, R. Gilman. |
| Date: | September 2013 |
| Formats: | txt pdf html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7006 |
|
The Session Description Protocol (SDP) has been extended with a capability negotiation mechanism framework that allows the endpoints to negotiate transport protocols and attributes. This framework has been extended with a media capabilities negotiation mechanism that allows endpoints to negotiate additional media-related capabilities.This negotiation is embedded into the widely used SDP offer/answer procedures.
This memo extends the SDP capability negotiation framework to allow endpoints to negotiate three additional SDP capabilities. In particular, this memo provides a mechanism to negotiate bandwidth("b=" line), connection data ("c=" line), and session or media titles("i=" line for each session or media). |
|
| |
| RFC 7007 | Update to Remove DVI4 from the Recommended Codecs for the RTP Profile for Audio and Video Conferences with Minimal Control (RTP/AVP) |
| |
|
|
The RTP Profile for Audio and Video Conferences with Minimal Control(RTP/AVP) is the basis for many other profiles, such as the SecureReal-time Transport Protocol (RTP/SAVP), the Extended RTP Profile forReal-time Transport Control Protocol (RTCP)-Based Feedback(RTP/AVPF), and the Extended Secure RTP Profile for RTCP-BasedFeedback (RTP/SAVPF). This document updates RFC 3551, the RTP/AVP profile (and by extension, the profiles that build upon it), to reflect changes in audio codec usage since that document was originally published. |
|
| |
| RFC 7009 | OAuth 2.0 Token Revocation |
| |
| Authors: | T. Lodderstedt, Ed., S. Dronia, M. Scurtescu. |
| Date: | August 2013 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7009 |
|
This document proposes an additional endpoint for OAuth authorization servers, which allows clients to notify the authorization server that a previously obtained refresh or access token is no longer needed.This allows the authorization server to clean up security credentials. A revocation request will invalidate the actual token and, if applicable, other tokens based on the same authorization grant. |
|
| |
| RFC 7012 | Information Model for IP Flow Information Export (IPFIX) |
| |
| Authors: | B. Claise, Ed., B. Trammell, Ed.. |
| Date: | September 2013 |
| Formats: | txt html json |
| Obsoletes: | RFC 5102 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7012 |
|
This document defines the data types and management policy for the information model for the IP Flow Information Export (IPFIX) protocol. This information model is maintained as the IANA "IPFIXInformation Elements" registry, the initial contents of which were defined by RFC 5102. This information model is used by the IPFIX protocol for encoding measured traffic information and information related to the traffic Observation Point, the traffic MeteringProcess, and the Exporting Process. Although this model was developed for the IPFIX protocol, it is defined in an open way that allows it to be easily used in other protocols, interfaces, and applications. This document obsoletes RFC 5102. |
|
| |
| RFC 7014 | Flow Selection Techniques |
| |
| Authors: | S. D'Antonio, T. Zseby, C. Henke, L. Peluso. |
| Date: | September 2013 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7014 |
|
The Intermediate Flow Selection Process is the process of selecting a subset of Flows from all observed Flows. The Intermediate FlowSelection Process may be located at an IP Flow Information Export(IPFIX) Exporter or Collector, or within an IPFIX Mediator. It reduces the effort of post-processing Flow data and transferring FlowRecords. This document describes motivations for using theIntermediate Flow Selection process and presents Intermediate FlowSelection techniques. It provides an information model for configuring Intermediate Flow Selection Process techniques and discusses what information about an Intermediate Flow SelectionProcess should be exported. |
|
| |
| RFC 7015 | Flow Aggregation for the IP Flow Information Export (IPFIX) Protocol |
| |
| Authors: | B. Trammell, A. Wagner, B. Claise. |
| Date: | September 2013 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7015 |
|
This document provides a common implementation-independent basis for the interoperable application of the IP Flow Information Export(IPFIX) protocol to the handling of Aggregated Flows, which are IPFIXFlows representing packets from multiple Original Flows sharing some set of common properties. It does this through a detailed terminology and a descriptive Intermediate Aggregation Process architecture, including a specification of methods for Original Flow counting and counter distribution across intervals. |
|
| |
| RFC 7022 | Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs) |
| |
| Authors: | A. Begen, C. Perkins, D. Wing, E. Rescorla. |
| Date: | September 2013 |
| Formats: | txt html json |
| Obsoletes: | RFC 6222 |
| Updates: | RFC 3550 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7022 |
|
The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a persistent transport-level identifier for an RTP endpoint. While theSynchronization Source (SSRC) identifier of an RTP endpoint may change if a collision is detected or when the RTP application is restarted, its RTCP CNAME is meant to stay unchanged, so that RTP endpoints can be uniquely identified and associated with their RTP media streams.
For proper functionality, RTCP CNAMEs should be unique within the participants of an RTP session. However, the existing guidelines for choosing the RTCP CNAME provided in the RTP standard (RFC 3550) are insufficient to achieve this uniqueness. RFC 6222 was published to update those guidelines to allow endpoints to choose unique RTCPCNAMEs. Unfortunately, later investigations showed that some parts of the new algorithms were unnecessarily complicated and/or ineffective. This document addresses these concerns and replaces RFC6222. |
|
| |
| RFC 7023 | MPLS and Ethernet Operations, Administration, and Maintenance (OAM) Interworking |
| |
| Authors: | D. Mohan, Ed., N. Bitar, Ed., A. Sajassi, Ed., S. DeLord, P. Niger, R. Qiu. |
| Date: | October 2013 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7023 |
|
This document specifies the mapping of defect states between EthernetAttachment Circuits (ACs) and associated Ethernet pseudowires (PWs) connected in accordance with the Pseudowire Emulation Edge-to-Edge(PWE3) architecture to realize an end-to-end emulated Ethernet service. It standardizes the behavior of Provider Edges (PEs) with respect to Ethernet PW and AC defects. |
|
| |
| RFC 7024 | Virtual Hub-and-Spoke in BGP/MPLS VPNs |
| |
| Authors: | H. Jeng, J. Uttaro, L. Jalil, B. Decraene, Y. Rekhter, R. Aggarwal. |
| Date: | October 2013 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7024 |
|
With BGP/MPLS Virtual Private Networks (VPNs), providing any-to-any connectivity among sites of a given VPN would require each ProviderEdge (PE) router connected to one or more of these sites to hold all the routes of that VPN. The approach described in this document allows the VPN service provider to reduce the number of PE routers that have to maintain all these routes by requiring only a subset of these routers to maintain all these routes.
Furthermore, when PE routers use ingress replication to carry the multicast traffic of VPN customers, the approach described in this document may, under certain circumstances, reduce bandwidth inefficiency associated with ingress replication and redistribute the replication load among PE routers. |
|
| |
| RFC 7026 | Retiring TLVs from the Associated Channel Header of the MPLS Generic Associated Channel |
| |
| Authors: | A. Farrel, S. Bryant. |
| Date: | September 2013 |
| Formats: | txt html json |
| Updates: | RFC 5586 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7026 |
|
The MPLS Generic Associated Channel (G-ACh) is a generalization of the applicability of the pseudowire (PW) Associated Channel Header(ACH). RFC 5586 defines the concept of TLV constructs that can be carried in messages on the G-ACh by placing them in the ACH between the fixed header fields and the G-ACh message. These TLVs are calledACH TLVs
No Associated Channel Type yet defined uses an ACH TLV. Furthermore, it is believed that handling TLVs in hardware introduces significant problems to the fast path, and since G-ACh messages are intended to be processed substantially in hardware, the use of ACH TLVs is undesirable.
This document updates RFC 5586 by retiring ACH TLVs and removing the associated registry. |
|
| |
| RFC 7030 | Enrollment over Secure Transport |
| |
|
|
This document profiles certificate enrollment for clients usingCertificate Management over CMS (CMC) messages over a secure transport. This profile, called Enrollment over Secure Transport(EST), describes a simple, yet functional, certificate management protocol targeting Public Key Infrastructure (PKI) clients that need to acquire client certificates and associated Certification Authority(CA) certificates. It also supports client-generated public/private key pairs as well as key pairs generated by the CA. |
|
| |
| RFC 7032 | LDP Downstream-on-Demand in Seamless MPLS |
| |
| Authors: | T. Beckhaus, Ed., B. Decraene, K. Tiruveedhula, M. Konstantynowicz, Ed., L. Martini. |
| Date: | October 2013 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7032 |
|
Seamless MPLS design enables a single IP/MPLS network to scale over core, metro, and access parts of a large packet network infrastructure using standardized IP/MPLS protocols. One of the key goals of Seamless MPLS is to meet requirements specific to access networks including high number of devices, device position in network topology, and compute and memory constraints that limit the amount of state access devices can hold. This can be achieved with LDPDownstream-on-Demand (DoD) label advertisement. This document describes LDP DoD use cases and lists required LDP DoD procedures in the context of Seamless MPLS design.
In addition, a new optional TLV type in the LDP Label Request message is defined for fast-up convergence. |
|
| |
| RFC 7033 | WebFinger |
| |
| Authors: | P. Jones, G. Salgueiro, M. Jones, J. Smarr. |
| Date: | September 2013 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7033 |
|
This specification defines the WebFinger protocol, which can be used to discover information about people or other entities on theInternet using standard HTTP methods. WebFinger discovers information for a URI that might not be usable as a locator otherwise, such as account or email URIs. |
|
| |
| RFC 7035 | Relative Location Representation |
| |
| Authors: | M. Thomson, B. Rosen, D. Stanley, G. Bajko, A. Thomson. |
| Date: | October 2013 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7035 |
|
This document defines an extension to the Presence Information DataFormat Location Object (PIDF-LO) (RFC 4119) for the expression of location information that is defined relative to a reference point.The reference point may be expressed as a geodetic or civic location, and the relative offset may be one of several shapes. An alternative binary representation is described.
Optionally, a reference to a secondary document (such as a map image) can be included, along with the relationship of the map coordinate system to the reference/offset coordinate system, to allow display of the map with the reference point and the relative offset. |
|
| |
| RFC 7037 | RADIUS Option for the DHCPv6 Relay Agent |
| |
| Authors: | L. Yeh, M. Boucadair. |
| Date: | October 2013 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7037 |
|
The DHCPv6 RADIUS option provides a mechanism to exchange authorization and identification information between the DHCPv6 relay agent and DHCPv6 server. This architecture assumes that the NetworkAccess Server (NAS) acts as both a DHCPv6 relay agent and RADIUS client. When receiving messages from the DHCPv6 clients, the NAS consults the RADIUS server and adds the RADIUS response when forwarding the DHCPv6 client's messages to the DHCPv6 server. TheDHCPv6 server then uses that additional information to generate an appropriate response to the DHCPv6 client's requests. |
|
| |
| RFC 7044 | An Extension to the Session Initiation Protocol (SIP) for Request History Information |
| |
| Authors: | M. Barnes, F. Audet, S. Schubert, J. van Elburg, C. Holmberg. |
| Date: | February 2014 |
| Formats: | txt html json |
| Obsoletes: | RFC 4244 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7044 |
|
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 SIP request arrives at a specific application or user. This document defines an optional SIP header field, History-Info, for capturing the history information in requests. The document also defines SIP header field parameters for the History-Info and Contact header fields to tag the method by which the target of a request is determined. In addition, this specification defines a value for the Privacy header field that directs the anonymization of values in the History-Info header field.This document obsoletes RFC 4244. |
|
| |
| RFC 7045 | Transmission and Processing of IPv6 Extension Headers |
| |
|
|
Various IPv6 extension headers have been standardised since the IPv6 standard was first published. This document updates RFC 2460 to clarify how intermediate nodes should deal with such extension headers and with any that are defined in the future. It also specifies how extension headers should be registered by IANA, with a corresponding minor update to RFC 2780. |
|
| |
| RFC 7048 | Neighbor Unreachability Detection Is Too Impatient |
| |
| Authors: | E. Nordmark, I. Gashinsky. |
| Date: | January 2014 |
| Formats: | txt html json |
| Updates: | RFC 4861 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7048 |
|
IPv6 Neighbor Discovery includes Neighbor Unreachability Detection.That function is very useful when a host has an alternative neighbor-- for instance, when there are multiple default routers -- since it allows the host to switch to the alternative neighbor in a short time. By default, this time is 3 seconds after the node starts probing. However, if there are no alternative neighbors, this timeout behavior is far too impatient. This document specifies relaxed rules for Neighbor Discovery retransmissions that allow an implementation to choose different timeout behavior based on whether or not there are alternative neighbors. This document updates RFC4861. |
|
| |
| RFC 7049 | Concise Binary Object Representation (CBOR) |
| |
| Authors: | C. Bormann, P. Hoffman. |
| Date: | October 2013 |
| Formats: | txt html json |
| Obsoleted by: | RFC 8949 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7049 |
|
The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. |
|
| |
| RFC 7050 | Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis |
| |
| Authors: | T. Savolainen, J. Korhonen, D. Wing. |
| Date: | November 2013 |
| Formats: | txt html json |
| Updated by: | RFC 8880 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7050 |
|
This document describes a method for detecting the presence of DNS64 and for learning the IPv6 prefix used for protocol translation on an access network. The method depends on the existence of a well-knownIPv4-only fully qualified domain name "ipv4only.arpa.". The information learned enables nodes to perform local IPv6 address synthesis and to potentially avoid NAT64 on dual-stack and multi- interface deployments. |
|
| |
| RFC 7053 | SACK-IMMEDIATELY Extension for the Stream Control Transmission Protocol |
| |
|
|
This document updates RFC 4960 by defining a method for the sender of a DATA chunk to indicate that the corresponding SelectiveAcknowledgment (SACK) chunk should be sent back immediately and should not be delayed. It is done by specifying a bit in the DATA chunk header, called the (I)mmediate bit, which can get set by either the Stream Control Transmission Protocol (SCTP) implementation or the application using an SCTP stack. Since unknown flags in chunk headers are ignored by SCTP implementations, this extension does not introduce any interoperability problems. |
|
| |
| RFC 7055 | A GSS-API Mechanism for the Extensible Authentication Protocol |
| |
| Authors: | S. Hartman, Ed., J. Howlett. |
| Date: | December 2013 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7055 |
|
This document defines protocols, procedures, and conventions to be employed by peers implementing the Generic Security ServiceApplication Program Interface (GSS-API) when using the ExtensibleAuthentication Protocol mechanism. Through the GS2 family of mechanisms defined in RFC 5801, these protocols also define howSimple Authentication and Security Layer (SASL) applications use theExtensible Authentication Protocol. |
|
| |
| RFC 7056 | Name Attributes for the GSS-API Extensible Authentication Protocol (EAP) Mechanism |
| |
| Authors: | S. Hartman, J. Howlett. |
| Date: | December 2013 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7056 |
|
The naming extensions to the Generic Security Service ApplicationProgramming Interface (GSS-API) provide a mechanism for applications to discover authorization and personalization information associated with GSS-API names. The Extensible Authentication Protocol GSS-API mechanism allows an Authentication, Authorization, and Accounting(AAA) peer to provide authorization attributes alongside an authentication response. It also supplies mechanisms to processSecurity Assertion Markup Language (SAML) messages provided in theAAA response. This document describes how to use the NamingExtensions API to access that information. |
|
| |
| RFC 7057 | Update to the Extensible Authentication Protocol (EAP) Applicability Statement for Application Bridging for Federated Access Beyond Web (ABFAB) |
| |
| Authors: | S. Winter, J. Salowey. |
| Date: | December 2013 |
| Formats: | txt json html |
| Updates: | RFC 3748 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7057 |
|
This document updates the Extensible Authentication Protocol (EAP) applicability statement from RFC 3748 to reflect recent usage of theEAP protocol in the Application Bridging for Federated Access Beyond web (ABFAB) architecture. |
|
| |
| RFC 7060 | Using LDP Multipoint Extensions on Targeted LDP Sessions |
| |
| Authors: | M. Napierala, E. Rosen, IJ. Wijnands. |
| Date: | November 2013 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7060 |
|
Label Distribution Protocol (LDP) can be used to set up Point-to-Multipoint (P2MP) and Multipoint-to-Multipoint (MP2MP) Label SwitchedPaths. However, the specification for the Multipoint Extensions toLDP presupposes that the two endpoints of an LDP session are directly connected. The LDP base specification allows for the case where the two endpoints of an LDP session are not directly connected; such a session is known as a "Targeted LDP" session. This document provides the specification for using the LDP Multipoint Extensions over aTargeted LDP session. |
|
| |
| RFC 7064 | URI Scheme for the Session Traversal Utilities for NAT (STUN) Protocol |
| |
| Authors: | S. Nandakumar, G. Salgueiro, P. Jones, M. Petit-Huguenin. |
| Date: | November 2013 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7064 |
|
This document specifies the syntax and semantics of the UniformResource Identifier (URI) scheme for the Session Traversal Utilities for NAT (STUN) protocol. |
|
| |
| RFC 7065 | Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers |
| |
| Authors: | M. Petit-Huguenin, S. Nandakumar, G. Salgueiro, P. Jones. |
| Date: | November 2013 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7065 |
|
This document specifies the syntax of Uniform Resource Identifier(URI) schemes for the Traversal Using Relays around NAT (TURN) protocol. It defines two URI schemes to provision the TURNResolution Mechanism (RFC 5928). |
|
| |
| RFC 7070 | An Architecture for Reputation Reporting |
| |
| Authors: | N. Borenstein, M. Kucherawy. |
| Date: | November 2013 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7070 |
|
This document describes a general architecture for a reputation-based service, allowing one to request reputation-related data over theInternet, where "reputation" refers to predictions or expectations about an entity or an identifier such as a domain name. The document roughly follows the recommendations of RFC 4101 for describing a protocol model. |
|
| |
| RFC 7071 | A Media Type for Reputation Interchange |
| |
| Authors: | N. Borenstein, M. Kucherawy. |
| Date: | November 2013 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7071 |
|
This document defines the format of reputation response data("reputons"), the media type for packaging it, and definition of a registry for the names of reputation applications and response sets. |
|
| |
| RFC 7072 | A Reputation Query Protocol |
| |
| Authors: | N. Borenstein, M. Kucherawy. |
| Date: | November 2013 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7072 |
|
This document defines a mechanism to conduct queries for reputation information over the HyperText Transfer Protocol (HTTP) usingJavaScript Object Notation (JSON) as the payload meta-format. |
|
| |
| RFC 7073 | A Reputation Response Set for Email Identifiers |
| |
| Authors: | N. Borenstein, M. Kucherawy. |
| Date: | November 2013 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7073 |
|
This document defines a response set for describing assertions a reputation service provider can make about email identifiers, for use in generating reputons. |
|
| |
| RFC 7074 | Revised Definition of the GMPLS Switching Capability and Type Fields |
| |
|
|
GMPLS provides control for multiple switching technologies and for hierarchical switching within a technology. GMPLS routing and signaling use common values to indicate the type of switching technology. These values are carried in routing protocols via theSwitching Capability field, and in signaling protocols via theSwitching Type field. While the values used in these fields are the primary indicators of the technology and hierarchy level being controlled, the values are not consistently defined and used across the different technologies supported by GMPLS. This document is intended to resolve the inconsistent definition and use of theSwitching Capability and Type fields by narrowly scoping the meaning and use of the fields. This document updates all documents that use the GMPLS Switching Capability and Types fields, in particular RFCs3471, 4202, 4203, and 5307. |
|
| |
| RFC 7075 | Realm-Based Redirection In Diameter |
| |
| Authors: | T. Tsou, R. Hao, T. Taylor, Ed.. |
| Date: | November 2013 |
| Formats: | txt html json |
| Updates: | RFC 6733 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7075 |
|
The Diameter protocol includes a capability for message redirection, controlled by an application-independent "redirect agent". In some circumstances, an operator may wish to redirect messages to an alternate domain without specifying individual hosts. This document specifies an application-specific mechanism by which a Diameter server or proxy (node) can perform such a redirection when theStraightforward-Naming Authority Pointer (S-NAPTR) is not used for dynamic peer discovery. A node performing this new function is referred to as a "Realm-based Redirect Server".
This memo updates Sections 6.13 and 6.14 of RFC 6733 with respect to the usage of the Redirect-Host-Usage and Redirect-Max-Cache-TimeAttribute-Value Pairs (AVPs). |
|
| |
| RFC 7077 | Update Notifications for Proxy Mobile IPv6 |
| |
| Authors: | S. Krishnan, S. Gundavelli, M. Liebsch, H. Yokota, J. Korhonen. |
| Date: | November 2013 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7077 |
|
This document specifies protocol enhancements for allowing the local mobility anchor in a Proxy Mobile IPv6 domain to asynchronously notify the mobile access gateway about changes related to a mobility session. These Update Notification messages are exchanged using a new Mobility Header message type specifically designed for this purpose. |
|
| |
| RFC 7078 | Distributing Address Selection Policy Using DHCPv6 |
| |
| Authors: | A. Matsumoto, T. Fujisaki, T. Chown. |
| Date: | January 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7078 |
|
RFC 6724 defines default address selection mechanisms for IPv6 that allow nodes to select an appropriate address when faced with multiple source and/or destination addresses to choose between. RFC 6724 allows for the future definition of methods to administratively configure the address selection policy information. This document defines a new DHCPv6 option for such configuration, allowing a site administrator to distribute address selection policy overriding the default address selection parameters and policy table, and thus allowing the administrator to control the address selection behavior of nodes in their site. |
|
| |
| RFC 7083 | Modification to Default Values of SOL_MAX_RT and INF_MAX_RT |
| |
|
|
This document updates RFC 3315 by redefining the default values forSOL_MAX_RT and INF_MAX_RT and defining options through which a DHCPv6 server can override the client's default value for SOL_MAX_RT andINF_MAX_RT with new values. |
|
| |
| RFC 7090 | Public Safety Answering Point (PSAP) Callback |
| |
| Authors: | H. Schulzrinne, H. Tschofenig, C. Holmberg, M. Patel. |
| Date: | April 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7090 |
|
After an emergency call is completed (terminated either prematurely by the emergency caller or normally by the call taker), the call taker may feel the need for further communication. For example, the call may have been dropped by accident without the call taker having sufficient information about the current state of an accident victim.A call taker may trigger a callback to the emergency caller using the contact information provided with the initial emergency call. This callback could, under certain circumstances, be treated like any other call and, as a consequence, it may get blocked by authorization policies or may get forwarded to an answering machine.
The IETF emergency services architecture specification already offers a solution approach for allowing Public Safety Answering Point (PSAP) callbacks to bypass authorization policies in order to reach the caller without unnecessary delays. Unfortunately, the specified mechanism only supports limited scenarios. This document discusses shortcomings of the current mechanisms and illustrates additional scenarios where better-than-normal call treatment behavior would be desirable. We describe a solution based on a new header field value for the SIP Priority header field, called "psap-callback", to markPSAP callbacks. |
|
| |
| RFC 7095 | jCard: The JSON Format for vCard |
| |
| Authors: | P. Kewisch. |
| Date: | January 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7095 |
|
This specification defines "jCard", a JSON format for vCard data.The vCard data format is a text format for representing and exchanging information about individuals and other entities, for example, telephone numbers, email addresses, structured names, and delivery addresses. JSON is a lightweight, text-based, language- independent data interchange format commonly used in Internet applications. |
|
| |
| RFC 7097 | RTP Control Protocol (RTCP) Extended Report (XR) for RLE of Discarded Packets |
| |
| Authors: | J. Ott, V. Singh, Ed., I. Curcio. |
| Date: | January 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7097 |
|
The RTP Control Protocol (RTCP) is used in conjunction with the Real- time Transport Protocol (RTP) in order to provide a variety of short- term and long-term reception statistics. The available reporting may include aggregate information across longer periods of time as well as individual packet reporting. This document specifies a per-packet report metric capturing individual packets discarded from the de- jitter buffer after successful reception. |
|
| |
| RFC 7104 | Duplication Grouping Semantics in the Session Description Protocol |
| |
| Authors: | A. Begen, Y. Cai, H. Ou. |
| Date: | January 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7104 |
|
Packet loss is undesirable for real-time multimedia sessions, but it can occur due to congestion or other unplanned network outages. This is especially true for IP multicast networks, where packet loss patterns can vary greatly between receivers. One technique that can be used to recover from packet loss without incurring unbounded delay for all the receivers is to duplicate the packets and send them in separate redundant streams. This document defines the semantics for grouping redundant streams in the Session Description Protocol (SDP).The semantics defined in this document are to be used with the SDPGrouping Framework. Grouping semantics at the Synchronization Source(SSRC) level are also defined in this document for RTP streams usingSSRC multiplexing. |
|
| |
| RFC 7105 | Using Device-Provided Location-Related Measurements in Location Configuration Protocols |
| |
| Authors: | M. Thomson, J. Winterbottom. |
| Date: | January 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7105 |
|
This document describes a protocol for a Device to provide location- related measurement data to a Location Information Server (LIS) within a request for location information. Location-related measurement information provides observations concerning properties related to the position of a Device; this information could be data about network attachment or about the physical environment. A LIS is able to use the location-related measurement data to improve the accuracy of the location estimate it provides to the Device. A basic set of location-related measurements are defined, including common modes of network attachment as well as assisted Global NavigationSatellite System (GNSS) parameters. |
|
| |
| RFC 7110 | Return Path Specified Label Switched Path (LSP) Ping |
| |
| Authors: | M. Chen, W. Cao, S. Ning, F. Jounay, S. Delord. |
| Date: | January 2014 |
| Formats: | txt html json |
| Updated by: | RFC 7737 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7110 |
|
This document defines extensions to the data-plane failure-detection protocol for Multiprotocol Label Switching (MPLS) Label SwitchedPaths (LSPs) known as "LSP ping". These extensions allow a selection of the LSP to be used for the echo reply return path. Enforcing a specific return path can be used to verify bidirectional connectivity and also increase LSP ping robustness. |
|
| |
| RFC 7112 | Implications of Oversized IPv6 Header Chains |
| |
| Authors: | F. Gont, V. Manral, R. Bonica. |
| Date: | January 2014 |
| Formats: | txt json html |
| Updates: | RFC 2460 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7112 |
|
The IPv6 specification allows IPv6 Header Chains of an arbitrary size. The specification also allows options that can, in turn, extend each of the headers. In those scenarios in which the IPv6Header Chain or options are unusually long and packets are fragmented, or scenarios in which the fragment size is very small, the First Fragment of a packet may fail to include the entire IPv6Header Chain. This document discusses the interoperability and security problems of such traffic, and updates RFC 2460 such that theFirst Fragment of a packet is required to contain the entire IPv6Header Chain. |
|
| |
| RFC 7114 | Creation of a Registry for smime-type Parameter Values |
| |
| Authors: | B. Leiba. |
| Date: | January 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7114 |
|
Secure/Multipurpose Internet Mail Extensions (S/MIME) defined theContent-Type parameter "smime-type". As the list of defined values for that parameter has increased, it has become clear that a registry is needed to document these values. This document creates the registry, registers the current values, and specifies the policies for registration of new values. |
|
| |
| RFC 7117 | Multicast in Virtual Private LAN Service (VPLS) |
| |
| Authors: | R. Aggarwal, Ed., Y. Kamite, L. Fang, Y. Rekhter, C. Kodeboniya. |
| Date: | February 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7117 |
|
RFCs 4761 and 4762 describe a solution for Virtual Private LANService (VPLS) multicast that relies on the use of point-to-point or multipoint-to-point unicast Label Switched Paths (LSPs) for carrying multicast traffic. This solution has certain limitations for certainVPLS multicast traffic profiles. For example, it may result in highly non-optimal bandwidth utilization when a large amount of multicast traffic is to be transported.
This document describes solutions for overcoming a subset of the limitations of the existing VPLS multicast solution. It describes procedures for VPLS multicast that utilize multicast trees in the service provider (SP) network. The solution described in this document allows sharing of one such multicast tree among multipleVPLS instances. Furthermore, the solution described in this document allows a single multicast tree in the SP network to carry traffic belonging only to a specified set of one or more IP multicast streams from one or more VPLS instances. |
|
| |
| RFC 7118 | The WebSocket Protocol as a Transport for the Session Initiation Protocol (SIP) |
| |
| Authors: | I. Baz Castillo, J. Millan Villegas, V. Pascual. |
| Date: | January 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7118 |
|
The WebSocket protocol enables two-way real-time communication between clients and servers in web-based applications. This document specifies a WebSocket subprotocol as a reliable transport mechanism between Session Initiation Protocol (SIP) entities to enable use ofSIP in web-oriented deployments. |
|
| |
| RFC 7119 | Operation of the IP Flow Information Export (IPFIX) Protocol on IPFIX Mediators |
| |
| Authors: | B. Claise, A. Kobayashi, B. Trammell. |
| Date: | February 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7119 |
|
This document specifies the operation of the IP Flow InformationExport (IPFIX) protocol specific to IPFIX Mediators, includingTemplate and Observation Point management, timing considerations, and other Mediator-specific concerns. |
|
| |
| RFC 7121 | High Availability within a Forwarding and Control Element Separation (ForCES) Network Element |
| |
| Authors: | K. Ogawa, W. Wang, E. Haleplidis, J. Hadi Salim. |
| Date: | February 2014 |
| Formats: | txt html json |
| Updates: | RFC 5810 |
| Updated by: | RFC 7391 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7121 |
|
This document discusses Control Element (CE) High Availability (HA) within a Forwarding and Control Element Separation (ForCES) NetworkElement (NE). Additionally, this document updates RFC 5810 by providing new normative text for the Cold Standby High Availability mechanism. |
|
| |
| RFC 7124 | Ethernet in the First Mile Copper (EFMCu) Interfaces MIB |
| |
|
|
This document updates RFC 5066. It amends that specification by informing the Internet community about the transition of theEFM-CU-MIB module from the concluded IETF Ethernet Interfaces and HubMIB Working Group to the Institute of Electrical and ElectronicsEngineers (IEEE) 802.3 working group. |
|
| |
| RFC 7130 | Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces |
| |
| Authors: | M. Bhatia, Ed., M. Chen, Ed., S. Boutros, Ed., M. Binderberger, Ed., J. Haas, Ed.. |
| Date: | February 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7130 |
|
This document defines a mechanism to run Bidirectional ForwardingDetection (BFD) on Link Aggregation Group (LAG) interfaces. It does so by running an independent Asynchronous mode BFD session on everyLAG member link.
This mechanism allows the verification of member link continuity, either in combination with, or in absence of, Link AggregationControl Protocol (LACP). It provides a shorter detection time than what LACP offers. The continuity check can also cover elements ofLayer 3 (L3) bidirectional forwarding. |
|
| |
| RFC 7133 | Information Elements for Data Link Layer Traffic Measurement |
| |
| Authors: | S. Kashima, A. Kobayashi, Ed., P. Aitken. |
| Date: | May 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7133 |
|
This document describes Information Elements related to the data link layer. They are used by the IP Flow Information Export (IPFIX) protocol for encoding measured data link layer traffic information. |
|
| |
| RFC 7134 | The Management Policy of the Resource Priority Header (RPH) Registry Changed to "IETF Review" |
| |
|
|
RFC 4412 defines the "Resource-Priority Namespaces" and "Resource-Priority Priority-values" registries. The management policy of these registries is "Standards Action". This document normatively updatesRFC 4412 to change the management policy of these registries to "IETFReview". |
|
| |
| RFC 7136 | Significance of IPv6 Interface Identifiers |
| |
| Authors: | B. Carpenter, S. Jiang. |
| Date: | February 2014 |
| Formats: | txt json html |
| Updates: | RFC 4291 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7136 |
|
The IPv6 addressing architecture includes a unicast interface identifier that is used in the creation of many IPv6 addresses.Interface identifiers are formed by a variety of methods. This document clarifies that the bits in an interface identifier have no meaning and that the entire identifier should be treated as an opaque value. In particular, RFC 4291 defines a method by which theUniversal and Group bits of an IEEE link-layer address are mapped into an IPv6 unicast interface identifier. This document clarifies that those two bits are significant only in the process of deriving interface identifiers from an IEEE link-layer address, and it updatesRFC 4291 accordingly. |
|
| |
| RFC 7138 | Traffic Engineering Extensions to OSPF for GMPLS Control of Evolving G.709 Optical Transport Networks |
| |
| Authors: | D. Ceccarelli, Ed., F. Zhang, S. Belotti, R. Rao, J. Drake. |
| Date: | March 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7138 |
|
This document describes Open Shortest Path First - TrafficEngineering (OSPF-TE) routing protocol extensions to support GMPLS control of Optical Transport Networks (OTNs) specified in ITU-TRecommendation G.709 as published in 2012. It extends mechanisms defined in RFC 4203. |
|
| |
| RFC 7139 | GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks |
| |
| Authors: | F. Zhang, Ed., G. Zhang, S. Belotti, D. Ceccarelli, K. Pithewan. |
| Date: | March 2014 |
| Formats: | txt html json |
| Updates: | RFC 4328 |
| Updated by: | RFC 7892 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7139 |
|
ITU-T Recommendation G.709 [G709-2012] introduced new Optical channelData Unit (ODU) containers (ODU0, ODU4, ODU2e, and ODUflex) and enhanced Optical Transport Network (OTN) flexibility.
This document updates the ODU-related portions of RFC 4328 to provide extensions to GMPLS signaling to control the full set of OTN features, including ODU0, ODU4, ODU2e, and ODUflex. |
|
| |
| RFC 7140 | LDP Extensions for Hub and Spoke Multipoint Label Switched Path |
| |
| Authors: | L. Jin, F. Jounay, IJ. Wijnands, N. Leymann. |
| Date: | March 2014 |
| Formats: | txt json html |
| Updated by: | RFC 7358 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7140 |
|
This document introduces a hub and spoke multipoint (HSMP) LabelSwitched Path (LSP), which allows traffic from root to leaf through point-to-multipoint (P2MP) LSPs and also leaf to root along the reverse path. That means traffic entering the HSMP LSP from the application/customer at the root node travels downstream to each leaf node, exactly as if it were traveling downstream along a P2MP LSP to each leaf node. Upstream traffic entering the HSMP LSP at any leaf node travels upstream along the tree to the root, as if it were unicast to the root. Direct communication among the leaf nodes is not allowed. |
|
| |
| RFC 7143 | Internet Small Computer System Interface (iSCSI) Protocol (Consolidated) |
| |
|
|
This document describes a transport protocol for SCSI that works on top of TCP. The iSCSI protocol aims to be fully compliant with the standardized SCSI Architecture Model (SAM-2). RFC 3720 defined the original iSCSI protocol. RFC 3721 discusses iSCSI naming examples and discovery techniques. Subsequently, RFC 3980 added an additional naming format to the iSCSI protocol. RFC 4850 followed up by adding a new public extension key to iSCSI. RFC 5048 offered a number of clarifications as well as a few improvements and corrections to the original iSCSI protocol.
This document obsoletes RFCs 3720, 3980, 4850, and 5048 by consolidating them into a single document and making additional updates to the consolidated specification. This document also updates RFC 3721. The text in this document thus supersedes the text in all the noted RFCs wherever there is a difference in semantics. |
|
| |
| RFC 7144 | Internet Small Computer System Interface (iSCSI) SCSI Features Update |
| |
| Authors: | F. Knight, M. Chadalapaka. |
| Date: | April 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7144 |
|
Internet Small Computer System Interface (iSCSI) is a SCSI transport protocol that maps the SCSI family of protocols ontoTCP/IP. The iSCSI protocol as specified in RFC 7143 (and as previously specified by the combination of RFC 3720 and RFC5048) is based on the SAM-2 (SCSI Architecture Model - 2) version of the SCSI family of protocols. This document defines enhancements to the iSCSI protocol to support certain additional features of the SCSI protocol that were defined inSAM-3, SAM-4, and SAM-5.
This document is a companion document to RFC 7143. |
|
| |
| RFC 7145 | Internet Small Computer System Interface (iSCSI) Extensions for the Remote Direct Memory Access (RDMA) Specification |
| |
|
|
Internet Small Computer System Interface (iSCSI) Extensions forRemote Direct Memory Access (RDMA) provides the RDMA data transfer capability to iSCSI by layering iSCSI on top of an RDMA-CapableProtocol. An RDMA-Capable Protocol provides RDMA Read and Write services, which enable data to be transferred directly into SCSI I/OBuffers without intermediate data copies. This document describes the extensions to the iSCSI protocol to support RDMA services as provided by an RDMA-Capable Protocol.
This document obsoletes RFC 5046. |
|
| |
| RFC 7146 | Securing Block Storage Protocols over IP: RFC 3723 Requirements Update for IPsec v3 |
| |
| Authors: | D. Black, P. Koning. |
| Date: | April 2014 |
| Formats: | txt html json |
| Updates: | RFC 3720, RFC 3723, RFC 3821, RFC 3822, RFC 4018, RFC 4172, RFC 4173, RFC 4174, RFC 5040, RFC 5041, RFC 5042, RFC 5043, RFC 5044, RFC 5045, RFC 5046, RFC 5047, RFC 5048 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7146 |
|
RFC 3723 specifies IPsec requirements for block storage protocols over IP (e.g., Internet Small Computer System Interface (iSCSI)) based on IPsec v2 (RFC 2401 and related RFCs); those requirements have subsequently been applied to remote direct data placement protocols, e.g., the Remote Direct Memory Access Protocol (RDMAP).This document updates RFC 3723's IPsec requirements to IPsec v3 (RFC4301 and related RFCs) and makes some changes to required algorithms based on developments in cryptography since RFC 3723 was published. |
|
| |
| RFC 7147 | Definitions of Managed Objects for the Internet Small Computer System Interface (iSCSI) |
| |
| Authors: | M. Bakke, P. Venkatesen. |
| Date: | April 2014 |
| Formats: | txt html json |
| Obsoletes: | RFC 4544 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7147 |
|
This document defines a portion of the Management Information Base(MIB) for use with network management protocols. In particular, it defines objects for managing a client using the Internet SmallComputer System Interface (iSCSI) protocol (SCSI over TCP).
This document obsoletes RFC 4544. |
|
| |
| RFC 7148 | Prefix Delegation Support for Proxy Mobile IPv6 |
| |
| Authors: | X. Zhou, J. Korhonen, C. Williams, S. Gundavelli, CJ. Bernardos. |
| Date: | March 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7148 |
|
This specification defines extensions to the Proxy Mobile IPv6 protocol for allowing a mobile router in a Proxy Mobile IPv6 domain to obtain IP prefixes for its attached mobile networks using DHCPv6 prefix delegation. Network-based mobility management support is provided for those delegated IP prefixes just as it is provided for the mobile node's home address. Even if the mobile router performs a handoff and changes its network point of attachment, mobility support is ensured for all the delegated IP prefixes and for all the IP nodes in the mobile network that use IP address configuration from those delegated IP prefixes. |
|
| |
| RFC 7150 | Conveying Vendor-Specific Constraints in the Path Computation Element Communication Protocol |
| |
| Authors: | F. Zhang, A. Farrel. |
| Date: | March 2014 |
| Formats: | txt json html |
| Obsoleted by: | RFC 7470 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7150 |
|
The Path Computation Element communication Protocol (PCEP) is used to convey path computation requests and responses both between PathComputation Clients (PCCs) and Path Computation Elements (PCEs) and between cooperating PCEs. In PCEP, the path computation requests carry details of the constraints and objective functions that the PCC wishes the PCE to apply in its computation.
This document defines a facility to carry vendor-specific information in PCEP using a dedicated object and a new Type-Length-Variable that can be carried in any existing PCEP object. |
|
| |
| RFC 7151 | File Transfer Protocol HOST Command for Virtual Hosts |
| |
|
|
The File Transfer Protocol, as defined in RFC 959, does not provide a way for FTP clients and servers to differentiate between multiple DNS names that are registered for a single IP address. This document defines a new FTP command that provides a mechanism for FTP clients and servers to identify individual virtual hosts on an FTP server. |
|
| |
| RFC 7153 | IANA Registries for BGP Extended Communities |
| |
|
|
This document reorganizes the IANA registries for the type values and sub-type values of the BGP Extended Communities attribute and the BGPIPv6-Address-Specific Extended Communities attribute. This is done in order to remove interdependencies among the registries, thus making it easier for IANA to determine which codepoints are available for assignment in which registries. This document also clarifies the information that must be provided to IANA when requesting an allocation from one or more of these registries. These changes are compatible with the existing allocations and thus do not affect protocol implementations. The changes will, however, impact the"IANA Considerations" sections of future protocol specifications.This document updates RFC 4360 and RFC 5701. |
|
| |
| RFC 7155 | Diameter Network Access Server Application |
| |
|
|
This document describes the Diameter protocol application used forAuthentication, Authorization, and Accounting services in the NetworkAccess Server (NAS) environment; it obsoletes RFC 4005. When combined with the Diameter Base protocol, Transport Profile, andExtensible Authentication Protocol specifications, this application specification satisfies typical network access services requirements. |
|
| |
| RFC 7156 | Diameter Support for Proxy Mobile IPv6 Localized Routing |
| |
| Authors: | G. Zorn, Q. Wu, J. Korhonen. |
| Date: | April 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7156 |
|
In Proxy Mobile IPv6, packets received from a Mobile Node (MN) by theMobile Access Gateway (MAG) to which it is attached are typically tunneled to a Local Mobility Anchor (LMA) for routing. The term"localized routing" refers to a method by which packets are routed directly between an MN's MAG and the MAG of its Correspondent Node(CN) without involving any LMA. In a Proxy Mobile IPv6 deployment, it may be desirable to control the establishment of localized routing sessions between two MAGs in a Proxy Mobile IPv6 domain by requiring that the session be authorized. This document specifies how to accomplish this using the Diameter protocol. |
|
| |
| RFC 7158 | The JavaScript Object Notation (JSON) Data Interchange Format |
| |
|
|
JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data.
This document removes inconsistencies with other specifications ofJSON, repairs specification errors, and offers experience-based interoperability guidance. |
|
| |
| RFC 7159 | The JavaScript Object Notation (JSON) Data Interchange Format |
| |
|
|
JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data.
This document removes inconsistencies with other specifications ofJSON, repairs specification errors, and offers experience-based interoperability guidance. |
|
| |
| RFC 7160 | Support for Multiple Clock Rates in an RTP Session |
| |
| Authors: | M. Petit-Huguenin, G. Zorn, Ed.. |
| Date: | April 2014 |
| Formats: | txt json html |
| Updates: | RFC 3550 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7160 |
|
This document clarifies the RTP specification regarding the use of different clock rates in an RTP session. It also provides guidance on how legacy RTP implementations that use multiple clock rates can interoperate with RTP implementations that use the algorithm described in this document. It updates RFC 3550. |
|
| |
| RFC 7162 | IMAP Extensions: Quick Flag Changes Resynchronization (CONDSTORE) and Quick Mailbox Resynchronization (QRESYNC) |
| |
|
|
Often, multiple IMAP (RFC 3501) clients need to coordinate changes to a common IMAP mailbox. Examples include different clients working on behalf of the same user and multiple users accessing shared mailboxes. These clients need a mechanism to efficiently synchronize state changes for messages within the mailbox.
Initially defined in RFC 4551, the Conditional Store facility provides a protected update mechanism for message state information and a mechanism for requesting only changes to the message state.This memo updates that mechanism and obsoletes RFC 4551, based on operational experience.
This document additionally updates another IMAP extension, QuickResynchronization, which builds on the Conditional STORE extension to provide an IMAP client the ability to fully resynchronize a mailbox as part of the SELECT/EXAMINE command, without the need for additional server-side state or client round trips. Hence, this memo obsoletes RFC 5162.
Finally, this document also updates the line-length recommendation inSection 3.2.1.5 of RFC 2683. |
|
| |
| RFC 7163 | URN for Country-Specific Emergency Services |
| |
| Authors: | C. Holmberg, I. Sedlacek. |
| Date: | March 2014 |
| Formats: | txt html json |
| Updates: | RFC 5031 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7163 |
|
This document updates the registration guidance provided in Section4.2 of RFC 5031, which allows the registration of service URNs with the 'sos' service type only for emergency services "that are offered widely and in different countries". This document updates those instructions to allow such registrations when, at the time of registration, those services are offered in only one country. |
|
| |
| RFC 7164 | RTP and Leap Seconds |
| |
| Authors: | K. Gross, R. Brandenburg. |
| Date: | March 2014 |
| Formats: | txt json html |
| Updates: | RFC 3550 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7164 |
|
This document discusses issues that arise when RTP sessions spanCoordinated Universal Time (UTC) leap seconds. It updates RFC 3550 by describing how RTP senders and receivers should behave in the presence of leap seconds. |
|
| |
| RFC 7166 | Supporting Authentication Trailer for OSPFv3 |
| |
| Authors: | M. Bhatia, V. Manral, A. Lindem. |
| Date: | March 2014 |
| Formats: | txt html json |
| Obsoletes: | RFC 6506 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7166 |
|
Currently, OSPF for IPv6 (OSPFv3) uses IPsec as the only mechanism for authenticating protocol packets. This behavior is different from authentication mechanisms present in other routing protocols (OSPFv2,Intermediate System to Intermediate System (IS-IS), RIP, and RoutingInformation Protocol Next Generation (RIPng)). In some environments, it has been found that IPsec is difficult to configure and maintain and thus cannot be used. This document defines an alternative mechanism to authenticate OSPFv3 protocol packets so that OSPFv3 does not depend only upon IPsec for authentication.
The OSPFv3 Authentication Trailer was originally defined in RFC 6506.This document obsoletes RFC 6506 by providing a revised definition, including clarifications and refinements of the procedures. |
|
| |
| RFC 7170 | Tunnel Extensible Authentication Protocol (TEAP) Version 1 |
| |
| Authors: | H. Zhou, N. Cam-Winget, J. Salowey, S. Hanna. |
| Date: | May 2014 |
| Formats: | txt json html |
| Updated by: | RFC 9427 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7170 |
|
This document defines the Tunnel Extensible Authentication Protocol(TEAP) version 1. TEAP is a tunnel-based EAP method that enables secure communication between a peer and a server by using theTransport Layer Security (TLS) protocol to establish a mutually authenticated tunnel. Within the tunnel, TLV objects are used to convey authentication-related data between the EAP peer and the EAP server. |
|
| |
| RFC 7171 | PT-EAP: Posture Transport (PT) Protocol for Extensible Authentication Protocol (EAP) Tunnel Methods |
| |
| Authors: | N. Cam-Winget, P. Sangster. |
| Date: | May 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7171 |
|
This document specifies PT-EAP, a Posture Transport (PT) protocol based on the Extensible Authentication Protocol (EAP) and designed to be used only inside an EAP tunnel method protected by Transport LayerSecurity (TLS). The document also describes the intended applicability of PT-EAP. |
|
| |
| RFC 7172 | Transparent Interconnection of Lots of Links (TRILL): Fine-Grained Labeling |
| |
| Authors: | D. Eastlake 3rd, M. Zhang, P. Agarwal, R. Perlman, D. Dutt. |
| Date: | May 2014 |
| Formats: | txt html json |
| Updates: | RFC 6325 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7172 |
|
The IETF has standardized Transparent Interconnection of Lots ofLinks (TRILL), a protocol for least-cost transparent frame routing in multi-hop networks with arbitrary topologies and link technologies, using link-state routing and a hop count. The TRILL base protocol standard supports the labeling of TRILL Data packets with up to 4KIDs. However, there are applications that require a larger number of labels providing configurable isolation of data. This document updates RFC 6325 by specifying optional extensions to the TRILL base protocol to safely accomplish this. These extensions, called fine- grained labeling, are primarily intended for use in large data centers, that is, those with more than 4K users requiring configurable data isolation from each other. |
|
| |
| RFC 7173 | Transparent Interconnection of Lots of Links (TRILL) Transport Using Pseudowires |
| |
| Authors: | L. Yong, D. Eastlake 3rd, S. Aldrin, J. Hudson. |
| Date: | May 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7173 |
|
This document specifies how to interconnect a pair of TransparentInterconnection of Lots of Links (TRILL) switch ports using pseudowires under existing TRILL and Pseudowire Emulation End-to-End(PWE3) standards. |
|
| |
| RFC 7175 | Transparent Interconnection of Lots of Links (TRILL): Bidirectional Forwarding Detection (BFD) Support |
| |
| Authors: | V. Manral, D. Eastlake 3rd, D. Ward, A. Banerjee. |
| Date: | May 2014 |
| Formats: | txt json html |
| Updated by: | RFC 8564 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7175 |
|
This document specifies use of the Bidirectional Forwarding Detection(BFD) protocol in Routing Bridge (RBridge) campuses based on theRBridge Channel extension to the Transparent Interconnection of Lots of Links (TRILL) protocol.
BFD is a widely deployed Operations, Administration, and Maintenance(OAM) mechanism in IP and MPLS networks, using UDP and AssociatedChannel Header (ACH) encapsulation respectively. This document specifies the BFD encapsulation over TRILL. |
|
| |
| RFC 7176 | Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS |
| |
| Authors: | D. Eastlake 3rd, T. Senevirathne, A. Ghanwani, D. Dutt, A. Banerjee. |
| Date: | May 2014 |
| Formats: | txt html json |
| Obsoletes: | RFC 6326 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7176 |
|
The IETF Transparent Interconnection of Lots of Links (TRILL) protocol provides optimal pair-wise data frame forwarding without configuration in multi-hop networks with arbitrary topology and link technology; it also provides support for multipathing of both unicast and multicast traffic. This document specifies the data formats and code points for the IS-IS extensions to support TRILL. These data formats and code points may also be used by technologies other thanTRILL. This document obsoletes RFC 6326. |
|
| |
| RFC 7177 | Transparent Interconnection of Lots of Links (TRILL): Adjacency |
| |
|
|
The IETF Transparent Interconnection of Lots of Links (TRILL) protocol supports arbitrary link technologies between TRILL switches, including point-to-point links and multi-access Local Area Network(LAN) links that can have multiple TRILL switches and end stations attached. TRILL uses Intermediate System to Intermediate System(IS-IS) routing. This document specifies the establishment, reporting, and termination of IS-IS adjacencies between TRILL switches, also known as RBridges (Routing Bridges). It also concerns four other link-local aspects of TRILL: Designated RBridge (DRB) selection, MTU (Maximum Transmission Unit) testing, pseudonode creation, and BFD (Bidirectional Forwarding Detection) session bootstrapping in connection with adjacency. State diagrams are included where appropriate. This document obsoletes RFC 6327 and updates RFC 6325. |
|
| |
| RFC 7178 | Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Support |
| |
| Authors: | D. Eastlake 3rd, V. Manral, Y. Li, S. Aldrin, D. Ward. |
| Date: | May 2014 |
| Formats: | txt json html |
| Updated by: | RFC 7978 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7178 |
|
This document specifies a general channel mechanism for sending messages, such as Bidirectional Forwarding Detection (BFD) messages, between Routing Bridges (RBridges) and between RBridges and end stations in an RBridge campus through extensions to the TransparentInterconnection of Lots of Links (TRILL) protocol. |
|
| |
| RFC 7179 | Transparent Interconnection of Lots of Links (TRILL): Header Extension |
| |
| Authors: | D. Eastlake 3rd, A. Ghanwani, V. Manral, Y. Li, C. Bestler. |
| Date: | May 2014 |
| Formats: | txt json html |
| Updates: | RFC 6325 |
| Updated by: | RFC 7780 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7179 |
|
The IETF Transparent Interconnection of Lots of Links (TRILL) base protocol (RFC 6325) specifies minimal hooks to safely support TRILLHeader extensions. This document specifies an initial extension providing additional flag bits and specifies some of those bits. It updates RFC 6325. |
|
| |
| RFC 7180 | Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates |
| |
|
|
The IETF Transparent Interconnection of Lots of Links (TRILL) protocol provides least-cost pair-wise data forwarding without configuration in multi-hop networks with arbitrary topology and link technology, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic.TRILL accomplishes this by using Intermediate System to IntermediateSystem (IS-IS) link-state routing and by encapsulating traffic using a header that includes a hop count. Since publication of the TRILL base protocol in July 2011, active development of TRILL has revealed errata in RFC 6325 and some cases that could use clarifications or updates.
RFCs 6327 and 6439 provide clarifications and updates with respect to adjacency and Appointed Forwarders. This document provides other known clarifications, corrections, and updates to RFCs 6325, 6327, and 6439. |
|
| |
| RFC 7181 | The Optimized Link State Routing Protocol Version 2 |
| |
|
|
This specification describes version 2 of the Optimized Link StateRouting Protocol (OLSRv2) for Mobile Ad Hoc Networks (MANETs). |
|
| |
| RFC 7182 | Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs) |
| |
| Authors: | U. Herberg, T. Clausen, C. Dearlove. |
| Date: | April 2014 |
| Formats: | txt html json |
| Obsoletes: | RFC 6622 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7182 |
|
This document revises, extends, and replaces RFC 6622. It describes general and flexible TLVs for representing cryptographic IntegrityCheck Values (ICVs) and timestamps, using the generalized Mobile AdHoc Network (MANET) packet/message format defined in RFC 5444. It defines two Packet TLVs, two Message TLVs, and two Address Block TLVs for affixing ICVs and timestamps to a packet, a message, and one or more addresses, respectively. |
|
| |
| RFC 7183 | Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and Optimized Link State Routing Protocol Version 2 (OLSRv2) |
| |
|
|
This document specifies integrity and replay protection for theMobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP) and the Optimized Link State Routing Protocol version 2 (OLSRv2).This protection is achieved by using an HMAC-SHA-256 Integrity CheckValue (ICV) TLV and a Timestamp TLV based on Portable OperatingSystem Interface (POSIX) time.
The mechanism in this specification can also be used for other protocols that use the generalized packet/message format described inRFC 5444.
This document updates RFC 6130 and RFC 7181 by mandating the implementation of this integrity and replay protection in NHDP andOLSRv2. |
|
| |
| RFC 7184 | Definition of Managed Objects for the Optimized Link State Routing Protocol Version 2 |
| |
| Authors: | U. Herberg, R. Cole, T. Clausen. |
| Date: | April 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7184 |
|
This document defines the Management Information Base (MIB) module for configuring and managing the Optimized Link State RoutingProtocol version 2 (OLSRv2). The OLSRv2-MIB module is structured into configuration information, state information, performance information, and notifications. This additional state and performance information is useful for troubleshooting problems and performance issues of the routing protocol. Two levels of compliance allow this MIB module to be deployed on constrained routers. |
|
| |
| RFC 7187 | Routing Multipoint Relay Optimization for the Optimized Link State Routing Protocol Version 2 (OLSRv2) |
| |
|
|
This specification updates the Optimized Link State Routing Protocol version 2 (OLSRv2) with an optimization to improve the selection of routing multipoint relays. The optimization retains full interoperability between implementations of OLSRv2 with and without this optimization. |
|
| |
| RFC 7188 | Optimized Link State Routing Protocol Version 2 (OLSRv2) and MANET Neighborhood Discovery Protocol (NHDP) Extension TLVs |
| |
|
|
This specification describes extensions to definitions of TLVs used by the Optimized Link State Routing Protocol version 2 (OLSRv2) and the MANET Neighborhood Discovery Protocol (NHDP) to increase their abilities to accommodate protocol extensions. This document updatesRFC 7181 (OLSRv2) and RFC 6130 (NHDP). |
|
| |
| RFC 7189 | Virtual Circuit Connectivity Verification (VCCV) Capability Advertisement for MPLS Transport Profile (MPLS-TP) |
| |
| Authors: | G. Mirsky. |
| Date: | March 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7189 |
|
This document specifies how signaling and selection processes forPseudowire (PW) Virtual Circuit Connectivity Verification (VCCV) are modified to ensure backward compatibility and allow use of proactiveConnectivity Verification (CV), Continuity Check (CC), and RemoteDefect Indication (RDI) over MPLS Transport Profile (MPLS-TP) PWs.This document introduces four new CV types and, to accommodate them, a new VCCV Extended CV parameter for PW Interface Parameters Sub-TLV is defined. |
|
| |
| RFC 7191 | Cryptographic Message Syntax (CMS) Key Package Receipt and Error Content Types |
| |
| Authors: | R. Housley. |
| Date: | April 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7191 |
|
This document defines the syntax for two Cryptographic Message Syntax(CMS) content types: one for key package receipts and another for key package errors. The key package receipt content type is used to confirm receipt of an identified key package or collection of key packages. The key package error content type is used to indicate an error occurred during the processing of a key package. CMS can be used to digitally sign, digest, authenticate, or encrypt these content types. |
|
| |
| RFC 7192 | Algorithms for Cryptographic Message Syntax (CMS) Key Package Receipt and Error Content Types |
| |
| Authors: | S. Turner. |
| Date: | April 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7192 |
|
This document describes the conventions for using several cryptographic algorithms with the Cryptographic Message Syntax (CMS) key package receipt and error content types. Specifically, it includes conventions necessary to implement SignedData,EnvelopedData, EncryptedData, and AuthEnvelopedData. |
|
| |
| RFC 7195 | Session Description Protocol (SDP) Extension for Setting Audio and Video Media Streams over Circuit-Switched Bearers in the Public Switched Telephone Network (PSTN) |
| |
| Authors: | M. Garcia-Martin, S. Veikkolainen. |
| Date: | May 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7195 |
|
This memo describes use cases, requirements, and protocol extensions for using the Session Description Protocol (SDP) offer/answer model for establishing audio and video media streams over circuit-switched bearers in the Public Switched Telephone Network (PSTN). |
|
| |
| RFC 7196 | Making Route Flap Damping Usable |
| |
| Authors: | C. Pelsser, R. Bush, K. Patel, P. Mohapatra, O. Maennel. |
| Date: | May 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7196 |
|
Route Flap Damping (RFD) was first proposed to reduce BGP churn in routers. Unfortunately, RFD was found to severely penalize sites for being well connected because topological richness amplifies the number of update messages exchanged. Many operators have turned RFD off. Based on experimental measurement, this document recommends adjusting a few RFD algorithmic constants and limits in order to reduce the high risks with RFD. The result is damping a non-trivial amount of long-term churn without penalizing well-behaved prefixes' normal convergence process. |
|
| |
| RFC 7197 | Duplication Delay Attribute in the Session Description Protocol |
| |
| Authors: | A. Begen, Y. Cai, H. Ou. |
| Date: | April 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7197 |
|
A straightforward approach to provide protection against packet losses due to network outages with a longest duration of T time units is to duplicate the original packets and send each copy separated in time by at least T time units. This approach is commonly referred to as "time-shifted redundancy", "temporal redundancy", or simply"delayed duplication". This document defines an attribute to indicate the presence of temporally redundant media streams and the duplication delay in the Session Description Protocol. |
|
| |
| RFC 7198 | Duplicating RTP Streams |
| |
| Authors: | A. Begen, C. Perkins. |
| Date: | April 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7198 |
|
Packet loss is undesirable for real-time multimedia sessions but can occur due to a variety of reasons including unplanned network outages. In unicast transmissions, recovering from such an outage can be difficult depending on the outage duration, due to the potentially large number of missing packets. In multicast transmissions, recovery is even more challenging as many receivers could be impacted by the outage. For this challenge, one solution that does not incur unbounded delay is to duplicate the packets and send them in separate redundant streams, provided that the underlying network satisfies certain requirements. This document explains howReal-time Transport Protocol (RTP) streams can be duplicated without breaking RTP or RTP Control Protocol (RTCP) rules. |
|
| |
| RFC 7199 | Location Configuration Extensions for Policy Management |
| |
| Authors: | R. Barnes, M. Thomson, J. Winterbottom, H. Tschofenig. |
| Date: | April 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7199 |
|
Current location configuration protocols are capable of provisioning an Internet host with a location URI that refers to the host's location. These protocols lack a mechanism for the target host to inspect or set the privacy rules that are applied to the URIs they distribute. This document extends the current location configuration protocols to provide hosts with a reference to the rules that are applied to a URI so that the host can view or set these rules. |
|
| |
| RFC 7200 | A Session Initiation Protocol (SIP) Load-Control Event Package |
| |
| Authors: | C. Shen, H. Schulzrinne, A. Koike. |
| Date: | April 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7200 |
|
This specification defines a load-control event package for theSession Initiation Protocol (SIP). It allows SIP entities to distribute load-filtering policies to other SIP entities in the network. The load-filtering policies contain rules to throttle calls from a specific user or based on their source or destination domain, telephone number prefix. The mechanism helps to prevent signaling overload and complements feedback-based SIP overload control efforts. |
|
| |
| RFC 7203 | An Incident Object Description Exchange Format (IODEF) Extension for Structured Cybersecurity Information |
| |
| Authors: | T. Takahashi, K. Landfield, Y. Kadobayashi. |
| Date: | April 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7203 |
|
This document extends the Incident Object Description Exchange Format(IODEF) defined in RFC 5070 to exchange enriched cybersecurity information among security experts at organizations and facilitate their operations. It provides a well-defined pattern to consistently embed structured information, such as identifier- and XML-based information. |
|
| |
| RFC 7208 | Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1 |
| |
|
|
Email on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction on what a sending host can use as the "MAIL FROM" of a message or the domain given on the SMTP HELO/EHLO commands. This document describes version 1 of the Sender Policy Framework (SPF) protocol, whereby ADministrativeManagement Domains (ADMDs) can explicitly authorize the hosts that are allowed to use their domain names, and a receiving host can check such authorization.
This document obsoletes RFC 4408. |
|
| |
| RFC 7210 | Database of Long-Lived Symmetric Cryptographic Keys |
| |
| Authors: | R. Housley, T. Polk, S. Hartman, D. Zhang. |
| Date: | April 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7210 |
|
This document specifies the information contained in a conceptual database of long-lived cryptographic keys used by many different routing protocols for message security. The database is designed to support both manual and automated key management. In addition to describing the schema for the database, this document describes the operations that can be performed on the database as well as the requirements for the routing protocols that wish to use the database.In many typical scenarios, the protocols do not directly use the long-lived key, but rather a key derivation function is used to derive a short-lived key from a long-lived key. |
|
| |
| RFC 7212 | MPLS Generic Associated Channel (G-ACh) Advertisement Protocol |
| |
| Authors: | D. Frost, S. Bryant, M. Bocci. |
| Date: | June 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7212 |
|
The MPLS Generic Associated Channel (G-ACh) provides an auxiliary logical data channel associated with a Label Switched Path (LSP), a pseudowire, or a section (link) over which a variety of protocols may flow. These protocols are commonly used to provide Operations,Administration, and Maintenance (OAM) mechanisms associated with the primary data channel. This document specifies simple procedures by which an endpoint of an LSP, pseudowire, or section may inform the other endpoints of its capabilities and configuration parameters, or other application-specific information. This information may then be used by the receiver to validate or adjust its local configuration, and by the network operator for diagnostic purposes. |
|
| |
| RFC 7213 | MPLS Transport Profile (MPLS-TP) Next-Hop Ethernet Addressing |
| |
| Authors: | D. Frost, S. Bryant, M. Bocci. |
| Date: | June 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7213 |
|
The MPLS Transport Profile (MPLS-TP) is the set of MPLS protocol functions applicable to the construction and operation of packet- switched transport networks. This document presents considerations for link-layer addressing of Ethernet frames carrying MPLS-TP packets. |
|
| |
| RFC 7214 | Moving Generic Associated Channel (G-ACh) IANA Registries to a New Registry |
| |
|
|
RFC 5586 generalized the applicability of the pseudowire AssociatedChannel Header (PW-ACH) into the Generic Associated Channel G-ACh.However, registries and allocations of G-ACh parameters had been distributed throughout different, sometimes unrelated, registries.This document coalesces these into a new "Generic Associated Channel(G-ACh) Parameters" registry under the "Multiprotocol Label SwitchingArchitecture (MPLS)" heading. This document updates RFC 5586.
This document also updates RFCs 6374, 6378, 6427, and 6428. |
|
| |
| RFC 7216 | Location Information Server (LIS) Discovery Using IP Addresses and Reverse DNS |
| |
| Authors: | M. Thomson, R. Bellis. |
| Date: | April 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7216 |
|
The residential gateway is a device that has become an integral part of home networking equipment. Discovering a Location InformationServer (LIS) is a necessary part of acquiring location information for location-based services. However, discovering a LIS when a residential gateway is present poses a configuration challenge, requiring a method that is able to work around the obstacle presented by the gateway.
This document describes a solution to this problem. The solution provides alternative domain names as input to the LIS discovery process based on the network addresses assigned to a Device. |
|
| |
| RFC 7217 | A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC) |
| |
| Authors: | F. Gont. |
| Date: | April 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7217 |
|
This document specifies a method for generating IPv6 InterfaceIdentifiers to be used with IPv6 Stateless Address Autoconfiguration(SLAAC), such that an IPv6 address configured using this method is stable within each subnet, but the corresponding Interface Identifier changes when the host moves from one network to another. This method is meant to be an alternative to generating Interface Identifiers based on hardware addresses (e.g., IEEE LAN Media Access Control(MAC) addresses), such that the benefits of stable addresses can be achieved without sacrificing the security and privacy of users. The method specified in this document applies to all prefixes a host may be employing, including link-local, global, and unique-local prefixes(and their corresponding addresses). |
|
| |
| RFC 7218 | Adding Acronyms to Simplify Conversations about DNS-Based Authentication of Named Entities (DANE) |
| |
|
|
Experience has shown that people get confused when discussing the three numeric fields of the TLSA record. This document specifies descriptive acronyms for the three numeric fields in TLSA records.This document updates the format of the IANA registry created by RFC6698. |
|
| |
| RFC 7219 | SEcure Neighbor Discovery (SEND) Source Address Validation Improvement (SAVI) |
| |
| Authors: | M. Bagnulo, A. Garcia-Martinez. |
| Date: | May 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7219 |
|
This memo specifies SEcure Neighbor Discovery (SEND) Source AddressValidation Improvement (SAVI), a mechanism to provide source address validation using the SEND protocol. The proposed mechanism complements ingress filtering techniques to provide a finer granularity on the control of IPv6 source addresses. |
|
| |
| RFC 7220 | Description Option for the Port Control Protocol (PCP) |
| |
| Authors: | M. Boucadair, R. Penno, D. Wing. |
| Date: | May 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7220 |
|
This document extends the Port Control Protocol (PCP) with the ability to associate a description with a PCP-instantiated mapping.It does this by defining a new DESCRIPTION option. |
|
| |
| RFC 7222 | Quality-of-Service Option for Proxy Mobile IPv6 |
| |
| Authors: | M. Liebsch, P. Seite, H. Yokota, J. Korhonen, S. Gundavelli. |
| Date: | May 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7222 |
|
This specification defines a new mobility option, the Quality-of-Service (QoS) option, for Proxy Mobile IPv6. This option can be used by the local mobility anchor and the mobile access gateway for negotiating Quality-of-Service parameters for a mobile node's IP flows. The negotiated QoS parameters can be used for QoS policing and marking of packets to enforce QoS differentiation on the path between the local mobility anchor and the mobile access gateway.Furthermore, making QoS parameters available on the mobile access gateway enables mapping of these parameters to QoS rules that are specific to the access technology and allows those rules to be enforced on the access network using access-technology-specific approaches. |
|
| |
| RFC 7223 | A YANG Data Model for Interface Management |
| |
|
|
This document defines a YANG data model for the management of network interfaces. It is expected that interface-type-specific data models augment the generic interfaces data model defined in this document.The data model includes configuration data and state data (status information and counters for the collection of statistics). |
|
| |
| RFC 7224 | IANA Interface Type YANG Module |
| |
| Authors: | M. Bjorklund. |
| Date: | May 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7224 |
|
This document defines the initial version of the iana-if-type YANG module. |
|
| |
| RFC 7225 | Discovering NAT64 IPv6 Prefixes Using the Port Control Protocol (PCP) |
| |
| Authors: | M. Boucadair. |
| Date: | May 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7225 |
|
This document defines a new Port Control Protocol (PCP) option to learn the IPv6 prefix(es) used by a PCP-controlled NAT64 device to build IPv4-converted IPv6 addresses. This option is needed for successful communications when IPv4 addresses are used in referrals. |
|
| |
| RFC 7230 | Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing |
| |
|
|
The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypertext information systems. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" UniformResource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations. |
|
| |
| RFC 7231 | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content |
| |
|
|
The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation. |
|
| |
| RFC 7232 | Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests |
| |
|
|
The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP/1.1 conditional requests, including metadata header fields for indicating state changes, request header fields for making preconditions on such state, and rules for constructing the responses to a conditional request when one or more preconditions evaluate to false. |
|
| |
| RFC 7233 | Hypertext Transfer Protocol (HTTP/1.1): Range Requests |
| |
| Authors: | R. Fielding, Ed., Y. Lafon, Ed., J. Reschke, Ed.. |
| Date: | June 2014 |
| Formats: | txt html json |
| Obsoletes: | RFC 2616 |
| Obsoleted by: | RFC 9110 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7233 |
|
The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypertext information systems. This document defines range requests and the rules for constructing and combining responses to those requests. |
|
| |
| RFC 7234 | Hypertext Transfer Protocol (HTTP/1.1): Caching |
| |
| Authors: | R. Fielding, Ed., M. Nottingham, Ed., J. Reschke, Ed.. |
| Date: | June 2014 |
| Formats: | txt json html |
| Obsoletes: | RFC 2616 |
| Obsoleted by: | RFC 9111 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7234 |
|
The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages. |
|
| |
| RFC 7235 | Hypertext Transfer Protocol (HTTP/1.1): Authentication |
| |
|
|
The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypermedia information systems. This document defines the HTTP Authentication framework. |
|
| |
| RFC 7239 | Forwarded HTTP Extension |
| |
| Authors: | A. Petersson, M. Nilsson. |
| Date: | June 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7239 |
|
This document defines an HTTP extension header field that allows proxy components to disclose information lost in the proxying process, for example, the originating IP address of a request or IP address of the proxy on the user-agent-facing interface. In a path of proxying components, this makes it possible to arrange it so that each subsequent component will have access to, for example, all IP addresses used in the chain of proxied HTTP requests.
This document also specifies guidelines for a proxy administrator to anonymize the origin of a request. |
|
| |
| RFC 7240 | Prefer Header for HTTP |
| |
|
|
This specification defines an HTTP header field that can be used by a client to request that certain behaviors be employed by a server while processing a request. |
|
| |
| RFC 7243 | RTP Control Protocol (RTCP) Extended Report (XR) Block for the Bytes Discarded Metric |
| |
| Authors: | V. Singh, Ed., J. Ott, I. Curcio. |
| Date: | May 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7243 |
|
The RTP Control Protocol (RTCP) is used in conjunction with the Real- time Transport Protocol (RTP) to provide a variety of short-term and long-term reception statistics. The available reporting may include aggregate information across longer periods of time as well as individual packet reporting. This document specifies a report computing the bytes discarded from the de-jitter buffer after successful reception. |
|
| |
| RFC 7244 | RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Synchronization Delay and Offset Metrics Reporting |
| |
| Authors: | H. Asaeda, Q. Wu, R. Huang. |
| Date: | May 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7244 |
|
This document defines two RTP Control Protocol (RTCP) Extended Report(XR) blocks that allow the reporting of initial synchronization delay and synchronization offset metrics for use in a range of RTP applications. |
|
| |
| RFC 7246 | Multipoint Label Distribution Protocol In-Band Signaling in a Virtual Routing and Forwarding (VRF) Table Context |
| |
| Authors: | IJ. Wijnands, Ed., P. Hitchen, N. Leymann, W. Henderickx, A. Gulko, J. Tantsura. |
| Date: | June 2014 |
| Formats: | txt json html |
| Updated by: | RFC 7438 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7246 |
|
An IP Multicast Distribution Tree (MDT) may traverse both label switching (i.e., Multiprotocol Label Switching, or MPLS) and non- label switching regions of a network. Typically, the MDT begins and ends in non-MPLS regions, but travels through an MPLS region. In such cases, it can be useful to begin building the MDT as a pure IPMDT, then convert it to an MPLS Multipoint Label Switched Path(MP-LSP) when it enters an MPLS-enabled region, and then convert it back to a pure IP MDT when it enters a non-MPLS-enabled region.Other documents specify the procedures for building such a hybridMDT, using Protocol Independent Multicast (PIM) in the non-MPLS region of the network, and using Multipoint Label DistributionProtocol (mLDP) in the MPLS region. This document extends those procedures to handle the case where the link connecting the two regions is a Virtual Routing and Forwarding (VRF) table link, as defined in the "BGP IP/MPLS VPN" specification. However, this document is primarily aimed at particular use cases where VRFs are used to support multicast applications other than multicast VPN. |
|
| |
| RFC 7247 | Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Architecture, Addresses, and Error Handling |
| |
| Authors: | P. Saint-Andre, A. Houri, J. Hildebrand. |
| Date: | May 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7247 |
|
As a foundation for the definition of bidirectional protocol mappings between the Session Initiation Protocol (SIP) and the ExtensibleMessaging and Presence Protocol (XMPP), this document specifies the architectural assumptions underlying such mappings as well as the mapping of addresses and error conditions. |
|
| |
| RFC 7248 | Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Presence |
| |
| Authors: | P. Saint-Andre, A. Houri, J. Hildebrand. |
| Date: | May 2014 |
| Formats: | txt html json |
| Obsoleted by: | RFC 8048 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7248 |
|
This document defines a bidirectional protocol mapping for the exchange of presence information between the Session InitiationProtocol (SIP) and the Extensible Messaging and Presence Protocol(XMPP). |
|
| |
| RFC 7250 | Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) |
| |
| Authors: | P. Wouters, Ed., H. Tschofenig, Ed., J. Gilmore, S. Weiler, T. Kivinen. |
| Date: | June 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7250 |
|
This document specifies a new certificate type and two TLS extensions for exchanging raw public keys in Transport Layer Security (TLS) andDatagram Transport Layer Security (DTLS). The new certificate type allows raw public keys to be used for authentication. |
|
| |
| RFC 7252 | The Constrained Application Protocol (CoAP) |
| |
|
|
The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained(e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks(6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation.
CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs andInternet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments. |
|
| |
| RFC 7256 | Multicast Control Extensions for the Access Node Control Protocol (ANCP) |
| |
| Authors: | F. Le Faucheur, R. Maglione, T. Taylor. |
| Date: | July 2014 |
| Formats: | txt json html |
| Updates: | RFC 6320 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7256 |
|
This document specifies the extensions to the Access Node ControlProtocol (ANCP) (RFC 6320) required for support of the multicast use cases defined in the Access Node Control Protocol framework document(RFC 5851) and one additional use case described in this document.These use cases are organized into the following ANCP capabilities: o multicast replication initiated by the Network Access Server(NAS); o conditional access and admission control with white and black lists; o conditional access and admission control with grey lists; o bandwidth delegation; and o committed bandwidth reporting.
These capabilities may be combined according to the rules given in this specification.
This document updates RFC 6320 by assigning capability type 3 to a capability specified in this document and by changing the starting point for IANA allocation of result codes determined by IETFConsensus from 0x100 to 0x64. |
|
| |
| RFC 7257 | Virtual Private LAN Service (VPLS) Management Information Base |
| |
| Authors: | T. Nadeau, Ed., A. Kiran Koushik, Ed., R. Mediratta, Ed.. |
| Date: | July 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7257 |
|
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 Virtual Private LAN services. It needs to be used in conjunction with the Pseudowire (PW) Management Information Base(PW-STD-MIB from RFC 5601). |
|
| |
| RFC 7260 | GMPLS RSVP-TE Extensions for Operations, Administration, and Maintenance (OAM) Configuration |
| |
| Authors: | A. Takacs, D. Fedyk, J. He. |
| Date: | June 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7260 |
|
Operations, Administration, and Maintenance (OAM) is an integral part of transport connections; hence, it is required that OAM functions be activated/deactivated in sync with connection commissioning/ decommissioning, in order to avoid spurious alarms and ensure consistent operation. In certain technologies, OAM entities are inherently established once the connection is set up, while other technologies require extra configuration to establish and configureOAM entities. This document specifies extensions to ResourceReservation Protocol - Traffic Engineering (RSVP-TE) to support the establishment and configuration of OAM entities along with LabelSwitched Path signaling. |
|
| |
| RFC 7261 | Offer/Answer Considerations for G723 Annex A and G729 Annex B |
| |
| Authors: | M. Perumal, P. Ravindran. |
| Date: | May 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7261 |
|
This document provides the offer/answer considerations for the annexa parameter of G723 and the annexb parameter of G729, G729D, and G729E when the value of the annexa or annexb parameter does not match in the Session Description Protocol (SDP) offer and answer. |
|
| |
| RFC 7263 | An Extension to the REsource LOcation And Discovery (RELOAD) Protocol to Support Direct Response Routing |
| |
| Authors: | N. Zong, X. Jiang, R. Even, Y. Zhang. |
| Date: | June 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7263 |
|
This document defines an optional extension to the REsource LOcationAnd Discovery (RELOAD) protocol to support the direct response routing mode. RELOAD recommends symmetric recursive routing for routing messages. The new optional extension provides a shorter route for responses, thereby reducing overhead on intermediate peers.This document also describes potential cases where this extension can be used. |
|
| |
| RFC 7264 | An Extension to the REsource LOcation And Discovery (RELOAD) Protocol to Support Relay Peer Routing |
| |
| Authors: | N. Zong, X. Jiang, R. Even, Y. Zhang. |
| Date: | June 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7264 |
|
This document defines an optional extension to the REsource LOcationAnd Discovery (RELOAD) protocol to support the relay peer routing mode. RELOAD recommends symmetric recursive routing for routing messages. The new optional extension provides a shorter route for responses, thereby reducing overhead on intermediate peers. This document also describes potential cases where this extension can be used. |
|
| |
| RFC 7265 | jCal: The JSON Format for iCalendar |
| |
| Authors: | P. Kewisch, C. Daboo, M. Douglass. |
| Date: | May 2014 |
| Formats: | txt html json |
| Updated by: | RFC 7529 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7265 |
|
This specification defines "jCal", a JSON format for iCalendar data.The iCalendar data format is a text format for capturing and exchanging information normally stored within a calendaring and scheduling application, for example, tasks and events. JSON is a lightweight, text-based, language-independent data interchange format commonly used in Internet applications. |
|
| |
| RFC 7266 | RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Mean Opinion Score (MOS) Metric Reporting |
| |
| Authors: | A. Clark, Q. Wu, R. Schott, G. Zorn. |
| Date: | June 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7266 |
|
This document defines an RTP Control Protocol (RTCP) Extended Report(XR) Block including two new segment types and associated SessionDescription Protocol (SDP) parameters that allow the reporting of mean opinion score (MOS) Metrics for use in a range of RTP applications. |
|
| |
| RFC 7267 | Dynamic Placement of Multi-Segment Pseudowires |
| |
| Authors: | L. Martini, Ed., M. Bocci, Ed., F. Balus, Ed.. |
| Date: | June 2014 |
| Formats: | txt json html |
| Updates: | RFC 6073 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7267 |
|
RFC 5254 describes the service provider requirements for extending the reach of pseudowires (PWs) across multiple Packet SwitchedNetwork domains. A multi-segment PW is defined as a set of two or more contiguous PW segments that behave and function as a single point-to-point PW. This document describes extensions to the PW control protocol to dynamically place the segments of the multi- segment pseudowire among a set of Provider Edge (PE) routers. This document also updates RFC 6073 by updating the value of the Length field of the PW Switching Point PE Sub-TLV Type 0x06 to 14. |
|
| |
| RFC 7268 | RADIUS Attributes for IEEE 802 Networks |
| |
|
|
RFC 3580 provides guidelines for the use of the Remote AuthenticationDial-In User Service (RADIUS) within IEEE 802 local area networks(LANs). This document defines additional attributes for use withinIEEE 802 networks and clarifies the usage of the EAP-Key-NameAttribute and the Called-Station-Id Attribute. This document updatesRFCs 3580 and 4072. |
|
| |
| RFC 7271 | MPLS Transport Profile (MPLS-TP) Linear Protection to Match the Operational Expectations of Synchronous Digital Hierarchy, Optical Transport Network, and Ethernet Transport Network Operators |
| |
| Authors: | J. Ryoo, Ed., E. Gray, Ed., H. van Helvoort, A. D'Alessandro, T. Cheung, E. Osborne. |
| Date: | June 2014 |
| Formats: | txt html json |
| Updates: | RFC 6378 |
| Updated by: | RFC 8234 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7271 |
|
This document describes alternate mechanisms to perform some of the functions of MPLS Transport Profile (MPLS-TP) linear protection defined in RFC 6378, and also defines additional mechanisms. The purpose of these alternate and additional mechanisms is to provide operator control and experience that more closely models the behavior of linear protection seen in other transport networks.
This document also introduces capabilities and modes for linear protection. A capability is an individual behavior, and a mode is a particular combination of capabilities. Two modes are defined in this document: Protection State Coordination (PSC) mode and AutomaticProtection Switching (APS) mode.
This document describes the behavior of the PSC protocol including priority logic and state machine when all the capabilities associated with the APS mode are enabled.
This document updates RFC 6378 in that the capability advertisement method defined here is an addition to that document. |
|
| |
| RFC 7272 | Inter-Destination Media Synchronization (IDMS) Using the RTP Control Protocol (RTCP) |
| |
| Authors: | R. van Brandenburg, H. Stokking, O. van Deventer, F. Boronat, M. Montagud, K. Gross. |
| Date: | June 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7272 |
|
This document defines a new RTP Control Protocol (RTCP) Packet Type and an RTCP Extended Report (XR) Block Type to be used for achievingInter-Destination Media Synchronization (IDMS). IDMS is the process of synchronizing playout across multiple media receivers. Using theRTCP XR IDMS Report Block defined in this document, media playout information from participants in a synchronization group can be collected. Based on the collected information, an RTCP IDMS SettingsPacket can then be sent to distribute a common target playout point to which all the distributed receivers, sharing a media experience, can synchronize.
Typical use cases in which IDMS is useful are social TV, shared service control (i.e., applications where two or more geographically separated users are watching a media stream together), distance learning, networked video walls, networked loudspeakers, etc. |
|
| |
| RFC 7273 | RTP Clock Source Signalling |
| |
| Authors: | A. Williams, K. Gross, R. van Brandenburg, H. Stokking. |
| Date: | June 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7273 |
|
NTP format timestamps are used by several RTP protocols for synchronisation and statistical measurements. This memo specifiesSession Description Protocol (SDP) signalling that identifies timestamp reference clock sources and SDP signalling that identifies the media clock sources in a multimedia session. |
|
| |
| RFC 7274 | Allocating and Retiring Special-Purpose MPLS Labels |
| |
| Authors: | K. Kompella, L. Andersson, A. Farrel. |
| Date: | June 2014 |
| Formats: | txt html json |
| Updates: | RFC 3032, RFC 3038, RFC 3209, RFC 3811, RFC 4182, RFC 4928, RFC 5331, RFC 5586, RFC 5921, RFC 5960, RFC 6391, RFC 6478, RFC 6790 |
| Updated by: | RFC 9017 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7274 |
|
Some MPLS labels have been allocated for specific purposes. A block of labels (0-15) has been set aside to this end; these labels are commonly called "reserved labels". They will be called "special- purpose labels" in this document.
As there are only 16 of these special-purpose labels, caution is needed in the allocation of new special-purpose labels; yet, at the same time, forward progress should be allowed when one is called for.
This memo defines new procedures for the allocation and retirement of special-purpose labels, as well as a method to extend the special- purpose label space and a description of how to handle extended special-purpose labels in the data plane. Finally, this memo renames the IANA registry for special-purpose labels to "Special-Purpose MPLSLabel Values" and creates a new registry called the "ExtendedSpecial-Purpose MPLS Label Values" registry.
This document updates a number of previous RFCs that use the term"reserved label". Specifically, this document updates RFCs 3032,3038, 3209, 3811, 4182, 4928, 5331, 5586, 5921, 5960, 6391, 6478, and6790. |
|
| |
| RFC 7275 | Inter-Chassis Communication Protocol for Layer 2 Virtual Private Network (L2VPN) Provider Edge (PE) Redundancy |
| |
| Authors: | L. Martini, S. Salam, A. Sajassi, M. Bocci, S. Matsushima, T. Nadeau. |
| Date: | June 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7275 |
|
This document specifies an Inter-Chassis Communication Protocol(ICCP) that enables Provider Edge (PE) device redundancy for VirtualPrivate Wire Service (VPWS) and Virtual Private LAN Service (VPLS) applications. The protocol runs within a set of two or more PEs, forming a Redundancy Group, for the purpose of synchronizing data among the systems. It accommodates multi-chassis attachment circuit redundancy mechanisms as well as pseudowire redundancy mechanisms. |
|
| |
| RFC 7277 | A YANG Data Model for IP Management |
| |
|
|
This document defines a YANG data model for management of IP implementations. The data model includes configuration data and state data. |
|
| |
| RFC 7280 | IANA Guidance for Managing the Unidirectional Lightweight Encapsulation (ULE) Next-Header Registry |
| |
|
|
This document updates RFC 4326 to clarify and update the allocation rules for the Unidirectional Lightweight Encapsulation (ULE) Next-Header registry. This registry is used by ULE and Generic StreamEncapsulation (GSE) to record the code points of Extension Headers and protocols supported by these encapsulation protocols. |
|
| |
| RFC 7283 | Handling Unknown DHCPv6 Messages |
| |
|
|
DHCPv6 is not specific about handling messages with unknown types.This memo describes the problems associated with receiving DHCPv6 messages with unknown types, and defines how a DHCPv6 server, client, or relay agent should behave when receiving unknown DHCPv6 messages.This document also provides advice for authors of future documents that define new messages to be sent from DHCP servers to DHCP relay agents. This document updates RFC 3315. |
|
| |
| RFC 7285 | Application-Layer Traffic Optimization (ALTO) Protocol |
| |
| Authors: | R. Alimi, Ed., R. Penno, Ed., Y. Yang, Ed., S. Kiesel, S. Previdi, W. Roome, S. Shalunov, R. Woundy. |
| Date: | September 2014 |
| Formats: | txt html json |
| Updated by: | RFC 9274 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7285 |
|
Applications using the Internet already have access to some topology information of Internet Service Provider (ISP) networks. For example, views to Internet routing tables at Looking Glass servers are available and can be practically downloaded to many network application clients. What is missing is knowledge of the underlying network topologies from the point of view of ISPs. In other words, what an ISP prefers in terms of traffic optimization -- and a way to distribute it.
The Application-Layer Traffic Optimization (ALTO) services defined in this document provide network information (e.g., basic network location structure and preferences of network paths) with the goal of modifying network resource consumption patterns while maintaining or improving application performance. The basic information of ALTO is based on abstract maps of a network. These maps provide a simplified view, yet enough information about a network for applications to effectively utilize them. Additional services are built on top of the maps.
This document describes a protocol implementing the ALTO services.Although the ALTO services would primarily be provided by ISPs, other entities, such as content service providers, could also provide ALTO services. Applications that could use the ALTO services are those that have a choice to which end points to connect. Examples of such applications are peer-to-peer (P2P) and content delivery networks. |
|
| |
| RFC 7286 | Application-Layer Traffic Optimization (ALTO) Server Discovery |
| |
| Authors: | S. Kiesel, M. Stiemerling, N. Schwan, M. Scharf, H. Song. |
| Date: | November 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7286 |
|
The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications that have to select one or several hosts from a set of candidates capable of providing a desired resource. ALTO is realized by a client-server protocol. Before anALTO client can ask for guidance, it needs to discover one or moreALTO servers.
This document specifies a procedure for resource-consumer-initiatedALTO server discovery, which can be used if the ALTO client is embedded in the resource consumer. |
|
| |
| RFC 7291 | DHCP Options for the Port Control Protocol (PCP) |
| |
| Authors: | M. Boucadair, R. Penno, D. Wing. |
| Date: | July 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7291 |
|
This document specifies DHCP (IPv4 and IPv6) options to configure hosts with Port Control Protocol (PCP) server IP addresses. The use of DHCPv4 or DHCPv6 depends on the PCP deployment scenarios. The set of deployment scenarios to which DHCPv4 or DHCPv6 can be applied is outside the scope of this document. |
|
| |
| RFC 7293 | The Require-Recipient-Valid-Since Header Field and SMTP Service Extension |
| |
| Authors: | W. Mills, M. Kucherawy. |
| Date: | July 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7293 |
|
This document defines an extension for the Simple Mail TransferProtocol (SMTP) called "RRVS" to provide a method for senders to indicate to receivers a point in time when the ownership of the target mailbox was known to the sender. This can be used to detect changes of mailbox ownership and thus prevent mail from being delivered to the wrong party. This document also defines a header field called "Require-Recipient-Valid-Since" that can be used to tunnel the request through servers that do not support the extension.
The intended use of these facilities is on automatically generated messages, such as account statements or password change instructions, that might contain sensitive information, though it may also be useful in other applications. |
|
| |
| RFC 7294 | RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Concealment Metrics Reporting on Audio Applications |
| |
| Authors: | A. Clark, G. Zorn, C. Bi, Q. Wu. |
| Date: | July 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7294 |
|
This document defines two RTP Control Protocol (RTCP) Extended Report(XR) blocks that allow the reporting of concealment metrics for audio applications of RTP. |
|
| |
| RFC 7301 | Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension |
| |
| Authors: | S. Friedl, A. Popov, A. Langley, E. Stephan. |
| Date: | July 2014 |
| Formats: | txt html json |
| Updated by: | RFC 8447 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7301 |
|
This document describes a Transport Layer Security (TLS) extension for application-layer protocol negotiation within the TLS handshake.For instances in which multiple application protocols are supported on the same TCP or UDP port, this extension allows the application layer to negotiate which protocol will be used within the TLS connection. |
|
| |
| RFC 7303 | XML Media Types |
| |
|
|
This specification standardizes three media types -- application/xml, application/xml-external-parsed-entity, and application/xml-dtd -- for use in exchanging network entities that are related to theExtensible Markup Language (XML) while defining text/xml and text/ xml-external-parsed-entity as aliases for the respective application/ types. This specification also standardizes the '+xml' suffix for naming media types outside of these five types when those media types represent XML MIME entities. |
|
| |
| RFC 7306 | Remote Direct Memory Access (RDMA) Protocol Extensions |
| |
| Authors: | H. Shah, F. Marti, W. Noureddine, A. Eiriksson, R. Sharp. |
| Date: | June 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7306 |
|
This document specifies extensions to the IETF Remote Direct MemoryAccess Protocol (RDMAP) as specified in RFC 5040. RDMAP provides read and write services directly to applications and enables data to be transferred directly into Upper-Layer Protocol (ULP) Buffers without intermediate data copies. The extensions specified in this document provide the following capabilities and/or improvements:Atomic Operations and Immediate Data. |
|
| |
| RFC 7307 | LDP Extensions for Multi-Topology |
| |
| Authors: | Q. Zhao, K. Raza, C. Zhou, L. Fang, L. Li, D. King. |
| Date: | July 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7307 |
|
Multi-Topology (MT) routing is supported in IP networks with the use of MT-aware IGPs. In order to provide MT routing withinMultiprotocol Label Switching (MPLS) Label Distribution Protocol(LDP) networks, new extensions are required.
This document describes the LDP protocol extensions required to support MT routing in an MPLS environment. |
|
| |
| RFC 7308 | Extended Administrative Groups in MPLS Traffic Engineering (MPLS-TE) |
| |
| Authors: | E. Osborne. |
| Date: | July 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7308 |
|
MPLS Traffic Engineering (MPLS-TE) advertises 32 administrative groups (commonly referred to as "colors" or "link colors") using theAdministrative Group sub-TLV. This is defined for OSPFv2 (RFC 3630),OSPFv3 (RFC 5329) and IS-IS (RFC 5305).
This document adds a sub-TLV to the IGP TE extensions, "ExtendedAdministrative Group". This sub-TLV provides for additional administrative groups (link colors) beyond the current limit of 32. |
|
| |
| RFC 7309 | Redundancy Mechanism for Inter-domain VPLS Service |
| |
| Authors: | Z. Liu, L. Jin, R. Chen, D. Cai, S. Salam. |
| Date: | July 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7309 |
|
In many existing Virtual Private LAN Service (VPLS) inter-domain deployments (based on RFC 4762), pseudowire (PW) connectivity offers no Provider Edge (PE) node redundancy, or offers PE node redundancy with only a single domain. This deployment approach incurs a high risk of service interruption, since at least one domain will not offer PE node redundancy. This document describes an inter-domainVPLS solution that provides PE node redundancy across domains. |
|
| |
| RFC 7310 | RTP Payload Format for Standard apt-X and Enhanced apt-X Codecs |
| |
| Authors: | J. Lindsay, H. Foerster. |
| Date: | July 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7310 |
|
This document specifies a scheme for packetizing Standard apt-X orEnhanced apt-X encoded audio data into Real-time Transport Protocol(RTP) packets. The document describes a payload format that permits transmission of multiple related audio channels in a single RTP payload and a means of establishing Standard apt-X and Enhanced apt-X connections through the Session Description Protocol (SDP). |
|
| |
| RFC 7311 | The Accumulated IGP Metric Attribute for BGP |
| |
| Authors: | P. Mohapatra, R. Fernando, E. Rosen, J. Uttaro. |
| Date: | August 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7311 |
|
Routing protocols that have been designed to run within a single administrative domain (IGPs) generally do so by assigning a metric to each link and then choosing, as the installed path between two nodes, the path for which the total distance (sum of the metric of each link along the path) is minimized. BGP, designed to provide routing over a large number of independent administrative domains (autonomous systems), does not make its path-selection decisions through the use of a metric. It is generally recognized that any attempt to do so would incur significant scalability problems as well as inter- administration coordination problems. However, there are deployments in which a single administration runs several contiguous BGP networks. In such cases, it can be desirable, within that single administrative domain, for BGP to select paths based on a metric, just as an IGP would do. The purpose of this document is to provide a specification for doing so. |
|
| |
| RFC 7313 | Enhanced Route Refresh Capability for BGP-4 |
| |
| Authors: | K. Patel, E. Chen, B. Venkatachalapathy. |
| Date: | July 2014 |
| Formats: | txt json html |
| Updates: | RFC 2918 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7313 |
|
In this document, we enhance the existing BGP route refresh mechanisms to provide for the demarcation of the beginning and the ending of a route refresh. The enhancement can be used to facilitate correction of BGP Routing Information Base (RIB) inconsistencies in a non-disruptive manner. This document updates RFC 2918. |
|
| |
| RFC 7317 | A YANG Data Model for System Management |
| |
| Authors: | A. Bierman, M. Bjorklund. |
| Date: | August 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7317 |
|
This document defines a YANG data model for the configuration and identification of some common system properties within a device containing a Network Configuration Protocol (NETCONF) server. This document also includes data node definitions for system identification, time-of-day management, user management, DNS resolver configuration, and some protocol operations for system management. |
|
| |
| RFC 7318 | Policy Qualifiers in Resource Public Key Infrastructure (RPKI) Certificates |
| |
|
|
This document updates RFC 6487 by clarifying the inclusion of policy qualifiers in the certificate policies extension of Resource PublicKey Infrastructure (RPKI) resource certificates. |
|
| |
| RFC 7321 | Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH) |
| |
|
|
This document updates the Cryptographic Algorithm ImplementationRequirements for the Encapsulating Security Payload (ESP) andAuthentication Header (AH). It also adds usage guidance to help in the selection of these algorithms.
ESP and AH protocols make use of various cryptographic algorithms to provide confidentiality and/or data origin authentication to protected data communications in the IP Security (IPsec) architecture. To ensure interoperability between disparate implementations, the IPsec standard specifies a set of mandatory-to- implement algorithms. This document specifies the current set of mandatory-to-implement algorithms for ESP and AH, specifies algorithms that should be implemented because they may be promoted to mandatory at some future time, and also recommends against the implementation of some obsolete algorithms. Usage guidance is also provided to help the user of ESP and AH best achieve their security goals through appropriate choices of cryptographic algorithms.
This document obsoletes RFC 4835. |
|
| |
| RFC 7323 | TCP Extensions for High Performance |
| |
| Authors: | D. Borman, B. Braden, V. Jacobson, R. Scheffenegger, Ed.. |
| Date: | September 2014 |
| Formats: | txt json html |
| Obsoletes: | RFC 1323 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7323 |
|
This document specifies a set of TCP extensions to improve performance over paths with a large bandwidth * delay product and to provide reliable operation over very high-speed paths. It defines the TCP Window Scale (WS) option and the TCP Timestamps (TS) option and their semantics. The Window Scale option is used to support larger receive windows, while the Timestamps option can be used for at least two distinct mechanisms, Protection Against WrappedSequences (PAWS) and Round-Trip Time Measurement (RTTM), that are also described herein.
This document obsoletes RFC 1323 and describes changes from it. |
|
| |
| RFC 7324 | Updates to MPLS Transport Profile Linear Protection |
| |
|
|
This document contains a number of updates to the Protection StateCoordination (PSC) logic defined in RFC 6378, "MPLS Transport Profile(MPLS-TP) Linear Protection". These updates provide some rules and recommendations around the use of TLVs in PSC, address some issues raised in an ITU-T liaison statement, and clarify PSC's behavior in a case not well explained in RFC 6378. |
|
| |
| RFC 7330 | Definitions of Textual Conventions (TCs) for Bidirectional Forwarding Detection (BFD) Management |
| |
| Authors: | T. Nadeau, Z. Ali, N. Akiya. |
| Date: | August 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7330 |
|
This document defines two Management Information Base (MIB) modules that contain Textual Conventions to represent commonly usedBidirectional Forwarding Detection (BFD) management information. The intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and used in BFD-related MIB modules that would otherwise define their own representations. |
|
| |
| RFC 7331 | Bidirectional Forwarding Detection (BFD) Management Information Base |
| |
| Authors: | T. Nadeau, Z. Ali, N. Akiya. |
| Date: | August 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7331 |
|
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 for modeling the Bidirectional Forwarding Detection (BFD) protocol. |
|
| |
| RFC 7332 | Loop Detection Mechanisms for Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) |
| |
| Authors: | H. Kaplan, V. Pascual. |
| Date: | August 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7332 |
|
SIP Back-to-Back User Agents (B2BUAs) can cause unending SIP request routing loops because, as User Agent Clients, they can generate SIP requests with new Max-Forwards values. This document discusses the difficulties associated with loop detection for B2BUAs and the requirements for them to prevent infinite loops. |
|
| |
| RFC 7335 | IPv4 Service Continuity Prefix |
| |
|
|
Dual-Stack Lite (DS-Lite), defined in RFC 6333, directs IANA to reserve 192.0.0.0/29 for the Basic Bridging BroadBand (B4) element.Per this memo, IANA has generalized that reservation to include other cases where a non-routed IPv4 interface must be numbered as part of an IPv6 transition solution. |
|
| |
| RFC 7339 | Session Initiation Protocol (SIP) Overload Control |
| |
| Authors: | V. Gurbani, Ed., V. Hilt, H. Schulzrinne. |
| Date: | September 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7339 |
|
Overload occurs in Session Initiation Protocol (SIP) networks whenSIP servers have insufficient resources to handle all the SIP messages they receive. Even though the SIP protocol provides a limited overload control mechanism through its 503 (ServiceUnavailable) response code, SIP servers are still vulnerable to overload. This document defines the behavior of SIP servers involved in overload control and also specifies a loss-based overload scheme for SIP. |
|
| |
| RFC 7341 | DHCPv4-over-DHCPv6 (DHCP 4o6) Transport |
| |
| Authors: | Q. Sun, Y. Cui, M. Siodelski, S. Krishnan, I. Farrer. |
| Date: | August 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7341 |
|
IPv4 connectivity is still needed as networks migrate towards IPv6.Users require IPv4 configuration even if the uplink to their service provider supports IPv6 only. This document describes a mechanism for obtaining IPv4 configuration information dynamically in IPv6 networks by carrying DHCPv4 messages over DHCPv6 transport. Two new DHCPv6 messages and two new DHCPv6 options are defined for this purpose. |
|
| |
| RFC 7343 | An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2) |
| |
|
|
This document specifies an updated Overlay Routable CryptographicHash Identifiers (ORCHID) format that obsoletes that in RFC 4843.These identifiers are intended to be used as endpoint identifiers at applications and Application Programming Interfaces (APIs) and not as identifiers for network location at the IP layer, i.e., locators.They are designed to appear as application-layer entities and at the existing IPv6 APIs, but they should not appear in actual IPv6 headers. To make them more like regular IPv6 addresses, they are expected to be routable at an overlay level. Consequently, while they are considered non-routable addresses from the IPv6-layer perspective, all existing IPv6 applications are expected to be able to use them in a manner compatible with current IPv6 addresses.
The Overlay Routable Cryptographic Hash Identifiers originally defined in RFC 4843 lacked a mechanism for cryptographic algorithm agility. The updated ORCHID format specified in this document removes this limitation by encoding, in the identifier itself, an index to the suite of cryptographic algorithms in use. |
|
| |
| RFC 7344 | Automating DNSSEC Delegation Trust Maintenance |
| |
| Authors: | W. Kumari, O. Gudmundsson, G. Barwood. |
| Date: | September 2014 |
| Formats: | txt json html |
| Updated by: | RFC 8078 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7344 |
|
This document describes a method to allow DNS Operators to more easily update DNSSEC Key Signing Keys using the DNS as a communication channel. The technique described is aimed at delegations in which it is currently hard to move information from the Child to Parent. |
|
| |
| RFC 7345 | UDP Transport Layer (UDPTL) over Datagram Transport Layer Security (DTLS) |
| |
| Authors: | C. Holmberg, I. Sedlacek, G. Salgueiro. |
| Date: | August 2014 |
| Formats: | txt json html |
| Updated by: | RFC 8842 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7345 |
|
This document specifies how the UDP Transport Layer (UDPTL) protocol, the predominant transport protocol for T.38 fax, can be transported over the Datagram Transport Layer Security (DTLS) protocol, how the usage of UDPTL over DTLS is indicated in the Session DescriptionProtocol (SDP), and how UDPTL over DTLS is negotiated in a session established using the Session Initiation Protocol (SIP). |
|
| |
| RFC 7346 | IPv6 Multicast Address Scopes |
| |
|
|
This document updates the definitions of IPv6 multicast scopes and therefore updates RFCs 4007 and 4291. |
|
| |
| RFC 7349 | LDP Hello Cryptographic Authentication |
| |
| Authors: | L. Zheng, M. Chen, M. Bhatia. |
| Date: | August 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7349 |
|
This document introduces a new optional Cryptographic AuthenticationTLV that LDP can use to secure its Hello messages. It secures theHello messages against spoofing attacks and some well-known attacks against the IP header. This document describes a mechanism to secure the LDP Hello messages using Hashed Message Authentication Code(HMAC) with the National Institute of Standards and Technology (NIST)Secure Hash Standard family of algorithms. |
|
| |
| RFC 7350 | Datagram Transport Layer Security (DTLS) as Transport for Session Traversal Utilities for NAT (STUN) |
| |
|
|
This document specifies the usage of Datagram Transport LayerSecurity (DTLS) as a transport protocol for Session TraversalUtilities for NAT (STUN). It provides guidance on when and how to use DTLS with the currently standardized STUN usages. It also specifies modifications to the STUN and Traversal Using Relay NAT(TURN) URIs and to the TURN resolution mechanism to facilitate the resolution of STUN and TURN URIs into the IP address and port of STUN and TURN servers supporting DTLS as a transport protocol. This document updates RFCs 5389 and 5928. |
|
| |
| RFC 7352 | Sieve Email Filtering: Detecting Duplicate Deliveries |
| |
| Authors: | S. Bosch. |
| Date: | September 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7352 |
|
This document defines a new test command, "duplicate", for the Sieve email filtering language. This test adds the ability to detect duplications. The main application for this new test is handling duplicate deliveries commonly caused by mailing list subscriptions or redirected mail addresses. The detection is normally performed by matching the message ID to an internal list of message IDs from previously delivered messages. For more complex applications, the"duplicate" test can also use the content of a specific header field or other parts of the message. |
|
| |
| RFC 7356 | IS-IS Flooding Scope Link State PDUs (LSPs) |
| |
| Authors: | L. Ginsberg, S. Previdi, Y. Yang. |
| Date: | September 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7356 |
|
Intermediate System to Intermediate System (IS-IS) provides efficient and reliable flooding of information to its peers; however, the current flooding scopes are limited to either area scope or domain scope. There are existing use cases where support of other flooding scopes is desirable. This document defines new Protocol Data Units(PDUs) that provide support for new flooding scopes as well as additional space for advertising information targeted for the currently supported flooding scopes. This document also defines extended Type-Length-Values (TLVs) and sub-TLVs that are encoded using 16-bit fields for Type and Length.
The protocol extensions defined in this document are not backwards compatible with existing implementations and so must be deployed with care. |
|
| |
| RFC 7357 | Transparent Interconnection of Lots of Links (TRILL): End Station Address Distribution Information (ESADI) Protocol |
| |
| Authors: | H. Zhai, F. Hu, R. Perlman, D. Eastlake 3rd, O. Stokes. |
| Date: | September 2014 |
| Formats: | txt html json |
| Updates: | RFC 6325 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7357 |
|
The IETF TRILL (Transparent Interconnection of Lots of Links) protocol provides least-cost pair-wise data forwarding without configuration in multi-hop networks with arbitrary topologies and link technologies. TRILL supports multipathing of both unicast and multicast traffic. Devices that implement the TRILL protocol are called TRILL switches or RBridges (Routing Bridges).
ESADI (End Station Address Distribution Information) is an optional protocol by which a TRILL switch can communicate, in a Data Label(VLAN or fine-grained label) scoped way, end station address and reachability information to TRILL switches participating in ESADI for the relevant Data Label. This document updates RFC 6325, specifically the documentation of the ESADI protocol, and is not backwards compatible. |
|
| |
| RFC 7358 | Label Advertisement Discipline for LDP Forwarding Equivalence Classes (FECs) |
| |
|
|
The label advertising behavior of an LDP speaker for a givenForwarding Equivalence Class (FEC) is governed by the FEC type and not necessarily by the LDP session's negotiated label advertisement mode. This document updates RFC 5036 to make that fact clear. It also updates RFCs 3212, 4447, 5918, 6388, and 7140 by specifying the label advertisement mode for all currently defined LDP FEC types. |
|
| |
| RFC 7361 | LDP Extensions for Optimized MAC Address Withdrawal in a Hierarchical Virtual Private LAN Service (H-VPLS) |
| |
| Authors: | P. Dutta, F. Balus, O. Stokes, G. Calvignac, D. Fedyk. |
| Date: | September 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7361 |
|
RFC 4762 describes a mechanism to remove or unlearn Media AccessControl (MAC) addresses that have been dynamically learned in aVirtual Private LAN Service (VPLS) instance for faster convergence on topology changes. The procedure also removes MAC addresses in theVPLS that do not require relearning due to such topology changes.This document defines an enhancement to the MAC address withdraw procedure with an empty MAC list (RFC 4762); this enhancement enables a Provider Edge (PE) device to remove only the MAC addresses that need to be relearned. Additional extensions to RFC 4762 MAC withdraw procedures are specified to provide an optimized MAC flushing for theProvider Backbone Bridging (PBB) VPLS specified in RFC 7041. |
|
| |
| RFC 7363 | Self-Tuning Distributed Hash Table (DHT) for REsource LOcation And Discovery (RELOAD) |
| |
| Authors: | J. Maenpaa, G. Camarillo. |
| Date: | September 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7363 |
|
REsource LOcation And Discovery (RELOAD) is a peer-to-peer (P2P) signaling protocol that provides an overlay network service. Peers in a RELOAD overlay network collectively run an overlay algorithm to organize the overlay and to store and retrieve data. This document describes how the default topology plugin of RELOAD can be extended to support self-tuning, that is, to adapt to changing operating conditions such as churn and network size. |
|
| |
| RFC 7366 | Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) |
| |
| Authors: | P. Gutmann. |
| Date: | September 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7366 |
|
This document describes a means of negotiating the use of the encrypt-then-MAC security mechanism in place of the existing MAC- then-encrypt mechanism in Transport Layer Security (TLS) and DatagramTransport Layer Security (DTLS). The MAC-then-encrypt mechanism has been the subject of a number of security vulnerabilities over a period of many years. |
|
| |
| RFC 7369 | GMPLS RSVP-TE Extensions for Ethernet Operations, Administration, and Maintenance (OAM) Configuration |
| |
| Authors: | A. Takacs, B. Gero, H. Long. |
| Date: | October 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7369 |
|
The work related to GMPLS Ethernet Label Switching (GELS) extendedGMPLS RSVP-TE to support the establishment of Ethernet LabelSwitching Paths (LSPs). IEEE Ethernet Connectivity Fault Management(CFM) specifies an adjunct Operations, Administration, andMaintenance (OAM) flow to check connectivity in Ethernet networks.CFM can also be used with Ethernet LSPs for fault detection and triggering recovery mechanisms. The ITU-T Y.1731 specification builds on CFM and specifies additional OAM mechanisms, includingPerformance Monitoring, for Ethernet networks. This document specifies extensions of the GMPLS RSVP-TE protocol to support the setup of the associated Ethernet OAM entities of Ethernet LSPs and defines the Ethernet technology-specific TLVs based on the GMPLS OAMConfiguration Framework. This document supports, but does not modify, the IEEE and ITU-T OAM mechanisms. |
|
| |
| RFC 7370 | Updates to the IS-IS TLV Codepoints Registry |
| |
|
|
This document recommends some editorial changes to the IANA "IS-ISTLV Codepoints" registry to more accurately document the state of the protocol. It also sets out new guidelines for Designated Experts to apply when reviewing allocations from the registry. |
|
| |
| RFC 7371 | Updates to the IPv6 Multicast Addressing Architecture |
| |
|
|
This document updates the IPv6 multicast addressing architecture by redefining the reserved bits as generic flag bits. The document also provides some clarifications related to the use of these flag bits.
This document updates RFCs 3956, 3306, and 4291. |
|
| |
| RFC 7372 | Email Authentication Status Codes |
| |
|
|
This document registers code points to allow status codes to be returned to an email client to indicate that a message is being rejected or deferred specifically because of email authentication failures.
This document updates RFC 7208, since some of the code points registered replace the ones recommended for use in that document. |
|
| |
| RFC 7373 | Textual Representation of IP Flow Information Export (IPFIX) Abstract Data Types |
| |
| Authors: | B. Trammell. |
| Date: | September 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7373 |
|
This document defines UTF-8 representations for IP Flow InformationExport (IPFIX) abstract data types (ADTs) to support interoperable usage of the IPFIX Information Elements with protocols based on textual encodings. |
|
| |
| RFC 7374 | Service Discovery Usage for REsource LOcation And Discovery (RELOAD) |
| |
| Authors: | J. Maenpaa, G. Camarillo. |
| Date: | October 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7374 |
|
REsource LOcation And Discovery (RELOAD) does not define a generic service discovery mechanism as a part of the base protocol (RFC6940). This document defines how the Recursive DistributedRendezvous (ReDiR) service discovery mechanism can be applied toRELOAD overlays to provide a generic service discovery mechanism. |
|
| |
| RFC 7377 | IMAP4 Multimailbox SEARCH Extension |
| |
|
|
The IMAP4 specification allows the searching of only the selected mailbox. A user often wants to search multiple mailboxes, and a client that wishes to support this must issue a series of SELECT andSEARCH commands, waiting for each to complete before moving on to the next. This extension allows a client to search multiple mailboxes with one command, limiting the delays caused by many round trips and not requiring disruption of the currently selected mailbox. This extension also uses MAILBOX, UIDVALIDITY, and TAG fields in ESEARCH responses, allowing a client to pipeline the searches if it chooses.This document updates RFC 4466 and obsoletes RFC 6237. |
|
| |
| RFC 7380 | RTP Control Protocol (RTCP) Extended Report (XR) Block for MPEG2 Transport Stream (TS) Program Specific Information (PSI) Decodability Statistics Metrics Reporting |
| |
| Authors: | J. Tong, C. Bi, Ed., R. Even, Q. Wu, Ed., R. Huang. |
| Date: | November 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7380 |
|
An MPEG2 Transport Stream (TS) is a standard container format used in the transmission and storage of multimedia data. Unicast/multicastMPEG2 TS over RTP is widely deployed in IPTV systems. This document defines an RTP Control Protocol (RTCP) Extended Report (XR) block that allows the reporting of MPEG2 TS decodability statistics metrics related to transmissions of MPEG2 TS over RTP. The metrics specified in the RTCP XR block are related to Program Specific Information(PSI) carried in MPEG TS. |
|
| |
| RFC 7383 | Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation |
| |
| Authors: | V. Smyslov. |
| Date: | November 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7383 |
|
This document describes a way to avoid IP fragmentation of largeInternet Key Exchange Protocol version 2 (IKEv2) messages. This allows IKEv2 messages to traverse network devices that do not allowIP fragments to pass through. |
|
| |
| RFC 7385 | IANA Registry for P-Multicast Service Interface (PMSI) Tunnel Type Code Points |
| |
|
|
RFC 6514 created a space of Tunnel Type code points for a new BGP attribute called the "P-Multicast Service Interface Tunnel (PMSITunnel) attribute". However, the RFC did not create a correspondingIANA registry.
There now is need to make further code point allocations from this name space. This document serves to update RFC 6514 in that it creates an IANA registry for that purpose. |
|
| |
| RFC 7386 | JSON Merge Patch |
| |
| Authors: | P. Hoffman, J. Snell. |
| Date: | October 2014 |
| Formats: | txt html json |
| Obsoleted by: | RFC 7396 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7386 |
|
This specification defines the JSON merge patch format and processing rules. The merge patch format is primarily intended for use with theHTTP PATCH method as a means of describing a set of modifications to a target resource's content. |
|
| |
| RFC 7388 | Definition of Managed Objects for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) |
| |
| Authors: | J. Schoenwaelder, A. Sehgal, T. Tsou, C. Zhou. |
| Date: | October 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7388 |
|
This document 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 IPv6 overLow-Power Wireless Personal Area Networks (6LoWPANs). |
|
| |
| RFC 7389 | Separation of Control and User Plane for Proxy Mobile IPv6 |
| |
| Authors: | R. Wakikawa, R. Pazhyannur, S. Gundavelli, C. Perkins. |
| Date: | October 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7389 |
|
This document specifies a method to split the control plane (CP) and user plane (UP) for a network infrastructure based on Proxy MobileIPv6 (PMIPv6). Existing specifications allow a mobile access gateway(MAG) to separate its control and user plane using the AlternateCare-of Address mobility option for IPv6 or Alternate IPv4 Care-ofAddress option for IPv4. However, the current specification does not provide any mechanism allowing the local mobility anchor (LMA) to perform an analogous functional split. To remedy that shortcoming, this document specifies a mobility option enabling an LMA to provide an alternate LMA address to be used for the bidirectional user-plane traffic between the MAG and LMA. With this new option, an LMA will be able to use an IP address for its user plane that is different than the IP address used for the control plane. |
|
| |
| RFC 7391 | Forwarding and Control Element Separation (ForCES) Protocol Extensions |
| |
|
|
Experience in implementing and deploying the Forwarding and ControlElement Separation (ForCES) architecture has demonstrated the need for a few small extensions both to ease programmability and to improve wire efficiency of some transactions. The ForCES protocol is extended with a table range operation and a new extension for error handling. This document updates the semantics in RFCs 5810 and 7121 to achieve that end goal. |
|
| |
| RFC 7392 | Explicit Path Routing for Dynamic Multi-Segment Pseudowires |
| |
| Authors: | P. Dutta, M. Bocci, L. Martini. |
| Date: | December 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7392 |
|
When set up through an explicit path, dynamic Multi-SegmentPseudowires (MS-PWs) may be required to provide a simple solution for1:1 protection with diverse primary and backup MS-PWs for a service, or to enable controlled signaling (strict or loose) for special MS-PWs. This document specifies the extensions and procedures required to enable dynamic MS-PWs to be established along explicit paths. |
|
| |
| RFC 7394 | Definition of Time to Live TLV for LSP-Ping Mechanisms |
| |
| Authors: | S. Boutros, S. Sivabalan, G. Swallow, S. Saxena, V. Manral, S. Aldrin. |
| Date: | November 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7394 |
|
LSP-Ping is a widely deployed Operation, Administration, andMaintenance (OAM) mechanism in MPLS networks. However, in the present form, this mechanism is inadequate to verify connectivity of a segment of a Multi-Segment Pseudowire (MS-PW) and/or bidirectional co-routed Label Switched Path (LSP) from any node on the path of theMS-PW and/or bidirectional co-routed LSP. This document defines aTLV to address this shortcoming. |
|
| |
| RFC 7395 | An Extensible Messaging and Presence Protocol (XMPP) Subprotocol for WebSocket |
| |
| Authors: | L. Stout, Ed., J. Moffitt, E. Cestari. |
| Date: | October 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7395 |
|
This document defines a binding for the Extensible Messaging andPresence Protocol (XMPP) over a WebSocket transport layer. AWebSocket binding for XMPP provides higher performance than the current HTTP binding for XMPP. |
|
| |
| RFC 7396 | JSON Merge Patch |
| |
| Authors: | P. Hoffman, J. Snell. |
| Date: | October 2014 |
| Formats: | txt html json |
| Obsoletes: | RFC 7386 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7396 |
|
This specification defines the JSON merge patch format and processing rules. The merge patch format is primarily intended for use with theHTTP PATCH method as a means of describing a set of modifications to a target resource's content. |
|
| |
| RFC 7400 | 6LoWPAN-GHC: Generic Header Compression for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) |
| |
| Authors: | C. Bormann. |
| Date: | November 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7400 |
|
RFC 6282 defines header compression in 6LoWPAN packets (where"6LoWPAN" refers to "IPv6 over Low-Power Wireless Personal AreaNetwork"). The present document specifies a simple addition that enables the compression of generic headers and header-like payloads, without a need to define a new header compression scheme for each such new header or header-like payload. |
|
| |
| RFC 7401 | Host Identity Protocol Version 2 (HIPv2) |
| |
|
|
This document specifies the details of the Host Identity Protocol(HIP). HIP allows consenting hosts to securely establish and maintain shared IP-layer state, allowing separation of the identifier and locator roles of IP addresses, thereby enabling continuity of communications across IP address changes. HIP is based on a Diffie-Hellman key exchange, using public key identifiers from a new HostIdentity namespace for mutual peer authentication. The protocol is designed to be resistant to denial-of-service (DoS) and man-in-the- middle (MitM) attacks. When used together with another suitable security protocol, such as the Encapsulating Security Payload (ESP), it provides integrity protection and optional encryption for upper- layer protocols, such as TCP and UDP.
This document obsoletes RFC 5201 and addresses the concerns raised by the IESG, particularly that of crypto agility. It also incorporates lessons learned from the implementations of RFC 5201. |
|
| |
| RFC 7402 | Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP) |
| |
| Authors: | P. Jokela, R. Moskowitz, J. Melen. |
| Date: | April 2015 |
| Formats: | txt html json |
| Obsoletes: | RFC 5202 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7402 |
|
This memo specifies an Encapsulating Security Payload (ESP) based mechanism for transmission of user data packets, to be used with theHost Identity Protocol (HIP). This document obsoletes RFC 5202. |
|
| |
| RFC 7403 | A Media-Based Traceroute Function for the Session Initiation Protocol (SIP) |
| |
| Authors: | H. Kaplan. |
| Date: | November 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7403 |
|
SIP already provides the ability to perform hop-by-hop traceroute forSIP messages using the Max-Forwards header field to determine the reachability path of requests to a target. A mechanism for media- loopback calls has also been defined separately, which enables test calls to be generated that result in media being looped back to the originator. This document describes a means of performing hop-by-hop traceroute-style test calls using the media-loopback mechanism to test the media path when SIP sessions go through media-relaying back- to-back user agents (B2BUAs). |
|
| |
| RFC 7405 | Case-Sensitive String Support in ABNF |
| |
|
|
This document extends the base definition of ABNF (Augmented Backus-Naur Form) to include a way to specify US-ASCII string literals that are matched in a case-sensitive manner. |
|
| |
| RFC 7407 | A YANG Data Model for SNMP Configuration |
| |
| Authors: | M. Bjorklund, J. Schoenwaelder. |
| Date: | December 2014 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7407 |
|
This document defines a collection of YANG definitions for configuring SNMP engines. |
|
| |
| RFC 7408 | Forwarding and Control Element Separation (ForCES) Model Extension |
| |
|
|
This memo extends the Forwarding and Control Element Separation(ForCES) model defined in RFC 5812 and updates that RFC to allow complex data types for metadata, optional default values for data types, and optional access types for structures. It also fixes an issue with Logical Functional Block (LFB) inheritance and introduces two new features: a new event condition called eventBecomesEqualTo and LFB properties. The changes introduced in this memo do not alter the protocol and retain backward compatibility with older LFB models. |
|
| |
| RFC 7410 | A Property Types Registry for the Authentication-Results Header Field |
| |
|
|
This document updates RFC 7001 by creating a registry for property types in the Authentication-Results header field, used in email authentication work, rather than limiting participants to using the original, small set of fixed values. |
|
| |
| RFC 7415 | Session Initiation Protocol (SIP) Rate Control |
| |
| Authors: | E. Noel, P. Williams. |
| Date: | February 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7415 |
|
The prevalent use of the Session Initiation Protocol (SIP) in NextGeneration Networks necessitates that SIP networks provide adequate control mechanisms to maintain transaction throughput by preventing congestion collapse during traffic overloads. A loss-based solution to remedy known vulnerabilities of the SIP 503 (Service Unavailable) overload control mechanism has already been proposed. Using the same signaling, this document proposes a rate-based control scheme to complement the loss-based control scheme. |
|
| |
| RFC 7420 | Path Computation Element Communication Protocol (PCEP) Management Information Base (MIB) Module |
| |
| Authors: | A. Koushik, E. Stephan, Q. Zhao, D. King, J. Hardwick. |
| Date: | December 2014 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7420 |
|
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 of the PathComputation Element Communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path ComputationElement (PCE), or between two PCEs. |
|
| |
| RFC 7427 | Signature Authentication in the Internet Key Exchange Version 2 (IKEv2) |
| |
|
|
The Internet Key Exchange Version 2 (IKEv2) protocol has limited support for the Elliptic Curve Digital Signature Algorithm (ECDSA).The current version only includes support for three Elliptic Curve groups, and there is a fixed hash algorithm tied to each group. This document generalizes IKEv2 signature support to allow any signature method supported by PKIX and also adds signature hash algorithm negotiation. This is a generic mechanism and is not limited toECDSA; it can also be used with other signature algorithms. |
|
| |
| RFC 7428 | Transmission of IPv6 Packets over ITU-T G.9959 Networks |
| |
| Authors: | A. Brandt, J. Buron. |
| Date: | February 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7428 |
|
This document describes the frame format for transmission of IPv6 packets as well as a method of forming IPv6 link-local addresses and statelessly autoconfigured IPv6 addresses on ITU-T G.9959 networks. |
|
| |
| RFC 7432 | BGP MPLS-Based Ethernet VPN |
| |
| Authors: | A. Sajassi, Ed., R. Aggarwal, N. Bitar, A. Isaac, J. Uttaro, J. Drake, W. Henderickx. |
| Date: | February 2015 |
| Formats: | txt html json |
| Updated by: | RFC 8584, RFC 9161 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7432 |
|
This document describes procedures for BGP MPLS-based Ethernet VPNs(EVPN). The procedures described here meet the requirements specified in RFC 7209 -- "Requirements for Ethernet VPN (EVPN)". |
|
| |
| RFC 7433 | A Mechanism for Transporting User-to-User Call Control Information in SIP |
| |
| Authors: | A. Johnston, J. Rafferty. |
| Date: | January 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7433 |
|
There is a class of applications that benefit from using SIP to exchange User-to-User Information (UUI) data during session establishment. This information, known as call control UUI data, is a small piece of data inserted by an application initiating the session and utilized by an application accepting the session. The syntax and semantics for the UUI data used by a specific application are defined by a UUI package. This UUI data is opaque to SIP and its function is unrelated to any basic SIP function. This document defines a new SIP header field, User-to-User, to transport UUI data, along with an extension mechanism. |
|
| |
| RFC 7434 | Interworking ISDN Call Control User Information with SIP |
| |
| Authors: | K. Drage, Ed., A. Johnston. |
| Date: | January 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7434 |
|
The motivation and use cases for interworking and transporting User- to-User Information (UUI) from the ITU-T Digital SubscriberSignalling System No. 1 (DSS1) User-user information element withinSIP are described in RFC 6567. As networks move to SIP, it is important that applications requiring this data can continue to function in SIP networks as well as have the ability to interwork with this ISDN service for end-to-end transparency. This document defines a usage (a new package called the ISDN UUI package) of theUser-to-User header field to enable interworking with this ISDN service.
This document covers interworking with both public ISDN and privateISDN capabilities, so the potential interworking with QSIG will also be addressed.
The package is identified by the new value "isdn-uui" of the"purpose" header field parameter. |
|
| |
| RFC 7438 | Multipoint LDP (mLDP) In-Band Signaling with Wildcards |
| |
| Authors: | IJ. Wijnands, Ed., E. Rosen, A. Gulko, U. Joorde, J. Tantsura. |
| Date: | January 2015 |
| Formats: | txt json html |
| Updates: | RFC 6826, RFC 7246 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7438 |
|
There are scenarios in which an IP multicast tree traverses an MPLS domain. In these scenarios, it can be desirable to convert the IP multicast tree "seamlessly" into an MPLS Multipoint Label SwitchedPath (MP-LSP) when it enters the MPLS domain, and then to convert it back to an IP multicast tree when it exits the MPLS domain. Previous documents specify procedures that allow certain kinds of IP multicast trees (either Source-Specific Multicast trees or BidirectionalMulticast trees) to be attached to an MPLS Multipoint Label SwitchedPath (MP-LSP). However, the previous documents do not specify procedures for attaching IP Any-Source Multicast trees to MP-LSPs, nor do they specify procedures for aggregating multiple IP multicast trees onto a single MP-LSP. This document specifies the procedures to support these functions. It does so by defining "wildcard" encodings that make it possible to specify, when setting up an MP-LSP, that a set of IP multicast trees, or a shared IP multicast tree, should be attached to that MP-LSP. Support for non-bidirectional IPAny-Source Multicast trees is subject to certain applicability restrictions that are discussed in this document. This document updates RFCs 6826 and 7246. |
|
| |
| RFC 7440 | TFTP Windowsize Option |
| |
| Authors: | P. Masotta. |
| Date: | January 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7440 |
|
The "Trivial File Transfer Protocol" (RFC 1350) is a simple, lockstep, file transfer protocol that allows a client to get or put a file onto a remote host. One of its primary uses is in the early stages of nodes booting from a Local Area Network (LAN). TFTP has been used for this application because it is very simple to implement. The employment of a lockstep scheme limits throughput when used on a LAN.
This document describes a TFTP option that allows the client and server to negotiate a window size of consecutive blocks to send as an alternative for replacing the single-block lockstep schema. The TFTP option mechanism employed is described in "TFTP Option Extension"(RFC 2347). |
|
| |
| RFC 7441 | Encoding Multipoint LDP (mLDP) Forwarding Equivalence Classes (FECs) in the NLRI of BGP MCAST-VPN Routes |
| |
| Authors: | IJ. Wijnands, E. Rosen, U. Joorde. |
| Date: | January 2015 |
| Formats: | txt html json |
| Updates: | RFC 6514 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7441 |
|
Many service providers offer "BGP/MPLS IP VPN" service to their customers. Existing IETF standards specify the procedures and protocols that a service provider uses in order to offer this service to customers who have IP unicast and IP multicast traffic in theirVPNs. It is also desirable to be able to support customers who haveMPLS multicast traffic in their VPNs. This document specifies the procedures and protocol extensions that are needed to support customers who use the Multipoint LDP (mLDP) as the control protocol for their MPLS multicast traffic. Existing standards do provide some support for customers who use mLDP, but only under a restrictive set of circumstances. This document generalizes the existing support to include all cases where the customer uses mLDP, without any restrictions. This document updates RFC 6514. |
|
| |
| RFC 7442 | Carrying Protocol Independent Multicast - Sparse Mode (PIM-SM) in Any-Source Multicast (ASM) Mode Trees over Multipoint LDP (mLDP) |
| |
| Authors: | Y. Rekhter, R. Aggarwal, N. Leymann, W. Henderickx, Q. Zhao, R. Li. |
| Date: | February 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7442 |
|
When IP multicast trees created by Protocol Independent Multicast -Sparse Mode (PIM-SM) in Any-Source Multicast (ASM) mode need to pass through an MPLS domain, it may be desirable to map such trees toPoint-to-Multipoint Label Switched Paths (P2MP LSPs). This document describes how to accomplish this in the case where such P2MP LSPs are established using Label Distribution Protocol (LDP) Extensions forP2MP and Multipoint-to-Multipoint LSPs: Multipoint LDP (mLDP). |
|
| |
| RFC 7447 | Deprecation of BGP Entropy Label Capability Attribute |
| |
| Authors: | J. Scudder, K. Kompella. |
| Date: | February 2015 |
| Formats: | txt json html |
| Updates: | RFC 6790 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7447 |
|
The BGP Entropy Label Capability attribute is defined in RFC 6790.Regrettably, it has a bug: although RFC 6790 mandates that routers incapable of processing Entropy Labels must remove the attribute, fulfillment of this requirement cannot be guaranteed in practice.This specification deprecates the attribute. A forthcoming document will propose a replacement. |
|
| |
| RFC 7450 | Automatic Multicast Tunneling |
| |
|
|
This document describes Automatic Multicast Tunneling (AMT), a protocol for delivering multicast traffic from sources in a multicast-enabled network to receivers that lack multicast connectivity to the source network. The protocol uses UDP encapsulation and unicast replication to provide this functionality.
The AMT protocol is specifically designed to support rapid deployment by requiring minimal changes to existing network infrastructure. |
|
| |
| RFC 7453 | MPLS Transport Profile (MPLS-TP) Traffic Engineering (TE) Management Information Base (MIB) |
| |
| Authors: | V. Mahalingam, K. Sampath, S. Aldrin, T. Nadeau. |
| Date: | February 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7453 |
|
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 and textual conventions for tunnels, identifiers, and Label Switching Routers to support Multiprotocol Label Switching (MPLS) MIB modules for transport networks. |
|
| |
| RFC 7455 | Transparent Interconnection of Lots of Links (TRILL): Fault Management |
| |
| Authors: | T. Senevirathne, N. Finn, S. Salam, D. Kumar, D. Eastlake 3rd, S. Aldrin, Y. Li. |
| Date: | March 2015 |
| Formats: | txt html json |
| Updates: | RFC 6325 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7455 |
|
This document specifies Transparent Interconnection of Lots of Links(TRILL) Operations, Administration, and Maintenance (OAM) fault management. Methods in this document follow the CFM (ConnectivityFault Management) framework defined in IEEE 802.1 and reuse OAM tools where possible. Additional messages and TLVs are defined for TRILL- specific applications or for cases where a different set of information is required other than CFM as defined in IEEE 802.1.This document updates RFC 6325. |
|
| |
| RFC 7456 | Loss and Delay Measurement in Transparent Interconnection of Lots of Links (TRILL) |
| |
| Authors: | T. Mizrahi, T. Senevirathne, S. Salam, D. Kumar, D. Eastlake 3rd. |
| Date: | March 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7456 |
|
Performance Monitoring (PM) is a key aspect of Operations,Administration, and Maintenance (OAM). It allows network operators to verify the Service Level Agreement (SLA) provided to customers and to detect network anomalies. This document specifies mechanisms forLoss Measurement and Delay Measurement in Transparent Interconnection of Lots of Links (TRILL) networks. |
|
| |
| RFC 7459 | Representation of Uncertainty and Confidence in the Presence Information Data Format Location Object (PIDF-LO) |
| |
|
|
This document defines key concepts of uncertainty and confidence as they pertain to location information. Methods for the manipulation of location estimates that include uncertainty information are outlined.
This document normatively updates the definition of location information representations defined in RFCs 4119 and 5491. It also deprecates related terminology defined in RFC 3693. |
|
| |
| RFC 7460 | Monitoring and Control MIB for Power and Energy |
| |
| Authors: | M. Chandramouli, B. Claise, B. Schoening, J. Quittek, T. Dietz. |
| Date: | March 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7460 |
|
This document defines a subset of the Management Information Base(MIB) for power and energy monitoring of devices. |
|
| |
| RFC 7461 | Energy Object Context MIB |
| |
| Authors: | J. Parello, B. Claise, M. Chandramouli. |
| Date: | March 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7461 |
|
This document defines a subset of a Management Information Base (MIB) for energy management of devices. The module addresses device identification, context information, and the energy relationships between devices. |
|
| |
| RFC 7462 | URNs for the Alert-Info Header Field of the Session Initiation Protocol (SIP) |
| |
| Authors: | L. Liess, Ed., R. Jesske, A. Johnston, D. Worley, P. Kyzivat. |
| Date: | March 2015 |
| Formats: | txt json html |
| Updates: | RFC 3261 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7462 |
|
The Session Initiation Protocol (SIP) supports the capability to provide a reference to a specific rendering to be used by the UserAgent (UA) as an alerting signal (e.g., a ring tone or ringback tone) when the user is alerted. This is done using the Alert-Info header field. However, the reference (typically a URL) addresses only a specific network resource with specific rendering properties. There is currently no support for standard identifiers for describing the semantics of the alerting situation or the characteristics of the alerting signal, without being tied to a particular rendering. To overcome these limitations and support new applications, a new family of URNs for use in Alert-Info header fields (and situations with similar requirements) is defined in this specification.
This document normatively updates RFC 3261, which defines the SessionInitiation Protocol (SIP). It changes the usage of the Alert-Info header field defined in RFC 3261 by additionally allowing its use in any non-100 provisional response to INVITE. This document also permits proxies to add or remove an Alert-Info header field and to add or remove Alert-Info header field values. |
|
| |
| RFC 7463 | Shared Appearances of a Session Initiation Protocol (SIP) Address of Record (AOR) |
| |
| Authors: | A. Johnston, Ed., M. Soroushnejad, Ed., V. Venkataramanan. |
| Date: | March 2015 |
| Formats: | txt json html |
| Updates: | RFC 3261, RFC 4235 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7463 |
|
This document describes the requirements and implementation of a group telephony feature commonly known as Bridged Line Appearance(BLA) or Multiple Line Appearance (MLA), or Shared Call/LineAppearance (SCA). When implemented using the Session InitiationProtocol (SIP), it is referred to as shared appearances of an Address of Record (AOR) since SIP does not have the concept of lines. This feature is commonly offered in IP Centrex services and IP PrivateBranch Exchange (IPBX) offerings and is likely to be implemented onSIP IP telephones and SIP feature servers used in a business environment. This feature allows several user agents (UAs) to share a common AOR, learn about calls placed and received by other UAs in the group, and pick up or join calls within the group. This document discusses use cases, lists requirements, and defines extensions to implement this feature. This specification updates RFCs 3261 and4235. |
|
| |
| RFC 7464 | JavaScript Object Notation (JSON) Text Sequences |
| |
| Authors: | N. Williams. |
| Date: | February 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7464 |
|
This document describes the JavaScript Object Notation (JSON) text sequence format and associated media type "application/json-seq". AJSON text sequence consists of any number of JSON texts, all encoded in UTF-8, each prefixed by an ASCII Record Separator (0x1E), and each ending with an ASCII Line Feed character (0x0A). |
|
| |
| RFC 7465 | Prohibiting RC4 Cipher Suites |
| |
|
|
This document requires that Transport Layer Security (TLS) clients and servers never negotiate the use of RC4 cipher suites when they establish connections. This applies to all TLS versions. This document updates RFCs 5246, 4346, and 2246. |
|
| |
| RFC 7466 | An Optimization for the Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP) |
| |
|
|
The link quality mechanism of the Mobile Ad Hoc Network (MANET)Neighborhood Discovery Protocol (NHDP) enables "ignoring" some 1-hop neighbors if the measured link quality from that 1-hop neighbor is below an acceptable threshold while still retaining the corresponding link information as acquired from the HELLO message exchange. This allows immediate reinstatement of the 1-hop neighbor if the link quality later improves sufficiently.
NHDP also collects information about symmetric 2-hop neighbors.However, it specifies that if a link from a symmetric 1-hop neighbor ceases being symmetric, including while "ignored" (as described above), then corresponding symmetric 2-hop neighbors are removed.This may lead to symmetric 2-hop neighborhood information being permanently removed (until further HELLO messages are received) if the link quality of a symmetric 1-hop neighbor drops below the acceptable threshold, even if only for a moment.
This specification updates RFC 6130 "Mobile Ad Hoc Network (MANET)Neighborhood Discovery Protocol (NHDP)" and RFC 7181 "The OptimizedLink State Routing Protocol Version 2 (OLSRv2)" to permit, as an option, retaining, but ignoring, symmetric 2-hop information when the link quality from the corresponding 1-hop neighbor drops below the acceptable threshold. This allows immediate reinstatement of the symmetric 2-hop neighbor if the link quality later improves sufficiently, thus making the symmetric 2-hop neighborhood more"robust". |
|
| |
| RFC 7468 | Textual Encodings of PKIX, PKCS, and CMS Structures |
| |
| Authors: | S. Josefsson, S. Leonard. |
| Date: | April 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7468 |
|
This document describes and discusses the textual encodings of thePublic-Key Infrastructure X.509 (PKIX), Public-Key CryptographyStandards (PKCS), and Cryptographic Message Syntax (CMS). The textual encodings are well-known, are implemented by several applications and libraries, and are widely deployed. This document articulates the de facto rules by which existing implementations operate and defines them so that future implementations can interoperate. |
|
| |
| RFC 7469 | Public Key Pinning Extension for HTTP |
| |
| Authors: | C. Evans, C. Palmer, R. Sleevi. |
| Date: | April 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7469 |
|
This document defines a new HTTP header that allows web host operators to instruct user agents to remember ("pin") the hosts' cryptographic identities over a period of time. During that time, user agents (UAs) will require that the host presents a certificate chain including at least one Subject Public Key Info structure whose fingerprint matches one of the pinned fingerprints for that host. By effectively reducing the number of trusted authorities who can authenticate the domain during the lifetime of the pin, pinning may reduce the incidence of man-in-the-middle attacks due to compromisedCertification Authorities. |
|
| |
| RFC 7470 | Conveying Vendor-Specific Constraints in the Path Computation Element Communication Protocol |
| |
|
|
The Path Computation Element Communication Protocol (PCEP) is used to convey path computation requests and responses both between PathComputation Clients (PCCs) and Path Computation Elements (PCEs) and between cooperating PCEs. In PCEP, the path computation requests carry details of the constraints and objective functions that the PCC wishes the PCE to apply in its computation.
This document defines a facility to carry vendor-specific information in PCEP using a dedicated object and a new Type-Length-Value (TLV) that can be carried in any PCEP object that supports TLVs.
This document obsoletes RFC 7150. The only changes from that document are a clarification of the use of the new Type-Length-Value and the allocation of a different code point for the VENDOR-INFORMATION object. |
|
| |
| RFC 7471 | OSPF Traffic Engineering (TE) Metric Extensions |
| |
| Authors: | S. Giacalone, D. Ward, J. Drake, A. Atlas, S. Previdi. |
| Date: | March 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7471 |
|
In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network performance information (e.g., link propagation delay) is becoming critical to data path selection.
This document describes common extensions to RFC 3630 "TrafficEngineering (TE) Extensions to OSPF Version 2" and RFC 5329 "TrafficEngineering Extensions to OSPF Version 3" to enable network performance information to be distributed in a scalable fashion. The information distributed using OSPF TE Metric Extensions can then be used to make path selection decisions based on network performance.
Note that this document only covers the mechanisms by which network performance information is distributed. The mechanisms for measuring network performance information or using that information, once distributed, are outside the scope of this document. |
|
| |
| RFC 7472 | Internet Printing Protocol (IPP) over HTTPS Transport Binding and the 'ipps' URI Scheme |
| |
|
|
This document defines the Internet Printing Protocol (IPP) over HTTPS transport binding and the corresponding 'ipps' URI scheme, which is used to designate the access to the network location of a secure IPP print service or a network resource managed by such a service.
This document defines an alternate IPP transport binding to that defined in the original IPP URL Scheme (RFC 3510), but this document does not update or obsolete RFC 3510.
This document updates RFCs 2910 and 2911. |
|
| |
| RFC 7473 | Controlling State Advertisements of Non-negotiated LDP Applications |
| |
|
|
There is no capability negotiation done for Label DistributionProtocol (LDP) applications that set up Label Switched Paths (LSPs) for IP prefixes or that signal point-to-point (P2P) Pseudowires (PWs) for Layer 2 Virtual Private Networks (L2VPNs). When an LDP session comes up, an LDP speaker may unnecessarily advertise its local state for such LDP applications even when the peer session is established for some other applications like Multipoint LDP (mLDP) or the Inter-Chassis Communication Protocol (ICCP). This document defines a solution by which an LDP speaker announces to its peer its disinterest in such non-negotiated applications, thus disabling the unnecessary advertisement of corresponding application state, which would have otherwise been advertised over the established LDP session. |
|
| |
| RFC 7474 | Security Extension for OSPFv2 When Using Manual Key Management |
| |
|
|
The current OSPFv2 cryptographic authentication mechanism as defined in RFCs 2328 and 5709 is vulnerable to both inter-session and intra- session replay attacks when using manual keying. Additionally, the existing cryptographic authentication mechanism does not cover the IP header. This omission can be exploited to carry out various types of attacks.
This document defines changes to the authentication sequence number mechanism that will protect OSPFv2 from both inter-session and intra- session replay attacks when using manual keys for securing OSPFv2 protocol packets. Additionally, we also describe some changes in the cryptographic hash computation that will eliminate attacks resulting from OSPFv2 not protecting the IP header. |
|
| |
| RFC 7477 | Child-to-Parent Synchronization in DNS |
| |
| Authors: | W. Hardaker. |
| Date: | March 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7477 |
|
This document specifies how a child zone in the DNS can publish a record to indicate to a parental agent that the parental agent may copy and process certain records from the child zone. The existence of the record and any change in its value can be monitored by a parental agent and acted on depending on local policy. |
|
| |
| RFC 7482 | Registration Data Access Protocol (RDAP) Query Format |
| |
| Authors: | A. Newton, S. Hollenbeck. |
| Date: | March 2015 |
| Formats: | txt json html |
| Obsoleted by: | RFC 9082 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7482 |
|
This document describes uniform patterns to construct HTTP URLs that may be used to retrieve registration information from registries(including both Regional Internet Registries (RIRs) and Domain NameRegistries (DNRs)) using "RESTful" web access patterns. These uniform patterns define the query syntax for the Registration DataAccess Protocol (RDAP). |
|
| |
| RFC 7483 | JSON Responses for the Registration Data Access Protocol (RDAP) |
| |
| Authors: | A. Newton, S. Hollenbeck. |
| Date: | March 2015 |
| Formats: | txt json html |
| Obsoleted by: | RFC 9083 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7483 |
|
This document describes JSON data structures representing registration information maintained by Regional Internet Registries(RIRs) and Domain Name Registries (DNRs). These data structures are used to form Registration Data Access Protocol (RDAP) query responses. |
|
| |
| RFC 7484 | Finding the Authoritative Registration Data (RDAP) Service |
| |
|
|
This document specifies a method to find which Registration DataAccess Protocol (RDAP) server is authoritative to answer queries for a requested scope, such as domain names, IP addresses, or AutonomousSystem numbers. |
|
| |
| RFC 7487 | Configuration of Proactive Operations, Administration, and Maintenance (OAM) Functions for MPLS-Based Transport Networks Using RSVP-TE |
| |
| Authors: | E. Bellagamba, A. Takacs, G. Mirsky, L. Andersson, P. Skoldstrom, D. Ward. |
| Date: | March 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7487 |
|
This specification describes the configuration of proactive MPLSTransport Profile (MPLS-TP) Operations, Administration, andMaintenance (OAM) functions for a given Label Switched Path (LSP) using a set of TLVs that are carried by the GMPLS RSVP-TE protocol based on the OAM Configuration Framework for GMPLS RSVP-TE. |
|
| |
| RFC 7488 | Port Control Protocol (PCP) Server Selection |
| |
| Authors: | M. Boucadair, R. Penno, D. Wing, P. Patil, T. Reddy. |
| Date: | March 2015 |
| Formats: | txt html json |
| Updates: | RFC 6887 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7488 |
|
This document specifies the behavior to be followed by a Port ControlProtocol (PCP) client to contact its PCP server(s) when one or several PCP server IP addresses are configured.
This document updates RFC 6887. |
|
| |
| RFC 7490 | Remote Loop-Free Alternate (LFA) Fast Reroute (FRR) |
| |
| Authors: | S. Bryant, C. Filsfils, S. Previdi, M. Shand, N. So. |
| Date: | April 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7490 |
|
This document describes an extension to the basic IP fast reroute mechanism, described in RFC 5286, that provides additional backup connectivity for point-to-point link failures when none can be provided by the basic mechanisms. |
|
| |
| RFC 7493 | The I-JSON Message Format |
| |
| Authors: | T. Bray, Ed.. |
| Date: | March 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7493 |
|
I-JSON (short for "Internet JSON") is a restricted profile of JSON designed to maximize interoperability and increase confidence that software can process it successfully with predictable results. |
|
| |
| RFC 7494 | IEEE 802.11 Medium Access Control (MAC) Profile for Control and Provisioning of Wireless Access Points (CAPWAP) |
| |
| Authors: | C. Shao, H. Deng, R. Pazhyannur, F. Bari, R. Zhang, S. Matsushima. |
| Date: | April 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7494 |
|
The Control and Provisioning of Wireless Access Points (CAPWAP) protocol binding for IEEE 802.11 defines two Medium Access Control(MAC) modes for IEEE 802.11 Wireless Transmission Points (WTPs):Split and Local MAC. In the Split MAC mode, the partitioning of encryption/decryption functions is not clearly defined. In the SplitMAC mode description, IEEE 802.11 encryption is specified as located in either the Access Controller (AC) or the WTP, with no clear way for the AC to inform the WTP of where the encryption functionality should be located. This leads to interoperability issues, especially when the AC and WTP come from different vendors. To prevent interoperability issues, this specification defines an IEEE 802.11MAC Profile message element in which each profile specifies an unambiguous division of encryption functionality between the WTP andAC. |
|
| |
| RFC 7495 | Enumeration Reference Format for the Incident Object Description Exchange Format (IODEF) |
| |
| Authors: | A. Montville, D. Black. |
| Date: | March 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7495 |
|
The Incident Object Description Exchange Format (IODEF) is an XML data representation framework for sharing information about computer security incidents. In IODEF, the Reference class provides references to externally specified information such as a vulnerability, Intrusion Detection System (IDS) alert, malware sample, advisory, or attack technique. In practice, these references are based on external enumeration specifications that define both the enumeration format and the specific enumeration values, but the IODEFReference class (as specified in IODEF v1 in RFC 5070) does not indicate how to include both of these important pieces of information.
This document establishes a stand-alone data format to include both the external specification and specific enumeration identification value, and establishes an IANA registry to manage external enumeration specifications. While this document does not updateIODEF v1, this enumeration reference format is used in IODEF v2 and is applicable to other formats that support this class of enumeration references. |
|
| |
| RFC 7496 | Additional Policies for the Partially Reliable Stream Control Transmission Protocol Extension |
| |
| Authors: | M. Tuexen, R. Seggelmann, R. Stewart, S. Loreto. |
| Date: | April 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7496 |
|
This document defines two additional policies for the PartiallyReliable Stream Control Transmission Protocol (PR-SCTP) extension.These policies allow limitation of the number of retransmissions and prioritization of user messages for more efficient usage of the send buffer. |
|
| |
| RFC 7503 | OSPFv3 Autoconfiguration |
| |
|
|
OSPFv3 is a candidate for deployments in environments where autoconfiguration is a requirement. One such environment is the IPv6 home network where users expect to simply plug in a router and have it automatically use OSPFv3 for intra-domain routing. This document describes the necessary mechanisms for OSPFv3 to be self-configuring.This document updates RFC 5340 by relaxing the HelloInterval/RouterDeadInterval checking during OSPFv3 adjacency formation and adding hysteresis to the update of self-originated Link StateAdvertisements (LSAs). |
|
| |
| RFC 7504 | SMTP 521 and 556 Reply Codes |
| |
|
|
This memo defines two Simple Mail Transfer Protocol (SMTP) reply codes, 521 and 556. The 521 code was originally described in anExperimental RFC in 1995 and is in wide use, but has not previously been formally incorporated into SMTP. The 556 code was created to support the new tests and actions specified in RFC 7505. These codes are used to indicate that an Internet host does not accept incoming mail at all. This specification is not applicable when the host sometimes accepts mail but may reject particular messages, or even all messages, under specific circumstances. |
|
| |
| RFC 7505 | A "Null MX" No Service Resource Record for Domains That Accept No Mail |
| |
| Authors: | J. Levine, M. Delany. |
| Date: | June 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7505 |
|
Internet mail determines the address of a receiving server through the DNS, first by looking for an MX record and then by looking for anA/AAAA record as a fallback. Unfortunately, this means that theA/AAAA record is taken to be mail server address even when that address does not accept mail. The No Service MX RR, informally called "null MX", formalizes the existing mechanism by which a domain announces that it accepts no mail, without having to provide a mail server; this permits significant operational efficiencies. |
|
| |
| RFC 7506 | IPv6 Router Alert Option for MPLS Operations, Administration, and Maintenance (OAM) |
| |
| Authors: | K. Raza, N. Akiya, C. Pignataro. |
| Date: | April 2015 |
| Formats: | txt json html |
| Updates: | RFC 4379 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7506 |
|
RFC 4379 defines the MPLS Label Switched Path (LSP) Ping/Traceroute mechanism in which the Router Alert Option (RAO) MUST be set in theIP header of the MPLS Echo Request messages and may conditionally be set in the IP header of the MPLS Echo Reply messages depending on theReply Mode used. While a generic "Router shall examine packet"Option Value is used for the IPv4 RAO, there is no generic RAO value defined for IPv6 that can be used. This document allocates a new, generic IPv6 RAO value that can be used by MPLS Operations,Administration, and Maintenance (OAM) tools, including the MPLS EchoRequest and MPLS Echo Reply messages for MPLS in IPv6 environments.Consequently, it updates RFC 4379.
The initial motivation to request an IPv6 RAO value for MPLS OAM comes from the MPLS LSP Ping/Traceroute. However, this value is applicable to all MPLS OAM and not limited to MPLS LSP Ping/Traceroute. |
|
| |
| RFC 7507 | TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks |
| |
|
|
This document defines a Signaling Cipher Suite Value (SCSV) that prevents protocol downgrade attacks on the Transport Layer Security(TLS) and Datagram Transport Layer Security (DTLS) protocols. It updates RFCs 2246, 4346, 4347, 5246, and 6347. Server update considerations are included. |
|
| |
| RFC 7509 | RTP Control Protocol (RTCP) Extended Report (XR) for Post-Repair Loss Count Metrics |
| |
| Authors: | R. Huang, V. Singh. |
| Date: | May 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7509 |
|
This document defines an RTP Control Protocol (RTCP) Extended Report(XR) block that allows reporting of a post-repair loss count metric for a range of RTP applications. In addition, another metric, repaired loss count, is also introduced in this report block for calculating the pre-repair loss count when needed, so that the RTP sender or a third-party entity is able to evaluate the effectiveness of the repair methods used by the system. |
|
| |
| RFC 7510 | Encapsulating MPLS in UDP |
| |
| Authors: | X. Xu, N. Sheth, L. Yong, R. Callon, D. Black. |
| Date: | April 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7510 |
|
This document specifies an IP-based encapsulation for MPLS, calledMPLS-in-UDP for situations where UDP (User Datagram Protocol) encapsulation is preferred to direct use of MPLS, e.g., to enableUDP-based ECMP (Equal-Cost Multipath) or link aggregation. The MPLS- in-UDP encapsulation technology must only be deployed within a single network (with a single network operator) or networks of an adjacent set of cooperating network operators where traffic is managed to avoid congestion, rather than over the Internet where congestion control is required. Usage restrictions apply to MPLS-in-UDP usage for traffic that is not congestion controlled and to UDP zero checksum usage with IPv6. |
|
| |
| RFC 7512 | The PKCS #11 URI Scheme |
| |
| Authors: | J. Pechanec, D. Moffat. |
| Date: | April 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7512 |
|
This memo specifies a PKCS #11 Uniform Resource Identifier (URI)Scheme for identifying PKCS #11 objects stored in PKCS #11 tokens and also for identifying PKCS #11 tokens, slots, or libraries. The URI scheme is based on how PKCS #11 objects, tokens, slots, and libraries are identified in "PKCS #11 v2.20: Cryptographic Token InterfaceStandard". |
|
| |
| RFC 7513 | Source Address Validation Improvement (SAVI) Solution for DHCP |
| |
| Authors: | J. Bi, J. Wu, G. Yao, F. Baker. |
| Date: | May 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7513 |
|
This document specifies the procedure for creating a binding between a DHCPv4/DHCPv6-assigned IP address and a binding anchor on a SourceAddress Validation Improvement (SAVI) device. The bindings set up by this procedure are used to filter packets with forged source IP addresses. This mechanism complements BCP 38 (RFC 2827) ingress filtering, providing finer-grained source IP address validation. |
|
| |
| RFC 7515 | JSON Web Signature (JWS) |
| |
| Authors: | M. Jones, J. Bradley, N. Sakimura. |
| Date: | May 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7515 |
|
JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON WebAlgorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification. |
|
| |
| RFC 7516 | JSON Web Encryption (JWE) |
| |
| Authors: | M. Jones, J. Hildebrand. |
| Date: | May 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7516 |
|
JSON Web Encryption (JWE) represents encrypted content usingJSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSONWeb Algorithms (JWA) specification and IANA registries defined by that specification. Related digital signature and MessageAuthentication Code (MAC) capabilities are described in the separateJSON Web Signature (JWS) specification. |
|
| |
| RFC 7517 | JSON Web Key (JWK) |
| |
| Authors: | M. Jones. |
| Date: | May 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7517 |
|
A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set ofJWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification. |
|
| |
| RFC 7518 | JSON Web Algorithms (JWA) |
| |
| Authors: | M. Jones. |
| Date: | May 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7518 |
|
This specification registers cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption(JWE), and JSON Web Key (JWK) specifications. It defines severalIANA registries for these identifiers. |
|
| |
| RFC 7519 | JSON Web Token (JWT) |
| |
|
|
JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSONWeb Signature (JWS) structure or as the plaintext of a JSON WebEncryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code(MAC) and/or encrypted. |
|
| |
| RFC 7521 | Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants |
| |
| Authors: | B. Campbell, C. Mortimore, M. Jones, Y. Goland. |
| Date: | May 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7521 |
|
This specification provides a framework for the use of assertions with OAuth 2.0 in the form of a new client authentication mechanism and a new authorization grant type. Mechanisms are specified for transporting assertions during interactions with a token endpoint; general processing rules are also specified.
The intent of this specification is to provide a common framework forOAuth 2.0 to interwork with other identity systems using assertions and to provide alternative client authentication mechanisms.
Note that this specification only defines abstract message flows and processing rules. In order to be implementable, companion specifications are necessary to provide the corresponding concrete instantiations. |
|
| |
| RFC 7522 | Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants |
| |
| Authors: | B. Campbell, C. Mortimore, M. Jones. |
| Date: | May 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7522 |
|
This specification defines the use of a Security Assertion MarkupLanguage (SAML) 2.0 Bearer Assertion as a means for requesting anOAuth 2.0 access token as well as for client authentication. |
|
| |
| RFC 7523 | JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants |
| |
| Authors: | M. Jones, B. Campbell, C. Mortimore. |
| Date: | May 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7523 |
|
This specification defines the use of a JSON Web Token (JWT) BearerToken as a means for requesting an OAuth 2.0 access token as well as for client authentication. |
|
| |
| RFC 7524 | Inter-Area Point-to-Multipoint (P2MP) Segmented Label Switched Paths (LSPs) |
| |
| Authors: | Y. Rekhter, E. Rosen, R. Aggarwal, T. Morin, I. Grosclaude, N. Leymann, S. Saad. |
| Date: | May 2015 |
| Formats: | txt html json |
| Updated by: | RFC 8534 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7524 |
|
This document describes procedures for building inter-area point-to- multipoint (P2MP) segmented service label switched paths (LSPs) by partitioning such LSPs into intra-area segments and using BGP as the inter-area routing and Label Distribution Protocol (LDP). Within each IGP area, the intra-area segments are either carried over intra- area P2MP LSPs, using P2MP LSP hierarchy, or instantiated using ingress replication. The intra-area P2MP LSPs may be signaled usingP2MP RSVP-TE or P2MP multipoint LDP (mLDP). If ingress replication is used within an IGP area, then (multipoint-to-point) LDP LSPs or(point-to-point) RSVP-TE LSPs may be used in the IGP area. The applications/services that use such inter-area service LSPs may beBGP Multicast VPN, Virtual Private LAN Service (VPLS) multicast, or global table multicast over MPLS. |
|
| |
| RFC 7527 | Enhanced Duplicate Address Detection |
| |
|
|
IPv6 Loopback Suppression and Duplicate Address Detection (DAD) are discussed in Appendix A of RFC 4862. That specification mentions a hardware-assisted mechanism to detect looped back DAD messages. If hardware cannot suppress looped back DAD messages, a software solution is required. Several service provider communities have expressed a need for automated detection of looped back NeighborDiscovery (ND) messages used by DAD. This document includes mitigation techniques and outlines the Enhanced DAD algorithm to automate the detection of looped back IPv6 ND messages used by DAD.For network loopback tests, the Enhanced DAD algorithm allows IPv6 to self-heal after a loopback is placed and removed. Further, for certain access networks, this document automates resolving a specific duplicate address conflict. This document updates RFCs 4429, 4861, and 4862. |
|
| |
| RFC 7529 | Non-Gregorian Recurrence Rules in the Internet Calendaring and Scheduling Core Object Specification (iCalendar) |
| |
|
|
This document defines extensions to the Internet Calendaring andScheduling Core Object Specification (iCalendar) (RFC 5545) to support use of non-Gregorian recurrence rules. It also defines howCalendaring Extensions to WebDAV (CalDAV) (RFC 4791) servers and clients can be extended to support these new recurrence rules. |
|
| |
| RFC 7530 | Network File System (NFS) Version 4 Protocol |
| |
|
|
The Network File System (NFS) version 4 protocol is a distributed file system protocol that builds on the heritage of 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 has been added. Of course, attention has been applied to making NFS version 4 operate well in an Internet environment.
This document, together with the companion External DataRepresentation (XDR) description document, RFC 7531, obsoletes RFC3530 as the definition of the NFS version 4 protocol. |
|
| |
| RFC 7531 | Network File System (NFS) Version 4 External Data Representation Standard (XDR) Description |
| |
| Authors: | T. Haynes, Ed., D. Noveck, Ed.. |
| Date: | March 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7531 |
|
The Network File System (NFS) version 4 protocol is a distributed file system protocol that owes its heritage to NFS protocol version 2(RFC 1094) and version 3 (RFC 1813). Unlike earlier versions, theNFS 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 has been added.Of course, attention has been applied to making NFS version 4 operate well in an Internet environment.
RFC 7530 formally obsoletes RFC 3530. This document, together withRFC 7530, replaces RFC 3530 as the definition of the NFS version 4 protocol. |
|
| |
| RFC 7532 | Namespace Database (NSDB) Protocol for Federated File Systems |
| |
| Authors: | J. Lentini, R. Tewari, C. Lever, Ed.. |
| Date: | March 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7532 |
|
This document describes a file system federation protocol that enables file access and namespace traversal across collections of independently administered fileservers. The protocol specifies a set of interfaces by which fileservers with different administrators can form a fileserver federation that provides a namespace composed of the file systems physically hosted on and exported by the constituent fileservers. |
|
| |
| RFC 7533 | Administration Protocol for Federated File Systems |
| |
| Authors: | J. Lentini, R. Tewari, C. Lever, Ed.. |
| Date: | March 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7533 |
|
This document describes the administration protocol for a federated file system (FedFS) that enables file access and namespace traversal across collections of independently administered fileservers. The protocol specifies a set of interfaces by which fileservers with different administrators can form a fileserver federation that provides a namespace composed of the file systems physically hosted on and exported by the constituent fileservers. |
|
| |
| RFC 7537 | IANA Registries for LSP Ping Code Points |
| |
|
|
RFCs 4379 and 6424 created name spaces for Multi-Protocol LabelSwitching (MPLS) Label Switched Path (LSP) Ping. However, those RFCs did not create the corresponding IANA registries for DownstreamMapping object Flags (DS Flags), Multipath Types, Pad TLVs, andInterface and Label Stack Address Types.
There is now a need to make further code point allocations from these name spaces. This document updates RFCs 4379 and 6424 in that it creates IANA registries for that purpose. |
|
| |
| RFC 7538 | The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect) |
| |
|
|
This document specifies the additional Hypertext Transfer Protocol(HTTP) status code 308 (Permanent Redirect). |
|
| |
| RFC 7540 | Hypertext Transfer Protocol Version 2 (HTTP/2) |
| |
|
|
This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection. It also introduces unsolicited push of representations from servers to clients.
This specification is an alternative to, but does not obsolete, theHTTP/1.1 message syntax. HTTP's existing semantics remain unchanged. |
|
| |
| RFC 7541 | HPACK: Header Compression for HTTP/2 |
| |
| Authors: | R. Peon, H. Ruellan. |
| Date: | May 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7541 |
|
This specification defines HPACK, a compression format for efficiently representing HTTP header fields, to be used in HTTP/2. |
|
| |
| RFC 7542 | The Network Access Identifier |
| |
|
|
In order to provide inter-domain authentication services, it is necessary to have a standardized method that domains can use to identify each other's users. This document defines the syntax for the Network Access Identifier (NAI), the user identifier submitted by the client prior to accessing resources. This document is a revised version of RFC 4282. It addresses issues with international character sets and makes a number of other corrections to RFC 4282. |
|
| |
| RFC 7543 | Covering Prefixes Outbound Route Filter for BGP-4 |
| |
| Authors: | H. Jeng, L. Jalil, R. Bonica, K. Patel, L. Yong. |
| Date: | May 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7543 |
|
This document defines a new Outbound Route Filter (ORF) type, called the Covering Prefixes ORF (CP-ORF). CP-ORF is applicable in VirtualHub-and-Spoke VPNs. It also is applicable in BGP/MPLS Ethernet VPN(EVPN) networks. |
|
| |
| RFC 7545 | Protocol to Access White-Space (PAWS) Databases |
| |
| Authors: | V. Chen, Ed., S. Das, L. Zhu, J. Malyar, P. McCann. |
| Date: | May 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7545 |
|
Portions of the radio spectrum that are allocated to licensees are available for non-interfering use. This available spectrum is called"white space". Allowing secondary users access to available spectrum"unlocks" existing spectrum to maximize its utilization and to provide opportunities for innovation, resulting in greater overall spectrum utilization.
One approach to managing spectrum sharing uses databases to report spectrum availability to devices. To achieve interoperability among multiple devices and databases, a standardized protocol must be defined and implemented. This document defines such a protocol, the"Protocol to Access White-Space (PAWS) Databases". |
|
| |
| RFC 7549 | 3GPP SIP URI Inter-Operator Traffic Leg Parameter |
| |
| Authors: | C. Holmberg, J. Holm, R. Jesske, M. Dolly. |
| Date: | May 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7549 |
|
In 3GPP networks, the signaling path between a calling user and a called user can be partitioned into segments, referred to as traffic legs. Each traffic leg may span networks belonging to different operators and will have its own characteristics that can be different from other traffic legs in the same call. A traffic leg might be associated with multiple SIP dialogs, e.g., in case a Back-to-BackUser Agent (B2BUA) that modifies the SIP dialog identifier is located within the traffic leg.
This document defines a new SIP URI parameter, 'iotl' (an abbreviation for Inter-Operator Traffic Leg). The parameter can be used in a SIP URI to indicate that the entity associated with the address, or an entity responsible for the host part of the address, represents the end of a specific traffic leg (or multiple traffic legs).
The SIP URI 'iotl' parameter defined in this document has known uses in 3GPP networks. Usage in other networks is also possible. |
|
| |
| RFC 7550 | Issues and Recommendations with Multiple Stateful DHCPv6 Options |
| |
|
|
The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) specification defined two stateful options, IA_NA and IA_TA, but did not anticipate the development of additional stateful options.DHCPv6 Prefix Delegation added the IA_PD option, which is stateful.Applications that use IA_NA and IA_PD together have revealed issues that need to be addressed. This document updates RFCs 3315 and 3633 to address these issues. |
|
| |
| RFC 7551 | RSVP-TE Extensions for Associated Bidirectional Label Switched Paths (LSPs) |
| |
| Authors: | F. Zhang, Ed., R. Jing, R. Gandhi, Ed.. |
| Date: | May 2015 |
| Formats: | txt json html |
| Updated by: | RFC 8537 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7551 |
|
This document describes Resource Reservation Protocol (RSVP) extensions to bind two point-to-point unidirectional Label SwitchedPaths (LSPs) into an associated bidirectional LSP. The association is achieved by defining new Association Types for use in ASSOCIATION and in Extended ASSOCIATION Objects. One of these types enables independent provisioning of the associated bidirectional LSPs on both sides, while the other enables single-sided provisioning. TheREVERSE_LSP Object is also defined to enable a single endpoint to trigger creation of the reverse LSP and to specify parameters of the reverse LSP in the single-sided provisioning case. |
|
| |
| RFC 7552 | Updates to LDP for IPv6 |
| |
|
|
The Label Distribution Protocol (LDP) specification defines procedures to exchange label bindings over either IPv4 or IPv6 networks, or both. This document corrects and clarifies the LDP behavior when an IPv6 network is used (with or without IPv4). This document updates RFCs 5036 and 6720. |
|
| |
| RFC 7555 | Proxy MPLS Echo Request |
| |
| Authors: | G. Swallow, V. Lim, S. Aldrin. |
| Date: | June 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7555 |
|
This document defines a means of remotely initiating MultiprotocolLabel Switched Protocol (MPLS) Pings on Label Switched Paths. AnMPLS Proxy Ping Request is sent to any Label Switching Router along aLabel Switched Path. The primary motivations for this facility are first to limit the number of messages and related processing when using LSP Ping in large Point-to-Multipoint LSPs, and second to enable tracing from leaf to leaf (or root). |
|
| |
| RFC 7559 | Packet-Loss Resiliency for Router Solicitations |
| |
| Authors: | S. Krishnan, D. Anipko, D. Thaler. |
| Date: | May 2015 |
| Formats: | txt json html |
| Updates: | RFC 4861 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7559 |
|
When an interface on a host is initialized, the host transmits RouterSolicitations in order to minimize the amount of time it needs to wait until the next unsolicited multicast Router Advertisement is received. In certain scenarios, these Router Solicitations transmitted by the host might be lost. This document specifies a mechanism for hosts to cope with the loss of the initial RouterSolicitations. |
|
| |
| RFC 7563 | Extensions to the Proxy Mobile IPv6 (PMIPv6) Access Network Identifier Option |
| |
| Authors: | R. Pazhyannur, S. Speicher, S. Gundavelli, J. Korhonen, J. Kaippallimalil. |
| Date: | June 2015 |
| Formats: | txt html json |
| Updates: | RFC 6757 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7563 |
|
The Access Network Identifier (ANI) mobility option was introduced inRFC 6757, "Access Network Identifier (ANI) Option for Proxy MobileIPv6". This enables a Mobile Access Gateway (MAG) to convey identifiers like the network identifier, geolocation, and operator identifier. This specification extends the Access Network Identifier mobility option with sub-options to carry the civic location and theMAG group identifier. This specification also defines an ANI Update-Timer sub-option that determines when and how often the ANI option will be updated. |
|
| |
| RFC 7564 | PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols |
| |
|
|
Application protocols using Unicode characters in protocol strings need to properly handle such strings in order to enforce internationalization rules for strings placed in various protocol slots (such as addresses and identifiers) and to perform valid comparison operations (e.g., for purposes of authentication or authorization). This document defines a framework enabling application protocols to perform the preparation, enforcement, and comparison of internationalized strings ("PRECIS") in a way that depends on the properties of Unicode characters and thus is agile with respect to versions of Unicode. As a result, this framework provides a more sustainable approach to the handling of internationalized strings than the previous framework, known asStringprep (RFC 3454). This document obsoletes RFC 3454. |
|
| |
| RFC 7565 | The 'acct' URI Scheme |
| |
| Authors: | P. Saint-Andre. |
| Date: | May 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7565 |
|
This document defines the 'acct' Uniform Resource Identifier (URI) scheme as a way to identify a user's account at a service provider, irrespective of the particular protocols that can be used to interact with the account. |
|
| |
| RFC 7568 | Deprecating Secure Sockets Layer Version 3.0 |
| |
| Authors: | R. Barnes, M. Thomson, A. Pironti, A. Langley. |
| Date: | June 2015 |
| Formats: | txt json html |
| Updates: | RFC 5246 |
| Updated by: | RFC 8996 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7568 |
|
The Secure Sockets Layer version 3.0 (SSLv3), as specified in RFC6101, is not sufficiently secure. This document requires that SSLv3 not be used. The replacement versions, in particular, TransportLayer Security (TLS) 1.2 (RFC 5246), are considerably more secure and capable protocols.
This document updates the backward compatibility section of RFC 5246 and its predecessors to prohibit fallback to SSLv3. |
|
| |
| RFC 7569 | Registry Specification for Mandatory Access Control (MAC) Security Label Formats |
| |
| Authors: | D. Quigley, J. Lu, T. Haynes. |
| Date: | July 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7569 |
|
In the past, Mandatory Access Control (MAC) systems have used very rigid policies that were implemented in particular protocols and platforms. As MAC systems become more widely deployed, additional flexibility in mechanism and policy will be required. While traditional trusted systems implemented Multi-Level Security (MLS) and integrity models, modern systems have expanded to include such technologies as type enforcement. Due to the wide range of policies and mechanisms that need to be accommodated, it is unlikely that the use of a single security label format and model will be viable.
To allow multiple MAC mechanisms and label formats to co-exist in a network, this document creates a registry of label format specifications. This registry contains label format identifiers and provides for the association of each such identifier with a corresponding extensive document outlining the exact syntax and use of the particular label format. |
|
| |
| RFC 7570 | Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO) |
| |
| Authors: | C. Margaria, Ed., G. Martinelli, S. Balls, B. Wright. |
| Date: | July 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7570 |
|
RFC 5420 extends RSVP-TE to specify or record generic attributes that apply to the whole of the path of a Label Switched Path (LSP). This document defines an extension to the RSVP Explicit Route Object (ERO) and Record Route Object (RRO) to allow them to specify or record generic attributes that apply to a given hop. |
|
| |
| RFC 7571 | GMPLS RSVP-TE Extensions for Lock Instruct and Loopback |
| |
| Authors: | J. Dong, M. Chen, Z. Li, D. Ceccarelli. |
| Date: | July 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7571 |
|
This document specifies extensions to Resource Reservation Protocol -Traffic Engineering (RSVP-TE) to support Lock Instruct (LI) andLoopback (LB) mechanisms for Label Switched Paths (LSPs). These mechanisms are applicable to technologies that use Generalized MPLS(GMPLS) for the control plane. |
|
| |
| RFC 7572 | Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Instant Messaging |
| |
| Authors: | P. Saint-Andre, A. Houri, J. Hildebrand. |
| Date: | June 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7572 |
|
This document defines a bidirectional protocol mapping for the exchange of single instant messages between the Session InitiationProtocol (SIP) and the Extensible Messaging and Presence Protocol(XMPP). |
|
| |
| RFC 7573 | Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): One-to-One Text Chat Sessions |
| |
| Authors: | P. Saint-Andre, S. Loreto. |
| Date: | June 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7573 |
|
This document defines a bidirectional protocol mapping for the exchange of instant messages in the context of a one-to-one chat session between a user of the Session Initiation Protocol (SIP) and a user of the Extensible Messaging and Presence Protocol (XMPP).Specifically for SIP text chat, this document specifies a mapping to the Message Session Relay Protocol (MSRP). |
|
| |
| RFC 7574 | Peer-to-Peer Streaming Peer Protocol (PPSPP) |
| |
| Authors: | A. Bakker, R. Petrocco, V. Grishchenko. |
| Date: | July 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7574 |
|
The Peer-to-Peer Streaming Peer Protocol (PPSPP) is a protocol for disseminating the same content to a group of interested parties in a streaming fashion. PPSPP supports streaming of both prerecorded (on- demand) and live audio/video content. It is based on the peer-to- peer paradigm, where clients consuming the content are put on equal footing with the servers initially providing the content, to create a system where everyone can potentially provide upload bandwidth. It has been designed to provide short time-till-playback for the end user and to prevent disruption of the streams by malicious peers.PPSPP has also been designed to be flexible and extensible. It can use different mechanisms to optimize peer uploading, prevent freeriding, and work with different peer discovery schemes(centralized trackers or Distributed Hash Tables). It supports multiple methods for content integrity protection and chunk addressing. Designed as a generic protocol that can run on top of various transport protocols, it currently runs on top of UDP usingLow Extra Delay Background Transport (LEDBAT) for congestion control. |
|
| |
| RFC 7577 | Definition of Managed Objects for Battery Monitoring |
| |
| Authors: | J. Quittek, R. Winter, T. Dietz. |
| Date: | July 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7577 |
|
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 managed objects that provide information on the status of batteries in managed devices. |
|
| |
| RFC 7578 | Returning Values from Forms: multipart/form-data |
| |
|
|
This specification defines the multipart/form-data media type, 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. This document obsoletesRFC 2388. |
|
| |
| RFC 7579 | General Network Element Constraint Encoding for GMPLS-Controlled Networks |
| |
| Authors: | G. Bernstein, Ed., Y. Lee, Ed., D. Li, W. Imajuku, J. Han. |
| Date: | June 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7579 |
|
Generalized Multiprotocol Label Switching (GMPLS) can be used to control a wide variety of technologies. In some of these technologies, network elements and links may impose additional routing constraints such as asymmetric switch connectivity, non-local label assignment, and label range limitations on links.
This document provides efficient, protocol-agnostic encodings for general information elements representing connectivity and label constraints as well as label availability. It is intended that protocol-specific documents will reference this memo to describe how information is carried for specific uses. |
|
| |
| RFC 7580 | OSPF-TE Extensions for General Network Element Constraints |
| |
| Authors: | F. Zhang, Y. Lee, J. Han, G. Bernstein, Y. Xu. |
| Date: | June 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7580 |
|
Generalized Multiprotocol Label Switching (GMPLS) can be used to control a wide variety of technologies including packet switching(e.g., MPLS), time division (e.g., Synchronous Optical Network /Synchronous Digital Hierarchy (SONET/SDH) and Optical TransportNetwork (OTN)), wavelength (lambdas), and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). In some of these technologies, network elements and links may impose additional routing constraints such as asymmetric switch connectivity, non- local label assignment, and label range limitations on links. This document describes Open Shortest Path First (OSPF) routing protocol extensions to support these kinds of constraints under the control ofGMPLS. |
|
| |
| RFC 7581 | Routing and Wavelength Assignment Information Encoding for Wavelength Switched Optical Networks |
| |
| Authors: | G. Bernstein, Ed., Y. Lee, Ed., D. Li, W. Imajuku, J. Han. |
| Date: | June 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7581 |
|
A Wavelength Switched Optical Network (WSON) requires certain key information fields be made available to facilitate path computation and the establishment of Label Switched Paths (LSPs). The information model described in "Routing and Wavelength AssignmentInformation Model for Wavelength Switched Optical Networks" (RFC7446) shows what information is required at specific points in theWSON. Part of the WSON information model contains aspects that may be of general applicability to other technologies, while other parts are specific to WSONs.
This document provides efficient, protocol-agnostic encodings for theWSON-specific information fields. It is intended that protocol- specific documents will reference this memo to describe how information is carried for specific uses. Such encodings can be used to extend GMPLS signaling and routing protocols. In addition, these encodings could be used by other mechanisms to convey this same information to a Path Computation Element (PCE). |
|
| |
| RFC 7582 | Multicast Virtual Private Network (MVPN): Using Bidirectional P-Tunnels |
| |
|
|
A set of prior RFCs specify procedures for supporting multicast inBGP/MPLS IP VPNs. These procedures allow customer multicast data to travel across a service provider's backbone network through a set of multicast tunnels. The tunnels are advertised in certain BGP multicast auto-discovery routes, by means of a BGP attribute known as the "Provider Multicast Service Interface (PMSI) Tunnel" attribute. Encodings have been defined that allow the PMSI Tunnel attribute to identify bidirectional (multipoint-to-multipoint) multicast distribution trees. However, the prior RFCs do not provide all the necessary procedures for using bidirectional tunnels to support multicast VPNs. This document updates RFCs 6513, 6514, and6625 by specifying those procedures. In particular, it specifies the procedures for assigning customer multicast flows (unidirectional or bidirectional) to specific bidirectional tunnels in the provider backbone, for advertising such assignments, and for determining which flows have been assigned to which tunnels. |
|
| |
| RFC 7584 | Session Traversal Utilities for NAT (STUN) Message Handling for SIP Back-to-Back User Agents (B2BUAs) |
| |
| Authors: | R. Ravindranath, T. Reddy, G. Salgueiro. |
| Date: | July 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7584 |
|
Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) are often designed to be on the media path rather than just intercepting signaling. This means that B2BUAs often act on the media path leading to separate media legs that the B2BUA correlates and bridges together. When acting on the media path, B2BUAs are likely to receive Session Traversal Utilities for NAT (STUN) packets as part of Interactive Connectivity Establishment (ICE) processing.
This document defines behavior for a B2BUA performing ICE processing.The goal of this document is to ensure that B2BUAs properly handleSIP messages that carry ICE semantics in Session Description Protocol(SDP) and STUN messages received as part of the ICE procedures forNAT and Firewall traversal of multimedia sessions. |
|
| |
| RFC 7587 | RTP Payload Format for the Opus Speech and Audio Codec |
| |
| Authors: | J. Spittka, K. Vos, JM. Valin. |
| Date: | June 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7587 |
|
This document defines the Real-time Transport Protocol (RTP) payload format for packetization of Opus-encoded speech and audio data necessary to integrate the codec in the most compatible way. It also provides an applicability statement for the use of Opus over RTP.Further, it describes media type registrations for the RTP payload format. |
|
| |
| RFC 7589 | Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication |
| |
| Authors: | M. Badra, A. Luchuk, J. Schoenwaelder. |
| Date: | June 2015 |
| Formats: | txt json html |
| Obsoletes: | RFC 5539 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7589 |
|
The Network Configuration Protocol (NETCONF) provides mechanisms to install, manipulate, and delete the configuration of network devices.This document describes how to use the Transport Layer Security (TLS) protocol with mutual X.509 authentication to secure the exchange ofNETCONF messages. This revision of RFC 5539 documents the new message framing used by NETCONF 1.1 and it obsoletes RFC 5539. |
|
| |
| RFC 7590 | Use of Transport Layer Security (TLS) in the Extensible Messaging and Presence Protocol (XMPP) |
| |
| Authors: | P. Saint-Andre, T. Alkemade. |
| Date: | June 2015 |
| Formats: | txt json html |
| Updates: | RFC 6120 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7590 |
|
This document provides recommendations for the use of Transport LayerSecurity (TLS) in the Extensible Messaging and Presence Protocol(XMPP). This document updates RFC 6120. |
|
| |
| RFC 7591 | OAuth 2.0 Dynamic Client Registration Protocol |
| |
| Authors: | J. Richer, Ed., M. Jones, J. Bradley, M. Machulak, P. Hunt. |
| Date: | July 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7591 |
|
This specification defines mechanisms for dynamically registeringOAuth 2.0 clients with authorization servers. Registration requests send a set of desired client metadata values to the authorization server. The resulting registration responses return a client identifier to use at the authorization server and the client metadata values registered for the client. The client can then use this registration information to communicate with the authorization server using the OAuth 2.0 protocol. This specification also defines a set of common client metadata fields and values for clients to use during registration. |
|
| |
| RFC 7596 | Lightweight 4over6: An Extension to the Dual-Stack Lite Architecture |
| |
| Authors: | Y. Cui, Q. Sun, M. Boucadair, T. Tsou, Y. Lee, I. Farrer. |
| Date: | July 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7596 |
|
Dual-Stack Lite (DS-Lite) (RFC 6333) describes an architecture for transporting IPv4 packets over an IPv6 network. This document specifies an extension to DS-Lite called "Lightweight 4over6", which moves the Network Address and Port Translation (NAPT) function from the centralized DS-Lite tunnel concentrator to the tunnel client located in the Customer Premises Equipment (CPE). This removes the requirement for a Carrier Grade NAT function in the tunnel concentrator and reduces the amount of centralized state that must be held to a per-subscriber level. In order to delegate the NAPT function and make IPv4 address sharing possible, port-restricted IPv4 addresses are allocated to the CPEs. |
|
| |
| RFC 7597 | Mapping of Address and Port with Encapsulation (MAP-E) |
| |
| Authors: | O. Troan, Ed., W. Dec, X. Li, C. Bao, S. Matsushima, T. Murakami, T. Taylor, Ed.. |
| Date: | July 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7597 |
|
This document describes a mechanism for transporting IPv4 packets across an IPv6 network using IP encapsulation. It also describes a generic mechanism for mapping between IPv6 addresses and IPv4 addresses as well as transport-layer ports. |
|
| |
| RFC 7598 | DHCPv6 Options for Configuration of Softwire Address and Port-Mapped Clients |
| |
| Authors: | T. Mrugalski, O. Troan, I. Farrer, S. Perreault, W. Dec, C. Bao, L. Yeh, X. Deng. |
| Date: | July 2015 |
| Formats: | txt json html |
| Updated by: | RFC 8539 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7598 |
|
This document specifies DHCPv6 options, termed Softwire46 options, for the provisioning of Softwire46 Customer Edge (CE) devices.Softwire46 is a collective term used to refer to architectures based on the notion of IPv4 Address plus Port (A+P) for providing IPv4 connectivity across an IPv6 network. |
|
| |
| RFC 7599 | Mapping of Address and Port using Translation (MAP-T) |
| |
| Authors: | X. Li, C. Bao, W. Dec, Ed., O. Troan, S. Matsushima, T. Murakami. |
| Date: | July 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7599 |
|
This document specifies the solution architecture based on "Mapping of Address and Port" stateless IPv6-IPv4 Network Address Translation(NAT64) for providing shared or non-shared IPv4 address connectivity to and across an IPv6 network. |
|
| |
| RFC 7601 | Message Header Field for Indicating Message Authentication Status |
| |
|
|
This document specifies a message header field called Authentication-Results for use with electronic mail messages to indicate the results of message authentication efforts. Any receiver-side software, such as mail filters or Mail User Agents (MUAs), can use this header field to relay that information in a convenient and meaningful way to users or to make sorting and filtering decisions. |
|
| |
| RFC 7602 | IS-IS Extended Sequence Number TLV |
| |
| Authors: | U. Chunduri, W. Lu, A. Tian, N. Shen. |
| Date: | July 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7602 |
|
This document defines the Extended Sequence Number TLV to protectIntermediate System to Intermediate System (IS-IS) PDUs from replay attacks. |
|
| |
| RFC 7603 | Energy Management (EMAN) Applicability Statement |
| |
| Authors: | B. Schoening, M. Chandramouli, B. Nordman. |
| Date: | August 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7603 |
|
The objective of Energy Management (EMAN) is to provide an energy management framework for networked devices. This document presents the applicability of the EMAN information model in a variety of scenarios with cases and target devices. These use cases are useful for identifying requirements for the framework and MIBs. Further, we describe the relationship of the EMAN framework to other relevant energy monitoring standards and architectures. |
|
| |
| RFC 7606 | Revised Error Handling for BGP UPDATE Messages |
| |
| Authors: | E. Chen, Ed., J. Scudder, Ed., P. Mohapatra, K. Patel. |
| Date: | August 2015 |
| Formats: | txt html json |
| Updates: | RFC 1997, RFC 4271, RFC 4360, RFC 4456, RFC 4760, RFC 5543, RFC 5701, RFC 6368 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7606 |
|
According to the base BGP specification, a BGP speaker that receives an UPDATE message containing a malformed attribute is required to reset the session over which the offending attribute was received.This behavior is undesirable because a session reset would impact not only routes with the offending attribute but also other valid routes exchanged over the session. This document partially revises the error handling for UPDATE messages and provides guidelines for the authors of documents defining new attributes. Finally, it revises the error handling procedures for a number of existing attributes.
This document updates error handling for RFCs 1997, 4271, 4360, 4456,4760, 5543, 5701, and 6368. |
|
| |
| RFC 7607 | Codification of AS 0 Processing |
| |
| Authors: | W. Kumari, R. Bush, H. Schiller, K. Patel. |
| Date: | August 2015 |
| Formats: | txt html json |
| Updates: | RFC 4271 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7607 |
|
This document updates RFC 4271 and proscribes the use of AutonomousSystem (AS) 0 in the Border Gateway Protocol (BGP) OPEN, AS_PATH,AS4_PATH, AGGREGATOR, and AS4_AGGREGATOR attributes in the BGP UPDATE message. |
|
| |
| RFC 7611 | BGP ACCEPT_OWN Community Attribute |
| |
| Authors: | J. Uttaro, P. Mohapatra, D. Smith, R. Raszuk, J. Scudder. |
| Date: | August 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7611 |
|
Under certain conditions, it is desirable for a Border GatewayProtocol (BGP) route reflector to be able to modify the Route Target(RT) list of a Virtual Private Network (VPN) route that the route reflector distributes, enabling the route reflector to control how a route originated within one VPN Routing and Forwarding table (VRF) is imported into other VRFs. This technique works effectively as long as the VRF that exports the route is not on the same Provider Edge(PE) router as the VRF(s) that imports the route. However, due to the constraints of BGP, it does not work if the two are on the samePE. This document describes a modification to BGP allowing this technique to work when the VRFs are on the same PE and to be used in a standard manner throughout an autonomous system. |
|
| |
| RFC 7613 | Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords |
| |
|
|
This document describes updated methods for handling Unicode strings representing usernames and passwords. The previous approach was known as SASLprep (RFC 4013) and was based on stringprep (RFC 3454).The methods specified in this document provide a more sustainable approach to the handling of internationalized usernames and passwords. The preparation, enforcement, and comparison of internationalized strings (PRECIS) framework, RFC 7564, obsoletes RFC3454, and this document obsoletes RFC 4013. |
|
| |
| RFC 7614 | Explicit Subscriptions for the REFER Method |
| |
| Authors: | R. Sparks. |
| Date: | August 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7614 |
|
The Session Initiation Protocol (SIP) REFER request, as defined byRFC 3515, triggers an implicit SIP-Specific Event Notification framework subscription. Conflating the start of the subscription with handling the REFER request makes negotiating SUBSCRIBE extensions impossible and complicates avoiding SIP dialog sharing.This document defines extensions to REFER that remove the implicit subscription and, if desired, replace it with an explicit one. |
|
| |
| RFC 7615 | HTTP Authentication-Info and Proxy-Authentication-Info Response Header Fields |
| |
|
|
This specification defines the "Authentication-Info" and "Proxy-Authentication-Info" response header fields for use in HypertextTransfer Protocol (HTTP) authentication schemes that need to return information once the client's authentication credentials have been accepted. |
|
| |
| RFC 7616 | HTTP Digest Access Authentication |
| |
| Authors: | R. Shekh-Yusef, Ed., D. Ahrens, S. Bremer. |
| Date: | September 2015 |
| Formats: | txt html json |
| Obsoletes: | RFC 2617 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7616 |
|
The Hypertext Transfer Protocol (HTTP) provides a simple challenge- response authentication mechanism that may be used by a server to challenge a client request and by a client to provide authentication information. This document defines the HTTP Digest Authentication scheme that can be used with the HTTP authentication mechanism. |
|
| |
| RFC 7617 | The 'Basic' HTTP Authentication Scheme |
| |
|
|
This document defines the "Basic" Hypertext Transfer Protocol (HTTP) authentication scheme, which transmits credentials as user-id/ password pairs, encoded using Base64. |
|
| |
| RFC 7618 | Dynamic Allocation of Shared IPv4 Addresses |
| |
| Authors: | Y. Cui, Q. Sun, I. Farrer, Y. Lee, Q. Sun, M. Boucadair. |
| Date: | August 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7618 |
|
This memo describes the dynamic allocation of shared IPv4 addresses to clients using DHCPv4. Address sharing allows a single IPv4 address to be allocated to multiple active clients simultaneously, with each client being differentiated by a unique set of transport- layer source port numbers. The necessary changes to existing DHCPv4 client and server behavior are described, and a new DHCPv4 option for provisioning clients with shared IPv4 addresses is included.
Due to the nature of IP address sharing, some limitations to its applicability are necessary. This memo describes these limitations and recommends suitable architectures and technologies where address sharing may be utilized. |
|
| |
| RFC 7619 | The NULL Authentication Method in the Internet Key Exchange Protocol Version 2 (IKEv2) |
| |
|
|
This document specifies the NULL Authentication method and theID_NULL Identification Payload ID Type for Internet Key ExchangeProtocol version 2 (IKEv2). This allows two IKE peers to establish single-side authenticated or mutual unauthenticated IKE sessions for those use cases where a peer is unwilling or unable to authenticate or identify itself. This ensures IKEv2 can be used for OpportunisticSecurity (also known as Opportunistic Encryption) to defend againstPervasive Monitoring attacks without the need to sacrifice anonymity. |
|
| |
| RFC 7621 | A Clarification on the Use of Globally Routable User Agent URIs (GRUUs) in the SIP Event Notification Framework |
| |
|
|
Experience since the publication of the most recent SIP Events framework (in July 2012) has shown that there is room for interpretation around the use of Globally Routable User Agent URIs in that specification. This document clarifies the intended behavior.
This document updates RFC 6665. |
|
| |
| RFC 7622 | Extensible Messaging and Presence Protocol (XMPP): Address Format |
| |
|
|
This document defines the address format for the Extensible Messaging and Presence Protocol (XMPP), including support for code points outside the ASCII range. This document obsoletes RFC 6122. |
|
| |
| RFC 7623 | Provider Backbone Bridging Combined with Ethernet VPN (PBB-EVPN) |
| |
| Authors: | A. Sajassi, Ed., S. Salam, N. Bitar, A. Isaac, W. Henderickx. |
| Date: | September 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7623 |
|
This document discusses how Ethernet Provider Backbone Bridging (PBB) can be combined with Ethernet VPN (EVPN) in order to reduce the number of BGP MAC Advertisement routes by aggregating Customer/ClientMAC (C-MAC) addresses via Provider Backbone MAC (B-MAC) address, provide client MAC address mobility using C-MAC aggregation, confine the scope of C-MAC learning to only active flows, offer per-site policies, and avoid C-MAC address flushing on topology changes. The combined solution is referred to as PBB-EVPN. |
|
| |
| RFC 7627 | Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension |
| |
| Authors: | K. Bhargavan, Ed., A. Delignat-Lavaud, A. Pironti, A. Langley, M. Ray. |
| Date: | September 2015 |
| Formats: | txt html json |
| Updates: | RFC 5246 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7627 |
|
The Transport Layer Security (TLS) master secret is not cryptographically bound to important session parameters such as the server certificate. Consequently, it is possible for an active attacker to set up two sessions, one with a client and another with a server, such that the master secrets on the two sessions are the same. Thereafter, any mechanism that relies on the master secret for authentication, including session resumption, becomes vulnerable to a man-in-the-middle attack, where the attacker can simply forward messages back and forth between the client and server. This specification defines a TLS extension that contextually binds the master secret to a log of the full handshake that computes it, thus preventing such attacks. |
|
| |
| RFC 7628 | A Set of Simple Authentication and Security Layer (SASL) Mechanisms for OAuth |
| |
| Authors: | W. Mills, T. Showalter, H. Tschofenig. |
| Date: | August 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7628 |
|
OAuth enables a third-party application to obtain limited access to a protected resource, either on behalf of a resource owner by orchestrating an approval interaction or by allowing the third-party application to obtain access on its own behalf.
This document defines how an application client uses credentials obtained via OAuth over the Simple Authentication and Security Layer(SASL) to access a protected resource at a resource server. Thereby, it enables schemes defined within the OAuth framework for non-HTTP- based application protocols.
Clients typically store the user's long-term credential. This does, however, lead to significant security vulnerabilities, for example, when such a credential leaks. A significant benefit of OAuth for usage in those clients is that the password is replaced by a shared secret with higher entropy, i.e., the token. Tokens typically provide limited access rights and can be managed and revoked separately from the user's long-term password. |
|
| |
| RFC 7630 | HMAC-SHA-2 Authentication Protocols in the User-based Security Model (USM) for SNMPv3 |
| |
| Authors: | J. Merkle, Ed., M. Lochter. |
| Date: | October 2015 |
| Formats: | txt json html |
| Obsoleted by: | RFC 7860 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7630 |
|
This memo specifies new HMAC-SHA-2 authentication protocols for theUser-based Security Model (USM) for SNMPv3 defined in RFC 3414. |
|
| |
| RFC 7631 | TLV Naming in the Mobile Ad Hoc Network (MANET) Generalized Packet/Message Format |
| |
|
|
This document reorganizes the naming of already-allocated TLV (type- length-value) types and type extensions in the "Mobile Ad hoc NETwork(MANET) Parameters" registries defined by RFC 5444 to use names appropriately. It has no consequences in terms of any protocol implementation.
This document also updates the Expert Review guidelines in RFC 5444, so as to establish a policy for consistent naming of future TLV type and type extension allocations. It makes no other changes toRFC 5444. |
|
| |
| RFC 7633 | X.509v3 Transport Layer Security (TLS) Feature Extension |
| |
| Authors: | P. Hallam-Baker. |
| Date: | October 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7633 |
|
The purpose of the TLS feature extension is to prevent downgrade attacks that are not otherwise prevented by the TLS protocol. In particular, the TLS feature extension may be used to mandate support for revocation checking features in the TLS protocol such as OnlineCertificate Status Protocol (OCSP) stapling. Informing clients that an OCSP status response will always be stapled permits an immediate failure in the case that the response is not stapled. This in turn prevents a denial-of-service attack that might otherwise be possible. |
|
| |
| RFC 7634 | ChaCha20, Poly1305, and Their Use in the Internet Key Exchange Protocol (IKE) and IPsec |
| |
| Authors: | Y. Nir. |
| Date: | August 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7634 |
|
This document describes the use of the ChaCha20 stream cipher along with the Poly1305 authenticator, combined into an AEAD algorithm for the Internet Key Exchange Protocol version 2 (IKEv2) and for IPsec. |
|
| |
| RFC 7635 | Session Traversal Utilities for NAT (STUN) Extension for Third-Party Authorization |
| |
| Authors: | T. Reddy, P. Patil, R. Ravindranath, J. Uberti. |
| Date: | August 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7635 |
|
This document proposes the use of OAuth 2.0 to obtain and validate ephemeral tokens that can be used for Session Traversal Utilities forNAT (STUN) authentication. The usage of ephemeral tokens ensures that access to a STUN server can be controlled even if the tokens are compromised. |
|
| |
| RFC 7636 | Proof Key for Code Exchange by OAuth Public Clients |
| |
| Authors: | N. Sakimura, Ed., J. Bradley, N. Agarwal. |
| Date: | September 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7636 |
|
OAuth 2.0 public clients utilizing the Authorization Code Grant are susceptible to the authorization code interception attack. This specification describes the attack as well as a technique to mitigate against the threat through the use of Proof Key for Code Exchange(PKCE, pronounced "pixy"). |
|
| |
| RFC 7638 | JSON Web Key (JWK) Thumbprint |
| |
| Authors: | M. Jones, N. Sakimura. |
| Date: | September 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7638 |
|
This specification defines a method for computing a hash value over aJSON Web Key (JWK). It defines which fields in a JWK are used in the hash computation, the method of creating a canonical form for those fields, and how to convert the resulting Unicode string into a byte sequence to be hashed. The resulting hash value can be used for identifying or selecting the key represented by the JWK that is the subject of the thumbprint. |
|
| |
| RFC 7639 | The ALPN HTTP Header Field |
| |
| Authors: | A. Hutton, J. Uberti, M. Thomson. |
| Date: | August 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7639 |
|
This specification allows HTTP CONNECT requests to indicate what protocol is intended to be used within the tunnel once established, using the ALPN header field. |
|
| |
| RFC 7641 | Observing Resources in the Constrained Application Protocol (CoAP) |
| |
|
|
The Constrained Application Protocol (CoAP) is a RESTful application protocol for constrained nodes and networks. The state of a resource on a CoAP server can change over time. This document specifies a simple protocol extension for CoAP that enables CoAP clients to"observe" resources, i.e., to retrieve a representation of a resource and keep this representation updated by the server over a period of time. The protocol follows a best-effort approach for sending new representations to clients and provides eventual consistency between the state observed by each client and the actual resource state at the server. |
|
| |
| RFC 7643 | System for Cross-domain Identity Management: Core Schema |
| |
| Authors: | P. Hunt, Ed., K. Grizzle, E. Wahlstroem, C. Mortimore. |
| Date: | September 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7643 |
|
The System for Cross-domain Identity Management (SCIM) specifications are designed to make identity management in cloud-based applications and services easier. The specification suite builds upon experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization, and privacy models. Its intent is to reduce the cost and complexity of user management operations by providing a common user schema and extension model as well as binding documents to provide patterns for exchanging this schema using HTTP.
This document provides a platform-neutral schema and extension model for representing users and groups and other resource types in JSON format. This schema is intended for exchange and use with cloud service providers. |
|
| |
| RFC 7644 | System for Cross-domain Identity Management: Protocol |
| |
| Authors: | P. Hunt, Ed., K. Grizzle, M. Ansari, E. Wahlstroem, C. Mortimore. |
| Date: | September 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7644 |
|
The System for Cross-domain Identity Management (SCIM) specification is an HTTP-based protocol that makes managing identities in multi- domain scenarios easier to support via a standardized service.Examples include, but are not limited to, enterprise-to-cloud service providers and inter-cloud scenarios. The specification suite seeks to build upon experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization, and privacy models. SCIM's intent is to reduce the cost and complexity of user management operations by providing a common user schema, an extension model, and a service protocol defined by this document. |
|
| |
| RFC 7647 | Clarifications for the Use of REFER with RFC 6665 |
| |
| Authors: | R. Sparks, A.B. Roach. |
| Date: | September 2015 |
| Formats: | txt json html |
| Updates: | RFC 3515 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7647 |
|
The SIP REFER method relies on the SIP-Specific Event Notification framework. That framework was revised by RFC 6665. This document highlights the implications of the requirement changes in RFC 6665, and updates the definition of the REFER method described in RFC 3515 to clarify and disambiguate the impact of those changes. |
|
| |
| RFC 7648 | Port Control Protocol (PCP) Proxy Function |
| |
| Authors: | S. Perreault, M. Boucadair, R. Penno, D. Wing, S. Cheshire. |
| Date: | September 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7648 |
|
This document specifies a new Port Control Protocol (PCP) functional element: the PCP proxy. The PCP proxy relays PCP requests received from PCP clients to upstream PCP server(s). A typical deployment usage of this function is to help establish successful PCP communications for PCP clients that cannot be configured with the address of a PCP server located more than one hop away. |
|
| |
| RFC 7650 | A Constrained Application Protocol (CoAP) Usage for REsource LOcation And Discovery (RELOAD) |
| |
| Authors: | J. Jimenez, J. Lopez-Vega, J. Maenpaa, G. Camarillo. |
| Date: | September 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7650 |
|
This document defines a Constrained Application Protocol (CoAP) Usage for REsource LOcation And Discovery (RELOAD). The CoAP Usage provides the functionality to federate Wireless Sensor Networks(WSNs) in a peer-to-peer fashion. The CoAP Usage for RELOAD allowsCoAP nodes to store resources in a RELOAD peer-to-peer overlay, provides a lookup service, and enables the use of RELOAD overlay as a cache for sensor data. This functionality is implemented in theRELOAD overlay itself, without the use of centralized servers. TheRELOAD AppAttach method is used to establish a direct connection between nodes through which CoAP messages are exchanged. |
|
| |
| RFC 7652 | Port Control Protocol (PCP) Authentication Mechanism |
| |
| Authors: | M. Cullen, S. Hartman, D. Zhang, T. Reddy. |
| Date: | September 2015 |
| Formats: | txt json html |
| Updates: | RFC 6887 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7652 |
|
An IPv4 or IPv6 host can use the Port Control Protocol (PCP) to flexibly manage the IP address-mapping and port-mapping information on Network Address Translators (NATs) or firewalls to facilitate communication with remote hosts. However, the uncontrolled generation or deletion of IP address mappings on such network devices may cause security risks and should be avoided. In some cases, the client may need to prove that it is authorized to modify, create, or delete PCP mappings. This document describes an in-band authentication mechanism for PCP that can be used in those cases.The Extensible Authentication Protocol (EAP) is used to perform authentication between PCP devices.
This document updates RFC 6887. |
|
| |
| RFC 7653 | DHCPv6 Active Leasequery |
| |
| Authors: | D. Raghuvanshi, K. Kinnear, D. Kukrety. |
| Date: | October 2015 |
| Formats: | txt json html |
| Updates: | RFC 5460 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7653 |
|
The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) has been extended with a Leasequery capability that allows a requestor to request information about DHCPv6 bindings. That mechanism is limited to queries for DHCPv6 binding data updates prior to the time theDHCPv6 server receives the Leasequery request. Continuous update of an external requestor with Leasequery data is sometimes desired.This document expands on the DHCPv6 Leasequery protocol and allows for active transfer of real-time DHCPv6 binding information data viaTCP. This document also updates DHCPv6 Bulk Leasequery (RFC 5460) by adding new options. |
|
| |
| RFC 7655 | RTP Payload Format for G.711.0 |
| |
| Authors: | M. Ramalho, Ed., P. Jones, N. Harada, M. Perumal, L. Miao. |
| Date: | November 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7655 |
|
This document specifies the Real-time Transport Protocol (RTP) payload format for ITU-T Recommendation G.711.0. ITU-T Rec. G.711.0 defines a lossless and stateless compression for G.711 packet payloads typically used in IP networks. This document also defines a storage mode format for G.711.0 and a media type registration for theG.711.0 RTP payload format. |
|
| |
| RFC 7658 | Deprecation of MIB Module NAT-MIB: Managed Objects for Network Address Translators (NATs) |
| |
| Authors: | S. Perreault, T. Tsou, S. Sivakumar, T. Taylor. |
| Date: | October 2015 |
| Formats: | txt html json |
| Obsoletes: | RFC 4008 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7658 |
|
This memo deprecates MIB module NAT-MIB, a portion of the ManagementInformation Base (MIB) previously defined in RFC 4008 for devices implementing Network Address Translator (NAT) function. A companion document defines a new version, NATV2-MIB, which responds to deficiencies found in module NAT-MIB and adds new capabilities.
This document obsoletes RFC 4008. All MIB objects specified in RFC4008 are included in this version unchanged with only the STATUS changed to deprecated. |
|
| |
| RFC 7659 | Definitions of Managed Objects for Network Address Translators (NATs) |
| |
| Authors: | S. Perreault, T. Tsou, S. Sivakumar, T. Taylor. |
| Date: | October 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7659 |
|
This memo defines a portion of the Management Information Base (MIB) for devices implementing the Network Address Translator (NAT) function. The new MIB module defined in this document, NATV2-MIB, is intended to replace module NAT-MIB (RFC 4008). NATV2-MIB is not backwards compatible with NAT-MIB, for reasons given in the text of this document. A companion document deprecates all objects in NAT-MIB. NATV2-MIB can be used for the monitoring of NAT instances on a device capable of NAT function. Compliance levels are defined for three application scenarios: basic NAT, pooled NAT, and carrier-grade NAT (CGN). |
|
| |
| RFC 7660 | Diameter Congestion and Filter Attributes |
| |
| Authors: | L. Bertz, S. Manning, B. Hirschman. |
| Date: | October 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7660 |
|
This document defines optional Diameter attributes that can be used to help manage networks that use Explicit Congestion Notification(ECN) or Diameter traffic filters. These new attributes allow for improved data traffic identification, support of ECN, and minimalDiameter filter administration.
RFC 5777 defines a Filter-Rule Attribute Value Pair (AVP) that accommodates extensions for classification, conditions, and actions.It, however, does not support traffic identification for packets using Explicit Congestion Notification as defined in RFC 3168 and does not provide specific actions when the flow(s) described by theFilter-Rule are congested.
Further, a Filter-Rule can describe multiple flows but not the exact number of flows. Flow count and other associated data (e.g., packets) are not captured by accounting applications, leaving administrators without useful information regarding the effectiveness or appropriateness of the filter definition.
The optional attributes defined in this document are forward and backwards compatible with RFC 5777. |
|
| |
| RFC 7662 | OAuth 2.0 Token Introspection |
| |
| Authors: | J. Richer, Ed.. |
| Date: | October 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7662 |
|
This specification defines a method for a protected resource to query an OAuth 2.0 authorization server to determine the active state of anOAuth 2.0 token and to determine meta-information about this token.OAuth 2.0 deployments can use this method to convey information about the authorization context of the token from the authorization server to the protected resource. |
|
| |
| RFC 7666 | Management Information Base for Virtual Machines Controlled by a Hypervisor |
| |
| Authors: | H. Asai, M. MacFaden, J. Schoenwaelder, K. Shima, T. Tsou. |
| Date: | October 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7666 |
|
This document defines a portion of the Management Information Base(MIB) for use with network management protocols in the Internet community. In particular, this specifies objects for managing virtual machines controlled by a hypervisor (a.k.a. virtual machine monitor). |
|
| |
| RFC 7668 | IPv6 over BLUETOOTH(R) Low Energy |
| |
| Authors: | J. Nieminen, T. Savolainen, M. Isomaki, B. Patil, Z. Shelby, C. Gomez. |
| Date: | October 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7668 |
|
Bluetooth Smart is the brand name for the Bluetooth low energy feature in the Bluetooth specification defined by the BluetoothSpecial Interest Group. The standard Bluetooth radio has been widely implemented and available in mobile phones, notebook computers, audio headsets, and many other devices. The low-power version of Bluetooth is a specification that enables the use of this air interface with devices such as sensors, smart meters, appliances, etc. The low- power variant of Bluetooth has been standardized since revision 4.0 of the Bluetooth specifications, although version 4.1 or newer is required for IPv6. This document describes how IPv6 is transported over Bluetooth low energy using IPv6 over Low-power Wireless PersonalArea Network (6LoWPAN) techniques. |
|
| |
| RFC 7670 | Generic Raw Public-Key Support for IKEv2 |
| |
| Authors: | T. Kivinen, P. Wouters, H. Tschofenig. |
| Date: | January 2016 |
| Formats: | txt html json |
| Updates: | RFC 7296 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7670 |
|
The Internet Key Exchange Version 2 (IKEv2) protocol did have support for raw public keys, but it only supported RSA raw public keys. In constrained environments, it is useful to make use of other types of public keys, such as those based on Elliptic Curve Cryptography.This document updates RFC 7296, adding support for other types of raw public keys to IKEv2. |
|
| |
| RFC 7671 | The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance |
| |
| Authors: | V. Dukhovni, W. Hardaker. |
| Date: | October 2015 |
| Formats: | txt html json |
| Updates: | RFC 6698 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7671 |
|
This document clarifies and updates the DNS-Based Authentication ofNamed Entities (DANE) TLSA specification (RFC 6698), based on subsequent implementation experience. It also contains guidance for implementers, operators, and protocol developers who want to use DANE records. |
|
| |
| RFC 7672 | SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) |
| |
| Authors: | V. Dukhovni, W. Hardaker. |
| Date: | October 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7672 |
|
This memo describes a downgrade-resistant protocol for SMTP transport security between Message Transfer Agents (MTAs), based on the DNS-Based Authentication of Named Entities (DANE) TLSA DNS record.Adoption of this protocol enables an incremental transition of theInternet email backbone to one using encrypted and authenticatedTransport Layer Security (TLS). |
|
| |
| RFC 7673 | Using DNS-Based Authentication of Named Entities (DANE) TLSA Records with SRV Records |
| |
| Authors: | T. Finch, M. Miller, P. Saint-Andre. |
| Date: | October 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7673 |
|
The DNS-Based Authentication of Named Entities (DANE) specification(RFC 6698) describes how to use TLSA resource records secured byDNSSEC (RFC 4033) to associate a server's connection endpoint with its Transport Layer Security (TLS) certificate (thus enabling administrators of domain names to specify the keys used in that domain's TLS servers). However, application protocols that use SRV records (RFC 2782) to indirectly name the target server connection endpoints for a service domain name cannot apply the rules from RFC6698. Therefore, this document provides guidelines that enable such protocols to locate and use TLSA records. |
|
| |
| RFC 7674 | Clarification of the Flowspec Redirect Extended Community |
| |
|
|
This document updates RFC 5575 ("Dissemination of Flow SpecificationRules") to clarify the formatting of the BGP Flowspec RedirectExtended Community. |
|
| |
| RFC 7675 | Session Traversal Utilities for NAT (STUN) Usage for Consent Freshness |
| |
| Authors: | M. Perumal, D. Wing, R. Ravindranath, T. Reddy, M. Thomson. |
| Date: | October 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7675 |
|
To prevent WebRTC applications, such as browsers, from launching attacks by sending traffic to unwilling victims, periodic consent to send needs to be obtained from remote endpoints.
This document describes a consent mechanism using a new SessionTraversal Utilities for NAT (STUN) usage. |
|
| |
| RFC 7676 | IPv6 Support for Generic Routing Encapsulation (GRE) |
| |
| Authors: | C. Pignataro, R. Bonica, S. Krishnan. |
| Date: | October 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7676 |
|
Generic Routing Encapsulation (GRE) can be used to carry any network- layer payload protocol over any network-layer delivery protocol.Currently, GRE procedures are specified for IPv4, used as either the payload or delivery protocol. However, GRE procedures are not specified for IPv6.
This document specifies GRE procedures for IPv6, used as either the payload or delivery protocol. |
|
| |
| RFC 7677 | SCRAM-SHA-256 and SCRAM-SHA-256-PLUS Simple Authentication and Security Layer (SASL) Mechanisms |
| |
|
|
This document registers the Simple Authentication and Security Layer(SASL) mechanisms SCRAM-SHA-256 and SCRAM-SHA-256-PLUS, provides guidance for secure implementation of the original SCRAM-SHA-1-PLUS mechanism, and updates the SCRAM registration procedures of RFC 5802. |
|
| |
| RFC 7678 | Attribute-Value Pairs for Provisioning Customer Equipment Supporting IPv4-Over-IPv6 Transitional Solutions |
| |
| Authors: | C. Zhou, T. Taylor, Q. Sun, M. Boucadair. |
| Date: | October 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7678 |
|
During the transition from IPv4 to IPv6, customer equipment may have to support one of the various transition methods that have been defined for carrying IPv4 packets over IPv6. This document enumerates the information that needs to be provisioned on a customer edge router to support a list of transition techniques based on tunneling IPv4 in IPv6, with a view to defining reusable components for a reasonable transition path between these techniques. To the extent that the provisioning is done dynamically, Authentication,Authorization, and Accounting (AAA) support is needed to provide the information to the network server responsible for passing the information to the customer equipment. This document specifiesDiameter (RFC 6733) Attribute-Value Pairs (AVPs) to be used for that purpose. |
|
| |
| RFC 7683 | Diameter Overload Indication Conveyance |
| |
| Authors: | J. Korhonen, Ed., S. Donovan, Ed., B. Campbell, L. Morand. |
| Date: | October 2015 |
| Formats: | txt json html |
| Updated by: | RFC 8581 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7683 |
|
This specification defines a base solution for Diameter overload control, referred to as Diameter Overload Indication Conveyance(DOIC). |
|
| |
| RFC 7684 | OSPFv2 Prefix/Link Attribute Advertisement |
| |
| Authors: | P. Psenak, H. Gredler, R. Shakir, W. Henderickx, J. Tantsura, A. Lindem. |
| Date: | November 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7684 |
|
OSPFv2 requires functional extension beyond what can readily be done with the fixed-format Link State Advertisements (LSAs) as described in RFC 2328. This document defines OSPFv2 Opaque LSAs based on Type-Length-Value (TLV) tuples that can be used to associate additional attributes with prefixes or links. Depending on the application, these prefixes and links may or may not be advertised in the fixed- format LSAs. The OSPFv2 Opaque LSAs are optional and fully backward compatible. |
|
| |
| RFC 7685 | A Transport Layer Security (TLS) ClientHello Padding Extension |
| |
|
|
This memo describes a Transport Layer Security (TLS) extension that can be used to pad ClientHello messages to a desired size. |
|
| |
| RFC 7686 | The ".onion" Special-Use Domain Name |
| |
| Authors: | J. Appelbaum, A. Muffett. |
| Date: | October 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7686 |
|
This document registers the ".onion" Special-Use Domain Name. |
|
| |
| RFC 7688 | GMPLS OSPF Enhancement for Signal and Network Element Compatibility for Wavelength Switched Optical Networks |
| |
| Authors: | Y. Lee, Ed., G. Bernstein, Ed.. |
| Date: | November 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7688 |
|
This document provides Generalized Multiprotocol Label Switching(GMPLS) Open Shortest Path First (OSPF) routing enhancements to support signal compatibility constraints associated with WavelengthSwitched Optical Network (WSON) elements. These routing enhancements are applicable in common optical or hybrid electro-optical networks where not all the optical signals in the network are compatible with all network elements participating in the network.
This compatibility constraint model is applicable to common optical or hybrid electro-optical systems such as optical-electronic-optical(OEO) switches, regenerators, and wavelength converters, since such systems can be limited to processing only certain types of WSON signals. |
|
| |
| RFC 7689 | Signaling Extensions for Wavelength Switched Optical Networks |
| |
| Authors: | G. Bernstein, Ed., S. Xu, Y. Lee, Ed., G. Martinelli, H. Harai. |
| Date: | November 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7689 |
|
This document provides extensions to Generalized Multiprotocol LabelSwitching (GMPLS) signaling for control of Wavelength SwitchedOptical Networks (WSONs). Such extensions are applicable in WSONs under a number of conditions including: (a) when optional processing, such as regeneration, must be configured to occur at specific nodes along a path, (b) where equipment must be configured to accept an optical signal with specific attributes, or (c) where equipment must be configured to output an optical signal with specific attributes.This document provides mechanisms to support distributed wavelength assignment with a choice of distributed wavelength assignment algorithms. |
|
| |
| RFC 7692 | Compression Extensions for WebSocket |
| |
| Authors: | T. Yoshino. |
| Date: | December 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7692 |
|
This document defines a framework for creating WebSocket extensions that add compression functionality to the WebSocket Protocol. An extension based on this framework compresses the payload data portion of WebSocket data messages on a per-message basis using parameters negotiated during the opening handshake. This framework provides a general method for applying a compression algorithm to the contents of WebSocket messages. Each compression algorithm has to be defined in a document defining the extension by specifying the parameter negotiation and the payload transformation algorithm in detail. This document also specifies one specific compression extension using theDEFLATE algorithm. |
|
| |
| RFC 7694 | Hypertext Transfer Protocol (HTTP) Client-Initiated Content-Encoding |
| |
|
|
In HTTP, content codings allow for payload encodings such as for compression or integrity checks. In particular, the "gzip" content coding is widely used for payload data sent in response messages.
Content codings can be used in request messages as well; however, discoverability is not on par with response messages. This document extends the HTTP "Accept-Encoding" header field for use in responses, to indicate the content codings that are supported in requests. |
|
| |
| RFC 7695 | Distributed Prefix Assignment Algorithm |
| |
| Authors: | P. Pfister, B. Paterson, J. Arkko. |
| Date: | November 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7695 |
|
This document specifies a distributed algorithm for dividing a set of prefixes in a manner that allows for automatic assignment of sub- prefixes that are unique and non-overlapping. Used in conjunction with a protocol that provides flooding of information among a set of participating nodes, prefix configuration within a network may be automated. |
|
| |
| RFC 7697 | MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM) Identifiers Management Information Base (MIB) |
| |
| Authors: | P. Pan, S. Aldrin, M. Venkatesan, K. Sampath, T. Nadeau, S. Boutros. |
| Date: | January 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7697 |
|
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 theOperations, Administration, and Maintenance (OAM) identifiers forMultiprotocol Label Switching (MPLS) and the MPLS-based TransportProfile (TP). |
|
| |
| RFC 7699 | Generalized Labels for the Flexi-Grid in Lambda Switch Capable (LSC) Label Switching Routers |
| |
|
|
GMPLS supports the description of optical switching by identifying entries in fixed lists of switchable wavelengths (called grids) through the encoding of lambda labels. Work within the ITU-T StudyGroup 15 has defined a finer-granularity grid, and the facility to flexibly select different widths of spectrum from the grid. This document defines a new GMPLS lambda label format to support this flexi-grid.
This document updates RFCs 3471 and 6205 by introducing a new label format. |
|
| |
| RFC 7700 | Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames |
| |
|
|
This document describes methods for handling Unicode strings representing memorable, human-friendly names (called "nicknames","display names", or "petnames") for people, devices, accounts, websites, and other entities. |
|
| |
| RFC 7701 | Multi-party Chat Using the Message Session Relay Protocol (MSRP) |
| |
| Authors: | A. Niemi, M. Garcia-Martin, G. Sandbakken. |
| Date: | December 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7701 |
|
The Message Session Relay Protocol (MSRP) defines a mechanism for sending instant messages (IMs) within a peer-to-peer session, negotiated using the Session Initiation Protocol (SIP) and theSession Description Protocol (SDP). This document defines the necessary tools for establishing multi-party chat sessions, or chat rooms, using MSRP. |
|
| |
| RFC 7702 | Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Groupchat |
| |
| Authors: | P. Saint-Andre, S. Ibarra, S. Loreto. |
| Date: | December 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7702 |
|
This document defines a bidirectional protocol mapping for the exchange of instant messages in the context of a multi-party chat session among users of the Session Initiation Protocol (SIP) and users of the Extensible Messaging and Presence Protocol (XMPP).Specifically, this document defines a mapping between the SIP-basedMessage Session Relay Protocol (MSRP) and the XMPP Multi-User Chat(MUC) extension. |
|
| |
| RFC 7705 | Autonomous System Migration Mechanisms and Their Effects on the BGP AS_PATH Attribute |
| |
|
|
This document discusses some existing commonly used BGP mechanisms for Autonomous System Number (ASN) migration that are not formally part of the BGP4 protocol specification. It is necessary to document these de facto standards to ensure that they are properly supported in future BGP protocol work. |
|
| |
| RFC 7708 | Using a Generic Associated Channel Label as a Virtual Circuit Connectivity Verification Channel Indicator |
| |
| Authors: | T. Nadeau, L. Martini, S. Bryant. |
| Date: | November 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7708 |
|
The Virtual Circuit Connectivity Verification (VCCV) protocol specified in RFC 5085 provides a control channel (CC) that is associated with a pseudowire (PW). This document specifies an additional VCCV control channel type to be used with pseudowires that do not use the PW Control Word and that are carried over an MPLS network. This new VCCV CC type uses the Generic Associated ChannelLabel defined in RFC 5586 to distinguish VCCV packets from packets carrying user data. This new VCCV CC type introduces compatibility with the method of MPLS Label Switched Path Operations,Administration, and Maintenance (OAM) identification, particularly inMPLS Transport Profile (MPLS-TP) networks (RFC 5921). |
|
| |
| RFC 7710 | Captive-Portal Identification Using DHCP or Router Advertisements (RAs) |
| |
| Authors: | W. Kumari, O. Gudmundsson, P. Ebersman, S. Sheng. |
| Date: | December 2015 |
| Formats: | txt html json |
| Obsoleted by: | RFC 8910 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7710 |
|
In many environments offering short-term or temporary Internet access(such as coffee shops), it is common to start new connections in a captive-portal mode. This highly restricts what the customer can do until the customer has authenticated.
This document describes a DHCP option (and a Router Advertisement(RA) extension) to inform clients that they are behind some sort of captive-portal device and that they will need to authenticate to getInternet access. It is not a full solution to address all of the issues that clients may have with captive portals; it is designed to be used in larger solutions. The method of authenticating to and interacting with the captive portal is out of scope for this document. |
|
| |
| RFC 7711 | PKIX over Secure HTTP (POSH) |
| |
| Authors: | M. Miller, P. Saint-Andre. |
| Date: | November 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7711 |
|
Experience has shown that it is difficult to deploy proper PKIX certificates for Transport Layer Security (TLS) in multi-tenanted environments. As a result, domains hosted in such environments often deploy applications using certificates that identify the hosting service, not the hosted domain. Such deployments force end users and peer services to accept a certificate with an improper identifier, resulting in degraded security. This document defines methods that make it easier to deploy certificates for proper server identity checking in non-HTTP application protocols. Although these methods were developed for use in the Extensible Messaging and PresenceProtocol (XMPP) as a Domain Name Association (DNA) prooftype, they might also be usable in other non-HTTP application protocols. |
|
| |
| RFC 7712 | Domain Name Associations (DNA) in the Extensible Messaging and Presence Protocol (XMPP) |
| |
| Authors: | P. Saint-Andre, M. Miller, P. Hancke. |
| Date: | November 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7712 |
|
This document improves the security of the Extensible Messaging andPresence Protocol (XMPP) in two ways. First, it specifies how to establish a strong association between a domain name and an XML stream, using the concept of "prooftypes". Second, it describes how to securely delegate a service domain name (e.g., example.com) to a target server hostname (e.g., hosting.example.net); this is especially important in multi-tenanted environments where the same target server hosts a large number of domains. |
|
| |
| RFC 7714 | AES-GCM Authenticated Encryption in the Secure Real-time Transport Protocol (SRTP) |
| |
| Authors: | D. McGrew, K. Igoe. |
| Date: | December 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7714 |
|
This document defines how the AES-GCM Authenticated Encryption withAssociated Data family of algorithms can be used to provide confidentiality and data authentication in the Secure Real-timeTransport Protocol (SRTP). |
|
| |
| RFC 7715 | Multipoint LDP (mLDP) Node Protection |
| |
| Authors: | IJ. Wijnands, Ed., K. Raza, A. Atlas, J. Tantsura, Q. Zhao. |
| Date: | January 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7715 |
|
This document describes procedures to support node protection forPoint-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths(P2MP and MP2MP LSPs) that have been built by the Multipoint LabelDistribution Protocol (mLDP). In order to protect a node N, thePoint of Local Repair (PLR) Label Switching Router (LSR) of N must learn the Merge Point (MPT) LSR(s) of node N such that traffic can be redirected to them in case node N fails. Redirecting the traffic around the failed node N depends on existing Point-to-Point (P2P)Label Switched Paths (LSPs). The pre-established LSPs originate from the PLR LSR and terminate on the MPT LSRs while bypassing LSR N. |
|
| |
| RFC 7716 | Global Table Multicast with BGP Multicast VPN (BGP-MVPN) Procedures |
| |
| Authors: | J. Zhang, L. Giuliano, E. Rosen, Ed., K. Subramanian, D. Pacella. |
| Date: | December 2015 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7716 |
|
RFCs 6513, 6514, and others describe protocols and procedures that aService Provider (SP) may deploy in order to offer Multicast VirtualPrivate Network (Multicast VPN or MVPN) service to its customers.Some of these procedures use BGP to distribute VPN-specific multicast routing information across a backbone network. With a small number of relatively minor modifications, the same BGP procedures can also be used to distribute multicast routing information that is not specific to any VPN. Multicast that is outside the context of a VPN is known as "Global Table Multicast", or sometimes simply as"Internet multicast". In this document, we describe the modifications that are needed to use the BGP-MVPN procedures forGlobal Table Multicast. |
|
| |
| RFC 7717 | IKEv2-Derived Shared Secret Key for the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP) |
| |
|
|
The One-Way Active Measurement Protocol (OWAMP) and Two-Way ActiveMeasurement Protocol (TWAMP) security mechanisms require that both the client and server endpoints possess a shared secret. This document describes the use of keys derived from an IKEv2 security association (SA) as the shared key in OWAMP or TWAMP. If the shared key can be derived from the IKEv2 SA, OWAMP or TWAMP can support certificate-based key exchange; this would allow for more operational flexibility and efficiency. The key derivation presented in this document can also facilitate automatic key management. |
|
| |
| RFC 7718 | Registries for the One-Way Active Measurement Protocol (OWAMP) |
| |
|
|
This memo describes the registries for OWAMP -- the One-Way ActiveMeasurement Protocol. The registries allow assignment of Mode bit positions and OWAMP Command numbers. Per this memo, IANA has established the registries for new features, called the OWAMP-Modes registry and the OWAMP Control Command Number registry. This memo updates RFC 4656. |
|
| |
| RFC 7723 | Port Control Protocol (PCP) Anycast Addresses |
| |
| Authors: | S. Kiesel, R. Penno. |
| Date: | January 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7723 |
|
The Port Control Protocol (PCP) anycast addresses enable PCP clients to transmit signaling messages to their closest PCP-aware on-pathNAT, firewall, or other middlebox without having to learn the IP address of that middlebox via some external channel. This document establishes one well-known IPv4 address and one well-known IPv6 address to be used as PCP anycast addresses. |
|
| |
| RFC 7724 | Active DHCPv4 Lease Query |
| |
| Authors: | K. Kinnear, M. Stapp, B. Volz, N. Russell. |
| Date: | December 2015 |
| Formats: | txt html json |
| Updates: | RFC 6926 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7724 |
|
The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) has been extended with a Leasequery capability that allows a requestor to request information about DHCPv4 bindings (RFC 4388). That mechanism is limited to queries for individual bindings. In some situations, individual binding queries may not be efficient, or even possible.In addition, continuous update of an external requestor withLeasequery data is sometimes desired. This document expands on theDHCPv4 Leasequery protocol, and allows for active transfer of near real-time DHCPv4 binding information data via TCP. This document updates RFC 6926, "DHCPv4 Bulk Leasequery". |
|
| |
| RFC 7725 | An HTTP Status Code to Report Legal Obstacles |
| |
| Authors: | T. Bray. |
| Date: | February 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7725 |
|
This document specifies a Hypertext Transfer Protocol (HTTP) status code for use when resource access is denied as a consequence of legal demands. |
|
| |
| RFC 7726 | Clarifying Procedures for Establishing BFD Sessions for MPLS Label Switched Paths (LSPs) |
| |
| Authors: | V. Govindan, K. Rajaraman, G. Mirsky, N. Akiya, S. Aldrin. |
| Date: | January 2016 |
| Formats: | txt json html |
| Updates: | RFC 5884 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7726 |
|
This document clarifies the procedures for establishing, maintaining, and removing multiple, concurrent BFD (Bidirectional ForwardingDetection) sessions for a given <MPLS LSP, FEC&rt; as described in RFC5884. |
|
| |
| RFC 7727 | Spanning Tree Protocol (STP) Application of the Inter-Chassis Communication Protocol (ICCP) |
| |
| Authors: | M. Zhang, H. Wen, J. Hu. |
| Date: | January 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7727 |
|
The Inter-Chassis Communication Protocol (ICCP) supports an inter- chassis redundancy mechanism that is used to support high network availability.
In this document, Provider Edge (PE) devices in a Redundancy Group(RG) running ICCP are used to offer multihomed connectivity toSpanning Tree Protocol (STP) networks to improve availability of theSTP networks. The ICCP TLVs and usage for the ICCP STP application are defined. |
|
| |
| RFC 7728 | RTP Stream Pause and Resume |
| |
| Authors: | B. Burman, A. Akram, R. Even, M. Westerlund. |
| Date: | February 2016 |
| Formats: | txt html json |
| Updates: | RFC 5104 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7728 |
|
With the increased popularity of real-time multimedia applications, it is desirable to provide good control of resource usage, and users also demand more control over communication sessions. This document describes how a receiver in a multimedia conversation can pause and resume incoming data from a sender by sending real-time feedback messages when using the Real-time Transport Protocol (RTP) for real- time data transport. This document extends the Codec Control Message(CCM) RTP Control Protocol (RTCP) feedback package by explicitly allowing and describing specific use of existing CCMs and adding a group of new real-time feedback messages used to pause and resume RTP data streams. This document updates RFC 5104. |
|
| |
| RFC 7729 | Forwarding and Control Element Separation (ForCES) Logical Functional Block (LFB) Subsidiary Management |
| |
| Authors: | B. Khasnabish, E. Haleplidis, J. Hadi Salim, Ed.. |
| Date: | December 2015 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7729 |
|
Deployment experience has demonstrated the value of using theForwarding and Control Element Separation (ForCES) architecture to manage resources other than packet forwarding. In that spirit, theForwarding Element Manager (FEM) is modeled by creating a LogicalFunctional Block (LFB) to represent its functionality. We refer to this LFB as the Subsidiary Mechanism (SM) LFB. A Control Element(CE) that controls a Forwarding Element's (FE) resources can also manage its configuration via the SM LFB. This document introduces the SM LFB class, an LFB class that specifies the configuration parameters of an FE. The configuration parameters include new LFB class loading and CE associations; they also provide manipulation of debug mechanisms along with a general purpose attribute definition to describe configuration information. |
|
| |
| RFC 7730 | Resource Public Key Infrastructure (RPKI) Trust Anchor Locator |
| |
| Authors: | G. Huston, S. Weiler, G. Michaelson, S. Kent. |
| Date: | January 2016 |
| Formats: | txt html json |
| Obsoletes: | RFC 6490 |
| Obsoleted by: | RFC 8630 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7730 |
|
This document defines a Trust Anchor Locator (TAL) for the ResourcePublic Key Infrastructure (RPKI). This document obsoletes RFC 6490 by adding support for multiple URIs in a TAL. |
|
| |
| RFC 7731 | Multicast Protocol for Low-Power and Lossy Networks (MPL) |
| |
| Authors: | J. Hui, R. Kelsey. |
| Date: | February 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7731 |
|
This document specifies the Multicast Protocol for Low-Power andLossy Networks (MPL), which provides IPv6 multicast forwarding in constrained networks. MPL avoids the need to construct or maintain any multicast forwarding topology, disseminating messages to all MPLForwarders in an MPL Domain.
MPL has two modes of operation. One mode uses the Trickle algorithm to manage control-plane and data-plane message transmissions and is applicable for deployments with few multicast sources. The other mode uses classic flooding. By providing both modes and parameterization of the Trickle algorithm, an MPL implementation can be used in a variety of multicast deployments and can trade between dissemination latency and transmission efficiency. |
|
| |
| RFC 7733 | Applicability Statement: The Use of the Routing Protocol for Low-Power and Lossy Networks (RPL) Protocol Suite in Home Automation and Building Control |
| |
| Authors: | A. Brandt, E. Baccelli, R. Cragie, P. van der Stok. |
| Date: | February 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7733 |
|
The purpose of this document is to provide guidance in the selection and use of protocols from the Routing Protocol for Low-Power andLossy Networks (RPL) protocol suite to implement the features required for control in building and home environments. |
|
| |
| RFC 7734 | Support for Shortest Path Bridging MAC Mode over Ethernet VPN (EVPN) |
| |
| Authors: | D. Allan, Ed., J. Tantsura, D. Fedyk, A. Sajassi. |
| Date: | January 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7734 |
|
This document describes how Ethernet Shortest Path Bridging MAC mode(SPBM) can be combined with Ethernet VPN (EVPN) to interwork withProvider Backbone Bridging Provider Edges (PBB PEs) as described in the PBB-EVPN solution (RFC 7623). This is achieved via operational isolation of each Ethernet network attached to an EVPN core while supporting full interworking between the different variations ofEthernet networks. |
|
| |
| RFC 7737 | Label Switched Path (LSP) Ping and Traceroute Reply Mode Simplification |
| |
| Authors: | N. Akiya, G. Swallow, C. Pignataro, L. Andersson, M. Chen. |
| Date: | January 2016 |
| Formats: | txt json html |
| Updates: | RFC 7110 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7737 |
|
The Multiprotocol Label Switching (MPLS) Label Switched Path (LSP)Ping and Traceroute use the Reply Mode field to signal the method to be used in the MPLS echo reply. This document updates the procedures for the "Reply via Specified Path" Reply Mode. The value of thisReply Mode is 5. The update creates a simple way to indicate that the reverse LSP should be used as the return path. This document also adds an optional TLV that can carry an ordered list of ReplyMode values.
This document updates RFC 7110. |
|
| |
| RFC 7740 | Simulating Partial Mesh of Multipoint-to-Multipoint (MP2MP) Provider Tunnels with Ingress Replication |
| |
| Authors: | Z. Zhang, Y. Rekhter, A. Dolganow. |
| Date: | January 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7740 |
|
RFC 6513 ("Multicast in MPLS/BGP IP VPNs") describes a method to support bidirectional customer multicast flows using a partial mesh of Multipoint-to-Multipoint (MP2MP) tunnels. This document specifies how a partial mesh of MP2MP tunnels can be simulated using IngressReplication. This solution enables a service provider to use IngressReplication to offer transparent bidirectional multicast service to its VPN customers. |
|
| |
| RFC 7741 | RTP Payload Format for VP8 Video |
| |
| Authors: | P. Westin, H. Lundin, M. Glover, J. Uberti, F. Galligan. |
| Date: | March 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7741 |
|
This memo describes an RTP payload format for the VP8 video codec.The payload format has wide applicability, as it supports applications from low-bitrate peer-to-peer usage to high-bitrate video conferences. |
|
| |
| RFC 7742 | WebRTC Video Processing and Codec Requirements |
| |
| Authors: | A.B. Roach. |
| Date: | March 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7742 |
|
This specification provides the requirements and considerations forWebRTC applications to send and receive video across a network. It specifies the video processing that is required as well as video codecs and their parameters. |
|
| |
| RFC 7743 | Relayed Echo Reply Mechanism for Label Switched Path (LSP) Ping |
| |
| Authors: | J. Luo, Ed., L. Jin, Ed., T. Nadeau, Ed., G. Swallow, Ed.. |
| Date: | January 2016 |
| Formats: | txt html json |
| Updates: | RFC 4379 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7743 |
|
In some inter-AS (Autonomous System) and inter-area deployment scenarios for RFC 4379 ("Label Switched Path (LSP) Ping andTraceroute"), a replying Label Switching Router (LSR) may not have the available route to an initiator, and the Echo Reply message sent to the initiator would be discarded, resulting in false negatives or a complete failure of operation of the LSP Ping and Traceroute. This document describes extensions to the LSP Ping mechanism to enable the replying LSR to have the capability to relay the Echo Response by a set of routable intermediate nodes to the initiator. This document updates RFC 4379. |
|
| |
| RFC 7746 | Label Switched Path (LSP) Self-Ping |
| |
| Authors: | R. Bonica, I. Minei, M. Conn, D. Pacella, L. Tomotaki. |
| Date: | January 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7746 |
|
When certain RSVP-TE optimizations are implemented, ingress LabelSwitching Router (LSRs) can receive RSVP RESV messages before forwarding state has been installed on all downstream nodes.According to the RSVP-TE specification, the ingress LSR can forward traffic through a Label Switched Path (LSP) as soon as it receives aRESV message. However, if the ingress LSR forwards traffic through the LSP before forwarding state has been installed on all downstream nodes, traffic can be lost.
This document describes LSP Self-ping. When an ingress LSR receives an RESV message, it can invoke LSP Self-ping procedures to ensure that forwarding state has been installed on all downstream nodes.
LSP Self-ping is a new protocol. It is not an extension of LSP Ping.Although LSP Ping and LSP Self-ping are named similarly, each is designed for a unique purpose. Each protocol listens on its own UDP port and executes its own procedures.
LSP Self-ping is an extremely lightweight mechanism. It does not consume control-plane resources on transit or egress LSRs. |
|
| |
| RFC 7750 | Differentiated Service Code Point and Explicit Congestion Notification Monitoring in the Two-Way Active Measurement Protocol (TWAMP) |
| |
| Authors: | J. Hedin, G. Mirsky, S. Baillargeon. |
| Date: | February 2016 |
| Formats: | txt json html |
| Updates: | RFC 5357 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7750 |
|
This document describes an optional extension for Two-Way ActiveMeasurement Protocol (TWAMP) allowing the monitoring of theDifferentiated Service Code Point and Explicit CongestionNotification fields with the TWAMP-Test protocol. |
|
| |
| RFC 7751 | Kerberos Authorization Data Container Authenticated by Multiple Message Authentication Codes (MACs) |
| |
|
|
This document specifies a Kerberos authorization data container that supersedes AD-KDC-ISSUED. It allows for multiple MessageAuthentication Codes (MACs) or signatures to authenticate the contained authorization data elements. The multiple MACs are needed to mitigate shortcomings in the existing AD-KDC-ISSUED container.This document updates RFC 4120. |
|
| |
| RFC 7752 | North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP |
| |
| Authors: | H. Gredler, Ed., J. Medved, S. Previdi, A. Farrel, S. Ray. |
| Date: | March 2016 |
| Formats: | txt html json |
| Obsoleted by: | RFC 9552 |
| Updated by: | RFC 9029 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7752 |
|
In a number of environments, a component external to a network is called upon to perform computations based on the network topology and current state of the connections within the network, includingTraffic Engineering (TE) information. This is information typically distributed by IGP routing protocols within the network.
This document describes a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol. This is achieved using a new BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism is applicable to physical and virtual IGP links. The mechanism described is subject to policy control.
Applications of this technique include Application-Layer TrafficOptimization (ALTO) servers and Path Computation Elements (PCEs). |
|
| |
| RFC 7753 | Port Control Protocol (PCP) Extension for Port-Set Allocation |
| |
| Authors: | Q. Sun, M. Boucadair, S. Sivakumar, C. Zhou, T. Tsou, S. Perreault. |
| Date: | February 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7753 |
|
In some use cases, e.g., Lightweight 4over6, the client may require not just one port, but a port set. This document defines an extension to the Port Control Protocol (PCP) that allows clients to manipulate a set of ports as a whole. This is accomplished using a new MAP option: PORT_SET. |
|
| |
| RFC 7757 | Explicit Address Mappings for Stateless IP/ICMP Translation |
| |
| Authors: | T. Anderson, A. Leiva Popper. |
| Date: | February 2016 |
| Formats: | txt html json |
| Updates: | RFC 6145 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7757 |
|
This document extends the Stateless IP/ICMP Translation Algorithm(SIIT) with an Explicit Address Mapping (EAM) algorithm and formally updates RFC 6145. The EAM algorithm facilitates stateless IP/ICMP translation between arbitrary (non-IPv4-translatable) IPv6 endpoints and IPv4. |
|
| |
| RFC 7759 | Configuration of Proactive Operations, Administration, and Maintenance (OAM) Functions for MPLS-Based Transport Networks Using Label Switched Path (LSP) Ping |
| |
| Authors: | E. Bellagamba, G. Mirsky, L. Andersson, P. Skoldstrom, D. Ward, J. Drake. |
| Date: | February 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7759 |
|
This specification describes the configuration of proactive MPLS-TPOperations, Administration, and Maintenance (OAM) functions for a given Label Switched Path (LSP) using a set of TLVs that are carried by the LSP Ping protocol. |
|
| |
| RFC 7766 | DNS Transport over TCP - Implementation Requirements |
| |
|
|
This document specifies the requirement for support of TCP as a transport protocol for DNS implementations and provides guidelines towards DNS-over-TCP performance on par with that of DNS-over-UDP.This document obsoletes RFC 5966 and therefore updates RFC 1035 andRFC 1123. |
|
| |
| RFC 7769 | Media Access Control (MAC) Address Withdrawal over Static Pseudowire |
| |
| Authors: | S. Sivabalan, S. Boutros, H. Shah, S. Aldrin, M. Venkatesan. |
| Date: | February 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7769 |
|
This document specifies a mechanism to signal Media Access Control(MAC) address withdrawal notification using a pseudowire (PW)Associated Channel (ACH). Such notification is useful when statically provisioned PWs are deployed in a Virtual Private LANService (VPLS) or Hierarchical Virtual Private LAN Service (H-VPLS) environment. |
|
| |
| RFC 7770 | Extensions to OSPF for Advertising Optional Router Capabilities |
| |
| Authors: | A. Lindem, Ed., N. Shen, JP. Vasseur, R. Aggarwal, S. Shaffer. |
| Date: | February 2016 |
| Formats: | txt json html |
| Obsoletes: | RFC 4970 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7770 |
|
It is useful for routers in an OSPFv2 or OSPFv3 routing domain to know the capabilities of their neighbors and other routers in the routing domain. This document proposes extensions to OSPFv2 andOSPFv3 for advertising optional router capabilities. The RouterInformation (RI) Link State Advertisement (LSA) is defined for this purpose. In OSPFv2, the RI LSA will be implemented with an OpaqueLSA type ID. In OSPFv3, the RI LSA will be implemented with a uniqueLSA type function code. In both protocols, the RI LSA can be advertised at any of the defined flooding scopes (link, area, or autonomous system (AS)). This document obsoletes RFC 4970 by providing a revised specification that includes support for advertisement of multiple instances of the RI LSA and a TLV for functional capabilities. |
|
| |
| RFC 7771 | Switching Provider Edge (S-PE) Protection for MPLS and MPLS Transport Profile (MPLS-TP) Static Multi-Segment Pseudowires |
| |
| Authors: | A. Malis, Ed., L. Andersson, H. van Helvoort, J. Shin, L. Wang, A. D'Alessandro. |
| Date: | January 2016 |
| Formats: | txt json html |
| Updates: | RFC 6870 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7771 |
|
In MPLS and MPLS Transport Profile (MPLS-TP) environments, statically provisioned Single-Segment Pseudowires (SS-PWs) are protected against tunnel failure via MPLS-level and MPLS-TP-level tunnel protection.With statically provisioned Multi-Segment Pseudowires (MS-PWs), each segment of the MS-PW is likewise protected from tunnel failures viaMPLS-level and MPLS-TP-level tunnel protection. However, static MS-PWs are not protected end-to-end against failure of one of theSwitching Provider Edge Routers (S-PEs) along the path of the MS-PW.This document describes how to achieve this protection via redundantMS-PWs by updating the existing procedures in RFC 6870. It also contains an optional approach based on MPLS-TP Linear Protection. |
|
| |
| RFC 7773 | Authentication Context Certificate Extension |
| |
| Authors: | S. Santesson. |
| Date: | March 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7773 |
|
This document defines an extension to X.509 certificates. The extension defined in this document holds data about how the certificate subject was authenticated by the Certification Authority that issued the certificate in which this extension appears.
This document also defines one data structure for inclusion in this extension. The data structure is designed to hold information when the subject is authenticated using a Security Assertion MarkupLanguage (SAML) assertion. |
|
| |
| RFC 7774 | Multicast Protocol for Low-Power and Lossy Networks (MPL) Parameter Configuration Option for DHCPv6 |
| |
| Authors: | Y. Doi, M. Gillmore. |
| Date: | March 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7774 |
|
This document defines a way to configure a parameter set for MPL(Multicast Protocol for Low-Power and Lossy Networks) via a DHCPv6 option. MPL has a set of parameters to control its behavior, and the parameter set is often configured as a network-wide parameter because the parameter set should be identical for each MPL Forwarder in anMPL Domain. Using the MPL Parameter Configuration Option defined in this document, a network can easily be configured with a single set of MPL parameters. |
|
| |
| RFC 7775 | IS-IS Route Preference for Extended IP and IPv6 Reachability |
| |
| Authors: | L. Ginsberg, S. Litkowski, S. Previdi. |
| Date: | February 2016 |
| Formats: | txt json html |
| Updates: | RFC 5308 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7775 |
|
In existing specifications, the route preferences for IPv4/IPv6Extended Reachability TLVs are not explicitly stated. There are also inconsistencies in the definition of how the up/down bit applies to route preference when the prefix advertisement appears in Level 2Link State Protocol Data Units (LSPs). This document addresses these issues.
This document updates RFC 5308. |
|
| |
| RFC 7777 | Advertising Node Administrative Tags in OSPF |
| |
| Authors: | S. Hegde, R. Shakir, A. Smirnov, Z. Li, B. Decraene. |
| Date: | March 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7777 |
|
This document describes an extension to the OSPF protocol to add an optional operational capability that allows tagging and grouping of the nodes in an OSPF domain. This allows simplification, ease of management and control over route and path selection based on configured policies. This document describes an extension to theOSPF protocol to advertise node administrative tags. The node tags can be used to express and apply locally defined network policies, which are a very useful operational capability. Node tags may be used by either OSPF itself or other applications consuming information propagated via OSPF.
This document describes the protocol extensions to disseminate node administrative tags to the OSPFv2 and OSPFv3 protocol. It provides example use cases of administrative node tags. |
|
| |
| RFC 7780 | Transparent Interconnection of Lots of Links (TRILL): Clarifications, Corrections, and Updates |
| |
|
|
Since the publication of the TRILL (Transparent Interconnection ofLots of Links) base protocol in 2011, active development and deployment of TRILL have revealed errata in RFC 6325 and areas that could use clarifications or updates. RFC 7177, RFC 7357, and an intended replacement of RFC 6439 provide clarifications and updates with respect to adjacency, the TRILL ESADI (End Station AddressDistribution Information) protocol, and Appointed Forwarders, respectively. This document provides other known clarifications, corrections, and updates. It obsoletes RFC 7180 (the previous "TRILL clarifications, corrections, and updates" RFC), and it updates RFCs6325, 7177, and 7179. |
|
| |
| RFC 7781 | Transparent Interconnection of Lots of Links (TRILL): Pseudo-Nickname for Active-Active Access |
| |
| Authors: | H. Zhai, T. Senevirathne, R. Perlman, M. Zhang, Y. Li. |
| Date: | February 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7781 |
|
The IETF TRILL (Transparent Interconnection of Lots of Links) protocol provides support for flow-level multipathing for both unicast and multi-destination traffic in networks with arbitrary topology. Active-active access at the TRILL edge is the extension of these characteristics to end stations that are multiply connected to a TRILL campus as discussed in RFC 7379. In this document, the edgeRBridge (Routing Bridge, or TRILL switch) group providing active- active access to such an end station is represented as a virtualRBridge. Based on the concept of the virtual RBridge, along with its pseudo-nickname, this document specifies a method for TRILL active- active access by such end stations. |
|
| |
| RFC 7782 | Transparent Interconnection of Lots of Links (TRILL) Active-Active Edge Using Multiple MAC Attachments |
| |
| Authors: | M. Zhang, R. Perlman, H. Zhai, M. Durrani, S. Gupta. |
| Date: | February 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7782 |
|
TRILL (Transparent Interconnection of Lots of Links) active-active service provides end stations with flow-level load balance and resilience against link failures at the edge of TRILL campuses, as described in RFC 7379.
This document specifies a method by which member RBridges (also referred to as Routing Bridges or TRILL switches) in an active-active edge RBridge group use their own nicknames as ingress RBridge nicknames to encapsulate frames from attached end systems. Thus, remote edge RBridges (who are not in the group) will see one hostMedia Access Control (MAC) address being associated with the multipleRBridges in the group. Such remote edge RBridges are required to maintain all those associations (i.e., MAC attachments) and to not flip-flop among them (as would occur prior to the implementation of this specification). The design goals of this specification are discussed herein. |
|
| |
| RFC 7783 | Coordinated Multicast Trees (CMT) for Transparent Interconnection of Lots of Links (TRILL) |
| |
| Authors: | T. Senevirathne, J. Pathangi, J. Hudson. |
| Date: | February 2016 |
| Formats: | txt html json |
| Updates: | RFC 6325 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7783 |
|
TRILL (Transparent Interconnection of Lots of Links) facilitates loop-free connectivity to non-TRILL networks via a choice of anAppointed Forwarder for a set of VLANs. Appointed Forwarders provideVLAN-based load sharing with an active-standby model. High- performance applications require an active-active load-sharing model.The active-active load-sharing model can be accomplished by representing any given non-TRILL network with a single virtualRBridge (also referred to as a virtual Routing Bridge or virtualTRILL switch). Virtual representation of the non-TRILL network with a single RBridge poses serious challenges in multi-destination RPF(Reverse Path Forwarding) check calculations. This document specifies required enhancements to build Coordinated Multicast Trees(CMT) within the TRILL campus to solve related RPF issues. CMT, which only requires a software upgrade, provides flexibility toRBridges in selecting a desired path of association to a given TRILL multi-destination distribution tree. This document updates RFC 6325. |
|
| |
| RFC 7784 | Transparent Interconnection of Lots of Links (TRILL) Operations, Administration, and Maintenance (OAM) MIB |
| |
| Authors: | D. Kumar, S. Salam, T. Senevirathne. |
| Date: | February 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7784 |
|
This document specifies the MIB for the OAM (Operations,Administration, and Maintenance) objects for IETF TRILL (TransparentInterconnection of Lots of Links). |
|
| |
| RFC 7787 | Distributed Node Consensus Protocol |
| |
| Authors: | M. Stenberg, S. Barth. |
| Date: | April 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7787 |
|
This document describes the Distributed Node Consensus Protocol(DNCP), a generic state synchronization protocol that uses theTrickle algorithm and hash trees. DNCP is an abstract protocol and must be combined with a specific profile to make a complete implementable protocol. |
|
| |
| RFC 7788 | Home Networking Control Protocol |
| |
| Authors: | M. Stenberg, S. Barth, P. Pfister. |
| Date: | April 2016 |
| Formats: | txt json html |
| Updated by: | RFC 8375 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7788 |
|
This document describes the Home Networking Control Protocol (HNCP), an extensible configuration protocol, and a set of requirements for home network devices. HNCP is described as a profile of and extension to the Distributed Node Consensus Protocol (DNCP). HNCP enables discovery of network borders, automated configuration of addresses, name resolution, service discovery, and the use of any routing protocol that supports routing based on both the source and destination address. |
|
| |
| RFC 7791 | Cloning the IKE Security Association in the Internet Key Exchange Protocol Version 2 (IKEv2) |
| |
| Authors: | D. Migault, Ed., V. Smyslov. |
| Date: | March 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7791 |
|
This document considers a VPN end user establishing an IPsec SecurityAssociation (SA) with a Security Gateway using the Internet KeyExchange Protocol version 2 (IKEv2), where at least one of the peers has multiple interfaces or where Security Gateway is a cluster with each node having its own IP address.
The protocol described allows a peer to clone an IKEv2 SA, where an additional SA is derived from an existing one. The newly created IKESA is set without the IKEv2 authentication exchange. This IKE SA can later be assigned to another interface or moved to another cluster node. |
|
| |
| RFC 7792 | RSVP-TE Signaling Extensions in Support of Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks |
| |
| Authors: | F. Zhang, X. Zhang, A. Farrel, O. Gonzalez de Dios, D. Ceccarelli. |
| Date: | March 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7792 |
|
This memo describes the extensions to the Resource ReservationProtocol - Traffic Engineering (RSVP-TE) signaling protocol to support Label Switched Paths (LSPs) in a GMPLS-controlled network that includes devices using the flexible optical grid. |
|
| |
| RFC 7794 | IS-IS Prefix Attributes for Extended IPv4 and IPv6 Reachability |
| |
| Authors: | L. Ginsberg, Ed., B. Decraene, S. Previdi, X. Xu, U. Chunduri. |
| Date: | March 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7794 |
|
This document introduces new sub-TLVs to support advertisement ofIPv4 and IPv6 prefix attribute flags and the source router ID of the router that originated a prefix advertisement. |
|
| |
| RFC 7795 | Pseudowire Redundancy on the Switching Provider Edge (S-PE) |
| |
| Authors: | J. Dong, H. Wang. |
| Date: | February 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7795 |
|
This document describes Multi-Segment Pseudowire (MS-PW) protection scenarios in which pseudowire redundancy is provided on the SwitchingProvider Edge (S-PE) as defined in RFC 5659. Operations of the S-PEs that provide PW redundancy are specified in this document. Signaling of the Preferential Forwarding status as defined in RFCs 6870 and6478 is reused. This document does not require any change to theTerminating Provider Edges (T-PEs) of MS-PW. |
|
| |
| RFC 7796 | Ethernet-Tree (E-Tree) Support in Virtual Private LAN Service (VPLS) |
| |
| Authors: | Y. Jiang, Ed., L. Yong, M. Paul. |
| Date: | March 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7796 |
|
This document specifies a generic Virtual Private LAN Service (VPLS) solution, which uses VLANs to indicate root or leaf traffic to support Ethernet-Tree (E-Tree) services. A VPLS Provider Edge (PE) model is illustrated as an example for the solution. In the solution, E-Tree VPLS PEs are interconnected by Pseudowires (PWs), which carry the VLAN indicating the E-Tree attribute. The MAC address-based Ethernet forwarding engine and the PW work in the same way as specified in RFC 4762 and RFC 4448, respectively. A signaling mechanism is described to support E-Tree capability and VLAN mapping negotiation. |
|
| |
| RFC 7797 | JSON Web Signature (JWS) Unencoded Payload Option |
| |
|
|
JSON Web Signature (JWS) represents the payload of a JWS as a base64url-encoded value and uses this value in the JWS Signature computation. While this enables arbitrary payloads to be integrity protected, some have described use cases in which the base64url encoding is unnecessary and/or an impediment to adoption, especially when the payload is large and/or detached. This specification defines a means of accommodating these use cases by defining an option to change the JWS Signing Input computation to not base64url- encode the payload. This option is intended to broaden the set of use cases for which the use of JWS is a good fit.
This specification updates RFC 7519 by stating that JSON Web Tokens(JWTs) MUST NOT use the unencoded payload option defined by this specification. |
|
| |
| RFC 7798 | RTP Payload Format for High Efficiency Video Coding (HEVC) |
| |
| Authors: | Y.-K. Wang, Y. Sanchez, T. Schierl, S. Wenger, M. M. Hannuksela. |
| Date: | March 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7798 |
|
This memo describes an RTP payload format for the video coding standard ITU-T Recommendation H.265 and ISO/IEC InternationalStandard 23008-2, both also known as High Efficiency Video Coding(HEVC) and developed by the Joint Collaborative Team on Video Coding(JCT-VC). The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload as well as fragmentation of a NAL unit into multiple RTP packets.Furthermore, it supports transmission of an HEVC bitstream over a single stream as well as multiple RTP streams. When multiple RTP streams are used, a single transport or multiple transports may be utilized. The payload format has wide applicability in videoconferencing, Internet video streaming, and high-bitrate entertainment-quality video, among others. |
|
| |
| RFC 7800 | Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) |
| |
| Authors: | M. Jones, J. Bradley, H. Tschofenig. |
| Date: | April 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7800 |
|
This specification describes how to declare in a JSON Web Token (JWT) that the presenter of the JWT possesses a particular proof-of- possession key and how the recipient can cryptographically confirm proof of possession of the key by the presenter. Being able to prove possession of a key is also sometimes described as the presenter being a holder-of-key. |
|
| |
| RFC 7802 | A Pseudo-Random Function (PRF) for the Kerberos V Generic Security Service Application Program Interface (GSS-API) Mechanism |
| |
|
|
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.
This document obsoletes RFC 4402 and reclassifies that document asHistoric. RFC 4402 starts the PRF+ counter at 1; however, a number of implementations start the counter at 0. As a result, the original specification would not be interoperable with existing implementations. |
|
| |
| RFC 7807 | Problem Details for HTTP APIs |
| |
| Authors: | M. Nottingham, E. Wilde. |
| Date: | March 2016 |
| Formats: | txt json html |
| Obsoleted by: | RFC 9457 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7807 |
|
This document defines a "problem detail" as a way to carry machine- readable details of errors in a HTTP response to avoid the need to define new error response formats for HTTP APIs. |
|
| |
| RFC 7808 | Time Zone Data Distribution Service |
| |
| Authors: | M. Douglass, C. Daboo. |
| Date: | March 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7808 |
|
This document defines a time zone data distribution service that allows reliable, secure, and fast delivery of time zone data and leap-second rules to client systems such as calendaring and scheduling applications or operating systems. |
|
| |
| RFC 7809 | Calendaring Extensions to WebDAV (CalDAV): Time Zones by Reference |
| |
|
|
This document defines an update to the Calendaring Extensions toWebDAV (CalDAV) calendar access protocol (RFC 4791) to allow clients and servers to exchange iCalendar data without the need to send full time zone data. |
|
| |
| RFC 7810 | IS-IS Traffic Engineering (TE) Metric Extensions |
| |
| Authors: | S. Previdi, Ed., S. Giacalone, D. Ward, J. Drake, Q. Wu. |
| Date: | May 2016 |
| Formats: | txt html json |
| Obsoleted by: | RFC 8570 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7810 |
|
In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network- performance criteria (e.g., latency) are becoming as critical to data-path selection as other metrics.
This document describes extensions to IS-IS Traffic EngineeringExtensions (RFC 5305) such that network-performance information can be distributed and collected in a scalable fashion. The information distributed using IS-IS TE Metric Extensions can then be used to make path-selection decisions based on network performance.
Note that this document only covers the mechanisms with which network-performance information is distributed. The mechanisms for measuring network performance or acting on that information, once distributed, are outside the scope of this document. |
|
| |
| RFC 7811 | An Algorithm for Computing IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-FRR) |
| |
| Authors: | G. Enyedi, A. Csaszar, A. Atlas, C. Bowers, A. Gopalan. |
| Date: | June 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7811 |
|
This document supports the solution put forth in "An Architecture forIP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-FRR)"(RFC 7812) by defining the associated MRT Lowpoint algorithm that is used in the Default MRT Profile to compute both the necessaryMaximally Redundant Trees with their associated next hops and the alternates to select for MRT-FRR. |
|
| |
| RFC 7812 | An Architecture for IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-FRR) |
| |
| Authors: | A. Atlas, C. Bowers, G. Enyedi. |
| Date: | June 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7812 |
|
This document defines the architecture for IP and LDP Fast Reroute using Maximally Redundant Trees (MRT-FRR). MRT-FRR is a technology that gives link-protection and node-protection with 100% coverage in any network topology that is still connected after the failure. |
|
| |
| RFC 7813 | IS-IS Path Control and Reservation |
| |
| Authors: | J. Farkas, Ed., N. Bragg, P. Unbehagen, G. Parsons, P. Ashwood-Smith, C. Bowers. |
| Date: | June 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7813 |
|
IEEE 802.1Qca Path Control and Reservation (PCR) specifies explicit path control via IS-IS in Layer 2 networks in order to move beyond the shortest path capabilities provided by IEEE 802.1aq Shortest PathBridging (SPB). IS-IS PCR provides capabilities for the establishment and control of explicit forwarding trees in a Layer 2 network domain. This document specifies the sub-TLVs for IS-IS PCR. |
|
| |
| RFC 7817 | Updated Transport Layer Security (TLS) Server Identity Check Procedure for Email-Related Protocols |
| |
|
|
This document describes the Transport Layer Security (TLS) server identity verification procedure for SMTP Submission, IMAP, POP, andManageSieve clients. It replaces Section 2.4 (Server Identity Check) of RFC 2595 and updates Section 4.1 (Processing After the STARTTLSCommand) of RFC 3207, Section 11.1 (STARTTLS Security Considerations) of RFC 3501, and Section 2.2.1 (Server Identity Check) of RFC 5804. |
|
| |
| RFC 7822 | Network Time Protocol Version 4 (NTPv4) Extension Fields |
| |
|
|
The Network Time Protocol version 4 (NTPv4) defines the optional usage of extension fields. An extension field, as defined in RFC5905, is an optional field that resides at the end of the NTP header and that can be used to add optional capabilities or additional information that is not conveyed in the standard NTP header. This document updates RFC 5905 by clarifying some points regarding NTP extension fields and their usage with Message Authentication Codes(MACs). |
|
| |
| RFC 7825 | A Network Address Translator (NAT) Traversal Mechanism for Media Controlled by the Real-Time Streaming Protocol (RTSP) |
| |
| Authors: | J. Goldberg, M. Westerlund, T. Zeng. |
| Date: | December 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7825 |
|
This document defines a solution for Network Address Translation(NAT) traversal for datagram-based media streams set up and controlled with the Real-Time Streaming Protocol version 2 (RTSP2.0). It uses Interactive Connectivity Establishment (ICE) adapted to use RTSP as a signaling channel, defining the necessary RTSP extensions and procedures. |
|
| |
| RFC 7826 | Real-Time Streaming Protocol Version 2.0 |
| |
| Authors: | H. Schulzrinne, A. Rao, R. Lanphier, M. Westerlund, M. Stiemerling, Ed.. |
| Date: | December 2016 |
| Formats: | txt json html |
| Obsoletes: | RFC 2326 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7826 |
|
This memorandum defines the Real-Time Streaming Protocol (RTSP) version 2.0, which obsoletes RTSP version 1.0 defined in RFC 2326.
RTSP is an application-layer protocol for the setup and control of 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 3550). |
|
| |
| RFC 7828 | The edns-tcp-keepalive EDNS0 Option |
| |
| Authors: | P. Wouters, J. Abley, S. Dickinson, R. Bellis. |
| Date: | April 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7828 |
|
DNS messages between clients and servers may be received over eitherUDP or TCP. UDP transport involves keeping less state on a busy server, but can cause truncation and retries over TCP. Additionally,UDP can be exploited for reflection attacks. Using TCP would reduce retransmits and amplification. However, clients commonly use TCP only for retries and servers typically use idle timeouts on the order of seconds.
This document defines an EDNS0 option ("edns-tcp-keepalive") that allows DNS servers to signal a variable idle timeout. This signalling encourages the use of long-lived TCP connections by allowing the state associated with TCP transport to be managed effectively with minimal impact on the DNS transaction time. |
|
| |
| RFC 7829 | SCTP-PF: A Quick Failover Algorithm for the Stream Control Transmission Protocol |
| |
| Authors: | Y. Nishida, P. Natarajan, A. Caro, P. Amer, K. Nielsen. |
| Date: | April 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7829 |
|
The Stream Control Transmission Protocol (SCTP) supports multihoming.However, when the failover operation specified in RFC 4960 is followed, there can be significant delay and performance degradation in the data transfer path failover. This document specifies a quick failover algorithm and introduces the SCTP Potentially Failed(SCTP-PF) destination state in SCTP Path Management.
This document also specifies a dormant state operation of SCTP that is required to be followed by an SCTP-PF implementation, but it may equally well be applied by a standard SCTP implementation, as described in RFC 4960.
Additionally, this document introduces an alternative switchback operation mode called "Primary Path Switchover" that will be beneficial in certain situations. This mode of operation applies to both a standard SCTP implementation and an SCTP-PF implementation.
The procedures defined in the document require only minimal modifications to the specification in RFC 4960. The procedures are sender-side only and do not impact the SCTP receiver. |
|
| |
| RFC 7830 | The EDNS(0) Padding Option |
| |
| Authors: | A. Mayrhofer. |
| Date: | May 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7830 |
|
This document specifies the EDNS(0) "Padding" option, which allowsDNS clients and servers to pad request and response messages by a variable number of octets. |
|
| |
| RFC 7833 | A RADIUS Attribute, Binding, Profiles, Name Identifier Format, and Confirmation Methods for the Security Assertion Markup Language (SAML) |
| |
| Authors: | J. Howlett, S. Hartman, A. Perez-Mendez, Ed.. |
| Date: | May 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7833 |
|
This document describes the use of the Security Assertion MarkupLanguage (SAML) with RADIUS in the context of the ApplicationBridging for Federated Access Beyond web (ABFAB) architecture. It defines two RADIUS attributes, a SAML binding, a SAML name identifier format, two SAML profiles, and two SAML confirmation methods. TheRADIUS attributes permit encapsulation of SAML Assertions and protocol messages within RADIUS, allowing SAML entities to communicate using the binding. The two profiles describe the application of this binding for ABFAB authentication and assertionQuery/Request, enabling a Relying Party to request authentication of, or assertions for, users or machines (clients). These clients may be named using a Network Access Identifier (NAI) name identifier format.Finally, the subject confirmation methods allow requests and queries to be issued for a previously authenticated user or machine without needing to explicitly identify them as the subject. The use of the artifacts defined in this document is not exclusive to ABFAB. They can be applied in any Authentication, Authorization, and Accounting(AAA) scenario, such as network access control. |
|
| |
| RFC 7838 | HTTP Alternative Services |
| |
| Authors: | M. Nottingham, P. McManus, J. Reschke. |
| Date: | April 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7838 |
|
This document specifies "Alternative Services" for HTTP, which allow an origin's resources to be authoritatively available at a separate network location, possibly accessed with a different protocol configuration. |
|
| |
| RFC 7839 | Access-Network-Identifier Option in DHCP |
| |
| Authors: | S. Bhandari, S. Gundavelli, M. Grayson, B. Volz, J. Korhonen. |
| Date: | June 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7839 |
|
This document specifies the format and mechanism that is to be used for encoding Access-Network Identifiers in DHCPv4 and DHCPv6 messages by defining new Access-Network-Identifier options and sub-options. |
|
| |
| RFC 7840 | A Routing Request Extension for the HTTP-Enabled Location Delivery (HELD) Protocol |
| |
|
|
For cases where location servers have access to emergency routing information, they are able to return routing information with the location information if the location request includes a request for the desired routing information. This document specifies an extension to the HTTP-Enabled Location Delivery (HELD) protocol that updates RFC 5985 to support this function. Allowing location and routing information to be acquired in a single request response exchange updates RFC 6881, as current location acquisition and route determination procedures are separate operations. |
|
| |
| RFC 7843 | Port Control Protocol (PCP) Third-Party ID Option |
| |
| Authors: | A. Ripke, R. Winter, T. Dietz, J. Quittek, R. da Silva. |
| Date: | May 2016 |
| Formats: | txt html json |
| Updates: | RFC 6887 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7843 |
|
This document describes a new Port Control Protocol (PCP) option called the THIRD_PARTY_ID option. It is designed to be used together with the THIRD_PARTY option specified in RFC 6887.
The THIRD_PARTY_ID option serves to identify a third party in situations where a third party's IP address contained in theTHIRD_PARTY option does not provide sufficient information to create requested mappings in a PCP-controlled device. |
|
| |
| RFC 7844 | Anonymity Profiles for DHCP Clients |
| |
| Authors: | C. Huitema, T. Mrugalski, S. Krishnan. |
| Date: | May 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7844 |
|
Some DHCP options carry unique identifiers. These identifiers can enable device tracking even if the device administrator takes care of randomizing other potential identifications like link-layer addresses or IPv6 addresses. The anonymity profiles are designed for clients that wish to remain anonymous to the visited network. The profiles provide guidelines on the composition of DHCP or DHCPv6 messages, designed to minimize disclosure of identifying information. |
|
| |
| RFC 7845 | Ogg Encapsulation for the Opus Audio Codec |
| |
|
|
This document defines the Ogg encapsulation for the Opus interactive speech and audio codec. This allows data encoded in the Opus format to be stored in an Ogg logical bitstream. |
|
| |
| RFC 7846 | Peer-to-Peer Streaming Tracker Protocol (PPSTP) |
| |
| Authors: | R. Cruz, M. Nunes, J. Xia, R. Huang, Ed., J. Taveira, D. Lingli. |
| Date: | May 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7846 |
|
This document specifies the base Peer-to-Peer Streaming TrackerProtocol (PPSTP) version 1, an application-layer control (signaling) protocol for the exchange of meta information between trackers and peers. The specification outlines the architecture of the protocol and its functionality; it also describes message flows, message processing instructions, message formats, formal syntax, and semantics. The PPSTP enables cooperating peers to form content- streaming overlay networks to support near real-time delivery of structured media content (audio, video, and associated timed text and metadata), such as adaptive multi-rate, layered (scalable), and multi-view (3D) videos in live, time-shifted, and on-demand modes. |
|
| |
| RFC 7848 | Mark and Signed Mark Objects Mapping |
| |
| Authors: | G. Lozano. |
| Date: | June 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7848 |
|
Domain Name Registries (DNRs) may operate in special modes for certain periods of time, enabling trademark holders to protect their rights during the introduction of a Top-Level Domain (TLD).
One of those special modes of operation is the Sunrise Period. TheSunrise Period allows trademark holders an advance opportunity to register domain names corresponding to their trademarks before names are generally available to the public.
This document describes the format of a mark and a digitally signed mark used by trademark holders for registering domain names during the Sunrise Period of generic Top-Level Domains (gTLDs). Three types of Mark objects are defined in this specification: registered trademarks, court-validated marks, and marks protected by statue or treaty. |
|
| |
| RFC 7850 | Registering Values of the SDP 'proto' Field for Transporting RTP Media over TCP under Various RTP Profiles |
| |
| Authors: | S. Nandakumar. |
| Date: | April 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7850 |
|
The Real-time Transport Protocol (RTP) specification establishes a registry of profile names for use by higher-level control protocols, such as the Session Description Protocol (SDP), to refer to the transport methods. This specification describes the following newSDP transport protocol identifiers for transporting RTP Media overTCP: 'TCP/RTP/AVPF', 'TCP/RTP/SAVP', 'TCP/RTP/SAVPF','TCP/DTLS/RTP/SAVP', 'TCP/DTLS/RTP/SAVPF', 'TCP/TLS/RTP/AVP', and'TCP/TLS/RTP/AVPF'. |
|
| |
| RFC 7851 | Peer-to-Peer (P2P) Overlay Diagnostics |
| |
| Authors: | H. Song, X. Jiang, R. Even, D. Bryan, Y. Sun. |
| Date: | May 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7851 |
|
This document describes mechanisms for Peer-to-Peer (P2P) overlay diagnostics. It defines extensions to the REsource LOcation AndDiscovery (RELOAD) base protocol to collect diagnostic information and details the protocol specifications for these extensions. Useful diagnostic information for connection and node status monitoring is also defined. The document also describes the usage scenarios and provides examples of how these methods are used to perform diagnostics. |
|
| |
| RFC 7852 | Additional Data Related to an Emergency Call |
| |
| Authors: | R. Gellens, B. Rosen, H. Tschofenig, R. Marshall, J. Winterbottom. |
| Date: | July 2016 |
| Formats: | txt html json |
| Updates: | RFC 6443, RFC 6881 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7852 |
|
When an emergency call is sent to a Public Safety Answering Point(PSAP), the originating device, the access network provider to which the device is connected, and all service providers in the path of the call have information about the call, the caller, or the location, which is helpful for the PSAP to have in handling the emergency.This document describes data structures and mechanisms to convey such data to the PSAP. The intent is that every emergency call carry as much of the information described here as possible using the mechanisms described here.
The mechanisms permit the data to be conveyed by reference (as an external resource) or by value (within the body of a SIP message or a location object). This follows the tradition of prior emergency services standardization work where data can be conveyed by value within the call signaling (i.e., in the body of the SIP message) or by reference. |
|
| |
| RFC 7854 | BGP Monitoring Protocol (BMP) |
| |
|
|
This document defines the BGP Monitoring Protocol (BMP), which can be used to monitor BGP sessions. BMP is intended to provide a convenient interface for obtaining route views. Prior to the introduction of BMP, screen scraping was the most commonly used approach to obtaining such views. The design goals are to keep BMP simple, useful, easily implemented, and minimally service affecting.BMP is not suitable for use as a routing protocol. |
|
| |
| RFC 7856 | Softwire Mesh Management Information Base (MIB) |
| |
| Authors: | Y. Cui, J. Dong, P. Wu, M. Xu, A. Yla-Jaaski. |
| Date: | May 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7856 |
|
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 a softwire mesh. |
|
| |
| RFC 7858 | Specification for DNS over Transport Layer Security (TLS) |
| |
| Authors: | Z. Hu, L. Zhu, J. Heidemann, A. Mankin, D. Wessels, P. Hoffman. |
| Date: | May 2016 |
| Formats: | txt json html |
| Updated by: | RFC 8310 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7858 |
|
This document describes the use of Transport Layer Security (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626. In addition, this document specifies two usage profiles for DNS over TLS and provides advice on performance considerations to minimize overhead from using TCP and TLS with DNS.
This document focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE Working Group. It does not prevent future applications of the protocol to recursive-to-authoritative traffic. |
|
| |
| RFC 7860 | HMAC-SHA-2 Authentication Protocols in User-Based Security Model (USM) for SNMPv3 |
| |
| Authors: | J. Merkle, Ed., M. Lochter. |
| Date: | April 2016 |
| Formats: | txt json html |
| Obsoletes: | RFC 7630 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7860 |
|
This document specifies several authentication protocols based on theSHA-2 hash functions for the User-based Security Model (USM) forSNMPv3 defined in RFC 3414. It obsoletes RFC 7630, in which the MIBMODULE-IDENTITY value was incorrectly specified. |
|
| |
| RFC 7861 | Remote Procedure Call (RPC) Security Version 3 |
| |
| Authors: | A. Adamson, N. Williams. |
| Date: | November 2016 |
| Formats: | txt json html |
| Updates: | RFC 5403 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7861 |
|
This document specifies version 3 of the Remote Procedure Call (RPC) security protocol (RPCSEC_GSS). This protocol provides support for multi-principal authentication of client hosts and user principals to a server (constructed by generic composition), security label assertions for multi-level security and type enforcement, structured privilege assertions, and channel bindings. This document updatesRFC 5403. |
|
| |
| RFC 7862 | Network File System (NFS) Version 4 Minor Version 2 Protocol |
| |
|
|
This document describes NFS version 4 minor version 2; it describes the protocol extensions made from NFS version 4 minor version 1.Major extensions introduced in NFS version 4 minor version 2 include the following: Server-Side Copy, Application Input/Output (I/O)Advise, Space Reservations, Sparse Files, Application Data Blocks, and Labeled NFS. |
|
| |
| RFC 7863 | Network File System (NFS) Version 4 Minor Version 2 External Data Representation Standard (XDR) Description |
| |
| Authors: | T. Haynes. |
| Date: | November 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7863 |
|
This document provides the External Data Representation (XDR) description for NFS version 4 minor version 2. |
|
| |
| RFC 7864 | Proxy Mobile IPv6 Extensions to Support Flow Mobility |
| |
|
|
Proxy Mobile IPv6 (PMIPv6) allows a mobile node to connect to the same PMIPv6 domain through different interfaces. This document describes extensions to the PMIPv6 protocol that are required to support network-based flow mobility over multiple physical interfaces.
This document updates RFC 5213. The extensions described in this document consist of the operations performed by the local mobility anchor and the mobile access gateway to manage the prefixes assigned to the different interfaces of the mobile node, as well as how the forwarding policies are handled by the network to ensure consistent flow mobility management. |
|
| |
| RFC 7865 | Session Initiation Protocol (SIP) Recording Metadata |
| |
| Authors: | R. Ravindranath, P. Ravindran, P. Kyzivat. |
| Date: | May 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7865 |
|
Session recording is a critical requirement in many communications environments, such as call centers and financial trading organizations. In some of these environments, all calls must be recorded for regulatory, compliance, and consumer protection reasons.The recording of a session is typically performed by sending a copy of a media stream to a recording device. This document describes the metadata model as viewed by the Session Recording Server (SRS) and the recording metadata format. |
|
| |
| RFC 7866 | Session Recording Protocol |
| |
| Authors: | L. Portman, H. Lum, Ed., C. Eckel, A. Johnston, A. Hutton. |
| Date: | May 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7866 |
|
This document specifies the use of the Session Initiation Protocol(SIP), the Session Description Protocol (SDP), and the Real-timeTransport Protocol (RTP) for delivering real-time media and metadata from a Communication Session (CS) to a recording device. The SessionRecording Protocol specifies the use of SIP, SDP, and RTP to establish a Recording Session (RS) between the Session RecordingClient (SRC), which is on the path of the CS, and a Session RecordingServer (SRS) at the recording device. This document considers only active recording, where the SRC purposefully streams media to an SRS and all participating user agents (UAs) are notified of the recording. Passive recording, where a recording device detects media directly from the network (e.g., using port-mirroring techniques), is outside the scope of this document. In addition, lawful intercept is outside the scope of this document. |
|
| |
| RFC 7867 | RTP Control Protocol (RTCP) Extended Report (XR) Block for Loss Concealment Metrics for Video Applications |
| |
| Authors: | R. Huang. |
| Date: | July 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7867 |
|
This document defines a new RTP Control Protocol (RTCP) ExtendedReport (XR) block that allows the reporting of loss concealment metrics for video applications of RTP. |
|
| |
| RFC 7870 | Dual-Stack Lite (DS-Lite) Management Information Base (MIB) for Address Family Transition Routers (AFTRs) |
| |
| Authors: | Y. Fu, S. Jiang, J. Dong, Y. Chen. |
| Date: | June 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7870 |
|
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 managed objects for Address FamilyTransition Routers (AFTRs) of Dual-Stack Lite (DS-Lite). |
|
| |
| RFC 7873 | Domain Name System (DNS) Cookies |
| |
| Authors: | D. Eastlake 3rd, M. Andrews. |
| Date: | May 2016 |
| Formats: | txt html json |
| Updated by: | RFC 9018 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7873 |
|
DNS Cookies are a lightweight DNS transaction security mechanism that provides limited protection to DNS servers and clients against a variety of increasingly common denial-of-service and amplification/ forgery or cache poisoning attacks by off-path attackers. DNSCookies are tolerant of NAT, NAT-PT (Network Address Translation -Protocol Translation), and anycast and can be incrementally deployed.(Since DNS Cookies are only returned to the IP address from which they were originally received, they cannot be used to generally trackInternet users.) |
|
| |
| RFC 7874 | WebRTC Audio Codec and Processing Requirements |
| |
| Authors: | JM. Valin, C. Bran. |
| Date: | May 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7874 |
|
This document outlines the audio codec and processing requirements for WebRTC endpoints. |
|
| |
| RFC 7876 | UDP Return Path for Packet Loss and Delay Measurement for MPLS Networks |
| |
| Authors: | S. Bryant, S. Sivabalan, S. Soni. |
| Date: | July 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7876 |
|
RFC 6374 defines a protocol for Packet Loss and Delay Measurement forMPLS networks (MPLS-PLDM). This document specifies the procedures to be used when sending and processing out-of-band MPLS performance management Responses over an UDP/IP return path. |
|
| |
| RFC 7877 | Session Peering Provisioning Framework (SPPF) |
| |
| Authors: | K. Cartwright, V. Bhatia, S. Ali, D. Schwartz. |
| Date: | August 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7877 |
|
This document specifies the data model and the overall structure for a framework to provision Session Establishment Data (SED) intoSession Data Registries and SIP Service Provider (SSP) data stores.The framework is called the "Session Peering Provisioning Framework"(SPPF). The provisioned data is typically used by network elements for session establishment. |
|
| |
| RFC 7878 | Session Peering Provisioning (SPP) Protocol over SOAP |
| |
| Authors: | K. Cartwright, V. Bhatia, J-F. Mule, A. Mayrhofer. |
| Date: | August 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7878 |
|
The Session Peering Provisioning Framework (SPPF) specifies the data model and the overall structure to provision Session EstablishmentData (SED) into Session Data Registries and SIP Service Provider data stores. To utilize this framework, one needs a substrate protocol.Given that the Simple Object Access Protocol (SOAP) is currently widely used for messaging between elements of such provisioning systems, this document specifies the usage of SOAP (via HTTPS) as the substrate protocol for SPPF. The benefits include leveraging prevalent expertise and a higher probability that existing provisioning systems will be able to easily migrate to using an SPPF- based protocol. |
|
| |
| RFC 7879 | DTLS-SRTP Handling in SIP Back-to-Back User Agents |
| |
| Authors: | R. Ravindranath, T. Reddy, G. Salgueiro, V. Pascual, P. Ravindran. |
| Date: | May 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7879 |
|
Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) exist on the signaling and media paths between the endpoints. This document describes the behavior of B2BUAs when Secure Real-timeTransport (SRTP) security context is set up with the DatagramTransport Layer Security (DTLS) protocol. |
|
| |
| RFC 7880 | Seamless Bidirectional Forwarding Detection (S-BFD) |
| |
| Authors: | C. Pignataro, D. Ward, N. Akiya, M. Bhatia, S. Pallagatti. |
| Date: | July 2016 |
| Formats: | txt json html |
| Updates: | RFC 5880 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7880 |
|
This document defines Seamless Bidirectional Forwarding Detection(S-BFD), a simplified mechanism for using BFD with a large proportion of negotiation aspects eliminated, thus providing benefits such as quick provisioning, as well as improved control and flexibility for network nodes initiating path monitoring.
This document updates RFC 5880. |
|
| |
| RFC 7881 | Seamless Bidirectional Forwarding Detection (S-BFD) for IPv4, IPv6, and MPLS |
| |
| Authors: | C. Pignataro, D. Ward, N. Akiya. |
| Date: | July 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7881 |
|
This document defines procedures for using Seamless BidirectionalForwarding Detection (S-BFD) in IPv4, IPv6, and MPLS environments. |
|
| |
| RFC 7883 | Advertising Seamless Bidirectional Forwarding Detection (S-BFD) Discriminators in IS-IS |
| |
| Authors: | L. Ginsberg, N. Akiya, M. Chen. |
| Date: | July 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7883 |
|
This document defines a means of advertising one or more SeamlessBidirectional Forwarding Detection (S-BFD) Discriminators using theIS-IS Router CAPABILITY TLV. |
|
| |
| RFC 7884 | OSPF Extensions to Advertise Seamless Bidirectional Forwarding Detection (S-BFD) Target Discriminators |
| |
| Authors: | C. Pignataro, M. Bhatia, S. Aldrin, T. Ranganath. |
| Date: | July 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7884 |
|
This document defines a new OSPF Router Information (RI) TLV that allows OSPF routers to flood the Seamless Bidirectional ForwardingDetection (S-BFD) Discriminator values associated with a target network identifier. This mechanism is applicable to both OSPFv2 andOSPFv3. |
|
| |
| RFC 7885 | Seamless Bidirectional Forwarding Detection (S-BFD) for Virtual Circuit Connectivity Verification (VCCV) |
| |
| Authors: | V. Govindan, C. Pignataro. |
| Date: | July 2016 |
| Formats: | txt json html |
| Updates: | RFC 5885 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7885 |
|
This document defines Seamless BFD (S-BFD) for VCCV by extending the procedures and Connectivity Verification (CV) types already defined for Bidirectional Forwarding Detection (BFD) for Virtual CircuitConnectivity Verification (VCCV).
This document updates RFC 5885 by extending the CV Type values and the capability selection. |
|
| |
| RFC 7886 | Advertising Seamless Bidirectional Forwarding Detection (S-BFD) Discriminators in the Layer Two Tunneling Protocol Version 3 (L2TPv3) |
| |
| Authors: | V. Govindan, C. Pignataro. |
| Date: | July 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7886 |
|
This document defines a new Attribute-Value Pair (AVP) that allowsL2TP Control Connection Endpoints (LCCEs) to advertise one or moreSeamless Bidirectional Forwarding Detection (S-BFD) Discriminator values using the Layer Two Tunneling Protocol version 3 (L2TPv3). |
|
| |
| RFC 7887 | Hierarchical Join/Prune Attributes |
| |
| Authors: | S. Venaas, J. Arango, I. Kouvelas. |
| Date: | June 2016 |
| Formats: | txt html json |
| Updates: | RFC 5384 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7887 |
|
This document defines a hierarchical method of encoding Join/Prune attributes that provides a more efficient encoding when the same attribute values need to be specified for multiple sources in a PIMJoin/Prune message. This document updates RFC 5384 by renaming the encoding type registry specified there. |
|
| |
| RFC 7888 | IMAP4 Non-synchronizing Literals |
| |
|
|
The Internet Message Access Protocol (RFC 3501) contains the"literal" syntactic construct for communicating strings. When sending a literal from client to server, IMAP 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 that does not require this network round trip.
This document specifies 2 IMAP extensions: LITERAL+ and LITERAL-.LITERAL+ allows the alternate form of literals in all IMAP commands.LITERAL- is the same as LITERAL+, but it disallows the alternate form of literals unless they are 4096 bytes or less.
This document obsoletes RFC 2088. |
|
| |
| RFC 7889 | The IMAP APPENDLIMIT Extension |
| |
| Authors: | J. SrimushnamBoovaraghamoorthy, N. Bisht. |
| Date: | May 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7889 |
|
This document defines an extension to the IMAP service whereby a server can inform the client about maximum message upload sizes, allowing the client to avoid sending APPEND commands that will fail because the messages are too large. |
|
| |
| RFC 7891 | Explicit Reverse Path Forwarding (RPF) Vector |
| |
| Authors: | J. Asghar, IJ. Wijnands, Ed., S. Krishnaswamy, A. Karan, V. Arya. |
| Date: | June 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7891 |
|
The PIM Reverse Path Forwarding (RPF) Vector TLV defined in RFC 5496 can be included in a PIM Join Attribute such that the RPF neighbor is selected based on the unicast reachability of the RPF Vector instead of the source or Rendezvous Point associated with the multicast tree.
This document defines a new RPF Vector Attribute type such that an explicit RPF neighbor list can be encoded in the PIM Join Attribute, thus bypassing the unicast route lookup. |
|
| |
| RFC 7892 | IANA Allocation Procedures for the GMPLS OTN Signal Type Registry |
| |
| Authors: | Z. Ali, A. Bonfanti, M. Hartley, F. Zhang. |
| Date: | May 2016 |
| Formats: | txt html json |
| Updates: | RFC 7139 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7892 |
|
IANA defined the "OTN Signal Type" subregistry of the "GeneralizedMulti-Protocol Label Switching (GMPLS) Signaling Parameters" registry in RFC 7139. This document updates the "OTN Signal Type" subregistry to allow registration via Specification Required. |
|
| |
| RFC 7894 | Alternative Challenge Password Attributes for Enrollment over Secure Transport |
| |
| Authors: | M. Pritikin, C. Wallace. |
| Date: | June 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7894 |
|
This document defines a set of new Certificate Signing Request attributes for use with the Enrollment over Secure Transport (EST) protocol. These attributes provide disambiguation of the existing overloaded uses for the challengePassword attribute defined in "PKCS#9: Selected Object Classes and Attribute Types Version 2.0" (RFC2985). Uses include the original certificate revocation password, common authentication password uses, and EST-defined linking of transport security identity. |
|
| |
| RFC 7895 | YANG Module Library |
| |
| Authors: | A. Bierman, M. Bjorklund, K. Watsen. |
| Date: | June 2016 |
| Formats: | txt json html |
| Obsoleted by: | RFC 8525 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7895 |
|
This document describes a YANG library that provides information about all the YANG modules used by a network management server (e.g., a Network Configuration Protocol (NETCONF) server). Simple caching mechanisms are provided to allow clients to minimize retrieval of this information. |
|
| |
| RFC 7896 | Update to the Include Route Object (IRO) Specification in the Path Computation Element Communication Protocol (PCEP) |
| |
|
|
The Path Computation Element Communication Protocol (PCEP) enables communications between a Path Computation Client (PCC) and a PCE, or between two PCEs. RFC 5440 defines the Include Route Object (IRO) to specify network elements to be traversed in the computed path. The specification does not specify if the IRO contains an ordered or unordered list of subobjects. During recent discussions, it was determined that there was a need to define a standard representation to ensure interoperability. It was also noted that there is a benefit in the handling of an attribute of the IRO's subobject, the L bit.
This document updates RFC 5440 regarding the IRO specification. |
|
| |
| RFC 7899 | Multicast VPN State Damping |
| |
| Authors: | T. Morin, Ed., S. Litkowski, K. Patel, Z. Zhang, R. Kebler, J. Haas. |
| Date: | June 2016 |
| Formats: | txt json html |
| Updates: | RFC 6514 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7899 |
|
This document describes procedures to damp Multicast VPN (MVPN) routing state changes and control the effect of the churn due to the multicast dynamicity in customer sites. The procedures described in this document are applicable to BGP-based multicast VPN and help avoid uncontrolled control-plane load increase in the core routing infrastructure. The new procedures proposed were inspired by BGP unicast route damping principles that have been adapted to multicast. |
|
| |
| RFC 7900 | Extranet Multicast in BGP/IP MPLS VPNs |
| |
|
|
Previous RFCs specify the procedures necessary to allow IP multicast traffic to travel from one site to another within a BGP/MPLS IP VPN(Virtual Private Network). However, it is sometimes desirable to allow multicast traffic whose source is in one VPN to be received by systems that are in another VPN. This is known as a "Multicast VPN(MVPN) extranet". This document updates RFCs 6513, 6514, and 6625 by specifying the procedures that are necessary in order to provide extranet MVPN service. |
|
| |
| RFC 7902 | Registry and Extensions for P-Multicast Service Interface Tunnel Attribute Flags |
| |
|
|
The BGP-based control procedures for Multicast Virtual PrivateNetworks (MVPNs) make use of a BGP attribute known as the"P-Multicast Service Interface (PMSI) Tunnel" attribute. The attribute contains a one-octet "Flags" field. The purpose of this document is to establish an IANA registry for the assignment of the bits in this field. Since the "Flags" field contains only eight bits, this document also defines a new BGP Extended Community,"Additional PMSI Tunnel Attribute Flags", that can be used to carry additional flags for the "P-Multicast Service Interface (PMSI)Tunnel" attribute. This document updates RFC 6514. |
|
| |
| RFC 7904 | A SIP Usage for REsource LOcation And Discovery (RELOAD) |
| |
| Authors: | C. Jennings, B. Lowekamp, E. Rescorla, S. Baset, H. Schulzrinne, T. Schmidt, Ed.. |
| Date: | October 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7904 |
|
This document defines a SIP Usage for REsource LOcation And Discovery(RELOAD). The SIP Usage provides the functionality of a SIP proxy or registrar in a fully distributed system and includes a lookup service for Address of Records (AORs) stored in the overlay. It also definesGlobally Routable User Agent URIs (GRUUs) that allow the registrations to map an AOR to a specific node reachable through the overlay. After such initial contact of a Peer, the RELOAD AppAttach method is used to establish a direct connection between nodes through which SIP messages are exchanged. |
|
| |
| RFC 7905 | ChaCha20-Poly1305 Cipher Suites for Transport Layer Security (TLS) |
| |
| Authors: | A. Langley, W. Chang, N. Mavrogiannopoulos, J. Strombergson, S. Josefsson. |
| Date: | June 2016 |
| Formats: | txt json html |
| Updates: | RFC 5246, RFC 6347 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7905 |
|
This document describes the use of the ChaCha stream cipher andPoly1305 authenticator in the Transport Layer Security (TLS) andDatagram Transport Layer Security (DTLS) protocols.
This document updates RFCs 5246 and 6347. |
|
| |
| RFC 7909 | Securing Routing Policy Specification Language (RPSL) Objects with Resource Public Key Infrastructure (RPKI) Signatures |
| |
|
|
This document describes a method that allows parties to electronically sign Routing Policy Specification Language objects and validate such electronic signatures. This allows relying parties to detect accidental or malicious modifications of such objects. It also allows parties who run Internet Routing Registries or similar databases, but do not yet have authentication (based on RoutingPolicy System Security) of the maintainers of certain objects, to verify that the additions or modifications of such database objects are done by the legitimate holder(s) of the Internet resources mentioned in those objects. This document updates RFCs 2622 and 4012 to add the signature attribute to supported RPSL objects. |
|
| |
| RFC 7911 | Advertisement of Multiple Paths in BGP |
| |
| Authors: | D. Walton, A. Retana, E. Chen, J. Scudder. |
| Date: | July 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7911 |
|
This document defines a BGP extension that allows the advertisement of multiple paths for the same address prefix without the new paths implicitly replacing any previous ones. The essence of the extension is that each path is identified by a Path Identifier in addition to the address prefix. |
|
| |
| RFC 7915 | IP/ICMP Translation Algorithm |
| |
| Authors: | C. Bao, X. Li, F. Baker, T. Anderson, F. Gont. |
| Date: | June 2016 |
| Formats: | txt json html |
| Obsoletes: | RFC 6145 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7915 |
|
This document describes the Stateless IP/ICMP Translation Algorithm(SIIT), which translates between IPv4 and IPv6 packet headers(including ICMP headers). This document obsoletes RFC 6145. |
|
| |
| RFC 7916 | Operational Management of Loop-Free Alternates |
| |
| Authors: | S. Litkowski, Ed., B. Decraene, C. Filsfils, K. Raza, M. Horneffer, P. Sarkar. |
| Date: | July 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7916 |
|
Loop-Free Alternates (LFAs), as defined in RFC 5286, constitute an IPFast Reroute (IP FRR) mechanism enabling traffic protection for IP traffic (and, by extension, MPLS LDP traffic). Following early deployment experiences, this document provides operational feedback on LFAs, highlights some limitations, and proposes a set of refinements to address those limitations. It also proposes required management specifications.
This proposal is also applicable to remote-LFA solutions. |
|
| |
| RFC 7917 | Advertising Node Administrative Tags in IS-IS |
| |
| Authors: | P. Sarkar, Ed., H. Gredler, S. Hegde, S. Litkowski, B. Decraene. |
| Date: | July 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7917 |
|
This document describes an extension to the IS-IS routing protocol to advertise node administrative tags. This optional capability allows tagging and grouping of the nodes in an IS-IS domain. The node administrative tags can be used to express and apply locally defined network policies, thereby providing a very useful operational capability. Node administrative tags may be used by either IS-IS itself or other applications consuming information propagated via IS-IS. |
|
| |
| RFC 7919 | Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS) |
| |
|
|
Traditional finite-field-based Diffie-Hellman (DH) key exchange during the Transport Layer Security (TLS) handshake suffers from a number of security, interoperability, and efficiency shortcomings.These shortcomings arise from lack of clarity about which DH group parameters TLS servers should offer and clients should accept. This document offers a solution to these shortcomings for compatible peers by using a section of the TLS "Supported Groups Registry" (renamed from "EC Named Curve Registry" by this document) to establish common finite field DH parameters with known structure and a mechanism for peers to negotiate support for these groups.
This document updates TLS versions 1.0 (RFC 2246), 1.1 (RFC 4346), and 1.2 (RFC 5246), as well as the TLS Elliptic Curve Cryptography(ECC) extensions (RFC 4492). |
|
| |
| RFC 7924 | Transport Layer Security (TLS) Cached Information Extension |
| |
| Authors: | S. Santesson, H. Tschofenig. |
| Date: | July 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7924 |
|
Transport Layer Security (TLS) handshakes often include fairly static information, such as the server certificate and a list of trusted certification authorities (CAs). This information can be of considerable size, particularly if the server certificate is bundled with a complete certificate chain (i.e., the certificates of intermediate CAs up to the root CA).
This document defines an extension that allows a TLS client to inform a server of cached information, thereby enabling the server to omit already available information. |
|
| |
| RFC 7925 | Transport Layer Security (TLS) / Datagram Transport Layer Security (DTLS) Profiles for the Internet of Things |
| |
| Authors: | H. Tschofenig, Ed., T. Fossati. |
| Date: | July 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7925 |
|
A common design pattern in Internet of Things (IoT) deployments is the use of a constrained device that collects data via sensors or controls actuators for use in home automation, industrial control systems, smart cities, and other IoT deployments.
This document defines a Transport Layer Security (TLS) and DatagramTransport Layer Security (DTLS) 1.2 profile that offers communications security for this data exchange thereby preventing eavesdropping, tampering, and message forgery. The lack of communication security is a common vulnerability in IoT products that can easily be solved by using these well-researched and widely deployed Internet security protocols. |
|
| |
| RFC 7931 | NFSv4.0 Migration: Specification Update |
| |
| Authors: | D. Noveck, Ed., P. Shivam, C. Lever, B. Baker. |
| Date: | July 2016 |
| Formats: | txt json html |
| Updates: | RFC 7530 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7931 |
|
The migration feature of NFSv4 allows the transfer of responsibility for a single file system from one server to another without disruption to clients. Recent implementation experience has shown problems in the existing specification for this feature in NFSv4.0.This document identifies the problem areas and provides revised specification text that updates the NFSv4.0 specification in RFC7530. |
|
| |
| RFC 7935 | The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure |
| |
|
|
This document specifies the algorithms, algorithms' parameters, asymmetric key formats, asymmetric key size, and signature format for the Resource Public Key Infrastructure (RPKI) subscribers that generate digital signatures on certificates, Certificate RevocationLists (CRLs), Cryptographic Message Syntax (CMS) signed objects and certification requests as well as for the relying parties (RPs) that verify these digital signatures. |
|
| |
| RFC 7936 | Clarifying Registry Procedures for the WebSocket Subprotocol Name Registry |
| |
|
|
This document clarifies the instructions to IANA for the subprotocol registry set up for WebSockets in RFC 6455. |
|
| |
| RFC 7937 | Content Distribution Network Interconnection (CDNI) Logging Interface |
| |
| Authors: | F. Le Faucheur, Ed., G. Bertrand, Ed., I. Oprescu, Ed., R. Peterkofsky. |
| Date: | August 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7937 |
|
This memo specifies the Logging interface between a downstreamContent Distribution Network (dCDN) and an upstream CDN (uCDN) that are interconnected as per the CDN Interconnection (CDNI) framework.First, it describes a reference model for CDNI logging. Then, it specifies the CDNI Logging File format and the actual protocol for exchange of CDNI Logging Files. |
|
| |
| RFC 7939 | Definition of Managed Objects for the Neighborhood Discovery Protocol |
| |
| Authors: | U. Herberg, R. Cole, I. Chakeres, T. Clausen. |
| Date: | August 2016 |
| Formats: | txt json html |
| Obsoletes: | RFC 6779 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7939 |
|
This document replaces RFC 6779; it contains revisions and extensions to the original document. It defines a portion of the ManagementInformation Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring parameters of the Neighborhood Discovery Protocol (NHDP) process on a router. The extensions described in this document add objects and values to support the NHDP optimization specified in RFC7466. The MIB module defined in this document, denoted NHDP-MIB, also reports state, performance information, and notifications aboutNHDP. This additional state and performance information is useful to troubleshoot problems and performance issues during neighbor discovery. |
|
| |
| RFC 7940 | Representing Label Generation Rulesets Using XML |
| |
| Authors: | K. Davies, A. Freytag. |
| Date: | August 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7940 |
|
This document describes a method of representing rules for validating identifier labels and alternate representations of those labels usingExtensible Markup Language (XML). These policies, known as "LabelGeneration Rulesets" (LGRs), are used for the implementation ofInternationalized Domain Names (IDNs), for example. The rulesets are used to implement and share that aspect of policy defining which labels and Unicode code points are permitted for registrations, which alternative code points are considered variants, and what actions may be performed on labels containing those variants. |
|
| |
| RFC 7941 | RTP Header Extension for the RTP Control Protocol (RTCP) Source Description Items |
| |
|
|
Source Description (SDES) items are normally transported in the RTPControl Protocol (RTCP). In some cases, it can be beneficial to speed up the delivery of these items. The main case is when a new synchronization source (SSRC) joins an RTP session and the receivers need this source's identity, relation to other sources, or its synchronization context, all of which may be fully or partially identified using SDES items. To enable this optimization, this document specifies a new RTP header extension that can carry SDES items. |
|
| |
| RFC 7944 | Diameter Routing Message Priority |
| |
| Authors: | S. Donovan. |
| Date: | August 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7944 |
|
When making routing and resource allocation decisions, Diameter nodes currently have no generic mechanism to determine the relative priority of Diameter messages. This document addresses this by defining a mechanism to allow Diameter endpoints to indicate the relative priority of Diameter transactions. With this information,Diameter nodes can factor that priority into routing, resource allocation, and overload abatement decisions. |
|
| |
| RFC 7946 | The GeoJSON Format |
| |
| Authors: | H. Butler, M. Daly, A. Doyle, S. Gillies, S. Hagen, T. Schaub. |
| Date: | August 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7946 |
|
GeoJSON is a geospatial data interchange format based on JavaScriptObject Notation (JSON). It defines several types of JSON objects and the manner in which they are combined to represent data about geographic features, their properties, and their spatial extents.GeoJSON uses a geographic coordinate reference system, World GeodeticSystem 1984, and units of decimal degrees. |
|
| |
| RFC 7947 | Internet Exchange BGP Route Server |
| |
| Authors: | E. Jasinska, N. Hilliard, R. Raszuk, N. Bakker. |
| Date: | September 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7947 |
|
This document outlines a specification for multilateral interconnections at Internet Exchange Points (IXPs). Multilateral interconnection is a method of exchanging routing information among three or more External BGP (EBGP) speakers using a single intermediate broker system, referred to as a route server. Route servers are typically used on shared access media networks, such asIXPs, to facilitate simplified interconnection among multipleInternet routers. |
|
| |
| RFC 7949 | OSPFv3 over IPv4 for IPv6 Transition |
| |
| Authors: | I. Chen, A. Lindem, R. Atkinson. |
| Date: | August 2016 |
| Formats: | txt html json |
| Updates: | RFC 5838 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7949 |
|
This document defines a mechanism to use IPv4 to transport OSPFv3 packets. Using OSPFv3 over IPv4 with the existing OSPFv3 AddressFamily extension can simplify transition from an OSPFv2 IPv4-only routing domain to an OSPFv3 dual-stack routing domain. This document updates RFC 5838 to support virtual links in the IPv4 unicast address family when using OSPFv3 over IPv4. |
|
| |
| RFC 7950 | The YANG 1.1 Data Modeling Language |
| |
|
|
YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol(NETCONF). |
|
| |
| RFC 7951 | JSON Encoding of Data Modeled with YANG |
| |
| Authors: | L. Lhotka. |
| Date: | August 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7951 |
|
This document defines encoding rules for representing configuration data, state data, parameters of Remote Procedure Call (RPC) operations or actions, and notifications defined using YANG asJavaScript Object Notation (JSON) text. |
|
| |
| RFC 7952 | Defining and Using Metadata with YANG |
| |
|
|
This document defines a YANG extension that allows for defining metadata annotations in YANG modules. The document also specifiesXML and JSON encoding of annotations and other rules for annotating instances of YANG data nodes. |
|
| |
| RFC 7953 | Calendar Availability |
| |
|
|
This document specifies a new iCalendar (RFC 5545) component that allows the publication of available and unavailable time periods associated with a calendar user. This component can be used in standard iCalendar free-busy lookups, including the iCalendarTransport-independent Interoperability Protocol (iTIP; RFC 5546) free-busy requests, to generate repeating blocks of available or busy time with exceptions as needed.
This document also defines extensions to the Calendaring Extensions to WebDAV (CalDAV) calendar access protocol (RFC 4791) and the associated scheduling protocol (RFC 6638) to specify how this new calendar component can be used when evaluating free-busy time. |
|
| |
| RFC 7956 | Transparent Interconnection of Lots of Links (TRILL) Distributed Layer 3 Gateway |
| |
| Authors: | W. Hao, Y. Li, A. Qu, M. Durrani, P. Sivamurugan. |
| Date: | September 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7956 |
|
The base TRILL (Transparent Interconnection of Lots of Links) protocol provides optimal pair-wise data frame forwarding for Layer 2 intra-subnet traffic but not for Layer 3 inter-subnet traffic. A centralized gateway solution is typically used for Layer 3 inter- subnet traffic forwarding but has the following issues:
1. Sub-optimum forwarding paths for inter-subnet traffic.
2. A centralized gateway that may need to support a very large number of gateway interfaces in a Data Center, one per tenant per DataLabel used by that tenant, to provide interconnect functionality for all the Layer 2 Virtual Networks in a TRILL campus.
3. A traffic bottleneck at the gateway.
This document specifies an optional TRILL distributed gateway solution that resolves these centralized gateway issues. |
|
| |
| RFC 7959 | Block-Wise Transfers in the Constrained Application Protocol (CoAP) |
| |
|
|
The Constrained Application Protocol (CoAP) is a RESTful transfer protocol for constrained nodes and networks. Basic CoAP messages work well for small payloads from sensors and actuators; however, applications will need to transfer larger payloads occasionally -- for instance, for firmware updates. In contrast to HTTP, where TCP does the grunt work of segmenting and resequencing, CoAP is based on datagram transports such as UDP or Datagram Transport Layer Security(DTLS). These transports only offer fragmentation, which is even more problematic in constrained nodes and networks, limiting the maximum size of resource representations that can practically be transferred.
Instead of relying on IP fragmentation, this specification extends basic CoAP with a pair of "Block" options for transferring multiple blocks of information from a resource representation in multiple request-response pairs. In many important cases, the Block options enable a server to be truly stateless: the server can handle each block transfer separately, with no need for a connection setup or other server-side memory of previous block transfers. Essentially, the Block options provide a minimal way to transfer larger representations in a block-wise fashion.
A CoAP implementation that does not support these options generally is limited in the size of the representations that can be exchanged, so there is an expectation that the Block options will be widely used in CoAP implementations. Therefore, this specification updatesRFC 7252. |
|
| |
| RFC 7961 | Transparent Interconnection of Lots of Links (TRILL): Interface Addresses APPsub-TLV |
| |
| Authors: | D. Eastlake 3rd, L. Yizhou. |
| Date: | August 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7961 |
|
This document specifies a TRILL (Transparent Interconnection of Lots of Links) IS-IS application sub-TLV that enables the reporting by aTRILL switch of sets of addresses. Each set of addresses reports all of the addresses that designate the same interface (port) and also reports the TRILL switch by which that interface is reachable. For example, a 48-bit MAC (Media Access Control) address, IPv4 address, and IPv6 address can be reported as all corresponding to the same interface reachable by a particular TRILL switch. Such information could be used in some cases to synthesize responses to, or bypass the need for, the Address Resolution Protocol (ARP), the IPv6 NeighborDiscovery (ND) protocol, or the flooding of unknown MAC addresses. |
|
| |
| RFC 7964 | Solutions for BGP Persistent Route Oscillation |
| |
| Authors: | D. Walton, A. Retana, E. Chen, J. Scudder. |
| Date: | September 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7964 |
|
Routing information reduction by BGP Route Reflection orConfederation can result in persistent internal BGP route oscillations with certain routing setups and network topologies.This document specifies two sets of additional paths that can be used to eliminate these route oscillations in a network. |
|
| |
| RFC 7965 | LDP Extensions for Pseudowire Binding to Label Switched Path (LSP) Tunnels |
| |
| Authors: | M. Chen, W. Cao, A. Takacs, P. Pan. |
| Date: | August 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7965 |
|
Many transport services require that user traffic, in the form ofPseudowires (PWs), be delivered via either a single co-routed bidirectional tunnel or two unidirectional tunnels that share the same routes. This document defines an optional extension to theLabel Distribution Protocol (LDP) that enables the binding betweenPWs and the underlying Traffic Engineering (TE) tunnels. The extension applies to both single-segment and multi-segment PWs. |
|
| |
| RFC 7968 | Transparent Interconnection of Lots of Links (TRILL): Using Data Labels for Tree Selection for Multi-Destination Data |
| |
| Authors: | Y. Li, D. Eastlake 3rd, W. Hao, H. Chen, S. Chatterjee. |
| Date: | August 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7968 |
|
TRILL (Transparent Interconnection of Lots of Links) uses distribution trees to deliver multi-destination frames. Multiple trees can be used by an ingress Routing Bridge (RBridge) for flows, regardless of the VLAN, Fine-Grained Label (FGL), and/or multicast group of the flow. Different ingress RBridges may choose different distribution trees for TRILL Data packets in the same VLAN, FGL, and/or multicast group. To avoid unnecessary link utilization, distribution trees should be pruned based on one or more of the following: VLAN, FGL, or multicast destination address. If any VLAN,FGL, or multicast group can be sent on any tree, for typical fast- path hardware, the amount of pruning information is multiplied by the number of trees, but there is limited hardware capacity for such pruning information.
This document specifies an optional facility to restrict the TRILLData packets sent on particular distribution trees by VLAN, FGL, and/or multicast groups, thus reducing the total amount of pruning information so that it can more easily be accommodated by fast-path hardware. |
|
| |
| RFC 7970 | The Incident Object Description Exchange Format Version 2 |
| |
|
|
The Incident Object Description Exchange Format (IODEF) defines a data representation for security incident reports and indicators commonly exchanged by operational security teams for mitigation and watch and warning. This document describes an updated information model for the IODEF and provides an associated data model specified with the XML schema. This new information and data model obsoletesRFCs 5070 and 6685. |
|
| |
| RFC 7975 | Request Routing Redirection Interface for Content Delivery Network (CDN) Interconnection |
| |
| Authors: | B. Niven-Jenkins, Ed., R. van Brandenburg, Ed.. |
| Date: | October 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7975 |
|
The Request Routing interface comprises (1) the asynchronous advertisement of footprint and capabilities by a downstream ContentDelivery Network (CDN) that allows an upstream CDN to decide whether to redirect particular user requests to that downstream CDN; and (2) the synchronous operation of an upstream CDN requesting whether a downstream CDN is prepared to accept a user request and of a downstream CDN responding with how to actually redirect the user request. This document describes an interface for the latter part, i.e., the CDNI Request Routing Redirection interface. |
|
| |
| RFC 7977 | The WebSocket Protocol as a Transport for the Message Session Relay Protocol (MSRP) |
| |
| Authors: | P. Dunkley, G. Llewellyn, V. Pascual, G. Salgueiro, R. Ravindranath. |
| Date: | September 2016 |
| Formats: | txt json html |
| Updates: | RFC 4975, RFC 4976 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7977 |
|
The WebSocket protocol enables two-way real-time communication between clients and servers in situations where direct access to TCP and UDP is not available (for example, from within JavaScript in a web browser). This document specifies a new WebSocket subprotocol as a reliable transport mechanism between Message Session Relay Protocol(MSRP) clients and relays to enable usage of MSRP in new scenarios.This document normatively updates RFCs 4975 and 4976. |
|
| |
| RFC 7978 | Transparent Interconnection of Lots of Links (TRILL): RBridge Channel Header Extension |
| |
| Authors: | D. Eastlake 3rd, M. Umair, Y. Li. |
| Date: | September 2016 |
| Formats: | txt html json |
| Updates: | RFC 7178 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7978 |
|
The IETF TRILL (Transparent Interconnection of Lots of Links) protocol includes an optional mechanism (specified in RFC 7178) called RBridge Channel for the transmission of typed messages betweenTRILL switches in the same campus and the transmission of such messages between TRILL switches and end stations on the same link.This document specifies extensions to the RBridge Channel protocol header to support two features as follows: (1) a standard method to tunnel payloads whose type can be indicated by Ethertype through encapsulation in RBridge Channel messages; and (2) a method to support security facilities for RBridge Channel messages. This document updates RFC 7178. |
|
| |
| RFC 7981 | IS-IS Extensions for Advertising Router Information |
| |
| Authors: | L. Ginsberg, S. Previdi, M. Chen. |
| Date: | October 2016 |
| Formats: | txt html json |
| Obsoletes: | RFC 4971 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7981 |
|
This document defines a new optional Intermediate System toIntermediate System (IS-IS) TLV named CAPABILITY, formed of multiple sub-TLVs, which allows a router to announce its capabilities within an IS-IS level or the entire routing domain. This document obsoletesRFC 4971. |
|
| |
| RFC 7982 | Measurement of Round-Trip Time and Fractional Loss Using Session Traversal Utilities for NAT (STUN) |
| |
| Authors: | P. Martinsen, T. Reddy, D. Wing, V. Singh. |
| Date: | September 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7982 |
|
A host with multiple interfaces needs to choose the best interface for communication. Oftentimes, this decision is based on a static configuration and does not consider the path characteristics, which may affect the user experience.
This document describes a mechanism for an endpoint to measure the path characteristics fractional loss and RTT using Session TraversalUtilities for NAT (STUN) messages. |
|
| |
| RFC 7983 | Multiplexing Scheme Updates for Secure Real-time Transport Protocol (SRTP) Extension for Datagram Transport Layer Security (DTLS) |
| |
|
|
This document defines how Datagram Transport Layer Security (DTLS),Real-time Transport Protocol (RTP), RTP Control Protocol (RTCP),Session Traversal Utilities for NAT (STUN), Traversal Using Relays around NAT (TURN), and ZRTP packets are multiplexed on a single receiving socket. It overrides the guidance from RFC 5764 ("SRTPExtension for DTLS"), which suffered from four issues described and fixed in this document.
This document updates RFC 5764. |
|
| |
| RFC 7984 | Locating Session Initiation Protocol (SIP) Servers in a Dual-Stack IP Network |
| |
| Authors: | O. Johansson, G. Salgueiro, V. Gurbani, D. Worley, Ed.. |
| Date: | September 2016 |
| Formats: | txt html json |
| Updates: | RFC 3263 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7984 |
|
RFC 3263 defines how a Session Initiation Protocol (SIP) implementation, given a SIP Uniform Resource Identifier (URI), should locate the next-hop SIP server using Domain Name System (DNS) procedures. As SIP networks increasingly transition from IPv4-only to dual-stack, a quality user experience must be ensured for dual- stack SIP implementations. This document updates the DNS procedures described in RFC 3263 for dual-stack SIP implementations in preparation for forthcoming specifications for applying "HappyEyeballs" principles to SIP. |
|
| |
| RFC 7986 | New Properties for iCalendar |
| |
|
|
This document defines a set of new properties for iCalendar data and extends the use of some existing properties to the entire iCalendar object. |
|
| |
| RFC 7987 | IS-IS Minimum Remaining Lifetime |
| |
| Authors: | L. Ginsberg, P. Wells, B. Decraene, T. Przygienda, H. Gredler. |
| Date: | October 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7987 |
|
Corruption of the Remaining Lifetime field in a Link State ProtocolData Unit (LSP) can go undetected. In certain scenarios, this may cause or exacerbate flooding storms. It is also a possible denial- of-service attack vector. This document defines a backwards- compatible solution to this problem. |
|
| |
| RFC 7988 | Ingress Replication Tunnels in Multicast VPN |
| |
|
|
RFCs 6513, 6514, and other RFCs describe procedures by which aService Provider may offer Multicast VPN (MVPN) service to its customers. These procedures create point-to-multipoint (P2MP) or multipoint-to-multipoint (MP2MP) trees across the Service Provider's backbone. One type of P2MP tree that may be used is known as an"Ingress Replication (IR) tunnel". In an IR tunnel, a parent node need not be directly connected to its child nodes. When a parent node has to send a multicast data packet to its n child nodes, it does not use Layer 2 multicast, IP multicast, or MPLS multicast to do so. Rather, it makes n individual copies, and then unicasts each copy, through an IP or MPLS unicast tunnel, to exactly one child node. While the prior MVPN specifications allow the use of IR tunnels, those specifications are not always very clear or explicit about how the MVPN protocol elements and procedures are applied to IR tunnels. This document updates RFCs 6513 and 6514 by adding additional details that are specific to the use of IR tunnels. |
|
| |
| RFC 7989 | End-to-End Session Identification in IP-Based Multimedia Communication Networks |
| |
| Authors: | P. Jones, G. Salgueiro, C. Pearce, P. Giralt. |
| Date: | October 2016 |
| Formats: | txt html json |
| Obsoletes: | RFC 7329 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 7989 |
|
This document describes an end-to-end session identifier for use inIP-based multimedia communication systems that enables endpoints, intermediary devices, and management systems to identify a session end-to-end, associate multiple endpoints with a given multipoint conference, track communication sessions when they are redirected, and associate one or more media flows with a given communication session. While the identifier is intended to work across multiple protocols, this document describes its usage in the SessionInitiation Protocol (SIP).
This document also describes a backwards-compatibility mechanism for an existing session identifier implementation (RFC 7329) that is sufficiently different from the procedures defined in this document.
This document obsoletes RFC 7329. |
|
| |
| RFC 8000 | Requirements for NFSv4 Multi-Domain Namespace Deployment |
| |
| Authors: | A. Adamson, N. Williams. |
| Date: | November 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8000 |
|
This document presents requirements for the deployment of the NFSv4 protocols for the construction of an NFSv4 file namespace in environments with multiple NFSv4 Domains. To participate in an NFSv4 multi-domain file namespace, the server must offer a multi-domain- capable file system and support RPCSEC_GSS for user authentication.In most instances, the server must also support identity-mapping services. |
|
| |
| RFC 8001 | RSVP-TE Extensions for Collecting Shared Risk Link Group (SRLG) Information |
| |
| Authors: | F. Zhang, Ed., O. Gonzalez de Dios, Ed., C. Margaria, M. Hartley, Z. Ali. |
| Date: | January 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8001 |
|
This document provides extensions for Resource Reservation Protocol -Traffic Engineering (RSVP-TE), including GMPLS, to support automatic collection of Shared Risk Link Group (SRLG) information for the TE link formed by a Label Switched Path (LSP). |
|
| |
| RFC 8002 | Host Identity Protocol Certificates |
| |
|
|
The Certificate (CERT) parameter is a container for digital certificates. It is used for carrying these certificates in HostIdentity Protocol (HIP) control packets. This document specifies the certificate parameter and the error signaling in case of a failed verification. Additionally, this document specifies the representations of Host Identity Tags (HITs) in X.509 version 3 (v3).
The concrete use cases of certificates, including how certificates are obtained and requested and which actions are taken upon successful or failed verification, are specific to the scenario in which the certificates are used. Hence, the definition of these scenario-specific aspects is left to the documents that use the CERT parameter.
This document updates RFC 7401 and obsoletes RFC 6253. |
|
| |
| RFC 8003 | Host Identity Protocol (HIP) Registration Extension |
| |
| Authors: | J. Laganier, L. Eggert. |
| Date: | October 2016 |
| Formats: | txt json html |
| Obsoletes: | RFC 5203 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8003 |
|
This document specifies a registration mechanism for the HostIdentity Protocol (HIP) that allows hosts to register with services, such as HIP rendezvous servers or middleboxes. This document obsoletes RFC 5203. |
|
| |
| RFC 8004 | Host Identity Protocol (HIP) Rendezvous Extension |
| |
| Authors: | J. Laganier, L. Eggert. |
| Date: | October 2016 |
| Formats: | txt html json |
| Obsoletes: | RFC 5204 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8004 |
|
This document defines a rendezvous extension for the Host IdentityProtocol (HIP). The rendezvous extension extends HIP and the HIPRegistration Extension for initiating communication between HIP nodes via HIP rendezvous servers. Rendezvous servers improve reachability and operation when HIP nodes are multihomed or mobile. This document obsoletes RFC 5204. |
|
| |
| RFC 8005 | Host Identity Protocol (HIP) Domain Name System (DNS) Extension |
| |
|
|
This document specifies a resource record (RR) for the Domain NameSystem (DNS) and how to use it with the Host Identity Protocol (HIP).This RR allows a HIP node to store in the DNS its Host Identity (HI), the public component of the node public-private key pair; its HostIdentity Tag (HIT), a truncated hash of its public key (PK); and the domain names of its rendezvous servers (RVSs). This document obsoletes RFC 5205. |
|
| |
| RFC 8006 | Content Delivery Network Interconnection (CDNI) Metadata |
| |
| Authors: | B. Niven-Jenkins, R. Murray, M. Caulfield, K. Ma. |
| Date: | December 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8006 |
|
The Content Delivery Network Interconnection (CDNI) Metadata interface enables interconnected Content Delivery Networks (CDNs) to exchange content distribution metadata in order to enable content acquisition and delivery. The CDNI Metadata associated with a piece of content provides a downstream CDN with sufficient information for the downstream CDN to service content requests on behalf of an upstream CDN. This document describes both a base set of CDNIMetadata and the protocol for exchanging that metadata. |
|
| |
| RFC 8007 | Content Delivery Network Interconnection (CDNI) Control Interface / Triggers |
| |
| Authors: | R. Murray, B. Niven-Jenkins. |
| Date: | December 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8007 |
|
This document describes the part of the Content Delivery NetworkInterconnection (CDNI) Control interface that allows a CDN to trigger activity in an interconnected CDN that is configured to deliver content on its behalf. The upstream CDN can use this mechanism to request that the downstream CDN pre-position metadata or content or to request that it invalidate or purge metadata or content. The upstream CDN can monitor the status of activity that it has triggered in the downstream CDN. |
|
| |
| RFC 8008 | Content Delivery Network Interconnection (CDNI) Request Routing: Footprint and Capabilities Semantics |
| |
| Authors: | J. Seedorf, J. Peterson, S. Previdi, R. van Brandenburg, K. Ma. |
| Date: | December 2016 |
| Formats: | txt html json |
| Updated by: | RFC 9388 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8008 |
|
This document captures the semantics of the "Footprint andCapabilities Advertisement" part of the Content Delivery NetworkInterconnection (CDNI) Request Routing interface, i.e., the desired meaning of "Footprint" and "Capabilities" in the CDNI context and what the "Footprint & Capabilities Advertisement interface (FCI)" offers within CDNI. The document also provides guidelines for theCDNI FCI protocol. It further defines a Base Advertisement Object, the necessary registries for capabilities and footprints, and guidelines on how these registries can be extended in the future. |
|
| |
| RFC 8012 | Label Switched Path (LSP) and Pseudowire (PW) Ping/Trace over MPLS Networks Using Entropy Labels (ELs) |
| |
| Authors: | N. Akiya, G. Swallow, C. Pignataro, A. Malis, S. Aldrin. |
| Date: | November 2016 |
| Formats: | txt json html |
| Updates: | RFC 6790 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8012 |
|
Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) ping and traceroute are methods used to test Equal-Cost Multipath (ECMP) paths. Ping is known as a connectivity-verification method and traceroute is known as a fault-isolation method, as described in RFC4379. When an LSP is signaled using the Entropy Label (EL) described in RFC 6790, the ability for LSP ping and traceroute operations to discover and exercise ECMP paths is lost for scenarios where LabelSwitching Routers (LSRs) apply different load-balancing techniques.One such scenario is when some LSRs apply EL-based load balancing while other LSRs apply load balancing that is not EL based (e.g.,IP). Another scenario is when an EL-based LSP is stitched with another LSP that can be EL based or not EL based.
This document extends the MPLS LSP ping and traceroute multipath mechanisms in RFC 6424 to allow the ability of exercising LSPs that make use of the EL. This document updates RFC 6790. |
|
| |
| RFC 8013 | Forwarding and Control Element Separation (ForCES) Inter-FE Logical Functional Block (LFB) |
| |
| Authors: | D. Joachimpillai, J. Hadi Salim. |
| Date: | February 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8013 |
|
This document describes how to extend the Forwarding and ControlElement Separation (ForCES) Logical Functional Block (LFB) topology across Forwarding Elements (FEs) by defining the inter-FE LFB class.The inter-FE LFB class provides the ability to pass data and metadata across FEs without needing any changes to the ForCES specification.The document focuses on Ethernet transport. |
|
| |
| RFC 8015 | RTP Control Protocol (RTCP) Extended Report (XR) Block for Independent Reporting of Burst/Gap Discard Metrics |
| |
| Authors: | V. Singh, C. Perkins, A. Clark, R. Huang. |
| Date: | November 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8015 |
|
This document defines an RTP Control Protocol (RTCP) Extended Report(XR) block that allows the reporting of burst/gap discard metrics independently of the burst/gap loss metrics for use in a range of RTP applications. |
|
| |
| RFC 8016 | Mobility with Traversal Using Relays around NAT (TURN) |
| |
| Authors: | T. Reddy, D. Wing, P. Patil, P. Martinsen. |
| Date: | November 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8016 |
|
It is desirable to minimize traffic disruption caused by changing IP address during a mobility event. One mechanism to minimize disruption is to expose a shorter network path to the mobility event so that only the local network elements are aware of the changed IP address and the remote peer is unaware of the changed IP address.
This document provides such an IP address mobility solution usingTraversal Using Relays around NAT (TURN). This is achieved by allowing a client to retain an allocation on the TURN server when theIP address of the client changes. |
|
| |
| RFC 8019 | Protecting Internet Key Exchange Protocol Version 2 (IKEv2) Implementations from Distributed Denial-of-Service Attacks |
| |
| Authors: | Y. Nir, V. Smyslov. |
| Date: | November 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8019 |
|
This document recommends implementation and configuration best practices for Internet Key Exchange Protocol version 2 (IKEv2)Responders, to allow them to resist Denial-of-Service and DistributedDenial-of-Service attacks. Additionally, the document introduces a new mechanism called "Client Puzzles" that helps accomplish this task. |
|
| |
| RFC 8020 | NXDOMAIN: There Really Is Nothing Underneath |
| |
|
|
This document states clearly that when a DNS resolver receives a response with a response code of NXDOMAIN, it means that the domain name which is thus denied AND ALL THE NAMES UNDER IT do not exist.
This document clarifies RFC 1034 and modifies a portion of RFC 2308: it updates both of them. |
|
| |
| RFC 8022 | A YANG Data Model for Routing Management |
| |
| Authors: | L. Lhotka, A. Lindem. |
| Date: | November 2016 |
| Formats: | txt json html |
| Obsoleted by: | RFC 8349 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8022 |
|
This document contains a specification of three YANG modules and one submodule. Together they form the core routing data model that serves as a framework for configuring and managing a routing subsystem. It is expected that these modules will be augmented by additional YANG modules defining data models for control-plane protocols, route filters, and other functions. The core routing data model provides common building blocks for such extensions -- routes,Routing Information Bases (RIBs), and control-plane protocols. |
|
| |
| RFC 8024 | Multi-Chassis Passive Optical Network (MC-PON) Protection in MPLS |
| |
| Authors: | Y. Jiang, Ed., Y. Luo, E. Mallette, Ed., Y. Shen, W. Cheng. |
| Date: | November 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8024 |
|
Multiprotocol Label Switching (MPLS) is being extended to the edge of operator networks including the network access nodes. Separately, network access nodes such as Passive Optical Network (PON) OpticalLine Terminations (OLTs) have evolved to support first-mile access protection, where one or more physical OLTs provide first-mile diversity to the customer edge. Multihoming support is needed on theMPLS-enabled PON OLT to provide resiliency for provided services.This document describes the Multi-Chassis PON (MC-PON) protection architecture in MPLS and also specifies the Inter-ChassisCommunication Protocol (ICCP) extension to support it. |
|
| |
| RFC 8025 | IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Paging Dispatch |
| |
| Authors: | P. Thubert, Ed., R. Cragie. |
| Date: | November 2016 |
| Formats: | txt html json |
| Updates: | RFC 4944 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8025 |
|
This specification updates RFC 4944 to introduce a new context switch mechanism for IPv6 over Low-Power Wireless Personal Area Network(6LoWPAN) compression, expressed in terms of Pages and signaled by a new Paging Dispatch. |
|
| |
| RFC 8026 | Unified IPv4-in-IPv6 Softwire Customer Premises Equipment (CPE): A DHCPv6-Based Prioritization Mechanism |
| |
| Authors: | M. Boucadair, I. Farrer. |
| Date: | November 2016 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8026 |
|
In IPv6-only provider networks, transporting IPv4 packets encapsulated in IPv6 is a common solution to the problem of IPv4 service continuity. A number of differing functional approaches have been developed for this, each having their own specific characteristics. As these approaches share a similar functional architecture and use the same data plane mechanisms, this memo specifies a DHCPv6 option, whereby a single instance of CustomerPremises Equipment (CPE) can interwork with all of the standardized and proposed approaches to providing encapsulated IPv4-in-IPv6 services by providing a prioritization mechanism. |
|
| |
| RFC 8028 | First-Hop Router Selection by Hosts in a Multi-Prefix Network |
| |
| Authors: | F. Baker, B. Carpenter. |
| Date: | November 2016 |
| Formats: | txt html json |
| Updates: | RFC 4861 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8028 |
|
This document describes expected IPv6 host behavior in a scenario that has more than one prefix, each allocated by an upstream network that is assumed to implement BCP 38 ingress filtering, when the host has multiple routers to choose from. It also applies to other scenarios such as the usage of stateful firewalls that effectively act as address-based filters. Host behavior in choosing a first-hop router may interact with source address selection in a given implementation. However, the selection of the source address for a packet is done before the first-hop router for that packet is chosen.Given that the network or host is, or appears to be, multihomed with multiple provider-allocated addresses, that the host has elected to use a source address in a given prefix, and that some but not all neighboring routers are advertising that prefix in their RouterAdvertisement Prefix Information Options, this document specifies to which router a host should present its transmission. It updates RFC4861. |
|
| |
| RFC 8029 | Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures |
| |
| Authors: | K. Kompella, G. Swallow, C. Pignataro, Ed., N. Kumar, S. Aldrin, M. Chen. |
| Date: | March 2017 |
| Formats: | txt html json |
| Obsoletes: | RFC 4379, RFC 6424, RFC 6829, RFC 7537 |
| Updates: | RFC 1122 |
| Updated by: | RFC 8611, RFC 9041 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8029 |
|
This document describes a simple and efficient mechanism to detect data-plane failures in Multiprotocol Label Switching (MPLS) LabelSwitched Paths (LSPs). It defines a probe message called an "MPLS echo request" and a response message called an "MPLS echo reply" for returning the result of the probe. The MPLS echo request is intended to contain sufficient information to check correct operation of the data plane and to verify the data plane against the control plane, thereby localizing faults.
This document obsoletes RFCs 4379, 6424, 6829, and 7537, and updatesRFC 1122. |
|
| |
| RFC 8030 | Generic Event Delivery Using HTTP Push |
| |
| Authors: | M. Thomson, E. Damaggio, B. Raymor, Ed.. |
| Date: | December 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8030 |
|
This document describes a simple protocol for the delivery of real- time events to user agents. This scheme uses HTTP/2 server push. |
|
| |
| RFC 8031 | Curve25519 and Curve448 for the Internet Key Exchange Protocol Version 2 (IKEv2) Key Agreement |
| |
| Authors: | Y. Nir, S. Josefsson. |
| Date: | December 2016 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8031 |
|
This document describes the use of Curve25519 and Curve448 for ephemeral key exchange in the Internet Key Exchange Protocol Version2 (IKEv2). |
|
| |
| RFC 8035 | Session Description Protocol (SDP) Offer/Answer Clarifications for RTP/RTCP Multiplexing |
| |
|
|
This document updates RFC 5761 by clarifying the SDP offer/answer negotiation of RTP and RTP Control Protocol (RTCP) multiplexing. It makes it clear that an answerer can only include an "a=rtcp-mux" attribute in a Session Description Protocol (SDP) answer if the associated SDP offer contained the attribute. |
|
| |
| RFC 8036 | Applicability Statement for the Routing Protocol for Low-Power and Lossy Networks (RPL) in Advanced Metering Infrastructure (AMI) Networks |
| |
| Authors: | N. Cam-Winget, Ed., J. Hui, D. Popa. |
| Date: | January 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8036 |
|
This document discusses the applicability of the Routing Protocol forLow-Power and Lossy Networks (RPL) in Advanced MeteringInfrastructure (AMI) networks. |
|
| |
| RFC 8037 | CFRG Elliptic Curve Diffie-Hellman (ECDH) and Signatures in JSON Object Signing and Encryption (JOSE) |
| |
| Authors: | I. Liusvaara. |
| Date: | January 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8037 |
|
This document defines how to use the Diffie-Hellman algorithms"X25519" and "X448" as well as the signature algorithms "Ed25519" and"Ed448" from the IRTF CFRG elliptic curves work in JSON ObjectSigning and Encryption (JOSE). |
|
| |
| RFC 8038 | Exporting MIB Variables Using the IP Flow Information Export (IPFIX) Protocol |
| |
| Authors: | P. Aitken, Ed., B. Claise, S. B S, C. McDowall, J. Schoenwaelder. |
| Date: | May 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8038 |
|
This document specifies a way to complement IP Flow InformationExport (IPFIX) Data Records with Management Information Base (MIB) objects, avoiding the need to define new IPFIX Information Elements for existing MIB objects that are already fully specified.
Two IPFIX Options Templates, as well as a method for creating IPFIXOptions Templates that are used to export the extra data required to fully describe Simple Network Management Protocol (SNMP) MIB objects in IPFIX, are specified herein. |
|
| |
| RFC 8040 | RESTCONF Protocol |
| |
| Authors: | A. Bierman, M. Bjorklund, K. Watsen. |
| Date: | January 2017 |
| Formats: | txt json html |
| Updated by: | RFC 8527 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8040 |
|
This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol(NETCONF). |
|
| |
| RFC 8042 | OSPF Two-Part Metric |
| |
| Authors: | Z. Zhang, L. Wang, A. Lindem. |
| Date: | December 2016 |
| Formats: | txt html json |
| Updates: | RFC 2328 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8042 |
|
This document specifies an optional OSPF protocol extension to represent router metrics in a multi-access network in two parts: the metric from the router to the network and the metric from the network to the router. For such networks, the router-to-router metric forOSPF route computation is the sum of the two parts. This document updates RFC 2328. |
|
| |
| RFC 8044 | Data Types in RADIUS |
| |
|
|
RADIUS specifications have used data types for two decades without defining them as managed entities. During this time, RADIUS implementations have named the data types and have used them in attribute definitions. This document updates the specifications to better follow established practice. We do this by naming the data types defined in RFC 6158, which have been used since at least the publication of RFC 2865. We provide an IANA registry for the data types and update the "RADIUS Attribute Types" registry to include aData Type field for each attribute. Finally, we recommend that authors of RADIUS specifications use these types in preference to existing practice. This document updates RFCs 2865, 3162, 4072,6158, 6572, and 7268. |
|
| |
| RFC 8045 | RADIUS Extensions for IP Port Configuration and Reporting |
| |
| Authors: | D. Cheng, J. Korhonen, M. Boucadair, S. Sivakumar. |
| Date: | January 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8045 |
|
This document defines three new RADIUS attributes. For devices that implement IP port ranges, these attributes are used to communicate with a RADIUS server in order to configure and report IP transport ports as well as mapping behavior for specific hosts. This mechanism can be used in various deployment scenarios such as Carrier-GradeNAT, IPv4/IPv6 translators, Provider WLAN gateway, etc. This document defines a mapping between some RADIUS attributes and IP FlowInformation Export (IPFIX) Information Element identifiers. |
|
| |
| RFC 8046 | Host Mobility with the Host Identity Protocol |
| |
| Authors: | T. Henderson, Ed., C. Vogt, J. Arkko. |
| Date: | February 2017 |
| Formats: | txt html json |
| Obsoletes: | RFC 5206 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8046 |
|
This document defines a mobility extension to the Host IdentityProtocol (HIP). Specifically, this document defines a "LOCATOR_SET" parameter for HIP messages that allows for a HIP host to notify peers about alternate addresses at which it may be reached. This document also defines how the parameter can be used to preserve communications across a change to the IP address used by one or both peer hosts.The same LOCATOR_SET parameter can also be used to support end-host multihoming (as specified in RFC 8047). This document obsoletes RFC5206. |
|
| |
| RFC 8047 | Host Multihoming with the Host Identity Protocol |
| |
| Authors: | T. Henderson, Ed., C. Vogt, J. Arkko. |
| Date: | February 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8047 |
|
This document defines host multihoming extensions to the HostIdentity Protocol (HIP), by leveraging protocol components defined for host mobility. |
|
| |
| RFC 8048 | Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Presence |
| |
|
|
This document defines a bidirectional protocol mapping for the exchange of presence information between the Session InitiationProtocol (SIP) and the Extensible Messaging and Presence Protocol(XMPP). This document obsoletes RFC 7248. |
|
| |
| RFC 8049 | YANG Data Model for L3VPN Service Delivery |
| |
| Authors: | S. Litkowski, L. Tomotaki, K. Ogaki. |
| Date: | February 2017 |
| Formats: | txt json html |
| Obsoleted by: | RFC 8299 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8049 |
|
This document defines a YANG data model that can be used for communication between customers and network operators and to deliver a Layer 3 provider-provisioned VPN service. This document is limited to BGP PE-based VPNs as described in RFCs 4026, 4110, and 4364. This model is intended to be instantiated at the management system to deliver the overall service. It is not a configuration model to be used directly on network elements. This model provides an abstracted view of the Layer 3 IP VPN service configuration components. It will be up to the management system to take this model as input and use specific configuration models to configure the different network elements to deliver the service. How the configuration of network elements is done is out of scope for this document. |
|
| |
| RFC 8050 | Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format with BGP Additional Path Extensions |
| |
| Authors: | C. Petrie, T. King. |
| Date: | May 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8050 |
|
This document extends the Multi-threaded Routing Toolkit (MRT) export format for Border Gateway Protocol (BGP) routing information by supporting the advertisement of multiple paths in BGP extensions. |
|
| |
| RFC 8052 | Group Domain of Interpretation (GDOI) Protocol Support for IEC 62351 Security Services |
| |
| Authors: | B. Weis, M. Seewald, H. Falk. |
| Date: | June 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8052 |
|
The IEC 61850 power utility automation family of standards describes methods using Ethernet and IP for distributing control and data frames within and between substations. The IEC 61850-90-5 and IEC62351-9 standards specify the use of the Group Domain ofInterpretation (GDOI) protocol (RFC 6407) to distribute security transforms for some IEC 61850 security protocols. This memo definesGDOI payloads to support those security protocols. |
|
| |
| RFC 8054 | Network News Transfer Protocol (NNTP) Extension for Compression |
| |
| Authors: | K. Murchison, J. Elie. |
| Date: | January 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8054 |
|
This document defines an extension to the Network News TransportProtocol (NNTP) that allows a connection to be effectively and efficiently compressed between an NNTP client and server. |
|
| |
| RFC 8055 | Session Initiation Protocol (SIP) Via Header Field Parameter to Indicate Received Realm |
| |
| Authors: | C. Holmberg, Y. Jiang. |
| Date: | January 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8055 |
|
This specification defines a new Session Initiation Protocol (SIP)Via header field parameter, 'received-realm', which allows a SIP entity acting as an entry point to a transit network to indicate from which adjacent upstream network a SIP request is received by using a network realm value associated with the adjacent network. |
|
| |
| RFC 8056 | Extensible Provisioning Protocol (EPP) and Registration Data Access Protocol (RDAP) Status Mapping |
| |
| Authors: | J. Gould. |
| Date: | January 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8056 |
|
This document describes the mapping of the Extensible ProvisioningProtocol (EPP) statuses with the statuses registered for use in theRegistration Data Access Protocol (RDAP). This document identifies gaps in the mapping, and registers RDAP statuses to fill those gaps to ensure that all of the EPP statuses specified in RFCs are supported in RDAP. |
|
| |
| RFC 8058 | Signaling One-Click Functionality for List Email Headers |
| |
| Authors: | J. Levine, T. Herkula. |
| Date: | January 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8058 |
|
This document describes a method for signaling a one-click function for the List-Unsubscribe email header field. The need for this arises out of the actuality that mail software sometimes fetches URLs in mail header fields, and thereby accidentally triggers unsubscriptions in the case of the List-Unsubscribe header field. |
|
| |
| RFC 8062 | Anonymity Support for Kerberos |
| |
|
|
This document defines extensions to the Kerberos protocol to allow aKerberos client to securely communicate with a Kerberos application service without revealing its identity, or without revealing more than its Kerberos realm. It also defines extensions that allow aKerberos client to obtain anonymous credentials without revealing its identity to the Kerberos Key Distribution Center (KDC). This document updates RFCs 4120, 4121, and 4556. This document obsoletesRFC 6112 and reclassifies that document as Historic. RFC 6112 contained errors, and the protocol described in that specification is not interoperable with any known implementation. This specification describes a protocol that interoperates with multiple implementations. |
|
| |
| RFC 8063 | Key Relay Mapping for the Extensible Provisioning Protocol |
| |
| Authors: | H.W. Ribbers, M.W. Groeneweg, R. Gieben, A.L.J. Verschuren. |
| Date: | February 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8063 |
|
This document describes an Extensible Provisioning Protocol (EPP) mapping for a key relay object that relays DNSSEC key material between EPP clients using the poll queue defined in RFC 5730.
This key relay mapping will help facilitate changing the DNS operator of a domain while keeping the DNSSEC chain of trust intact. |
|
| |
| RFC 8064 | Recommendation on Stable IPv6 Interface Identifiers |
| |
| Authors: | F. Gont, A. Cooper, D. Thaler, W. Liu. |
| Date: | February 2017 |
| Formats: | txt json html |
| Updates: | RFC 2464, RFC 2467, RFC 2470, RFC 2491, RFC 2492, RFC 2497, RFC 2590, RFC 3146, RFC 3572, RFC 4291, RFC 4338, RFC 4391, RFC 5072, RFC 5121 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8064 |
|
This document changes the recommended default Interface Identifier(IID) generation scheme for cases where Stateless AddressAutoconfiguration (SLAAC) is used to generate a stable IPv6 address.It recommends using the mechanism specified in RFC 7217 in such cases, and recommends against embedding stable link-layer addresses in IPv6 IIDs. It formally updates RFC 2464, RFC 2467, RFC 2470, RFC2491, RFC 2492, RFC 2497, RFC 2590, RFC 3146, RFC 3572, RFC 4291, RFC4338, RFC 4391, RFC 5072, and RFC 5121. This document does not change any existing recommendations concerning the use of temporary addresses as specified in RFC 4941. |
|
| |
| RFC 8066 | IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) ESC Dispatch Code Points and Guidelines |
| |
| Authors: | S. Chakrabarti, G. Montenegro, R. Droms, J. Woodyatt. |
| Date: | February 2017 |
| Formats: | txt html json |
| Updates: | RFC 4944, RFC 6282 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8066 |
|
RFC 4944 defines the ESC dispatch type to allow additional dispatch octets in the 6LoWPAN header. The value of the ESC dispatch type was updated by RFC 6282; however, its usage was not defined in either RFC6282 or RFC 4944. This document updates RFC 4944 and RFC 6282 by defining the ESC extension octet code points and listing registration entries for known use cases at the time of writing of this document. |
|
| |
| RFC 8070 | Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) Freshness Extension |
| |
| Authors: | M. Short, Ed., S. Moore, P. Miller. |
| Date: | February 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8070 |
|
This document describes how to further extend the Public KeyCryptography for Initial Authentication in Kerberos (PKINIT) extension (defined in RFC 4556) to exchange an opaque data blob that a Key Distribution Center (KDC) can validate to ensure that the client is currently in possession of the private key during a PKINITAuthentication Service (AS) exchange. |
|
| |
| RFC 8071 | NETCONF Call Home and RESTCONF Call Home |
| |
| Authors: | K. Watsen. |
| Date: | February 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8071 |
|
This RFC presents NETCONF Call Home and RESTCONF Call Home, which enable a NETCONF or RESTCONF server to initiate a secure connection to a NETCONF or RESTCONF client, respectively. |
|
| |
| RFC 8072 | YANG Patch Media Type |
| |
| Authors: | A. Bierman, M. Bjorklund, K. Watsen. |
| Date: | February 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8072 |
|
This document describes a method for applying patches to configuration datastores using data defined with the YANG data modeling language. |
|
| |
| RFC 8074 | Source Address Validation Improvement (SAVI) for Mixed Address Assignment Methods Scenario |
| |
| Authors: | J. Bi, G. Yao, J. Halpern, E. Levy-Abegnoli, Ed.. |
| Date: | February 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8074 |
|
In networks that use multiple techniques for address assignment, the spoofing of addresses assigned by each technique can be prevented using the appropriate Source Address Validation Improvement (SAVI) methods. This document reviews how multiple SAVI methods can coexist in a single SAVI device and how collisions are resolved when the same binding entry is discovered by two or more methods. |
|
| |
| RFC 8075 | Guidelines for Mapping Implementations: HTTP to the Constrained Application Protocol (CoAP) |
| |
| Authors: | A. Castellani, S. Loreto, A. Rahman, T. Fossati, E. Dijk. |
| Date: | February 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8075 |
|
This document provides reference information for implementing a cross-protocol network proxy that performs translation from the HTTP protocol to the Constrained Application Protocol (CoAP). This will enable an HTTP client to access resources on a CoAP server through the proxy. This document describes how an HTTP request is mapped to a CoAP request and how a CoAP response is mapped back to an HTTP response. This includes guidelines for status code, URI, and media type mappings, as well as additional interworking advice. |
|
| |
| RFC 8076 | A Usage for Shared Resources in RELOAD (ShaRe) |
| |
| Authors: | A. Knauf, T. Schmidt, Ed., G. Hege, M. Waehlisch. |
| Date: | March 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8076 |
|
This document defines a REsource LOcation And Discovery (RELOAD)Usage for managing shared write access to RELOAD Resources. SharedResources in RELOAD (ShaRe) form a basic primitive for enabling various coordination and notification schemes among distributed peers. Access in ShaRe is controlled by a hierarchical trust delegation scheme maintained within an access list. A newUSER-CHAIN-ACL access policy allows authorized peers to write aShared Resource without owning its corresponding certificate. This specification also adds mechanisms to store Resources with a variable name that is useful whenever peer-independent rendezvous processes are required. |
|
| |
| RFC 8078 | Managing DS Records from the Parent via CDS/CDNSKEY |
| |
| Authors: | O. Gudmundsson, P. Wouters. |
| Date: | March 2017 |
| Formats: | txt json html |
| Updates: | RFC 7344 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8078 |
|
RFC 7344 specifies how DNS trust can be maintained across key rollovers in-band between parent and child. This document elevatesRFC 7344 from Informational to Standards Track. It also adds a method for initial trust setup and removal of a secure entry point.
Changing a domain's DNSSEC status can be a complicated matter involving multiple unrelated parties. Some of these parties, such as the DNS operator, might not even be known by all the organizations involved. The inability to disable DNSSEC via in-band signaling is seen as a problem or liability that prevents some DNSSEC adoption at a large scale. This document adds a method for in-band signaling of these DNSSEC status changes.
This document describes reasonable policies to ease deployment of the initial acceptance of new secure entry points (DS records).
It is preferable that operators collaborate on the transfer or move of a domain. The best method is to perform a Key Signing Key (KSK) plus Zone Signing Key (ZSK) rollover. If that is not possible, the method using an unsigned intermediate state described in this document can be used to move the domain between two parties. This leaves the domain temporarily unsigned and vulnerable to DNS spoofing, but that is preferred over the alternative of validation failures due to a mismatched DS and DNSKEY record. |
|
| |
| RFC 8079 | Guidelines for End-to-End Support of the RTP Control Protocol (RTCP) in Back-to-Back User Agents (B2BUAs) |
| |
| Authors: | L. Miniero, S. Garcia Murillo, V. Pascual. |
| Date: | February 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8079 |
|
SIP Back-to-Back User Agents (B2BUAs) are often designed to also be on the media path, rather than just to intercept signalling. This means that B2BUAs often implement an RTP or RTP Control Protocol(RTCP) stack as well, thus leading to separate multimedia sessions that the B2BUA correlates and bridges together. If not disciplined, this behaviour can severely impact the communication experience, especially when statistics and feedback information contained in RTCP messages get lost because of mismatches in the reported data.
This document defines the proper behaviour B2BUAs should follow when acting on both the signalling plane and media plane in order to preserve the end-to-end functionality of RTCP. |
|
| |
| RFC 8080 | Edwards-Curve Digital Security Algorithm (EdDSA) for DNSSEC |
| |
| Authors: | O. Sury, R. Edmonds. |
| Date: | February 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8080 |
|
This document describes how to specify Edwards-curve Digital SecurityAlgorithm (EdDSA) keys and signatures in DNS Security (DNSSEC). It uses EdDSA with the choice of two curves: Ed25519 and Ed448. |
|
| |
| RFC 8081 | The "font" Top-Level Media Type |
| |
| Authors: | C. Lilley. |
| Date: | February 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8081 |
|
This memo serves to register and document the "font" top-level media type, under which subtypes for representation formats for fonts may be registered. This document also serves as a registration application for a set of intended subtypes, which are representative of some existing subtypes already in use, and currently registered under the "application" tree by their separate registrations. |
|
| |
| RFC 8082 | Using Codec Control Messages in the RTP Audio-Visual Profile with Feedback with Layered Codecs |
| |
| Authors: | S. Wenger, J. Lennox, B. Burman, M. Westerlund. |
| Date: | March 2017 |
| Formats: | txt html json |
| Updates: | RFC 5104 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8082 |
|
This document updates RFC 5104 by fixing a shortcoming in the specification language of the Codec Control Message Full IntraRequest (FIR) description when using it with layered codecs. In particular, a decoder refresh point needs to be sent by a media sender when a FIR is received on any layer of the layered bitstream, regardless of whether those layers are being sent in a single or in multiple RTP flows. The other payload-specific feedback messages defined in RFC 5104 and RFC 4585 (which was updated by RFC 5506) have also been analyzed, and no corresponding shortcomings have been found. |
|
| |
| RFC 8083 | Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions |
| |
|
|
The Real-time Transport Protocol (RTP) is widely used in telephony, video conferencing, and telepresence applications. Such applications are often run on best-effort UDP/IP networks. If congestion control is not implemented in these applications, then network congestion can lead to uncontrolled packet loss and a resulting deterioration of the user's multimedia experience. The congestion control algorithm acts as a safety measure by stopping RTP flows from using excessive resources and protecting the network from overload. At the time of this writing, however, while there are several proprietary solutions, there is no standard algorithm for congestion control of interactiveRTP flows.
This document does not propose a congestion control algorithm. It instead defines a minimal set of RTP circuit breakers: conditions under which an RTP sender needs to stop transmitting media data to protect the network from excessive congestion. It is expected that, in the absence of long-lived excessive congestion, RTP applications running on best-effort IP networks will be able to operate without triggering these circuit breakers. To avoid triggering the RTP circuit breaker, any Standards Track congestion control algorithms defined for RTP will need to operate within the envelope set by theseRTP circuit breaker algorithms. |
|
| |
| RFC 8086 | GRE-in-UDP Encapsulation |
| |
| Authors: | L. Yong, Ed., E. Crabbe, X. Xu, T. Herbert. |
| Date: | March 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8086 |
|
This document specifies a method of encapsulating network protocol packets within GRE and UDP headers. This GRE-in-UDP encapsulation allows the UDP source port field to be used as an entropy field.This may be used for load-balancing of GRE traffic in transit networks using existing Equal-Cost Multipath (ECMP) mechanisms.There are two applicability scenarios for GRE-in-UDP with different requirements: (1) general Internet and (2) a traffic-managed controlled environment. The controlled environment has less restrictive requirements than the general Internet. |
|
| |
| RFC 8089 | The "file" URI Scheme |
| |
|
|
This document provides a more complete specification of the "file"Uniform Resource Identifier (URI) scheme and replaces the very brief definition in Section 3.10 of RFC 1738.
It defines a common syntax that is intended to interoperate across the broad spectrum of existing usages. At the same time, it notes some other current practices around the use of file URIs. |
|
| |
| RFC 8092 | BGP Large Communities Attribute |
| |
| Authors: | J. Heitz, Ed., J. Snijders, Ed., K. Patel, I. Bagdonas, N. Hilliard. |
| Date: | February 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8092 |
|
This document describes the BGP Large Communities attribute, an extension to BGP-4. This attribute provides a mechanism to signal opaque information within separate namespaces to aid in routing management. The attribute is suitable for use with all AutonomousSystem Numbers (ASNs) including four-octet ASNs. |
|
| |
| RFC 8093 | Deprecation of BGP Path Attribute Values 30, 31, 129, 241, 242, and 243 |
| |
| Authors: | J. Snijders. |
| Date: | February 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8093 |
|
This document requests IANA to mark BGP path attribute values 30, 31,129, 241, 242, and 243 as "Deprecated". |
|
| |
| RFC 8097 | BGP Prefix Origin Validation State Extended Community |
| |
| Authors: | P. Mohapatra, K. Patel, J. Scudder, D. Ward, R. Bush. |
| Date: | March 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8097 |
|
This document defines a new BGP opaque extended community to carry the origination Autonomous System (AS) validation state inside an autonomous system. Internal BGP (IBGP) speakers that receive this validation state can configure local policies that allow it to influence their decision process. |
|
| |
| RFC 8102 | Remote-LFA Node Protection and Manageability |
| |
| Authors: | P. Sarkar, Ed., S. Hegde, C. Bowers, H. Gredler, S. Litkowski. |
| Date: | March 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8102 |
|
The loop-free alternates (LFAs) computed following the current remote-LFA specification guarantees only link protection. The resulting remote-LFA next hops (also called "PQ-nodes") may not guarantee node protection for all destinations being protected by it.
This document describes an extension to the remote-loop-free-based IP fast reroute mechanisms that specifies procedures for determining whether or not a given PQ-node provides node protection for a specific destination. The document also shows how the same procedure can be utilized for the collection of complete characteristics for alternate paths. Knowledge about the characteristics of all alternate paths is a precursor to applying the operator-defined policy for eliminating paths not fitting the constraints. |
|
| |
| RFC 8103 | Using ChaCha20-Poly1305 Authenticated Encryption in the Cryptographic Message Syntax (CMS) |
| |
| Authors: | R. Housley. |
| Date: | February 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8103 |
|
This document describes the conventions for using ChaCha20-Poly1305Authenticated Encryption in the Cryptographic Message Syntax (CMS).ChaCha20-Poly1305 is an authenticated encryption algorithm constructed of the ChaCha stream cipher and Poly1305 authenticator. |
|
| |
| RFC 8104 | Pseudowire (PW) Endpoint Fast Failure Protection |
| |
| Authors: | Y. Shen, R. Aggarwal, W. Henderickx, Y. Jiang. |
| Date: | March 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8104 |
|
This document specifies a fast mechanism for protecting pseudowires(PWs) transported by IP/MPLS tunnels against egress endpoint failures, including egress attachment circuit (AC) failure, egress provider edge (PE) failure, multi-segment PW terminating PE failure, and multi-segment PW switching PE failure. Operating on the basis of multihomed customer edge (CE), redundant PWs, upstream label assignment, and context-specific label switching, the mechanism enables local repair to be performed by the router upstream adjacent to a failure. The router can restore a PW in the order of tens of milliseconds, by rerouting traffic around the failure to a protector through a pre-established bypass tunnel. Therefore, the mechanism can be used to reduce traffic loss before global repair reacts to the failure and the network converges on the topology changes due to the failure. |
|
| |
| RFC 8105 | Transmission of IPv6 Packets over Digital Enhanced Cordless Telecommunications (DECT) Ultra Low Energy (ULE) |
| |
| Authors: | P. Mariager, J. Petersen, Ed., Z. Shelby, M. Van de Logt, D. Barthel. |
| Date: | May 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8105 |
|
Digital Enhanced Cordless Telecommunications (DECT) Ultra Low Energy(ULE) is a low-power air interface technology that is proposed by theDECT Forum and is defined and specified by ETSI.
The DECT air interface technology has been used worldwide in communication devices for more than 20 years. It has primarily been used to carry voice for cordless telephony but has also been deployed for data-centric services.
DECT ULE is a recent addition to the DECT interface primarily intended for low-bandwidth, low-power applications such as sensor devices, smart meters, home automation, etc. As the DECT ULE interface inherits many of the capabilities from DECT, it benefits from operation that is long-range and interference-free, worldwide- reserved frequency band, low silicon prices, and maturity. There is an added value in the ability to communicate with IPv6 over DECT ULE, such as for Internet of Things applications.
This document describes how IPv6 is transported over DECT ULE usingIPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) techniques. |
|
| |
| RFC 8106 | IPv6 Router Advertisement Options for DNS Configuration |
| |
| Authors: | J. Jeong, S. Park, L. Beloeil, S. Madanapalli. |
| Date: | March 2017 |
| Formats: | txt html json |
| Obsoletes: | RFC 6106 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8106 |
|
This document specifies IPv6 Router Advertisement (RA) options(called "DNS RA options") to allow IPv6 routers to advertise a list of DNS Recursive Server Addresses and a DNS Search List to IPv6 hosts.
This document, which obsoletes RFC 6106, defines a higher default value of the lifetime of the DNS RA options to reduce the likelihood of expiry of the options on links with a relatively high rate of packet loss. |
|
| |
| RFC 8108 | Sending Multiple RTP Streams in a Single RTP Session |
| |
|
|
This memo expands and clarifies the behavior of Real-time TransportProtocol (RTP) endpoints that use multiple synchronization sources(SSRCs). This occurs, for example, when an endpoint sends multipleRTP streams in a single RTP session. This memo updates RFC 3550 with regard to handling multiple SSRCs per endpoint in RTP sessions, with a particular focus on RTP Control Protocol (RTCP) behavior. It also updates RFC 4585 to change and clarify the calculation of the timeout of SSRCs and the inclusion of feedback messages. |
|
| |
| RFC 8114 | Delivery of IPv4 Multicast Services to IPv4 Clients over an IPv6 Multicast Network |
| |
| Authors: | M. Boucadair, C. Qin, C. Jacquenet, Y. Lee, Q. Wang. |
| Date: | March 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8114 |
|
This document specifies a solution for the delivery of IPv4 multicast services to IPv4 clients over an IPv6 multicast network. The solution relies upon a stateless IPv4-in-IPv6 encapsulation scheme and uses an IPv6 multicast distribution tree to deliver IPv4 multicast traffic. The solution is particularly useful for the delivery of multicast service offerings to customers serviced byDual-Stack Lite (DS-Lite). |
|
| |
| RFC 8115 | DHCPv6 Option for IPv4-Embedded Multicast and Unicast IPv6 Prefixes |
| |
| Authors: | M. Boucadair, J. Qin, T. Tsou, X. Deng. |
| Date: | March 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8115 |
|
This document defines a Dynamic Host Configuration Protocol version 6(DHCPv6) Option for multicast IPv4 service continuity solutions, which is used to carry the IPv6 prefixes to be used to build unicast and multicast IPv4-embedded IPv6 addresses. |
|
| |
| RFC 8122 | Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP) |
| |
|
|
This document specifies how to establish secure connection-oriented media transport sessions over the Transport Layer Security (TLS) protocol using the Session Description Protocol (SDP). It defines the SDP protocol identifier, 'TCP/TLS'. It also defines the syntax and semantics for an SDP 'fingerprint' attribute that identifies the certificate that will be presented for the TLS session. This mechanism allows media transport over TLS connections to be established securely, so long as the integrity of session descriptions is assured.
This document obsoletes RFC 4572 by clarifying the usage of multiple fingerprints. |
|
| |
| RFC 8124 | The Session Description Protocol (SDP) WebSocket Connection URI Attribute |
| |
| Authors: | R. Ravindranath, G. Salgueiro. |
| Date: | March 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8124 |
|
The WebSocket protocol enables bidirectional real-time communication between clients and servers in web-based applications. This document specifies extensions to Session Description Protocol (SDP) for application protocols using WebSocket as a transport. |
|
| |
| RFC 8127 | Mobile Access Gateway Configuration Parameters Controlled by the Local Mobility Anchor |
| |
| Authors: | D. Patki, S. Gundavelli, J. Lee, Q. Fu, L. Bertz. |
| Date: | August 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8127 |
|
This specification defines a new extension,LMA-Controlled-MAG-Session-Params, to Proxy Mobile IPv6. This option can be used by the local mobility anchor (LMA) in a Proxy Mobile IPv6 domain for signaling a mobile access gateway (MAG) on enforcing specific values for various configuration parameters such as heartbeat and binding refresh parameters. |
|
| |
| RFC 8129 | Authentication Indicator in Kerberos Tickets |
| |
| Authors: | A. Jain, N. Kinder, N. McCallum. |
| Date: | March 2017 |
| Formats: | txt json html |
| Updates: | RFC 4120 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8129 |
|
This document updates RFC 4120, as it specifies an extension in theKerberos protocol. It defines a new authorization data type,AD-AUTHENTICATION-INDICATOR. The purpose of introducing this data type is to include an indicator of the strength of a client's authentication in service tickets so that application services can use it as an input into policy decisions. |
|
| |
| RFC 8130 | RTP Payload Format for the Mixed Excitation Linear Prediction Enhanced (MELPe) Codec |
| |
| Authors: | V. Demjanenko, D. Satterlee. |
| Date: | March 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8130 |
|
This document describes the RTP payload format for the MixedExcitation Linear Prediction Enhanced (MELPe) speech coder. MELPe's three different speech encoding rates and sample frame sizes are supported. Comfort noise procedures and packet loss concealment are described in detail. |
|
| |
| RFC 8132 | PATCH and FETCH Methods for the Constrained Application Protocol (CoAP) |
| |
| Authors: | P. van der Stok, C. Bormann, A. Sehgal. |
| Date: | April 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8132 |
|
The methods defined in RFC 7252 for the Constrained ApplicationProtocol (CoAP) only allow access to a complete resource, not to parts of a resource. In case of resources with larger or complex data, or in situations where resource continuity is required, replacing or requesting the whole resource is undesirable. Several applications using CoAP need to access parts of the resources.
This specification defines the new CoAP methods, FETCH, PATCH, and iPATCH, which are used to access and update parts of a resource. |
|
| |
| RFC 8138 | IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing Header |
| |
|
|
This specification introduces a new IPv6 over Low-Power WirelessPersonal Area Network (6LoWPAN) dispatch type for use in 6LoWPAN route-over topologies, which initially covers the needs of RoutingProtocol for Low-Power and Lossy Networks (RPL) data packet compression (RFC 6550). Using this dispatch type, this specification defines a method to compress the RPL Option (RFC 6553) information and Routing Header type 3 (RFC 6554), an efficient IP-in-IP technique, and is extensible for more applications. |
|
| |
| RFC 8139 | Transparent Interconnection of Lots of Links (TRILL): Appointed Forwarders |
| |
|
|
TRILL (Transparent Interconnection of Lots of Links) supports multi- access LAN (Local Area Network) links where a single link can have multiple end stations and TRILL switches attached. Where multipleTRILL switches are attached to a link, native traffic to and from end stations on that link is handled by a subset of those TRILL switches called "Appointed Forwarders" as originally specified in RFC 6325, with the intent that native traffic in each VLAN be handled by at most one TRILL switch. This document clarifies and updates theAppointed Forwarder mechanism. It updates RFCs 6325 and 7177 and obsoletes RFC 6439. |
|
| |
| RFC 8141 | Uniform Resource Names (URNs) |
| |
|
|
A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) that is assigned under the "urn" URI scheme and a particular URN namespace, with the intent that the URN will be a persistent, location-independent resource identifier. With regard to URN syntax, this document defines the canonical syntax for URNs (in a way that is consistent with URI syntax), specifies methods for determining URN- equivalence, and discusses URI conformance. With regard to URN namespaces, this document specifies a method for defining a URN namespace and associating it with a namespace identifier, and it describes procedures for registering namespace identifiers with theInternet Assigned Numbers Authority (IANA). This document obsoletes both RFCs 2141 and 3406. |
|
| |
| RFC 8142 | GeoJSON Text Sequences |
| |
| Authors: | S. Gillies. |
| Date: | April 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8142 |
|
This document describes the GeoJSON text sequence format and"application/geo+json-seq" media type. This format is based onJavaScript Object Notation (JSON) text sequences and GeoJSON, and it makes arbitrarily large geographic datasets incrementally parseable without restricting the form of GeoJSON texts within a sequence. |
|
| |
| RFC 8143 | Using Transport Layer Security (TLS) with Network News Transfer Protocol (NNTP) |
| |
|
|
This document provides recommendations for improving the security of the Network News Transfer Protocol (NNTP) when using Transport LayerSecurity (TLS). It modernizes the NNTP usage of TLS to be consistent with TLS best current practices. This document updates RFC 4642. |
|
| |
| RFC 8144 | Use of the Prefer Header Field in Web Distributed Authoring and Versioning (WebDAV) |
| |
|
|
This document defines how the Prefer header field (RFC 7240) can be used by a Web Distributed Authoring and Versioning (WebDAV) client to request that certain behaviors be employed by a server while constructing a response to a request. Furthermore, it defines the new "depth-noroot" preference.
This document updates RFC 7240. |
|
| |
| RFC 8145 | Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC) |
| |
| Authors: | D. Wessels, W. Kumari, P. Hoffman. |
| Date: | April 2017 |
| Formats: | txt html json |
| Updated by: | RFC 8553 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8145 |
|
The DNS Security Extensions (DNSSEC) were developed to provide origin authentication and integrity protection for DNS data by using digital signatures. These digital signatures can be verified by building a chain of trust starting from a trust anchor and proceeding down to a particular node in the DNS. This document specifies two different ways for validating resolvers to signal to a server which keys are referenced in their chain of trust. The data from such signaling allow zone administrators to monitor the progress of rollovers in aDNSSEC-signed zone. |
|
| |
| RFC 8147 | Next-Generation Pan-European eCall |
| |
| Authors: | R. Gellens, H. Tschofenig. |
| Date: | May 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8147 |
|
This document describes how to use IP-based emergency services mechanisms to support the next generation of the Pan-European in- vehicle emergency call service defined under the eSafety initiative of the European Commission (generally referred to as "eCall"). eCall is a standardized and mandated system for a special form of emergency calls placed by vehicles, providing real-time communications and an integrated set of related data.
This document also registers MIME media types and an Emergency CallData Type for the eCall vehicle data and metadata/control data, and an INFO package to enable carrying this data in SIP INFO requests.
Although this specification is designed to meet the requirements of next-generation Pan-European eCall (NG-eCall), it is specified generically such that the technology can be reused or extended to suit requirements across jurisdictions. |
|
| |
| RFC 8148 | Next-Generation Vehicle-Initiated Emergency Calls |
| |
| Authors: | R. Gellens, B. Rosen, H. Tschofenig. |
| Date: | May 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8148 |
|
This document describes how to use IP-based emergency services mechanisms to support the next generation of emergency calls placed by vehicles (automatically in the event of a crash or serious incident, or manually invoked by a vehicle occupant) and conveying vehicle, sensor, and location data related to the crash or incident.Such calls are often referred to as "Automatic Crash Notification"(ACN), or "Advanced Automatic Crash Notification" (AACN), even in the case of manual trigger. The "Advanced" qualifier refers to the ability to carry a richer set of data.
This document also registers a MIME media type and Emergency CallData Type for the vehicle, sensor, and location data (often referred to as "crash data" even though there is not necessarily a crash) and an INFO package to enable carrying this and related data in SIP INFO requests. An external specification for the data format, contents, and structure is referenced in this document.
This document reuses the technical aspects of next-generation Pan-European eCall (a mandated and standardized system for emergency calls by in-vehicle systems (IVSs) within Europe and other regions).However, this document specifies use of a different set of vehicle(crash) data, specifically, the Vehicle Emergency Data Set (VEDS) rather than the eCall Minimum Set of Data (MSD). This document is an extension of the IETF eCall document, with the primary differences being that this document makes the MSD data set optional and VEDS mandatory, and it adds attribute values to the metadata/control object to permit greater functionality. This document registers a new INFO package (identical to that registered for eCall but with the addition of the VEDS MIME type). This document also describes legacy(circuit-switched) ACN systems and their migration to next-generation emergency calling, to provide background information and context. |
|
| |
| RFC 8149 | RSVP Extensions for Reoptimization of Loosely Routed Point-to-Multipoint Traffic Engineering Label Switched Paths (LSPs) |
| |
| Authors: | T. Saad, Ed., R. Gandhi, Ed., Z. Ali, R. Venator, Y. Kamite. |
| Date: | April 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8149 |
|
The reoptimization of a Point-to-Multipoint (P2MP) TrafficEngineering (TE) Label Switched Path (LSP) may be triggered based on the need to reoptimize an individual source-to-leaf (S2L) sub-LSP or a set of S2L sub-LSPs, both using the Sub-Group-based reoptimization method, or the entire P2MP-TE LSP tree using the Make-Before-Break(MBB) method. This document discusses the application of the existing mechanisms for path reoptimization of loosely routed Point- to-Point (P2P) TE LSPs to the P2MP-TE LSPs, identifies issues in doing so, and defines procedures to address them. When reoptimizing a large number of S2L sub-LSPs in a tree using the Sub-Group-based reoptimization method, the S2L sub-LSP descriptor list may need to be semantically fragmented. This document defines the notion of a fragment identifier to help recipient nodes unambiguously reconstruct the fragmented S2L sub-LSP descriptor list. |
|
| |
| RFC 8150 | MPLS Transport Profile Linear Protection MIB |
| |
| Authors: | S. Kingston Smiler, M. Venkatesan, D. King, S. Aldrin, J. Ryoo. |
| Date: | April 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8150 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it defines objects for managing Multiprotocol Label Switching - TransportProfile (MPLS-TP) linear protection. |
|
| |
| RFC 8152 | CBOR Object Signing and Encryption (COSE) |
| |
|
|
Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need for the ability to have basic security services defined for this data format.This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. |
|
| |
| RFC 8154 | Parallel NFS (pNFS) Small Computer System Interface (SCSI) Layout |
| |
| Authors: | C. Hellwig. |
| Date: | May 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8154 |
|
The Parallel Network File System (pNFS) allows a separation between the metadata (onto a metadata server) and data (onto a storage device) for a file. The Small Computer System Interface (SCSI) layout type is defined in this document as an extension to pNFS to allow the use of SCSI-based block storage devices. |
|
| |
| RFC 8155 | Traversal Using Relays around NAT (TURN) Server Auto Discovery |
| |
| Authors: | P. Patil, T. Reddy, D. Wing. |
| Date: | April 2017 |
| Formats: | txt html json |
| Updates: | RFC 5766 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8155 |
|
Current Traversal Using Relays around NAT (TURN) server discovery mechanisms are relatively static and limited to explicit configuration. These are usually under the administrative control of the application or TURN service provider, and not the enterprise,ISP, or the network in which the client is located. Enterprises andISPs wishing to provide their own TURN servers need auto-discovery mechanisms that a TURN client could use with minimal or no configuration. This document describes three such mechanisms forTURN server discovery.
This document updates RFC 5766 to relax the requirement for mutual authentication in certain cases. |
|
| |
| RFC 8156 | DHCPv6 Failover Protocol |
| |
| Authors: | T. Mrugalski, K. Kinnear. |
| Date: | June 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8156 |
|
DHCPv6 as defined in "Dynamic Host Configuration Protocol for IPv6(DHCPv6)" (RFC 3315) does not offer server redundancy. This document defines a protocol implementation to provide DHCPv6 failover, a mechanism for running two servers with the capability for either server to take over clients' leases in case of server failure or network partition. It meets the requirements for DHCPv6 failover detailed in "DHCPv6 Failover Requirements" (RFC 7031). |
|
| |
| RFC 8158 | IP Flow Information Export (IPFIX) Information Elements for Logging NAT Events |
| |
| Authors: | S. Sivakumar, R. Penno. |
| Date: | December 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8158 |
|
Network operators require NAT devices to log events like creation and deletion of translations and information about the resources that theNAT device is managing. In many cases, the logs are essential to identify an attacker or a host that was used to launch malicious attacks and for various other purposes of accounting. Since there is no standard way of logging this information, different NAT devices use proprietary formats; hence, it is difficult to expect consistent behavior. This lack of standardization makes it difficult to write the Collector applications that would receive this data and process it to present useful information. This document describes the formats for logging NAT events. |
|
| |
| RFC 8159 | Keyed IPv6 Tunnel |
| |
| Authors: | M. Konstantynowicz, Ed., G. Heron, Ed., R. Schatzmayr, W. Henderickx. |
| Date: | May 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8159 |
|
This document describes a tunnel encapsulation for Ethernet over IPv6 with a mandatory 64-bit cookie for connecting Layer 2 (L2) Ethernet attachment circuits identified by IPv6 addresses. The encapsulation is based on the Layer 2 Tunneling Protocol Version 3 (L2TPv3) over IP and does not use the L2TPv3 control plane. |
|
| |
| RFC 8160 | IUTF8 Terminal Mode in Secure Shell (SSH) |
| |
| Authors: | S. Tatham, D. Tucker. |
| Date: | April 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8160 |
|
This document specifies a new opcode in the Secure Shell terminal modes encoding. The new opcode describes the widely used IUTF8 terminal mode bit, which indicates that terminal I/O uses UTF-8 character encoding. |
|
| |
| RFC 8163 | Transmission of IPv6 over Master-Slave/Token-Passing (MS/TP) Networks |
| |
| Authors: | K. Lynn, Ed., J. Martocci, C. Neilson, S. Donaldson. |
| Date: | May 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8163 |
|
Master-Slave/Token-Passing (MS/TP) is a medium access control method for the RS-485 physical layer and is used primarily in building automation networks. This specification defines the frame format for transmission of IPv6 packets and the method of forming link-local and statelessly autoconfigured IPv6 addresses on MS/TP networks. |
|
| |
| RFC 8166 | Remote Direct Memory Access Transport for Remote Procedure Call Version 1 |
| |
|
|
This document specifies a protocol for conveying Remote ProcedureCall (RPC) messages on physical transports capable of Remote DirectMemory Access (RDMA). This protocol is referred to as the RPC-over-RDMA version 1 protocol in this document. It requires no revision to application RPC protocols or the RPC protocol itself. This document obsoletes RFC 5666. |
|
| |
| RFC 8167 | Bidirectional Remote Procedure Call on RPC-over-RDMA Transports |
| |
| Authors: | C. Lever. |
| Date: | June 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8167 |
|
Minor versions of Network File System (NFS) version 4 newer than minor version 0 work best when Remote Procedure Call (RPC) transports can send RPC transactions in both directions on the same connection.This document describes how RPC transport endpoints capable of RemoteDirect Memory Access (RDMA) convey RPCs in both directions on a single connection. |
|
| |
| RFC 8168 | DHCPv6 Prefix-Length Hint Issues |
| |
| Authors: | T. Li, C. Liu, Y. Cui. |
| Date: | May 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8168 |
|
DHCPv6 Prefix Delegation allows a client to include a prefix-length hint value in the IA_PD option to indicate a preference for the size of the prefix to be delegated, but it is unclear about how the client and server should act in different situations involving the prefix- length hint. This document provides a summary of the existing problems with the prefix-length hint and guidance on what the client and server could do in different situations. |
|
| |
| RFC 8169 | Residence Time Measurement in MPLS Networks |
| |
| Authors: | G. Mirsky, S. Ruffini, E. Gray, J. Drake, S. Bryant, A. Vainshtein. |
| Date: | May 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8169 |
|
This document specifies a new Generic Associated Channel (G-ACh) forResidence Time Measurement (RTM) and describes how it can be used by time synchronization protocols within an MPLS domain.
Residence time is the variable part of the propagation delay of timing and synchronization messages; knowing this delay for each message allows for a more accurate determination of the delay to be taken into account when applying the value included in a PrecisionTime Protocol event message. |
|
| |
| RFC 8171 | Transparent Interconnection of Lots of Links (TRILL): Edge Directory Assistance Mechanisms |
| |
| Authors: | D. Eastlake 3rd, L. Dunbar, R. Perlman, Y. Li. |
| Date: | June 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8171 |
|
This document describes mechanisms for providing directory service toTRILL (Transparent Interconnection of Lots of Links) edge switches.The directory information provided can be used in reducing multi- destination traffic, particularly ARP / Neighbor Discovery (ND) and unknown unicast flooding. It can also be used to detect traffic with forged source addresses. |
|
| |
| RFC 8173 | Precision Time Protocol Version 2 (PTPv2) Management Information Base |
| |
| Authors: | V. Shankarkumar, L. Montini, T. Frost, G. Dowd. |
| Date: | June 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8173 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in internets based on TCP or IP. In particular, it defines objects for managing networks using the Precision Time Protocol (PTP), specified in IEEE Std. 1588-2008.
This memo specifies a MIB module in a manner that is both compliant to the Structure of Management Information version 2 (SMIv2) and semantically identical to the peer SMIv1 definitions. |
|
| |
| RFC 8175 | Dynamic Link Exchange Protocol (DLEP) |
| |
| Authors: | S. Ratliff, S. Jury, D. Satterwhite, R. Taylor, B. Berry. |
| Date: | June 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8175 |
|
When routing devices rely on modems to effect communications over wireless links, they need timely and accurate knowledge of the characteristics of the link (speed, state, etc.) in order to make routing decisions. In mobile or other environments where these characteristics change frequently, manual configurations or the inference of state through routing or transport protocols does not allow the router to make the best decisions. This document introduces a new protocol called the Dynamic Link Exchange Protocol(DLEP), which provides a bidirectional, event-driven communication channel between the router and the modem to facilitate communication of changing link characteristics. |
|
| |
| RFC 8176 | Authentication Method Reference Values |
| |
| Authors: | M. Jones, P. Hunt, A. Nadalin. |
| Date: | June 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8176 |
|
The "amr" (Authentication Methods References) claim is defined and registered in the IANA "JSON Web Token Claims" registry, but no standard Authentication Method Reference values are currently defined. This specification establishes a registry forAuthentication Method Reference values and defines an initial set ofAuthentication Method Reference values. |
|
| |
| RFC 8177 | YANG Data Model for Key Chains |
| |
| Authors: | A. Lindem, Ed., Y. Qu, D. Yeung, I. Chen, J. Zhang. |
| Date: | June 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8177 |
|
This document describes the key chain YANG data model. Key chains are commonly used for routing protocol authentication and other applications requiring symmetric keys. A key chain is a list containing one or more elements containing a Key ID, key string, send/accept lifetimes, and the associated authentication or encryption algorithm. By properly overlapping the send and accept lifetimes of multiple key chain elements, key strings and algorithms may be gracefully updated. By representing them in a YANG data model, key distribution can be automated. |
|
| |
| RFC 8178 | Rules for NFSv4 Extensions and Minor Versions |
| |
|
|
This document describes the rules relating to the extension of theNFSv4 family of protocols. It covers the creation of minor versions, the addition of optional features to existing minor versions, and the correction of flaws in features already published as ProposedStandards. The rules relating to the construction of minor versions and the interaction of minor version implementations that appear in this document supersede the minor versioning rules in RFC 5661 and other RFCs defining minor versions. |
|
| |
| RFC 8181 | A Publication Protocol for the Resource Public Key Infrastructure (RPKI) |
| |
| Authors: | S. Weiler, A. Sonalker, R. Austein. |
| Date: | July 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8181 |
|
This document defines a protocol for publishing Resource Public KeyInfrastructure (RPKI) objects. Even though the RPKI will have many participants issuing certificates and creating other objects, it is operationally useful to consolidate the publication of those objects.Even in cases where a certificate issuer runs its own publication repository, it can be useful to run the certificate engine itself on a different machine from the publication repository. This document defines a protocol which addresses these needs. |
|
| |
| RFC 8182 | The RPKI Repository Delta Protocol (RRDP) |
| |
| Authors: | T. Bruijnzeels, O. Muravskiy, B. Weber, R. Austein. |
| Date: | July 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8182 |
|
In the Resource Public Key Infrastructure (RPKI), CertificateAuthorities (CAs) publish certificates, including end-entity certificates, Certificate Revocation Lists (CRLs), and RPKI signed objects to repositories. Relying Parties retrieve the published information from those repositories. This document specifies a newRPKI Repository Delta Protocol (RRDP) for this purpose. RRDP was specifically designed for scaling. It relies on an UpdateNotification File which lists the current Snapshot and Delta Files that can be retrieved using HTTPS (HTTP over Transport Layer Security(TLS)), and it enables the use of Content Distribution Networks(CDNs) or other caching infrastructures for the retrieval of these files. |
|
| |
| RFC 8183 | An Out-of-Band Setup Protocol for Resource Public Key Infrastructure (RPKI) Production Services |
| |
| Authors: | R. Austein. |
| Date: | July 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8183 |
|
This note describes a simple out-of-band protocol to ease setup of the Resource Public Key Infrastructure (RPKI) provisioning and publication protocols between two parties. The protocol is encoded in a small number of XML messages, which can be passed back and forth by any mutually agreeable means which provides acceptable data integrity and authentication.
This setup protocol is not part of the provisioning or publication protocol; rather, it is intended to simplify configuration of these protocols by setting up relationships and exchanging keying material used to authenticate those relationships. |
|
| |
| RFC 8185 | Dual-Homing Coordination for MPLS Transport Profile (MPLS-TP) Pseudowires Protection |
| |
| Authors: | W. Cheng, L. Wang, H. Li, J. Dong, A. D'Alessandro. |
| Date: | June 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8185 |
|
In some scenarios, MPLS Transport Profile (MPLS-TP) pseudowires (PWs)(RFC 5921) may be statically configured when a dynamic control plane is not available. A fast protection mechanism for MPLS-TP PWs is needed to protect against the failure of an Attachment Circuit (AC), the failure of a Provider Edge (PE), or a failure in the PacketSwitched Network (PSN). The framework and typical scenarios of dual- homing PW local protection are described in RFC 8184. This document proposes a dual-homing coordination mechanism for MPLS-TP PWs that is used for state exchange and switchover coordination between the dual- homing PEs for dual-homing PW local protection. |
|
| |
| RFC 8186 | Support of the IEEE 1588 Timestamp Format in a Two-Way Active Measurement Protocol (TWAMP) |
| |
| Authors: | G. Mirsky, I. Meilik. |
| Date: | June 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8186 |
|
This document describes an OPTIONAL feature for active performance measurement protocols that allows use of the Precision Time Protocol timestamp format defined in IEEE 1588v2, as an alternative to theNetwork Time Protocol that is currently used. |
|
| |
| RFC 8187 | Indicating Character Encoding and Language for HTTP Header Field Parameters |
| |
|
|
By default, header field values in Hypertext Transfer Protocol (HTTP) messages cannot easily carry characters outside the US-ASCII coded character set. RFC 2231 defines an encoding mechanism for use in parameters inside Multipurpose Internet Mail Extensions (MIME) header field values. This document specifies an encoding suitable for use in HTTP header fields that is compatible with a simplified profile of the encoding defined in RFC 2231.
This document obsoletes RFC 5987. |
|
| |
| RFC 8188 | Encrypted Content-Encoding for HTTP |
| |
| Authors: | M. Thomson. |
| Date: | June 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8188 |
|
This memo introduces a content coding for HTTP that allows message payloads to be encrypted. |
|
| |
| RFC 8189 | Multi-Cost Application-Layer Traffic Optimization (ALTO) |
| |
| Authors: | S. Randriamasy, W. Roome, N. Schwan. |
| Date: | October 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8189 |
|
The Application-Layer Traffic Optimization (ALTO) protocol, specified in RFC 7285, defines several services that return various metrics describing the costs between network endpoints.
This document defines a new service that allows an ALTO Client to retrieve several cost metrics in a single request for an ALTO filtered cost map and endpoint cost map. In addition, it extends the constraints to further filter those maps by allowing an ALTO Client to specify a logical combination of tests on several cost metrics. |
|
| |
| RFC 8191 | Home Network Prefix Renumbering in Proxy Mobile IPv6 (PMIPv6) |
| |
| Authors: | Z. Yan, J. Lee, X. Lee. |
| Date: | August 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8191 |
|
In the basic Proxy Mobile IPv6 (PMIPv6) specification, a Mobile Node(MN) is assigned with a Home Network Prefix (HNP) during its initial attachment, and the MN configures its Home Address (HoA) with theHNP. During the movement of the MN, the HNP remains unchanged to keep ongoing communications associated with the HoA. However, the current PMIPv6 specification does not specify related operations whenHNP renumbering has occurred (e.g., due to change of service provider or site topology, etc.). In this document, a solution to support HNP renumbering is proposed, as an optional extension of the PMIPv6 specification. |
|
| |
| RFC 8193 | Information Model for Large-Scale Measurement Platforms (LMAPs) |
| |
| Authors: | T. Burbridge, P. Eardley, M. Bagnulo, J. Schoenwaelder. |
| Date: | August 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8193 |
|
This Information Model applies to the Measurement Agent within anLMAP framework. As such, it outlines the information that is configured or preconfigured on the Measurement Agent or exists in communications with a Controller or Collector within an LMAP framework. The purpose of such an Information Model is to provide a protocol- and device-independent view of the Measurement Agent that can be implemented via one or more Control and Report Protocols. |
|
| |
| RFC 8194 | A YANG Data Model for LMAP Measurement Agents |
| |
| Authors: | J. Schoenwaelder, V. Bajpai. |
| Date: | August 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8194 |
|
This document defines a data model for Large-Scale MeasurementPlatforms (LMAPs). The data model is defined using the YANG data modeling language. |
|
| |
| RFC 8196 | IS-IS Autoconfiguration |
| |
| Authors: | B. Liu, Ed., L. Ginsberg, B. Decraene, I. Farrer, M. Abrahamsson. |
| Date: | July 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8196 |
|
This document specifies IS-IS autoconfiguration mechanisms. The key components are IS-IS System ID self-generation, duplication detection, and duplication resolution. These mechanisms provide limited IS-IS functions and are therefore suitable for networks where plug-and-play configuration is expected. |
|
| |
| RFC 8197 | A SIP Response Code for Unwanted Calls |
| |
| Authors: | H. Schulzrinne. |
| Date: | July 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8197 |
|
This document defines the 607 (Unwanted) SIP response code, allowing called parties to indicate that the call or message was unwanted.SIP entities may use this information to adjust how future calls from this calling party are handled for the called party or more broadly. |
|
| |
| RFC 8198 | Aggressive Use of DNSSEC-Validated Cache |
| |
|
|
The DNS relies upon caching to scale; however, the cache lookup generally requires an exact match. This document specifies the use of NSEC/NSEC3 resource records to allow DNSSEC-validating resolvers to generate negative answers within a range and positive answers from wildcards. This increases performance, decreases latency, decreases resource utilization on both authoritative and recursive servers, and increases privacy. Also, it may help increase resilience to certainDoS attacks in some circumstances.
This document updates RFC 4035 by allowing validating resolvers to generate negative answers based upon NSEC/NSEC3 records and positive answers in the presence of wildcards. |
|
| |
| RFC 8202 | IS-IS Multi-Instance |
| |
| Authors: | L. Ginsberg, S. Previdi, W. Henderickx. |
| Date: | June 2017 |
| Formats: | txt json html |
| Obsoletes: | RFC 6822 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8202 |
|
This document describes a mechanism that allows a single router to share one or more circuits among multiple Intermediate System toIntermediate System (IS-IS) routing protocol instances.
Multiple instances allow the isolation of resources associated with each instance. Routers will form instance-specific adjacencies.Each instance can support multiple topologies. Each topology has a unique Link State Database (LSDB). Each Protocol Data Unit (PDU) will contain a new Type-Length-Value (TLV) identifying the instance and the topology (or topologies) to which the PDU belongs.
This document obsoletes RFC 6822. |
|
| |
| RFC 8203 | BGP Administrative Shutdown Communication |
| |
|
|
This document enhances the BGP Cease NOTIFICATION message"Administrative Shutdown" and "Administrative Reset" subcodes for operators to transmit a short freeform message to describe why a BGP session was shutdown or reset. This document updates RFC 4486. |
|
| |
| RFC 8205 | BGPsec Protocol Specification |
| |
| Authors: | M. Lepinski, Ed., K. Sriram, Ed.. |
| Date: | September 2017 |
| Formats: | txt html json |
| Updated by: | RFC 8206 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8205 |
|
This document describes BGPsec, an extension to the Border GatewayProtocol (BGP) that provides security for the path of AutonomousSystems (ASes) through which a BGP UPDATE message passes. BGPsec is implemented via an optional non-transitive BGP path attribute that carries digital signatures produced by each AS that propagates theUPDATE message. The digital signatures provide confidence that everyAS on the path of ASes listed in the UPDATE message has explicitly authorized the advertisement of the route. |
|
| |
| RFC 8206 | BGPsec Considerations for Autonomous System (AS) Migration |
| |
| Authors: | W. George, S. Murphy. |
| Date: | September 2017 |
| Formats: | txt json html |
| Updates: | RFC 8205 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8206 |
|
This document discusses considerations and methods for supporting and securing a common method for Autonomous System (AS) migration within the BGPsec protocol. |
|
| |
| RFC 8208 | BGPsec Algorithms, Key Formats, and Signature Formats |
| |
|
|
This document specifies the algorithms, algorithm parameters, asymmetric key formats, asymmetric key sizes, and signature formats used in BGPsec (Border Gateway Protocol Security). This document updates RFC 7935 ("The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure").
This document also includes example BGPsec UPDATE messages as well as the private keys used to generate the messages and the certificates necessary to validate those signatures. |
|
| |
| RFC 8209 | A Profile for BGPsec Router Certificates, Certificate Revocation Lists, and Certification Requests |
| |
| Authors: | M. Reynolds, S. Turner, S. Kent. |
| Date: | September 2017 |
| Formats: | txt html json |
| Updates: | RFC 6487 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8209 |
|
This document defines a standard profile for X.509 certificates used to enable validation of Autonomous System (AS) paths in the BorderGateway Protocol (BGP), as part of an extension to that protocol known as BGPsec. BGP is the standard for inter-domain routing in theInternet; it is the "glue" that holds the Internet together. BGPsec is being developed as one component of a solution that addresses the requirement to provide security for BGP. The goal of BGPsec is to provide full AS path validation based on the use of strong cryptographic primitives. The end entity (EE) certificates specified by this profile are issued to routers within an AS. Each of these certificates is issued under a Resource Public Key Infrastructure(RPKI) Certification Authority (CA) certificate. These CA certificates and EE certificates both contain the AS Resource extension. An EE certificate of this type asserts that the router or routers holding the corresponding private key are authorized to emit secure route advertisements on behalf of the AS(es) specified in the certificate. This document also profiles the format of certification requests and specifies Relying Party (RP) certificate path validation procedures for these EE certificates. This document extends theRPKI; therefore, this document updates the RPKI Resource CertificatesProfile (RFC 6487). |
|
| |
| RFC 8210 | The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 1 |
| |
|
|
In order to verifiably validate the origin Autonomous Systems andAutonomous System Paths of BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure(RFC 6480) prefix origin data and router keys from a trusted cache.This document describes a protocol to deliver them.
This document describes version 1 of the RPKI-Router protocol. RFC6810 describes version 0. This document updates RFC 6810. |
|
| |
| RFC 8212 | Default External BGP (EBGP) Route Propagation Behavior without Policies |
| |
| Authors: | J. Mauch, J. Snijders, G. Hankins. |
| Date: | July 2017 |
| Formats: | txt json html |
| Updates: | RFC 4271 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8212 |
|
This document updates RFC 4271 by defining the default behavior of aBGP speaker when there is no Import or Export Policy associated with an External BGP session. |
|
| |
| RFC 8213 | Security of Messages Exchanged between Servers and Relay Agents |
| |
| Authors: | B. Volz, Y. Pal. |
| Date: | August 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8213 |
|
The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) has no guidance for how to secure messages exchanged between servers and relay agents. The Dynamic Host Configuration Protocol for IPv6(DHCPv6) states that IPsec should be used to secure messages exchanged between servers and relay agents but does not require encryption. With recent concerns about pervasive monitoring and other attacks, it is appropriate to require securing relay-to-relay and relay-to-server communication for DHCPv6 and relay-to-server communication for DHCPv4. |
|
| |
| RFC 8214 | Virtual Private Wire Service Support in Ethernet VPN |
| |
| Authors: | S. Boutros, A. Sajassi, S. Salam, J. Drake, J. Rabadan. |
| Date: | August 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8214 |
|
This document describes how Ethernet VPN (EVPN) can be used to support the Virtual Private Wire Service (VPWS) in MPLS/IP networks.EVPN accomplishes the following for VPWS: provides Single-Active as well as All-Active multihoming with flow-based load-balancing, eliminates the need for Pseudowire (PW) signaling, and provides fast protection convergence upon node or link failure. |
|
| |
| RFC 8215 | Local-Use IPv4/IPv6 Translation Prefix |
| |
| Authors: | T. Anderson. |
| Date: | August 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8215 |
|
This document reserves the IPv6 prefix 64:ff9b:1::/48 for local use within domains that enable IPv4/IPv6 translation mechanisms. |
|
| |
| RFC 8217 | Clarifications for When to Use the name-addr Production in SIP Messages |
| |
|
|
RFC 3261 constrained several SIP header fields whose grammar contains the "name-addr / addr-spec" alternative to use name-addr when certain characters appear. Unfortunately, it expressed the constraints with prose copied into each header field definition, and at least one header field was missed. Further, the constraint has not been copied into documents defining extension headers whose grammar contains the alternative.
This document updates RFC 3261 to state the constraint generically and clarifies that the constraint applies to all SIP header fields where there is a choice between using name-addr or addr-spec. It also updates the RFCs that define extension SIP header fields using the alternative to clarify that the constraint applies (RFCs 3325,3515, 3892, 4508, 5002, 5318, 5360, and 5502). |
|
| |
| RFC 8221 | Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH) |
| |
| Authors: | P. Wouters, D. Migault, J. Mattsson, Y. Nir, T. Kivinen. |
| Date: | October 2017 |
| Formats: | txt html json |
| Obsoletes: | RFC 7321 |
| Updated by: | RFC 9395 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8221 |
|
This document replaces RFC 7321, "Cryptographic AlgorithmImplementation Requirements and Usage Guidance for EncapsulatingSecurity Payload (ESP) and Authentication Header (AH)". The goal of this document is to enable ESP and AH to benefit from cryptography that is up to date while making IPsec interoperable. |
|
| |
| RFC 8223 | Application-Aware Targeted LDP |
| |
| Authors: | S. Esale, R. Torvi, L. Jalil, U. Chunduri, K. Raza. |
| Date: | August 2017 |
| Formats: | txt json html |
| Updates: | RFC 7473 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8223 |
|
Recent Targeted Label Distribution Protocol (tLDP) applications, such as remote Loop-Free Alternates (LFAs) and BGP auto-discovered pseudowires, may automatically establish a tLDP session with anyLabel Switching Router (LSR) in a network. The initiating LSR has information about the targeted applications to administratively control initiation of the session. However, the responding LSR has no such information to control acceptance of this session. This document defines a mechanism to advertise and negotiate the TargetedApplication Capability (TAC) during LDP session initialization. As the responding LSR becomes aware of targeted applications, it may establish a limited number of tLDP sessions for certain applications.In addition, each targeted application is mapped to LDP ForwardingEquivalence Class (FEC) elements to advertise only necessary LDP FEC label bindings over the session. This document updates RFC 7473 for enabling advertisement of LDP FEC label bindings over the session. |
|
| |
| RFC 8224 | Authenticated Identity Management in the Session Initiation Protocol (SIP) |
| |
| Authors: | J. Peterson, C. Jennings, E. Rescorla, C. Wendt. |
| Date: | February 2018 |
| Formats: | txt html json |
| Obsoletes: | RFC 4474 |
| Updated by: | RFC 8946 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8224 |
|
The baseline 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 requests. It does so by defining aSIP header field for conveying a signature used for validating the identity and for conveying a reference to the credentials of the signer.
This document obsoletes RFC 4474. |
|
| |
| RFC 8225 | PASSporT: Personal Assertion Token |
| |
| Authors: | C. Wendt, J. Peterson. |
| Date: | February 2018 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8225 |
|
This document defines a method for creating and validating a token that cryptographically verifies an originating identity or, more generally, a URI or telephone number representing the originator of personal communications. The Personal Assertion Token, PASSporT, is cryptographically signed to protect the integrity of the identity of the originator and to verify the assertion of the identity information at the destination. The cryptographic signature is defined with the intention that it can confidently verify the originating persona even when the signature is sent to the destination party over an insecure channel. PASSporT is particularly useful for many personal-communications applications over IP networks and other multi-hop interconnection scenarios where the originating and destination parties may not have a direct trusted relationship. |
|
| |
| RFC 8226 | Secure Telephone Identity Credentials: Certificates |
| |
| Authors: | J. Peterson, S. Turner. |
| Date: | February 2018 |
| Formats: | txt json html |
| Updated by: | RFC 9118 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8226 |
|
In order to prevent the impersonation of telephone numbers on theInternet, some kind of credential system needs to exist that cryptographically asserts authority over telephone numbers. This document describes the use of certificates in establishing authority over telephone numbers, as a component of a broader architecture for managing telephone numbers as identities in protocols like SIP. |
|
| |
| RFC 8227 | MPLS-TP Shared-Ring Protection (MSRP) Mechanism for Ring Topology |
| |
| Authors: | W. Cheng, L. Wang, H. Li, H. van Helvoort, J. Dong. |
| Date: | August 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8227 |
|
This document describes requirements, architecture, and solutions forMPLS-TP Shared-Ring Protection (MSRP) in a ring topology for point- to-point (P2P) services. The MSRP mechanism is described to meet the ring protection requirements as described in RFC 5654. This document defines the Ring Protection Switching (RPS) protocol that is used to coordinate the protection behavior of the nodes on an MPLS ring. |
|
| |
| RFC 8229 | TCP Encapsulation of IKE and IPsec Packets |
| |
| Authors: | T. Pauly, S. Touati, R. Mantha. |
| Date: | August 2017 |
| Formats: | txt html json |
| Obsoleted by: | RFC 9329 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8229 |
|
This document describes a method to transport Internet Key ExchangeProtocol (IKE) and IPsec packets over a TCP connection for traversing network middleboxes that may block IKE negotiation over UDP. This method, referred to as "TCP encapsulation", involves sending both IKE packets for Security Association establishment and EncapsulatingSecurity Payload (ESP) packets over a TCP connection. This method is intended to be used as a fallback option when IKE cannot be negotiated over UDP. |
|
| |
| RFC 8230 | Using RSA Algorithms with CBOR Object Signing and Encryption (COSE) Messages |
| |
| Authors: | M. Jones. |
| Date: | September 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8230 |
|
The CBOR Object Signing and Encryption (COSE) specification defines cryptographic message encodings using Concise Binary ObjectRepresentation (CBOR). This specification defines algorithm encodings and representations enabling RSA algorithms to be used forCOSE messages. Encodings are specified for the use of RSAProbabilistic Signature Scheme (RSASSA-PSS) signatures, RSAEncryption Scheme - Optimal Asymmetric Encryption Padding (RSAES-OAEP) encryption, and RSA keys. |
|
| |
| RFC 8231 | Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE |
| |
|
|
The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests.
Although PCEP explicitly makes no assumptions regarding the information available to the PCE, it also makes no provisions for PCE control of timing and sequence of path computations within and acrossPCEP sessions. This document describes a set of extensions to PCEP to enable stateful control of MPLS-TE and GMPLS Label Switched Paths(LSPs) via PCEP. |
|
| |
| RFC 8232 | Optimizations of Label Switched Path State Synchronization Procedures for a Stateful PCE |
| |
| Authors: | E. Crabbe, I. Minei, J. Medved, R. Varga, X. Zhang, D. Dhody. |
| Date: | September 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8232 |
|
A stateful Path Computation Element (PCE) has access to not only the information disseminated by the network's Interior Gateway Protocol(IGP) but also the set of active paths and their reserved resources for its computation. The additional Label Switched Path (LSP) state information allows the PCE to compute constrained paths while considering individual LSPs and their interactions. This requires aState Synchronization mechanism between the PCE and the network, thePCE and Path Computation Clients (PCCs), and cooperating PCEs. The basic mechanism for State Synchronization is part of the stateful PCE specification. This document presents motivations for optimizations to the base State Synchronization procedure and specifies the required Path Computation Element Communication Protocol (PCEP) extensions. |
|
| |
| RFC 8233 | Extensions to the Path Computation Element Communication Protocol (PCEP) to Compute Service-Aware Label Switched Paths (LSPs) |
| |
| Authors: | D. Dhody, Q. Wu, V. Manral, Z. Ali, K. Kumaki. |
| Date: | September 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8233 |
|
In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network performance criteria (e.g., latency) are becoming as critical to data path selection as other metrics and constraints. These metrics are associated with the Service Level Agreement (SLA) between customers and service providers. The link bandwidth utilization (the total bandwidth of a link in actual use for the forwarding) is another important factor to consider during path computation.
IGP Traffic Engineering (TE) Metric Extensions describe mechanisms with which network performance information is distributed via OSPF and IS-IS, respectively. The Path Computation Element CommunicationProtocol (PCEP) provides mechanisms for Path Computation Elements(PCEs) to perform path computations in response to Path ComputationClient (PCC) requests. This document describes the extension to PCEP to carry latency, delay variation, packet loss, and link bandwidth utilization as constraints for end-to-end path computation. |
|
| |
| RFC 8234 | Updates to MPLS Transport Profile (MPLS-TP) Linear Protection in Automatic Protection Switching (APS) Mode |
| |
| Authors: | J. Ryoo, T. Cheung, H. van Helvoort, I. Busi, G. Wen. |
| Date: | August 2017 |
| Formats: | txt html json |
| Updates: | RFC 7271 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8234 |
|
This document contains updates to MPLS Transport Profile (MPLS-TP) linear protection in Automatic Protection Switching (APS) mode defined in RFC 7271. The updates provide rules related to the initialization of the Protection State Coordination (PSC) ControlLogic (in which the state machine resides) when operating in APS mode and clarify the operation related to state transition table lookup. |
|
| |
| RFC 8237 | MPLS Label Switched Path (LSP) Pseudowire (PW) Status Refresh Reduction for Static PWs |
| |
| Authors: | L. Martini, G. Swallow, E. Bellagamba. |
| Date: | October 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8237 |
|
This document describes a method for generating an aggregated pseudowire (PW) status message transmitted for a statically configured PW on a Multiprotocol Label Switching (MPLS) LabelSwitched Path (LSP) to indicate the status of one or more PWs carried on the LSP.
The method for transmitting the PW status information is not new; however, this protocol extension allows a Service Provider (SP) to reliably monitor the individual PW status while not overwhelming the network with multiple periodic status messages. This is achieved by sending a single cumulative summary status verification message for all the PWs grouped in the same LSP. |
|
| |
| RFC 8245 | Rules for Designing Protocols Using the Generalized Packet/Message Format from RFC 5444 |
| |
| Authors: | T. Clausen, C. Dearlove, U. Herberg, H. Rogge. |
| Date: | October 2017 |
| Formats: | txt json html |
| Updates: | RFC 5444 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8245 |
|
RFC 5444 specifies a generalized Mobile Ad Hoc Network (MANET) packet/message format and describes an intended use for multiplexedMANET routing protocol messages; this use is mandated by RFC 5498 when using the MANET port or protocol number that it specifies. This document updates RFC 5444 by providing rules and recommendations for how the multiplexer operates and how protocols can use the packet/message format. In particular, the mandatory rules prohibit a number of uses that have been suggested in various proposals and that would have led to interoperability problems, to the impediment of protocol extension development, and/or to an inability to use optional generic parsers. |
|
| |
| RFC 8246 | HTTP Immutable Responses |
| |
| Authors: | P. McManus. |
| Date: | September 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8246 |
|
The immutable HTTP response Cache-Control extension allows servers to identify resources that will not be updated during their freshness lifetime. This ensures that a client never needs to revalidate a cached fresh resource to be certain it has not been modified. |
|
| |
| RFC 8247 | Algorithm Implementation Requirements and Usage Guidance for the Internet Key Exchange Protocol Version 2 (IKEv2) |
| |
|
|
The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Internet KeyExchange (IKE) protocol is used to negotiate the IPsec SecurityAssociation (IPsec SA) parameters, such as which algorithms should be used. To ensure interoperability between different implementations, it is necessary to specify a set of algorithm implementation requirements and usage guidance to ensure that there is at least one algorithm that all implementations support. This document updatesRFC 7296 and obsoletes RFC 4307 in defining the current algorithm implementation requirements and usage guidance for IKEv2, and does minor cleaning up of the IKEv2 IANA registry. This document does not update the algorithms used for packet encryption using IPsecEncapsulating Security Payload (ESP). |
|
| |
| RFC 8249 | Transparent Interconnection of Lots of Links (TRILL): MTU Negotiation |
| |
|
|
The base IETF TRILL (Transparent Interconnection of Lots of Links) protocol has a TRILL campus-wide MTU feature, specified in RFCs 6325 and 7177, that assures that link-state changes can be successfully flooded throughout the campus while being able to take advantage of a campus-wide capability to support jumbo packets. This document specifies recommended updates to that MTU feature to take advantage, for appropriate link-local packets, of link-local MTUs that exceed the TRILL campus MTU. In addition, it specifies an efficient algorithm for local MTU testing. This document updates RFCs 6325,7177, and 7780. |
|
| |
| RFC 8250 | IPv6 Performance and Diagnostic Metrics (PDM) Destination Option |
| |
| Authors: | N. Elkins, R. Hamilton, M. Ackermann. |
| Date: | September 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8250 |
|
To assess performance problems, this document describes optional headers embedded in each packet that provide sequence numbers and timing information as a basis for measurements. Such measurements may be interpreted in real time or after the fact. This document specifies the Performance and Diagnostic Metrics (PDM) DestinationOptions header. The field limits, calculations, and usage in measurement of PDM are included in this document. |
|
| |
| RFC 8251 | Updates to the Opus Audio Codec |
| |
|
|
This document addresses minor issues that were found in the specification of the Opus audio codec in RFC 6716. It updates the normative decoder implementation included in Appendix A of RFC 6716.The changes fix real and potential security-related issues, as well as minor quality-related issues. |
|
| |
| RFC 8253 | PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP) |
| |
| Authors: | D. Lopez, O. Gonzalez de Dios, Q. Wu, D. Dhody. |
| Date: | October 2017 |
| Formats: | txt html json |
| Updates: | RFC 5440 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8253 |
|
The Path Computation Element Communication Protocol (PCEP) defines the mechanisms for the communication between a Path ComputationClient (PCC) and a Path Computation Element (PCE), or among PCEs.This document describes PCEPS -- the usage of Transport LayerSecurity (TLS) to provide a secure transport for PCEP. The additional security mechanisms are provided by the transport protocol supporting PCEP; therefore, they do not affect the flexibility and extensibility of PCEP.
This document updates RFC 5440 in regards to the PCEP initialization phase procedures. |
|
| |
| RFC 8254 | Uniform Resource Name (URN) Namespace Registration Transition |
| |
|
|
The original registration procedure for formal Uniform Resource Name(URN) namespaces required IETF Consensus. That requirement discouraged some registrations and increased the risk for problems that could occur as a result. The requirements have now been changed by RFC 8141, which adopts a different model, focusing on encouraging registration and publication of information for all appropriate namespaces. This document clarifies the status of relevant olderRFCs and confirms and documents advice to IANA about selected existing registrations. This document also obsoletes RFCs 3044 and3187 and moves them to Historic status. These RFCs describe the ISSN and ISBN namespaces, which are now outdated because the descriptions reside in registration templates. |
|
| |
| RFC 8255 | Multiple Language Content Type |
| |
| Authors: | N. Tomkinson, N. Borenstein. |
| Date: | October 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8255 |
|
This document defines the 'multipart/multilingual' content type, which is an addition to the Multipurpose Internet Mail Extensions(MIME) standard. This content type makes it possible to send one message that contains multiple language versions of the same information. The translations would be identified by a language tag and selected by the email client based on a user's language settings. |
|
| |
| RFC 8258 | Generalized SCSI: A Generic Structure for Interface Switching Capability Descriptor (ISCD) Switching Capability Specific Information (SCSI) |
| |
| Authors: | D. Ceccarelli, L. Berger. |
| Date: | October 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8258 |
|
This document defines a generic information structure for information carried in routing protocol Interface Switching Capability Descriptor(ISCD) Switching Capability Specific Information (SCSI) fields. This"Generalized SCSI" can be used with routing protocols that defineGMPLS ISCDs and any specific technology. This document does not modify any existing technology-specific formats and is defined for use in conjunction with new GMPLS Switching Capability types. The context for this document is Generalized MPLS, and the reader is expected to be familiar with the GMPLS architecture and associated protocol standards. |
|
| |
| RFC 8260 | Stream Schedulers and User Message Interleaving for the Stream Control Transmission Protocol |
| |
| Authors: | R. Stewart, M. Tuexen, S. Loreto, R. Seggelmann. |
| Date: | November 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8260 |
|
The Stream Control Transmission Protocol (SCTP) is a message-oriented transport protocol supporting arbitrarily large user messages. This document adds a new chunk to SCTP for carrying payload data. This allows a sender to interleave different user messages that would otherwise result in head-of-line blocking at the sender. The interleaving of user messages is required for WebRTC data channels.
Whenever an SCTP sender is allowed to send user data, it may choose from multiple outgoing SCTP streams. Multiple ways for performing this selection, called stream schedulers, are defined in this document. A stream scheduler can choose to either implement, or not implement, user message interleaving. |
|
| |
| RFC 8261 | Datagram Transport Layer Security (DTLS) Encapsulation of SCTP Packets |
| |
|
|
The Stream Control Transmission Protocol (SCTP) is a transport protocol originally defined to run on top of the network protocolsIPv4 or IPv6. This document specifies how SCTP can be used on top of the Datagram Transport Layer Security (DTLS) protocol. Using the encapsulation method described in this document, SCTP is unaware of the protocols being used below DTLS; hence, explicit IP addresses cannot be used in the SCTP control chunks. As a consequence, theSCTP associations carried over DTLS can only be single-homed. |
|
| |
| RFC 8262 | Content-ID Header Field in the Session Initiation Protocol (SIP) |
| |
|
|
This document specifies the Content-ID header field for usage in theSession Initiation Protocol (SIP). This document also updates RFC5621, which only allows a Content-ID URL to reference a body part that is part of a multipart message-body. This update enables aContent-ID URL to reference a complete message-body and metadata provided by some additional SIP header fields.
This document updates RFC 5368 and RFC 6442 by clarifying their usage of the SIP Content-ID header field. |
|
| |
| RFC 8263 | Group Domain of Interpretation (GDOI) GROUPKEY-PUSH Acknowledgement Message |
| |
| Authors: | B. Weis, U. Mangla, T. Karl, N. Maheshwari. |
| Date: | November 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8263 |
|
The Group Domain of Interpretation (GDOI) includes the ability of aGroup Controller/Key Server (GCKS) to provide a set of current GroupMember (GM) devices with additional security associations (e.g., to rekey expiring security associations). This memo adds the ability of a GCKS to request that the GM devices return an acknowledgement of receipt of its rekey message and specifies the acknowledgement method. |
|
| |
| RFC 8264 | PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols |
| |
| Authors: | P. Saint-Andre, M. Blanchet. |
| Date: | October 2017 |
| Formats: | txt json html |
| Obsoletes: | RFC 7564 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8264 |
|
Application protocols using Unicode code points in protocol strings need to properly handle such strings in order to enforce internationalization rules for strings placed in various protocol slots (such as addresses and identifiers) and to perform valid comparison operations (e.g., for purposes of authentication or authorization). This document defines a framework enabling application protocols to perform the preparation, enforcement, and comparison of internationalized strings ("PRECIS") in a way that depends on the properties of Unicode code points and thus is more agile with respect to versions of Unicode. As a result, this framework provides a more sustainable approach to the handling of internationalized strings than the previous framework, known asStringprep (RFC 3454). This document obsoletes RFC 7564. |
|
| |
| RFC 8265 | Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords |
| |
| Authors: | P. Saint-Andre, A. Melnikov. |
| Date: | October 2017 |
| Formats: | txt json html |
| Obsoletes: | RFC 7613 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8265 |
|
This document describes updated methods for handling Unicode strings representing usernames and passwords. The previous approach was known as SASLprep (RFC 4013) and was based on Stringprep (RFC 3454).The methods specified in this document provide a more sustainable approach to the handling of internationalized usernames and passwords. This document obsoletes RFC 7613. |
|
| |
| RFC 8266 | Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames |
| |
|
|
This document describes methods for handling Unicode strings representing memorable, human-friendly names (called "nicknames","display names", or "petnames") for people, devices, accounts, websites, and other entities. This document obsoletes RFC 7700. |
|
| |
| RFC 8267 | Network File System (NFS) Upper-Layer Binding to RPC-over-RDMA Version 1 |
| |
|
|
This document specifies Upper-Layer Bindings of Network File System(NFS) protocol versions to RPC-over-RDMA version 1, thus enabling the use of Direct Data Placement. This document obsoletes RFC 5667. |
|
| |
| RFC 8268 | More Modular Exponentiation (MODP) Diffie-Hellman (DH) Key Exchange (KEX) Groups for Secure Shell (SSH) |
| |
|
|
This document defines added Modular Exponentiation (MODP) groups for the Secure Shell (SSH) protocol using SHA-2 hashes. This document updates RFC 4250. This document updates RFC 4253 by correcting an error regarding checking the Peer's DH Public Key. |
|
| |
| RFC 8270 | Increase the Secure Shell Minimum Recommended Diffie-Hellman Modulus Size to 2048 Bits |
| |
| Authors: | L. Velvindron, M. Baushke. |
| Date: | December 2017 |
| Formats: | txt json html |
| Updates: | RFC 4419 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8270 |
|
The Diffie-Hellman (DH) Group Exchange for the Secure Shell (SSH) transport-layer protocol specifies that servers and clients should support groups with a minimum modulus group size of 1024 bits.Recent security research has shown that the minimum value of 1024 bits is insufficient to protect against state-sponsored actors and any organization with enough computing resources. This RFC updatesRFC 4419, which allowed for DH moduli less than 2048 bits; now, 2048 bits is the minimum acceptable group size. |
|
| |
| RFC 8271 | Updates to the Resource Reservation Protocol for Fast Reroute of Traffic Engineering GMPLS Label Switched Paths (LSPs) |
| |
| Authors: | M. Taillon, T. Saad, Ed., R. Gandhi, Ed., Z. Ali, M. Bhatia. |
| Date: | October 2017 |
| Formats: | txt json html |
| Updates: | RFC 4090 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8271 |
|
This document updates the Resource Reservation Protocol - TrafficEngineering (RSVP-TE) Fast Reroute (FRR) procedures defined in RFC4090 to support Packet Switch Capable (PSC) Generalized MultiprotocolLabel Switching (GMPLS) Label Switched Paths (LSPs). These updates allow the coordination of a bidirectional bypass tunnel assignment protecting a common facility in both forward and reverse directions of a co-routed bidirectional LSP. In addition, these updates enable the redirection of bidirectional traffic onto bypass tunnels that ensure the co-routing of data paths in the forward and reverse directions after FRR and avoid RSVP soft-state timeout in the control plane. |
|
| |
| RFC 8275 | Allowing Inheritable NFSv4 Access Control Entries to Override the Umask |
| |
| Authors: | J. Fields, A. Gruenbacher. |
| Date: | December 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8275 |
|
In many environments, inheritable NFSv4 Access Control Entries (ACEs) can be rendered ineffective by the application of the per-process file mode creation mask (umask). This can be addressed by transmitting the umask and create mode as separate pieces of data, allowing the server to make more intelligent decisions about the permissions to set on new files. This document proposes a protocol extension to accomplish that. |
|
| |
| RFC 8276 | File System Extended Attributes in NFSv4 |
| |
| Authors: | M. Naik, M. Eshel. |
| Date: | December 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8276 |
|
This document describes an optional feature extending the NFSv4 protocol. This feature allows extended attributes (hereinafter also referred to as xattrs) to be interrogated and manipulated using NFSv4 clients. Xattrs are provided by a file system to associate opaque metadata, not interpreted by the file system, with files and directories. Such support is present in many modern local file systems. New file attributes are provided to allow clients to query the server for xattr support, with that support consisting of new operations to get and set xattrs on file system objects. |
|
| |
| RFC 8277 | Using BGP to Bind MPLS Labels to Address Prefixes |
| |
|
|
This document specifies a set of procedures for using BGP to advertise that a specified router has bound a specified MPLS label(or a specified sequence of MPLS labels organized as a contiguous part of a label stack) to a specified address prefix. This can be done by sending a BGP UPDATE message whose Network Layer ReachabilityInformation field contains both the prefix and the MPLS label(s) and whose Next Hop field identifies the node at which said prefix is bound to said label(s). This document obsoletes RFC 3107. |
|
| |
| RFC 8278 | Mobile Access Gateway (MAG) Multipath Options |
| |
| Authors: | P. Seite, A. Yegin, S. Gundavelli. |
| Date: | January 2018 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8278 |
|
This specification defines extensions to the Proxy Mobile IPv6(PMIPv6) protocol that allow a mobile access gateway (MAG) to register more than one proxy care-of address (pCoA) with the local mobility anchor (LMA) and to simultaneously establish multiple IP tunnels with the LMA. This capability allows the MAG to utilize all the available access networks to route the mobile node's IP traffic.This document defines the following two new mobility header options: the MAG Multipath Binding option and the MAG Identifier option. |
|
| |
| RFC 8279 | Multicast Using Bit Index Explicit Replication (BIER) |
| |
| Authors: | IJ. Wijnands, Ed., E. Rosen, Ed., A. Dolganow, T. Przygienda, S. Aldrin. |
| Date: | November 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8279 |
|
This document specifies a new architecture for the forwarding of multicast data packets. It provides optimal forwarding of multicast packets through a "multicast domain". However, it does not require a protocol for explicitly building multicast distribution trees, nor does it require intermediate nodes to maintain any per-flow state.This architecture is known as "Bit Index Explicit Replication"(BIER). When a multicast data packet enters the domain, the ingress router determines the set of egress routers to which the packet needs to be sent. The ingress router then encapsulates the packet in aBIER header. The BIER header contains a bit string in which each bit represents exactly one egress router in the domain; to forward the packet to a given set of egress routers, the bits corresponding to those routers are set in the BIER header. The procedures for forwarding a packet based on its BIER header are specified in this document. Elimination of the per-flow state and the explicit tree- building protocols results in a considerable simplification. |
|
| |
| RFC 8281 | Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model |
| |
| Authors: | E. Crabbe, I. Minei, S. Sivabalan, R. Varga. |
| Date: | December 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8281 |
|
The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests.
The extensions for stateful PCE provide active control ofMultiprotocol Label Switching (MPLS) Traffic Engineering LabelSwitched Paths (TE LSPs) via PCEP, for a model where the PCC delegates control over one or more locally configured LSPs to thePCE. This document describes the creation and deletion ofPCE-initiated LSPs under the stateful PCE model. |
|
| |
| RFC 8282 | Extensions to the Path Computation Element Communication Protocol (PCEP) for Inter-Layer MPLS and GMPLS Traffic Engineering |
| |
| Authors: | E. Oki, T. Takeda, A. Farrel, F. Zhang. |
| Date: | December 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8282 |
|
The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol LabelSwitching (MPLS) and Generalized MPLS (GMPLS) networks.
MPLS and GMPLS networks may be constructed from layered service networks. It is advantageous for overall network efficiency to provide end-to-end traffic engineering across multiple network layers through a process called inter-layer traffic engineering. PCE is a candidate solution for such requirements.
The PCE Communication Protocol (PCEP) is designed as a communication protocol between Path Computation Clients (PCCs) and PCEs. This document presents PCEP extensions for inter-layer traffic engineering. |
|
| |
| RFC 8285 | A General Mechanism for RTP Header Extensions |
| |
| Authors: | D. Singer, H. Desineni, R. Even, Ed.. |
| Date: | October 2017 |
| Formats: | txt json html |
| Obsoletes: | RFC 5285 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8285 |
|
This document provides a general mechanism to use the header extension feature of RTP (the Real-time Transport Protocol). It provides the option to use a small number of small extensions in eachRTP packet, where the universe of possible extensions is large and registration is decentralized. The actual extensions in use in a session are signaled in the setup information for that session. This document obsoletes RFC 5285. |
|
| |
| RFC 8286 | RTP/RTCP Extension for RTP Splicing Notification |
| |
| Authors: | J. Xia, R. Even, R. Huang, L. Deng. |
| Date: | October 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8286 |
|
Content splicing is a process that replaces the content of a main multimedia stream with other multimedia content and that delivers the substitutive multimedia content to the receivers for a period of time. The splicer is designed to handle RTP splicing and needs to know when to start and end the splicing.
This memo defines two RTP/RTCP extensions to indicate the splicing- related information to the splicer: an RTP header extension that conveys the information "in band" and an RTP Control Protocol (RTCP) packet that conveys the information out of band. |
|
| |
| RFC 8287 | Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data Planes |
| |
| Authors: | N. Kumar, Ed., C. Pignataro, Ed., G. Swallow, N. Akiya, S. Kini, M. Chen. |
| Date: | December 2017 |
| Formats: | txt html json |
| Updated by: | RFC 8690, RFC 9214 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8287 |
|
A Segment Routing (SR) architecture leverages source routing and tunneling paradigms and can be directly applied to the use of aMultiprotocol Label Switching (MPLS) data plane. A node steers a packet through a controlled set of instructions called "segments" by prepending the packet with an SR header.
The segment assignment and forwarding semantic nature of SR raises additional considerations for connectivity verification and fault isolation for a Label Switched Path (LSP) within an SR architecture.This document illustrates the problem and defines extensions to perform LSP Ping and Traceroute for Segment Routing IGP-Prefix andIGP-Adjacency Segment Identifiers (SIDs) with an MPLS data plane. |
|
| |
| RFC 8288 | Web Linking |
| |
|
|
This specification defines a model for the relationships between resources on the Web ("links") and the type of those relationships("link relation types").
It also defines the serialisation of such links in HTTP headers with the Link header field. |
|
| |
| RFC 8291 | Message Encryption for Web Push |
| |
| Authors: | M. Thomson. |
| Date: | November 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8291 |
|
This document describes a message encryption scheme for the Web Push protocol. This scheme provides confidentiality and integrity for messages sent from an application server to a user agent. |
|
| |
| RFC 8292 | Voluntary Application Server Identification (VAPID) for Web Push |
| |
| Authors: | M. Thomson, P. Beverloo. |
| Date: | November 2017 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8292 |
|
An application server can use the Voluntary Application ServerIdentification (VAPID) method described in this document to voluntarily identify itself to a push service. The "vapid" authentication scheme allows a client to include its identity in a signed token with requests that it makes. The signature can be used by the push service to attribute requests that are made by the same application server to a single entity. The identification information can allow the operator of a push service to contact the operator of the application server. The signature can be used to restrict the use of a push message subscription to a single application server. |
|
| |
| RFC 8294 | Common YANG Data Types for the Routing Area |
| |
| Authors: | X. Liu, Y. Qu, A. Lindem, C. Hopps, L. Berger. |
| Date: | December 2017 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8294 |
|
This document defines a collection of common data types using theYANG data modeling language. These derived common types are designed to be imported by other modules defined in the routing area. |
|
| |
| RFC 8295 | EST (Enrollment over Secure Transport) Extensions |
| |
| Authors: | S. Turner. |
| Date: | January 2018 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8295 |
|
The EST (Enrollment over Secure Transport) protocol defines the Well-Known URI (Uniform Resource Identifier) -- /.well-known/est -- along with a number of other path components that clients use for PKI(Public Key Infrastructure) services, namely certificate enrollment(e.g., /simpleenroll). This document defines a number of other PKI services as additional path components -- specifically, firmware and trust anchors as well as symmetric, asymmetric, and encrypted keys.This document also specifies the PAL (Package Availability List), which is an XML (Extensible Markup Language) file or JSON (JavaScriptObject Notation) object that clients use to retrieve packages available and authorized for them. This document extends the EST server path components to provide these additional services. |
|
| |
| RFC 8296 | Encapsulation for Bit Index Explicit Replication (BIER) in MPLS and Non-MPLS Networks |
| |
| Authors: | IJ. Wijnands, Ed., E. Rosen, Ed., A. Dolganow, J. Tantsura, S. Aldrin, I. Meilik. |
| Date: | January 2018 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8296 |
|
Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "multicast domain", without requiring intermediate routers to maintain any per-flow state or to engage in an explicit tree-building protocol. When a multicast data packet enters the domain, the ingress router determines the set of egress routers to which the packet needs to be sent. The ingress router then encapsulates the packet in a BIER header. The BIER header contains a bit string in which each bit represents exactly one egress router in the domain; to forward the packet to a given set of egress routers, the bits corresponding to those routers are set in the BIER header. The details of the encapsulation depend on the type of network used to realize the multicast domain. This document specifies a BIER encapsulation that can be used in an MPLS network or, with slight differences, in a non-MPLS network. |
|
| |
| RFC 8299 | YANG Data Model for L3VPN Service Delivery |
| |
| Authors: | Q. Wu, Ed., S. Litkowski, L. Tomotaki, K. Ogaki. |
| Date: | January 2018 |
| Formats: | txt json html |
| Obsoletes: | RFC 8049 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8299 |
|
This document defines a YANG data model that can be used for communication between customers and network operators and to deliver a Layer 3 provider-provisioned VPN service. This document is limited to BGP PE-based VPNs as described in RFCs 4026, 4110, and 4364. This model is intended to be instantiated at the management system to deliver the overall service. It is not a configuration model to be used directly on network elements. This model provides an abstracted view of the Layer 3 IP VPN service configuration components. It will be up to the management system to take this model as input and use specific configuration models to configure the different network elements to deliver the service. How the configuration of network elements is done is out of scope for this document.
This document obsoletes RFC 8049; it replaces the unimplementable module in that RFC with a new module with the same name that is not backward compatible. The changes are a series of small fixes to theYANG module and some clarifications to the text. |
|
| |
| RFC 8300 | Network Service Header (NSH) |
| |
| Authors: | P. Quinn, Ed., U. Elzur, Ed., C. Pignataro, Ed.. |
| Date: | January 2018 |
| Formats: | txt json html |
| Updated by: | RFC 9451 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8300 |
|
This document describes a Network Service Header (NSH) imposed on packets or frames to realize Service Function Paths (SFPs). The NSH also provides a mechanism for metadata exchange along the instantiated service paths. The NSH is the Service Function Chaining(SFC) encapsulation required to support the SFC architecture (defined in RFC 7665). |
|
| |
| RFC 8301 | Cryptographic Algorithm and Key Usage Update to DomainKeys Identified Mail (DKIM) |
| |
|
|
The cryptographic algorithm and key size requirements included whenDomainKeys Identified Mail (DKIM) was designed a decade ago are functionally obsolete and in need of immediate revision. This document updates DKIM requirements to those minimally suitable for operation with currently specified algorithms. |
|
| |
| RFC 8302 | Transparent Interconnection of Lots of Links (TRILL): ARP and Neighbor Discovery (ND) Optimization |
| |
| Authors: | Y. Li, D. Eastlake 3rd, L. Dunbar, R. Perlman, M. Umair. |
| Date: | January 2018 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8302 |
|
This document describes mechanisms to optimize the Address ResolutionProtocol (ARP) and Neighbor Discovery (ND) traffic in a TransparentInterconnection of Lots of Links (TRILL) campus. TRILL switches maintain a cache of IP / Media Access Control (MAC) address / DataLabel bindings that are learned from ARP/ND requests and responses that pass through them. In many cases, this cache allows an edgeRouting Bridge (RBridge) to avoid flooding an ARP/ND request by either responding to it directly or encapsulating it and unicasting it. Such optimization reduces packet flooding over a TRILL campus. |
|
| |
| RFC 8305 | Happy Eyeballs Version 2: Better Connectivity Using Concurrency |
| |
| Authors: | D. Schinazi, T. Pauly. |
| Date: | December 2017 |
| Formats: | txt json html |
| Obsoletes: | RFC 6555 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8305 |
|
Many communication protocols operating over the modern Internet use hostnames. These often resolve to multiple IP addresses, each of which may have different performance and connectivity characteristics. Since specific addresses or address families (IPv4 or IPv6) may be blocked, broken, or sub-optimal on a network, clients that attempt multiple connections in parallel have a chance of establishing a connection more quickly. This document specifies requirements for algorithms that reduce this user-visible delay and provides an example algorithm, referred to as "Happy Eyeballs". This document obsoletes the original algorithm description in RFC 6555. |
|
| |
| RFC 8306 | Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths |
| |
| Authors: | Q. Zhao, D. Dhody, Ed., R. Palleti, D. King. |
| Date: | November 2017 |
| Formats: | txt html json |
| Obsoletes: | RFC 6006 |
| Updated by: | RFC 9353 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8306 |
|
Point-to-point Multiprotocol Label Switching (MPLS) and GeneralizedMPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may be established using signaling techniques, but their paths may first need to be determined. The Path Computation Element (PCE) has been identified as an appropriate technology for the determination of the paths of point-to-multipoint (P2MP) TE LSPs.
This document describes extensions to the PCE Communication Protocol(PCEP) to handle requests and responses for the computation of paths for P2MP TE LSPs.
This document obsoletes RFC 6006. |
|
| |
| RFC 8307 | Well-Known URIs for the WebSocket Protocol |
| |
|
|
RFC 5785 defines a path prefix, "/.well-known/", that can be used by well-known URIs. It was specifically defined for the "http" and"https" URI schemes. The present memo formally updates RFC 6455, which defines the URI schemes defined for the WebSocket Protocol, to extend the use of these well-known URIs to those URI schemes. |
|
| |
| RFC 8308 | Extension Negotiation in the Secure Shell (SSH) Protocol |
| |
|
|
This memo updates RFCs 4251, 4252, 4253, and 4254 by defining a mechanism for Secure Shell (SSH) clients and servers to exchange information about supported protocol extensions confidentially afterSSH key exchange. |
|
| |
| RFC 8310 | Usage Profiles for DNS over TLS and DNS over DTLS |
| |
| Authors: | S. Dickinson, D. Gillmor, T. Reddy. |
| Date: | March 2018 |
| Formats: | txt json html |
| Updates: | RFC 7858 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8310 |
|
This document discusses usage profiles, based on one or more authentication mechanisms, which can be used for DNS over TransportLayer Security (TLS) or Datagram TLS (DTLS). These profiles can increase the privacy of DNS transactions compared to using only cleartext DNS. This document also specifies new authentication mechanisms -- it describes several ways that a DNS client can use an authentication domain name to authenticate a (D)TLS connection to aDNS server. Additionally, it defines (D)TLS protocol profiles forDNS clients and servers implementing DNS over (D)TLS. This document updates RFC 7858. |
|
| |
| RFC 8311 | Relaxing Restrictions on Explicit Congestion Notification (ECN) Experimentation |
| |
|
|
This memo updates RFC 3168, which specifies Explicit CongestionNotification (ECN) as an alternative to packet drops for indicating network congestion to endpoints. It relaxes restrictions in RFC 3168 that hinder experimentation towards benefits beyond just removal of loss. This memo summarizes the anticipated areas of experimentation and updates RFC 3168 to enable experimentation in these areas. AnExperimental RFC in the IETF document stream is required to take advantage of any of these enabling updates. In addition, this memo makes related updates to the ECN specifications for RTP in RFC 6679 and for the Datagram Congestion Control Protocol (DCCP) in RFCs 4341,4342, and 5622. This memo also records the conclusion of the ECN nonce experiment in RFC 3540 and provides the rationale for reclassification of RFC 3540 from Experimental to Historic; this reclassification enables new experimental use of the ECT(1) codepoint. |
|
| |
| RFC 8314 | Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access |
| |
|
|
This specification outlines current recommendations for the use ofTransport Layer Security (TLS) to provide confidentiality of email traffic between a Mail User Agent (MUA) and a Mail Submission Server or Mail Access Server. This document updates RFCs 1939, 2595, 3501,5068, 6186, and 6409. |
|
| |
| RFC 8315 | Cancel-Locks in Netnews Articles |
| |
|
|
This document defines an extension to the Netnews Article Format that may be used to authenticate the withdrawal of existing articles.This document updates RFC 5537. |
|
| |
| RFC 8317 | Ethernet-Tree (E-Tree) Support in Ethernet VPN (EVPN) and Provider Backbone Bridging EVPN (PBB-EVPN) |
| |
| Authors: | A. Sajassi, Ed., S. Salam, J. Drake, J. Uttaro, S. Boutros, J. Rabadan. |
| Date: | January 2018 |
| Formats: | txt html json |
| Updates: | RFC 7385 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8317 |
|
The MEF Forum (MEF) has defined a rooted-multipoint Ethernet service known as Ethernet-Tree (E-Tree). A solution framework for supporting this service in MPLS networks is described in RFC 7387, "A Framework for Ethernet-Tree (E-Tree) Service over a Multiprotocol LabelSwitching (MPLS) Network". This document discusses how those functional requirements can be met with a solution based on RFC 7432,"BGP MPLS Based Ethernet VPN (EVPN)", with some extensions and a description of how such a solution can offer a more efficient implementation of these functions than that of RFC 7796,"Ethernet-Tree (E-Tree) Support in Virtual Private LAN Service(VPLS)". This document makes use of the most significant bit of theTunnel Type field (in the P-Multicast Service Interface (PMSI) Tunnel attribute) governed by the IANA registry created by RFC 7385; hence, it updates RFC 7385 accordingly. |
|
| |
| RFC 8319 | Support for Adjustable Maximum Router Lifetimes per Link |
| |
| Authors: | S. Krishnan, J. Korhonen, S. Chakrabarti, E. Nordmark, A. Yourtchenko. |
| Date: | February 2018 |
| Formats: | txt json html |
| Updates: | RFC 4861 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8319 |
|
The IPv6 Neighbor Discovery protocol specifies the maximum time allowed between sending unsolicited multicast Router Advertisements(RAs) from a router interface as well as the maximum router lifetime.It also allows the limits to be overridden by documents that are specific to the link layer. This document allows for overriding these values on a per-link basis.
This document specifies updates to the IPv6 Neighbor DiscoveryProtocol (RFC 4861) to increase the maximum time allowed between sending unsolicited multicast RAs from a router interface as well as to increase the maximum router lifetime. |
|
| |
| RFC 8320 | LDP Extensions to Support Maximally Redundant Trees |
| |
| Authors: | A. Atlas, K. Tiruveedhula, C. Bowers, J. Tantsura, IJ. Wijnands. |
| Date: | February 2018 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8320 |
|
This document specifies extensions to the Label Distribution Protocol(LDP) to support the creation of Label Switched Paths (LSPs) forMaximally Redundant Trees (MRTs). A prime use of MRTs is for unicast and multicast IP/LDP Fast Reroute, which we will refer to as"MRT-FRR".
The sole protocol extension to LDP is simply the ability to advertise an MRT Capability. This document describes that extension and the associated behavior expected for Label Switching Routers (LSRs) andLabel Edge Routers (LERs) advertising the MRT Capability.
MRT-FRR uses LDP multi-topology extensions, so three multi-topologyIDs have been allocated from the MPLS MT-ID space. |
|
| |
| RFC 8322 | Resource-Oriented Lightweight Information Exchange (ROLIE) |
| |
| Authors: | J. Field, S. Banghart, D. Waltermire. |
| Date: | February 2018 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8322 |
|
This document defines a resource-oriented approach for security automation information publication, discovery, and sharing. Using this approach, producers may publish, share, and exchange representations of software descriptors, security incidents, attack indicators, software vulnerabilities, configuration checklists, and other security automation information as web-addressable resources.Furthermore, consumers and other stakeholders may access and search this security information as needed, establishing a rapid and on-demand information exchange network for restricted internal use or public access repositories. This specification extends the AtomPublishing Protocol and Atom Syndication Format to transport and share security automation resource representations. |
|
| |
| RFC 8323 | CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets |
| |
| Authors: | C. Bormann, S. Lemay, H. Tschofenig, K. Hartke, B. Silverajan, B. Raymor, Ed.. |
| Date: | February 2018 |
| Formats: | txt html json |
| Updates: | RFC 7641, RFC 7959 |
| Updated by: | RFC 8974 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8323 |
|
The Constrained Application Protocol (CoAP), although inspired byHTTP, was designed to use UDP instead of TCP. The message layer ofCoAP over UDP includes support for reliable delivery, simple congestion control, and flow control.
Some environments benefit from the availability of CoAP carried over reliable transports such as TCP or Transport Layer Security (TLS).This document outlines the changes required to use CoAP over TCP,TLS, and WebSockets transports. It also formally updates RFC 7641 for use with these transports and RFC 7959 to enable the use of larger messages over a reliable transport. |
|
| |
| RFC 8325 | Mapping Diffserv to IEEE 802.11 |
| |
| Authors: | T. Szigeti, J. Henry, F. Baker. |
| Date: | February 2018 |
| Formats: | txt json html |
| Updated by: | RFC 8622 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8325 |
|
As Internet traffic is increasingly sourced from and destined to wireless endpoints, it is crucial that Quality of Service (QoS) be aligned between wired and wireless networks; however, this is not always the case by default. This document specifies a set of mappings from Differentiated Services Code Point (DSCP) to IEEE802.11 User Priority (UP) to reconcile the marking recommendations offered by the IETF and the IEEE so as to maintain consistent QoS treatment between wired and IEEE 802.11 wireless networks. |
|
| |
| RFC 8326 | Graceful BGP Session Shutdown |
| |
| Authors: | P. Francois, Ed., B. Decraene, Ed., C. Pelsser, K. Patel, C. Filsfils. |
| Date: | March 2018 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8326 |
|
This document standardizes a new well-known BGP community,GRACEFUL_SHUTDOWN, to signal the graceful shutdown of paths. This document also describes operational procedures that use this well-known community to reduce the amount of traffic lost when BGP peering sessions are about to be shut down deliberately, e.g., for planned maintenance. |
|
| |
| RFC 8330 | OSPF Traffic Engineering (OSPF-TE) Link Availability Extension for Links with Variable Discrete Bandwidth |
| |
| Authors: | H. Long, M. Ye, G. Mirsky, A. D'Alessandro, H. Shah. |
| Date: | February 2018 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8330 |
|
A network may contain links with variable discrete bandwidth, e.g., microwave and copper. The bandwidth of such links may change discretely in response to a changing external environment. The word"availability" is typically used to describe such links during network planning. This document defines a new type of GeneralizedSwitching Capability-Specific Information (SCSI) TLV to extend theGeneralized Multiprotocol Label Switching (GMPLS) Open Shortest PathFirst (OSPF) routing protocol. The extension can be used for route computation in a network that contains links with variable discrete bandwidth. Note that this document only covers the mechanisms by which the availability information is distributed. The mechanisms by which availability information of a link is determined and the use of the distributed information for route computation are outside the scope of this document. It is intended that technology-specific documents will reference this document to describe specific uses. |
|
| |
| RFC 8331 | RTP Payload for Society of Motion Picture and Television Engineers (SMPTE) ST 291-1 Ancillary Data |
| |
| Authors: | T. Edwards. |
| Date: | February 2018 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8331 |
|
This memo describes a Real-time Transport Protocol (RTP) payload format for the Society of Motion Picture and Television Engineers(SMPTE) ancillary space (ANC) data, as defined by SMPTE ST 291-1.SMPTE ANC data is generally used along with professional video formats to carry a range of ancillary data types, including time code, Closed Captioning, and the Active Format Description (AFD). |
|
| |
| RFC 8332 | Use of RSA Keys with SHA-256 and SHA-512 in the Secure Shell (SSH) Protocol |
| |
|
|
This memo updates RFCs 4252 and 4253 to define new public key algorithms for use of RSA keys with SHA-256 and SHA-512 for server and client authentication in SSH connections. |
|
| |
| RFC 8333 | Micro-loop Prevention by Introducing a Local Convergence Delay |
| |
| Authors: | S. Litkowski, B. Decraene, C. Filsfils, P. Francois. |
| Date: | March 2018 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8333 |
|
This document describes a mechanism for link-state routing protocols that prevents local transient forwarding loops in case of link failure. This mechanism proposes a two-step convergence by introducing a delay between the convergence of the node adjacent to the topology change and the network-wide convergence.
Because this mechanism delays the IGP convergence, it may only be used for planned maintenance or when Fast Reroute (FRR) protects the traffic during the time between the link failure and the IGP convergence.
The mechanism is limited to the link-down event in order to keep the mechanism simple.
Simulations using real network topologies have been performed and show that local loops are a significant portion (&rt;50%) of the total forwarding loops. |
|
| |
| RFC 8334 | Launch Phase Mapping for the Extensible Provisioning Protocol (EPP) |
| |
| Authors: | J. Gould, W. Tan, G. Brown. |
| Date: | March 2018 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8334 |
|
This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of domain name registrations and applications during the launch of a domain name registry. |
|
| |
| RFC 8335 | PROBE: A Utility for Probing Interfaces |
| |
| Authors: | R. Bonica, R. Thomas, J. Linkova, C. Lenart, M. Boucadair. |
| Date: | February 2018 |
| Formats: | txt json html |
| Updates: | RFC 4884 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8335 |
|
This document describes a network diagnostic tool called PROBE.PROBE is similar to PING in that it can be used to query the status of a probed interface, but it differs from PING in that it does not require bidirectional connectivity between the probing and probed interfaces. Instead, PROBE requires bidirectional connectivity between the probing interface and a proxy interface. The proxy interface can reside on the same node as the probed interface, or it can reside on a node to which the probed interface is directly connected. This document updates RFC 4884. |
|
| |
| RFC 8336 | The ORIGIN HTTP/2 Frame |
| |
| Authors: | M. Nottingham, E. Nygren. |
| Date: | March 2018 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8336 |
|
This document specifies the ORIGIN frame for HTTP/2, to indicate what origins are available on a given connection. |
|
| |
| RFC 8338 | Signaling Root-Initiated Point-to-Multipoint Pseudowire Using LDP |
| |
| Authors: | S. Boutros, Ed., S. Sivabalan, Ed.. |
| Date: | March 2018 |
| Formats: | txt json html |
| Updates: | RFC 7385 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8338 |
|
This document specifies a mechanism to signal Point-to-Multipoint(P2MP) Pseudowire (PW) trees using LDP. Such a mechanism is suitable for any Layer 2 VPN service requiring P2MP connectivity over an IP orMPLS-enabled PSN. A P2MP PW established via the proposed mechanism is root initiated. This document updates RFC 7385 by reassigning the reserved value 0xFF to be the wildcard transport tunnel type. |
|
| |
| RFC 8339 | Definition of P2MP PW TLV for Label Switched Path (LSP) Ping Mechanisms |
| |
| Authors: | P. Jain, Ed., S. Boutros, S. Aldrin. |
| Date: | March 2018 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8339 |
|
Label Switched Path (LSP) Ping is a widely deployed Operation,Administration, and Maintenance (OAM) mechanism in MPLS networks.This document describes a mechanism to verify connectivity of Point- to-Multipoint (P2MP) Pseudowires (PWs) using LSP Ping. |
|
| |
| RFC 8342 | Network Management Datastore Architecture (NMDA) |
| |
| Authors: | M. Bjorklund, J. Schoenwaelder, P. Shafer, K. Watsen, R. Wilton. |
| Date: | March 2018 |
| Formats: | txt json html |
| Updates: | RFC 7950 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8342 |
|
Datastores are a fundamental concept binding the data models written in the YANG data modeling language to network management protocols such as the Network Configuration Protocol (NETCONF) and RESTCONF.This document defines an architectural framework for datastores based on the experience gained with the initial simpler model, addressing requirements that were not well supported in the initial model. This document updates RFC 7950. |
|
| |
| RFC 8343 | A YANG Data Model for Interface Management |
| |
|
|
This document defines a YANG data model for the management of network interfaces. It is expected that interface-type-specific data models augment the generic interfaces data model defined in this document.The data model includes definitions for configuration and system state (status information and counters for the collection of statistics).
The YANG data model in this document conforms to the NetworkManagement Datastore Architecture (NMDA) defined in RFC 8342.
This document obsoletes RFC 7223. |
|
| |
| RFC 8344 | A YANG Data Model for IP Management |
| |
|
|
This document defines a YANG data model for management of IP implementations. The data model includes configuration and system state.
The YANG data model in this document conforms to the NetworkManagement Datastore Architecture defined in RFC 8342.
This document obsoletes RFC 7277. |
|
| |
| RFC 8345 | A YANG Data Model for Network Topologies |
| |
| Authors: | A. Clemm, J. Medved, R. Varga, N. Bahadur, H. Ananthakrishnan, X. Liu. |
| Date: | March 2018 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8345 |
|
This document defines an abstract (generic, or base) YANG data model for network/service topologies and inventories. The data model serves as a base model that is augmented with technology-specific details in other, more specific topology and inventory data models. |
|
| |
| RFC 8346 | A YANG Data Model for Layer 3 Topologies |
| |
| Authors: | A. Clemm, J. Medved, R. Varga, X. Liu, H. Ananthakrishnan, N. Bahadur. |
| Date: | March 2018 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8346 |
|
This document defines a YANG data model for Layer 3 network topologies. |
|
| |
| RFC 8347 | A YANG Data Model for the Virtual Router Redundancy Protocol (VRRP) |
| |
| Authors: | X. Liu, Ed., A. Kyparlis, R. Parikh, A. Lindem, M. Zhang. |
| Date: | March 2018 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8347 |
|
This document describes a data model for the Virtual RouterRedundancy Protocol (VRRP). Both versions 2 and 3 of VRRP are covered. |
|
| |
| RFC 8348 | A YANG Data Model for Hardware Management |
| |
| Authors: | A. Bierman, M. Bjorklund, J. Dong, D. Romascanu. |
| Date: | March 2018 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8348 |
|
This document defines a YANG data model for the management of hardware on a single server. |
|
| |
| RFC 8349 | A YANG Data Model for Routing Management (NMDA Version) |
| |
| Authors: | L. Lhotka, A. Lindem, Y. Qu. |
| Date: | March 2018 |
| Formats: | txt html json |
| Obsoletes: | RFC 8022 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8349 |
|
This document specifies three YANG modules and one submodule.Together, they form the core routing data model that serves as a framework for configuring and managing a routing subsystem. It is expected that these modules will be augmented by additional YANG modules defining data models for control-plane protocols, route filters, and other functions. The core routing data model provides common building blocks for such extensions -- routes, RoutingInformation Bases (RIBs), and control-plane protocols.
The YANG modules in this document conform to the Network ManagementDatastore Architecture (NMDA). This document obsoletes RFC 8022. |
|
| |
| RFC 8353 | Generic Security Service API Version 2: Java Bindings Update |
| |
| Authors: | M. Upadhyay, S. Malkani, W. Wang. |
| Date: | May 2018 |
| Formats: | txt json html |
| Obsoletes: | RFC 5653 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8353 |
|
The Generic Security Services Application Programming Interface(GSS-API) offers application programmers uniform access to security services atop a variety of underlying cryptographic mechanisms. This document updates the Java bindings for the GSS-API that are specified in "Generic Security Service API Version 2: Java Bindings Update"(RFC 5653). This document obsoletes RFC 5653 by adding a new output token field to the GSSException class so that when the initSecContext or acceptSecContext methods of the GSSContext class fail, it has a chance to emit an error token that can be sent to the peer for debugging or informational purpose. The stream-based GSSContext methods are also removed in this version.
The GSS-API is described at a language-independent conceptual level in "Generic Security Service Application Program Interface Version 2,Update 1" (RFC 2743). 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 forGSS-API are "The Simple Public-Key GSS-API Mechanism (SPKM)"(RFC 2025) and "The Kerberos Version 5 Generic Security ServiceApplication Program Interface (GSS-API) Mechanism: Version 2"(RFC 4121). |
|
| |
| RFC 8356 | Experimental Codepoint Allocation for the Path Computation Element Communication Protocol (PCEP) |
| |
| Authors: | D. Dhody, D. King, A. Farrel. |
| Date: | March 2018 |
| Formats: | txt json html |
| Updates: | RFC 5440 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8356 |
|
IANA assigns values to the Path Computation Element CommunicationProtocol (PCEP) parameters (messages, objects, TLVs). IANA established a top-level registry to contain all PCEP codepoints and sub-registries. This top-level registry contains sub-registries forPCEP message, object, and TLV types. The allocation policy for each of these sub-registries is IETF Review.
This document updates RFC 5440 by changing the allocation policies for these three registries to mark some of the codepoints as assigned for Experimental Use. |
|
| |
| RFC 8357 | Generalized UDP Source Port for DHCP Relay |
| |
| Authors: | N. Shen, E. Chen. |
| Date: | March 2018 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8357 |
|
This document defines an extension to the DHCP protocols that allows a relay agent to use any available source port for upstream communications. The extension also allows inclusion of a DHCP option that can be used to statelessly route responses back to the appropriate source port on downstream communications. |
|
| |
| RFC 8359 | Network-Assigned Upstream Label |
| |
|
|
This document discusses a Generalized Multi-Protocol Label Switching(GMPLS) Resource reSerVation Protocol with Traffic Engineering(RSVP-TE) mechanism that enables the network to assign an upstream label for a bidirectional Label Switched Path (LSP). This is useful in scenarios where a given node does not have sufficient information to assign the correct upstream label on its own and needs to rely on the downstream node to pick an appropriate label. This document updates RFCs 3471, 3473, and 6205 as it defines processing for a special label value in the UPSTREAM_LABEL object. |
|
| |
| RFC 8360 | Resource Public Key Infrastructure (RPKI) Validation Reconsidered |
| |
| Authors: | G. Huston, G. Michaelson, C. Martinez, T. Bruijnzeels, A. Newton, D. Shaw. |
| Date: | April 2018 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8360 |
|
This document specifies an alternative to the certificate validation procedure specified in RFC 6487 that reduces aspects of operational fragility in the management of certificates in the Resource PublicKey Infrastructure (RPKI), while retaining essential security features.
The procedure specified in RFC 6487 requires that ResourceCertificates are rejected entirely if they are found to overclaim any resources not contained on the issuing certificate, whereas the validation process defined here allows an issuing CertificationAuthority (CA) to chose to communicate that such ResourceCertificates should be accepted for the intersection of their resources and the issuing certificate.
It should be noted that the validation process defined here considers validation under a single trust anchor (TA) only. In particular, concerns regarding overclaims where multiple configured TAs claim overlapping resources are considered out of scope for this document.
This choice is signaled by a set of alternative Object Identifiers(OIDs) per "X.509 Extensions for IP Addresses and AS Identifiers"(RFC 3779) and "Certificate Policy (CP) for the Resource Public KeyInfrastructure (RPKI)" (RFC 6484). It should be noted that in case these OIDs are not used for any certificate under a trust anchor, the validation procedure defined here has the same outcome as the procedure defined in RFC 6487.
Furthermore, this document provides an alternative to Route OriginAuthorization (ROA) (RFC 6482) and BGPsec Router Certificate (BGPsecPKI Profiles -- publication requested) validation. |
|
| |
| RFC 8361 | Transparent Interconnection of Lots of Links (TRILL): Centralized Replication for Active-Active Broadcast, Unknown Unicast, and Multicast (BUM) Traffic |
| |
| Authors: | W. Hao, Y. Li, M. Durrani, S. Gupta, A. Qu. |
| Date: | April 2018 |
| Formats: | txt html json |
| Updates: | RFC 6325 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8361 |
|
In Transparent Interconnection of Lots of Links (TRILL) active-active access, a Reverse Path Forwarding (RPF) check failure issue may occur when using the pseudo-nickname mechanism specified in RFC 7781. This document describes a solution to resolve this RPF check failure issue through centralized replication. All ingress Routing Bridges(RBridges) send Broadcast, Unknown Unicast, and Multicast (BUM) traffic to a centralized node with unicast TRILL encapsulation. When the centralized node receives the BUM traffic, it decapsulates the packets and forwards them to their destination RBridges using a distribution tree established per the TRILL base protocol (RFC 6325).To avoid RPF check failure on an RBridge sitting between the ingressRBridge and the centralized replication node, some change in the RPF calculation algorithm is required. RPF checks on each RBridge MUST be calculated as if the centralized node was the ingress RBridge, instead of being calculated using the actual ingress RBridge. This document updates RFC 6325. |
|
| |
| RFC 8362 | OSPFv3 Link State Advertisement (LSA) Extensibility |
| |
| Authors: | A. Lindem, A. Roy, D. Goethals, V. Reddy Vallem, F. Baker. |
| Date: | April 2018 |
| Formats: | txt json html |
| Updates: | RFC 5340, RFC 5838 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8362 |
|
OSPFv3 requires functional extension beyond what can readily be done with the fixed-format Link State Advertisement (LSA) as described inRFC 5340. Without LSA extension, attributes associated with OSPFv3 links and advertised IPv6 prefixes must be advertised in separateLSAs and correlated to the fixed-format LSAs. This document extends the LSA format by encoding the existing OSPFv3 LSA information inType-Length-Value (TLV) tuples and allowing advertisement of additional information with additional TLVs. Backward-compatibility mechanisms are also described.
This document updates RFC 5340, "OSPF for IPv6", and RFC 5838,"Support of Address Families in OSPFv3", by providing TLV-based encodings for the base OSPFv3 unicast support and OSPFv3 address family support. |
|
| |
| RFC 8363 | GMPLS OSPF-TE Extensions in Support of Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks |
| |
| Authors: | X. Zhang, H. Zheng, R. Casellas, O. Gonzalez de Dios, D. Ceccarelli. |
| Date: | May 2018 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8363 |
|
The International Telecommunication Union Telecommunication standardization sector (ITU-T) has extended its RecommendationsG.694.1 and G.872 to include a new Dense Wavelength DivisionMultiplexing (DWDM) grid by defining channel spacings, a set of nominal central frequencies, and the concept of the "frequency slot".Corresponding techniques for data-plane connections are known as"flexi-grid".
Based on the characteristics of flexi-grid defined in G.694.1 and inRFCs 7698 and 7699, this document describes the Open Shortest PathFirst - Traffic Engineering (OSPF-TE) extensions in support of GMPLS control of networks that include devices that use the new flexible optical grid. |
|
| |
| RFC 8365 | A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN) |
| |
| Authors: | A. Sajassi, Ed., J. Drake, Ed., N. Bitar, R. Shekhar, J. Uttaro, W. Henderickx. |
| Date: | March 2018 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8365 |
|
This document specifies how Ethernet VPN (EVPN) can be used as aNetwork Virtualization Overlay (NVO) solution and explores the various tunnel encapsulation options over IP and their impact on theEVPN control plane and procedures. In particular, the following encapsulation options are analyzed: Virtual Extensible LAN (VXLAN),Network Virtualization using Generic Routing Encapsulation (NVGRE), and MPLS over GRE. This specification is also applicable to GenericNetwork Virtualization Encapsulation (GENEVE); however, some incremental work is required, which will be covered in a separate document. This document also specifies new multihoming procedures for split-horizon filtering and mass withdrawal. It also specifiesEVPN route constructions for VXLAN/NVGRE encapsulations andAutonomous System Border Router (ASBR) procedures for multihoming ofNetwork Virtualization Edge (NVE) devices. |
|
| |
| RFC 8366 | A Voucher Artifact for Bootstrapping Protocols |
| |
| Authors: | K. Watsen, M. Richardson, M. Pritikin, T. Eckert. |
| Date: | May 2018 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8366 |
|
This document defines a strategy to securely assign a pledge to an owner using an artifact signed, directly or indirectly, by the pledge's manufacturer. This artifact is known as a "voucher".
This document defines an artifact format as a YANG-defined JSON document that has been signed using a Cryptographic Message Syntax(CMS) structure. Other YANG-derived formats are possible. The voucher artifact is normally generated by the pledge's manufacturer(i.e., the Manufacturer Authorized Signing Authority (MASA)).
This document only defines the voucher artifact, leaving it to other documents to describe specialized protocols for accessing it. |
|
| |
| RFC 8370 | Techniques to Improve the Scalability of RSVP-TE Deployments |
| |
| Authors: | V. Beeram, Ed., I. Minei, R. Shakir, D. Pacella, T. Saad. |
| Date: | May 2018 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8370 |
|
Networks that utilize RSVP-TE LSPs are encountering implementations that have a limited ability to support the growth in the number ofLSPs deployed.
This document defines two techniques, Refresh-Interval IndependentRSVP (RI-RSVP) and Per-Peer Flow Control, that reduce the number of processing cycles required to maintain RSVP-TE LSP state in LabelSwitching Routers (LSRs) and hence allow implementations to support larger scale deployments. |
|
| |
| RFC 8371 | Mobile Node Identifier Types for MIPv6 |
| |
| Authors: | C. Perkins, V. Devarapalli. |
| Date: | July 2018 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8371 |
|
This document defines additional identifier type numbers for use with the mobile node identifier option for Mobile IPv6 (MIPv6) as defined by RFC 4283. |
|
| |
| RFC 8373 | Negotiating Human Language in Real-Time Communications |
| |
|
|
Users have various human (i.e., natural) language needs, abilities, and preferences regarding spoken, written, and signed languages.This document defines new Session Description Protocol (SDP) media- level attributes so that when establishing interactive communication sessions ("calls"), it is possible to negotiate (i.e., communicate and match) the caller's language and media needs with the capabilities of the called party. This is especially important for emergency calls, because it allows for a call to be handled by a call taker capable of communicating with the user or for a translator or relay operator to be bridged into the call during setup. However, this also applies to non-emergency calls (for example, calls to a company call center).
This document describes the need as well as a solution that uses newSDP media attributes. |
|
| |
| RFC 8375 | Special-Use Domain 'home.arpa.' |
| |
|
|
This document specifies the behavior that is expected from the DomainName System with regard to DNS queries for names ending with'.home.arpa.' and designates this domain as a special-use domain name. 'home.arpa.' is designated for non-unique use in residential home networks. The Home Networking Control Protocol (HNCP) is updated to use the 'home.arpa.' domain instead of '.home'. |
|
| |
| RFC 8377 | Transparent Interconnection of Lots of Links (TRILL): Multi-Topology |
| |
|
|
This document specifies extensions to the IETF TRILL (TransparentInterconnection of Lots of Links) protocol to support multi-topology routing of unicast and multi-destination traffic based on IS-IS(Intermediate System to Intermediate System) multi-topology specified in RFC 5120. This document updates RFCs 6325 and 7177. |
|
| |
| RFC 8379 | OSPF Graceful Link Shutdown |
| |
| Authors: | S. Hegde, P. Sarkar, H. Gredler, M. Nanduri, L. Jalil. |
| Date: | May 2018 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8379 |
|
When a link is being prepared to be taken out of service, the traffic needs to be diverted from both ends of the link. Increasing the metric to the highest value on one side of the link is not sufficient to divert the traffic flowing in the other direction.
It is useful for the routers in an OSPFv2 or OSPFv3 routing domain to be able to advertise a link as being in a graceful-shutdown state to indicate impending maintenance activity on the link. This information can be used by the network devices to reroute the traffic effectively.
This document describes the protocol extensions to disseminate graceful-link-shutdown information in OSPFv2 and OSPFv3. |
|
| |
| RFC 8380 | Directory-Assisted Transparent Interconnection of Lots of Links (TRILL) Encapsulation |
| |
| Authors: | L. Dunbar, D. Eastlake 3rd, R. Perlman. |
| Date: | May 2018 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8380 |
|
This document describes how data center networks can benefit from non-RBridge nodes performing TRILL (Transparent Interconnection ofLots of Links) encapsulation with assistance from a directory service. |
|
| |
| RFC 8381 | Transparent Interconnection of Lots of Links (TRILL): Vendor-Specific RBridge Channel Protocol |
| |
| Authors: | D. Eastlake 3rd, Y. Li, W. Hao, A. Banerjee. |
| Date: | May 2018 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8381 |
|
The IETF TRILL (Transparent Interconnection of Lots of Links) protocol is implemented by devices called TRILL switches or RBridges(Routing Bridges). TRILL includes a general mechanism, called anRBridge Channel, for the transmission of typed messages betweenRBridges in the same campus and between RBridges and end stations on the same link. This document specifies a method to send vendor- specific messages over the RBridge Channel facility. |
|
| |
| RFC 8383 | Transparent Interconnection of Lots of Links (TRILL): Address Flush Message |
| |
| Authors: | W. Hao, D. Eastlake 3rd, Y. Li, M. Umair. |
| Date: | May 2018 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8383 |
|
The TRILL (Transparent Interconnection of Lots of Links) protocol, by default, learns end station addresses from observing the data plane.In particular, it learns local Media Access Control (MAC) addresses and the edge switch port of attachment from the receipt of local data frames and learns remote MAC addresses and the edge switch port of attachment from the decapsulation of remotely sourced TRILL Data packets.
This document specifies a message by which a TRILL switch can explicitly request other TRILL switches to flush certain MAC reachability learned through the decapsulation of TRILL Data packets.This is a supplement to the TRILL automatic address forgetting (seeSection 4.8.3 of RFC 6325) and can assist in achieving more rapid convergence in case of topology or configuration change. |
|
| |
| RFC 8384 | Transparent Interconnection of Lots of Links (TRILL) Smart Endnodes |
| |
| Authors: | R. Perlman, F. Hu, D. Eastlake 3rd, T. Liao. |
| Date: | July 2018 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8384 |
|
This document addresses the problem of the size and freshness of the endnode learning table in edge Routing Bridges (RBridges), by allowing endnodes to volunteer for endnode learning and encapsulation/decapsulation. Such an endnode is known as a "SmartEndnode". Only the attached edge RBridge can distinguish a "SmartEndnode" from a "normal endnode". The Smart Endnode uses the nickname of the attached edge RBridge, so this solution does not consume extra nicknames. The solution also enables endnodes that areFine-Grained Label (FGL) aware. |
|
| |
| RFC 8389 | Definitions of Managed Objects for Mapping of Address and Port with Encapsulation (MAP-E) |
| |
| Authors: | Y. Fu, S. Jiang, B. Liu, J. Dong, Y. Chen. |
| Date: | December 2018 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8389 |
|
This memo defines a portion of the Management Information Base (MIB) for Mapping of Address and Port with Encapsulation (MAP-E) for use with network management protocols. |
|
| |
| RFC 8390 | RSVP-TE Path Diversity Using Exclude Route |
| |
| Authors: | Z. Ali, Ed., G. Swallow, Ed., F. Zhang, Ed., D. Beller, Ed.. |
| Date: | July 2018 |
| Formats: | txt html json |
| Updates: | RFC 4874 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8390 |
|
RSVP-TE provides support for the communication of exclusion information during Label Switched Path (LSP) setup. A typical LSP diversity use case is for protection, where two LSPs should follow different paths through the network in order to avoid single points of failure, thus greatly improving service availability. This document specifies an approach that can be used for network scenarios where the full path(s) is not necessarily known by use of an abstract identifier for the path. Three types of abstract identifiers are specified: client based, Path Computation Element (PCE) based, and network based. This document specifies two new diversity subobjects for the RSVP eXclude Route Object (XRO) and the Explicit ExclusionRoute Subobject (EXRS).
For the protection use case, LSPs are typically created at a slow rate and exist for a long time so that it is reasonable to assume that a given (reference) path currently existing (with a well-known identifier) will continue to exist and can be used as a reference when creating the new diverse path. Re-routing of the existing(reference) LSP, before the new path is established, is not considered. |
|
| |
| RFC 8392 | CBOR Web Token (CWT) |
| |
| Authors: | M. Jones, E. Wahlstroem, S. Erdtman, H. Tschofenig. |
| Date: | May 2018 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8392 |
|
CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR), and CBOR ObjectSigning and Encryption (COSE) is used for added application-layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token(JWT) but uses CBOR rather than JSON. |
|
| |
| RFC 8393 | Operating the Network Service Header (NSH) with Next Protocol "None" |
| |
| Authors: | A. Farrel, J. Drake. |
| Date: | May 2018 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8393 |
|
This document describes a network that supports Service FunctionChaining (SFC) using the Network Service Header (NSH) with no payload data and carrying only metadata. This is achieved by defining a newNSH "Next Protocol" type value of "None".
This document illustrates some of the functions that may be achieved or enhanced by this mechanism, but it does not provide an exhaustive list of use cases, nor is it intended to be definitive about the functions it describes. It is expected that other documents will describe specific use cases in more detail and will define the protocol mechanics for each use case. |
|
| |
| RFC 8395 | Extensions to BGP-Signaled Pseudowires to Support Flow-Aware Transport Labels |
| |
| Authors: | K. Patel, S. Boutros, J. Liste, B. Wen, J. Rabadan. |
| Date: | June 2018 |
| Formats: | txt html json |
| Updates: | RFC 4761 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8395 |
|
This document defines protocol extensions required to synchronize flow label states among Provider Edges (PEs) when using the BGP-based signaling procedures. These protocol extensions are equally applicable to point-to-point Layer 2 Virtual Private Networks(L2VPNs). This document updates RFC 4761 by defining new flags in the Control Flags field of the Layer2 Info Extended Community. |
|
| |
| RFC 8397 | Transparent Interconnection of Lots of Links (TRILL) Multilevel Using Unique Nicknames |
| |
| Authors: | M. Zhang, D. Eastlake 3rd, R. Perlman, H. Zhai, D. Liu. |
| Date: | May 2018 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8397 |
|
TRILL (Transparent Interconnection of Lots of Links) routing can be extended to support multiple levels by building on the multilevel feature of IS-IS routing. Depending on how nicknames are managed, there are two primary alternatives to realize TRILL multilevel: the unique nickname approach and the aggregated nickname approach as discussed in RFC 8243. This document specifies a unique nickname approach. This approach gives unique nicknames to all TRILL switches across the multilevel TRILL campus. |
|
| |
| RFC 8398 | Internationalized Email Addresses in X.509 Certificates |
| |
| Authors: | A. Melnikov, Ed., W. Chuang, Ed.. |
| Date: | May 2018 |
| Formats: | txt html json |
| Updates: | RFC 5280 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8398 |
|
This document defines a new name form for inclusion in the otherName field of an X.509 Subject Alternative Name and Issuer AlternativeName extension that allows a certificate subject to be associated with an internationalized email address.
This document updates RFC 5280. |
|
| |
| RFC 8399 | Internationalization Updates to RFC 5280 |
| |
|
|
The updates to RFC 5280 described in this document provide alignment with the 2008 specification for Internationalized Domain Names (IDNs) and add support for internationalized email addresses in X.509 certificates. |
|
| |
| RFC 8400 | Extensions to RSVP-TE for Label Switched Path (LSP) Egress Protection |
| |
| Authors: | H. Chen, A. Liu, T. Saad, F. Xu, L. Huang. |
| Date: | June 2018 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8400 |
|
This document describes extensions to Resource Reservation Protocol -Traffic Engineering (RSVP-TE) for locally protecting the egress node(s) of a Point-to-Point (P2P) or Point-to-Multipoint (P2MP)Traffic Engineered (TE) Label Switched Path (LSP). |
|
| |
| RFC 8401 | Bit Index Explicit Replication (BIER) Support via IS-IS |
| |
| Authors: | L. Ginsberg, Ed., T. Przygienda, S. Aldrin, Z. Zhang. |
| Date: | June 2018 |
| Formats: | txt html json |
| Updated by: | RFC 9272 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8401 |
|
This document defines IS-IS extensions to support multicast forwarding using the Bit Index Explicit Replication (BIER) architecture. |
|
| |
| RFC 8402 | Segment Routing Architecture |
| |
| Authors: | C. Filsfils, Ed., S. Previdi, Ed., L. Ginsberg, B. Decraene, S. Litkowski, R. Shakir. |
| Date: | July 2018 |
| Formats: | txt json html |
| Updated by: | RFC 9256 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8402 |
|
Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called"segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain.
SR can be directly applied to the MPLS architecture with no change to the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack.
SR can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by theDestination Address (DA) of the packet. The next active segment is indicated by a pointer in the new routing header. |
|
| |
| RFC 8405 | Shortest Path First (SPF) Back-Off Delay Algorithm for Link-State IGPs |
| |
| Authors: | B. Decraene, S. Litkowski, H. Gredler, A. Lindem, P. Francois, C. Bowers. |
| Date: | June 2018 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8405 |
|
This document defines a standard algorithm to temporarily postpone or"back off" link-state IGP Shortest Path First (SPF) computations.This reduces the computational load and churn on IGP nodes when multiple temporally close network events trigger multiple SPF computations.
Having one standard algorithm improves interoperability by reducing the probability and/or duration of transient forwarding loops during the IGP convergence when the IGP reacts to multiple temporally closeIGP events. |
|
| |
| RFC 8408 | Conveying Path Setup Type in PCE Communication Protocol (PCEP) Messages |
| |
| Authors: | S. Sivabalan, J. Tantsura, I. Minei, R. Varga, J. Hardwick. |
| Date: | July 2018 |
| Formats: | txt html json |
| Updated by: | RFC 8664 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8408 |
|
A Path Computation Element (PCE) can compute Traffic Engineering (TE) paths through a network; these paths are subject to various constraints. Currently, TE paths are Label Switched Paths (LSPs) that are set up using the RSVP-TE signaling protocol. However, otherTE path setup methods are possible within the PCE architecture. This document proposes an extension to the PCE Communication Protocol(PCEP) to allow support for different path setup methods over a givenPCEP session. |
|
| |
| RFC 8410 | Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure |
| |
| Authors: | S. Josefsson, J. Schaad. |
| Date: | August 2018 |
| Formats: | txt html json |
| Updated by: | RFC 9295 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8410 |
|
This document specifies algorithm identifiers and ASN.1 encoding formats for elliptic curve constructs using the curve25519 and curve448 curves. The signature algorithms covered are Ed25519 andEd448. The key agreement algorithms covered are X25519 and X448.The encoding for public key, private key, and Edwards-curve DigitalSignature Algorithm (EdDSA) structures is provided. |
|
| |
| RFC 8412 | Software Inventory Message and Attributes (SWIMA) for PA-TNC |
| |
| Authors: | C. Schmidt, D. Haynes, C. Coffin, D. Waltermire, J. Fitzgerald-McKay. |
| Date: | July 2018 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8412 |
|
This document extends "PA-TNC: A Posture Attribute (PA) ProtocolCompatible with Trusted Network Connect (TNC)" (RFC 5792) by providing specific attributes and message exchanges to allow endpoints to report their installed software inventory information to a NEA Server, as defined in "Network Endpoint Assessment (NEA):Overview and Requirements" (RFC 5209). |
|
| |
| RFC 8414 | OAuth 2.0 Authorization Server Metadata |
| |
| Authors: | M. Jones, N. Sakimura, J. Bradley. |
| Date: | June 2018 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8414 |
|
This specification defines a metadata format that an OAuth 2.0 client can use to obtain the information needed to interact with anOAuth 2.0 authorization server, including its endpoint locations and authorization server capabilities. |
|
| |
| RFC 8415 | Dynamic Host Configuration Protocol for IPv6 (DHCPv6) |
| |
| Authors: | T. Mrugalski, M. Siodelski, B. Volz, A. Yourtchenko, M. Richardson, S. Jiang, T. Lemon, T. Winters. |
| Date: | November 2018 |
| Formats: | txt html json |
| Obsoletes: | RFC 3315, RFC 3633, RFC 3736, RFC 4242, RFC 7083, RFC 7283, RFC 7550 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8415 |
|
This document describes the Dynamic Host Configuration Protocol forIPv6 (DHCPv6): an extensible mechanism for configuring nodes with network configuration parameters, IP addresses, and prefixes.Parameters can be provided statelessly, or in combination with stateful assignment of one or more IPv6 addresses and/or IPv6 prefixes. DHCPv6 can operate either in place of or in addition to stateless address autoconfiguration (SLAAC).
This document updates the text from RFC 3315 (the original DHCPv6 specification) and incorporates prefix delegation (RFC 3633), stateless DHCPv6 (RFC 3736), an option to specify an upper bound for how long a client should wait before refreshing information (RFC4242), a mechanism for throttling DHCPv6 clients when DHCPv6 service is not available (RFC 7083), and relay agent handling of unknown messages (RFC 7283). In addition, this document clarifies the interactions between models of operation (RFC 7550). As such, this document obsoletes RFC 3315, RFC 3633, RFC 3736, RFC 4242, RFC 7083,RFC 7283, and RFC 7550. |
|
| |
| RFC 8416 | Simplified Local Internet Number Resource Management with the RPKI (SLURM) |
| |
| Authors: | D. Ma, D. Mandelberg, T. Bruijnzeels. |
| Date: | August 2018 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8416 |
|
The Resource Public Key Infrastructure (RPKI) is a global authorization infrastructure that allows the holder of InternetNumber Resources (INRs) to make verifiable statements about those resources. Network operators, e.g., Internet Service Providers(ISPs), can use the RPKI to validate BGP route origin assertions.ISPs can also use the RPKI to validate the path of a BGP route.However, ISPs may want to establish a local view of exceptions to theRPKI data in the form of local filters and additions. The mechanisms described in this document provide a simple way to enable INR holders to establish a local, customized view of the RPKI, overriding globalRPKI repository data as needed. |
|
| |
| RFC 8417 | Security Event Token (SET) |
| |
| Authors: | P. Hunt, Ed., M. Jones, W. Denniss, M. Ansari. |
| Date: | July 2018 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8417 |
|
This specification defines the Security Event Token (SET) data structure. A SET describes statements of fact from the perspective of an issuer about a subject. These statements of fact represent an event that occurred directly to or about a security subject, for example, a statement about the issuance or revocation of a token on behalf of a subject. This specification is intended to enable representing security- and identity-related events. A SET is a JSONWeb Token (JWT), which can be optionally signed and/or encrypted.SETs can be distributed via protocols such as HTTP. |
|
| |
| RFC 8418 | Use of the Elliptic Curve Diffie-Hellman Key Agreement Algorithm with X25519 and X448 in the Cryptographic Message Syntax (CMS) |
| |
| Authors: | R. Housley. |
| Date: | August 2018 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8418 |
|
This document describes the conventions for using the Elliptic CurveDiffie-Hellman (ECDH) key agreement algorithm with curve25519 and curve448 in the Cryptographic Message Syntax (CMS). |
|
| |
| RFC 8419 | Use of Edwards-Curve Digital Signature Algorithm (EdDSA) Signatures in the Cryptographic Message Syntax (CMS) |
| |
| Authors: | R. Housley. |
| Date: | August 2018 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8419 |
|
This document specifies the conventions for using the Edwards-curveDigital Signature Algorithm (EdDSA) for curve25519 and curve448 in the Cryptographic Message Syntax (CMS). For each curve, EdDSA defines the PureEdDSA and HashEdDSA modes. However, the HashEdDSA mode is not used with the CMS. In addition, no context string is used with the CMS. |
|
| |
| RFC 8420 | Using the Edwards-Curve Digital Signature Algorithm (EdDSA) in the Internet Key Exchange Protocol Version 2 (IKEv2) |
| |
| Authors: | Y. Nir. |
| Date: | August 2018 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8420 |
|
This document describes the use of the Edwards-curve DigitalSignature Algorithm (EdDSA) in the Internet Key Exchange ProtocolVersion 2 (IKEv2). |
|
| |
| RFC 8422 | Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier |
| |
| Authors: | Y. Nir, S. Josefsson, M. Pegourie-Gonnard. |
| Date: | August 2018 |
| Formats: | txt json html |
| Obsoletes: | RFC 4492 |
| Updated by: | RFC 8996 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8422 |
|
This document describes key exchange algorithms based on EllipticCurve Cryptography (ECC) for the Transport Layer Security (TLS) protocol. In particular, it specifies the use of Ephemeral EllipticCurve Diffie-Hellman (ECDHE) key agreement in a TLS handshake and the use of the Elliptic Curve Digital Signature Algorithm (ECDSA) andEdwards-curve Digital Signature Algorithm (EdDSA) as authentication mechanisms.
This document obsoletes RFC 4492. |
|
| |
| RFC 8425 | IANA Considerations for IPv6 Neighbor Discovery Prefix Information Option Flags |
| |
|
|
The Prefix Information Option (PIO) in the IPv6 Neighbor DiscoveryRouter Advertisement message defines an 8-bit flag field; this field has two flags defined, and the remaining 6 bits are reserved(Reserved1). RFC 6275 defines a flag from this field without creating an IANA registry or updating RFC 4861. The purpose of this document is to create an IANA registry for the PIO flags. This document updates RFC 4861. |
|
| |
| RFC 8428 | Sensor Measurement Lists (SenML) |
| |
| Authors: | C. Jennings, Z. Shelby, J. Arkko, A. Keranen, C. Bormann. |
| Date: | August 2018 |
| Formats: | txt html json |
| Updated by: | RFC 9100 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8428 |
|
This specification defines a format for representing simple sensor measurements and device parameters in Sensor Measurement Lists(SenML). Representations are defined in JavaScript Object Notation(JSON), Concise Binary Object Representation (CBOR), ExtensibleMarkup Language (XML), and Efficient XML Interchange (EXI), which share the common SenML data model. A simple sensor, such as a temperature sensor, could use one of these media types in protocols such as HTTP or the Constrained Application Protocol (CoAP) to transport the measurements of the sensor or to be configured. |
|
| |
| RFC 8431 | A YANG Data Model for the Routing Information Base (RIB) |
| |
| Authors: | L. Wang, M. Chen, A. Dass, H. Ananthakrishnan, S. Kini, N. Bahadur. |
| Date: | September 2018 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8431 |
|
This document defines a YANG data model for the Routing InformationBase (RIB) that aligns with the Interface to the Routing System(I2RS) RIB information model. |
|
| |
| RFC 8434 | Requirements for Parallel NFS (pNFS) Layout Types |
| |
|
|
This document defines the requirements that individual Parallel NFS(pNFS) layout types need to meet in order to work within the pNFS framework as defined in RFC 5661. In so doing, this document aims to clearly distinguish between requirements for pNFS as a whole and those specifically directed to the pNFS file layout. The lack of a clear separation between the two sets of requirements has been troublesome for those specifying and evaluating new layout types. In this regard, this document updates RFC 5661. |
|
| |
| RFC 8435 | Parallel NFS (pNFS) Flexible File Layout |
| |
| Authors: | B. Halevy, T. Haynes. |
| Date: | August 2018 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8435 |
|
Parallel NFS (pNFS) allows a separation between the metadata (onto a metadata server) and data (onto a storage device) for a file. The flexible file layout type is defined in this document as an extension to pNFS that allows the use of storage devices that require only a limited degree of interaction with the metadata server and use already-existing protocols. Client-side mirroring is also added to provide replication of files. |
|
| |
| RFC 8436 | Update to IANA Registration Procedures for Pool 3 Values in the Differentiated Services Field Codepoints (DSCP) Registry |
| |
|
|
The Differentiated Services (Diffserv) architecture specifies use of the DS field in the IPv4 and IPv6 packet headers to carry one of 64 distinct differentiated services field codepoint (DSCP) values. TheInternet Assigned Numbers Authority (IANA) maintains a registry of assigned DSCP values.
This update to RFC 2474 changes the IANA registration policy for Pool3 of the registry (i.e., DSCP values of the form xxxx01) to StandardsAction, i.e., values are assigned through a Standards Track or BestCurrent Practice RFC. The update also removes permission for experimental and local use of the codepoints that form Pool 3 of theDSCP registry; Pool 2 Codepoints (i.e., DSCP values of the form xxxx11) remain available for these purposes. |
|
| |
| RFC 8437 | IMAP UNAUTHENTICATE Extension for Connection Reuse |
| |
|
|
This specification extends the Internet Message Access Protocol(IMAP) to allow an administrative client to reuse the same IMAP connection on behalf of multiple IMAP user identities. |
|
| |
| RFC 8438 | IMAP Extension for STATUS=SIZE |
| |
| Authors: | S. Bosch. |
| Date: | August 2018 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8438 |
|
This document adds a new capability called "STATUS=SIZE" to theInternet Message Access Protocol (IMAP). It allows retrieving the total storage size of a mailbox with a single STATUS command rather than retrieving and summing the sizes of all individual messages in that mailbox. |
|
| |
| RFC 8440 | IMAP4 Extension for Returning MYRIGHTS Information in Extended LIST |
| |
| Authors: | K. Murchison, B. Gondwana. |
| Date: | August 2018 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8440 |
|
This document defines an extension to the Internet Message AccessProtocol (IMAP) LIST command that allows the client to request the set of rights that the logged-in user has been granted on mailboxes, along with other information typically returned by the LIST command. |
|
| |
| RFC 8441 | Bootstrapping WebSockets with HTTP/2 |
| |
|
|
This document defines a mechanism for running the WebSocket Protocol(RFC 6455) over a single stream of an HTTP/2 connection. |
|
| |
| RFC 8442 | ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for TLS 1.2 and DTLS 1.2 |
| |
| Authors: | J. Mattsson, D. Migault. |
| Date: | September 2018 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8442 |
|
This document defines several new cipher suites for version 1.2 of the Transport Layer Security (TLS) protocol and version 1.2 of theDatagram Transport Layer Security (DTLS) protocol. These cipher suites are based on the Ephemeral Elliptic Curve Diffie-Hellman withPre-Shared Key (ECDHE_PSK) key exchange together with theAuthenticated Encryption with Associated Data (AEAD) algorithmsAES-GCM and AES-CCM. PSK provides light and efficient authentication, ECDHE provides forward secrecy, and AES-GCM andAES-CCM provide encryption and integrity protection. |
|
| |
| RFC 8443 | Personal Assertion Token (PASSporT) Extension for Resource Priority Authorization |
| |
| Authors: | R. Singh, M. Dolly, S. Das, A. Nguyen. |
| Date: | August 2018 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8443 |
|
This document extends the Personal Assertion Token (PASSporT) specification defined in RFC 8225 to allow the inclusion of cryptographically signed assertions of authorization for the values populated in the Session Initiation Protocol (SIP) 'Resource-Priority' header field, which is used for communications resource prioritization. |
|
| |
| RFC 8444 | OSPFv2 Extensions for Bit Index Explicit Replication (BIER) |
| |
| Authors: | P. Psenak, Ed., N. Kumar, IJ. Wijnands, A. Dolganow, T. Przygienda, J. Zhang, S. Aldrin. |
| Date: | November 2018 |
| Formats: | txt json html |
| Updated by: | RFC 9272 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8444 |
|
Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain multicast-related, per- flow state. BIER also does not require an explicit tree-building protocol for its operation. A multicast data packet enters a BIER domain at a Bit-Forwarding Ingress Router (BFIR) and leaves the BIER domain at one or more Bit-Forwarding Egress Routers (BFERs). TheBFIR adds a BIER packet header to the packet. The BIER packet header contains a BitString in which each bit represents exactly one BFER to forward the packet to. The set of BFERs to which the multicast packet needs to be forwarded is expressed by the set of bits in theBIER packet header.
This document describes the OSPF protocol extension (from RFC 2328) that is required for BIER with MPLS encapsulation (which is defined in RFC 8296). Support for other encapsulation types and the use of multiple encapsulation types are outside the scope of this document. |
|
| |
| RFC 8445 | Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal |
| |
|
|
This document describes a protocol for Network Address Translator(NAT) traversal for UDP-based communication. This protocol is calledInteractive Connectivity Establishment (ICE). ICE makes use of theSession Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN).
This document obsoletes RFC 5245. |
|
| |
| RFC 8446 | The Transport Layer Security (TLS) Protocol Version 1.3 |
| |
|
|
This document specifies version 1.3 of the Transport Layer Security(TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.
This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077,5246, and 6961. This document also specifies new requirements forTLS 1.2 implementations. |
|
| |
| RFC 8447 | IANA Registry Updates for TLS and DTLS |
| |
|
|
This document describes a number of changes to TLS and DTLS IANA registries that range from adding notes to the registry all the way to changing the registration policy. These changes were mostly motivated by WG review of the TLS- and DTLS-related registries undertaken as part of the TLS 1.3 development process.
This document updates the following RFCs: 3749, 5077, 4680, 5246,5705, 5878, 6520, and 7301. |
|
| |
| RFC 8449 | Record Size Limit Extension for TLS |
| |
|
|
An extension to Transport Layer Security (TLS) is defined that allows endpoints to negotiate the maximum size of protected records that each will send the other.
This replaces the maximum fragment length extension defined inRFC 6066. |
|
| |
| RFC 8450 | RTP Payload Format for VC-2 High Quality (HQ) Profile |
| |
| Authors: | J. Weaver. |
| Date: | October 2018 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8450 |
|
This memo describes an RTP payload format for the High Quality (HQ) profile of Society of Motion Picture and Television EngineersStandard ST 2042-1, known as VC-2. This document describes the transport of HQ Profile VC-2 in RTP packets and has applications for low-complexity, high-bandwidth streaming of both lossless and lossy compressed video.
The HQ profile of VC-2 is intended for low-latency video compression(with latency potentially on the order of lines of video) at high data rates (with compression ratios on the order of 2:1 or 4:1). |
|
| |
| RFC 8457 | IMAP "$Important" Keyword and "\Important" Special-Use Attribute |
| |
| Authors: | B. Leiba, Ed.. |
| Date: | September 2018 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8457 |
|
RFC 6154 created an IMAP special-use LIST extension and defined an initial set of attributes. This document defines a new attribute,"\Important", and establishes a new IANA registry for IMAP folder attributes, which include the attributes defined in RFCs 5258, 3501, and 6154. This document also defines a new IMAP keyword,"$Important", and registers it in the registry defined in RFC 5788. |
|
| |
| RFC 8460 | SMTP TLS Reporting |
| |
| Authors: | D. Margolis, A. Brotman, B. Ramakrishnan, J. Jones, M. Risher. |
| Date: | September 2018 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8460 |
|
A number of protocols exist for establishing encrypted channels between SMTP Mail Transfer Agents (MTAs), including STARTTLS, DNS-Based Authentication of Named Entities (DANE) TLSA, and MTA StrictTransport Security (MTA-STS). These protocols can fail due to misconfiguration or active attack, leading to undelivered messages or delivery over unencrypted or unauthenticated channels. This document describes a reporting mechanism and format by which sending systems can share statistics and specific information about potential failures with recipient domains. Recipient domains can then use this information to both detect potential attacks and diagnose unintentional misconfigurations. |
|
| |
| RFC 8461 | SMTP MTA Strict Transport Security (MTA-STS) |
| |
| Authors: | D. Margolis, M. Risher, B. Ramakrishnan, A. Brotman, J. Jones. |
| Date: | September 2018 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8461 |
|
SMTP MTA Strict Transport Security (MTA-STS) is a mechanism enabling mail service providers (SPs) to declare their ability to receiveTransport Layer Security (TLS) secure SMTP connections and to specify whether sending SMTP servers should refuse to deliver to MX hosts that do not offer TLS with a trusted server certificate. |
|
| |
| RFC 8463 | A New Cryptographic Signature Method for DomainKeys Identified Mail (DKIM) |
| |
|
|
This document adds a new signing algorithm, Ed25519-SHA256, to"DomainKeys Identified Mail (DKIM) Signatures" (RFC 6376). DKIM verifiers are required to implement this algorithm. |
|
| |
| RFC 8466 | A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service Delivery |
| |
| Authors: | B. Wen, G. Fioccola, Ed., C. Xie, L. Jalil. |
| Date: | October 2018 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8466 |
|
This document defines a YANG data model that can be used to configure a Layer 2 provider-provisioned VPN service. It is up to a management system to take this as an input and generate specific configuration models to configure the different network elements to deliver the service. How this configuration of network elements is done is out of scope for this document.
The YANG data model defined in this document includes support for point-to-point Virtual Private Wire Services (VPWSs) and multipointVirtual Private LAN Services (VPLSs) that use Pseudowires signaled using the Label Distribution Protocol (LDP) and the Border GatewayProtocol (BGP) as described in RFCs 4761 and 6624.
The YANG data model defined in this document conforms to the NetworkManagement Datastore Architecture defined in RFC 8342. |
|
| |
| RFC 8469 | Recommendation to Use the Ethernet Control Word |
| |
| Authors: | S. Bryant, A. Malis, I. Bagdonas. |
| Date: | November 2018 |
| Formats: | txt json html |
| Updates: | RFC 4448 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8469 |
|
The pseudowire (PW) encapsulation of Ethernet, as defined inRFC 4448, specifies that the use of the control word (CW) is optional. In the absence of the CW, an Ethernet PW packet can be misidentified as an IP packet by a label switching router (LSR).This may lead to the selection of the wrong equal-cost multipath(ECMP) path for the packet, leading in turn to the misordering of packets. This problem has become more serious due to the deployment of equipment with Ethernet Media Access Control (MAC) addresses that start with 0x4 or 0x6. The use of the Ethernet PW CW addresses this problem. This document RECOMMENDS the use of the Ethernet PW CW in all but exceptional circumstances.
This document updates RFC 4448. |
|
| |
| RFC 8470 | Using Early Data in HTTP |
| |
| Authors: | M. Thomson, M. Nottingham, W. Tarreau. |
| Date: | September 2018 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8470 |
|
Using TLS early data creates an exposure to the possibility of a replay attack. This document defines mechanisms that allow clients to communicate with servers about HTTP requests that are sent in early data. Techniques are described that use these mechanisms to mitigate the risk of replay. |
|
| |
| RFC 8471 | The Token Binding Protocol Version 1.0 |
| |
| Authors: | A. Popov, Ed., M. Nystroem, D. Balfanz, J. Hodges. |
| Date: | October 2018 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8471 |
|
This document specifies version 1.0 of the Token Binding protocol.The Token Binding protocol allows client/server applications to create long-lived, uniquely identifiable TLS bindings spanning multiple TLS sessions and connections. Applications are then enabled to cryptographically bind security tokens to the TLS layer, preventing token export and replay attacks. To protect privacy, theToken Binding identifiers are only conveyed over TLS and can be reset by the user at any time. |
|
| |
| RFC 8472 | Transport Layer Security (TLS) Extension for Token Binding Protocol Negotiation |
| |
| Authors: | A. Popov, Ed., M. Nystroem, D. Balfanz. |
| Date: | October 2018 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8472 |
|
This document specifies a Transport Layer Security (TLS) extension for the negotiation of Token Binding protocol version and key parameters. Negotiation of Token Binding in TLS 1.3 and later versions is beyond the scope of this document. |
|
| |
| RFC 8473 | Token Binding over HTTP |
| |
| Authors: | A. Popov, M. Nystroem, D. Balfanz, Ed., N. Harper, J. Hodges. |
| Date: | October 2018 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8473 |
|
This document describes a collection of mechanisms that allow HTTP servers to cryptographically bind security tokens (such as cookies and OAuth tokens) to TLS connections.
We describe both first-party and federated scenarios. In a first- party scenario, an HTTP server is able to cryptographically bind the security tokens that it issues to a client -- and that the client subsequently returns to the server -- to the TLS connection between the client and the server. Such bound security tokens are protected from misuse, since the server can generally detect if they are replayed inappropriately, e.g., over other TLS connections.
Federated Token Bindings, on the other hand, allow servers to cryptographically bind security tokens to a TLS connection that the client has with a different server than the one issuing the token.
This document is a companion document to "The Token Binding ProtocolVersion 1.0" (RFC 8471). |
|
| |
| RFC 8474 | IMAP Extension for Object Identifiers |
| |
|
|
This document updates RFC 3501 (IMAP4rev1) with persistent identifiers on mailboxes and messages to allow clients to more efficiently reuse cached data when resources have changed location on the server. |
|
| |
| RFC 8476 | Signaling Maximum SID Depth (MSD) Using OSPF |
| |
| Authors: | J. Tantsura, U. Chunduri, S. Aldrin, P. Psenak. |
| Date: | December 2018 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8476 |
|
This document defines a way for an Open Shortest Path First (OSPF) router to advertise multiple types of supported Maximum SID Depths(MSDs) at node and/or link granularity. Such advertisements allow entities (e.g., centralized controllers) to determine whether a particular Segment Identifier (SID) stack can be supported in a given network. This document only refers to the Signaling MSD as defined in RFC 8491, but it defines an encoding that can support other MSD types. Here, the term "OSPF" means both OSPFv2 and OSPFv3. |
|
| |
| RFC 8480 | 6TiSCH Operation Sublayer (6top) Protocol (6P) |
| |
| Authors: | Q. Wang, Ed., X. Vilajosana, T. Watteyne. |
| Date: | November 2018 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8480 |
|
This document defines the "IPv6 over the TSCH mode of IEEE 802.15.4e"(6TiSCH) Operation Sublayer (6top) Protocol (6P), which enables distributed scheduling in 6TiSCH networks. 6P allows neighbor nodes to add/delete Time-Slotted Channel Hopping (TSCH) cells to/on one another. 6P is part of the 6TiSCH Operation Sublayer (6top), the layer just above the IEEE Std 802.15.4 TSCH Medium Access Control layer. 6top is composed of one or more Scheduling Functions (SFs) and the 6top Protocol defined in this document. A 6top SF decides when to add/delete cells, and it triggers 6P Transactions. The definition of SFs is out of scope for this document; however, this document provides the requirements for an SF. |
|
| |
| RFC 8481 | Clarifications to BGP Origin Validation Based on Resource Public Key Infrastructure (RPKI) |
| |
|
|
Deployment of BGP origin validation based on Resource Public KeyInfrastructure (RPKI) is hampered by, among other things, vendor misimplementations in two critical areas: which routes are validated and whether policy is applied when not specified by configuration.This document is meant to clarify possible misunderstandings causing those misimplementations; it thus updates RFC 6811 by clarifying that all prefixes should have their validation state set and that policy must not be applied without operator configuration. |
|
| |
| RFC 8482 | Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY |
| |
|
|
The Domain Name System (DNS) specifies a query type (QTYPE) "ANY".The operator of an authoritative DNS server might choose not to respond to such queries for reasons of local policy, motivated by security, performance, or other reasons.
The DNS specification does not include specific guidance for the behavior of DNS servers or clients in this situation. This document aims to provide such guidance.
This document updates RFCs 1034 and 1035. |
|
| |
| RFC 8484 | DNS Queries over HTTPS (DoH) |
| |
| Authors: | P. Hoffman, P. McManus. |
| Date: | October 2018 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8484 |
|
This document defines a protocol for sending DNS queries and gettingDNS responses over HTTPS. Each DNS query-response pair is mapped into an HTTP exchange. |
|
| |
| RFC 8485 | Vectors of Trust |
| |
| Authors: | J. Richer, Ed., L. Johansson. |
| Date: | October 2018 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8485 |
|
This document defines a mechanism for describing and signaling several aspects of a digital identity transaction and its participants. These aspects are used to determine the amount of trust to be placed in that transaction. |
|
| |
| RFC 8486 | Ambisonics in an Ogg Opus Container |
| |
| Authors: | J. Skoglund, M. Graczyk. |
| Date: | October 2018 |
| Formats: | txt html json |
| Updates: | RFC 7845 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8486 |
|
This document defines an extension to the Opus audio codec to encapsulate coded Ambisonics using the Ogg format. It also contains updates to RFC 7845 to reflect necessary changes in the description of channel mapping families. |
|
| |
| RFC 8487 | Mtrace Version 2: Traceroute Facility for IP Multicast |
| |
| Authors: | H. Asaeda, K. Meyer, W. Lee, Ed.. |
| Date: | October 2018 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8487 |
|
This document describes the IP multicast traceroute facility, namedMtrace version 2 (Mtrace2). Unlike unicast traceroute, Mtrace2 requires special implementations on the part of routers. This specification describes the required functionality in multicast routers, as well as how an Mtrace2 client invokes a Query and receives a Reply. |
|
| |
| RFC 8489 | Session Traversal Utilities for NAT (STUN) |
| |
| Authors: | M. Petit-Huguenin, G. Salgueiro, J. Rosenberg, D. Wing, R. Mahy, P. Matthews. |
| Date: | February 2020 |
| Formats: | txt json html |
| Obsoletes: | RFC 5389 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8489 |
|
Session Traversal Utilities for NAT (STUN) is a protocol that serves as a tool for other protocols in dealing with NAT traversal. It can be used by an endpoint to determine the IP address and port allocated to it by a NAT. It can also be used to check connectivity between two endpoints and as a keep-alive protocol to maintain NAT bindings.STUN works with many existing NATs and does not require any special behavior from them.
STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution.
This document obsoletes RFC 5389. |
|
| |
| RFC 8490 | DNS Stateful Operations |
| |
| Authors: | R. Bellis, S. Cheshire, J. Dickinson, S. Dickinson, T. Lemon, T. Pusateri. |
| Date: | March 2019 |
| Formats: | txt json html |
| Updates: | RFC 1035, RFC 7766 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8490 |
|
This document defines a new DNS OPCODE for DNS Stateful Operations(DSO). DSO messages communicate operations within persistent stateful sessions using Type Length Value (TLV) syntax. Three TLVs are defined that manage session timeouts, termination, and encryption padding, and a framework is defined for extensions to enable new stateful operations. This document updates RFC 1035 by adding a newDNS header OPCODE that has both different message semantics and a new result code. This document updates RFC 7766 by redefining a session, providing new guidance on connection reuse, and providing a new mechanism for handling session idle timeouts. |
|
| |
| RFC 8491 | Signaling Maximum SID Depth (MSD) Using IS-IS |
| |
| Authors: | J. Tantsura, U. Chunduri, S. Aldrin, L. Ginsberg. |
| Date: | November 2018 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8491 |
|
This document defines a way for an Intermediate System toIntermediate System (IS-IS) router to advertise multiple types of supported Maximum SID Depths (MSDs) at node and/or link granularity.Such advertisements allow entities (e.g., centralized controllers) to determine whether a particular Segment ID (SID) stack can be supported in a given network. This document only defines one type ofMSD: Base MPLS Imposition. However, it defines an encoding that can support other MSD types. This document focuses on MSD use in a network that is Segment Routing (SR) enabled, but MSD may also be useful when SR is not enabled. |
|
| |
| RFC 8495 | Allocation Token Extension for the Extensible Provisioning Protocol (EPP) |
| |
| Authors: | J. Gould, K. Feher. |
| Date: | November 2018 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8495 |
|
This document describes an Extensible Provisioning Protocol (EPP) extension for including an Allocation Token in "query" and"transform" commands. The Allocation Token is used as a credential that authorizes a client to request the allocation of a specific object from the server using one of the EPP transform commands, including "create" and "transfer". |
|
| |
| RFC 8497 | Marking SIP Messages to Be Logged |
| |
| Authors: | P. Dawes, C. Arunachalam. |
| Date: | November 2018 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8497 |
|
SIP networks use signaling monitoring tools to diagnose user-reported problems and to perform regression testing if network or user agent(UA) software is upgraded. As networks grow and become interconnected, including connection via transit networks, it becomes impractical to predict the path that SIP signaling will take between user agents and therefore impractical to monitor SIP signaling end to end.
This document describes an indicator for the SIP protocol that can be used to mark signaling as being of interest to logging. Such marking will typically be applied as part of network testing controlled by the network operator and is not used in normal user agent signaling.Operators of all networks on the signaling path can agree to carry such marking end to end, including the originating and terminatingSIP user agents, even if a session originates and terminates in different networks. |
|
| |
| RFC 8500 | IS-IS Routing with Reverse Metric |
| |
| Authors: | N. Shen, S. Amante, M. Abrahamsson. |
| Date: | February 2019 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8500 |
|
This document describes a mechanism to allow IS-IS routing to quickly and accurately shift traffic away from either a point-to-point or multi-access LAN interface during network maintenance or other operational events. This is accomplished by signaling adjacent IS-IS neighbors with a higher reverse metric, i.e., the metric towards the signaling IS-IS router. |
|
| |
| RFC 8502 | L2L3 VPN Multicast MIB |
| |
| Authors: | Z. Zhang, H. Tsunoda. |
| Date: | December 2018 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8502 |
|
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 two MIB modules that will be used by other MIB modules for monitoring and/or configuring Layer 2 and Layer3 Virtual Private Networks that support multicast. |
|
| |
| RFC 8503 | BGP/MPLS Layer 3 VPN Multicast Management Information Base |
| |
| Authors: | H. Tsunoda. |
| Date: | December 2018 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8503 |
|
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 Multicast communication over IP Virtual Private Networks(VPNs) supported by the Multiprotocol Label Switching/Border GatewayProtocol (MPLS/BGP) on a Provider Edge (PE) router. |
|
| |
| RFC 8505 | Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery |
| |
|
|
This specification updates RFC 6775 -- the Low-Power WirelessPersonal Area Network (6LoWPAN) Neighbor Discovery specification -- to clarify the role of the protocol as a registration technique and simplify the registration operation in 6LoWPAN routers, as well as to provide enhancements to the registration capabilities and mobility detection for different network topologies, including the RoutingRegistrars performing routing for host routes and/or proxy NeighborDiscovery in a low-power network. |
|
| |
| RFC 8506 | Diameter Credit-Control Application |
| |
| Authors: | L. Bertz, Ed., D. Dolson, Ed., Y. Lifshitz, Ed.. |
| Date: | March 2019 |
| Formats: | txt html json |
| Obsoletes: | RFC 4006 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8506 |
|
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. The Diameter Credit-Control application as defined in this document obsoletes RFC 4006, and it must be supported by all new Diameter Credit-Control application implementations. |
|
| |
| RFC 8508 | IMAP REPLACE Extension |
| |
| Authors: | S. Brandt. |
| Date: | January 2019 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8508 |
|
This document defines an IMAP extension that can be used to replace an existing message in a message store with a new message. Message replacement is a common operation for clients that automatically save drafts or notes as a user composes them. |
|
| |
| RFC 8509 | A Root Key Trust Anchor Sentinel for DNSSEC |
| |
| Authors: | G. Huston, J. Damas, W. Kumari. |
| Date: | December 2018 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8509 |
|
The DNS Security Extensions (DNSSEC) were developed to provide origin authentication and integrity protection for DNS data by using digital signatures. These digital signatures can be verified by building a chain of trust starting from a trust anchor and proceeding down to a particular node in the DNS. This document specifies a mechanism that will allow an end user and third parties to determine the trusted key state for the root key of the resolvers that handle that user's DNS queries. Note that this method is only applicable for determining which keys are in the trust store for the root key. |
|
| |
| RFC 8510 | OSPF Link-Local Signaling (LLS) Extensions for Local Interface ID Advertisement |
| |
| Authors: | P. Psenak, Ed., K. Talaulikar, W. Henderickx, P. Pillay-Esnault. |
| Date: | January 2019 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8510 |
|
Every OSPF interface is assigned an Interface ID that uniquely identifies the interface on the router. In some cases, it is useful to know the assigned Interface ID on the remote side of the adjacency(Remote Interface ID).
This document describes the extensions to OSPF link-local signaling(LLS) to advertise the Local Interface ID. |
|
| |
| RFC 8512 | A YANG Module for Network Address Translation (NAT) and Network Prefix Translation (NPT) |
| |
| Authors: | M. Boucadair, Ed., S. Sivakumar, C. Jacquenet, S. Vinapamula, Q. Wu. |
| Date: | January 2019 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8512 |
|
This document defines a YANG module for the Network AddressTranslation (NAT) function.
Network Address Translation from IPv4 to IPv4 (NAT44), NetworkAddress and Protocol Translation from IPv6 Clients to IPv4 Servers(NAT64), customer-side translator (CLAT), Stateless IP/ICMPTranslation (SIIT), Explicit Address Mappings (EAM) for SIIT,IPv6-to-IPv6 Network Prefix Translation (NPTv6), and Destination NAT are covered in this document. |
|
| |
| RFC 8513 | A YANG Data Model for Dual-Stack Lite (DS-Lite) |
| |
| Authors: | M. Boucadair, C. Jacquenet, S. Sivakumar. |
| Date: | January 2019 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8513 |
|
This document defines a YANG module for the Dual-Stack Lite (DS-Lite)Address Family Transition Router (AFTR) and Basic Bridging BroadBand(B4) elements. |
|
| |
| RFC 8514 | Internet Message Access Protocol (IMAP) - SAVEDATE Extension |
| |
| Authors: | S. Bosch. |
| Date: | January 2019 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8514 |
|
This document adds a new capability called "SAVEDATE" to the InternetMessage Access Protocol (IMAP). It defines a new IMAP message attribute called "save date" that, unlike the existing "internal date" attribute, always indicates the moment at which the message was saved in its current mailbox. The SAVEDATE capability extends theFETCH command with the means to retrieve the save date attribute and extends the SEARCH command to allow using the save date attribute in searching criteria. |
|
| |
| RFC 8516 | "Too Many Requests" Response Code for the Constrained Application Protocol |
| |
| Authors: | A. Keranen. |
| Date: | January 2019 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8516 |
|
A Constrained Application Protocol (CoAP) server can experience temporary overload because one or more clients are sending requests to the server at a higher rate than the server is capable or willing to handle. This document defines a new CoAP response code for a server to indicate that a client should reduce the rate of requests. |
|
| |
| RFC 8518 | Selection of Loop-Free Alternates for Multi-Homed Prefixes |
| |
| Authors: | P. Sarkar, Ed., U. Chunduri, Ed., S. Hegde, J. Tantsura, H. Gredler. |
| Date: | March 2019 |
| Formats: | txt json html |
| Updates: | RFC 5286 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8518 |
|
Deployment experience gained from implementing algorithms to determine Loop-Free Alternates (LFAs) for multi-homed prefixes (MHPs) has revealed some avenues for potential improvement. This document provides explicit inequalities that can be used to evaluate neighbors as potential alternates for MHPs. It also provides detailed criteria for evaluating potential alternates for external prefixes advertised by OSPF ASBRs. This document updates Section 6 of RFC 5286 by expanding some of the routing aspects. |
|
| |
| RFC 8519 | YANG Data Model for Network Access Control Lists (ACLs) |
| |
| Authors: | M. Jethanandani, S. Agarwal, L. Huang, D. Blair. |
| Date: | March 2019 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8519 |
|
This document defines a data model for Access Control Lists (ACLs).An ACL is a user-ordered set of rules used to configure the forwarding behavior in a device. Each rule is used to find a match on a packet and define actions that will be performed on the packet. |
|
| |
| RFC 8520 | Manufacturer Usage Description Specification |
| |
| Authors: | E. Lear, R. Droms, D. Romascanu. |
| Date: | March 2019 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8520 |
|
This memo specifies a component-based architecture for ManufacturerUsage Descriptions (MUDs). The goal of MUD is to provide a means for end devices to signal to the network what sort of access and network functionality they require to properly function. The initial focus is on access control. Later work can delve into other aspects.
This memo specifies two YANG modules, IPv4 and IPv6 DHCP options, aLink Layer Discovery Protocol (LLDP) TLV, a URL, an X.509 certificate extension, and a means to sign and verify the descriptions. |
|
| |
| RFC 8525 | YANG Library |
| |
| Authors: | A. Bierman, M. Bjorklund, J. Schoenwaelder, K. Watsen, R. Wilton. |
| Date: | March 2019 |
| Formats: | txt json html |
| Obsoletes: | RFC 7895 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8525 |
|
This document describes a YANG library that provides information about the YANG modules, datastores, and datastore schemas used by a network management server. Simple caching mechanisms are provided to allow clients to minimize retrieval of this information. This version of the YANG library supports the Network Management DatastoreArchitecture (NMDA) by listing all datastores supported by a network management server and the schema that is used by each of these datastores.
This document obsoletes RFC 7895. |
|
| |
| RFC 8526 | NETCONF Extensions to Support the Network Management Datastore Architecture |
| |
| Authors: | M. Bjorklund, J. Schoenwaelder, P. Shafer, K. Watsen, R. Wilton. |
| Date: | March 2019 |
| Formats: | txt html json |
| Updates: | RFC 6241, RFC 7950 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8526 |
|
This document extends the Network Configuration Protocol (NETCONF) defined in RFC 6241 in order to support the Network ManagementDatastore Architecture (NMDA) defined in RFC 8342.
This document updates RFCs 6241 and 7950. The update to RFC 6241 adds new <get-data&rt; and <edit-data&rt; operations and augments existing<lock&rt;, <unlock&rt;, and <validate&rt; operations. The update to RFC 7950 requires the usage of the YANG library (described in RFC 8525) byNETCONF servers implementing the NMDA. |
|
| |
| RFC 8527 | RESTCONF Extensions to Support the Network Management Datastore Architecture |
| |
| Authors: | M. Bjorklund, J. Schoenwaelder, P. Shafer, K. Watsen, R. Wilton. |
| Date: | March 2019 |
| Formats: | txt html json |
| Updates: | RFC 8040 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8527 |
|
This document extends the RESTCONF protocol defined in RFC 8040 in order to support the Network Management Datastore Architecture (NMDA) defined in RFC 8342.
This document updates RFC 8040 by introducing new datastore resources, adding a new query parameter, and requiring the usage of the YANG library (described in RFC 8525) by RESTCONF servers implementing the NMDA. |
|
| |
| RFC 8528 | YANG Schema Mount |
| |
| Authors: | M. Bjorklund, L. Lhotka. |
| Date: | March 2019 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8528 |
|
This document defines a mechanism that adds the schema trees defined by a set of YANG modules onto a mount point defined in the schema tree in another YANG module. |
|
| |
| RFC 8529 | YANG Data Model for Network Instances |
| |
| Authors: | L. Berger, C. Hopps, A. Lindem, D. Bogdanovic, X. Liu. |
| Date: | March 2019 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8529 |
|
This document defines a network instance module. This module can be used to manage the virtual resource partitioning that may be present on a network device. Examples of common industry terms for virtual resource partitioning are VPN Routing and Forwarding (VRF) instances and Virtual Switch Instances (VSIs).
The YANG data model in this document conforms to the NetworkManagement Datastore Architecture (NMDA) defined in RFC 8342. |
|
| |
| RFC 8530 | YANG Model for Logical Network Elements |
| |
| Authors: | L. Berger, C. Hopps, A. Lindem, D. Bogdanovic, X. Liu. |
| Date: | March 2019 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8530 |
|
This document defines a logical network element (LNE) YANG module that is compliant with the Network Management Datastore Architecture(NMDA). This module can be used to manage the logical resource partitioning that may be present on a network device. Examples of common industry terms for logical resource partitioning are logical systems or logical routers. The YANG model in this document conforms with NMDA as defined in RFC 8342. |
|
| |
| RFC 8531 | Generic YANG Data Model for Connection-Oriented Operations, Administration, and Maintenance (OAM) Protocols |
| |
| Authors: | D. Kumar, Q. Wu, Z. Wang. |
| Date: | April 2019 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8531 |
|
This document presents a base YANG data model for connection-orientedOperations, Administration, and Maintenance (OAM) protocols. It provides a technology-independent abstraction of key OAM constructs for such protocols. The model presented here can be extended to include technology-specific details. This guarantees uniformity in the management of OAM protocols and provides support for nested OAM workflows (i.e., performing OAM functions at different levels through a unified interface).
The YANG data model in this document conforms to the NetworkManagement Datastore Architecture. |
|
| |
| RFC 8532 | Generic YANG Data Model for the Management of Operations, Administration, and Maintenance (OAM) Protocols That Use Connectionless Communications |
| |
| Authors: | D. Kumar, Z. Wang, Q. Wu, Ed., R. Rahman, S. Raghavan. |
| Date: | April 2019 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8532 |
|
This document presents a base YANG Data model for the management ofOperations, Administration, and Maintenance (OAM) protocols that use connectionless communications. The data model is defined using theYANG data modeling language, as specified in RFC 7950. It provides a technology-independent abstraction of key OAM constructs for OAM protocols that use connectionless communication. The base model presented here can be extended to include technology-specific details.
There are two key benefits of this approach: First, it leads to uniformity between OAM protocols. Second, it supports both nestedOAM workflows (i.e., performing OAM functions at the same level or different levels through a unified interface) as well as interactiveOAM workflows (i.e., performing OAM functions at the same level through a unified interface). |
|
| |
| RFC 8533 | A YANG Data Model for Retrieval Methods for the Management of Operations, Administration, and Maintenance (OAM) Protocols That Use Connectionless Communications |
| |
| Authors: | D. Kumar, M. Wang, Q. Wu, Ed., R. Rahman, S. Raghavan. |
| Date: | April 2019 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8533 |
|
This document presents a retrieval method YANG data model for connectionless Operations, Administration, and Maintenance (OAM) protocols. It provides technology-independent RPC operations for OAM protocols that use connectionless communication. The retrieval methods model herein presented can be extended to include technology- specific details. There are two key benefits of this approach:First, it leads to uniformity between OAM protocols. Second, it supports both nested OAM workflows (i.e., performing OAM functions at different or the same levels through a unified interface) as well as interactive OAM workflows (i.e., performing OAM functions at the same levels through a unified interface). |
|
| |
| RFC 8534 | Explicit Tracking with Wildcard Routes in Multicast VPN |
| |
|
|
The base Multicast VPN (MVPN) specifications (RFCs 6513 and 6514) provide procedures to allow a multicast ingress node to invoke"explicit tracking" for a multicast flow or set of flows, thus learning the egress nodes for that flow or set of flows. However, the specifications are not completely clear about how the explicit tracking procedures work in certain scenarios. This document provides the necessary clarifications. It also specifies a new, optimized explicit-tracking procedure. This new procedure allows an ingress node, by sending a single message, to request explicit tracking of each of a set of flows, where the set of flows is specified using a wildcard mechanism. This document updates RFCs6514, 6625, 7524, 7582, and 7900. |
|
| |
| RFC 8536 | The Time Zone Information Format (TZif) |
| |
| Authors: | A. Olson, P. Eggert, K. Murchison. |
| Date: | February 2019 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8536 |
|
This document specifies the Time Zone Information Format (TZif) for representing and exchanging time zone information, independent of any particular service or protocol. Two media types for this format are also defined. |
|
| |
| RFC 8537 | Updates to the Fast Reroute Procedures for Co-routed Associated Bidirectional Label Switched Paths (LSPs) |
| |
|
|
Resource Reservation Protocol (RSVP) association signaling can be used to bind two unidirectional Label Switched Paths (LSPs) into an associated bidirectional LSP. When an associated bidirectional LSP is co-routed, the reverse LSP follows the same path as its forwardLSP. This document updates the fast reroute procedures defined inRFC 4090 to support both single-sided and double-sided provisioned associated bidirectional LSPs. This document also updates the procedure for associating two reverse LSPs defined in RFC 7551 to support co-routed bidirectional LSPs. The fast reroute procedures can ensure that, for the co-routed LSPs, traffic flows on co-routed paths in the forward and reverse directions after a failure event. |
|
| |
| RFC 8538 | Notification Message Support for BGP Graceful Restart |
| |
| Authors: | K. Patel, R. Fernando, J. Scudder, J. Haas. |
| Date: | March 2019 |
| Formats: | txt json html |
| Updates: | RFC 4724 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8538 |
|
The BGP Graceful Restart mechanism defined in RFC 4724 limits the usage of BGP Graceful Restart to BGP messages other than BGPNOTIFICATION messages. This document updates RFC 4724 by defining an extension that permits the Graceful Restart procedures to be performed when the BGP speaker receives a BGP NOTIFICATION message or the Hold Time expires. This document also defines a new subcode forBGP Cease NOTIFICATION messages; this new subcode requests a full session restart instead of a Graceful Restart. |
|
| |
| RFC 8539 | Softwire Provisioning Using DHCPv4 over DHCPv6 |
| |
| Authors: | I. Farrer, Q. Sun, Y. Cui, L. Sun. |
| Date: | March 2019 |
| Formats: | txt json html |
| Updates: | RFC 7598 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8539 |
|
DHCPv4 over DHCPv6 (RFC 7341) is a mechanism for dynamically configuring IPv4 for use as an over-the-top service in an IPv6-only network. Softwires are an example of such a service. For DHCPv4 over DHCPv6 (DHCP 4o6) to function with some IPv4-over-IPv6 softwire mechanisms and deployment scenarios (e.g., RFC 7596 or RFC 7597), the operator needs to know the IPv6 address that the client will use as the source of an IPv4-in-IPv6 softwire tunnel. This address, in conjunction with the client's IPv4 address, and (in some deployments) the Port Set ID are used to create a binding table entry in the operator's softwire tunnel concentrator. This memo defines a DHCPv6 option to convey IPv6 parameters for establishing the softwire tunnel and a DHCPv4 option (to be used only with DHCP 4o6) to communicate the source tunnel IPv6 address between the DHCP 4o6 client and server. It is designed to work in conjunction with the IPv4 address allocation process.
"DHCPv6 Options for Configuration of Softwire Address and Port-MappedClients" (RFC 7598) describes a deterministic DHCPv6-based mechanism for provisioning softwires. This document updates RFC 7598, allowingOPTION_S46_BR (90) to be enumerated in the DHCPv6 client's OptionRequest Option (ORO) request and to appear directly within subsequent messages sent by the DHCPv6 server. |
|
| |
| RFC 8542 | A YANG Data Model for Fabric Topology in Data-Center Networks |
| |
| Authors: | Y. Zhuang, D. Shi, R. Gu, H. Ananthakrishnan. |
| Date: | March 2019 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8542 |
|
This document defines a YANG data model for fabric topology in data- center networks and represents one possible view of the data-center fabric. This document focuses on the data model only and does not endorse any kind of network design that could be based on the abovementioned model. |
|
| |
| RFC 8543 | Extensible Provisioning Protocol (EPP) Organization Mapping |
| |
| Authors: | L. Zhou, N. Kong, J. Yao, J. Gould, G. Zhou. |
| Date: | March 2019 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8543 |
|
This document describes an Extensible Provisioning Protocol (EPP) mapping for provisioning and management of organization objects stored in a shared central repository. |
|
| |
| RFC 8544 | Organization Extension for the Extensible Provisioning Protocol (EPP) |
| |
| Authors: | L. Zhou, N. Kong, J. Wei, J. Yao, J. Gould. |
| Date: | April 2019 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8544 |
|
This document describes an extension to Extensible ProvisioningProtocol (EPP) object mappings that is designed to support assigning an organization to any existing object (domain, host, contact) as well as any future objects. |
|
| |
| RFC 8545 | Well-Known Port Assignments for the One-Way Active Measurement Protocol (OWAMP) and the Two-Way Active Measurement Protocol (TWAMP) |
| |
|
|
This memo explains the motivation and describes the reassignment of well-known ports for the One-Way Active Measurement Protocol (OWAMP) and the Two-Way Active Measurement Protocol (TWAMP) for control and measurement. It also clarifies the meaning and composition of theseStandards Track protocol names for the industry.
This memo updates RFCs 4656 and 5357, in terms of the UDP well-known port assignments, and it clarifies the complete OWAMP and TWAMP protocol composition for the industry. |
|
| |
| RFC 8549 | Export of BGP Community Information in IP Flow Information Export (IPFIX) |
| |
| Authors: | Z. Li, R. Gu, J. Dong. |
| Date: | April 2019 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8549 |
|
By introducing new Information Elements (IEs), this document extends the existing BGP-related IEs to enable IP Flow Information Export(IPFIX) to export BGP community information, including the BGPStandard Communities defined in RFC 1997, BGP Extended Communities defined in RFC 4360, and BGP Large Communities defined in RFC 8092.According to the network operator's BGP community planning, network traffic information can then be accumulated and analyzed at the BGP community granularity, which represents the traffic of different kinds of customers, services, or geographical regions. Network traffic information at the BGP community granularity is useful for network traffic analysis and engineering. |
|
| |
| RFC 8550 | Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Certificate Handling |
| |
| Authors: | J. Schaad, B. Ramsdell, S. Turner. |
| Date: | April 2019 |
| Formats: | txt html json |
| Obsoletes: | RFC 5750 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8550 |
|
This document specifies conventions for X.509 certificate usage bySecure/Multipurpose Internet Mail Extensions (S/MIME) v4.0 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 5280("Internet X.509 Public Key Infrastructure Certificate andCertificate Revocation List (CRL) Profile"). S/MIME agents must meet the certificate-processing requirements in this document as well as those in RFC 5280. This document obsoletes RFC 5750. |
|
| |
| RFC 8551 | Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification |
| |
| Authors: | J. Schaad, B. Ramsdell, S. Turner. |
| Date: | April 2019 |
| Formats: | txt html json |
| Obsoletes: | RFC 5751 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8551 |
|
This document defines Secure/Multipurpose Internet Mail Extensions(S/MIME) version 4.0. 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 5751. |
|
| |
| RFC 8555 | Automatic Certificate Management Environment (ACME) |
| |
| Authors: | R. Barnes, J. Hoffman-Andrews, D. McCarney, J. Kasten. |
| Date: | March 2019 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8555 |
|
Public Key Infrastructure using X.509 (PKIX) certificates are used for a number of purposes, the most significant of which is the authentication of domain names. Thus, certification authorities(CAs) in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate. As of this writing, this verification is done through a collection of ad hoc mechanisms. This document describes a protocol that a CA and an applicant can use to automate the process of verification and certificate issuance. The protocol also provides facilities for other certificate management functions, such as certificate revocation. |
|
| |
| RFC 8556 | Multicast VPN Using Bit Index Explicit Replication (BIER) |
| |
| Authors: | E. Rosen, Ed., M. Sivakumar, T. Przygienda, S. Aldrin, A. Dolganow. |
| Date: | April 2019 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8556 |
|
The Multicast Virtual Private Network (MVPN) specifications require the use of multicast tunnels ("P-tunnels") that traverse a service provider's backbone network. The P-tunnels are used for carrying multicast traffic across the backbone. A variety of P-tunnel types are supported. Bit Index Explicit Replication (BIER) is a new architecture that provides optimal multicast forwarding through a"multicast domain", without requiring intermediate routers to maintain any per-flow state or to engage in an explicit tree-building protocol. This document specifies the protocol and procedures that allow MVPN to use BIER as the method of carrying multicast traffic over a service provider's backbone network. |
|
| |
| RFC 8559 | Dynamic Authorization Proxying in the Remote Authentication Dial-In User Service (RADIUS) Protocol |
| |
|
|
RFC 5176 defines Change-of-Authorization (CoA) and Disconnect Message(DM) behavior for RADIUS. RFC 5176 also suggests that proxying these messages is possible, but it does not provide guidance as to how that is done. This specification updates RFC 5176 to correct that omission for scenarios where networks use realm-based proxying as defined in RFC 7542. This specification also updates RFC 5580 to allow the Operator-Name attribute in CoA-Request and Disconnect-Request packets. |
|
| |
| RFC 8560 | Seamless Integration of Ethernet VPN (EVPN) with Virtual Private LAN Service (VPLS) and Their Provider Backbone Bridge (PBB) Equivalents |
| |
| Authors: | A. Sajassi, Ed., S. Salam, N. Del Regno, J. Rabadan. |
| Date: | May 2019 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8560 |
|
This document specifies mechanisms for backward compatibility ofEthernet VPN (EVPN) and Provider Backbone Bridge Ethernet VPN(PBB-EVPN) solutions with Virtual Private LAN Service (VPLS) andProvider Backbone Bridge VPLS (PBB-VPLS) solutions. It also provides mechanisms for the seamless integration of these two technologies in the same MPLS/IP network on a per-VPN-instance basis. Implementation of this document enables service providers to introduce EVPN/PBB-EVPNProvider Edges (PEs) in their brownfield deployments of VPLS/PBB-VPLS networks. This document specifies the control-plane and forwarding behavior needed for the auto-discovery of the following: 1) a VPN instance, 2) multicast and unicast operation, and 3) a Media AccessControl (MAC) mobility operation. This enables seamless integration between EVPN and VPLS PEs as well as between PBB-VPLS and PBB-EVPNPEs. |
|
| |
| RFC 8561 | A YANG Data Model for Microwave Radio Link |
| |
| Authors: | J. Ahlberg, M. Ye, X. Li, D. Spreafico, M. Vaupotic. |
| Date: | June 2019 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8561 |
|
This document defines a YANG data model for control and management of radio link interfaces and their connectivity to packet (typicallyEthernet) interfaces in a microwave/millimeter wave node. The data nodes for management of the interface protection functionality is broken out into a separate and generic YANG data model in order to make it available for other interface types as well. |
|
| |
| RFC 8562 | Bidirectional Forwarding Detection (BFD) for Multipoint Networks |
| |
| Authors: | D. Katz, D. Ward, S. Pallagatti, Ed., G. Mirsky, Ed.. |
| Date: | April 2019 |
| Formats: | txt json html |
| Updates: | RFC 5880 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8562 |
|
This document describes extensions to the Bidirectional ForwardingDetection (BFD) protocol for its use in multipoint and multicast networks.
This document updates RFC 5880. |
|
| |
| RFC 8563 | Bidirectional Forwarding Detection (BFD) Multipoint Active Tails |
| |
| Authors: | D. Katz, D. Ward, S. Pallagatti, Ed., G. Mirsky, Ed.. |
| Date: | April 2019 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8563 |
|
This document describes active tail extensions to the BidirectionalForwarding Detection (BFD) protocol for multipoint networks. |
|
| |
| RFC 8564 | Support of Point-to-Multipoint Bidirectional Forwarding Detection (BFD) in Transparent Interconnection of Lots of Links (TRILL) |
| |
|
|
Point-to-multipoint (P2MP) Bidirectional Forwarding Detection (BFD) is designed to verify multipoint connectivity. This document specifies the support of P2MP BFD in Transparent Interconnection ofLots of Links (TRILL). Similar to TRILL point-to-point BFD, BFDControl packets in TRILL P2MP BFD are transmitted using RBridgeChannel messages. This document updates RFCs 7175 and 7177. |
|
| |
| RFC 8570 | IS-IS Traffic Engineering (TE) Metric Extensions |
| |
| Authors: | L. Ginsberg, Ed., S. Previdi, Ed., S. Giacalone, D. Ward, J. Drake, Q. Wu. |
| Date: | March 2019 |
| Formats: | txt html json |
| Obsoletes: | RFC 7810 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8570 |
|
In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network- performance criteria (e.g., latency) are becoming as critical to data-path selection as other metrics.
This document describes extensions to IS-IS Traffic EngineeringExtensions (RFC 5305). These extensions provide a way to distribute and collect network-performance information in a scalable fashion.The information distributed using IS-IS TE Metric Extensions can then be used to make path-selection decisions based on network performance.
Note that this document only covers the mechanisms with which network-performance information is distributed. The mechanisms for measuring network performance or acting on that information, once distributed, are outside the scope of this document.
This document obsoletes RFC 7810. |
|
| |
| RFC 8571 | BGP - Link State (BGP-LS) Advertisement of IGP Traffic Engineering Performance Metric Extensions |
| |
| Authors: | L. Ginsberg, Ed., S. Previdi, Q. Wu, J. Tantsura, C. Filsfils. |
| Date: | March 2019 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8571 |
|
This document defines new BGP - Link State (BGP-LS) TLVs in order to carry the IGP Traffic Engineering Metric Extensions defined in theIS-IS and OSPF protocols. |
|
| |
| RFC 8572 | Secure Zero Touch Provisioning (SZTP) |
| |
| Authors: | K. Watsen, I. Farrer, M. Abrahamsson. |
| Date: | April 2019 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8572 |
|
This document presents a technique to securely provision a networking device when it is booting in a factory-default state. Variations in the solution enable it to be used on both public and private networks. The provisioning steps are able to update the boot image, commit an initial configuration, and execute arbitrary scripts to address auxiliary needs. The updated device is subsequently able to establish secure connections with other systems. For instance, a device may establish NETCONF (RFC 6241) and/or RESTCONF (RFC 8040) connections with deployment-specific network management systems. |
|
| |
| RFC 8573 | Message Authentication Code for the Network Time Protocol |
| |
|
|
The Network Time Protocol (NTP), as described in RFC 5905, states that NTP packets should be authenticated by appending NTP data to a128-bit key and hashing the result with MD5 to obtain a 128-bit tag.This document deprecates MD5-based authentication, which is considered too weak, and recommends the use of AES-CMAC as described in RFC 4493 as a replacement. |
|
| |
| RFC 8575 | YANG Data Model for the Precision Time Protocol (PTP) |
| |
| Authors: | Y. Jiang, Ed., X. Liu, J. Xu, R. Cummings, Ed.. |
| Date: | May 2019 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8575 |
|
This document defines a YANG data model for the configuration of devices and clocks using the Precision Time Protocol (PTP) as specified in IEEE Std 1588-2008. It also defines the retrieval of the configuration information, the data sets and the running states of PTP clocks. The YANG module in this document conforms to theNetwork Management Datastore Architecture (NMDA). |
|
| |
| RFC 8577 | Signaling RSVP-TE Tunnels on a Shared MPLS Forwarding Plane |
| |
| Authors: | H. Sitaraman, V. Beeram, T. Parikh, T. Saad. |
| Date: | April 2019 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8577 |
|
As the scale of MPLS RSVP-TE networks has grown, the number of LabelSwitched Paths (LSPs) supported by individual network elements has increased. Various implementation recommendations have been proposed to manage the resulting increase in the amount of control-plane state information.
However, those changes have had no effect on the number of labels that a transit Label Switching Router (LSR) has to support in the forwarding plane. That number is governed by the number of LSPs transiting or terminated at the LSR and is directly related to the total LSP state in the control plane.
This document defines a mechanism to prevent the maximum size of the label space limit on an LSR from being a constraint to control-plane scaling on that node. It introduces the notion of preinstalled'per-TE link labels' that can be shared by MPLS RSVP-TE LSPs that traverse these TE links. This approach significantly reduces the forwarding-plane state required to support a large number of LSPs.This couples the feature benefits of the RSVP-TE control plane with the simplicity of the Segment Routing (SR) MPLS forwarding plane. |
|
| |
| RFC 8579 | Sieve Email Filtering: Delivering to Special-Use Mailboxes |
| |
| Authors: | S. Bosch. |
| Date: | May 2019 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8579 |
|
The SPECIAL-USE capability of the IMAP protocol (RFC 6154) allows clients to identify special-use mailboxes, e.g., where draft or sent messages should be put. This simplifies client configuration. In contrast, the Sieve mail filtering language (RFC 5228) currently has no such capability. This memo defines a Sieve extension that fills this gap: it adds a test for checking whether a special-use attribute is assigned for a particular mailbox or any mailbox, and it adds the ability to file messages into a mailbox identified solely by a special-use attribute. |
|
| |
| RFC 8580 | Sieve Extension: File Carbon Copy (FCC) |
| |
|
|
The Sieve email filtering language provides a number of action commands, some of which can generate additional messages on behalf of the user. This document defines an extension to such commands to allow a copy of any generated message to be filed into a target mailbox.
This document updates RFCs 5230 and 5435 by adding a new tagged argument to the Vacation and Notify actions, respectively. |
|
| |
| RFC 8581 | Diameter Agent Overload and the Peer Overload Report |
| |
|
|
This specification documents an extension to the Diameter OverloadIndication Conveyance (DOIC), a base solution for Diameter overload defined in RFC 7683. The extension defines the Peer Overload report type. The initial use case for the peer report is the handling of occurrences of overload of a Diameter Agent. |
|
| |
| RFC 8582 | Diameter Overload Rate Control |
| |
| Authors: | S. Donovan, Ed., E. Noel. |
| Date: | August 2019 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8582 |
|
This specification documents an extension to the Diameter OverloadIndication Conveyance (DOIC) base solution, which is defined in RFC7683. This extension adds a new overload-control abatement algorithm. This abatement algorithm allows for a DOIC reporting node to specify a maximum rate at which a DOIC reacting node sendsDiameter requests to the DOIC reporting node. |
|
| |
| RFC 8583 | Diameter Load Information Conveyance |
| |
| Authors: | B. Campbell, S. Donovan, Ed., JJ. Trottin. |
| Date: | August 2019 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8583 |
|
RFC 7068 describes requirements for Overload Control in Diameter.This includes a requirement to allow Diameter nodes to send "load" information, even when the node is not overloaded. The base solution defined in RFC 7683 (Diameter Overload Information Conveyance (DOIC)) describes a mechanism meeting most of the requirements but does not currently include the ability to send load information. This document defines a mechanism for the conveying of Diameter load information. |
|
| |
| RFC 8584 | Framework for Ethernet VPN Designated Forwarder Election Extensibility |
| |
| Authors: | J. Rabadan, Ed., S. Mohanty, Ed., A. Sajassi, J. Drake, K. Nagaraj, S. Sathappan. |
| Date: | April 2019 |
| Formats: | txt html json |
| Updates: | RFC 7432 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8584 |
|
An alternative to the default Designated Forwarder (DF) selection algorithm in Ethernet VPNs (EVPNs) is defined. The DF is theProvider Edge (PE) router responsible for sending Broadcast, UnknownUnicast, and Multicast (BUM) traffic to a multihomed Customer Edge(CE) device on a given VLAN on a particular Ethernet Segment (ES).In addition, the ability to influence the DF election result for aVLAN based on the state of the associated Attachment Circuit (AC) is specified. This document clarifies the DF election Finite StateMachine in EVPN services. Therefore, it updates the EVPN specification (RFC 7432). |
|
| |
| RFC 8586 | Loop Detection in Content Delivery Networks (CDNs) |
| |
| Authors: | S. Ludin, M. Nottingham, N. Sullivan. |
| Date: | April 2019 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8586 |
|
This document defines the CDN-Loop request header field for HTTP.CDN-Loop addresses an operational need that occurs when an HTTP request is intentionally forwarded between Content Delivery Networks(CDNs), but is then accidentally or maliciously re-routed back into the original CDN causing a non-terminating loop. The new header field can be used to identify the error and terminate the loop. |
|
| |
| RFC 8587 | NFS Version 4.0 Trunking Update |
| |
|
|
In NFS version 4.0, the fs_locations attribute informs clients about alternate locations of file systems. An NFS version 4.0 client can use this information to handle migration and replication of server file systems. This document describes how an NFS version 4.0 client can also use this information to discover an NFS version 4.0 server's trunking capabilities. This document updates RFC 7530. |
|
| |
| RFC 8588 | Personal Assertion Token (PaSSporT) Extension for Signature-based Handling of Asserted information using toKENs (SHAKEN) |
| |
| Authors: | C. Wendt, M. Barnes. |
| Date: | May 2019 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8588 |
|
This document extends the Personal Assertion Token (PASSporT), which is a token object that conveys cryptographically signed information about the participants involved in communications. The extension is defined based on the "Signature-based Handling of Asserted information using toKENs (SHAKEN)" specification by the ATIS/SIPForum IP-NNI Task Group. It provides both (1) a specific set of levels of confidence in the correctness of the originating identity of a call originated in a SIP-based telephone network as well as (2) an identifier that allows the Service Provider (SP) to uniquely identify the origin of the call within its network. |
|
| |
| RFC 8590 | Change Poll Extension for the Extensible Provisioning Protocol (EPP) |
| |
| Authors: | J. Gould, K. Feher. |
| Date: | May 2019 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8590 |
|
This document describes an Extensible Provisioning Protocol (EPP) extension for notifying clients of operations on client-sponsored objects that were not initiated by the client through EPP. These operations may include contractual or policy requirements including, but not limited to, regular batch processes, customer support actions, Uniform Domain-Name Dispute-Resolution Policy (UDRP) orUniform Rapid Suspension (URS) actions, court-directed actions, and bulk updates based on customer requests. Since the client is not directly involved or knowledgable of these operations, the extension is used along with an EPP object mapping to provide the resulting state of the postoperation object, and optionally a preoperation object, with the operation metadata of what, when, who, and why. |
|
| |
| RFC 8591 | SIP-Based Messaging with S/MIME |
| |
|
|
Mobile messaging applications used with the Session InitiationProtocol (SIP) commonly use some combination of the SIP MESSAGE method and the Message Session Relay Protocol (MSRP). While these provide mechanisms for hop-by-hop security, neither natively provides end-to-end protection. This document offers guidance on how to provide end-to-end authentication, integrity protection, and confidentiality using the Secure/Multipurpose Internet MailExtensions (S/MIME). It updates and provides clarifications for RFCs3261, 3428, and 4975. |
|
| |
| RFC 8595 | An MPLS-Based Forwarding Plane for Service Function Chaining |
| |
| Authors: | A. Farrel, S. Bryant, J. Drake. |
| Date: | June 2019 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8595 |
|
This document describes how Service Function Chaining (SFC) can be achieved in an MPLS network by means of a logical representation of the Network Service Header (NSH) in an MPLS label stack. That is, the NSH is not used, but the fields of the NSH are mapped to fields in the MPLS label stack. This approach does not deprecate or replace the NSH, but it acknowledges that there may be a need for an interim deployment of SFC functionality in brownfield networks. |
|
| |
| RFC 8598 | Split DNS Configuration for the Internet Key Exchange Protocol Version 2 (IKEv2) |
| |
| Authors: | T. Pauly, P. Wouters. |
| Date: | May 2019 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8598 |
|
This document defines two Configuration Payload Attribute Types(INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA) for the Internet KeyExchange Protocol version 2 (IKEv2). These payloads add support for private (internal-only) DNS domains. These domains are intended to be resolved using non-public DNS servers that are only reachable through the IPsec connection. DNS resolution for other domains remains unchanged. These Configuration Payloads only apply to split- tunnel configurations. |
|
| |
| RFC 8599 | Push Notification with the Session Initiation Protocol (SIP) |
| |
| Authors: | C. Holmberg, M. Arnold. |
| Date: | May 2019 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8599 |
|
This document describes how a Push Notification Service (PNS) can be used to wake a suspended Session Initiation Protocol (SIP) User Agent(UA) with push notifications, and it also describes how the UA can send binding-refresh REGISTER requests and receive incoming SIP requests in an environment in which the UA may be suspended. The document defines new SIP URI parameters to exchange PNS information between the UA and the SIP entity that will then request that push notifications be sent to the UA. It also defines the parameters to trigger such push notification requests. The document also defines new feature-capability indicators that can be used to indicate support of this mechanism. |
|
| |
| RFC 8600 | Using Extensible Messaging and Presence Protocol (XMPP) for Security Information Exchange |
| |
| Authors: | N. Cam-Winget, Ed., S. Appala, S. Pope, P. Saint-Andre. |
| Date: | June 2019 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8600 |
|
This document describes how to use the Extensible Messaging andPresence Protocol (XMPP) to collect and distribute security incident reports and other security-relevant information between network- connected devices, primarily for the purpose of communication amongComputer Security Incident Response Teams and associated entities.To illustrate the principles involved, this document describes such a usage for the Incident Object Description Exchange Format (IODEF). |
|
| |
| RFC 8601 | Message Header Field for Indicating Message Authentication Status |
| |
|
|
This document specifies a message header field called"Authentication-Results" for use with electronic mail messages to indicate the results of message authentication efforts. Any receiver-side software, such as mail filters or Mail User Agents(MUAs), can use this header field to relay that information in a convenient and meaningful way to users or to make sorting and filtering decisions.
This document obsoletes RFC 7601. |
|
| |
| RFC 8602 | Update to the Telephony Routing over IP (TRIP) IANA Registry Rules regarding Postal Addresses |
| |
|
|
This memo updates the IANA registry rules for the Telephony Routing over IP (TRIP) protocol, by no longer requiring that postal addresses be included in contact information.
This memo updates RFC 3219. |
|
| |
| RFC 8606 | ISDN User Part (ISUP) Cause Location Parameter for the SIP Reason Header Field |
| |
|
|
The SIP Reason header field is defined to carry ISUP (ISDN User Part) cause values as well as SIP response codes. Some services in SIP networks may need to know the ISUP location where the call was released in the PSTN (Public Switched Telephone Network) to correctly interpret the reason of release. This document updates RFC 3326 by adding a location parameter for this purpose. |
|
| |
| RFC 8608 | BGPsec Algorithms, Key Formats, and Signature Formats |
| |
|
|
This document specifies the algorithms, algorithm parameters, asymmetric key formats, asymmetric key sizes, and signature formats used in BGPsec (Border Gateway Protocol Security). This document updates RFC 7935 ("The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure") and obsoletes RFC 8208("BGPsec Algorithms, Key Formats, and Signature Formats") by addingDocumentation and Experimentation Algorithm IDs, correcting the range of unassigned algorithms IDs to fill the complete range, and restructuring the document for better reading.
This document also includes example BGPsec UPDATE messages as well as the private keys used to generate the messages and the certificates necessary to validate those signatures. |
|
| |
| RFC 8610 | Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures |
| |
| Authors: | H. Birkholz, C. Vigano, C. Bormann. |
| Date: | June 2019 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8610 |
|
This document proposes a notational convention to express ConciseBinary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR orJSON. |
|
| |
| RFC 8611 | Label Switched Path (LSP) Ping and Traceroute Multipath Support for Link Aggregation Group (LAG) Interfaces |
| |
| Authors: | N. Akiya, G. Swallow, S. Litkowski, B. Decraene, J. Drake, M. Chen. |
| Date: | June 2019 |
| Formats: | txt html json |
| Updates: | RFC 8029 |
| Updated by: | RFC 9041 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8611 |
|
This document defines extensions to the MPLS Label Switched Path(LSP) Ping and Traceroute mechanisms as specified in RFC 8029. The extensions allow the MPLS LSP Ping and Traceroute mechanisms to discover and exercise specific paths of Layer 2 (L2) Equal-CostMultipath (ECMP) over Link Aggregation Group (LAG) interfaces.Additionally, a mechanism is defined to enable the determination of the capabilities supported by a Label Switching Router (LSR).
This document updates RFC 8029. |
|
| |
| RFC 8613 | Object Security for Constrained RESTful Environments (OSCORE) |
| |
| Authors: | G. Selander, J. Mattsson, F. Palombini, L. Seitz. |
| Date: | July 2019 |
| Formats: | txt json html |
| Updates: | RFC 7252 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8613 |
|
This document defines Object Security for Constrained RESTfulEnvironments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR ObjectSigning and Encryption (COSE). OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP.OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols.
Although an optional functionality of CoAP, OSCORE alters CoAP options processing and IANA registration. Therefore, this document updates RFC 7252. |
|
| |
| RFC 8614 | Updated Processing of Control Flags for BGP Virtual Private LAN Service (VPLS) |
| |
| Authors: | R. Singh, K. Kompella, S. Palislamovic. |
| Date: | June 2019 |
| Formats: | txt html json |
| Updates: | RFC 4761 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8614 |
|
This document updates the meaning of the Control Flags field in the"Layer2 Info Extended Community" used for BGP Virtual Private LANService (VPLS) Network Layer Reachability Information (NLRI) as defined in RFC 4761. This document updates RFC 4761. |
|
| |
| RFC 8615 | Well-Known Uniform Resource Identifiers (URIs) |
| |
|
|
This memo defines a path prefix for "well-known locations","/.well-known/", in selected Uniform Resource Identifier (URI) schemes.
In doing so, it obsoletes RFC 5785 and updates the URI schemes defined in RFC 7230 to reserve that space. It also updates RFC 7595 to track URI schemes that support well-known URIs in their registry. |
|
| |
| RFC 8616 | Email Authentication for Internationalized Mail |
| |
|
|
Sender Policy Framework (SPF) (RFC 7208), DomainKeys Identified Mail(DKIM) (RFC 6376), and Domain-based Message Authentication,Reporting, and Conformance (DMARC) (RFC 7489) enable a domain owner to publish email authentication and policy information in the DNS.In internationalized email, domain names can occur both as U-labels and A-labels. This specification updates the SPF, DKIM, and DMARC specifications to clarify which form of internationalized domain names to use in those specifications. |
|
| |
| RFC 8618 | Compacted-DNS (C-DNS): A Format for DNS Packet Capture |
| |
| Authors: | J. Dickinson, J. Hague, S. Dickinson, T. Manderson, J. Bond. |
| Date: | September 2019 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8618 |
|
This document describes a data representation for collections of DNS messages. The format is designed for efficient storage and transmission of large packet captures of DNS traffic; it attempts to minimize the size of such packet capture files but retain the fullDNS message contents along with the most useful transport metadata.It is intended to assist with the development of DNS traffic- monitoring applications. |
|
| |
| RFC 8619 | Algorithm Identifiers for the HMAC-based Extract-and-Expand Key Derivation Function (HKDF) |
| |
| Authors: | R. Housley. |
| Date: | June 2019 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8619 |
|
RFC 5869 specifies the HMAC-based Extract-and-Expand Key DerivationFunction (HKDF) algorithm. This document assigns algorithm identifiers to the HKDF algorithm when used with three common one-way hash functions. |
|
| |
| RFC 8620 | The JSON Meta Application Protocol (JMAP) |
| |
|
|
This document specifies a protocol for clients to efficiently query, fetch, and modify JSON-based data objects, with support for push notification of changes and fast resynchronisation and for out-of- band binary data upload/download. |
|
| |
| RFC 8621 | The JSON Meta Application Protocol (JMAP) for Mail |
| |
|
|
This document specifies a data model for synchronising email data with a server using the JSON Meta Application Protocol (JMAP).Clients can use this to efficiently search, access, organise, and send messages, and to get push notifications for fast resynchronisation when new messages are delivered or a change is made in another client. |
|
| |
| RFC 8622 | A Lower-Effort Per-Hop Behavior (LE PHB) for Differentiated Services |
| |
|
|
This document specifies properties and characteristics of a Lower-Effort Per-Hop Behavior (LE PHB). The primary objective of this LEPHB is to protect Best-Effort (BE) traffic (packets forwarded with the default PHB) from LE traffic in congestion situations, i.e., when resources become scarce, BE traffic has precedence over LE traffic and may preempt it. Alternatively, packets forwarded by the LE PHB can be associated with a scavenger service class, i.e., they scavenge otherwise-unused resources only. There are numerous uses for thisPHB, e.g., for background traffic of low precedence, such as bulk data transfers with low priority in time, non-time-critical backups, larger software updates, web search engines while gathering information from web servers and so on. This document recommends a standard Differentiated Services Code Point (DSCP) value for the LEPHB.
This specification obsoletes RFC 3662 and updates the DSCP recommended in RFCs 4594 and 8325 to use the DSCP assigned in this specification. |
|
| |
| RFC 8623 | Stateful Path Computation Element (PCE) Protocol Extensions for Usage with Point-to-Multipoint TE Label Switched Paths (LSPs) |
| |
| Authors: | U. Palle, D. Dhody, Y. Tanaka, V. Beeram. |
| Date: | June 2019 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8623 |
|
The Path Computation Element (PCE) has been identified as an appropriate technology for the determination of the paths of point- to-multipoint (P2MP) TE Label Switched Paths (LSPs). This document provides extensions required for the Path Computation ElementCommunication Protocol (PCEP) so as to enable the usage of a statefulPCE capability in supporting P2MP TE LSPs. |
|
| |
| RFC 8624 | Algorithm Implementation Requirements and Usage Guidance for DNSSEC |
| |
|
|
The DNSSEC protocol makes use of various cryptographic algorithms in order to provide authentication of DNS data and proof of nonexistence. To ensure interoperability between DNS resolvers andDNS authoritative servers, it is necessary to specify a set of algorithm implementation requirements and usage guidelines to ensure that there is at least one algorithm that all implementations support. This document defines the current algorithm implementation requirements and usage guidance for DNSSEC. This document obsoletesRFC 6944. |
|
| |
| RFC 8625 | Ethernet Traffic Parameters with Availability Information |
| |
| Authors: | H. Long, M. Ye, Ed., G. Mirsky, Ed., A. D'Alessandro, H. Shah. |
| Date: | August 2019 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8625 |
|
A packet-switching network may contain links with variable bandwidths(e.g., copper and radio). The bandwidth of such links is sensitive to the external environment (e.g., climate). Availability is typically used to describe these links when doing network planning.This document introduces an optional Bandwidth Availability TLV inRSVP-TE signaling. This extension can be used to set up a GMPLSLabel Switched Path (LSP) in conjunction with the EthernetSENDER_TSPEC object. |
|
| |
| RFC 8627 | RTP Payload Format for Flexible Forward Error Correction (FEC) |
| |
| Authors: | M. Zanaty, V. Singh, A. Begen, G. Mandyam. |
| Date: | July 2019 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8627 |
|
This document defines new RTP payload formats for the Forward ErrorCorrection (FEC) packets that are generated by the non-interleaved and interleaved parity codes from source media encapsulated in RTP.These parity codes are systematic codes (Flexible FEC, or "FLEXFEC"), where a number of FEC repair packets are generated from a set of source packets from one or more source RTP streams. These FEC repair packets are sent in a redundancy RTP stream separate from the source RTP stream(s) that carries the source packets. RTP source packets that were lost in transmission can be reconstructed using the source and repair packets that were received. The non-interleaved and interleaved parity codes that are defined in this specification offer a good protection against random and bursty packet losses, respectively, at a cost of complexity. The RTP payload formats that are defined in this document address scalability issues experienced with the earlier specifications and offer several improvements. Due to these changes, the new payload formats are not backward compatible with earlier specifications; however, endpoints that do not implement this specification can still work by simply ignoring the FEC repair packets. |
|
| |
| RFC 8628 | OAuth 2.0 Device Authorization Grant |
| |
| Authors: | W. Denniss, J. Bradley, M. Jones, H. Tschofenig. |
| Date: | August 2019 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8628 |
|
The OAuth 2.0 device authorization grant is designed for Internet- connected devices that either lack a browser to perform a user-agent- based authorization or are input constrained to the extent that requiring the user to input text in order to authenticate during the authorization flow is impractical. It enables OAuth clients on such devices (like smart TVs, media consoles, digital picture frames, and printers) to obtain user authorization to access protected resources by using a user agent on a separate device. |
|
| |
| RFC 8629 | Dynamic Link Exchange Protocol (DLEP) Multi-Hop Forwarding Extension |
| |
| Authors: | B. Cheng, L. Berger, Ed.. |
| Date: | July 2019 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8629 |
|
This document defines an extension to the Dynamic Link ExchangeProtocol (DLEP) that enables the reporting and control of multi-hop forwarding by DLEP-capable modems. |
|
| |
| RFC 8630 | Resource Public Key Infrastructure (RPKI) Trust Anchor Locator |
| |
| Authors: | G. Huston, S. Weiler, G. Michaelson, S. Kent, T. Bruijnzeels. |
| Date: | August 2019 |
| Formats: | txt html json |
| Obsoletes: | RFC 7730 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8630 |
|
This document defines a Trust Anchor Locator (TAL) for the ResourcePublic Key Infrastructure (RPKI). The TAL allows Relying Parties in the RPKI to download the current Trust Anchor (TA) CertificationAuthority (CA) certificate from one or more locations and verify that the key of this self-signed certificate matches the key on the TAL.Thus, Relying Parties can be configured with TA keys but can allow these TAs to change the content of their CA certificate. In particular, it allows TAs to change the set of IP Address Delegations and/or Autonomous System Identifier Delegations included in the extension(s) (RFC 3779) of their certificate.
This document obsoletes the previous definition of the TAL as provided in RFC 7730 by adding support for Uniform ResourceIdentifiers (URIs) (RFC 3986) that use HTTP over TLS (HTTPS) (RFC7230) as the scheme. |
|
| |
| RFC 8632 | A YANG Data Model for Alarm Management |
| |
| Authors: | S. Vallin, M. Bjorklund. |
| Date: | September 2019 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8632 |
|
This document defines a YANG module for alarm management. It includes functions for alarm-list management, alarm shelving, and notifications to inform management systems. There are also operations to manage the operator state of an alarm and administrative alarm procedures. The module carefully maps to relevant alarm standards. |
|
| |
| RFC 8635 | Router Keying for BGPsec |
| |
| Authors: | R. Bush, S. Turner, K. Patel. |
| Date: | August 2019 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8635 |
|
BGPsec-speaking routers are provisioned with private keys in order to sign BGPsec announcements. The corresponding public keys are published in the Global Resource Public Key Infrastructure (RPKI), enabling verification of BGPsec messages. This document describes two methods of generating the public-private key pairs: router-driven and operator-driven. |
|
| |
| RFC 8636 | Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) Algorithm Agility |
| |
| Authors: | L. Hornquist Astrand, L. Zhu, M. Cullen, G. Hudson. |
| Date: | July 2019 |
| Formats: | txt json html |
| Updates: | RFC 4556 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8636 |
|
This document updates the Public Key Cryptography for InitialAuthentication in Kerberos (PKINIT) standard (RFC 4556) to remove protocol structures tied to specific cryptographic algorithms. ThePKINIT key derivation function is made negotiable, and the digest algorithms for signing the pre-authentication data and the client'sX.509 certificates are made discoverable.
These changes provide preemptive protection against vulnerabilities discovered in the future in any specific cryptographic algorithm and allow incremental deployment of newer algorithms. |
|
| |
| RFC 8638 | IPv4 Multicast over an IPv6 Multicast in Softwire Mesh Networks |
| |
| Authors: | M. Xu, Y. Cui, J. Wu, S. Yang, C. Metz. |
| Date: | September 2019 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8638 |
|
During the transition to IPv6, there are scenarios where a backbone network internally running one IP address family (referred to as the internal IP or I-IP family) connects client networks running anotherIP address family (referred to as the external IP or E-IP family).In such cases, the I-IP backbone needs to offer both unicast and multicast transit services to the client E-IP networks.
This document describes a mechanism for supporting multicast across backbone networks where the I-IP and E-IP protocol families differ.The document focuses on the IPv4-over-IPv6 scenario, due to lack of real-world use cases for the IPv6-over-IPv4 scenario. |
|
| |
| RFC 8639 | Subscription to YANG Notifications |
| |
| Authors: | E. Voit, A. Clemm, A. Gonzalez Prieto, E. Nilsen-Nygaard, A. Tripathy. |
| Date: | September 2019 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8639 |
|
This document defines a YANG data model and associated mechanisms enabling subscriber-specific subscriptions to a publisher's event streams. Applying these elements allows a subscriber to request and receive a continuous, customized feed of publisher-generated information. |
|
| |
| RFC 8640 | Dynamic Subscription to YANG Events and Datastores over NETCONF |
| |
| Authors: | E. Voit, A. Clemm, A. Gonzalez Prieto, E. Nilsen-Nygaard, A. Tripathy. |
| Date: | September 2019 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8640 |
|
This document provides a Network Configuration Protocol (NETCONF) binding to the dynamic subscription capability of both subscribed notifications and YANG-Push. |
|
| |
| RFC 8641 | Subscription to YANG Notifications for Datastore Updates |
| |
| Authors: | A. Clemm, E. Voit. |
| Date: | September 2019 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8641 |
|
This document describes a mechanism that allows subscriber applications to request a continuous and customized stream of updates from a YANG datastore. Providing such visibility into updates enables new capabilities based on the remote mirroring and monitoring of configuration and operational state. |
|
| |
| RFC 8642 | Policy Behavior for Well-Known BGP Communities |
| |
| Authors: | J. Borkenhagen, R. Bush, R. Bonica, S. Bayraktar. |
| Date: | August 2019 |
| Formats: | txt html json |
| Updates: | RFC 1997 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8642 |
|
Well-known BGP communities are manipulated differently across various current implementations, resulting in difficulties for operators.Network operators should deploy consistent community handling across their networks while taking the inconsistent behaviors from the various BGP implementations into consideration. This document recommends specific actions to limit future inconsistency: namely,BGP implementors must not create further inconsistencies from this point forward. These behavioral changes, though subtle, actually update RFC 1997. |
|
| |
| RFC 8650 | Dynamic Subscription to YANG Events and Datastores over RESTCONF |
| |
| Authors: | E. Voit, R. Rahman, E. Nilsen-Nygaard, A. Clemm, A. Bierman. |
| Date: | November 2019 |
| Formats: | txt json html pdf xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8650 |
|
This document provides a RESTCONF binding to the dynamic subscription capability of both subscribed notifications and YANG-Push. |
|
| |
| RFC 8651 | Dynamic Link Exchange Protocol (DLEP) Control-Plane-Based Pause Extension |
| |
| Authors: | B. Cheng, D. Wiggins, L. Berger, Ed.. |
| Date: | October 2019 |
| Formats: | txt json pdf xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8651 |
|
This document defines an extension to the Dynamic Link ExchangeProtocol (DLEP) that enables a modem to use DLEP messages to pause and resume data traffic coming from its peer router. |
|
| |
| RFC 8652 | A YANG Data Model for the Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) |
| |
| Authors: | X. Liu, F. Guo, M. Sivakumar, P. McAllister, A. Peter. |
| Date: | November 2019 |
| Formats: | txt xml pdf html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8652 |
|
This document defines a YANG data model that can be used to configure and manage Internet Group Management Protocol (IGMP) and MulticastListener Discovery (MLD) devices. |
|
| |
| RFC 8654 | Extended Message Support for BGP |
| |
|
|
The BGP specification (RFC 4271) mandates a maximum BGP message size of 4,096 octets. As BGP is extended to support new Address FamilyIdentifiers (AFIs), Subsequent AFIs (SAFIs), and other features, there is a need to extend the maximum message size beyond 4,096 octets. This document updates the BGP specification by extending the maximum message size from 4,096 octets to 65,535 octets for all messages except for OPEN and KEEPALIVE messages. |
|
| |
| RFC 8655 | Deterministic Networking Architecture |
| |
| Authors: | N. Finn, P. Thubert, B. Varga, J. Farkas. |
| Date: | October 2019 |
| Formats: | txt json xml pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8655 |
|
This document provides the overall architecture for DeterministicNetworking (DetNet), which provides a capability to carry specified unicast or multicast data flows for real-time applications with extremely low data loss rates and bounded latency within a network domain. Techniques used include 1) reserving data-plane resources for individual (or aggregated) DetNet flows in some or all of the intermediate nodes along the path of the flow, 2) providing explicit routes for DetNet flows that do not immediately change with the network topology, and 3) distributing data from DetNet flow packets over time and/or space to ensure delivery of each packet's data in spite of the loss of a path. DetNet operates at the IP layer and delivers service over lower-layer technologies such as MPLS and Time-Sensitive Networking (TSN) as defined by IEEE 802.1. |
|
| |
| RFC 8656 | Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) |
| |
|
|
If a host is located behind a NAT, it can be impossible for that host to communicate directly with other hosts (peers) in certain situations. In these situations, it is necessary for the host to use the services of an intermediate node that acts as a communication relay. This specification defines a protocol, called "TraversalUsing Relays around NAT" (TURN), that allows the host to control the operation of the relay and to exchange packets with its peers using the relay. TURN differs from other relay control protocols in that it allows a client to communicate with multiple peers using a single relay address.
The TURN protocol was designed to be used as part of the InteractiveConnectivity Establishment (ICE) approach to NAT traversal, though it can also be used without ICE.
This document obsoletes RFCs 5766 and 6156. |
|
| |
| RFC 8657 | Certification Authority Authorization (CAA) Record Extensions for Account URI and Automatic Certificate Management Environment (ACME) Method Binding |
| |
|
|
The Certification Authority Authorization (CAA) DNS record allows a domain to communicate an issuance policy to Certification Authorities(CAs) but only allows a domain to define a policy with CA-level granularity. However, the CAA specification (RFC 8659) also provides facilities for an extension to admit a more granular, CA-specific policy. This specification defines two such parameters: one allowing specific accounts of a CA to be identified by URIs and one allowing specific methods of domain control validation as defined by theAutomatic Certificate Management Environment (ACME) protocol to be required. |
|
| |
| RFC 8658 | RADIUS Attributes for Softwire Mechanisms Based on Address plus Port (A+P) |
| |
| Authors: | S. Jiang, Ed., Y. Fu, Ed., C. Xie, T. Li, M. Boucadair, Ed.. |
| Date: | November 2019 |
| Formats: | txt json html pdf xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8658 |
|
IPv4-over-IPv6 transition mechanisms provide IPv4 connectivity services over IPv6 native networks during the IPv4/IPv6 coexistence period. DHCPv6 options have been defined to configure clients forLightweight 4over6, Mapping of Address and Port with Encapsulation(MAP-E), Mapping of Address and Port using Translation (MAP-T) unicast softwire mechanisms, and multicast softwires. However, in many networks, configuration information is stored in anAuthentication, Authorization, and Accounting (AAA) server, which utilizes the Remote Authentication Dial In User Service (RADIUS) protocol to provide centralized management for users. When a new transition mechanism is developed, new RADIUS attributes need to be defined correspondingly.
This document defines new RADIUS attributes to carry softwire configuration parameters based on Address plus Port from a AAA server to a Broadband Network Gateway. Both unicast and multicast attributes are covered. |
|
| |
| RFC 8659 | DNS Certification Authority Authorization (CAA) Resource Record |
| |
| Authors: | P. Hallam-Baker, R. Stradling, J. Hoffman-Andrews. |
| Date: | November 2019 |
| Formats: | txt json pdf xml html |
| Obsoletes: | RFC 6844 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8659 |
|
The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify one or more CertificationAuthorities (CAs) authorized to issue certificates for that domain name. CAA Resource Records allow a public CA to implement additional controls to reduce the risk of unintended certificate mis-issue.This document defines the syntax of the CAA record and rules for processing CAA records by CAs.
This document obsoletes RFC 6844. |
|
| |
| RFC 8660 | Segment Routing with the MPLS Data Plane |
| |
| Authors: | A. Bashandy, Ed., C. Filsfils, Ed., S. Previdi, B. Decraene, S. Litkowski, R. Shakir. |
| Date: | December 2019 |
| Formats: | txt json xml pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8660 |
|
Segment Routing (SR) leverages the source-routing paradigm. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. In the MPLS data plane, the SR header is instantiated through a label stack.This document specifies the forwarding behavior to allow instantiating SR over the MPLS data plane (SR-MPLS). |
|
| |
| RFC 8661 | Segment Routing MPLS Interworking with LDP |
| |
| Authors: | A. Bashandy, Ed., C. Filsfils, Ed., S. Previdi, B. Decraene, S. Litkowski. |
| Date: | December 2019 |
| Formats: | txt xml pdf json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8661 |
|
A Segment Routing (SR) node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. A segment can represent any instruction, topological or service based. SR allows enforcing a flow through any topological path while maintaining per-flow state only at the ingress node to theSR domain.
The Segment Routing architecture can be directly applied to the MPLS data plane with no change in the forwarding plane. This document describes how Segment Routing MPLS operates in a network where LDP is deployed and in the case where SR-capable and non-SR-capable nodes coexist. |
|
| |
| RFC 8662 | Entropy Label for Source Packet Routing in Networking (SPRING) Tunnels |
| |
| Authors: | S. Kini, K. Kompella, S. Sivabalan, S. Litkowski, R. Shakir, J. Tantsura. |
| Date: | December 2019 |
| Formats: | txt html json pdf xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8662 |
|
Segment Routing (SR) leverages the source-routing paradigm. A node steers a packet through an ordered list of instructions, called segments. Segment Routing can be applied to the Multiprotocol LabelSwitching (MPLS) data plane. Entropy labels (ELs) are used in MPLS to improve load-balancing. This document examines and describes howELs are to be applied to Segment Routing MPLS. |
|
| |
| RFC 8663 | MPLS Segment Routing over IP |
| |
| Authors: | X. Xu, S. Bryant, A. Farrel, S. Hassan, W. Henderickx, Z. Li. |
| Date: | December 2019 |
| Formats: | txt html pdf xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8663 |
|
MPLS Segment Routing (SR-MPLS) is a method of source routing a packet through an MPLS data plane by imposing a stack of MPLS labels on the packet to specify the path together with any packet-specific instructions to be executed on it. SR-MPLS can be leveraged to realize a source-routing mechanism across MPLS, IPv4, and IPv6 data planes by using an MPLS label stack as a source-routing instruction set while making no changes to SR-MPLS specifications and interworking with SR-MPLS implementations.
This document describes how SR-MPLS-capable routers and IP-only routers can seamlessly coexist and interoperate through the use ofSR-MPLS label stacks and IP encapsulation/tunneling such as MPLS- over-UDP as defined in RFC 7510. |
|
| |
| RFC 8664 | Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing |
| |
| Authors: | S. Sivabalan, C. Filsfils, J. Tantsura, W. Henderickx, J. Hardwick. |
| Date: | December 2019 |
| Formats: | txt json pdf xml html |
| Updates: | RFC 8408 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8664 |
|
Segment Routing (SR) enables any head-end node to select any path without relying on a hop-by-hop signaling technique (e.g., LDP orRSVP-TE). It depends only on "segments" that are advertised by link- state Interior Gateway Protocols (IGPs). An SR path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree(SPT), an explicit configuration, or a Path Computation Element(PCE). This document specifies extensions to the Path ComputationElement Communication Protocol (PCEP) that allow a stateful PCE to compute and initiate Traffic-Engineering (TE) paths, as well as aPath Computation Client (PCC) to request a path subject to certain constraints and optimization criteria in SR networks.
This document updates RFC 8408. |
|
| |
| RFC 8665 | OSPF Extensions for Segment Routing |
| |
| Authors: | P. Psenak, Ed., S. Previdi, Ed., C. Filsfils, H. Gredler, R. Shakir, W. Henderickx, J. Tantsura. |
| Date: | December 2019 |
| Formats: | txt json html pdf xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8665 |
|
Segment Routing (SR) allows a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological subpaths called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF).
This document describes the OSPFv2 extensions required for SegmentRouting. |
|
| |
| RFC 8666 | OSPFv3 Extensions for Segment Routing |
| |
| Authors: | P. Psenak, Ed., S. Previdi, Ed.. |
| Date: | December 2019 |
| Formats: | txt html xml pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8666 |
|
Segment Routing (SR) allows a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological subpaths called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF).
This document describes the OSPFv3 extensions required for SegmentRouting with the MPLS data plane. |
|
| |
| RFC 8667 | IS-IS Extensions for Segment Routing |
| |
| Authors: | S. Previdi, Ed., L. Ginsberg, Ed., C. Filsfils, A. Bashandy, H. Gredler, B. Decraene. |
| Date: | December 2019 |
| Formats: | txt xml html pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8667 |
|
Segment Routing (SR) allows for a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological sub-paths, called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF).
This document describes the IS-IS extensions that need to be introduced for Segment Routing operating on an MPLS data plane. |
|
| |
| RFC 8668 | Advertising Layer 2 Bundle Member Link Attributes in IS-IS |
| |
| Authors: | L. Ginsberg, Ed., A. Bashandy, C. Filsfils, M. Nanduri, E. Aries. |
| Date: | December 2019 |
| Formats: | txt xml json pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8668 |
|
There are deployments where the Layer 3 interface on which IS-IS operates is a Layer 2 interface bundle. Existing IS-IS advertisements only support advertising link attributes of the Layer3 interface. If entities external to IS-IS wish to control traffic flows on the individual physical links that comprise the Layer 2 interface bundle, link attribute information about the bundle members is required.
This document introduces the ability for IS-IS to advertise the link attributes of Layer 2 (L2) Bundle Members. |
|
| |
| RFC 8669 | Segment Routing Prefix Segment Identifier Extensions for BGP |
| |
| Authors: | S. Previdi, C. Filsfils, A. Lindem, Ed., A. Sreekantiah, H. Gredler. |
| Date: | December 2019 |
| Formats: | txt json xml pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8669 |
|
Segment Routing (SR) leverages the source-routing paradigm. A node steers a packet through an ordered list of instructions called"segments". A segment can represent any instruction, topological or service based. The ingress node prepends an SR header to a packet containing a set of segment identifiers (SIDs). Each SID represents a topological or service-based instruction. Per-flow state is maintained only on the ingress node of the SR domain. An "SR domain" is defined as a single administrative domain for global SID assignment.
This document defines an optional, transitive BGP attribute for announcing information about BGP Prefix Segment Identifiers (BGPPrefix-SIDs) and the specification for SR-MPLS SIDs. |
|
| |
| RFC 8671 | Support for Adj-RIB-Out in the BGP Monitoring Protocol (BMP) |
| |
| Authors: | T. Evens, S. Bayraktar, P. Lucente, P. Mi, S. Zhuang. |
| Date: | November 2019 |
| Formats: | txt json pdf xml html |
| Updates: | RFC 7854 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8671 |
|
The BGP Monitoring Protocol (BMP) only defines access to the Adj-RIB-In Routing Information Bases (RIBs). This document updates BMP (RFC7854) by adding access to the Adj-RIB-Out RIBs. It also adds a new flag to the peer header to distinguish between Adj-RIB-In and Adj-RIB-Out. |
|
| |
| RFC 8675 | A YANG Data Model for Tunnel Interface Types |
| |
| Authors: | M. Boucadair, I. Farrer, R. Asati. |
| Date: | November 2019 |
| Formats: | txt json html xml pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8675 |
|
This document specifies the initial version of a YANG module "iana- tunnel-type", which contains a collection of IANA-maintained YANG identities used as interface types for tunnel interfaces. The module reflects the "tunnelType" registry maintained by IANA. The latest revision of this YANG module can be obtained from the IANA website.
Tunnel type values are not directly added to the Tunnel InterfaceTypes YANG module; they must instead be added to the "tunnelType"IANA registry. Once a new tunnel type registration is made by IANA for a new tunneling scheme or even an existing one that is not already listed in the current registry (e.g., LISP, NSH), IANA will update the Tunnel Interface Types YANG module accordingly.
Some of the IETF-defined tunneling techniques are not listed in the current IANA registry. It is not the intent of this document to update the existing IANA registry with a comprehensive list of tunnel technologies. Registrants must follow the IETF registration procedure for interface types whenever a new tunnel type is needed. |
|
| |
| RFC 8676 | YANG Modules for IPv4-in-IPv6 Address plus Port (A+P) Softwires |
| |
| Authors: | I. Farrer, Ed., M. Boucadair, Ed.. |
| Date: | November 2019 |
| Formats: | txt html pdf xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8676 |
|
This document defines YANG modules for the configuration and operation of IPv4-in-IPv6 softwire Border Relays and CustomerPremises Equipment for the Lightweight 4over6, Mapping of Address andPort with Encapsulation (MAP-E), and Mapping of Address and Port using Translation (MAP-T) softwire mechanisms. |
|
| |
| RFC 8679 | MPLS Egress Protection Framework |
| |
| Authors: | Y. Shen, M. Jeganathan, B. Decraene, H. Gredler, C. Michel, H. Chen. |
| Date: | December 2019 |
| Formats: | txt pdf xml json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8679 |
|
This document specifies a fast reroute framework for protecting IP/MPLS services and MPLS transport tunnels against egress node and egress link failures. For each type of egress failure, it defines the roles of Point of Local Repair (PLR), protector, and backup egress router and the procedures of establishing a bypass tunnel from a PLR to a protector. It describes the behaviors of these routers in handling an egress failure, including local repair on the PLR and context-based forwarding on the protector. The framework can be used to develop egress protection mechanisms to reduce traffic loss before global repair reacts to an egress failure and control-plane protocols converge on the topology changes due to the egress failure. |
|
| |
| RFC 8680 | Forward Error Correction (FEC) Framework Extension to Sliding Window Codes |
| |
|
|
RFC 6363 describes a framework for using Forward Error Correction(FEC) codes to provide protection against packet loss. The framework supports applying FEC to arbitrary packet flows over unreliable transport and is primarily intended for real-time, or streaming, media. However, FECFRAME as per RFC 6363 is restricted to block FEC codes. This document updates RFC 6363 to support FEC codes based on a sliding encoding window, in addition to block FEC codes, in a backward-compatible way. During multicast/broadcast real-time content delivery, the use of sliding window codes significantly improves robustness in harsh environments, with less repair traffic and lower FEC-related added latency. |
|
| |
| RFC 8681 | Sliding Window Random Linear Code (RLC) Forward Erasure Correction (FEC) Schemes for FECFRAME |
| |
|
|
This document describes two fully specified Forward ErasureCorrection (FEC) Schemes for Sliding Window Random Linear Codes(RLC), one for RLC over the Galois Field (a.k.a., Finite Field)GF(2), a second one for RLC over the Galois Field GF(2^(8)), each time with the possibility of controlling the code density. They can protect arbitrary media streams along the lines defined by FECFRAME extended to Sliding Window FEC Codes. These Sliding Window FEC Codes rely on an encoding window that slides over the source symbols, generating new repair symbols whenever needed. Compared to block FEC codes, these Sliding Window FEC Codes offer key advantages with real- time flows in terms of reduced FEC-related latency while often providing improved packet erasure recovery capabilities. |
|
| |
| RFC 8682 | TinyMT32 Pseudorandom Number Generator (PRNG) |
| |
| Authors: | M. Saito, M. Matsumoto, V. Roca, Ed., E. Baccelli. |
| Date: | January 2020 |
| Formats: | txt xml pdf html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8682 |
|
This document describes the TinyMT32 Pseudorandom Number Generator(PRNG), which produces 32-bit pseudorandom unsigned integers and aims at having a simple-to-use and deterministic solution. This PRNG is a small-sized variant of the Mersenne Twister (MT) PRNG. The main advantage of TinyMT32 over MT is the use of a small internal state, compatible with most target platforms that include embedded devices, while keeping reasonably good randomness that represents a significant improvement compared to the Park-Miller LinearCongruential PRNG. However, neither the TinyMT nor MT PRNG is meant to be used for cryptographic applications. |
|
| |
| RFC 8684 | TCP Extensions for Multipath Operation with Multiple Addresses |
| |
| Authors: | A. Ford, C. Raiciu, M. Handley, O. Bonaventure, C. Paasch. |
| Date: | March 2020 |
| Formats: | txt json xml pdf html |
| Obsoletes: | RFC 6824 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8684 |
|
TCP/IP communication is currently restricted to a single path per connection, yet multiple paths often exist between peers. The simultaneous use of these multiple paths for a TCP/IP session would improve resource usage within the network and thus improve user experience through higher throughput and improved resilience to network failure.
Multipath TCP provides the ability to simultaneously use multiple paths between peers. This document presents a set of extensions to traditional TCP to support multipath operation. The protocol offers the same type of service to applications as TCP (i.e., a reliable bytestream), and it provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths.
This document specifies v1 of Multipath TCP, obsoleting v0 as specified in RFC 6824, through clarifications and modifications primarily driven by deployment experience. |
|
| |
| RFC 8685 | Path Computation Element Communication Protocol (PCEP) Extensions for the Hierarchical Path Computation Element (H-PCE) Architecture |
| |
| Authors: | F. Zhang, Q. Zhao, O. Gonzalez de Dios, R. Casellas, D. King. |
| Date: | December 2019 |
| Formats: | txt xml pdf json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8685 |
|
The Hierarchical Path Computation Element (H-PCE) architecture is defined in RFC 6805. It provides a mechanism to derive an optimum end-to-end path in a multi-domain environment by using a hierarchical relationship between domains to select the optimum sequence of domains and optimum paths across those domains.
This document defines extensions to the Path Computation ElementCommunication Protocol (PCEP) to support H-PCE procedures. |
|
| |
| RFC 8686 | Application-Layer Traffic Optimization (ALTO) Cross-Domain Server Discovery |
| |
| Authors: | S. Kiesel, M. Stiemerling. |
| Date: | February 2020 |
| Formats: | txt html json pdf xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8686 |
|
The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications that have to select one or several hosts from a set of candidates capable of providing a desired resource. ALTO is realized by a client-server protocol. Before anALTO client can ask for guidance, it needs to discover one or moreALTO servers that can provide suitable guidance.
In some deployment scenarios, in particular if the information about the network topology is partitioned and distributed over several ALTO servers, it may be necessary to discover an ALTO server outside of the ALTO client's own network domain, in order to get appropriate guidance. This document details applicable scenarios, itemizes requirements, and specifies a procedure for ALTO cross-domain server discovery.
Technically, the procedure specified in this document takes oneIP address or prefix and a U-NAPTR Service Parameter (typically,"ALTO:https") as parameters. It performs DNS lookups (for NAPTR resource records in the "in-addr.arpa." or "ip6.arpa." trees) and returns one or more URIs of information resources related to that IP address or prefix. |
|
| |
| RFC 8687 | OSPF Routing with Cross-Address Family Traffic Engineering Tunnels |
| |
|
|
When using Traffic Engineering (TE) in a dual-stack IPv4/IPv6 network, the Multiprotocol Label Switching (MPLS) TE Label SwitchedPath (LSP) infrastructure may be duplicated, even if the destinationIPv4 and IPv6 addresses belong to the same remote router. In order to achieve an integrated MPLS TE LSP infrastructure, OSPF routes must be computed over MPLS TE tunnels created using information propagated in another OSPF instance. This issue is solved by advertising cross- address family (X-AF) OSPF TE information.
This document describes an update to RFC 5786 that allows for the easy identification of a router's local X-AF IP addresses. |
|
| |
| RFC 8688 | A Session Initiation Protocol (SIP) Response Code for Rejected Calls |
| |
| Authors: | E.W. Burger, B. Nagda. |
| Date: | December 2019 |
| Formats: | txt json html pdf xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8688 |
|
This document defines the 608 (Rejected) Session Initiation Protocol(SIP) response code. This response code enables calling parties to learn that an intermediary rejected their call attempt. No one will deliver, and thus answer, the call. As a 6xx code, the caller will be aware that future attempts to contact the same User Agent Server will likely fail. The initial use case driving the need for the 608 response code is when the intermediary is an analytics engine. In this case, the rejection is by a machine or other process. This contrasts with the 607 (Unwanted) SIP response code in which a human at the target User Agent Server indicates the user did not want the call. In some jurisdictions, this distinction is important. This document also defines the use of the Call-Info header field in 608 responses to enable rejected callers to contact entities that blocked their calls in error. This provides a remediation mechanism for legal callers that find their calls blocked. |
|
| |
| RFC 8689 | SMTP Require TLS Option |
| |
|
|
The SMTP STARTTLS option, used in negotiating transport-level encryption of SMTP connections, is not as useful from a security standpoint as it might be because of its opportunistic nature; message delivery is, by default, prioritized over security. This document describes an SMTP service extension, REQUIRETLS, and a message header field, TLS-Required. If the REQUIRETLS option or TLS-Required message header field is used when sending a message, it asserts a request on the part of the message sender to override the default negotiation of TLS, either by requiring that TLS be negotiated when the message is relayed or by requesting that recipient-side policy mechanisms such as MTA-STS and DNS-BasedAuthentication of Named Entities (DANE) be ignored when relaying a message for which security is unimportant. |
|
| |
| RFC 8690 | Clarification of Segment ID Sub-TLV Length for RFC 8287 |
| |
| Authors: | N. Nainar, C. Pignataro, F. Iqbal, A. Vainshtein. |
| Date: | December 2019 |
| Formats: | txt json html xml pdf |
| Updates: | RFC 8287 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8690 |
|
RFC 8287 defines the extensions to perform LSP Ping and Traceroute for Segment Routing IGP-Prefix and IGP-Adjacency Segment Identifiers(SIDs) with the MPLS data plane. RFC 8287 proposes three TargetForwarding Equivalence Class (FEC) Stack sub-TLVs. While RFC 8287 defines the format and procedure to handle those sub-TLVs, it does not sufficiently clarify how the length of the Segment ID sub-TLVs should be computed to be included in the Length field of the sub-TLVs. This ambiguity has resulted in interoperability issues.
This document updates RFC 8287 by clarifying the length of each of the Segment ID sub-TLVs defined in RFC 8287. |
|
| |
| RFC 8691 | Basic Support for IPv6 Networks Operating Outside the Context of a Basic Service Set over IEEE Std 802.11 |
| |
| Authors: | N. Benamar, J. Härri, J. Lee, T. Ernst. |
| Date: | December 2019 |
| Formats: | txt json xml pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8691 |
|
This document provides methods and settings for using IPv6 to communicate among nodes within range of one another over a singleIEEE 802.11-OCB link. Support for these methods and settings require minimal changes to existing stacks. This document also describes limitations associated with using these methods. Optimizations and usage of IPv6 over more complex scenarios are not covered in this specification and are a subject for future work. |
|
| |
| RFC 8692 | Internet X.509 Public Key Infrastructure: Additional Algorithm Identifiers for RSASSA-PSS and ECDSA Using SHAKEs |
| |
|
|
Digital signatures are used to sign messages, X.509 certificates, andCertificate Revocation Lists (CRLs). This document updates the"Algorithms and Identifiers for the Internet X.509 Public KeyInfrastructure Certificate and Certificate Revocation List (CRL)Profile" (RFC 3279) and describes the conventions for using the SHAKE function family in Internet X.509 certificates and revocation lists as one-way hash functions with the RSA Probabilistic signature andElliptic Curve Digital Signature Algorithm (ECDSA) signature algorithms. The conventions for the associated subject public keys are also described. |
|
| |
| RFC 8693 | OAuth 2.0 Token Exchange |
| |
| Authors: | M. Jones, A. Nadalin, B. Campbell, Ed., J. Bradley, C. Mortimore. |
| Date: | January 2020 |
| Formats: | txt pdf html xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8693 |
|
This specification defines a protocol for an HTTP- and JSON-basedSecurity Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation. |
|
| |
| RFC 8695 | A YANG Data Model for the Routing Information Protocol (RIP) |
| |
| Authors: | X. Liu, P. Sarda, V. Choudhary. |
| Date: | February 2020 |
| Formats: | txt json pdf xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8695 |
|
This document describes a data model for the management of theRouting Information Protocol (RIP). Both RIP version 2 and RIPng are covered. The data model includes definitions for configuration, operational state, and Remote Procedure Calls (RPCs).
The YANG data model in this document conforms to the NetworkManagement Datastore Architecture (NMDA). |
|
| |
| RFC 8696 | Using Pre-Shared Key (PSK) in the Cryptographic Message Syntax (CMS) |
| |
|
|
The invention of a large-scale quantum computer would pose a serious challenge for the cryptographic algorithms that are widely deployed today. The Cryptographic Message Syntax (CMS) supports key transport and key agreement algorithms that could be broken by the invention of such a quantum computer. By storing communications that are protected with the CMS today, someone could decrypt them in the future when a large-scale quantum computer becomes available. Once quantum-secure key management algorithms are available, the CMS will be extended to support the new algorithms if the existing syntax does not accommodate them. This document describes a mechanism to protect today's communication from the future invention of a large-scale quantum computer by mixing the output of key transport and key agreement algorithms with a pre-shared key. |
|
| |
| RFC 8697 | Path Computation Element Communication Protocol (PCEP) Extensions for Establishing Relationships between Sets of Label Switched Paths (LSPs) |
| |
| Authors: | I. Minei, E. Crabbe, S. Sivabalan, H. Ananthakrishnan, D. Dhody, Y. Tanaka. |
| Date: | January 2020 |
| Formats: | txt html json xml pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8697 |
|
This document introduces a generic mechanism to create a grouping ofLabel Switched Paths (LSPs) in the context of a Path ComputationElement (PCE). This grouping can then be used to define associations between sets of LSPs or between a set of LSPs and a set of attributes(such as configuration parameters or behaviors), and it is equally applicable to the stateful PCE (active and passive modes) and the stateless PCE. |
|
| |
| RFC 8702 | Use of the SHAKE One-Way Hash Functions in the Cryptographic Message Syntax (CMS) |
| |
|
|
This document updates the "Cryptographic Message Syntax (CMS)Algorithms" (RFC 3370) and describes the conventions for using theSHAKE family of hash functions in the Cryptographic Message Syntax as one-way hash functions with the RSA Probabilistic Signature Scheme(RSASSA-PSS) and Elliptic Curve Digital Signature Algorithm (ECDSA).The conventions for the associated signer public keys in CMS are also described. |
|
| |
| RFC 8703 | Dynamic Link Exchange Protocol (DLEP) Link Identifier Extension |
| |
| Authors: | R. Taylor, S. Ratliff. |
| Date: | February 2020 |
| Formats: | txt xml html pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8703 |
|
The Dynamic Link Exchange Protocol (DLEP) is a protocol for modems to advertise the status of wireless links between reachable destinations to attached routers. The core specification of the protocol (RFC8175) assumes that every modem in the radio network has an attachedDLEP router and requires that the Media Access Control (MAC) address of the DLEP interface on the attached router be used to identify the destination in the network, for purposes of reporting the state and quality of the link to that destination.
This document describes a DLEP extension that allows modems that do not meet the strict requirement above to use DLEP to describe link availability and quality to one or more destinations reachable beyond a device on the Layer 2 domain. |
|
| |
| RFC 8705 | OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens |
| |
| Authors: | B. Campbell, J. Bradley, N. Sakimura, T. Lodderstedt. |
| Date: | February 2020 |
| Formats: | txt xml pdf json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8705 |
|
This document describes OAuth client authentication and certificate- bound access and refresh tokens using mutual Transport Layer Security(TLS) authentication with X.509 certificates. OAuth clients are provided a mechanism for authentication to the authorization server using mutual TLS, based on either self-signed certificates or public key infrastructure (PKI). OAuth authorization servers are provided a mechanism for binding access tokens to a client's mutual-TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token. |
|
| |
| RFC 8706 | Restart Signaling for IS-IS |
| |
|
|
This document describes a mechanism for a restarting router to signal to its neighbors that it is restarting, allowing them to reestablish their adjacencies without cycling through the DOWN state while still correctly initiating database synchronization.
This document additionally describes a mechanism for a router to signal its neighbors that it is preparing to initiate a restart while maintaining forwarding-plane state. This allows the neighbors to maintain their adjacencies until the router has restarted but also allows the neighbors to bring the adjacencies down in the event of other topology changes.
This document additionally describes a mechanism for a restarting router to determine when it has achieved Link State Protocol DataUnit (LSP) database synchronization with its neighbors and a mechanism to optimize LSP database synchronization while minimizing transient routing disruption when a router starts.
This document obsoletes RFC 5306. |
|
| |
| RFC 8707 | Resource Indicators for OAuth 2.0 |
| |
| Authors: | B. Campbell, J. Bradley, H. Tschofenig. |
| Date: | February 2020 |
| Formats: | txt html pdf json xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8707 |
|
This document specifies an extension to the OAuth 2.0 AuthorizationFramework defining request parameters that enable a client to explicitly signal to an authorization server about the identity of the protected resource(s) to which it is requesting access. |
|
| |
| RFC 8708 | Use of the HSS/LMS Hash-Based Signature Algorithm in the Cryptographic Message Syntax (CMS) |
| |
|
|
This document specifies the conventions for using the HierarchicalSignature System (HSS) / Leighton-Micali Signature (LMS) hash-based signature algorithm with the Cryptographic Message Syntax (CMS). In addition, the algorithm identifier and public key syntax are provided. The HSS/LMS algorithm is one form of hash-based digital signature; it is described in RFC 8554. |
|
| |
| RFC 8709 | Ed25519 and Ed448 Public Key Algorithms for the Secure Shell (SSH) Protocol |
| |
|
|
This document describes the use of the Ed25519 and Ed448 digital signature algorithms in the Secure Shell (SSH) protocol.Accordingly, this RFC updates RFC 4253. |
|
| |
| RFC 8710 | Multipart Content-Format for the Constrained Application Protocol (CoAP) |
| |
| Authors: | T. Fossati, K. Hartke, C. Bormann. |
| Date: | February 2020 |
| Formats: | txt json xml html pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8710 |
|
This memo defines application/multipart-core, an application- independent media type that can be used to combine representations of zero or more different media types (each with a ConstrainedApplication Protocol (CoAP) Content-Format identifier) into a single representation, with minimal framing overhead. |
|
| |
| RFC 8723 | Double Encryption Procedures for the Secure Real-Time Transport Protocol (SRTP) |
| |
| Authors: | C. Jennings, P. Jones, R. Barnes, A.B. Roach. |
| Date: | April 2020 |
| Formats: | txt html xml pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8723 |
|
In some conferencing scenarios, it is desirable for an intermediary to be able to manipulate some parameters in Real-time TransportProtocol (RTP) packets, while still providing strong end-to-end security guarantees. This document defines a cryptographic transform for the Secure Real-time Transport Protocol (SRTP) that uses two separate but related cryptographic operations to provide hop-by-hop and end-to-end security guarantees. Both the end-to-end and hop-by- hop cryptographic algorithms can utilize an authenticated encryption with associated data (AEAD) algorithm or take advantage of futureSRTP transforms with different properties. |
|
| |
| RFC 8724 | SCHC: Generic Framework for Static Context Header Compression and Fragmentation |
| |
| Authors: | A. Minaburo, L. Toutain, C. Gomez, D. Barthel, JC. Zuniga. |
| Date: | April 2020 |
| Formats: | txt json xml html pdf |
| Updated by: | RFC 9441 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8724 |
|
This document defines the Static Context Header Compression and fragmentation (SCHC) framework, which provides both a header compression mechanism and an optional fragmentation mechanism. SCHC has been designed with Low-Power Wide Area Networks (LPWANs) in mind.
SCHC compression is based on a common static context stored both in the LPWAN device and in the network infrastructure side. This document defines a generic header compression mechanism and its application to compress IPv6/UDP headers.
This document also specifies an optional fragmentation and reassembly mechanism. It can be used to support the IPv6 MTU requirement over the LPWAN technologies. Fragmentation is needed for IPv6 datagrams that, after SCHC compression or when such compression was not possible, still exceed the Layer 2 maximum payload size.
The SCHC header compression and fragmentation mechanisms are independent of the specific LPWAN technology over which they are used. This document defines generic functionalities and offers flexibility with regard to parameter settings and mechanism choices.This document standardizes the exchange over the LPWAN between twoSCHC entities. Settings and choices specific to a technology or a product are expected to be grouped into profiles, which are specified in other documents. Data models for the context and profiles are out of scope. |
|
| |
| RFC 8727 | JSON Binding of the Incident Object Description Exchange Format |
| |
| Authors: | T. Takahashi, R. Danyliw, M. Suzuki. |
| Date: | August 2020 |
| Formats: | txt html pdf xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8727 |
|
The Incident Object Description Exchange Format (IODEF) defined inRFC 7970 provides an information model and a corresponding XML data model for exchanging incident and indicator information. This document gives implementers and operators an alternative format to exchange the same information by defining an alternative data model implementation in JSON and its encoding in Concise Binary ObjectRepresentation (CBOR). |
|
| |
| RFC 8731 | Secure Shell (SSH) Key Exchange Method Using Curve25519 and Curve448 |
| |
| Authors: | A. Adamantiadis, S. Josefsson, M. Baushke. |
| Date: | February 2020 |
| Formats: | txt json xml pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8731 |
|
This document describes the specification for using Curve25519 andCurve448 key exchange methods in the Secure Shell (SSH) protocol. |
|
| |
| RFC 8732 | Generic Security Service Application Program Interface (GSS-API) Key Exchange with SHA-2 |
| |
|
|
This document specifies additions and amendments to RFC 4462. It defines a new key exchange method that uses SHA-2 for integrity and deprecates weak Diffie-Hellman (DH) groups. The purpose of this specification is to modernize the cryptographic primitives used byGeneric Security Service (GSS) key exchanges. |
|
| |
| RFC 8733 | Path Computation Element Communication Protocol (PCEP) Extensions for MPLS-TE Label Switched Path (LSP) Auto-Bandwidth Adjustment with Stateful PCE |
| |
| Authors: | D. Dhody, Ed., R. Gandhi, Ed., U. Palle, R. Singh, L. Fang. |
| Date: | February 2020 |
| Formats: | txt html pdf json xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8733 |
|
The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests.Stateful PCE extensions allow stateful control of MPLS-TE LabelSwitched Paths (LSPs) using PCEP.
The auto-bandwidth feature allows automatic and dynamic adjustment of the TE LSP bandwidth reservation based on the volume of traffic flowing through the LSP. This document describes PCEP extensions for auto-bandwidth adjustment when employing an active stateful PCE for both PCE-initiated and PCC-initiated LSPs. |
|
| |
| RFC 8736 | PIM Message Type Space Extension and Reserved Bits |
| |
|
|
The PIM version 2 messages share a common message header format. The common header definition contains eight reserved bits. This document specifies how these bits may be used by individual message types and creates a registry containing the per-message-type usage. This document also extends the PIM type space by defining three new message types. For each of the new types, four of the previously reserved bits are used to form an extended type range.
This document updates RFCs 7761 and 3973 by defining the use of the currently Reserved field in the PIM common header. This document further updates RFCs 7761 and 3973, along with RFCs 5015, 5059, 6754, and 8364, by specifying the use of the currently reserved bits for each PIM message.
This document obsoletes RFC 6166. |
|
| |
| RFC 8737 | Automated Certificate Management Environment (ACME) TLS Application-Layer Protocol Negotiation (ALPN) Challenge Extension |
| |
|
|
This document specifies a new challenge for the Automated CertificateManagement Environment (ACME) protocol that allows for domain control validation using TLS. |
|
| |
| RFC 8738 | Automated Certificate Management Environment (ACME) IP Identifier Validation Extension |
| |
|
|
This document specifies identifiers and challenges required to enable the Automated Certificate Management Environment (ACME) to issue certificates for IP addresses. |
|
| |
| RFC 8739 | Support for Short-Term, Automatically Renewed (STAR) Certificates in the Automated Certificate Management Environment (ACME) |
| |
| Authors: | Y. Sheffer, D. Lopez, O. Gonzalez de Dios, A. Pastor Perales, T. Fossati. |
| Date: | March 2020 |
| Formats: | txt xml json pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8739 |
|
Public key certificates need to be revoked when they are compromised, that is, when the associated private key is exposed to an unauthorized entity. However, the revocation process is often unreliable. An alternative to revocation is issuing a sequence of certificates, each with a short validity period, and terminating the sequence upon compromise. This memo proposes an AutomatedCertificate Management Environment (ACME) extension to enable the issuance of Short-Term, Automatically Renewed (STAR) X.509 certificates. |
|
| |
| RFC 8740 | Using TLS 1.3 with HTTP/2 |
| |
|
|
This document updates RFC 7540 by forbidding TLS 1.3 post-handshake authentication, as an analog to the existing TLS 1.2 renegotiation restriction. |
|
| |
| RFC 8741 | Ability for a Stateful Path Computation Element (PCE) to Request and Obtain Control of a Label Switched Path (LSP) |
| |
| Authors: | A. Raghuram, A. Goddard, J. Karthik, S. Sivabalan, M. Negi. |
| Date: | March 2020 |
| Formats: | txt html pdf json xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8741 |
|
A stateful Path Computation Element (PCE) retains information about the placement of Multiprotocol Label Switching (MPLS) TrafficEngineering Label Switched Paths (TE LSPs). When a PCE has stateful control over LSPs, it may send indications to LSP head-ends to modify the attributes (especially the paths) of the LSPs. A PathComputation Client (PCC) that has set up LSPs under local configuration may delegate control of those LSPs to a stateful PCE.
There are use cases in which a stateful PCE may wish to obtain control of locally configured LSPs that it is aware of but have not been delegated to the PCE.
This document describes an extension to the Path Computation ElementCommunication Protocol (PCEP) to enable a PCE to make requests for such control. |
|
| |
| RFC 8742 | Concise Binary Object Representation (CBOR) Sequences |
| |
|
|
This document describes the Concise Binary Object Representation(CBOR) Sequence format and associated media type "application/cbor- seq". A CBOR Sequence consists of any number of encoded CBOR data items, simply concatenated in sequence.
Structured syntax suffixes for media types allow other media types to build on them and make it explicit that they are built on an existing media type as their foundation. This specification defines and registers "+cbor-seq" as a structured syntax suffix for CBORSequences. |
|
| |
| RFC 8745 | Path Computation Element Communication Protocol (PCEP) Extensions for Associating Working and Protection Label Switched Paths (LSPs) with Stateful PCE |
| |
| Authors: | H. Ananthakrishnan, S. Sivabalan, C. Barth, I. Minei, M. Negi. |
| Date: | March 2020 |
| Formats: | txt xml pdf html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8745 |
|
An active stateful Path Computation Element (PCE) is capable of computing as well as controlling via Path Computation ElementCommunication Protocol (PCEP) Multiprotocol Label Switching TrafficEngineering (MPLS-TE) Label Switched Paths (LSPs). Furthermore, it is also possible for an active stateful PCE to create, maintain, and delete LSPs. This document defines the PCEP extension to associate two or more LSPs to provide end-to-end path protection. |
|
| |
| RFC 8746 | Concise Binary Object Representation (CBOR) Tags for Typed Arrays |
| |
|
|
The Concise Binary Object Representation (CBOR), as defined in RFC7049, is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation.
This document makes use of this extensibility to define a number ofCBOR tags for typed arrays of numeric data, as well as additional tags for multi-dimensional and homogeneous arrays. It is intended as the reference document for the IANA registration of the CBOR tags defined. |
|
| |
| RFC 8747 | Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs) |
| |
| Authors: | M. Jones, L. Seitz, G. Selander, S. Erdtman, H. Tschofenig. |
| Date: | March 2020 |
| Formats: | txt json pdf xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8747 |
|
This specification describes how to declare in a CBOR Web Token (CWT)(which is defined by RFC 8392) that the presenter of the CWT possesses a particular proof-of-possession key. Being able to prove possession of a key is also sometimes described as being the holder- of-key. This specification provides equivalent functionality to"Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)" (RFC7800) but using Concise Binary Object Representation (CBOR) and CWTs rather than JavaScript Object Notation (JSON) and JSON Web Tokens(JWTs). |
|
| |
| RFC 8748 | Registry Fee Extension for the Extensible Provisioning Protocol (EPP) |
| |
| Authors: | R. Carney, G. Brown, J. Frakes. |
| Date: | March 2020 |
| Formats: | txt html json pdf xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8748 |
|
Given the expansion of the DNS namespace and the proliferation of novel business models, it is desirable to provide a method forExtensible Provisioning Protocol (EPP) clients to query EPP servers for the fees and credits associated with various billable transactions and provide expected fees and credits for certain commands and objects. This document describes an EPP extension mapping for registry fees. |
|
| |
| RFC 8749 | Moving DNSSEC Lookaside Validation (DLV) to Historic Status |
| |
|
|
This document retires DNSSEC Lookaside Validation (DLV) and reclassifies RFCs 4431 and 5074 as Historic. Furthermore, this document updates RFC 6698 by excluding the DLV resource record from certificates and updates RFC 6840 by excluding the DLV registries from the trust anchor selection. |
|
| |
| RFC 8750 | Implicit Initialization Vector (IV) for Counter-Based Ciphers in Encapsulating Security Payload (ESP) |
| |
| Authors: | D. Migault, T. Guggemos, Y. Nir. |
| Date: | March 2020 |
| Formats: | txt html json xml pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8750 |
|
Encapsulating Security Payload (ESP) sends an initialization vector(IV) in each packet. The size of the IV depends on the applied transform and is usually 8 or 16 octets for the transforms defined at the time this document was written. When used with IPsec, some algorithms, such as AES-GCM, AES-CCM, and ChaCha20-Poly1305, take theIV to generate a nonce that is used as an input parameter for encrypting and decrypting. This IV must be unique but can be predictable. As a result, the value provided in the ESP SequenceNumber (SN) can be used instead to generate the nonce. This avoids sending the IV itself and saves 8 octets per packet in the case ofAES-GCM, AES-CCM, and ChaCha20-Poly1305. This document describes how to do this. |
|
| |
| RFC 8753 | Internationalized Domain Names for Applications (IDNA) Review for New Unicode Versions |
| |
|
|
The standards for Internationalized Domain Names in Applications(IDNA) require a review of each new version of Unicode to determine whether incompatibilities with prior versions or other issues exist and, where appropriate, to allow the IETF to decide on the trade-offs between compatibility with prior IDNA versions and compatibility withUnicode going forward. That requirement, and its relationship to tables maintained by IANA, has caused significant confusion in the past. This document makes adjustments to the review procedure based on experience and updates IDNA, specifically RFC 5892, to reflect those changes and to clarify the various relationships involved. It also makes other minor adjustments to align that document with experience. |
|
| |
| RFC 8754 | IPv6 Segment Routing Header (SRH) |
| |
| Authors: | C. Filsfils, Ed., D. Dukes, Ed., S. Previdi, J. Leddy, S. Matsushima, D. Voyer. |
| Date: | March 2020 |
| Formats: | txt pdf xml html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8754 |
|
Segment Routing can be applied to the IPv6 data plane using a new type of Routing Extension Header called the Segment Routing Header(SRH). This document describes the SRH and how it is used by nodes that are Segment Routing (SR) capable. |
|
| |
| RFC 8757 | Dynamic Link Exchange Protocol (DLEP) Latency Range Extension |
| |
| Authors: | B. Cheng, L. Berger, Ed.. |
| Date: | March 2020 |
| Formats: | txt json xml html pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8757 |
|
This document defines an extension to the Dynamic Link ExchangeProtocol (DLEP) to provide the range of latency that can be experienced on a link. |
|
| |
| RFC 8759 | RTP Payload for Timed Text Markup Language (TTML) |
| |
|
|
This memo describes a Real-time Transport Protocol (RTP) payload format for Timed Text Markup Language (TTML), an XML-based timed text format from W3C. This payload format is specifically targeted at streaming workflows using TTML. |
|
| |
| RFC 8760 | The Session Initiation Protocol (SIP) Digest Access Authentication Scheme |
| |
|
|
This document updates RFC 3261 by modifying the Digest AccessAuthentication scheme used by the Session Initiation Protocol (SIP) to add support for more secure digest algorithms, e.g., SHA-256 andSHA-512/256, to replace the obsolete MD5 algorithm. |
|
| |
| RFC 8762 | Simple Two-Way Active Measurement Protocol |
| |
|
|
This document describes the Simple Two-way Active MeasurementProtocol (STAMP), which enables the measurement of both one-way and round-trip performance metrics, like delay, delay variation, and packet loss. |
|
| |
| RFC 8765 | DNS Push Notifications |
| |
| Authors: | T. Pusateri, S. Cheshire. |
| Date: | June 2020 |
| Formats: | txt html json xml pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8765 |
|
The Domain Name System (DNS) was designed to return matching records efficiently for queries for data that are relatively static. When those records change frequently, DNS is still efficient at returning the updated results when polled, as long as the polling rate is not too high. But, there exists no mechanism for a client to be asynchronously notified when these changes occur. This document defines a mechanism for a client to be notified of such changes toDNS records, called DNS Push Notifications. |
|
| |
| RFC 8766 | Discovery Proxy for Multicast DNS-Based Service Discovery |
| |
|
|
This document specifies a network proxy that uses Multicast DNS to automatically populate the wide-area unicast Domain Name System namespace with records describing devices and services found on the local link. |
|
| |
| RFC 8767 | Serving Stale Data to Improve DNS Resiliency |
| |
|
|
This document defines a method (serve-stale) for recursive resolvers to use stale DNS data to avoid outages when authoritative nameservers cannot be reached to refresh expired data. One of the motivations for serve-stale is to make the DNS more resilient to DoS attacks and thereby make them less attractive as an attack vector. This document updates the definitions of TTL from RFCs 1034 and 1035 so that data can be kept in the cache beyond the TTL expiry; it also updates RFC2181 by interpreting values with the high-order bit set as being positive, rather than 0, and suggests a cap of 7 days. |
|
| |
| RFC 8768 | Constrained Application Protocol (CoAP) Hop-Limit Option |
| |
| Authors: | M. Boucadair, T. Reddy.K, J. Shallow. |
| Date: | March 2020 |
| Formats: | txt pdf html xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8768 |
|
The presence of Constrained Application Protocol (CoAP) proxies may lead to infinite forwarding loops, which is undesirable. To prevent and detect such loops, this document specifies the Hop-Limit CoAP option. |
|
| |
| RFC 8770 | Host Router Support for OSPFv2 |
| |
| Authors: | K. Patel, P. Pillay-Esnault, M. Bhardwaj, S. Bayraktar. |
| Date: | April 2020 |
| Formats: | txt xml pdf html json |
| Updates: | RFC 6987 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8770 |
|
The Open Shortest Path First Version 2 (OSPFv2) protocol does not have a mechanism for a node to repel transit traffic if it is on the shortest path. This document defines a bit called the Host-bit(H-bit). This bit enables a router to advertise that it is a non- transit router. This document also describes the changes needed to support the H-bit in the domain. In addition, this document updatesRFC 6987 to advertise Type 2 External and Not-So-Stubby Area (NSSA)Link State Advertisements (LSAs) (RFC 3101) with a high cost in order to repel traffic effectively. |
|
| |
| RFC 8775 | PIM Designated Router Load Balancing |
| |
| Authors: | Y. Cai, H. Ou, S. Vallepalli, M. Mishra, S. Venaas, A. Green. |
| Date: | April 2020 |
| Formats: | txt html json pdf xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8775 |
|
On a multi-access network, one of the PIM-SM (PIM Sparse Mode) routers is elected as a Designated Router. One of the responsibilities of the Designated Router is to track local multicast listeners and forward data to these listeners if the group is operating in PIM-SM. This document specifies a modification to thePIM-SM protocol that allows more than one of the PIM-SM routers to take on this responsibility so that the forwarding load can be distributed among multiple routers. |
|
| |
| RFC 8776 | Common YANG Data Types for Traffic Engineering |
| |
| Authors: | T. Saad, R. Gandhi, X. Liu, V. Beeram, I. Bryskin. |
| Date: | June 2020 |
| Formats: | txt json xml pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8776 |
|
This document defines a collection of common data types and groupings in YANG data modeling language. These derived common types and groupings are intended to be imported by modules that model TrafficEngineering (TE) configuration and state capabilities. |
|
| |
| RFC 8777 | DNS Reverse IP Automatic Multicast Tunneling (AMT) Discovery |
| |
|
|
This document updates RFC 7450, "Automatic Multicast Tunneling" (orAMT), by modifying the relay discovery process. A new DNS resource record named AMTRELAY is defined for publishing AMT relays for source-specific multicast channels. The reverse IP DNS zone for a multicast sender's IP address is configured to use AMTRELAY resource records to advertise a set of AMT relays that can receive and forward multicast traffic from that sender over an AMT tunnel. Other extensions and clarifications to the relay discovery process are also defined. |
|
| |
| RFC 8778 | Use of the HSS/LMS Hash-Based Signature Algorithm with CBOR Object Signing and Encryption (COSE) |
| |
|
|
This document specifies the conventions for using the HierarchicalSignature System (HSS) / Leighton-Micali Signature (LMS) hash-based signature algorithm with the CBOR Object Signing and Encryption(COSE) syntax. The HSS/LMS algorithm is one form of hash-based digital signature; it is described in RFC 8554. |
|
| |
| RFC 8779 | Path Computation Element Communication Protocol (PCEP) Extensions for GMPLS |
| |
| Authors: | C. Margaria, Ed., O. Gonzalez de Dios, Ed., F. Zhang, Ed.. |
| Date: | July 2020 |
| Formats: | txt xml pdf html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8779 |
|
A Path Computation Element (PCE) provides path computation functions for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. Additional requirements for GMPLS are identified in RFC7025.
This memo provides extensions to the Path Computation ElementCommunication Protocol (PCEP) for the support of the GMPLS control plane to address those requirements. |
|
| |
| RFC 8780 | The Path Computation Element Communication Protocol (PCEP) Extension for Wavelength Switched Optical Network (WSON) Routing and Wavelength Assignment (RWA) |
| |
| Authors: | Y. Lee, Ed., R. Casellas, Ed.. |
| Date: | July 2020 |
| Formats: | txt html json xml pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8780 |
|
This document provides Path Computation Element CommunicationProtocol (PCEP) extensions for the support of Routing and WavelengthAssignment (RWA) in Wavelength Switched Optical Networks (WSONs).Path provisioning in WSONs requires an RWA process. From a path computation perspective, wavelength assignment is the process of determining which wavelength can be used on each hop of a path and forms an additional routing constraint to optical path computation. |
|
| |
| RFC 8781 | Discovering PREF64 in Router Advertisements |
| |
|
|
This document specifies a Neighbor Discovery option to be used inRouter Advertisements (RAs) to communicate prefixes of NetworkAddress and Protocol Translation from IPv6 clients to IPv4 servers(NAT64) to hosts. |
|
| |
| RFC 8782 | Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification |
| |
| Authors: | T. Reddy.K, Ed., M. Boucadair, Ed., P. Patil, A. Mortensen, N. Teague. |
| Date: | May 2020 |
| Formats: | txt pdf xml json html |
| Obsoleted by: | RFC 9132 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8782 |
|
This document specifies the Distributed Denial-of-Service Open ThreatSignaling (DOTS) signal channel, a protocol for signaling the need for protection against Distributed Denial-of-Service (DDoS) attacks to a server capable of enabling network traffic mitigation on behalf of the requesting client.
A companion document defines the DOTS data channel, a separate reliable communication layer for DOTS management and configuration purposes. |
|
| |
| RFC 8783 | Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification |
| |
| Authors: | M. Boucadair, Ed., T. Reddy.K, Ed.. |
| Date: | May 2020 |
| Formats: | txt json pdf xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8783 |
|
The document specifies a Distributed Denial-of-Service Open ThreatSignaling (DOTS) data channel used for bulk exchange of data that cannot easily or appropriately communicated through the DOTS signal channel under attack conditions.
This is a companion document to "Distributed Denial-of-Service OpenThreat Signaling (DOTS) Signal Channel Specification" (RFC 8782). |
|
| |
| RFC 8784 | Mixing Preshared Keys in the Internet Key Exchange Protocol Version 2 (IKEv2) for Post-quantum Security |
| |
| Authors: | S. Fluhrer, P. Kampanakis, D. McGrew, V. Smyslov. |
| Date: | June 2020 |
| Formats: | txt pdf html xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8784 |
|
The possibility of quantum computers poses a serious challenge to cryptographic algorithms deployed widely today. The Internet KeyExchange Protocol Version 2 (IKEv2) is one example of a cryptosystem that could be broken; someone storing VPN communications today could decrypt them at a later time when a quantum computer is available.It is anticipated that IKEv2 will be extended to support quantum- secure key exchange algorithms; however, that is not likely to happen in the near term. To address this problem before then, this document describes an extension of IKEv2 to allow it to be resistant to a quantum computer by using preshared keys. |
|
| |
| RFC 8786 | Updated Rules for Processing Stateful PCE Request Parameters Flags |
| |
|
|
Extensions to the Path Computation Element Communication Protocol(PCEP) to support stateful Path Computation Elements (PCEs) are defined in RFC 8231. One of the extensions is the Stateful PCERequest Parameters (SRP) object. That object includes a Flags field that is a set of 32 bit flags, and RFC 8281 defines an IANA registry for tracking assigned flags. However, RFC 8231 does not explain how an implementation should set unassigned flags in transmitted messages, nor how an implementation should process unassigned, unknown, or unsupported flags in received messages.
This document updates RFC 8231 by defining the correct behaviors. |
|
| |
| RFC 8787 | Location Source Parameter for the SIP Geolocation Header Field |
| |
| Authors: | J. Winterbottom, R. Jesske, B. Chatras, A. Hutton. |
| Date: | May 2020 |
| Formats: | txt json xml pdf html |
| Updates: | RFC 6442 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8787 |
|
There are some circumstances where a Geolocation header field may contain more than one locationValue. Knowing the identity of the node adding the locationValue allows the recipient more freedom in selecting the value to look at first rather than relying solely on the order of the locationValues. This document defines the "loc-src" parameter so that the entity adding the locationValue to theGeolocation header field can identify itself using its hostname.This document updates RFC 6442. |
|
| |
| RFC 8790 | FETCH and PATCH with Sensor Measurement Lists (SenML) |
| |
|
|
The Sensor Measurement Lists (SenML) media type and data model can be used to send collections of resources, such as batches of sensor data or configuration parameters. The Constrained Application Protocol(CoAP) FETCH, PATCH, and iPATCH methods enable accessing and updating parts of a resource or multiple resources with one request. This document defines new media types for the CoAP FETCH, PATCH, and iPATCH methods for resources represented using the SenML data model. |
|
| |
| RFC 8791 | YANG Data Structure Extensions |
| |
|
|
This document describes YANG mechanisms for defining abstract data structures with YANG. |
|
| |
| RFC 8794 | Extensible Binary Meta Language |
| |
| Authors: | S. Lhomme, D. Rice, M. Bunkus. |
| Date: | July 2020 |
| Formats: | txt xml pdf html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8794 |
|
This document defines the Extensible Binary Meta Language (EBML) format as a binary container format designed for audio/video storage.EBML is designed as a binary equivalent to XML and uses a storage- efficient approach to build nested Elements with identifiers, lengths, and values. Similar to how an XML Schema defines the structure and semantics of an XML Document, this document defines howEBML Schemas are created to convey the semantics of an EBML Document. |
|
| |
| RFC 8795 | YANG Data Model for Traffic Engineering (TE) Topologies |
| |
| Authors: | X. Liu, I. Bryskin, V. Beeram, T. Saad, H. Shah, O. Gonzalez de Dios. |
| Date: | August 2020 |
| Formats: | txt html xml pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8795 |
|
This document defines a YANG data model for representing, retrieving, and manipulating Traffic Engineering (TE) Topologies. The model serves as a base model that other technology-specific TE topology models can augment. |
|
| |
| RFC 8796 | RSVP-TE Summary Fast Reroute Extensions for Label Switched Path (LSP) Tunnels |
| |
| Authors: | M. Taillon, T. Saad, Ed., R. Gandhi, A. Deshmukh, M. Jork, V. Beeram. |
| Date: | July 2020 |
| Formats: | txt json pdf xml html |
| Updates: | RFC 4090 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8796 |
|
This document updates RFC 4090 for the Resource Reservation Protocol(RSVP) Traffic Engineering (TE) procedures defined for facility backup protection. The updates include extensions that reduce the amount of signaling and processing that occurs during Fast Reroute(FRR); as a result, scalability when undergoing FRR convergence after a link or node failure is improved. These extensions allow the RSVP message exchange between the Point of Local Repair (PLR) and theMerge Point (MP) nodes to be independent of the number of protectedLabel Switched Paths (LSPs) traversing between them when facility bypass FRR protection is used. The signaling extensions are fully backwards compatible with nodes that do not support them. |
|
| |
| RFC 8797 | Remote Direct Memory Access - Connection Manager (RDMA-CM) Private Data for RPC-over-RDMA Version 1 |
| |
|
|
This document specifies the format of Remote Direct Memory Access -Connection Manager (RDMA-CM) Private Data exchanged between RPC-over-RDMA version 1 peers as part of establishing a connection. The addition of the Private Data payload specified in this document is an optional extension that does not alter the RPC-over-RDMA version 1 protocol. This document updates RFC 8166. |
|
| |
| RFC 8798 | Additional Units for Sensor Measurement Lists (SenML) |
| |
|
|
The Sensor Measurement Lists (SenML) media type supports the indication of units for a quantity represented. This short document registers a number of additional unit names in the IANA registry for units in SenML. It also defines a registry for secondary units that cannot be in SenML's main registry, as they are derived by linear transformation from units already in that registry. |
|
| |
| RFC 8800 | Path Computation Element Communication Protocol (PCEP) Extension for Label Switched Path (LSP) Diversity Constraint Signaling |
| |
| Authors: | S. Litkowski, S. Sivabalan, C. Barth, M. Negi. |
| Date: | July 2020 |
| Formats: | txt json xml html pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8800 |
|
This document introduces a simple mechanism to associate a group ofLabel Switched Paths (LSPs) via an extension to the Path ComputationElement Communication Protocol (PCEP) with the purpose of computing diverse (disjointed) paths for those LSPs. The proposed extension allows a Path Computation Client (PCC) to advertise to a PathComputation Element (PCE) that a particular LSP belongs to a particular Disjoint Association Group; thus, the PCE knows that theLSPs in the same group need to be disjoint from each other. |
|
| |
| RFC 8801 | Discovering Provisioning Domain Names and Data |
| |
| Authors: | P. Pfister, É. Vyncke, T. Pauly, D. Schinazi, W. Shao. |
| Date: | July 2020 |
| Formats: | txt json xml html pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8801 |
|
Provisioning Domains (PvDs) are defined as consistent sets of network configuration information. PvDs allows hosts to manage connections to multiple networks and interfaces simultaneously, such as when a home router provides connectivity through both a broadband and cellular network provider.
This document defines a mechanism for explicitly identifying PvDs through a Router Advertisement (RA) option. This RA option announces a PvD identifier, which hosts can compare to differentiate betweenPvDs. The option can directly carry some information about a PvD and can optionally point to PvD Additional Information that can be retrieved using HTTP over TLS. |
|
| |
| RFC 8804 | Content Delivery Network Interconnection (CDNI) Request Routing Extensions |
| |
| Authors: | O. Finkelman, S. Mishra. |
| Date: | September 2020 |
| Formats: | txt pdf json xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8804 |
|
Open Caching architecture is a use case of Content Delivery NetworkInterconnection (CDNI) in which the commercial Content DeliveryNetwork (CDN) is the upstream CDN (uCDN) and the ISP caching layer serves as the downstream CDN (dCDN). This document defines extensions to the CDNI Metadata Interface (MI) and the Footprint &Capabilities Advertisement interface (FCI). These extensions are derived from requirements raised by Open Caching but are also applicable to CDNI use cases in general. |
|
| |
| RFC 8807 | Login Security Extension for the Extensible Provisioning Protocol (EPP) |
| |
|
|
The Extensible Provisioning Protocol (EPP) includes a client authentication scheme that is based on a user identifier and password. The structure of the password field is defined by an XMLSchema data type that specifies minimum and maximum password length values, but there are no other provisions for password management other than changing the password. This document describes an EPP extension that allows longer passwords to be created and adds additional security features to the EPP login command and response. |
|
| |
| RFC 8808 | A YANG Data Model for Factory Default Settings |
| |
| Authors: | Q. Wu, B. Lengyel, Y. Niu. |
| Date: | August 2020 |
| Formats: | txt json xml pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8808 |
|
This document defines a YANG data model with the "factory-reset" RPC to allow clients to reset a server back to its factory default condition. It also defines an optional "factory-default" datastore to allow clients to read the factory default configuration for the device.
The YANG data model in this document conforms to the NetworkManagement Datastore Architecture (NMDA) defined in RFC 8342. |
|
| |
| RFC 8810 | Revision to Capability Codes Registration Procedures |
| |
|
|
This document updates RFC 5492 by making a change to the registration procedures for BGP Capability Codes. Specifically, the range formerly designated "Private Use" is divided into three new ranges:"First Come First Served", "Experimental Use", and "Reserved". |
|
| |
| RFC 8812 | CBOR Object Signing and Encryption (COSE) and JSON Object Signing and Encryption (JOSE) Registrations for Web Authentication (WebAuthn) Algorithms |
| |
|
|
The W3C Web Authentication (WebAuthn) specification and the FIDOAlliance FIDO2 Client to Authenticator Protocol (CTAP) specification use CBOR Object Signing and Encryption (COSE) algorithm identifiers.This specification registers the following algorithms (which are used by WebAuthn and CTAP implementations) in the IANA "COSE Algorithms" registry: RSASSA-PKCS1-v1_5 using SHA-256, SHA-384, SHA-512, and SHA-1; and Elliptic Curve Digital Signature Algorithm (ECDSA) using the secp256k1 curve and SHA-256. It registers the secp256k1 elliptic curve in the IANA "COSE Elliptic Curves" registry. Also, for use with JSON Object Signing and Encryption (JOSE), it registers the algorithm ECDSA using the secp256k1 curve and SHA-256 in the IANA"JSON Web Signature and Encryption Algorithms" registry and the secp256k1 elliptic curve in the IANA "JSON Web Key Elliptic Curve" registry. |
|
| |
| RFC 8813 | Clarifications for Elliptic Curve Cryptography Subject Public Key Information |
| |
|
|
This document updates RFC 5480 to specify semantics for the keyEncipherment and dataEncipherment key usage bits when used in certificates that support Elliptic Curve Cryptography. |
|
| |
| RFC 8814 | Signaling Maximum SID Depth (MSD) Using the Border Gateway Protocol - Link State |
| |
| Authors: | J. Tantsura, U. Chunduri, K. Talaulikar, G. Mirsky, N. Triantafillis. |
| Date: | August 2020 |
| Formats: | txt json xml pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8814 |
|
This document defines a way for a Border Gateway Protocol - LinkState (BGP-LS) speaker to advertise multiple types of supportedMaximum SID Depths (MSDs) at node and/or link granularity.
Such advertisements allow entities (e.g., centralized controllers) to determine whether a particular Segment Identifier (SID) stack can be supported in a given network. |
|
| |
| RFC 8817 | RTP Payload Format for Tactical Secure Voice Cryptographic Interoperability Specification (TSVCIS) Codec |
| |
| Authors: | V. Demjanenko, J. Punaro, D. Satterlee. |
| Date: | August 2020 |
| Formats: | txt html pdf json xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8817 |
|
This document describes the RTP payload format for the TacticalSecure Voice Cryptographic Interoperability Specification (TSVCIS) speech coder. TSVCIS is a scalable narrowband voice coder supporting varying encoder data rates and fallbacks. It is implemented as an augmentation to the Mixed Excitation Linear Prediction Enhanced(MELPe) speech coder by conveying additional speech coder parameters to enhance voice quality. TSVCIS augmented speech data is processed in conjunction with its temporally matched Mixed Excitation LinearPrediction (MELP) 2400 speech data. The RTP packetization of TSVCIS and MELPe speech coder data is described in detail. |
|
| |
| RFC 8819 | YANG Module Tags |
| |
|
|
This document provides for the association of tags with YANG modules.The expectation is for such tags to be used to help classify and organize modules. A method for defining, reading, and writing modules tags is provided. Tags may be registered and assigned during module definition, assigned by implementations, or dynamically defined and set by users. This document also provides guidance to future model writers; as such, this document updates RFC 8407. |
|
| |
| RFC 8824 | Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP) |
| |
| Authors: | A. Minaburo, L. Toutain, R. Andreasen. |
| Date: | June 2021 |
| Formats: | txt json html pdf xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8824 |
|
This document defines how to compress Constrained ApplicationProtocol (CoAP) headers using the Static Context Header Compression and fragmentation (SCHC) framework. SCHC defines a header compression mechanism adapted for Constrained Devices. SCHC uses a static description of the header to reduce the header's redundancy and size. While RFC 8724 describes the SCHC compression and fragmentation framework, and its application for IPv6/UDP headers, this document applies SCHC to CoAP headers. The CoAP header structure differs from IPv6 and UDP, since CoAP uses a flexible header with a variable number of options, themselves of variable length. The CoAP message format is asymmetric: the request messages have a header format different from the format in the response messages. This specification gives guidance on applying SCHC to flexible headers and how to leverage the asymmetry for more efficient compression Rules. |
|
| |
| RFC 8825 | Overview: Real-Time Protocols for Browser-Based Applications |
| |
|
|
This document gives an overview and context of a protocol suite intended for use with real-time applications that can be deployed in browsers -- "real-time communication on the Web".
It intends to serve as a starting and coordination point to make sure that (1) all the parts that are needed to achieve this goal are findable and (2) the parts that belong in the Internet protocol suite are fully specified and on the right publication track.
This document is an applicability statement -- it does not itself specify any protocol, but it specifies which other specifications implementations are supposed to follow to be compliant with Web Real-Time Communication (WebRTC). |
|
| |
| RFC 8826 | Security Considerations for WebRTC |
| |
|
|
WebRTC is a protocol suite for use with real-time applications that can be deployed in browsers -- "real-time communication on the Web".This document defines the WebRTC threat model and analyzes the security threats of WebRTC in that model. |
|
| |
| RFC 8827 | WebRTC Security Architecture |
| |
|
|
This document defines the security architecture for WebRTC, a protocol suite intended for use with real-time applications that can be deployed in browsers -- "real-time communication on the Web". |
|
| |
| RFC 8828 | WebRTC IP Address Handling Requirements |
| |
|
|
This document provides information and requirements for how IP addresses should be handled by Web Real-Time Communication (WebRTC) implementations. |
|
| |
| RFC 8829 | JavaScript Session Establishment Protocol (JSEP) |
| |
| Authors: | J. Uberti, C. Jennings, E. Rescorla, Ed.. |
| Date: | January 2021 |
| Formats: | txt xml json pdf html |
| Obsoleted by: | RFC 9429 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8829 |
|
This document describes the mechanisms for allowing a JavaScript application to control the signaling plane of a multimedia session via the interface specified in the W3C RTCPeerConnection API and discusses how this relates to existing signaling protocols. |
|
| |
| RFC 8830 | WebRTC MediaStream Identification in the Session Description Protocol |
| |
|
|
This document specifies a Session Description Protocol (SDP) grouping mechanism for RTP media streams that can be used to specify relations between media streams.
This mechanism is used to signal the association between the SDP concept of "media description" and the Web Real-Time Communication(WebRTC) concept of MediaStream/MediaStreamTrack using SDP signaling. |
|
| |
| RFC 8831 | WebRTC Data Channels |
| |
| Authors: | R. Jesup, S. Loreto, M. Tüxen. |
| Date: | January 2021 |
| Formats: | txt pdf xml json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8831 |
|
The WebRTC framework specifies protocol support for direct, interactive, rich communication using audio, video, and data between two peers' web browsers. This document specifies the non-media data transport aspects of the WebRTC framework. It provides an architectural overview of how the Stream Control TransmissionProtocol (SCTP) is used in the WebRTC context as a generic transport service that allows web browsers to exchange generic data from peer to peer. |
|
| |
| RFC 8832 | WebRTC Data Channel Establishment Protocol |
| |
| Authors: | R. Jesup, S. Loreto, M. Tüxen. |
| Date: | January 2021 |
| Formats: | txt html json xml pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8832 |
|
The WebRTC framework specifies protocol support for direct interactive rich communication using audio, video, and data between two peers' web browsers. This document specifies a simple protocol for establishing symmetric data channels between the peers. It uses a two-way handshake and allows sending of user data without waiting for the handshake to complete. |
|
| |
| RFC 8833 | Application-Layer Protocol Negotiation (ALPN) for WebRTC |
| |
|
|
This document specifies two Application-Layer Protocol Negotiation(ALPN) labels for use with Web Real-Time Communication (WebRTC). The"webrtc" label identifies regular WebRTC: a DTLS session that is used to establish keys for the Secure Real-time Transport Protocol (SRTP) or to establish data channels using the Stream Control TransmissionProtocol (SCTP) over DTLS. The "c-webrtc" label describes the same protocol, but the peers also agree to maintain the confidentiality of the media by not sharing it with other applications. |
|
| |
| RFC 8834 | Media Transport and Use of RTP in WebRTC |
| |
| Authors: | C. Perkins, M. Westerlund, J. Ott. |
| Date: | January 2021 |
| Formats: | txt json html xml pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8834 |
|
The framework for Web Real-Time Communication (WebRTC) provides support for direct interactive rich communication using audio, video, text, collaboration, games, etc. between two peers' web browsers.This memo describes the media transport aspects of the WebRTC framework. It specifies how the Real-time Transport Protocol (RTP) is used in the WebRTC context and gives requirements for which RTP features, profiles, and extensions need to be supported. |
|
| |
| RFC 8835 | Transports for WebRTC |
| |
|
|
This document describes the data transport protocols used by WebReal-Time Communication (WebRTC), including the protocols used for interaction with intermediate boxes such as firewalls, relays, andNAT boxes. |
|
| |
| RFC 8837 | Differentiated Services Code Point (DSCP) Packet Markings for WebRTC QoS |
| |
| Authors: | P. Jones, S. Dhesikan, C. Jennings, D. Druta. |
| Date: | January 2021 |
| Formats: | txt html pdf xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8837 |
|
Networks can provide different forwarding treatments for individual packets based on Differentiated Services Code Point (DSCP) values on a per-hop basis. This document provides the recommended DSCP values for web browsers to use for various classes of Web Real-TimeCommunication (WebRTC) traffic. |
|
| |
| RFC 8838 | Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol |
| |
|
|
This document describes "Trickle ICE", an extension to theInteractive Connectivity Establishment (ICE) protocol that enablesICE agents to begin connectivity checks while they are still gathering candidates, by incrementally exchanging candidates over time instead of all at once. This method can considerably accelerate the process of establishing a communication session. |
|
| |
| RFC 8839 | Session Description Protocol (SDP) Offer/Answer Procedures for Interactive Connectivity Establishment (ICE) |
| |
|
|
This document describes Session Description Protocol (SDP) Offer/Answer procedures for carrying out Interactive ConnectivityEstablishment (ICE) between the agents.
This document obsoletes RFCs 5245 and 6336. |
|
| |
| RFC 8840 | A Session Initiation Protocol (SIP) Usage for Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (Trickle ICE) |
| |
| Authors: | E. Ivov, T. Stach, E. Marocco, C. Holmberg. |
| Date: | January 2021 |
| Formats: | txt html json xml pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8840 |
|
The Interactive Connectivity Establishment (ICE) protocol describes aNetwork Address Translator (NAT) traversal mechanism for UDP-based multimedia sessions established with the Offer/Answer model. The ICE extension for Incremental Provisioning of Candidates (Trickle ICE) defines a mechanism that allows ICE Agents to shorten session establishment delays by making the candidate gathering and connectivity checking phases of ICE non-blocking and by executing them in parallel.
This document defines usage semantics for Trickle ICE with theSession Initiation Protocol (SIP). The document also defines a newSIP Info Package to support this usage together with the corresponding media type. Additionally, a new Session DescriptionProtocol (SDP) "end-of-candidates" attribute and a new SIP option tag"trickle-ice" are defined. |
|
| |
| RFC 8841 | Session Description Protocol (SDP) Offer/Answer Procedures for Stream Control Transmission Protocol (SCTP) over Datagram Transport Layer Security (DTLS) Transport |
| |
| Authors: | C. Holmberg, R. Shpount, S. Loreto, G. Camarillo. |
| Date: | January 2021 |
| Formats: | txt html xml pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8841 |
|
The Stream Control Transmission Protocol (SCTP) is a transport protocol used to establish associations between two endpoints. RFC8261 specifies how SCTP can be used on top of the Datagram TransportLayer Security (DTLS) protocol, which is referred to as SCTP-over-DTLS.
This specification defines the following new Session DescriptionProtocol (SDP) protocol identifiers (proto values): "UDP/DTLS/SCTP" and "TCP/DTLS/SCTP". This specification also specifies how to use the new proto values with the SDP offer/answer mechanism for negotiating SCTP-over-DTLS associations. |
|
| |
| RFC 8842 | Session Description Protocol (SDP) Offer/Answer Considerations for Datagram Transport Layer Security (DTLS) and Transport Layer Security (TLS) |
| |
|
|
This document defines the Session Description Protocol (SDP) offer/ answer procedures for negotiating and establishing a DatagramTransport Layer Security (DTLS) association. The document also defines the criteria for when a new DTLS association must be established. The document updates RFCs 5763 and 7345 by replacing common SDP offer/answer procedures with a reference to this specification.
This document defines a new SDP media-level attribute, "tls-id".
This document also defines how the "tls-id" attribute can be used for negotiating and establishing a Transport Layer Security (TLS) connection, in conjunction with the procedures in RFCs 4145 and 8122. |
|
| |
| RFC 8843 | Negotiating Media Multiplexing Using the Session Description Protocol (SDP) |
| |
|
|
This specification defines a new Session Description Protocol (SDP)Grouping Framework extension called 'BUNDLE'. The extension can be used with the SDP offer/answer mechanism to negotiate the usage of a single transport (5-tuple) for sending and receiving media described by multiple SDP media descriptions ("m=" sections). Such transport is referred to as a BUNDLE transport, and the media is referred to as bundled media. The "m=" sections that use the BUNDLE transport form a BUNDLE group.
This specification defines a new RTP Control Protocol (RTCP) SourceDescription (SDES) item and a new RTP header extension.
This specification updates RFCs 3264, 5888, and 7941. |
|
| |
| RFC 8844 | Unknown Key-Share Attacks on Uses of TLS with the Session Description Protocol (SDP) |
| |
|
|
This document describes unknown key-share attacks on the use ofDatagram Transport Layer Security for the Secure Real-Time TransportProtocol (DTLS-SRTP). Similar attacks are described on the use ofDTLS-SRTP with the identity bindings used in Web Real-TimeCommunications (WebRTC) and SIP identity. These attacks are difficult to mount, but they cause a victim to be misled about the identity of a communicating peer. This document defines mitigation techniques that implementations of RFC 8122 are encouraged to deploy. |
|
| |
| RFC 8845 | Framework for Telepresence Multi-Streams |
| |
| Authors: | M. Duckworth, Ed., A. Pepperell, S. Wenger. |
| Date: | January 2021 |
| Formats: | txt html pdf xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8845 |
|
This document defines a framework for a protocol to enable devices in a telepresence conference to interoperate. The protocol enables communication of information about multiple media streams so a sending system and receiving system can make reasonable decisions about transmitting, selecting, and rendering the media streams. This protocol is used in addition to SIP signaling and Session DescriptionProtocol (SDP) negotiation for setting up a telepresence session. |
|
| |
| RFC 8846 | An XML Schema for the Controlling Multiple Streams for Telepresence (CLUE) Data Model |
| |
| Authors: | R. Presta, S P. Romano. |
| Date: | January 2021 |
| Formats: | txt json xml html pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8846 |
|
This document provides an XML schema file for the definition of CLUE data model types. The term "CLUE" stands for "Controlling MultipleStreams for Telepresence" and is the name of the IETF working group in which this document, as well as other companion documents, has been developed. The document defines a coherent structure for information associated with the description of a telepresence scenario. |
|
| |
| RFC 8849 | Mapping RTP Streams to Controlling Multiple Streams for Telepresence (CLUE) Media Captures |
| |
|
|
This document describes how the Real-time Transport Protocol (RTP) is used in the context of the Controlling Multiple Streams forTelepresence (CLUE) protocol. It also describes the mechanisms and recommended practice for mapping RTP media streams, as defined in theSession Description Protocol (SDP), to CLUE Media Captures and defines a new RTP header extension (CaptureID). |
|
| |
| RFC 8851 | RTP Payload Format Restrictions |
| |
|
|
In this specification, we define a framework for specifying restrictions on RTP streams in the Session Description Protocol(SDP). This framework defines a new "rid" ("restriction identifier")SDP attribute to unambiguously identify the RTP streams within an RTP session and restrict the streams' payload format parameters in a codec-agnostic way beyond what is provided with the regular payload types.
This specification updates RFC 4855 to give additional guidance on choice of Format Parameter (fmtp) names and their relation to the restrictions defined by this document. |
|
| |
| RFC 8852 | RTP Stream Identifier Source Description (SDES) |
| |
| Authors: | A.B. Roach, S. Nandakumar, P. Thatcher. |
| Date: | January 2021 |
| Formats: | txt xml pdf json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8852 |
|
This document defines and registers two new Real-time TransportControl Protocol (RTCP) Stream Identifier Source Description (SDES) items. One, named RtpStreamId, is used for unique identification ofRTP streams. The other, RepairedRtpStreamId, can be used to identify which stream is to be repaired using a redundancy RTP stream. |
|
| |
| RFC 8853 | Using Simulcast in Session Description Protocol (SDP) and RTP Sessions |
| |
| Authors: | B. Burman, M. Westerlund, S. Nandakumar, M. Zanaty. |
| Date: | January 2021 |
| Formats: | txt json xml pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8853 |
|
In some application scenarios, it may be desirable to send multiple differently encoded versions of the same media source in differentRTP streams. This is called simulcast. This document describes how to accomplish simulcast in RTP and how to signal it in the SessionDescription Protocol (SDP). The described solution uses an RTP/RTCP identification method to identify RTP streams belonging to the same media source and makes an extension to SDP to indicate that those RTP streams are different simulcast formats of that media source. TheSDP extension consists of a new media-level SDP attribute that expresses capability to send and/or receive simulcast RTP streams. |
|
| |
| RFC 8854 | WebRTC Forward Error Correction Requirements |
| |
|
|
This document provides information and requirements for the use ofForward Error Correction (FEC) by WebRTC implementations. |
|
| |
| RFC 8855 | The Binary Floor Control Protocol (BFCP) |
| |
| Authors: | G. Camarillo, K. Drage, T. Kristensen, J. Ott, C. Eckel. |
| Date: | January 2021 |
| Formats: | txt xml html pdf json |
| Obsoletes: | RFC 4582 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8855 |
|
Floor control is a means to manage joint or exclusive access to shared resources in a (multiparty) conferencing environment.Thereby, floor control complements other functions -- such as conference and media session setup, conference policy manipulation, and media control -- that are realized by other protocols.
This document specifies the Binary Floor Control Protocol (BFCP).BFCP is used between floor participants and floor control servers, and between floor chairs (i.e., moderators) and floor control servers.
This document obsoletes RFC 4582. |
|
| |
| RFC 8856 | Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams |
| |
|
|
This document defines the Session Description Protocol (SDP) offer/ answer procedures for negotiating and establishing Binary FloorControl Protocol (BFCP) streams.
This document obsoletes RFC 4583. |
|
| |
| RFC 8857 | The WebSocket Protocol as a Transport for the Binary Floor Control Protocol (BFCP) |
| |
| Authors: | V. Pascual, A. Román, S. Cazeaux, G. Salgueiro, R. Ravindranath. |
| Date: | January 2021 |
| Formats: | txt json pdf xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8857 |
|
The WebSocket protocol enables two-way real-time communication between clients and servers. This document specifies the use ofBinary Floor Control Protocol (BFCP) as a new WebSocket subprotocol enabling a reliable transport mechanism between BFCP entities in new scenarios. |
|
| |
| RFC 8858 | Indicating Exclusive Support of RTP and RTP Control Protocol (RTCP) Multiplexing Using the Session Description Protocol (SDP) |
| |
|
|
This document defines a new Session Description Protocol (SDP) media- level attribute, 'rtcp-mux-only', that can be used by an endpoint to indicate exclusive support of RTP and RTP Control Protocol (RTCP) multiplexing. The document also updates RFC 5761 by clarifying that an offerer can use a mechanism to indicate that it is not able to send and receive RTCP on separate ports. |
|
| |
| RFC 8859 | A Framework for Session Description Protocol (SDP) Attributes When Multiplexing |
| |
|
|
The purpose of this specification is to provide a framework for analyzing the multiplexing characteristics of Session DescriptionProtocol (SDP) attributes when SDP is used to negotiate the usage of a single 5-tuple for sending and receiving media associated with multiple media descriptions.
This specification also categorizes the existing SDP attributes based on the framework described herein. |
|
| |
| RFC 8860 | Sending Multiple Types of Media in a Single RTP Session |
| |
|
|
This document specifies how an RTP session can contain RTP streams with media from multiple media types such as audio, video, and text.This has been restricted by the RTP specifications (RFCs 3550 and3551), and thus this document updates RFCs 3550 and 3551 to enable this behaviour for applications that satisfy the applicability for using multiple media types in a single RTP session. |
|
| |
| RFC 8861 | Sending Multiple RTP Streams in a Single RTP Session: Grouping RTP Control Protocol (RTCP) Reception Statistics and Other Feedback |
| |
| Authors: | J. Lennox, M. Westerlund, Q. Wu, C. Perkins. |
| Date: | January 2021 |
| Formats: | txt html xml pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8861 |
|
RTP allows multiple RTP streams to be sent in a single session but requires each Synchronization Source (SSRC) to send RTP ControlProtocol (RTCP) reception quality reports for every other SSRC visible in the session. This causes the number of RTCP reception reports to grow with the number of SSRCs, rather than the number of endpoints. In many cases, most of these RTCP reception reports are unnecessary, since all SSRCs of an endpoint are normally co-located and see the same reception quality. This memo defines a ReportingGroup extension to RTCP to reduce the reporting overhead in such scenarios. |
|
| |
| RFC 8863 | Interactive Connectivity Establishment Patiently Awaiting Connectivity (ICE PAC) |
| |
|
|
During the process of establishing peer-to-peer connectivity,Interactive Connectivity Establishment (ICE) agents can encounter situations where they have no candidate pairs to check, and, as a result, conclude that ICE processing has failed. However, because additional candidate pairs can be discovered during ICE processing, declaring failure at this point may be premature. This document discusses when these situations can occur.
This document updates RFCs 8445 and 8838 by requiring that an ICE agent wait a minimum amount of time before declaring ICE failure, even if there are no candidate pairs left to check. |
|
| |
| RFC 8864 | Negotiation Data Channels Using the Session Description Protocol (SDP) |
| |
| Authors: | K. Drage, M. Makaraju, R. Ejzak, J. Marcon, R. Even, Ed.. |
| Date: | January 2021 |
| Formats: | txt html pdf json xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8864 |
|
Data channel setup can be done using either the in-band Data ChannelEstablishment Protocol (DCEP) or some out-of-band non-DCEP protocol.This document specifies how the SDP (Session Description Protocol) offer/answer exchange can be used to achieve an out-of-band non-DCEP negotiation for establishing a data channel. |
|
| |
| RFC 8865 | T.140 Real-Time Text Conversation over WebRTC Data Channels |
| |
|
|
This document specifies how a Web Real-Time Communication (WebRTC) data channel can be used as a transport mechanism for real-time text using the ITU-T Protocol for multimedia application text conversation(Recommendation ITU-T T.140) and how the Session Description Protocol(SDP) offer/answer mechanism can be used to negotiate such a data channel, referred to as a T.140 data channel. This document updatesRFC 8373 to specify its use with WebRTC data channels. |
|
| |
| RFC 8866 | SDP: Session Description Protocol |
| |
| Authors: | A. Begen, P. Kyzivat, C. Perkins, M. Handley. |
| Date: | January 2021 |
| Formats: | txt json xml pdf html |
| Obsoletes: | RFC 4566 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8866 |
|
This memo 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 obsoletes RFC 4566. |
|
| |
| RFC 8870 | Encrypted Key Transport for DTLS and Secure RTP |
| |
| Authors: | C. Jennings, J. Mattsson, D. McGrew, D. Wing, F. Andreasen. |
| Date: | January 2021 |
| Formats: | txt html pdf xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8870 |
|
Encrypted Key Transport (EKT) is an extension to DTLS (DatagramTransport Layer Security) and the Secure Real-time Transport Protocol(SRTP) that provides for the secure transport of SRTP master keys, rollover counters, and other information within SRTP. This facility enables SRTP for decentralized conferences by distributing a common key to all of the conference endpoints. |
|
| |
| RFC 8871 | A Solution Framework for Private Media in Privacy-Enhanced RTP Conferencing (PERC) |
| |
| Authors: | P. Jones, D. Benham, C. Groves. |
| Date: | January 2021 |
| Formats: | txt pdf xml html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8871 |
|
This document describes a solution framework for ensuring that media confidentiality and integrity are maintained end to end within the context of a switched conferencing environment where MediaDistributors are not trusted with the end-to-end media encryption keys. The solution builds upon existing security mechanisms defined for the Real-time Transport Protocol (RTP). |
|
| |
| RFC 8873 | Message Session Relay Protocol (MSRP) over Data Channels |
| |
|
|
This document specifies how a Web Real-Time Communication (WebRTC) data channel can be used as a transport mechanism for the MessageSession Relay Protocol (MSRP) and how the Session DescriptionProtocol (SDP) offer/answer mechanism can be used to negotiate such a data channel, referred to as an MSRP data channel. Two network configurations are supported: the connection of two MSRP data channel endpoints; and a gateway configuration, which connects an MSRP data channel endpoint with an MSRP endpoint that uses either TCP or TLS.This document updates RFC 4975. |
|
| |
| RFC 8876 | Non-interactive Emergency Calls |
| |
| Authors: | B. Rosen, H. Schulzrinne, H. Tschofenig, R. Gellens. |
| Date: | September 2020 |
| Formats: | txt json pdf xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8876 |
|
Use of the Internet for emergency calling is described in RFC 6443,'Framework for Emergency Calling Using Internet Multimedia'. In some cases of emergency calls, the transmission of application data is all that is needed, and no interactive media channel is established: a situation referred to as 'non-interactive emergency calls', where, unlike most emergency calls, there is no two-way interactive media such as voice or video or text. This document describes use of a SIPMESSAGE transaction that includes a container for the data based on the Common Alerting Protocol (CAP). That type of emergency request does not establish a session, distinguishing it from SIP INVITE, which does. Any device that needs to initiate a request for emergency services without an interactive media channel would use the mechanisms in this document. |
|
| |
| RFC 8879 | TLS Certificate Compression |
| |
| Authors: | A. Ghedini, V. Vasiliev. |
| Date: | December 2020 |
| Formats: | txt pdf html xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8879 |
|
In TLS handshakes, certificate chains often take up the majority of the bytes transmitted.
This document describes how certificate chains can be compressed to reduce the amount of data transmitted and avoid some round trips. |
|
| |
| RFC 8880 | Special Use Domain Name 'ipv4only.arpa' |
| |
|
|
NAT64 (Network Address and Protocol Translation from IPv6 Clients toIPv4 Servers) allows client devices using IPv6 to communicate with servers that have only IPv4 connectivity.
The specification for how a client discovers its local network'sNAT64 prefix (RFC 7050) defines the special name 'ipv4only.arpa' for this purpose. However, in its Domain Name Reservation Considerations section (Section 8.1), that specification (RFC 7050) indicates that the name actually has no particularly special properties that would require special handling.
Consequently, despite the well-articulated special purpose of the name, 'ipv4only.arpa' was not recorded in the Special-Use DomainNames registry as a name with special properties.
This document updates RFC 7050. It describes the special treatment required and formally declares the special properties of the name.It also adds similar declarations for the corresponding reverse mapping names. |
|
| |
| RFC 8881 | Network File System (NFS) Version 4 Minor Version 1 Protocol |
| |
|
|
This document describes the Network File System (NFS) version 4 minor version 1, including features retained from the base protocol (NFS version 4 minor version 0, which is specified in RFC 7530) and protocol extensions made subsequently. The later minor version has no dependencies on NFS version 4 minor version 0, and is considered a separate protocol.
This document obsoletes RFC 5661. It substantially revises the treatment of features relating to multi-server namespace, superseding the description of those features appearing in RFC 5661. |
|
| |
| RFC 8883 | ICMPv6 Errors for Discarding Packets Due to Processing Limits |
| |
|
|
Network nodes may discard packets if they are unable to process protocol headers of packets due to processing constraints or limits.When such packets are dropped, the sender receives no indication, so it cannot take action to address the cause of discarded packets.This specification defines several new ICMPv6 errors that can be sent by a node that discards packets because it is unable to process the protocol headers. A node that receives such an ICMPv6 error may use the information to diagnose packet loss and may modify what it sends in future packets to avoid subsequent packet discards. |
|
| |
| RFC 8887 | A JSON Meta Application Protocol (JMAP) Subprotocol for WebSocket |
| |
|
|
This document defines a binding for the JSON Meta ApplicationProtocol (JMAP) over a WebSocket transport layer. The WebSocket binding for JMAP provides higher performance than the current HTTP binding for JMAP. |
|
| |
| RFC 8888 | RTP Control Protocol (RTCP) Feedback for Congestion Control |
| |
| Authors: | Z. Sarker, C. Perkins, V. Singh, M. Ramalho. |
| Date: | January 2021 |
| Formats: | txt html pdf json xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8888 |
|
An effective RTP congestion control algorithm requires more fine- grained feedback on packet loss, timing, and Explicit CongestionNotification (ECN) marks than is provided by the standard RTP ControlProtocol (RTCP) Sender Report (SR) and Receiver Report (RR) packets.This document describes an RTCP feedback message intended to enable congestion control for interactive real-time traffic using RTP. The feedback message is designed for use with a sender-based congestion control algorithm, in which the receiver of an RTP flow sends back to the sender RTCP feedback packets containing the information the sender needs to perform congestion control. |
|
| |
| RFC 8892 | Guidelines and Registration Procedures for Interface Types and Tunnel Types |
| |
|
|
This document provides guidelines and procedures for those who are defining, registering, or evaluating definitions of new interface types ("ifType" values) and tunnel types. The original definition of the IANA interface type registry predated the use of IANAConsiderations sections and YANG modules, so some confusion arose over time. Tunnel types were added later, with the same requirements and allocation policy as interface types. This document updates RFC2863 and provides updated guidance for these registries. |
|
| |
| RFC 8893 | Resource Public Key Infrastructure (RPKI) Origin Validation for BGP Export |
| |
|
|
A BGP speaker may perform Resource Public Key Infrastructure (RPKI) origin validation not only on routes received from BGP neighbors and routes that are redistributed from other routing protocols, but also on routes it sends to BGP neighbors. For egress policy, it is important that the classification use the 'effective origin AS' of the processed route, which may specifically be altered by the commonly available knobs, such as removing private ASes, confederation handling, and other modifications of the origin AS.This document updates RFC 6811. |
|
| |
| RFC 8895 | Application-Layer Traffic Optimization (ALTO) Incremental Updates Using Server-Sent Events (SSE) |
| |
|
|
The Application-Layer Traffic Optimization (ALTO) protocol (RFC 7285) provides network-related information, called network information resources, to client applications so that clients can make informed decisions in utilizing network resources. This document presents a mechanism to allow an ALTO server to push updates to ALTO clients to achieve two benefits: (1) updates can be incremental, in that if only a small section of an information resource changes, the ALTO server can send just the changes and (2) updates can be immediate, in that the ALTO server can send updates as soon as they are available. |
|
| |
| RFC 8896 | Application-Layer Traffic Optimization (ALTO) Cost Calendar |
| |
| Authors: | S. Randriamasy, R. Yang, Q. Wu, L. Deng, N. Schwan. |
| Date: | November 2020 |
| Formats: | txt json html xml pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8896 |
|
This document is an extension to the base Application-Layer TrafficOptimization (ALTO) protocol. It extends the ALTO cost information service so that applications decide not only 'where' to connect but also 'when'. This is useful for applications that need to perform bulk data transfer and would like to schedule these transfers during an off-peak hour, for example. This extension introduces the ALTOCost Calendar with which an ALTO Server exposes ALTO cost values inJSON arrays where each value corresponds to a given time interval.The time intervals, as well as other Calendar attributes, are specified in the Information Resources Directory and ALTO Server responses. |
|
| |
| RFC 8898 | Third-Party Token-Based Authentication and Authorization for Session Initiation Protocol (SIP) |
| |
|
|
This document defines the "Bearer" authentication scheme for theSession Initiation Protocol (SIP) and a mechanism by which user authentication and SIP registration authorization is delegated to a third party, using the OAuth 2.0 framework and OpenID Connect Core1.0. This document updates RFC 3261 to provide guidance on how a SIPUser Agent Client (UAC) responds to a SIP 401/407 response that contains multiple WWW-Authenticate/Proxy-Authenticate header fields. |
|
| |
| RFC 8899 | Packetization Layer Path MTU Discovery for Datagram Transports |
| |
|
|
This document specifies Datagram Packetization Layer Path MTUDiscovery (DPLPMTUD). This is a robust method for Path MTU Discovery(PMTUD) for datagram Packetization Layers (PLs). It allows a PL, or a datagram application that uses a PL, to discover whether a network path can support the current size of datagram. This can be used to detect and reduce the message size when a sender encounters a packet black hole. It can also probe a network path to discover whether the maximum packet size can be increased. This provides functionality for datagram transports that is equivalent to the PLPMTUD specification for TCP, specified in RFC 4821, which it updates. It also updates the UDP Usage Guidelines to refer to this method for use with UDP datagrams and updates SCTP.
The document provides implementation notes for incorporating DatagramPMTUD into IETF datagram transports or applications that use datagram transports.
This specification updates RFC 4960, RFC 4821, RFC 6951, RFC 8085, and RFC 8261. |
|
| |
| RFC 8908 | Captive Portal API |
| |
| Authors: | T. Pauly, Ed., D. Thakore, Ed.. |
| Date: | September 2020 |
| Formats: | txt html pdf xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8908 |
|
This document describes an HTTP API that allows clients to interact with a Captive Portal system. With this API, clients can discover how to get out of captivity and fetch state about their CaptivePortal sessions. |
|
| |
| RFC 8909 | Registry Data Escrow Specification |
| |
|
|
This document specifies the format and contents of data escrow deposits targeted primarily for domain name registries. The specification is designed to be independent of the underlying objects that are being escrowed, and therefore it could also be used for purposes other than domain name registries. |
|
| |
| RFC 8910 | Captive-Portal Identification in DHCP and Router Advertisements (RAs) |
| |
|
|
In many environments offering short-term or temporary Internet access(such as coffee shops), it is common to start new connections in a captive portal mode. This highly restricts what the user can do until the user has satisfied the captive portal conditions.
This document describes a DHCPv4 and DHCPv6 option and a RouterAdvertisement (RA) option to inform clients that they are behind some sort of captive portal enforcement device, and that they will need to satisfy the Captive Portal conditions to get Internet access. It is not a full solution to address all of the issues that clients may have with captive portals; it is designed to be one component of a standardized approach for hosts to interact with such portals. While this document defines how the network operator may convey the captive portal API endpoint to hosts, the specific methods of satisfying and interacting with the captive portal are out of scope of this document.
This document replaces RFC 7710, which used DHCP code point 160. Due to a conflict, this document specifies 114. Consequently, this document also updates RFC 3679. |
|
| |
| RFC 8911 | Registry for Performance Metrics |
| |
| Authors: | M. Bagnulo, B. Claise, P. Eardley, A. Morton, A. Akhter. |
| Date: | November 2021 |
| Formats: | txt html json xml pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8911 |
|
This document defines the format for the IANA Registry of PerformanceMetrics. This document also gives a set of guidelines for RegisteredPerformance Metric requesters and reviewers. |
|
| |
| RFC 8912 | Initial Performance Metrics Registry Entries |
| |
| Authors: | A. Morton, M. Bagnulo, P. Eardley, K. D'Souza. |
| Date: | November 2021 |
| Formats: | txt json pdf xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8912 |
|
This memo defines the set of initial entries for the IANA Registry ofPerformance Metrics. The set includes UDP Round-Trip Latency andLoss, Packet Delay Variation, DNS Response Latency and Loss, UDPPoisson One-Way Delay and Loss, UDP Periodic One-Way Delay and Loss,ICMP Round-Trip Latency and Loss, and TCP Round-Trip Delay and Loss. |
|
| |
| RFC 8913 | Two-Way Active Measurement Protocol (TWAMP) YANG Data Model |
| |
| Authors: | R. Civil, A. Morton, R. Rahman, M. Jethanandani, K. Pentikousis, Ed.. |
| Date: | November 2021 |
| Formats: | txt pdf json xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8913 |
|
This document specifies a data model for client and server implementations of the Two-Way Active Measurement Protocol (TWAMP).This document defines the TWAMP data model through Unified ModelingLanguage (UML) class diagrams and formally specifies it using theYANG data modeling language (RFC 7950). The data model is compliant with the Network Management Datastore Architecture (NMDA). |
|
| |
| RFC 8914 | Extended DNS Errors |
| |
| Authors: | W. Kumari, E. Hunt, R. Arends, W. Hardaker, D. Lawrence. |
| Date: | October 2020 |
| Formats: | txt html pdf xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8914 |
|
This document defines an extensible method to return additional information about the cause of DNS errors. Though created primarily to extend SERVFAIL to provide additional information about the cause of DNS and DNSSEC failures, the Extended DNS Errors option defined in this document allows all response types to contain extended error information. Extended DNS Error information does not change the processing of RCODEs. |
|
| |
| RFC 8915 | Network Time Security for the Network Time Protocol |
| |
| Authors: | D. Franke, D. Sibold, K. Teichel, M. Dansarie, R. Sundblad. |
| Date: | September 2020 |
| Formats: | txt pdf xml html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8915 |
|
This memo specifies Network Time Security (NTS), a mechanism for using Transport Layer Security (TLS) and Authenticated Encryption with Associated Data (AEAD) to provide cryptographic security for the client-server mode of the Network Time Protocol (NTP).
NTS is structured as a suite of two loosely coupled sub-protocols.The first (NTS Key Establishment (NTS-KE)) handles initial authentication and key establishment over TLS. The second (NTSExtension Fields for NTPv4) handles encryption and authentication during NTP time synchronization via extension fields in the NTP packets, and holds all required state only on the client via opaque cookies. |
|
| |
| RFC 8916 | A YANG Data Model for the Multicast Source Discovery Protocol (MSDP) |
| |
| Authors: | X. Liu, Z. Zhang, Ed., A. Peter, M. Sivakumar, F. Guo, P. McAllister. |
| Date: | October 2020 |
| Formats: | txt json xml html pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8916 |
|
This document defines a YANG data model for the configuration and management of Multicast Source Discovery Protocol (MSDP) protocol operations. |
|
| |
| RFC 8917 | The LoST-Validation Straightforward-Naming Authority PoinTeR (S-NAPTR) Application Service Tag |
| |
|
|
This document adds the 'LoST-Validation' service tag to theStraightforward-Naming Authority PoinTeR (S-NAPTR) ApplicationService Tag IANA registry. This tag can appear in a Naming AuthorityPointer (NAPTR) Domain Name System (DNS) record to assist clients of the Location-to-Service Translation (LoST) Protocol in identifyingLoST servers designated for location validation. This tag and the information about its use update RFC 5222, which enables the explicit discovery of a server that supports location validation. |
|
| |
| RFC 8918 | Invalid TLV Handling in IS-IS |
| |
|
|
The key to the extensibility of the Intermediate System toIntermediate System (IS-IS) protocol has been the handling of unsupported and/or invalid Type-Length-Value (TLV) tuples. Although there are explicit statements in existing specifications, deployment experience has shown that there are inconsistencies in the behavior when a TLV that is disallowed in a particular Protocol Data Unit(PDU) is received.
This document discusses such cases and makes the correct behavior explicit in order to ensure that interoperability is maximized.
This document updates RFCs 5305 and 6232. |
|
| |
| RFC 8919 | IS-IS Application-Specific Link Attributes |
| |
| Authors: | L. Ginsberg, P. Psenak, S. Previdi, W. Henderickx, J. Drake. |
| Date: | October 2020 |
| Formats: | txt html json xml pdf |
| Obsoleted by: | RFC 9479 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8919 |
|
Existing traffic-engineering-related link attribute advertisements have been defined and are used in RSVP-TE deployments. Since the original RSVP-TE use case was defined, additional applications (e.g.,Segment Routing Policy and Loop-Free Alternates) that also make use of the link attribute advertisements have been defined. In cases where multiple applications wish to make use of these link attributes, the current advertisements do not support application- specific values for a given attribute, nor do they support indication of which applications are using the advertised value for a given link. This document introduces new link attribute advertisements that address both of these shortcomings. |
|
| |
| RFC 8920 | OSPF Application-Specific Link Attributes |
| |
| Authors: | P. Psenak, Ed., L. Ginsberg, W. Henderickx, J. Tantsura, J. Drake. |
| Date: | October 2020 |
| Formats: | txt pdf xml html json |
| Obsoleted by: | RFC 9492 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8920 |
|
Existing traffic-engineering-related link attribute advertisements have been defined and are used in RSVP-TE deployments. Since the original RSVP-TE use case was defined, additional applications (e.g.,Segment Routing Policy and Loop-Free Alternates) that also make use of the link attribute advertisements have been defined. In cases where multiple applications wish to make use of these link attributes, the current advertisements do not support application- specific values for a given attribute, nor do they support indication of which applications are using the advertised value for a given link. This document introduces new link attribute advertisements inOSPFv2 and OSPFv3 that address both of these shortcomings. |
|
| |
| RFC 8925 | IPv6-Only Preferred Option for DHCPv4 |
| |
| Authors: | L. Colitti, J. Linkova, M. Richardson, T. Mrugalski. |
| Date: | October 2020 |
| Formats: | txt html xml pdf json |
| Updates: | RFC 2563 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8925 |
|
This document specifies a DHCPv4 option to indicate that a host supports an IPv6-only mode and is willing to forgo obtaining an IPv4 address if the network provides IPv6 connectivity. It also updatesRFC 2563 to specify DHCPv4 server behavior when the server receives aDHCPDISCOVER not containing the Auto-Configure option but containing the new option defined in this document. |
|
| |
| RFC 8926 | Geneve: Generic Network Virtualization Encapsulation |
| |
| Authors: | J. Gross, Ed., I. Ganga, Ed., T. Sridhar, Ed.. |
| Date: | November 2020 |
| Formats: | txt pdf xml json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8926 |
|
Network virtualization involves the cooperation of devices with a wide variety of capabilities such as software and hardware tunnel endpoints, transit fabrics, and centralized control clusters. As a result of their role in tying together different elements of the system, the requirements on tunnels are influenced by all of these components. Therefore, flexibility is the most important aspect of a tunneling protocol if it is to keep pace with the evolution of technology. This document describes Geneve, an encapsulation protocol designed to recognize and accommodate these changing capabilities and needs. |
|
| |
| RFC 8928 | Address-Protected Neighbor Discovery for Low-Power and Lossy Networks |
| |
| Authors: | P. Thubert, Ed., B. Sarikaya, M. Sethi, R. Struik. |
| Date: | November 2020 |
| Formats: | txt pdf html xml json |
| Updates: | RFC 8505 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8928 |
|
This document updates the IPv6 over Low-Power Wireless Personal AreaNetwork (6LoWPAN) Neighbor Discovery (ND) protocol defined in RFCs6775 and 8505. The new extension is called Address-ProtectedNeighbor Discovery (AP-ND), and it protects the owner of an address against address theft and impersonation attacks in a Low-Power andLossy Network (LLN). Nodes supporting this extension compute a cryptographic identifier (Crypto-ID), and use it with one or more of their Registered Addresses. The Crypto-ID identifies the owner of the Registered Address and can be used to provide proof of ownership of the Registered Addresses. Once an address is registered with theCrypto-ID and a proof of ownership is provided, only the owner of that address can modify the registration information, thereby enforcing Source Address Validation. |
|
| |
| RFC 8929 | IPv6 Backbone Router |
| |
|
|
This document updates RFCs 6775 and 8505 in order to enable proxy services for IPv6 Neighbor Discovery by Routing Registrars called"Backbone Routers". Backbone Routers are placed along the wireless edge of a backbone and federate multiple wireless links to form a single Multi-Link Subnet (MLSN). |
|
| |
| RFC 8930 | On Forwarding 6LoWPAN Fragments over a Multi-Hop IPv6 Network |
| |
| Authors: | T. Watteyne, Ed., P. Thubert, Ed., C. Bormann. |
| Date: | November 2020 |
| Formats: | txt html xml pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8930 |
|
This document provides generic rules to enable the forwarding of anIPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) fragment over a route-over network. Forwarding fragments can improve both end-to-end latency and reliability as well as reduce the buffer requirements in intermediate nodes; it may be implemented using RFC4944 and Virtual Reassembly Buffers (VRBs). |
|
| |
| RFC 8931 | IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Selective Fragment Recovery |
| |
|
|
This document updates RFC 4944 with a protocol that forwards individual fragments across a route-over mesh and recovers them end to end, with congestion control capabilities to protect the network. |
|
| |
| RFC 8933 | Update to the Cryptographic Message Syntax (CMS) for Algorithm Identifier Protection |
| |
|
|
This document updates the Cryptographic Message Syntax (CMS) specified in RFC 5652 to ensure that algorithm identifiers in signed- data and authenticated-data content types are adequately protected. |
|
| |
| RFC 8934 | PCE Communication Protocol (PCEP) Extensions for Label Switched Path (LSP) Scheduling with Stateful PCE |
| |
| Authors: | H. Chen, Ed., Y. Zhuang, Ed., Q. Wu, D. Ceccarelli. |
| Date: | October 2020 |
| Formats: | txt html pdf json xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8934 |
|
This document defines a set of extensions to the stateful PCECommunication Protocol (PCEP) to enable Label Switched Path (LSP) path computation, activation, setup, and deletion based on scheduled time intervals for the LSP and the actual network resource usage in a centralized network environment, as stated in RFC 8413. |
|
| |
| RFC 8935 | Push-Based Security Event Token (SET) Delivery Using HTTP |
| |
| Authors: | A. Backman, Ed., M. Jones, Ed., M. Scurtescu, M. Ansari, A. Nadalin. |
| Date: | November 2020 |
| Formats: | txt html pdf xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8935 |
|
This specification defines how a Security Event Token (SET) can be delivered to an intended recipient using HTTP POST over TLS. The SET is transmitted in the body of an HTTP POST request to an endpoint operated by the recipient, and the recipient indicates successful or failed transmission via the HTTP response. |
|
| |
| RFC 8936 | Poll-Based Security Event Token (SET) Delivery Using HTTP |
| |
| Authors: | A. Backman, Ed., M. Jones, Ed., M. Scurtescu, M. Ansari, A. Nadalin. |
| Date: | November 2020 |
| Formats: | txt xml pdf json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8936 |
|
This specification defines how a series of Security Event Tokens(SETs) can be delivered to an intended recipient using HTTP POST overTLS initiated as a poll by the recipient. The specification also defines how delivery can be assured, subject to the SET Recipient's need for assurance. |
|
| |
| RFC 8939 | Deterministic Networking (DetNet) Data Plane: IP |
| |
| Authors: | B. Varga, Ed., J. Farkas, L. Berger, D. Fedyk, S. Bryant. |
| Date: | November 2020 |
| Formats: | txt html xml pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8939 |
|
This document specifies the Deterministic Networking (DetNet) data plane operation for IP hosts and routers that provide DetNet service to IP-encapsulated data. No DetNet-specific encapsulation is defined to support IP flows; instead, the existing IP-layer and higher-layer protocol header information is used to support flow identification and DetNet service delivery. This document builds on the DetNet architecture (RFC 8655) and data plane framework (RFC 8938). |
|
| |
| RFC 8940 | Extensible Authentication Protocol (EAP) Session-Id Derivation for EAP Subscriber Identity Module (EAP-SIM), EAP Authentication and Key Agreement (EAP-AKA), and Protected EAP (PEAP) |
| |
|
|
RFC 5247 is updated to define and clarify EAP Session-Id derivation for multiple Extensible Authentication Protocol (EAP) methods. The derivation of Session-Id was not given for EAP Subscriber IdentityModule (EAP-SIM) or EAP Authentication and Key Agreement (EAP-AKA) when using the fast reconnect exchange instead of full authentication. The derivation of Session-Id for full authentication is clarified for both EAP-SIM and EAP-AKA. The derivation ofSession-Id for Protected EAP (PEAP) is also given. The definition for PEAP follows the definition for other TLS-based EAP methods. |
|
| |
| RFC 8941 | Structured Field Values for HTTP |
| |
| Authors: | M. Nottingham, P-H. Kamp. |
| Date: | February 2021 |
| Formats: | txt json pdf xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8941 |
|
This document describes a set of data types and associated algorithms that are intended to make it easier and safer to define and handleHTTP header and trailer fields, known as "Structured Fields","Structured Headers", or "Structured Trailers". It is intended for use by specifications of new HTTP fields that wish to use a common syntax that is more restrictive than traditional HTTP field values. |
|
| |
| RFC 8943 | Concise Binary Object Representation (CBOR) Tags for Date |
| |
| Authors: | M. Jones, A. Nadalin, J. Richter. |
| Date: | November 2020 |
| Formats: | txt xml html pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8943 |
|
The Concise Binary Object Representation (CBOR), as specified in RFC7049, is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation.
In CBOR, one point of extensibility is the definition of CBOR tags.RFC 7049 defines two tags for time: CBOR tag 0 (date/time string as per RFC 3339) and tag 1 (POSIX "seconds since the epoch"). Since then, additional requirements have become known. This specification defines a CBOR tag for a date text string (as per RFC 3339) for applications needing a textual date representation within theGregorian calendar without a time. It also defines a CBOR tag for days since the date 1970-01-01 in the Gregorian calendar for applications needing a numeric date representation without a time.This specification is the reference document for IANA registration of the CBOR tags defined. |
|
| |
| RFC 8944 | A YANG Data Model for Layer 2 Network Topologies |
| |
| Authors: | J. Dong, X. Wei, Q. Wu, M. Boucadair, A. Liu. |
| Date: | November 2020 |
| Formats: | txt xml pdf json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8944 |
|
This document defines a YANG data model for Layer 2 network topologies. In particular, this data model augments the generic network and network topology data models with topology attributes that are specific to Layer 2. |
|
| |
| RFC 8946 | Personal Assertion Token (PASSporT) Extension for Diverted Calls |
| |
|
|
The Personal Assertion Token (PASSporT) is specified in RFC 8225 to convey cryptographically signed information about the people involved in personal communications. This document extends PASSporT to include an indication that a call has been diverted from its original destination to a new one. This information can greatly improve the decisions made by verification services in call forwarding scenarios.Also specified here is an encapsulation mechanism for nesting aPASSporT within another PASSporT that assists relying parties in some diversion scenarios.
This document updates RFC 8224. |
|
| |
| RFC 8947 | Link-Layer Address Assignment Mechanism for DHCPv6 |
| |
| Authors: | B. Volz, T. Mrugalski, C. Bernardos. |
| Date: | December 2020 |
| Formats: | txt html pdf json xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8947 |
|
In certain environments, e.g., large-scale virtualization deployments, new devices are created in an automated manner. Such devices may have their link-layer addresses assigned in an automated fashion. With sufficient scale, the likelihood of a collision using random assignment without duplication detection is not acceptable.Therefore, an allocation mechanism is required. This document proposes an extension to DHCPv6 that allows a scalable approach to link-layer address assignments where preassigned link-layer address assignments (such as by a manufacturer) are not possible or are unnecessary. |
|
| |
| RFC 8948 | Structured Local Address Plan (SLAP) Quadrant Selection Option for DHCPv6 |
| |
| Authors: | CJ. Bernardos, A. Mourad. |
| Date: | December 2020 |
| Formats: | txt json html pdf xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8948 |
|
The IEEE originally structured the 48-bit Media Access Control (MAC) address space in such a way that half of it was reserved for local use. In 2017, the IEEE published a new standard (IEEE Std 802c) with a new optional Structured Local Address Plan (SLAP). It specifies different assignment approaches in four specified regions of the local MAC address space.
The IEEE is developing protocols to assign addresses (IEEE P802.1CQ).There is also work in the IETF on specifying a new mechanism that extends DHCPv6 operation to handle the local MAC address assignments.
This document proposes extensions to DHCPv6 protocols to enable aDHCPv6 client or a DHCPv6 relay to indicate a preferred SLAP quadrant to the server so that the server may allocate MAC addresses in the quadrant requested by the relay or client. A new DHCPv6 option(QUAD) is defined for this purpose. |
|
| |
| RFC 8950 | Advertising IPv4 Network Layer Reachability Information (NLRI) with an IPv6 Next Hop |
| |
| Authors: | S. Litkowski, S. Agrawal, K. Ananthamurthy, K. Patel. |
| Date: | November 2020 |
| Formats: | txt json xml html pdf |
| Obsoletes: | RFC 5549 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8950 |
|
Multiprotocol BGP (MP-BGP) specifies that the set of usable next-hop address families is determined by the Address Family Identifier (AFI) and the Subsequent Address Family Identifier (SAFI). The AFI/SAFI definitions for the IPv4 address family only have provisions for advertising a next-hop address that belongs to the IPv4 protocol when advertising IPv4 Network Layer Reachability Information (NLRI) orVPN-IPv4 NLRI.
This document specifies the extensions necessary to allow the advertising of IPv4 NLRI or VPN-IPv4 NLRI with a next-hop address that belongs to the IPv6 protocol. This comprises an extension of the AFI/SAFI definitions to allow the address of the next hop forIPv4 NLRI or VPN-IPv4 NLRI to also belong to the IPv6 protocol, the encoding of the next hop to determine which of the protocols the address actually belongs to, and a BGP Capability allowing MP-BGP peers to dynamically discover whether they can exchange IPv4 NLRI andVPN-IPv4 NLRI with an IPv6 next hop. This document obsoletes RFC5549. |
|
| |
| RFC 8951 | Clarification of Enrollment over Secure Transport (EST): Transfer Encodings and ASN.1 |
| |
|
|
This document updates RFC 7030: Enrollment over Secure Transport to resolve some errata that were reported and that have proven to cause interoperability issues when RFC 7030 was extended.
This document deprecates the specification of "Content-Transfer-Encoding" headers for Enrollment over Secure Transport (EST) endpoints. This document fixes some syntactical errors in ASN.1 that were present. |
|
| |
| RFC 8954 | Online Certificate Status Protocol (OCSP) Nonce Extension |
| |
|
|
This document specifies the updated format of the Nonce extension in the Online Certificate Status Protocol (OCSP) request and response messages. OCSP is used to check the status of a certificate, and theNonce extension is used to cryptographically bind an OCSP response message to a particular OCSP request message. This document updatesRFC 6960. |
|
| |
| RFC 8955 | Dissemination of Flow Specification Rules |
| |
|
|
This document defines a Border Gateway Protocol Network LayerReachability Information (BGP NLRI) encoding format that can be used to distribute (intra-domain and inter-domain) traffic FlowSpecifications for IPv4 unicast and IPv4 BGP/MPLS VPN services. This allows the routing system to propagate information regarding more specific components of the traffic aggregate defined by an IP destination prefix.
It also specifies BGP Extended Community encoding formats, which can be used to propagate Traffic Filtering Actions along with the FlowSpecification NLRI. Those Traffic Filtering Actions encode actions a routing system can take if the packet matches the Flow Specification.
This document obsoletes both RFC 5575 and RFC 7674. |
|
| |
| RFC 8956 | Dissemination of Flow Specification Rules for IPv6 |
| |
| Authors: | C. Loibl, Ed., R. Raszuk, Ed., S. Hares, Ed.. |
| Date: | December 2020 |
| Formats: | txt html json xml pdf |
| Updates: | RFC 8955 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8956 |
|
"Dissemination of Flow Specification Rules" (RFC 8955) provides aBorder Gateway Protocol (BGP) extension for the propagation of traffic flow information for the purpose of rate limiting or filtering IPv4 protocol data packets.
This document extends RFC 8955 with IPv6 functionality. It also updates RFC 8955 by changing the IANA Flow Spec Component Types registry. |
|
| |
| RFC 8957 | Synonymous Flow Label Framework |
| |
| Authors: | S. Bryant, M. Chen, G. Swallow, S. Sivabalan, G. Mirsky. |
| Date: | January 2021 |
| Formats: | txt html xml pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8957 |
|
RFC 8372 ("MPLS Flow Identification Considerations") describes the requirement for introducing flow identities within the MPLS architecture. This document describes a method of accomplishing this by using a technique called "Synonymous Flow Labels" in which labels that mimic the behavior of other labels provide the identification service. These identifiers can be used to trigger per-flow operations on the packet at the receiving label switching router. |
|
| |
| RFC 8960 | A YANG Data Model for MPLS Base |
| |
| Authors: | T. Saad, K. Raza, R. Gandhi, X. Liu, V. Beeram. |
| Date: | December 2020 |
| Formats: | txt pdf json xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8960 |
|
This document contains a specification of the MPLS base YANG data model. The MPLS base YANG data model serves as a base framework for configuring and managing an MPLS switching subsystem on an MPLS- enabled router. It is expected that other MPLS YANG data models(e.g., MPLS Label Switched Path (LSP) static, LDP, or RSVP-TE YANG data models) will augment the MPLS base YANG data model. |
|
| |
| RFC 8964 | Deterministic Networking (DetNet) Data Plane: MPLS |
| |
| Authors: | B. Varga, Ed., J. Farkas, L. Berger, A. Malis, S. Bryant, J. Korhonen. |
| Date: | January 2021 |
| Formats: | txt json xml pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8964 |
|
This document specifies the Deterministic Networking (DetNet) data plane when operating over an MPLS Packet Switched Network. It leverages existing pseudowire (PW) encapsulations and MPLS TrafficEngineering (MPLS-TE) encapsulations and mechanisms. This document builds on the DetNet architecture and data plane framework. |
|
| |
| RFC 8966 | The Babel Routing Protocol |
| |
|
|
Babel is a loop-avoiding, distance-vector routing protocol that is robust and efficient both in ordinary wired networks and in wireless mesh networks. This document describes the Babel routing protocol and obsoletes RFC 6126 and RFC 7557. |
|
| |
| RFC 8967 | MAC Authentication for the Babel Routing Protocol |
| |
|
|
This document describes a cryptographic authentication mechanism for the Babel routing protocol that has provisions for replay avoidance.This document obsoletes RFC 7298. |
|
| |
| RFC 8968 | Babel Routing Protocol over Datagram Transport Layer Security |
| |
| Authors: | A. Décimo, D. Schinazi, J. Chroboczek. |
| Date: | January 2021 |
| Formats: | txt json pdf xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8968 |
|
The Babel Routing Protocol does not contain any means to authenticate neighbours or provide integrity or confidentiality for messages sent between them. This document specifies a mechanism to ensure these properties using Datagram Transport Layer Security (DTLS). |
|
| |
| RFC 8970 | IMAP4 Extension: Message Preview Generation |
| |
|
|
This document specifies an Internet Message Access Protocol (IMAP) protocol extension that allows a client to request a server-generated abbreviated text representation of message data that is useful as a contextual preview of the entire message. |
|
| |
| RFC 8972 | Simple Two-Way Active Measurement Protocol Optional Extensions |
| |
| Authors: | G. Mirsky, X. Min, H. Nydell, R. Foote, A. Masputra, E. Ruffini. |
| Date: | January 2021 |
| Formats: | txt html json pdf xml |
| Updates: | RFC 8762 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8972 |
|
This document describes optional extensions to Simple Two-way ActiveMeasurement Protocol (STAMP) that enable measurement of performance metrics. The document also defines a STAMP Test Session Identifier and thus updates RFC 8762. |
|
| |
| RFC 8973 | DDoS Open Threat Signaling (DOTS) Agent Discovery |
| |
| Authors: | M. Boucadair, T. Reddy.K. |
| Date: | January 2021 |
| Formats: | txt html pdf json xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8973 |
|
This document specifies mechanisms to configure DDoS Open ThreatSignaling (DOTS) clients with their DOTS servers. The discovery procedure also covers the DOTS signal channel Call Home. It can be useful to know the appropriate DOTS server for a given location in order to engage mitigation actions. This is true even in cases where the DOTS client cannot localize the attack: cases where it only knows that some resources are under attack and that help is needed. |
|
| |
| RFC 8974 | Extended Tokens and Stateless Clients in the Constrained Application Protocol (CoAP) |
| |
|
|
This document provides considerations for alleviating ConstrainedApplication Protocol (CoAP) clients and intermediaries of keeping per-request state. To facilitate this, this document additionally introduces a new, optional CoAP protocol extension for extended token lengths.
This document updates RFCs 7252 and 8323 with an extended definition of the "TKL" field in the CoAP message header. |
|
| |
| RFC 8976 | Message Digest for DNS Zones |
| |
| Authors: | D. Wessels, P. Barber, M. Weinberg, W. Kumari, W. Hardaker. |
| Date: | February 2021 |
| Formats: | txt html xml pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8976 |
|
This document describes a protocol and new DNS Resource Record that provides a cryptographic message digest over DNS zone data at rest.The ZONEMD Resource Record conveys the digest data in the zone itself. When used in combination with DNSSEC, ZONEMD allows recipients to verify the zone contents for data integrity and origin authenticity. This provides assurance that received zone data matches published data, regardless of how the zone data has been transmitted and received. When used without DNSSEC, ZONEMD functions as a checksum, guarding only against unintentional changes.
ZONEMD does not replace DNSSEC: DNSSEC protects individual RRsets(DNS data with fine granularity), whereas ZONEMD protects a zone's data as a whole, whether consumed by authoritative name servers, recursive name servers, or any other applications.
As specified herein, ZONEMD is impractical for large, dynamic zones due to the time and resources required for digest calculation.However, the ZONEMD record is extensible so that new digest schemes may be added in the future to support large, dynamic zones. |
|
| |
| RFC 8977 | Registration Data Access Protocol (RDAP) Query Parameters for Result Sorting and Paging |
| |
| Authors: | M. Loffredo, M. Martinelli, S. Hollenbeck. |
| Date: | January 2021 |
| Formats: | txt xml pdf html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8977 |
|
The Registration Data Access Protocol (RDAP) does not include core functionality for clients to provide sorting and paging parameters for control of large result sets. This omission can lead to unpredictable server processing of queries and client processing of responses. This unpredictability can be greatly reduced if clients can provide servers with their preferences for managing large responses. This document describes RDAP query extensions that allow clients to specify their preferences for sorting and paging result sets. |
|
| |
| RFC 8979 | Subscriber and Performance Policy Identifier Context Headers in the Network Service Header (NSH) |
| |
| Authors: | B. Sarikaya, D. von Hugo, M. Boucadair. |
| Date: | February 2021 |
| Formats: | txt xml json pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8979 |
|
This document defines the Subscriber and Performance PolicyIdentifier Context Headers. These Variable-Length Context Headers can be carried in the Network Service Header (NSH) and are used to inform Service Functions (SFs) of subscriber- and performance-related information for the sake of policy enforcement and appropriateService Function Chaining (SFC) operations. The structure of eachContext Header and their use and processing by NSH-aware nodes are described. |
|
| |
| RFC 8981 | Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6 |
| |
| Authors: | F. Gont, S. Krishnan, T. Narten, R. Draves. |
| Date: | February 2021 |
| Formats: | txt json xml pdf html |
| Obsoletes: | RFC 4941 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8981 |
|
This document describes an extension to IPv6 Stateless AddressAutoconfiguration that causes hosts to generate temporary addresses with randomized interface identifiers for each prefix advertised with autoconfiguration enabled. Changing addresses over time limits the window of time during which eavesdroppers and other information collectors may trivially perform address-based network-activity correlation when the same address is employed for multiple transactions by the same host. Additionally, it reduces the window of exposure of a host as being accessible via an address that becomes revealed as a result of active communication. This document obsoletes RFC 4941. |
|
| |
| RFC 8982 | Registration Data Access Protocol (RDAP) Partial Response |
| |
| Authors: | M. Loffredo, M. Martinelli. |
| Date: | February 2021 |
| Formats: | txt pdf xml html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8982 |
|
The Registration Data Access Protocol (RDAP) does not include capabilities to request partial responses. Servers will only return full responses that include all of the information that a client is authorized to receive. A partial response capability that limits the amount of information returned, especially in the case of search queries, could bring benefits to both clients and servers. This document describes an RDAP query extension that allows clients to specify their preference for obtaining a partial response. |
|
| |
| RFC 8983 | Internet Key Exchange Protocol Version 2 (IKEv2) Notification Status Types for IPv4/IPv6 Coexistence |
| |
|
|
This document specifies new Internet Key Exchange Protocol Version 2(IKEv2) notification status types to better manage IPv4 and IPv6 coexistence by allowing the responder to signal to the initiator which address families are allowed.
This document updates RFC 7296. |
|
| |
| RFC 8984 | JSCalendar: A JSON Representation of Calendar Data |
| |
|
|
This specification defines a data model and JSON representation of calendar data that can be used for storage and data exchange in a calendaring and scheduling environment. It aims to be an alternative and, over time, successor to the widely deployed iCalendar data format. It also aims to be unambiguous, extendable, and simple to process. In contrast to the jCal format, which is also based onJSON, JSCalendar is not a direct mapping from iCalendar but defines the data model independently and expands semantics where appropriate. |
|
| |
| RFC 8985 | The RACK-TLP Loss Detection Algorithm for TCP |
| |
| Authors: | Y. Cheng, N. Cardwell, N. Dukkipati, P. Jha. |
| Date: | February 2021 |
| Formats: | txt json pdf xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8985 |
|
This document presents the RACK-TLP loss detection algorithm for TCP.RACK-TLP uses per-segment transmit timestamps and selective acknowledgments (SACKs) and has two parts. Recent Acknowledgment(RACK) starts fast recovery quickly using time-based inferences derived from acknowledgment (ACK) feedback, and Tail Loss Probe (TLP) leverages RACK and sends a probe packet to trigger ACK feedback to avoid retransmission timeout (RTO) events. Compared to the widely used duplicate acknowledgment (DupAck) threshold approach, RACK-TLP detects losses more efficiently when there are application-limited flights of data, lost retransmissions, or data packet reordering events. It is intended to be an alternative to the DupAck threshold approach. |
|
| |
| RFC 8986 | Segment Routing over IPv6 (SRv6) Network Programming |
| |
| Authors: | C. Filsfils, Ed., P. Camarillo, Ed., J. Leddy, D. Voyer, S. Matsushima, Z. Li. |
| Date: | February 2021 |
| Formats: | txt html xml pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8986 |
|
The Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header.
Each instruction is implemented on one or several nodes in the network and identified by an SRv6 Segment Identifier in the packet.
This document defines the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors that enables the creation of interoperable overlays with underlay optimization. |
|
| |
| RFC 8987 | DHCPv6 Prefix Delegating Relay Requirements |
| |
| Authors: | I. Farrer, N. Kottapalli, M. Hunek, R. Patterson. |
| Date: | February 2021 |
| Formats: | txt html xml json pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8987 |
|
This document describes operational problems that are known to occur when using DHCPv6 relays with prefix delegation. These problems can prevent successful delegation and result in routing failures. To address these problems, this document provides necessary functional requirements for operating DHCPv6 relays with prefix delegation.
It is recommended that any network operator using DHCPv6 prefix delegation with relays ensure that these requirements are followed on their networks. |
|
| |
| RFC 8990 | GeneRic Autonomic Signaling Protocol (GRASP) |
| |
| Authors: | C. Bormann, B. Carpenter, Ed., B. Liu, Ed.. |
| Date: | May 2021 |
| Formats: | txt json html pdf xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8990 |
|
This document specifies the GeneRic Autonomic Signaling Protocol(GRASP), which enables autonomic nodes and Autonomic Service Agents to dynamically discover peers, to synchronize state with each other, and to negotiate parameter settings with each other. GRASP depends on an external security environment that is described elsewhere. The technical objectives and parameters for specific application scenarios are to be described in separate documents. Appendices briefly discuss requirements for the protocol and existing protocols with comparable features. |
|
| |
| RFC 8994 | An Autonomic Control Plane (ACP) |
| |
| Authors: | T. Eckert, Ed., M. Behringer, Ed., S. Bjarnason. |
| Date: | May 2021 |
| Formats: | txt xml json pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8994 |
|
Autonomic functions need a control plane to communicate, which depends on some addressing and routing. This Autonomic Control Plane should ideally be self-managing and be as independent as possible of configuration. This document defines such a plane and calls it the"Autonomic Control Plane", with the primary use as a control plane for autonomic functions. It also serves as a "virtual out-of-band channel" for Operations, Administration, and Management (OAM) communications over a network that provides automatically configured, hop-by-hop authenticated and encrypted communications via automatically configured IPv6 even when the network is not configured or is misconfigured. |
|
| |
| RFC 8995 | Bootstrapping Remote Secure Key Infrastructure (BRSKI) |
| |
| Authors: | M. Pritikin, M. Richardson, T. Eckert, M. Behringer, K. Watsen. |
| Date: | May 2021 |
| Formats: | txt xml pdf json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 8995 |
|
This document specifies automated bootstrapping of an AutonomicControl Plane. To do this, a Secure Key Infrastructure is bootstrapped. This is done using manufacturer-installed X.509 certificates, in combination with a manufacturer's authorizing service, both online and offline. We call this process theBootstrapping Remote Secure Key Infrastructure (BRSKI) protocol.Bootstrapping a new device can occur when using a routable address and a cloud service, only link-local connectivity, or limited/ disconnected networks. Support for deployment models with less stringent security requirements is included. Bootstrapping is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device. The established secure connection can be used to deploy a locally issued certificate to the device as well. |
|
| |
| RFC 8997 | Deprecation of TLS 1.1 for Email Submission and Access |
| |
|
|
This specification updates the current recommendation for the use of the Transport Layer Security (TLS) protocol to provide confidentiality of email between a Mail User Agent (MUA) and a MailSubmission Server or Mail Access Server. This document updates RFC8314. |
|
| |
| RFC 8999 | Version-Independent Properties of QUIC |
| |
|
|
This document defines the properties of the QUIC transport protocol that are common to all versions of the protocol. |
|
| |
| RFC 9000 | QUIC: A UDP-Based Multiplexed and Secure Transport |
| |
| Authors: | J. Iyengar, Ed., M. Thomson, Ed.. |
| Date: | May 2021 |
| Formats: | txt html xml pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9000 |
|
This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration ofTLS for key negotiation, loss detection, and an exemplary congestion control algorithm. |
|
| |
| RFC 9001 | Using TLS to Secure QUIC |
| |
| Authors: | M. Thomson, Ed., S. Turner, Ed.. |
| Date: | May 2021 |
| Formats: | txt html json xml pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9001 |
|
This document describes how Transport Layer Security (TLS) is used to secure QUIC. |
|
| |
| RFC 9002 | QUIC Loss Detection and Congestion Control |
| |
| Authors: | J. Iyengar, Ed., I. Swett, Ed.. |
| Date: | May 2021 |
| Formats: | txt json pdf xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9002 |
|
This document describes loss detection and congestion control mechanisms for QUIC. |
|
| |
| RFC 9003 | Extended BGP Administrative Shutdown Communication |
| |
|
|
This document enhances the BGP Cease NOTIFICATION message"Administrative Shutdown" and "Administrative Reset" subcodes for operators to transmit a short free-form message to describe why a BGP session was shut down or reset. This document updates RFC 4486 and obsoletes RFC 8203 by defining an Extended BGP AdministrativeShutdown Communication of up to 255 octets to improve communication using multibyte character sets. |
|
| |
| RFC 9005 | Path Computation Element Communication Protocol (PCEP) Extension for Associating Policies and Label Switched Paths (LSPs) |
| |
| Authors: | S. Litkowski, S. Sivabalan, J. Tantsura, J. Hardwick, C. Li. |
| Date: | March 2021 |
| Formats: | txt pdf xml html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9005 |
|
This document introduces a simple mechanism to associate policies with a group of Label Switched Paths (LSPs) via an extension to thePath Computation Element Communication Protocol (PCEP). The extension allows a PCEP speaker to advertise to a PCEP peer that a particular LSP belongs to a particular Policy Association Group(PAG). |
|
| |
| RFC 9007 | Handling Message Disposition Notification with the JSON Meta Application Protocol (JMAP) |
| |
|
|
This document specifies a data model for handling Message DispositionNotifications (MDNs) (see RFC 8098) in the JSON Meta ApplicationProtocol (JMAP) (see RFCs 8620 and 8621). |
|
| |
| RFC 9008 | Using RPI Option Type, Routing Header for Source Routes, and IPv6-in-IPv6 Encapsulation in the RPL Data Plane |
| |
|
|
This document looks at different data flows through Low-Power andLossy Networks (LLN) where RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) is used to establish routing. The document enumerates the cases where RPL Packet Information (RPI) Option Type(RFC 6553), RPL Source Route Header (RFC 6554), and IPv6-in-IPv6 encapsulation are required in the data plane. This analysis provides the basis upon which to design efficient compression of these headers. This document updates RFC 6553 by adding a change to theRPI Option Type. Additionally, this document updates RFC 6550 by defining a flag in the DODAG Information Object (DIO) Configuration option to indicate this change and updates RFC 8138 as well to consider the new Option Type when the RPL Option is decompressed. |
|
| |
| RFC 9009 | Efficient Route Invalidation |
| |
| Authors: | R.A. Jadhav, Ed., P. Thubert, R.N. Sahoo, Z. Cao. |
| Date: | April 2021 |
| Formats: | txt html json xml pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9009 |
|
This document explains the problems associated with the use of No-Path Destination Advertisement Object (NPDAO) messaging in RFC 6550 and also discusses the requirements for an optimized route invalidation messaging scheme. Further, this document specifies a new proactive route invalidation message called the "DestinationCleanup Object" (DCO), which fulfills requirements for optimized route invalidation messaging. |
|
| |
| RFC 9010 | Routing for RPL (Routing Protocol for Low-Power and Lossy Networks) Leaves |
| |
|
|
This specification provides a mechanism for a host that implements a routing-agnostic interface based on IPv6 over Low-Power WirelessPersonal Area Network (6LoWPAN) Neighbor Discovery to obtain reachability services across a network that leverages RFC 6550 for its routing operations. It updates RFCs 6550, 6775, and 8505. |
|
| |
| RFC 9011 | Static Context Header Compression and Fragmentation (SCHC) over LoRaWAN |
| |
| Authors: | O. Gimenez, Ed., I. Petrov, Ed.. |
| Date: | April 2021 |
| Formats: | txt html json pdf xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9011 |
|
The Static Context Header Compression and fragmentation (SCHC) specification (RFC 8724) describes generic header compression and fragmentation techniques for Low-Power Wide Area Network (LPWAN) technologies. SCHC is a generic mechanism designed for great flexibility so that it can be adapted for any of the LPWAN technologies.
This document defines a profile of SCHC (RFC 8724) for use in LoRaWAN networks and provides elements such as efficient parameterization and modes of operation. |
|
| |
| RFC 9012 | The BGP Tunnel Encapsulation Attribute |
| |
|
|
This document defines a BGP path attribute known as the "TunnelEncapsulation attribute", which can be used with BGP UPDATEs of various Subsequent Address Family Identifiers (SAFIs) to provide information needed to create tunnels and their corresponding encapsulation headers. It provides encodings for a number of tunnel types, along with procedures for choosing between alternate tunnels and routing packets into tunnels.
This document obsoletes RFC 5512, which provided an earlier definition of the Tunnel Encapsulation attribute. RFC 5512 was never deployed in production. Since RFC 5566 relies on RFC 5512, it is likewise obsoleted. This document updates RFC 5640 by indicating that the Load-Balancing Block sub-TLV may be included in any TunnelEncapsulation attribute where load balancing is desired. |
|
| |
| RFC 9013 | OSPF Advertisement of Tunnel Encapsulations |
| |
| Authors: | X. Xu, Ed., B. Decraene, Ed., R. Raszuk, L. Contreras, L. Jalil. |
| Date: | April 2021 |
| Formats: | txt xml pdf json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9013 |
|
Networks use tunnels for a variety of reasons. A large variety of tunnel types are defined, and the tunnel encapsulator router needs to select a type of tunnel that is supported by the tunnel decapsulator router. This document defines how to advertise, in OSPF RouterInformation Link State Advertisements (LSAs), the list of tunnel encapsulations supported by the tunnel decapsulator. |
|
| |
| RFC 9014 | Interconnect Solution for Ethernet VPN (EVPN) Overlay Networks |
| |
| Authors: | J. Rabadan, Ed., S. Sathappan, W. Henderickx, A. Sajassi, J. Drake. |
| Date: | May 2021 |
| Formats: | txt xml html pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9014 |
|
This document describes how Network Virtualization Overlays (NVOs) can be connected to a Wide Area Network (WAN) in order to extend theLayer 2 connectivity required for some tenants. The solution analyzes the interaction between NVO networks running EthernetVirtual Private Networks (EVPNs) and other Layer 2 VPN (L2VPN) technologies used in the WAN, such as Virtual Private LAN Services(VPLSs), VPLS extensions for Provider Backbone Bridging (PBB-VPLS),EVPN, or PBB-EVPN. It also describes how the existing technical specifications apply to the interconnection and extends the EVPN procedures needed in some cases. In particular, this document describes how EVPN routes are processed on Gateways (GWs) that interconnect EVPN-Overlay and EVPN-MPLS networks, as well as theInterconnect Ethernet Segment (I-ES), to provide multihoming. This document also describes the use of the Unknown MAC Route (UMR) to avoid issues of a Media Access Control (MAC) scale on Data CenterNetwork Virtualization Edge (NVE) devices. |
|
| |
| RFC 9015 | BGP Control Plane for the Network Service Header in Service Function Chaining |
| |
| Authors: | A. Farrel, J. Drake, E. Rosen, J. Uttaro, L. Jalil. |
| Date: | June 2021 |
| Formats: | txt html xml pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9015 |
|
This document describes the use of BGP as a control plane for networks that support service function chaining. The document introduces a new BGP address family called the "Service FunctionChain (SFC) Address Family Identifier / Subsequent Address FamilyIdentifier" (SFC AFI/SAFI) with two Route Types. One Route Type is originated by a node to advertise that it hosts a particular instance of a specified service function. This Route Type also provides"instructions" on how to send a packet to the hosting node in a way that indicates that the service function has to be applied to the packet. The other Route Type is used by a controller to advertise the paths of "chains" of service functions and give a unique designator to each such path so that they can be used in conjunction with the Network Service Header (NSH) defined in RFC 8300.
This document adopts the service function chaining architecture described in RFC 7665. |
|
| |
| RFC 9017 | Special-Purpose Label Terminology |
| |
|
|
This document discusses and recommends terminology that may be used when MPLS Special-Purpose Labels (SPLs) are specified and documented.
This document applies that terminology change to the relevant IANA registry and also clarifies the use of the Entropy Label Indicator(7) when immediately preceded by the Extension Label (15).
This document updates RFCs 3032 and 7274. |
|
| |
| RFC 9018 | Interoperable Domain Name System (DNS) Server Cookies |
| |
| Authors: | O. Sury, W. Toorop, D. Eastlake 3rd, M. Andrews. |
| Date: | April 2021 |
| Formats: | txt html pdf xml json |
| Updates: | RFC 7873 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9018 |
|
DNS Cookies, as specified in RFC 7873, are a lightweight DNS transaction security mechanism that provide limited protection to DNS servers and clients against a variety of denial-of-service amplification, forgery, or cache-poisoning attacks by off-path attackers.
This document updates RFC 7873 with precise directions for creatingServer Cookies so that an anycast server set including diverse implementations will interoperate with standard clients, with suggestions for constructing Client Cookies in a privacy-preserving fashion, and with suggestions on how to update a Server Secret. AnIANA registry listing the methods and associated pseudorandom function suitable for creating DNS Server Cookies has been created with the method described in this document as the first and, as of the time of publication, only entry. |
|
| |
| RFC 9020 | YANG Data Model for Segment Routing |
| |
| Authors: | S. Litkowski, Y. Qu, A. Lindem, P. Sarkar, J. Tantsura. |
| Date: | May 2021 |
| Formats: | txt xml html pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9020 |
|
This document defines three YANG data models. The first is forSegment Routing (SR) configuration and operation, which is to be augmented by different Segment Routing data planes. The next is aYANG data model that defines a collection of generic types and groupings for SR. The third module defines the configuration and operational states for the Segment Routing MPLS data plane. |
|
| |
| RFC 9022 | Domain Name Registration Data (DNRD) Objects Mapping |
| |
| Authors: | G. Lozano, J. Gould, C. Thippeswamy. |
| Date: | May 2021 |
| Formats: | txt json html pdf xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9022 |
|
This document specifies the format, contents, and semantics of DomainName Registration Data (DNRD) escrow deposits for a domain name registry. |
|
| |
| RFC 9024 | Deterministic Networking (DetNet) Data Plane: IEEE 802.1 Time-Sensitive Networking over MPLS |
| |
| Authors: | B. Varga, Ed., J. Farkas, A. Malis, S. Bryant, D. Fedyk. |
| Date: | June 2021 |
| Formats: | txt html pdf json xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9024 |
|
This document specifies the Deterministic Networking data plane whenTime-Sensitive Networking (TSN) networks are interconnected over aDetNet MPLS network. |
|
| |
| RFC 9025 | Deterministic Networking (DetNet) Data Plane: MPLS over UDP/IP |
| |
| Authors: | B. Varga, Ed., J. Farkas, L. Berger, A. Malis, S. Bryant. |
| Date: | April 2021 |
| Formats: | txt html pdf xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9025 |
|
This document specifies the MPLS Deterministic Networking (DetNet) data plane operation and encapsulation over an IP network. The approach is based on the operation of MPLS-over-UDP technology. |
|
| |
| RFC 9026 | Multicast VPN Fast Upstream Failover |
| |
| Authors: | T. Morin, Ed., R. Kebler, Ed., G. Mirsky, Ed.. |
| Date: | April 2021 |
| Formats: | txt xml pdf json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9026 |
|
This document defines Multicast Virtual Private Network (VPN) extensions and procedures that allow fast failover for upstream failures by allowing downstream Provider Edges (PEs) to consider the status of Provider-Tunnels (P-tunnels) when selecting the Upstream PE for a VPN multicast flow. The fast failover is enabled by using"Bidirectional Forwarding Detection (BFD) for Multipoint Networks"(RFC 8562) and the new BGP Attribute, BFD Discriminator. Also, this document introduces a new BGP Community, Standby PE, extending BGPMulticast VPN (MVPN) routing so that a C-multicast route can be advertised toward a Standby Upstream PE. |
|
| |
| RFC 9027 | Assertion Values for Resource Priority Header and SIP Priority Header Claims in Support of Emergency Services Networks |
| |
|
|
This document adds new assertion values for a Resource PriorityHeader ("rph") claim and a new SIP Priority Header ("sph") claim for protection of the "psap-callback" value as part of the "rph" PersonalAssertion Token (PASSporT) extension in support of the security of emergency services networks for emergency call origination and callback. |
|
| |
| RFC 9029 | Updates to the Allocation Policy for the Border Gateway Protocol - Link State (BGP-LS) Parameters Registries |
| |
|
|
RFC 7752 defines the Border Gateway Protocol - Link State (BGP-LS).IANA created a registry consistent with that document called "BorderGateway Protocol - Link State (BGP-LS) Parameters" with a number of subregistries. The allocation policy applied by IANA for those registries is "Specification Required", as defined in RFC 8126.
This document updates RFC 7752 by changing the allocation policy for all of the registries to "Expert Review" and by updating the guidance to the designated experts. |
|
| |
| RFC 9031 | Constrained Join Protocol (CoJP) for 6TiSCH |
| |
| Authors: | M. Vučinić, Ed., J. Simon, K. Pister, M. Richardson. |
| Date: | May 2021 |
| Formats: | txt html pdf xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9031 |
|
This document describes the minimal framework required for a new device, called a "pledge", to securely join a 6TiSCH (IPv6 over theTime-Slotted Channel Hopping mode of IEEE 802.15.4) network. The framework requires that the pledge and the JRC (Join Registrar/Coordinator, a central entity), share a symmetric key. How this key is provisioned is out of scope of this document. Through a singleCoAP (Constrained Application Protocol) request-response exchange secured by OSCORE (Object Security for Constrained RESTfulEnvironments), the pledge requests admission into the network, and the JRC configures it with link-layer keying material and other parameters. The JRC may at any time update the parameters through another request-response exchange secured by OSCORE. This specification defines the Constrained Join Protocol and its CBOR(Concise Binary Object Representation) data structures, and it describes how to configure the rest of the 6TiSCH communication stack for this join process to occur in a secure manner. Additional security mechanisms may be added on top of this minimal framework. |
|
| |
| RFC 9032 | Encapsulation of 6TiSCH Join and Enrollment Information Elements |
| |
| Authors: | D. Dujovne, Ed., M. Richardson. |
| Date: | May 2021 |
| Formats: | txt json xml pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9032 |
|
In the Time-Slotted Channel Hopping (TSCH) mode of IEEE Std 802.15.4, opportunities for broadcasts are limited to specific times and specific channels. Routers in a TSCH network transmit EnhancedBeacon (EB) frames to announce the presence of the network. This document provides a mechanism by which additional information critical for new nodes (pledges) and long-sleeping nodes may be carried within the EB in order to conserve use of broadcast opportunities. |
|
| |
| RFC 9033 | 6TiSCH Minimal Scheduling Function (MSF) |
| |
| Authors: | T. Chang, Ed., M. Vučinić, X. Vilajosana, S. Duquennoy, D. Dujovne. |
| Date: | May 2021 |
| Formats: | txt json xml html pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9033 |
|
This specification defines the "IPv6 over the TSCH mode of IEEE802.15.4" (6TiSCH) Minimal Scheduling Function (MSF). ThisScheduling Function describes both the behavior of a node when joining the network and how the communication schedule is managed in a distributed fashion. MSF is built upon the 6TiSCH OperationSublayer Protocol (6P) and the minimal security framework for 6TiSCH. |
|
| |
| RFC 9034 | Packet Delivery Deadline Time in the Routing Header for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) |
| |
| Authors: | L. Thomas, S. Anamalamudi, S.V.R. Anand, M. Hegde, C. Perkins. |
| Date: | June 2021 |
| Formats: | txt html json xml pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9034 |
|
This document specifies a new type for the 6LoWPAN routing header containing the deadline time for data packets, designed for use over constrained networks. The deadline time enables forwarding and scheduling decisions for time-critical machine-to-machine (M2M) applications running on Internet-enabled devices that operate within time-synchronized networks. This document also specifies a representation for the deadline time values in such networks. |
|
| |
| RFC 9035 | A Routing Protocol for Low-Power and Lossy Networks (RPL) Destination-Oriented Directed Acyclic Graph (DODAG) Configuration Option for the 6LoWPAN Routing Header |
| |
|
|
This document updates RFC 8138 by defining a bit in the RoutingProtocol for Low-Power and Lossy Networks (RPL) Destination-OrientedDirected Acyclic Graph (DODAG) Configuration option to indicate whether compression is used within the RPL Instance and to specify the behavior of nodes compliant with RFC 8138 when the bit is set and unset. |
|
| |
| RFC 9036 | Changing the Location-to-Service Translation (LoST) Location Profiles Registry Policy |
| |
|
|
This document changes the policy of the "Location-to-ServiceTranslation (LoST) Location Profiles" IANA registry established byRFC 5222 from Standards Action to Specification Required. This allows standards development organizations (SDOs) other than the IETF to add new values. |
|
| |
| RFC 9038 | Extensible Provisioning Protocol (EPP) Unhandled Namespaces |
| |
|
|
The Extensible Provisioning Protocol (EPP), as defined in RFC 5730, includes a method for the client and server to determine the objects to be managed during a session and the object extensions to be used during a session. The services are identified using namespace URIs, and an "unhandled namespace" is one that is associated with a service not supported by the client. This document defines an operational practice that enables the server to return information associated with unhandled namespace URIs and that maintains compliance with the negotiated services defined in RFC 5730. |
|
| |
| RFC 9039 | Uniform Resource Names for Device Identifiers |
| |
| Authors: | J. Arkko, C. Jennings, Z. Shelby. |
| Date: | June 2021 |
| Formats: | txt pdf xml html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9039 |
|
This document describes a new Uniform Resource Name (URN) namespace for hardware device identifiers. A general representation of device identity can be useful in many applications, such as in sensor data streams and storage or in equipment inventories. A URN-based representation can be passed along in applications that need the information. |
|
| |
| RFC 9041 | Updating the MPLS Label Switched Paths (LSPs) Ping Parameters IANA Registry |
| |
|
|
This document updates RFCs 8029 and 8611, both of which define IANA registries for MPLS Label Switched Path (LSP) Ping. In particular, the registration procedure "Private Use" (previously known as "VendorPrivate Use") has been changed to "First Come First Served" for theTLV and sub-TLV registries.
It also updates the description of the procedures for the responses sent when an unknown or erroneous code point is found. The updates are to clarify and align this namespace with recent developments, e.g., aligning terminology with RFC 8126 instead of the now obsoletedRFC 5226 (both titled "Guidelines for Writing an IANA ConsiderationsSection in RFCs"). |
|
| |
| RFC 9042 | Sieve Email Filtering: Delivery by MAILBOXID |
| |
|
|
The OBJECTID capability of IMAP (RFC 8474) allows clients to identify mailboxes by a unique identifier that survives renaming.
This document extends the Sieve email filtering language (RFC 5228) to allow using that same unique identifier as a target for fileinto rules and for testing the existence of mailboxes. |
|
| |
| RFC 9044 | Using the AES-GMAC Algorithm with the Cryptographic Message Syntax (CMS) |
| |
|
|
This document specifies the conventions for using the AES-GMACMessage Authentication Code algorithm with the Cryptographic MessageSyntax (CMS) as specified in RFC 5652. |
|
| |
| RFC 9045 | Algorithm Requirements Update to the Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF) |
| |
|
|
This document updates the cryptographic algorithm requirements for the Password-Based Message Authentication Code in the Internet X.509Public Key Infrastructure Certificate Request Message Format (CRMF) specified in RFC 4211. |
|
| |
| RFC 9047 | Propagation of ARP/ND Flags in an Ethernet Virtual Private Network (EVPN) |
| |
| Authors: | J. Rabadan, Ed., S. Sathappan, K. Nagaraj, W. Lin. |
| Date: | June 2021 |
| Formats: | txt html xml pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9047 |
|
This document defines an Extended Community that is advertised along with an Ethernet Virtual Private Network (EVPN) Media Access Control(MAC) / IP Advertisement route and carries information relevant to the Address Resolution Protocol (ARP) / Neighbor Discovery (ND) resolution so that an EVPN Provider Edge (PE) implementing a proxy-ARP/ND function in broadcast domains (BDs) or an ARP/ND function onIntegrated Routing and Bridging (IRB) interfaces can reply to ARPRequests or Neighbor Solicitation (NS) messages with the correct information. |
|
| |
| RFC 9050 | Path Computation Element Communication Protocol (PCEP) Procedures and Extensions for Using the PCE as a Central Controller (PCECC) of LSPs |
| |
| Authors: | Z. Li, S. Peng, M. Negi, Q. Zhao, C. Zhou. |
| Date: | July 2021 |
| Formats: | txt json html pdf xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9050 |
|
The Path Computation Element (PCE) is a core component of Software-Defined Networking (SDN) systems.
A PCE as a Central Controller (PCECC) can simplify the processing of a distributed control plane by blending it with elements of SDN and without necessarily completely replacing it. Thus, the LabelSwitched Path (LSP) can be calculated/set up/initiated and the label- forwarding entries can also be downloaded through a centralized PCE server to each network device along the path while leveraging the existing PCE technologies as much as possible.
This document specifies the procedures and Path Computation ElementCommunication Protocol (PCEP) extensions for using the PCE as the central controller for provisioning labels along the path of the static LSP. |
|
| |
| RFC 9051 | Internet Message Access Protocol (IMAP) - Version 4rev2 |
| |
|
|
The Internet Message Access Protocol Version 4rev2 (IMAP4rev2) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev2 permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders.IMAP4rev2 also provides the capability for an offline client to resynchronize with the server.
IMAP4rev2 includes operations for creating, deleting, and renaming mailboxes; checking for new messages; removing messages permanently; setting and clearing flags; parsing per RFCs 5322, 2045, and 2231; searching; and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4rev2 are accessed by the use of numbers. These numbers are either message sequence numbers or unique identifiers.
IMAP4rev2 does not specify a means of posting mail; this function is handled by a mail submission protocol such as the one specified inRFC 6409. |
|
| |
| RFC 9056 | Deterministic Networking (DetNet) Data Plane: IP over MPLS |
| |
| Authors: | B. Varga, Ed., L. Berger, D. Fedyk, S. Bryant, J. Korhonen. |
| Date: | October 2021 |
| Formats: | txt html pdf xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9056 |
|
This document specifies the Deterministic Networking data plane when encapsulating IP over an MPLS packet-switched network. |
|
| |
| RFC 9059 | Path Computation Element Communication Protocol (PCEP) Extensions for Associated Bidirectional Label Switched Paths (LSPs) |
| |
| Authors: | R. Gandhi, Ed., C. Barth, B. Wen. |
| Date: | June 2021 |
| Formats: | txt json pdf html xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9059 |
|
This document defines Path Computation Element Communication Protocol(PCEP) extensions for grouping two unidirectional MPLS-TE LabelSwitched Paths (LSPs), one in each direction in the network, into an associated bidirectional LSP. These PCEP extensions can be applied either using a stateful PCE for both PCE-initiated and PCC-initiatedLSPs or using a stateless PCE. The PCEP procedures defined are applicable to the LSPs using RSVP-TE for signaling. |
|
| |
| RFC 9060 | Secure Telephone Identity Revisited (STIR) Certificate Delegation |
| |
|
|
The Secure Telephone Identity Revisited (STIR) certificate profile provides a way to attest authority over telephone numbers and related identifiers for the purpose of preventing telephone number spoofing.This specification details how that authority can be delegated from a parent certificate to a subordinate certificate. This supports a number of use cases, including those where service providers grant credentials to enterprises or other customers capable of signing calls with STIR. |
|
| |
| RFC 9061 | A YANG Data Model for IPsec Flow Protection Based on Software-Defined Networking (SDN) |
| |
| Authors: | R. Marin-Lopez, G. Lopez-Millan, F. Pereniguez-Garcia. |
| Date: | July 2021 |
| Formats: | txt xml pdf json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9061 |
|
This document describes how to provide IPsec-based flow protection(integrity and confidentiality) by means of an Interface to NetworkSecurity Function (I2NSF) Controller. It considers two main well- known scenarios in IPsec: gateway-to-gateway and host-to-host. The service described in this document allows the configuration and monitoring of IPsec Security Associations (IPsec SAs) from an I2NSFController to one or several flow-based Network Security Functions(NSFs) that rely on IPsec to protect data traffic.
This document focuses on the I2NSF NSF-Facing Interface by providingYANG data models for configuring the IPsec databases, namely SecurityPolicy Database (SPD), Security Association Database (SAD), PeerAuthorization Database (PAD), and Internet Key Exchange Version 2(IKEv2). This allows IPsec SA establishment with minimal intervention by the network administrator. This document defines three YANG modules, but it does not define any new protocol. |
|
| |
| RFC 9066 | Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Call Home |
| |
| Authors: | T. Reddy.K, M. Boucadair, Ed., J. Shallow. |
| Date: | December 2021 |
| Formats: | txt xml html pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9066 |
|
This document specifies the Denial-of-Service Open Threat Signaling(DOTS) signal channel Call Home, which enables a Call Home DOTS server to initiate a secure connection to a Call Home DOTS client and to receive attack traffic information from the Call Home DOTS client.The Call Home DOTS server in turn uses the attack traffic information to identify compromised devices launching outgoing DDoS attacks and take appropriate mitigation action(s).
The DOTS signal channel Call Home is not specific to home networks; the solution targets any deployment in which it is required to blockDDoS attack traffic closer to the source(s) of a DDoS attack. |
|
| |
| RFC 9067 | A YANG Data Model for Routing Policy |
| |
| Authors: | Y. Qu, J. Tantsura, A. Lindem, X. Liu. |
| Date: | October 2021 |
| Formats: | txt xml html pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9067 |
|
This document defines a YANG data model for configuring and managing routing policies in a vendor-neutral way. The model provides a generic routing policy framework that can be extended for specific routing protocols using the YANG 'augment' mechanism. |
|
| |
| RFC 9068 | JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens |
| |
|
|
This specification defines a profile for issuing OAuth 2.0 access tokens in JSON Web Token (JWT) format. Authorization servers and resource servers from different vendors can leverage this profile to issue and consume access tokens in an interoperable manner. |
|
| |
| RFC 9069 | Support for Local RIB in the BGP Monitoring Protocol (BMP) |
| |
| Authors: | T. Evens, S. Bayraktar, M. Bhardwaj, P. Lucente. |
| Date: | February 2022 |
| Formats: | txt json xml pdf html |
| Updates: | RFC 7854 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9069 |
|
The BGP Monitoring Protocol (BMP) defines access to local RoutingInformation Bases (RIBs). This document updates BMP (RFC 7854) by adding access to the Local Routing Information Base (Loc-RIB), as defined in RFC 4271. The Loc-RIB contains the routes that have been selected by the local BGP speaker's Decision Process. |
|
| |
| RFC 9070 | YANG Data Model for MPLS LDP |
| |
| Authors: | K. Raza, Ed., R. Asati, X. Liu, S. Esale, X. Chen, H. Shah. |
| Date: | March 2022 |
| Formats: | txt pdf json xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9070 |
|
This document describes a YANG data model for the Multiprotocol LabelSwitching (MPLS) Label Distribution Protocol (LDP). The model also serves as the base model to define the Multipoint LDP (mLDP) model.
The YANG modules in this document conform to the Network ManagementDatastore Architecture (NMDA). |
|
| |
| RFC 9071 | RTP-Mixer Formatting of Multiparty Real-Time Text |
| |
|
|
This document provides enhancements of real-time text (as specified in RFC 4103) suitable for mixing in a centralized conference model, enabling source identification and rapidly interleaved transmission of text from different sources. The intended use is for real-time text mixers and participant endpoints capable of providing an efficient presentation or other treatment of a multiparty real-time text session. The specified mechanism builds on the standard use of the Contributing Source (CSRC) list in the Real-time TransportProtocol (RTP) packet for source identification. The method makes use of the same "text/t140" and "text/red" formats as for two-party sessions.
Solutions using multiple RTP streams in the same RTP session are briefly mentioned, as they could have some benefits over the RTP- mixer model. The RTP-mixer model was selected to be used for the fully specified solution in this document because it can be applied to a wide range of existing RTP implementations.
A capability exchange is specified so that it can be verified that a mixer and a participant can handle the multiparty-coded real-time text stream using the RTP-mixer method. The capability is indicated by the use of a Session Description Protocol (SDP) (RFC 8866) media attribute, "rtt-mixer".
This document updates RFC 4103 ("RTP Payload for Text Conversation").
A specification for how a mixer can format text for the case when the endpoint is not multiparty aware is also provided. |
|
| |
| RFC 9072 | Extended Optional Parameters Length for BGP OPEN Message |
| |
|
|
The Optional Parameters in the BGP OPEN message as defined in the base BGP specification are limited to 255 octets due to a one-octet length field. BGP capabilities are carried in this field and may foreseeably exceed 255 octets in the future, leading to concerns about this limitation.
This document updates RFC 4271 by extending, in a backward-compatible manner, the length of the Optional Parameters in a BGP OPEN message.The Parameter Length field of individual Optional Parameters is also extended. |
|
| |
| RFC 9073 | Event Publishing Extensions to iCalendar |
| |
|
|
This specification updates RFC 5545 by introducing a number of new iCalendar properties and components that are of particular use for event publishers and in social networking.
This specification also defines a new "STRUCTURED-DATA" property for iCalendar (RFC 5545) to allow for data that is directly pertinent to an event or task to be included with the calendar data. |
|
| |
| RFC 9074 | "VALARM" Extensions for iCalendar |
| |
|
|
This document defines a set of extensions to the iCalendar "VALARM" component to enhance the use of alarms and improve interoperability between clients and servers.
This document updates RFC 5545. |
|
| |
| RFC 9077 | NSEC and NSEC3: TTLs and Aggressive Use |
| |
|
|
Due to a combination of unfortunate wording in earlier documents, aggressive use of NSEC and NSEC3 records may deny the existence of names far beyond the intended lifetime of a denial. This document changes the definition of the NSEC and NSEC3 TTL to correct that situation. This document updates RFCs 4034, 4035, 5155, and 8198. |
|
| |
| RFC 9079 | Source-Specific Routing in the Babel Routing Protocol |
| |
| Authors: | M. Boutier, J. Chroboczek. |
| Date: | August 2021 |
| Formats: | txt pdf xml json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9079 |
|
Source-specific routing, also known as Source Address DependentRouting (SADR), is an extension to traditional next-hop routing where packets are forwarded according to both their destination address and their source address. This document describes an extension for source-specific routing to the Babel routing protocol. |
|
| |
| RFC 9080 | Homenet Profile of the Babel Routing Protocol |
| |
|
|
This document defines the exact subset of the Babel routing protocol and its extensions that is required by an implementation of theHomenet protocol suite, as well as the interactions between the HomeNetworking Control Protocol (HNCP) and Babel. |
|
| |
| RFC 9081 | Interoperation between Multicast Virtual Private Network (MVPN) and Multicast Source Directory Protocol (MSDP) Source-Active Routes |
| |
|
|
This document specifies the procedures for interoperation betweenMulticast Virtual Private Network (MVPN) Source-Active (SA) routes and customer Multicast Source Discovery Protocol (MSDP) SA routes, which is useful for MVPN provider networks offering services to customers with an existing MSDP infrastructure. Without the procedures described in this document, VPN-specific MSDP sessions are required among the Provider Edge (PE) routers that are customer MSDP peers. This document updates RFC 6514. |
|
| |
| RFC 9084 | OSPF Prefix Originator Extensions |
| |
| Authors: | A. Wang, A. Lindem, J. Dong, P. Psenak, K. Talaulikar, Ed.. |
| Date: | August 2021 |
| Formats: | txt xml json pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9084 |
|
This document defines OSPF extensions to include information associated with the node originating a prefix along with the prefix advertisement. These extensions do not change the core OSPF route computation functionality but provide useful information for network analysis, troubleshooting, and use cases like traffic engineering. |
|
| |
| RFC 9085 | Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing |
| |
| Authors: | S. Previdi, K. Talaulikar, Ed., C. Filsfils, H. Gredler, M. Chen. |
| Date: | August 2021 |
| Formats: | txt xml json pdf html |
| Updated by: | RFC 9356 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9085 |
|
Segment Routing (SR) allows for a flexible definition of end-to-end paths by encoding paths as sequences of topological subpaths, called"segments". These segments are advertised by routing protocols, e.g., by the link-state routing protocols (IS-IS, OSPFv2, and OSPFv3) within IGP topologies.
This document defines extensions to the Border Gateway Protocol -Link State (BGP-LS) address family in order to carry SR information via BGP. |
|
| |
| RFC 9086 | Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing BGP Egress Peer Engineering |
| |
| Authors: | S. Previdi, K. Talaulikar, Ed., C. Filsfils, K. Patel, S. Ray, J. Dong. |
| Date: | August 2021 |
| Formats: | txt html json pdf xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9086 |
|
A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with a list of segment identifiers (SIDs). A segment can represent any instruction, topological or service based. SR segments allow steering a flow through any topological path and service chain while maintaining per- flow state only at the ingress node of the SR domain.
This document describes an extension to Border Gateway Protocol -Link State (BGP-LS) for advertisement of BGP Peering Segments along with their BGP peering node information so that efficient BGP EgressPeer Engineering (EPE) policies and strategies can be computed based on Segment Routing. |
|
| |
| RFC 9088 | Signaling Entropy Label Capability and Entropy Readable Label Depth Using IS-IS |
| |
| Authors: | X. Xu, S. Kini, P. Psenak, C. Filsfils, S. Litkowski, M. Bocci. |
| Date: | August 2021 |
| Formats: | txt json html pdf xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9088 |
|
Multiprotocol Label Switching (MPLS) has defined a mechanism to load- balance traffic flows using Entropy Labels (EL). An ingress LabelSwitching Router (LSR) cannot insert ELs for packets going into a given Label Switched Path (LSP) unless an egress LSR has indicated via signaling that it has the capability to process ELs, referred to as the Entropy Label Capability (ELC), on that LSP. In addition, it would be useful for ingress LSRs to know each LSR's capability for reading the maximum label stack depth and performing EL-based load- balancing, referred to as Entropy Readable Label Depth (ERLD). This document defines a mechanism to signal these two capabilities usingIS-IS and Border Gateway Protocol - Link State (BGP-LS). |
|
| |
| RFC 9089 | Signaling Entropy Label Capability and Entropy Readable Label Depth Using OSPF |
| |
| Authors: | X. Xu, S. Kini, P. Psenak, C. Filsfils, S. Litkowski, M. Bocci. |
| Date: | August 2021 |
| Formats: | txt json pdf xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9089 |
|
Multiprotocol Label Switching (MPLS) has defined a mechanism to load- balance traffic flows using Entropy Labels (EL). An ingress LabelSwitching Router (LSR) cannot insert ELs for packets going into a given Label Switched Path (LSP) unless an egress LSR has indicated via signaling that it has the capability to process ELs, referred to as the Entropy Label Capability (ELC), on that LSP. In addition, it would be useful for ingress LSRs to know each LSR's capability for reading the maximum label stack depth and performing EL-based load- balancing, referred to as Entropy Readable Label Depth (ERLD). This document defines a mechanism to signal these two capabilities usingOSPFv2 and OSPFv3, and Border Gateway Protocol - Link State (BGP-LS). |
|
| |
| RFC 9090 | Concise Binary Object Representation (CBOR) Tags for Object Identifiers |
| |
|
|
The Concise Binary Object Representation (CBOR), defined in RFC 8949, is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation.
This document defines CBOR tags for object identifiers (OIDs) and is the reference document for the IANA registration of the CBOR tags so defined. |
|
| |
| RFC 9092 | Finding and Using Geofeed Data |
| |
| Authors: | R. Bush, M. Candela, W. Kumari, R. Housley. |
| Date: | July 2021 |
| Formats: | txt pdf html xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9092 |
|
This document specifies how to augment the Routing PolicySpecification Language inetnum: class to refer specifically to geofeed data comma-separated values (CSV) files and describes an optional scheme that uses the Routing Public Key Infrastructure to authenticate the geofeed data CSV files. |
|
| |
| RFC 9093 | A YANG Data Model for Layer 0 Types |
| |
| Authors: | H. Zheng, Y. Lee, A. Guo, V. Lopez, D. King. |
| Date: | August 2021 |
| Formats: | txt pdf html xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9093 |
|
This document defines a collection of common data types and groupings in the YANG data modeling language. These derived common types and groupings are intended to be imported by modules that model Layer 0 optical Traffic Engineering (TE) configuration and state capabilities such as Wavelength Switched Optical Networks (WSONs) and flexi-gridDense Wavelength Division Multiplexing (DWDM) networks. |
|
| |
| RFC 9094 | A YANG Data Model for Wavelength Switched Optical Networks (WSONs) |
| |
| Authors: | H. Zheng, Y. Lee, A. Guo, V. Lopez, D. King. |
| Date: | August 2021 |
| Formats: | txt pdf xml json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9094 |
|
This document provides a YANG data model for the routing and wavelength assignment (RWA) TE topology in Wavelength SwitchedOptical Networks (WSONs). The YANG data model defined in this document conforms to the Network Management Datastore Architecture(NMDA). |
|
| |
| RFC 9097 | Metrics and Methods for One-Way IP Capacity |
| |
| Authors: | A. Morton, R. Geib, L. Ciavattone. |
| Date: | November 2021 |
| Formats: | txt html xml json pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9097 |
|
This memo revisits the problem of Network Capacity Metrics first examined in RFC 5136. This memo specifies a more practical MaximumIP-Layer Capacity Metric definition catering to measurement and outlines the corresponding Methods of Measurement. |
|
| |
| RFC 9100 | Sensor Measurement Lists (SenML) Features and Versions |
| |
|
|
This short document updates RFC 8428, "Sensor Measurement Lists(SenML)", by specifying the use of independently selectable "SenMLFeatures" and mapping them to SenML version numbers. |
|
| |
| RFC 9101 | The OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request (JAR) |
| |
| Authors: | N. Sakimura, J. Bradley, M. Jones. |
| Date: | August 2021 |
| Formats: | txt json html pdf xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9101 |
|
The authorization request in OAuth 2.0 described in RFC 6749 utilizes query parameter serialization, which means that authorization request parameters are encoded in the URI of the request and sent through user agents such as web browsers. While it is easy to implement, it means that a) the communication through the user agents is not integrity protected and thus, the parameters can be tainted, b) the source of the communication is not authenticated, and c) the communication through the user agents can be monitored. Because of these weaknesses, several attacks to the protocol have now been put forward.
This document introduces the ability to send request parameters in aJSON Web Token (JWT) instead, which allows the request to be signed with JSON Web Signature (JWS) and encrypted with JSON Web Encryption(JWE) so that the integrity, source authentication, and confidentiality properties of the authorization request are attained.The request can be sent by value or by reference. |
|
| |
| RFC 9103 | DNS Zone Transfer over TLS |
| |
|
|
DNS zone transfers are transmitted in cleartext, which gives attackers the opportunity to collect the content of a zone by eavesdropping on network connections. The DNS Transaction Signature(TSIG) mechanism is specified to restrict direct zone transfer to authorized clients only, but it does not add confidentiality. This document specifies the use of TLS, rather than cleartext, to prevent zone content collection via passive monitoring of zone transfers: XFR over TLS (XoT). Additionally, this specification updates RFC 1995 and RFC 5936 with respect to efficient use of TCP connections and RFC7766 with respect to the recommended number of connections between a client and server for each transport. |
|
| |
| RFC 9104 | Distribution of Traffic Engineering Extended Administrative Groups Using the Border Gateway Protocol - Link State (BGP-LS) |
| |
| Authors: | J. Tantsura, Z. Wang, Q. Wu, K. Talaulikar. |
| Date: | August 2021 |
| Formats: | txt json xml pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9104 |
|
Administrative groups are link attributes used for traffic engineering. This document defines an extension to the BorderGateway Protocol - Link State (BGP-LS) for advertisement of extended administrative groups (EAGs). |
|
| |
| RFC 9105 | A YANG Data Model for Terminal Access Controller Access-Control System Plus (TACACS+) |
| |
| Authors: | B. Wu, Ed., G. Zheng, M. Wang, Ed.. |
| Date: | August 2021 |
| Formats: | txt xml pdf json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9105 |
|
This document defines a Terminal Access Controller Access-ControlSystem Plus (TACACS+) client YANG module that augments the SystemManagement data model, defined in RFC 7317, to allow devices to make use of TACACS+ servers for centralized Authentication, Authorization, and Accounting (AAA). Though being a standard module, this module does not endorse the security mechanisms of the TACACS+ protocol (RFC8907), and TACACS+ MUST be used within a secure deployment.
The YANG module in this document conforms to the Network ManagementDatastore Architecture (NMDA) defined in RFC 8342. |
|
| |
| RFC 9107 | BGP Optimal Route Reflection (BGP ORR) |
| |
| Authors: | R. Raszuk, Ed., B. Decraene, Ed., C. Cassar, E. Åman, K. Wang. |
| Date: | August 2021 |
| Formats: | txt html pdf xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9107 |
|
This document defines an extension to BGP route reflectors. On route reflectors, BGP route selection is modified in order to choose the best route from the standpoint of their clients, rather than from the standpoint of the route reflectors themselves. Depending on the scaling and precision requirements, route selection can be specific for one client, common for a set of clients, or common for all clients of a route reflector. This solution is particularly applicable in deployments using centralized route reflectors, where choosing the best route based on the route reflector's IGP location is suboptimal. This facilitates, for example, a "best exit point" policy ("hot potato routing").
The solution relies upon all route reflectors learning all paths that are eligible for consideration. BGP route selection is performed in the route reflectors based on the IGP cost from configured locations in the link-state IGP. |
|
| |
| RFC 9108 | YANG Types for DNS Classes and Resource Record Types |
| |
| Authors: | L. Lhotka, P. Špaček. |
| Date: | September 2021 |
| Formats: | txt json pdf html xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9108 |
|
This document introduces the YANG module "iana-dns-class-rr-type", which contains derived types reflecting two IANA registries: DNSCLASSes and Resource Record (RR) TYPEs. These YANG types are intended as the minimum basis for future data modeling work. |
|
| |
| RFC 9109 | Network Time Protocol Version 4: Port Randomization |
| |
|
|
The Network Time Protocol (NTP) can operate in several modes. Some of these modes are based on the receipt of unsolicited packets and therefore require the use of a well-known port as the local port.However, in the case of NTP modes where the use of a well-known port is not required, employing such a well-known port unnecessarily facilitates the ability of attackers to perform blind/off-path attacks. This document formally updates RFC 5905, recommending the use of transport-protocol ephemeral port randomization for those modes where use of the NTP well-known port is not required. |
|
| |
| RFC 9113 | HTTP/2 |
| |
|
|
This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced latency by introducing field compression and allowing multiple concurrent exchanges on the same connection.
This document obsoletes RFCs 7540 and 8740. |
|
| |
| RFC 9114 | HTTP/3 |
| |
|
|
The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment. This document describes a mapping of HTTP semantics over QUIC. This document also identifies HTTP/2 features that are subsumed by QUIC and describes how HTTP/2 extensions can be ported to HTTP/3. |
|
| |
| RFC 9115 | An Automatic Certificate Management Environment (ACME) Profile for Generating Delegated Certificates |
| |
| Authors: | Y. Sheffer, D. López, A. Pastor Perales, T. Fossati. |
| Date: | September 2021 |
| Formats: | txt json pdf xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9115 |
|
This document defines a profile of the Automatic CertificateManagement Environment (ACME) protocol by which the holder of an identifier (e.g., a domain name) can allow a third party to obtain anX.509 certificate such that the certificate subject is the delegated identifier while the certified public key corresponds to a private key controlled by the third party. A primary use case is that of aContent Delivery Network (CDN), the third party, terminating TLS sessions on behalf of a content provider (the holder of a domain name). The presented mechanism allows the holder of the identifier to retain control over the delegation and revoke it at any time.Importantly, this mechanism does not require any modification to the deployed TLS clients and servers. |
|
| |
| RFC 9117 | Revised Validation Procedure for BGP Flow Specifications |
| |
| Authors: | J. Uttaro, J. Alcaide, C. Filsfils, D. Smith, P. Mohapatra. |
| Date: | August 2021 |
| Formats: | txt html json xml pdf |
| Updates: | RFC 8955 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9117 |
|
This document describes a modification to the validation procedure defined for the dissemination of BGP Flow Specifications. The dissemination of BGP Flow Specifications as specified in RFC 8955 requires that the originator of the Flow Specification match the originator of the best-match unicast route for the destination prefix embedded in the Flow Specification. For an Internal Border GatewayProtocol (iBGP) received route, the originator is typically a border router within the same autonomous system (AS). The objective is to allow only BGP speakers within the data forwarding path to originateBGP Flow Specifications. Sometimes it is desirable to originate theBGP Flow Specification from any place within the autonomous system itself, for example, from a centralized BGP route controller.However, the validation procedure described in RFC 8955 will fail in this scenario. The modification proposed herein relaxes the validation rule to enable Flow Specifications to be originated within the same autonomous system as the BGP speaker performing the validation. Additionally, this document revises the AS_PATH validation rules so Flow Specifications received from an ExternalBorder Gateway Protocol (eBGP) peer can be validated when such a peer is a BGP route server.
This document updates the validation procedure in RFC 8955. |
|
| |
| RFC 9118 | Enhanced JSON Web Token (JWT) Claim Constraints for Secure Telephone Identity Revisited (STIR) Certificates |
| |
|
|
RFC 8226 specifies the use of certificates for Secure TelephoneIdentity Credentials; these certificates are often called "SecureTelephone Identity Revisited (STIR) Certificates". RFC 8226 provides a certificate extension to constrain the JSON Web Token (JWT) claims that can be included in the Personal Assertion Token (PASSporT), as defined in RFC 8225. If the PASSporT signer includes a JWT claim outside the constraint boundaries, then the PASSporT recipient will reject the entire PASSporT. This document updates RFC 8226; it provides all of the capabilities available in the original certificate extension as well as an additional way to constrain the allowable JWT claims. The enhanced extension can also provide a list of claims that are not allowed to be included in the PASSporT. |
|
| |
| RFC 9122 | IANA Registry for Sieve Actions |
| |
| Authors: | A. Melnikov, K. Murchison. |
| Date: | June 2023 |
| Formats: | txt html json xml pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9122 |
|
The Sieve Email Filtering Language (RFC 5228) is a popular email filtering language used upon final mail delivery. This document creates a registry for Sieve actions to help developers and Sieve extension writers track interactions between different extensions. |
|
| |
| RFC 9125 | Gateway Auto-Discovery and Route Advertisement for Site Interconnection Using Segment Routing |
| |
| Authors: | A. Farrel, J. Drake, E. Rosen, K. Patel, L. Jalil. |
| Date: | August 2021 |
| Formats: | txt json xml pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9125 |
|
Data centers are attached to the Internet or a backbone network by gateway routers. One data center typically has more than one gateway for commercial, load-balancing, and resiliency reasons. Other sites, such as access networks, also need to be connected across backbone networks through gateways.
This document defines a mechanism using the BGP Tunnel Encapsulation attribute to allow data center gateway routers to advertise routes to the prefixes reachable in the site, including advertising them on behalf of other gateways at the same site. This allows segment routing to be used to identify multiple paths across the Internet or backbone network between different gateways. The paths can be selected for load-balancing, resilience, and quality purposes. |
|
| |
| RFC 9126 | OAuth 2.0 Pushed Authorization Requests |
| |
| Authors: | T. Lodderstedt, B. Campbell, N. Sakimura, D. Tonge, F. Skokan. |
| Date: | September 2021 |
| Formats: | txt pdf xml html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9126 |
|
This document defines the pushed authorization request (PAR) endpoint, which allows clients to push the payload of an OAuth 2.0 authorization request to the authorization server via a direct request and provides them with a request URI that is used as reference to the data in a subsequent call to the authorization endpoint. |
|
| |
| RFC 9127 | YANG Data Model for Bidirectional Forwarding Detection (BFD) |
| |
| Authors: | R. Rahman, Ed., L. Zheng, Ed., M. Jethanandani, Ed., S. Pallagatti, G. Mirsky. |
| Date: | October 2021 |
| Formats: | txt html pdf xml json |
| Updated by: | RFC 9314 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9127 |
|
This document defines a YANG data model that can be used to configure and manage Bidirectional Forwarding Detection (BFD).
The YANG modules in this document conform to the Network ManagementDatastore Architecture (NMDA) (RFC 8342). |
|
| |
| RFC 9128 | YANG Data Model for Protocol Independent Multicast (PIM) |
| |
| Authors: | X. Liu, P. McAllister, A. Peter, M. Sivakumar, Y. Liu, F. Hu. |
| Date: | October 2022 |
| Formats: | txt pdf xml json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9128 |
|
This document defines a YANG data model that can be used to configure and manage devices supporting Protocol Independent Multicast (PIM).The model covers the PIM protocol configuration, operational state, and event notifications data. |
|
| |
| RFC 9129 | YANG Data Model for the OSPF Protocol |
| |
| Authors: | D. Yeung, Y. Qu, Z. Zhang, I. Chen, A. Lindem. |
| Date: | October 2022 |
| Formats: | txt json pdf xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9129 |
|
This document defines a YANG data model that can be used to configure and manage OSPF. The model is based on YANG 1.1 as defined in RFC7950 and conforms to the Network Management Datastore Architecture(NMDA) as described in RFC 8342. |
|
| |
| RFC 9130 | YANG Data Model for the IS-IS Protocol |
| |
| Authors: | S. Litkowski, Ed., D. Yeung, A. Lindem, J. Zhang, L. Lhotka. |
| Date: | October 2022 |
| Formats: | txt xml pdf json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9130 |
|
This document defines a YANG data model that can be used to configure and manage the IS-IS protocol on network elements. |
|
| |
| RFC 9131 | Gratuitous Neighbor Discovery: Creating Neighbor Cache Entries on First-Hop Routers |
| |
|
|
Neighbor Discovery (RFC 4861) is used by IPv6 nodes to determine the link-layer addresses of neighboring nodes as well as to discover and maintain reachability information. This document updates RFC 4861 to allow routers to proactively create a Neighbor Cache entry when a newIPv6 address is assigned to a node. It also updates RFC 4861 and recommends that nodes send unsolicited Neighbor Advertisements upon assigning a new IPv6 address. These changes will minimize the delay and packet loss when a node initiates connections to an off-link destination from a new IPv6 address. |
|
| |
| RFC 9132 | Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification |
| |
| Authors: | M. Boucadair, Ed., J. Shallow, T. Reddy.K. |
| Date: | September 2021 |
| Formats: | txt html pdf json xml |
| Obsoletes: | RFC 8782 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9132 |
|
This document specifies the Distributed Denial-of-Service Open ThreatSignaling (DOTS) signal channel, a protocol for signaling the need for protection against Distributed Denial-of-Service (DDoS) attacks to a server capable of enabling network traffic mitigation on behalf of the requesting client.
A companion document defines the DOTS data channel, a separate reliable communication layer for DOTS management and configuration purposes.
This document obsoletes RFC 8782. |
|
| |
| RFC 9133 | Controlling Filtering Rules Using Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel |
| |
| Authors: | K. Nishizuka, M. Boucadair, T. Reddy.K, T. Nagata. |
| Date: | September 2021 |
| Formats: | txt html pdf json xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9133 |
|
This document specifies an extension to the Distributed Denial-of-Service Open Threat Signaling (DOTS) signal channel protocol so thatDOTS clients can control their filtering rules when an attack mitigation is active.
Particularly, this extension allows a DOTS client to activate or deactivate existing filtering rules during a Distributed Denial-of-Service (DDoS) attack. The characterization of these filtering rules is conveyed by a DOTS client during an 'idle' time (i.e., no mitigation is active) by means of the DOTS data channel protocol. |
|
| |
| RFC 9134 | RTP Payload Format for ISO/IEC 21122 (JPEG XS) |
| |
| Authors: | T. Bruylants, A. Descampe, C. Damman, T. Richter. |
| Date: | October 2021 |
| Formats: | txt json html pdf xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9134 |
|
This document specifies a Real-Time Transport Protocol (RTP) payload format to be used for transporting video encoded with JPEG XS (ISO/IEC 21122). JPEG XS is a low-latency, lightweight image coding system. Compared to an uncompressed video use case, it allows higher resolutions and video frame rates while offering visually lossless quality, reduced power consumption, and encoding-decoding latency confined to a fraction of a video frame. |
|
| |
| RFC 9135 | Integrated Routing and Bridging in Ethernet VPN (EVPN) |
| |
| Authors: | A. Sajassi, S. Salam, S. Thoria, J. Drake, J. Rabadan. |
| Date: | October 2021 |
| Formats: | txt json pdf xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9135 |
|
Ethernet VPN (EVPN) provides an extensible and flexible multihomingVPN solution over an MPLS/IP network for intra-subnet connectivity among Tenant Systems and end devices that can be physical or virtual.However, there are scenarios for which there is a need for a dynamic and efficient inter-subnet connectivity among these Tenant Systems and end devices while maintaining the multihoming capabilities ofEVPN. This document describes an Integrated Routing and Bridging(IRB) solution based on EVPN to address such requirements. |
|
| |
| RFC 9136 | IP Prefix Advertisement in Ethernet VPN (EVPN) |
| |
| Authors: | J. Rabadan, Ed., W. Henderickx, J. Drake, W. Lin, A. Sajassi. |
| Date: | October 2021 |
| Formats: | txt xml pdf html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9136 |
|
The BGP MPLS-based Ethernet VPN (EVPN) (RFC 7432) mechanism provides a flexible control plane that allows intra-subnet connectivity in anMPLS and/or Network Virtualization Overlay (NVO) (RFC 7365) network.In some networks, there is also a need for dynamic and efficient inter-subnet connectivity across Tenant Systems and end devices that can be physical or virtual and do not necessarily participate in dynamic routing protocols. This document defines a new EVPN route type for the advertisement of IP prefixes and explains some use-case examples where this new route type is used. |
|
| |
| RFC 9140 | Nimble Out-of-Band Authentication for EAP (EAP-NOOB) |
| |
| Authors: | T. Aura, M. Sethi, A. Peltonen. |
| Date: | December 2021 |
| Formats: | txt html json pdf xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9140 |
|
The Extensible Authentication Protocol (EAP) provides support for multiple authentication methods. This document defines the EAP-NOOB authentication method for nimble out-of-band (OOB) authentication and key derivation. The EAP method is intended for bootstrapping all kinds of Internet-of-Things (IoT) devices that have no preconfigured authentication credentials. The method makes use of a user-assisted, one-directional, out-of-band (OOB) message between the peer device and authentication server to authenticate the in-band key exchange.The device must have a nonnetwork input or output interface, such as a display, microphone, speaker, or blinking light, that can send or receive dynamically generated messages of tens of bytes in length. |
|
| |
| RFC 9141 | Updating References to the IETF FTP Service |
| |
| Authors: | R. Danyliw. |
| Date: | November 2021 |
| Formats: | txt html pdf xml json |
| Updates: | RFC 2077, RFC 2418, RFC 2648, RFC 2954, RFC 2955, RFC 3020, RFC 3083, RFC 3201, RFC 3202, RFC 3295, RFC 3684, RFC 3962, RFC 3970, RFC 4036, RFC 4131, RFC 4251, RFC 4323, RFC 4546, RFC 4547, RFC 4639, RFC 4682, RFC 5098, RFC 5428, RFC 6756, RFC 7241 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9141 |
|
The IETF FTP service running at ftp.ietf.org, ops.ietf.org, and ietf.org will be retired. A number of published RFCs in the IETF andIAB streams include URIs that reference this FTP service. To ensure that the materials referenced using the IETF FTP service can still be found, this document updates the FTP-based references in these affected documents with HTTPS URIs. |
|
| |
| RFC 9142 | Key Exchange (KEX) Method Updates and Recommendations for Secure Shell (SSH) |
| |
|
|
This document updates the recommended set of key exchange methods for use in the Secure Shell (SSH) protocol to meet evolving needs for stronger security. It updates RFCs 4250, 4253, 4432, and 4462. |
|
| |
| RFC 9143 | Negotiating Media Multiplexing Using the Session Description Protocol (SDP) |
| |
|
|
This specification defines a new Session Description Protocol (SDP)Grouping Framework extension called 'BUNDLE'. The extension can be used with the SDP offer/answer mechanism to negotiate the usage of a single transport (5-tuple) for sending and receiving media described by multiple SDP media descriptions ("m=" sections). Such transport is referred to as a "BUNDLE transport", and the media is referred to as "bundled media". The "m=" sections that use the BUNDLE transport form a BUNDLE group.
This specification defines a new RTP Control Protocol (RTCP) SourceDescription (SDES) item and a new RTP header extension.
This specification updates RFCs 3264, 5888, and 7941.
This specification obsoletes RFC 8843. |
|
| |
| RFC 9144 | Comparison of Network Management Datastore Architecture (NMDA) Datastores |
| |
| Authors: | A. Clemm, Y. Qu, J. Tantsura, A. Bierman. |
| Date: | December 2021 |
| Formats: | txt xml html pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9144 |
|
This document defines a Remote Procedure Call (RPC) operation to compare management datastores that comply with the Network ManagementDatastore Architecture (NMDA). |
|
| |
| RFC 9145 | Integrity Protection for the Network Service Header (NSH) and Encryption of Sensitive Context Headers |
| |
| Authors: | M. Boucadair, T. Reddy.K, D. Wing. |
| Date: | December 2021 |
| Formats: | txt xml pdf html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9145 |
|
This specification presents an optional method to add integrity protection directly to the Network Service Header (NSH) used forService Function Chaining (SFC). Also, this specification allows for the encryption of sensitive metadata (MD) that is carried in the NSH. |
|
| |
| RFC 9146 | Connection Identifier for DTLS 1.2 |
| |
| Authors: | E. Rescorla, Ed., H. Tschofenig, Ed., T. Fossati, A. Kraus. |
| Date: | March 2022 |
| Formats: | txt json html pdf xml |
| Updates: | RFC 6347 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9146 |
|
This document specifies the Connection ID (CID) construct for theDatagram Transport Layer Security (DTLS) protocol version 1.2.
A CID is an identifier carried in the record layer header that gives the recipient additional information for selecting the appropriate security association. In "classical" DTLS, selecting a security association of an incoming DTLS record is accomplished with the help of the 5-tuple. If the source IP address and/or source port changes during the lifetime of an ongoing DTLS session, then the receiver will be unable to locate the correct security context.
The new ciphertext record format with the CID also provides content type encryption and record layer padding.
This document updates RFC 6347. |
|
| |
| RFC 9147 | The Datagram Transport Layer Security (DTLS) Protocol Version 1.3 |
| |
|
|
This document specifies version 1.3 of the Datagram Transport LayerSecurity (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.
The DTLS 1.3 protocol is based on the Transport Layer Security (TLS)1.3 protocol and provides equivalent security guarantees with the exception of order protection / non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol.
This document obsoletes RFC 6347. |
|
| |
| RFC 9148 | EST-coaps: Enrollment over Secure Transport with the Secure Constrained Application Protocol |
| |
| Authors: | P. van der Stok, P. Kampanakis, M. Richardson, S. Raza. |
| Date: | April 2022 |
| Formats: | txt html json pdf xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9148 |
|
Enrollment over Secure Transport (EST) is used as a certificate provisioning protocol over HTTPS. Low-resource devices often use the lightweight Constrained Application Protocol (CoAP) for message exchanges. This document defines how to transport EST payloads over secure CoAP (EST-coaps), which allows constrained devices to use existing EST functionality for provisioning certificates. |
|
| |
| RFC 9149 | TLS Ticket Requests |
| |
| Authors: | T. Pauly, D. Schinazi, C.A. Wood. |
| Date: | April 2022 |
| Formats: | txt html pdf xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9149 |
|
TLS session tickets enable stateless connection resumption for clients without server-side, per-client state. Servers vend an arbitrary number of session tickets to clients, at their discretion, upon connection establishment. Clients store and use tickets when resuming future connections. This document describes a mechanism by which clients can specify the desired number of tickets needed for future connections. This extension aims to provide a means for servers to determine the number of tickets to generate in order to reduce ticket waste while simultaneously priming clients for future connection attempts. |
|
| |
| RFC 9154 | Extensible Provisioning Protocol (EPP) Secure Authorization Information for Transfer |
| |
| Authors: | J. Gould, R. Wilhelm. |
| Date: | December 2021 |
| Formats: | txt pdf xml html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9154 |
|
The Extensible Provisioning Protocol (EPP) (RFC 5730) defines the use of authorization information to authorize a transfer of an EPP object, such as a domain name, between clients that are referred to as "registrars". Object-specific, password-based authorization information (see RFCs 5731 and 5733) is commonly used but raises issues related to the security, complexity, storage, and lifetime of authentication information. This document defines an operational practice, using the EPP RFCs, that leverages the use of strong random authorization information values that are short lived, not stored by the client, and stored by the server using a cryptographic hash that provides for secure authorization information that can safely be used for object transfers. |
|
| |
| RFC 9155 | Deprecating MD5 and SHA-1 Signature Hashes in TLS 1.2 and DTLS 1.2 |
| |
|
|
The MD5 and SHA-1 hashing algorithms are increasingly vulnerable to attack, and this document deprecates their use in TLS 1.2 and DTLS1.2 digital signatures. However, this document does not deprecateSHA-1 with Hashed Message Authentication Code (HMAC), as used in record protection. This document updates RFC 5246. |
|
| |
| RFC 9156 | DNS Query Name Minimisation to Improve Privacy |
| |
|
|
This document describes a technique called "QNAME minimisation" to improve DNS privacy, where the DNS resolver no longer always sends the full original QNAME and original QTYPE to the upstream name server. This document obsoletes RFC 7816. |
|
| |
| RFC 9157 | Revised IANA Considerations for DNSSEC |
| |
|
|
This document changes the review requirements needed to get DNSSEC algorithms and resource records added to IANA registries. It updatesRFC 6014 to include hash algorithms for Delegation Signer (DS) records and NextSECure version 3 (NSEC3) parameters (for HashedAuthenticated Denial of Existence). It also updates RFCs 5155 and6014, which have requirements for DNSSEC algorithms, and updates RFC8624 to clarify the implementation recommendation related to the algorithms described in RFCs that are not on the standards track.The rationale for these changes is to bring the requirements for DS records and hash algorithms used in NSEC3 in line with the requirements for all other DNSSEC algorithms. |
|
| |
| RFC 9159 | IPv6 Mesh over BLUETOOTH(R) Low Energy Using the Internet Protocol Support Profile (IPSP) |
| |
| Authors: | C. Gomez, S.M. Darroudi, T. Savolainen, M. Spoerk. |
| Date: | December 2021 |
| Formats: | txt html xml json pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9159 |
|
RFC 7668 describes the adaptation of IPv6 over Low-Power WirelessPersonal Area Network (6LoWPAN) techniques to enable IPv6 overBluetooth Low Energy (Bluetooth LE) networks that follow the star topology. However, recent Bluetooth specifications allow the formation of extended topologies as well. This document specifies mechanisms that are needed to enable IPv6 mesh over Bluetooth LE links established by using the Bluetooth Internet Protocol SupportProfile (IPSP). This document does not specify the routing protocol to be used in an IPv6 mesh over Bluetooth LE links. |
|
| |
| RFC 9161 | Operational Aspects of Proxy ARP/ND in Ethernet Virtual Private Networks |
| |
| Authors: | J. Rabadan, Ed., S. Sathappan, K. Nagaraj, G. Hankins, T. King. |
| Date: | January 2022 |
| Formats: | txt pdf xml html json |
| Updates: | RFC 7432 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9161 |
|
This document describes the Ethernet Virtual Private Network (EVPN)Proxy ARP/ND function augmented by the capability of the ARP/NDExtended Community. From that perspective, this document updates theEVPN specification to provide more comprehensive documentation of the operation of the Proxy ARP/ND function. The EVPN Proxy ARP/ND function and the ARP/ND Extended Community help operators of InternetExchange Points, Data Centers, and other networks deal with IPv4 andIPv6 address resolution issues associated with large BroadcastDomains by reducing and even suppressing the flooding produced by address resolution in the EVPN network. |
|
| |
| RFC 9164 | Concise Binary Object Representation (CBOR) Tags for IPv4 and IPv6 Addresses and Prefixes |
| |
| Authors: | M. Richardson, C. Bormann. |
| Date: | December 2021 |
| Formats: | txt html xml pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9164 |
|
This specification defines two Concise Binary Object Representation(CBOR) tags for use with IPv6 and IPv4 addresses and prefixes. |
|
| |
| RFC 9165 | Additional Control Operators for the Concise Data Definition Language (CDDL) |
| |
|
|
The Concise Data Definition Language (CDDL), standardized in RFC8610, provides "control operators" as its main language extension point.
The present document defines a number of control operators that were not yet ready at the time RFC 8610 was completed: .plus, .cat, and.det for the construction of constants; .abnf/.abnfb for includingABNF (RFC 5234 and RFC 7405) in CDDL specifications; and .feature for indicating the use of a non-basic feature in an instance. |
|
| |
| RFC 9166 | A YANG Data Model for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping |
| |
| Authors: | H. Zhao, X. Liu, Y. Liu, A. Peter, M. Sivakumar. |
| Date: | February 2022 |
| Formats: | txt pdf json xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9166 |
|
This document defines a YANG data model that can be used to configure and manage Internet Group Management Protocol (IGMP) and MulticastListener Discovery (MLD) snooping devices. The YANG module in this document conforms to the Network Management Datastore Architecture(NMDA). |
|
| |
| RFC 9167 | Registry Maintenance Notification for the Extensible Provisioning Protocol (EPP) |
| |
| Authors: | T. Sattler, R. Carney, J. Kolker. |
| Date: | December 2021 |
| Formats: | txt pdf json xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9167 |
|
This document describes an Extensible Provisioning Protocol (EPP) extension called "Registry Maintenance Notification", which is used by EPP servers to notify EPP clients and allow EPP clients to queryEPP servers regarding maintenance events. |
|
| |
| RFC 9168 | Path Computation Element Communication Protocol (PCEP) Extension for Flow Specification |
| |
| Authors: | D. Dhody, A. Farrel, Z. Li. |
| Date: | January 2022 |
| Formats: | txt pdf xml html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9168 |
|
The Path Computation Element (PCE) is a functional component capable of selecting paths through a traffic engineering (TE) network. These paths may be supplied in response to requests for computation or may be unsolicited requests issued by the PCE to network elements. Both approaches use the PCE Communication Protocol (PCEP) to convey the details of the computed path.
Traffic flows may be categorized and described using "FlowSpecifications". RFC 8955 defines the Flow Specification and describes how Flow Specification components are used to describe traffic flows. RFC 8955 also defines how Flow Specifications may be distributed in BGP to allow specific traffic flows to be associated with routes.
This document specifies a set of extensions to PCEP to support dissemination of Flow Specifications. This allows a PCE to indicate what traffic should be placed on each path that it is aware of.
The extensions defined in this document include the creation, update, and withdrawal of Flow Specifications via PCEP and can be applied to tunnels initiated by the PCE or to tunnels where control is delegated to the PCE by the Path Computation Client (PCC). Furthermore, a PCC requesting a new path can include Flow Specifications in the request to indicate the purpose of the tunnel allowing the PCE to factor this into the path computation. |
|
| |
| RFC 9171 | Bundle Protocol Version 7 |
| |
| Authors: | S. Burleigh, K. Fall, E. Birrane, III. |
| Date: | January 2022 |
| Formats: | txt html xml pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9171 |
|
This document presents a specification for the Bundle Protocol, adapted from the experimental Bundle Protocol specification developed by the Delay-Tolerant Networking Research Group of the InternetResearch Task Force and documented in RFC 5050. |
|
| |
| RFC 9172 | Bundle Protocol Security (BPSec) |
| |
| Authors: | E. Birrane, III, K. McKeever. |
| Date: | January 2022 |
| Formats: | txt json pdf xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9172 |
|
This document defines a security protocol providing data integrity and confidentiality services for the Bundle Protocol (BP). |
|
| |
| RFC 9173 | Default Security Contexts for Bundle Protocol Security (BPSec) |
| |
| Authors: | E. Birrane, III, A. White, S. Heiner. |
| Date: | January 2022 |
| Formats: | txt json html pdf xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9173 |
|
This document defines default integrity and confidentiality security contexts that can be used with Bundle Protocol Security (BPSec) implementations. These security contexts are intended to be used both for testing the interoperability of BPSec implementations and for providing basic security operations when no other security contexts are defined or otherwise required for a network. |
|
| |
| RFC 9174 | Delay-Tolerant Networking TCP Convergence-Layer Protocol Version 4 |
| |
| Authors: | B. Sipos, M. Demmer, J. Ott, S. Perreault. |
| Date: | January 2022 |
| Formats: | txt html pdf json xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9174 |
|
This document describes a TCP convergence layer (TCPCL) for Delay-Tolerant Networking (DTN). This version of the TCPCL protocol resolves implementation issues in the earlier TCPCL version 3 as defined in RFC 7242 and provides updates to the Bundle Protocol (BP) contents, encodings, and convergence-layer requirements in BP version7 (BPv7). Specifically, TCPCLv4 uses BPv7 bundles encoded by theConcise Binary Object Representation (CBOR) as its service data unit being transported and provides a reliable transport of such bundles.This TCPCL version also includes security and extensibility mechanisms. |
|
| |
| RFC 9175 | Constrained Application Protocol (CoAP): Echo, Request-Tag, and Token Processing |
| |
|
|
This document specifies enhancements to the Constrained ApplicationProtocol (CoAP) that mitigate security issues in particular use cases. The Echo option enables a CoAP server to verify the freshness of a request or to force a client to demonstrate reachability at its claimed network address. The Request-Tag option allows the CoAP server to match block-wise message fragments belonging to the same request. This document updates RFC 7252 with respect to the following: processing requirements for client Tokens, forbidding non- secure reuse of Tokens to ensure response-to-request binding whenCoAP is used with a security protocol, and amplification mitigation(where the use of the Echo option is now recommended). |
|
| |
| RFC 9176 | Constrained RESTful Environments (CoRE) Resource Directory |
| |
| Authors: | C. Amsüss, Ed., Z. Shelby, M. Koster, C. Bormann, P. van der Stok. |
| Date: | April 2022 |
| Formats: | txt json xml pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9176 |
|
In many Internet of Things (IoT) applications, direct discovery of resources is not practical due to sleeping nodes or networks where multicast traffic is inefficient. These problems can be solved by employing an entity called a Resource Directory (RD), which contains information about resources held on other servers, allowing lookups to be performed for those resources. The input to an RD is composed of links, and the output is composed of links constructed from the information stored in the RD. This document specifies the web interfaces that an RD supports for web servers to discover the RD and to register, maintain, look up, and remove information on resources.Furthermore, new target attributes useful in conjunction with an RD are defined. |
|
| |
| RFC 9177 | Constrained Application Protocol (CoAP) Block-Wise Transfer Options Supporting Robust Transmission |
| |
| Authors: | M. Boucadair, J. Shallow. |
| Date: | March 2022 |
| Formats: | txt xml pdf json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9177 |
|
This document specifies alternative Constrained Application Protocol(CoAP) block-wise transfer options: Q-Block1 and Q-Block2.
These options are similar to, but distinct from, the CoAP Block1 andBlock2 options defined in RFC 7959. The Q-Block1 and Q-Block2 options are not intended to replace the Block1 and Block2 options but rather have the goal of supporting Non-confirmable (NON) messages for large amounts of data with fewer packet interchanges. Also, theQ-Block1 and Q-Block2 options support faster recovery should any of the blocks get lost in transmission. |
|
| |
| RFC 9179 | A YANG Grouping for Geographic Locations |
| |
|
|
This document defines a generic geographical location YANG grouping.The geographical location grouping is intended to be used in YANG data models for specifying a location on or in reference to Earth or any other astronomical object. |
|
| |
| RFC 9181 | A Common YANG Data Model for Layer 2 and Layer 3 VPNs |
| |
| Authors: | S. Barguil, O. Gonzalez de Dios, Ed., M. Boucadair, Ed., Q. Wu. |
| Date: | February 2022 |
| Formats: | txt html xml json pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9181 |
|
This document defines a common YANG module that is meant to be reused by various VPN-related modules such as Layer 3 VPN and Layer 2 VPN network models. |
|
| |
| RFC 9182 | A YANG Network Data Model for Layer 3 VPNs |
| |
| Authors: | S. Barguil, O. Gonzalez de Dios, Ed., M. Boucadair, Ed., L. Munoz, A. Aguado. |
| Date: | February 2022 |
| Formats: | txt pdf xml json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9182 |
|
As a complement to the Layer 3 Virtual Private Network Service Model(L3SM), which is used for communication between customers and service providers, this document defines an L3VPN Network Model (L3NM) that can be used for the provisioning of Layer 3 Virtual Private Network(L3VPN) services within a service provider network. The model provides a network-centric view of L3VPN services.
The L3NM is meant to be used by a network controller to derive the configuration information that will be sent to relevant network devices. The model can also facilitate communication between a service orchestrator and a network controller/orchestrator. |
|
| |
| RFC 9183 | Single Nickname for an Area Border RBridge in Multilevel Transparent Interconnection of Lots of Links (TRILL) |
| |
| Authors: | M. Zhang, D. Eastlake 3rd, R. Perlman, M. Cullen, H. Zhai. |
| Date: | February 2022 |
| Formats: | txt json pdf xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9183 |
|
A major issue in multilevel TRILL is how to manage RBridge nicknames.In this document, area border RBridges use a single nickname in bothLevel 1 and Level 2. RBridges in Level 2 must obtain unique nicknames but RBridges in different Level 1 areas may have the same nicknames. |
|
| |
| RFC 9184 | BGP Extended Community Registries Update |
| |
|
|
This document updates several BGP Extended Community registries in order to replace the "Experimental Use" registration procedure in some entries, since their use is clearly not experimental and is thus misleading.
This document updates RFCs 7153 and 8955. |
|
| |
| RFC 9186 | Fast Failover in Protocol Independent Multicast - Sparse Mode (PIM-SM) Using Bidirectional Forwarding Detection (BFD) for Multipoint Networks |
| |
|
|
This document specifies how Bidirectional Forwarding Detection (BFD) for multipoint networks can provide sub-second failover for routers that participate in Protocol Independent Multicast - Sparse Mode(PIM-SM). An extension to the PIM Hello message used to bootstrap a point-to-multipoint BFD session is also defined in this document. |
|
| |
| RFC 9190 | EAP-TLS 1.3: Using the Extensible Authentication Protocol with TLS 1.3 |
| |
|
|
The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides a standard mechanism for support of multiple authentication methods. This document specifies the use of EAP-TLS with TLS 1.3 while remaining backwards compatible with existing implementations ofEAP-TLS. TLS 1.3 provides significantly improved security and privacy, and reduced latency when compared to earlier versions ofTLS. EAP-TLS with TLS 1.3 (EAP-TLS 1.3) further improves security and privacy by always providing forward secrecy, never disclosing the peer identity, and by mandating use of revocation checking when compared to EAP-TLS with earlier versions of TLS. This document also provides guidance on authentication, authorization, and resumption for EAP-TLS in general (regardless of the underlying TLS version used). This document updates RFC 5216. |
|
| |
| RFC 9193 | Sensor Measurement Lists (SenML) Fields for Indicating Data Value Content-Format |
| |
|
|
The Sensor Measurement Lists (SenML) media types support multiple types of values, from numbers to text strings and arbitrary binaryData Values. In order to facilitate processing of binary DataValues, this document specifies a pair of new SenML fields for indicating the content format of those binary Data Values, i.e., their Internet media type, including parameters as well as any content codings applied. |
|
| |
| RFC 9194 | A YANG Module for IS-IS Reverse Metric |
| |
|
|
This document defines a YANG module for managing the reverse metric extension to the Intermediate System to Intermediate System (IS-IS) intra-domain routing information exchange protocol. |
|
| |
| RFC 9195 | A File Format for YANG Instance Data |
| |
| Authors: | B. Lengyel, B. Claise. |
| Date: | February 2022 |
| Formats: | txt html xml pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9195 |
|
There is a need to document data defined in YANG models at design time, implementation time, or when a live server is unavailable.This document specifies a standard file format for YANG instance data, which follows the syntax and semantics of existing YANG models and annotates it with metadata. |
|
| |
| RFC 9196 | YANG Modules Describing Capabilities for Systems and Datastore Update Notifications |
| |
| Authors: | B. Lengyel, A. Clemm, B. Claise. |
| Date: | February 2022 |
| Formats: | txt json pdf xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9196 |
|
This document defines two YANG modules, "ietf-system-capabilities" and "ietf-notification-capabilities".
The module "ietf-system-capabilities" provides a placeholder structure that can be used to discover YANG-related system capabilities for servers. The module can be used to report capability information from the server at runtime or at implementation time by making use of the YANG instance data file format.
The module "ietf-notification-capabilities" augments "ietf-system- capabilities" to specify capabilities related to "Subscription toYANG Notifications for Datastore Updates" (RFC 8641). |
|
| |
| RFC 9197 | Data Fields for In Situ Operations, Administration, and Maintenance (IOAM) |
| |
| Authors: | F. Brockners, Ed., S. Bhandari, Ed., T. Mizrahi, Ed.. |
| Date: | May 2022 |
| Formats: | txt json pdf html xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9197 |
|
In situ Operations, Administration, and Maintenance (IOAM) collects operational and telemetry information in the packet while the packet traverses a path between two points in the network. This document discusses the data fields and associated data types for IOAM. IOAM-Data-Fields can be encapsulated into a variety of protocols, such asNetwork Service Header (NSH), Segment Routing, Generic NetworkVirtualization Encapsulation (Geneve), or IPv6. IOAM can be used to complement OAM mechanisms based on, e.g., ICMP or other types of probe packets. |
|
| |
| RFC 9198 | Advanced Unidirectional Route Assessment (AURA) |
| |
| Authors: | J. Alvarez-Hamelin, A. Morton, J. Fabini, C. Pignataro, R. Geib. |
| Date: | May 2022 |
| Formats: | txt html pdf json xml |
| Updates: | RFC 2330 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9198 |
|
This memo introduces an advanced unidirectional route assessment(AURA) metric and associated measurement methodology based on the IPPerformance Metrics (IPPM) framework (RFC 2330). This memo updatesRFC 2330 in the areas of path-related terminology and path description, primarily to include the possibility of parallel subpaths between a given Source and Destination pair, owing to the presence of multipath technologies. |
|
| |
| RFC 9200 | Authentication and Authorization for Constrained Environments Using the OAuth 2.0 Framework (ACE-OAuth) |
| |
| Authors: | L. Seitz, G. Selander, E. Wahlstroem, S. Erdtman, H. Tschofenig. |
| Date: | August 2022 |
| Formats: | txt html xml json pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9200 |
|
This specification defines a framework for authentication and authorization in Internet of Things (IoT) environments calledACE-OAuth. The framework is based on a set of building blocks including OAuth 2.0 and the Constrained Application Protocol (CoAP), thus transforming a well-known and widely used authorization solution into a form suitable for IoT devices. Existing specifications are used where possible, but extensions are added and profiles are defined to better serve the IoT use cases. |
|
| |
| RFC 9201 | Additional OAuth Parameters for Authentication and Authorization for Constrained Environments (ACE) |
| |
|
|
This specification defines new parameters and encodings for the OAuth2.0 token and introspection endpoints when used with the framework for Authentication and Authorization for Constrained Environments(ACE). These are used to express the proof-of-possession (PoP) key the client wishes to use, the PoP key that the authorization server has selected, and the PoP key the resource server uses to authenticate to the client. |
|
| |
| RFC 9202 | Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE) |
| |
| Authors: | S. Gerdes, O. Bergmann, C. Bormann, G. Selander, L. Seitz. |
| Date: | August 2022 |
| Formats: | txt json pdf xml html |
| Updated by: | RFC 9430 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9202 |
|
This specification defines a profile of the Authentication andAuthorization for Constrained Environments (ACE) framework that allows constrained servers to delegate client authentication and authorization. The protocol relies on DTLS version 1.2 or later for communication security between entities in a constrained network using either raw public keys or pre-shared keys. A resource- constrained server can use this protocol to delegate management of authorization information to a trusted host with less-severe limitations regarding processing power and memory. |
|
| |
| RFC 9203 | The Object Security for Constrained RESTful Environments (OSCORE) Profile of the Authentication and Authorization for Constrained Environments (ACE) Framework |
| |
| Authors: | F. Palombini, L. Seitz, G. Selander, M. Gunnarsson. |
| Date: | August 2022 |
| Formats: | txt pdf xml json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9203 |
|
This document specifies a profile for the Authentication andAuthorization for Constrained Environments (ACE) framework. It utilizes Object Security for Constrained RESTful Environments(OSCORE) to provide communication security and proof-of-possession for a key owned by the client and bound to an OAuth 2.0 access token. |
|
| |
| RFC 9204 | QPACK: Field Compression for HTTP/3 |
| |
| Authors: | C. Krasic, M. Bishop, A. Frindell, Ed.. |
| Date: | June 2022 |
| Formats: | txt pdf xml html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9204 |
|
This specification defines QPACK: a compression format for efficiently representing HTTP fields that is to be used in HTTP/3.This is a variation of HPACK compression that seeks to reduce head- of-line blocking. |
|
| |
| RFC 9207 | OAuth 2.0 Authorization Server Issuer Identification |
| |
| Authors: | K. Meyer zu Selhausen, D. Fett. |
| Date: | March 2022 |
| Formats: | txt json html xml pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9207 |
|
This document specifies a new parameter called iss. This parameter is used to explicitly include the issuer identifier of the authorization server in the authorization response of an OAuth authorization flow. The iss parameter serves as an effective countermeasure to "mix-up attacks". |
|
| |
| RFC 9208 | IMAP QUOTA Extension |
| |
|
|
This document defines a QUOTA extension of the Internet MessageAccess Protocol (IMAP) (see RFCs 3501 and 9051) that permits administrative limits on resource usage (quotas) to be manipulated through the IMAP protocol.
This document obsoletes RFC 2087 but attempts to remain backwards compatible whenever possible. |
|
| |
| RFC 9209 | The Proxy-Status HTTP Response Header Field |
| |
| Authors: | M. Nottingham, P. Sikora. |
| Date: | June 2022 |
| Formats: | txt html json xml pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9209 |
|
This document defines the Proxy-Status HTTP response field to convey the details of an intermediary's response handling, including generated errors. |
|
| |
| RFC 9211 | The Cache-Status HTTP Response Header Field |
| |
|
|
To aid debugging, HTTP caches often append header fields to a response, explaining how they handled the request in an ad hoc manner. This specification defines a standard mechanism to do so that is aligned with HTTP's caching model. |
|
| |
| RFC 9213 | Targeted HTTP Cache Control |
| |
| Authors: | S. Ludin, M. Nottingham, Y. Wu. |
| Date: | June 2022 |
| Formats: | txt xml pdf json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9213 |
|
This specification defines a convention for HTTP response header fields that allow cache directives to be targeted at specific caches or classes of caches. It also defines one such header field, theCDN-Cache-Control response header field, which is targeted at content delivery network (CDN) caches. |
|
| |
| RFC 9214 | OSPFv3 Code Point for MPLS LSP Ping |
| |
|
|
IANA has created "Protocol in the Segment ID Sub-TLV" and "Protocol in Label Stack Sub-TLV of Downstream Detailed Mapping TLV" registries under the "Multiprotocol Label Switching (MPLS) Label Switched Paths(LSPs) Ping Parameters" registry. RFC 8287 defines the code points for Open Shortest Path First (OSPF) and Intermediate System toIntermediate System (IS-IS) protocols.
This document specifies the code point to be used in the Segment ID sub-TLV and Downstream Detailed Mapping (DDMAP) TLV when the InteriorGateway Protocol (IGP) is OSPFv3. This document also updatesRFC 8287 by clarifying that the existing "OSPF" code point is to be used only to indicate OSPFv2 and by defining the behavior when theSegment ID sub-TLV indicates the use of IPv6. |
|
| |
| RFC 9218 | Extensible Prioritization Scheme for HTTP |
| |
|
|
This document describes a scheme that allows an HTTP client to communicate its preferences for how the upstream server prioritizes responses to its requests, and also allows a server to hint to a downstream intermediary how its responses should be prioritized when they are forwarded. This document defines the Priority header field for communicating the initial priority in an HTTP version-independent manner, as well as HTTP/2 and HTTP/3 frames for reprioritizing responses. These share a common format structure that is designed to provide future extensibility. |
|
| |
| RFC 9219 | S/MIME Signature Verification Extension to the JSON Meta Application Protocol (JMAP) |
| |
|
|
This document specifies an extension to "The JSON Meta ApplicationProtocol (JMAP) for Mail" (RFC 8621) for returning the S/MIME signature verification status. |
|
| |
| RFC 9220 | Bootstrapping WebSockets with HTTP/3 |
| |
|
|
The mechanism for running the WebSocket Protocol over a single stream of an HTTP/2 connection is equally applicable to HTTP/3, but theHTTP-version-specific details need to be specified. This document describes how the mechanism is adapted for HTTP/3. |
|
| |
| RFC 9221 | An Unreliable Datagram Extension to QUIC |
| |
| Authors: | T. Pauly, E. Kinnear, D. Schinazi. |
| Date: | March 2022 |
| Formats: | txt html xml pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9221 |
|
This document defines an extension to the QUIC transport protocol to add support for sending and receiving unreliable datagrams over aQUIC connection. |
|
| |
| RFC 9231 | Additional XML Security Uniform Resource Identifiers (URIs) |
| |
|
|
This document updates and corrects the IANA "XML Security URIs" registry that lists URIs intended for use with XML digital signatures, encryption, canonicalization, and key management. TheseURIs identify algorithms and types of information. This document also obsoletes and corrects three errata against RFC 6931. |
|
| |
| RFC 9233 | Internationalized Domain Names for Applications 2008 (IDNA2008) and Unicode 12.0.0 |
| |
|
|
This document describes the changes between Unicode 6.0.0 and Unicode12.0.0 in the context of the current version of InternationalizedDomain Names for Applications 2008 (IDNA2008). Some additions and changes have been made in the Unicode Standard that affect the values produced by the algorithm IDNA2008 specifies. IDNA2008 allows adding exceptions to the algorithm for backward compatibility; however, this document does not add any such exceptions. This document provides the necessary tables to IANA to make its database consistent withUnicode 12.0.0.
To improve understanding, this document describes systems that are being used as alternatives to those that conform to IDNA2008. |
|
| |
| RFC 9234 | Route Leak Prevention and Detection Using Roles in UPDATE and OPEN Messages |
| |
| Authors: | A. Azimov, E. Bogomazov, R. Bush, K. Patel, K. Sriram. |
| Date: | May 2022 |
| Formats: | txt html xml json pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9234 |
|
Route leaks are the propagation of BGP prefixes that violate assumptions of BGP topology relationships, e.g., announcing a route learned from one transit provider to another transit provider or a lateral (i.e., non-transit) peer or announcing a route learned from one lateral peer to another lateral peer or a transit provider.These are usually the result of misconfigured or absent BGP route filtering or lack of coordination between autonomous systems (ASes).Existing approaches to leak prevention rely on marking routes by operator configuration, with no check that the configuration corresponds to that of the External BGP (eBGP) neighbor, or enforcement of the two eBGP speakers agreeing on the peering relationship. This document enhances the BGP OPEN message to establish an agreement of the peering relationship on each eBGP session between autonomous systems in order to enforce appropriate configuration on both sides. Propagated routes are then marked according to the agreed relationship, allowing both prevention and detection of route leaks. |
|
| |
| RFC 9237 | An Authorization Information Format (AIF) for Authentication and Authorization for Constrained Environments (ACE) |
| |
|
|
Information about which entities are authorized to perform what operations on which constituents of other entities is a crucial component of producing an overall system that is secure. Conveying precise authorization information is especially critical in highly automated systems with large numbers of entities, such as theInternet of Things.
This specification provides a generic information model and format for representing such authorization information, as well as two variants of a specific instantiation of that format for use withRepresentational State Transfer (REST) resources identified by URI path. |
|
| |
| RFC 9240 | An Extension for Application-Layer Traffic Optimization (ALTO): Entity Property Maps |
| |
| Authors: | W. Roome, S. Randriamasy, Y. Yang, J. Zhang, K. Gao. |
| Date: | July 2022 |
| Formats: | txt json html xml pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9240 |
|
This document specifies an extension to the base Application-LayerTraffic Optimization (ALTO) Protocol that generalizes the concept of"endpoint properties", which have been tied to IP addresses so far, to entities defined by a wide set of objects. Further, these properties are presented as maps, similar to the network and cost maps in the base ALTO Protocol. While supporting the endpoints and related Endpoint Property Service defined in RFC 7285, the ALTOProtocol is extended in two major directions. First, from endpoints restricted to IP addresses to entities covering a wider and extensible set of objects; second, from properties for specific endpoints to entire entity property maps. These extensions introduce additional features that allow entities and property values to be specific to a given information resource. This is made possible by a generic and flexible design of entity and property types. |
|
| |
| RFC 9241 | Content Delivery Network Interconnection (CDNI) Footprint and Capabilities Advertisement Using Application-Layer Traffic Optimization (ALTO) |
| |
| Authors: | J. Seedorf, Y. Yang, K. Ma, J. Peterson, J. Zhang. |
| Date: | July 2022 |
| Formats: | txt json xml pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9241 |
|
The Content Delivery Networks Interconnection (CDNI) framework in RFC6707 defines a set of protocols to interconnect CDNs to achieve multiple goals, including extending the reach of a given CDN. A CDNIRequest Routing Footprint & Capabilities Advertisement interface(FCI) is needed to achieve the goals of a CDNI. RFC 8008 defines theFCI semantics and provides guidelines on the FCI protocol, but the exact protocol is not specified. This document defines a newApplication-Layer Traffic Optimization (ALTO) service, called "CDNIAdvertisement Service", that provides an implementation of the FCI, following the guidelines defined in RFC 8008. |
|
| |
| RFC 9242 | Intermediate Exchange in the Internet Key Exchange Protocol Version 2 (IKEv2) |
| |
|
|
This document defines a new exchange, called "Intermediate Exchange", for the Internet Key Exchange Protocol Version 2 (IKEv2). This exchange can be used for transferring large amounts of data in the process of IKEv2 Security Association (SA) establishment. An example of the need to do this is using key exchange methods resistant toQuantum Computers (QCs) for IKE SA establishment. The IntermediateExchange makes it possible to use the existing IKE fragmentation mechanism (which cannot be used in the initial IKEv2 exchange), helping to avoid IP fragmentation of large IKE messages if they need to be sent before IKEv2 SA is established. |
|
| |
| RFC 9243 | A YANG Data Model for DHCPv6 Configuration |
| |
|
|
This document describes YANG data models for the configuration and management of Dynamic Host Configuration Protocol for IPv6 (DHCPv6)(RFC 8415) servers, relays, and clients. |
|
| |
| RFC 9244 | Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry |
| |
| Authors: | M. Boucadair, Ed., T. Reddy.K, Ed., E. Doron, M. Chen, J. Shallow. |
| Date: | June 2022 |
| Formats: | txt pdf xml json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9244 |
|
This document aims to enrich the Distributed Denial-of-Service OpenThreat Signaling (DOTS) signal channel protocol with various telemetry attributes, allowing for optimal Distributed Denial-of-Service (DDoS) attack mitigation. It specifies the normal traffic baseline and attack traffic telemetry attributes a DOTS client can convey to its DOTS server in the mitigation request, the mitigation status telemetry attributes a DOTS server can communicate to a DOTS client, and the mitigation efficacy telemetry attributes a DOTS client can communicate to a DOTS server. The telemetry attributes can assist the mitigator in choosing the DDoS mitigation techniques and performing optimal DDoS attack mitigation.
This document specifies two YANG modules: one for representing DOTS telemetry message types and one for sharing the attack mapping details over the DOTS data channel. |
|
| |
| RFC 9246 | URI Signing for Content Delivery Network Interconnection (CDNI) |
| |
| Authors: | R. van Brandenburg, K. Leung, P. Sorber. |
| Date: | June 2022 |
| Formats: | txt html xml pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9246 |
|
This document describes how the concept of URI Signing supports the content access control requirements of Content Delivery NetworkInterconnection (CDNI) and proposes a URI Signing method as a JSONWeb Token (JWT) profile.
The proposed URI Signing method specifies the information needed to be included in the URI to transmit the signed JWT, as well as the claims needed by the signed JWT to authorize a User Agent (UA). The mechanism described can be used both in CDNI and single ContentDelivery Network (CDN) scenarios. |
|
| |
| RFC 9247 | BGP - Link State (BGP-LS) Extensions for Seamless Bidirectional Forwarding Detection (S-BFD) |
| |
| Authors: | Z. Li, S. Zhuang, K. Talaulikar, Ed., S. Aldrin, J. Tantsura, G. Mirsky. |
| Date: | June 2022 |
| Formats: | txt html json xml pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9247 |
|
Seamless Bidirectional Forwarding Detection (S-BFD) defines a simplified mechanism to use Bidirectional Forwarding Detection (BFD) with large portions of negotiation aspects eliminated, thus providing benefits such as quick provisioning as well as improved control and flexibility to network nodes initiating the path monitoring. The link-state routing protocols (IS-IS and OSPF) have been extended to advertise the S-BFD Discriminators.
This document defines extensions to the BGP - Link State (BGP-LS) address family to carry the S-BFD Discriminators' information viaBGP. |
|
| |
| RFC 9248 | Interoperability Profile for Relay User Equipment |
| |
|
|
Video Relay Service (VRS) is a term used to describe a method by which a hearing person can communicate with a sign language speaker who is deaf, deafblind, or hard of hearing (HoH) or has a speech disability using an interpreter (i.e., a Communications Assistant(CA)) connected via a videophone to the sign language speaker and an audio telephone call to the hearing user. The CA interprets using sign language on the videophone link and voice on the telephone link.Often the interpreters may be employed by a company or agency, termed a "provider" in this document. The provider also provides a video service that allows users to connect video devices to their service and subsequently to CAs and other sign language speakers. It is desirable that the videophones used by the sign language speaker conform to a standard so that any device may be used with any provider and that direct video calls between sign language speakers work. This document describes the interface between a videophone and a provider. |
|
| |
| RFC 9249 | A YANG Data Model for NTP |
| |
| Authors: | N. Wu, D. Dhody, Ed., A. Sinha, Ed., A. Kumar S N, Y. Zhao. |
| Date: | July 2022 |
| Formats: | txt json xml pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9249 |
|
This document defines a YANG data model that can be used to configure and manage Network Time Protocol (NTP) version 4. It can also be used to configure and manage version 3. The data model includes configuration data and state data. |
|
| |
| RFC 9250 | DNS over Dedicated QUIC Connections |
| |
| Authors: | C. Huitema, S. Dickinson, A. Mankin. |
| Date: | May 2022 |
| Formats: | txt json pdf html xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9250 |
|
This document describes the use of QUIC to provide transport confidentiality for DNS. The encryption provided by QUIC has similar properties to those provided by TLS, while QUIC transport eliminates the head-of-line blocking issues inherent with TCP and provides more efficient packet-loss recovery than UDP. DNS over QUIC (DoQ) has privacy properties similar to DNS over TLS (DoT) specified in RFC7858, and latency characteristics similar to classic DNS over UDP.This specification describes the use of DoQ as a general-purpose transport for DNS and includes the use of DoQ for stub to recursive, recursive to authoritative, and zone transfer scenarios. |
|
| |
| RFC 9251 | Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Proxies for Ethernet VPN (EVPN) |
| |
| Authors: | A. Sajassi, S. Thoria, M. Mishra, K. Patel, J. Drake, W. Lin. |
| Date: | June 2022 |
| Formats: | txt json pdf xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9251 |
|
This document describes how to support endpoints running the InternetGroup Management Protocol (IGMP) or Multicast Listener Discovery(MLD) efficiently for the multicast services over an Ethernet VPN(EVPN) network by incorporating IGMP/MLD Proxy procedures on EVPNProvider Edges (PEs). |
|
| |
| RFC 9252 | BGP Overlay Services Based on Segment Routing over IPv6 (SRv6) |
| |
| Authors: | G. Dawra, Ed., K. Talaulikar, Ed., R. Raszuk, B. Decraene, S. Zhuang, J. Rabadan. |
| Date: | July 2022 |
| Formats: | txt xml pdf html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9252 |
|
This document defines procedures and messages for SRv6-based BGP services, including Layer 3 Virtual Private Network (L3VPN), EthernetVPN (EVPN), and Internet services. It builds on "BGP/MPLS IP VirtualPrivate Networks (VPNs)" (RFC 4364) and "BGP MPLS-Based Ethernet VPN"(RFC 7432). |
|
| |
| RFC 9253 | Support for iCalendar Relationships |
| |
|
|
This specification updates the iCalendar RELATED-TO property defined in RFC 5545 by adding new relation types and introduces new iCalendar properties (LINK, CONCEPT, and REFID) to allow better linking and grouping of iCalendar components and related data. |
|
| |
| RFC 9254 | Encoding of Data Modeled with YANG in the Concise Binary Object Representation (CBOR) |
| |
| Authors: | M. Veillette, Ed., I. Petrov, Ed., A. Pelov, C. Bormann, M. Richardson. |
| Date: | July 2022 |
| Formats: | txt json xml pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9254 |
|
YANG (RFC 7950) is a data modeling language used to model configuration data, state data, parameters and results of RemoteProcedure Call (RPC) operations or actions, and notifications.
This document defines encoding rules for YANG in the Concise BinaryObject Representation (CBOR) (RFC 8949). |
|
| |
| RFC 9255 | The 'I' in RPKI Does Not Stand for Identity |
| |
|
|
There is a false notion that Internet Number Resources (INRs) in theRPKI can be associated with the real-world identity of the 'holder' of an INR. This document specifies that RPKI does not associate to the INR holder. |
|
| |
| RFC 9256 | Segment Routing Policy Architecture |
| |
| Authors: | C. Filsfils, K. Talaulikar, Ed., D. Voyer, A. Bogdanov, P. Mattes. |
| Date: | July 2022 |
| Formats: | txt html json pdf xml |
| Updates: | RFC 8402 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9256 |
|
Segment Routing (SR) allows a node to steer a packet flow along any path. Intermediate per-path states are eliminated thanks to source routing. SR Policy is an ordered list of segments (i.e., instructions) that represent a source-routed policy. Packet flows are steered into an SR Policy on a node where it is instantiated called a headend node. The packets steered into an SR Policy carry an ordered list of segments associated with that SR Policy.
This document updates RFC 8402 as it details the concepts of SRPolicy and steering into an SR Policy. |
|
| |
| RFC 9258 | Importing External Pre-Shared Keys (PSKs) for TLS 1.3 |
| |
|
|
This document describes an interface for importing external Pre-Shared Keys (PSKs) into TLS 1.3. |
|
| |
| RFC 9259 | Operations, Administration, and Maintenance (OAM) in Segment Routing over IPv6 (SRv6) |
| |
| Authors: | Z. Ali, C. Filsfils, S. Matsushima, D. Voyer, M. Chen. |
| Date: | June 2022 |
| Formats: | txt json pdf xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9259 |
|
This document describes how the existing IPv6 mechanisms for ping and traceroute can be used in a Segment Routing over IPv6 (SRv6) network.The document also specifies the OAM flag (O-flag) in the SegmentRouting Header (SRH) for performing controllable and predictable flow sampling from segment endpoints. In addition, the document describes how a centralized monitoring system performs a path continuity check between any nodes within an SRv6 domain. |
|
| |
| RFC 9260 | Stream Control Transmission Protocol |
| |
|
|
This document describes the Stream Control Transmission Protocol(SCTP) and obsoletes RFC 4960. It incorporates the specification of the chunk flags registry from RFC 6096 and the specification of the I bit of DATA chunks from RFC 7053. Therefore, RFCs 6096 and 7053 are also obsoleted by this document. In addition, RFCs 4460 and 8540, which describe errata for SCTP, are obsoleted by this document.
SCTP was originally designed to transport Public Switched TelephoneNetwork (PSTN) signaling messages over IP networks. It is also suited to be used for other applications, for example, WebRTC.
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 MaximumTransmission Unit (PMTU) 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 9261 | Exported Authenticators in TLS |
| |
|
|
This document describes a mechanism that builds on Transport LayerSecurity (TLS) or Datagram Transport Layer Security (DTLS) and enables peers to provide proof of ownership of an identity, such as an X.509 certificate. This proof can be exported by one peer, transmitted out of band to the other peer, and verified by the receiving peer. |
|
| |
| RFC 9262 | Tree Engineering for Bit Index Explicit Replication (BIER-TE) |
| |
| Authors: | T. Eckert, Ed., M. Menth, G. Cauchie. |
| Date: | October 2022 |
| Formats: | txt html pdf xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9262 |
|
This memo describes per-packet stateless strict and loose path steered replication and forwarding for "Bit Index ExplicitReplication" (BIER) packets (RFC 8279); it is called "TreeEngineering for Bit Index Explicit Replication" (BIER-TE) and is intended to be used as the path steering mechanism for TrafficEngineering with BIER.
BIER-TE introduces a new semantic for "bit positions" (BPs). TheseBPs indicate adjacencies of the network topology, as opposed to (non-TE) BIER in which BPs indicate "Bit-Forwarding Egress Routers"(BFERs). A BIER-TE "packets BitString" therefore indicates the edges of the (loop-free) tree across which the packets are forwarded byBIER-TE. BIER-TE can leverage BIER forwarding engines with little changes. Co-existence of BIER and BIER-TE forwarding in the same domain is possible -- for example, by using separate BIER"subdomains" (SDs). Except for the optional routed adjacencies,BIER-TE does not require a BIER routing underlay and can therefore operate without depending on a routing protocol such as the "InteriorGateway Protocol" (IGP). |
|
| |
| RFC 9263 | Network Service Header (NSH) Metadata Type 2 Variable-Length Context Headers |
| |
| Authors: | Y. Wei, Ed., U. Elzur, S. Majee, C. Pignataro, D. Eastlake 3rd. |
| Date: | August 2022 |
| Formats: | txt html json pdf xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9263 |
|
Service Function Chaining (SFC) uses the Network Service Header (NSH)(RFC 8300) to steer and provide context metadata (MD) with each packet. Such metadata can be of various types, including MD Type 2, consisting of Variable-Length Context Headers. This document specifies several such Context Headers that can be used within aService Function Path (SFP). |
|
| |
| RFC 9264 | Linkset: Media Types and a Link Relation Type for Link Sets |
| |
| Authors: | E. Wilde, H. Van de Sompel. |
| Date: | July 2022 |
| Formats: | txt json pdf html xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9264 |
|
This specification defines two formats and associated media types for representing sets of links as standalone documents. One format is based on JSON, and the other is aligned with the format for representing links in the HTTP "Link" header field. This specification also introduces a link relation type to support the discovery of sets of links. |
|
| |
| RFC 9266 | Channel Bindings for TLS 1.3 |
| |
|
|
This document defines a channel binding type, tls-exporter, that is compatible with TLS 1.3 in accordance with RFC 5056, "On the Use ofChannel Bindings to Secure Channels". Furthermore, it updates the default channel binding to the new binding for versions of TLS greater than 1.2. This document updates RFCs 5801, 5802, 5929, and7677. |
|
| |
| RFC 9270 | GMPLS Signaling Extensions for Shared Mesh Protection |
| |
|
|
ITU-T Recommendation G.808.3 defines the generic aspects of a SharedMesh Protection (SMP) mechanism, where the difference between SMP andShared Mesh Restoration (SMR) is also identified. ITU-TRecommendation G.873.3 defines the protection switching operation and associated protocol for SMP at the Optical Data Unit (ODU) layer.RFC 7412 provides requirements for any mechanism that would be used to implement SMP in a Multi-Protocol Label Switching - TransportProfile (MPLS-TP) network.
This document updates RFCs 4872 and 4873 to provide extensions forGeneralized Multi-Protocol Label Switching (GMPLS) signaling to support the control of the SMP mechanism. |
|
| |
| RFC 9272 | Underlay Path Calculation Algorithm and Constraints for Bit Index Explicit Replication (BIER) |
| |
| Authors: | Z. Zhang, T. Przygienda, A. Dolganow, H. Bidgoli, IJ. Wijnands, A. Gulko. |
| Date: | September 2022 |
| Formats: | txt html json xml pdf |
| Updates: | RFC 8401, RFC 8444 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9272 |
|
This document specifies general rules for the interaction between theBIER Algorithm (BAR) and the IGP Algorithm (IPA) used for underlay path calculation within the Bit Index Explicit Replication (BIER) architecture. The semantics defined in this document update RFC 8401 and RFC 8444. This document also updates the "BIER Algorithm" registry established in RFC 8401. |
|
| |
| RFC 9274 | A Cost Mode Registry for the Application-Layer Traffic Optimization (ALTO) Protocol |
| |
|
|
This document creates a new IANA registry for tracking cost modes supported by the Application-Layer Traffic Optimization (ALTO)Protocol. Also, this document relaxes a constraint that was imposed by the ALTO specification on allowed cost mode values.
This document updates RFC 7285. |
|
| |
| RFC 9277 | On Stable Storage for Items in Concise Binary Object Representation (CBOR) |
| |
| Authors: | M. Richardson, C. Bormann. |
| Date: | August 2022 |
| Formats: | txt pdf html xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9277 |
|
This document defines a stored ("file") format for Concise BinaryObject Representation (CBOR) data items that is friendly to common systems that recognize file types, such as the Unix file(1) command. |
|
| |
| RFC 9278 | JWK Thumbprint URI |
| |
|
|
This specification registers a kind of URI that represents a JSON WebKey (JWK) Thumbprint value. JWK Thumbprints are defined in RFC 7638.This enables JWK Thumbprints to be used, for instance, as key identifiers in contexts requiring URIs. |
|
| |
| RFC 9279 | Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) Message Extension |
| |
| Authors: | M. Sivakumar, S. Venaas, Z. Zhang, H. Asaeda. |
| Date: | August 2022 |
| Formats: | txt json pdf xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9279 |
|
This document specifies a generic mechanism to extend IGMPv3 andMulticast Listener Discovery Version 2 (MLDv2) by using a list ofTLVs (Type, Length, and Value). |
|
| |
| RFC 9286 | Manifests for the Resource Public Key Infrastructure (RPKI) |
| |
|
|
This document defines a "manifest" for use in the Resource Public KeyInfrastructure (RPKI). A manifest is a signed object (file) that contains a listing of all the signed objects (files) in the repository publication point (directory) associated with an authority responsible for publishing in the repository. For each certificate,Certificate Revocation List (CRL), or other type of signed objects issued by the authority that are published at this repository publication point, the manifest contains both the name of the file containing the object and a hash of the file content. Manifests are intended to enable a relying party (RP) to detect certain forms of attacks against a repository. Specifically, if an RP checks a manifest's contents against the signed objects retrieved from a repository publication point, then the RP can detect replay attacks, and unauthorized in-flight modification or deletion of signed objects. This document obsoletes RFC 6486. |
|
| |
| RFC 9287 | Greasing the QUIC Bit |
| |
|
|
This document describes a method for negotiating the ability to send an arbitrary value for the second-most significant bit in QUIC packets. |
|
| |
| RFC 9289 | Towards Remote Procedure Call Encryption by Default |
| |
|
|
This document describes a mechanism that, through the use of opportunistic Transport Layer Security (TLS), enables encryption ofRemote Procedure Call (RPC) transactions while they are in transit.The proposed mechanism interoperates with Open Network Computing(ONC) RPC implementations that do not support it. This document updates RFC 5531. |
|
| |
| RFC 9290 | Concise Problem Details for Constrained Application Protocol (CoAP) APIs |
| |
| Authors: | T. Fossati, C. Bormann. |
| Date: | October 2022 |
| Formats: | txt json xml html pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9290 |
|
This document defines a concise "problem detail" as a way to carry machine-readable details of errors in a Representational StateTransfer (REST) response to avoid the need to define new error response formats for REST APIs for constrained environments. The format is inspired by, but intended to be more concise than, the problem details for HTTP APIs defined in RFC 7807. |
|
| |
| RFC 9291 | A YANG Network Data Model for Layer 2 VPNs |
| |
| Authors: | M. Boucadair, Ed., O. Gonzalez de Dios, Ed., S. Barguil, L. Munoz. |
| Date: | September 2022 |
| Formats: | txt json xml html pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9291 |
|
This document defines an L2VPN Network Model (L2NM) that can be used to manage the provisioning of Layer 2 Virtual Private Network (L2VPN) services within a network (e.g., a service provider network). TheL2NM complements the L2VPN Service Model (L2SM) by providing a network-centric view of the service that is internal to a service provider. The L2NM is particularly meant to be used by a network controller to derive the configuration information that will be sent to relevant network devices.
Also, this document defines a YANG module to manage Ethernet segments and the initial versions of two IANA-maintained modules that include a set of identities of BGP Layer 2 encapsulation types and pseudowire types. |
|
| |
| RFC 9292 | Binary Representation of HTTP Messages |
| |
| Authors: | M. Thomson, C. A. Wood. |
| Date: | August 2022 |
| Formats: | txt pdf xml html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9292 |
|
This document defines a binary format for representing HTTP messages. |
|
| |
| RFC 9294 | Application-Specific Link Attributes Advertisement Using the Border Gateway Protocol - Link State (BGP-LS) |
| |
| Authors: | K. Talaulikar, Ed., P. Psenak, J. Tantsura. |
| Date: | August 2022 |
| Formats: | txt pdf json xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9294 |
|
Extensions have been defined for link-state routing protocols that enable distribution of application-specific link attributes for existing as well as newer applications such as Segment Routing (SR).This document defines extensions to the Border Gateway Protocol -Link State (BGP-LS) to enable the advertisement of these application- specific attributes as a part of the topology information from the network. |
|
| |
| RFC 9295 | Clarifications for Ed25519, Ed448, X25519, and X448 Algorithm Identifiers |
| |
| Authors: | S. Turner, S. Josefsson, D. McCarney, T. Ito. |
| Date: | September 2022 |
| Formats: | txt pdf xml json html |
| Updates: | RFC 8410 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9295 |
|
This document updates RFC 8410 to clarify existing semantics, and specify missing semantics, for key usage bits when used in certificates that support the Ed25519, Ed448, X25519, and X448Elliptic Curve Cryptography algorithms. |
|
| |
| RFC 9297 | HTTP Datagrams and the Capsule Protocol |
| |
| Authors: | D. Schinazi, L. Pardue. |
| Date: | August 2022 |
| Formats: | txt html xml pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9297 |
|
This document describes HTTP Datagrams, a convention for conveying multiplexed, potentially unreliable datagrams inside an HTTP connection.
In HTTP/3, HTTP Datagrams can be sent unreliably using the QUICDATAGRAM extension. When the QUIC DATAGRAM frame is unavailable or undesirable, HTTP Datagrams can be sent using the Capsule Protocol, which is a more general convention for conveying data in HTTP connections.
HTTP Datagrams and the Capsule Protocol are intended for use by HTTP extensions, not applications. |
|
| |
| RFC 9298 | Proxying UDP in HTTP |
| |
|
|
This document describes how to proxy UDP in HTTP, similar to how theHTTP CONNECT method allows proxying TCP in HTTP. More specifically, this document defines a protocol that allows an HTTP client to create a tunnel for UDP communications through an HTTP server that acts as a proxy. |
|
| |
| RFC 9300 | The Locator/ID Separation Protocol (LISP) |
| |
| Authors: | D. Farinacci, V. Fuller, D. Meyer, D. Lewis, A. Cabellos, Ed.. |
| Date: | October 2022 |
| Formats: | txt json pdf xml html |
| Obsoletes: | RFC 6830 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9300 |
|
This document describes the data plane protocol for the Locator/IDSeparation Protocol (LISP). LISP defines two namespaces: EndpointIdentifiers (EIDs), which identify end hosts; and Routing Locators(RLOCs), which identify network attachment points. With this, LISP effectively separates control from data and allows routers to create overlay networks. LISP-capable routers exchange encapsulated packets according to EID-to-RLOC mappings stored in a local Map-Cache.
LISP requires no change to either host protocol stacks or underlay routers and offers Traffic Engineering (TE), multihoming, and mobility, among other features.
This document obsoletes RFC 6830. |
|
| |
| RFC 9301 | Locator/ID Separation Protocol (LISP) Control Plane |
| |
|
|
This document describes the control plane and Mapping Service for theLocator/ID Separation Protocol (LISP), implemented by two types ofLISP-speaking devices -- the LISP Map-Resolver and LISP Map-Server -- that provide a simplified "front end" for one or more Endpoint IDs(EIDs) to Routing Locator mapping databases.
By using this control plane service interface and communicating withMap-Resolvers and Map-Servers, LISP Ingress Tunnel Routers (ITRs) andEgress Tunnel Routers (ETRs) are not dependent on the details of mapping database systems; this behavior facilitates modularity with different database designs. Since these devices implement the "edge" of the LISP control plane infrastructure, connecting EID addressable nodes of a LISP site, the implementation and operational complexity of the overall cost and effort of deploying LISP is reduced.
This document obsoletes RFCs 6830 and 6833. |
|
| |
| RFC 9302 | Locator/ID Separation Protocol (LISP) Map-Versioning |
| |
|
|
This document describes the Locator/ID Separation Protocol (LISP)Map-Versioning mechanism, which provides in-packet information aboutEndpoint-ID-to-Routing-Locator (EID-to-RLOC) mappings used to encapsulate LISP data packets. This approach is based on associating a version number to EID-to-RLOC mappings and transporting such a version number in the LISP-specific header of LISP-encapsulated packets. LISP Map-Versioning is particularly useful to inform communicating Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers(ETRs) about modifications of the mappings used to encapsulate packets. The mechanism is optional and transparent to implementations not supporting this feature, since in the LISP- specific header and in the Map Records, bits used for Map-Versioning can be safely ignored by ITRs and ETRs that do not support or do not want to use the mechanism.
This document obsoletes RFC 6834, which is the initial experimental specifications of the mechanisms updated by this document. |
|
| |
| RFC 9303 | Locator/ID Separation Protocol Security (LISP-SEC) |
| |
| Authors: | F. Maino, V. Ermagan, A. Cabellos, D. Saucez. |
| Date: | October 2022 |
| Formats: | txt xml pdf html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9303 |
|
This memo specifies Locator/ID Separation Protocol Security (LISP-SEC), a set of security mechanisms that provides origin authentication, integrity, and anti-replay protection to the LISP'sEndpoint-ID-to-Routing-Locator (EID-to-RLOC) mapping data conveyed via the mapping lookup process. LISP-SEC also enables verification of authorization on EID-Prefix claims in Map-Reply messages. |
|
| |
| RFC 9304 | Locator/ID Separation Protocol (LISP): Shared Extension Message and IANA Registry for Packet Type Allocations |
| |
|
|
This document specifies a Locator/ID Separation Protocol (LISP) shared message type for defining future extensions and conducting experiments without consuming a LISP Packet Type codepoint for each extension.
This document obsoletes RFC 8113. |
|
| |
| RFC 9305 | Locator/ID Separation Protocol (LISP) Generic Protocol Extension |
| |
| Authors: | F. Maino, Ed., J. Lemon, P. Agarwal, D. Lewis, M. Smith. |
| Date: | October 2022 |
| Formats: | txt json xml pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9305 |
|
This document describes extensions to the Locator/ID SeparationProtocol (LISP) data plane, via changes to the LISP header, to support multiprotocol encapsulation and allow the introduction of new protocol capabilities. |
|
| |
| RFC 9309 | Robots Exclusion Protocol |
| |
| Authors: | M. Koster, G. Illyes, H. Zeller, L. Sassman. |
| Date: | September 2022 |
| Formats: | txt json html pdf xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9309 |
|
This document specifies and extends the "Robots Exclusion Protocol" method originally defined by Martijn Koster in 1994 for service owners to control how content served by their services may be accessed, if at all, by automatic clients known as crawlers.Specifically, it adds definition language for the protocol, instructions for handling errors, and instructions for caching. |
|
| |
| RFC 9310 | X.509 Certificate Extension for 5G Network Function Types |
| |
| Authors: | R. Housley, S. Turner, J. Preuß Mattsson, D. Migault. |
| Date: | January 2023 |
| Formats: | txt json xml pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9310 |
|
This document specifies the certificate extension for includingNetwork Function Types (NFTypes) for the 5G System in X.509 v3 public key certificates as profiled in RFC 5280. |
|
| |
| RFC 9314 | YANG Data Model for Bidirectional Forwarding Detection (BFD) |
| |
| Authors: | M. Jethanandani, Ed., R. Rahman, Ed., L. Zheng, Ed., S. Pallagatti, G. Mirsky. |
| Date: | September 2022 |
| Formats: | txt json pdf xml html |
| Updates: | RFC 9127 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9314 |
|
This document defines a YANG data model that can be used to configure and manage Bidirectional Forwarding Detection (BFD).
The YANG modules in this document conform to the Network ManagementDatastore Architecture (NMDA) (RFC 8342). This document updates"YANG Data Model for Bidirectional Forwarding Detection (BFD)" (RFC9127). |
|
| |
| RFC 9322 | In Situ Operations, Administration, and Maintenance (IOAM) Loopback and Active Flags |
| |
| Authors: | T. Mizrahi, F. Brockners, S. Bhandari, B. Gafni, M. Spiegel. |
| Date: | November 2022 |
| Formats: | txt html xml json pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9322 |
|
In situ Operations, Administration, and Maintenance (IOAM) collects operational and telemetry information in packets while they traverse a path between two points in the network. This document defines two new flags in the IOAM Trace Option headers, specifically the Loopback and Active flags. |
|
| |
| RFC 9323 | A Profile for RPKI Signed Checklists (RSCs) |
| |
| Authors: | J. Snijders, T. Harrison, B. Maddison. |
| Date: | November 2022 |
| Formats: | txt html xml json pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9323 |
|
This document defines a Cryptographic Message Syntax (CMS) protected content type for use with the Resource Public Key Infrastructure(RPKI) to carry a general-purpose listing of checksums (a'checklist'). The objective is to allow for the creation of an attestation, termed an "RPKI Signed Checklist (RSC)", which contains one or more checksums of arbitrary digital objects (files) that are signed with a specific set of Internet Number Resources. When validated, an RSC confirms that the respective Internet resource holder produced the RSC. |
|
| |
| RFC 9324 | Policy Based on the Resource Public Key Infrastructure (RPKI) without Route Refresh |
| |
|
|
A BGP speaker performing policy based on the Resource Public KeyInfrastructure (RPKI) should not issue route refresh to its neighbors because it has received new RPKI data. This document updates RFC8481 by describing how to avoid doing so by either keeping a fullAdj-RIB-In or saving paths dropped due to ROV (Route OriginValidation) so they may be reevaluated with respect to new RPKI data. |
|
| |
| RFC 9326 | In Situ Operations, Administration, and Maintenance (IOAM) Direct Exporting |
| |
| Authors: | H. Song, B. Gafni, F. Brockners, S. Bhandari, T. Mizrahi. |
| Date: | November 2022 |
| Formats: | txt pdf xml html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9326 |
|
In situ Operations, Administration, and Maintenance (IOAM) is used for recording and collecting operational and telemetry information.Specifically, IOAM allows telemetry data to be pushed into data packets while they traverse the network. This document introduces a new IOAM option type (denoted IOAM-Option-Type) called the "IOAMDirect Export (DEX) Option-Type". This Option-Type is used as a trigger for IOAM data to be directly exported or locally aggregated without being pushed into in-flight data packets. The exporting method and format are outside the scope of this document. |
|
| |
| RFC 9328 | RTP Payload Format for Versatile Video Coding (VVC) |
| |
| Authors: | S. Zhao, S. Wenger, Y. Sanchez, Y.-K. Wang, M. M Hannuksela. |
| Date: | December 2022 |
| Formats: | txt json pdf xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9328 |
|
This memo describes an RTP payload format for the Versatile VideoCoding (VVC) specification, which was published as both ITU-TRecommendation H.266 and ISO/IEC International Standard 23090-3. VVC was developed by the Joint Video Experts Team (JVET). The RTP payload format allows for packetization of one or more NetworkAbstraction Layer (NAL) units in each RTP packet payload, as well as fragmentation of a NAL unit into multiple RTP packets. The payload format has wide applicability in videoconferencing, Internet video streaming, and high-bitrate entertainment-quality video, among other applications. |
|
| |
| RFC 9329 | TCP Encapsulation of Internet Key Exchange Protocol (IKE) and IPsec Packets |
| |
|
|
This document describes a method to transport Internet Key ExchangeProtocol (IKE) and IPsec packets over a TCP connection for traversing network middleboxes that may block IKE negotiation over UDP. This method, referred to as "TCP encapsulation", involves sending both IKE packets for Security Association (SA) establishment and EncapsulatingSecurity Payload (ESP) packets over a TCP connection. This method is intended to be used as a fallback option when IKE cannot be negotiated over UDP.
TCP encapsulation for IKE and IPsec was defined in RFC 8229. This document clarifies the specification for TCP encapsulation by including additional clarifications obtained during implementation and deployment of this method. This documents obsoletes RFC 8229. |
|
| |
| RFC 9335 | Completely Encrypting RTP Header Extensions and Contributing Sources |
| |
|
|
While the Secure Real-time Transport Protocol (SRTP) provides confidentiality for the contents of a media packet, a significant amount of metadata is left unprotected, including RTP header extensions and contributing sources (CSRCs). However, this data can be moderately sensitive in many applications. While there have been previous attempts to protect this data, they have had limited deployment, due to complexity as well as technical limitations.
This document updates RFC 3711, the SRTP specification, and definesCryptex as a new mechanism that completely encrypts header extensions and CSRCs and uses simpler Session Description Protocol (SDP) signaling with the goal of facilitating deployment. |
|
| |
| RFC 9336 | X.509 Certificate General-Purpose Extended Key Usage (EKU) for Document Signing |
| |
| Authors: | T. Ito, T. Okubo, S. Turner. |
| Date: | December 2022 |
| Formats: | txt xml pdf html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9336 |
|
RFC 5280 specifies several extended key purpose identifiers(KeyPurposeIds) for X.509 certificates. This document defines a general-purpose Document-Signing KeyPurposeId for inclusion in theExtended Key Usage (EKU) extension of X.509 public key certificates.Document-Signing applications may require that the EKU extension be present and that a Document-Signing KeyPurposeId be indicated in order for the certificate to be acceptable to that Document-Signing application. |
|
| |
| RFC 9339 | OSPF Reverse Metric |
| |
| Authors: | K. Talaulikar, Ed., P. Psenak, H. Johnston. |
| Date: | December 2022 |
| Formats: | txt json xml pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9339 |
|
This document specifies the extensions to OSPF that enable a router to use Link-Local Signaling (LLS) to signal the metric that receivingOSPF neighbor(s) should use for a link to the signaling router. When used on the link to the signaling router, the signaling of this reverse metric (RM) allows a router to influence the amount of traffic flowing towards itself. In certain use cases, this enables routers to maintain symmetric metrics on both sides of a link between them. |
|
| |
| RFC 9341 | Alternate-Marking Method |
| |
| Authors: | G. Fioccola, Ed., M. Cociglio, G. Mirsky, T. Mizrahi, T. Zhou. |
| Date: | December 2022 |
| Formats: | txt html pdf xml json |
| Obsoletes: | RFC 8321 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9341 |
|
This document describes the Alternate-Marking technique to perform packet loss, delay, and jitter measurements on live traffic. This technology can be applied in various situations and for different protocols. According to the classification defined in RFC 7799, it could be considered Passive or Hybrid depending on the application.This document obsoletes RFC 8321. |
|
| |
| RFC 9342 | Clustered Alternate-Marking Method |
| |
| Authors: | G. Fioccola, Ed., M. Cociglio, A. Sapio, R. Sisto, T. Zhou. |
| Date: | December 2022 |
| Formats: | txt xml pdf json html |
| Obsoletes: | RFC 8889 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9342 |
|
This document generalizes and expands the Alternate-Marking methodology to measure any kind of unicast flow whose packets can follow several different paths in the network; this can result in a multipoint-to-multipoint network. The network clustering approach is presented and, for this reason, the technique described here is called "Clustered Alternate Marking". This document obsoletes RFC8889. |
|
| |
| RFC 9343 | IPv6 Application of the Alternate-Marking Method |
| |
| Authors: | G. Fioccola, T. Zhou, M. Cociglio, F. Qin, R. Pang. |
| Date: | December 2022 |
| Formats: | txt xml json pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9343 |
|
This document describes how the Alternate-Marking Method can be used as a passive performance measurement tool in an IPv6 domain. It defines an Extension Header Option to encode Alternate-Marking information in both the Hop-by-Hop Options Header and DestinationOptions Header. |
|
| |
| RFC 9345 | Delegated Credentials for TLS and DTLS |
| |
| Authors: | R. Barnes, S. Iyengar, N. Sullivan, E. Rescorla. |
| Date: | July 2023 |
| Formats: | txt html xml pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9345 |
|
The organizational separation between operators of TLS and DTLS endpoints and the certification authority can create limitations.For example, the lifetime of certificates, how they may be used, and the algorithms they support are ultimately determined by theCertification Authority (CA). This document describes a mechanism to overcome some of these limitations by enabling operators to delegate their own credentials for use in TLS and DTLS without breaking compatibility with peers that do not support this specification. |
|
| |
| RFC 9346 | IS-IS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering |
| |
| Authors: | M. Chen, L. Ginsberg, S. Previdi, D. Xiaodong. |
| Date: | February 2023 |
| Formats: | txt json pdf xml html |
| Obsoletes: | RFC 5316 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9346 |
|
This document describes extensions to the Intermediate System toIntermediate System (IS-IS) protocol to support Multiprotocol LabelSwitching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering(TE) for multiple Autonomous Systems (ASes). It defines IS-IS extensions for the flooding of TE information about inter-AS links, which can be used to perform inter-AS TE path computation.
No support for flooding information from within one AS to another AS is proposed or defined in this document.
This document builds on RFC 5316 by adding support for IPv6-only operation.
This document obsoletes RFC 5316. |
|
| |
| RFC 9347 | Aggregation and Fragmentation Mode for Encapsulating Security Payload (ESP) and Its Use for IP Traffic Flow Security (IP-TFS) |
| |
|
|
This document describes a mechanism for aggregation and fragmentation of IP packets when they are being encapsulated in EncapsulatingSecurity Payload (ESP). This new payload type can be used for various purposes, such as decreasing encapsulation overhead for smallIP packets; however, the focus in this document is to enhance IPTraffic Flow Security (IP-TFS) by adding Traffic Flow Confidentiality(TFC) to encrypted IP-encapsulated traffic. TFC is provided by obscuring the size and frequency of IP traffic using a fixed-size, constant-send-rate IPsec tunnel. The solution allows for congestion control, as well as nonconstant send-rate usage. |
|
| |
| RFC 9348 | A YANG Data Model for IP Traffic Flow Security |
| |
|
|
This document describes a YANG module for the management of IPTraffic Flow Security (IP-TFS) additions to Internet Key ExchangeProtocol version 2 (IKEv2) and IPsec. |
|
| |
| RFC 9349 | Definitions of Managed Objects for IP Traffic Flow Security |
| |
|
|
This document describes managed objects for the management of IPTraffic Flow Security additions to Internet Key Exchange ProtocolVersion 2 (IKEv2) and IPsec. This document provides a read-only version of the objects defined in the YANG module for the same purpose, which is in "A YANG Data Model for IP Traffic Flow Security"(RFC 9348). |
|
| |
| RFC 9350 | IGP Flexible Algorithm |
| |
| Authors: | P. Psenak, Ed., S. Hegde, C. Filsfils, K. Talaulikar, A. Gulko. |
| Date: | February 2023 |
| Formats: | txt html xml json pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9350 |
|
IGP protocols historically compute the best paths over the network based on the IGP metric assigned to the links. Many network deployments use RSVP-TE or Segment Routing - Traffic Engineering (SR-TE) to steer traffic over a path that is computed using different metrics or constraints than the shortest IGP path. This document specifies a solution that allows IGPs themselves to compute constraint-based paths over the network. This document also specifies a way of using Segment Routing (SR) Prefix-SIDs and SRv6 locators to steer packets along the constraint-based paths. |
|
| |
| RFC 9351 | Border Gateway Protocol - Link State (BGP-LS) Extensions for Flexible Algorithm Advertisement |
| |
| Authors: | K. Talaulikar, Ed., P. Psenak, S. Zandi, G. Dawra. |
| Date: | February 2023 |
| Formats: | txt html xml pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9351 |
|
Flexible Algorithm is a solution that allows some routing protocols(e.g., OSPF and IS-IS) to compute paths over a network based on user- defined (and hence, flexible) constraints and metrics. The computation is performed by routers participating in the specific network in a distributed manner using a Flexible Algorithm Definition(FAD). This definition is provisioned on one or more routers and propagated through the network by OSPF and IS-IS flooding.
Border Gateway Protocol - Link State (BGP-LS) enables the collection of various topology information from the network. This document defines extensions to the BGP-LS address family to advertise the FAD as a part of the topology information from the network. |
|
| |
| RFC 9352 | IS-IS Extensions to Support Segment Routing over the IPv6 Data Plane |
| |
| Authors: | P. Psenak, Ed., C. Filsfils, A. Bashandy, B. Decraene, Z. Hu. |
| Date: | February 2023 |
| Formats: | txt pdf xml json html |
| Updates: | RFC 7370 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9352 |
|
The Segment Routing (SR) architecture allows a flexible definition of the end-to-end path by encoding it as a sequence of topological elements called "segments". It can be implemented over the MPLS or the IPv6 data plane. This document describes the IS-IS extensions required to support SR over the IPv6 data plane.
This document updates RFC 7370 by modifying an existing registry. |
|
| |
| RFC 9353 | IGP Extension for Path Computation Element Communication Protocol (PCEP) Security Capability Support in PCE Discovery (PCED) |
| |
|
|
When a Path Computation Element (PCE) is a Label Switching Router(LSR) or a server participating in the Interior Gateway Protocol(IGP), its presence and path computation capabilities can be advertised using IGP flooding. The IGP extensions for PCE Discovery(PCED) (RFCs 5088 and 5089) define a method to advertise path computation capabilities using IGP flooding for OSPF and IS-IS, respectively. However, these specifications lack a method to advertise Path Computation Element Communication Protocol (PCEP) security (e.g., Transport Layer Security (TLS) and TCP AuthenticationOption (TCP-AO)) support capability.
This document defines capability flag bits for the PCE-CAP-FLAGS sub-TLV that can be announced as an attribute in the IGP advertisement to distribute PCEP security support information. In addition, this document updates RFCs 5088 and 5089 to allow advertisement of a KeyID or KEY-CHAIN-NAME sub-TLV to support TCP-AO security capability.This document also updates RFCs 8231 and 8306. |
|
| |
| RFC 9354 | Transmission of IPv6 Packets over Power Line Communication (PLC) Networks |
| |
| Authors: | J. Hou, B. Liu, Y-G. Hong, X. Tang, C. Perkins. |
| Date: | January 2023 |
| Formats: | txt html pdf xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9354 |
|
Power Line Communication (PLC), namely using electric power lines for indoor and outdoor communications, has been widely applied to supportAdvanced Metering Infrastructure (AMI), especially smart meters for electricity. The existing electricity infrastructure facilitates the expansion of PLC deployments due to its potential advantages in terms of cost and convenience. Moreover, a wide variety of accessible devices raises the potential demand of IPv6 for future applications.This document describes how IPv6 packets are transported over constrained PLC networks, such as those described in ITU-T G.9903,IEEE 1901.1, and IEEE 1901.2. |
|
| |
| RFC 9355 | OSPF Bidirectional Forwarding Detection (BFD) Strict-Mode |
| |
| Authors: | K. Talaulikar, Ed., P. Psenak, A. Fu, M. Rajesh. |
| Date: | February 2023 |
| Formats: | txt pdf xml html json |
| Updates: | RFC 2328 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9355 |
|
This document specifies the extensions to OSPF that enable an OSPF router to signal the requirement for a Bidirectional ForwardingDetection (BFD) session prior to adjacency formation. Link-LocalSignaling (LLS) is used to advertise the requirement for strict-modeBFD session establishment for an OSPF adjacency. If both OSPF neighbors advertise BFD strict-mode, adjacency formation will be blocked until a BFD session has been successfully established.
This document updates RFC 2328 by augmenting the OSPF neighbor state machine with a check for BFD session up before progression from Init to 2-Way state when operating in OSPF BFD strict-mode. |
|
| |
| RFC 9356 | Advertising Layer 2 Bundle Member Link Attributes in OSPF |
| |
|
|
There are deployments where the Layer 3 (L3) interface on which OSPF operates is a Layer 2 (L2) interface bundle. Existing OSPF advertisements only support advertising link attributes of the L3 interface. If entities external to OSPF wish to control traffic flows on the individual physical links that comprise the L2 interface bundle, link attribute information for the bundle members is required.
This document defines the protocol extensions for OSPF to advertise the link attributes of L2 bundle members. The document also specifies the advertisement of these OSPF extensions via the BorderGateway Protocol - Link State (BGP-LS) and thereby updates RFC 9085. |
|
| |
| RFC 9357 | Label Switched Path (LSP) Object Flag Extension for Stateful PCE |
| |
|
|
RFC 8231 describes a set of extensions to the Path ComputationElement Communication Protocol (PCEP) to enable stateful control ofMPLS-TE and GMPLS Label Switched Paths (LSPs) via PCEP. One of the extensions is the LSP object, which includes a Flag field with a length of 12 bits. However, all bits of the Flag field have already been assigned.
This document defines a new LSP-EXTENDED-FLAG TLV for the LSP object for an extended Flag field. |
|
| |
| RFC 9358 | Path Computation Element Communication Protocol (PCEP) Extensions for Establishing Relationships between Sets of Label Switched Paths and Virtual Networks |
| |
| Authors: | Y. Lee, H. Zheng, D. Ceccarelli. |
| Date: | February 2023 |
| Formats: | txt html json xml pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9358 |
|
This document describes how to extend the Path Computation ElementCommunication Protocol (PCEP) association mechanism introduced by RFC8697 to further associate sets of Label Switched Paths (LSPs) with a higher-level structure such as a Virtual Network (VN) requested by a customer or application. This extended association mechanism can be used to facilitate control of a VN using the PCE architecture. |
|
| |
| RFC 9359 | Echo Request/Reply for Enabled In Situ OAM (IOAM) Capabilities |
| |
| Authors: | X. Min, G. Mirsky, L. Bo. |
| Date: | April 2023 |
| Formats: | txt html xml pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9359 |
|
This document describes a generic format for use in echo request/ reply mechanisms, which can be used within an IOAM-Domain, allowing the IOAM encapsulating node to discover the enabled IOAM capabilities of each IOAM transit and IOAM decapsulating node. The generic format is intended to be used with a variety of data planes such as IPv6,MPLS, Service Function Chain (SFC), and Bit Index ExplicitReplication (BIER). |
|
| |
| RFC 9360 | CBOR Object Signing and Encryption (COSE): Header Parameters for Carrying and Referencing X.509 Certificates |
| |
|
|
The CBOR Object Signing and Encryption (COSE) message structure uses references to keys in general. For some algorithms, additional properties are defined that carry parameters relating to keys as needed. The COSE Key structure is used for transporting keys outside of COSE messages. This document extends the way that keys can be identified and transported by providing attributes that refer to or contain X.509 certificates. |
|
| |
| RFC 9362 | Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Configuration Attributes for Robust Block Transmission |
| |
| Authors: | M. Boucadair, J. Shallow. |
| Date: | February 2023 |
| Formats: | txt json xml pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9362 |
|
This document specifies new DDoS Open Threat Signaling (DOTS) signal channel configuration parameters that can be negotiated between DOTS peers to enable the use of Q-Block1 and Q-Block2 ConstrainedApplication Protocol (CoAP) options. These options enable robust and faster transmission rates for large amounts of data with less packet interchanges as well as support for faster recovery should any of the blocks get lost in transmission (especially during DDoS attacks).
Also, this document defines a YANG data model for representing these new DOTS signal channel configuration parameters. This model augments the DOTS signal YANG module ("ietf-dots-signal-channel") defined in RFC 9132. |
|
| |
| RFC 9363 | A YANG Data Model for Static Context Header Compression (SCHC) |
| |
|
|
This document describes a YANG data model for the Static ContextHeader Compression (SCHC) compression and fragmentation Rules.
This document formalizes the description of the Rules for better interoperability between SCHC instances either to exchange a set ofRules or to modify the parameters of some Rules. |
|
| |
| RFC 9366 | Multiple SIP Reason Header Field Values |
| |
|
|
The SIP Reason header field as defined in RFC 3326 allows only oneReason value per protocol value. Experience with more recently defined protocols shows it is useful to allow multiple values with the same protocol value. This document updates RFC 3326 to allow multiple values for an indicated registered protocol when that protocol defines what the presence of multiple values means. |
|
| |
| RFC 9368 | Compatible Version Negotiation for QUIC |
| |
|
|
QUIC does not provide a complete version negotiation mechanism but instead only provides a way for the server to indicate that the version the client chose is unacceptable. This document describes a version negotiation mechanism that allows a client and server to select a mutually supported version. Optionally, if the client's chosen version and the negotiated version share a compatible first flight format, the negotiation can take place without incurring an extra round trip. This document updates RFC 8999. |
|
| |
| RFC 9369 | QUIC Version 2 |
| |
|
|
This document specifies QUIC version 2, which is identical to QUIC version 1 except for some trivial details. Its purpose is to combat various ossification vectors and exercise the version negotiation framework. It also serves as a template for the minimum changes in any future version of QUIC.
Note that "version 2" is an informal name for this proposal that indicates it is the second version of QUIC to be published as aStandards Track document. The protocol specified here uses a version number other than 2 in the wire image, in order to minimize ossification risks. |
|
| |
| RFC 9370 | Multiple Key Exchanges in the Internet Key Exchange Protocol Version 2 (IKEv2) |
| |
| Authors: | CJ. Tjhai, M. Tomlinson, G. Bartlett, S. Fluhrer, D. Van Geest, O. Garcia-Morchon, V. Smyslov. |
| Date: | May 2023 |
| Formats: | txt html xml pdf json |
| Updates: | RFC 7296 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9370 |
|
This document describes how to extend the Internet Key ExchangeProtocol Version 2 (IKEv2) to allow multiple key exchanges to take place while computing a shared secret during a Security Association(SA) setup.
This document utilizes the IKE_INTERMEDIATE exchange, where multiple key exchanges are performed when an IKE SA is being established. It also introduces a new IKEv2 exchange, IKE_FOLLOWUP_KE, which is used for the same purpose when the IKE SA is being rekeyed or is creating additional Child SAs.
This document updates RFC 7296 by renaming a Transform Type 4 from"Diffie-Hellman Group (D-H)" to "Key Exchange Method (KE)" and renaming a field in the Key Exchange Payload from "Diffie-HellmanGroup Num" to "Key Exchange Method". It also renames an IANA registry for this Transform Type from "Transform Type 4 - Diffie-Hellman Group Transform IDs" to "Transform Type 4 - Key ExchangeMethod Transform IDs". These changes generalize key exchange algorithms that can be used in IKEv2. |
|
| |
| RFC 9373 | EdDSA Value for IPSECKEY |
| |
| Authors: | R. Moskowitz, T. Kivinen, M. Richardson. |
| Date: | March 2023 |
| Formats: | txt json pdf html xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9373 |
|
This document assigns a value for Edwards-Curve Digital SignatureAlgorithm (EdDSA) Public Keys to the "IPSECKEY Resource RecordParameters" registry. |
|
| |
| RFC 9374 | DRIP Entity Tag (DET) for Unmanned Aircraft System Remote ID (UAS RID) |
| |
|
|
This document describes the use of Hierarchical Host Identity Tags(HHITs) as self-asserting IPv6 addresses, which makes them trustable identifiers for use in Unmanned Aircraft System Remote Identification(UAS RID) and tracking.
Within the context of RID, HHITs will be called DRIP Entity Tags(DETs). HHITs provide claims to the included explicit hierarchy that provides registry (via, for example, DNS, RDAP) discovery for third- party identifier endorsement.
This document updates RFCs 7343 and 7401. |
|
| |
| RFC 9375 | A YANG Data Model for Network and VPN Service Performance Monitoring |
| |
| Authors: | B. Wu, Ed., Q. Wu, Ed., M. Boucadair, Ed., O. Gonzalez de Dios, B. Wen. |
| Date: | April 2023 |
| Formats: | txt html json pdf xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9375 |
|
The data model for network topologies defined in RFC 8345 introduces vertical layering relationships between networks that can be augmented to cover network and service topologies. This document defines a YANG module for performance monitoring (PM) of both underlay networks and overlay VPN services that can be used to monitor and manage network performance on the topology of both layers. |
|
| |
| RFC 9384 | A BGP Cease NOTIFICATION Subcode for Bidirectional Forwarding Detection (BFD) |
| |
|
|
The Bidirectional Forwarding Detection (BFD) protocol (RFC 5880) is used to detect loss of connectivity between two forwarding engines, typically with low latency. BFD is leveraged by routing protocols, including the Border Gateway Protocol (BGP), to bring down routing protocol connections more quickly than the original protocol timers.
This document defines a subcode for the BGP Cease NOTIFICATION message (Section 6.7 of RFC 4271) for use when a BGP connection is being closed due to a BFD session going down. |
|
| |
| RFC 9388 | Content Delivery Network Interconnection (CDNI) Footprint Types: Country Subdivision Code and Footprint Union |
| |
|
|
Open Caching architecture is a use case of Content Delivery NetworkInterconnection (CDNI) in which the commercial Content DeliveryNetwork (CDN) is the upstream CDN (uCDN) and the ISP caching layer serves as the downstream CDN (dCDN). RFC 8006 defines footprint types that are used for footprint objects as part of the Metadata interface (MI). The footprint types are also used for the Footprint& Capabilities Advertisement interface (FCI) as defined in RFC 8008.This document defines two new footprint types. The first footprint type defined is an ISO 3166-2 country subdivision code. Defining this country subdivision code improves granularity for delegation as compared to the ISO 3166-1 country code footprint type defined in RFC8006. The ISO 3166-2 country subdivision code is also added as a new entity domain type in the "ALTO Entity Domain Types" registry defined in Section 7.4 of RFC 9241. The second footprint type defines a footprint union to aggregate footprint objects. This allows for additive semantics over the narrowing semantics defined in Appendix B of RFC 8008 and therefore updates RFC 8008. The two new footprint types are based on the requirements raised by Open Caching but are also applicable to CDNI use cases in general. |
|
| |
| RFC 9390 | Diameter Group Signaling |
| |
| Authors: | M. Jones, M. Liebsch, L. Morand. |
| Date: | April 2023 |
| Formats: | txt html pdf json xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9390 |
|
In large network deployments, a single Diameter node can support over a million concurrent Diameter sessions. In some use cases, Diameter nodes need to apply the same operation to a large group of Diameter sessions concurrently. The Diameter base protocol commands operate on a single session so these use cases can result in many thousands of command exchanges enforcing the same operation on each session in the group. In order to reduce signaling, it is desirable to enable bulk operations on all (or part of) the sessions managed by aDiameter node using a single or a few command exchanges. This document specifies the Diameter protocol extensions to achieve this signaling optimization. |
|
| |
| RFC 9391 | Static Context Header Compression over Narrowband Internet of Things |
| |
|
|
This document describes Static Context Header Compression and fragmentation (SCHC) specifications, RFCs 8724 and 8824, in combination with the 3rd Generation Partnership Project (3GPP) and the Narrowband Internet of Things (NB-IoT).
This document has two parts: one normative part that specifies the use of SCHC over NB-IoT and one informational part that recommends some values if 3GPP wants to use SCHC inside their architectures. |
|
| |
| RFC 9393 | Concise Software Identification Tags |
| |
| Authors: | H. Birkholz, J. Fitzgerald-McKay, C. Schmidt, D. Waltermire. |
| Date: | June 2023 |
| Formats: | txt json xml pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9393 |
|
ISO/IEC 19770-2:2015 Software Identification (SWID) tags provide an extensible XML-based structure to identify and describe individual software components, patches, and installation bundles. SWID tag representations can be too large for devices with network and storage constraints. This document defines a concise representation of SWID tags: Concise SWID (CoSWID) tags. CoSWID supports a set of semantics and features that are similar to those for SWID tags, as well as new semantics that allow CoSWIDs to describe additional types of information, all in a more memory-efficient format. |
|
| |
| RFC 9394 | IMAP PARTIAL Extension for Paged SEARCH and FETCH |
| |
|
|
The PARTIAL extension of the Internet Message Access Protocol (seeRFCs 3501 and 9051) allows clients to limit the number of SEARCH results returned, as well as to perform incremental (paged) searches.This also helps servers to optimize resource usage when performing searches.
This document extends the PARTIAL SEARCH return option originally specified in RFC 5267. It also clarifies some interactions betweenRFC 5267 and RFCs 4731 and 9051.
This document updates RFCs 4731 and 5267. |
|
| |
| RFC 9395 | Deprecation of the Internet Key Exchange Version 1 (IKEv1) Protocol and Obsoleted Algorithms |
| |
|
|
Internet Key Exchange Version 1 (IKEv1) has been deprecated, and RFCs2407, 2408, and 2409 have been moved to Historic status. This document updates RFCs 8221 and 8247 to reflect the usage guidelines of old algorithms that are associated with IKEv1 and are not specified or commonly implemented for IKEv2. This document further updates the IANA registries for IKEv2 "Transform Type Values" by adding a "Status" column where the deprecation status can be listed. |
|
| |
| RFC 9396 | OAuth 2.0 Rich Authorization Requests |
| |
| Authors: | T. Lodderstedt, J. Richer, B. Campbell. |
| Date: | May 2023 |
| Formats: | txt json html pdf xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9396 |
|
This document specifies a new parameter authorization_details that is used to carry fine-grained authorization data in OAuth messages. |
|
| |
| RFC 9398 | A YANG Data Model for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Proxy Devices |
| |
| Authors: | H. Zhao, X. Liu, Y. Liu, M. Panchanathan, M. Sivakumar. |
| Date: | May 2023 |
| Formats: | txt html json pdf xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9398 |
|
This document defines a YANG data model that can be used to configure and manage Internet Group Management Protocol (IGMP) or MulticastListener Discovery (MLD) Proxy devices. The YANG module in this document conforms to the Network Management Datastore Architecture(NMDA). |
|
| |
| RFC 9399 | Internet X.509 Public Key Infrastructure: Logotypes in X.509 Certificates |
| |
|
|
This document specifies a certificate extension for including logotypes in public key certificates and attribute certificates.This document obsoletes RFCs 3709 and 6170. |
|
| |
| RFC 9403 | A YANG Data Model for RIB Extensions |
| |
|
|
A Routing Information Base (RIB) is a list of routes and their corresponding administrative data and operational state.
RFC 8349 defines the basic building blocks for the RIB data model, and this model augments it to support multiple next hops (aka paths) for each route as well as additional attributes. |
|
| |
| RFC 9404 | JSON Meta Application Protocol (JMAP) Blob Management Extension |
| |
|
|
The JSON Meta Application Protocol (JMAP) base protocol (RFC 8620) provides the ability to upload and download arbitrary binary data viaHTTP POST and GET on a defined endpoint. This binary data is called a "blob".
This extension adds additional ways to create and access blobs by making inline method calls within a standard JMAP request.
This extension also adds a reverse lookup mechanism to discover where blobs are referenced within other data types. |
|
| |
| RFC 9406 | HyStart++: Modified Slow Start for TCP |
| |
| Authors: | P. Balasubramanian, Y. Huang, M. Olson. |
| Date: | May 2023 |
| Formats: | txt json xml pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9406 |
|
This document describes HyStart++, a simple modification to the slow start phase of congestion control algorithms. Slow start can overshoot the ideal send rate in many cases, causing high packet loss and poor performance. HyStart++ uses increase in round-trip delay as a heuristic to find an exit point before possible overshoot. It also adds a mitigation to prevent jitter from causing premature slow start exit. |
|
| |
| RFC 9408 | A YANG Network Data Model for Service Attachment Points (SAPs) |
| |
| Authors: | M. Boucadair, Ed., O. Gonzalez de Dios, S. Barguil, Q. Wu, V. Lopez. |
| Date: | June 2023 |
| Formats: | txt xml pdf html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9408 |
|
This document defines a YANG data model for representing an abstract view of the provider network topology that contains the points from which its services can be attached (e.g., basic connectivity, VPN, network slices). Also, the model can be used to retrieve the points where the services are actually being delivered to customers(including peer networks).
This document augments the 'ietf-network' data model defined in RFC8345 by adding the concept of Service Attachment Points (SAPs). TheSAPs are the network reference points to which network services, such as Layer 3 Virtual Private Network (L3VPN) or Layer 2 Virtual PrivateNetwork (L2VPN), can be attached. One or multiple services can be bound to the same SAP. Both User-to-Network Interface (UNI) andNetwork-to-Network Interface (NNI) are supported in the SAP data model. |
|
| |
| RFC 9410 | Handling of Identity Header Errors for Secure Telephone Identity Revisited (STIR) |
| |
|
|
This document extends the current error-handling procedures for mapping of verification failure reasons to 4xx codes for SecureTelephone Identity Revisited (STIR) and the Authenticated IdentityManagement in the Session Initiation Protocol (SIP). It extends the ability to use the Reason header field as an option for conveying an error associated with an Identity header field to the upstream authentication service when local policy dictates that the call should continue in the presence of a verification failure. This document also defines procedures that enable a failure reason to be mapped to a specific Identity header field for scenarios that use multiple Identity header fields, where some may have errors and others may not. The handling of those situations is also defined. |
|
| |
| RFC 9412 | The ORIGIN Extension in HTTP/3 |
| |
|
|
The ORIGIN frame for HTTP/2 is equally applicable to HTTP/3, but it needs to be separately registered. This document describes theORIGIN frame for HTTP/3. |
|
| |
| RFC 9418 | A YANG Data Model for Service Assurance |
| |
| Authors: | B. Claise, J. Quilbeuf, P. Lucente, P. Fasano, T. Arumugam. |
| Date: | July 2023 |
| Formats: | txt pdf xml html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9418 |
|
This document specifies YANG modules for representing assurance graphs. These graphs represent the assurance of a given service by decomposing it into atomic assurance elements called subservices.The companion document, "Service Assurance for Intent-BasedNetworking Architecture" (RFC 9417), presents an architecture for implementing the assurance of such services.
The YANG data models in this document conform to the NetworkManagement Datastore Architecture (NMDA) defined in RFC 8342. |
|
| |
| RFC 9420 | The Messaging Layer Security (MLS) Protocol |
| |
| Authors: | R. Barnes, B. Beurdouche, R. Robert, J. Millican, E. Omara, K. Cohn-Gordon. |
| Date: | July 2023 |
| Formats: | txt html json xml pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9420 |
|
Messaging applications are increasingly making use of end-to-end security mechanisms to ensure that messages are only accessible to the communicating endpoints, and not to any servers involved in delivering messages. Establishing keys to provide such protections is challenging for group chat settings, in which more than two clients need to agree on a key but may not be online at the same time. In this document, we specify a key establishment protocol that provides efficient asynchronous group key establishment with forward secrecy (FS) and post-compromise security (PCS) for groups in size ranging from two to thousands. |
|
| |
| RFC 9421 | HTTP Message Signatures |
| |
| Authors: | A. Backman, Ed., J. Richer, Ed., M. Sporny. |
| Date: | February 2024 |
| Formats: | txt html xml json pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9421 |
|
This document describes a mechanism for creating, encoding, and verifying digital signatures or message authentication codes over components of an HTTP message. This mechanism supports use cases where the full HTTP message may not be known to the signer and where the message may be transformed (e.g., by intermediaries) before reaching the verifier. This document also describes a means for requesting that a signature be applied to a subsequent HTTP message in an ongoing HTTP exchange. |
|
| |
| RFC 9422 | The LIMITS SMTP Service Extension |
| |
| Authors: | N. Freed, J. Klensin. |
| Date: | February 2024 |
| Formats: | txt json pdf xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9422 |
|
This document defines a LIMITS extension for the Simple Mail TransferProtocol (SMTP), including submission, as well as the Local MailTransfer Protocol (LMTP). It also defines an associated limit registry. The extension provides the means for an SMTP, submission, or LMTP server to inform the client of limits the server intends to apply to the protocol during the current session. The client is then able to adapt its behavior in order to conform to those limits. |
|
| |
| RFC 9425 | JSON Meta Application Protocol (JMAP) for Quotas |
| |
|
|
This document specifies a data model for handling quotas on accounts with a server using the JSON Meta Application Protocol (JMAP). |
|
| |
| RFC 9427 | TLS-Based Extensible Authentication Protocol (EAP) Types for Use with TLS 1.3 |
| |
|
|
The Extensible Authentication Protocol-TLS (EAP-TLS) (RFC 5216) has been updated for TLS 1.3 in RFC 9190. Many other EAP Types also depend on TLS, such as EAP-Flexible Authentication via SecureTunneling (EAP-FAST) (RFC 4851), EAP-Tunneled TLS (EAP-TTLS) (RFC5281), the Tunnel Extensible Authentication Protocol (TEAP) (RFC7170). It is possible that many vendor-specific EAP methods, such as the Protected Extensible Authentication Protocol (PEAP), depend onTLS as well. This document updates those methods in order to use the new key derivation methods available in TLS 1.3. Additional changes necessitated by TLS 1.3 are also discussed. |
|
| |
| RFC 9428 | Transmission of IPv6 Packets over Near Field Communication |
| |
| Authors: | Y. Choi, Ed., Y-G. Hong, J-S. Youn. |
| Date: | July 2023 |
| Formats: | txt html xml pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9428 |
|
Near Field Communication (NFC) is a set of standards for smartphones and portable devices to establish radio communication with each other by touching them together or bringing them into proximity, usually no more than 10 cm apart. NFC standards cover communication protocols and data exchange formats and are based on existing Radio FrequencyIdentification (RFID) standards, including ISO/IEC 14443 and FeliCa.The standards include ISO/IEC 18092 and those defined by the NFCForum. The NFC technology has been widely implemented and available in mobile phones, laptop computers, and many other devices. This document describes how IPv6 is transmitted over NFC using IPv6 overLow-Power Wireless Personal Area Network (6LoWPAN) techniques. |
|
| |
| RFC 9429 | JavaScript Session Establishment Protocol (JSEP) |
| |
|
|
This document describes the mechanisms for allowing a JavaScript application to control the signaling plane of a multimedia session via the interface specified in the W3C RTCPeerConnection API and discusses how this relates to existing signaling protocols.
This specification obsoletes RFC 8829. |
|
| |
| RFC 9430 | Extension of the Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE) to Transport Layer Security (TLS) |
| |
|
|
This document updates "Datagram Transport Layer Security (DTLS)Profile for Authentication and Authorization for ConstrainedEnvironments (ACE)" (RFC 9202) by specifying that the profile applies to TLS as well as DTLS. |
|
| |
| RFC 9431 | Message Queuing Telemetry Transport (MQTT) and Transport Layer Security (TLS) Profile of Authentication and Authorization for Constrained Environments (ACE) Framework |
| |
|
|
This document specifies a profile for the Authentication andAuthorization for Constrained Environments (ACE) framework to enable authorization in a publish-subscribe messaging system based onMessage Queuing Telemetry Transport (MQTT). Proof-of-Possession keys, bound to OAuth 2.0 access tokens, are used to authenticate and authorize MQTT Clients. The protocol relies on TLS for confidentiality and MQTT server (Broker) authentication. |
|
| |
| RFC 9432 | DNS Catalog Zones |
| |
| Authors: | P. van Dijk, L. Peltan, O. Surý, W. Toorop, C.R. Monshouwer, P. Thomassen, A. Sargsyan. |
| Date: | July 2023 |
| Formats: | txt xml json pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9432 |
|
This document describes a method for automatic DNS zone provisioning among DNS primary and secondary name servers by storing and transferring the catalog of zones to be provisioned as one or more regular DNS zones. |
|
| |
| RFC 9436 | PIM Message Type Space Extension and Reserved Bits |
| |
|
|
The PIM version 2 messages share a common message header format. The common header definition contains eight reserved bits. This document specifies how these bits may be used by individual message types and extends the PIM type space.
This document updates RFCs 7761 and 3973 by defining the use of theReserved field in the PIM common header. This document further updates RFCs 7761 and 3973, along with RFCs 5015, 5059, 6754, and8364, by specifying the use of the bits for each PIM message.
This document obsoletes RFC 8736. |
|
| |
| RFC 9437 | Publish/Subscribe Functionality for the Locator/ID Separation Protocol (LISP) |
| |
| Authors: | A. Rodriguez-Natal, V. Ermagan, A. Cabellos, S. Barkai, M. Boucadair. |
| Date: | August 2023 |
| Formats: | txt json pdf html xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9437 |
|
This document specifies an extension to the Locator/ID SeparationProtocol (LISP) control plane to enable Publish/Subscribe (PubSub) operation. |
|
| |
| RFC 9438 | CUBIC for Fast and Long-Distance Networks |
| |
|
|
CUBIC is a standard TCP congestion control algorithm that uses a cubic function instead of a linear congestion window increase function to improve scalability and stability over fast and long- distance networks. CUBIC has been adopted as the default TCP congestion control algorithm by the Linux, Windows, and Apple stacks.
This document updates the specification of CUBIC to include algorithmic improvements based on these implementations and recent academic work. Based on the extensive deployment experience withCUBIC, this document also moves the specification to the StandardsTrack and obsoletes RFC 8312. This document also updates RFC 5681, to allow for CUBIC's occasionally more aggressive sending behavior. |
|
| |
| RFC 9439 | Application-Layer Traffic Optimization (ALTO) Performance Cost Metrics |
| |
| Authors: | Q. Wu, Y. Yang, Y. Lee, D. Dhody, S. Randriamasy, L. Contreras. |
| Date: | August 2023 |
| Formats: | txt html pdf xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9439 |
|
The cost metric is a basic concept in Application-Layer TrafficOptimization (ALTO), and different applications may use different types of cost metrics. Since the ALTO base protocol (RFC 7285) defines only a single cost metric (namely, the generic "routingcost" metric), if an application wants to issue a cost map or an endpoint cost request in order to identify a resource provider that offers better performance metrics (e.g., lower delay or loss rate), the base protocol does not define the cost metric to be used.
This document addresses this issue by extending the specification to provide a variety of network performance metrics, including network delay, delay variation (a.k.a. jitter), packet loss rate, hop count, and bandwidth.
There are multiple sources (e.g., estimations based on measurements or a Service Level Agreement) available for deriving a performance metric. This document introduces an additional "cost-context" field to the ALTO "cost-type" field to convey the source of a performance metric. |
|
| |
| RFC 9441 | Static Context Header Compression (SCHC) Compound Acknowledgement (ACK) |
| |
|
|
This document updates the Static Context Header Compression (SCHC) and fragmentation protocol (RFC 8724) and the corresponding YANG module (RFC 9363). It defines a SCHC Compound Acknowledgement (ACK) message format and procedure, which are intended to reduce the number of response transmissions (i.e., SCHC ACKs) in the ACK-on-Error Mode, by accumulating bitmaps of several windows in a single SCHC message(i.e., the SCHC Compound ACK).
Both the message format and procedure are generic, so they can be used, for instance, by any of the four Low-Power Wide Area Network(LPWAN) technologies defined in RFC 8376, which are Sigfox, LongRange Wide Area Network (LoRaWAN), Narrowband Internet of Things (NB-IoT), and IEEE 802.15.4w. |
|
| |
| RFC 9442 | Static Context Header Compression (SCHC) over Sigfox Low-Power Wide Area Network (LPWAN) |
| |
| Authors: | J. Zúñiga, C. Gomez, S. Aguilar, L. Toutain, S. Céspedes, D. Wistuba, J. Boite. |
| Date: | July 2023 |
| Formats: | txt html pdf xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9442 |
|
The Static Context Header Compression (SCHC) and fragmentation specification (RFC 8724) describes a generic framework for application header compression and fragmentation modes designed forLow-Power Wide Area Network (LPWAN) technologies. This document defines a profile of SCHC over Sigfox LPWAN and provides optimal parameter values and modes of operation. |
|
| |
| RFC 9443 | Multiplexing Scheme Updates for QUIC |
| |
|
|
RFC 7983 defines a scheme for a Real-time Transport Protocol (RTP) receiver to demultiplex Datagram Transport Layer Security (DTLS),Session Traversal Utilities for NAT (STUN), Secure Real-timeTransport Protocol (SRTP) / Secure Real-time Transport ControlProtocol (SRTCP), ZRTP, and Traversal Using Relays around NAT (TURN) channel packets arriving on a single port. This document updates RFC7983 and RFC 5764 to also allow QUIC packets to be multiplexed on a single receiving socket. |
|
| |
| RFC 9444 | Automated Certificate Management Environment (ACME) for Subdomains |
| |
| Authors: | O. Friel, R. Barnes, T. Hollebeek, M. Richardson. |
| Date: | August 2023 |
| Formats: | txt json html pdf xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9444 |
|
This document specifies how Automated Certificate ManagementEnvironment (ACME) can be used by a client to obtain a certificate for a subdomain identifier from a certification authority.Additionally, this document specifies how a client can fulfill a challenge against an ancestor domain but may not need to fulfill a challenge against the explicit subdomain if certification authority policy allows issuance of the subdomain certificate without explicit subdomain ownership proof. |
|
| |
| RFC 9445 | RADIUS Extensions for DHCP-Configured Services |
| |
|
|
This document specifies two new Remote Authentication Dial-In UserService (RADIUS) attributes that carry DHCP options. The specification is generic and can be applicable to any service that relies upon DHCP. Both DHCPv4- and DHCPv6-configured services are covered.
Also, this document updates RFC 4014 by relaxing a constraint on permitted RADIUS attributes in the RADIUS Attributes DHCP suboption. |
|
| |
| RFC 9447 | Automated Certificate Management Environment (ACME) Challenges Using an Authority Token |
| |
| Authors: | J. Peterson, M. Barnes, D. Hancock, C. Wendt. |
| Date: | September 2023 |
| Formats: | txt xml pdf html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9447 |
|
Some proposed extensions to the Automated Certificate ManagementEnvironment (ACME) rely on proving eligibility for certificates through consulting an external authority that issues a token according to a particular policy. This document specifies a genericAuthority Token Challenge for ACME that supports subtype claims for different identifiers or namespaces that can be defined separately for specific applications. |
|
| |
| RFC 9448 | TNAuthList Profile of Automated Certificate Management Environment (ACME) Authority Token |
| |
| Authors: | C. Wendt, D. Hancock, M. Barnes, J. Peterson. |
| Date: | September 2023 |
| Formats: | txt json xml pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9448 |
|
This document defines a profile of the Automated CertificateManagement Environment (ACME) Authority Token for the automated and authorized creation of certificates for Voice over IP (VoIP) telephone providers to support Secure Telephone Identity (STI) using the TNAuthList defined by STI certificates. |
|
| |
| RFC 9449 | OAuth 2.0 Demonstrating Proof of Possession (DPoP) |
| |
| Authors: | D. Fett, B. Campbell, J. Bradley, T. Lodderstedt, M. Jones, D. Waite. |
| Date: | September 2023 |
| Formats: | txt xml pdf json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9449 |
|
This document describes a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level.This mechanism allows for the detection of replay attacks with access and refresh tokens. |
|
| |
| RFC 9451 | Operations, Administration, and Maintenance (OAM) Packet and Behavior in the Network Service Header (NSH) |
| |
|
|
This document clarifies an ambiguity in the Network Service Header(NSH) specification related to the handling of O bit. In particular, this document clarifies the meaning of "OAM packet".
This document updates RFC 8300. |
|
| |
| RFC 9452 | Network Service Header (NSH) Encapsulation for In Situ OAM (IOAM) Data |
| |
| Authors: | F. Brockners, Ed., S. Bhandari, Ed.. |
| Date: | August 2023 |
| Formats: | txt html xml pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9452 |
|
In situ Operations, Administration, and Maintenance (IOAM) is used for recording and collecting operational and telemetry information while the packet traverses a path between two points in the network.This document outlines how IOAM-Data-Fields are encapsulated with theNetwork Service Header (NSH). |
|
| |
| RFC 9454 | Update to OSPF Terminology |
| |
|
|
This document updates some OSPF terminology to be in line with inclusive language used in the industry. The IETF has designated"Guidance for NIST Staff on Using Inclusive Language in DocumentaryStandards" by the US National Institute of Standards and Technology(NIST) for its inclusive language guidelines. It is intended that all future OSPF documents use this revised terminology even when they reference the RFCs updated by this document.
This document updates RFCs 2328, 4222, 4811, 5243, 5340, 5614, and5838. |
|
| |
| RFC 9456 | Updates to the TLS Transport Model for SNMP |
| |
|
|
This document updates RFC 6353 ("Transport Layer Security (TLS)Transport Model for the Simple Network Management Protocol (SNMP)") to reflect changes necessary to support Transport Layer Security version 1.3 (TLS 1.3) and Datagram Transport Layer Security version1.3 (DTLS 1.3), which are jointly known as "(D)TLS 1.3". This document is compatible with (D)TLS 1.2 and is intended to be compatible with future versions of SNMP and (D)TLS.
This document updates the SNMP-TLS-TM-MIB as defined in RFC 6353. |
|
| |
| RFC 9457 | Problem Details for HTTP APIs |
| |
|
|
This document defines a "problem detail" to carry machine-readable details of errors in HTTP response content to avoid the need to define new error response formats for HTTP APIs.
This document obsoletes RFC 7807. |
|
| |
| RFC 9458 | Oblivious HTTP |
| |
| Authors: | M. Thomson, C. A. Wood. |
| Date: | January 2024 |
| Formats: | txt pdf json xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9458 |
|
This document describes Oblivious HTTP, a protocol for forwarding encrypted HTTP messages. Oblivious HTTP allows a client to make multiple requests to an origin server without that server being able to link those requests to the client or to identify the requests as having come from the same client, while placing only limited trust in the nodes used to forward the messages. |
|
| |
| RFC 9459 | CBOR Object Signing and Encryption (COSE): AES-CTR and AES-CBC |
| |
| Authors: | R. Housley, H. Tschofenig. |
| Date: | September 2023 |
| Formats: | txt pdf json xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9459 |
|
The Concise Binary Object Representation (CBOR) data format is designed for small code size and small message size. CBOR ObjectSigning and Encryption (COSE) is specified in RFC 9052 to provide basic security services using the CBOR data format. This document specifies the conventions for using AES-CTR and AES-CBC as content encryption algorithms with COSE. |
|
| |
| RFC 9460 | Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records) |
| |
| Authors: | B. Schwartz, M. Bishop, E. Nygren. |
| Date: | November 2023 |
| Formats: | txt json html xml pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9460 |
|
This document specifies the "SVCB" ("Service Binding") and "HTTPS"DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTP origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration), and are extensible to support future uses (such as keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible withCNAME. The HTTPS RR is a variation of SVCB for use with HTTP (seeRFC 9110, "HTTP Semantics"). By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy. |
|
| |
| RFC 9461 | Service Binding Mapping for DNS Servers |
| |
|
|
The SVCB DNS resource record type expresses a bound collection of endpoint metadata, for use when establishing a connection to a named service. DNS itself can be such a service, when the server is identified by a domain name. This document provides the SVCB mapping for named DNS servers, allowing them to indicate support for encrypted transport protocols. |
|
| |
| RFC 9462 | Discovery of Designated Resolvers |
| |
| Authors: | T. Pauly, E. Kinnear, C. A. Wood, P. McManus, T. Jensen. |
| Date: | November 2023 |
| Formats: | txt pdf html xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9462 |
|
This document defines Discovery of Designated Resolvers (DDR), a set of mechanisms for DNS clients to use DNS records to discover a resolver's encrypted DNS configuration. An Encrypted DNS Resolver discovered in this manner is referred to as a "Designated Resolver".These mechanisms can be used to move from unencrypted DNS to encrypted DNS when only the IP address of a resolver is known. These mechanisms are designed to be limited to cases where Unencrypted DNSResolvers and their Designated Resolvers are operated by the same entity or cooperating entities. It can also be used to discover support for encrypted DNS protocols when the name of an Encrypted DNSResolver is known. |
|
| |
| RFC 9463 | DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR) |
| |
| Authors: | M. Boucadair, Ed., T. Reddy.K, Ed., D. Wing, N. Cook, T. Jensen. |
| Date: | November 2023 |
| Formats: | txt pdf html xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9463 |
|
This document specifies new DHCP and IPv6 Router Advertisement options to discover encrypted DNS resolvers (e.g., DNS over HTTPS,DNS over TLS, and DNS over QUIC). Particularly, it allows a host to learn an Authentication Domain Name together with a list of IP addresses and a set of service parameters to reach such encrypted DNS resolvers. |
|
| |
| RFC 9464 | Internet Key Exchange Protocol Version 2 (IKEv2) Configuration for Encrypted DNS |
| |
| Authors: | M. Boucadair, T. Reddy.K, D. Wing, V. Smyslov. |
| Date: | November 2023 |
| Formats: | txt pdf xml json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9464 |
|
This document specifies new Internet Key Exchange Protocol Version 2(IKEv2) Configuration Payload Attribute Types to assign DNS resolvers that support encrypted DNS protocols, such as DNS over HTTPS (DoH),DNS over TLS (DoT), and DNS over QUIC (DoQ). |
|
| |
| RFC 9465 | PIM Null-Register Packing |
| |
| Authors: | V. Kamath, R. Chokkanathapuram Sundaram, R. Banthia, A. Gopal. |
| Date: | September 2023 |
| Formats: | txt json pdf xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9465 |
|
In PIM Sparse Mode (PIM-SM) networks, PIM Null-Register messages are sent by the Designated Router (DR) to the Rendezvous Point (RP) to signal the presence of multicast sources in the network. There are periodic PIM Null-Registers sent from the DR to the RP to keep the state alive at the RP as long as the source is active. The PIM Null-Register message carries information about a single multicast source and group.
This document defines a standard to send information about multiple multicast sources and groups in a single PIM message. This document refers to the new messages as the "PIM Packed Null-Register message" and "PIM Packed Register-Stop message". |
|
| |
| RFC 9466 | PIM Assert Message Packing |
| |
| Authors: | Y. Liu, Ed., T. Eckert, Ed., M. McBride, Z. Zhang. |
| Date: | October 2023 |
| Formats: | txt html xml json pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9466 |
|
When PIM Sparse Mode (PIM-SM), including PIM Source-SpecificMulticast (PIM-SSM), is used in shared LAN networks, there is often more than one upstream router. This can lead to duplicate IP multicast packets being forwarded by these PIM routers. PIM Assert messages are used to elect a single forwarder for each IP multicast traffic flow between these routers.
This document defines a mechanism to send and receive information for multiple IP multicast flows in a single PackedAssert message. This optimization reduces the total number of PIM packets on the LAN and can therefore speed up the election of the single forwarder, reducing the number of duplicate IP multicast packets incurred. |
|
| |
| RFC 9467 | Relaxed Packet Counter Verification for Babel MAC Authentication |
| |
|
|
This document relaxes the packet verification rules defined in "MACAuthentication for the Babel Routing Protocol" (RFC 8967) in order to make the protocol more robust in the presence of packet reordering.This document updates RFC 8967. |
|
| |
| RFC 9468 | Unsolicited Bidirectional Forwarding Detection (BFD) for Sessionless Applications |
| |
| Authors: | E. Chen, N. Shen, R. Raszuk, R. Rahman. |
| Date: | August 2023 |
| Formats: | txt json xml pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9468 |
|
For operational simplification of "sessionless" applications usingBidirectional Forwarding Detection (BFD), in this document, we present procedures for "unsolicited BFD" that allow a BFD session to be initiated by only one side and established without explicit per- session configuration or registration by the other side (subject to certain per-interface or global policies).
We also introduce a new YANG module to configure and manage"unsolicited BFD". The YANG module in this document is based on YANG1.1, as defined in RFC 7950, and conforms to the Network ManagementDatastore Architecture (NMDA), as described in RFC 8342. This document augments RFC 9314. |
|
| |
| RFC 9470 | OAuth 2.0 Step Up Authentication Challenge Protocol |
| |
| Authors: | V. Bertocci, B. Campbell. |
| Date: | September 2023 |
| Formats: | txt json pdf html xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9470 |
|
It is not uncommon for resource servers to require different authentication strengths or recentness according to the characteristics of a request. This document introduces a mechanism that resource servers can use to signal to a client that the authentication event associated with the access token of the current request does not meet its authentication requirements and, further, how to meet them. This document also codifies a mechanism for a client to request that an authorization server achieve a specific authentication strength or recentness when processing an authorization request. |
|
| |
| RFC 9471 | DNS Glue Requirements in Referral Responses |
| |
| Authors: | M. Andrews, S. Huque, P. Wouters, D. Wessels. |
| Date: | September 2023 |
| Formats: | txt json pdf html xml |
| Updates: | RFC 1034 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9471 |
|
The DNS uses glue records to allow iterative clients to find the addresses of name servers that are contained within a delegated zone.Authoritative servers are expected to return all available glue records for in-domain name servers in a referral response. If message size constraints prevent the inclusion of all glue records for in-domain name servers, the server must set the TC (Truncated) flag to inform the client that the response is incomplete and that the client should use another transport to retrieve the full response. This document updates RFC 1034 to clarify correct server behavior. |
|
| |
| RFC 9472 | A YANG Data Model for Reporting Software Bills of Materials (SBOMs) and Vulnerability Information |
| |
|
|
To improve cybersecurity posture, automation is necessary to locate the software a device is using, whether that software has known vulnerabilities, and what, if any, recommendations suppliers may have. This memo extends the Manufacturer User Description (MUD) YANG schema to provide the locations of software bills of materials(SBOMs) and vulnerability information by introducing a transparency schema. |
|
| |
| RFC 9475 | Messaging Use Cases and Extensions for Secure Telephone Identity Revisited (STIR) |
| |
| Authors: | J. Peterson, C. Wendt. |
| Date: | December 2023 |
| Formats: | txt xml json pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9475 |
|
Secure Telephone Identity Revisited (STIR) provides a means of attesting the identity of a telephone caller via a signed token in order to prevent impersonation of a calling party number, which is a key enabler for illegal robocalling. Similar impersonation is sometimes leveraged by bad actors in the text and multimedia messaging space. This document explores the applicability of STIR'sPersonal Assertion Token (PASSporT) and certificate issuance framework to text and multimedia messaging use cases, including support for both messages carried as a payload in SIP requests and messages sent in sessions negotiated by SIP. |
|
| |
| RFC 9476 | The .alt Special-Use Top-Level Domain |
| |
| Authors: | W. Kumari, P. Hoffman. |
| Date: | September 2023 |
| Formats: | txt html json pdf xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9476 |
|
This document reserves a Top-Level Domain (TLD) label "alt" to be used in non-DNS contexts. It also provides advice and guidance to developers creating alternative namespaces. |
|
| |
| RFC 9478 | Labeled IPsec Traffic Selector Support for the Internet Key Exchange Protocol Version 2 (IKEv2) |
| |
| Authors: | P. Wouters, S. Prasad. |
| Date: | October 2023 |
| Formats: | txt json html pdf xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9478 |
|
This document defines a new Traffic Selector Type (TS Type) for theInternet Key Exchange Protocol version 2 (IKEv2) to add support for negotiating Mandatory Access Control (MAC) security labels as aTraffic Selector of the Security Policy Database (SPD). SecurityLabels for IPsec are also known as "Labeled IPsec". The new TS Type,TS_SECLABEL, consists of a variable length opaque field that specifies the security label. |
|
| |
| RFC 9479 | IS-IS Application-Specific Link Attributes |
| |
| Authors: | L. Ginsberg, P. Psenak, S. Previdi, W. Henderickx, J. Drake. |
| Date: | October 2023 |
| Formats: | txt json pdf xml html |
| Obsoletes: | RFC 8919 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9479 |
|
Existing traffic-engineering-related link attribute advertisements have been defined and are used in RSVP-TE deployments. Since the original RSVP-TE use case was defined, additional applications (e.g.,Segment Routing Policy and Loop-Free Alternates) that also make use of the link attribute advertisements have been defined. In cases where multiple applications wish to make use of these link attributes, the current advertisements do not support application- specific values for a given attribute, nor do they support an indication of which applications are using the advertised value for a given link. This document introduces link attribute advertisements that address both of these shortcomings.
This document obsoletes RFC 8919. |
|
| |
| RFC 9480 | Certificate Management Protocol (CMP) Updates |
| |
|
|
This document contains a set of updates to the syntax of CertificateManagement Protocol (CMP) version 2 and its HTTP transfer mechanism.This document updates RFCs 4210, 5912, and 6712.
The aspects of CMP updated in this document are using EnvelopedData instead of EncryptedValue, clarifying the handling of p10cr messages, improving the crypto agility, as well as adding new general message types, extended key usages to identify certificates for use with CMP, and well-known URI path segments.
CMP version 3 is introduced to enable signaling support ofEnvelopedData instead of EncryptedValue and signal the use of an explicit hash AlgorithmIdentifier in certConf messages, as far as needed. |
|
| |
| RFC 9481 | Certificate Management Protocol (CMP) Algorithms |
| |
| Authors: | H. Brockhaus, H. Aschauer, M. Ounsworth, J. Gray. |
| Date: | November 2023 |
| Formats: | txt pdf json xml html |
| Updates: | RFC 4210 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9481 |
|
This document describes the conventions for using several cryptographic algorithms with the Certificate Management Protocol(CMP). CMP is used to enroll and further manage the lifecycle ofX.509 certificates. This document also updates the algorithm use profile from Appendix D.2 of RFC 4210. |
|
| |
| RFC 9482 | Constrained Application Protocol (CoAP) Transfer for the Certificate Management Protocol |
| |
| Authors: | M. Sahni, Ed., S. Tripathi, Ed.. |
| Date: | November 2023 |
| Formats: | txt html xml pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9482 |
|
This document specifies the use of the Constrained ApplicationProtocol (CoAP) as a transfer mechanism for the CertificateManagement Protocol (CMP). CMP defines the interaction between various PKI entities for the purpose of certificate creation and management. CoAP is an HTTP-like client-server protocol used by various constrained devices in the Internet of Things space. |
|
| |
| RFC 9483 | Lightweight Certificate Management Protocol (CMP) Profile |
| |
| Authors: | H. Brockhaus, D. von Oheimb, S. Fries. |
| Date: | November 2023 |
| Formats: | txt html json xml pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9483 |
|
This document aims at simple, interoperable, and automated PKI management operations covering typical use cases of industrial andInternet of Things (IoT) scenarios. This is achieved by profiling the Certificate Management Protocol (CMP), the related CertificateRequest Message Format (CRMF), and transfer based on HTTP orConstrained Application Protocol (CoAP) in a succinct but sufficiently detailed and self-contained way. To make secure certificate management for simple scenarios and constrained devices as lightweight as possible, only the most crucial types of operations and options are specified as mandatory. More specialized or complex use cases are supported with optional features. |
|
| |
| RFC 9484 | Proxying IP in HTTP |
| |
| Authors: | T. Pauly, Ed., D. Schinazi, A. Chernyakhovsky, M. Kühlewind, M. Westerlund. |
| Date: | October 2023 |
| Formats: | txt json xml html pdf |
| Updates: | RFC 9298 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9484 |
|
This document describes how to proxy IP packets in HTTP. This protocol is similar to UDP proxying in HTTP but allows transmitting arbitrary IP packets. More specifically, this document defines a protocol that allows an HTTP client to create an IP tunnel through anHTTP server that acts as an IP proxy. This document updates RFC9298. |
|
| |
| RFC 9485 | I-Regexp: An Interoperable Regular Expression Format |
| |
|
|
This document specifies I-Regexp, a flavor of regular expression that is limited in scope with the goal of interoperation across many different regular expression libraries. |
|
| |
| RFC 9486 | IPv6 Options for In Situ Operations, Administration, and Maintenance (IOAM) |
| |
| Authors: | S. Bhandari, Ed., F. Brockners, Ed.. |
| Date: | September 2023 |
| Formats: | txt html pdf xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9486 |
|
In situ Operations, Administration, and Maintenance (IOAM) records operational and telemetry information in the packet while the packet traverses a path between two points in the network. This document outlines how IOAM Data-Fields are encapsulated in IPv6. |
|
| |
| RFC 9487 | Export of Segment Routing over IPv6 Information in IP Flow Information Export (IPFIX) |
| |
| Authors: | T. Graf, B. Claise, P. Francois. |
| Date: | November 2023 |
| Formats: | txt pdf xml html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9487 |
|
This document introduces new IP Flow Information Export (IPFIX)Information Elements (IEs) to identify a set of information related to Segment Routing over IPv6 (SRv6) such as data contained in aSegment Routing Header (SRH), the SRv6 control plane, and the SRv6Endpoint behavior that traffic is being forwarded with. |
|
| |
| RFC 9488 | Local Protection Enforcement in the Path Computation Element Communication Protocol (PCEP) |
| |
| Authors: | A. Stone, M. Aissaoui, S. Sidor, S. Sivabalan. |
| Date: | October 2023 |
| Formats: | txt json pdf xml html |
| Updates: | RFC 5440 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9488 |
|
This document updates RFC 5440 to clarify usage of the LocalProtection Desired bit signaled in the Path Computation ElementCommunication Protocol (PCEP). This document also introduces a new flag for signaling protection enforcement in PCEP. |
|
| |
| RFC 9489 | Label Switched Path (LSP) Ping Mechanisms for EVPN and Provider Backbone Bridging EVPN (PBB-EVPN) |
| |
| Authors: | P. Jain, A. Sajassi, S. Salam, S. Boutros, G. Mirsky. |
| Date: | November 2023 |
| Formats: | txt pdf xml json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9489 |
|
Label Switched Path (LSP) Ping is a widely deployed Operations,Administration, and Maintenance (OAM) mechanism in MPLS networks.This document describes mechanisms for detecting data plane failures using LSP Ping in MPLS-based Ethernet VPN (EVPN) and ProviderBackbone Bridging EVPN (PBB-EVPN) networks. |
|
| |
| RFC 9491 | Integration of the Network Service Header (NSH) and Segment Routing for Service Function Chaining (SFC) |
| |
| Authors: | J. Guichard, Ed., J. Tantsura, Ed.. |
| Date: | November 2023 |
| Formats: | txt xml pdf json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9491 |
|
This document describes the integration of the Network Service Header(NSH) and Segment Routing (SR), as well as encapsulation details, to efficiently support Service Function Chaining (SFC) while maintaining separation of the service and transport planes as originally intended by the SFC architecture.
Combining these technologies allows SR to be used for steering packets between Service Function Forwarders (SFFs) along a givenService Function Path (SFP), whereas the NSH is responsible for maintaining the integrity of the service plane, the SFC instance context, and any associated metadata.
This integration demonstrates that the NSH and SR can work cooperatively and provide a network operator with the flexibility to use whichever transport technology makes sense in specific areas of their network infrastructure while still maintaining an end-to-end service plane using the NSH. |
|
| |
| RFC 9492 | OSPF Application-Specific Link Attributes |
| |
| Authors: | P. Psenak, Ed., L. Ginsberg, W. Henderickx, J. Tantsura, J. Drake. |
| Date: | October 2023 |
| Formats: | txt html pdf json xml |
| Obsoletes: | RFC 8920 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9492 |
|
Existing traffic-engineering-related link attribute advertisements have been defined and are used in RSVP-TE deployments. Since the original RSVP-TE use case was defined, additional applications such as Segment Routing (SR) Policy and Loop-Free Alternates (LFAs) that also make use of the link attribute advertisements have been defined.In cases where multiple applications wish to make use of these link attributes, the current advertisements do not support application- specific values for a given attribute, nor do they support indication of which applications are using the advertised value for a given link. This document introduces link attribute advertisements inOSPFv2 and OSPFv3 that address both of these shortcomings.
This document obsoletes RFC 8920. |
|
| |
| RFC 9493 | Subject Identifiers for Security Event Tokens |
| |
| Authors: | A. Backman, Ed., M. Scurtescu, P. Jain. |
| Date: | December 2023 |
| Formats: | txt html json pdf xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9493 |
|
Security events communicated within Security Event Tokens may support a variety of identifiers to identify subjects related to the event.This specification formalizes the notion of Subject Identifiers as structured information that describes a subject and named formats that define the syntax and semantics for encoding Subject Identifiers as JSON objects. It also establishes a registry for defining and allocating names for such formats as well as the JSON Web Token (JWT)"sub_id" Claim. |
|
| |
| RFC 9494 | Long-Lived Graceful Restart for BGP |
| |
| Authors: | J. Uttaro, E. Chen, B. Decraene, J. Scudder. |
| Date: | November 2023 |
| Formats: | txt json pdf xml html |
| Updates: | RFC 6368 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9494 |
|
This document introduces a BGP capability called the "Long-LivedGraceful Restart Capability" (or "LLGR Capability"). The benefit of this capability is that stale routes can be retained for a longer time upon session failure than is provided for by BGP GracefulRestart (as described in RFC 4724). A well-known BGP community called "LLGR_STALE" is introduced for marking stale routes retained for a longer time. A second well-known BGP community called"NO_LLGR" is introduced for marking routes for which these procedures should not be applied. We also specify that such long-lived stale routes be treated as the least preferred and that their advertisements be limited to BGP speakers that have advertised the capability. Use of this extension is not advisable in all cases, and we provide guidelines to help determine if it is.
This memo updates RFC 6368 by specifying that the LLGR_STALE community must be propagated into, or out of, the path attributes exchanged between the Provider Edge (PE) and Customer Edge (CE) routers. |
|
| |
| RFC 9495 | Certification Authority Authorization (CAA) Processing for Email Addresses |
| |
|
|
The Certification Authority Authorization (CAA) DNS resource record(RR) provides a mechanism for domains to express the allowed set ofCertification Authorities that are authorized to issue certificates for the domain. RFC 8659 contains the core CAA specification, whereProperty Tags that restrict the issuance of certificates that certify domain names are defined. This specification defines a Property Tag that grants authorization to Certification Authorities to issue certificates that contain the id-kp-emailProtection key purpose in the extendedKeyUsage extension and at least one rfc822Name value or otherName value of type id-on-SmtpUTF8Mailbox that includes the domain name in the subjectAltName extension. |
|
| |
| RFC 9502 | IGP Flexible Algorithm in IP Networks |
| |
| Authors: | W. Britto, S. Hegde, P. Kaneriya, R. Shetty, R. Bonica, P. Psenak. |
| Date: | November 2023 |
| Formats: | txt html xml json pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9502 |
|
This document extends IGP Flexible Algorithm so that it can be used with regular IPv4 and IPv6 forwarding. |
|
| |
| RFC 9503 | Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Segment Routing Networks |
| |
| Authors: | R. Gandhi, Ed., C. Filsfils, M. Chen, B. Janssens, R. Foote. |
| Date: | October 2023 |
| Formats: | txt html xml pdf json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9503 |
|
Segment Routing (SR) leverages the source routing paradigm. SR is applicable to both Multiprotocol Label Switching (SR-MPLS) and IPv6(SRv6) forwarding planes. This document specifies Simple Two-WayActive Measurement Protocol (STAMP) extensions (as described in RFC8762) for SR networks, for both the SR-MPLS and SRv6 forwarding planes, by augmenting the optional extensions defined in RFC 8972. |
|
| |
| RFC 9504 | Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE Usage in GMPLS-Controlled Networks |
| |
| Authors: | Y. Lee, H. Zheng, O. Gonzalez de Dios, V. Lopez, Z. Ali. |
| Date: | December 2023 |
| Formats: | txt json html xml pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9504 |
|
The Path Computation Element Communication Protocol (PCEP) has been extended to support stateful PCE functions where the stateful PCE maintains information about paths and resource usage within a network; however, these extensions do not cover all requirements forGMPLS networks.
This document provides the extensions required for PCEP so as to enable the usage of a stateful PCE capability in GMPLS-controlled networks. |
|
| |
| RFC 9509 | X.509 Certificate Extended Key Usage (EKU) for 5G Network Functions |
| |
| Authors: | T. Reddy.K, J. Ekman, D. Migault. |
| Date: | March 2024 |
| Formats: | txt pdf json xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9509 |
|
RFC 5280 specifies several extended key purpose identifiers(KeyPurposeIds) for X.509 certificates. This document defines encrypting JSON objects in HTTP messages, using JSON Web Tokens(JWTs), and signing the OAuth 2.0 access tokens KeyPurposeIds for inclusion in the Extended Key Usage (EKU) extension of X.509 v3 public key certificates used by Network Functions (NFs) for the 5GSystem. |
|
| |
| RFC 9513 | OSPFv3 Extensions for Segment Routing over IPv6 (SRv6) |
| |
| Authors: | Z. Li, Z. Hu, K. Talaulikar, Ed., P. Psenak. |
| Date: | December 2023 |
| Formats: | txt html pdf xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9513 |
|
The Segment Routing (SR) architecture allows a flexible definition of the end-to-end path by encoding it as a sequence of topological elements called segments. It can be implemented over an MPLS or IPv6 data plane. This document describes the OSPFv3 extensions required to support SR over the IPv6 data plane. |
|
| |
| RFC 9514 | Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing over IPv6 (SRv6) |
| |
| Authors: | G. Dawra, C. Filsfils, K. Talaulikar, Ed., M. Chen, D. Bernier, B. Decraene. |
| Date: | December 2023 |
| Formats: | txt json pdf xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9514 |
|
Segment Routing over IPv6 (SRv6) allows for a flexible definition of end-to-end paths within various topologies by encoding paths as sequences of topological or functional sub-paths called "segments".These segments are advertised by various protocols such as BGP, IS-IS, and OSPFv3.
This document defines extensions to BGP - Link State (BGP-LS) to advertise SRv6 segments along with their behaviors and other attributes via BGP. The BGP-LS address-family solution for SRv6 described in this document is similar to BGP-LS for SR for the MPLS data plane, which is defined in RFC 9085. |
|
| |
| RFC 9515 | Revision to Registration Procedures for Multiple BMP Registries |
| |
|
|
This document updates RFC 7854, "BGP Monitoring Protocol (BMP)", by changing the registration procedures for several registries.Specifically, any BMP registry with a range of 32768-65530 designated"Specification Required" has that range redesignated as "First ComeFirst Served". |
|
| |
| RFC 9516 | Active Operations, Administration, and Maintenance (OAM) for Service Function Chaining (SFC) |
| |
| Authors: | G. Mirsky, W. Meng, T. Ao, B. Khasnabish, K. Leung, G. Mishra. |
| Date: | November 2023 |
| Formats: | txt xml pdf html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9516 |
|
A set of requirements for active Operations, Administration, andMaintenance (OAM) for Service Function Chaining (SFC) in a network is presented in this document. Based on these requirements, an encapsulation of active OAM messages in SFC and a mechanism to detect and localize defects are described. |
|
| |
| RFC 9519 | Update to the IANA SSH Protocol Parameters Registry Requirements |
| |
|
|
This specification updates the registration policies for adding new entries to registries within the IANA "Secure Shell (SSH) ProtocolParameters" group of registries. Previously, the registration policy was generally IETF Review, as defined in RFC 8126, although a few registries require Standards Action. This specification changes it from IETF Review to Expert Review. This document updates RFCs 4250,4716, 4819, and 8308. |
|
| |
| RFC 9520 | Negative Caching of DNS Resolution Failures |
| |
|
|
In the DNS, resolvers employ caching to reduce both latency for end users and load on authoritative name servers. The process of resolution may result in one of three types of responses: (1) a response containing the requested data, (2) a response indicating the requested data does not exist, or (3) a non-response due to a resolution failure in which the resolver does not receive any useful information regarding the data's existence. This document concerns itself only with the third type.
RFC 2308 specifies requirements for DNS negative caching. There, caching of TYPE 2 responses is mandatory and caching of TYPE 3 responses is optional. This document updates RFC 2308 to require negative caching for DNS resolution failures.
RFC 4035 allows DNSSEC validation failure caching. This document updates RFC 4035 to require caching for DNSSEC validation failures.
RFC 4697 prohibits aggressive requerying for NS records at a failed zone's parent zone. This document updates RFC 4697 to expand this requirement to all query types and to all ancestor zones. |
|
| |
| RFC 9521 | Bidirectional Forwarding Detection (BFD) for Generic Network Virtualization Encapsulation (Geneve) |
| |
| Authors: | X. Min, G. Mirsky, S. Pallagatti, J. Tantsura, S. Aldrin. |
| Date: | January 2024 |
| Formats: | txt json pdf html xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9521 |
|
This document describes the use of the Bidirectional ForwardingDetection (BFD) protocol in point-to-point Generic NetworkVirtualization Encapsulation (Geneve) unicast tunnels used to make up an overlay network. |
|
| |
| RFC 9524 | Segment Routing Replication for Multipoint Service Delivery |
| |
| Authors: | D. Voyer, Ed., C. Filsfils, R. Parekh, H. Bidgoli, Z. Zhang. |
| Date: | February 2024 |
| Formats: | txt xml json pdf html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9524 |
|
This document describes the Segment Routing Replication segment for multipoint service delivery. A Replication segment allows a packet to be replicated from a replication node to downstream nodes. |
|
| |
| RFC 9525 | Service Identity in TLS |
| |
|
|
Many application technologies enable secure communication between two entities by means of Transport Layer Security (TLS) with InternetPublic Key Infrastructure using X.509 (PKIX) certificates. This document specifies procedures for representing and verifying the identity of application services in such interactions.
This document obsoletes RFC 6125. |
|
| |
| RFC 9527 | DHCPv6 Options for the Homenet Naming Authority |
| |
| Authors: | D. Migault, R. Weber, T. Mrugalski. |
| Date: | January 2024 |
| Formats: | txt html json pdf xml |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9527 |
|
This document defines DHCPv6 options so that a Homenet NamingAuthority (HNA) can automatically set the appropriate configuration and outsource the authoritative naming service for the home network.In most cases, the outsourcing mechanism is transparent for the end user. |
|
| |
| RFC 9528 | Ephemeral Diffie-Hellman Over COSE (EDHOC) |
| |
| Authors: | G. Selander, J. Preuß Mattsson, F. Palombini. |
| Date: | March 2024 |
| Formats: | txt json pdf xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9528 |
|
This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a very compact and lightweight authenticated Diffie-Hellman key exchange with ephemeral keys. EDHOC provides mutual authentication, forward secrecy, and identity protection. EDHOC is intended for usage in constrained scenarios, and a main use case is to establish an Object Security for Constrained RESTful Environments (OSCORE) security context. By reusing CBOR Object Signing and Encryption(COSE) for cryptography, Concise Binary Object Representation (CBOR) for encoding, and Constrained Application Protocol (CoAP) for transport, the additional code size can be kept very low. |
|
| |
| RFC 9530 | Digest Fields |
| |
|
|
This document defines HTTP fields that support integrity digests.The Content-Digest field can be used for the integrity of HTTP message content. The Repr-Digest field can be used for the integrity of HTTP representations. Want-Content-Digest and Want-Repr-Digest can be used to indicate a sender's interest and preferences for receiving the respective Integrity fields.
This document obsoletes RFC 3230 and the Digest and Want-Digest HTTP fields. |
|
| |
| RFC 9532 | HTTP Proxy-Status Parameter for Next-Hop Aliases |
| |
|
|
This document defines the next-hop-aliases HTTP Proxy-StatusParameter. This parameter carries the list of aliases and canonical names an intermediary received during DNS resolution as part of establishing a connection to the next hop. |
|
| |
| RFC 9533 | One-Way and Two-Way Active Measurement Protocol Extensions for Performance Measurement on a Link Aggregation Group |
| |
| Authors: | Z. Li, T. Zhou, J. Guo, G. Mirsky, R. Gandhi. |
| Date: | January 2024 |
| Formats: | txt html pdf xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9533 |
|
This document defines extensions to the One-Way Active MeasurementProtocol (OWAMP) and the Two-Way Active Measurement Protocol (TWAMP) to implement performance measurement on every member link of a LinkAggregation Group (LAG). Knowing the measured metrics of each member link of a LAG enables operators to enforce the performance-based traffic steering policy across the member links. |
|
| |
| RFC 9534 | Simple Two-Way Active Measurement Protocol Extensions for Performance Measurement on a Link Aggregation Group |
| |
| Authors: | Z. Li, T. Zhou, J. Guo, G. Mirsky, R. Gandhi. |
| Date: | January 2024 |
| Formats: | txt json pdf xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9534 |
|
This document extends Simple Two-way Active Measurement Protocol(STAMP) to implement performance measurement on every member link of a Link Aggregation Group (LAG). Knowing the measured metrics of each member link of a LAG enables operators to enforce a performance-based traffic steering policy across the member links. |
|
| |
| RFC 9535 | JSONPath: Query Expressions for JSON |
| |
| Authors: | S. Gössner, Ed., G. Normington, Ed., C. Bormann, Ed.. |
| Date: | February 2024 |
| Formats: | txt pdf xml json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9535 |
|
JSONPath defines a string syntax for selecting and extracting JSON(RFC 8259) values from within a given JSON value. |
|
| |
| RFC 9536 | Registration Data Access Protocol (RDAP) Reverse Search |
| |
| Authors: | M. Loffredo, M. Martinelli. |
| Date: | April 2024 |
| Formats: | txt html xml json pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9536 |
|
The Registration Data Access Protocol (RDAP) does not include query capabilities for finding the list of domains related to a set of entities matching a given search pattern. Considering that an RDAP entity can be associated with any defined object class and other relationships between RDAP object classes exist, a reverse search can be applied to other use cases besides the classic domain-entity scenario. This document describes an RDAP extension that allows servers to provide a reverse search feature based on the relationship defined in RDAP between an object class for search and any related object class. The reverse search based on the domain-entity relationship is treated as a particular case. |
|
| |
| RFC 9537 | Redacted Fields in the Registration Data Access Protocol (RDAP) Response |
| |
| Authors: | J. Gould, D. Smith, J. Kolker, R. Carney. |
| Date: | March 2024 |
| Formats: | txt html xml json pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9537 |
|
This document describes a Registration Data Access Protocol (RDAP) extension for specifying methods of redaction of RDAP responses and explicitly identifying redacted RDAP response fields, using JSONPath as the default expression language. |
|
| |
| RFC 9538 | Content Delivery Network Interconnection (CDNI) Delegation Using the Automated Certificate Management Environment |
| |
| Authors: | F. Fieau, Ed., E. Stephan, S. Mishra. |
| Date: | February 2024 |
| Formats: | txt json html xml pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9538 |
|
This document defines metadata to support delegating the delivery ofHTTPS content between two or more interconnected Content DeliveryNetworks (CDNs). Specifically, this document defines a ContentDelivery Network Interconnection (CDNI) Metadata interface object to enable delegation of X.509 certificates leveraging delegation schemes defined in RFC 9115. Per RFC 9115, delegating entities can remain in full control of the delegation and can revoke it at any time. This avoids the need to share private cryptographic key material between the involved entities. |
|
| |
| RFC 9540 | Discovery of Oblivious Services via Service Binding Records |
| |
| Authors: | T. Pauly, T. Reddy.K. |
| Date: | February 2024 |
| Formats: | txt html pdf xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9540 |
|
This document defines a parameter that can be included in ServiceBinding (SVCB) and HTTPS DNS resource records to denote that a service is accessible using Oblivious HTTP, by offering an ObliviousGateway Resource through which to access the target. This document also defines a mechanism for learning the key configuration of the discovered Oblivious Gateway Resource. |
|
| |
| RFC 9541 | Flush Mechanism for Customer MAC Addresses Based on Service Instance Identifier (I-SID) in Provider Backbone Bridging EVPN (PBB-EVPN) |
| |
| Authors: | J. Rabadan, Ed., S. Sathappan, K. Nagaraj, M. Miyake, T. Matsuda. |
| Date: | March 2024 |
| Formats: | txt pdf xml html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9541 |
|
Provider Backbone Bridging (PBB) can be combined with EthernetVirtual Private Networks (EVPNs) to deploy Ethernet Local AreaNetwork (E-LAN) services in large Multiprotocol Label Switching(MPLS) networks. That combination is what we refer to as "PBB-EVPN."Single-Active multihoming and per Service Instance Identifier (I-SID) load-balancing can be provided to access devices and aggregation networks. In order to speed up the network convergence in case of failures on Single-Active multihomed Ethernet Segments (ESs), PBB-EVPN defines a flush mechanism for Customer MACs (C-MACs) called"C-MAC flush" that works for different Ethernet Segment Backbone MAC(B-MAC) address allocation models. This document complements thoseC-MAC flush procedures for cases in which no PBB-EVPN ESs are defined(i.e., the attachment circuit is associated with a zero EthernetSegment Identifier (ESI)) and the C-MAC flush requires I-SID-level granularity. |
|
| |
| RFC 9545 | Path Segment Identifier in MPLS-Based Segment Routing Networks |
| |
| Authors: | W. Cheng, Ed., H. Li, C. Li, Ed., R. Gandhi, R. Zigler. |
| Date: | February 2024 |
| Formats: | txt html xml json pdf |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9545 |
|
A Segment Routing (SR) path is identified by an SR segment list. A subset of segments from the segment list cannot be leveraged to distinguish one SR path from another as they may be partially congruent. SR path identification is a prerequisite for various use cases such as performance measurement and end-to-end 1+1 path protection.
In an SR over MPLS (SR-MPLS) data plane, an egress node cannot determine on which SR path a packet traversed the network from the label stack because the segment identifiers are removed from the label stack as the packet transits the network.
This document defines a Path Segment Identifier (PSID) to identify anSR path on the egress node of the path. |
|
| |
| RFC 9546 | Operations, Administration, and Maintenance (OAM) for Deterministic Networking (DetNet) with the MPLS Data Plane |
| |
| Authors: | G. Mirsky, M. Chen, B. Varga. |
| Date: | February 2024 |
| Formats: | txt json pdf xml html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9546 |
|
This document defines format and usage principles of theDeterministic Networking (DetNet) service Associated Channel over aDetNet network with the MPLS data plane. The DetNet serviceAssociated Channel can be used to carry test packets of activeOperations, Administration, and Maintenance (OAM) protocols that are used to detect DetNet failures and measure performance metrics. |
|
| |
| RFC 9549 | Internationalization Updates to RFC 5280 |
| |
|
|
The updates to RFC 5280 described in this document provide alignment with the 2008 specification for Internationalized Domain Names (IDNs) and includes support for internationalized email addresses in X.509 certificates. The updates ensure that name constraints for email addresses that contain only ASCII characters and internationalized email addresses are handled in the same manner. This document obsoletes RFC 8399. |
|
| |
| RFC 9552 | Distribution of Link-State and Traffic Engineering Information Using BGP |
| |
|
|
In many environments, a component external to a network is called upon to perform computations based on the network topology and the current state of the connections within the network, includingTraffic Engineering (TE) information. This is information typically distributed by IGP routing protocols within the network.
This document describes a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol. This is achieved using aBGP Network Layer Reachability Information (NLRI) encoding format.The mechanism applies to physical and virtual (e.g., tunnel) IGP links. The mechanism described is subject to policy control.
Applications of this technique include Application-Layer TrafficOptimization (ALTO) servers and Path Computation Elements (PCEs).
This document obsoletes RFC 7752 by completely replacing that document. It makes some small changes and clarifications to the previous specification. This document also obsoletes RFC 9029 by incorporating the updates that it made to RFC 7752. |
|
| |
| RFC 9561 | Using the Parallel NFS (pNFS) SCSI Layout to Access Non-Volatile Memory Express (NVMe) Storage Devices |
| |
| Authors: | C. Hellwig, Ed., C. Lever, S. Faibish, D. Black. |
| Date: | April 2024 |
| Formats: | txt html pdf xml json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 9561 |
|
This document specifies how to use the Parallel Network File System(pNFS) Small Computer System Interface (SCSI) Layout Type to access storage devices using the Non-Volatile Memory Express (NVMe) protocol family. |
|
