| |
|
| |
| | Reserved IPv6 Interface Identifiers |
| |
|
Interface Identifiers in IPv6 unicast addresses are used to identify interfaces on a link. They are required to be unique within a subnet. Several RFCs have specified interface identifiers or identifier ranges that have a special meaning attached to them. An IPv6 node autoconfiguring an interface identifier in these ranges will encounter unexpected consequences. Since there is no centralized repository for such reserved identifiers, this document aims to create one. |
| | RTP Payload Format for Adaptive TRansform Acoustic Coding (ATRAC) Family |
| |
|
This document describes an RTP payload format for efficient and flexible transporting of audio data encoded with the Adaptive TRansform Audio Coding (ATRAC) family of codecs. Recent enhancements to the ATRAC family of codecs support high quality audio coding with multiple channels. The RTP payload format as presented in this document also includes support for data fragmentation, elementary redundancy measures, and a variation on scalable streaming. |
| | IMAP4 extension for named searches (filters) |
| |
| | draft-melnikov-imapext-filters-07.txt |
| | Date: |
02/12/2008 |
| | Authors: |
Alexey Melnikov, Curtis King |
| | Working Group: |
Enhancements to Internet email to Support Diverse Service Environments (lemonade) |
| | Formats: |
txt |
|
The document defines a way to persistently store named IMAP (RFC 3501) searches on the server. Such named searches can be subsequently referenced in a SEARCH or any other command that accepts a search criterion as a parameter. |
| | Tags for Identifying Languages |
| |
|
This document describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object. It also describes how to register values for use in language tags and the creation of user-defined extensions for private interchange. |
| | Multicast Ping Protocol |
| |
|
The Multicast Ping Protocol specified in this document allows for checking whether an endpoint can receive multicast, both Source- Specific Multicast (SSM) and Any-Source Multicast (ASM). It can also be used to obtain additional multicast-related information such as multicast tree setup time. This protocol is based on an implementation of tools called ssmping and asmping. |
| | An Analysis of Scaling Issues in MPLS-TE Core Networks |
| |
|
Traffic engineered Multiprotocol Label Switching (MPLS-TE) is deployed in providers' core networks. As providers plan to grow these networks, they need to understand whether existing protocols and implementations can support the network sizes that they are planning. This document presents an analysis of some of the scaling concerns for the number of Label Switching Paths (LSPs) in MPLS-TE core networks, and examines the value of two techniques (LSP hierarchies, and multipoint-to-point LSPs) for improving scaling. The intention is to motivate the development of appropriate deployment techniques and protocol extensions to enable the application of MPLS-TE in large networks. This document only considers the question of achieving scalability for the support of point-to-point MPLS-TE LSPs. Point-to-multipoint MPLS-TE LSPs are for future study. |
| | MPLS Generic Associated Channel |
| |
| | draft-ietf-mpls-tp-gach-gal-00.txt |
| | Date: |
02/12/2008 |
| | Authors: |
Martin Vigoureux, Matthew Bocci, David Ward, George Swallow, Rahul Aggarwal |
| | Working Group: |
Multiprotocol Label Switching (mpls) |
| | Formats: |
txt |
|
This document generalises the applicability of the pseudowire Associated Channel Header (ACH), enabling the realization of a control channel associated to MPLS Label Switched Paths (LSP), MPLS pseudowires (PW) and MPLS Sections. In order to identify the presence of this G-ACH, this document also assigns of one of the reserved MPLS label values to the 'Generic Alert Label (GAL)', to be used as a label based exception mechanism. |
| | Object-based pNFS Operations |
| |
|
Parallel NFS (pNFS) extends NFSv4 to allow clients to directly access file data on the storage used by the NFSv4 server. This ability to bypass the server for data access can increase both performance and parallelism, but requires additional client functionality for data access, some of which is dependent on the class of storage used, a.k.a. the Layout Type. The main pNFS operations and data types in NFSv4 Minor Version 1 specify a layout-type-independent layer; layout-type-specific information is conveyed using opaque data structures which internal structure is further defined by the particular layout type specification. This document specifies the NFSv4.1 Object-based pNFS Layout Type in companion with the main NFSv4 Minor Version 1 specification. |
| | Elliptic-Curve Algorithm Integration in the Secure Shell Transport Layer |
| |
|
This document describes algorithms based on Elliptic Curve Cryptography (ECC) for use within the Secure Shell (SSH) transport protocol. In particular, it specifies: Elliptic Curve Diffie-Hellman (ECDH) key agreement, Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key agreement and Elliptic Curve Digital Signature Algorithm (ECDSA) for use in the SSH Transport Layer protocol. |
| | Common Architecture Label IPv6 Security Option (CALIPSO) |
| |
|
This document describes an optional method for encoding explicit packet Sensitivity Labels on IPv6 packets. It is intended for use only within Multi-Level secure (MLS) networking environments that are both trusted and trustworthy. |
| | Vouch By Reference |
| |
|
This document describes the Vouch By Reference (VBR) protocol. VBR is a protocol for adding third-party certification to email. It permits independent third parties to certify the owner of a domain name that is associated with received mail. |
| | OCSP Algorithm Agility |
| |
|
The OSCP specification defined in RFC 2560 requires server responses to be signed but does not specify a mechanism for selecting the signature algorithm to be used leading to possible interoperability failures in contexts where multiple signature algorithms are in use. This document specifies an algorithm for server signature algorithm selection and an extension that allows a client to advise a server that specific signature algorithms are supported. |
| | Distributed Internet Archive Protocol (DIAP) |
| |
|
A de-centralised, self-contained and managed storage protocol. A system to provide strong storage fail over by using existing resources over networks distributing vital data evenly. Rapid deployment and high redundancy for small to medium organisations as well as individuals. Designed to reduce dependency on tape backup systems. The protocol also has implications for long term archiving. By classifying data vitality values the limitations in physical space due to bandwidth constrictions can be overcome and the usefulness of DIAP maximised. |
| | Portable Contacts: A Common Format and Protocol for Accessing Contacts |
| |
|
This document specifies Portable Contacts, XML and JSON address book document formats and an interface for accessing address book and friends-list information over HTTP. |
| | Tiered Routing for IPv4 and IPv6 (TRIP) |
| |
|
This document describes a mechanism for scalable, tiered Internet routing, called TRIP. The goal of TRIP is to decrease the growth rate of the core Internet routing tables by increasing route aggregation and constraining the propagation of multihoming and traffic engineering routes. TRIP accomplishes this goal by defining separate routing domains for edge networks and transit networks. All current, non-TRIP-aware networks and nodes are considered part of the transit domain. Edge network domains may be created by deploying TRIP at a domain-boundary routers or within IP (v4 or v6) endpoints. In addition to defining the basic TRIP mechanism, this document describes an incremental deployment path that provides a means for endpoints in TRIP-enabled edge networks to talk directly to non-TRIP- aware end-points in transit domain. This is accomplished without the need to advertise edge network prefixes in the global routing tables or to create a separate global routing domain for edge network prefixes. |
| |
|
| |
| | Initial Hypertext Transfer Protocol (HTTP) Method Registrations |
| |
|
This document registers those Hypertext Transfer Protocol (HTTP) methods which have been defined in standards-track RFCs before the IANA HTTP Method Registry was established. |
| | Update to the Language Subtag Registry |
| |
|
This memo defines the procedure used to update the IANA Language Subtag Registry in conjunction with the publication of RFC 4646bis [RFC EDITOR NOTE: replace with actual RFC number], for use in forming tags for identifying languages. As an Internet-Draft, it also contained a complete replacement of the contents of the Registry to be used by IANA in updating it. To prevent confusion, this material was removed before publication. |
| | WiMAX Forum/3GPP2 Proxy Mobile IPv4 |
| |
|
Mobile IPv4 is a standard mobility protocol that enables IPv4 device to move among networks while maintaining its IP address. The mobile device has the Mobile IPv4 client function to signal its location to the routing anchor, known as the Home Agent. However, there are many IPv4 devices without such capability due to various reasons. This document describes Proxy Mobile IPv4 (PMIPv4), a scheme based on having the Mobile IPv4 client function in a network entity to provide mobility support for an unaltered and mobility-unaware IPv4 device. This document also describes a particular application of PMIPv4 as specified in the WiMAX Forum and another application that is to be adopted in 3GPP2 |
| | File Transfer Protocol HOST Command |
| |
|
The File Transfer Protocol, as defined in RFC 959 [1] and RFC 1123 Section 4 [6], is one of the oldest and widely used protocols on the Internet. This document addresses the subject of creating multi-homed FTP hosts servers on a single IP address. This is achieved by extending the FTP specification to add a HOST command that is used to specify individual FTP hosts. |
| | Cryptographic Algorithm Implementation Requirements for Routing Protocols |
| |
|
The interior gateway routing protocols Open Shortest Path First version 2 (OSPFv2) [RFC2328], Intermediate System to Intermediate System (IS-IS) [ISO] [RFC1195] and Routing Information Protocol (RIP) [RFC2453] currently define Clear Text and Message Digest 5 (MD5) [RFC1321] algorithms for authenticating their protocol packets. There have recently been documents adding support of the Secure Hash Algorithm (SHA) family of hash functions for authenticating routing protocol packets for RIP [RFC4822], IS-IS [ISIS-HMAC] and OSPF [OSPF- HMAC]. To ensure interoperability between disparate implementations, it is imperative that we specify a set of mandatory-to-implement algorithms thereby ensuring that there is at least one algorithm that all implementations will have available. This document defines the current set of mandatory-to-implement algorithms to be used for the cryptographic authentication of these routing protocols as well as specifying the algorithms that should be implemented because they may be promoted to mandatory at some future time. |
| | Location Measurements for IEEE 802.16e Devices |
| |
|
IEEE 802.16e defines means for true mobility within an 802.16 wireless network. Determining an accurate location for 802.16e devices requires information on radio parameters. A format is defined for location-related measurement data that can be provided by an 802.16e device. This measurement data can be used by a Location Information Server (LIS) to more accurately determine the location of the device. A separate measurement used for identifying WiMAX session-related parameters is also provided. |
| | The References Header for SIP |
| |
|
This document defines a SIP extension header, References, to be used within SIP messages to signify that the message (and the dialog containing it) is related to one or more other dialogs. It is expected to be used largely for diagnostic purposes. |
| | IANA Allocation Guidelines for the Address Resolution Protocol (ARP) |
| |
|
This document specifies the IANA guidelines for allocating new values in the Address Resolution Protocol (ARP). This document also reserves some numbers for experimentation purposes. The changes also affect other protocols that employ values from the ARP name spaces. |
| | Mechanism for performing LSP-Ping over RSVP protection paths |
| |
|
This document describes methods for performing lsp ping over mpls rsvp-te protection paths, when the protection paths are not in use. Conventional LSP-Ping follows the same path as data traffic. In some cases, it might be useful to follow the data path of protection paths (detours and bypasses) to ensure that the those paths are fully functional. This document describes enhancements to LSP-Ping to perform ping over such paths. |
| | Identifying ESP-NULL Packets |
| |
|
Encapsulating Security Payload (ESP) [RFC4303] provides data integrity protection, confidentiality and data origin authentication for data transported in an IP packet. There are various applications and protocols that do not require confidentiality but only need data integrity assurance or data origin authentication. Since ESP support is mandatory for IPSec, such applications end up using ESP with NULL encryption. However, because of the way ESP is defined, it is impossible for firewalls and intermediate routers to differentiate between encrypted ESP and ESP NULL packets by simply examining them. This poses problems for the firewalls since such packets cannot be filtered and identified. It poses a different set of problems for routers since such packets cannot be properly filtered, classified and prioritized. This document proposes an extension to ESP so that firewalls and routers can disambiguate between ESP encrypted and ESP NULL encrypted packets. |
| | A Protocol for Remotely Managing Sieve Scripts |
| |
|
Sieve scripts allow users to filter incoming email. Message stores are commonly sealed servers so users cannot log into them, yet users must be able to update their scripts on them. This document describes a protocol "ManageSieve" for securely managing Sieve scripts on a remote server. This protocol allows a user to have multiple scripts, and also alerts a user to syntactically flawed scripts. |
| | Response Code for Indication of Terminated Dialog |
| |
|
This specification defines a new SIP response code, 199 Early Dialog Terminated, which a SIP forking proxy and a UAS can use to indicate upstream towards the UAC that an early dialog has been terminated, before a final response is sent towards the UAC. |
| | TCP User Timeout Option |
| |
|
The TCP user timeout controls how long transmitted data may remain unacknowledged before a connection is forcefully closed. It is a local, per-connection parameter. This document specifies a new TCP option - the TCP User Timeout Option - that allows one end of a TCP connection to advertise its current user timeout value. This information provides advice to the other end of the TCP connection to adapt its user timeout accordingly. Increasing the user timeouts on both ends of a TCP connection allows it to survive extended periods without end-to-end connectivity. Decreasing the user timeouts allows busy servers to explicitly notify their clients that they will maintain the connection state only for a short time without connectivity. |
| |
|
| |
| | Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) |
| |
| | draft-ietf-behave-turn-12.txt |
| | Date: |
30/11/2008 |
| | Authors: |
Jonathan Rosenberg, Rohan Mahy, Philip Matthews |
| | Working Group: |
Behavior Engineering for Hindrance Avoidance (behave) |
| | Formats: |
txt xml |
|
If a host is located behind a NAT, then in certain situations it can be impossible for that host to communicate directly with other hosts (peers). In these situations, it is necessary for the host to use the services of an intermediate node that acts as a communication relay. This specification defines a protocol, called TURN (Traversal Using Relays around NAT), that allows the host to control the operation of the relay and to exchange packets with its peers using the relay. TURN differs from some other relay control protocols in that it allows a client to communicate with multiple peers using a single relay address. The TURN protocol was designed to be used as part of the ICE (Interactive Connectivity Establishment) approach to NAT traversal, though it can be also used without ICE. |
| | Link Relations and HTTP Header Linking |
| |
|
This document specifies relation types for Web links, and defines a registry for them. It also defines how to send such links in HTTP headers with the Link header-field. |
| | The SIEVE mail filtering language - extension for accessing mailbox metadata |
| |
|
This memo defines an extension to the SIEVE mail filtering language (RFC 5228) for accessing mailbox and server annotations (variables). |
| | Representation of Uncertainty and Confidence in PIDF-LO |
| |
|
The key concepts of uncertainty and confidence as they pertain to location information are defined. Methods for the manipulation of location estimates that include uncertainty information are outlined. |
| | System for Managing a Shared Domain Registry |
| |
|
This document describes the typical usage and communication protocol of a client/server shared registry system for management of domain name registrations. The system described is a "thick registry" system, providing support for the storage and management of both the technical and the registrant contact information concerning domain registrations. The system relies on the existing HTTP and HTTPS infrastructure for transport and secure transfer to avoid having to implement a dedicated protocol and server environment. A bespoke XML format is used to communicate between clients and the SRS server. Comments are solicited and should be addressed to the mailing list at srsstandards-l@nzrs.net.nz and/or the author. The mailing list management page can be found at . |
| | Using POST to add Members to Web Distributed Authoring and Versioning (WebDAV) Collections |
| |
|
The Hypertext Transfer Protocol (HTTP) Extensions for the Web Distributed Authoring and Versioning (WebDAV) do not define the behavior for the "POST" method when applied to collections, as the base specification (HTTP) leaves implementers lots of freedom for the semantics of "POST". This has led to a situation where many WebDAV servers do not implement POST for collections at all, although it is well suited to be used for the purpose of adding new members to a collection, where the server remains in control of the newly assigned URL. As a matter of fact, the Atom Publishing Protocol (AtomPub) uses POST exactly for that purpose. On the other hand, WebDAV-based protocols such as the Calendar Extensions to WebDAV (CalDAV) frequently require clients to pick a unique URL, although the server could easily perform that task. This specification defines a discovery mechanism through which servers can advertise support for POST requests with the aforementioned "add collection member" semantics. |
| | A Session Identifier for the Session Initiation Protocol (SIP) |
| |
|
There are several reasons for having a globally unique session identifier for the same SIP session, which can be maintained across B2BUA's and other SIP middle-boxes. This draft proposes a new SIP header to carry such a value: Session-ID. |
| | TCP's Reaction to Soft Errors |
| |
|
This document describes a non-standard, but widely implemented, modification to TCP's handling of ICMP soft error messages, that rejects pending connection-requests when those error messages are received. This behavior reduces the likelihood of long delays between connection establishment attempts that may arise in a number of scenarios, including one in which dual stack nodes that have IPv6 enabled by default are deployed in IPv4 or mixed IPv4 and IPv6 environments. |
| | vCard Extensions to WebDAV (CardDAV) |
| |
|
This document defines extensions to the Web Distributed Authoring and Versioning (WebDAV) protocol to specify a standard way of accessing, managing, and sharing contact information based on the vCard format. Discussion of this Internet-Draft is taking place on the mailing list . |
| |
|
| |
| | An updated IDNA criterion for right-to-left scripts |
| |
| | draft-ietf-idnabis-bidi-03.txt |
| | Date: |
29/11/2008 |
| | Authors: |
Harald Alvestrand, Cary Karp |
| | Working Group: |
Internationalized Domain Names in Applications (Revised) (idnabis) |
| | Formats: |
txt xml |
|
The use of right-to-left scripts in internationalized domain names has presented several challenges. This memo discusses some problems with these scripts, and some shortcomings in the 2003 IDNA BIDI criterion. Based on this discussion, it proposes a new BIDI rule for IDNA labels. |
| | Updates to the Updates to Asserted Identity in the Session Initiation Protocol (SIP) |
| |
|
An update to the [RFC3325] is currently being defined in [draft- update-pai], to add additional request method types and use-cases for P-Asserted-Identity applicability. The update does not, however, apply to SIP responses, ACK or CANCEL requests. This draft proposes an update to the update, to add SIP response, ACK and CANCEL support. Kaplan Expires May 29, 2009 [page 1] Updates to the Update for PAI in SIP November 2008 |
| | QoS NSLP QSPEC Template |
| |
| | draft-ietf-nsis-qspec-21.txt |
| | Date: |
29/11/2008 |
| | Authors: |
Attila Bader, Cornelia Kappler, David Oran |
| | Working Group: |
Next Steps in Signaling (nsis) |
| | Formats: |
txt |
|
The QoS NSLP protocol is used to signal QoS reservations and is independent of a specific QoS model (QOSM) such as IntServ or DiffServ. Rather, all information specific to a QOSM is encapsulated in a separate object, the QSPEC. This document defines a template for the QSPEC including a number of QSPEC parameters. The QSPEC parameters provide a common language to be re-used in several QOSMs and thereby aim to ensure the extensibility and interoperability of QoS NSLP. The node initiating the NSIS signaling adds an initiator QSPEC, which indicates the QSPEC parameters that must be interpreted by the downstream nodes less the reservation fails, thereby ensuring the intention of the NSIS initiator is preserved along the signaling path. |
| |
|
| |
| | Container Option for Server Configuration |
| |
|
In some DHCP service deployments, it is desirable for a DHCP server in one administrative domain to pass configuration options to a DHCP server in a different administrative domain. This DHCP option carries a set of DHCP options that can be used by another DHCP server. |
| | Requirements for a Location-by-Reference Mechanism |
| |
|
This document defines terminology and provides requirements relating to Location-by-Reference approach using a location URI to handle location information within signaling and other Internet messaging. |
| | Internationalized Domain Names for Applications (IDNA): Background,Explanation,and Rationale |
| |
|
Several years have passed since the original protocol for Internationalized Domain Names (IDNs) was completed and deployed. During that time, a number of issues have arisen, including the need to update the system to deal with newer versions of Unicode. Some of these issues require tuning of the existing protocols and the tables on which they depend. This document provides an overview of a revised system and provides explanatory material for its components. |
| | Internationalized Domain Names in Applications (IDNA): Protocol |
| |
|
This document supplies the protocol definition for a revised and updated specification for internationalized domain names (IDNs). The rationale for these changes, the relationship to the older specification, and important terminology are provided in other documents. This document specifies the protocol mechanism, called Internationalizing Domain Names in Applications (IDNA), for registering and looking up IDNs in a way that does not require changes to the DNS itself. IDNA is only meant for processing domain names, not free text. |
| | Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework |
| |
|
This document is one of a collection that, together, describe the protocol and usage context for a revision of Internationalized Domain Names for Applications (IDNA), superseding the earlier version. It describes the document collection and provides definitions and other material that are common to the set. |
| | An Interactive Voice Response (IVR) Control Package for the Media Control Channel Framework |
| |
|
This document defines a Media Control Channel Framework Package for Interactive Voice Response (IVR) dialog interaction on media connections and conferences. The package defines dialog management request elements for preparing, starting and terminating dialog interactions, as well as associated responses and notifications. Dialog interactions are specified in a dialog language. This package defines a lightweight IVR dialog language (supporting prompt playback, runtime controls, DTMF collect and media recording) and allows other dialog languages to be used. The package also defines elements for auditing package capabilities and IVR dialogs. |
| | A Mixer Control Package for the Media Control Channel Framework |
| |
|
This document defines a Media Control Channel Framework Package for managing mixers for media conferences and connections. The package defines request elements for managing conference mixers, managing mixers between conferences and/or connections, as well as associated responses and notifications. The package also defines elements for auditing package capabilities and mixers. |
| | MIPv6 Correspondent Node-Targeted Location Privacy and Optimized Routing |
| |
|
This document discusses the problem of correspondent node-targeted location privacy in Mobile IPv6 and proposes a mechanism to achieve simultaneous optimized routing and full correspondent node-targeted IP address location privacy. The mechanism utilizes the MIPv6 bootstrapping mechanisms and does neither require any new network entities nor changes to home agent or correspondent node implementations. |
| | Credential Protection Ciphersuites for Transport Layer Security (TLS) |
| |
|
This document defines a set of cipher suites to add client credential protection to the Transport Layer Security (TLS) protocol. By negotiating one of those ciphersuites, the TLS clients will be able to determine for themselves when, how, to what extent and for what purpose information about them is communicated to others. The ciphersuites defined in this document can be used only when public key certificates are used in the client authentication process. |
| | Behaviour of BitTorrent service in an IP Shared Address Environment |
| |
|
This memo describes the behaviour of BitTorrent service in the context of IP shared addresses. It provides an overview of the used testbed and main results of the tests that have been conducted in order to assess the limitations of an architecture based on shared IP addresses. |
| | HTTP Cache-Control Extensions for Stale Content |
| |
|
This document defines two independent HTTP Cache-Control extensions that allow control over the use of stale responses by caches. |
| | PKI Resource Query Protocol (PRQP) |
| |
|
One of the most strategic problems still open in PKIX is locating public data and services associated with a Certification Authority (CA). This issue impacts interoperability and usability in PKIX. This draft describes the PKI Resource Query Protocol (PRQP), its design, definition, and its impact in already deployed PKIX protocols. |
| | Extended MKCOL for WebDAV |
| |
|
This specification extends the Web Distributed Authoring and Versioning (WebDAV) MKCOL method to allow collections of arbitrary resourcetype to be created and to allow properties to be set at the same time. |
| |
|
| |
| | Network Address Translation (NAT) Behavioral Requirements for the Datagram Congestion Control Protocol |
| |
|
This document defines a set of requirements for NATs handling the Datagram Congestion Control Protocol (DCCP). Those allow DCCP applications, such as streaming applications to operate consistently. These requirements are very similar to the TCP requirements for NATs already published by the IETF. Ensuring that NATs meet this set of requirements will greatly increase the likelihood that applications using DCCP will function properly. |
| | DNS Proxy Implementation Guidelines |
| |
|
This document provides guidelines for the implementation of DNS proxies, as found in broadband routers and other similar network devices. |
| | An Architectural Framework for Media Server Control |
| |
|
This document describes an Architectural Framework for Media Server Control. The primary focus will be to define logical entities that exist within the context of Media Server control, and define the appropriate naming conventions and interactions between them. |
| | A Framework for MPLS in Transport Networks |
| |
|
This document specifies an archiectectural framework for the application of MPLS in transport networks. It describes a profile of MPLS that enables operational models typical in transport networks networks, while providing additional OAM, survivability and other maintenance functions not currently supported by MPLS. |
| | IPv4 Support for Proxy Mobile IPv6 |
| |
|
This document specifies extensions to Proxy Mobile IPv6 protocol for adding IPv4 protocol support. The scope of IPv4 protocol support is two-fold: 1) enable IPv4 home address mobility support to the mobile node. 2) allowing the mobility entities in the Proxy Mobile IPv6 domain to exchange signaling messages over an IPv4 transport network. |
| |
|
| |
| | ZRTP: Media Path Key Agreement for Secure RTP |
| |
|
This document defines ZRTP, a protocol for media path Diffie-Hellman exchange to agree on a session key and parameters for establishing Secure Real-time Transport Protocol (SRTP) sessions. The ZRTP protocol is media path keying because it is multiplexed on the same port as RTP and does not require support in the signaling protocol. ZRTP does not assume a Public Key Infrastructure (PKI) or require the complexity of certificates in end devices. For the media session, ZRTP provides confidentiality, protection against man-in-the-middle (MiTM) attacks, and, in cases where the signaling protocol provides end-to-end integrity protection, authentication. ZRTP can utilize a Session Description Protocol (SDP) attribute to provide discovery and authentication through the signaling channel. To provide best effort SRTP, ZRTP utilizes normal RTP/AVP profiles. |
| | Private Session Initiation Protocol (SIP) Proxy-to-Proxy Extensions for Supporting the PacketCable Distributed Call Signaling Architecture |
| |
|
In order to deploy a residential telephone service at very large scale across different domains, it is necessary for trusted elements owned by different service providers to exchange trusted information that conveys customer-specific information and expectations about the parties involved in the call. This document describes private extensions to the Session Initiation Protocol (SIP) [RFC3261] for supporting the exchange of customer information and billing information between trusted entities in the PacketCable Distributed Call Signaling Architecture. These extensions provide mechanisms for access network coordination to prevent theft of service, customer originated trace of harassing calls, support for operator services and emergency services, and support for various other regulatory issues. The use of the extensions is only applicable within closed administrative domains, or among federations of administrative domains with previously agreed-upon policies where coordination of charging and other functions is required. |
| | Locator/ID Separation Protocol (LISP) |
| |
| | draft-farinacci-lisp-10.txt |
| | Date: |
26/11/2008 |
| | Authors: |
Dino Farinacci, Vince Fuller, David Oran, Dave Meyer, Scott Brim |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
This draft describes a simple, incremental, network-based protocol to implement separation of Internet addresses into Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). This mechanism requires no changes to host stacks and no major changes to existing database infrastructures. The proposed protocol can be implemented in a relatively small number of routers. This proposal was stimulated by the problem statement effort at the Amsterdam IAB Routing and Addressing Workshop (RAWS), which took place in October 2006. |
| | LISP for Multicast Environments |
| |
|
This draft describes how inter-domain multicast routing will function in an environment where Locator/ID Separation is deployed using the LISP architecture. |
| | Pairtrees for Object Storage (V0.1) http://www.ietf.org/internet-drafts/draft-kunze-pairtree-01.txt |
| |
| | draft-kunze-pairtree-01.txt |
| | Date: |
26/11/2008 |
| | Authors: |
John Kunze, Martin Haye, Erik Hetzner, Mark Reyes, Cory Snavely |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
This document specifies Pairtree, a filesystem hierarchy for holding objects that are located within that hierarchy by mapping identifier strings to object directory (or folder) paths two characters at a time. If an object directory (folder) holds all the files, and nothing but the files, that comprise the object, a "pairtree" can be imported by a system that knows nothing about the nature or structure of the objects but can still deliver any object's files by requested identifier. The mapping is reversible, so the importing system can also walk the pairtree and reliably enumerate all the contained object identifiers. To the extent that object dependencies are stored inside the pairtree (e.g., fast indexes stored outside contain only derivative data), simple or complex collections built on top of pairtrees can recover from index failures and reconstruct a collection view simply by walking the trees. Pairtrees have the advantage that many object operations, including backup and restore, can be performed with native operating system tools.1. The basic pairtree algorithm The pairtree algorithm maps an arbitrary UTF-8 [RFC3629] encoded identifier string into a filesystem directory path based on successive pairs of characters, and also defines the reverse mapping (from pathname to identifier). In this document the word "directory" is used interchangeably with the word "folder" and all examples conform to Unix-based filesystem conventions which should tranlate easily to Windows conventions after substituting the path separator ('\' instead of '/'). Pairtree places no limitations on file and path lengths, so implementors thinking about maximal interoperation may wish to consider the issues listed in the Interoperability section of this document. The mapping from identifier string to path has two parts. First, the string is cleaned by converting characters that would be illegal or especially problemmatic in Unix or Windows filesystems. The cleaned string is then split into pairs of characters, each of which becomes a directory name in a filesystem path: successive pairs map to successive path components until there are no characters left, with the last component being either a 1- or 2-character directory name. The resulting path is known as a _pairpath_, or _ppath_. abcd -> ab/cd/ abcdefg -> ab/cd/ef/g/ 12-986xy4 -> 12/-9/86/xy/4/ Armed with specific knowledge of a given namespace's identifier distribution, one might achieve more balanced or efficient trees by mapping to paths from character groupings other than successive pairs. Pairtree assumes that this sort of optimization, however, being tailored to individual and transient namespace conditions, is often less important than having a single generalized and shareable mapping. It uses pairs of characters to achieve hierarchies that exhibit a reasonable balance of path length and fanout (number of probable entries in any component directory).2. Pairpath termination and object encapsulation A ppath (pairpath) terminates when it reaches an object. A little jargon helps explain this. A _shorty_ is a 1- or 2-character directory name, or any file or directory name that begins with "pairtree" (these are reserved for future use). A ppath consists of a sequence of "shorties" ending in a non-shorty, such as a 3-character directory name or the 2-character file name "xy". The pairtree below contains two objects with identifiers "abcd" and "abcde". ab/ | \--- cd/ | |--- foo/ | | README.txt | | thumbnail.gif | | | |--- master_images/ | | | ... | | ... | | | \--- gh/ | \--- e/ | \--- bar/ | metadata | 54321.wav | index.html An object is reached when a non-shorty is detected. An object is _properly encapsulated_ if it is entirely contained in a non-shorty directory that is the immediate child of a shorty directory, in other words, if the 1- or 2-char directory name ending the object's ppath contains exactly one non-shorty directory that holds all the object's descendants. The two objects "abcd" and "abcde" above are properly encapsulated. Any shorty directory found at the same level as the non-shorty extends the pairtree. So while the "foo/" directory above does not subsume "e/" at the same level, by encapsulation, it does subsume the "gh/" underneath it (i.e., "gh/" is invisible to the pairtree algorithm, at least on a first pass). Practice will vary according to local custom as to how to name the encapsulating object directory beneath that last shorty. Its name is completely independent of the object identifier. For example, every object directory in a pairtree could have the uniform name "thingy". It is common for the directory name to be a terminal substring of the object identifier, as in: id: 13030_45xqv_793842495 ppath: 13/03/0_/45/xq/v_/79/38/42/49/5/793842495 All objects should be properly encapsulated. If an object is detected that is _improperly encapsulated_, that is, when a ppath ends with a shorty directory that contains more than one non-shorty, the detecting system should take corrective action. In this situation, also known as a "split end", all those non-shorties (directories and files) are considered to belong to one object (not properly encapsulated) identified by the containing ppath. Excluding shorties from the object permits one identifier to be a substring of another (e.g., "abcd" and "abcde" can co-exist in a pairtree), and defining ppath termination in this way prevents "hidden riders", or data residing in a pairtree that is not contained or accounted for in any object. Here is an example of an improperly encapsulated object named "bent". be/ | \--- nt/ [ split end: two files, no encapsulation ] | README.txt | report.pdf | \--- ef/ | ... If a "split end" is encountered, an importing system is encouraged to normalize it by creating a single object directory called "obj" and pushing the non-shorties in question underneath it, as in: be/ | \--- nt/ | |--- obj/ [ split end repaired with "obj" directory ] | | README.txt | | report.pdf | \--- ef/ | ... |
| |
|
| |
| | DHCPv6 Bulk Leasequery |
| |
|
The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) has been extended with a Leasequery capability that allows a client to request information about DHCPv6 bindings. That mechanism is limited to queries for individual bindings. In some situations individual binding queries may not be efficient, or even possible. This document expands on the Leasequery protocol, adding new query types and allowing for bulk transfer of DHCPv6 binding data via TCP. |
| | Binding Revocation for IPv6 Mobility |
| |
|
This document defines the revocation semantics for terminating a mobile node's mobility session and associated resources. These semantics are generic enough and can be used by mobility entities in the case of Client Mobile IPv6 and its extensions. This mechanism allows the mobility entity which initiates the revocation procedure to request its corresponding one to terminate either one, multiple or all specified binding cache entries. |
| | PathErr Message Triggered MPLS and GMPLS LSP Reroute |
| |
|
This document describes how Resource ReserVation Protocol (RSVP) PathErr Messages may be used to trigger rerouting of Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) point-to-point Traffic Engineering (TE) Label Switched Paths (LSPs) without first removing LSP state or resources. Such LSP rerouting may be desirable in a number of cases including, for example, soft-preemption and graceful shutdown. This document describes the usage of existing Standards Track mechanisms to support LSP rerouting. In this case, it relies on mechanisms already defined as part of RSVP-TE and simply describes a sequence of actions to be executed. While existing protocol definition can be used to support reroute applications, this document also defines a new reroute-specific error code to allow for the future definition of reroute application-specific error values. |
| | pNFS Block/Volume Layout |
| |
|
Parallel NFS (pNFS) extends NFSv4 to allow clients to directly access file data on the storage used by the NFSv4 server. This ability to bypass the server for data access can increase both performance and parallelism, but requires additional client functionality for data access, some of which is dependent on the class of storage used. The main pNFS operations draft specifies storage-class-independent extensions to NFS; this draft specifies the additional extensions (primarily data structures) for use of pNFS with block and volume based storage. |
| | Complications from Network Address Translator Deployment Topologies |
| |
|
This document identifies two deployment scenarios that have arisen from the unconventional network topologies formed using Network Address Translator devices (NATs). First, the simplicity of administering networks through the combination of NAT and DHCP has increasingly lead to the deployment of multi-level inter-connected private networks involving overlapping IP address spaces. Second, the proliferation of private networks in enterprises, hotels and conferences, and the wide spread use of Virtual Private Networks (VPNs) to access enterprise intranet from remote locations has increasingly lead to overlapping IP address space between remote and corporate networks. The document does not dismiss these unconventional scenarios as invalid, but recognizes them as real and offers recommendations to ensure these real scenarios can function. |
| | Service Selection for Mobile IPv4 |
| |
|
In some Mobile IPv4 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 to provide multiple services within a single mobility service subscription. This document describes a Service Selection Extension for Mobile IPv4 that is intended to assist home agents to make specific service selections for the mobility service subscription during the registration procedure. |
| | Using OpenPGP Keys for Transport Layer Security (TLS) Authentication |
| |
|
This memo proposes extensions to the Transport Layer Security (TLS) protocol to support the OpenPGP key format. The extensions discussed here include a certificate type negotiation mechanism, and the required modifications to the TLS Handshake Protocol. This memo replaces the Experimental [RFC5081]. |
| | Asynchronous Channels for the Blocks Extensible Exchange Protocol (BEEP) |
| |
|
The Blocks Extensible Exchange Protocol (BEEP) provides a protocol framework for the development of application protocols. This document describes an BEEP feature that enables asynchrony for individual channels. |
| | On RFC Streams,Headers,and Boilerplates |
| |
|
RFC documents contain a number of fixed elements such as the title page header, standard boilerplates and copyright/IPR statements. This document describes them and introduces some updates to reflect current usage and requirements of RFC publication. In particular, this updated structure is intended to communicate clearly the source of RFC creation and review. |
| | RADIUS Attributes for IEEE 802.16 Privacy Key Management Version 1 (PKMv1) Protocol Support |
| |
|
This document defines a set of RADIUS Attributes which are designed to provide RADIUS support for IEEE 802.16 Privacy Key Management Version 1. |
| | Revisions to the BGP 'Minimum Route Advertisement Interval' |
| |
|
This document revises the specification of the BGP MRAI timer, by deprecating the previously recommended values and by allowing for withdrawals to be exempted from the MRAI. |
| | Management Information Base for OSPFv3 |
| |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in IPv6-based internets. In particular, it defines objects for managing the Open Shortest Path First (OSPF) Routing Protocol for IPv6, otherwise known as OSPF version 3 (OSPFv3). Please send comments to ospf@ietf.org. |
| | New Tunnel-Type Values |
| |
|
This document defines a set of values for the Tunnel-Type RADIUS Attribute. |
| | The use of the SIPS URI Scheme in the Session Initiation Protocol (SIP) |
| |
|
This document provides clarifications and guidelines concerning the use of the SIPS URI scheme in the Session Initiation Protocol (SIP). It also makes normative changes to SIP. |
| | Essential correction for IPv6 ABNF and URI comparison in RFC3261 |
| |
|
This memo corrects the Augmented Backus-Naur Form (ABNF) production rule associated with generating IPv6 literals in RFC3261. It also clarifies the rule for Uniform Resource Identifier (URI) comparison when the URIs contain textual representation of IP addresses. |
| |
|
| |
| | Diameter Base Protocol |
| |
|
The Diameter base protocol is intended to provide an Authentication, Authorization and Accounting (AAA) framework for applications such as network access or IP mobility. Diameter is also intended to work in both local Authentication, Authorization & Accounting and roaming situations. This document specifies the message format, transport, error reporting, accounting and security services to be used by all Diameter applications. The Diameter base application needs to be supported by all Diameter implementations. |
| | Diameter Applications Design Guidelines |
| |
|
The Diameter Base protocol provides updated rules on how to extend Diameter by modifying and/or deriving from existing applications or creating entirely new applications. This is a companion document to the Diameter Base protocol that further explains and clarifies these rules. It is meant as a guidelines document and therefore it does not add, remove or change existing rules. |
| | GEOPRIV PIDF-LO Usage Clarification,Considerations and Recommendations |
| |
|
The Presence Information Data Format Location Object (PIDF-LO) specification provides a flexible and versatile means to represent location information. There are, however, circumstances that arise when information needs to be constrained in how it is represented. In these circumstances the range of options that need to be implemented are reduced. There is growing interest in being able to use location information contained in a PIDF-LO for routing applications. To allow successful interoperability between applications, location information needs to be normative and more tightly constrained than is currently specified in the RFC 4119 (PIDF-LO). This document makes recommendations on how to constrain, represent and interpret locations in a PIDF-LO. This further recommends a subset of Geography Markup Language (GML) 3.1.1 that is mandatory t |