|
Internet Drafts - IDs for Apr/2008
Index - Month Index of IDs
All IDs - sorted by date)
30/04/2008
| |
|
| |
| | OTP Pre-authentication |
| |
|
The Kerberos protocol provides a framework authenticating a client using the exchange of pre-authentication data. This document describes the use of this framework to carry out One Time Password (OTP) authentication. |
| | Point-to-Multipoint Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB) module |
| |
|
This memo defines a portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects for point-to-multipoint (P2MP) Multiprotocol Label Switching (MPLS) based traffic engineering (TE). The MIB module defined in this document is applicable to P2MP MPLS-TE by extensions to the MPLS-TE MIB module defined in RFC 3812. It is equally applicable to P2MP Generalized MPLS (GMPLS) in association with the GMPLS TE MIB module defined in RFC 4802. |
| | EAP Tunneled TLS Authentication Protocol Version 0 (EAP-TTLSv0) |
| |
|
EAP-TTLS is an EAP method that provides additional functionality beyond what is available in EAP-TLS [RFC5216]. In EAP-TLS, a TLS handshake is used to mutually authenticate a client and server. EAP- TTLS extends this authentication negotiation by using the secure connection established by the TLS handshake to exchange additional information between client and server. In EAP-TTLS, the TLS handshake may be mutual; or it may be one-way, in which only the server is authenticated to the client. The secure connection established by the handshake may then be used to allow the server to authenticate the client using existing, widely-deployed authentication mechanisms. The authentication of the client may itself be EAP, or it may be another authentication protocol such as PAP, CHAP, MS-CHAP or MS-CHAP-V2. Thus, EAP-TTLS allows legacy password-based authentication protocols to be used against existing authentication databases, while protecting the security of these legacy protocols against eavesdropping, man-in-the-middle and other attacks. EAP-TTLS also allows client and server to establish keying material for use in the data connection between the client and access point. The keying material is established implicitly between client and server based on the TLS handshake. This document describes EAP-TTLSv0; that is, the original version 0 of the EAP-TTLS protocol, which has been widely deployed. |
| | Guidelines for firewall administrators regarding MIPv6 traffic |
| |
|
This document presents some recommendations for firewall administrators to help them configure their existing firewalls in a way that allows in certain deployment scenarios the Mobile IPv6 signaling and data messages to pass through. For other scenarios, the support of additional mechanisms to create pinholes required for MIPv6 will be necessary. This document assumes that the firewalls in question include some kind of stateful packet filtering capability. |
| | Guidelines for firewall vendors regarding MIPv6 traffic |
| |
|
This document presents some recommendations for firewall vendors to help them implement their firewalls in a way that allows Mobile IPv6 signaling and data messages to pass through. This document describes how to implement stateful packet filtering capability for MIPv6. |
| | TCP Congestion Control |
| |
|
This document defines TCP's four intertwined congestion control algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery. In addition, the document specifies how TCP should begin transmission after a relatively long idle period, as well as discussing various acknowledgment generation methods. |
29/04/2008
| |
|
| |
| | GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs) |
| |
|
This document defines a method for the support of GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs). The presented approach is applicable to any switching technology and builds on the original RSVP model for the transport of traffic related parameters. The procedures described in this document are experimental. |
| | Applicability Statement for SecureMail: A framework for increasing email security |
| |
|
This document provides an Applicability Statement for Securemail, a framework proposal for secure transmission and better authentication of email based on current Internet standards. The SecureMail framework proposes the use of Transaction Layer Security (TLS), the Sender Policy Framework (SPF) and Sender ID to support secure email communication between internet servers with some assurance of the authenticity of the message sender. Comments are solicited and should be addressed to the mailing list at securemail-discuss@googlegroups.com and/or the authors. |
| | Extended Random Values for TLS |
| |
|
This document describes an extension for using larger client and server Random values with Transport Layer Security (TLS) and Datagram TLS (DTLS). |
| | ECC in OpenPGP |
| |
|
This document proposes an Elliptic Curve Cryptography extension to the OpenPGP public key format and specifies three Elliptic Curves that enjoy broad support by other standards, including NIST standards. The document aims to standardize an optimal but narrow set of parameters for best interoperability and it does so within the framework it defines that can be expanded in the future to allow more choices. |
| | Capabilities Advertisement with BGP-4 |
| |
|
This document defines an Optional Parameter, called Capabilities, that is expected to facilitate the introduction of new capabilities in the Border Gateway Protocol (BGP) by providing graceful capability advertisement without requiring that BGP peering be terminated. This document obsoletes RFC 3392. |
| | Managed Objects for ATM over Packet Switched Network (PSN) |
| |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling ATM Pseudowire (PW) carrying ATM cells over Packet Switch Network (PSN). |
| | Managed Objects for TDM over Packet Switched Network (PSN) |
| |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for pseudo wire encapsulation for structured or unstructured TDM (T1, E1, T3, E3) circuits over a Packet Switch Network (PSN). |
| | Using SHA2 Algorithms with Cryptographic Message Syntax |
| |
|
This document describes the conventions for using the Secure Hash Algorithm (SHA) message digest algorithms (SHA-224, SHA-256, SHA-384, SHA-512) with the Cryptographic Message Syntax (CMS). It also describes the conventions for using these algorithms with CMS and the Digital Signature Algorithm (DSA), Rivest Shamir Adleman (RSA), and Elliptic Curve DSA (ECDSA) signature algorithms. |
28/04/2008
| |
|
| |
| | RTP Payload Format for ITU-T Recommendation G.711.1 |
| |
|
This document specifies a Real-time Transport Protocol (RTP) payload format to be used for the International Telecommunication Union (ITU-T) G.711.1 audio codec. Two media type registrations are also included. |
| | Locator/ID Separation Protocol (LISP) |
| |
| | draft-farinacci-lisp-07.txt |
| | Date: |
28/04/2008 |
| | Authors: |
Dino Farinacci, Vince Fuller, David Oran, Dave Meyer |
| | 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. |
| | Mobility Support Using MPLS and MP-BGP Signaling |
| |
|
This document describes a new approach to handling user mobility at the network layer in the context of Multi-Protocol Label Switched Networks (MPLS). This approach does not rely on the existing IP mobility management protocols such as Mobile IP, and is instead based on the combination of Multi-Protocol BGP (MP-BGP) and MPLS. This document proposes to introduce new protocol elements to MP-BGP to achieve Mobility Label distribution at the network control plane and the optimal packet delivery to the mobile node by the network forwarding plane using MPLS. |
| | A Taxonomy for New Routing and Addressing Architecture Designs |
| |
|
The Routing Research Group is tasked to design a new routing architecture to meet the challenges of scalability in face of pervasive multi-homing and inter-domain traffic engineering. A number of solutions have been proposed. This draft describes a taxonomy for the design space. |
| | 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. |
| | Industrial Routing Requirements in Low Power and Lossy Networks |
| |
|
Wireless, low power field devices enable industrial users to significantly increase the amount of information collected and the number of control points that can be remotely managed. The deployment of these wireless devices will significantly improve the productivity and safety of the plants while increasing the efficiency of the plant workers. For wireless devices to have a significant advantage over wired devices in an industrial environment the wireless network needs to have three qualities: low power, high reliability, and easy installation and maintenance. The aim of this document is to analyze the requirements for the routing protocol used for low power and lossy networks (L2N) in industrial environments. |
27/04/2008
| |
|
| |
| | HTTP digest authentication using alternate password storage schemes |
| |
|
This document proposes to extend the HTTP Digest Authentication by adding a set new algorithms. These algorithms use different hash functions and combination of various information such as user name, realm, password, salt, and/or other data, in order to achieve compatibility with existing mechanisms used to store user credentials in various authentication/autorization servers. |
| | A Framework for Session Initiation Protocol (SIP) Session Policies |
| |
|
Proxy servers play a central role as an intermediary in the Session Initiation Protocol (SIP) as they define and impact policies on call routing, rendezvous, and other call features. This document specifies a framework for SIP session policies that provides a standard mechanism by which a proxy can define or influence policies on sessions, such as the codecs or media types to be used. It defines a model, an overall architecture and new protocol mechanisms for session policies. |
26/04/2008
| |
|
| |
| | Inter-technology handover in netlmm domain |
| |
|
Proxy Mobile IPv6 specification [Gun2008] describes a network based mobility management protocol which provides IP mobility service to a host in a way which is transparent to the host itself. This document analyses the scenario in which the MN equipped with multiple network interfaces roams in a netlmm domain consisting of several access networks. If the MN wants to preserve IP session continuity across different network interfaces as it moves from one access network to another it needs to be enhanced with a new, netlmm-specific functionality. |
25/04/2008
| |
|
| |
| | Domain-wide Prefix Distribution with Two-Level IS-IS |
| |
|
This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support optimal routing within a two-level domain. The IS-IS protocol is specified in ISO 10589, with extensions for supporting IPv4 (Internet Protocol) specified in RFC 1195. This document replaces RFC 2966. This document extends the semantics presented in RFC 1195 so that a routing domain running with both level 1 and level 2 Intermediate Systems (IS) [routers] can distribute IP prefixes between level 1 and level 2 and vice versa. This distribution requires certain restrictions to insure that persistent forwarding loops do not form. The goal of this domain-wide prefix distribution is to increase the granularity of the routing information within the domain. |
| | Media Control Channel Framework |
| |
|
This document describes a Framework and protocol for application deployment where the application logic and processing are distributed. The framework uses the Session Initiation Protocol (SIP) to establish an application-level control mechanism between application servers and associated external servers such as media servers. The motivation for the creation of this Framework is to provide an interface suitable to meet the requirements of a distributed, centralized conference system, as defined by the IETF. It is not, however, limited to this scope and it is envisioned that this generic Framework will be used for a wide variety of de-coupled control architectures between network entities. |
| | FA extensions to NEMOv4 Base |
| |
|
The base NEMOv4 specification defines extensions to Mobile IPv4 for mobile networks. NEMOv4 extensions are defined for use only by the mobile node and the home agent. This specification introduces extensions for NEMO support on the foreign agent. |
| | Agent-based multicast support for moving networks (NEMO) |
| |
|
This document describes an approach to support multicast listeners and senders located within a moving IPv6 network (NEMO). A NEMO is built up by at least one Mobile Router (MR) and a set of Mobile Network Nodes (MNNs). The MR handles all routing related tasks to provide connectivity between the MNNs and an access network including mobility management. Correspondingly the MR also subscribes to multicast groups and forwards emerging multicast traffic on behalf of a MNN. For optimised routing of multicast data a hierarchical multicast agent is introduced as a logical entity providing an anchor to the multicast tree. In the MR a corresponding functionality is defined which decides on the location of the specific agent to be used for a distinct multicast traffic. |
| | Streamlined FTP Command Extensions |
| |
|
This document specifies FTP commands to download thumbnails of remote images, remove entire directory trees, request the amount of storage space available to the user, request the size of a remote directory and its contents, and to specify an FTP host. The commands are designed to reduce the number of server / client exchanges, provide information that was not previously available, and to reduce bandwidth requirements for some higher level operations. |
| | BGP ACCEPT_OWN Well-known Community Attribute |
| |
|
It may be useful for a BGP speaker in an autonomous system to receive and accept its own advertised route from a route reflector with more fine-grained route control. For example, the route reflector can change certain attributes of a route as desired, and then re- advertise it back to the originator. Though it is possible to perform such policy control directly at the originator, it may be operationally cumbersome in a network with a large number of border routers having complex BGP policies. This draft defines a new and well-known BGP community value, ACCEPT_OWN, that signals a BGP speaker to accept an UPDATE message and process the associated routes even when the ORIGINATOR_ID or the NEXT_HOP matches that of the receiving speaker. |
| | Conversion of MIB to XSD for NETCONF |
| |
|
NETCONF needs a data model for its process of standardization. This documentation defines a standard expression of SMI MIBs in XSD for NETCONF to ensure uniformity, general interoperability and reusability of existing MIBs. In addition, we define a XML schema to give a restriction and validation to translated XSD files. |
| | The Camellia Cipher in OpenPGP |
| |
|
This document presents the necessary information to use the Camellia symmetric block cipher in the OpenPGP protocol. |
| | Best Current Practices for NAT Traversal for SIP |
| |
|
Traversal of the Session Initiation Protocol (SIP) and the sessions it establishes through Network Address Translators (NAT) is a complex problem. Currently there are many deployment scenarios and traversal mechanisms for media traffic. This document aims to provide concrete recommendations and a unified method for NAT traversal as well as documenting corresponding flows. |
| | SIP (Session Initiation Protocol) Usage of the Offer/Answer Model |
| |
|
The Session Initiation Protocol (SIP) utilizes the offer/answer model to establish and update multimedia sessions using the Session Description Protocol (SDP). The description of the offer/answer model in SIP is dispersed across multiple RFCs. This document summarizes all the current usages of the offer/answer model in SIP communication. |
24/04/2008
| |
|
| |
| | IMAP Support for UTF-8 |
| |
|
This specification extends the Internet Message Access Protocol version 4rev1 (IMAP4rev1) to support unencoded international characters in user names, mail addresses and message headers. This is an early draft and intended as a framework for discussion. Please do not deploy implementations of this draft. |
| | LISP Alternative Topology (LISP+ALT) |
| |
|
This document describes a method of building an alternative, logical topology for managing Endpoint Identifier to Routing Locator mappings using the Locator/ID Separation Protocol. The logical network is built as an overlay on the public Internet using existing technologies and tools, specifically the Border Gateway Protocol and the Generic Routing Encapsulation. An important design goal for LISP+ALT is to allow for the relatively easy deployment of an efficient mapping system while minimizing changes to existing hardware and software. |
| | PPP Over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics |
| |
| | draft-bberry-rfc4938bis-00.txt |
| | Date: |
24/04/2008 |
| | Authors: |
Bo Berry, Stan Ratliff, Ed Paradise, Tim Kaiser, Mike Adams |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
txt |
|
This document extends the Point-to-Point over Ethernet (PPPoE) Protocol with an optional credit-based flow control mechanism and an optional Link Quality Metric report. These optional extensions improve the performance of PPPoE over media with variable bandwidth and limited buffering, such as mobile point-to-point radio links. |
| | Advertising an IPv4 NLRI with an IPv6 Next Hop |
| |
|
MultiProtocol-BGP (MP-BGP) specifies that the set of Network Layer protocols to which the address carried in the Next Hop field may belong is determined by the Address Family Identifier (AFI) and the Subsequent Address Family Identifier (SAFI). The current AFI/SAFI definitions for the IPv4 address family only have provisions for advertising a Next Hop address that belongs to the IPv4 protocol when advertising an IPv4 Network Layer Reachability Information (NLRI) or a VPN-IPv4 NLRI. This document specifies the extensions necessary to allow advertising an IPv4 NLRI or a VPN-IPv4 NLRI with a Next Hop address that belongs to the IPv6 protocol. This comprises an extension of the AFI/SAFI definitions to allow the address of the Next Hop for an IPv4 NLRI or VPN-IPv4 NLRI to also belong to the IPv6 protocol, the encoding of the Next Hop in order to determine which of the protocols the address actually belongs to, and a new BGP Capability allowing MP-BGP Peers to dynamically discover whether they can exchange IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 Next Hop. |
23/04/2008
| |
|
| |
| | Congestion Control in the RFC Series |
| |
|
This document is an informational snapshot produced by the IRTF's Internet Congestion Control Research Group (ICCRG). It provides a survey of congestion control topics described by documents in the RFC series. This does not modify or update the specifications or status fo the RFC documents that are discussed. It may be used as a reference or starting point for the future work of the research group, especially in noting gaps or open issues in the current IETF standards. |
| | Guidelines for Free Standards in the IETF |
| |
|
This document discuss copyright and patents in standard documents from a free software perspective. The document contains instructions for document authors who wish to encourage and enable free software implementations of their standard. It can also be used as a check- list for document reviewers and patent license reviewers. |
| | SNMP Trace Analysis Definitions |
| |
|
The Network Management Research Group (NMRG) started an activity to collect traces of the Simple Network Management Protocol (SNMP) from operational networks. To analyze these traces, it is necessary to split potentially large traces into more manageable pieces that make it easier to deal with large data sets and simplify the analysis of the data. This document provides some common definitions that have been found useful for implementing tools to support trace analysis. This document mainly serves as a reference for the definitions underlying these tools and it is not meant to explain all the motivation and reasoning behind the definitions. Some of this background information can be found in other research papers. |
| | Multi-Hop Discovery of Candidate Access Routers (MHD-CAR) |
| |
|
The Candidate Access Router Discovery (CARD) protocol specified in [1] is aimed to enable seamless IP layer handover by aiding seamless Layer 3 (L3) mobility management protocols like Fast Mobile IP (FMIP) by providing identity and capabilities information of the candidate access routers (CARs) to the mobile node (MN) prior to the initiation of handover while the MN is still connected to its current AR. The specifications as laid down in [1], however, specifies a very generic mechanism of the CARD protocol effective only in specific network architecture scenarios and it doesn't take into account the stringent requirements of a fast moving MN and real time communication sessions, especially when it comes to resolving candidate access routers that my be adjacent geographically but not topologically. This draft addresses the expected shortcomings of the base CARD protocol with respect to fast moving MNs and real time communication sessions by proposing extensions that is expected to improve and/or enhance the performance of the generic CARD protocol as specified in [1]. |
| | 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. |
22/04/2008
| |
|
| |
| | Internationalized Email Headers |
| |
|
Full internationalization of electronic mail requires not only the capability to transmit non-ASCII content, to encode selected information in specific header fields, and to use non-ASCII characters in envelope addresses. It also requires being able to express those addresses and information based on them in mail header fields. This document specifies an experimental variant of Internet mail that permits the use of Unicode encoded in UTF-8, rather than ASCII, as the base form for Internet email header field bodies. This form is permitted in transmission only if authorized by an SMTP extension, as specified in an associated specification. |
| | Portable Symmetric Key Container |
| |
|
This document specifies a symmetric key format for transport and provisioning of symmetric keys (for example One Time Password (OTP) shared secrets or symmetric cryptographic keys) to different types of crypto modules such as a strong authentication device. The standard key transport format enables enterprises to deploy best-of-breed solutions combining components from different vendors into the same infrastructure. This work is a joint effort by the members of OATH (Initiative for Open AuTHentication) to specify a format that can be freely distributed to the technical community. The authors believe that a common and shared specification will facilitate adoption of two- factor authentication on the Internet by enabling interoperability between commercial and open-source implementations. |
| | IMAP4 Multimailbox SEARCH Extension |
| |
|
The IMAP4 specification allows the searching only of the selected mailbox. A user often wants to search multiple mailboxes, and a client that wishes to support this must issue a series of SELECT and SEARCH commands, waiting for each to complete before moving on to the next. This extension allows a client to search multiple mailboxes with one command, limiting the round-trips and waiting for various searches to complete. This also introduces mailbox field in ESEARCH responses, allowing a client to pipeline the searches if it chooses.Note A revised version of this draft document will be submitted to the RFC editor as a Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested, and should be sent to ietf-imapext@imc.org. |
| | URI Scheme for Java(tm) Message Service 1.0 |
| |
| | draft-merrick-jms-uri-03.txt |
| | Date: |
22/04/2008 |
| | Authors: |
Dongbo Xiao, Roland Merrick, Peter Easton, Derek Rokicki, Eric Johnson |
| | Working Group: |
Individual Submissions (none) |
| | Formats: |
xml txt |
|
This document defines the format of Uniform Resource Identifiers (URI) as defined in [RFC3986], for designating connections and destination addresses used in the Java(tm) Messaging Service (JMS) [REF-JMS]. It was originally designed for particular uses, but should have general applicability wherever a JMS URI is needed to describe the connection to a JMS provider, and access to a JMS destination. The syntax of this 'jms' URI is not compatible with any known current vendor implementation, but the expressivity of the format should permit all vendors to use it. |
| | Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol |
| |
|
An authenticated encryption algorithm combines encryption and integrity into a single operation; such algorithms may also be referred to as combined modes of an encryption cipher or as combined mode algorithms. This document describes the use of authenticated encryption algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) protocol. The use of two specific authenticated encryption algorithms with the IKEv2 Encrypted Payload is also described; these two algorithms are the Advanced Encryption Standard (AES) in Galois/Counter Mode (AES GCM) and AES in Counter with CBC-MAC Mode (AES CCM). Additional documents may describe the use of other authenticated encryption algorithms with the IKEv2 Encrypted Payload. |
| | Proposed High-level Changes From IDNA2003 To IDNA200x |
| |
|
This document lists the changes that are proposed for IDNA200x. It covers both the changes in the initial documents from the design team and other changes proposed in the Working Group. |
| | Industrial Routing Requirements in Low Power and Lossy Networks |
| |
|
Wireless, low power field devices enable industrial users to significantly increase the amount of information collected and the number of control points that can be remotely managed. The deployment of these wireless devices will significantly improve the productivity and safety of the plants while increasing the efficiency of the plant workers. For wireless devices to have a significant advantage over wired devices in an industrial environment the wireless network needs to have three qualities: low power, high reliability, and easy installation and maintenance. The aim of this document is to analyze the requirements for the routing protocol used for low power and lossy networks (L2N) in industrial environments. |
| | OSPF Link-local Signaling |
| |
|
OSPF is a link-state intra-domain routing protocol. OSPF routers exchange information on a link using packets that follow a well- defined fixed format. The format is not flexible enough to enable new features which need to exchange arbitrary data. This document describes a backward-compatible technique to perform link-local signaling, i.e., exchange arbitrary data on a link. |
21/04/2008
| |
|
| |
| | MIP6-bootstrapping for the Integrated Scenario |
| |
|
Mobile IPv6 bootstrapping can be categorized into two primary scenarios, the split scenario and the integrated scenario. In the split scenario, the mobile node's mobility service is authorized by a different service authorizer than the network access authorizer. In the integrated scenario, the mobile node's mobility service is authorized by the same service authorizer as the network access service authorizer. This document defines a method for home agent information discovery for the integrated scenario. |
| | IMAP METADATA Extension |
| |
|
The METADATA extension to the Internet Message Access Protocol permits clients and servers to maintain "annotations" or "meta data" on IMAP servers. It is possible to have annotations on a per-mailbox basis or on the server as a whole. For example, this would allow comments about the purpose of a particular mailbox to be "attached" to that mailbox, or a "message of the day" containing server status information to be made available to anyone logging in to the server. |
| | The Atom "deleted-entry" Element |
| |
|
This specification adds mechanisms to the Atom Syndication Format which Atom Feed publishers can use to explicitly identify Atom entries that have been removed from an Atom feed. |
| | The Session Initiation Protocol (SIP) P-Served-User Private-Header (P-Header) |
| |
|
This document specifies the SIP P-Served-User P-header. This header field addresses an issue that was found in the 3rd-Generation Partnership Project (3GPP) IMS (IP Multimedia Subsystem) between an S-CSCF (Serving Call Session Control Function) and an AS (Application Server) on the ISC (IMS Subsystem Service Control) interface to convey the identity of the served user and the session case that applies to this particular communication session and application invocation. |
| | A Profile for Bogon Origin Attestations (BOAs) |
| |
|
This document defines a standard profile for Bogon Origin Attestations (BOAs). A BOA is a digitally signed object that provides a means of verifying that an IP address block holder has not authorized any Autonomous System (AS) to originate routes that are equivalent to any of the addresses listed in the BOA, and also provides a means of verifying that BGP speaker is not using an AS as a BGP speaker without appropriate authority to use that AS. The proposed application of BOAs is intended to fit within the requirements for adding security measures to inter-domain routing, including the ability to support incremental and piecemeal deployment of such measures, and does not require any changes to the specification of BGP. |
| | End-Point Channel Bindings for IPsec Using IKEv2 and Public Keys |
| |
|
This document specifies the end-point channel bindings for "IPsec channels" where the peers used the Internet Key Exchange protocol version 2 (IKEv2) and where they used public keys and/or certificates to authenticate each other. Specifically, we use hashes of the end- points' public keys. |
| | Unique Channel Bindings for IPsec Using IKEv2 |
| |
|
This document specifies the unique channel bindings for IPsec channels constructed by connection latching, where the peers used the Internet Key Exchange protocol version 2 (IKEv2). New IKEv2 notification payloads are used to select an IKE_SA from which to derive the unique channel bindings for a given IPsec channel. |
19/04/2008
| |
|
| |
| | Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications |
| |
|
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a mapping of SYSLOG messages to Simple Network Management Protocol (SNMP) notifications. |
18/04/2008
| |
|
| |
| | Transmission of IP over Ethernet over IEEE 802.16 Networks |
| |
|
This document describes the transmission of IPv4 over Ethernet as well as IPv6 over Ethernet in an access network deploying the IEEE 802.16 cellular radio transmission technology. The Ethernet on top of IEEE 802.16 is realized by bridging connections which the IEEE 802.16 provides between a base station and its associated subscriber stations. Due to the resource constraints of radio transmission systems and the limitations of the IEEE 802.16 MAC functionality for the realization of an Ethernet, the transmission of IP over Ethernet over IEEE 802.16 may considerably benefit by adding IP specific support functions in the Ethernet over IEEE 802.16 while maintaining full compatibility with standard IP over Ethernet behavior. |
| | Header Protection for S/MIME |
| |
|
In the current S/MIME Version 3.1 specification, the header protection is achieved by encoding the whole message as a message/rfc822 MIME object. Since this approach poses some practical problems, we propose to use signed attributes to implement a fully backward compatible S/MIME header protection scheme. |
17/04/2008
| |
|
| |
| | HTTP Enabled Location Delivery (HELD) |
| |
|
A Layer 7 Location Configuration Protocol (L7 LCP) is described that is used for retrieving location information from a server within an access network. The protocol includes options for retrieving location information in two forms: by value and by reference. The protocol is an extensible application-layer protocol that is independent of session-layer. This document describes the use of Hypertext Transfer Protocol (HTTP) as a transport for the protocol. |
| | Three-Way Handshake for Intermediate System to Intermediate System (IS-IS) Point-to-Point Adjacencies |
| |
|
The IS-IS routing protocol (Intermediate System to Intermediate System, ISO 10589) requires reliable protocols at the link layer for point-to-point links. As a result, it does not use a three-way handshake when establishing adjacencies on point-to- point media. This paper defines a backward-compatible extension to the protocol that provides for a three-way handshake. It is fully interoperable with systems that do not support the extension. Additionally, the extension allows the robust operation of more than 256 point-to-point links on a single router. This extension has been implemented by multiple router vendors; this paper is provided to the Internet community in order to allow interoperable implementations to be built by other vendors. |
| | 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. |
| | Contexts for IMAP4 |
| |
|
The IMAP4rev1 protocol has powerful search facilities as part of the core protocol, but lacks the ability to create live, updated results which can be easily handled. This memo provides such an extension, and shows how it can be used to provide a facility similar to virtual mailboxes. |
| | Extended URLFETCH for binary and converted parts |
| |
|
The URLFETCH command defined as part of URLAUTH provides a mechanism for third-parties to gain access to data held within messages in a user's private store, however, this data is sent verbatim, which is not suitable for a number of applications. This memo specifies a method for obtaining data in forms suitable for non-mail applications. |
| | BGP protocol extensions using attribute for Path Computation Element (PCE) Discovery |
| |
|
It is highly desirable for Path Computation Clients (PCCs) to be able to dynamically discover a set of Path Computation Elements (PCEs) when PCCs/PCEs request a path computation to PCEs within an AS and across ASs. In such a scenario, specifically BGP/MPLS IP-VPNs, it is advantageous to use BGP to distribute PCE information. This document defines a new attribute and describes how PCE information can be carried using BGP. |
| | PCEP extensions for a BGP/MPLS IP-VPN |
| |
|
It is highly desirable for VPN customers to be able to dynamically establish their MPLS TE LSPs in the context of a BGP/MPLS IP-VPN. In such a scenario, it is advantageous to use PCE to calculate customer MPLS TE LSPs. This document defines PCEP extensions for BGP/MPLS IP- VPNs. |
16/04/2008
| |
|
| |
| | Analysis of Inter-domain Label Switched Path (LSP) Recovery |
| |
|
Protection and recovery are important features of service offerings in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. Increasingly, MPLS and GMPLS networks are being extended from single domain scope to multi-domain environments. Various schemes and processes have been developed to establish Label Switched Paths (LSPs) in multi-domain environments. These are discussed in RFC 4726: A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering. This document analyzes the application of these techniques to protection and recovery in multi-domain networks. The main focus for this document is on establishing end-to-end diverse Traffic Engineering (TE) LSPs in multi-domain networks. Takeda et al. Expires October 2008 [page 1] draft-ietf-ccamp-inter-domain-recovery-analysis-05.txt April 2008 |
| | Guidelines for IP Flow Information eXport (IPFIX) Testing |
| |
|
This document presents a list of tests for implementers of IP Flow Information Export (IPFIX) compliant Exporting Processes and Collecting Processes. This document specifies guidelines for a series of tests that can be run on the IPFIX Exporting Process and Collecting Process in order to probe the conformity and robustness of the IPFIX protocol implementations. These tests cover all important functions, in order to gain a level of confidence in the IPFIX implementation. Therefore they allow the implementer to perform interoperability or plug tests with other IPFIX Exporting Processes and Collecting Processes. |
| | Remote Direct Memory Access Transport for Remote Procedure Call |
| |
| | draft-ietf-nfsv4-rpcrdma-08.txt |
| | Date: |
16/04/2008 |
| | Authors: |
Thomas Talpey, Brent Callaghan, Intellectual Property |
| | Working Group: |
Network File System Version 4 (nfsv4) |
| | Formats: |
txt |
|
A protocol is described providing Remote Direct Memory Access (RDMA) as a new transport for Remote Procedure Call (RPC). The RDMA transport binding conveys the benefits of efficient, bulk data transport over high speed networks, while providing for minimal change to RPC applications and with no required revision of the application RPC protocol, or the RPC protocol itself. |
| | NFS Direct Data Placement |
| |
|
This draft defines the bindings of the various Network File System (NFS) versions to the Remote Direct Memory Access (RDMA) operations supported by the RPC/RDMA transport protocol. It describes the use of direct data placement by means of server-initiated RDMA operations into client-supplied buffers for implementations of NFS versions 2, 3, 4 and 4.1 over such an RDMA transport. |
| | NAT Port Mapping Protocol (NAT-PMP) |
| |
|
This document describes a protocol for automating the process of creating Network Address Translation (NAT) port mappings. Included in the protocol is a method for retrieving the external IP address of a NAT gateway, thus allowing a client to make this external IP address and port number known to peers that may wish to communicate with it. This protocol is implemented in current Apple products including Mac OS X, Bonjour for Windows, and AirPort wireless base stations. |
| | IMAP Response Codes |
| |
|
IMAP responses consist of a response type (OK, NO, BAD), an optional machine-readable response code and a human-readable text. This document collects and documents a variety of machine-readable response codes, for better interoperation and error reporting.1. Conventions Used in This Document Formal syntax is defined by [RFC5234] as modified by [RFC3501]. Example lines prefaced by "C:" are sent by the client and ones prefaced by "S:" by the server. "[...]" means elision. |
| | Website Parse Templates |
| |
|
This document defines general concepts and terminology for Website Parse Templates creation that are used to provide web crawlers/data parsers with proper information about website structure and content. |
| | IKEv2 Mediation Extension |
| |
|
This document describes the IKEv2 Mediation Extension (IKE-ME), a connectivity extension to the Internet Key Exchange IKEv2. IKE-ME allows two peers, each behind one or more Network Address Translators (NATs) or firewalls to establish a direct and secure connection without the need to configure any of the intermediate network devices. To establish this direct connection, a process similar to Interactive Connectivity Establishment (ICE) is used. |
| | Elliptic Curve Cryptography Subject Public Key Information |
| |
|
This document specifies the syntax and semantics for the Subject Public Key Information field in certificates that support Elliptic Curve Cryptography. This document updates RFC 3279. |
| | A Call Control and Multi-party usage framework for the Session Initiation Protocol (SIP) |
| |
| | draft-ietf-sipping-cc-framework-10.txt |
| | Date: |
16/04/2008 |
| | Authors: |
Rohan Mahy, Robert Sparks, Jonathan Rosenberg, Dan Petrie, Alan Johnston |
| | Working Group: |
Session Initiation Proposal Investigation (sipping) |
| | Formats: |
xml txt |
|
This document defines a framework and requirements for call control and multi-party usage of SIP. To enable discussion of multi-party features and applications we define an abstract call model for describing the media relationships required by many of these. The model and actions described here are specifically chosen to be independent of the SIP signaling and/or mixing approach chosen to actually setup the media relationships. In addition to its dialog manipulation aspect, this framework includes requirements for communicating related information and events such as conference and session state, and session history. This framework also describes other goals that embody the spirit of SIP applications as used on the Internet. |
15/04/2008
| |
|
| |
| | Mobile IPv6 Location Privacy Solutions |
| |
|
Mobile IPv6 [10] enables mobile nodes to remain reachable while roaming on the Internet. With its current specification, the location of a mobile node can be revealed and its movement can be tracked by simply monitoring its IP packets. In this document, we consider the MIP6 location privacy problem described in [14] and propose efficient and secure techniques to protect the location privacy of a mobile node. |
| | Real-time Inter-network Defense |
| |
|
Network security incidents, such as system compromises, worms, viruses, phishing incidents, and denial of service, typically result in the loss of service, data, and resources both human and system. Network providers and Computer Security Incident Response Teams need to be equipped and ready to assist in communicating and tracing security incidents with tools and procedures in place before the occurrence of an attack. Real-time Inter-network Defense outlines a proactive inter-network communication method to facilitate sharing incident handling data while integrating existing detection, tracing, source identification, and mitigation mechanisms across for a complete incident handling solution. Combining these capabilities in a communication system provides a way to achieve higher security levels on networks. Policy guidelines for handling incidents are recommended and can be agreed upon by a consortium using the security recommendations and considerations. |
| | Routing and Addressing Problem Statement |
| |
|
Note this document is unchanged relative to -01, which recently expired. There has been much discussion over the last years about the overall scalability of the Internet routing system. This document attempts to describe what the actual problem is and the various demands being placed on the routing system that have made finding a straightforward solution difficult. Comments should be sent to rrg@psg.com or to radir@ietf.org. |
| | Conventions for the Use of the Session Description Protocol (SDP) for Circuit-Switched Bearer Connections in the Public Switched Telephone Network (PSTN) |
| |
|
This memo describes use cases, requirements, and protocol conventions for using the Session Description Protocol (SDP) Offer/Answer model for establishing circuit-switched bearer connections in the Public Switched Telephone Network (PSTN). Additionally, this memo pro | |