---

"Internet Email Subaddressing", Dave Cridland, 16-Nov-07. ( bytes)

It is often useful for a single user to have multiple email addresses which can be used to assist categorizing incoming email. One way of doing this is to divide the local-part of an email address into user and detail parts. The user part is used to route the message within the specified domain and the detail part is used to route the message according to a particular user's wishes. This specification formalizes the de-facto standard for subaddressing in use today and includes advice and requirements for final delivery agents, MUAs and mail list servers which wish to support subaddressing.

"Salted Challenge Response Authentication Mechanism (SCRAM)", Chris Newman, 14-Dec-07. ( bytes)

The secure authentication mechanism most widely deployed and used by Internet application protocols is the transmission of clear-text passwords over a channel protected by Transport Layer Security (TLS). There are some significant security concerns with that mechanism, which could be addressed by the use of a challenge response authentication mechanism protected by TLS. Unfortunately, the challenge response mechanisms presently on the standards track all fail to meet requirements necessary for widespread deployment, and have had success only in limited use. This specification describes the Salted Challenge Response Authentication Mechanism (SCRAM), which addresses the security concerns and meets the deployability requirements. When used in combination with TLS or an equivalent security layer, this mechanism could improve the status-quo for application protocol authentication and provide a suitable choice for a mandatory-to-implement mechanism for future application protocol standards.

"Additional ECC Groups For IKE and IKEv2", Daniel R. L. Brown, 10-Oct-06. ( bytes)

This document describes additional elliptic curve groups for use in IKE (as defined in RFC 2409) and IKEv2 (as defined in RFC 3406). These groups are defined to align IKE and IKEv2 with other ECC implementations and standards, and in addition, many of them provide higher strength than the previousley defined Oakley groups.

"Geographic extensions for HTTP transactions", Andrew Daviel, Felix Kaegi, Martin Kofahl, 7-Dec-07. ( bytes)

This memo describes a method of adding simple geographic position or region information to HTTP transactions using extension headers. It allows location-based services on the World Wide Web, without the additional overhead of geographic query requests and possibly graphical input. Extension headers transmit predefined or detected position information to reflect a location that the requesting agent is interested in. This information may be used by a server to present appropriate position-dependent responses, such as search engine results or weather maps.

"Cisco Systems' Simple Certificate Enrollment Protocol(SCEP)", Xiaoyi Liu, 3-Dec-07. ( bytes)

This document specifies the Simple Certificate Enrollment Protocol, a PKI communication protocol which leverages existing technology by using PKCS#7 and PKCS#10. SCEP is the evolution of the enrollment protocol developed by Verisign, Inc. for Cisco Systems, Inc. It now enjoys wide support in both client and CA implementations.

"LDAP Administrators Address Attribute", Mark Wahl, 6-Sep-07. ( bytes)

Organizations with multiple or outsourced directory servers need the ability for administrators to determine who is responsible for a particular directory server. This document defines an attribute with contact information for a directory server's responsible party, conceptually similar to the 'sysContact' object of SNMP, which can be retrieved from the directory server using the Lightweight Directory Access Protocol.

"Secure Internet Live Conferencing (SILC), Protocol Specification", Pekka Riikonen, 23-Jan-07. ( bytes)

This memo describes a Secure Internet Live Conferencing (SILC) protocol which provides secure conferencing services over insecure network channel. SILC provides advanced and feature rich conferencing services with security as main design principal. Strong cryptographic methods are used to protect SILC packets inside the SILC network. Three other specifications relates very closely to this memo; SILC Packet Protocol [SILC2], SILC Key Exchange and Authentication Protocols [SILC3] and SILC Commands [SILC4].

"SILC Packet Protocol", Pekka Riikonen, 19-Jan-07. ( bytes)

This memo describes a Packet Protocol used in the Secure Internet Live Conferencing (SILC) protocol, specified in the Secure Internet Live Conferencing, Protocol Specification [SILC1]. This protocol describes the packet types and packet payloads which defines the contents of the packets. The protocol provides secure binary packet protocol that assures that the contents of the packets are secured and authenticated.

"SILC Key Exchange and Authentication Protocols", Pekka Riikonen, 19-Jan-07. ( bytes)

This memo describes two protocols used in the Secure Internet Live Conferencing (SILC) protocol, specified in the Secure Internet Live Conferencing, Protocol Specification [SILC1]. The SILC Key Exchange (SKE) protocol provides secure key exchange between two parties resulting into shared secret key material. The protocol is based on Diffie-Hellman key exchange algorithm and its functionality is derived from several key exchange protocols. The second protocol, SILC Connection Authentication protocol provides user level authentication used when creating connections in SILC network. The protocol supports passphrase (pre-shared secret) authentication and public key (and certificate) authentication based on digital signatures.

"LDAP Transactions", Kurt Zeilenga, 20-Nov-07. ( bytes)

Lightweight Directory Access Protocol (LDAP) update operations, such as Add, Delete, and Modify operations, have atomic, consistency, isolation, durability (ACID) properties. Each of these update operations act upon an entry. It is often desirable to update two or more entries in a single unit of interaction, a transaction. Transactions are necessary to support a number of applications including resource provisioning. This document extends LDAP to support transactions.

"SILC Commands", Pekka Riikonen, 19-Jan-07. ( bytes)

This memo describes the commands used in the Secure Internet Live Conferencing (SILC) protocol, specified in the Secure Internet Live Conferencing, Protocol Specification [SILC1]. The SILC Commands are very important part of the SILC protocol. Usually the commands are used by SILC clients to manage the SILC session, but also SILC servers may use the commands. This memo specifies detailed command messages and command reply messages.

"IPv4 Address Conflict Detection", Stuart Cheshire, 20-Feb-08. ( bytes)

When two hosts on the same link attempt to use the same IPv4 address at the same time (except in rare special cases where this has been arranged by prior coordination) problems ensue for one or both hosts. This document describes (i) a simple precaution that a host can take in advance to help prevent this misconfiguration from happening, and (ii) if this misconfiguration does occur, a simple mechanism by which a host can passively detect after-the-fact that it has happened, so that the host or administrator may respond to rectify the problem.

"URI Scheme for GSM Short Message Service", Erik Wilde, Antti Vaha-Sipila, 18-Dec-07. ( bytes)

This memo specifies the Uniform Resource Identifier (URI) scheme "sms" for specifying one or more recipients for an SMS message. SMS messages are two-way paging messages that can be sent from and received by a mobile phone or a suitably equipped networked device.

"Media Gateway Control Protocol Fax Package", Flemming Andreasen, David Hancock, 20-Feb-08. ( bytes)

This document defines a Media Gateway Control Protocol (MGCP) package to support fax calls. The package allows for fax calls to be supported in two different ways. The first one utilizes ITU-T Recommendation T.38 for fax relay under the control of the Call Agent. The second one lets the gateway decide upon a method for fax transmission as well as handle the details of the fax call without Call Agent involvement.

"Analysis of Inter-Domain Routing Requirements and History", Avri Doria, Elwyn Davies, 7-Jan-08. ( bytes)

This document analyses the state of Inter-Domain Routing (IDR) and the relationship between inter-domain and intra-domain routing. The analysis is carried out with respect to RFC 1126 and other IDR requirements and design efforts as it appeared to be in 2001 with editorial additions reflecting developments up to 2006. It is the companion document to "Requirements for Inter-Domain Routing" [I-D.irtf-routing-reqs], which is a discussion of requirements for the future routing architecture and future routing protocols. This document summarizes discussions held several years ago by members of the IRTF Routing Research Group (IRTF RRG) and other interested parties. The document is published with the support of the IRTF RRG as a record of the work completed at that time, but with the understanding that it does not necessarily represent either the latest technical understanding or the technical concensus of the research group at the date of publication. [Note to RFC Editor: Please replace the reference in the abstract with a non-reference quoting the RFC number of the companion document when it is allocated, i.e., '(RFC xxxx)' and remove this note.]

"IMAP METADATA Extension", Cyrus Daboo, 21-Apr-08. ( bytes)

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.

"Web Distributed Authoring and Versioning (WebDAV) SEARCH", Julian Reschke, Surendra Reddy, Jim Davis, Alan Babich, 18-Feb-08. ( bytes)

This document specifies a set of methods, headers, properties and content-types composing WebDAV SEARCH, an application of the HTTP/1.1 protocol to efficiently search for DAV resources based upon a set of client-supplied criteria.

"An IPv4 Flowlabel Option", Thomas Dreibholz, 9-Jan-08. ( bytes)

This draft defines an IPv4 option containing a flowlabel that is compatible to IPv6. It is required for simplified usage of IntServ and interoperability with IPv6.

"SILC Message Flag Payloads", Pekka Riikonen, 26-May-05. ( bytes)

This memo describes the data payloads associated with the SILC Message Flags, as defined in the SILC Packet Protocol specification [SILC2]. The purpose of the Message Flags is to augment the function of the Message Payload used to send both private and channel messages, by allowing the sender to tell the receiver what type of data the payload includes, and how the data should be processed. Some of the Message Flags may define additional payloads to be associated with the flag, and this memo describes these payloads.

"User Online Presence and Information Attributes", Pekka Riikonen, 19-Jan-07. ( bytes)

This document defines set of attributes that can represent the online user's presence in a network, and to provide general information about the user. The purpose is to provide a generic mechanism to share online presence and status, and general information about the user to be used in several kind of network protocols and applications. These attributes could be used by for example chat and conferencing protocols (such as Instant Message protocols), network games, and other similar network protocols and applications that has online users in a network.

"Dynamic Hostname Exchange Mechanism for OSPF", Subbaiah Venkata, Sanjay Harwani, Carlos Pignataro, Danny McPherson, 29-Jan-08. ( bytes)

Currently, there does not exist a simple and dynamic mechanism for routers running OSPF to learn about symbolic hostnames just like for routers running IS-IS. This document defines a new OSPF Router Information (RI) TLV which allows the OSPF routers to flood their hostname-to-Router ID mapping information across the OSPF network. This mechanism is applicable to both OSPFv2 and OSPFv3.

"Using PPP-over-Ethernet (PPPoE) in Wireless LANs", Giuseppe Paterno, 26-May-05. ( bytes)

This document explores the use of Point-To-Point Protocol over Ethernet (PPPoE) to provide wireless access to the Internet and suggests how the infrastructure can be deployed. The document targets consumers, corporations, Internet Service Providers, and mobile phone operators that provide user access through Wireless LANs technologies such as IEEE 802.11.

"EAP-Support in Smartcard", Guy Pujolle, Pascal Urien, 20-Feb-08. ( bytes)

This document describes the functional interface, based on the ISO7816 standard, to EAP methods, fully and securely executed in smart cards. This class of tamper resistant device may deliver client or server services; it can compute Root Keys from an Extended Master Session Key (EMSK).

"Guidelines for Mandating the Use of IPsec Version 2", Steven Bellovin, 8-Oct-07. ( bytes)

The Security Considerations sections of many Internet Drafts say, in effect, "just use IPsec". While this is sometimes correct, more often it will leave users without real, interoperable security mechanisms. This memo offers some guidance on when IPsec Version 2 should and should not be specified.

"Split Multi-link Trunking (SMLT)", Roger Lapuh, 16-Nov-07. ( bytes)

This document describes Split Multi-link Trunking (SMLT) for bridged and routed networks. SMLT enables topologies with upstream node redundancy for increased reliability of Layer 2 link aggregation subnetworks based on [IEEE 802.3ad] and router redundancy based on VRRP [RFC3768]. SMLT is an improvement over Multi-Link Trunking (MLT), a method of link aggregation that allows multiple Ethernet links to be aggregated together, and handled as a single logical trunk. MLT can be realized via many different link aggregation mechanisms. Several methods of MLT are in use today; one example is [IEEE 802.3ad]. SMLT is MLT with links of a link-aggregation group connected to ports on two different devices (e.g. SMLT client and aggregation device). Unlike MLT, at least one end of a link-aggregated group is dual-homed to two different SMLT aggregation devices. In many cases those devices act as bridges (switches) as well as L3 routers (Routing Switches). These two redundant SMLT aggregation devices can share one or more VRRP routing instances; for that SMLT-VRRP extends the VRRP functionality to an active-active router concept, where both SMLT aggregation device route traffic for a common VRRP-ID, thus load balancing traffic not only for L2 but also for L3.

"Reorder Density and Reorder Buffer-occupancy Density - Metrics for Packet Reordering Measurements", Anura Jayasumana, 23-Jul-07. ( bytes)

This document presents two metrics for packet reordering, namely, Reorder Density (RD) and Reorder Buffer-occupancy Density (RBD). A threshold is used to clearly define when a packet is considered lost, to bound computational complexity at O(N), and to keep the memory. requirement for evaluation independent of N, where N is the length of the packet sequence. RD is a comprehensive metric that captures the characteristics of reordering, while RBD evaluates the sequences from the point of view of recovery from reordering. These metrics are simple to compute yet comprehensive in their characterization of packet reordering. The measures are robust and orthogonal to packet loss and duplication.

"Reliable Server Pooling Applicability for IP Flow Information Exchange", Lode Coene, 9-Jan-08. ( bytes)

This document describes the applicability of the Reliable Server Pooling architecture to the IP Flow Information Exchange using the Aggregate Server Access Protocol (ASAP) functionality of RSerPool only. Data exchange in IPFIX between the router and the data collector can be provided by a limited retransmission protocol.

"Prepaid Extensions to Remote Authentication Dial-In User Service (RADIUS)", Avi Lior, Parviz Yegani, Kuntal Chowdhury, Hannes Tschofenig, Andreas Pashalidis, 25-Feb-08. ( bytes)

This document specifies an extension to the Remote Authentication Dial-In User Service (RADIUS) protocol that enables service providers to charge for prepaid services. The supported charging models supported are volume-based, duration-based, and based on one-time events.

"Lumas - Language for Universal Message Abstraction and Specification", Peter Cordell, 2-Feb-07. ( bytes)

A number of methods and tools are available for defining the format of messages used for application protocols. However, many of these methods and tools have been designed for purposes other than message definition, and have been adopted on the basis that they are available rather than being ideally suited to the task. This often means that the methods make it difficult to get definitions correct, or result in unnecessary complexity and verbosity both in the definition and on the wire. Lumas - Language for Universal Message Abstraction and Specification - has been custom designed for the purpose of message definition. It is thus easy to specify messages in a compact, extensible format that is readily machine manipulated to produce a compact encoding on the wire.

"Memorandum for multi-domain Public Key Infrastructure Interoperability", Masaki Shimaoka, Nelson Hastings, Rebecca Nielsen, 1-Apr-08. ( bytes)

The objective of this document is to establish a terminology framework and to suggest the operational requirements of PKI domain for interoperability of multi-domain Public Key Infrastructure, where each PKI domain is operated under a distinct policy. This document describes the relationships between Certification Authorities (CAs), provides the definition and requirements for PKI domains, and discusses typical models of multi-domain PKI.

"Requirements for Inter-Domain Routing", Avri Doria, 7-Jan-08. ( bytes)

The requirements for routing architectures described in this document were produced by two sub-groups under the IRTF Routing Research Group in 2001, with some editorial updates up to 2006. The two sub-groups worked independently, and the resulting requirements represent two separate views of the problem and of what is required to fix the problem. This document may usefully serve as part of the recommended reading for anyone who works on routing architecture designs for the Internet in the future. The document is published with the support of the IRTF RRG as a record of the work completed at that time, but with the understanding that it does not necessarily represent either the latest technical understanding or the technical consensus of the research group at the date of publication.

"Cisco Systems' Private VLANs: Scalable Security in a Multi-Client Environment", Sanjib HomChaudhuri, Marco Foschiano, 11-Mar-08. ( bytes)

This document describes a mechanism to achieve device isolation through the application of special Layer 2 forwarding constraints. Such mechanism allows end devices to share the same IP subnet while being Layer 2 isolated, which in turn allows network designers to employ larger subnets and so reduce the address management overhead.

"Session Initiation Protocol (SIP) Event Notification Extension for Notification Throttling", Aki Niemi, Krisztian Kiss, 25-Feb-08. ( bytes)

This memo specifies a throttle mechanism for limiting the rate of Session Initiation Protocol (SIP) event notifications. This mechanism can be applied in subscriptions to all SIP event packages, but the mechanism is especially designed to be used in combination with a subscription to a Resource List Server (RLS).

"PATCH Method for HTTP", Lisa Dusseault, James Snell, 3-Jan-08. ( bytes)

Several applications extending HTTP require a feature to do partial resource modification. Existing HTTP functionality only allows a complete replacement of a document. This proposal adds a new HTTP method, PATCH, to modify an existing HTTP resource.

"MANET Extension of OSPF using CDS Flooding", Richard Ogier, Phil Spagnolo, 18-Nov-07. ( bytes)

This document specifies an extension of OSPF for IPv6 to support mobile ad hoc networks (MANETs). The extension, called OSPF-MDR, is designed as a new OSPF interface type for MANETs. OSPF-MDR is based on the selection of a subset of MANET routers, consisting of MANET Designated Routers (MDRs) and Backup MDRs. The MDRs form a connected dominating set (CDS), and the MDRs and Backup MDRs together form a biconnected CDS for robustness. This CDS is exploited in two ways. First, to reduce flooding overhead, an optimized flooding procedure is used in which only (Backup) MDRs flood new LSAs back out the receiving interface; reliable flooding is ensured by retransmitting LSAs along adjacencies. Second, adjacencies are formed only between (Backup) MDRs and a subset of their neighbors, allowing for much better scaling in dense networks. The CDS is constructed using 2-hop neighbor information provided in a Hello protocol extension. The Hello protocol is further optimized by allowing differential Hellos that report only changes in neighbor states. Options are specified for originating router-LSAs that provide full or partial topology information, allowing overhead to be reduced by advertising less topology information.

"SixXS Heartbeat Protocol", Jeroen Massar, 6-Jun-05. ( bytes)

This document proposes a heartbeat protocol for signalling availability of hosts with a specific emphasis on providing a signalling protocol for allowing dynamic non-24/7 endnodes to use tunnel's of the various IPv6 Tunnel Brokers.

"Mixmaster Protocol Version 2", U Moeller, 30-Dec-04. ( bytes)

Most e-mail security protocols only protect the message body, leaving useful information such as the identities of the conversing parties, sizes of messages and frequency of message exchange open to adversaries. This document describes Mixmaster version 2, a mail transfer protocol designed to protect electronic mail against traffic analysis.

"IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP)", Marc Blanchet, Florent Parent, 6-May-08. ( bytes)

A tunnel broker with the Tunnel Setup Protocol (TSP) enables the establishment of tunnels of various inner protocols, such as IPv6 or IPv4, inside various outer protocols packets, such as IPv4, IPv6 or UDP over IPv4 for IPv4 NAT traversal. The control protocol (TSP) is used by the tunnel client to negotiate the tunnel with the broker. A mobile node implementing TSP can be connected to both IPv4 and IPv6 networks whether it is on IPv4 only, IPv4 behind a NAT or on IPv6 only. A tunnel broker may terminate the tunnels on remote tunnel servers or on itself. This document describes the TSP protocol within the model of the tunnel broker model.

"A QoS Model for Signaling IntServ Controlled-Load Service with NSIS", Cornelia Kappler, Xiaoming Fu, Bernd Schloer, 1-Feb-08. ( bytes)

This document describes a QoS Model to signal IntServ controlled load service with QoS NSLP. QoS NSLP is QoS Model agnostic. All QoS Model specific information is carried in an opaque object, the QSPEC. This document hence specifies the QSPEC for controlled load service, how the QSPEC must be processed in QoS NSLP nodes, and how QoS NSLP messages must be used.

"Terminology for Benchmarking LDP Data Plane Convergence", Thomas Eriksson, 19-Feb-08. ( bytes)

This document defines new terms for benchmarking of LDP convergence. These terms are to be used in future methodology documents for benchmarking LDP Convergence. Existing BMWG terminology documents such as IGP Convergence Benchmarking [3] provide useful terms for LDP Convergence benchmarking. These terms are discussed in this document. Applicable terminology for MPLS and LDP defined in MPLS WG RFCs [1] and [2] is also discussed.

"User Session Tracking in RADIUS", Glen Zorn, Avi Lior, 21-Feb-08. ( bytes)

This document defines a set of new messages and attributes designed to allow RADIUS servers to cleanly track user sessions.

"DNS Blacklists and Whitelists", John Levine, 7-May-08. ( bytes)

The rise of spam and other anti-social behavior on the Internet has led to the creation of shared blacklists and whitelists of IP addresses or domains. The DNS has become a de-facto standard method of distributing these blacklists and whitelists. This memo documents the structure and usage of DNS based blacklists and whitelists, and the protocol used to query them. IRTF Notice This document is a product of the Anti-Spam Research Group (ASRG). Comments and discussion may be directed to the ASRG mailing list, asrg@irtf.org. This document is not an IETF Internet Standard. It represents the consensus of the Anti-Spam Research Group of the Internet Research Task Force. It may be considered for standardization by the IETF in the future.

"Guidelines for Management of DNSBLs for Email", Chris Lewis, Matt Sergeant, 7-Apr-08. ( bytes)

The rise of spam and other anti-social behavior on the Internet has led to the creation of shared DNS-based lists of IPs or domains used to help guide email filtering. This memo discusses guidelines for management of public DNSBLs by the operators of such DNSBLs, as well as provide useful background for server administrators who use DNSBLs. It is not intended to advise on the utility or effiacacy of particular DNSBLs or the DNSBL concept in general, nor to assist end users with questions about spam. The document will seek BCP status. Comments and discussion of this document should be addressed to the asrg@ietf.org mailing list.

"RADIUS Error Messages", Glen Zorn, 21-Feb-08. ( bytes)

This document describes new RADIUS protocol elements designed to allow the communication of packet and attribute errors between RADIUS servers and clients.

"Light Weight Access Point Protocol", Pat Calhoun, 2-Mar-07. ( bytes)

In the recent years, there has been a shift in wireless LAN product architectures from autonomous access points to centralized control of light weight access points. The general goal has been to move most of the traditional wireless functionality such as access control (user authentication and authorization), mobility and radio management out of the access point into a centralized controller. The IETF's CAPWAP WG has identified that a standards based protocol is necessary between a wireless Access Controller and Wireless Termination Points (the latter are also commonly referred to as Light Weight Access Points). This specification defines the Light Weight Access Point Protocol (LWAPP), which addresses the CAPWAP's protocol requirements. Although the LWAPP protocol is designed to be flexible enough to be used for a variety of wireless technologies, this specific document describes the base protocol, and an extension that allows it to be used with the IEEE's 802.11 wireless LAN protocol.

"Licklider Transmission Protocol - Specification", Manikantan Ramadas, Scott Burleigh, Stephen Farrell, 20-Jan-08. ( bytes)

This document describes the Licklider Transmission Protocol (LTP), designed to provide retransmission-based reliability over links characterized by extremely long message round-trip times (RTTs) and/or frequent interruptions in connectivity. Since communication across interplanetary space is the most prominent example of this sort of environment, LTP is principally aimed at supporting "long- haul" reliable transmission in interplanetary space, but it has applications in other environments as well. LTP does ARQ of data transmissions by soliciting selective- acknowledgment reception reports. It is stateful, and has no negotiation or handshakes. In an Interplanetary Internet setting deploying the Bundle protocol that is being developed by the Delay Tolerant Networking Research Group, LTP is intended to serve as a reliable "convergence layer" protocol operating in pairwise fashion between adjacent Interplanetary Internet nodes that are in direct RF communication. In that operational scenario, and potentially in some other deployments of the Bundle Protocol, LTP runs directly over a data- link layer protocol; when this is the case, forward error correction coding and/or checksum mechanisms in the underlying data-link layer protocol must assure the integrity of the data passed between the communicating entities. Since no mechanisms for flow control or congestion control are included in the design of LTP, this protocol is not intended or appropriate for ubiquitous deployment in the global Internet. When LTP is run over UDP, it must only be used for software development or in private local area networks. When LTP is not run over UDP, it must be run directly over a protocol, (nominally a link- layer protocol), that meets the requirements specified in section 5. This document is a product of the Delay Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised.

"Internet Mail Architecture", Dave Crocker, 24-Feb-08. ( bytes)

Over its thirty-five year history Internet Mail has undergone significant changes in scale and complexity, as it has become a global infrastructure service. The first standardized architecture for networked email specified little more than a simple split between the user world and the transmission world. Core aspects of the service, such as the styles of mailbox address and basic message format, have remained remarkably constant. However today's Internet Mail is distinguished by many independent operators, many different components for providing service to users and many others for performing message transfer. Public discussion of the service often lacks common terminology and a common frame of reference for these components and their activities. Having a common reference model and terminology facilitates discussion about problems with the service, changes in policy, or enhancement to the service's functionality. This document offers an enhanced Internet Mail architecture that targets description of the existing service, in order to facilitate clearer and more efficient technical, operations and policy discussions about email.

"Population Count Extensions to PIM", Dino Farinacci, Greg Shepherd, 27-Feb-08. ( bytes)

This specification defines a method for providing multicast distribution-tree accounting data for billing and debugging. Simple extensions to the PIM protocol allow a rough approximation of tree- based data in a scalable fashion.

"IP Fast Reroute using tunnels", Stewart Bryant, Clarence Filsfils, Stefano Previdi, Mike Shand, 16-Nov-07. ( bytes)

This draft describes an IP fast re-route mechanism that provides backup connectivity in the event of a link or router failure. In the absence of single points of failure and asymmetric costs, the mechanism provides complete protection against any single failure. If perfect repair is not possible, the identity of all the unprotected links and routers is known in advance. This IP Fast Reroute advanced method was invented in 2002 and draft (draft-bryant-ipfrr-tunnels-00.txt) describing it was submitted to the IETF in May 2004. It was one of the first methods of achieving full repair coverage in an IP Network, and as such the draft has been widely referenced in the academic literature. The authors DO NOT propose that this IPFRR method be implemented since better IPFRR advanced method capable of achieving full repair coverage have subsequently been invented.

"DISCOVER: Supporting Multicast DNS Queries", Bill Manning, Paul Vixie, 17-Nov-05. ( bytes)

This document describes the DISCOVER opcode, an experimental extension to the Domain Name System (DNS) to use multicast queries for resource discovery. A client multicasts a DNS query using the DISCOVER opcode and processes the multiple responses that may result.

"The case against Hop-by-Hop options", Suresh Krishnan, 25-Feb-08. ( bytes)

The Hop-by-Hop option header is a type of IPv6 extension header that has been defined in the IPv6 protocol specification. The contents of this header need to be processed by every node along the path of an IPv6 datagram.This draft highlights the characteristics of this extension header which make it prone to Denial of Service attacks and proposes solutions to minimize such attacks.

"Session Key Transport in RADIUS", Glen Zorn, Hao Zhou, Joseph Salowey, 21-Feb-08. ( bytes)

This document describes an extension to the RADIUS protocol designed to support requests for, and delivery of, session key material between RADIUS clients and servers. The messages described in this document may be used for a wide variety of keying applications.

"RADIUS Attributes for the Delivery of Keying Material", Glen Zorn, 17-Apr-07. ( bytes)

This document defines a set of RADIUS Attributes designed to allow both the secure transmission of cryptographic keying material and strong authentication of any RADIUS message.

"Extending the Space Available for TCP Options", Wesley Eddy, 9-May-05. ( bytes)

This document describes a method for increasing the space available for TCP options. Two new TCP options (LO and SLO) are detailed which reduce the limitations imposed by the TCP header's Data Offset field. The LO option provides this extension after connection establishment, and the SLO option aids in transmission of lengthy connection initialization and configuration options.

"TLS Express", Mohamad Badra, 16-Feb-05. ( bytes)

This document defines a new extension that may be used to add Pre Shared Key authentication functionality to TLS. It is based on the TLS abbreviated handshake and it provides the ability to share a session key for data encryption.

"Securing Neighbour Discovery Proxy Problem Statement", Greg Daley, Jean-Michel Combes, 25-Feb-08. ( bytes)

Neighbour Discovery Proxy is used to provide an address presence on a link from nodes which are no themselves present. It allows a node to receive packets directed at its address by allowing another device to neighbour advertise on its behalf. Neighbour Discovery Proxy is used in Mobile IPv6 and related protocols to provide reachability from nodes on the home network when a Mobile Node is not at home, by allowing the Home Agent to act as proxy. It is also used as a mechanism to allow a global prefix to span multiple links, where proxies act as relays for neighbour discovery messages. Neighbour Discovery Proxy currently cannot be secured using SEND. Today, SEND assumes that a node advertising an address is the address owner and in possession of appropriate public and private keys for that node. This document describes how existing practice for proxy Neighbour Discovery relates to Secured Neighbour Discovery.

"Group Co-operative Route Filtering capability for BGP-4", Susan Hares, Praveen Muley, Keyur Patel, Benson Schliesser, 24-Feb-08. ( bytes)

Currently BGP-4 is capable of carrying multiple (Outbound Route Filters) ORFs entries for a given "AFI/SAFI". Each ORF provides a filter that a route whose NLRI matches AFI/SAFI, must pass through to be transmitted in the BGP Update message. Efficient processing of ORF filters may require ordering of individual ORFs in certain sequence and grouping of ORFs that should be applied together. The grouping functionality also provides the support for logical OR operation between the grouped ORFs. This group ORF provides an ORF type that specifies that ordering and grouping. The route set that passes set of ORFs running in a "Group ORF" will pass the same ORFs sent in normal ORFs.

"Mobile IPv6 - NSIS Interaction for Firewall traversal", Niklas Steinleitner, Xiaoming Fu, Franck Le, 16-Nov-07. ( bytes)

Most of the firewalls deployed today are Mobile IPv6 unaware. Widespread Mobile IPv6 deployment is not possible unless Mobile IPv6 messages can pass through these firewalls. One approach is to use a signaling protocol to communicate with these firewalls and instruct them to bypass these Mobile IPv6 messages. The goal of this document is to describe the interaction between NSIS and Mobile IPv6 for enabling Mobile IPv6 traversal.

"SDP Descriptors for FLUTE", Harsh Mehta, 30-Jan-06. ( bytes)

This document specifies the use of SDP to describe the parameters required to begin, join, receive data from, and/or end FLUTE sessions. It also provides a Composite Session SDP media grouping semantic for grouping media streams into protocol-specific sessions, such as multiple-channel FLUTE sessions.

"Document: draft-otani-ccamp-interas-gmpls-te-07.txt", Tomohiro Otani, Shuichi Okamoto, Satoru Okamoto, 18-Dec-07. ( bytes)

This draft provides requirements for the support of generalized multi-protocol label switching (GMPLS) inter-domain traffic engineering (TE). Its main objective is to present the differences between MPLS inter-domain TE and GMPLS inter-domain TE. This draft covers not only GMPLS Inter-domain architecture but also functional requirements in terms of GMPLS signaling and routing in order to specify these in a GMPLS Inter-domain environment.

"Scope Modifiers in Intellectual Property Declarations", I Maturana, I Robredo, 16-Aug-05. ( bytes)

The purpose of this RFC is to focus discussion on intellectual property problems in the Internet. This document introduces and defines scope modifiers to be used in intellectual property declarations. These modifiers abstract the ownership behavior of resources available in interoperable environnments, such as the Internet.

"A Schema and Guidelines for Defining Session Initiation Protocol User Agent Profile Datasets", Sumanth Channabasappa, Sam Ganesan, 18-Nov-07. ( bytes)

This document defines the requirements and a format for SIP user agent profile data. An overall schema is specified for the definition of profile datasets. The schema also provides for expressing constraints for how multiple sources of profile data are to be combined. This document provides a guide to considerations, policies and syntax for defining datasets to be included in profile data. It also explores some specific datasets to test the requirements, assumptions and syntax.

"Using XML Schema to define NETCONF Content", Sharon Chisholm, Alex Clemm, 25-Feb-08. ( bytes)

This memo defines a framework for defining content for NETCONF using a meta-model and XML Schema. The approach is to build on existing well-deployed technology and overlap management specific semantics to ensure high-quality interoperable definition of NETCONF content.

"Guidelines for Writing an IANA Considerations Section in RFCs", Thomas Narten, Harald Alvestrand, 26-Mar-08. ( bytes)

Many protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication transform for IPsec). To ensure that such quantities have consistent values and interpretations across all implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA). In order for IANA to manage a given name space prudently, it needs guidelines describing the conditions under which new values can be assigned, or when modifications to existing values can be made. If IANA is expected to play a role in the management of a name space, the IANA must be given clear and concise instructions describing that role. This document discusses issues that should be considered in formulating a policy for assigning values to a name space and provides guidelines to document authors on the specific text that must be included in documents that place demands on IANA. This document obsoletes RFC 2434. Contents Status of this Memo.......................................... 1

"The IPvLX Architecture", Fred Templin, 11-May-07. ( bytes)

The IETF has embraced IPv6 as the next-generation Internet protocol, but global IPv4 deployment continues in private addressing domains behind Network Address Translators (NATs). This document envisions a long-term IPv6/IPv4 coexistence, with IPv6 addresses serving as identifiers (and sometimes also locators) and IPv4 addresses serving as locators (and sometimes also identifiers). This document proposes an architectural framework for IPv6/IPv4 coexistence called: "IPvLX (IP with virtual Link Extension)".

"Atomsub: Transporting Atom Notifications over the Publish-Subscribe Extension to the Extensible Messaging and Presence Protocol (XMPP)", Peter Saint-Andre, Joe Hildebrand, Bob Wyman, 7-May-08. ( bytes)

This memo describes a method for notifying interested parties about changes in syndicated information encapsulated in the Atom feed format, where such notifications are delivered via an extension to the Extensible Messaging and Presence Protocol (XMPP) for publish- subscribe functionality.

"Message Header Field for Indicating Message Authentication Status", Murray Kucherawy, 19-Mar-08. ( bytes)

This memo defines a new message header field for use with electronic mail messages to indicate the results of message authentication efforts. Mail user agents (MUAs) may use this message header field to relay that information in a convenient way to users or to make sorting and filtering decisions.

"Network-Layer Signaling: Transport Layer", Melinda Shore, 14-Jun-07. ( bytes)

The RSVP model for communicating requests to network devices along a datapath has proven useful for a variety of applications beyond what the protocol designers envisioned, and while the architectural model generalizes well the protocol itself has a number of features that limit its applicability to applications other than IntServ. Network Layer Signaling uses the RSVP on-path communication model to carry requests to middleboxes and other network devices. It is based on a "two-layer" architecture that divides protocol function into transport and application. This document describes the transport protocol.

"Interaction between SIP and HIP", Hannes Tschofenig, Joerg Ott, Henning Schulzrinne, Tom Henderson, Gonzalo Camarillo, 25-Feb-08. ( bytes)

This document investigates the interworking between the Session Initiation Protocol (SIP) and the Host Identity Protocol (HIP) and the benefits that may arise from their combined operation. The aspect of exchanging Host Identities (or Host Identity Tags) in SIP/SDP for later usage with the Host Identity Protocol Protocol (HIP) is described in more detail as an example of this interworking.

"Using Kerberos V5 over the Transport Layer Security (TLS) protocol", Simon Josefsson, 3-Dec-07. ( bytes)

This document specify how the Kerberos V5 protocol can be transported over the Transport Layer Security (TLS) protocol, to provide additional security features.

"Version 2.0 Microsoft Word Template for Creating Internet Drafts and RFCs", Joseph Touch, 27-Feb-08. ( bytes)

This document describes the properties and use of a revised Microsoft Word template (.dot) for writing Internet Drafts and RFCs. It updates the initial template described in RFC 3285 to more fully support Word's outline modes and to be easier to use. This template can be direct-printed and direct-viewed, where either is line-for-line identical with RFC Editor-compliant ASCII output. This version is intended as an update to RFC3285. The most recent version of this template and post-processing scripts are available at http://www.isi.edu/touch/tools

"Licklider Transmission Protocol - Motivation", Scott Burleigh, Manikantan Ramadas, Stephen Farrell, Intellectual Property, 9-Apr-08. ( bytes)

This document describes the Licklider Transmission Protocol (LTP) designed to provide retransmission-based reliability over links characterized by extremely long message round-trip times (RTTs) and/or frequent interruptions in connectivity. Since communication across interplanetary space is the most prominent example of this sort of environment, LTP is principally aimed at supporting "long- haul" reliable transmission in interplanetary space, but it has applications in other environments as well. In an Interplanetary Internet setting deploying the Bundle protocol, LTP is intended to serve as a reliable convergence layer over single hop deep-space RF links. LTP does ARQ of data transmissions by soliciting selective-acknowledgment reception reports. It is stateful and has no negotiation or handshakes. This document is a product of the Delay Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised.

"Licklider Transmission Protocol - Security Extensions", Stephen Farrell, Manikantan Ramadas, Scott Burleigh, Intellectual Property, 12-Mar-08. ( bytes)

The Licklider Transmission Protocol (LTP), is intended to serve as a reliable convergence layer over single hop deep-space RF links. LTP does ARQ of data transmissions by soliciting selective-acknowledgment reception reports. It is stateful and has no negotiation or handshakes. LTP is designed to provide retransmission-based reliability over links characterized by extremely long message round-trip times (RTTs) and/or frequent interruptions in connectivity. Since communication across interplanetary space is the most prominent example of this sort of environment, LTP is principally aimed at supporting "long- haul" reliable transmission in interplanetary space, but has applications in other environments as well. This document describes security extensions to LTP, and is part of a series of related documents describing LTP. Other documents in this series cover the motivation for LTP and the main protocol specification. We recommend reading all the documents in the series before writing code based on this document. This document is a product of the Delay Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised.

"The OpenPGP mail and news header field", Atom Smasher, Simon Josefsson, 14-Apr-08. ( bytes)

This document describes the OpenPGP mail and news header field. The field provide information about the sender's OpenPGP key. See for more information.

"TLS Sign", Ibrahim Hajjeh, Mohamad Badra, 15-Dec-07. ( bytes)

TLS protocol provides authentication and data protection for communication between two entities. However, missing from the protocol is a way to perform non-repudiation service. This document defines extensions to the TLS protocol to allow it to perform non-repudiation service. It is based on [TLSSIGN] and it provides the client and the server the ability to sign by TLS, handshake and applications data using certificates such as X.509.

"Certificate Exchange Messaging for EDIINT", Kyle Meadors, Dale Moberg, 22-Feb-08. ( bytes)

The EDIINT AS1, AS2 and AS3 message formats do not currently contain any neutral provisions for transporting and exchanging trading partner profiles or digital certificates. EDIINT Certificate Exchange Messaging provides the format and means to effectively exchange certificates for use within trading partner relationships. The messaging consists of two types of messages, Request and Response, which allow trading partners to communicate certificates, their intended usage and their acceptance through XML. Certificates can be specified for use in digital signatures, data encryption or SSL/TLS over HTTP (HTTPS).

"IPFIX Flow Aggregation", Falko Dressler, Christoph Sommer, Gerhard Muenz, Atsushi Kobayashi, 19-Nov-07. ( bytes)

IPFIX Flow Aggregation describes a methodology for reducing the amount of measurement data exchanged between monitoring devices (IPFIX Exporters) and analyzers (IPFIX Collectors). Aggregation techniques represent a necessary enhancement in order to cope with increasing amounts of monitoring data that accrue with the ever- growing network capacities. Using aggregation techniques, measurement information of multiple Flows that are sharing some common criteria is merged to be exported in one Compound Flow. Subsets of Flows eligible for aggregation, as well as the desired degree of similarity, can be customized using a set of Aggregation Rules.

"VoIP Configuration Server Address Option", Richard Johnson, 16-Nov-07. ( bytes)

This memo documents existing usage for the "VoIP Configuration Server Address Option" (previously known as the "TFTP Server IP Address Option". The option number currently in use is 150. This memo documents the current usage of the option in agreement with [6], which declares that any pre-existing usages of option numbers in the range 128 - 223 should be documented and the working group will try to officially assign those numbers to those options.

"Circuit Cross-Connect", Kireeti Kompella, 9-Feb-06. ( bytes)

Circuit Cross-Connect (CCC) was the ground-breaking design and implementation of the transport of Layer 2 frames over Multi-Protocol Label Switching (MPLS), which is now seen as an important application of MPLS. Thus, documenting CCC is important from a historical point of view. Furthermore, CCC is still in production in many networks, providing yet another reason to document it. It is hoped that those interested in this area will see where it started, how far we have come, and the strengths and weaknesses of this particular approach, and thereby gain some perspective of the area. If in the process they get new insights for the future development in this area, that is a bonus.

"Document: draft-otani-ccamp-gmpls-cspf-constraints-07.txt", Tomohiro Otani, Kenichi Ogaki, Arthi Ayyangar, Rajiv Papneja, Kireeti Kompella, Daniel King, 19-Nov-07. ( bytes)

This document provides guidelines for the consideration of Generalized Multiprotocol Label Switching (GMPLS) Traffic-Engineering (TE) attributes for computation of routes for Label Switched Paths (LSPs) in a GMPLS network. This document summarizes how GMPLS TE attributes on ingress links, transit links, and egress links may be treated as path computation constraints to determine the route of a GMPLS Label Switched Path (LSP). T. Otani et al. Expires May 2008 1 Internet Drafts draft-otani-ccamp-gmpls-cspf-constraints-07.txt November 2007

"Transmitting Confidential Data in RADIUS", Glen Zorn, Hao Zhou, Joseph Salowey, 25-Feb-08. ( bytes)

This document defines a set of RADIUS Attributes designed to allow the secure transmission of sensitive or confidential data between RADIUS clients and servers and the strong authentication of any RADIUS message.

"Dynamic AS Re-Association At Confederation Edge", Susan Hares, Pratik Bose, 24-Feb-08. ( bytes)

This document provides a mechanism for Autonomous Systems within an AS Confederation to survive the disconnection to other AS within the AS confederation without dropping peers. When all links to the other AS in the Confederation break, this mechanism allows the AS to revert to local AS to continue communication with E-BGP peers. This mechanism has two parts: Capability signaling between the two parties at connection start to save two AS (internal and AS Confederation AS) and a mechanism to signal the switch between AS Confederation AS and internal AS.

"Session Initiation Protocol (SIP) Session Mobility", Ron Shacham, Henning Schulzrinne, Srisakul Thakolsri, Wolfgang Kellerer, 18-Nov-07. ( bytes)

Session mobility is the transfer of media of an ongoing communication session from one device to another. This document describes the basic approaches and shows the signaling and media flow examples for providing this service using the Session Initiation Protocol (SIP). Service discovery is essential to locate targets for session transfer and is discussed using the Service Location Protocol (SLP) as an example. This document is intended as an informational document.

"The 'mailto' URI Scheme", Martin Duerst, Larry Masinter, Jamie Zawinski, 24-Feb-08. ( bytes)

This document defines the format of Uniform Resource Identifiers (URI) to identify resources that are reached using Internet mail. It adds better internationalization and compatibility with IRIs (RFC 3987) to the previous syntax of 'mailto' URIs (RFC 2368).

"PF_KEY Extension as an Interface between Mobile IPv6 and IPsec/IKE", Shinta Sugimoto, Francis Dupont, Masahide Nakamura, 15-Dec-07. ( bytes)

This document describes the need for an interface between Mobile IPv6 and IPsec/IKE and show how the two protocols can interwork. We propose a set of extensions to the PF_KEY framework which allows smooth and solid operation of IKE in a Mobile IPv6 environment. The first extension is called PF_KEY MIGRATE and is for migrating the endpoint addresses of a IPsec Security Association pair in tunnel mode. The second extension is named SADB_X_EXT_PACKET and allows IKE to make the right choice for address selection in bootstrapping process. Both extensions are helpful for assuring smooth interworking between Mobile IPv6 and IPsec/IKE and achieving performance optimization.

"EAP Tunneled TLS Authentication Protocol Version 0 (EAP-TTLSv0)", Paul Funk, Simon Blake-Wilson, 30-Apr-08. ( bytes)

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.

"BGP Point to Multipoint LSP", Satoru Matsushima, Tetsuya Murakami, Kenichi Nagami, 25-Feb-08. ( bytes)

This document describes motivations and use cases to P2MP extension of BGP. This extension will allow to make both Inter-AS and Intra-AS P2MP LSP that fit to some use cases then also clarify required features.

"P3P Policy Attributes for LDAP", Mark Wahl, 12-Dec-06. ( bytes)

This document defines attributes for use in the Lightweight Directory Access Protocol (LDAP) which contain URIs for privacy policy documents. These documents describe the privacy policy concerning access to a directory server, and the privacy policies that apply to the contents of the directory (a subtree of entries).

"IS-IS BFD Enabled TLV", Christian Hopps, Les Ginsberg, 19-Nov-07. ( bytes)

This document describes a TLV for use in the IS-IS routing protocol that allows for the proper use of the Bidirectional Forwarding Detection protocol (BFD). There exist certain scenarios in which IS-IS will not react appropriately to a BFD detected forwarding plane failure without use of either this TLV or some other method.

"Wireless LAN Control Protocol (WiCoP)", Satoshi Iino, 7-Feb-07. ( bytes)

The popularity of wireless local area networks (WLANs) has led to wide spread deployments across different establishments. It has also translated in to increasing scale of the WLANs. Large-scale deployments made of large numbers of wireless termination points (WTPs) and covering substantial areas are increasingly common. The Wireless LAN Control Protocol (WiCoP) described in this document allows for the control and provisioning of large-scale WLANs. It enables central management of these networks and realizes the objectives set forth for the control and provisioning of wireless access points (CAPWAP).

"Multiple Attachments for EDI-INT", Kyle Meadors, 19-Mar-08. ( bytes)

The EDIINT AS1, AS2 and AS3 message were designed specifically for the transport of EDI documents. Since multiple interchanges could be placed within a single EDI document, there was not a need for sending multiple EDI documents in a single message. As adoption of EDI-INT grew, other uses developed aside from single EDI document transport. Some transactions required multiple attachments to be interpreted together and stored in a single message. This informational draft describes how multiple documents, including non-EDI payloads, can be attached and transmitted in a single EDI-INT transport message. The attachments are stored within the MIME Multipart/Related structure. A minimal list of content-types to be supported as attachments is provided.

"Best Current Practices of XCAST (Explicit Multi-Unicast) by 2004", Chih-Chang Hsu, 22-Jul-05. ( bytes)

In 2000, XCAST (Explicit Multi-Unicast) was first proposed as a protocol intended for small group multicasting. It combined three similar datagram simulcasting protocols that were submitted as earlier Internet Drafts by a number of different research groups. After that, researchers in those groups worked together to further develop, experiment and conduct standardization in IETF as well as in the open source community. This resulted in several implementations of protocol stacks, systems of multi-party video conference and group management, and mechanisms for harmonizing XCAST with ASM and SSM. In addition, an XCAST backbone for various experiments has been launched to operate inter-continentally. One of the main purposes of this document is to summarize the efforts undertaken by XCAST community as "best current practices" that would then be formally introduced to the IETF/IRTF community. In addition, we raise an issue concerning IANA resource allocation, which prevents us from widely expanding our experimental networks as well as distributing our software. Finally, we request IESG and other experts to check the validity of our proposed protocol and make any suggestions about how IANA can assign appropriate resources accordingly.

"IANA Considerations for XCAST (Explicit Multi-Unicast)", Chih-Chang Hsu, 4-Apr-05. ( bytes)

XCAST (Explicit Multi-Unicast) is an experimental protocol for small group multicasting. This protocol requires IANA allocations for a new type of multicast address, a routing type of IPv6 routing header, an option type of Destination Option header and an option header of IPv6 Hop-by-Hop Options header. This document contains guidelines to IANA about what allocations are required for XCAST protocol.

"SLAPP : Secure Light Access Point Protocol", Partha Narasimhan, 27-Mar-06. ( bytes)

The CAPWAP problem statement [3] describes a problem that needs to be addressed before a wireless LAN (WLAN) network designer can construct a solution composed of Wireless Termination Points (WTP) and Access Controllers (AC) from multiple, different vendors. One of the primary goals is to find a solution that solves the interoperability between the two classes of devices (WTPs and ACs) which then enables an AC from one vendor to control and manage a WTP from another.

"SCTP NAT Traversal Considerations", Qiaobing Xie, Randall Stewart, Matt Holdrege, Michael Tuexen, 17-Nov-07. ( bytes)

This document defines and classifies scenarios for the usage of SCTP in networks with NATs and similar middleboxes.

"An Extensible Format for Email Feedback Reports", Yakov Shafranovich, 12-Mar-08. ( bytes)

This document defines an extensible format and MIME type that may be used by network operators to report feedback about received email to other parties. This format is intended as a machine readable replacement for various existing report formats currently used in Internet email.

"Registration Templates for Legacy Message Header Field Names", Bruce Lilly, 21-Apr-05. ( bytes)

This memo documents several Internet Message Format message header field names and provides registration templates so that the names can be registered in the permanent message header field name registry.

"Stream Control Transmission Protocol (SCTP) Network Address Translation", Randall Stewart, Michael Tuexen, 17-Nov-07. ( bytes)

Stream Control Transmission Protocol [RFC4960] provides a reliable communications channel between two end-hosts in many ways similar to TCP [RFC0793]. With the widespread deployment of Network Address Translators (NAT), specialized code has been added to NAT for TCP that allows multiple hosts to reside behind a NAT and yet use only a single globally unique IPv4 address, even when two hosts (behind the NAT) choose the same port numbers for their connection. This additional code is sometimes classified as Network Address and Port Translation or NAPT. To date, specialized code for SCTP has NOT yet been added to most NAT's so that only pure NAT is available. The end result of this is that only one SCTP capable host can be behind a NAT. This document describes an SCTP specific variant of NAT which provides similar features of NAPT in the single point traversal scenario described in [I-D.xie-behave-sctp-nat-cons]. Furthermore both algorithms are compared.

"The 'news' and 'nntp' URI Schemes", Frank Ellermann, 2-Apr-08. ( bytes)

This memo specifies the 'news' and 'nntp' Uniform Resource Identifier (URI) schemes that were originally defined in RFC 1738. The purpose of this document is to allow RFC 1738 to be made obsolete while keeping the information about these schemes on standards track.

"IMMP -- Internet Message Mapping Protocol", Sabarish Ramanathan, 24-May-05. ( bytes)

The Internet Message Mapping Protocol (IMMP) is designed to support the provision of mail in a medium to large scale operation. It is intended to be used as a companion to the SMTP protocol and mail receiving protocols (POP, IMAP, web mail also), providing services which are outside the scope of mail access. The services that IMMP provides are mapping mails into appropriate subinbox (inside the inbox) when the messages are received through SMTP, Extended inbox management and Spam guard management.

"CalDAV Scheduling Extensions to WebDAV", Cyrus Daboo, Bernard Desruisseaux, Lisa Dusseault, 18-Nov-07. ( bytes)

This document defines extensions to the Web Distributed Authoring and Versioning (WebDAV) protocol to specify a standard way of exchanging and processing scheduling messages based on the iCalendar Transport- Independent Interoperability Protocol (iTIP). This document defines the "calendar-schedule" feature of CalDAV.

"Bundle Security Protocol Specification", Susan Symington, Stephen Farrell, Howard Weiss, Peter Lovell, 24-Feb-08. ( bytes)

This document defines the bundle security protocol, which provides data integrity and confidentiality services. We also describe various bundle security considerations including policy options.

"Distributing Address Selection Policy using DHCPv6", Tomohiro Fujisaki, 15-Nov-07. ( bytes)

This document describes a new DHCPv6 option for distributing address selection policy information defined in RFC3484 to a client. With this option, site administrators can distribute address selection policy to control the node's address selection behavior.

"Applicability of Loop-free Convergence", Stewart Bryant, Mike Shand, 16-Nov-07. ( bytes)

This draft describes the applicability of loop free convergence technologies to a number of network applications.

"NAT Port Mapping Protocol (NAT-PMP)", Stuart Cheshire, 16-Apr-08. ( bytes)

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.

"H-TCP: TCP Congestion Control for High Bandwidth-Delay Product Paths", Doug Leith, 7-Apr-08. ( bytes)

This document describes a number of changes to the TCP congestion control algorithm to to improve performance in high bandwidth-delay product paths. We focus on changes to the congestion avoidance mode, rather than slow-start.

"QoS-Enhanced Border Gateway Protocol", Mohammed Boucadair, 5-Jul-05. ( bytes)

This memo describes a proposal for exchanging QoS-enabled reachability information between service providers. It defines new BGP attributes to be used in order to convey QoS performance characteristics between service providers and it describes how to use these QoS values in order to select the best path. An example of route selection process that takes into account the QoS performance values enclosed in BGP messages is also detailed.

"The Meta-QoS-Class concept", Pierre Levis, Mohammed Boucadair, 30-Jun-05. ( bytes)

This document describes a framework for inter-domain Quality of Service (QoS). It makes use of a new concept denoted by Meta-QoS- Class. This new concept guides and simplifies QoS agreements between providers and opens up new perspectives for a global QoS-enabled Internet.

"Applicability of Reliable Server Pooling for Real-Time Distributed Computing", Thomas Dreibholz, 9-Jan-08. ( bytes)

This document describes the applicability of the Reliable Server Pooling architecture to manage real-time distributed computing pools and access the resources of such pools.

"RADIUS Attributes for IEEE 802 Networks", Bernard Aboba, Jouni Malinen, 9-Apr-08. ( bytes)

RFC 3580 provides guidelines for the use of the Remote Authentication Dialin User Service (RADIUS) within IEEE 802 local area networks (LANs). This document proposes additional attributes for use within IEEE 802 networks. The attributes defined in this document are usable both within RADIUS and Diameter.

"Use of the Reason header filed in Session Initiation Protocol (SIP) responses", Roland Jesske, 20-Feb-08. ( bytes)

This document proposes the use of the Reason header field in SIP responses.

"Synchronisation of Loop Free Timer Values", Alia K, Stewart Bryant, 14-Feb-08. ( bytes)

This draft describes a mechanism that enables routers to agree on a common convergence delay time for use in loop-free convergence.

"Simple Mail Transfer Protocol", John Klensin, 14-Apr-08. ( bytes)

This document is a specification of the basic protocol for Internet electronic mail transport. It consolidates, updates, and clarifies several previous documents, making all or parts of most of them obsolete. It covers the SMTP extension mechanisms and best practices for the contemporary Internet, but does not provide details about particular extensions. Although SMTP was designed as a mail transport and delivery protocol, this specification also contains information that is important to its use as a "mail submission" protocol for "split-UA" mail reading systems and mobile environments.

"Distributed Multimodal Synchronization Protocol", Jonathan Engelsma, Chris Cross, 31-Jul-07. ( bytes)

This document proposes a Distributed Multimodal Synchronization Protocol (DMSP) designed to enable multimodal interaction for mobile devices by accessing services in the network. More specifically, this protocol coordinates events of interest between a visual browser or application running on a mobile device with a VoiceXML (Voice Extensible Markup Language) browser running in the network.

"IPv6 Address Assignment to End Sites", Thomas Narten, 11-Mar-08. ( bytes)

RFC 3177 argued that in IPv6, end sites should be assigned /48 blocks in most cases. The Regional Internet Registries (RIRs) adopted that recommendation in 2002, but began reconsidering the policy in 2005. This document revisits and updates the RFC 3177 recommendations on the assignment of IPv6 address space to end sites. The exact choice of how much address space to assign end sites is a policy issue under the purview of the RIRs, subject to IPv6 architectural andoperational considerations. This document reviews the architectural and operational considerations of end site assignments as well as the motivations behind the original 3177 recommendations. The document clarifies that changing the /48 recommendation is one of policy, and has minimal impact on the IPv6 architecture and on IETF Standards.

"Dynamic Provisioning using Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST)", Nancy Cam-Winget, David McGrew, Joseph Salowey, Hao Zhou, 7-Apr-08. ( bytes)

The flexible authentication via secure tunneling EAP method (EAP- FAST) enables secure communication between a peer and a server by using Transport Layer Security (TLS) to establish a mutually authenticated tunnel. EAP-FAST also enables the provisioning credentials or other information through this protected tunnel. This document describes the use of EAP-FAST for dynamic provisioning.

"Sieve Email Filtering: Date and Index Extensions", Ned Freed, 20-Apr-08. ( bytes)

This document describes the "date" and "index" extensions to the Sieve email filtering language. The "date" extension gives Sieve the ability to test date and time values in various ways. The "index" extension provides a means to limit header and address tests to specific instances of header fields when header fields are repeated. Change History (to be removed prior to publication as an RFC) Changed usage from Julian Days to Modified Julian Days. This has the advantage that the number are smaller and day numbers change at midnight rather than at noon. Added the ability to return the day of the week. Use the term "argument" instead of "parameter" throughout. Added a "std11" part type as a means to operate on values formatted in the same way as a Date: header field. Changed the terminology from "part" to "date-part". Updated reference to 3028bis, corrected miscellaneous typos. Updated the IANA registration templates. Added "time" and "date" as possible date-part values with appropriate syntax. Restricted allowed ISO 8601 formats so that comparisons will be reliable. Changed the date-part "timezone" to "zone" to make it consistent with the :zone parameter. Removed the reference to structured header fields in the description of the date test. Added a paragraph to make it clear that :index counts header fields, not the contents of header fields. Allow leap seconds. Added :originalzone parameter to date test. Added several examples. Made the specification of :last without :index an error, aligning this specification with editheader. Added some security considerations text about the impact of currentdate on script analysis. Updated references to recently published RFCs. Clarified that date tests must return false for dates that aren't valid according to the calendar system. Correct erroneous reference to Julian calendar dates - should be Gregorian instead. Clarified that "std11" isn't really intended to be used in comparison operations and added an example of using "std11" to insert a date/ time in a header field. Added an appendix giving sample code to convert to and from modified Julian date values. Simplified the requirements for extracting date information from header fields.

"Secure SCTP", Carsten Hohendorf, 9-Jan-08. ( bytes)

This document explains the reason for the integration of security functionality into SCTP, and gives a short description of S-SCTP and its services. S-SCTP is fully compatible with SCTP defined in RFC2960, it is designed to integrate cryptographic functions into SCTP.

"Survey of IP address autoconfiguration mechanisms for MANETs", Carlos Bernardos, Maria Calderon, Hassnaa Moustafa, 8-Apr-08. ( bytes)

This Internet Draft provides a detailed description of most of the existing IP autoconfiguration solutions proposed so far. The main aim of this document is to serve as a general reference for the AUTOCONF solution space. We present most of the previously proposed IP AUTOCONF mechanisms in MANETs, showing their key characteristics, conforming to the AUTOCONF problem statement draft and the MANET architecture draft. Furthermore, each solution is analysed based on a number of evaluation considerations.

"The Core Session Initiation Protocol User Agent Protocol Data Set", Sumanth Channabasappa, Sam Ganesan, 18-Nov-07. ( bytes)

This document defines the properties and format for the core SIP user agent protocol dataset. The properties defined in this document are expected to be common to most SIP user agents regardless of whether the user agent support audio, video, text or any combination of media. These core SIP properties are considered to be a dataset. Several datasets may be combined into documents or profiles that are provided to SIP user agents so that they can operate with the desired behavior.

"Operational Reliability for EDIINT AS2 draft-duker-as2-reliability-03.txt", John Duker, Dale Moberg, 12-Feb-08. ( bytes)

The goal of this document is to define approaches to achieve a "once and only once" delivery of messages. The EDIINT AS2 protocol [AS2] is implemented by a number of software tools on a variety of platforms with varying capabilities and with varying network service quality. Although the AS2 protocol defines a unique "Message-ID", current implementations of AS2 do not provide a standard method to prevent the same message (re-transmitted by the initial sender) from reaching back-end business applications at the initial receiver. TCP underpinnings of HTTP over which AS2 operates generally provide a good quality of network connectivity, but experience indicates a need to be able to compensate for both transient server and socket exceptions, including "Connection refused" as well as "Server busy." In addition, difficulties with server availability, stability, and loads can result in reduced operational reliability. This document describes some ways to compensate for exceptions and enhance the reliability of AS2 protocol operation. Implementation of these reliability features is indicated by presence of the "AS2- Reliability" value in the EDIINT-Features header.

"Link Adaptation for IPv6-in-(foo)*-in-IPv4 Tunnels", Fred Templin, 14-May-07. ( bytes)

IPv6-in-(foo)*-in-IPv4 tunnels must support a minimum Maximum Transmission Unit (MTU) of 1280 bytes for IPv6 via static prearrangements and/or dynamic MTU determination based on ICMPv4 messages, but these methods have known operational limitations. This document specifies a link adaptation mechanism for IPv6-in-(foo)*-in- IPv4 tunnels that presents an assured MTU to the IPv6 layer using tunnel endpoint-based segmentation/reassembly and dynamic segment size probing.

"EDI-INT Features Header", Kyle Meadors, 19-Mar-08. ( bytes)

With the maturity of the EDI-INT standard of AS1, AS2 and AS3, applications and additional features are being built upon the basic secure transport functionality. These features are not necessarily supported by all EDI-INT applications and could cause potential problems with implementations

"HIP DHT Interface", Jeff Ahrenholz, 14-Jan-08. ( bytes)

This document specifies a common interface for using HIP with a Distributed Hash Table service to provide a HIT-to-address lookup service and an unmanaged name-to-HIT lookup service.

"Tools for the Evaluation of Simulation and Testbed Scenarios", Sally Floyd, Eddie Kohler, Intellectual Property, 23-Feb-08. ( bytes)

This document describes tools for the evaluation of simulation and testbed scenarios used in research on Internet congestion control mechanisms. We believe that research in congestion control mechanisms has been seriously hampered by the lack of good models underpinning analysis, simulation, and testbed experiments, and that tools for the evaluation of simulation and testbed scenarios can help in the construction of better scenarios, based on better underlying models. One use of the tools described in this document is in comparing key characteristics of test scenarios with known characteristics from the diverse and ever-changing real world. Tools characterizing the aggregate traffic on a link include the distribution of per-packet round-trip times, the distribution of connection sizes, and the like. Tools characterizing end-to-end paths include drop rates as a function of packet size and of burst size, the synchronization ratio between two end-to-end TCP flows, and the like. For each characteristic, we describe what aspects of the scenario determine this characteristic, how the characteristic can affect the results of simulations and experiments for the evaluation of congestion control mechanisms, and what is known about this characteristic in the real world. We also explain why the use of such tools can add considerable power to our understanding and evaluation of simulation and testbed scenarios. (This Internet-Draft is also available in PDF format [ bytes].)

"Delay-Tolerant Networking Security Overview", Stephen Farrell, Susan Symington, Howard Weiss, Peter Lovell, 24-Feb-08. ( bytes)

This document provides an overview of the security requirements and mechanisms considered for delay tolerant networking security. It discusses the options for protecting such networks and describes reasons why specific security mechanisms were (or were not) chosen for the relevant protocols. The entire document is informative, given its purpose is mainly to document design decisions.

"Four-octet AS Specific BGP Extended Community", Yakov Rekhter, 8-Apr-08. ( bytes)

This document defines a new type of a BGP extended community - four- octet AS specific extended community. This community allows to carry 4 octet autonomous system numbers.

"Password-Authenticated Diffie-Hellman Exchange (PAK)", Alec Brusilovsky, 19-Nov-07. ( bytes)

This document proposes to add mutual authentication, based on human-memorizable password, to the basic unauthenticated Diffie-Hellman key exchange. The proposed algorithm is called Password-authenticated Key exchange (PAK). PAK allows two parties to authenticate themselves while performing the Diffie-Hellman exchange. The protocol is secure against all passive and active attacks. In particular, it does not allow either type of attackers to obtain any information that would enable an off-line dictionary attack on the password. The use of Diffie-Hellman exchange ensures Forward Secrecy.

"Moving Forwards with IETF Process Evolution", Elwyn Davies, 26-Oct-06. ( bytes)

This document provides a summary of previously identified problems with the Internet Engineering Task Force (IETF) process for developing standards and other specifications; and then identifies a set of goals to aim at, and guidelines that should be followed during any activity seeking to revise and update this process. It does not propose specific changes to the process, which should be the subject of future documents.

"vCard Extensions to WebDAV (CardDAV)", Cyrus Daboo, 23-Feb-08. ( bytes)

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 .

"The Session Initiation Protocol User Agent Identity Profile Data Set", Daniel Petrie, Sumanth Channabasappa, Sam Ganesan, 18-Nov-07. ( bytes)

This document defines the properties and data format for the SIP user agent identity profile data set. The properties in this data set define identities or SIP address of records (AORs) related to incoming or outgoing SIP signaling on a user agent. The identities may be those that are registered via the SIP REGISTER method or identities which are provisioned on the user agent. These identities may be used or referenced when defining identity specific handling related to SIP features on the user agent.

"The Session Initiation Protocol User Agent VoIP Features Data Set", Daniel Petrie, Sumanth Channabasappa, Sam Ganesan, 18-Nov-07. ( bytes)

This document defines the properties and format for the SIP user agent VoIP Features data set. The properties defined in this document are expected to be common to most SIP user agents that provide VoIP capabilities. These VoIP Feature properties are considered to be a data set. Several types of datasets may be combined into documents that are provided to SIP user agents so that they can operate with the desired behavior.

"UDP Encapsulation of SCTP Packets", Michael Tuexen, Randall Stewart, 17-Nov-07. ( bytes)

This document describes a simple method of encapsulating SCTP Packets. This makes it possible to use SCTP in networks with legacy NAT not supporting SCTP.

"Address Resolution for GMPLS controlled PSC Ethernet Interfaces", Zafar Ali, Hassan Sheikh, Tomohiro Otani, Hidetsugu Sugiyama, 27-Feb-08. ( bytes)

This document outlines some interoperability issues observed with the use of ARP over GMPLS controlled Ethernet router-to- router (PSC) interfaces transiting from a non-Ethernet core, e.g., FSC or LSC core. The document also recommends some procedures to address these issues. The aim of this document is to facilitate and ensure better interworking of GMPLS- capable Label Switching Routers (LSRs), based on experience gained in interoperability testing.

"Re-ECN: Adding Accountability for Causing Congestion to TCP/IP", Bob Briscoe, Arnaud Jacquet, T Moncaster, Alan Smith, 10-Jan-08. ( bytes)

This document introduces a new protocol for explicit congestion notification (ECN), termed re-ECN, which can be deployed incrementally around unmodified routers. The protocol arranges an extended ECN field in each packet so that, as it crosses any interface in an internetwork, it will carry a truthful prediction of congestion on the remainder of its path. Then the upstream party at any trust boundary in the internetwork can be held responsible for the congestion they cause, or allow to be caused. So, networks can introduce straightforward accountability and policing mechanisms for incoming traffic from end-customers or from neighbouring network domains. The purpose of this document is to specify the re-ECN protocol at the IP layer and to give guidelines on any consequent changes required to transport protocols. It includes the changes required to TCP both as an example and as a specification. It also gives examples of mechanisms that can use the protocol to ensure data sources respond correctly to congestion. And it describes example mechanisms that ensure the dominant selfish strategy of both network domains and end-points will be to set the extended ECN field honestly. Authors' Statement: Status (to be removed by the RFC Editor) Although the re-ECN protocol is intended to make a simple but far- reaching change to the Internet architecture, the most immediate priority for the authors is to delay any move of the ECN nonce to Proposed Standard status. The argument for this position is developed in Appendix I. Changes from previous drafts (to be removed by the RFC Editor) Full diffs created using the rfcdiff tool are available at From -04 to -05 (current version): Completed justification for packet marking with FNE during slow- start(Appendix D). Minor editorial changes throughout. From -03 to -04: Clarified reasons for holding back ECN nonce (Section 3.2 & Appendix I). Clarified Figure 1. Added Section 4.1.1.1 on equivalence of drops and ECN marks. Improved precision of Section 5.6 on IP in IP tunnels. Explained the RTT fairness is possible to enforce, but unlikely to be required (Section 6.1.3 & Appendix F). Explained that bulk per-user policing should be adequate but per- flow policing is also possible if desired, though it is not likely to be necessary (Section 6.1.5 & Appendix G). Reinforced need for passive policing at inter-domain borders to enable all-optical networking (Section 6.1.6). Minor editorial changes throughout. From -02 to -03: Started guidelines for re-ECN support in DCCP and SCTP. Added annex on limitations of nonce mechanism. Minor editorial changes throughout. From -01 to -02: Explanation on informal terminology in Section 3.4 clarified. IPv6 wire protocol encoding added (Section 5.2). Text on (non-)issues with tunnels, encryption and link layer congestion notification added (Section 5.6 & Section 5.7). Section added giving evolvability arguments against encouraging bottleneck policing (Section 6.1.2). And text on re-ECN's evolvability by design added to Section 6.1.3 Text on inter-domain policing (Section 6.1.6) and inter-domain fail-safes (Section 6.1.7) added. From -00 to -01: Encoding of re-ECN wire protocol changed for reasons given in Appendix B and consequently draft substantially re-written. Substantial text added in sections on applications, incremental deployment, architectural rationale and security considerations.

"Considerations for Having a Successful BOF", Thomas Narten, 12-Oct-07. ( bytes)

This document discusses tactics and strategy for hosting a successful IETF Birds-of-a-Feather (BOF) Session, especially one oriented at the formation of an IETF Working Group. It is based on the experiences of having participated in numerous BOFs, both successful and unsuccessful.

"DNS Glue RR Survey and Terminology Clarification", Peter Koch, 19-Nov-07. ( bytes)

This document presents a survey of the use of the term "glue record" in DNS related RFCs and proposes a terminology for the various glue policies seen in different TLDs.

"Issues Discussed in Revising BGP-4", Andrew Lange, 13-Dec-07. ( bytes)

This document records the issues discussed and the consensus reached in the Interdoming Routing (IDR) Working Group during its efforts to revise and bring up to date the base specification for the BGP-4 protocol.

"IAX: Inter-Asterisk eXchange Version 2", Mark Spencer, Brian Capouch, Ed Guy, Frank Miller, Kenneth Shumard, 30-Mar-08. ( bytes)

This document describes IAX, the Inter-Asterisk eXchange protocol, an application-layer control and media protocol for creating, modifying, and terminating multimedia sessions over Internet Protocol (IP) networks. IAX was developed by the open source community for the Asterisk PBX and is targeted primarily at Voice over Internet Protocol (VoIP) call control, but it can be used with streaming video or any other type of multimedia. IAX is an "all in one" protocol for handling multimedia in IP networks. It combines both control and media services in the same protocol. In addition, IAX uses a single UDP data stream on a static port greatly simplifying Network Address Translation (NAT) gateway traversal, eliminating the need for other protocols to work around NAT, and simplifying network and firewall management. IAX employs a compact encoding which decreases bandwidth usage and is well suited for Internet telephony service. In addition, its open nature permits new payload types additions needed to support additional services.

"IPv6 over Low Power WPAN Security Analysis", Soohong Daniel Park, 25-Feb-08. ( bytes)

This document discusses possible threats and security options for IPv6-over-IEEE802.15.4 networks. It is an informational document to raise awareness of security issues in IPv6 lowPan networks.

"The Atom "deleted-entry" Element", James Snell, 21-Apr-08. ( bytes)

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.

"SIP Interface to VoiceXML Media Services", Dave Burke, 12-Jul-07. ( bytes)

This document describes a SIP interface to VoiceXML media services, which is commonly employed between application servers and media servers offering VoiceXML processing capabilities.

"Extending ICMP to Identify the Receiving Interface", Alia Atlas, Ronald Bonica, Nuova Systems, Naiming Shen, Enke Chen, 16-Nov-07. ( bytes)

This memo defines ICMP extensions, using ICMP multi-part messages, through which a router or host can explicitly identify the interface upon which an undeliverable datagram anrrived. The incoming interface can be identified by ifIndex, name, and/or address, as already used in MIBs and by OSPF. The extensions defined herein are particularly useful when troubleshooting networks with unnumbered interfaces, parallel interfaces and/or asymmetric routing.

"OCRA: OATH Challenge-Response Algorithms", Salah Machani, Intellectual Property, 3-Apr-08. ( bytes)

This document describes the OATH algorithm for challenge-response authentication and signatures. This algorithm is based on the HOTP algorithm [RFC4226] that was introduced by OATH (initiative for Open AuTHentication) [OATH] and submitted as an individual draft to the IETF in 2006. OATH-HOTP-VARIANTS Expires - October 2008 [page 1] OCRA: OATH Challenge Response Algorithms April 2008

"A Basic Interactive Voice Response (IVR) Control Package for the Media Control Channel Framework", Chris Boulton, Tim Melanchuk, Scott McGlashan, 24-Feb-08. ( bytes)

This document defines a Media Control Channel Framework Package for basic Interactive Voice Response (IVR) interaction.

"Centralized Conferencing Manipulation Protocol", Mary Barnes, Chris Boulton, Henning Schulzrinne, 25-Feb-08. ( bytes)

The Centralized Conferencing Manipulation Protocol (CCMP) defined in this document provides the mechanisms to create, change and delete objects related to centralized conferences, including participants, their media and their roles. The protocol relies on web services and SIP event notification as its infrastructure, but can control conferences that use any signaling protocol to invite users. CCMP is based on the Simple Object Access Protocol (SOAP), with the data necessary for the interactions specified via Web Services Description Language (WSDL).

"Issues with existing Cryptographic Protection Methods for Routing Protocols", Vishwas Manral, 11-Feb-08. ( bytes)

Routing protocols are designed to use cryptographic mechanisms to authenticate data being received from a neighboring router to ensure that it has not been modified in transit, and actually originated from the neighboring router purporting to have originating the data. Most of the cryptographic mechanisms defined to date rely on hash algorithms applied to the data in the routing protocol packet, which means the data is transported, in the clear, along with a signature based on the data itself. These mechanisms rely on the manual configuration of the keys used to seed, or build, these hash based signatures. This document outlines some of the problems with manual keying of these cryptographic algorithms.

"Private Extensions to the Session Initiation Protocol (SIP) for Service Interaction Indicator", Yuzhong Shen, 18-Apr-08. ( bytes)

In SIP-based networks, a SIP session MAY involve several application servers on the originating and terminating side. In a certain case, an application server needs to set some indications in SIP message to indicate service information (what are invoked, what can be allowed and what should blocked). This kind of information will be also required for composition of SIP applications. There is a need to provide indicators for service interaction between SIP application servers or other SIP endpoints. This document describes a mechanism of service interaction indicator for the Session Initiation Protocol (SIP) that enhances service interaction between SIP application servers in a trusted network.

"The "pack" URI Scheme", Andrey Shur, Jerry Dunietz, 10-Mar-08. ( bytes)

A package is a logical entity that holds a collection of parts. Given the URI for a complete package, the "pack" URI scheme provides for the construction and use of URIs referring to individual parts within the package. It also provides for the use of part's URIs as base URIs for resolving relative references between the parts in a single package.

"Transport Layer Security (TLS) Authorization Extensions", Mark Brown, Russ Housley, 10-Sep-07. ( bytes)

This document specifies authorization extensions to the Transport Layer Security (TLS) Handshake Protocol. Extensions carried in the client and server hello messages to confirm that both parties support the desired authorization data types. Then, if supported by both the client and the server, authorization information is exchanged in the supplemental data handshake message.

"Requirements for supporting Customer RSVP and RSVP-TE Over a BGP/MPLS IP-VPN", Kenji Kumaki, 20-Feb-08. ( bytes)

Some service providers want to build a service which guarantees QoS or bandwidth from a local CE to a remote CE through the network. Today, customers expect to run triple play services through BGP/MPLS IP-VPNs. As a result, their requirements for end-to-end QoS of applications are increasing. Depending on the application (e.g., voice, video, bandwidth-guaranteed data pipe, etc.), an end-to-end native RSVP path and/or an end-to-end MPLS TE LSP are required, and they need to meet some constraints. This document describes service provider requirements for supporting customer RSVP and RSVP-TE over a BGP/MPLS VPN

"LowPan Neighbor Discovery Extensions", Samita Chakrabarti, Erik Nordmark, 20-Nov-07. ( bytes)

IETF 6LowPan working group defines IPv6 over low-power personal area network (IEEE 802.15.4). IEEE 802.15.4 link layer does not have multicast support, although it supports broadcast. Due to the nature of LowPan network or sensor networks, broadcast messages should be minimized. This document suggests some optimizations to IPv6 Neighbor Discovery related multicast messages in order to reduce signaling in the low-cost low-powered network.

"The Jabber-ID Header Field", Peter Saint-Andre, 4-Dec-07. ( bytes)

This document defines a header field that enables the author of an email or netnews message to include a Jabber Identifier in the message header block for the purpose of associating the author with a particular Extensible Messaging and Presence Protocol (XMPP) address.

"BR Organization Mapping for the Extensible Provisioning Protocol (EPP)", Frederico Neves, Hugo Koji Kobayashi, 24-Aug-06. ( bytes)

This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of .br organizational social information stored in a shared central repository. Specified in XML, this mapping extends the EPP contact mapping to provide additional features required for the provisioning of .br organizational social information.

"WiMAX Forum/3GPP2 Proxy Mobile IPv4", Kent Leung, 1-Apr-08. ( bytes)

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, and the existing application of PMIPv4 in WiMAX Forum and 3GPP2.

"Media Server Markup Language (MSML)", Adnan Saleem, 12-Feb-08. ( bytes)

The Media Server Markup Language (MSML) is used to control and invoke many different types of services on IP Media Servers. Clients can use it to define how multimedia sessions interact on a Media Server and to apply services to individuals or groups of users. MSML can be used, for example, to control Media Server conferencing features such as video layout and audio mixing, create sidebar conferences or personal mixes, and set the properties of media streams. As well, clients can use MSML to define media processing dialogs, which may be used as parts of application interactions with users or conferences. Transformation of media streams to and from users or conferences as well as IVR dialogs are examples of such interactions, which are specified using MSML. MSML clients may also invoke dialogs with individual users or with groups of conference participants using VoiceXML.

"PCC-PCE Communication Requirements for Point to Multipoint Multiprotocol Label Switching Traffic Engineering (MPLS-TE)", Seisho Yasukawa, Adrian Farrel, 12-May-08. ( bytes)

The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. Extensions to the MPLS and GMPLS signaling and routing protocols have been made in support of point-to-multipoint (P2MP) Traffic Engineered (TE) Label Switched Paths (LSPs). The use of PCE in MPLS networks is already established, and since P2MP TE LSP routes are sometimes complex to compute, it is likely that PCE will be used for P2MP LSPs. Generic requirements for a communication protocol between Path Computation Clients (PCCs) and PCEs are presented in "Path Computation Element (PCE) Communication Protocol Generic Requirements". This document complements the generic requirements and presents a detailed set of PCC-PCE communication protocol requirements for point-to-multipoint MPLS/GMPLS traffic engineering.

"PCC-PCE Communication Requirements for VPNs", Seisho Yasukawa, Adrian Farrel, 14-Feb-08. ( bytes)

The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. An important application of MPLS and GMPLS networks is Virtual Private Networks (VPNs) that may be constructed using Label Switched Paths (LSPs) in the MPLS and GMPLS networks as VPN tunnels. PCE may be applied as a tool to compute the paths of such tunnels in order to achieve better use of the network resources and to provide better levels of service to the VPN customers. Generic requirements for a communication protocol between Path Computation Clients (PCCs) and PCEs are presented in "Path Computation Element (PCE) Communication Protocol Generic Requirements". This document complements the generic requirements and presents a detailed set of PCC-PCE communication protocol requirements that are specific to the application of PCE to VPNs.

"Extended Shim6 Design for ID/loc split and Traffic Engineering", Erik Nordmark, 23-Feb-08. ( bytes)

The Shim6 protocol provides for locator agility while satisfying the 'first, do no harm' security requirements. This document outlines three rather orthogonal sets of extensions to Shim6. The first one is how to procide complete separation between identifiers and locators. The second one is how to allow routers to rewrite the locators in the shim6 packets as a way to provide traffic engineering information to the hosts. The third one is the outline of a simple extension to allow shim6, with a CGA upper-layer ID, to operate using IPv4 addresses as locators. The purpose of this outline is to stimulate discussions.

"Supporting Multipoint-to-Point Label Switched Paths in Multiprotocol Label Switching Traffic Engineering", Seisho Yasukawa, Adrian Farrel, 14-Feb-08. ( bytes)

Traffic engineered Multiprotocol Label Switching (MPLS-TE) uses Resource Reservation Protocol traffic engineering extensions (RSVP-TE) as the signaling protocol to establish Label Switched Paths (LSPs). Although the Resource Reservation Protocol (RSVP) on which RSVP-TE is built supports the convergence of traffic flows toward a common destination, this concept has not been exploited in MPLS-TE which has been limited to point-to-point (P2P) and point-to-multipoint (P2MP) LSPs. This document describes extensions to RSVP-TE procedures and protocol elements to support multipoint-to-point (MP2P) LSPs.

"Mobile IPv6 Location Privacy Solutions", QIU Ying, Fan Zhao, Rajeev Koodli, 15-Apr-08. ( bytes)

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.

"Organizing IETF Process Change", Elwyn Davies, 13-Jun-06. ( bytes)

This document sets out a strawman proposal for how to organize the revision and update of any part of the Internet Engineering Task Force (IETF) processes including those for developing standards and other specifications. It does not propose specific changes to any of these processes, which should be the subject of future documents. However, it does propose an initial target area for process change.

"GIST Extension for Hybrid On-path Off-path Signaling (HyPath)", Luís Cordeiro, Marilia Curado, Edmundo Monteiro, Vitor Bernardo, David Palma, Florin Racaru, Michel Diaz, Christophe Chassot, 23-Feb-08. ( bytes)

In a multi-domain Internet that offers QoS guaranties for applications, there is the need of signaling among the domain entities that are responsible for the management of QoS. Because different domains have different network protocols and topologies, the HyPath approach uses the NSIS protocol and interactions with the local routing protocols to have an off-path signaling in hybrid environments.

"Datagram Transport Layer Security for Stream Control Transmission Protocol", Michael Tuexen, Eric Rescorla, 17-Nov-07. ( bytes)

This document describes the usage of the Datagram Transport Layer Security (DTLS) protocol over the Stream Control Transmission Protocol (SCTP). The user of DTLS over SCTP can take advantage of all features provided by SCTP and its extensions, especially support of o multiple streams to avoid head of line blocking. o multi-homing to provide network level fault tolerance. o unordered delivery. o partial reliable data transfer.

"Enhanced validation of domains for HTTP State Management Cookies using DNS", Yngve Pettersen, 24-Feb-08. ( bytes)

HTTP State Management Cookies are used for a wide variety of tasks on the Internet, from preference handling to user identification. An important privacy and security feature of cookies is that their information can only be sent to a servers in a limited namespace, the domain. The variation of domain structures that are in use by domain name registries, especially the country code Top Level Domains (ccTLD) namespaces, makes it difficult to determine what is a valid domain, e.g. example.co.uk and example.no, which cookies should be permitted for, and a registry-like domain (subTLDs) like co.uk where cookies should not be permitted. This document specifies an imperfect method using DNS name lookups for cookie domains to determine if cookies can be permitted for that domain, based on the assumption that most subTLD domains will not have an IP address assigned to them, while most legitimate services that share cookies among multiple servers will have an IP address for their domain name to make the user's navigation easier by omitting the customary "www" prefix.

"The TLD Subdomain Structure Protocol and its use for Cookie domain validation", Yngve Pettersen, 24-Feb-08. ( bytes)

This document defines a protocol and specification format that can be used by a client to discover how a Top Level Domain (TLD) is organized in terms of what subdomains are used to place closely related but independent domains, e.g. commercial domains in country code TLDs (ccTLD) like .uk are placed in the .co.uk subTLD domain. This information is then used to limit which domains an Internet service can set cookies for, strengthening the rules already defined by the cookie specifications.

"Flow Bindings in Mobile IPv6 and Nemo Basic Support", Hesham Soliman, Nicolas Montavont, Niko Fikouras, Koojana Kuladinithi, 19-Nov-07. ( bytes)

This document introduces extensions to Mobile IPv6 [1] and Nemo Basic Support [2] that allow nodes to bind one or more flows to a care-of address. These extensions allow multihomed nodes to take full advantage of the different properties associated with each of their interfaces.

"An MP-BGP protocol extension to advertize TE-related PE-CE link information", JP Vasseur, Gargi Nalawade, Kenji Kumaki, 18-Nov-07. ( bytes)

This document proposes MP-BGP protocol extension so as to convey Traffic Engineering Link characterictics of PE (Provider Edge) - CE (Customer Edge) links in order to extend the visibility of the Traffic Engineering Database to those links. This can then be used to more efficiently compute CE-to-CE Traffic Engineering Label Swtiched Path (TE LSP) when required to provide specific services such as bandwidth guarantees and end to end fast protection in a Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN) environment.

"ZRTP: Media Path Key Agreement for Secure RTP", Philip Zimmermann, Alan Johnston, Jon Callas, 10-Mar-08. ( bytes)

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 a secret is available from the signaling protocol, authentication. ZRTP can utilize two Session Description Protocol (SDP) attributes to provide discovery and authentication through the signaling channel. To provide best effort SRTP, ZRTP utilizes normal RTP/AVP profiles.

"Session Description Protocol (SDP) Indicators for Datagram Transport Layer Security (DTLS)", Jason Fischl, Hannes Tschofenig, 18-Nov-07. ( bytes)

This specification defines how to use the Session Description Protocol (SDP) to signal that media will be transported over Datagram Transport Layer Security (DTLS) or where the SRTP security context is established using DTLS and. It reuses the syntax and semantics for an SDP 'fingerprint' attribute that identifies the certificate which will be presented during the DTLS handshake.

"DNSSEC Validator API", Abhijit Hayatnagarkar, Suresh Krishnaswamy, 4-Jan-08. ( bytes)

The DNS Security Extensions (DNSSEC) provide origin authentication and integrity of DNS data. However, the current resolver Application Programming Interface (API) does not allow a security-aware resolver to communicate detailed results of DNSSEC processing back to the application. This document describes an API between applications and a validating security-aware stub resolver that allows applications to control the validation process and obtain results of DNSSEC processing.

"Firewall friendly Return-Routability Test (RRT) for Mobile IPv6", Gabor Bajko, 25-Feb-08. ( bytes)

This document defines a slightly modified Return Routability Test (RRT) for MIPv6 [RFC3775]. The herein defined RRT mechanism is intended for CoA exchanges between the MN and the CN. Once the MN and CN find out their peers' valid addresses, an additional mechanism, defined in [I-D.tschofenig-mip6-ice], will be used to run connectivity checks to figure out which of the address pairs have connectivity and, if needed, open the required pinholes in the firewalls as described in [4]. The defined mechanism is intended to work with current firewalls without requiring any support from them.

"Internet Key Exchange Protocol: IKEv2", Charlie Kaufman, Paul Hoffman, Pasi Eronen, 25-Feb-08. ( bytes)

This document describes version 2 of the Internet Key Exchange (IKE) protocol. It is a restatement of RFC 4306, and includes all of the clarifications from RFC 4718.

"Media Playback Control Protocol Requirements", Steven Whitehead, Marie-Jose Montpetit, Xavier Marjou, Sam Ganesan, Jan Lindquist, 12-May-08. ( bytes)

The media playback control functionality controls the delivery of streaming media by the means of commands like pause, fast forward, fast rewind, slow forward, slow rewind. This document presents some of the requirements for a media control protocol that does not contain any session setup semantics in it.