| |
| RFC 5101 | Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information |
| |
|
|
This document specifies the IP Flow Information Export (IPFIX) protocol that serves for transmitting IP Traffic Flow information over the network. In order to transmit IP Traffic Flow information from an Exporting Process to an information Collecting Process, a common representation of flow data and a standard means of communicating them is required. This document describes how theIPFIX Data and Template Records are carried over a number of transport protocols from an IPFIX Exporting Process to an IPFIXCollecting Process. |
|
| |
| RFC 5102 | Information Model for IP Flow Information Export |
| |
| Authors: | J. Quittek, S. Bryant, B. Claise, P. Aitken, J. Meyer. |
| Date: | January 2008 |
| Formats: | txt html json |
| Obsoleted by: | RFC 7012 |
| Updated by: | RFC 6313 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5102 |
|
This memo defines an information model for the IP Flow Information eXport (IPFIX) protocol. It is used by the IPFIX protocol for encoding measured traffic information and information related to the traffic Observation Point, the traffic Metering Process, and theExporting Process. Although developed for the IPFIX protocol, the model is defined in an open way that easily allows using it in other protocols, interfaces, and applications. |
|
| |
| RFC 5103 | Bidirectional Flow Export Using IP Flow Information Export (IPFIX) |
| |
| Authors: | B. Trammell, E. Boschi. |
| Date: | January 2008 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5103 |
|
This document describes an efficient method for exporting bidirectional flow (Biflow) information using the IP Flow InformationExport (IPFIX) protocol, representing each Biflow using a single FlowRecord. |
|
| |
| RFC 5104 | Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF) |
| |
|
|
This document specifies a few extensions to the messages defined in the Audio-Visual Profile with Feedback (AVPF). They are helpful primarily in conversational multimedia scenarios where centralized multipoint functionalities are in use. However, some are also usable in smaller multicast environments and point-to-point calls.
The extensions discussed are messages related to the ITU-T Rec. H.271Video Back Channel, Full Intra Request, Temporary Maximum MediaStream Bit Rate, and Temporal-Spatial Trade-off. |
|
| |
| RFC 5105 | ENUM Validation Token Format Definition |
| |
| Authors: | O. Lendl. |
| Date: | December 2007 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5105 |
|
An ENUM domain name is tightly coupled with the underlying E.164 number. The process of verifying whether the Registrant of an ENUM domain name is identical to the Assignee of the corresponding E.164 number is commonly called "validation". This document describes a signed XML data format -- the Validation Token -- with whichValidation Entities can convey successful completion of a validation procedure in a secure fashion. |
|
| |
| RFC 5106 | The Extensible Authentication Protocol-Internet Key Exchange Protocol version 2 (EAP-IKEv2) Method |
| |
| Authors: | H. Tschofenig, D. Kroeselberg, A. Pashalidis, Y. Ohba, F. Bersani. |
| Date: | February 2008 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5106 |
|
This document specifies EAP-IKEv2, an Extensible AuthenticationProtocol (EAP) method that is based on the Internet Key Exchange(IKEv2) protocol. EAP-IKEv2 provides mutual authentication and session key establishment between an EAP peer and an EAP server. It supports authentication techniques that are based on passwords, high-entropy shared keys, and public key certificates. EAP-IKEv2 further provides support for cryptographic ciphersuite negotiation, hash function agility, identity confidentiality (in certain modes of operation), fragmentation, and an optional "fast reconnect" mode. |
|
| |
| RFC 5107 | DHCP Server Identifier Override Suboption |
| |
| Authors: | R. Johnson, J. Kumarasamy, K. Kinnear, M. Stapp. |
| Date: | February 2008 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5107 |
|
This memo defines a new suboption of the DHCP relay information option that allows the DHCP relay to specify a new value for theServer Identifier option, which is inserted by the DHCP Server. This allows the DHCP relay to act as the actual DHCP server such thatRENEW DHCPREQUESTs will come to the relay instead of going to the server directly. This gives the relay the opportunity to include theRelay Agent option with appropriate suboptions even on DHCP RENEW messages. |
|
| |
| RFC 5109 | RTP Payload Format for Generic Forward Error Correction |
| |
|
|
This document specifies a payload format for generic Forward ErrorCorrection (FEC) for media data encapsulated in RTP. It is based on the exclusive-or (parity) operation. The payload format described in this document allows end systems to apply protection using various protection lengths and levels, in addition to using various protection group sizes to adapt to different media and channel characteristics. It enables complete recovery of the protected packets or partial recovery of the critical parts of the payload depending on the packet loss situation. This scheme is completely compatible with non-FEC-capable hosts, so the receivers in a multicast group that do not implement FEC can still work by simply ignoring the protection data. This specification obsoletes RFC 2733 and RFC 3009. The FEC specified in this document is not backward compatible with RFC 2733 and RFC 3009. |
|
| |
| RFC 5110 | Overview of the Internet Multicast Routing Architecture |
| |
| Authors: | P. Savola. |
| Date: | January 2008 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5110 |
|
This document describes multicast routing architectures that are currently deployed on the Internet. This document briefly describes those protocols and references their specifications.
This memo also reclassifies several older RFCs to Historic. TheseRFCs describe multicast routing protocols that were never widely deployed or have fallen into disuse. |
|
| |
| RFC 5111 | Experiment in Exploratory Group Formation within the Internet Engineering Task Force (IETF) |
| |
| Authors: | B. Aboba, L. Dondeti. |
| Date: | January 2008 |
| Formats: | txt json html |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5111 |
|
This document describes an RFC 3933 experiment in the Working Group formation process, known as the Exploratory Group. ExploratoryGroups may be created as the first step toward Working Group formation, or as an intermediate step between a Birds of a Feather(BOF) session and Working Group creation. Exploratory Groups are focused on completion of prerequisites for Working Group formation, and as a result they have a short life-time, with limited opportunities for milestone extension. |
|
| |
| RFC 5112 | The Presence-Specific Static Dictionary for Signaling Compression (Sigcomp) |
| |
| Authors: | M. Garcia-Martin. |
| Date: | January 2008 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5112 |
|
The Session Initiation Protocol (SIP) is a text-based protocol for initiating and managing communication sessions. The protocol is extended by the SIP-events notification framework to provide subscriptions and notifications of SIP events. One example of such event notification mechanism is presence, which is expressed in XML documents called presence documents. SIP can be compressed by usingSignaling Compression (SigComp), which is enhanced by using the SIP/Session Description Protocol (SDP) dictionary to achieve better compression rates. However, the SIP/SDP dictionary is not able to increase the compression factor of (typically lengthy) presence documents. This memo defines the presence-specific static dictionary that SigComp can use in order to compress presence documents to achieve higher efficiency. The dictionary is compression-algorithm independent. |
|
| |
| RFC 5113 | Network Discovery and Selection Problem |
| |
| Authors: | J. Arkko, B. Aboba, J. Korhonen, Ed., F. Bari. |
| Date: | January 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5113 |
|
When multiple access networks are available, users may have difficulty in selecting which network to connect to and how to authenticate with that network. This document defines the network discovery and selection problem, dividing it into multiple sub- problems. Some constraints on potential solutions are outlined, and the limitations of several solutions (including existing ones) are discussed. |
|
| |
| RFC 5114 | Additional Diffie-Hellman Groups for Use with IETF Standards |
| |
| Authors: | M. Lepinski, S. Kent. |
| Date: | January 2008 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5114 |
|
This document describes eight Diffie-Hellman groups that can be used in conjunction with IETF protocols to provide security for Internet communications. The groups allow implementers to use the same groups with a variety of security protocols, e.g., SMIME, Secure SHell(SSH), Transport Layer Security (TLS), and Internet Key Exchange(IKE).
All of these groups comply in form and structure with relevant standards from ISO, ANSI, NIST, and the IEEE. These groups are compatible with all IETF standards that make use of Diffie-Hellman orElliptic Curve Diffie-Hellman cryptography.
These groups and the associated test data are defined by NIST on their web site [EX80056A], but have not yet (as of this writing) been published in a formal NIST document. Publication of these groups and associated test data, as well as describing how to use Diffie-Hellman and Elliptic Curve Diffie-Hellman for key agreement in all of the protocols cited below, in one RFC, will facilitate development of interoperable implementations and support the Federal InformationProcessing Standard (FIPS) validation of implementations that make use of these groups. |
|
| |
| RFC 5115 | Telephony Routing over IP (TRIP) Attribute for Resource Priority |
| |
| Authors: | K. Carlberg, P. O'Hanlon. |
| Date: | January 2008 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5115 |
|
This document defines a new attribute for the Telephony Routing overIP (TRIP) protocol. The attribute associates protocols/services in the PSTN offering authorized prioritization during call setup that are reachable through a TRIP gateway. Current examples of preferential service in the Public Switched Telephone Network (PSTN) are Government Emergency Telecommunications Service (GETS) in theU.S. and Government Telephone Preference Scheme (GTPS) in the U.K.The proposed attribute for TRIP is based on the NameSpace.Value tuple defined for the SIP Resource-Priority field. |
|
| |
| RFC 5116 | An Interface and Algorithms for Authenticated Encryption |
| |
| Authors: | D. McGrew. |
| Date: | January 2008 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5116 |
|
This document defines algorithms for Authenticated Encryption withAssociated Data (AEAD), and defines a uniform interface and a registry for such algorithms. The interface and registry can be used as an application-independent set of cryptoalgorithm suites. This approach provides advantages in efficiency and security, and promotes the reuse of crypto implementations. |
|
| |
| RFC 5117 | RTP Topologies |
| |
| Authors: | M. Westerlund, S. Wenger. |
| Date: | January 2008 |
| Formats: | txt html json |
| Obsoleted by: | RFC 7667 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5117 |
|
This document discusses multi-endpoint topologies used in Real-timeTransport Protocol (RTP)-based environments. In particular, centralized topologies commonly employed in the video conferencing industry are mapped to the RTP terminology. |
|
| |
| RFC 5118 | Session Initiation Protocol (SIP) Torture Test Messages for Internet Protocol Version 6 (IPv6) |
| |
| Authors: | V. Gurbani, C. Boulton, R. Sparks. |
| Date: | February 2008 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5118 |
|
This document provides examples of Session Initiation Protocol (SIP) test messages designed to exercise and "torture" the code of anIPv6-enabled SIP implementation. |
|
| |
| RFC 5119 | A Uniform Resource Name (URN) Namespace for the Society of Motion Picture and Television Engineers (SMPTE) |
| |
| Authors: | T. Edwards. |
| Date: | February 2008 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5119 |
|
This document describes a Uniform Resource Name (URN) namespace for the Society of Motion Picture and Television Engineers (SMPTE) for naming persistent resources that SMPTE produces or manages. A subnamespace for Universal Labels is specifically described. |
|
| |
| RFC 5120 | M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs) |
| |
| Authors: | T. Przygienda, N. Shen, N. Sheth. |
| Date: | February 2008 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5120 |
|
This document describes an optional mechanism within IntermediateSystem to Intermediate Systems (IS-ISs) used today by many ISPs forIGP routing within their clouds. This document describes how to run, within a single IS-IS domain, a set of independent IP topologies that we call Multi-Topologies (MTs). This MT extension can be used for a variety of purposes, such as an in-band management network "on top" of the original IGP topology, maintaining separate IGP routing domains for isolated multicast or IPv6 islands within the backbone, or forcing a subset of an address space to follow a different topology. |
|
| |
| RFC 5121 | Transmission of IPv6 via the IPv6 Convergence Sublayer over IEEE 802.16 Networks |
| |
| Authors: | B. Patil, F. Xia, B. Sarikaya, JH. Choi, S. Madanapalli. |
| Date: | February 2008 |
| Formats: | txt json html |
| Updated by: | RFC 8064 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5121 |
|
IEEE Std 802.16 is an air interface specification for fixed and mobile Broadband Wireless Access Systems. Service-specific convergence sublayers to which upper-layer protocols interface are a part of the IEEE 802.16 MAC (Medium Access Control). The Packet convergence sublayer (CS) is used for the transport of all packet- based protocols such as Internet Protocol (IP) and IEEE 802.3 LAN/MANCSMA/CD Access Method (Ethernet). IPv6 packets can be sent and received via the IP-specific part of the Packet CS. This document specifies the addressing and operation of IPv6 over the IP-specific part of the Packet CS for hosts served by a network that utilizes theIEEE Std 802.16 air interface. It recommends the assignment of a unique prefix (or prefixes) to each host and allows the host to use multiple identifiers within that prefix, including support for randomly generated interface identifiers. |
|
| |
| RFC 5122 | Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP) |
| |
|
|
This document defines the use of Internationalized ResourceIdentifiers (IRIs) and Uniform Resource Identifiers (URIs) in identifying or interacting with entities that can communicate via theExtensible Messaging and Presence Protocol (XMPP).
This document obsoletes RFC 4622. |
|
| |
| RFC 5123 | Considerations in Validating the Path in BGP |
| |
| Authors: | R. White, B. Akyol. |
| Date: | February 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5123 |
|
This document examines the implications of hop-by-hop forwarding, route aggregation, and route filtering on the concept of validation within a BGP Autonomous System (AS) Path. |
|
| |
| RFC 5124 | Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF) |
| |
| Authors: | J. Ott, E. Carrara. |
| Date: | February 2008 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5124 |
|
An RTP profile (SAVP) for secure real-time communications and another profile (AVPF) to provide timely feedback from the receivers to a sender are defined in RFC 3711 and RFC 4585, respectively. This memo specifies the combination of both profiles to enable secure RTP communications with feedback. |
|
| |
| RFC 5125 | Reclassification of RFC 3525 to Historic |
| |
|
|
This document reclassifies RFC 3525, Gateway Control Protocol Version1, to Historic Status. This memo also obsoletes RFC 3525. |
|
| |
| RFC 5126 | CMS Advanced Electronic Signatures (CAdES) |
| |
| Authors: | D. Pinkas, N. Pope, J. Ross. |
| Date: | March 2008 |
| Formats: | txt html json |
| Obsoletes: | RFC 3126 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5126 |
|
This document defines the format of an electronic signature that can remain valid over long periods. This includes evidence as to its validity even if the signer or verifying party later attempts to deny(i.e., repudiates) the validity of the signature.
The format can be considered as an extension to RFC 3852 and RFC2634, where, when appropriate, additional signed and unsigned attributes have been defined.
The contents of this Informational RFC amount to a transposition of the ETSI Technical Specification (TS) 101 733 V.1.7.4 (CMS AdvancedElectronic Signatures -- CAdES) and is technically equivalent to it.
The technical contents of this specification are maintained by ETSI.The ETSI TS and further updates are available free of charge at: http://www.etsi.org/WebSite/Standards/StandardsDownload.aspx |
|
| |
| RFC 5127 | Aggregation of Diffserv Service Classes |
| |
| Authors: | K. Chan, J. Babiarz, F. Baker. |
| Date: | February 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5127 |
|
In the core of a high-capacity network, service differentiation may still be needed to support applications' utilization of the network.Applications with similar traffic characteristics and performance requirements are mapped into Diffserv service classes based on end- to-end behavior requirements of the applications. However, some network segments may be configured in such a way that a single forwarding treatment may satisfy the traffic characteristics and performance requirements of two or more service classes. In these cases, it may be desirable to aggregate two or more Diffserv service classes into a single forwarding treatment. This document provides guidelines for the aggregation of Diffserv service classes into forwarding treatments. |
|
| |
| RFC 5128 | State of Peer-to-Peer (P2P) Communication across Network Address Translators (NATs) |
| |
| Authors: | P. Srisuresh, B. Ford, D. Kegel. |
| Date: | March 2008 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5128 |
|
This memo documents the various methods known to be in use by applications to establish direct communication in the presence ofNetwork Address Translators (NATs) at the current time. Although this memo is intended to be mainly descriptive, the SecurityConsiderations section makes some purely advisory recommendations about how to deal with security vulnerabilities the applications could inadvertently create when using the methods described. This memo covers NAT traversal approaches used by both TCP- and UDP-based applications. This memo is not an endorsement of the methods described, but merely an attempt to capture them in a document. |
|
| |
| RFC 5129 | Explicit Congestion Marking in MPLS |
| |
|
|
RFC 3270 defines how to support the Diffserv architecture in MPLS networks, including how to encode Diffserv Code Points (DSCPs) in anMPLS header. DSCPs may be encoded in the EXP field, while other uses of that field are not precluded. RFC 3270 makes no statement about how Explicit Congestion Notification (ECN) marking might be encoded in the MPLS header. This document defines how an operator might define some of the EXP codepoints for explicit congestion notification, without precluding other uses. |
|
| |
| RFC 5130 | A Policy Control Mechanism in IS-IS Using Administrative Tags |
| |
| Authors: | S. Previdi, M. Shand, Ed., C. Martin. |
| Date: | February 2008 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5130 |
|
This document describes an extension to the IS-IS protocol to add operational capabilities that allow for ease of management and control over IP prefix distribution within an IS-IS domain. This document enhances the IS-IS protocol by extending the information that an Intermediate System (IS) router can place in Link StateProtocol (LSP) Data Units for policy use. This extension will provide operators with a mechanism to control IP prefix distribution throughout multi-level IS-IS domains. |
|
| |
| RFC 5131 | A MIB Textual Convention for Language Tags |
| |
| Authors: | D. McWalter, Ed.. |
| Date: | December 2007 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5131 |
|
This MIB module defines a textual convention to represent BCP 47 language tags. The intent is that this textual convention will be imported and used in MIB modules that would otherwise define their own representation. |
|
| |
| RFC 5132 | IP Multicast MIB |
| |
| Authors: | D. McWalter, D. Thaler, A. Kessler. |
| Date: | December 2007 |
| Formats: | txt html json |
| Obsoletes: | RFC 2932 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5132 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes objects used for managing multicast function, independent of the specific multicast protocol(s) in use.This document obsoletes RFC 2932. |
|
| |
| RFC 5133 | Terminal Endpoint Identifier (TEI) Query Request Number Change |
| |
| Authors: | M. Tuexen, K. Morneault. |
| Date: | December 2007 |
| Formats: | txt html json |
| Updates: | RFC 4233 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5133 |
|
The Integrated Services Digital Network (ISDN) Q.921-User AdaptationLayer (IUA) Protocol, described in RFC 4233, defines the message type of Terminal Endpoint Identifier (TEI) Query Request messages as 5.However, this number is already being used by the Digital PrivateNetwork Signaling System (DPNSS)/Digital Access Signaling System 2(DASS 2) Extensions (DUA) to the IUA Protocol described in RFC 4129.This document updates RFC 4233 such that the message type of TEIQuery Request messages is 8. |
|
| |
| RFC 5134 | A Uniform Resource Name Namespace for the EPCglobal Electronic Product Code (EPC) and Related Standards |
| |
| Authors: | M. Mealling. |
| Date: | January 2008 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5134 |
|
This document describes URN namespaces that will identify various objects within the EPCglobal system for identifying products within ecommerce and supply chain management applications. |
|
| |
| RFC 5135 | IP Multicast Requirements for a Network Address Translator (NAT) and a Network Address Port Translator (NAPT) |
| |
|
|
This document specifies requirements for a for a Network AddressTranslator (NAT) and a Network Address Port Translator (NAPT) that support Any Source IP Multicast or Source-Specific IP Multicast. AnIP multicast-capable NAT device that adheres to the requirements of this document can optimize the operation of IP multicast applications that are generally unaware of IP multicast NAT devices. |
|
| |
| RFC 5136 | Defining Network Capacity |
| |
| Authors: | P. Chimento, J. Ishac. |
| Date: | February 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5136 |
|
Measuring capacity is a task that sounds simple, but in reality can be quite complex. In addition, the lack of a unified nomenclature on this subject makes it increasingly difficult to properly build, test, and use techniques and tools built around these constructs. This document provides definitions for the terms 'Capacity' and 'AvailableCapacity' related to IP traffic traveling between a source and destination in an IP network. By doing so, we hope to provide a common framework for the discussion and analysis of a diverse set of current and future estimation techniques. |
|
| |
| RFC 5137 | ASCII Escaping of Unicode Characters |
| |
|
|
There are a number of circumstances in which an escape mechanism is needed in conjunction with a protocol to encode characters that cannot be represented or transmitted directly. With ASCII coding, the traditional escape has been either the decimal or hexadecimal numeric value of the character, written in a variety of different ways. The move to Unicode, where characters occupy two or more octets and may be coded in several different forms, has further complicated the question of escapes. This document discusses some options now in use and discusses considerations for selecting one for use in new IETF protocols, and protocols that are now being internationalized. |
|
| |
| RFC 5138 | A Uniform Resource Name (URN) Namespace for the Commission for the Management and Application of Geoscience Information (CGI) |
| |
| Authors: | S. Cox. |
| Date: | February 2008 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5138 |
|
This document describes a URN (Uniform Resource Name) namespace that is engineered by the Commission for the Management and Application ofGeoscience Information (CGI) for naming (i) persistent resources published by the CGI and (ii) resources published by organizations that wish them to be used in the context of services conforming to protocols and agreements issued by CGI. The formal NamespaceIdentifier (NID) is "cgi". |
|
| |
| RFC 5139 | Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO) |
| |
| Authors: | M. Thomson, J. Winterbottom. |
| Date: | February 2008 |
| Formats: | txt json html |
| Updates: | RFC 4119 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5139 |
|
This document defines an XML format for the representation of civic location. This format is designed for use with Presence InformationData Format Location Object (PIDF-LO) documents and replaces the civic location format in RFC 4119. The format is based on the civic address definition in PIDF-LO, but adds several new elements based on the civic types defined for Dynamic Host Configuration Protocol(DHCP), and adds a hierarchy to address complex road identity schemes. The format also includes support for the xml:lang language tag and restricts the types of elements where appropriate. |
|
| |
| RFC 5140 | A Telephony Gateway REgistration Protocol (TGREP) |
| |
| Authors: | M. Bangalore, R. Kumar, J. Rosenberg, H. Salama, D.N. Shah. |
| Date: | March 2008 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5140 |
|
This document describes the Telephony Gateway Registration Protocol(TGREP) for registration of telephony prefixes supported by telephony gateways and soft switches. The registration mechanism can also be used to export resource information. The prefix and resource information can then be passed on to a Telephony Routing over IP(TRIP) Location Server, which in turn can propagate that routing information within and between Internet Telephony AdministrativeDomains (ITADs). TGREP shares a lot of similarities with the TRIP protocol. It has similar procedures and finite state machine for session establishment. It also shares the same format for messages and a subset of attributes with TRIP. |
|
| |
| RFC 5141 | A Uniform Resource Name (URN) Namespace for the International Organization for Standardization (ISO) |
| |
| Authors: | J. Goodwin, H. Apel. |
| Date: | March 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5141 |
|
This document describes a Uniform Resource Name NamespaceIdentification (URN NID) for the International Organization forStandardization (ISO). This URN NID is intended for use for the identification of persistent resources published by the ISO standards body (including documents, document metadata, extracted resources such as standard schemata and standard value sets, and other resources). |
|
| |
| RFC 5142 | Mobility Header Home Agent Switch Message |
| |
| Authors: | B. Haley, V. Devarapalli, H. Deng, J. Kempf. |
| Date: | January 2008 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5142 |
|
This document specifies a new Mobility Header message type that can be used between a home agent and mobile node to signal to a mobile node that it should acquire a new home agent. |
|
| |
| RFC 5143 | Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation Service over MPLS (CEM) Encapsulation |
| |
| Authors: | A. Malis, J. Brayley, J. Shirron, L. Martini, S. Vogelsang. |
| Date: | February 2008 |
| Formats: | txt json html |
| Obsoleted by: | RFC 4842 |
| Status: | HISTORIC |
| DOI: | 10.17487/RFC 5143 |
|
This document describes a historical method for encapsulatingSynchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH)Path signals for transport across packet-switched networks (PSNs).The PSNs explicitly supported by this document include MPLS and IP.Note that RFC 4842 describes the standards-track protocol for this functionality, and new implementations must use RFC 4842 rather than this document except when interoperability with older implementations is desired. |
|
| |
| RFC 5144 | A Domain Availability Check (DCHK) Registry Type for the Internet Registry Information Service (IRIS) |
| |
| Authors: | A. Newton, M. Sanz. |
| Date: | February 2008 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5144 |
|
This document describes a lightweight domain availability service using the Internet Registry Information Service (IRIS) framework and the data model of the IRIS Domain Registry (DREG) service. |
|
| |
| RFC 5145 | Framework for MPLS-TE to GMPLS Migration |
| |
| Authors: | K. Shiomoto, Ed.. |
| Date: | March 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5145 |
|
The migration from Multiprotocol Label Switching (MPLS) TrafficEngineering (TE) to Generalized MPLS (GMPLS) is the process of evolving an MPLS-TE control plane to a GMPLS control plane. An appropriate migration strategy will be selected based on various factors including the service provider's network deployment plan, customer demand, and operational policy.
This document presents several migration models and strategies for migrating from MPLS-TE to GMPLS. In the course of migration, MPLS-TE and GMPLS devices, or networks, may coexist that may require interworking between MPLS-TE and GMPLS protocols. Aspects of the required interworking are discussed as it will influence the choice of a migration strategy. This framework document provides a migration toolkit to aid the operator in selection of an appropriate strategy.
This framework document also lists a set of solutions that may aid in interworking, and highlights a set of potential issues. |
|
| |
| RFC 5146 | Interworking Requirements to Support Operation of MPLS-TE over GMPLS Networks |
| |
| Authors: | K. Kumaki, Ed.. |
| Date: | March 2008 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5146 |
|
Operation of a Multiprotocol Label Switching (MPLS) traffic engineering (TE) network as a client network to a Generalized MPLS(GMPLS) network has enhanced operational capabilities compared to those provided by a coexistent protocol model (i.e., operation ofMPLS-TE over an independently managed transport layer).
The GMPLS network may be a packet or a non-packet network, and may itself be a multi-layer network supporting both packet and non-packet technologies. An MPLS-TE Label Switched Path (LSP) originates and terminates on an MPLS Label Switching Router (LSR). The GMPLS network provides transparent transport for the end-to-end MPLS-TELSP.
This document describes a framework and Service Provider requirements for operating MPLS-TE networks over GMPLS networks. |
|
| |
| RFC 5147 | URI Fragment Identifiers for the text/plain Media Type |
| |
|
|
This memo defines URI fragment identifiers for text/plain MIME entities. These fragment identifiers make it possible to refer to parts of a text/plain MIME entity, either identified by character position or range, or by line position or range. Fragment identifiers may also contain information for integrity checks to make them more robust. |
|
| |
| RFC 5148 | Jitter Considerations in Mobile Ad Hoc Networks (MANETs) |
| |
| Authors: | T. Clausen, C. Dearlove, B. Adamson. |
| Date: | February 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5148 |
|
This document provides recommendations for jittering (randomly modifying timing) of control traffic transmissions in Mobile Ad hocNETwork (MANET) routing protocols to reduce the probability of transmission collisions. |
|
| |
| RFC 5149 | Service Selection for Mobile IPv6 |
| |
| Authors: | J. Korhonen, U. Nilsson, V. Devarapalli. |
| Date: | February 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5149 |
|
In some Mobile IPv6 deployments, identifying the mobile node or the mobility service subscriber is not enough to distinguish between multiple services possibly provisioned to the said mobile node and its mobility service subscription. A capability to specify different services in addition to the mobile node identity can be leveraged to provide flexibility for mobility service providers on provisioning multiple services to one mobility service subscription. This document describes a Service Selection Mobility Option for both conventional Mobile IPv6 and Proxy Mobile IPv6 that is intended to assist home agents to make a specific service selection for the mobility service subscription during the binding registration procedure. |
|
| |
| RFC 5150 | Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE) |
| |
| Authors: | A. Ayyangar, K. Kompella, JP. Vasseur, A. Farrel. |
| Date: | February 2008 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5150 |
|
In certain scenarios, there may be a need to combine severalGeneralized Multiprotocol Label Switching (GMPLS) Label SwitchedPaths (LSPs) such that a single end-to-end (e2e) LSP is realized and all traffic from one constituent LSP is switched onto the next LSP.We will refer to this as "LSP stitching", the key requirement being that a constituent LSP not be allocated to more than one e2e LSP.The constituent LSPs will be referred to as "LSP segments" (S-LSPs).
This document describes extensions to the existing GMPLS signaling protocol (Resource Reservation Protocol-Traffic Engineering (RSVP-TE)) to establish e2e LSPs created from S-LSPs, and describes how theLSPs can be managed using the GMPLS signaling and routing protocols.
It may be possible to configure a GMPLS node to switch the traffic from an LSP for which it is the egress, to another LSP for which it is the ingress, without requiring any signaling or routing extensions whatsoever and such that the operation is completely transparent to other nodes. This will also result in LSP stitching in the data plane. However, this document does not cover this scenario of LSP stitching. |
|
| |
| RFC 5151 | Inter-Domain MPLS and GMPLS Traffic Engineering -- Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions |
| |
|
|
This document describes procedures and protocol extensions for the use of Resource Reservation Protocol-Traffic Engineering (RSVP-TE) signaling in Multiprotocol Label Switching-Traffic Engineering(MPLS-TE) packet networks and Generalized MPLS (GMPLS) packet and non-packet networks to support the establishment and maintenance ofLabel Switched Paths that cross domain boundaries.
For the purpose of this document, a domain is considered to be any collection of network elements within a common realm of address space or path computation responsibility. Examples of such domains includeAutonomous Systems, Interior Gateway Protocol (IGP) routing areas, and GMPLS overlay networks. |
|
| |
| RFC 5152 | A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs) |
| |
| Authors: | JP. Vasseur, Ed., A. Ayyangar, Ed., R. Zhang. |
| Date: | February 2008 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5152 |
|
This document specifies a per-domain path computation technique for establishing inter-domain Traffic Engineering (TE) MultiprotocolLabel Switching (MPLS) and Generalized MPLS (GMPLS) Label SwitchedPaths (LSPs). In this document, a domain refers to a collection of network elements within a common sphere of address management or path computational responsibility such as Interior Gateway Protocol (IGP) areas and Autonomous Systems.
Per-domain computation applies where the full path of an inter-domainTE LSP cannot be or is not determined at the ingress node of the TELSP, and is not signaled across domain boundaries. This is most likely to arise owing to TE visibility limitations. The signaling message indicates the destination and nodes up to the next domain boundary. It may also indicate further domain boundaries or domain identifiers. The path through each domain, possibly including the choice of exit point from the domain, must be determined within the domain. |
|
| |
| RFC 5153 | IP Flow Information Export (IPFIX) Implementation Guidelines |
| |
| Authors: | E. Boschi, L. Mark, J. Quittek, M. Stiemerling, P. Aitken. |
| Date: | April 2008 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5153 |
|
The IP Flow Information Export (IPFIX) protocol defines how IP Flow information can be exported from routers, measurement probes, or other devices. This document provides guidelines for the implementation and use of the IPFIX protocol. Several sets of guidelines address Template management, transport-specific issues, implementation of Exporting and Collecting Processes, and IPFIX implementation on middleboxes (such as firewalls, network address translators, tunnel endpoints, packet classifiers, etc.). |
|
| |
| RFC 5154 | IP over IEEE 802.16 Problem Statement and Goals |
| |
| Authors: | J. Jee, Ed., S. Madanapalli, J. Mandin. |
| Date: | April 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5154 |
|
This document specifies problems in running IP over IEEE 802.16 networks by identifying specific gaps in the IEEE 802.16 Media AccessControl (MAC) for IPv4 and IPv6 support. This document also provides an overview of IEEE 802.16 network characteristics and convergence sublayers. Common terminology used for the base guideline while defining the solution framework is also presented. |
|
| |
| RFC 5155 | DNS Security (DNSSEC) Hashed Authenticated Denial of Existence |
| |
|
|
The Domain Name System Security (DNSSEC) Extensions introduced theNSEC resource record (RR) for authenticated denial of existence.This document introduces an alternative resource record, NSEC3, which similarly provides authenticated denial of existence. However, it also provides measures against zone enumeration and permits gradual expansion of delegation-centric zones. |
|
| |
| RFC 5156 | Special-Use IPv6 Addresses |
| |
|
|
This document is a compilation of special IPv6 addresses defined in other RFCs. It can be used as a checklist of invalid routing prefixes for developing filtering policies for routes and IP packets.It does not discuss addresses that are assigned to operators and users through the Regional Internet Registries. |
|
| |
| RFC 5157 | IPv6 Implications for Network Scanning |
| |
|
|
The much larger default 64-bit subnet address space of IPv6 should in principle make traditional network (port) scanning techniques used by certain network worms or scanning tools less effective. While traditional network scanning probes (whether by individuals or automated via network worms) may become less common, administrators should be aware that attackers may use other techniques to discoverIPv6 addresses on a target network, and thus they should also be aware of measures that are available to mitigate them. This informational document discusses approaches that administrators could take when planning their site address allocation and management strategies as part of a defence-in-depth approach to network security. |
|
| |
| RFC 5158 | 6to4 Reverse DNS Delegation Specification |
| |
|
|
This memo describes the service mechanism for entering a delegation of DNS servers that provide reverse lookup of 6to4 IPv6 addresses into the 6to4 reverse zone file. The mechanism is based on a conventional DNS delegation service interface, allowing the service client to enter the details of a number of DNS servers for the delegated domain. In the context of a 6to4 reverse delegation, the client is primarily authenticated by its source address used in the delegation request, and is authorized to use the function if its IPv6 address prefix corresponds to an address from within the requested6to4 delegation address block. |
|
| |
| RFC 5159 | Session Description Protocol (SDP) Attributes for Open Mobile Alliance (OMA) Broadcast (BCAST) Service and Content Protection |
| |
| Authors: | L. Dondeti, Ed., A. Jerichow. |
| Date: | March 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5159 |
|
This document provides descriptions of Session Description Protocol(SDP) attributes used by the Open Mobile Alliance's Broadcast Service and Content Protection specification. |
|
| |
| RFC 5160 | Considerations of Provider-to-Provider Agreements for Internet-Scale Quality of Service (QoS) |
| |
| Authors: | P. Levis, M. Boucadair. |
| Date: | March 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5160 |
|
This memo analyzes provider-to-provider Quality of Service (QoS) agreements suitable for a global QoS-enabled Internet. It defines terminology relevant to inter-domain QoS models. It proposes a new concept denoted by Meta-QoS-Class (MQC). This concept could potentially drive and federate the way QoS inter-domain relationships are built between providers. It opens up new perspectives for a QoS- enabled Internet that retains, as much as possible, the openness of the existing best-effort Internet. |
|
| |
| RFC 5161 | The IMAP ENABLE Extension |
| |
| Authors: | A. Gulbrandsen, Ed., A. Melnikov, Ed.. |
| Date: | March 2008 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5161 |
|
Most IMAP extensions are used by the client when it wants to and the server supports it. However, a few extensions require the server to know whether a client supports that extension. The ENABLE extension allows an IMAP client to say which extensions it supports. |
|
| |
| RFC 5162 | IMAP4 Extensions for Quick Mailbox Resynchronization |
| |
| Authors: | A. Melnikov, D. Cridland, C. Wilson. |
| Date: | March 2008 |
| Formats: | txt json html |
| Obsoleted by: | RFC 7162 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5162 |
|
This document defines an IMAP4 extension, which gives an IMAP client the ability to quickly resynchronize any previously opened mailbox as part of the SELECT command, without the need for server-side state or additional client round-trips. This extension also introduces a new response that allows for a more compact representation of a list of expunged messages (and always includes the Unique Identifiers (UIDs) expunged). |
|
| |
| RFC 5163 | Extension Formats for Unidirectional Lightweight Encapsulation (ULE) and the Generic Stream Encapsulation (GSE) |
| |
| Authors: | G. Fairhurst, B. Collini-Nocker. |
| Date: | April 2008 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5163 |
|
This document describes a set of Extension Headers for theUnidirectional Lightweight Encapsulation (ULE), RFC 4326.
The Extension Header formats specified in this document define extensions appropriate to both ULE and the Generic StreamEncapsulation (GSE) for the second-generation framing structure defined by the Digital Video Broadcasting (DVB) family of specifications. |
|
| |
| RFC 5164 | Mobility Services Transport: Problem Statement |
| |
| Authors: | T. Melia, Ed.. |
| Date: | March 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5164 |
|
There are ongoing activities in the networking community to develop solutions that aid in IP handover mechanisms between heterogeneous wired and wireless access systems including, but not limited to, IEEE802.21. Intelligent access selection, taking into account link-layer attributes, requires the delivery of a variety of different information types to the terminal from different sources within the network and vice-versa. The protocol requirements for this signalling have both transport and security issues that must be considered. The signalling must not be constrained to specific link types, so there is at least a common component to the signalling problem, which is within the scope of the IETF. This document presents a problem statement for this core problem. |
|
| |
| RFC 5165 | A Uniform Resource Name (URN) Namespace for the Open Geospatial Consortium (OGC) |
| |
| Authors: | C. Reed. |
| Date: | April 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5165 |
|
This document describes a Uniform Resource Name (URN) namespace that is engineered by the Open Geospatial Consortium (OGC) for naming persistent resources published by the OGC. The formal NamespaceIDentifier (NID) is "ogc". |
|
| |
| RFC 5166 | Metrics for the Evaluation of Congestion Control Mechanisms |
| |
| Authors: | S. Floyd, Ed.. |
| Date: | March 2008 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5166 |
|
This document discusses the metrics to be considered in an evaluation of new or modified congestion control mechanisms for the Internet.These include metrics for the evaluation of new transport protocols, of proposed modifications to TCP, of application-level congestion control, and of Active Queue Management (AQM) mechanisms in the router. This document is the first in a series of documents aimed at improving the models that we use in the evaluation of transport protocols.
This document is a product of the Transport Modeling Research Group(TMRG), and has received detailed feedback from many members of theResearch Group (RG). As the document tries to make clear, there is not necessarily a consensus within the research community (or theIETF community, the vendor community, the operations community, or any other community) about the metrics that congestion control mechanisms should be designed to optimize, in terms of trade-offs between throughput and delay, fairness between competing flows, and the like. However, we believe that there is a clear consensus that congestion control mechanisms should be evaluated in terms of trade- offs between a range of metrics, rather than in terms of optimizing for a single metric. |
|
| |
| RFC 5167 | Media Server Control Protocol Requirements |
| |
| Authors: | M. Dolly, R. Even. |
| Date: | March 2008 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5167 |
|
This document addresses the communication between an application server and media server. The current work in IETF working groups shows these logical entities, but it does not address the physical decomposition and the protocol between the entities.
This document presents the requirements for a Media Server ControlProtocol (MCP) that enables an application server to use a media server. It will address the aspects of announcements, InteractiveVoice Response, and conferencing media services. |
|
| |
| RFC 5168 | XML Schema for Media Control |
| |
| Authors: | O. Levin, R. Even, P. Hagendorf. |
| Date: | March 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5168 |
|
This document defines an Extensible Markup Language (XML) Schema for video fast update in a tightly controlled environment, developed byMicrosoft, Polycom, Radvision and used by multiple vendors. This document describes a method that has been deployed in SessionInitiation Protocol (SIP) based systems over the last three years and is being used across real-time interactive applications from different vendors in an interoperable manner. New implementations are discouraged from using the method described except for backward compatibility purposes. New implementations are required to use the new Full Intra Request command in the RTP Control Protocol (RTCP) channel. |
|
| |
| RFC 5169 | Handover Key Management and Re-Authentication Problem Statement |
| |
| Authors: | T. Clancy, M. Nakhjiri, V. Narayanan, L. Dondeti. |
| Date: | March 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5169 |
|
This document describes the Handover Keying (HOKEY) re-authentication problem statement. The current Extensible Authentication Protocol(EAP) keying framework is not designed to support re-authentication and handovers without re-executing an EAP method. This often causes unacceptable latency in various mobile wireless environments. This document details the problem and defines design goals for a generic mechanism to reuse derived EAP keying material for handover. |
|
| |
| RFC 5170 | Low Density Parity Check (LDPC) Staircase and Triangle Forward Error Correction (FEC) Schemes |
| |
| Authors: | V. Roca, C. Neumann, D. Furodet. |
| Date: | June 2008 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5170 |
|
This document describes two Fully-Specified Forward Error Correction(FEC) Schemes, Low Density Parity Check (LDPC) Staircase and LDPCTriangle, and their application to the reliable delivery of data objects on the packet erasure channel (i.e., a communication path where packets are either received without any corruption or discarded during transmission). These systematic FEC codes belong to the well- known class of "Low Density Parity Check" codes, and are large blockFEC codes in the sense of RFC 3453. |
|
| |
| RFC 5171 | Cisco Systems UniDirectional Link Detection (UDLD) Protocol |
| |
| Authors: | M. Foschiano. |
| Date: | April 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5171 |
|
This document describes a Cisco Systems protocol that can be used to detect and disable unidirectional Ethernet fiber or copper links caused, for instance, by mis-wiring of fiber strands, interface malfunctions, media converters' faults, etc. It operates at Layer 2 in conjunction with IEEE 802.3's existing Layer 1 fault detection mechanisms.
This document explains the protocol objectives and applications, illustrates the specific premises the protocol was based upon, and describes the protocol architecture and related deployment issues to serve as a possible base for future standardization. |
|
| |
| RFC 5172 | Negotiation for IPv6 Datagram Compression Using IPv6 Control Protocol |
| |
|
|
The Point-to-Point Protocol (PPP) provides a standard method of encapsulating network-layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols.
The IPv6 Control Protocol (IPV6CP), which is an NCP for a PPP link, allows for the negotiation of desirable parameters for an IPv6 interface over PPP.
This document defines the IPv6 datagram compression option that can be negotiated by a node on the link through the IPV6CP. |
|
| |
| RFC 5173 | Sieve Email Filtering: Body Extension |
| |
|
|
This document defines a new command for the "Sieve" email filtering language that tests for the occurrence of one or more strings in the body of an email message. |
|
| |
| RFC 5174 | A Uniform Resource Name (URN) Namespace for the European Broadcasting Union (EBU) |
| |
| Authors: | J-P. Evain. |
| Date: | May 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5174 |
|
This document describes a Uniform Resource Name (URN) namespace for the European Broadcasting Union (EBU) for naming persistent resources defined within EBU technical documentation and Internet resources.Example resources include technical documents and specifications, eXtensible Markup Language (XML) Schemas, classification schemes, XMLDocument Type Definitions (DTDs), namespaces, style sheets, media assets, and other types of resources produced or managed by the EBU. |
|
| |
| RFC 5175 | IPv6 Router Advertisement Flags Option |
| |
| Authors: | B. Haberman, Ed., R. Hinden. |
| Date: | March 2008 |
| Formats: | txt html json |
| Obsoletes: | RFC 5075 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5175 |
|
The IPv6 Neighbor Discovery's Router Advertisement message contains an 8-bit field reserved for single-bit flags. Several protocols have reserved flags in this field and others are preparing to reserve a sufficient number of flags to exhaust the field. This document defines an option to the Router Advertisement message that expands the number of flag bits available. |
|
| |
| RFC 5176 | Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS) |
| |
| Authors: | M. Chiba, G. Dommety, M. Eklund, D. Mitton, B. Aboba. |
| Date: | January 2008 |
| Formats: | txt json html |
| Obsoletes: | RFC 3576 |
| Updated by: | RFC 8559 |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5176 |
|
This document describes a currently deployed extension to the RemoteAuthentication Dial In User Service (RADIUS) protocol, allowing dynamic changes to a user session, as implemented by network access server products. This includes support for disconnecting users and changing authorizations applicable to a user session. |
|
| |
| RFC 5177 | Network Mobility (NEMO) Extensions for Mobile IPv4 |
| |
| Authors: | K. Leung, G. Dommety, V. Narayanan, A. Petrescu. |
| Date: | April 2008 |
| Formats: | txt json html |
| Updated by: | RFC 6626 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5177 |
|
This document describes a protocol for supporting Mobile Networks between a Mobile Router and a Home Agent by extending the Mobile IPv4 protocol. A Mobile Router is responsible for the mobility of one or more network segments or subnets moving together. The Mobile Router hides its mobility from the nodes on the Mobile Network. The nodes on the Mobile Network may be fixed in relationship to the MobileRouter and may not have any mobility function.
Extensions to Mobile IPv4 are introduced to support Mobile Networks. |
|
| |
| RFC 5178 | Generic Security Service Application Program Interface (GSS-API) Internationalization and Domain-Based Service Names and Name Type |
| |
| Authors: | N. Williams, A. Melnikov. |
| Date: | May 2008 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5178 |
|
This document describes domain-name-based service principal names and the corresponding name type for the Generic Security ServiceApplication Programming Interface (GSS-API). Internationalization of the GSS-API is also covered.
Domain-based service names are similar to host-based service names, but using a domain name (not necessarily an Internet domain name) in addition to a hostname. The primary purpose of domain-based names is to provide a measure of protection to applications that utilize insecure service discovery protocols. This is achieved by providing a way to name clustered services after the "domain" which they service, thereby allowing their clients to authorize the service's servers based on authentication of their service names. |
|
| |
| RFC 5179 | Generic Security Service Application Program Interface (GSS-API) Domain-Based Service Names Mapping for the Kerberos V GSS Mechanism |
| |
| Authors: | N. Williams. |
| Date: | May 2008 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5179 |
|
This document describes the mapping of Generic Security ServiceApplication Program Interface (GSS-API) domain-name-based service principal names onto Kerberos V principal names. |
|
| |
| RFC 5180 | IPv6 Benchmarking Methodology for Network Interconnect Devices |
| |
| Authors: | C. Popoviciu, A. Hamza, G. Van de Velde, D. Dugatkin. |
| Date: | May 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5180 |
|
The benchmarking methodologies defined in RFC 2544 are IP version independent. However, RFC 2544 does not address some of the specificities of IPv6. This document provides additional benchmarking guidelines, which in conjunction with RFC 2544, lead to a more complete and realistic evaluation of the IPv6 performance of network interconnect devices. IPv6 transition mechanisms are outside the scope of this document. |
|
| |
| RFC 5181 | IPv6 Deployment Scenarios in 802.16 Networks |
| |
| Authors: | M-K. Shin, Ed., Y-H. Han, S-E. Kim, D. Premec. |
| Date: | May 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5181 |
|
This document provides a detailed description of IPv6 deployment and integration methods and scenarios in wireless broadband access networks in coexistence with deployed IPv4 services. In this document, we will discuss the main components of IPv6 IEEE 802.16 access networks and their differences from IPv4 IEEE 802.16 networks and how IPv6 is deployed and integrated in each of the IEEE 802.16 technologies. |
|
| |
| RFC 5182 | IMAP Extension for Referencing the Last SEARCH Result |
| |
|
|
Many IMAP clients use the result of a SEARCH command as the input to perform another operation, for example, fetching the found messages, deleting them, or copying them to another mailbox.
This can be achieved using standard IMAP operations described in RFC3501; however, this would be suboptimal. The server will send the list of found messages to the client; after that, the client will have to parse the list, reformat it, and send it back to the server.The client can't pipeline the SEARCH command with the subsequent command, and, as a result, the server might not be able to perform some optimizations.
This document proposes an IMAP extension that allows a client to tell a server to use the result of a SEARCH (or Unique Identifier (UID)SEARCH) command as an input to any subsequent command. |
|
| |
| RFC 5183 | Sieve Email Filtering: Environment Extension |
| |
| Authors: | N. Freed. |
| Date: | May 2008 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5183 |
|
This document describes the "environment" extension to the Sieve email filtering language. The "environment" extension gives a Sieve script access to information about the Sieve interpreter itself, where it is running, and about any transport connection currently involved in transferring the message. |
|
| |
| RFC 5184 | Unified Layer 2 (L2) Abstractions for Layer 3 (L3)-Driven Fast Handover |
| |
| Authors: | F. Teraoka, K. Gogo, K. Mitsuya, R. Shibui, K. Mitani. |
| Date: | May 2008 |
| Formats: | txt html json |
| Status: | EXPERIMENTAL |
| DOI: | 10.17487/RFC 5184 |
|
This document proposes unified Layer 2 (L2) abstractions for Layer 3(L3)-driven fast handovers. For efficient network communication, it is vital for a protocol layer to know or utilize other layers' information, such as the form of L2 triggers. However, each protocol layer is basically designed independently. Since each protocol layer is also implemented independently in current operating systems, it is very hard to exchange control information between protocol layers.This document defines nine kinds of L2 abstractions in the form of"primitives" to achieve fast handovers in the network layer as a means of solving the problem. This mechanism is called "L3-driven fast handovers" because the network layer initiates L2 and L3 handovers by using the primitives. This document is a product of theIP Mobility Optimizations (MobOpts) Research Group. |
|
| |
| RFC 5185 | OSPF Multi-Area Adjacency |
| |
| Authors: | S. Mirtorabi, P. Psenak, A. Lindem, Ed., A. Oswal. |
| Date: | May 2008 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5185 |
|
This document describes an extension to the Open Shortest Path First(OSPF) protocol to allow a single physical link to be shared by multiple areas. This is necessary to allow the link to be considered an intra-area link in multiple areas. This would create an intra- area path in each of the corresponding areas sharing the same link. |
|
| |
| RFC 5186 | Internet Group Management Protocol Version 3 (IGMPv3) / Multicast Listener Discovery Version 2 (MLDv2) and Multicast Routing Protocol Interaction |
| |
| Authors: | B. Haberman, J. Martin. |
| Date: | May 2008 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5186 |
|
The definitions of the Internet Group Management Protocol Version 3(IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) require new behavior within the multicast routing protocols. The additional source information contained in IGMPv3 and MLDv2 messages necessitates that multicast routing protocols manage and utilize the information. This document describes how multicast routing protocols will interact with these source-filtering group management protocols. |
|
| |
| RFC 5187 | OSPFv3 Graceful Restart |
| |
| Authors: | P. Pillay-Esnault, A. Lindem. |
| Date: | June 2008 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5187 |
|
This document describes the OSPFv3 graceful restart. The OSPFv3 graceful restart is identical to that of OSPFv2 except for the differences described in this document. These differences include the format of the grace Link State Advertisements (LSAs) and other considerations. |
|
| |
| RFC 5188 | RTP Payload Format for the Enhanced Variable Rate Wideband Codec (EVRC-WB) and the Media Subtype Updates for EVRC-B Codec |
| |
|
|
This document specifies Real-time Transport Protocol (RTP) payload formats to be used for the Enhanced Variable Rate Wideband Codec(EVRC-WB) and updates the media type registrations for EVRC-B codec.Several media type registrations are included for EVRC-WB RTP payload formats. In addition, a file format is specified for transport ofEVRC-WB speech data in storage mode applications such as email. |
|
| |
| RFC 5189 | Middlebox Communication (MIDCOM) Protocol Semantics |
| |
| Authors: | M. Stiemerling, J. Quittek, T. Taylor. |
| Date: | March 2008 |
| Formats: | txt html json |
| Obsoletes: | RFC 3989 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5189 |
|
This document specifies semantics for a Middlebox Communication(MIDCOM) protocol to be used by MIDCOM agents for interacting with middleboxes such as firewalls and Network Address Translators (NATs).The semantics discussion does not include any specification of a concrete syntax or a transport protocol. However, a concrete protocol is expected to implement the specified semantics or, more likely, a superset of it. The MIDCOM protocol semantics is derived from the MIDCOM requirements, from the MIDCOM framework, and from working group decisions. This document obsoletes RFC 3989. |
|
| |
| RFC 5190 | Definitions of Managed Objects for Middlebox Communication |
| |
| Authors: | J. Quittek, M. Stiemerling, P. Srisuresh. |
| Date: | March 2008 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5190 |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community.In particular, it describes a set of managed objects that allow configuring middleboxes, such as firewalls and network address translators, in order to enable communication across these devices.The definitions of managed objects in this documents follow closely the MIDCOM semantics defined in RFC 5189. |
|
| |
| RFC 5191 | Protocol for Carrying Authentication for Network Access (PANA) |
| |
| Authors: | D. Forsberg, Y. Ohba, Ed., B. Patil, H. Tschofenig, A. Yegin. |
| Date: | May 2008 |
| Formats: | txt html json |
| Updated by: | RFC 5872 |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5191 |
|
This document defines the Protocol for Carrying Authentication forNetwork Access (PANA), a network-layer transport for ExtensibleAuthentication Protocol (EAP) to enable network access authentication between clients and access networks. In EAP terms, PANA is aUDP-based EAP lower layer that runs between the EAP peer and the EAP authenticator. |
|
| |
| RFC 5192 | DHCP Options for Protocol for Carrying Authentication for Network Access (PANA) Authentication Agents |
| |
| Authors: | L. Morand, A. Yegin, S. Kumar, S. Madanapalli. |
| Date: | May 2008 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5192 |
|
This document defines new DHCPv4 and DHCPv6 options that contain a list of IP addresses to locate one or more PANA (Protocol for carrying Authentication for Network Access) Authentication Agents(PAAs). This is one of the methods that a PANA Client (PaC) can use to locate PAAs. |
|
| |
| RFC 5193 | Protocol for Carrying Authentication for Network Access (PANA) Framework |
| |
| Authors: | P. Jayaraman, R. Lopez, Y. Ohba, Ed., M. Parthasarathy, A. Yegin. |
| Date: | May 2008 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5193 |
|
This document defines the general Protocol for CarryingAuthentication for Network Access (PANA) framework functional elements, high-level call flow, and deployment environments. |
|
| |
| RFC 5194 | Framework for Real-Time Text over IP Using the Session Initiation Protocol (SIP) |
| |
| Authors: | A. van Wijk, Ed., G. Gybels, Ed.. |
| Date: | June 2008 |
| Formats: | txt html json |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5194 |
|
This document lists the essential requirements for real-time Text- over-IP (ToIP) and defines a framework for implementation of all required functions based on the Session Initiation Protocol (SIP) and the Real-Time Transport Protocol (RTP). This includes interworking between Text-over-IP and existing text telephony on the PublicSwitched Telephone Network (PSTN) and other networks. |
|
| |
| RFC 5195 | BGP-Based Auto-Discovery for Layer-1 VPNs |
| |
| Authors: | H. Ould-Brahim, D. Fedyk, Y. Rekhter. |
| Date: | June 2008 |
| Formats: | txt html json |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5195 |
|
The purpose of this document is to define a BGP-based auto-discovery mechanism for Layer-1 VPNs (L1VPNs). The auto-discovery mechanism for L1VPNs allows the provider network devices to dynamically discover the set of Provider Edges (PEs) having ports attached toCustomer Edge (CE) members of the same VPN. That information is necessary for completing the signaling phase of L1VPN connections.One main objective of a L1VPN auto-discovery mechanism is to support the "single-end provisioning" model, where addition of a new port to a given L1VPN would involve configuration changes only on the PE that has this port and on the CE that is connected to the PE via this port. |
|
| |
| RFC 5196 | Session Initiation Protocol (SIP) User Agent Capability Extension to Presence Information Data Format (PIDF) |
| |
| Authors: | M. Lonnfors, K. Kiss. |
| Date: | September 2008 |
| Formats: | txt json html |
| Status: | PROPOSED STANDARD |
| DOI: | 10.17487/RFC 5196 |
|
Presence Information Data Format (PIDF) defines a common presence data format for Common Profile for Presence (CPP) compliant presence protocols. This memo defines a PIDF extension to represent SIP UserAgent capabilities. |
|
| |
| RFC 5197 | On the Applicability of Various Multimedia Internet KEYing (MIKEY) Modes and Extensions |
| |
| Authors: | S. Fries, D. Ignjatic. |
| Date: | June 2008 |
| Formats: | txt json html |
| Status: | INFORMATIONAL |
| DOI: | 10.17487/RFC 5197 |
|
Multimedia Internet Keying (MIKEY) is a key management protocol that can be used for real-time applications. In particular, it has been defined focusing on the support of the Secure Real-time TransportProtocol (SRTP). MIKEY itself is standardized within RFC 3830 and defines four key distribution methods. Moreover, it is defined to allow extensions of the protocol. As MIKEY becomes more and more accepted, extensions to the base protocol arise, especially in terms of additional key distribution methods but also in terms of payload enhancements.
This document provides an overview about the MIKEY base document in general as well as the existing extensions for MIKEY, which have been defined or are in the process of definition. It is intended as an additional source of information for developers or architects to provide more insight in use case scenarios and motivations as well as advantages and disadvantages for the different key distribution schemes. The use cases discussed in this document are strongly related to dedicated SIP call scenarios providing challenges for key management in general, among them media before Session DescriptionProtocol (SDP) answer, forking, and shared key conferencing. |
|
| |
| RFC 5198 | Unicode Format for Network Interchange |
| |
|
|
The Internet today is in need of a standardized form for the transmission of internationalized "text" information, paralleling the specifications for the use of ASCII that date from the early days of the ARPANET. This document specifies that format, using UTF-8 with normalization and specific line-ending sequences. |
|
