RFC Abstracts
RFC5392 - OSPF Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering
This document describes extensions to the OSPF version 2 and 3 protocols to support Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple Autonomous 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.
RFC5391 - RTP Payload Format for ITU-T Recommendation G.711.1
This document specifies a Real-time Transport Protocol (RTP) payload format to be used for the ITU Telecommunication Standardization Sector (ITU-T) G.711.1 audio codec. Two media type registrations are also included. [STANDARDS-TRACK]
RFC5390 - Requirements for Management of Overload in the Session Initiation Protocol
Overload occurs in Session Initiation Protocol (SIP) networks when proxies and user agents have insufficient resources to complete the processing of a request. SIP provides limited support for overload handling through its 503 response code, which tells an upstream element that it is overloaded. However, numerous problems have been identified with this mechanism. This document summarizes the problems with the existing 503 mechanism, and provides some requirements for a solution. This memo provides information for the Internet community.
RFC5389 - 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 Address Translator (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.
RFC5388 - Information Model and XML Data Model for Traceroute Measurements
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. [STANDARDS-TRACK]
RFC5387 - Problem and Applicability Statement for Better-Than-Nothing Security (BTNS)
The Internet network security protocol suite, IPsec, requires authentication, usually of network-layer entities, to enable access control and provide security services. This authentication can be based on mechanisms such as pre-shared symmetric keys, certificates with associated asymmetric keys, or the use of Kerberos (via Kerberized Internet Negotiation of Keys (KINK)). The need to deploy authentication information and its associated identities can be a significant obstacle to the use of IPsec.
RFC5386 - Better-Than-Nothing Security: An Unauthenticated Mode of IPsec
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 Encapsulating Security Payload (ESP) and the IPsec Authentication Header (AH). No changes to IKEv2 bits-on-the-wire are required, but Peer Authorization 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). [STANDARDS-TRACK]
RFC5385 - Version 2.0 Microsoft Word Template for Creating Internet Drafts and RFCs
This document describes the properties and use of a revised Microsoft Word template (.dot) for writing Internet Drafts and RFCs. It replaces the initial template described in RFC 3285 to more fully support Word's outline modes and to be easier to use. This template can be direct-printed and direct-viewed, where either is line-for-line identical with RFC Editor-compliant ASCII output. This version obsoletes RFC 3285.
RFC5384 - The Protocol Independent Multicast (PIM) Join Attribute Format
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. [STANDARDS-TRACK]
RFC5383 - Deployment Considerations for Lemonade-Compliant Mobile Email
This document discusses deployment issues and describes requirements for successful deployment of mobile email that are implicit in the IETF lemonade documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
RFC5382 - NAT Behavioral Requirements for TCP
This document defines a set of requirements for NATs that handle TCP that would allow many applications, such as peer-to-peer applications and online games to work consistently. Developing NATs that meet this set of requirements will greatly increase the likelihood that these applications will function properly. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
RFC5381 - Experience of Implementing NETCONF over SOAP
This document describes how the authors developed a SOAP (Simple Object Access Protocol)-based NETCONF (Network Configuration Protocol) client and server. It describes an alternative SOAP binding for NETCONF that does not interoperate with an RFC 4743 conformant implementation making use of cookies on top of the persistent transport connections of HTTP. When SOAP is used as a transport protocol for NETCONF, various kinds of development tools are available. By making full use of these tools, developers can significantly reduce their workload. The authors developed an NMS (Network Management System) and network equipment that can deal with NETCONF messages sent over SOAP. This document aims to provide NETCONF development guidelines gained from the experience of implementing a SOAP-based NETCONF client and server. This memo provides information for the Internet community.
RFC5380 - Hierarchical Mobile IPv6 (HMIPv6) Mobility Management
This document introduces extensions to Mobile IPv6 and IPv6 Neighbour Discovery 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. [STANDARDS-TRACK]
RFC5379 - Guidelines for Using the Privacy Mechanism for SIP
This is an informational document that provides guidelines for using the privacy mechanism for the Session Initiation Protocol (SIP) that is specified in RFC 3323 and subsequently extended in RFCs 3325 and 4244. It is intended to clarify the handling of the target SIP headers/parameters and the Session Description Protocol (SDP) parameters for each of the privacy header values (priv-values). This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC5378 - Rights Contributors Provide to the IETF Trust
The IETF policies about rights in Contributions to the IETF are designed to ensure that such Contributions can be made available to the IETF and Internet communities while permitting the authors to retain as many rights as possible. This memo details the IETF policies on rights in Contributions to the IETF. It also describes the objectives that the policies are designed to meet. This memo obsoletes RFCs 3978 and 4748 and, with BCP 79 and RFC 5377, replaces Section 10 of RFC 2026. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
RFC5377 - Advice to the Trustees of the IETF Trust on Rights to Be Granted in IETF Documents
Contributors grant intellectual property rights to the IETF. The IETF Trust holds and manages those rights on behalf of the IETF. The Trustees of the IETF Trust are responsible for that management. This management includes granting the licenses to copy, implement, and otherwise use IETF Contributions, among them Internet-Drafts and RFCs. The Trustees of the IETF Trust accepts direction from the IETF regarding the rights to be granted. This document describes the desires of the IETF regarding outbound rights to be granted in IETF Contributions. This memo provides information for the Internet community.
RFC5376 - Inter-AS Requirements for the Path Computation Element Communication Protocol (PCECP)
Multiprotocol Label Switching Traffic Engineered (MPLS TE) Label Switched Paths (LSPs) may be established wholly within an Autonomous System (AS) or may cross AS boundaries.
RFC5375 - IPv6 Unicast Address Assignment Considerations
One fundamental aspect of any IP communications infrastructure is its addressing plan. With its new address architecture and allocation policies, the introduction of IPv6 into a network means that network designers and operators need to reconsider their existing approaches to network addressing. Lack of guidelines on handling this aspect of network design could slow down the deployment and integration of IPv6. This document aims to provide the information and recommendations relevant to planning the addressing aspects of IPv6 deployments. The document also provides IPv6 addressing case studies for both an enterprise and an ISP network. This memo provides information for the Internet community.
RFC5374 - Multicast Extensions to the Security Architecture for the Internet Protocol
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. [STANDARDS-TRACK]
RFC5373 - Requesting Answering Modes for the Session Initiation Protocol (SIP)
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. [STANDARDS-TRACK]
RFC5372 - Payload Format for JPEG 2000 Video: Extensions for Scalability and Main Header Recovery
This memo describes extended uses for the payload header in "RTP Payload 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.
RFC5371 - RTP Payload Format for JPEG 2000 Video Streams
This memo describes an RTP payload format for the ISO/IEC International Standard 15444-1 | ITU-T Rec. T.800, better known as JPEG 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. [STANDARDS-TRACK]
RFC5370 - The Session Initiation Protocol (SIP) Conference Bridge Transcoding Model
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. [STANDARDS-TRACK]
RFC5369 - Framework for Transcoding with the Session Initiation Protocol (SIP)
This document defines a framework for transcoding with SIP. This framework includes how to discover the need for transcoding services in a session and how to invoke those transcoding services. Two models for transcoding services invocation are discussed: the conference bridge model and the third-party call control model. Both models meet the requirements for SIP regarding transcoding services invocation to support deaf, hard of hearing, and speech-impaired individuals. This memo provides information for the Internet community.
RFC5368 - Referring to Multiple Resources in the Session Initiation Protocol (SIP)
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 Resource Identifier (URI) lists in the Refer-To header field and the "multiple-refer" SIP option-tag. [STANDARDS-TRACK]
RFC5367 - Subscriptions to Request-Contained Resource Lists in the Session Initiation Protocol (SIP)
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 single SUBSCRIBE dialog. [STANDARDS-TRACK]
RFC5366 - Conference Establishment Using Request-Contained Lists in the Session Initiation Protocol (SIP)
This document describes how to create a conference using SIP URI-list services. In particular, it describes a mechanism that allows a User Agent Client to provide a conference server with the initial list of participants using an INVITE-contained URI list. [STANDARDS-TRACK]
RFC5365 - Multiple-Recipient MESSAGE Requests in the Session Initiation Protocol (SIP)
This document specifies a mechanism that allows a SIP User Agent Client (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 a MESSAGE request including the payload to each of the URIs included in the list. [STANDARDS-TRACK]
RFC5364 - Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists
In certain types of multimedia communications, a Session Initiation Protocol (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. [STANDARDS-TRACK]
RFC5363 - Framework and Security Considerations for Session Initiation Protocol (SIP) URI-List Services
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. [STANDARDS-TRACK]
RFC5362 - The Session Initiation Protocol (SIP) Pending Additions Event Package
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. [STANDARDS-TRACK]
RFC5361 - A Document Format for Requesting Consent
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. [STANDARDS-TRACK]
RFC5360 - A Framework for Consent-Based Communications in the Session Initiation Protocol (SIP)
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. [STANDARDS-TRACK]
RFC5359 - Session Initiation Protocol Service Examples
This document gives examples of Session Initiation Protocol (SIP) services. This covers most features offered in so-called IP Centrex offerings from local exchange carriers and PBX (Private Branch Exchange) features. Most of the services shown in this document are implemented in the SIP user agents, although some require the assistance of a SIP proxy. Some require some extensions to SIP including the REFER, SUBSCRIBE, and NOTIFY methods and the Replaces and Join header fields. These features are not intended to be an exhaustive set, but rather show implementations of common features likely to be implemented on SIP IP telephones in a business environment. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
RFC5358 - Preventing Use of Recursive Nameservers in Reflector Attacks
This document describes ways to prevent the use of default configured recursive nameservers as reflectors in Denial of Service (DoS) attacks. It provides recommended configuration as measures to mitigate the attack. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
RFC5357 - A Two-Way Active Measurement Protocol (TWAMP)
The One-way Active Measurement Protocol (OWAMP), specified in RFC 4656, 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 Measurement Protocol (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. [STANDARDS-TRACK]
RFC5356 - Reliable Server Pooling Policies
This document describes server pool policies for Reliable Server Pooling (RSerPool) including considerations for implementing them at Endpoint Handlespace Redundancy Protocol (ENRP) servers and pool users. This memo defines an Experimental Protocol for the Internet community.
RFC5355 - Threats Introduced by Reliable Server Pooling (RSerPool) and Requirements for Security in Response to Threats
Reliable Server Pooling (RSerPool) is an architecture and set of protocols for the management and access to server pools supporting highly reliable applications and for client access mechanisms to a server pool. This document describes security threats to the RSerPool architecture and presents requirements for security to thwart these threats. This memo provides information for the Internet community.
RFC5354 - Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace Redundancy Protocol (ENRP) Parameters
This document details the parameters of the Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace Redundancy Protocol (ENRP) defined within the Reliable Server Pooling (RSerPool) architecture. This memo defines an Experimental Protocol for the Internet community.
RFC5353 - Endpoint Handlespace Redundancy Protocol (ENRP)
The Endpoint Handlespace Redundancy Protocol (ENRP) is designed to work in conjunction with the Aggregate Server Access Protocol (ASAP) to accomplish the functionality of the Reliable Server Pooling (RSerPool) requirements and architecture. Within the operational scope of RSerPool, ENRP defines the procedures and message formats of a distributed, fault-tolerant registry service for storing, bookkeeping, retrieving, and distributing pool operation and membership information. This memo defines an Experimental Protocol for the Internet community.
RFC5352 - Aggregate Server Access Protocol (ASAP)
Aggregate Server Access Protocol (ASAP; RFC 5352), in conjunction with the Endpoint Handlespace Redundancy Protocol (ENRP; RFC 5353), provides a high-availability data transfer mechanism over IP networks. ASAP uses a handle-based addressing model that isolates a logical communication endpoint from its IP address(es), thus effectively eliminating the binding between the communication endpoint and its physical IP address(es), which normally constitutes a single point of failure.
RFC5351 - An Overview of Reliable Server Pooling Protocols
The Reliable Server Pooling effort (abbreviated "RSerPool") provides an application-independent set of services and protocols for building fault-tolerant and highly available client/server applications. This document provides an overview of the protocols and mechanisms in the Reliable Server Pooling suite. This memo provides information for the Internet community.
RFC5350 - 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. [STANDARDS-TRACK]
RFC5349 - Elliptic Curve Cryptography (ECC) Support for Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)
This document describes the use of Elliptic Curve certificates, Elliptic Curve signature schemes and Elliptic Curve Diffie-Hellman (ECDH) key agreement within the framework of PKINIT -- the Kerberos Version 5 extension that provides for the use of public key cryptography. This memo provides information for the Internet community.
RFC5348 - TCP Friendly Rate Control (TFRC): Protocol Specification
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.
RFC5347 - Media Gateway Control Protocol Fax Package
This document defines a Media Gateway Control Protocol (MGCP) package to support fax calls. The package allows for fax calls to be supported in two different ways. The first one utilizes ITU-T Recommendation T.38 for fax relay under the control of the Call Agent. The second one lets the gateway decide upon a method for fax transmission as well as handle the details of the fax call without Call Agent involvement. This memo provides information for the Internet community.
RFC5346 - Operational Requirements for ENUM-Based Softswitch Use
This document describes experiences of operational requirements and several considerations for ENUM-based softswitches concerning call routing between two Korean Voice over IP (VoIP) carriers, gained during the ENUM pre-commercial trial hosted by the National Internet Development Agency of Korea (NIDA) in 2006.
RFC5345 - Simple Network Management Protocol (SNMP) Traffic Measurements and Trace Exchange Formats
The Simple Network Management Protocol (SNMP) is widely deployed to monitor, control, and (sometimes also) configure network elements. Even though the SNMP technology is well documented, it remains relatively unclear how SNMP is used in practice and what typical SNMP usage patterns are.
RFC5344 - Presence and Instant Messaging Peering Use Cases
This document describes several use cases of peering of non-VoIP (Voice over IP) services between two or more Service Providers. These Service Providers create a peering relationship between themselves, thus enabling their users to collaborate with users on the other Service Provider network. The target of this document is to drive requirements for peering between domains that provide the non-VoIP based collaboration services with presence and, in particular, Instant Messaging (IM). This memo provides information for the Internet community.
RFC5343 - Simple Network Management Protocol (SNMP) Context EngineID Discovery
The Simple Network Management Protocol (SNMP) version three (SNMPv3) requires that an application know the identifier (snmpEngineID) of the remote SNMP protocol engine in order to retrieve or manipulate objects maintained on the remote SNMP entity.
This document describes extensions to the OSPF version 2 and 3 protocols to support Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple Autonomous 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.
RFC5391 - RTP Payload Format for ITU-T Recommendation G.711.1
This document specifies a Real-time Transport Protocol (RTP) payload format to be used for the ITU Telecommunication Standardization Sector (ITU-T) G.711.1 audio codec. Two media type registrations are also included. [STANDARDS-TRACK]
RFC5390 - Requirements for Management of Overload in the Session Initiation Protocol
Overload occurs in Session Initiation Protocol (SIP) networks when proxies and user agents have insufficient resources to complete the processing of a request. SIP provides limited support for overload handling through its 503 response code, which tells an upstream element that it is overloaded. However, numerous problems have been identified with this mechanism. This document summarizes the problems with the existing 503 mechanism, and provides some requirements for a solution. This memo provides information for the Internet community.
RFC5389 - 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 Address Translator (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.
RFC5388 - Information Model and XML Data Model for Traceroute Measurements
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. [STANDARDS-TRACK]
RFC5387 - Problem and Applicability Statement for Better-Than-Nothing Security (BTNS)
The Internet network security protocol suite, IPsec, requires authentication, usually of network-layer entities, to enable access control and provide security services. This authentication can be based on mechanisms such as pre-shared symmetric keys, certificates with associated asymmetric keys, or the use of Kerberos (via Kerberized Internet Negotiation of Keys (KINK)). The need to deploy authentication information and its associated identities can be a significant obstacle to the use of IPsec.
RFC5386 - Better-Than-Nothing Security: An Unauthenticated Mode of IPsec
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 Encapsulating Security Payload (ESP) and the IPsec Authentication Header (AH). No changes to IKEv2 bits-on-the-wire are required, but Peer Authorization 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). [STANDARDS-TRACK]
RFC5385 - Version 2.0 Microsoft Word Template for Creating Internet Drafts and RFCs
This document describes the properties and use of a revised Microsoft Word template (.dot) for writing Internet Drafts and RFCs. It replaces the initial template described in RFC 3285 to more fully support Word's outline modes and to be easier to use. This template can be direct-printed and direct-viewed, where either is line-for-line identical with RFC Editor-compliant ASCII output. This version obsoletes RFC 3285.
RFC5384 - The Protocol Independent Multicast (PIM) Join Attribute Format
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. [STANDARDS-TRACK]
RFC5383 - Deployment Considerations for Lemonade-Compliant Mobile Email
This document discusses deployment issues and describes requirements for successful deployment of mobile email that are implicit in the IETF lemonade documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
RFC5382 - NAT Behavioral Requirements for TCP
This document defines a set of requirements for NATs that handle TCP that would allow many applications, such as peer-to-peer applications and online games to work consistently. Developing NATs that meet this set of requirements will greatly increase the likelihood that these applications will function properly. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
RFC5381 - Experience of Implementing NETCONF over SOAP
This document describes how the authors developed a SOAP (Simple Object Access Protocol)-based NETCONF (Network Configuration Protocol) client and server. It describes an alternative SOAP binding for NETCONF that does not interoperate with an RFC 4743 conformant implementation making use of cookies on top of the persistent transport connections of HTTP. When SOAP is used as a transport protocol for NETCONF, various kinds of development tools are available. By making full use of these tools, developers can significantly reduce their workload. The authors developed an NMS (Network Management System) and network equipment that can deal with NETCONF messages sent over SOAP. This document aims to provide NETCONF development guidelines gained from the experience of implementing a SOAP-based NETCONF client and server. This memo provides information for the Internet community.
RFC5380 - Hierarchical Mobile IPv6 (HMIPv6) Mobility Management
This document introduces extensions to Mobile IPv6 and IPv6 Neighbour Discovery 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. [STANDARDS-TRACK]
RFC5379 - Guidelines for Using the Privacy Mechanism for SIP
This is an informational document that provides guidelines for using the privacy mechanism for the Session Initiation Protocol (SIP) that is specified in RFC 3323 and subsequently extended in RFCs 3325 and 4244. It is intended to clarify the handling of the target SIP headers/parameters and the Session Description Protocol (SDP) parameters for each of the privacy header values (priv-values). This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC5378 - Rights Contributors Provide to the IETF Trust
The IETF policies about rights in Contributions to the IETF are designed to ensure that such Contributions can be made available to the IETF and Internet communities while permitting the authors to retain as many rights as possible. This memo details the IETF policies on rights in Contributions to the IETF. It also describes the objectives that the policies are designed to meet. This memo obsoletes RFCs 3978 and 4748 and, with BCP 79 and RFC 5377, replaces Section 10 of RFC 2026. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
RFC5377 - Advice to the Trustees of the IETF Trust on Rights to Be Granted in IETF Documents
Contributors grant intellectual property rights to the IETF. The IETF Trust holds and manages those rights on behalf of the IETF. The Trustees of the IETF Trust are responsible for that management. This management includes granting the licenses to copy, implement, and otherwise use IETF Contributions, among them Internet-Drafts and RFCs. The Trustees of the IETF Trust accepts direction from the IETF regarding the rights to be granted. This document describes the desires of the IETF regarding outbound rights to be granted in IETF Contributions. This memo provides information for the Internet community.
RFC5376 - Inter-AS Requirements for the Path Computation Element Communication Protocol (PCECP)
Multiprotocol Label Switching Traffic Engineered (MPLS TE) Label Switched Paths (LSPs) may be established wholly within an Autonomous System (AS) or may cross AS boundaries.
RFC5375 - IPv6 Unicast Address Assignment Considerations
One fundamental aspect of any IP communications infrastructure is its addressing plan. With its new address architecture and allocation policies, the introduction of IPv6 into a network means that network designers and operators need to reconsider their existing approaches to network addressing. Lack of guidelines on handling this aspect of network design could slow down the deployment and integration of IPv6. This document aims to provide the information and recommendations relevant to planning the addressing aspects of IPv6 deployments. The document also provides IPv6 addressing case studies for both an enterprise and an ISP network. This memo provides information for the Internet community.
RFC5374 - Multicast Extensions to the Security Architecture for the Internet Protocol
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. [STANDARDS-TRACK]
RFC5373 - Requesting Answering Modes for the Session Initiation Protocol (SIP)
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. [STANDARDS-TRACK]
RFC5372 - Payload Format for JPEG 2000 Video: Extensions for Scalability and Main Header Recovery
This memo describes extended uses for the payload header in "RTP Payload 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.
RFC5371 - RTP Payload Format for JPEG 2000 Video Streams
This memo describes an RTP payload format for the ISO/IEC International Standard 15444-1 | ITU-T Rec. T.800, better known as JPEG 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. [STANDARDS-TRACK]
RFC5370 - The Session Initiation Protocol (SIP) Conference Bridge Transcoding Model
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. [STANDARDS-TRACK]
RFC5369 - Framework for Transcoding with the Session Initiation Protocol (SIP)
This document defines a framework for transcoding with SIP. This framework includes how to discover the need for transcoding services in a session and how to invoke those transcoding services. Two models for transcoding services invocation are discussed: the conference bridge model and the third-party call control model. Both models meet the requirements for SIP regarding transcoding services invocation to support deaf, hard of hearing, and speech-impaired individuals. This memo provides information for the Internet community.
RFC5368 - Referring to Multiple Resources in the Session Initiation Protocol (SIP)
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 Resource Identifier (URI) lists in the Refer-To header field and the "multiple-refer" SIP option-tag. [STANDARDS-TRACK]
RFC5367 - Subscriptions to Request-Contained Resource Lists in the Session Initiation Protocol (SIP)
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 single SUBSCRIBE dialog. [STANDARDS-TRACK]
RFC5366 - Conference Establishment Using Request-Contained Lists in the Session Initiation Protocol (SIP)
This document describes how to create a conference using SIP URI-list services. In particular, it describes a mechanism that allows a User Agent Client to provide a conference server with the initial list of participants using an INVITE-contained URI list. [STANDARDS-TRACK]
RFC5365 - Multiple-Recipient MESSAGE Requests in the Session Initiation Protocol (SIP)
This document specifies a mechanism that allows a SIP User Agent Client (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 a MESSAGE request including the payload to each of the URIs included in the list. [STANDARDS-TRACK]
RFC5364 - Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists
In certain types of multimedia communications, a Session Initiation Protocol (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. [STANDARDS-TRACK]
RFC5363 - Framework and Security Considerations for Session Initiation Protocol (SIP) URI-List Services
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. [STANDARDS-TRACK]
RFC5362 - The Session Initiation Protocol (SIP) Pending Additions Event Package
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. [STANDARDS-TRACK]
RFC5361 - A Document Format for Requesting Consent
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. [STANDARDS-TRACK]
RFC5360 - A Framework for Consent-Based Communications in the Session Initiation Protocol (SIP)
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. [STANDARDS-TRACK]
RFC5359 - Session Initiation Protocol Service Examples
This document gives examples of Session Initiation Protocol (SIP) services. This covers most features offered in so-called IP Centrex offerings from local exchange carriers and PBX (Private Branch Exchange) features. Most of the services shown in this document are implemented in the SIP user agents, although some require the assistance of a SIP proxy. Some require some extensions to SIP including the REFER, SUBSCRIBE, and NOTIFY methods and the Replaces and Join header fields. These features are not intended to be an exhaustive set, but rather show implementations of common features likely to be implemented on SIP IP telephones in a business environment. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
RFC5358 - Preventing Use of Recursive Nameservers in Reflector Attacks
This document describes ways to prevent the use of default configured recursive nameservers as reflectors in Denial of Service (DoS) attacks. It provides recommended configuration as measures to mitigate the attack. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
RFC5357 - A Two-Way Active Measurement Protocol (TWAMP)
The One-way Active Measurement Protocol (OWAMP), specified in RFC 4656, 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 Measurement Protocol (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. [STANDARDS-TRACK]
RFC5356 - Reliable Server Pooling Policies
This document describes server pool policies for Reliable Server Pooling (RSerPool) including considerations for implementing them at Endpoint Handlespace Redundancy Protocol (ENRP) servers and pool users. This memo defines an Experimental Protocol for the Internet community.
RFC5355 - Threats Introduced by Reliable Server Pooling (RSerPool) and Requirements for Security in Response to Threats
Reliable Server Pooling (RSerPool) is an architecture and set of protocols for the management and access to server pools supporting highly reliable applications and for client access mechanisms to a server pool. This document describes security threats to the RSerPool architecture and presents requirements for security to thwart these threats. This memo provides information for the Internet community.
RFC5354 - Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace Redundancy Protocol (ENRP) Parameters
This document details the parameters of the Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace Redundancy Protocol (ENRP) defined within the Reliable Server Pooling (RSerPool) architecture. This memo defines an Experimental Protocol for the Internet community.
RFC5353 - Endpoint Handlespace Redundancy Protocol (ENRP)
The Endpoint Handlespace Redundancy Protocol (ENRP) is designed to work in conjunction with the Aggregate Server Access Protocol (ASAP) to accomplish the functionality of the Reliable Server Pooling (RSerPool) requirements and architecture. Within the operational scope of RSerPool, ENRP defines the procedures and message formats of a distributed, fault-tolerant registry service for storing, bookkeeping, retrieving, and distributing pool operation and membership information. This memo defines an Experimental Protocol for the Internet community.
RFC5352 - Aggregate Server Access Protocol (ASAP)
Aggregate Server Access Protocol (ASAP; RFC 5352), in conjunction with the Endpoint Handlespace Redundancy Protocol (ENRP; RFC 5353), provides a high-availability data transfer mechanism over IP networks. ASAP uses a handle-based addressing model that isolates a logical communication endpoint from its IP address(es), thus effectively eliminating the binding between the communication endpoint and its physical IP address(es), which normally constitutes a single point of failure.
RFC5351 - An Overview of Reliable Server Pooling Protocols
The Reliable Server Pooling effort (abbreviated "RSerPool") provides an application-independent set of services and protocols for building fault-tolerant and highly available client/server applications. This document provides an overview of the protocols and mechanisms in the Reliable Server Pooling suite. This memo provides information for the Internet community.
RFC5350 - 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. [STANDARDS-TRACK]
RFC5349 - Elliptic Curve Cryptography (ECC) Support for Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)
This document describes the use of Elliptic Curve certificates, Elliptic Curve signature schemes and Elliptic Curve Diffie-Hellman (ECDH) key agreement within the framework of PKINIT -- the Kerberos Version 5 extension that provides for the use of public key cryptography. This memo provides information for the Internet community.
RFC5348 - TCP Friendly Rate Control (TFRC): Protocol Specification
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.
RFC5347 - Media Gateway Control Protocol Fax Package
This document defines a Media Gateway Control Protocol (MGCP) package to support fax calls. The package allows for fax calls to be supported in two different ways. The first one utilizes ITU-T Recommendation T.38 for fax relay under the control of the Call Agent. The second one lets the gateway decide upon a method for fax transmission as well as handle the details of the fax call without Call Agent involvement. This memo provides information for the Internet community.
RFC5346 - Operational Requirements for ENUM-Based Softswitch Use
This document describes experiences of operational requirements and several considerations for ENUM-based softswitches concerning call routing between two Korean Voice over IP (VoIP) carriers, gained during the ENUM pre-commercial trial hosted by the National Internet Development Agency of Korea (NIDA) in 2006.
RFC5345 - Simple Network Management Protocol (SNMP) Traffic Measurements and Trace Exchange Formats
The Simple Network Management Protocol (SNMP) is widely deployed to monitor, control, and (sometimes also) configure network elements. Even though the SNMP technology is well documented, it remains relatively unclear how SNMP is used in practice and what typical SNMP usage patterns are.
RFC5344 - Presence and Instant Messaging Peering Use Cases
This document describes several use cases of peering of non-VoIP (Voice over IP) services between two or more Service Providers. These Service Providers create a peering relationship between themselves, thus enabling their users to collaborate with users on the other Service Provider network. The target of this document is to drive requirements for peering between domains that provide the non-VoIP based collaboration services with presence and, in particular, Instant Messaging (IM). This memo provides information for the Internet community.
RFC5343 - Simple Network Management Protocol (SNMP) Context EngineID Discovery
The Simple Network Management Protocol (SNMP) version three (SNMPv3) requires that an application know the identifier (snmpEngineID) of the remote SNMP protocol engine in order to retrieve or manipulate objects maintained on the remote SNMP entity.