| |
| 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 5309 | Point-to-Point Operation over LAN in Link State Routing Protocols |
| |
| Authors: | N. Shen, Ed., A. Zinin, Ed.. |
| Date: | October 2008 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5309 |
|
The two predominant circuit types used by link state routing protocols are point-to-point and broadcast. It is important to identify the correct circuit type when forming adjacencies, flooding link state database packets, and representing the circuit topologically. This document describes a simple mechanism to treat the broadcast network as a point-to-point connection from the standpoint of IP routing. |
|
| |
| 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 5317 | Joint Working Team (JWT) Report on MPLS Architectural Considerations for a Transport Profile |
| |
| Authors: | S. Bryant, Ed., L. Andersson, Ed.. |
| Date: | February 2009 |
| Formats: | txt pdf html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5317 |
|
This RFC archives the report of the IETF - ITU-T Joint Working Team(JWT) on the application of MPLS to transport networks. The JWT recommended of Option 1: The IETF and the ITU-T jointly agree to work together and bring transport requirements into the IETF and extendIETF MPLS forwarding, OAM (Operations, Administration, andManagement), survivability, network management and control plane protocols to meet those requirements through the IETF StandardsProcess. This RFC is available in ASCII (which contains a summary of the slides) and in PDF (which contains the summary and a copy of the slides). |
|
| |
| RFC 5318 | The Session Initiation Protocol (SIP) P-Refused-URI-List Private-Header (P-Header) |
| |
| Authors: | J. Hautakorpi, G. Camarillo. |
| Date: | December 2008 |
| Formats: | txt json html |
| Updated by: | RFC 8217 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5318 |
|
This document specifies the Session Initiation Protocol (SIP)P-Refused-URI-List Private-Header (P-Header). This P-Header is used in the Open Mobile Alliance's (OMA) Push to talk over Cellular (PoC) system. It enables URI-list servers to refuse the handling of incoming URI lists that have embedded URI lists. This P-Header also makes it possible for the URI-list server to inform the client about the embedded URI list that caused the rejection and the individualURIs that form such a URI list. |
|
| |
| RFC 5320 | The Subnetwork Encapsulation and Adaptation Layer (SEAL) |
| |
| Authors: | F. Templin, Ed.. |
| Date: | February 2010 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5320 |
|
For the purpose of this document, subnetworks are defined as virtual topologies that span connected network regions bounded by encapsulating border nodes. These virtual topologies may span multiple IP and/or sub-IP layer forwarding hops, and can introduce failure modes due to packet duplication and/or links with diverseMaximum Transmission Units (MTUs). This document specifies aSubnetwork Encapsulation and Adaptation Layer (SEAL) that accommodates such virtual topologies over diverse underlying link technologies. |
|
| |
| RFC 5321 | Simple Mail Transfer Protocol |
| |
|
|
This document is a specification of the basic protocol for Internet electronic mail transport. It consolidates, updates, and clarifies several previous documents, making all or parts of most of them obsolete. It covers the SMTP extension mechanisms and best practices for the contemporary Internet, but does not provide details about particular extensions. 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 for "split-UA" (User Agent) mail reading systems and mobile environments. |
|
| |
| RFC 5322 | Internet Message Format |
| |
|
|
This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This specification is a revision of Request For Comments (RFC) 2822, which itself supersededRequest For Comments (RFC) 822, "Standard for the Format of ARPAInternet Text Messages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs. |
|
| |
| 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 5325 | Licklider Transmission Protocol - Motivation |
| |
| Authors: | S. Burleigh, M. Ramadas, S. Farrell. |
| Date: | September 2008 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5325 |
|
This document describes the motivation for the development of theLicklider Transmission Protocol (LTP) designed to provide retransmission-based reliability over links characterized by extremely long message round-trip times (RTTs) and/or frequent interruptions in connectivity. Since communication across interplanetary space is the most prominent example of this sort of environment, LTP is principally aimed at supporting "long-haul" reliable transmission in interplanetary space, but it has applications in other environments as well.
In an Interplanetary Internet setting deploying the Bundle protocol,LTP is intended to serve as a reliable convergence layer over single-hop deep-space radio frequency (RF) links. LTP does AutomaticRepeat reQuest (ARQ) of data transmissions by soliciting selective- acknowledgment reception reports. It is stateful and has no negotiation or handshakes.
This document is a product of the Delay Tolerant Networking ResearchGroup and has been reviewed by that group. No objections to its publication as an RFC were raised. |
|
| |
| RFC 5326 | Licklider Transmission Protocol - Specification |
| |
| Authors: | M. Ramadas, S. Burleigh, S. Farrell. |
| Date: | September 2008 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5326 |
|
This document describes the Licklider Transmission Protocol (LTP), designed to provide retransmission-based reliability over links characterized by extremely long message round-trip times (RTTs) and/or frequent interruptions in connectivity. Since communication across interplanetary space is the most prominent example of this sort of environment, LTP is principally aimed at supporting "long- haul" reliable transmission in interplanetary space, but it has applications in other environments as well.
This document is a product of the Delay Tolerant Networking ResearchGroup and has been reviewed by that group. No objections to its publication as an RFC were raised. |
|
| |
| RFC 5327 | Licklider Transmission Protocol - Security Extensions |
| |
| Authors: | S. Farrell, M. Ramadas, S. Burleigh. |
| Date: | September 2008 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5327 |
|
The Licklider Transmission Protocol (LTP) is intended to serve as a reliable convergence layer over single-hop deep-space radio frequency(RF) links. LTP does Automatic Repeat reQuest (ARQ) of data transmissions by soliciting selective-acknowledgment reception reports. It is stateful and has no negotiation or handshakes. This document describes security extensions to LTP, and is part of a series of related documents describing LTP.
This document is a product of the Delay Tolerant Networking ResearchGroup and has been reviewed by that group. No objections to its publication as an RFC were raised. |
|
| |
| RFC 5328 | A Uniform Resource Name (URN) Namespace for the Digital Video Broadcasting Project (DVB) |
| |
|
|
This document describes a Uniform Resource Name (URN) namespace for the Digital Video Broadcasting Project (DVB) for naming persistent resources defined within DVB standards. Example resources include technical documents and specifications, eXtensible Markup Language(XML) Schemas, classification schemes, XML Document Type Definitions(DTDs), namespaces, style sheets, media assets, and other types of resources produced or managed by DVB. |
|
| |
| 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 5335 | Internationalized Email Headers |
| |
|
|
Full internationalization of electronic mail requires not only the capabilities to transmit non-ASCII content, to encode selected information in specific header fields, and to use non-ASCII characters in envelope addresses. It also requires being able to express those addresses and the information based on them in mail header fields. This document specifies an experimental variant ofInternet mail that permits the use of Unicode encoded in UTF-8, rather than ASCII, as the base form for Internet email header field.This form is permitted in transmission only if authorized by an SMTP extension, as specified in an associated specification. This specification Updates section 6.4 of RFC 2045 to conform with the requirements. |
|
| |
| RFC 5336 | SMTP Extension for Internationalized Email Addresses |
| |
|
|
This document specifies an SMTP extension for transport and delivery of email messages with internationalized email addresses or header information. Communication with systems that do not implement this specification is specified in another document. This document updates some syntaxes and rules defined in RFC 2821 and RFC 2822, and has some material updating RFC 4952. |
|
| |
| RFC 5337 | Internationalized Delivery Status and Disposition Notifications |
| |
|
|
Delivery status notifications (DSNs) are critical to the correct operation of an email system. However, the existing Draft Standards(RFC 3461, RFC 3462, RFC 3464) are presently limited to US-ASCII text in the machine-readable portions of the protocol. This specification adds a new address type for international email addresses so an original recipient address with non-US-ASCII characters can be correctly preserved even after downgrading. This also provides updated content return media types for delivery status notifications and message disposition notifications to support use of the new address type.
This document experimentally extends RFC 3461, RFC 3464, and RFC3798. |
|
| |
| RFC 5338 | Using the Host Identity Protocol with Legacy Applications |
| |
| Authors: | T. Henderson, P. Nikander, M. Komu. |
| Date: | September 2008 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5338 |
|
This document is an informative overview of how legacy applications can be made to work with the Host Identity Protocol (HIP). HIP proposes to add a cryptographic name space for network stack names.From an application viewpoint, HIP-enabled systems support a new address family of host identifiers, but it may be a long time until such HIP-aware applications are widely deployed even if host systems are upgraded. This informational document discusses implementation and Application Programming Interface (API) issues relating to usingHIP in situations in which the system is HIP-aware but the applications are not, and is intended to aid implementors and early adopters in thinking about and locally solving systems issues regarding the incremental deployment of HIP. |
|
| |
| RFC 5339 | Evaluation of Existing GMPLS Protocols against Multi-Layer and Multi-Region Networks (MLN/MRN) |
| |
| Authors: | JL. Le Roux, Ed., D. Papadimitriou, Ed.. |
| Date: | September 2008 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5339 |
|
This document provides an evaluation of Generalized MultiprotocolLabel Switching (GMPLS) protocols and mechanisms against the requirements for Multi-Layer Networks (MLNs) and Multi-RegionNetworks (MRNs). In addition, this document identifies areas where additional protocol extensions or procedures are needed to satisfy these requirements, and provides guidelines for potential extensions. |
|
| |
| 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 5342 | IANA Considerations and IETF Protocol Usage for IEEE 802 Parameters |
| |
|
|
Some IETF protocols make use of Ethernet frame formats and IEEE 802 parameters. This document discusses some use of such parameters inIETF protocols and specifies IANA considerations for allocation of code points under the IANA OUI (Organizationally Unique Identifier). |
|
| |
| RFC 5343 | 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 introduces a well-known localEngineID and a discovery mechanism that can be used to learn the snmpEngineID of a remote SNMP protocol engine. The proposed mechanism is independent of the features provided by SNMP security models and may also be used by other protocol interfaces providing access to managed objects.
This document updates RFC 3411. |
|
| |
| RFC 5344 | Presence and Instant Messaging Peering Use Cases |
| |
| Authors: | A. Houri, E. Aoki, S. Parameswar. |
| Date: | October 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5344 |
|
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). |
|
| |
| RFC 5345 | Simple Network Management Protocol (SNMP) Traffic Measurements and Trace Exchange Formats |
| |
| Authors: | J. Schoenwaelder. |
| Date: | October 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5345 |
|
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.
This document describes an approach to carrying out large-scale SNMP traffic measurements in order to develop a better understanding of how SNMP is used in real-world production networks. It describes the motivation, the measurement approach, and the tools and data formats needed to carry out such a study.
This document was produced within the IRTF's Network ManagementResearch Group (NMRG), and it represents the consensus of all of the active contributors to this group. |
|
| |
| RFC 5346 | Operational Requirements for ENUM-Based Softswitch Use |
| |
| Authors: | J. Lim, W. Kim, C. Park, L. Conroy. |
| Date: | October 2008 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5346 |
|
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 InternetDevelopment Agency of Korea (NIDA) in 2006.
These experiences show that an interim solution can maintain the stability of ongoing commercial softswitch system operations during the initial stage of ENUM service, where the DNS does not have sufficient data for the majority of calls. |
|
| |
| RFC 5347 | Media Gateway Control Protocol Fax Package |
| |
| Authors: | F. Andreasen, D. Hancock. |
| Date: | October 2008 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5347 |
|
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-TRecommendation T.38 for fax relay under the control of the CallAgent. The second one lets the gateway decide upon a method for fax transmission as well as handle the details of the fax call withoutCall Agent involvement. |
|
| |
| 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 5349 | Elliptic Curve Cryptography (ECC) Support for Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) |
| |
| Authors: | L. Zhu, K. Jaganathan, K. Lauter. |
| Date: | September 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5349 |
|
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 KerberosVersion 5 extension that provides for the use of public key cryptography. |
|
| |
| 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 5351 | An Overview of Reliable Server Pooling Protocols |
| |
| Authors: | P. Lei, L. Ong, M. Tuexen, T. Dreibholz. |
| Date: | September 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5351 |
|
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 theReliable Server Pooling suite. |
|
| |
| RFC 5352 | Aggregate Server Access Protocol (ASAP) |
| |
| Authors: | R. Stewart, Q. Xie, M. Stillman, M. Tuexen. |
| Date: | September 2008 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5352 |
|
Aggregate Server Access Protocol (ASAP; RFC 5352), in conjunction with the Endpoint Handlespace Redundancy Protocol (ENRP; RFC 5353), provides a high-availability data transfer mechanism over IP networks. ASAP uses a handle-based addressing model that isolates a logical communication endpoint from its IP address(es), thus effectively eliminating the binding between the communication endpoint and its physical IP address(es), which normally constitutes a single point of failure.
In addition, ASAP defines each logical communication destination as a pool, providing full transparent support for server pooling and load sharing. It also allows dynamic system scalability -- members of a server pool can be added or removed at any time without interrupting the service.
ASAP is designed to take full advantage of the network level redundancy provided by the Stream Transmission Control Protocol(SCTP; RFC 4960). Each transport protocol, other than SCTP, MUST have an accompanying transport mapping document. It should be noted that ASAP messages passed between Pool Elements (PEs) and ENRP servers MUST use the SCTP transport protocol.
The high-availability server pooling is gained by combining two protocols, namely ASAP and ENRP, in which ASAP provides the user interface for Pool Handle to address translation, load sharing management, and fault management, while ENRP defines the high- availability Pool Handle translation service. |
|
| |
| RFC 5353 | Endpoint Handlespace Redundancy Protocol (ENRP) |
| |
| Authors: | Q. Xie, R. Stewart, M. Stillman, M. Tuexen, A. Silverton. |
| Date: | September 2008 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5353 |
|
The Endpoint Handlespace Redundancy Protocol (ENRP) is designed to work in conjunction with the Aggregate Server Access Protocol (ASAP) to accomplish the functionality of the Reliable Server Pooling(RSerPool) requirements and architecture. Within the operational scope of RSerPool, ENRP defines the procedures and message formats of a distributed, fault-tolerant registry service for storing, bookkeeping, retrieving, and distributing pool operation and membership information. |
|
| |
| RFC 5354 | Aggregate Server Access Protocol (ASAP) and Endpoint Handlespace Redundancy Protocol (ENRP) Parameters |
| |
| Authors: | R. Stewart, Q. Xie, M. Stillman, M. Tuexen. |
| Date: | September 2008 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5354 |
|
This document details the parameters of the Aggregate Server AccessProtocol (ASAP) and Endpoint Handlespace Redundancy Protocol (ENRP) defined within the Reliable Server Pooling (RSerPool) architecture. |
|
| |
| RFC 5355 | Threats Introduced by Reliable Server Pooling (RSerPool) and Requirements for Security in Response to Threats |
| |
| Authors: | M. Stillman, Ed., R. Gopal, E. Guttman, S. Sengodan, M. Holdrege. |
| Date: | September 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5355 |
|
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 theRSerPool architecture and presents requirements for security to thwart these threats. |
|
| |
| RFC 5356 | Reliable Server Pooling Policies |
| |
| Authors: | T. Dreibholz, M. Tuexen. |
| Date: | September 2008 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5356 |
|
This document describes server pool policies for Reliable ServerPooling (RSerPool) including considerations for implementing them atEndpoint Handlespace Redundancy Protocol (ENRP) servers and pool users. |
|
| |
| RFC 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 5358 | 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. |
|
| |
| RFC 5359 | Session Initiation Protocol Service Examples |
| |
| Authors: | A. Johnston, Ed., R. Sparks, C. Cunningham, S. Donovan, K. Summers. |
| Date: | October 2008 |
| Formats: | txt html json |
| Also: | BCP 0144 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 5359 |
|
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 BranchExchange) 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. |
|
| |
| 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 5369 | Framework for Transcoding with the Session Initiation Protocol (SIP) |
| |
| Authors: | G. Camarillo. |
| Date: | October 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5369 |
|
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. |
|
| |
| 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 5375 | IPv6 Unicast Address Assignment Considerations |
| |
| Authors: | G. Van de Velde, C. Popoviciu, T. Chown, O. Bonness, C. Hahn. |
| Date: | December 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5375 |
|
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 ofIPv6. 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. |
|
| |
| RFC 5376 | Inter-AS Requirements for the Path Computation Element Communication Protocol (PCECP) |
| |
| Authors: | N. Bitar, R. Zhang, K. Kumaki. |
| Date: | November 2008 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5376 |
|
Multiprotocol Label Switching Traffic Engineered (MPLS TE) LabelSwitched Paths (LSPs) may be established wholly within an AutonomousSystem (AS) or may cross AS boundaries.
The Path Computation Element (PCE) is a component that is capable of computing constrained paths for (G)MPLS TE LSPs. The PCECommunication Protocol (PCECP) is defined to allow communication between Path Computation Clients (PCCs) and PCEs, as well as betweenPCEs. The PCECP is used to request constrained paths and to supply computed paths in response. Generic requirements for the PCECP are set out in "Path Computation Element (PCE) Communication ProtocolGeneric Requirements", RFC 4657. This document extends those requirements to cover the use of PCECP in support of inter-AS MPLSTE. |
|
| |
| RFC 5377 | Advice to the Trustees of the IETF Trust on Rights to Be Granted in IETF Documents |
| |
|
|
Contributors grant intellectual property rights to the IETF. TheIETF Trust holds and manages those rights on behalf of the IETF. TheTrustees 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 andRFCs. 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 IETFContributions. |
|
| |
| RFC 5378 | 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, replacesSection 10 of RFC 2026. |
|
| |
| RFC 5379 | Guidelines for Using the Privacy Mechanism for SIP |
| |
| Authors: | M. Munakata, S. Schubert, T. Ohba. |
| Date: | February 2010 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5379 |
|
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 and4244. 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). |
|
| |
| 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 5381 | Experience of Implementing NETCONF over SOAP |
| |
| Authors: | T. Iijima, Y. Atarashi, H. Kimura, M. Kitani, H. Okita. |
| Date: | October 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5381 |
|
This document describes how the authors developed a SOAP (SimpleObject Access Protocol)-based NETCONF (Network ConfigurationProtocol) 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 withNETCONF messages sent over SOAP. This document aims to provideNETCONF development guidelines gained from the experience of implementing a SOAP-based NETCONF client and server. |
|
| |
| RFC 5382 | NAT Behavioral Requirements for TCP |
| |
| Authors: | S. Guha, Ed., K. Biswas, B. Ford, S. Sivakumar, P. Srisuresh. |
| Date: | October 2008 |
| Formats: | txt json html |
| Updated by: | RFC 7857 |
| Also: | BCP 0142 |
| Status: | BEST CURRENT PRACTICE |
| DOI: | 10.17487/RFC 5382 |
|
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. |
|
| |
| RFC 5383 | 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 theIETF lemonade documents. |
|
| |
| 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 5385 | Version 2.0 Microsoft Word Template for Creating Internet Drafts and RFCs |
| |
|
|
This document describes the properties and use of a revised MicrosoftWord 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.
The most recent version of this template and post-processing scripts are available at http://www.isi.edu/touch/tools. |
|
| |
| 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 5387 | Problem and Applicability Statement for Better-Than-Nothing Security (BTNS) |
| |
| Authors: | J. Touch, D. Black, Y. Wang. |
| Date: | November 2008 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5387 |
|
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 (viaKerberized 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.
This document explains the rationale for extending the Internet network security protocol suite to enable use of IPsec security services without authentication. These extensions are intended to protect communication, providing "better-than-nothing security"(BTNS). The extensions may be used on their own (this use is calledStand-Alone BTNS, or SAB) or may be used to provide network-layer security that can be authenticated by higher layers in the protocol stack (this use is called Channel-Bound BTNS, or CBB). The document also explains situations for which use of SAB and/or CBB extensions are applicable. |
|
| |
| 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 5390 | Requirements for Management of Overload in the Session Initiation Protocol |
| |
| Authors: | J. Rosenberg. |
| Date: | December 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5390 |
|
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. |
|
| |
| 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 5394 | Policy-Enabled Path Computation Framework |
| |
| Authors: | I. Bryskin, D. Papadimitriou, L. Berger, J. Ash. |
| Date: | December 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5394 |
|
The Path Computation Element (PCE) architecture introduces the concept of policy in the context of path computation. This document provides additional details on policy within the PCE architecture and also provides context for the support of PCE Policy. This document introduces the use of the Policy Core Information Model (PCIM) as a framework for supporting path computation policy. This document also provides representative scenarios for the support of PCE Policy. |
|
| |
| RFC 5395 | Domain Name System (DNS) IANA Considerations |
| |
|
|
Internet Assigned Number Authority (IANA) parameter assignment considerations are specified for the allocation of Domain Name System(DNS) resource record types, CLASSes, operation codes, error codes,DNS protocol message header bits, and AFSDB resource record subtypes. |
|
| |
| 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 5398 | Autonomous System (AS) Number Reservation for Documentation Use |
| |
| Authors: | G. Huston. |
| Date: | December 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5398 |
|
To reduce the likelihood of conflict and confusion when relating documented examples to deployed systems, two blocks of AutonomousSystem numbers (ASNs) are reserved for use in examples in RFCs, books, documentation, and the like. This document describes the reservation of two blocks of ASNs as reserved numbers for use in documentation. |
|
