Current Internet-Drafts This summary sheet provides a short synopsis of each Internet-Draft available within the "internet-drafts" directory at the shadow sites directory. These drafts are listed alphabetically by working group acronym and start date. IP over IEEE 802.16 Networks (16ng) ----------------------------------- "Transmission of IPv4 packets over IEEE 802.16's IP Convergence Sublayer", Syam Madanapalli, Soohong Daniel Park, Samita Chakrabarti, Gabriel Montenegro, 14-Jun-09, IEEE 802.16 is an air interface specification for wireless broadband access. IEEE 802.16 has specified multiple service specific Convergence Sublayers for transmitting upper layer protocols. The packet CS (Packet Convergence Sublayer) is used for the transport of all packet-based protocols such as Internet Protocol (IP) and IEEE 802.3 (Ethernet). The IP-specific part of the Packet CS enables the transport of IPv4 packets directly over the IEEE 802.16 MAC. This document specifies the frame format, the Maximum Transmission Unit (MTU) and address assignment procedures for transmitting IPv4 packets over the IP-specific part of the Packet Convergence Sublayer of IEEE 802.16. IPv6 over Low power WPAN (6lowpan) ---------------------------------- "Compression Format for IPv6 Datagrams in 6LoWPAN Networks", Jonathan Hui, Pascal Thubert, 5-Oct-09, This document specifies an IPv6 header compression format for IPv6 packet delivery in 6LoWPAN networks. The compression format relies on shared context to allow compression of arbitrary prefixes. How the information is maintained in that shared context is out of scope. This document specifies compression of multicast addresses and a framework for compressing next headers. This framework specifies UDP compression. "Design and Application Spaces for 6LoWPANs", Eunsook Kim, Dominik Kaspar, Nicolas Chevrollier, JP Vasseur, 9-Nov-09, This document investigates potential application scenarios and use cases for low-power wireless personal area networks (LoWPANs). This document provides dimensions of design space for LoWPAN applications. A list of use cases and market domains that may benefit and motivate the work currently done in the 6LoWPAN WG is provided with the characterisitcis of each dimention. A complete list of practical use cases is not the goal of this document. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 13, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "6LoWPAN Neighbor Discovery", Zach Shelby, Pascal Thubert, Jonathan Hui, Samita Chakrabarti, Carsten Bormann, Erik Nordmark, 26-Oct-09, This document specifies an extension of Neighbor Discovery for 6LoWPAN. The 6LoWPAN format allows IPv6 to be used over energy and bandwidth constrained wireless networks often making use of multihop topologies. However, the use of classic IPv6 Neighbor Discovery with 6LoWPAN has several problems. Classic Neighbor Discovery was not designed for non-transitive wireless links, and the traditional IPv6 link concept and heavy use of multicast makes it unpractical. This document specifies an ND mechanism both sufficient for minimal for LoWPAN operation which optimizes Neighbor Discovery. "Problem Statement and Requirements for 6LoWPAN Routing", Eunsook Kim, Dominik Kaspar, Carles Gomez, Carsten Bormann, 28-Jul-09, 6LoWPANs are formed by devices that are compatible with the IEEE 802.15.4 standard. However, neither the IEEE 802.15.4 standard nor the 6LoWPAN format specification define how mesh topologies could be obtained and maintained. Thus, it should be considered how 6LoWPAN formation and multi-hop routing could be supported. This document provides the problem statement and design space for 6LoWPAN routing. It defines the routing requirements for 6LoWPAN networks, considering the low-power and other particular characteristics of the devices and links. The purpose of this document is not to recommend specific solutions, but to provide general, layer-agnostic guidelines about the design of 6LoWPAN routing, which can lead to further analysis and protocol design. This document is intended as input to groups working on routing protocols relevant to 6LoWPAN, such as the IETF ROLL WG. IPv6 Maintenance (6man) ----------------------- "IPv6 Node Requirements RFC 4294-bis", John Loughney, Thomas Narten, 13-Jul-09, This document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations. Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments. "IPv6 Subnet Model: the Relationship between Links and Subnet Prefixes", Hemant Singh, Wes Beebee, Erik Nordmark, 23-Dec-09, IPv6 specifies a model of a subnet that is different than the IPv4 subnet model. The subtlety of the differences has resulted in incorrect implementations that do not interoperate. This document spells out the most important difference; that an IPv6 address isn't automatically associated with an IPv6 on-link prefix. This document also updates (partially due to security concerns caused by incorrect implementations) a part of the definition of on-link from [RFC4861]. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 26, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. "Handling of overlapping IPv6 fragments", Suresh Krishnan, 2-Jul-09, The fragmentation and reassembly algorithm specified in the base IPv6 specification allows fragments to overlap. This document demonstrates the security issues with allowing overlapping fragments and updates the IPv6 specification to explicitly forbid overlapping fragments. "A Recommendation for IPv6 Address Text Representation", Seiichi Kawamura, Masanobu Kawashima, 24-Nov-09, As IPv6 network grows, there will be more engineers and also non- engineers who will have the need to use an IPv6 address in text. While the IPv6 address architecture RFC 4291 section 2.2 depicts a flexible model for text representation of an IPv6 address, this flexibility has been causing problems for operators, system engineers, and users. This document will describe the problems that a flexible text representation has been causing. This document also recommends a canonical representation format that best avoids confusion. It is expected that the canonical format is followed by humans and systems when representing IPv6 addresses as text, but all implementations must accept and be able to handle any legitimate RFC4291 format. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 29, 2010.Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "IANA Allocation Guidelines for the IPv6 Routing Header", Jari Arkko, Scott Bradner, 12-Oct-09, This document specifies the IANA guidelines for allocating new values for the Routing Type field in the IPv6 Routing Header. "Considerations for IPv6 Address Selection Policy Changes", Tim Chown, 19-Oct-09, Where the source and/or destination node of an IPv6 communication is multi-addressed, a mechanism is required for the initiating node to select the most appropriate address pair for the communication. RFC 3484 (IPv6 Default Address Selection) [RFC3484] defines such a mechanism for nodes to perform source and destination address selection. While RFC3484 recognised the need for implementations to be able to change the policy table, it did not define how this could be achieved. Requirements have now emerged for administrators to be able to dynamically change the RFC 3484 policy tables from a central control point, and for nomadic hosts to be able to obtain the policy for the network that they are currently attached to without manual user intervention. This text discusses considerations for such policy changes, including examples of cases where a change of policy is required, and the likely frequency of such policy changes. This text also includes some discussion on the need to also update RFC 3484, where default policies are currently defined. ADSL MIB (adslmib) ------------------ "xDSL multi-pair bonding using Time-Division Inverse Multiplexing (G.Bond/TDIM) MIB", Edward Beili, 17-Aug-09, This document defines Management Information Base (MIB) module for use with network management protocols in TCP/IP based internets. This document proposes an extension to the G.Bond MIB module with a set of objects for managing multi-pair bonded xDSL interfaces using Time-Division Inverse Multiplexing (TDIM), defined in ITU-T recommendation G.998.3. Application-Layer Traffic Optimization (alto) --------------------------------------------- "Application-Layer Traffic Optimization (ALTO) Requirements", Sebastian Kiesel, Laird Popkin, Stefano Previdi, Richard Woundy, Yang Yang, 23-Oct-09, Many Internet applications are used to access resources, such as pieces of information or server processes, which are available in several equivalent replicas on different hosts. This includes, but is not limited to, peer-to-peer file sharing applications. The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications, which have to select one or several hosts from a set of candidates, that are able to provide a desired resource. This guidance shall be based on parameters that affect performance and efficiency of the data transmission between the hosts, e.g., the topological distance. The ultimate goal is to improve performance (or Quality of Experience) in the application while reducing resource consumption in the underlying network infrastructure. This document enumerates requirements for ALTO, which should be considered when specifying, assessing, or comparing protocols and implementations, and it solicits feedback and discussion. "ALTO Protocol", Richard Alimi, Reinaldo Penno, Yang Yang, 16-Dec-09, Networking applications today already have access to a great amount of Inter-Provider network topology information. For example, views of the Internet routing table are easily available at looking glass servers and entirely practical to be downloaded by clients. What is missing is knowledge of the underlying network topology from the ISP or Content Provider (henceforth referred as Provider) point of view. In other words, what an Provider prefers in terms of traffic optimization -- and a way to distribute it. The ALTO Service provides information such as preferences of network resources with the goal of modifying network resource consumption patterns while maintaining or improving application performance. This document describes a protocol implementing the ALTO Service. While such service would primarily be provided by the network (i.e., the ISP), content providers and third parties could also operate this service. Applications that could use this service are those that have a choice in connection endpoints. Examples of such applications are peer-to-peer (P2P) and content delivery networks. Access Node Control Protocol (ancp) ----------------------------------- "Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks", Sven Ooghe, Norbert Voigt, Michel Platnic, Thomas Haag, Sanjay Wadhwa, 5-Oct-09, The purpose of this document is to define a framework for an Access Node Control Mechanism between a Network Access Server (NAS) and an Access Node (e.g. a Digital Subscriber Line Access Multiplexer (DSLAM)) in a multi-service reference architecture in order to perform QoS-related, service-related and Subscriber-related operations. The Access Node Control Mechanism will ensure that the transmission of the information does not need to go through distinct element managers but rather using a direct device-device communication. This allows for performing access link related operations within those network elements, while avoiding impact on the existing Operational Support Systems (OSSes). This document first identifies a number of use cases for which the Access Node Control Mechanism may be appropriate. It then presents the requirements for the Access Node Control Protocol that must be taken into account during protocol design. Finally, it describes requirements for the network elements that need to support ANCP and the described use cases. These requirements should be seen as guidelines rather than as absolute requirements. RFC 2119 therefore does not apply to the nodal requirements. "Security Threats and Security Requirements for the Access Node Control Protocol (ANCP)", Hassnaa Moustafa, Hannes Tschofenig, Stefaan De Cnodder, 9-Jul-09, The Access Node Control Protocol (ANCP) aims to communicate QoS- related, service-related and subscriber-related configurations and operations between a Network Access Server (NAS) and an Access Node (e.g., a Digital Subscriber Line Access Multiplexer (DSLAM)). The main goal of this protocol is to allow the NAS to configure, manage and control access equipments including the ability for the access nodes to report information to the NAS. The present document investigates security threats that all ANCP nodes could encounter. This document develops a threat model for ANCP security aiming to decide which security functions are required. Based on this, security requirements regarding the Access Node Control Protocol are defined. "Protocol for Access Node Control Mechanism in Broadband Networks", Sanjay Wadhwa, Jerome Moisand, Swami Subramanian, Thomas Haag, Norber Voigt, Roberta Maglione, 8-Nov-09, This document describes proposed extensions to the GSMPv3 protocol to allow its use in a broadband environment, as a control plane between Access Nodes (e.g. DSLAM) and Broadband Network Gateways (e.g. NAS). These proposed extensions are required to realize a protocol for "Access Node Control" mechanism as described in [ANCP-FRAMEWORK]. The resulting protocol with the proposed extensions to GSMPv3 [RFC3292] is referred to as "Access Node Control Protocol" (ANCP). This document currently focuses on specific use cases of access node control mechanism for topology discovery, line configuration, and OAM as described in ANCP framework document [ANCP-FRAMEWORK]. It is intended to be augmented by additional protocol specification for future use cases considered in scope by the ANCP charter. ANCP framework document [ANCP-FRAMEWORK] describes the ANCP use-cases in detail. Illustrative text for the use-cases is included here to help the protocol implementer understand the greater context of ANCP protocol interactions. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 13, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "Access Node Control Protocol (ANCP) MIB module for Access Nodes", Stefaan De Cnodder, Moti Morgenstern, 31-Jul-09, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines objects for managing access nodes that are using the Access Node Control Protocol (ANCP). "Additional Multicast Control Extensions for ANCP", Francois Le Faucheur, Roberta Maglione, Tom Taylor, 27-Oct-09, This document specifies the extensions to the Access Node Control Protocol required for support of the multicast use cases defined in the Access Node Control Protocol framework document. Those use cases are organized into the following ANCP capabilities: o NAS-initiated multicast replication; o conditional access with white and black lists; o conditional access with grey lists; o bandwidth delegation. These capabilities may be combined according to the rules given in this specification. Ad-Hoc Network Autoconfiguration (autoconf) ------------------------------------------- "IP Addressing Model in Ad Hoc Networks", Emmanuel Baccelli, Mark Townsley, 7-Dec-09, This document describes a model for configuring IP addresses and subnet prefixes on the interfaces of routers which connect to links with undetermined connectivity properties. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 10, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Audio/Video Transport (avt) --------------------------- "RTCP Extensions for Single-Source Multicast Sessions with Unicast Feedback", Joerg Ott, Julian Chesterfield, 8-Nov-09, This document specifies an extension to the Real-time Transport Control Protocol (RTCP) to use unicast feedback to a multicast sender. The proposed extension is useful for single-source multicast sessions such as Source-Specific Multicast (SSM) communication where the traditional model of many-to-many group communication is either not available or not desired. In addition, it can be applied to any group that might benefit from a sender-controlled summarized reporting mechanism. "The use of AES-192 and AES-256 in Secure RTP", David McGrew, 25-Oct-09, This memo describes the use of the Advanced Encryption Standard (AES) with 192 and 256 bit keys within the Secure RTP protocol. It defines Counter Mode encryption for SRTP and SRTCP and a new SRTP Key Derivation Function (KDF) for AES-192 and AES-256. "Multiplexing RTP Data and Control Packets on a Single Port", Colin Perkins, Magnus Westerlund, 6-Aug-07, This memo discusses issues that arise when multiplexing RTP data packets and RTP control protocol (RTCP) packets on a single UDP port. It updates RFC 3550 to describe when such multiplexing is, and is not, appropriate, and explains how the Session Description Protocol (SDP) can be used to signal multiplexed sessions. "RTP Payload Format for SVC Video", Stephan Wenger, Ye-Kui Wang, Thomas Schierl, Alex Eleftheriadis, 26-Oct-09, This memo describes an RTP payload format for Scalable Video Coding (SVC) as defined in_Annex G of ITU-T Recommendation H.264, which is technically identical to Amendment 3 of ISO/IEC International Standard 14496-10. The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload, as well as fragmentation of a NAL unit in multiple RTP packets. Furthermore, it supports transmission of an SVC stream over a single as well as multiple RTP sessions. The payload format defines a new media subtype name "H264-SVC", but is still backwards compatible to [I-D.ietf-avt-rtp-rfc3984bis] since the base layer, when encapsulated in its own RTP stream, must use the H.264 media subtype name ("H264") and the packetization method specified in [I- D.ietf-avt-rtp-rfc3984bis]. The payload format has wide applicability in videoconferencing, Internet video streaming, and high bit-rate entertainment-quality video, among others. "RTP Payload Format for MIDI", John Lazzaro, John Wawrzynek, 10-Aug-09, This memo describes a Real-time Transport Protocol (RTP) payload format for the MIDI (Musical Instrument Digital Interface) command language. The format encodes all commands that may legally appear on a MIDI 1.0 DIN cable. The format is suitable for interactive applications (such as network musical performance) and content- delivery applications (such as file streaming). The format may be used over unicast and multicast UDP and TCP, and it defines tools for graceful recovery from packet loss. Stream behavior, including the MIDI rendering method, may be customized during session setup. The format also serves as a mode for the mpeg4-generic format, to support the MPEG 4 Audio Object Types for General MIDI, Downloadable Sounds Level 2, and Structured Audio. "Application Mechanism for maintaining alive the Network Address Translator (NAT) mappings associated to RTP flows.", Xavier Marjou, Aurelien Sollaud, 7-Dec-09, This document lists the different mechanisms that enable applications using Real-time Transport Protocol (RTP) to maintain their RTP Network Address Translator (NAT) mappings alive. It also makes a recommendation for a preferred mechanism. This document is not applicable to Interactive Connectivity Establishment (ICE) agents. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 11, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for Secure Real-time Transport Protocol (SRTP)", David McGrew, Eric Rescorla, 28-Feb-09, This document describes a Datagram Transport Layer Security (DTLS) extension to establish keys for secure RTP (SRTP) and secure RTP Control Protocol (SRTCP) flows. DTLS keying happens on the media path, independent of any out-of-band signalling channel present. "Forward-shifted RTP Redundancy Payload Support", Qiaobing Xie, 11-Dec-09, This document defines a simple enhancement to RFC 2198 to support RTP sessions with forward-shifted redundant encodings, i.e., redundant data sent before the corresponding primary data. Forward-shifted redundancy can be used to conceal losses of a large number of consecutive media frames (e.g., consecutive loss of seconds or even tens of seconds of media). Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 14, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "The SEED Cipher Algorithm and Its Use with the Secure Real-time Transport Protocol (SRTP)", Seokung Yoon, Joongman Kim, Haeryong Park, Hyuncheol Jeong, Yoojae Won, 15-Jun-09, This document describes the use of the SEED block cipher algorithm in the Secure Real-time Transport Protocol (SRTP) for providing confidentiality for the Real-time Transport Protocol (RTP) traffic and for the control traffic for RTP, the Real-time Transport Control Protocol (RTCP). "RTP Payload Format for H.264 RCDO Video", Tom Kristensen, Patrick Luthi, 15-Dec-09, This document describes an RTP Payload format for the Reduced- Complexity Decoding Operation (RCDO) for H.264 Baseline profile bitstreams, as specified in ITU-T Recommendation H.241. RCDO reduces the decoding cost and resource consumption of the video processing. The RTP Payload format is based on the description in RFC3984bis. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 18, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "RTP Payload Format for IP-MR Speech Codec draft-ietf-avt-rtp-ipmr-10.txt", SPIRIT DSP, 5-Oct-09, This document specifies the payload format for packetization of SPIRIT IP-MR encoded speech signals into the Real-time Transport Protocol (RTP). The payload format supports transmission of multiple frames per payload and introduced redundancy for robustness against packet loss. Table of Contents "Post-Repair Loss RLE Report Block Type for RTCP XR", Ali Begen, Dong Hsu, Michael Lague, 10-Nov-09, This document defines a new report block type within the framework of RTP Control Protocol (RTCP) Extended Reports (XR). One of the initial XR report block types is the Loss Run Length Encoding (RLE) Report Block. This report conveys the information regarding the individual Real-time Transport Protocol (RTP) packet receipt and loss events experienced during the RTCP interval preceding the transmission of the report. The new report, which is referred to as the Post-repair Loss RLE Report, carries the information regarding the remaining lost packets after all loss-repair methods are applied. By comparing the RTP packet receipts/losses before and after the loss repair is completed, one can determine the effectiveness of the loss- repair methods in an aggregated fashion. This document also defines the signaling of the Post-repair Loss RLE Report in the Session Description Protocol (SDP). Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 15, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. "Guidelines for Extending the RTP Control Protocol (RTCP)", Joerg Ott, Colin Perkins, 5-Jan-10, The RTP Control Protocol (RTCP) is used along with the Real-time Transport Protocol (RTP) to provide a control channel between media senders and receivers. This allows constructing a feedback loop to enable application adaptivity and monitoring, among other uses. The basic reporting mechanisms offered by RTCP are generic, yet quite powerful and suffice to cover a range of uses. This document provides guidelines on extending RTCP if those basic mechanisms prove insufficient. "Why RTP Does Not Mandate a Single Security Mechanism", Colin Perkins, Magnus Westerlund, 22-Dec-09, This memo discusses the problem of securing real-time multimedia sessions, and explains why the Real-time Transport Protocol (RTP), and the associated RTP control protocol (RTCP), do not mandate a single media security mechanism. "RTP Payload Format for H.264 Video", Ye-Kui Wang, Roni Even, Tom Kristensen, Randell Jesup, 21-Sep-09, This memo describes an RTP Payload format for the ITU-T Recommendation H.264 video codec and the technically identical ISO/IEC International Standard 14496-10 video codec, excluding the Scalable Video Coding (SVC) extension and the Multivew Video Coding extension, for which the RTP payload formats are defined elsewhere. The RTP payload format allows for packetization of one or more Network Abstraction Layer Units (NALUs), produced by an H.264 video encoder, in each RTP payload. The payload format has wide applicability, as it supports applications from simple low bit-rate conversational usage, to Internet video streaming with interleaved transmission, to high bit-rate video-on-demand. This memo obsoletes RFC 3984. Changes from RFC 3984 are summarized in section 18. Issues on backward compatibility to RFC 3984 are discussed in section 17. "RTP payload format for G.718 speech/audio", Ari Lakaniemi, Ye-Kui Wang, 22-Oct-09, This document specifies the Real-Time Transport Protocol (RTP) payload format for the Embedded Variable Bit-Rate (EV-VBR) speech/audio codec, specified in ITU-T G.718. A media type registration for this RTP payload format is also included. "Rapid Synchronisation of RTP Flows", Colin Perkins, Thomas Schierl, 8-Jan-10, This memo outlines how RTP sessions are synchronised, and discusses how rapidly such synchronisation can occur. We show that most RTP sessions can be synchronised immediately, but that the use of video switching multipoint conference units (MCUs) or large source specific multicast (SSM) groups can greatly increase the synchronisation delay. This increase in delay can be unacceptable to some applications that use layered and/or multi-description codecs. This memo introduces three mechanisms to reduce the synchronisation delay for such sessions. First, it updates the RTP Control Protocol (RTCP) timing rules to reduce the initial synchronisation delay for SSM sessions. Second, a new feedback packet is defined for use with the Extended RTP Profile for RTCP-based Feedback (RTP/AVPF), allowing video switching MCUs to rapidly request resynchronisation. Finally, new RTP header extensions are defined to allow rapid synchronisation of late joiners, and guarantee correct timestamp based decoding order recovery for layered codecs in the presence of clock skew. "RTP Payload format for GSM-HR", Xiaodong Duan, Shuaiyu Wang, Magnus Westerlund, Karl Hellwig, Ingemar Johansson, 30-Sep-09, This document specifies the payload format for packetization of the GSM Half-Rate speech codec data into the Real-time Transport Protocol (RTP). The payload format supports transmission of multiple frames per payload and packet loss robustness methods using redundancy. "Unicast-Based Rapid Acquisition of Multicast RTP Sessions", Bill Ver Steeg, Ali Begen, Tom Van Caenegem, Zeev Vax, 16-Nov-09, When an RTP receiver joins a primary multicast session, it may need to acquire and parse certain Reference Information before it can process any data sent in the multicast session. Depending on the join time, length of the Reference Information repetition interval, size of the Reference Information as well as the application and transport properties, the time lag before an RTP receiver can usefully consume the multicast data, which we refer to as the Acquisition Delay, varies and may be large. This is an undesirable phenomenon for receivers that frequently switch among different multicast sessions, such as video broadcasts. In this document, we describe a method using the existing RTP and RTCP protocol machinery that reduces the acquisition delay. In this method, an auxiliary unicast RTP session carrying the Reference Information to the receiver precedes/accompanies the primary multicast stream. This unicast RTP flow may be transmitted at a faster than natural rate to further accelerate the acquisition. The motivating use case for this capability is multicast applications that carry real-time compressed audio and video. However, the proposed method can also be used in other types of multicast applications where the acquisition delay is long enough to be a problem. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 20, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Behavior Engineering for Hindrance Avoidance (behave) ----------------------------------------------------- "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", Jonathan Rosenberg, Rohan Mahy, Philip Matthews, 3-Jul-09, If a host is located behind a NAT, then in certain situations it can be impossible for that host to communicate directly with other hosts (peers). In these situations, it is necessary for the host to use the services of an intermediate node that acts as a communication relay. This specification defines a protocol, called TURN (Traversal Using Relays around NAT), that allows the host to control the operation of the relay and to exchange packets with its peers using the relay. TURN differs from some other relay control protocols in that it allows a client to communicate with multiple peers using a single relay address. The TURN protocol was designed to be used as part of the ICE (Interactive Connectivity Establishment) approach to NAT traversal, though it can be also used without ICE. "Traversal Using Relays around NAT (TURN) Extension for IPv6", Simon Perreault, Gonzalo Camarillo, Oscar Novo, 17-Dec-09, This document adds IPv6 support to Traversal Using Relays around NAT (TURN). IPv6 support in TURN includes IPv4-to-IPv6, IPv6-to-IPv6, and IPv6-to-IPv4 relaying. This document defines the REQUESTED- ADDRESS-FAMILY attribute for TURN. The REQUESTED-ADDRESS-FAMILY attribute allows a client to explicitly request the address type the TURN server will allocate (e.g., an IPv4-only node may request the TURN server to allocate an IPv6 address). "NAT Behavior Discovery Using STUN", Derek MacDonald, Bruce Lowekamp, 27-Sep-09, This specification defines an experimental usage of the Session Traversal Utilities for NAT (STUN) Protocol that discovers the presence and current behaviour of NATs and firewalls between the STUN client and the STUN server. "Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations", Simon Perreault, Jonathan Rosenberg, 19-Oct-09, This specification defines an extension of Traversal Using Relays around NAT (TURN), a relay protocol for NAT traversal, to allow a TURN client to request TCP allocations, and defines new requests and indications for the TURN server to open and accept TCP connections with the client's peers. TURN and this extension both purposefully restrict the ways in which the relayed address can be used. In particular, it prevents users from running general purpose servers from ports obtained from the TURN server. "Test vectors for STUN", Remi Denis-Courmont, 18-Nov-08, The Session Traversal Utilities for NAT (STUN) protocol defines several STUN attributes. The content of some of these -- FINGERPRINT, MESSAGE-INTEGRITY and XOR-MAPPED-ADDRESS -- involve binary-logical operations (hashing, xor). This document provides test vectors for those attributes. "Stream Control Transmission Protocol (SCTP) Network Address Translation", Randall Stewart, Michael Tuexen, Irene Ruengeler, 21-Dec-09, 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 a 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 NATs 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 and multi-point traversal scenario. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 24, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "Traversal Using Relays around NAT (TURN) Resolution Mechanism", Marc Petit-Huguenin, 25-Nov-09, This document defines a resolution mechanism to generate a list of server transport addresses that can be tried to create a Traversal Using Relays around NAT (TURN) allocation. "IP/ICMP Translation Algorithm", Xing Li, Congxiao Bao, Fred Baker, 17-Dec-09, This document specifies an update to the Stateless IP/ICMP Translation Algorithm (SIIT) described in RFC 2765. The algorithm translates between IPv4 and IPv6 packet headers (including ICMP headers). This specification addresses both a stateless and a stateful mode. In the stateless mode, translation information is carried in the address itself, permitting both IPv4->IPv6 and IPv6->IPv4 session establishment without maintaining state in the IP/ICMP translator. In the stateful mode, translation state is maintained between IPv4 address/transport port tuples and IPv6 address/transport port tuples, enabling IPv6 systems to open sessions with IPv4 systems. The choice of operational mode is made by the operator deploying the network and is critical to the operation of the applications using it. Acknowledgement of previous work This document is a product of the 2008-2009 effort to define a replacement for NAT-PT. It is an update to and directly derivative from Erik Nordmark's [RFC2765], which similarly provides both stateless and stateful translation between IPv4 [RFC0791] and IPv6 [RFC2460], and between ICMPv4 [RFC0792] and ICMPv6 [RFC4443]. The original document was a product of the NGTRANS working group. The changes in this document reflect five components: 1. Redescribing the network model to map to present and projected usage [I-D.ietf-behave-v6v4-framework]. 2. Moving the address format to the address format document [I-D.ietf-behave-address-format], to coordinate with other drafts on the topic. 3. Describing both stateful and stateless operation. 4. Some changes in ICMP. 5. Updating references. Requirements "DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", Marcelo Bagnulo, Andrew Sullivan, Philip Matthews, Iljitsch van Beijnum, 17-Dec-09, DNS64 is a mechanism for synthesizing AAAA records from A records. DNS64 is used with an IPv6/IPv4 translator to enable client-server communication between an IPv6-only client and an IPv4-only server, without requiring any changes to either the IPv6 or the IPv4 node, for the class of applications that work through NATs. This document specifies DNS64, and provides suggestions on how it should be deployed in conjunction with IPv6/IPv4 translators. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 20, 2010.Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", Marcelo Bagnulo, Philip Matthews, Iljitsch van Beijnum, 17-Dec-09, NAT64 is a mechanism for translating IPv6 packets to IPv4 packets and vice-versa. DNS64 is a mechanism for synthesizing AAAA records from A records. These two mechanisms together enable client-server communication between an IPv6-only client and an IPv4-only server, without requiring any changes to either the IPv6 or the IPv4 node, for the class of applications that work through NATs. They also enable peer-to-peer communication between an IPv4 and an IPv6 node, where the communication can be initiated by either end using existing, NAT-traversing, peer-to-peer communication techniques. NAT64 also support IPv4 initiated communications to a subset of the IPv6 hosts through statically configured bindings in the NAT64. This document specifies NAT64, and gives suggestions on how it should be deployed. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 20, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. "Framework for IPv4/IPv6 Translation", Fred Baker, Xing Li, Congxiao Bao, Kevin Yin, 17-Dec-09, This note describes a framework for IPv4/IPv6 translation. This is in the context of replacing NAT-PT, which was deprecated by RFC 4966, and to enable networks to have IPv4 and IPv6 coexist in a somewhat rational manner while transitioning to an IPv6 network. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 20, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "IPv6 Addressing of IPv4/IPv6 Translators", Christian Huitema, Congxiao Bao, Marcelo Bagnulo, Mohammed Boucadair, Xing Li, 17-Dec-09, This document discusses the algorithmic translation of an IPv6 address to a corresponding IPv4 address, and vice versa, using only statically configured information. It defines a Well-Known Prefix for use in algorithmic translations, while allowing organizations to also use Network Specific Prefixes when appropriate. Algorithmic translation is used in IPv4/IPv6 translators, as well as other types of proxies and gateways (e.g., for DNS) used in IPv4/IPv6 scenarios. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 20, 2010.Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "IPv6-to-IPv4 translation FTP considerations", Iljitsch van Beijnum, 17-Dec-09, The File Transfer Protocol has a very long history, and despite the fact that today, other options exist to perform file transfers, FTP is still in common use. As such, it is important that in the situation where some client computers are IPv6-only while many servers are still IPv4-only and IPv6-to-IPv4 translators are used to bridge that gap, FTP is made to work through these translators as best it can. FTP has an active and a passive mode, both as original commands that are IPv4-specific, and as extended, IP version agnostic commands. The only FTP mode that works without changes through an IPv6-to-IPv4 translator is extended passive. However, many existing FTP servers don't support this mode, and some clients don't ask for it. This document describes server, client and middlebox (if any) behavior that minimizes this problem. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 20, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Bidirectional Forwarding Detection (bfd) ---------------------------------------- "BFD For MPLS LSPs", Rahul Aggarwal, Kireeti Kompella, Thomas Nadeau, George Swallow, 20-Jun-08, One desirable application of Bi-directional Forwarding Detection (BFD) is to detect a Multi Protocol Label Switched (MPLS) Label Switched Path (LSP) data plane failure. LSP-Ping is an existing mechanism for detecting MPLS data plane failures and for verifying the MPLS LSP data plane against the control plane. BFD can be used for the former, but not for the latter. However the control plane processing required for BFD control packets is relatively smaller than the processing required for LSP-Ping messages. A combination of LSP-Ping and BFD can be used to provide faster data plane failure detection and/or make it possible to provide such detection on a greater number of LSPs. This document describes the applicability of BFD in relation to LSP-Ping for this application. It also describes procedures for using BFD in this environment. "Bidirectional Forwarding Detection", Dave Katz, David Ward, 5-Jan-10, This document describes a protocol intended to detect faults in the bidirectional path between two forwarding engines, including interfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. It operates independently of media, data protocols, and routing protocols. "BFD for Multihop Paths", Dave Katz, David Ward, 5-Jan-10, This document describes the use of the Bidirectional Forwarding Detection protocol (BFD) over multihop paths, including unidirectional links. "BFD for IPv4 and IPv6 (Single Hop)", Dave Katz, David Ward, 5-Jan-10, This document describes the use of the Bidirectional Forwarding Detection protocol over IPv4 and IPv6 for single IP hops. "Generic Application of BFD", Dave Katz, David Ward, 5-Feb-09, This document describes the generic application of the Bidirectional Forwarding Detection (BFD) protocol. Basic Level of Interoperability for SIP Services (bliss) -------------------------------------------------------- "An Analysis of Automatic Call Handling Implementation Issues in the Session Initiation Protocol (SIP)", John Elwell, 19-Oct-09, This discusses problems associated with automatic call handling (ACH) when using the Session Initiation Protocol (SIP) and specifies some best practices to help achieve interoperability. This work is being discussed on the bliss@ietf.org mailing list. "Call Completion for Session Initiation Protocol (SIP)", Dale Worley, Martin Huelsemann, Roland Jesske, Denis Alexeitsev, 26-Oct-09, The call completion features allow the calling user of a failed call to be notified when the called user becomes available to receive a call. For the realization of a basic solution without queueing call- completion requests, this document references the usage of the the dialog event package [RFC4235] as described as 'automatic redial' in [RFC5359]. For the realization of a more comprehensive solution with queueing call-completion requests, this document introduces an architecture for implementing these features in the Session Initiation Protocol: "Call completion" implementations associated with the caller's and callee's endpoints cooperate to place the caller's request for call completion into a queue at the callee's endpoint, and, when a caller's request is ready to be serviced, re-attempt the original, failed call. The deployment of a certain SIP call-completion solution is also dependent on the needed level of interoperability with existing call- completion solutions in other networks. "Shared Appearances of a Session Initiation Protocol (SIP) Address of Record (AOR)", Alan Johnston, Mohsen Soroushnejad, Venkatesh Venkataramanan, 26-Oct-09, This document describes the requirements and implementation of a group telephony feature commonly known as Bridged Line Appearance (BLA) or Multiple Line Appearance (MLA), or Shared Call/Line Appearance (SCA). When implemented using the Session Initiation Protocol (SIP), it is referred to as shared appearances of an Address of Record (AOR) since SIP does not have the concept of lines. This feature is commonly offered in IP Centrex services and IP-PBX offerings and is likely to be implemented on SIP IP telephones and SIP feature servers used in a business environment. This document discusses use cases, lists requirements and defines SIP extensions to implement this feature. "Implementing Call Park and Retrieve using the Session Initiation Protocol (SIP)", Michael Procter, 14-Oct-09, Call Park and Call Retrieve are useful telephony services that are familiar to many users. Existing implementations using the Session Initiation Protocol (SIP) show that a variety of approaches can be Taken, with varying degrees of interoperability. This draft discusses a number of feature variations, and how they may be implemented using existing techniques. An additional URI parameter is also described, which enables further common use-cases to be implemented. Benchmarking Methodology (bmwg) ------------------------------- "Terminology for Benchmarking IPsec Devices", Merike Kaeo, Tim Van Herck, Michele Bustos, 28-Jul-09, This purpose of this document is to define terminology specific to measuring the performance of IPsec devices. It builds upon the tenets set forth in [RFC1242], [RFC2544], [RFC2285] and other IETF Benchmarking Methodology Working Group (BMWG) documents used for benchmarking routers and switches. This document seeks to extend these efforts specific to the IPsec paradigm. The BMWG produces two major classes of documents: Benchmarking Terminology documents and Benchmarking Methodology documents. The Terminology documents present the benchmarks and other related terms. The Methodology documents define the procedures required to collect the benchmarks cited in the corresponding Terminology documents. "Benchmarking Methodology for Link-State IGP Data Plane Route Convergence", Scott Poretsky, Brent Imhoff, Kris Michielsen, 26-Oct-09, This document describes the methodology for benchmarking Link-State Interior Gateway Protocol (IGP) Route Convergence. The methodology is to be used for benchmarking IGP convergence time through externally observable (black box) data plane measurements. The methodology can be applied to any link-state IGP, such as ISIS and OSPF. "Terminology for Benchmarking Link-State IGP Data Plane Route Convergence", Scott Poretsky, Brent Imhoff, Kris Michielsen, 26-Oct-09, This document describes the terminology for benchmarking Interior Gateway Protocol (IGP) Route Convergence. The terminology is to be used for benchmarking IGP convergence time through externally observable (black box) data plane measurements. The terminology can be applied to any link-state IGP, such as ISIS and OSPF. "Methodology for Benchmarking IPsec Devices", Merike Kaeo, Tim Van Herck, 28-Jul-09, The purpose of this draft is to describe methodology specific to the benchmarking of IPsec IP forwarding devices. It builds upon the tenets set forth in [RFC2544], [RFC2432] and other IETF Benchmarking Methodology Working Group (BMWG) efforts. This document seeks to extend these efforts to the IPsec paradigm. The BMWG produces two major classes of documents: Benchmarking "Benchmarking Terminology for Protection Performance", Rajiv Papneja, Scott Poretsky, Samir Vapiwala, Jay Karthik, 21-Dec-09, This document provides common terminology and metrics for benchmarking the performance of sub-IP layer protection mechanisms. The performance benchmarks are measured at the IP-Layer, avoiding dependence on specific sub-IP protection mechanisms. The benchmarks and terminology can be applied in methodology documents for different sub-IP layer protection mechanisms such as Automatic Protection Switching (APS), Virtual Router Redundancy Protocol (VRRP), Stateful High Availability (HA), and Multi-Protocol Label Switching Fast Reroute (MPLS-FRR). "Methodology for benchmarking MPLS protection mechanisms", Rajiv Papneja, Scott Poretsky, Shankar Rao, Samir Vapiwala, Jay Karthik, Jean-Louis Le Roux, 21-Dec-09, This draft describes the methodology for benchmarking MPLS Protection mechanisms for link and node protection as defined in [MPLS-FRR-EXT]. This document provides test methodologies and testbed setup for measuring failover times while considering all dependencies that might impact faster recovery of real-time applications bound to MPLS based traffic engineered tunnels. The benchmarking terms used in this document are defined in [TERM-ID]. Calendaring and Scheduling Standards Simplification (calsify) ------------------------------------------------------------- "iCalendar Message-Based Interoperability Protocol (iMIP)", Alexey Melnikov, 9-Oct-09, This document, iCalendar Message-Based Interoperability Protocol (iMIP), specifies a binding from the iCalendar Transport-independent Interoperability Protocol (iTIP) to Internet email-based transports. Calendaring entries defined by the iCalendar Object Model (iCAL) are wrapped using constructs from RFC 5322, RFC 2045, RFC 2046, RFC 2047 and RFC 2049, and then transported over SMTP. This document is a product of the Calendaring and Scheduling Standards Simplification (calsify) working group. More information about the IETF CALSIFY working group activities can be found on the IETF web site at . The issue tracker for the Calsify WG is located at: "iCalendar Transport-Independent Interoperability Protocol (iTIP)", Cyrus Daboo, 4-Oct-09, This document specifies a protocol using the iCalendar object specification to provide scheduling interoperability between different calendaring systems. This is done without reference to a specific transport protocol so as to allow multiple methods of communication between systems. Subsequent documents will define profiles of this protocol using specific interoperable methods of communications between systems. iTIP complements the iCalendar object specification by adding semantics for group scheduling methods commonly available in current calendaring systems. These scheduling methods permit two or more calendaring systems to perform transactions such as publish, schedule, reschedule, respond to scheduling requests, negotiation of changes or cancel. Control And Provisioning of Wireless Access Points (capwap) ----------------------------------------------------------- "CAPWAP Protocol Base MIB", Yang Shi, David Perkins, Chris Elliott, Yong Zhang, 11-Jan-10, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it describes the managed objects for modeling the Control And Provisioning of Wireless Access Points (CAPWAP) Protocol. Status of This Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 15, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "CAPWAP Protocol Binding MIB for IEEE 802.11", Yang Shi, David Perkins, Chris Elliott, Yong Zhang, 2-Jan-10, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it describes managed objects for modeling the Control And Provisioning of Wireless Access Points (CAPWAP) Protocol for IEEE 802.11 wireless binding. Status of This Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 6, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Common Control and Measurement Plane (ccamp) -------------------------------------------- "Procedures for Dynamically Signaled Hierarchical Label Switched Paths", Kohei Shiomoto, Adrian Farrel, Richard Rabbat, Arthi Ayyangar, Zafar Ali, 19-Oct-09, Label Switched Paths (LSPs) set up in Multiprotocol Label Switching (MPLS) or Generalized MPLS (GMPLS) networks can be used to form links to carry traffic in those networks or in other (client) networks. Protocol mechanisms already exist to facilitate the establishment of such LSPs and to bundle TE links to reduce the load on routing protocols. This document defines extensions to those mechanisms to support identifying the use to which such LSPs are to be put and to enable the TE link endpoints to be assigned addresses or unnumbered identifiers during the signaling process. The mechanisms defined in this document deprecates the technique for the signaling of LSPs that are to be used as numbered TE links described in RFC 4206. "Ethernet Traffic Parameters", Dimitri Papadimitriou, 11-Nov-09, This document describes the support of Metro Ethernet Forum (MEF) Ethernet Traffic Parameters as described in MEF10.1 when using Generalized Multi-Protocol Label Switching (GMPLS) Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling. "OSPFv2 Routing Protocols Extensions for ASON Routing", Dimitri Papadimitriou, 16-Aug-09, The ITU-T has defined an architecture and requirements for operating an Automatically Switched Optical Network (ASON). The Generalized Multiprotocol Label Switching (GMPLS) protocol suite is designed to provide a control plane for a range of network technologies including optical networks such as time division multiplexing (TDM) networks including SONET/SDH and Optical Transport Networks (OTNs), and lambda switching optical networks. The requirements for GMPLS routing to satisfy the requirements of ASON routing, and an evaluation of existing GMPLS routing protocols are provided in other documents. This document defines extensions to the OSPFv2 Link State Routing Protocol to meet the requirements for routing in an ASON. Note that this work is scoped to the requirements and evaluation expressed in RFC 4258 and RFC 4652 and the ITU-T Recommendations current when those documents were written. Future extensions of revisions of this work may be necessary if the ITU-T Recommendations are revised or if new requirements are introduced into a revision of RFC 4258. "Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering Networks", Zafar Ali, JP Vasseur, Anca Zamfir, 15-Sep-09, MPLS-TE Graceful Shutdown is a method for explicitly notifying the nodes in a Traffic Engineering (TE) enabled network that the TE capability on a link or on an entire Label Switching Router (LSR) is going to be disabled. MPLS-TE graceful shutdown mechanisms are tailored toward addressing planned outage in the network. This document provides requirements and protocol mechanisms to reduce/eliminate traffic disruption in the event of a planned shutdown of a network resource. These operations are equally applicable to both MPLS-TE and its Generalized MPLS (GMPLS) extensions. "draft-ietf-ccamp-gmpls-vcat-lcas-09.txt", Greg Bernstein, Diego Caviglia, Richard Rabbat, Huub Helvoort, 11-Jan-10, This document describes requirements for, and use of, the Generalized Multi-Protocol Label Switching (GMPLS) control plane in conjunction with the Virtual Concatenation (VCAT) layer 1 inverse multiplexing mechanism and its companion Link Capacity Adjustment Scheme (LCAS) which can be used for hitless dynamic resizing of the inverse multiplex group. These techniques apply to Optical Transport Network (OTN), Synchronous Optical Network (SONET), Synchronous Digital Hierarchy (SDH), and Plesiochronous Digital Hierarchy (PDH) signals. "Traffic Engineering Database Management Information Base in support of MPLS-TE/GMPLS", Masanori Miyazawa, Tomohiro Otani, Kenji Kumaki, Thomas Nadeau, 26-Oct-09, This memo defines the Management Information Base (MIB) objects in order to manage traffic engineering database (TED) information with extension in support of Multi-Protocol Label Switching (MPLS) with traffic engineering (TE) as well as Generalized MPLS (GMPLS) for use with network management protocols. "Generalized Multi-Protocol Label Switching (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN)", Dimitri Papadimitriou, Martin Vigoureux, Kohei Shiomoto, Deborah Brungard, Jean-Louis Le Roux, 14-Dec-09, There are specific requirements for the support of networks comprising Label Switching Routers (LSR) participating in different data plane switching layers controlled by a single Generalized Multi Protocol Label Switching (GMPLS) control plane instance, referred to as GMPLS Multi-Layer Networks/ Multi-Region Networks (MLN/MRN). This document defines extensions to GMPLS routing and signaling protocols so as to support the operation of GMPLS Multi- Layer/Multi-Region Networks. It covers the elements of a single GMPLS control plane instance controlling multiple LSP regions or layers within a single TE domain. "Generalized Multi-Protocol Label Switching (GMPLS) Ethernet Label Switching Architecture and Framework", Don Fedyk, Lou Berger, Loa Andersson, 18-Dec-09, There has been significant recent work in increasing the capabilities of Ethernet switches and Ethernet forwarding models. As a consequence, the role of Ethernet is rapidly expanding into "transport networks" that previously were the domain of other technologies such as Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH), Time-Division Multiplex (TDM) and Asynchronous Transfer Mode (ATM). This document defines an architecture and framework for a Generalized MPLS based control plane for Ethernet in this "transport network" capacity. GMPLS has already been specified for similar technologies. Some additional extensions to the GMPLS control plane are needed and this document provides a framework for these extensions. "Label Switched Path (LSP) Dynamic Provisioning Performance Metrics in Generalized MPLS Networks", Weiqiang Sun, Guoying Zhang, Jianhua Gao, Guowu Xie, Rajiv Papneja, Bin Gu, Xueqing Wei, Tomohiro Otani, Ruiquan Jing, 15-Dec-09, Generalized Multi-Protocol Label Switching (GMPLS) is one of the most promising candidate technologies for future data transmission network. GMPLS has been developed to control and operate different kinds of network elements, such as conventional routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexers (ADMs), photonic cross-connects (PXCs), optical cross- connects (OXCs), etc. The dynamic provisioning ability of these physically diverse devices differs from each other drastically. At the same time, the need for dynamically provisioned connections is increasing because optical networks are being deployed in metro areas. As different applications have varied requirements in the provisioning performance of optical networks, it is imperative to define standardized metrics and procedures such that the performance of networks and application needs can be mapped to each other. This document provides a series of performance metrics to evaluate the dynamic Label Switched Path (LSP) provisioning performance in GMPLS networks, specifically the dynamic LSP setup/release performance. These metrics can be used to characterize the features of GMPLS networks in LSP dynamic provisioning. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 17, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. "Data Channel Status Confirmation Extensions for the Link Management Protocol", Dan Li, Huiying Xu, Fatai Zhang, Snigdho Bardalai, Julien Meuric, Diego Caviglia, 13-Dec-09, This document defines simple additions to the Link Management Protocol (LMP) to provide a control plane tool that can assist in the location of stranded resources by allowing adjacent Label- Switching Routers (LSRs) to confirm data channel statuses, and provides triggers for notifying the management plane if any discrepancies are found. As LMP is already used to verify data plane Li Expires June 2010 [page 1] draft-ietf-ccamp-confirm-data-channel-status-09.txt December 2009 connectivity, it is considered to be an appropriate candidate to support this feature. "RSVP-TE Signaling Extension For Management Plane To Control Plane LSP Handover In A GMPLS Enabled Transport Network.", Diego Caviglia, Daniele Ceccarelli, Dan Li, Snigdho Bardalai, 8-Jan-10, In a transport network scenario, where Data Plane connections are controlled either by a Generalized Multi-Protocol Label Switching (GMPLS) Control Plane (Soft Permanent Connections - SPC) or by a Management System (Permanent Connections - PC) may independently coexist, the ability of transforming an existing PC into a SPC and vice versa - without actually affecting Data Plane traffic being carried over it - is a requirement. The requirements for the conversion between permanent connections and switched connections in a GMPLS Network are defined in [RFC5493]. This memo describes an extension to GMPLS RSVP-TE signaling that enables the transfer of connection ownership between the Management and the Control Planes. Such a transfer is referred to as a Handover. This document defines all Handover related procedures. This includes the handling of failure conditions and subsequent reversion to original state. A basic premise of the extension is that the handover procedures must never impact an already established Data plane. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 12, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 Ethernet Service Switching", Lou Berger, Don Fedyk, 14-Oct-09, This document describes a method for controlling two specific types of Ethernet switching via Generalized Multi-Protocol Label Switching (GMPLS). This document supports the types of switching corresponding to the Ethernet services that have been defined in the context of the Metro Ethernet Forum (MEF) and International Telecommunication Union (ITU) G.8011. Specifically, switching in support of Ethernet private line and Ethernet virtual private line services are covered. Support for MEF and ITU defined parameters is also covered. "Generalized Multiprotocol Label Switching (GMPLS) control of Ethernet PBB-TE", Don Fedyk, David Allan, Himanshu Shah, Nabil Bitar, Attila Takacs, Diego Caviglia, Alan McGuire, Nurit Sprecher, Lou Berger, 15-Oct-09, This specification is complementary to the GMPLS Ethernet Label Switching Architecture and Framework [ARCH] and describes the technology specific aspects of GMPLS control for Provider Backbone Bridge Traffic Engineering (PBB-TE) [IEEE 802.1Qay]. The necessary GMPLS extensions and mechanisms are described to establish Ethernet PBB-TE point to point (P2P) and point to multipoint (P2MP) connections. This document supports, but does not modify, the standard IEEE data plane. "Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 User-Network Interface (UNI)", Lou Berger, Don Fedyk, 14-Oct-09, This document describes a method for controlling two specific types of Ethernet switching via a Generalized Multi-Protocol Label Switching (GMPLS) based User-Network Interface (UNI). This document supports the types of switching required by the Ethernet services that have been defined in the context of the Metro Ethernet Forum (MEF) and International Telecommunication Union (ITU) G.8011. This document is the UNI companion to "Generalized MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 Ethernet Service Switching". This document does not define or limit the underlying intra-domain or Internal NNI (I-NNI) technology used to support the UNI. "Generalized Labels for Lambda-Switching Capable Label Switching Routers", Tomohiro Otani, Takehiro Tsuritani, Dan Li, Richard Rabbat, Sidney Shiba, Hongxiang Guo, Keiji Miyazaki, Diego Caviglia, 6-Dec-09, Technology in the optical domain is constantly evolving and as a consequence new equipment providing lambda switching capability has been developed and is currently being deployed. However, [RFC3471] has defined that a wavelength label (section 3.2.1.1) "only has significance between two neighbors" and global wavelength continuity is not considered. In order to achieve interoperability in a network composed of next generation lambda switch-capable equipment, this document defines a standard lambda label format, being compliant with either [G.694.1](DWDM-grid) or [G.694.2](CWDM-grid). Moreover some consideration on how to ensure lambda continuity with RSVP-TE is provided. This document is a companion to the Generalized Multi- Protocol Label Switching (GMPLS) signaling. It defines the label format when Lambda Switching is requested in an all optical network. "Generalized MPLS (GMPLS) Data Channel Switching Capable (DCSC) and Channel Set Label Extensions", Lou Berger, Don Fedyk, 14-Oct-09, This document describes two technology-independent extensions to Generalized Multi-Protocol Label Switching. The first extension defines the new switching type Data Channel Switching Capable. Data Channel Switching Capable interfaces are able to support switching of the whole digital channel presented on single channel interfaces. The second extension defines a new type of generalized label and updates related objects. The new label is called the Generalized Channel_Set Label and allows more than one data plane label to be controlled as part of an LSP. "Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks", Greg Bernstein, 9-Oct-09, This document provides a model of information needed by the routing and wavelength assignment (RWA) process in wavelength switched optical networks (WSONs). The purpose of the information described in this model is to facilitate constrained lightpath computation in WSONs, particularly in cases where there are no or a limited number of wavelength converters available. This model does not include optical impairments. "Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks (WSON)", Greg Bernstein, Young Lee, Wataru Imajuku, 9-Oct-09, This memo provides a framework for applying Generalized Multi- Protocol Label Switching (GMPLS) and the Path Computation Element (PCE) architecture to the control of wavelength switched optical networks (WSON). In particular we provide control plane models for key wavelength switched optical network subsystems and processes. The subsystems include wavelength division multiplexed links, tunable laser transmitters, reconfigurable optical add/drop multiplexers (ROADM) and wavelength converters. Lightpath provisioning, in general, requires the routing and wavelength assignment (RWA) process. This process is reviewed and the information requirements, both static and dynamic for this process are presented, along with alternative implementation architectures that could be realized via various combinations of extended GMPLS and PCE protocols. This memo focuses on topological elements and path selection constraints that are common across different WSON environments as such it does not address optical impairments in any depth nor does it address potential incompatibilities between some types of optical signals and some types of network elements and links. "Routing and Wavelength Assignment Information Encoding for Wavelength Switched Optical Networks", Greg Bernstein, 8-Oct-09, A wavelength switched optical network (WSON) requires that certain key information elements are made available to facilitate path computation and the establishment of label switching paths (LSPs). The information model described in "Routing and Wavelength Assignment Information for Wavelength Switched Optical Networks" shows what information is required at specific points in the WSON. The information may be used in Generalized Multiprotocol Label Switching (GMPLS) signaling protocols, and may be distributed by GMPLS routing protocols. Other distribution mechanisms (for example, XML-based protocols) may also be used. This document provides efficient, protocol-agnostic encodings for the information elements necessary to operate a WSON. It is intended that protocol-specific documents will reference this memo to describe how information is carried for specific uses. "OAM Configuration Framework and Requirements for GMPLS RSVP-TE", Attila Takacs, Don Fedyk, He Jia, 26-Oct-09, OAM is an integral part of transport connections, hence it is required that OAM functions are activated/deactivated in sync with connection commissioning/decommissioning; avoiding spurious alarms and ensuring consistent operation. In certain technologies OAM entities are inherently established once the connection is set up, while other technologies require extra configuration to establish and configure OAM entities. This document specifies extensions to RSVP-TE to support the establishment and configuration of OAM entities along with LSP signaling. "GMPLS RSVP-TE Extensions for Ethernet OAM Configuration", Attila Takacs, Balazs Gero, Don Fedyk, Dinesh Mohan, Hao Long, 26-Oct-09, The GMPLS controlled Ethernet Label Switching (GELS) work is extending GMPLS RSVP-TE to support the establishment of Ethernet LSPs. IEEE Ethernet Connectivity Fault Management (CFM) specifies an adjunct OAM flow to check connectivity in Ethernet networks. CFM can be also used with Ethernet LSPs for fault detection and triggering recovery mechanisms. The ITU-T Y.1731 specification builds on CFM and specifies additional OAM mechanisms, including Performance Monitoring, for Ethernet networks. This document specifies extensions of GMPLS RSVP-TE to support the setup of the associated Ethernet OAM (CFM and Y.1731) entities adding a technology specific TLV to [OAM-CONF-FWK]. "A Framework for the Control of Wavelength Switched Optical Networks (WSON) with Impairments", Greg Bernstein, 22-Oct-09, The operation of optical networks requires information on the physical characterization of optical network elements, subsystems, devices, and cabling. These physical characteristics may be important to consider when using a GMPLS control plane to support path setup and maintenance. This document discusses how the definition and characterization of optical fiber, devices, subsystems, and network elements contained in various ITU-T recommendations can be combined with GMPLS control plane protocols and mechanisms to support Impairment Aware Routing and Wavelength Assignment (IA-RWA) in optical networks. "OSPF Enhancement for Signal and Network Element Compatibility for Wavelength Switched Optical Networks", Young Lee, Greg Bernstein, 8-Dec-09, This document provides GMPLS OSPF routing enhancements to support signal compatibility constraints associated with WSON network elements. These routing enhancements are required in common optical or hybrid electro-optical networks where not all of the optical signals in the network are compatible with all network elements participating in the network. This compatibility constraint model is applicable to common optical or hybrid electro optical systems such as OEO switches, regenerators, and wavelength converters since such systems can be limited to processing only certain types of WSON signals. Cga & Send maIntenance (csi) ---------------------------- "SeND Hash Threat Analysis", Ana Kukec, Suresh Krishnan, Sheng Jiang, 8-Nov-09, This document analysis the use of hashes in SeND, possible threats and the impact of recent attacks on hash functions used by SeND. Current SeND specification [rfc3971] uses the SHA-1 [sha-1] hash algorithm and PKIX certificates [rfc5280] and does not provide support for the hash algorithm agility. The purpose of the document is to provide analysis of possible hash threats and to decide how to encode the hash agility support in SeND. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 13, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "Securing Neighbor Discovery Proxy Problem Statement", Jean-Michel Combes, Suresh Krishnan, Greg Daley, 18-Oct-09, Neighbor Discovery Proxies are used to provide an address presence on a link for nodes that are no longer present on the link. They allow a node to receive packets directed at its address by allowing another device to perform neighbor discovery operations on its behalf. Neighbor 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 Neighbor discovery messages. Neighbor 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 Neighbor Discovery relates to Secured Neighbor Discovery. "Secure Proxy ND Support for SEND", Suresh Krishnan, Julien Laganier, Marco Bonola, 13-Jul-09, Secure Neighbor Discovery (SEND) specifies a method for securing Neighbor Discovery (ND) signaling against specific threats. As specified today, SEND assumes that the node advertising an address is the owner of the address and is in possession of the private key used to generate the digital signature on the message. This means that the Proxy ND signaling initiated by nodes that do not possess knowledge of the address owner's private key cannot be secured using SEND. This document extends the current SEND specification with support for Proxy ND, the Secure Proxy ND Support for SEND. "Certificate profile and certificate management for SEND", Suresh Krishnan, Ana Kukec, Roque Gagliano, 26-Oct-09, SEcure Neighbor Discovery (SEND) Utilizes X.509v3 certificates for performing router authorization. This document specifies a certificate profile for SEND based on Resource Certificates along with extended key usage values required for SEND. "DHCPv6 and CGA Interaction: Problem Statement", Sheng Jiang, Sean Shen, Tim Chown, 16-Dec-09, This document describes potential issues in the interaction between DHCPv6 and Cryptographically Generated Addresses (CGAs). Firstly, the scenario of using CGAs in DHCPv6 environments is discussed. Some operations are clarified for the interaction of DHCPv6 servers and CGA-associated hosts. We then also discuss how CGAs and DHCPv6 may have mutual benefits for each other, including using CGAs in DHCPv6 operations to enhance its security features and using DHCPv6 to provide the CGA generation function. "SEND Name Type field Registry", Roque Gagliano, Suresh Krishnan, Ana Kukec, 24-Nov-09, SEcure Neighbor Discovery (SEND) defines the Name Type field in the Trust Anchor option. This document requesto to IANA the creation and management of a registry for this field. This document also specifies a new Name Type field based on a certificate Subject Key Identifier (SKI). Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 28, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Datagram Congestion Control Protocol (dccp) ------------------------------------------- "RTP and the Datagram Congestion Control Protocol (DCCP)", Colin Perkins, 22-Jun-07, The Real-time Transport Protocol (RTP) is a widely used transport for real-time multimedia on IP networks. The Datagram Congestion Control Protocol (DCCP) is a newly defined transport protocol that provides desirable services for real-time applications. This memo specifies a mapping of RTP onto DCCP, along with associated signalling, such that real-time applications can make use of the services provided by DCCP. Dynamic Host Configuration (dhc) -------------------------------- "Virtual Subnet Selection Options for DHCPv4 and DHCPv6", Kim Kinnear, Richard Johnson, Mark Stapp, Jay Kumarasamy, 21-Sep-09, This memo defines a Virtual Subnet Selection (VSS) option for DHCPv4 and DHCPv6, and a DHCPv4 relay-agent-information sub-option. These are intended for use by DHCP clients, relay agents, and proxy clients in situations where VSS information needs to be passed to the DHCP server for proper address or prefix allocation to take place. For the DHCPv4 option and relay-agent-information sub-option, this memo documents existing usage as per RFC 3942 [RFC3942]. "Subnet Allocation Option", Richard Johnson, Jay Kumarasamy, Kim Kinnear, Mark Stapp, 12-Nov-09, This document defines a new DHCP option which is passed between the DHCP Client and the DHCP Server to request dynamic allocation of a subnet, give specifications of subnet(s) allocated, and report usage statistics. This memo documents the current usage of the option in agreement with [RFC3942], 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. "DHCPv6 Relay Agent Assignment Notification (RAAN) Option", Ralph Droms, Bernie Volz, Ole Troan, 13-Jul-09, The DHCP Relay Agent Assignment Notification (RAAN) option is sent from a DHCP server to a DHCP relay agent to inform the relay agent of IPv6 addresses that have been assigned or IPv6 prefixes that have been delegated to DHCP clients. "Rebind Capability in DHCPv6 Reconfigure Messages", D Evans, Ralph Droms, 8-Nov-09, This document updates RFC 3315 to allow the Rebind message type to appear in the Reconfigure Message option of a Reconfigure message, which extends the Reconfigure message to allow a DHCPv6 server to cause a DHCPv6 client to send a Rebind message. The document also clarifies how a DHCPv6 client responds to a received Reconfigure message. "Container Option for Server Configuration", Ralph Droms, 24-Mar-09, In some DHCP service deployments, it is desirable for a DHCP server in one administrative domain to pass configuration options to a DHCP server in a different administrative domain. This DHCP option carries a set of DHCP options that can be used by another DHCP server. "The DHCPv4 Relay Agent Identifier Suboption", Mark Stapp, 7-Jul-09, This memo defines a new Relay Agent Identifier suboption for the Dynamic Host Configuration Protocol's (DHCP) Relay Agent Information option. The suboption carries a value that uniquely identifies the relay agent device. The value may be administratively-configured or may be generated by the relay agent. The suboption allows a DHCP relay agent to include the identifier in the DHCP messages it sends. "DHCPv6 option for network boot", Thomas Huth, Jens Freimann, Vincent Zimmer, Dave Thaler, 4-Jan-10, The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) provides a framework for passing configuration information to nodes on a network. This document describes new options for DHCPv6 which are required for booting a node from the network. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 8, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "DHCPv4 Leasequery by relay agent remote ID", Pavan Kurapati, D.T.V. Ramakrishna Rao, Bharat Joshi, 23-Nov-09, Some Relay Agents extract lease information from the DHCP message exchanged between the client and DHCP server. This lease information is used by relay agents for various purposes like antispoofing and prevention of flooding. RFC 4388 defines a mechanism for relay agents to retrieve the lease information from the DHCP server as and when this information is lost. The existing leasequery mechanism is data driven, which means that a relay agent can initiate the leasequery only when it starts receiving data from/to the clients. In certain scenarios, this model is not scalable. This document first looks at issues in existing mechanism and then proposes a new query type, query by remote ID, to address these issues. "DHCPv4 Vendor-specific Message", Bernie Volz, 4-Aug-09, This document requests a vendor-specific DHCPv4 message assignment. This message can be used for vendor specific and experimental purposes. "DHCPv6 Vendor-specific Message", Bernie Volz, 4-Aug-09, This document requests a vendor-specific DHCPv6 message assignment. This message can be used for vendor specific and experimental purposes. "Bulk DHCPv4 Lease Query", Kim Kinnear, Bernie Volz, Neil Russell, Mark Stapp, D.T.V. Ramakrishna Rao, Bharat Joshi, Pavan Kurapati, 26-Oct-09, The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Leasequery extension allows a requestor to request information about DHCPv4 bindings. This mechanism is limited to queries for individual bindings. In some situations individual binding queries may not be efficient, or even possible. This document extends the DHCPv4 Leasequery protocol to allow for bulk transfer of DHCPv4 address binding data via TCP. "Lightweight DHCPv6 Relay Agent", David Miles, Sven Ooghe, Wojciech Dec, Suresh Krishnan, 12-Oct-09, This document proposes a Lightweight DHCPv6 Relay Agent (LDRA) that is used to insert relay agent options in DHCPv6 message exchanges identifying client-facing interfaces. The LDRA can be implemented in existing access nodes (such as DSLAMs and Ethernet switches) that do not support IPv6 control or routing functions. Diameter Maintenance and Extensions (dime) ------------------------------------------ "Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction", Jouni Korhonen, Hannes Tschofenig, Julien Bournelle, Gerardo Giaretta, Madjid Nakhjiri, 28-Apr-09, Mobile IPv6 deployments may want to bootstrap their operations dynamically based on an interaction between the Home Agent and the Diameter server of the Mobile Service Provider. This document specifies the interaction between a Mobile IP Home Agent and a Diameter server. This document defines the Home Agent to the Diameter server communication when the mobile node authenticates using the Internet Key Exchange v2 protocol with the Extensible Authentication Protocol or using the Mobile IPv6 Authentication Protocol. In addition to authentication and authorization, the configuration of Mobile IPv6 specific parameters and accounting is specified in this document. "Diameter Base Protocol", Victor Fajardo, Jari Arkko, John Loughney, Glen Zorn, 2-Sep-09, The Diameter base protocol is intended to provide an Authentication, Authorization and Accounting (AAA) framework for applications such as network access or IP mobility in both local and roaming situations. This document specifies the message format, transport, error reporting, accounting and security services used by all Diameter applications. The Diameter base protocol as defined in this document must be supported by all Diameter implementations. "Diameter Quality of Service Application", Dong Sun, Pete McCann, Hannes Tschofenig, Tina Tsou (Ting ZOU), Avri Doria, Glen Zorn, 26-Oct-09, This document describes the framework, messages and procedures for the Diameter Quality of Service (QoS) application. The Diameter QoS application allows network elements to interact with Diameter servers when allocating QoS resources in the network. In particular, two modes of operation -- Pull and Push -- are defined. "Diameter Applications Design Guidelines", Victor Fajardo, Tolga Asveren, Hannes Tschofenig, Glenn McGregor, John Loughney, 13-Jul-09, The Diameter Base protocol provides updated rules on how to extend Diameter by modifying and/or deriving from existing applications or creating entirely new applications. This is a companion document to the Diameter Base protocol that further explains and clarifies these rules. It is meant as a guidelines document and therefore it does not add, remove or change existing rules. "Traffic Classification and Quality of Service Attributes for Diameter", Jouni Korhonen, Hannes Tschofenig, Mayutan Arumaithurai, Mark Jones, Avi Lior, 18-Dec-09, This document defines a number of Diameter attribute-value pairs (AVP) for traffic classification with actions for filtering and Quality of Service (QoS) treatment. These AVPs can be used in existing and future Diameter applications where permitted by the Augmented Backus-Naur Form (ABNF) specification of the respective Diameter command extension policy. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 21, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. "Diameter Support for EAP Re-authentication Protocol (ERP)", Lakshminath Dondeti, Julien Bournelle, Lionel Morand, Sebastien Decugis, 8-Oct-09, EAP Re-authentication Protocol (ERP) defines extensions to the Extensible Authentication Protocol (EAP) to support efficient re- authentication between the peer and an EAP Re-authentication (ER) server through a compatible authenticator. This document specifies Diameter support for ERP. It defines a new Diameter ERP application to transport ERP messages between ER authenticator and ER server, and a set of new AVPs that can be used to transport the cryptographic material needed by the re-authentication server. "Diameter User-Name and Realm Based Request Routing Clarifications", Jouni Korhonen, Mark Jones, Lionel Morand, Tina Tsou (Ting ZOU), 6-Oct-09, This specification defines the behavior required of Diameter agents to route requests when the User-Name Attribute Value Pair contains a Network Access Identifier formatted with multiple realms. These multi-realm or "Decorated" Network Access Identifiers are used in order to force the routing of request messages through a predefined list of mediating realms. "Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility Anchor Interaction with Diameter Server", Jouni Korhonen, Julien Bournelle, Kuntal Chowdhury, Ahmad Muhanna, Ulrike Meyer, 22-Sep-09, This specification defines Authentication, Authorization, and Accounting interactions between Proxy Mobile IPv6 entities (both Mobile Access Gateway and Local Mobility Anchor) and an Authentication, Authorization, and Accounting server within a Proxy Mobile IPv6 Domain. These Authentication, Authorization, and Accounting interactions are primarily used to download and update mobile node specific policy profile information between Proxy Mobile IPv6 entities and a remote policy store. "Diameter Base Protocol MIB", Glen Zorn, Subash Comerica, 8-Nov-09, Along with providing support for certain basic authentication, authorization and accounting functions, the Diameter protocol is designed to provide a framework for AAA applications. This document defines the Management Information Base (MIB) module which describes the minimum set of objects needed to manage an implementation of the Diameter protocol. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 13, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. "Diameter Credit Control Application MIB", Glen Zorn, Subash Comerica, 4-Dec-09, Along with providing support for certain basic authentication, authorization and accounting functions, the Diameter base protocol is intended to provide a framework for AAA applications. This document defines the Management Information Base (MIB) module which describes the minimum set of objects needed to manage an implementation of the Diameter Credit Control application. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 7, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. "The Diameter Capabilities Update Application", Jiao Kang, Glen Zorn, 1-Dec-09, This document defines a new Diameter application and associated command codes. The Capabilities Update application is intended to allow the dynamic update of Diameter peer capabilities while the peer-to-peer connection is in the open state. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 4, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "Realm-Based Redirection In Diameter", Tina Tsou (Ting ZOU), Tom Taylor, 27-Oct-09, RFC 3588 allows a Diameter redirect agent to specify one or more individual hosts to which a Diameter message may be redirected by an upstream Diameter node. However, in some circumstances an operator may wish to redirect messages to an alternate domain without specifying individual hosts. This document specifies the means by which this can be achieved. It also defines a new application by means of which support for this capability can be advertised. "Diameter NAT Control Application", Frank Brockners, Vaneeta Singh, Shwetha Bhandari, Victor Fajardo, 26-Oct-09, This document describes the framework, messages, and procedures for the Diameter NAT Control Application (DNCA), allowing for per- endpoint control of large scale NAT devices, which are put in place to cope with IPv4-address space completion. The Diameter NAT Control Application allows external devices to configure and manage a Large Scale NAT (LSN) device - expanding the existing Diameter-based AAA and policy control capabilities with a NAT control component. These external devices can be network elements in the data plane such as a Network Access Server (NAS), or can be more centralized control plane devices such as AAA-servers. DNCA establishes a context to commonly identify and manage endpoints on a gateway or server, and a large scale NAT device. This includes, for example, the control of the total number of NAT-bindings allowed or the allocation of a specific NAT-binding for a particular endpoint. In addition, it allows large scale NAT devices to provide information relevant to accounting purposes. "Diameter Extended NAPTR", Mark Jones, Jouni Korhonen, 28-Dec-09, This document describes an extended format for the NAPTR service fields used in dynamic Diameter agent discovery. The extended format allows NAPTR queries to contain Diameter Application-Id information. "Diameter IKEv2: Support for Interaction between IKEv2 Server and Diameter Server", Violeta Cakulev, Avi Lior, 4-Jan-10, Internet Key Exchange is a component of IPsec used for performing mutual authentication as well as establishing and maintaining security associations (SAs) between two parties such as a user and a network entity. Internet Key Exchange v2 (IKEv2) protocol allows several different mechanisms for authenticating a user, namely the Extensible Authentication Protocol, certificates, and pre-shared secrets. To authenticate and/or authorize the user, the network element such as the Access Gateway may need to dynamically bootstrap a security association based on interaction with the Diameter server. This document specifies the interaction between the Access Gateway and Diameter server for the IKEv2 based on pre-shared secrets. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 8, 2010.Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. "Diameter Attribute-Value Pairs for Cryptographic Key Transport", Wenson Wu, Glen Zorn, 7-Jan-10, Some Authentication, Authorization, and Accounting (AAA) applications require the transport of cryptographic keying material; this document specifies a set of Attribute-Value Pairs (AVPs) providing native Diameter support of cryptographic key delivery. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 12, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Domain Keys Identified Mail (dkim) ---------------------------------- "DomainKeys Identified Mail (DKIM) Development, Deployment and Operations", Tony Hansen, Ellen Siegel, Phillip Hallam-Baker, Dave Crocker, 17-Dec-09, DomainKeys Identified Mail (DKIM) allows an organization to claim responsibility for transmitting a message, in a way that can be validated by a recipient. The organization can be the author's, the originating sending site, an intermediary, or one of their agents. A message can contain multiple signatures, from the same or different organizations involved with the message. DKIM defines a domain-level digital signature authentication framework for email, using public key cryptography, using the domain name service as its key server technology [RFC4871]. This permits verification of a responsible organization, as well as the integrity of the message contents. DKIM will also provide a mechanism that permits potential email signers to publish information about their email signing practices; this will permit email receivers to make additional assessments about messages. DKIM's authentication of email identity can assist in the global control of "spam" and "phishing". This document provides implementation, deployment, operational and migration considerations for DKIM. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 21, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Detecting Network Attachment (dna) ---------------------------------- "Design Alternative for Detecting Network Attachment in IPv6 Networks (DNAv6 Design Alternative)", Sathya Narayanan, James Kempf, Erik Nordmark, Brett Pentland, JinHyeock Choi, Greg Daley, Nicolas Montavont, 2-Dec-09, In this memo, a mechanism that was developed for detection of network attachement is documented for future reference. This memo is an informational document and thus does not define a new standard. The mechanism proposed in this experimental RFC requires the hosts to monitor all the prefixes advertised on the link and use it for link identification in the presence of non-DNAv6 routers is presented. A more efficient link-identification mechanism requiring the DNAv6 routers to monitor the link for advertised prefixes to assist the hosts in link identification combined with a fast router advertisement mechanism that selects the order of response for the router deterministically is also presented. "Tentative Options for Link-Layer Addresses in IPv6 Neighbour Discovery", Greg Daley, Erik Nordmark, 26-Oct-09, The proposed IPv6 Duplicate Address Detection (DAD) Optimization "Optimistic DAD" defines a set of recoverable procedures which allow a node to make use of an address before DAD completes. Essentially, Optimistic DAD forbids usage of certain Neighbour Discovery options which could pollute active neighbour cache entries, while an address is tentative. This document defines a new option and procedures to replace cache polluting options, in a way which is useful to tentative nodes. These procedures are designed to be to backward compatible with existing devices which support IPv6 Neighbour Discovery. "Simple procedures for Detecting Network Attachment in IPv6", Suresh Krishnan, Greg Daley, 26-Oct-09, Detecting Network Attachment allows hosts to assess if its existing addressing or routing configuration is valid for a newly connected network. This document provides simple procedures for detecting network attachment in IPv6 hosts, and procedures for routers to support such services. DNS Extensions (dnsext) ----------------------- "DNS Zone Transfer Protocol (AXFR)", Edward Lewis, Alfred Hoenes, 6-Dec-09, The Domain Name System standard mechanisms for maintaining coherent servers for a zone consist of three elements. One mechanism is the Authoritative Transfer (AXFR) defined in RFC 1034 and RFC 1035. The definition of AXFR has proven insufficient in detail, thereby forcing implementations intended to be compliant to make assumptions, impeding interoperability. Yet today we have a satisfactory set of implementations that do interoperate. This document is a new definition of AXFR -- new in the sense that is it recording an accurate definition of an interoperable AXFR mechanism. "Clarifications and Implementation Notes for DNSSECbis", Samuel Weiler, David Blacka, 5-Sep-09, This document is a collection of technical clarifications to the DNSSECbis document set. It is meant to serve as a resource to implementors as well as a repository of DNSSECbis errata. "Update to DNAME Redirection in the DNS", Scott Rose, Wouter Wijngaards, 12-Nov-09, The DNAME record provides redirection for a sub-tree of the domain name tree in the DNS system. That is, all names that end with a particular suffix are redirected to another part of the DNS. This is a revision of the original specification in RFC 2672, also aligning RFC 3363 and RFC 4294 with this revision. "Extension Mechanisms for DNS (EDNS0)", Michael Graff, Paul Vixie, 28-Jul-09, The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow requestors to advertise their capabilities to responders. This document describes backward compatible mechanisms for allowing the protocol to grow. This document updates the EDNS0 specification based on 10 years of operational experience. "Cryptographic Algorithm Identifier Allocation for DNSSEC", Paul Hoffman, 22-Sep-09, This document specifies how DNSSEC cryptographic algorithm identifiers in the IANA registries are allocated. It changes the rule from "standard required" to "RFC required". It does not change the list of algorithms that are recommended or required for DNSSEC implementations. "Use of GOST signature algorithms in DNSKEY and RRSIG Resource Records for DNSSEC", Vasily Dolmatov, Artem Chuprina, Igor Ustinov, 12-Dec-09, This document describes how to produce signature and hash using GOST algorithms [DRAFT1, DRAFT2, DRAFT3] for DNSKEY, RRSIG and DS resource records for use in the Domain Name System Security Extensions (DNSSEC, RFC 4033, RFC 4034, and RFC 4035). V.Dolmatov Expires June 12, 2010 [page 1] "Handling of Unknown DNS Resource Record (RR) Types", Andreas Gustafsson, 23-Sep-09, Extending the Domain Name System (DNS) with new Resource Record (RR) types should not requires changes to name server software. This document specifies how new RR types are transparently handled by DNS software. "DNS Transport over TCP", Ray Bellis, 7-Jan-10, This document updates the requirements for the support of TCP as a transport protocol for DNS implementations. "DNS Security (DNSSEC) DNSKEY IANA Registry Algorithm Status Addition", Scott Rose, 12-Nov-09, The DNS Security Extensions (DNSSEC) has an IANA registry to allocate cryptographic algorithm suites for use in generating digital signatures over DNS data. Newly introduced cryptographic algorithms to DNSSEC mean implementors need to know which algorithms need to be implmented, which are optional, and which are obsolete. This document adds a column to the IANA registry table for Domain Name System Security (DNSSEC) Algorithm Numbers to list their status for use. Domain Name System Operations (dnsop) ------------------------------------- "Locally-served DNS Zones", Mark Andrews, 18-Nov-09, Experience with the Domain Name System (DNS) has shown that there are a number of DNS zones all iterative resolvers and recursive nameservers should automatically serve, unless configured otherwise. RFC 4193 specifies that this should occur for D.F.IP6.ARPA. This document extends the practice to cover the IN-ADDR.ARPA zones for RFC 1918 address space and other well known zones with similar characteristics. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 23, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. "AS112 Nameserver Operations", Joe Abley, William Maton, 5-Oct-09, Many sites connected to the Internet make use of IPv4 addresses which are not globally unique. Examples are the addresses designated in RFC1918 for private use within individual sites. Devices in such environments may occasionally originate reverse DNS queries corresponding to those private-use addresses. Since the addresses concerned have only local significance, it is good practice for site administrators to ensure that they are answered locally. However, it is not uncommon for such queries to follow the normal delegation path in the public DNS instead of being answered within the site. It is not possible for public DNS servers to give useful answers to such queries. In addition, due to the wide deployment of private-use addresses and the continuing growth of the Internet, the volume of such queries is large and growing. The AS112 project aims to provide a distributed sink for such queries in order to reduce the load on the root and IN-ADDR.ARPA authority servers. This document describes the steps required to install a new AS112 node, and offers advice relating to such a node's operation. "I'm Being Attacked by PRISONER.IANA.ORG!", Joe Abley, William Maton, 5-Oct-09, Many sites connected to the Internet make use of IPv4 addresses which are not globally unique. Examples are the addresses designated in RFC1918 for private use within individual sites. Hosts should never normally send DNS reverse mapping queries for those addresses on the public Internet. However, such queries are frequently observed. Authoritative servers are deployed to provide authoritative answers to such queries as part of a loosely- coordinated effort known as the AS112 project. Since queries sent to AS112 servers are usually not intentional, the replies received back from those servers are typically unexpected. Unexpected inbound traffic can trigger alarms on intrusion detection systems and firewalls, and operators of such systems often mistakenly believe that they are being attacked. This document provides background information and technical advice to those firewall operators. "Initializing a DNS Resolver with Priming Queries", Peter Koch, Matt Larson, 26-Oct-09, This document describes the initial queries a DNS resolver is supposed to emit to initialize its cache with a current NS RRSet for the root zone as well as the necessary address information. "DNSSEC Signing Policy & Practice Statement Framework", Fredrik Ljunggren, Anne-Marie Eklund-Lowinder, Tomofumi Okubo, 25-Nov-09, This document presents a framework to assist writers of DNSSEC Signing Policy and Practice Statements such as Regulatory Authorities and Registry Managers on both the TLD and secondary level, who is operating a DNS zone with Security Extensions (DNSSEC) implemented. In particular, the framework provides a comprehensive list of topics that potentially (at the writer's discretion) needs to be covered in a DNSSEC Signing Policy definition and Practice Statement. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 29, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Email Address Internationalization (eai) ---------------------------------------- "IMAP Support for UTF-8", Pete Resnick, Chris Newman, 29-Nov-09, This specification extends the Internet Message Access Protocol version 4rev1 (IMAP4rev1) to support UTF-8 encoded international characters in user names, mail addresses and message headers. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 3, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. "Mailing Lists and Internationalized Email Addresses", Randall Gellens, 11-Jan-10, This document describes considerations for mailing lists with the introduction of internationalized email addresses. This document makes some specific recommendations on how mailing lists should act in various situations. "POP3 Support for UTF-8", Randall Gellens, Chris Newman, 25-Oct-09, This specification extends the Post Office Protocol version 3 (POP3) to support un-encoded international characters in user names, passwords, mail addresses, message headers, and protocol-level textual error strings. "Displaying Downgraded Messages for Email Address Internationalization", Kazunori Fujiwara, Barry Leiba, 1-Dec-09, This document describes a method for displaying downgraded messages which originally contained internationalized E-mail addresses or internationalized header fields. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 4, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "Internationalized Delivery Status and Disposition Notifications", Chris Newman, Alexey Melnikov, 13-Jul-09, Delivery status notifications (DSNs) are critical to the correct operation of an email system. However, the existing Draft Standards (RFC 3461, RFC 3462, RFC 3464) are presently limited to US-ASCII text in the machine-readable portions of the protocol. This specification adds a new address type for international email addresses so an original recipient address with non-US-ASCII characters can be correctly preserved even after downgrading. This also provides updated content return media types for delivery status notifications and message disposition notifications to support use of the new address type. This document experimentally extends RFC 3461, RFC 3464, and RFC 3798. Emergency Context Resolution with Internet Technologies (ecrit) --------------------------------------------------------------- "Best Current Practice for Communications Services in support of Emergency Calling", Brian Rosen, James Polk, 27-Jul-09, The IETF and other standards organization have efforts targeted at standardizing various aspects of placing emergency calls on IP networks. This memo describes best current practice on how devices, networks and services should use such standards to make emergency calls. "Framework for Emergency Calling using Internet Multimedia", Brian Rosen, Henning Schulzrinne, James Polk, Andrew Newton, 27-Jul-09, The IETF has standardized various aspects of placing emergency calls. This document describes how all of those component parts are used to support emergency calls from citizens and visitors to authorities. "Location Hiding: Problem Statement and Requirements", Henning Schulzrinne, Laura Liess, Hannes Tschofenig, Barbara Stark, Andres Kuett, 13-Jul-09, The emergency services architecture developed in the IETF Emergency Context Resolution with Internet Technology (ECRIT) working group describes an architecture where location information is provided by access networks to end points or VoIP service providers in order to determine the correct dial string and information to route the call to a Public Safety Answering Point (PSAP). For determining the PSAP Uniform Resource Identifier (URI) the usage of the Location-to- Service Translation (LoST) Protocol is envisioned. This document provides a problem statement and lists requirements for situations where the Internet Access Provider (IAP) and/or the Internet Service Provider (ISP) are only willing to disclose limited or no location information. "Specifying Holes in LoST Service Boundaries", James Winterbottom, Martin Thomson, 12-Oct-08, This document describes how holes can be specified in geodetic service boundaries. One means of implementing a search solution in a service database, such as one might provide with a LoST server, is described. "Synchronizing Location-to-Service Translation (LoST) Protocol based Service Boundaries and Mapping Elements", Henning Schulzrinne, Hannes Tschofenig, 26-Oct-09, The Location-to-Service Translation (LoST) protocol is an XML-based protocol for mapping service identifiers and geodetic or civic location information to service URIs and service boundaries. In particular, it can be used to determine the location-appropriate Public Safety Answering Point (PSAP) for emergency services. The main data structure, the element, used for encapsulating information about service boundaries is defined in the LoST protocol specification and circumscribes the region within which all locations map to the same service Uniform Resource Identifier (URI) or set of URIs for a given service. This document defines an XML protocol to exchange these mappings between two nodes. This mechanism is designed for the exchange of authoritative elements between two entities. Exchanging cached elements, i.e. non-authoritative elements, is possible but not envisioned. In any case, this document can also be used without the LoST protocol even though the format of the element is re-used from the LoST specification. "Location-to-Service Translation Protocol (LoST) Extension: ServiceListBoundary", Karl Wolf, 9-Nov-09, LoST maps service identifiers and location information to service contact URIs. If a LoST client wants to discover available services for a particular location, it will perform a query to the LoST server. However, the response from the LoST server does not provide information about the geographical region for which the returned service list is valid. Therefore, this document proposes a ServiceListBoundary to assist the client to not miss a change in available services when moving. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 13, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "Using Imprecise Location for Emergency Context Resolution", Richard Barnes, Matt Lepinski, 7-Oct-09, Emergency calling works best when precise location is available for emergency call routing. However, there are situations in which a location provider is unable or unwilling to provide precise location, yet still wishes to enable subscribers to make emergency calls. This document describes the level of location accuracy that providers must provide to enable emergency call routing. In addition, we descibe how emergency services and non-emergency services can be invoked by an endpoint that does not have access to its precise location. EAP Method Update (emu) ----------------------- "Requirements for a Tunnel Based EAP Method", Katrin Hoeper, Stephen Hanna, Hao Zhou, Joseph Salowey, 7-Oct-09, This memo defines the requirements for a tunnel-based Extensible Authentication Protocol (EAP) Method. This method will use Transport Layer Security (TLS) to establish a secure tunnel. The tunnel will provide support for password authentication, EAP authentication and the transport of additional data for other purposes. "Channel Binding Support for EAP Methods", Charles Clancy, Katrin Hoeper, 22-Oct-09, This document defines how to implement channel bindings for Extensible Authentication Protocol (EAP) methods to address the lying NAS as well as the lying provider problem. Telephone Number Mapping (enum) ------------------------------- "IANA Registration for IAX Enumservice", Ed Guy, 14-Feb-09, This document registers the IAX Enumservice using the URI scheme 'iax:' as per the IANA registration process defined in the ENUM specification RFC3761. "IANA Registration of Enumservices: Guide, Template and IANA Considerations", Bernie Hoeneisen, Alexander Mayrhofer, Jason Livingood, 16-Dec-09, This document specifies a revision of the IANA Registration Guidelines for Enumservices, describes corresponding registration procedures, and provides a guideline for creating Enumservice Specifications. "IANA Registration for an Enumservice Calling Name Delivery (CNAM) Information and IANA Registration for URI type 'pstndata'", Richard Shockey, 29-Sep-08, This document registers the Enumservice 'pstndata' and subtype 'cnam' using the URI scheme 'pstndata:' as per the IANA registration process defined in the ENUM specification, RFC 3761 and registers a new URI type 'pstndata:'. This data is used to facilitate the transfer of Calling Name Delivery (CNAM) data for calls that originate on the Public Switched Telephone Network (PSTN) that may be displayed on VoIP or other Real-time Client User Agents (CUA). The pstndata URI is created to facilitate this transfer, however this URI may be used to transport other PSTN data in the future. "ENUM Requirement for EDNS0 Support", Jim Reid, Lawrence Conroy, 6-Sep-06, Support for EDNS0 (Extension Mechanisms for DNS) is mandated in this document for DNS entities querying for or serving NAPTR records. In general those entities will be supporting ENUM resolution. This requirement is needed because DNS responses to ENUM-related queries generally return large RRSets. Without EDNS0 support these lookups would result in truncated responses and repeated queries over TCP transport. That has a severe impact on DNS server load and on the latency of those queries. This document adds an operational requirement to use of the protocol standardised in RFC 3761. "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", Scott Bradner, Lawrence Conroy, Kazunori Fujiwara, 26-Nov-09, This document discusses the use of the Domain Name System (DNS) for the storage of E.164 numbers, and for resolving them into URIs that can be used for (for example) telephony call setup. This document also describes how the DNS can be used to identify the services associated with an E.164 number. This document obsoletes RFC 3761. Status of This Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 22, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "IANA Registration for Enumservice UNUSED", Richard Stastny, Lawrence Conroy, Jim Reid, 29-Mar-08, This document registers the Enumservice "unused" using the URI scheme "http:" as per the IANA registration process defined in the ENUM specification, RFC 3761. This Enumservice may be used to indicate that the E.164 number (or E.164 number range) tied to the domain in which the enclosing NAPTR is published is not allocated or assigned for communications service. When such an indication is provided, an ENUM client can detect calls that will fail "early". "Update of legacy IANA Registrations of Enumservices", Bernie Hoeneisen, Alexander Mayrhofer, 14-Oct-09, This document revises all Enumservices that were IANA registered under the now obsolete specification of the Enumservice registry defined in [RFC3761]. FEC Framework (fecframe) ------------------------ "SDP Elements for FEC Framework", Ali Begen, 19-Aug-09, This document specifies the use of Session Description Protocol (SDP) to describe the parameters required to signal the Forward Error Correction (FEC) Framework Configuration Information between the sender(s) and receiver(s). This document also provides examples that show the semantics for grouping multiple source and repair flows together for the applications that simultaneously use multiple instances of the FEC Framework. "Guidelines for Implementing DVB-IPTV Application-Layer Hybrid FEC Protection", Ali Begen, Thomas Stockhammer, 15-Dec-09, The Annex E of the Digital Video Broadcasting (DVB)-IPTV technical specification defines an optional Application-layer Forward Error Correction (AL-FEC) protocol to protect the streaming media carried over RTP transport. The DVB-IPTV AL-FEC protocol uses two layers for FEC protection. The first (base) layer is based on the 1-D interleaved parity code. The second (enhancement) layer is based on the Raptor code. By offering a layered approach, the DVB-IPTV AL-FEC protocol offers a good protection against both bursty and random packet losses at a cost of decent complexity. This document describes how one can implement the DVB-IPTV AL-FEC protocol by using the 1-D interleaved parity code and Raptor code that have already been specified in separate documents. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 18, 2010.Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "RTP Payload Format for 1-D Interleaved Parity FEC", Ali Begen, 8-Jan-10, This document defines a new RTP payload format for the Forward Error Correction (FEC) that is generated by the 1-D interleaved parity code from a source media encapsulated in RTP. The 1-D interleaved parity code is a systematic code, where a number of repair symbols are generated from a set of source symbols and sent in a repair flow separate from the source flow that carries the source symbols. The 1-D interleaved parity code offers a good protection against bursty packet losses at a cost of reasonable complexity. The new payload format defined in this document is used (with some exceptions) as a part of the DVB Application-layer FEC specification. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 12, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "RTP Payload Format for Raptor FEC", Mark Watson, 23-Oct-09, This document specifies an RTP Payload Format for Forward Error Correction repair data produced by the Raptor FEC Schemes. Raptor FEC Schemes are specified for use with the IETF FEC Framework which supports transport of repair data over both UDP and RTP. This document specifies the Payload Format which is required for the use of RTP to carry Raptor repair flows. Forwarding and Control Element Separation (forces) -------------------------------------------------- "ForCES Applicability Statement", Alan Crouch, Hormuzd Khosravi, Avri Doria, Xin-ping Wang, Kentaro Ogawa, 9-Oct-09, The ForCES protocol defines a standard framework and mechanism for the interconnection between Control Elements and Forwarding Elements in IP routers and similar devices. In this document we describe the applicability of the ForCES model and protocol. We provide example deployment scenarios and functionality, as well as document applications that would be inappropriate for ForCES. "ForCES Forwarding Element Model", Joel Halpern, Jamal Hadi Salim, 7-Oct-08, This document defines the forwarding element (FE) model used in the Forwarding and Control Element Separation (ForCES) protocol [2]. The model represents the capabilities, state and configuration of forwarding elements within the context of the ForCES protocol, so that control elements (CEs) can control the FEs accordingly. More specifically, the model describes the logical functions that are present in an FE, what capabilities these functions support, and how these functions are or can be interconnected. This FE model is intended to satisfy the model requirements specified in the ForCES requirements document, RFC3654 [6]. "ForCES Protocol Specification", Ligang Dong, Avri Doria, Ram Gopal, Robert HAAS, Jamal Salim, Hormuzd Khosravi, Weiming Wang, 2-Mar-09, This document specifies the Forwarding and Control Element Separation (ForCES) protocol. ForCES protocol is used for communications between Control Elements(CEs) and Forwarding Elements (FEs) in a ForCES Network Element (ForCES NE). This specification is intended to meet the ForCES protocol requirements defined in RFC3654. Besides the ForCES protocol, this specification also defines the requirements for the Transport Mapping Layer (TML).Authors The participants in the ForCES Protocol Team, primary co-authors and co-editors, of this protocol specification, are: Ligang Dong (Zhejiang Gongshang University), Avri Doria (Lulea University of Technology), Ram Gopal (Nokia), Robert Haas (IBM), Jamal Hadi Salim (Znyx), Hormuzd M Khosravi (Intel), and Weiming Wang (Zhejiang Gongshang University). Special acknowledgement goes to Joel Halpern who has done extensive editing in support of congruence between the model and this protocol specification. Without his participation and persistence, this specification might never have been completed. "ForCES MIB", Robert HAAS, 10-Sep-08, This memo defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it defines managed objects for the Forwarding and Control Element Separation (ForCES) Network Element (NE). "SCTP based TML (Transport Mapping Layer) for ForCES protocol", Jamal Hadi Salim, Kentaro Ogawa, 23-Nov-09, This document defines the SCTP based TML (Transport Mapping Layer) for the ForCES protocol. It explains the rationale for choosing the SCTP (Stream Control Transmission Protocol) and also describes how this TML addresses all the requirements required by and the ForCES protocol. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 27, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. "ForCES Interoperability Draft", Evangelos Haleplidis, Kentaro Ogawa, Xin-ping Wang, Chuanhuang Li, 7-Sep-09, This document describes the details of the interoperability test of the Forward and Control Element Separation (ForCES) protocol that took place in the University of Patras in Rio, Greece, 15 and 16 July 2009. This informational draft provided necessary information, for all parties who wish to participate in the interoperability test. This update also includes the results of the test. "Implementation Report for ForCES", Evangelos Haleplidis, Kentaro Ogawa, Weiming Wang, Jamal Hadi Salim, 7-Sep-09, Forwarding and Control Element Separation (ForCES) defines an architectural framework and associated protocols to standardize information exchange between the control plane and the forwarding plane in a ForCES Network Element (ForCES NE). RFC3654 has defined the ForCES requirements, and RFC3746 has defined the ForCES framework. This document is an implementation report of the ForCES Protocol, Model and SCTP-TML, including the report on interoperability testing and the current state of ForCES implementations. "ForCES Implementation Experience Draft", Evangelos Haleplidis, Odysseas Koufopavlou, Spyros Denazis, 8-Oct-09, The forwarding and Control Element Separation (ForCES) protocol defines a standard communication and control mechanism through which a Control Element (CE) can control the behavior of a Forwarding Element (FE). This document captures the experience of implementing the ForCES protocol and model. It's aim is to help others by providing examples and possible strategies for implementing the ForCES protocol. Geographic Location/Privacy (geopriv) ------------------------------------- "Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information", Henning Schulzrinne, Hannes Tschofenig, John Morris, Jorge Cuellar, James Polk, 13-Jul-09, This document defines an authorization policy language for controlling access to location information. It extends the Common Policy authorization framework to provide location-specific access control. More specifically, this document defines condition elements specific to location information in order to restrict access based on the current location of the Target. Furthermore, it offers location- specific transformation elements to reduce the granularity of the returned location information. "Filtering Location Notifications in the Session Initiation Protocol (SIP)", Rohan Mahy, Brian Rosen, Hannes Tschofenig, 28-Dec-09, This document describes filters that limit asynchronous location notifications to compelling events, designed as an extension to RFC 4661, an XML-based format for event notification filtering, and based on RFC 3856, the SIP presence event package. The resulting location information is conveyed in existing location formats wrapped in the Presence Information Data Format Location Object (PIDF-LO). Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 1, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement and Requirements", Hannes Tschofenig, Henning Schulzrinne, 13-Jul-09, This document provides a problem statement, lists requirements and captures design aspects for a Geopriv Layer 7 Location Configuration Protocol L7 (LCP). This protocol aims to allow an end host to obtain location information, by value or by reference, from a Location Information Server (LIS) that is located in the access network. The obtained location information can then be used for a variety of different protocols and purposes. For example, it can be used as input to the Location-to-Service Translation Protocol (LoST) or to convey location within SIP to other entities. "HTTP Enabled Location Delivery (HELD)", Mary Barnes, James Winterbottom, Martin Thomson, Barbara Stark, 28-Aug-09, A Layer 7 Location Configuration Protocol (L7 LCP) is described that is used for retrieving location information from a server within an access network. The protocol includes options for retrieving location information in two forms: by value and by reference. The protocol is an extensible application-layer protocol that is independent of session-layer. This document describes the use of HyperText Transfer Protocol (HTTP) and HTTP over Transport Layer Security (HTTP/TLS) as transports for the protocol. "Requirements for a Location-by-Reference Mechanism", Roger Marshall, 9-Nov-09, This document defines terminology and provides requirements relating to Location-by-Reference approach using a location Uniform Resource Identifier (URI) to handle location information within signaling and other Internet messaging. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 13, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "Discovering the Local Location Information Server (LIS)", Martin Thomson, James Winterbottom, 8-Dec-09, Discovery of the correct Location Information Server (LIS) in the local access network is necessary for devices that wish to acquire location information from the network. A method is described for the discovery of a LIS in the access network serving a device. Dynamic Host Configuration Protocol (DHCP) options for IP versions 4 and 6 are defined that specify a domain name. This domain name is then used as input to a URI-enabled NAPTR (U-NAPTR) resolution process. Status of This Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 11, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "Dynamic Host Configuration Protocol (DHCP) IPv4 and IPv6 Option for a Location Uniform Resource Identifier (URI)", James Polk, 14-Sep-09, This document creates a Dynamic Host Configuration Protocol (DHCP) Option for transmitting a client's geolocation Uniform Resource Identifier (URI) of a client, which can be dereferenced in a separate transaction by the client or an entity the client sends this URI to. "Considerations for Civic Addresses in PIDF-LO - Guidelines and IANA Registry Definition", Karl Wolf, Alexander Mayrhofer, 9-Jul-09, This document provides a guideline for creating civic address consideration documents for individual countries, as required by RFC 4776. Furthermore, this document also creates an IANA Registry referring to such address consideration documents and registers such an address consideration for Austria. "A Uniform Resource Identifier for Geographic Locations ('geo' URI)", Alexander Mayrhofer, Christian Spanring, 9-Nov-09, This document specifies a Uniform Resource Identifier (URI) for geographic locations using the 'geo' scheme name. A 'geo' URI identifies a physical location in a two- or three-dimensional coordinate reference system in a compact, simple, human-readable, and protocol-independent way. The default coordinate reference system used is WGS-84. "Dynamic Host Configuration Protocol Options for Coordinate-based Location Configuration Information", James Polk, John Schnizlein, Marc Linsner, Martin Thomson, Bernard Aboba, 17-Dec-09, This document specifies Dynamic Host Configuration Protocol Options (both DHCPv4 and DHCPv6) for the coordinate-based geographic location of the client. The Location Configuration Information (LCI) includes latitude, longitude, and altitude, with resolution or uncertainty indicators for each. Separate parameters indicate the reference datum for each of these values. "An Architecture for Location and Location Privacy in Internet Applications", Richard Barnes, Matt Lepinski, Alissa Cooper, John Morris, Hannes Tschofenig, Henning Schulzrinne, 26-Oct-09, Location-based services (such as navigation applications, emergency services, management of equipment in the field) need geographic location information about Internet hosts, their users, and other related entities. These applications need to securely gather and transfer location information for location services, and at the same time protect the privacy of the individuals involved. This document describes an architecture for privacy-preserving location-based services in the Internet, focusing on authorization, security, and privacy requirements for the data formats and protocols used by these services. "Use of Device Identity in HTTP-Enabled Location Delivery (HELD)", James Winterbottom, Martin Thomson, Hannes Tschofenig, Richard Barnes, 8-Dec-09, When a Location Information Server receives a request for location information (using the locationRequest message), described in the base HTTP Enabled Location Delivery (HELD) specification, it uses the source IP address of arriving message as a pointer to the location determination process. This is sufficient in environments where the location of a Device can be determined based on its IP address. Two additional use cases are addresses by this document. In the first, location configuration requires additional or alternative identifiers from the source IP address provided in the request. In the second, an entity other than the Device requests the location of the Device. This document extends the HELD protocol to allow the location request message to carry Device identifiers. Privacy and security considerations describe the conditions where requests containing identifiers are permitted. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 12, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Global Routing Operations (grow) -------------------------------- "MRT routing information export format", Larry Blunk, Manish Karir, Craig Labovitz, 13-Jul-09, This document describes the MRT format for routing information export. This format was developed in concert with the Multi-threaded Routing Toolkit (MRT) from whence the format takes it name. The format can be used to export routing protocol messages, state changes, and routing information base contents. "BGP Monitoring Protocol", John Scudder, Rex Fernando, Stephen Stuart, 14-Dec-09, This document proposes a simple protocol, BMP, which can be used to monitor BGP sessions. BMP is intended to provide a more convenient interface for obtaining route views for research purpose than the screen-scraping approach in common use today. The design goals are to keep BMP simple, useful, easily implemented, and minimally service-affecting. BMP is not suitable for use as a routing protocol. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 17, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. "FIB Suppression with Virtual Aggregation", Paul Francis, Xiaohu Xu, Hitesh Ballani, Dan Jen, Robert Raszuk, Lixia Zhang, 25-Oct-09, The continued growth in the Default Free Routing Table (DFRT) stresses the global routing system in a number of ways. One of the most costly stresses is FIB size: ISPs often must upgrade router hardware simply because the FIB has run out of space, and router vendors must design routers that have adequate FIB. FIB suppression is an approach to relieving stress on the FIB by NOT loading selected RIB entries into the FIB. Virtual Aggregation (VA) allows ISPs to shrink the FIBs of any and all routers, easily by an order of magnitude with negligible increase in path length and load. FIB suppression deployed autonomously by an ISP (cooperation between ISPs is not required), and can co-exist with legacy routers in the ISP. "Requirements for the graceful shutdown of BGP sessions", Bruno Decraene, Pierre Francois, cristel pelsser, Zubair Ahmad, Antonio Jose Elizond Armengol, 23-Oct-09, The BGP protocol is heavily used in Service Provider networks both for Internet and BGP/MPLS VPN services. For resiliency purposes, redundant routers and BGP sessions can be deployed to reduce the consequences of an AS Border Router or BGP session breakdown on customers' or peers' traffic. However simply taking down or even up a BGP session for maintenance purposes may still induce connectivity losses during the BGP convergence. This is no more satisfactory for new applications (e.g. voice over IP, on line gaming, VPN). Therefore, a solution is required for the graceful shutdown of a (set of) BGP session(s) in order to limit the amount of traffic loss during a planned shutdown. This document expresses requirements for such a solution. "Graceful BGP session shutdown", Pierre Francois, Bruno Decraene, Cristel Pelsser, Clarence Filsfils, 26-Oct-09, This draft describes operational procedures aimed at reducing the amount of traffic lost during planned maintenances of routers, involving the shutdown of BGP peering sessions. "Proposal to use an inner MPLS label to identify the remote ASBR VA", Xiaohu Xu, Paul Francis, 23-Sep-09, The draft "MPLS Tunnels for Virtual Aggregation" [I-D.ietf-grow-va-mpls] specifies how MPLS is used as the tunneling protocol for Virtual Aggregation (VA). The -00 version of that draft specifies only one level of labels, with the result that one Label Switched Path (LSP) for every remote ASBR must be established. For large ISPs, this can amount to a large number of LSPs. This draft proposes adding the option of using an inner label to identify the remote ASBR. Either an outer label or an IP tunnel is used to reach the local ASBR. When MPLS is used as the tunneling protocol, this reduces the number of LSPs to the number of local border routers (ASBR). "Proposal for Auto-Configuration in Virtual Aggregation", Paul Francis, Xiaohu Xu, Hitesh Ballani, Dan Jen, Robert Raszuk, Lixia Zhang, 18-Oct-09, Virtual Aggregation as specified in [I-D.ietf-grow-va] requires a certain amount of configuration, namely virtual prefixes (VP), a VP list, type of tunnel, and popular prefixes. This draft proposes optional approaches to auto-configuration of popular prefixes and the VP list, and discusses the pros and cons of each. If these proposals are accepted, they will be incorporated into [I-D.ietf-grow-va]. Host Identity Protocol (hip) ---------------------------- "Basic HIP Extensions for Traversal of Network Address Translators", Miika Komu, Tom Henderson, Hannes Tschofenig, Jan Melen, Ari Keranen, 23-Oct-09, This document specifies extensions to the Host Identity Protocol (HIP) to facilitate Network Address Translator (NAT) traversal. The extensions are based on the use of the Interactive Connectivity Establishment (ICE) methodology to discover a working path between two end-hosts, and on standard techniques for encapsulating Encapsulating Security Payload (ESP) packets within the User Datagram Protocol (UDP). This document also defines elements of a procedure for NAT traversal, including the optional use of a HIP relay server. With these extensions HIP is able to work in environments that have NATs and provides a generic NAT traversal solution to higher-layer networking applications. "Basic Socket Interface Extensions for Host Identity Protocol (HIP)", Miika Komu, Tom Henderson, 29-Dec-09, This document defines extensions to the current sockets API for the Host Identity Protocol (HIP). The extensions focus on the use of public-key based identifiers discovered via DNS resolution, but define also interfaces for manual bindings between HITs and locators. With the extensions, the application can also support more relaxed security models where the communication can be non-HIP based, according to local policies. The extensions in this document are experimental and provide basic tools for further experimentation with policies. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 2, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. "HIP Certificates", Tobias Heer, Samu Varjonen, 26-Oct-09, This document specifies a certificate parameter called CERT for the Host Identity Protocol (HIP). The CERT parameter is a container for X.509.v3 certificates and for Simple Public Key Infrastructure (SPKI) certificates. It is used for carrying these certificates in HIP control packets. Additionally, this document specifies the representations of Host Identity Tags in X.509.v3 and in SPKI certificates. "HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking Environment", Gonzalo Camarillo, Pekka Nikander, Jani Hautakorpi, Ari Keranen, Alan Johnston, 26-Oct-09, This document specifies a framework to build HIP (Host Identity Protocol)-based overlay networks. This framework uses HIP to perform connection management. Other functions, such as data storage and retrieval or overlay maintenance, are implemented using protocols other than HIP. These protocols are loosely referred to as peer protocols. "HIP (Host Identity Protocol) Immediate Carriage and Conveyance of Upper-layer Protocol Signaling (HICCUPS)", Pekka Nikander, Gonzalo Camarillo, Jan Melen, 26-Oct-09, This document defines a new HIP (Host Identity Protocol) packet type called DATA. HIP DATA packets are used to securely and reliably convey arbitrary protocol messages over the Internet and various overlay networks. "Host Identity Protocol (HIP) Multi-hop Routing Extension", Gonzalo Camarillo, Ari Keranen, 26-Oct-09, This document specifies two extensions to HIP to implement multi-hop routing. The first extension allows implementing source routing in HIP. That is, a host sending a HIP packet can define a set of hosts that the HIP packet should traverse. The second extension allows a HIP packet to carry and record the list of hosts that forwarded it. Handover Keying (hokey) ----------------------- "Distribution of EAP based keys for handover and re-authentication", Katrin Hoeper, Madjid Nakhjiri, Yoshihiro Ohba, 3-Dec-09, This document describes an abstract mechanism for delivering root keys from an Extensible Authentication Protocol (EAP) server to another network server that requires the keys for offering security protected services, such as re-authentication, to an EAP peer. The distributed root key can be either a usage-specific root key (USRK), a domain-specific root key (DSRK) or a domain-specific usage-specific root key (DSUSRK) that has been derived from an Extended Master Session Key (EMSK) hierarchy previously established between the EAP server and an EAP peer. The document defines a template for a key distribution exchange (KDE) protocol that can distribute these different types of root keys using an AAA (Authentication, Authorization and Accounting) protocol and discusses its security requirements. The described protocol template does not specify message formats, data encoding, or other implementation details. It thus needs to be instantiated with a specific protocol (e.g. RADIUS or Diameter) before it can be used. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 6, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. "Extensible Authentication Protocol (EAP) Early Authentication Problem Statement", Yoshihiro Ohba, Glen Zorn, 17-Dec-09, EAP early authentication may be defined as the use of EAP by a mobile device to establish authenticated keying material on a target attachment point prior to its arrival. This draft discusses the EAP early authentication problem in detail. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 20, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Hypertext Transfer Protocol Bis (httpbis) ----------------------------------------- "HTTP/1.1, part 1: URIs, Connections, and Message Parsing", Roy Fielding, Jim Gettys, Jeffrey Mogul, Henrik Nielsen, Larry Masinter, Paul Leach, Tim Berners-Lee, Julian Reschke, 26-Oct-09, The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 1 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 1 provides an overview of HTTP and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the generic message syntax and parsing requirements for HTTP message frames, and describes general security concerns for implementations. "HTTP/1.1, part 2: Message Semantics", Roy Fielding, Jim Gettys, Jeffrey Mogul, Henrik Nielsen, Larry Masinter, Paul Leach, Tim Berners-Lee, Julian Reschke, 26-Oct-09, The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages as expressed by request methods, request-header fields, response status codes, and response-header fields. "HTTP/1.1, part 3: Message Payload and Content Negotiation", Roy Fielding, Jim Gettys, Jeffrey Mogul, Henrik Nielsen, Larry Masinter, Paul Leach, Tim Berners-Lee, Julian Reschke, 26-Oct-09, The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 3 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 3 defines HTTP message content, metadata, and content negotiation. "HTTP/1.1, part 4: Conditional Requests", Roy Fielding, Jim Gettys, Jeffrey Mogul, Henrik Nielsen, Larry Masinter, Paul Leach, Tim Berners-Lee, Julian Reschke, 26-Oct-09, The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 4 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 4 defines request header fields for indicating conditional requests and the rules for constructing responses to those requests. "HTTP/1.1, part 5: Range Requests and Partial Responses", Roy Fielding, Jim Gettys, Jeffrey Mogul, Henrik Nielsen, Larry Masinter, Paul Leach, Tim Berners-Lee, Julian Reschke, 26-Oct-09, The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 5 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 5 defines range-specific requests and the rules for constructing and combining responses to those requests. "HTTP/1.1, part 6: Caching", Roy Fielding, Jim Gettys, Jeffrey Mogul, Henrik Nielsen, Larry Masinter, Paul Leach, Tim Berners-Lee, Julian Reschke, 26-Oct-09, The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. This document is Part 6 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 6 defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages. "HTTP/1.1, part 7: Authentication", Roy Fielding, Jim Gettys, Jeffrey Mogul, Henrik Nielsen, Larry Masinter, Paul Leach, Tim Berners-Lee, Julian Reschke, 26-Oct-09, The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 7 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 7 defines HTTP Authentication. HTTP State Management Mechanism (httpstate) ------------------------------------------- "HTTP State Management Mechanism", Adam Barth, 6-Jan-10, This document defines the HTTP Cookie and Set-Cookie headers. These headers can be used by HTTP servers to store state on HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol. The cookie protocol has many historical infelicities and should be avoided for new applications of HTTP. NOTE: If you have suggestions for improving the draft, please send email to http-state@ietf.org. Suggestions with test cases are especially appreciated. Internet Architecture Board (iab) --------------------------------- "Design Choices When Expanding DNS", Patrik Faltstrom, Rob Austein, Peter Koch, 9-Mar-09, This note discusses how to extend the DNS with new data for a new application. DNS extension discussions too often focus on reuse of the TXT Resource Record Type. This document lists different mechanisms to extend the DNS, and concludes that the use of a new DNS Resource Record Type is the best solution. ""Uncoordinated Protocol Development Considered Harmful"", Stewart Bryant, Monique Morrow, 24-Sep-09, This document identifies problems that may result from the absence of formal coordination and joint development on protocols of mutual interest between standards development organizations. Some of these problems may cause significant harm to the Internet. The document suggests that a robust procedure is required prevent this from occurring in the future. The IAB has selected a number of case studies, such as T-MPLS, as recent examples to describe hazard to the Internet architecture as a result of uncoordinated adaptation of a protocol. This experience has resulted in a considerable improvement in the relationship between the IETF and the ITU-T. In particular, this was achieved via the establishment of the "Joint working team on MPLS-TP" . In addition, the leadership of the two organisations agreed to improve inter-organizational working practices so as to avoid conflict in the future between ITU-T Recommendations and IETF RFCs. Whilst we use ITU-T - IETF interactions in these case studies, the scope of the document extends to all SDO that have an overlapping protocol interest with the IETF. Internationalized Domain Names in Applications, Revised (idnabis) ----------------------------------------------------------------- "The Unicode code points and IDNA", Patrik Faltstrom, 9-Jan-10, This document specifies rules for deciding whether a code point, considered in isolation or in context, is a candidate for inclusion in an Internationalized Domain Name (IDN). It is part of the specification of Internationalizing Domain Names in Applications 2008 (IDNA2008). Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 13, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale", John Klensin, 11-Jan-10, Several years have passed since the original protocol for Internationalized Domain Names (IDNs) was completed and deployed. During that time, a number of issues have arisen, including the need to update the system to deal with newer versions of Unicode. Some of these issues require tuning of the existing protocols and the tables on which they depend. This document provides an overview of a revised system and provides explanatory material for its components. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 15, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. "Internationalized Domain Names in Applications (IDNA): Protocol", John Klensin, 7-Jan-10, This document is the revised protocol definition for internationalized domain names (IDNs). The rationale for changes, the relationship to the older specification, and important "Right-to-left scripts for IDNA", Harald Alvestrand, Cary Karp, 27-Sep-09, The use of right-to-left scripts in internationalized domain names has presented several challenges. This memo proposes a new BIDI rule for IDNA labels, based on the encountered problems with some scripts, and some shortcomings in the 2003 IDNA BIDI criterion. "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", John Klensin, 7-Jan-10, This document is one of a collection that, together, describe the protocol and usage context for a revision of Internationalized Domain Names for Applications (IDNA), superseding the earlier version. It describes the document collection and provides definitions and other material that are common to the set. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 11, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. "Mapping Characters in IDNA", Pete Resnick, Paul Hoffman, 19-Oct-09, In the original version of the Internationalized Domain Names in Applications (IDNA) protocol, any Unicode code points taken from user input were mapped into a set of Unicode code points that "make sense", which were then encoded and passed to the domain name system (DNS). The current version of IDNA presumes that the input to the protocol comes from a set of "permitted" code points, which it then encodes and passes to the DNS, but does not specify what to do with the result of user input. This document describes the actions that can be taken by an implementation between user input and passing permitted code points to the new IDNA protocol. Inter-Domain Routing (idr) -------------------------- "AS-wide Unique BGP Identifier for BGP-4", Enke Chen, Jenny Yuan, 3-Aug-09, To accommodate situations where the current requirements for the BGP Identifier are not met, this document relaxes the definition of the BGP Identifier to be a 4-octet unsigned, non-zero integer, and relaxes the "uniqueness" requirement so that only AS-wide uniqueness of the BGP Identifiers is required. These revisions to the base BGP specification do not introduce any backward compatibility issue. "Multisession BGP", John Scudder, Chandrashekhar Appanna, 12-Jul-09, This specification augments "Multiprotocol Extensions for BGP-4" (MP- BGP) by proposing a mechanism to facilitate the use of multiple sessions between a given pair of BGP speakers. Each session is used to transport routes related by some session-based attribute such as AFI/SAFI. This provides an alternative to the MP-BGP approach of multiplexing all routes onto a single connection. Use of this approach is expected to provide finer-grained fault management and isolation as the BGP protocol is used to support more and more diverse services. "Revisions to the BGP 'Minimum Route Advertisement Interval'", Paul Jakma, 28-Jul-09, This document revises the specification of the BGP MRAI timer, by deprecating the previously recommended values and by allowing for withdrawals to be exempted from the MRAI. "Advertisement of Multiple Paths in BGP", Daniel Walton, Alvaro Retana, Enke Chen, John Scudder, 3-Aug-09, In this document we propose a BGP extension that allows the advertisement of multiple paths for the same address prefix without the new paths implicitly replacing any previous ones. The essence of the extension is that each path is identified by a path identifier in addition to the address prefix. "Generic Subtype for BGP Four-octet AS specific extended community", Dhananjaya Rao, Pradosh Mohapatra, Jeffrey Haas, 26-Oct-09, Maintaining the current best practices with communities, ISPs and enterprises that are assigned a 4-octet AS number may want the BGP UPDATE messages they receive from their customers or peers to include a 4-octet AS specific extended community. This document defines a new sub-type within the four-octet AS specific extended community to facilitate this practice. "Error Handling for Optional Transitive BGP Attributes", John Scudder, Enke Chen, 26-Oct-09, According to the base BGP specification, a BGP speaker that receives an UPDATE message containing a malformed attribute is required to reset the session over which the offending attribute was received. This behavior is undesirable in the case of optional transitive attributes. This document revises BGP's error-handling rules for optional transitive attributes, and provides guidelines for the authors of documents defining new optional transitive attributes. It also revises the error handling procedures for several existing optional transitive attributes. "BGP Support for Four-octet AS Number Space", Quaizar Vohra, Enke Chen, 2-Oct-09, Currently the Autonomous System (AS) number is encoded as a two-octet entity in BGP. This document describes extensions to BGP to carry the Autonomous System number as a four-octet entity. "The Accumulated IGP Metric Attribute for BGP", Rex Fernando, Pradosh Mohapatra, Eric Rosen, James Uttaro, 7-Oct-09, Routing protocols that have been designed to run within a single administrative domain ("IGPs") generally do so by assigning a metric to each link, and then choosing as the installed path between two nodes the path for which the total distance (sum of the metric of each link along the path) is minimized. BGP, designed to provide routing over a large number of independent administrative domains ("autonomous systems"), does not make its path selection decisions through the use of a metric. It is generally recognized that any attempt to do so would incur significant scalability problems, as well as inter-administration coordination problems. However, there are deployments in which a single administration runs several contiguous BGP networks. In such cases, it can be desirable, within that single administrative domain, for BGP to select paths based on a metric, just as an IGP would do. The purpose of this document is to provide a specification for doing so. "BGP Bestpath Selection Criteria", Rajiv Asati, 28-Aug-09, BGP specification [RFC4271] prescribes 'BGP next-hop reachability' as one of the key 'Route Resolvability Condition' that must be satisfied before the BGP bestpath candidate selection. This condition, however, may not be sufficient (as explained in the Appendix section) and desire further granularity. This document defines enhances the "Route Resolvability Condition" to facilitate the next-hop to be resolved in the chosen data plane. "BGP Advisory Message", Tom Scholl, John Scudder, Richard Steenbergen, David Freedman, 16-Oct-09, The BGP routing protocol is used with external as well as internal neighbors to propagate route advertisements. In the case of external BGP sessions, there is typically a demarcation of administrative responsibility between the two entities. Provisioning, maintenance and administrative actions are communicated via off-line methods such as email or telephone calls. While these methods have been used for many years, it can be troublesome for an operator to correlate a BGP- related event in the network with a notice that was transmitted in email. This document proposes a new BGP message type, the Advisory message, which can be used to convey advisory information to a BGP speaker's peer. A capability is used to ensure that the recipient of the Advisory message is capable of supporting it. IP Flow Information Export (ipfix) ---------------------------------- "Definitions of Managed Objects for IP Flow Information Export", Thomas Dietz, Atsushi Kobayashi, Benoit Claise, Gerhard Muenz, 10-Dec-09, This document defines managed objects for IP Flow Information Export (IPFIX). These objects provide information for monitoring IPFIX Exporters and IPFIX Collectors including the basic configuration information. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 13, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "IPFIX Mediation: Problem Statement", Atsushi Kobayashi, Benoit Claise, Haruhiko Nishida, Christoph Sommer, Falko Dressler, Emile Stephan, 10-Dec-09, Flow-based measurement is a popular method for various network monitoring usages. The sharing of flow-based information for monitoring applications having different requirements raises some open issues in terms of measurement system scalability, flow-based measurement flexibility, and export reliability that IPFIX Mediation may help resolve. This document describes some problems related to flow-based measurement that network administrators have been facing, and then describes IPFIX Mediation applicability examples along with the problems. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 5, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. "IPFIX Mediation: Framework", Atsushi Kobayashi, Benoit Claise, Keisuke Ishibashi, 16-Oct-09, This document describes a framework for IPFIX Mediation. This framework details the IPFIX Mediation reference model and IPFIX Mediator components. "IPFIX Export per SCTP Stream", Benoit Claise, Paul Aitken, Andrew Johnson, Gerhard Muenz, 19-Nov-09, This document specifies an extension to the specifications in RFC5101, IP Flow Information Export (IPFIX), when using the Partial Reliability extension of SCTP (PR-SCTP, Partial Reliability Stream Control Transmission Protocol). When implemented at both the Exporting and Collecting Processes, this method offers several advantages such as the ability to calculate Data Record losses for PR-SCTP, immediate export of Template Withdrawal Messages, immediate reuse of Template IDs within an SCTP stream, reduced likelihood of Data Record loss, and reduced demands on the Collecting Process. When implemented in only the Collecting or Exporting Process then normal IPFIX behavior will be seen without these additional benefits. "Configuration Data Model for IPFIX and PSAMP", Gerhard Muenz, Benoit Claise, Paul Aitken, 23-Oct-09, This document specifies a data model for the configuration of selection processes, caches, exporting processes, and collecting processes of IPFIX and PSAMP compliant monitoring devices using UML (Unified Modeling Language) class diagrams. The configuration data is encoded in Extensible Markup Language (XML). The structure of the data model is specified in a YANG module to ensure compatibility with the NETCONF protocol. "IP Flow Anonymisation Support", Elisa Boschi, Brian Trammell, 19-Nov-09, This document describes anonymisation techniques for IP flow data and the export of anonymised data using the IPFIX protocol. It provides a categorization of common anonymisation schemes and defines the parameters needed to describe them. It provides guidelines for the implementation of anonymised data export and storage over IPFIX, and describes an Options-based method for anonymisation metadata export within the IPFIX protocol, providing the basis for the definition of information models for configuring anonymisation techniques within an IPFIX Metering or Exporting Process, and for reporting the technique in use to an IPFIX Collecting Process. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 23, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "Export of Structured Data in IPFIX", Benoit Claise, Gowri Dhandapani, Stan Yates, Paul Aitken, 15-Oct-09, This document specifies an extension to IP Flow Information eXport (IPFIX) protocol specification in [RFC5101] and the IPFIX information model specified in [RFC5102] to support hierarchical structured data and lists (sequences) of Information Elements in data records. This extension allows definition of complex data structures such as variable-length lists and specification of hierarchical containment relationships between Temp "Flow Selection Techniques", Lorenzo Peluso, Tanja Zseby, Salvatore D'Antonio, Maurizio Molina, 18-Oct-09, Flow selection is the process in charge of electing a limited number of flows from all of those observed at an observation point to be considered into the measurement process chain. The flow selection process can be enabled at different stages of the monitoring reference model. It can be performed at metering time once the packet classification has been executed, i.e. flow state dependent packet selection, or at recording/exporting time by limiting the number of flows to be stored and/or exported to the collector applications. This document illustrates the motivations which might lead flow selection to be performed and presents a classification of the related techniques. The document furthermore provides an information model for configuring flow selection techniques and discusses what information about the flow selection process is beneficial to be exported by adopting a suitable information model. "Reliability Extension for IPFIX", Sujay Gupta, 4-Dec-09, IPFIX[RFC3917] mandates the IPFIX device should be reliable.To be reliable the individual components like the Metering process or the Exporting process should not fail to meter & export the flow information to the collector, else indicate its incapability explicitly. Currently, IPFIX transmits failure by sending count of packets,flows it failed to process along with the duration of the failure. This document outlines some of the limitations an IPFIX device may have and suggests solutions. IP Performance Metrics (ippm) ----------------------------- "Framework for Metric Composition", Al Morton, 20-Dec-09, This memo describes a detailed framework for composing and aggregating metrics (both in time and in space) originally defined by the IP Performance Metrics (IPPM) RFC 2330 and developed by the IETF. This new framework memo describes the generic composition and aggregation mechanisms. The memo provides a basis for additional documents that implement the framework to define detailed compositions and aggregations of metrics which are useful in practice. "Spatial Composition of Metrics", Al Morton, Emile Stephan, 19-Oct-09, This memo utilizes IPPM metrics that are applicable to both complete paths and sub-paths, and defines relationships to compose a complete path metric from the sub-path metrics with some accuracy w.r.t. the actual metrics. This is called Spatial Composition in RFC 2330. The memo refers to the Framework for Metric Composition, and provides background and motivation for combining metrics to derive others. The descriptions of several composed metrics and statistics follow. "Reporting IP Performance Metrics to Users", Stanislav Shalunov, Martin Swany, 13-Jul-09, The aim of this document is to define a small set of metrics that are robust, easy to understand, orthogonal, relevant, and easy to compute. The IPPM WG has defined a large number of richly parameterized metrics because network measurement has many purposes. Often, the ultimate purpose is to report a concise set of metrics describing a network's state to an end user. It is for this purpose that the present set of metrics is defined. "TWAMP Reflect Octets and Symmetrical Size Features", Al Morton, Len Ciavattone, 23-Oct-09, The IETF has completed its work on the core specification of TWAMP - the Two-Way Active Measurement Protocol. This memo describes two closely-related features for TWAMP: an optional capability where the responder host returns some of the command octets or padding octets to the controller, a new sender packet format that ensures equal test packet sizes are used in both directions. "Individual Session Control Feature for TWAMP", Al Morton, Murtaza Chiba, 23-Oct-09, The IETF has completed its work on the core specification of TWAMP - the Two-Way Active Measurement Protocol. This memo describes a new feature for TWAMP, that gives the controlling host the ability to start and stop one or more individual test sessions using Session Identifiers. The base capability of the TWAMP protocol requires all test sessions previously requested and accepted to start and stop at the same time. "Reporting Metrics: Different Points of View", Al Morton, Gomathi Ramachandran, Ganga Maguluri, 19-Oct-09, Consumers of IP network performance metrics have many different uses in mind. This memo categorizes the different audience points of view. It describes how the categories affect the selection of metric parameters and options when seeking info that serves their needs. The memo then proceeds to discuss "long-term" reporting considerations (e.g, days, weeks or months, as opposed to 10 seconds). IP Security Maintenance and Extensions (ipsecme) ------------------------------------------------ "Internet Key Exchange Protocol: IKEv2", Charlie Kaufman, Paul Hoffman, Yoav Nir, Pasi Eronen, 9-Dec-09, This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining security associations (SAs). It replaces and updates RFC 4306, and includes all of the clarifications from RFC 4718. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 12, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. "Wrapped ESP for Traffic Visibility", Ken Grewal, Gabriel Montenegro, Manav Bhatia, 30-Nov-09, This document describes the Wrapped Encapsulating Security Payload (WESP) protocol, which builds on the Encapsulating Security Payload (ESP) [RFC4303], and is designed to allow intermediate devices to (1) ascertain if data confidentiality is being employed within ESP and if not, (2) inspect the IPsec packets for network monitoring and access control functions. Currently in the IPsec ESP standard, there is no way to differentiate between encrypted and unencrypted payloads by simply examining a packet. This poses certain challenges to the intermediate devices that need to deep inspect the packet before making a decision on what should be done with that packet (Inspect and/or Allow/Drop). The mechanism described in this document can be used to easily disambiguate integrity-only ESP from ESP-encrypted packets, without compromising on the security provided by ESP. "IPv6 Configuration in IKEv2", Pasi Eronen, Julien Laganier, Cheryl Madson, 26-Oct-09, When IKEv2 is used for remote VPN access (client to VPN gateway), the gateway assigns the client an IP address from the internal network using IKEv2 configuration payloads. The configuration payloads specified in RFC 4306 work well for IPv4, but make it difficult to use certain features of IPv6. This document specifies new configuration attributes for IKEv2 that allows the VPN gateway to assign IPv6 prefixes to clients, enabling all features of IPv6 to be used with the client-gateway "virtual link". "IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap", Sheila Frankel, Suresh Krishnan, 1-Oct-09, Over the past few years, the number of RFCs that define and use IPsec and IKE has greatly proliferated. This is complicated by the fact that these RFCs originate from numerous IETF working groups: the original IPsec WG, its various spin-offs, and other WGs that use IPsec and/or IKE to protect their protocols' traffic. This document is a snapshot of IPsec- and IKE-related RFCs. It includes a brief description of each RFC, along with background information explaining the motivation and context of IPsec's outgrowths and extensions. It obsoletes the previous IPsec Document Roadmap [RFC2411]. "Heuristics for Detecting ESP-NULL packets", Tero Kivinen, Daniel McDonald, 30-Nov-09, This document describes a set of heuristics for distinguishing IPsec ESP-NULL (Encapsulating Security Payload without encryption) packets from encrypted ESP packets. These heuristics can be used on intermediate devices, like traffic analyzers, and deep inspection engines, to quickly decide whether given packet flow is interesting or not. Use of these heuristics does not require any changes made on existing RFC4303 compliant IPsec hosts. "Using Advanced Encryption Standard (AES) Counter Mode with IKEv2", Sean Shen, Yu Mao, S murthy, 4-Dec-09, This document describes the usage of Advanced Encryption Standard Counter Mode (AES-CTR), with an explicit initialization vector, by IKEv2 for encrypting the IKEv2 exchanges that follow the IKE_SA_INIT exchange. IS-IS for IP Internets (isis) ----------------------------- "IPv6 Traffic Engineering in IS-IS", Jon Harrison, Jon Berger, Mike Bartlett, 21-Sep-09, This document specifies a method for exchanging IPv6 Traffic Engineering information using the IS-IS routing protocol. The described method uses three new TLVs, together with two new sub-TLVs of the Extended IS Reachability TLV. The information distributed allows a CSPF algorithm to calculate traffic engineered routes using IPv6 addresses. "Advertising Generic Information in IS-IS", Les Ginsberg, Stefano Previdi, Mike Shand, 6-Jan-10, This draft describes the manner in which generic application information (i.e. information not directly related to the operation of the IS-IS protocol) SHOULD be advertised in IS-IS LSPs and defines guidelines which SHOULD be used when flooding such information. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 8, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "IS-IS Multi-Instance", Stefano Previdi, Les Ginsberg, Mike Shand, David Ward, Abhay Roy, 15-Oct-09, This draft describes a mechanism that allows a single router to share one or more links among multiple IS-IS routing protocol instances. Multiple instances allow the isolation of resources associated with each instance. Routers will form instance specific adjacencies, exchange instance specific routing updates and compute paths utilizing instance specific LSDB information. Each PDU will contain a new TLV identifying the instance to which the PDU belongs. This allows a network operator to deploy multiple IS-IS instances in parallel, using the same set of links when required and still have the capability of computing instance specific paths. This draft does not address the forwarding paradigm that needs to be used in order to ensure data PDUs are forwarded according to the paths computed by a specific instance. "IS-IS BFD Enabled TLV", Christian Hopps, Les Ginsberg, 6-Jan-10, 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. Integrated Security Model for SNMP (isms) ----------------------------------------- "Transport Layer Security (TLS) Transport Model for SNMP", Wesley Hardaker, 8-Jan-10, This document describes a Transport Model for the Simple Network Management Protocol (SNMP), that uses either the Transport Layer Security protocol or the Datagram Transport Layer Security (DTLS) protocol. The TLS and DTLS protocols provide authentication and privacy services for SNMP applications. This document describes how the TLS Transport Model (TLSTM) implements the needed features of a SNMP Transport Subsystem to make this protection possible in an interoperable way. This transport model is designed to meet the security and operational needs of network administrators. It supports sending of SNMP messages over TLS/TCP, DTLS/UDP and DTLS/SCTP. The TLS mode can make use of TCP's improved support for larger packet sizes and the DTLS mode provides potentially superior operation in environments where a connectionless (e.g. UDP or SCTP) transport is preferred. Both TLS and DTLS integrate well into existing public keying infrastructures. This document also defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines objects for managing the TLS Transport Model for SNMP. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 12, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. "Extensions to View-based Access Control Model for use with RADIUS", Kaushik Narayan, David Nelson, Randy Presuhn, 2-Dec-09, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it describes a backward-compatible extension to the View-based Access Control Model (VACM) for SNMPv3 for use with RADIUS and other AAA services to provide authorization of MIB database access, and defines objects for managing this extension. This extension is intended to be used in conjunction with secure SNMP Transport Models that facilitate RADIUS authentication, such as the Secure Shell Transport Model. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 5, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Provisioning of Symmetric Keys (keyprov) ---------------------------------------- "Dynamic Symmetric Key Provisioning Protocol (DSKPP)", Andrea Doherty, Mingliang Pei, Salah Machani, Magnus Nystrom, 16-Nov-09, DSKPP is a client-server protocol for initialization (and configuration) of symmetric keys to locally and remotely accessible cryptographic modules. The protocol can be run with or without private-key capabilities in the cryptographic modules, and with or without an established public-key infrastructure. Two variations of the protocol support multiple usage scenarios. With the four-pass variant, keys are mutually generated by the provisioning server and cryptographic module; provisioned keys are not transferred over-the-wire or over-the-air. The two-pass variant enables secure and efficient download and installation of pre- generated symmetric keys to a cryptographic module. This document builds on information contained in [RFC4758], adding specific enhancements in response to implementation experience and liaison requests. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 20, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "Symmetric Key Package Content Type", Sean Turner, Russ Housley, 20-Oct-09, This document defines the symmetric key format content type. It is transport independent. The Cryptographic Message Syntax can be used to digitally sign, digest, authenticate, or encrypt this content type. "Portable Symmetric Key Container (PSKC)", Philip Hoyer, Mingliang Pei, Salah Machani, 8-Jan-10, This document specifies a symmetric key format for transport and provisioning of symmetric keys to different types of crypto modules. For example, One Time Password (OTP) shared secrets or symmetric cryptographic keys to strong authentication devices. A standard key transport format enables enterprises to deploy best-of-breed solutions combining components from different vendors into the same infrastructure. Kitten (GSS-API Next Generation) (kitten) ----------------------------------------- "Namespace Considerations and Registries for GSS-API Extensions", Nicolas Williams, 1-Apr-09, This document describes the ways in which the GSS-API may be extended and directs the creation of an IANA registry for various GSS-API namespaces. "GSS-API Naming Extensions", Nicolas Williams, Leif Johansson, 30-Jul-09, The Generic Security Services API (GSS-API) provides a simple naming architecture that supports name-based authorization. This document introduces new APIs that extend the GSS-API naming model to support name attribute transfer between GSS-API peers. Kerberos (krb-wg) ----------------- "A Generalized Framework for Kerberos Pre-Authentication", Sam Hartman, Larry Zhu, 26-Oct-09, Kerberos is a protocol for verifying the identity of principals (e.g., a workstation user or a network server) on an open network. The Kerberos protocol provides a mechanism called pre-authentication for proving the identity of a principal and for better protecting the long-term secrets of the principal. This document describes a model for Kerberos pre-authentication mechanisms. The model describes what state in the Kerberos request a pre-authentication mechanism is likely to change. It also describes how multiple pre-authentication mechanisms used in the same request will interact. This document also provides common tools needed by multiple pre- authentication mechanisms. One of these tools is a secure channel between the client and the KDC with a reply key strengthening mechanism; this secure channel can be used to protect the authentication exchange thus eliminate offline dictionary attacks. With these tools, it is relatively straightforward to chain multiple authentication mechanisms, utilize a different key management system, or support a new key agreement algorithm. "Using Kerberos V5 over the Transport Layer Security (TLS) protocol", Simon Josefsson, 31-Jul-09, This document specify how the Kerberos V5 protocol can be transported over the Transport Layer Security (TLS) protocol, to provide additional security features. "Problem statement on the cross-realm operation of Kerberos", Shoichi Sakane, Saber Zrelli, Masahiro Ishiyama, 4-Jan-10, The Kerberos protocol is today one of the most widely deployed authentication protocols in the Internet. In order for a Kerberos deployment to operate in a scalable manner, different Kerberos realms must interoperate in such a way that cross-realm operations can be performed efficiently and securely. This document provides background information regarding large scale Kerberos deployments in the industrial sector, with the aim of identifying issues in the current Kerberos cross-realm authentication model as defined in RFC4120. As industrial automation is moving towards wider adoption of Internet standards, the Kerberos authentication protocol represents one of the best alternatives for ensuring the confidentiality and the integrity of communications in control networks while meeting performance and security requirements. However, the use of Kerberos cross-realm operations in large scale industrial systems may introduce issues that could cause performance and reliability problems. This document describes some examples of actual large scale industrial systems, and lists requirements and restriction regarding authentication operations in such environments. The current document also identifies a number of requirements derived from the industrial automation field. Although they are found in the field of industrial automation, these requirements are general enough and are applicable to the problem of Kerberos cross-realm operations. Conventions used in this document The reader is assumed to be familiar with the terms and concepts described in the Kerberos Version 5 [RFC4120]. "OTP Pre-authentication", Gareth Richards, 9-Oct-09, The Kerberos protocol provides a framework authenticating a client using the exchange of pre-authentication data. This document describes the use of this framework to carry out One Time Password (OTP) authentication. "Initial and Pass Through Authentication Using Kerberos V5 and the GSS- API (IAKERB)", Larry Zhu, Jeffrey Altman, 30-Jul-09, This document defines extensions to the Kerberos protocol and the GSS-API Kerberos mechanism that enable a GSS-API Kerberos client to exchange messages with the KDC using the GSS-API acceptor as the proxy, by encapsulating the Kerberos messages inside GSS-API tokens. With these extensions a client can obtain Kerberos tickets for services where the KDC is not accessible to the client, but is accessible to the application server. "An information model for Kerberos version 5", Leif Johansson, 19-Oct-09, This document describes an information model for Kerberos version 5 from the point of view of an administrative service. There is no standard for administrating a kerberos 5 KDC. This document describes the services exposed by an administrative interface to a KDC. Layer 2 Virtual Private Networks (l2vpn) ---------------------------------------- "Provisioning, Autodiscovery, and Signaling in L2VPNs", Eric Rosen, 5-May-06, Provider Provisioned Layer 2 Virtual Private Networks (L2VPNs) may have different "provisioning models", i.e., models for what information needs to be configured in what entities. Once configured, the provisioning information is distributed by a "discovery process". When the discovery process is complete, a signaling protocol is automatically invoked to set up the mesh of Pseudowires (PWs) that form the (virtual) backbone of the L2VPN. This document specifies a number of L2VPN provisioning models, and further specifies the semantic structure of the endpoint identifiers required by each model. It discusses the distribution of these identifiers by the discovery process, especially when discovery is based on the Border Gateway Protocol (BGP). It then specifies how the endpoint identifiers are carried in the two signaling protocols that are used to set up PWs, the Label Distribution Protocol (LDP) and the Layer 2 Tunneling Protocol (L2TPv3). "L2VPN OAM Requirements and Framework", Dinesh Mohan, Ali Sajassi, Simon Delord, Philippe Niger, 14-Jul-08, This draft provides framework and requirements for Layer 2 Virtual Private Networks (L2VPN) Operation, Administration and Maintenance (OAM). The OAM framework is intended to provide OAM layering across L2VPN services, Pseudo Wires (PWs) and Packet Switched Network (PSN) tunnels. The requirements are intended to identify OAM requirement for L2VPN services (i.e. VPLS, VPWS, and IPLS). Furthermore, if L2VPN services OAM requirements impose specific requirements on PWOAM and/or PSN OAM, those specific PW and/or PSN OAM requirements are also identified. "Multicast in VPLS", Rahul Aggarwal, Yuji Kamite, Luyuan Fang, Yakhov Rekhter, 13-Jul-09, This document describes a solution for overcoming a subset of the limitations of existing VPLS multicast solutions. It describes procedures for VPLS multicast that utilize multicast trees in the sevice provider (SP) network. One such multicast tree can be shared between multiple VPLS instances. Procedures by which a single multicast tree in the SP network can be used to carry traffic belonging only to a specified set of one or more IP multicast streams from one or more VPLSes are also described. "VPLS Interoperability with CE Bridges", Dinesh Mohan, Ali Sajassi, 29-Sep-08, One of the main motivations behind VPLS is its ability to provide connectivity not only among customer routers and servers/hosts but also among customer IEEE bridges. VPLS is expected to deliver the same level of service that current enterprise users are accustomed to from their own enterprise bridged networks or their Ethernet Service Providers. When CE devices are IEEE bridges, then there are certain issues and challenges that need to be accounted for in a VPLS network. The majority of these issues have currently been addressed in the IEEE 802.1ad standard for provider bridges and they can be leveraged for VPLS networks. This draft extends the PE model described in RFC 4664 based on IEEE 802.1ad bridge module and illustrates a clear demarcation between IEEE bridge module and IETF LAN emulation module. By doing so, it describes that the majority of interoperability issues with CE bridges can be delegated to 802.1ad bridge module, thus removing the burden on IETF LAN emulation module within a VPLS PE. "Framework and Requirements for Virtual Private Multicast Service (VPMS)", Yuji Kamite, Frederic JOUNAY, Ben Niven-Jenkins, Deborah Brungard, Lizhong Jin, 26-Oct-09, This document provides a framework and service level requirements for Virtual Private Multicast Service (VPMS). VPMS is defined as a Layer 2 VPN service that provides point-to-multipoint connectivity for a variety of Layer 2 link layers across an IP or MPLS-enabled PSN. This document outlines architectural service models of VPMS and states generic and high level requirements. This is intended to aid in developing protocols and mechanisms to support VPMS. "Extensions to VPLS PE model for Provider Backbone Bridging", Ali Sajassi, Florin Balus, Raymond Zhang, 7-Jan-10, IEEE 802.1ah standard [IEEE802.1ah], also known as Provider Backbone Bridges (PBB) defines an architecture and bridge protocols for interconnection of multiple Provider Bridge Networks (PBNs). PBB was defined in IEEE as a connectionless technology based on multipoint VLAN tunnels. MSTP is used as the core control plane for loop avoidance and load balancing. As a result, the coverage of the solution is limited by STP scale in the core of large service provider networks. PBB on the other hand can be used to attain better scalability in terms of number of customer MAC addresses and number of service instances that can be supported. Virtual Private LAN Service (VPLS) [RFC4762] provides a solution for extending Ethernet LAN services, using MPLS tunneling capabilities, through a routed MPLS backbone without running (M)STP across the backbone. As a result, VPLS has been deployed on a large scale in service provider networks. This draft discusses extensions to the VPLS PE model required to incorporate desirable PBB components while maintaining the Service Provider fit of the initial model. "VPLS Interoperability with Provider Backbone Bridges", Ali Sajassi, San Jose, Florin Balus, 19-Oct-09, The scalability of H-VPLS with Ethernet access network can be improved by incorporating Provider Backbone Bridge functionality in VPLS access. Provider Backbone Bridging has been standardized as IEEE 802.1ah-2008, and aims to improve the scalability of MAC addresses and service instances in Provider Ethernet networks. This document describes different interoperability scenarios where Provider Backbone Bridge functionality is used in H-VPLS with Ethernet or MPLS access network to attain better scalability in terms of number of customer MAC addresses and number of service instances. The document also describes the scenarios and the mechanisms for incorporating Provider Backbone Bridge functionality within H-VPLS with existing Ethernet access and interoperability among them. Furthermore, the document discusses the migration mechanisms and scenarios by which Provider Backbone Bridge functionality can be incorporated into H-VPLS with existing MPLS access. "BGP based Multi-homing in Virtual Private LAN Service", Bhupesh Kothari, Kireeti Kompella, Wim Henderickx, Florin Balus, James Uttaro, 20-Nov-09, Virtual Private LAN Service (VPLS) is a Layer 2 Virtual Private Network (VPN) that gives its customers the appearance that their sites are connected via a Local Area Network (LAN). It is often required for the Service Provider (SP) to give the customer redundant connectivity to some sites, often called "multi-homing". This memo shows how BGP-based multi-homing can be offered in the context of LDP and BGP VPLS solutions. "VPLS Interoperability with Provider Backbone Bridges", Ali Sajassi, San Jose, Florin Balus, 5-Jan-10, The scalability of H-VPLS with Ethernet access network can be improved by incorporating Provider Backbone Bridge functionality in VPLS access. Provider Backbone Bridging has been standardized as IEEE 802.1ah-2008, and aims to improve the scalability of MAC addresses and service instances in Provider Ethernet networks. This document describes different interoperability scenarios where Provider Backbone Bridge functionality is used in H-VPLS with Ethernet or MPLS access network to attain better scalability in terms of number of customer MAC addresses and number of service instances. The document also describes the scenarios and the mechanisms for incorporating Provider Backbone Bridge functionality within H-VPLS with existing Ethernet access and interoperability among them. Furthermore, the document discusses the migration mechanisms and scenarios by which Provider Backbone Bridge functionality can be incorporated into H-VPLS with existing MPLS access. Layer 3 Virtual Private Networks (l3vpn) ---------------------------------------- "Multicast in MPLS/BGP IP VPNs", Rahul Aggarwal, Sarveshwar Bandi, Yiqun Cai, Thomas Morin, Yakhov Rekhter, Eric Rosen, IJsbrand Wijnands, Seisho Yasukawa, 30-Nov-09, In order for IP multicast traffic within a BGP/MPLS IP VPN (Virtual Private Network) to travel from one VPN site to another, special protocols and procedures must be implemented by the VPN Service Provider. These protocols and procedures are specified in this document. "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", Rahul Aggarwal, Eric Rosen, Thomas Morin, Yakhov Rekhter, 30-Sep-09, This document describes the BGP encodings and procedures for exchanging the information elements required by Multicast in MPLS/BGP IP VPNs, as specified in [MVPN]. "Requirements for supporting Customer RSVP and RSVP-TE over a BGP/MPLS IP-VPN", Kenji Kumaki, Yuji Kamite, Raymond Zhang, 28-Dec-09, Today, customers expect to run triple play services through BGP/MPLS IP-VPNs. Some Service Providers will deploy services that request QoS guarantees from a local CE to a remote CE across the network. As a result, the application (e.g., voice, video, bandwidth-guaranteed data pipe, etc.) requirements for an end-to- end QOS and reserving an adequate bandwidth continue to increase. Service Providers can use both an MPLS and an MPLS-TE LSP to meet the service objectives. This document describes service provider requirements for supporting a customer RSVP and RSVP-TE over a BGP/MPLS IP-VPN. "OSPFv3 as a PE-CE routing protocol", Padma Pillay-Esnault, Peter Moyer, Jeff Doyle, Emre Ertekin, Michael Lundberg, 23-Nov-09, Many Service Providers (SPs) offer Virtual Private Network (VPN) services to their customers using a technique in which Customer Edge (CE) routers are routing peers of Provider Edge (PE) routers. The Border Gateway Protocol (BGP) is used to distribute the customer's routes across the provider's IP backbone network, and Multiprotocol Label Switching (MPLS) is used to tunnel customer packets across the provider's backbone. This is known as a "BGP/MPLS IP VPN". Originally only IPv4 was supported and it was later extended to support IPv6 VPNs as well. Extensions were later added for the support of the Open Shortest Path First protocol version 2 (OSPFv2) as a PE-CE routing protocol for the IPv4 VPNs. This document extends those specifications to support OSPF version 3 (OSPFv3) as a PE-CE routing protocol. The OSPFv3 PE-CE functionality is identical to that of OSPFv2 except for the differences described in this document. Status of This Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 28, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. "Mandatory Features in a Layer 3 Multicast BGP/MPLS VPN Solution", Thomas Morin, Ben Niven-Jenkins, Yuji Kamite, Raymond Zhang, Nicolai Leymann, Nabil Bitar, 26-Oct-09, More that one set of mechanisms to support multicast in a layer 3 BGP/MPLS VPN has been defined. These are presented in the documents that define them as optional building blocks. To enable interoperability between implementations, this document defines a subset of features that is considered mandatory for a multicast BGP/MPLS VPN implementation. This will help implementers and deployers understand which L3VPN multicast requirements are best satisfied by each option. Low Extra Delay Background Transport (ledbat) --------------------------------------------- "Low Extra Delay Background Transport (LEDBAT)", Stanislav Shalunov, 19-Oct-09, LEDBAT is an alternative experimental congestion control algorithm. LEDBAT enables an advanced networking application to minimize the extra delay it induces in the bottleneck while saturating the bottleneck. It thus implements an end-to-end version of scavenger service. LEDBAT has been been implemented in BitTorrent DNA, as the exclusive congestion control mechanism, and in uTorrent, as an experimental mechanism, and deployed in the wild with favorable results. Locator/ID Separation Protocol (lisp) ------------------------------------- "Locator/ID Separation Protocol (LISP)", Dino Farinacci, Vince Fuller, Dave Meyer, Darrel Lewis, 29-Sep-09, This draft describes a simple, incremental, network-based protocol to implement separation of Internet addresses into Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). This mechanism requires no changes to host stacks and no major changes to existing database infrastructures. The proposed protocol can be implemented in a relatively small number of routers. This proposal was stimulated by the problem statement effort at the Amsterdam IAB Routing and Addressing Workshop (RAWS), which took place in October 2006. "LISP Map Server", Vince Fuller, Dino Farinacci, 6-Oct-09, This draft describes the LISP Map-Server (LISP-MS), a computing system which provides a simple LISP protocol interface as a "front end" to the Endpoint-ID (EID) to Routing Locator (RLOC) mapping database and associated virtual network of LISP protocol elements. The purpose of the Map-Server is to simplify the implementation and operation of LISP Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs), the devices that implement the "edge" of the LISP infrastructure and which connect directly to LISP-capable Internet end sites. "LISP for Multicast Environments", Dino Farinacci, Dave Meyer, John Zwiebel, Stig Venaas, 29-Sep-09, This draft describes how inter-domain multicast routing will function in an environment where Locator/ID Separation is deployed using the LISP architecture. Long-Term Archive and Notary Services (ltans) --------------------------------------------- "Long-term Archive Protocol (LTAP)", Aleksej Jerman-Blazic, Peter Sylvester, Carl Wallace, 13-Jul-09, This document describes a service operated as a trusted third party to securely archive electronic documents called a long-term archive service (LTA). We describe an architecture framework and a protocol allowing clients to interact with such a service. Bindings to concrete transport and security protocol layers are given. "Extensible Markup Language Evidence Record Syntax", A. Jerman Blazic, Svetlana Saljic, Tobias Gondrom, 3-Aug-09, In many scenarios, users must be able to demonstrate the (time) existence, integrity and validity of data including signed data for long or undetermined period of time. This document specifies XML syntax and processing rules for creating evidence for long-term non- repudiation of existence of data. ERS-XML incorporates alternative syntax and processing rules to ASN.1 ERS syntax by using XML language. Mobile Ad-hoc Networks (manet) ------------------------------ "Simplified Multicast Forwarding", Joseph Macker, SMF Team, 13-Jul-09, This document describes a Simplified Multicast Forwarding (SMF) mechanism that provides basic IP multicast forwarding suitable for wireless mesh and mobile ad hoc network (MANET) use. SMF defines techniques for multicast duplicate packet detection (DPD) to be applied in the forwarding process and includes maintenance and checking operations for both IPv4 and IPv6 protocol use. SMF also specifies mechanisms for applying reduced relay sets to achieve more efficient multicast data distribution within a mesh topology versus simple flooding. The document describes interactions with other protocols and multiple deployment approaches. Distributed algorithms for selecting reduced relay sets and related discussion are provided in the Appendices. Basic issues relating to the operation of multicast MANET border routers are discussed but ongoing work remains in this area beyond the scope of this document. "The Optimized Link State Routing Protocol version 2", Thomas Clausen, Christopher Dearlove, Philippe Jacquet, 25-Sep-09, This document describes version 2 of the Optimized Link State Routing (OLSRv2) protocol for Mobile Ad hoc NETworks (MANETs). "Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)", Thomas Clausen, Christopher Dearlove, Justin Dean, 26-Oct-09, This document describes a 1-hop and symmetric 2-hop neighborhood discovery protocol (NHDP) for mobile ad hoc networks (MANETs). "Definition of Managed Objects for the DYMO Manet Routing Protocol", Sean Harnedy, Robert Cole, Ian Chakeres, 25-Oct-09, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring aspects of the DYMO routing process. The DYMO-MIB also reports state information, performance information, and notifications. In addition to configuration, this additional state and performance information is useful to management operators troubleshooting DYMO routing problems. "Definition of Managed Objects for the Manet Simplified Multicast Framework Relay Set Process", Robert Cole, Joseph Macker, Brian Adamson, Sean Harnedy, 26-Oct-09, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring aspects of the Simplified Multicast Forwarding (SMF) process for Mobile Ad-Hoc Networks (MANETs). The SMF-MIB also reports state information, performance metrics, and notifications. In addition to configuration, this additional state and performance information is useful to operators troubleshooting multicast forwarding problems. "Definition of Managed Objects for the Neighborhood Discovery Protocol", Ulrich Herberg, Robert Cole, Ian Chakeres, 11-Nov-09, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring aspects of the Neighborhood Discovery Protocol (NHDP) process on a router. The NHDP MIB also reports state information, performance information and notifications. This additional state and performance information is useful to management stations troubleshooting neighbor discovery problems. Status of This Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 13, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "Definition of Managed Objects for the MANET Optimized Link State Routing Protocol version 2", Ulrich Herberg, Robert Cole, Thomas Clausen, 8-Nov-09, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring and managing aspects of the Optimized Link State Routing protocol version 2. The Optimized Link State Routing MIB also reports state information, performance metrics, and notifications. In addition to configuration, this additional state and performance information is useful to management stations troubleshooting Mobile Ad-Hoc Networks routing problems. Status of This Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 13, 2010.Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. MBONE Deployment (mboned) ------------------------- "IANA Guidelines for IPv4 Multicast Address Assignments", Michelle Cotton, Leo Vegoda, Dave Meyer, 19-Nov-09, This document provides guidance for the Internet Assigned Numbers Authority (IANA) in assigning IPv4 multicast addresses. It obsoletes RFC 3171 and RFC 3138 and updates RFC 2780. "Overview of the Internet Multicast Addressing Architecture", Pekka Savola, 3-Aug-09, The lack of up-to-date documentation on IP multicast address allocation and assignment procedures has caused a great deal of confusion. To clarify the situation, this memo describes the allocation and assignment techniques and mechanisms currently (as of this writing) in use. "Requirements for Multicast AAA coordinated between Content Provider(s) and Network Service Provider(s)", Tsunemasa Hayashi, Haixiang He, Hiroaki Satou, Hiroshi Ohta, Susheela Vaidya, 12-Jul-09, This memo presents requirements in the area of accounting and access control for IP multicasting. The scope of the requirements is limited to cases where Authentication, Accounting and Authorization (AAA) functions are coordinated between Content Provider(s) and Network Service Provider(s). In order to describe the new requirements of a multi-entity Content Deliver System(CDS) using multicast, the memo presents three basic business models: 1) the Content Provider and the Network Provider are the same entity, 2) the Content Provider(s) and the Network Provider(s) are separate entities and users are not directly billed, and 3) the Content Provider(s) and the Network Provider(s) are separate entities and users are billed based on content consumption or subscriptions. The requirements of these three models are listed and evaluated as to which aspects are already supported by existing technologies and which aspects are not. General requirements for accounting and admission control capabilities including quality-of-service (QoS) related issues are listed and the constituent logical functional components are presented. This memo assumes that the capabilities can be realized by integrating AAA functionalities with a multicast CDS system, with IGMP/MLD at the edge of the network. "AAA and Admission Control Framework for Multicasting", Tsunemasa Hayashi, Haixiang He, Hiroaki Satou, Hiroshi Ohta, Christian Jacquenet, 4-Aug-09, IP multicast-based services, such as TV broadcasting or videoconferencing raise the issue of making sure that potential customers are fully entitled to access the corresponding contents. There is indeed a need for service and content providers to identify users (if not authenticate, especially within the context of enforcing electronic payment schemes) and to retrieve statistical information for accounting purposes, as far as content and network usage are concerned. This memo describes the framework for specifying the Authorization, Authentication and Accounting (AAA) capabilities that could be activated within the context of the deployment and the operation of IP multicast-based services. This framework addresses the requirements presented in "Requirements for Accounting, Authentication and Authorization in Well Managed IP Multicasting Services" [I-D.ietf-mboned-maccnt-req]. The memo provides a basic AAA enabled model as well as an extended fully enabled model with resource and admission control coordination. "Lightweight IGMPv3 and MLDv2 Protocols", Hui Liu, Wei Cao, Hitoshi Asaeda, 14-Oct-09, This document describes lightweight IGMPv3 and MLDv2 protocols (LW- IGMPv3 and LW-MLDv2), which simplify the standard (full) versions of IGMPv3 and MLDv2. The interoperability with the full versions and the previous versions of IGMP and MLD is also taken into account. "Mtrace Version 2: Traceroute Facility for IP Multicast", Hitoshi Asaeda, Tatuya Jinmei, Bill Fenner, Stephen Casner, 26-Oct-09, This document describes the IP multicast traceroute facility. Unlike unicast traceroute, multicast traceroute requires special implementations on the part of routers. This specification describes the required functionality in multicast routers, as well as how management applications can use the router functionality. "Requirements for IP Multicast Session Announcement", Hitoshi Asaeda, Vincent Roca, 26-Oct-09, The Session Announcement Protocol (SAP) [2] was used to announce information for all available IP multicast sessions to the prospective receiver in an experimental network. It is easy to use, but not scalable and difficult to control the SAP message transmission in a wide area network. This document describes the issues and the requirements for multicast session announcement in the global Internet. Media Server Control (mediactrl) -------------------------------- "Media Control Channel Framework", Chris Boulton, Tim Melanchuk, Scott McGlashan, 23-Oct-09, This document describes a Framework and protocol for application deployment where the application programming logic and media processing are distributed. This implies that application programming logic can seamlessly gain access to appropriate resources that are not co-located on the same physical network entity. The framework uses the Session Initiation Protocol (SIP) to establish an application-level control mechanism between application servers and associated external servers such as media servers. The motivation for the creation of this Framework is to provide an interface suitable to meet the requirements of a distributed, centralized conference system, as defined by the IETF. It is not, however, limited to this scope and it is envisioned that this generic Framework will be used for a wide variety of de-coupled control architectures between network entities. "An Interactive Voice Response (IVR) Control Package for the Media Control Channel Framework", Scott McGlashan, Tim Melanchuk, Chris Boulton, 25-Nov-09, This document defines a Media Control Channel Framework Package for Interactive Voice Response (IVR) dialog interaction on media connections and conferences. The package defines dialog management request elements for preparing, starting and terminating dialog interactions, as well as associated responses and notifications. Dialog interactions are specified in a dialog language. This package defines a lightweight IVR dialog language (supporting prompt playback, runtime controls, DTMF collect and media recording) and allows other dialog languages to be used. The package also defines elements for auditing package capabilities and IVR dialogs. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 29, 2010.Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. "A Mixer Control Package for the Media Control Channel Framework", Scott McGlashan, Tim Melanchuk, Chris Boulton, 11-Jan-10, This document defines a Media Control Channel Framework Package for managing mixers for media conferences and connections. The package defines request elements for managing conference mixers, managing mixers between conferences and/or connections, as well as associated responses and notifications. The package also defines elements for auditing package capabilities and mixers. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 15, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. "Media Control Channel Framework (CFW) Call Flow Examples", Alessandro Amirante, Tobia Castaldi, Lorenzo Miniero, Simon Romano, 26-Oct-09, This document provides a list of typical Media Control Channel Framework [I-D.ietf-mediactrl-sip-control-framework] call flows. It aims at being a simple guide to the use of the interface between Application Servers and MEDIACTRL-based Media Servers, as well as a base reference documentation for both implementors and protocol researchers. "Media Resource Brokering", Chris Boulton, Lorenzo Miniero, 15-Dec-09, The MediaCtrl work group in the IETF has proposed an architecture for controlling media services. The Session Initiation Protocol (SIP) is used as the signalling protocol which provides many inherent capabilities for message routing. In addition to such signalling properties, a need exists for intelligent, application level media service selection based on non-static signalling properties. This is especially true when considered in conjunction with deployment architectures that include 1:M and M:M combinations of Application Servers and Media Servers. This document introduces a Media Resource Broker (MRB) entity which manages the availability of Media Servers and the media resource demands of Application Servers. The document includes potential deployment options for an MRB and appropriate interfaces to Application Servers and Media Servers. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 18, 2010.Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Mobility EXTensions for IPv6 (mext) ----------------------------------- "Home Agent Reliability Protocol", Ryuji Wakikawa, 13-Jul-09, The home agent can be a single point of failure when Mobile IPv6 is operated in a system. It is critical to provide home agent reliability in the event of a home agent crashing or becoming unavailable. This would allow another home agent to take over and continue providing service to the mobile nodes. This document describes the problem scope briefly and provides a mechanism of home agent failure detection, home agent state transfer, and home agent switching for home agent redundancy and reliability. "Flow Bindings in Mobile IPv6 and NEMO Basic Support", Hesham Soliman, George Tsirtsis, Nicolas Montavont, Gerardo Giaretta, Koojana Kuladinithi, 8-Nov-09, This document introduces extensions to Mobile IPv6 that allow nodes to bind one or more flows to a care-of address. These extensions allow multihomed nodes to instruct home agents and other Mobile IPv6 entities to direct inbound flows to specific addresses. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 13, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "Mobility Support in IPv6", Dave Johnson, Charles Perkins, Jari Arkko, 21-Oct-09, This document specifies a protocol which allows nodes to remain reachable while moving around in the IPv6 Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about the mobile node's current location. IPv6 packets addressed to a mobile node's home address are transparently routed to its care-of address. The protocol enables IPv6 nodes to cache the binding of a mobile node's home address with its care-of address, and to then send any packets destined for the mobile node directly to it at this care-of address. To support this operation, Mobile IPv6 defines a new IPv6 protocol and a new destination option. All IPv6 nodes, whether mobile or stationary, can communicate with mobile nodes. "DHCPv6 Prefix Delegation for NEMO", Ralph Droms, Pascal Thubert, Francis Dupont, Wassim Haddad, 26-Oct-09, One aspect of network mobility support is the assignment of a prefix or prefixes to a Mobile Router (MR) for use on the links in the Mobile Network. DHCPv6 prefix delegation can be used for this configuration task. "Binding Revocation for IPv6 Mobility", Ahmad Muhanna, Mohamed Khalil, Sri Gundavelli, Kuntal Chowdhury, Parviz Yegani, 26-Oct-09, This document defines a binding revocation mechanism to terminate a mobile node's mobility session and the associated resources. These semantics are generic enough and can be used by mobility entities in the case of Mobile IPv6 and its extensions. This mechanism allows the mobility entity which initiates the revocation procedure to request its peer to terminate either one, multiple or all specified binding(s). "Guidelines for firewall administrators regarding MIPv6 traffic", Suresh Krishnan, Niklas Steinleitner, QIU Ying, Gabor Bajko, 26-Oct-09, This document presents some recommendations for firewall administrators to help them configure their existing firewalls in a way that allows in certain deployment scenarios the Mobile IPv6 and DSMIPv6 signaling and data messages to pass through. For other scenarios, the support of additional mechanisms to create pinholes required for MIPv6 will be necessary. This document assumes that the firewalls in question include some kind of stateful packet filtering capability. "Guidelines for firewall vendors regarding MIPv6 traffic", Suresh Krishnan, Yaron Sheffer, Niklas Steinleitner, Gabor Bajko, 26-Oct-09, This document presents some recommendations for firewall vendors to help them implement their firewalls in a way that allows Mobile IPv6 and DSMIPv6 signaling and data messages to pass through. This document describes how to implement stateful packet filtering capability for MIPv6 and DSMIPv6. "Traffic Selectors for Flow Bindings", George Tsirtsis, Gerardo Giaretta, Hesham Soliman, Nicolas Montavont, 16-Dec-09, This document defines binary formats for IPv4 and IPv6 traffic selectors to be used in conjunction with flow bindings for Mobile IPv6. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 19, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Multiple Interfaces (mif) ------------------------- "Current Practices for Multiple Interface Hosts", Margaret Wasserman, 19-Oct-09, An increasing number of hosts are operating in multiple-interface environments, where different network interfaces are providing unequal levels of service or connectivity. This document summarizes current practices in this area, and describes in detail how some common operating systems cope with these challenges. "Multiple Interfaces Problem Statement", Marc Blanchet, Pierrick Seite, 26-Oct-09, A multihomed host receives node configuration information from each of its provisioning domain. Some configuration objects are global to the node, some are local to the interface. Various issues arise when multiple conflicting node-scoped configuration objects are received on multiple interfaces. Similar situations also happen with single interface host connected to multiple networks. This document describes these issues. Mobility for IPv4 (mip4) ------------------------ "IP Mobility Support for IPv4, revised", Charles Perkins, 7-Oct-09, This document specifies protocol enhancements that allow transparent routing of IP datagrams to mobile nodes in the Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about its current point of attachment to the Internet. The protocol provides for registering the care-of address with a home agent. The home agent sends datagrams destined for the mobile node through a tunnel to the care-of address. After arriving at the end of the tunnel, each datagram is then delivered to the mobile node. "Generic Notification Message for Mobile IPv4", Hui Deng, Henrik Levkowetz, Vijay Devarapalli, Sri Gundavelli, Brian Haley, 10-Sep-09, This document specifies protocol enhancements that allow Mobile IPv4 entities to send and receive explicit notification messages using a new Mobile IPv4 message type designed for this purpose. "Dynamic Prefix Allocation for NEMOv4", George Tsirtsis, Vincent Park, Vidya Narayanan, Kent Leung, 8-Nov-09, The base NEMOv4 specification defines extensions to Mobile IPv4 for mobile networks. This specification defines a dynamic prefix allocation mechanism. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 12, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Mobility for IPv6 (mip6) ------------------------ "Using IPsec between Mobile and Correspondent IPv6 Nodes", Francis Dupont, Jean-Michel Combes, 25-Aug-08, Mobile IPv6 uses IPsec to protect signaling between the Mobile Node and the Home Agent. This document defines how IPsec can be used between the Mobile Node and Correspondent Nodes for Home Address Option validation and protection of mobility signaling for Route Optimization. The configuration details for IPsec and IKE are also provided. "MIP6-bootstrapping for the Integrated Scenario", Kuntal Chowdhury, Alper Yegin, 21-Apr-08, Mobile IPv6 bootstrapping can be categorized into two primary scenarios, the split scenario and the integrated scenario. In the split scenario, the mobile node's mobility service is authorized by a different service authorizer than the network access authorizer. In the integrated scenario, the mobile node's mobility service is authorized by the same service authorizer as the network access service authorizer. This document defines a method for home agent information discovery for the integrated scenario. "DHCP Options for Home Information Discovery in MIPv6", Hee-Jin Jang, Alper Yegin, Kuntal Chowdhury, JinHyeock Choi, 22-May-08, This draft defines a DHCP-based scheme to enable dynamic discovery of Mobile IPv6 home network information. New DHCP options are defined which allow a mobile node to request the home agent IP address, FQDN, or home network prefix and obtain it via the DHCP response. Mobility for IP: Performance, Signaling and Handoff Optimization (mipshop) -------------------------------------------------------------------------- "Fast Handovers for Proxy Mobile IPv6", Hidetoshi Yokota, Kuntal Chowdhury, Rajeev Koodli, Basavaraj Patil, Frank Xia, 28-Dec-09, Mobile IPv6 (MIPv6) [RFC3775] provides a mobile node with IP mobility when it performs a handover from one access router to another and fast handovers for Mobile IPv6 (FMIPv6) [RFC5568] are specified to enhance the handover performance in terms of latency and packet loss. While MIPv6 (and FMIPv6 as well) requires the participation of the mobile node in the mobility-related signaling, Proxy Mobile IPv6 (PMIPv6) [RFC5213] provides IP mobility to mobile nodes that either have or do not have MIPv6 functionality without such involvement. Nevertheless, the basic performance of PMIPv6 in terms of handover latency and packet loss is considered not any different from that of MIPv6. When the fast handover is considered in such an environment, several modifications are needed to FMIPv6 to adapt to the network-based mobility management. This document specifies the usage of Fast Mobile IPv6 (FMIPv6) when Proxy Mobile IPv6 is used as the mobility management protocol. Necessary extensions are specified for FMIPv6 to support the scenario when the mobile node does not have IP mobility functionality and hence is not involved with either MIPv6 or FMIPv6 operations. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 1, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. "Transient Binding for Proxy Mobile IPv6", Marco Liebsch, Ahmad Muhanna, Oliver Blume, 21-Sep-09, This document specifies a mechanism which enhances Proxy Mobile IPv6 protocol signaling to support the creation of a transient binding cache entry which is used to optimize the performance of dual radio handover, as well as single radio handover. This mechanism is applicable to the mobile node's inter-MAG handover while using a single interface or different interfaces. The handover problem space using the Proxy Mobile IPv6 base protocol is analyzed and the use of transient binding cache entries at the local mobility anchor is described. The specified extension to the Proxy Mobile IPv6 protocol ensures optimized forwarding of downlink as well as uplink packets between mobile nodes and the network infrastructure and avoids superfluous packet forwarding delay or even packet loss. Multiparty Multimedia Session Control (mmusic) ---------------------------------------------- "Real Time Streaming Protocol 2.0 (RTSP)", Henning Schulzrinne, Anup Rao, Rob Lanphier, Magnus Westerlund, Martin Stiemerling, 13-Jul-09, This memorandum defines RTSP version 2.0 which obsoletes RTSP version 1.0 which is defined in RFC 2326. The Real Time Streaming Protocol, or RTSP, is an application-level protocol for setup and control of the delivery of data with real-time properties. RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and video. Sources of data can include both live data feeds and stored clips. This protocol is intended to control multiple data delivery sessions, provide a means for choosing delivery channels such as UDP, multicast UDP and TCP, and provide a means for choosing delivery mechanisms based upon RTP (RFC 3550). "A Network Address Translator (NAT) Traversal mechanism for media controlled by Real-Time Streaming Protocol (RTSP)", Jeff Goldberg, Magnus Westerlund, Thomas Zeng, 13-Jul-09, This document defines a solution for Network Address Translation (NAT) traversal for datagram based media streams setup and controlled with Real-time Streaming Protocol version 2 (RTSP 2.0). It uses Interactive Connectivity Establishment (ICE) adapted to use RTSP as a signalling channel, defining the necessary extra RTSP extensions and procedures. "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", Jonathan Rosenberg, 29-Oct-07, This document describes a protocol for Network Address Translator (NAT) traversal for UDP-based multimedia sessions established with the offer/answer model. This protocol is called Interactive Connectivity Establishment (ICE). ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN). ICE can be used by any protocol utilizing the offer/answer model, such as the Session Initiation Protocol (SIP). "An Extension to the Session Description Protocol (SDP) for Media Loopback", C Sivachelvan, Nagarjuna Venna, Paul Jones, Nathan Stratton, Arjun Roychowdhury, Kaynam Hedayat, 7-Oct-09, The wide deployment of Voice over IP (VoIP), Real-time Text and Video over IP services has introduced new challenges in managing and maintaining voice/real-time Text/video quality, reliability, and overall performance. In particular, media delivery is an area that needs attention. One method of meeting these challenges is monitoring the media delivery performance by looping media back to the transmitter. This is typically referred to as "active monitoring" of services. Media loopback is especially popular in ensuring the quality of transport to the edge of a given VoIP, Real-time Text or Video over IP service. Today in networks that deliver real-time media, short of running 'ping' and 'traceroute' to the edge, service providers are left without the necessary tools to actively monitor, manage, and diagnose quality issues with their service. The extension defined herein adds new SDP media attributes which enables establishment of media sessions where the media is looped back to the transmitter. Such media sessions will serve as monitoring and troubleshooting tools by providing the means for measurement of more advanced VoIP, Real-time Text and Video Over IP performance metrics. "Connectivity Preconditions for Session Description Protocol Media Streams", Flemming Andreasen, Gonzalo Camarillo, David Oran, Dan Wing, 9-Mar-09, This document defines a new connectivity precondition for the Session Description Protocol (SDP) precondition framework. A connectivity precondition can be used to delay session establishment or modification until media stream connectivity has been successfully verified. The method of verification may vary depending on the type of transport used for the media. For unreliable datagram transports such as UDP, verification involves probing the stream with data or control packets. For reliable connection-oriented transports such as TCP, verification can be achieved simply by successful connection establishment or by probing the connection with data or control packets, depending on the situation. "TCP Candidates with Interactive Connectivity Establishment (ICE)", Simon Perreault, Jonathan Rosenberg, 13-Oct-09, Interactive Connectivity Establishment (ICE) defines a mechanism for NAT traversal for multimedia communication protocols based on the offer/answer model of session negotiation. ICE works by providing a set of candidate transport addresses for each media stream, which are then validated with peer-to-peer connectivity checks based on Session Traversal Utilities for NAT (STUN). ICE provides a general framework for describing candidates, but only defines UDP-based transport protocols. This specification extends ICE to TCP-based media, including the ability to offer a mix of TCP and UDP-based candidates for a single stream. "SDP Capability Negotiation", Flemming Andreasen, 19-May-09, The Session Description Protocol (SDP) was intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. SDP was not intended to provide capability indication or capability negotiation, however over the years, SDP has seen widespread adoption and as a result it has been gradually extended to provide limited support for these, notably in the form of the offer/answer model defined in RFC 3264. SDP does not define how to negotiate one or more alternative transport protocols (e.g. RTP profiles) or attributes. This makes it difficult to deploy new RTP profiles such as secure RTP or RTP with RTCP-based feedback, negotiate use of different security keying mechanisms, etc. It also presents problems for some forms of media negotiation. The purpose of this document is to address these shortcomings by extending SDP with capability negotiation parameters and associated offer/answer procedures to use those parameters in a backwards compatible manner. The document defines a general SDP Capability Negotiation framework. It also specifies how to provide attributes and transport protocols as capabilities and negotiate them using the framework. Extensions for other types of capabilities (e.g. media types and media formats) may be provided in other documents. "The SDP (Session Description Protocol) Grouping Framework", Gonzalo Camarillo, Henning Schulzrinne, 10-Nov-09, In this specification, we define a framework to group "m" lines in SDP (Session Description Protocol) for different purposes. This framework uses the "group" and "mid" SDP attributes, both of which are defined in this specification. Additionally, we specify how to use the framework for two different purposes: for lip synchronization and for receiving a media flow consisting of several media streams on different transport addresses. This document obsoletes RFC 3388. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 15, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "Forward Error Correction Grouping Semantics in Session Description Protocol", Ali Begen, 19-Oct-09, The Session Description Protocol (SDP) supports grouping media lines. SDP also has semantics defined for grouping the associated source and Forward Error Correction (FEC)-based repair flows. However, the semantics that was defined in RFC 4756 generally fail to provide the specific grouping relationships between the source and repair flows when there are more than one source and/or repair flows in the same group. Furthermore, the existing semantics does not support describing additive repair flows. This document addresses these issues by introducing new FEC grouping semantics. SSRC-level grouping semantics is also introduced in this document for Real-time Transport Protocol (RTP) streams using SSRC multiplexing. "Negotiation of Generic Image Attributes in SDP", Ingemar Johansson, Kyunghun Jung, 18-Oct-09, This document proposes a new generic session setup attribute to make it possible to negotiate different image attributes such as image size. A possible use case is to make it possible for a low-end hand- held terminal to display video without the need to rescale the image, something that may consume large amounts of memory and processing power. The draft also helps to maintain an optimal bitrate for video as only the image size that is desired by the receiver is transmitted. "Session Description Protocol (SDP) Extension For Setting Up Audio and Video Media Streams Over Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN)", Miguel Garcia-Martin, Simo Veikkolainen, 23-Oct-09, This memo describes use cases, requirements, and protocol extensions for using the Session Description Protocol (SDP) Offer/Answer model for establishing audio and video media streams over circuit-switched bearers in the Public Switched Telephone Network (PSTN). Message Organization (morg) --------------------------- "Display-based Address Sorting for the IMAP4 SORT Extension", Dan Karp, 18-Oct-09, This document describes an IMAP protocol extension enabling server- side message sorting based on the commonly-displayed portion of the From and To header fields. "IMAP4 Extension for returning STATUS information in extended LIST", Alexey Melnikov, Timo Sirainen, 13-May-09, Many IMAP clients display information about total number of messages/ total number of unseen messages in IMAP mailboxes. In order to do that they are forced to issue a LIST or LSUB command, to list all available mailboxes, followed by a STATUS command for each mailbox found. This document provides an extension to LIST command that allows the client to request STATUS information for mailboxes together with other information typically returned by the LIST command. Note A revised version of this draft document will be submitted to the RFC editor as a Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested, and should be sent to morg@ietf.org. Multiprotocol Label Switching (mpls) ------------------------------------ "MPLS Traffic Engineering Soft Preemption", Denver Maddux, Curtis Villamizar, Amir Birjandi, and Swallow, JP Vasseur, 29-Jul-09, This document specifies Multiprotocol Label Switching (MPLS) Traffic Engineering Soft Preemption, a suite of protocol modifications extending the concept of preemption with the goal of reducing/ eliminating traffic disruption of preempted Traffic Engineering Label Switched Paths (TE LSPs). Initially MPLS RSVP-TE was defined supporting only immediate TE LSP displacement upon preemption. The utilization of a reroute request notification helps more gracefully mitigate the re-route process of preempted TE LSP. For the brief period soft preemption is activated, reservations (though not necessarily traffic levels) are in effect under-provisioned until the TE LSP(s) can be re-routed. For this reason, the feature is primarily but not exclusively interesting in MPLS enabled IP networks with Differentiated Services and Traffic Engineering capabilities. "Detecting Data Plane Failures in Point-to-Multipoint Multiprotocol Label Switching (MPLS) - Extensions to LSP Ping", Seisho Yasukawa, Adrian Farrel, Zafar Ali, George Swallow, Thomas Nadeau, Shaleen Saxena, 14-Dec-09, Recent proposals have extended the scope of Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) to encompass point-to-multipoint (P2MP) LSPs. The requirement for a simple and efficient mechanism that can be used to detect data plane failures in point-to-point (P2P) MPLS LSPs has been recognized and has led to the development of techniques for fault detection and isolation commonly referred to as "LSP Ping". The scope of this document is fault detection and isolation for P2MP MPLS LSPs. This documents does not replace any of the mechanisms of LSP Ping, but clarifies their applicability to MPLS P2MP LSPs, and extends the techniques and mechanisms of LSP Ping to the MPLS P2MP environment.Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. "Component Link Recording and Resource Control for TE Link Bundles", Zafar Ali, Dimitri Papadimitriou, 17-Nov-09, Record Route is a useful administrative tool that has been used extensively by the service providers. However, when TE links are bundled, identification of label resource in Record Route Object (RRO) is not enough for the administrative purpose. Network service A.Zamfir et al. - Expires May 2010 [page 1] Component Link Record. & Resource Control for TE Link Bundles providers would like to know the component link within a TE link that is being used by a given LSP. In other words, when link bundling is used, resource recording requires mechanisms to specify the component link identifier, along with the TE link identifier and Label. As it is not possible to record component link in the RRO, this draft defines the extensions to RSVP-TE [RFC3209] and [RFC3473] to specify component link identifiers for resource recording purposes. This draft also defines the Explicit Route Object (ERO) counterpart of the RRO extension. The ERO extensions are needed to perform explicit label/ resource control over bundled TE link. Hence, this document defines the extensions to RSVP-TE [RFC3209] and [RFC3473] to specify component link identifiers for explicit resource control and recording over TE link bundles. "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", Ina Minei, Kireeti Kompella, IJsbrand Wijnands, Bob Thomas, 26-Oct-09, This document describes extensions to the Label Distribution Protocol (LDP) for the setup of point to multi-point (P2MP) and multipoint-to- multipoint (MP2MP) Label Switched Paths (LSPs) in Multi-Protocol Label Switching (MPLS) networks. These extensions are also referred to as mLDP Multicast LDP. mLDP constructs the P2MP or MP2MP LSPs without interacting with or relying upon any other multicast tree construction protocol. Protocol elements and procedures for this solution are described for building such LSPs in a receiver-initiated manner. There can be various applications for P2MP/MP2MP LSPs, for example IP multicast or support for multicast in BGP/MPLS L3VPNs. Specification of how such applications can use a LDP signaled P2MP/ MP2MP LSP is outside the scope of this document. "MPLS Upstream Label Assignment for RSVP-TE", Rahul Aggarwal, Jean-Louis Le Roux, 12-Jul-09, This document describes procedures for distributing upstream-assigned labels for Resource Reservation Protocol - Traffic Engineering (RSVP- TE). It also describes how these procedures can be used for avoiding branch LSR traffic replication on a LAN for RSVP-TE point-to- multipoint (P2MP)LSPs. "MPLS Upstream Label Assignment for LDP", Rahul Aggarwal, Jean-Louis Le Roux, 12-Jul-09, This document describes procedures for distributing upstream-assigned labels for Label Distribution Protocol (LDP). It also describes how these procedures can be used for avoiding branch LSR traffic replication on a LAN for LDP point-to-multipoint (P2MP)LSPs. "Point-to-Multipoint Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB) module", Adrian Farrel, Seisho Yasukawa, Thomas Nadeau, 17-Apr-09, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for point-to-multipoint (P2MP) Multiprotocol Label Switching (MPLS) based traffic engineering (TE). The MIB module defined in this document is applicable to P2MP MPLS-TE by extensions to the MPLS-TE MIB module defined in RFC 3812. It is equally applicable to P2MP Generalized MPLS (GMPLS) in association with the GMPLS TE MIB module defined in RFC 4802. "LDP Typed Wildcard FEC", Ina Minei, Bob Thomas, Rajiv Asati, 5-Sep-09, The LDP specification [RFC5036] for the Wildcard FEC element has several deficiencies. This document corrects those deficiencies. In addition, it specifies the Typed Wildcard FEC for the Prefix FEC Element Type defined in RFC5036. "Node behavior upon originating and receiving Resource ReserVation Protocol (RSVP) Path Error message", JP Vasseur, George Swallow, Ina Minei, 28-Sep-09, The aim of this document is to describe a common practice with regard to the behavior of a node sending a Resource ReserVation Protocol (RSVP) Traffic Engineering (TE) Path Error message and to the behavior of a node receiving an RSVP Path Error message for a preempted Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label Switched Path (TE LSP). This document does not define any new protocol extensions. "Security Framework for MPLS and GMPLS Networks", Luyuan Fang, Michael Behringer, 25-Oct-09, This document provides a security framework for Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) Networks. This document addresses the security aspects that are relevant in the context of MPLS and GMPLS. It describes the security threats, the related defensive techniques, and the mechanisms for detection and reporting. This document emphasizes RSVP-TE and LDP security considerations, as well as Inter-AS and Inter-provider security considerations for building and maintaining MPLS and GMPLS networks across different domains or different Service Providers. "Non PHP Behavior and out-of-band mapping for RSVP-TE LSPs", Zafar Ali, George Swallow, 26-Oct-09, There are many deployment scenarios which require Egress LSR to receive binding of the RSVP-TE LSP to an application, and payload identification, using some "out-of-band" (OOB) mechanism. This document proposes protocol mechanisms to address this requirement. The procedures described in this document are equally applicable for point-to-point (P2P) and point-to- multipoint (P2MP) LSPs. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. "Mechanism for performing LSP-Ping over MPLS tunnels", Nitin Bahadur, Kireeti Kompella, George Swallow, 23-Oct-09, This document describes methods for performing lsp-ping traceroute over mpls tunnels and for traceroute of stitched mpls LSPs. The techniques outlined in RFC 4379 are insufficient to perform traceroute FEC validation and path discovery for a LSP that goes over other mpls tunnels or for a stitched LSP. This document describes enhancements to the downstream-mapping TLV (defined in RFC 4379). These enhancements along with other procedures outlined in this document can be used to trace such LSPs. "Signaling LDP Label Advertisement Completion", Rajiv Asati, Pradosh Mohapatra, Bob Thomas, Emily Chen, 28-Aug-09, There are situations following Label Distribution Protocol (LDP) session establishment where it would be useful for an LDP speaker to know when its peer has advertised all of its labels. The LDP specification provides no mechanism for an LDP speaker to notify a peer when it has completed its initial label advertisements to that peer. This document specifies means for an LDP speaker to signal completion of its initial label advertisements following session establishment. "PathErr Message Triggered MPLS and GMPLS LSP Reroute", Lou Berger, Dimitri Papadimitriou, JP Vasseur, 24-Sep-09, This document describes how Resource ReserVation Protocol (RSVP) PathErr Messages may be used to trigger rerouting of Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) point-to-point Traffic Engineering (TE) Label Switched Paths (LSPs) without first removing LSP state or resources. Such LSP rerouting may be desirable in a number of cases including, for example, soft-preemption and graceful shutdown. This document describes the usage of existing Standards Track mechanisms to support LSP rerouting. In this case, it relies on mechanisms already defined as part of RSVP-TE and simply describes a sequence of actions to be executed. While existing protocol definition can be used to support reroute applications, this document also defines a new reroute-specific error code to allow for the future definition of reroute application-specific error values. "A Framework for MPLS in Transport Networks", Matthew Bocci, Stewart Bryant, Dan Frost, Lieven Levrau, Lou Berger, 22-Dec-09, This document specifies an architectural framework for the application of Multiprotocol Label Switching (MPLS) to the construction of packet-switched equivalents of traditional circuit- switched carrier networks. It describes a common set of protocol functions - the MPLS Transport Profile (MPLS-TP) - that supports the operational models and capabilities typical of such networks, including signaled or explicitly provisioned bi-directional connection-oriented paths, protection and restoration mechanisms, comprehensive Operations, Administration and Maintenance (OAM) functions, and network operation in the absence of a dynamic control plane or IP forwarding support. Some of these functions are defined in existing MPLS specifications, while others require extensions to existing specifications to meet the requirements of the MPLS-TP. This document defines the subset of the MPLS-TP applicable in general and to point-to-point paths. The remaining subset, applicable specifically to point-to-multipoint paths, are out of scope of this document. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications Union Telecommunications Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. Status of This Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 25, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "Requirements for OAM in MPLS Transport Networks", Martin Vigoureux, David Ward, Malcolm Betts, 16-Dec-09, This document lists architectural and functional requirements for the Operations, Administration and Maintenance of MPLS Transport Profile. These requirements apply to pseudowires, Label Switched Paths, and Sections. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 19, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "Requirements for Label Edge Router Forwarding of IPv4 Option Packets", William Jaeger, John Mullooly, Tom Scholl, David Smith, 6-Jan-10, This document imposes a new requirement on Label Edge Routers (LER) specifying that when determining whether to MPLS encapsulate an IP packet, the determination is made independent of any IP options that may be carried in the IP packet header. Lack of a formal standard has resulted in different LER forwarding behaviors for IP packets with header options despite being associated with a prefix-based Forwarding Equivalence Class (FEC). IP option packets that belong to a prefix-based FEC but fail to be MPLS encapsulated simply due to their header options present a security risk against the MPLS infrastructure. Further, LERs that are unable to MPLS encapsulate IP packets with header options cannot operate in certain MPLS environments. This new requirement will reduce the risk of IP options-based security attacks against LSRs as well as assist LER operation across MPLS networks which minimize the IP routing information carried by LSRs. "MPLS TP Network Management Requirements", Scott Mansfield, Kam Lam, 22-Oct-09, This document specifies the requirements for the management of equipment used in networks supporting an MPLS Transport Profile (MPLS-TP). The requirements are defined for specification of network management aspects of protocol mechanisms and procedures that constitute the building blocks out of which the MPLS transport profile is constructed. That is, these requirements indicate what management capabilities need to be available in MPLS for use in managing the MPLS-TP. This document is intended to identify essential network management capabilities, not to specify what functions any particular MPLS implementation supports. Gray, et al Expires April, 2010 [page 1] Internet-Draft MPLS-TP NM Requirements October, 2009 "MPLS-TP OAM Framework", David Allan, Italo Busi, Ben Niven-Jenkins, 10-Dec-09, Multi-Protocol Label Switching (MPLS) Transport Profile (MPLS-TP) is based on a profile of the MPLS and pseudowire (PW) procedures as specified in the MPLS Traffic Engineering (MPLS-TE), pseudowire (PW) and multi-segment PW (MS-PW) architectures complemented with additional Operations, Administration and Maintenance (OAM) procedures for fault, performance and protection-switching management for packet transport applications that do not rely on the presence of a control plane. This document describes a framework to support a comprehensive set of OAM procedures that fulfills the MPLS-TP OAM requirements [12]. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications Union Telecommunications Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network. "Multiprotocol Label Switching Transport Profile Survivability Framework", Nurit Sprecher, Adrian Farrel, 9-Nov-09, Network survivability is the ability of a network to restore traffic delivery following disruption or failure of network resources. Survivability is critical to the delivery of guaranteed network services such as those subject to strict Service Level Agreements (SLAs) that place maximum bounds on the length of time the service may be degraded or unavailable. The Transport Profile of Multiprotocol Label Switching (MPLS-TP) is a packet transport technology based on the MPLS data plane and re-using many aspects of the MPLS management and control planes. This document provides a framework for the provision of survivability in an MPLS-TP network, describing recovery elements, types, methods and topological considerations. Survivability may be supported by control plane, management plane, and by Operations, Administration and Maintenance (OAM) functions to achieve data plane recovery. This document describes mechanisms for protecting MPLS-TP Label Switched Paths (LSPs). Detailed consideration for the protection of pseudowires in MPLS-TP networks is out of scope. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications Union Telecommunications Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 13, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. "MPLS-TP Network Management Framework", Scott Mansfield, Eric Gray, Hing-Kam Lam, 16-Nov-09, This document provides the network management framework for the Transport Profile for Multi-Protocol Label Switching (MPLS-TP). This framework relies on the management terminology from the ITU-T to describe the management architecture that could be used for an MPLS-TP management network. The management of the MPLS-TP network could be based on multi-tiered distributed management systems. This document provides a description of the network and element management architectures that could be applied and also describes heuristics associated with fault, configuration, and performance aspects of the management system. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network. This Informational Internet-Draft is aimed at achieving IETF Consensus before publication as an RFC and will be subject to an IETF Last Call. [RFC Editor, please remove this note before publication as an RFC and insert the correct Streams Boilerplate to indicate that the published RFC has IETF Consensus.] Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 20, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "A Thesaurus for the Terminology used in Multiprotocol Label Switching Transport Profile (MPLS-TP) drafts/RFCs and ITU-T's Transport Network Recommendations", Huub Helvoort, Loa Andersson, Nurit Sprecher, 26-Oct-09, MPLS-TP is based on a profile of the MPLS and PW procedures as specified in the MPLS-TE and (MS-)PW architectures developed by the IETF. The ITU-T has specified a Transport Network architecture. This document provides a thesaurus for the interpretation of MPLS-TP terminology within the context of the ITU-T Transport Network recommendations. It is important to note that MPLS-TP is applicable in a wider set of contexts than just Transport Networks. The definitions presented in this document do not provide exclusive nor complete interpretations of MPLS-TP concepts. This document simply allows the MPLS-TP terms to be applied within the Transport Network context. "IETF Multi-Protocol Label Switching (MPLS) Transport Profile (MPLS-TP) Document Process", Loa Andersson, David Ward, Malcolm Betts, Adrian Farrel, 24-Nov-09, The decision to develop a Multiprotocol Label Switching (MPLS) Transport Profile (MPLS-TP) in cooperation between the IETF and the ITU-T is document in RFC 5317 as the decision of the Joint Working Team on MPLS-TP. This document provides additional detail of the processes for the development of IETF RFCs on MPLS-TP. It provides an adaptation of the IETF working group process; identifies the expected participation in the process by the ITU-T; and clarifies the rules and conventions regarding MPLS-TP documents. This document does not specify any ITU-T process; ITU-T activities will be done according to ITU-T process/rules. This document does not specify or modify the normal IETF working group process. It is limited to the specific adaptations of that process to facilitate the cooperation agreement between the IETF and the ITU-T on MPLS-TP, and to ensure a good and consistent document review across the two organizations. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network. "MPLS-TP OAM Analysis", Nurit Sprecher, Huub Helvoort, Elisa Bellagamba, Yaacov Weingarten, 8-Nov-09, This document analyzes the set of requirements for Operations, Administration, and Maintenance (OAM) for the Transport Profile of MPLS(MPLS-TP) as defined in [MPLS-TP OAM Reqs], to evaluate whether existing OAM tools (either from the current MPLS toolset or from the ITU-T documents) can be applied to these requirements. Eventually, the purpose of the document is to recommend which of the existing tools should be extended and what new tools should be defined to support the set of OAM requirements for MPLS-TP. This document reports the conclusions of the MPLS-TP design team discussions concerning the MPLS-TP OAM tools at IETF75. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 13, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. "MPLS-TP Identifiers", Matthew Bocci, George Swallow, 9-Nov-09, This document specifies identifiers for MPLS-TP objects. Included are identifiers conformant to existing ITU conventions and identifiers which are compatible with existing IP, MPLS, GMPLS, and Pseudowire definitions. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 14, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "LDP IGP Synchronization for broadcast networks", Wenhu Lu, Sriganesh Kini, 10-Nov-09, [LDP-IGP-SYNC] describes a mechanism to prevent black-holing traffic (e.g. VPN) when IGP is operational on a link but LDP is not. If this mechanism is applied to broadcast links that have more than one LDP/IGP peer, the cost-out procedure can only be applied to the link as a whole but not an individual peer. When a new LDP peer comes up on a broadcast network, this can result in loss of traffic through other established peers on that network. This document describes a mechanism to address that use-case without dropping traffic. The mechanism does not introduce any protocol changes. Multicast Security (msec) ------------------------- "Use of TESLA in the ALC and NORM Protocols", Vincent Roca, Aurelien Francillon, Sebastien Faurite, 26-Oct-09, This document details the TESLA packet source authentication and packet integrity verification protocol and its integration within the ALC and NORM content delivery protocols. This document only considers the authentication/integrity verification of the packets generated by the session's sender. The authentication and integrity verification of the packets sent by receivers, if any, is out of the scope of this document. "Using Counter Modes with Encapsulating Security Payload (ESP) and Authentication Header (AH) to Protect Group Traffic", David McGrew, Brian Weis, 25-Nov-09, Advanced Encryption Standard (AES) counter modes use a counter, which is typically assumed to be incremented by a single sender. This memo describes the use of AES counter modes when applied to the Encapsulating Security Payload (ESP) and Authentication Header (AH) in multiple-sender group applications. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 28, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Network Endpoint Assessment (nea) --------------------------------- "PB-TNC: A Posture Broker Protocol (PB) Compatible with TNC", Ravi Sahita, Stephen Hanna, Kaushik Narayan, 25-Oct-09, This document specifies PB-TNC, a Posture Broker Protocol identical to the Trusted Computing Group's IF-TNCCS 2.0 protocol. The document then evaluates PB-TNC against the requirements defined in the NEA Requirements specification. "PA-TNC: A Posture Attribute Protocol (PA) Compatible with TNC", Kaushik Narayan, Paul Sangster, 23-Oct-09, This document specifies PA-TNC, a Posture Attribute Protocol identical to the Trusted Computing Group's IF-M 1.0 protocol. The document then evaluates PA-TNC against the requirements defined in the NEA Requirements specification. Network Configuration (netconf) ------------------------------- "YANG Module for NETCONF Monitoring", Mark Scott, Martin Bjorklund, 30-Nov-09, This document defines a NETCONF data model to be used to monitor the NETCONF protocol. The monitoring data model includes information about NETCONF datastores, sessions, locks and statistics. This data facilitates the management of a NETCONF server. This document also defines methods for NETCONF clients to discover data models supported by a NETCONF server and defines a new NETCONF operation to retrieve them. "With-defaults capability for NETCONF", Andy Bierman, Balazs Lengyel, 22-Oct-09, The NETCONF protocol defines ways to read configuration data from a NETCONF server. Part of this data is not set by the NETCONF client, but rather a default value is used. In many situations the NETCONF client has a priori knowledge about default data, so the NETCONF server does not need to send it to the client. In other situations the NETCONF client will need this data as part of the NETCONF messages. This document defines a capability-based extension to the NETCONF protocol that allows the NETCONF client to control whether default values are part of NETCONF messages or output to the target URL. "NETCONF Configuration Protocol", Rob Enns, Martin Bjorklund, Juergen Schoenwaelder, Andy Bierman, 13-Jul-09, The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized on top of a simple Remote Procedure Call (RPC) layer. "Using the NETCONF Configuration Protocol over Secure Shell (SSH)", Margaret Wasserman, Ted Goddard, 28-Dec-09, This document describes a method for invoking and running the NETCONF protocol within a Secure Shell (SSH) session as an SSH subsystem. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 1, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Network-Based Mobility Extensions (netext) ------------------------------------------ "PMIPv6 Localized Routing Problem Statement", Marco Liebsch, Sangjin Jeong, Wenson Wu, 26-Oct-09, Proxy Mobile IPv6 is the IETF standard for network-based mobility management. In Proxy Mobile IPv6, mobile nodes are topologically anchored at a Local Mobility Anchor, which forwards all data for registered mobile nodes. The set up and maintenance of localized routing, which allows forwarding of data packets between mobile nodes and correspondent nodes directly without involvement of the Local Mobility Anchor in forwarding, is not considered. This document describes the problem space of localized routing in Proxy Mobile IPv6. "Runtime LMA Assignment Support for Proxy Mobile IPv6", Jouni Korhonen, Sri Gundavelli, Hidetoshi Yokota, Xiangsong Cui, 19-Oct-09, This document describes a redirect functionality and corresponding mobility options for Proxy Mobile IPv6. The redirect functionality allows a dynamic runtime assignment of a Local Mobility Anchor and redirecting the mobility session to the assigned Local Mobility Anchor. Network-based Localized Mobility Management (netlmm) ---------------------------------------------------- "IPv4 Support for Proxy Mobile IPv6", Ryuji Wakikawa, Sri Gundavelli, 12-Sep-09, This document specifies extensions to Proxy Mobile IPv6 protocol for adding IPv4 protocol support. The scope of IPv4 protocol support is two-fold: 1) enable IPv4 home address mobility support to the mobile node. 2) allowing the mobility entities in the Proxy Mobile IPv6 domain to exchange signaling messages over an IPv4 transport network. "GRE Key Option for Proxy Mobile IPv6", Ahmad Muhanna, Mohamed Khalil, Sri Gundavelli, Kent Leung, 5-May-09, This specification defines a new Mobility Option for allowing the mobile access gateway and the local mobility anchor to negotiate GRE (Generic Routing Encapsulation) encapsulation mode and exchange the downlink and uplink GRE keys which are used for marking the downlink and uplink traffic that belong to a specific mobility session. In addition, the same mobility option can be used to negotiate the GRE encapsulation mode without exchanging the GRE keys. "Heartbeat Mechanism for Proxy Mobile IPv6", Vijay Devarapalli, Rajeev Koodli, Heeseon Lim, Nishi Kant, Suresh Krishnan, Julien Laganier, 9-Apr-09, Proxy Mobile IPv6 is a network-based mobility management protocol. The mobility entities involved in the Proxy Mobile IPv6 protocol, the Mobile Access Gateway (MAG) and the Local Mobility Anchor (LMA), setup tunnels dynamically to manage mobility for a mobile node within the Proxy Mobile IPv6 domain. This document describes a heartbeat mechanism between the MAG and the LMA to detect failures, quickly inform peers in the event of a recovery from node failures, and allow a peer to take appropriate action. "Interactions between PMIPv6 and MIPv6: scenarios and related issues", Gerardo Giaretta, 1-Jun-09, The scenarios where Proxy Mobile IPv6 (PMIPv6) and Mobile IPv6 (MIPv6) protocols are both deployed in a network require some analysis and considerations. This document describes all identified possible scenarios, which require an interaction between PMIPv6 and MIPv6 and discusses all issues related to these scenarios. Solutions and recommendations to enable these scenarios are also described. "LMA Discovery for Proxy Mobile IPv6", Jouni Korhonen, Vijay Devarapalli, 2-Sep-09, Large Proxy Mobile IPv6 deployments would benefit from a functionality, where a Mobile Access Gateway could dynamically discover a Local Mobility Anchor for a Mobile Node attaching to a Proxy Mobile IPv6 domain. The purpose of the dynamic discovery functionality is to reduce the amount of static configuration in the Mobile Access Gateway. This specification describes a number of possible dynamic Local Mobility Anchor discovery solutions. "Proxy Mobile IPv6 Management Information Base", Glenn Mansfield, Kazuhide Koide, Sri Gundavelli, Ryuji Wakikawa, 14-Sep-09, This memo defines a portion of the Management Information Base (MIB), the Proxy Mobile-IPv6 MIB, for use with network management protocols in the Internet community. In particular, the Proxy Mobile-IPv6 MIB will be used to monitor and control the mobile access gateway (MAG) node and the local mobility anchor (LMA) functions of a Proxy Mobile IPv6 (PMIPv6) entity. NETCONF Data Modeling Language (netmod) --------------------------------------- "YANG - A data modeling language for NETCONF", Martin Bjorklund, 12-Jan-10, YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF) protocol, NETCONF remote procedure calls, and NETCONF notifications. "Common YANG Data Types", Juergen Schoenwaelder, 1-Dec-09, This document introduces a collection of common data types to be used with the YANG data modeling language. "Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content", Ladislav Lhotka, Rohan Mahy, Sharon Chisholm, 19-Oct-09, This draft specifies the mapping rules for translating YANG data models into Document Schema Definition Languages (DSDL), a coordinated set of XML schema languages standardized as ISO 19757. The following DSDL schema languages are used by the mapping: RELAX NG, Schematron and DSRL. The mapping takes one or more YANG modules and produces a set of DSDL schemas for a selected target document type - datastore content, NETCONF PDU etc. Procedures for schema- based validation of such documents are also discussed. "Guidelines for Authors and Reviewers of YANG Data Model Documents", Andy Bierman, 26-Oct-09, This memo provides guidelines for authors and reviewers of standards track specifications containing YANG data model modules. Applicable portions may be used as a basis for reviews of other YANG data model documents. Recommendations and procedures are defined, which are intended to increase interoperability and usability of NETCONF implementations which utilize YANG data model modules. Network File System Version 4 (nfsv4) ------------------------------------- "NFS Direct Data Placement", Tom Talpey, Brent Callaghan, 16-Apr-08, This draft defines the bindings of the various Network File System (NFS) versions to the Remote Direct Memory Access (RDMA) operations supported by the RPC/RDMA transport protocol. It describes the use of direct data placement by means of server-initiated RDMA operations into client-supplied buffers for implementations of NFS versions 2, 3, 4 and 4.1 over such an RDMA transport. "Remote Direct Memory Access Transport for Remote Procedure Call", Tom Talpey, Brent Callaghan, 4-Dec-08, A protocol is described providing Remote Direct Memory Access (RDMA) as a new transport for Remote Procedure Call (RPC). The RDMA transport binding conveys the benefits of efficient, bulk data transport over high speed networks, while providing for minimal change to RPC applications and with no required revision of the application RPC protocol, or the RPC protocol itself. "NFS Version 4 Minor Version 1", Spencer Shepler, Mike Eisler, David Noveck, 15-Dec-08, This document describes NFS version 4 minor version one, including features retained from the base protocol (NFS version 4 minor version zero which is specified in RFC3530) and protocol extensions made subsequently. Major extensions introduced in NFS version 4 minor version one include: Sessions, Directory Delegations, and parallel NFS (pNFS). NFS version 4 minor version one has no dependencies on NFS version 4 minor version zero, and is considered a separate protocol. Thus this document neither updates nor obsoletes RFC3530. NFS minor version one is deemed superior to NFS minor version zero with no loss of functionality, and its use is preferred over version zero. Both NFS minor version zero and one can be used simultaneously on the same network, between the same client and server. "pNFS Block/Volume Layout", David Black, Stephen Fridella, Jason Glasgow, 23-Dec-08, Parallel NFS (pNFS) extends NFSv4 to allow clients to directly access file data on the storage used by the NFSv4 server. This ability to bypass the server for data access can increase both performance and parallelism, but requires additional client functionality for data access, some of which is dependent on the class of storage used. The main pNFS operations draft specifies storage-class-independent extensions to NFS; this draft specifies the additional extensions (primarily data structures) for use of pNFS with block and volume based storage. "Object-based pNFS Operations", Benny Halevy, Brent Welch, Jim Zelenka, 15-Dec-08, Parallel NFS (pNFS) extends NFSv4 to allow clients to directly access file data on the storage used by the NFSv4 server. This ability to bypass the server for data access can increase both performance and parallelism, but requires additional client functionality for data access, some of which is dependent on the class of storage used, a.k.a. the Layout Type. The main pNFS operations and data types in NFSv4 Minor Version 1 specify a layout-type-independent layer; layout-type-specific information is conveyed using opaque data structures which internal structure is further defined by the particular layout type specification. This document specifies the NFSv4.1 Object-based pNFS Layout Type in companion with the main NFSv4 Minor Version 1 specification. "NFSv4 Minor Version 1 XDR Description", Spencer Shepler, Mike Eisler, David Noveck, 15-Dec-08, This Internet-Draft provides the XDR description for NFSv4 minor version one. "IANA Considerations for RPC Net Identifiers and Universal Address Formats", Mike Eisler, 30-Jan-09, This Internet-Draft lists IANA Considerations for RPC Network Identifiers (netids) and RPC Universal Network Addresses (uaddrs). This Internet-Draft updates, but does not replace, RFC1833. "Administration Protocol for Federated Filesystems", James Lentini, Craig Everhart, Daniel Ellard, Renu Tewari, Manoj Naik, 26-Oct-09, This document describes the administration protocol for a federated file system that enables file access and namespace traversal across collections of independently administered fileservers. The protocol specifies a set of interfaces by which fileservers and collections of fileservers with different administrators can form a fileserver federation that provides a namespace composed of the filesystems physically hosted on and exported by the constituent fileservers. "Using DNS SRV to Specify a Global File Name Space with NFS version 4", Craig Everhart, Andy Adamson, Jiaying Zhang, 26-Oct-09, The NFS version 4 protocol provides a natural way for a collection of NFS file servers to collaborate in providing an organization-wide file name space. The DNS SRV RR allows a simple and appropriate way for an organization to publish the root of its name space, even to clients that might not be intimately associated with such an organization. The DNS SRV RR can be used to join these organization- wide file name spaces together to allow construction of a global, uniform NFS version 4 file name space. "NSDB Protocol for Federated Filesystems", James Lentini, Craig Everhart, Daniel Ellard, Renu Tewari, Manoj Naik, 26-Oct-09, This document describes a filesystem federation protocol that enables file access and namespace traversal across collections of independently administered fileservers. The protocol specifies a set of interfaces by which fileservers with different administrators can form a fileserver federation that provides a namespace composed of the filesystems physically hosted on and exported by the constituent fileservers. "Requirements for Federated File Systems", James Lentini, Craig Everhart, Daniel Ellard, Renu Tewari, Manoj Naik, 22-Oct-09, This document describes and lists the functional requirements of a federated file system and defines related terms. Individual Submissions (none) ----------------------------- "Password Policy for LDAP Directories", Jim Sermersheim, Ludovic Poitou, Howard Chu, 9-Aug-09, Password policy as described in this document is a set of rules that controls how passwords are used and administered in Lightweight Directory Access Protocol (LDAP) based directories. In order to improve the security of LDAP directories and make it difficult for password cracking programs to break into directories, it is desirable to enforce a set of rules on password usage. These rules are made to ensure that users change their passwords periodically, passwords meet construction requirements, the re-use of old password is restricted, and to deter password guessing attacks. "Cisco Systems' Simple Certificate Enrollment Protocol", Max Pritikin, Andrew Nourse, J Vilhuber, 30-Nov-09, This document specifies the Simple Certificate Enrollment Protocol, a PKI communication protocol which leverages existing technology by using PKCS#7 and PKCS#10 over HTTP. 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. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 3, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. "LDAP Transactions", Kurt Zeilenga, 19-Dec-08, 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. "Diversion Indication in SIP", Stuart Levy, Bryan Byerly, John Yang, 28-Jul-09, This document proposes an extension to the Session Initiation Protocol (SIP). This extension provides the ability for the called SIP user agent to identify from whom the call was diverted and why the call was diverted. The extension defines a general header, Diversion, which conveys the diversion information from other SIP user agents and proxies to the called user agent. This extension allows enhanced support for various features, including Unified Messaging, Third-Party Voicemail, and Automatic Call Distribution (ACD). SIP user agents and SIP proxies which receive diversion information may use this as supplemental information for feature invocation decisions. "Multicast in MPLS/BGP IP VPNs", Yiqun Cai, Eric Rosen, IJsbrand Wijnands, 18-Aug-09, This draft describes the deployed MVPN (Multicast in BGP/MPLS IP VPNs) solution of Cisco Systems. "Multicast DNS", Stuart Cheshire, Marc Krochmal, 8-Sep-09, As networked devices become smaller, more portable, and more ubiquitous, the ability to operate with less configured infrastructure is increasingly important. In particular, the ability to look up DNS resource record data types (including, but not limited to, host names) in the absence of a conventional managed DNS server, is becoming essential. Multicast DNS (mDNS) provides the ability to do DNS-like operations on the local link in the absence of any conventional unicast DNS server. In addition, mDNS designates a portion of the DNS namespace to be free for local use, without the need to pay any annual fee, and without the need to set up delegations or otherwise configure a conventional DNS server to answer for those names. The primary benefits of mDNS names are that (i) they require little or no administration or configuration to set them up, (ii) they work when no infrastructure is present, and (iii) they work during infrastructure failures. "The "tdb" URI scheme: denoting described resources", Larry Masinter, 12-Jul-09, This document defines a URI scheme, "tdb" ( standing for "Thing Described By"). It provides a semantic hook for allowing anyone at any time to mint a URI for anything that they can describe. Such URIs may include a timestamp to fix the description at a given date or time. This URI scheme may reduce the need to define define new URN namespaces merely for the purpose of creating stable identifiers. In addition, they provide a ready means for identifying "non-information resources" by semantic indirection -- a way of creating a URI for anything. Note This document is not a product of any working group. Many of the ideas here have been discussed since 2001. This document has been discussed on the mailing list . Previous versions have couched "tdb" as a URN namespace, and included a "duri" scheme for fixing date without indirection, which seems unnecessary. It was originally written as a thought experiment as a way of resolving the use/mention problem in semantic web applications, but may have other uses. "Requirements for Replacing AppleTalk", Stuart Cheshire, Marc Krochmal, 17-Nov-08, One of the goals of the authors of Multicast DNS (mDNS) and DNS-Based Service Discovery (DNS-SD) was the desire to retire AppleTalk and the AppleTalk Name Binding Protocol, and to replace them with an IP-based solution. This document presents a brief overview of the capabilities of AppleTalk NBP, and outlines the properties required of an IP-based replacement. "Compressed Data within an Internet EDI Message", Terry Harding, 27-Aug-08, This document explains the rules and procedures for utilizing compression (RFC 3274) within an Internet EDI (Electronic Data Interchange) 'AS' message, as defined in RFCs 3335, 4130, and 4823. "Analysis of Inter-Domain Routing Requirements and History", Elwyn Davies, Avri Doria, 16-Feb-09, This document analyses the state of the Internet domain-based routing system, concentrating on Inter-Domain Routing (IDR) and also considering 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 looking at the routing system as it appeared to be in 2001 with editorial additions reflecting developments up to 2006. It is the companion document to "A Set of Possible Requirements for a Future Routing Architecture" [I-D.irtf-routing-reqs], which is a discussion of requirements for the future routing architecture, addressing systems developments 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.] "An IPv4 Flowlabel Option", Thomas Dreibholz, 4-Jan-10, 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. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 9, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "BGP Persistent Route Oscillation Solutions", Daniel Walton, Alvaro Retana, Enke Chen, John Scudder, 12-Nov-09, In this document we present two sets of paths for an address prefix that can be advertised by a BGP route reflector or confederation ASBR to eliminate the MED-induced route oscillations in a network. The first set involves all the available paths, and would achieve the same routing consistency as the full IBGP mesh. The second set, which is a subset of the first one, involves the neighbor-AS based Group Best Paths, and would be sufficient to eliminate the MED- induced route oscillations (subject to certain commonly adopted topological constrains). "IMAP4 Keyword Registry", Alexey Melnikov, Dave Cridland, 11-Dec-09, The aim of this document is to establishe a new IANA registry for IMAP keywords and to define a procedure for keyword registration, in order to improve interoperability between different IMAP clients. Note A revised version of this draft document will be submitted to the RFC editor as a Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested, and should be sent to morg@ietf.org. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 14, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "Binding Extensions to Web Distributed Authoring and Versioning (WebDAV)", Geoffrey Clemm, Jason Crawford, Julian Reschke, Jim Whitehead, 15-Dec-09, This specification defines bindings, and the BIND method for creating multiple bindings to the same resource. Creating a new binding to a resource causes at least one new URI to be mapped to that resource. Servers are required to ensure the integrity of any bindings that they allow to be created. "EAP-Support in Smartcard", Guy Pujolle, Pascal Urien, 6-Aug-09, 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). "An Approach for Using LDAP as a Network Information Service", Luke Howard, Howard Chu, 9-Aug-09, This document describes a mechanism for mapping entities related to TCP/IP and the UNIX system [UNIX] into [X.500] entries so that they may be resolved with the Lightweight Directory Access Protocol [RFC4511]. A set of attribute types and object classes are proposed, along with specific guidelines for interpreting them. The intention is to assist the deployment of LDAP as an organizational nameservice. No proposed solutions are intended as standards for the Internet. Rather, it is hoped that a general consensus will emerge as to the appropriate solution to such problems, leading eventually to the adoption of standards. The proposed mechanism has already been implemented with some success. "Reliable Server Pooling Applicability for IP Flow Information Exchange", Thomas Dreibholz, Lode Coene, Phillip Conrad, 4-Jan-10, 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. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 9, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "Dynamic Host Configuration Protocol (DHCPv4) Option for the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", Fred Templin, 8-Dec-09, This document specifies a Dynamic Host Configuration Protocol (DHCPv4) option for nodes that implement the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP). Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 11, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "Prepaid Extensions to Remote Authentication Dial-In User Service (RADIUS)", Avi Lior, Parviz Yegani, Kuntal Chowdhury, Hannes Tschofenig, Andreas Pashalidis, 27-Dec-09, 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. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 30, 2010.Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "Lumas - Language for Universal Message Abstraction and Specification", Peter Cordell, 2-Feb-07, 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. "A Set of Possible Requirements for a Future Routing Architecture", Avri Doria, Elwyn Davies, Frank Kastenholz, 16-Feb-09, 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, 19-Aug-08, 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. Some of the numerous deployment scenarios of the aforementioned mechanism (which range from data center designs to Ethernet-to-the- home basement networks) are mentioned in the following to exemplify its possible usages; however, this document is not intended to cover all such deployment scenarios nor delve into their details. "PANA Enabling IPsec based Access Control", Mohan Parthasarathy, 14-Jul-05, PANA (Protocol for carrying Authentication for Network Access) is a protocol for authenticating clients to the access network using IP based protocols. The PANA protocol authenticates the client and also establishes a PANA security association between the PANA client and PANA authentication agent at the end of a successful authentication. This document discusses the details for establishing an IPsec security association using the PANA security association for enabling IPsec based access control. "Stream Control Transmission Protocol (SCTP) Packet Drop Reporting", Randall Stewart, Peter Lei, Michael Tuexen, 21-Dec-09, This document describes a new chunk type for SCTP. This new chunk type can be used by both endhosts and routers to report the loss of SCTP datagrams due to errors in transmission or other drops not due to congestion. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 24, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "PATCH Method for HTTP", Lisa Dusseault, James Snell, 25-Nov-09, Several applications extending the Hypertext Transfer Protocol (HTTP) require a feature to do partial resource modification. The existing HTTP PUT method only allows a complete replacement of a document. This proposal adds a new HTTP method, PATCH, to modify an existing HTTP resource. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 29, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "Layer 2 Virtual Private Networks Using BGP for Auto-discovery and Signaling", Kireeti Kompella, Bhupesh Kothari, Rao Cherukuri, 13-Jul-09, Layer 2 Virtual Private Networks (L2VPNs) based on Frame Relay or ATM circuits have been around a long time; more recently, Ethernet VPNs, including Virtual Private LAN Service, have become popular. Traditional L2VPNs often required a separate Service Provider infrastructure for each type, and yet another for the Internet and IP VPNs. In addition, L2VPN provisioning was cumbersome. This document presents a new approach to the problem of offering L2VPN services where the L2VPN customer's experience is virtually identical to that offered by traditional Layer 2 VPNs, but such that a Service Provider can maintain a single network for L2VPNs, IP VPNs and the Internet, as well as a common provisioning methodology for all services. "IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP)", Marc Blanchet, Florent Parent, 6-May-08, 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. "An Extension for EAP-Only Authentication in IKEv2", Pasi Eronen, Hannes Tschofenig, Yaron Sheffer, 20-Oct-09, IKEv2 specifies that EAP authentication must be used together with public key signature based responder authentication. This is necessary with old EAP methods that provide only unilateral authentication using, e.g., one-time passwords or token cards. This document specifies how EAP methods that provide mutual authentication and key agreement can be used to provide extensible responder authentication for IKEv2 based on methods other than public key signatures. "A QoS Model for Signaling IntServ Controlled-Load Service with NSIS", Cornelia Kappler, Xiaoming Fu, Bernd Schloer, 21-Oct-09, 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. "Using GOST 28147-89, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms for XML Security", Serguei Leontiev, Pavel Smirnov, Aleksandr Chelpanov, 25-Nov-09, This document specifies how to use Russian national cryptographic standards GOST 28147-89, GOST R 34.10-2001 and GOST R 34.11-94 with XML Signatures, XML Encryption, WS-SecureConversation, WS- SecurityPolicy and WS-Trust. A number of Uniform Resource Identifiers (URIs) and XML elements are defined. "DNS Blacklists and Whitelists", John Levine, 17-Nov-08, 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 the 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) of the Internet Research Task Force. It represents the consensus of the ASRG with respect to practices to improve interoperability of DNS based blacklists and whitelists, but does not constitute an IETF or Internet standard. [NOTE TO RFC EDITOR: Please remove this paragraph in publication.] Comments and discussion may be directed to the ASRG mailing list, asrg@irtf.org. "Light Weight Access Point Protocol", Pat Calhoun, 2-Mar-07, 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. "IP Fast Reroute using tunnels", Stewart Bryant, Clarence Filsfils, Stefano Previdi, Mike Shand, 16-Nov-07, 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, 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, 14-Jul-09, 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. "Vendor Specific RADIUS Attributes for the Delivery of Keying Material", Glen Zorn, Tiebing Zhang, Jesse Walker, Joseph Salowey, 6-Mar-09, 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. "SDP Descriptors for FLUTE", Harsh Mehta, 30-Jan-06, 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. "XML Media Types", Murata Makoto, Dan Kohn, Chris Lilley, 24-Sep-09, This document standardizes three media types -- application/xml, application/xml-external-parsed-entity, and application/xml-dtd -- for use in exchanging network entities that are related to the Extensible Markup Language (XML) while deprecating text/xml and text/ xml-external-parsed-entity. This document also standardizes a convention (using the suffix '+xml') for naming media types outside of these five types when those media types represent XML MIME entities. XML MIME entities are currently exchanged via the HyperText Transfer Protocol on the World Wide Web, are an integral part of the WebDAV protocol for remote web authoring, and are expected to have utility in many domains. Major differences from [RFC3023] are deprecation of text/xml and text/xml-external-parsed-entity, the addition of XPointer and XML Base as fragment identifiers and base URIs, respectively, mention of the XPointer Registry, and updating of many references. "HIP Experiment Report", Tom Henderson, Andrei Gurtov, 26-Oct-09, This document is a report from the IRTF HIP research group documenting the collective experiences and lessons learned from studies, related experimentation, and designs completed by the research group. The documents summarizes implications of adding HIP to host protocol stacks, Internet infrastructure, and applications. The perspective of a network operator, as well as a list of HIP experiments, are presented as well. "Robust Header Compression (ROHC) over 802 networks", Carsten Bormann, 13-Jul-09, Various proposals have been submitted to the ROHC working group for enabling the use of ROHC [RFC3095] header compression over Ethernet, 802.11 and other 802-based links. Previous proposals generally suffered from a lack of systems perspective on 802 networks. The present document attempts to supply some systems perspective and provides a rough outline for a solution. This is a submission to the IETF ROHC WG. Please direct discussion to its mailing list, rohc@ietf.org $Revision: 1.9 $ "Version 2.0 Microsoft Word Template for Creating Internet Drafts and RFCs", Joseph Touch, 8-Jul-08, 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 "The QName URN Namespace", David Orchard, Rich Salz, Julian Reschke, 15-Dec-09, This specification defines a Uniform Resource Name namespace for XML namespace-qualified names, QNames. As long as the URN is encoded in the same character set as the document containing the original QName, the Qname URN provides enough information to maintain the semantics, and optionally the exact syntax, of the original name. "Certificate Exchange Messaging for EDIINT", Kyle Meadors, Dale Moberg, 1-Sep-09, 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). "VoIP Configuration Server Address Option", Richard Johnson, 6-Jan-09, 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 RFC 3942 [RFC3942], 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. "The 'mailto' URI Scheme", Martin Duerst, Larry Masinter, Jamie Zawinski, 26-Oct-09, 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). "Unintended Consequence of two NAT deployments with Overlapping Address Space", Pyda Srisuresh, Bryan Ford, 12-Aug-09, This document identifies two deployment scenarios that have arisen from the unconventional network topologies formed using Network Address Translator devices (NATs). First, the simplicity of administering networks through the combination of NAT and DHCP has increasingly lead to the deployment of multi-level inter-connected private networks involving overlapping private IP address spaces. Second, the proliferation of private networks in enterprises, hotels and conferences, and the wide spread use of Virtual Private Networks (VPNs) to access enterprise intranet from remote locations has increasingly lead to overlapping private IP address space between remote and corporate networks. The document does not dismiss these unconventional scenarios as invalid, but recognizes them as real and offers recommendations to help ensure these deployments can function without a meltdown. "SDP and RTSP extensions defined for 3GPP Packet-switched Streaming Service and Multimedia Broadcast/Multicast Service", Magnus Westerlund, Per Frojdh, 8-May-09, The Packet-switched Streaming Service (PSS) and the Multimedia Broadcast/Multicast Service (MBMS) defined by 3GPP use SDP and RTSP with some extensions. This document provides information about these extensions and registers the RTSP and SDP extensions with IANA. "The LDAP Don't Use Copy Control", Kurt Zeilenga, 17-Dec-09, This document defines the Lightweight Directory Access Protocol (LDAP) Don't Use Copy control extension which allows a client to specify that copied information should not be used in providing service. This control is based upon the X.511 dontUseCopy service control option. "Wireless LAN Control Protocol (WiCoP)", Satoshi Iino, 7-Feb-07, 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, 1-Sep-09, 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. "SLAPP : Secure Light Access Point Protocol", Partha Narasimhan, 27-Mar-06, 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. "An Extensible Format for Email Feedback Reports", Yakov Shafranovich, John Levine, Murray Kucherawy, 20-Oct-09, 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. "The 'news' and 'nntp' URI Schemes", Frank Ellermann, 2-Apr-08, 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. "CalDAV Scheduling Extensions to WebDAV", Cyrus Daboo, Bernard Desruisseaux, 20-Aug-09, This document defines extensions to the CalDAV "calendar-access" feature to specify a standard way of performing scheduling transactions with iCalendar-based calendar components. This document defines the "calendar-auto-schedule" feature of CalDAV. "Bundle Security Protocol Specification", Susan Symington, Stephen Farrell, Howard Weiss, Peter Lovell, 20-Nov-09, This document defines the bundle security protocol, which provides data integrity and confidentiality services for the bundle protocol. Separate capabilities are provided to protect the bundle payload and additional data that may be included within the bundle. We also describe various bundle security considerations including policy options. 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. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 24, 2010.Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. "Distributing Address Selection Policy using DHCPv6", Tomohiro Fujisaki, Arifumi Matsumoto, Ruri Hiromi, 13-Oct-09, 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 Reliable Server Pooling for Real-Time Distributed Computing", Thomas Dreibholz, 4-Jan-10, 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. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 9, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "RADIUS Attributes for IEEE 802 Networks", Bernard Aboba, Jouni Malinen, Paul Congdon, Joseph Salowey, 25-Oct-09, 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. "Simple Service Location Protocol (SSLP) for 6LoWPAN", Ki-Hyung Kim, Waleed Baig, Seung Yoo, Soohong Daniel Park, Hamid Mukhtar, 26-Oct-09, The Simple Service Location Protocol (SSLP) provides a framework for the discovery and selection of the services working on 6LoWPAN. The protocol has a simple structure that is easy to be implemented on 6LoWPAN devices that are characterized by short range, low bit rate and low power. The protocol also offers a mechanism for interoperability with the IP networks under SLP. It enables communication between 6LoWPAN and other IP networks. "Secure SCTP", Carsten Hohendorf, Esbold Unurkhaan, Thomas Dreibholz, 4-Jan-10, 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 RFC4960, it is designed to integrate cryptographic functions into SCTP. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 9, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "Combined Presence Schemas Utilizing RELAX NG", Jari Urpalainen, 9-Oct-08, This memo describes a batch of Presence Information Data Format (PIDF) and its extension schemas written with the RELAX NG schema language. Unlike with the current W3C XML Schema language it is possible to write reasonable forwards and backwards compatible presence combination schemas. These RELAX NG schemas are stricter than the W3C Schemas and thus the instance documents that validate with these schemas follow the intended content model more closely. Especially, these schemas are targeted to actual implementations in order to decrease interoperability problems. "Operational Reliability for EDIINT AS2", John Duker, Dale Moberg, 26-Oct-09, 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. "EDI-INT Features Header", Kyle Meadors, 1-Oct-08, 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, 9-Nov-09, This document specifies a common interface for using HIP with a Distributed Hash Table service to provide a name-to-HIT lookup service and a HIT-to-address lookup service. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 13, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. "GRE Key Extension for Mobile IPv4", Parviz Yegani, Gopal Dommety, Avi Lior, Kuntal Chowdhury, Jay Navali, 28-Jul-09, The GRE specification contains a Key field, which MAY contain a value that is used to identify a particular GRE data stream. This specification defines a new Mobile IP extension that is used to exchange the value to be used in the GRE Key field. This extension further allows the Mobility Agents to setup the necessary protocol interfaces prior to receiving the mobile's traffic. The new extension option allows a foreign agent to request GRE tunneling without disturbing the Home Agent behavior specified for Mobile Ipv4. GRE tunneling provides an advantage that allows operator's private home networks to be overlaid and allows the HA to provide overlapping home addresses to different subscribers. When the tuple < Care of Address, Home Address and Home Agent Address > is the same across multiple subscriber sessions, GRE tunneling will provide a means for the FA and HA to identify data streams for the individual sessions based on the GRE key. In the absence of this key identifier, the data streams cannot be distinguished from each other, a significant drawback when using IP-in-IP tunneling. "Pre-authentication Support for PANA", Yoshihiro Ohba, Alper Yegin, 14-Dec-09, This document defines an extension to the Protocol for carrying Authentication for Network Access (PANA) for proactively establishing a PANA security association between a PANA client in one access network and a PANA authentication agent in another access network to which the PANA client may move. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 17, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "Password-Authenticated Diffie-Hellman Exchange (PAK)", Igor Faynberg, Sarvar Patel, Zachary Zeltsan, Alec Brusilovsky, 10-Apr-09, 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. PAK provides Forward Secrecy. "Re-ECN: Adding Accountability for Causing Congestion to TCP/IP", Bob Briscoe, Arnaud Jacquet, T Moncaster, Alan Smith, 30-Sep-09, This document introduces a new protocol for explicit congestion notification (ECN), termed re-ECN, which can be deployed incrementally around unmodified routers. The protocol works by arranging 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. 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 briefly gives examples of mechanisms that can use the protocol to ensure data sources respond correctly to congestion,and these are described more fully in a companion document [I-D.briscoe-tsvwg-re-ecn-tcp-motivation]. 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 E. Changes from previous drafts (to be removed by the RFC Editor) Full diffs from all previous verisons (created using the rfcdiff tool) are available at From -07 to -08 (current version): Minor changes and consistency checks. References updated. From -06 to -07: Major changes made following splitting this protocol document from the related motivations document [I-D.briscoe-tsvwg-re-ecn-tcp-motivation]. Significant re-ordering of remaining text. New terminology introduced for clarity. Minor editorial changes throughout. "UDP Encapsulation of SCTP Packets", Michael Tuexen, Randall Stewart, 21-Dec-09, 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. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 24, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "IAX: Inter-Asterisk eXchange Version 2", Mark Spencer, Brian Capouch, Ed Guy, Frank Miller, Kenneth Shumard, 5-Oct-08, 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. "DTCP: Dynamic Tasking Control Protocol", David Cavuto, 11-Nov-09, Dynamic Tasking Control Protocol is a message-based interface by which an authorized client may connect to a server -- usually a network element (NE) or security policy enforcement point (PEP) -- and issue dynamic requests for data. These tasking requests contain, among other parameters, packet matching criteria that may apply to certain packets flowing through that network element. The primary intent of the tasking request is to instruct that network element to send copies of packets matching those criteria to a destination (usually via tunneling) for further inspection or other action. The protocol contains a security architecture to address client or server spoofing as well as replay prevention. The protocol assumes that multiple clients may simultaneously control a single server. "IPv6 over Low Power WPAN Security Analysis", Soohong Daniel Park, Ki-Hyung Kim, Wassim Haddad, Samita Chakrabarti, Julien Laganier, 13-Jul-09, This document discusses possible threats and security options for IPv6-over-IEEE802.15.4 networks. Its goal is to raise awareness about security issues in IPv6 lowPan networks. "Extending ICMP for Interface and Next-hop Identification", Ronald Bonica, Carlos Pignataro, Naiming Shen, 6-Jan-10, This memo defines a data structure that can be appended to selected ICMP messages. The ICMP extension defined herein can be used to identify any combination of the following: the IP interface upon which a datagram arrived, the sub-IP component of an IP interface upon which a datagram arrived, the IP interface through which the datagram would have been forwarded had it been forwardable, the IP next hop to which the datagram would have been forwarded. Devices can use this ICMP extension to identify interfaces and their components by any combination of the following: ifIndex, IPv4 address, IPv6 address, name and MTU. ICMP-aware devices can use these extensions to identify both numbered and unnumbered interfaces. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 10, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. "Private Extensions to the Session Initiation Protocol (SIP) for Service Interaction Indicator", Yuzhong Shen, 13-Nov-09, 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, 17-Feb-09, 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, 14-Oct-09, 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, such as Attribute Certificates or SAML Assertions, is exchanged in the supplemental data handshake message. "Encrypted Key Transport for Secure RTP", David McGrew, Flemming Andreasen, Dan Wing, Lakshminath Dondeti, 26-Oct-09, SRTP Encrypted Key Transport (EKT) is an extension to SRTP that provides for the secure transport of SRTP master keys, Rollover Counters, and other information, within SRTP or SRTCP. This facility enables SRTP to work for decentralized conferences with minimal control, and to handle situations caused by early media. This note defines EKT, and also describes how to use it with SDP Security Descriptions, DTLS-SRTP Key Transport (KTR), and MIKEY. These other key management protocols provide an EKT key to everyone in a session, and EKT coordinates the keys within the session. "4over6 Transit Solution using IP Encapsulation and MP-BGP Extensions", Jianping Wu, Yong Cui, Xing Li, Mingwei Xu, Chris Metz, 7-Dec-09, The emerging and growing deployment of IPv6 networks will introduce cases where connectivity with IPv4 networks crossing IPv6 transit backbones is desired. This document describes a mechanism for automatic discovery and creation of IPv4 over IPv6 tunnels via extensions to multi- protocol BGP. It is targeted at connecting islands of IPv4 networks across an IPv6-only backbone without the need for a manually configured overlay of tunnels. The mechanisms described in this document have been implemented, tested and deployed on the large research IPv6 network in China. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 10, 2010.Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "Mobile IPv6 Location Privacy Solutions", QIU Ying, Fan Zhao, Rajeev Koodli, 8-Jul-09, Mobile IPv6 (RFC 3775) enables a mobile node to remain reachable while it roams on the Internet. However, the location and movement of the mobile node can be revealed by the IP addresses used in signaling or data packets. In this document, we consider the Mobile IPv6 location privacy problem described in RFC 4882, and propose efficient and secure techniques to protect location privacy of the mobile node. This document is a product of the IP Mobility Optimizations (MobOpts) Research Group. "WiMAX Forum/3GPP2 Proxy Mobile IPv4", Kent Leung, 1-Dec-08, Mobile IPv4 is a standard mobility protocol that enables IPv4 device to move among networks while maintaining its IP address. The mobile device has the Mobile IPv4 client function to signal its location to the routing anchor, known as the Home Agent. However, there are many IPv4 devices without such capability due to various reasons. This document describes Proxy Mobile IPv4 (PMIPv4), a scheme based on having the Mobile IPv4 client function in a network entity to provide mobility support for an unaltered and mobility-unaware IPv4 device. This document also describes a particular application of PMIPv4 as specified in the WiMAX Forum and another application that is to be adopted in 3GPP2 "Media Server Markup Language (MSML)", Adnan Saleem, Garland Sharratt, 28-Jul-09, The Media Server Markup Language (MSML) is used to control and invoke many different types of services on IP Media Servers. The MSML control interface was initially driven by Radisys with subsequent significant contributions from Intel, Dialogic, and others in the industry. 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. "Supporting Multipoint-to-Point Label Switched Paths in Multiprotocol Label Switching Traffic Engineering", Seisho Yasukawa, Adrian Farrel, 19-Oct-09, 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. "ZRTP: Media Path Key Agreement for Secure RTP", Philip Zimmermann, Alan Johnston, Jon Callas, 10-Nov-09, This document defines ZRTP, a protocol for media path Diffie-Hellman exchange to agree on a session key and parameters for establishing Secure Real-time Transport Protocol (SRTP) sessions. The ZRTP protocol is media path keying because it is multiplexed on the same port as RTP and does not require support in the signaling protocol. ZRTP does not assume a Public Key Infrastructure (PKI) or require the complexity of certificates in end devices. For the media session, ZRTP provides confidentiality, protection against man-in-the-middle (MiTM) attacks, and, in cases where the signaling protocol provides end-to-end integrity protection, authentication. ZRTP can utilize a Session Description Protocol (SDP) attribute to provide discovery and authentication through the signaling channel. To provide best effort SRTP, ZRTP utilizes normal RTP/AVP profiles. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 14, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "Definition of an Internet Research Task Force (IRTF) Document Stream", Aaron Falk, 10-Nov-09, This memo defines the publication stream for RFCs from the Internet Research Task Force. Most documents undergoing this process will come from IRTF Research Groups and it is expected that they will be published as Informational or Experimental RFCs by the RFC Editor. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 15, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "Applicability of Reliable Server Pooling for SCTP-Based Endpoint Mobility", Thomas Dreibholz, Jobin Pulinthanath, 4-Jan-10, This document describes a novel mobility concept based on a combination of SCTP with Dynamic Address Reconfiguration extension and Reliable Server Pooling (RSerPool). Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 9, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "Channel Bindings for TLS based on the PRF", Simon Josefsson, 19-Aug-09, This document specify how to compute data, "channel bindings", that is cryptographically bound to a specific Transport Layer Security (TLS) session. The intention is to use this data as a name of the secure channel for the purpose of a channel binding. The channel bindings can be used by authentication protocols to avoid tunneling attacks and security layer re-use. The data is derived using the TLS Pseudo-Random Function (PRF). "Reliable Server Pooling (RSerPool) Bakeoff Scoring", Thomas Dreibholz, Michael Tuexen, 4-Jan-10, This memo describes some of the scoring to be used in the testing of Reliable Server Pooling protocols ASAP and ENRP at upcoming bakeoffs. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 9, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "Virtual Enterprise Traversal (VET)", Fred Templin, 13-Apr-09, Enterprise networks connect routers over various link types, and may also connect to provider networks and/or the global Internet. Enterprise network nodes require a means to automatically provision IP addresses/prefixes and support internetworking operation in a wide variety of use cases including SOHO networks, Mobile Ad-hoc Networks (MANETs), multi-organizational corporate networks and the interdomain core of the global Internet itself. This document specifies a Virtual Enterprise Traversal (VET) abstraction for autoconfiguration and operation of nodes in enterprise networks. "Web Linking", Mark Nottingham, 11-Jul-09, This document specifies relation types for Web links, and defines a registry for them. It also defines how to send such links in HTTP headers with the Link header-field. "Considerations for Information Services and Operator Services Using SIP", John Haluska, Renee Berkowitz, Paul Roder, Wesley Downum, Richard Ahern, Paul Lung, Nicholas Costantino, Chris Blackwell, 23-Oct-09, Information Services are services whereby information is provided in response to user requests, and may include involvement of a human or automated agent. A popular existing Information Service is Directory Assistance (DA). Moving ahead, Information Services providers envision exciting multimedia services that support simultaneous voice and data interactions with full operator backup at any time during the call. Information Services providers are planning to migrate to SIP based platforms, which will enable such advanced services, while continuing to support traditional DA services. Operator Services are traditional PSTN services which often involve providing human or automated assistance to a caller, and often require the specialized capabilities traditionally provided by an operator services switch. Market and/or regulatory factors in some jurisdictions dictate that some subset of Operator Services continue to be provided going forward. This document aims to identify how Operator and Information Services can be implemented using existing or currently proposed SIP mechanisms, to identity existing protocol gaps, and to provide a set of Best Current Practices to facilitate interoperability. For Operator Services, the intention is to describe how current operator services can continue to be provided to PSTN based subscribers via a SIP based operator services architecture. It also looks at how current operator services might be provided to SIP based subscribers via such an architecture, but does not consider the larger question of the need for or usefulness or suitability of each of these services for SIP based subscribers. "Multiple aggregated control URIs for RTSP", Thorsten Lohmar, Torbjorn Einarsson, 14-Jul-09, RTSP defines the setup and control for on demand and live streaming media sessions, which are delivered via an external media transport protocol such as RTP/UDP. RTSP does not define a mechanism to change the content during an on-going streaming session. Such a mechanism improves the streaming experience when a user browses through multiple offerings on a single streaming site. This document describes several methods to improve content switching. The basic principle is to re-use already established transport sessions (e.g. RTP/UDP sessions) and negotiate new content to be delivered on the existing sessions. If additional transport sessions are necessary, those sessions are established separately. This principle of re-using the RTSP control and transport sessions decreases the content switch delay to a large extent and improves the end-user experience. The present document defines a mechanism for switching to new content, both when the client already has the content description available and when it does not. This document additionally considers switching of a single media stream in a session, when several alternative media components are available. For instance, the content may provide several alternate audio tracks in different languages to be played with a single video stream. The principle of Fast Content Switching and Start-up is also defined in 3GPP TS 26.234 [3GPP.26.234] for RTSP 1.0 [RFC2326]. "Delay-Tolerant Networking Bundle-in-Bundle Encapsulation", Susan Symington, Robert Durst, Keith Scott, 12-Aug-09, This document defines an encapsulation-specific application agent capability and a bundle payload format for use with the Bundle Protocol [refs.DTNBP] within the context of a Delay-Tolerant Network architecture [refs.DTNarch]. It defines the capability and format for placing one or more bundles inside of the payload field of an encapsulating bundle's Bundle Payload Block. "Delay-Tolerant Networking Previous Hop Insertion Block", Susan Symington, 12-Nov-09, This document defines an extension block that may be used with the DTN Bundle Protocol. This Previous Hop Insertion Block (PHIB) extension block is designed to be inserted by a forwarding node to provide the endpoint identifier (EID) of an endpoint of which the forwarding node is a member so that this EID may be conveyed to the next-hop receiving node. Knowledge of an EID of an endpoint of which a previous-hop node is a member may be required in some circumstances to support certain routing protocols (e.g., flood routing). If this EID cannot be provided by the convergence layer or other means, the PHIB defines the mechanism whereby the EID can be provided with the bundle. Each PHIB is always removed from the bundle by the receiving node so that its presence within the bundle is limited to exactly one hop. This document defines the format and processing of this PHIB. 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." Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 16, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "Delay-Tolerant Networking Custodial Multicast Extensions", Susan Symington, Robert Durst, Keith Scott, 12-Aug-09, This document defines optional extensions to the Bundle Protocol [refs.DTNBP] for supporting the custodial multicast delivery of bundles within a Delay-Tolerant Network (DTN). The protocol extensions described herein may be used to support custody transfer and custody-based reforwarding during the transmission of a bundle from a single source node to multiple destination nodes. "Channel Bindings for TLS", Jeffrey Altman, Nicolas Williams, Larry Zhu, 2-Oct-09, This document defines three channel binding types for Transport Layer Security (TLS), tls-unique, tls-server-end-point, and tls-unique-for- telnet, in accordance with RFC 5056 (On Channel Binding). "Dynamic Extensions to the Presence Information Data Format Location Object (PIDF-LO)", Henning Schulzrinne, Vishal Singh, Hannes Tschofenig, Martin Thomson, 17-Aug-09, The Geopriv Location Object introduced by the Presence Information Data Format - Location Object (PIDF-LO), RFC 4119, defines a basic XML format for carrying geographical information of a presentity. This document defines PIDF-LO extensions that are intended to convey information about moving objects. Elements are defined that enable expression of spatial orientation, speed, heading, and acceleration of the presentity. "Congestion Control in the RFC Series", Michael Welzl, Wesley Eddy, 30-Oct-08, This document is an informational snapshot produced by the IRTF's Internet Congestion Control Research Group (ICCRG). It provides a survey of congestion control topics described by documents in the RFC series. This does not modify or update the specifications or status of the RFC documents that are discussed. It may be used as a reference or starting point for the future work of the research group, especially in noting gaps or open issues in the current IETF standards. "Authentication/Confidentiality for OSPFv2", Mukesh Gupta, Nagavenkata Melam, 4-Aug-09, This document describes means and mechanisms to provide authentication/confidentiality to OSPFv2 using IPsec (IP Security). "DAI Parameter for the "tel" URI", James Yu, David Hancock, Flemming Andreasen, 26-Oct-09, This document defines a "dai" parameter for the "tel" Uniform Resource Identifier (URI) to support the Dial Around Indicator (DAI). The "dai" parameter is associated with the "cic" parameter, defined in [RFC4694], and indicates how the carrier identified in the "cic" parameter was selected. This document also expands the use of the "cic" parameter to support pre-subscribed and dialed long-distance carrier requirements. "Sharing Transaction Fraud Data", David M'Raihi, Siddharth Bajaj, Sharon Boeyen, Michael Grandcolas, 22-Dec-09, This document describes a document format for exchanging transaction fraud (Thraud) information. It extends the Incident Handling Working Group (INCH WG) Incident Object Description Exchange Format (IODEF) incident reporting document format. "Extensions to the IODEF-Document Class for Reporting Phishing", Patrick Cain, David Jevans, 24-Nov-09, This document extends the Incident Object Description Exchange Format (IODEF) defined in RFC5070 to support the reporting of phishing events, which is a particular type of fraud. These extensions are flexible enough to support information gleaned from activities throughout the entire electronic fraud cycle - from receipt of the phishing lure to the disablement of the collection site. Both simple reporting and complete forensic reporting are possible, as is consolidating multiple incidents .RFC 2129 Keywords "Session Initiation Protocol (SIP) Overload Control", Volker Hilt, Henning Schulzrinne, 25-Oct-09, Overload occurs in Session Initiation Protocol (SIP) networks when SIP servers have insufficient resources to handle all SIP messages they receive. Even though the SIP protocol provides a limited overload control mechanism through its 503 (Service Unavailable) response code, SIP servers are still vulnerable to overload. This document defines an overload control mechanism for SIP. "An uniform format for IPv6 extension headers", Suresh Krishnan, James Woodyatt, Erik Kline, James Hoagland, 13-Jul-09, In IPv6, optional internet-layer information is encoded in separate headers that may be placed between the IPv6 header and the transport layer header. There are a small number of such extension headers currently defined. This document defines a format for defining a new family of IPv6 extension headers. "Use of Target Identity in HTTP-Enabled Location Delivery (HELD)", Martin Thomson, Hannes Tschofenig, Richard Barnes, James Winterbottom, 27-Aug-09, When a Location Information Server receives a request for location information (using the locationRequest message), described in the base HTTP Enabled Location Delivery (HELD) specification, it uses the source IP address of arriving message as a pointer to the location determination process. This is sufficient in environments where the location of a Device can be determined based on its IP address. Two additional use cases are addresses by this document. In the first, location configuration requires additional or alternative identifiers from the source IP address provided in the request. In the second, an entity other than the Device requests the location of the Device. This document extends the HELD protocol to allow the location request message to carry Device identifiers. Privacy and security considerations describe the conditions where requests containing identifiers are permitted. "The 'javascript' resource identifier scheme", Bjoern Hoehrmann, 24-Aug-09, This memo defines the 'javascript' resource identifier scheme. Using this scheme, executable script code can be specified in contexts that support resource identifiers. "Credential Protection Ciphersuites for Transport Layer Security (TLS)", Ibrahim Hajjeh, Mohamad Badra, 13-Nov-09, This document defines a set of cipher suites to add client credential protection to the Transport Layer Security (TLS) protocol. By negotiating one of those ciphersuites, the TLS clients will be able to determine for themselves when, how, to what extent and for what purpose information about them is communicated to others. The ciphersuites defined in this document can be used only when public key certificates are used in the client authentication process. "Real-time Inter-network Defense", Kathleen Moriarty, 13-Jul-09, Network security incidents, such as system compromises, worms, viruses, phishing incidents, and denial of service, typically result in the loss of service, data, and resources both human and system. Network providers and Computer Security Incident Response Teams need to be equipped and ready to assist in communicating and tracing security incidents with tools and procedures in place before the occurrence of an attack. Real-time Inter-network Defense outlines a proactive inter-network communication method to facilitate sharing incident handling data while integrating existing detection, tracing, source identification, and mitigation mechanisms across for a complete incident handling solution. Combining these capabilities in a communication system provides a way to achieve higher security levels on networks. Policy guidelines for handling incidents are recommended and can be agreed upon by a consortium using the security recommendations and considerations. "IEEE 802.21 Basic Schema", Kenichi Taniuchi, Yoshihiro Ohba, Subir Das, 14-Dec-09, This document describes an RDF (Resource Description Framework) schema defined in IEEE 802.21 as the basic schema for Media- Independent Information Service where the schema uses OWL (Web Ontology Language) constructs. This document serves as the Specification required by the IANA to maintain a global registry for storing the RDF schema. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 18, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "Distributed DNS Implementation in IpV6", Lican Huang, 28-Jul-09, This file is a proposal for P2P based Domain Name query stratagy in IpV6. The DNS servers construct n-tuple overlay virtual hierarchical overlay network. With cached addresses of DNS servers, the overload of traffic in tree structure can be avoided. This strategy may use for Domain Name query and reverse Domain Name query in IpV6 for a large number of domain names. "A Framework for Distributed Conferencing", Simon Romano, Alessandro Amirante, Tobia Castaldi, Lorenzo Miniero, Alfonso Buono, 7-Jan-10, This document defines the framework for Distributed Conferencing (DCON). The framework draws inspiration from the work carried out in the XCON working group, which has defined a complete architecture for centralized conferencing. DCON is based on the idea that a distributed conference can be setup by appropriately orchestrating the operation of a number of XCON focus elements, each in charge of managing a certain number of participants. Interaction between each participant and the corresponding conference focus is based on the standard XCON framework, whereas inter-focus interaction is defined in this document. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 11, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "Requirements for Distributed Conferencing", Simon Romano, Alessandro Amirante, Tobia Castaldi, Lorenzo Miniero, Alfonso Buono, 7-Jan-10, This document examines the requirements for Distributed Conferencing (DCON). Separate documents will map the requirements to existing protocol primitives, define new protocol extensions, and introduce new protocols as needed. Together, these documents will provide a guideline for building interoperable conferencing applications. The current works in SIPPING and XCON working groups marginally address the matter, which is nonetheless considered as out-of-scope. The requirements listed in this document are in part based on thoughts derived from the cited working groups activities. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 11, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "Requirements for the XCON-DCON Synchronization Protocol", Simon Romano, Alessandro Amirante, Tobia Castaldi, Lorenzo Miniero, Alfonso Buono, 7-Jan-10, The Distributed Conferencing (DCON) framework provides the means to distribute Centralized Conference (XCON) information by appropriately orchestrating a number of centralized focus entities (clouds). The mechanism we propose to make each XCON cloud communicate with its related DCON peer is based on the use of some kind of XCON-DCON Synchronization Protocol (XDSP). This document gives the requirements for XDSP. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 11, 2010.Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "PSTN scope of PCN Charter", Stuart Goldman, Frank Suraci, Bob Schaefer, 20-Oct-09, The IETF PCN Working Group has continued its work investigating pre- congestion and admission control mechanisms. This work has progressed under the current charter, but has not yet considered related legacy PSTN interactions or the need for ubiquitous connectivity between users on dissimilar networks. The PCN charter could be improved by a strong positive statement to the effect committing to future work addressing legacy networks. In that light, please consider the questions below which include differential PCN treatment based on traffic types, security, and PSTN interoperability concerns. It seems helpful to have a touchstone of some concerns relative to the PSTN network and IP network Gateway in order to confirm that they will be addressed in future work. This attempt is motivated by a desire to avoid the accidental omission of a topic that may be hard to "retrofit" in later. "Prefix Management for Mobile IPv6 Fast Handover on Point-to-Point Links", Frank Xia, Behcet Sarikaya, 5-Aug-09, Mobile IPv6 Fast Handovers specification currently does not explicitly define prefix management over point-to-point links when a mobile node uses a prefix to formulate a new care-of-address. In this document a mechanism is developed for a previous access router to request unique prefixes from a new access router, and in turn, the previous access router advertises the prefixes to the mobile node for a new care-of-address configuration. Extensions to Mobile IPv6 Fast Handovers specification are also specified in this document. "FCAST: Scalable Object Delivery for the ALC and NORM Protocols", Vincent Roca, Brian Adamson, 19-Oct-09, This document introduces the FCAST object (e.g., file) delivery application on top of the ALC and NORM reliable multicast protocols. FCAST is a highly scalable application that provides a reliable object delivery service. "Media Gateway Control Protocol Voiceband Data Package and General Purpose Media Descriptor Parameter Package", Sandeep Sharma, Joe Stone, Rajesh Kumar, 16-Oct-09, This document defines Media Gateway Control Protocol (MGCP) packages that enable a Call Agent to authorize and monitor the transition of a connection to and from voiceband data (VBD) with or without redundancy and FEC (forward error correction). Although the focus is on VBD, the General-Purpose Media Descriptor Parameter package can be used to authorize other modes of operation, not relevant to VBD, for a particular codec. In addition to the definition of these new packages, this document describes the use of the Media Format Parameter package and Fax package with VBD, redundancy and FEC. "The Camellia-CMAC-96 and Camellia-CMAC-PRF-128 Algorithms and Its Use with IPsec", Akihiro Kato, Satoru Kanno, Masayuki Kanda, Tetsu Iwata, 20-Dec-09, This memo specifies two new algorithms for IPsec. One is the usage of Cipher-based Message Authentication Code (CMAC) with the Camellia block cipher as an authentication mechanism in the IPsec Encapsulating Security Payload and Authentication Header protocols. This algorithm is called Camellia-CMAC-96. The other algorithm is a pseudo-random function (PRF) based on CMAC with the Camellia block cipher for the Internet Key Exchange, version 2. This algorithm is called Camellia-CMAC-PRF-128. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 24, 2010.Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. "The Use of Galois/Counter Mode (GCM) for the Camellia Block Cipher With IPsec ESP", Akihiro Kato, Satoru Kanno, Masayuki Kanda, 4-Jan-10, This document describes the use of the Camellia block ciper algorithm in Galois/Counter Mode (GCM) as an IPsec Encapsulating Security Payload (ESP) mechanism to provide confidentiality and data origin authentication. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 8, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. "Media Description for IKE in the Session Description Protocol (SDP)", Makoto Saito, Dan Wing, Masashi Toyama, 9-Nov-09, This document specifies how to establish secure media sessions over a virtual private network using Session Initiation Protocol for the purpose of on-demand media/application sharing between peers. It extends the protocol identifier of Session Description Protocol (SDP) so that it can negotiate the use of Internet Key Exchange Protocol (IKE) for media sessions in the SDP offer/answer model. It also specifies the method to boot up IKE and generate IPsec security associations using a self-signed certificate under the mechanism of connection-oriented media transport over the Transport Layer Security in the SDP (comedia-tls). This document extends RFC 4572. In addition, it defines a new attribute "udp-setup", which is similar to the "setup" attribute defined in RFC 4145, to enable endpoints to negotiate their roles in an IKE session. To use pre-shared keys for authentication in IKE, a new attribute "psk-fingerprint" is also defined. "LDP Extensions for Source-initiated Point-to-Multipoint Pseudowire", Philippe Niger, Yuji Kamite, Frederic JOUNAY, 13-Jul-09, This document provides a solution to extend Label Distribution Protocol (LDP) signaling in order to allow set up and maintenance of Point-to-Multipoint Pseudowire (P2MP PW). Such an extension of existing point to point Pseudowire is made necessary by new applications. The document deals with the source-initiated P2MP PW setup and maintenance. "P2PSIP Security Overview and Risk Analysis", Song Yongchao, Marcin Matuszewski, Dan York, 28-Sep-09, This document provides a security overview and analysis for the Peer- to-Peer Session Initiation Protocol (P2PSIP) overlay network. It discusses security threats for the P2PSIP architecture and its components. It compares security difference between client/server (C/S) and P2P implementations of SIP, and then partitions the P2PSIP architecture into layers and analyzes the security issues in each layer and the security relationship among the layers. "The Minger Email Address Verification Protocol", Arvel Hathcock, Jonathan Merkel, 3-Aug-09, This document describes the Minger protocol. Minger is a protocol which allows a mail handling entity to query a remote service and ask the question "do you accept mail for this email address?" It includes security in the form of a hashed shared secret but can also be used anonymously if desired. "The SatLabs Group DVB-RCS MIB", Petter Amundsen, Micheline Lambert, Hans-Peter Lexow, Stephane Combes, 22-Oct-09, This document describes the MIB module for the Digital Video Broadcasting Return Channel via Satellite system (DVB-RCS), as defined by the SatLabs Group. It defines a set of MIB entities to characterize the behavior and performance of network layer entities deploying DVB-RCS. "Adding Acknowledgement Congestion Control to TCP", Sally Floyd, 4-Jul-09, This document describes a possible congestion control mechanism for acknowledgement traffic (ACKs) in TCP. The document specifies an end-to-end acknowledgement congestion control mechanism for TCP that uses participation from both TCP hosts, the TCP data sender and the TCP data receiver. The TCP data sender detects lost or ECN-marked ACK packets, and tells the TCP data receiver the ACK Ratio R to use to respond to the congestion on the reverse path from the data receiver to the data sender. The TCP data receiver sends roughly one ACK packet for every R data packets received. This mechanism is based on the acknowledgement congestion control in DCCP's CCID 2. This acknowledgement congestion control mechanism is being specified for further evaluation by the network community. "Diameter Base Protocol Interoperability Test Suite", Victor Fajardo, Alan McNamee, Hannes Tschofenig, Julien Bournelle, 13-Jul-09, This document describes a collection of test cases to be used for Diameter base protocol interoperability testing. "Diameter Credit Control Interoperability Test Suite", Alan McNamee, Hannes Tschofenig, Victor Fajardo, Julien Bournelle, 13-Jul-09, This document describes a collection of test cases to be used for Diameter Credit Control application interoperability testing. "Diameter Applications Interoperability Test Suite", Victor Fajardo, Alan McNamee, Hannes Tschofenig, Julien Bournelle, 13-Jul-09, This document describes a collection of test cases to be used for Diameter applications interoperability testing. "A Session Initiation Protocol (SIP) Extension for the Identification of Services", Keith Drage, 24-Mar-09, This document describes private extensions to the Session Initiation Protocol (SIP) that enable a network of trusted SIP servers to assert the service of authenticated users. The use of these extensions is only applicable inside an administrative domain with previously agreed-upon policies for generation, transport and usage of such information. This document does NOT offer a general service identification model suitable for use between different trust domains, or use in the Internet at large. The document also defines a URN to identify both services and UA applications. This URN can be used within the SIP header fields defined in this document to identify services, and also within the framework defined for caller preferences and callee capabilities to identify usage of both services and applications between end UAs. "Delay-Tolerant Networking Retransmission Block", Susan Symington, 8-Oct-09, This document defines an optional extension block, called a Retransmission Block (RB), that may be used with the Bundle Protocol [refs.DTNBP] within the context of a Delay-Tolerant Network architecture [refs.DTNarch]. The Retransmission Block (RB) is designed to be used within a DTN that, as a matter of policy, deletes all replayed bundles from the network. It is designed to be used in a network that permits duplicate bundles to be forwarded if those bundles have been retransmitted by a custodian, that may (if possible) permit duplicate bundles to be forwarded if those bundles are in intentional or unintentional routing loops (contingent on the availability of mechanisms to distinguish looping bundles from other bundles), but that will consider all other duplicate bundles to be maliciously replayed bundles and delete them as such. The Retransmission Block is designed to be inserted into a bundle by a custodian when the custodian is retransmitting that bundle. The purpose of the RB is to mark the bundle as a custody-based retransmission so that it can be distinguished from other types of duplicate bundles and thereby be spared from deletion. This document defines the format and processing of this new Retransmission Block. "Reclassification of the APEX RFCs to Historic", Marshall T. Rose, 4-Jun-07, This memo reclassifies the APEX RFCs (RFCs 3340-3343) from PROPOSED STANDARD to HISTORIC. "Using Saratoga with a Bundle Agent as a Convergence Layer for Delay-Tolerant Networking", Lloyd Wood, Jim McKim, Wesley Eddy, Will Ivancic, Chris Jackson, 25-Oct-09, Saratoga is a simple, lightweight, UDP-based transfer protocol. This describes how to use Saratoga as a Delay-Tolerant Networking (DTN) "convergence layer" with the Bundle Protocol and its Bundle Agents, building on the Saratoga specification in draft-wood-tsvwg-saratoga. "Multicast Mobility in MIPv6: Problem Statement and Brief Survey", Gorry Fairhurst, Thomas Schmidt, Matthias Waehlisch, 19-Oct-09, This document discusses current mobility extensions to IP layer multicast. It describes problems arising from mobile group communication in general, the case of multicast listener mobility, and for mobile senders using Any Source Multicast and Source Specific Multicast. Characteristic aspects of multicast routing and deployment issues for fixed IPv6 networks are summarized. Specific properties and interplays with the underlying network access are surveyed with respect to the relevant technologies in the wireless domain. It outlines the principal approaches to multicast mobility, together with a comprehensive exploration of the mobile multicast problem and solution space. This document concludes with a conceptual roadmap for initial steps in standardization for use by future mobile multicast protocol designers. This document is a product of the IP Mobility Optimizations (MobOpts) Research Group. "Handle Resolution Option for ASAP", Thomas Dreibholz, 4-Jan-10, This document describes the Handle Resolution option for the ASAP protocol. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 9, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "Timezone Information in HTTP", Stefanos Harhalakis, 27-Jul-09, This document defines a HTTP header for clients to provide timezone information to web servers. An ABNF description of the corresponding header is provided.Discussion Discussion about this document takes place in http-wg mailing list (ietf-http-wg@w3.org). Please CC v13@v13.gr too. "NERD: A Not-so-novel EID to RLOC Database", Eliot Lear, 11-Jan-10, LISP is a protocol to encapsulate IP packets in order to allow end sites to multihome without injecting routes from one end of the Internet to another. This memo presents an experimental database and a discussion of methods to transport the mapping of EIDs to RLOCs to routers in a reliable, scalable, and secure manner. Our analysis concludes that transport of of all EID/RLOC mappings scales well to at least 10"8 entries. "Definition of a Delay Measurement Infrastructure and Delay-Sensitive Least-Used Policy for Reliable Server Pooling", Thomas Dreibholz, Xing Zhou, 4-Jan-10, This document contains the definition of a delay measurement infrastructure and a delay-sensitive Least-Used policy for Reliable Server Pooling. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 9, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "Guidelines for Using the Privacy Mechanism for SIP", Mayumi Munakata, Shida Schubert, Takumi Ohba, 25-Sep-08, This is an informational document that provides guidelines for using the privacy mechanism for Session Initiation Protocol (SIP), that is specified in RFC 3323 and subsequently extended in RFCs 3325 and 4244. It is intended to clarify the handling of the target SIP headers/parameters and SDP parameters for each of the privacy header values (priv-values). "ECC Brainpool Standard Curves and Curve Generation", Manfred Lochter, Johannes Merkle, 6-Mar-09, This Memo proposes several elliptic curve domain parameters over finite prime fields for use in cryptographic applications. The domain parameters are consistent with the relevant international standards, and can be used in X.509 certificates and certificate revocation lists (CRLs), for Internet Key Exchange (IKE), Transport Layer Security (TLS), XML signatures, and all applications or protocols based on the cryptographic message syntax (CMS). "Location URI Contexts in HTTP-Enabled Location Delivery (HELD)", James Winterbottom, Hannes Tschofenig, Martin Thomson, 21-Oct-09, This document describes a protocol extension for the HTTP-Enabled Location Delivery (HELD) protocol. It allows a Target to manage their location information on a Location Information Server (LIS) through the application of constraints invoked by accessing a location URI. Constraints are described that allow control over how long the URI is valid for and the access policy used when a location URI is accessed. "Internationalized Resource Identifiers (IRIs)", Martin Duerst, Michel Suignard, Larry Masinter, 26-Oct-09, This document defines the Internationalized Resource Identifier (IRI) protocol element, as an extension of the Uniform Resource Identifier (URI). An IRI is a sequence of characters from the Universal Character Set (Unicode/ISO 10646). Grammar and processing rules are given for IRIs and related syntactic forms. In addition, this document provides named additional rule sets for processing otherwise invalid IRIs, in a way that supports other specifications that wish to mandate common behavior for 'error' handling. In particular, rules used in some XML languages (LEIRI) and web applications are given. Defining IRI as new protocol element (rather than updating or extending the definition of URI) allows independent orderly transitions: other protocols and languages that use URIs must explicitly choose to allow IRIs. Guidelines are provided for the use and deployment of IRIs and related protocol elements when revising protocols, formats, and software components that currently deal only with URIs. [RFC Editor: Please remove this paragraph before publication.] This document is intended to update RFC 3987 and move towards IETF Draft Standard. This is an interim version in preparation for the IRI BOF at IETF 76 in Hiroshima. For discussion and comments on this draft, please use the public-iri@w3.org mailing list. "Emulating Border Flow Policing using Re-PCN on Bulk Data", Bob Briscoe, 26-Oct-09, Scaling per flow admission control to the Internet is a hard problem. The approach of combining Diffserv and pre-congestion notification (PCN) provides a service slightly better than Intserv controlled load that scales to networks of any size without needing Diffserv's usual overprovisioning, but only if domains trust each other to comply with admission control and rate policing. This memo claims to solve this trust problem without losing scalability. It provides a sufficient emulation of per-flow policing at borders but with only passive bulk metering rather than per-flow processing. Measurements are sufficient to apply penalties against cheating neighbour networks. "Collection Synchronization for WebDAV", Cyrus Daboo, Arnaud Quillaud, 19-Nov-09, This specification defines an extension to WebDAV that allows efficient synchronization of the contents of a WebDAV collection. "Requirements, Terminology and Framework for Exigent Communications", Hannes Tschofenig, Henning Schulzrinne, Steve Norreys, 13-Jul-09, Various agencies need to provide information to the restricted group of persons or even to the generic public before, during and after emergency situations. While many aspects of such systems are specific to national or local jurisdictions, emergencies span such boundaries and notifications need to reach visitors from other jurisdictions. This document summarizes requirements for protocols to allow alerts to be conveyed to IP-based end points. "Session Initiation Protocol (SIP) Event Package for the Common Alerting Protocol (CAP)", Brian Rosen, Henning Schulzrinne, Hannes Tschofenig, 13-Jul-09, The Common Alerting Protocol (CAP) is an XML document format for exchanging emergency alerts and public warnings. This document allows CAP documents to be distributed via the event notification mechanism available with the Session Initiation Protocol (SIP). "Six/One: A Solution for Routing and Addressing in IPv6", Christian Vogt, 26-Oct-09, There is heightened concern about the growth of the global routing table and the increased frequency of routing table updates. Both is due to the use of provider-independent addressing space in edge networks, which accommodates operators' desire to move traffic quickly and easily from one provider to another. The main recent proposals attempt to solve this problem by hiding provider- independent addressing space through a level of indirection. Unfortunately, indirection requires a non-trivial distribution of address translation information across the Internet. This is either slow, or costly in terms of signaling overhead, or both. Security and transitionability are further issues. This document proposes an alternative solution, which is based on a single, provider-dependent addressing space and hence avoids the problems of indirection. The solution meets the objectives of edge network operators while limiting the size of the routing table and its update frequency. "File Transfer Protocol HOST Command", Paul Hethmon, Robert McMurray, 20-Nov-09, The File Transfer Protocol, as defined in RFC 959 and Section 4 of RFC 1123, is one of the oldest and most widely used protocols on the Internet. This document addresses the subject of creating multi-homed hostname- based FTP servers on a single IP address. This is achieved by extending the FTP specification to add a HOST command that is used to specify individual FTP hosts. "An Evaluation Framework for Data Modeling Languages in Network Management Domain", Hui Xu, Debao Xiao, 10-Nov-09, With rapid development of next generation networks, it is expected that a separate effort to study data modeling languages in the interest of network management should be undertaken. Based on a good understanding of the requirements of data modeling in next generation network management domain, evaluation on management data modeling languages becomes an essential way for the purpose of standardization to replace proprietary data models in the near future. Our project aims to establish a framework for evaluation to measure the capabilities of management data modeling languages in meeting those requirements by a set of criteria, which are modeling approaches, interoperability, conformance, extensibility, readability, data representation and security considerations. "Open Research Issues in Internet Congestion Control", Michael Welzl, Michael Scharf, Bob Briscoe, Dimitri Papadimitriou, 3-Sep-09, This document describes some of the open problems in Internet congestion control that are known today. This includes several new challenges that are becoming important as the network grows, as well as some issues that have been known for many years. These challenges are generally considered to be open research topics that may require more study or application of innovative techniques before Internet- scale solutions can be confidently engineered and deployed. "The Lightweight Global Navigation Satellite System (GNSS) Support Protocol (LGSP)", Mike Tyson, Carlo Kopp, 21-Dec-07, This document presents the Lightweight GNSS (Global Navigation Satellite System) Support Protocol (LGSP). The Lightweight GNSS Support Protocol (LGSP) is being developed in order to provide a comprehensive solution which solves the problems inherent in traditional radio-based Differential GPS (DGPS) protocols. LGSP will also provide additional support for GNSS user equipment, such as a GPS almanac retrieval method, allowing compatible units to perform faster almanac acquisition, thus resulting in less time until an initial position measurement can be established. Other supporting features include alternative distribution of GPS navigation messages and differential correction messages, a hierarchical mirroring architecture, redundant backup operation and load balancing functions. "Routing and Addressing Problem Statement", Thomas Narten, 15-Dec-09, There has been much discussion over the last years about the overall scalability of the Internet routing system. This document attempts to describe what the actual problem is and the various demands being placed on the routing system that have made finding a straightforward solution difficult. Comments should be sent to rrg@psg.com or to radir@ietf.org. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 18, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. "Extensions to the Emergency Services Architecture for dealing with Unauthenticated and Unauthorized Devices", Henning Schulzrinne, Stephen McCann, Gabor Bajko, Hannes Tschofenig, Dirk Kroeselberg, 26-Oct-09, The IETF emergency services architecture assumes that the calling device has acquired rights to use the access network or that no authentication is required for the access network, such as for public wireless access points. Subsequent protocol interactions, such as obtaining location information, learning the address of the Public Safety Answering Point (PSAP) and the emergency call itself are largely decoupled from the underlying network access procedures. In some cases, the device does not have credentials for network access, does not have a VoIP provider or application service provider (ASP), or the credentials have become invalid, e.g., because the user has exhausted their prepaid balance or the account has expired. This document provides a problem statement, introduces terminology and describes an extension for the base IETF emergency services architecture to address these scenarios. "A Framework of Media-Independent Pre-Authentication (MPA) for Inter- domain Handover Optimization", Ashutosh Dutta, Victor Fajardo, Yoshihiro Ohba, Kenichi Taniuchi, Henning Schulzrinne, 26-Oct-09, This document describes a framework of Media-independent Pre- Authentication (MPA), a new handover optimization mechanism that addresses the issues on existing mobility management protocols and mobility optimization mechanisms to support inter-domain handover. MPA is a mobile-assisted, secure handover optimization scheme that works over any link-layer and with any mobility management protocol and is best applicable to support optimization during inter-domain handover. MPA's pre-authentication, pre-configuration, and proactive handover techniques allow many of the handoff related operations to take place before the mobile has moved to the new network. We describe the details of all the associated techniques and present the experimental results from the scenarios involving both inter- technology and intra-technology handoff. This document is a product of the IP Mobility Optimizations (MobOpts) Research Group. "Home Agent assisted Route Optimization between Mobile IPv4 Networks", Antti Makela, Jouni Korhonen, 12-Oct-09, This document describes a Home Agent assisted Route Optimization functionality to IPv4 Network Mobility Protocol. The function is designed to facilitate optimal routing in cases where all nodes are connected to a single Home Agent, thus the use case is Route Optimization within single organization or similar entity. The functionality adds possibility to discover eligible peer nodes based on information received from Home Agent, Network Prefixes they represent, and how to establish direct tunnel between such nodes. "Reliability-only Ciphersuites for the Bundle Protocol", Wesley Eddy, Lloyd Wood, Will Ivancic, 25-Oct-09, The Delay-Tolerant Networking Bundle Protocol includes a custody transfer mechanism to provide acknowledgements of receipt for particular bundles. No checksum is included in the basic DTN Bundle Protocol, however, so at intermediate hops, it is not possible to verify that bundles have been either forwarded or passed through convergence layers without error. Without assurance that a bundle has been received without errors, the custody transfer receipt cannot guarantee that a correct copy of the bundle has been transferred, and errored bundles are forwarded when the destination cannot use the errored content, and discarding the errored bundle early would have been better for performance and throughput reasons. This document addresses that situation by defining new ciphersuites for use within the existing Bundle Security Protocol's Payload Integrity Block (formerly called the Payload Security Block [ED: remove old name before RFC]) to provide error-detection functions that do not require support for other, more complex, security-providing ciphersuites that protect integrity against deliberate modifications. This creates the checksum service needed for error-free reliability, and does so by separating security concerns from the few new reliability-only ciphersuite definitions that are introduced here. The reliability- only ciphersuites given here are intended to protect only against errors and accidental modification; not against deliberate integrity violations. This document discusses the advantages and disadvantages of this approach and the existing constraints that combined to drive this design. "Using Self-Delimiting Numeric Values in Protocols", Wesley Eddy, 21-Dec-09, Self-Delimiting Numeric Values (SDNVs) have recently been introduced as a field type in proposed Delay-Tolerant Networking protocols. SDNVs encode an arbitrary-length non-negative integer or arbitrary- length bit-string with minimum overhead. They are intended to provide protocol flexibility without sacrificing economy, and to assist in future-proofing protocols under development. This document describes formats and algorithms for SDNV encoding and decoding, along with notes on implementation and usage. 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. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 24, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "Cryptographic Message Syntax (CMS) Content Constraints Extension", Russ Housley, Sam Ashmore, Carl Wallace, 20-Oct-09, This document specifies the syntax and semantics for the Cryptographic Message Syntax (CMS) content constraints extension. This extension is used to determine whether a public key is appropriate to use in the processing of a protected content. In particular, the CMS content constraints extension is one part of the authorization decision; it is used when validating a digital signature on a CMS SignedData content or validating a message authentication code (MAC) on a CMS AuthenticatedData content or CMS AuthEnvelopedData content. The signed or authenticated content type is identified by an ASN.1 object identifier, and this extension indicates the content types that the public key is authorized to validate. If the authorization check is successful, the CMS content constraints extension also provides default values for absent attributes. "Revision of the Binary Floor Control Protocol (BFCP) for use over an unreliable transport", Mark Thompson, Tom Kristensen, Geir Arne Sandbakken, Trond Andersen, 23-Oct-09, This memo extends the Binary Floor Control Protocol (BFCP) for use over an unreliable transport. It details a set of revisions to the protocol definition document and the specification of BFCP streams in the Session Description Protocol (SDP). "Using Device-provided Location-Related Measurements in Location Configuration Protocols", Martin Thomson, James Winterbottom, 21-Oct-09, A method is described by which a Device is able to provide location- related measurement data to a LIS within a request for location information. Location-related measurement information are observations concerning properties related to the position of a Device, which could be data about network attachment or about the physical environment. When a LIS generates location information for a Device, information from the Device can improve the accuracy of the location estimate. A basic set of location-related measurements are defined, including common modes of network attachment as well as assisted Global Navigation Satellite System (GNSS) parameters. "Signaling Extensions for Wavelength Switched Optical Networks", Greg Bernstein, 22-Oct-09, This memo provides extensions to Generalized Multi-Protocol Label Switching (GMPLS) signaling for control of wavelength switched optical networks (WSON). Such extensions are necessary in WSONs under a number of conditions including: (a) when optional processing, such as regeneration, must be indicated to occur at specific nodes along a path, (b) where equipment must be configured to accept an optical signal with specific attributes, or (c) where equipment must be configured to output an optical signal with specific attributes. In addition this memo provides mechanisms to support distributed wavelength assignment in bidirectional LSP, and choice in distributed wavelength assignment algorithms. These extensions build on previous work for the control of lambda and G.709 based networks. "Saratoga: A Scalable File Transfer Protocol", Lloyd Wood, Jim McKim, Wesley Eddy, Will Ivancic, Chris Jackson, 25-Oct-09, This document specifies the Saratoga transfer protocol. Saratoga was originally developed to efficiently transfer remote-sensing imagery from a low-Earth-orbiting satellite constellation, but is useful for many other scenarios, including ad-hoc peer-to-peer communications, delay-tolerant networking, and grid computing. Saratoga is a simple, lightweight, content dissemination protocol that builds on UDP, and optionally uses UDP-Lite. Saratoga is intended for use when moving files or streaming data between peers which may have only sporadic or intermittent connectivity, and is capable of transferring very large amounts of data reliably under adverse conditions. The Saratoga protocol is designed to cope with highly asymmetric link or path capacity between peers, and can support fully-unidirectional data transfer if required. In scenarios with dedicated links, Saratoga focuses on high link utilization to make the most of limited connectivity times, while standard congestion control mechanisms can be implemented for operation over shared links. Loss recovery is implemented via a simple negative-ack ARQ mechanism. The protocol specified in this document is considered to be appropriate for experimental use on private IP networks. "Distributed Universal Resource Name Resolution based on Distributed DNS", Lican Huang, 28-Jul-09, This file is a proposal for Universal Resource Name resolution based on semantic P2P network-VIRGO. "Session Initiation Protocol Service Example -- Music on Hold", Dale Worley, 25-Oct-09, The "music on hold" feature is one of the most desired features of telephone systems in the business environment. "Music on hold" is where, when one party to a call has the call "on hold", that party's telephone provides an audio stream (often music) to be heard by the other party. Architectural features of SIP make it difficult to implement music-on-hold in a way that is fully compliant with the standards. The implementation of music-on-hold described in this document is fully effective and standards-compliant, but has a number of advantages over the methods previously documented. In particular, it is less likely to produce peculiar user interface effects and more likely to work in systems which perform authentication than the method of RFC 5359. "GMPLS Signaling Extensions for Optical Impairment Aware Lightpath Setup", Giovanni Martinelli, Andrea Zanardi, 13-Jul-09, The problem of provisioning a lightpath in a transparent dense wavelength division multiplexing (DWDM) optical island requires the evaluation of of the optical impairments along the selected route. In this memo we propose a GMPLS signaling protocol (RSVP/RSVP-TE) extension to collect and provide the egress node the optical impairment parameters needed to validate a lightpath setup request feasibility. "Registration of the Real-time-text Media Feature Tag", Gunnar Hellstrom, Arnoud Wijk, 12-Jul-09, This memo defines a new Media Feature Tag "real-time-text" for use in SIP registration and session establishment. This is used to indicate if a device capable of text communication has full real-time text capabilities or limitations in its capabilities requiring the users to apply some turn-taking habits. To the RFC editor Please replace y.y with the assigned ASN.1 identifier and XXXX with the RFC number of this specification. "Real-time text interworking between PSTN and IP networks", Gunnar Hellstrom, Barry Dingle, Arnoud Wijk, Guido Gybels, 13-Jul-09, IP networks can support real-time text communication. SIP-based real- time text is called Text-over-IP or ToIP. PSTN networks support real-time text using textphones (or TTYs). When real-time text is supported by different networks, gateways are needed to provide interoperability. Real-time text capable gateways may also support real-time voice. This specification describes procedures for interworking between ToIP and PSTN textphones using a real-time text capable gateway (RTT gateway). It also describes ways to route calls to RTT gateways for several call scenarios. Procedures that support the phased introduction of RTT gateways and procedures that support the invocation of text channels at any time during the call are included. Interworking of PSTN textphones that do not support simultaneity of voice and text with IP User Agents that support simultaneous voice and text is also described. "Representation of Uncertainty and Confidence in PIDF-LO", Martin Thomson, James Winterbottom, 30-Nov-09, The key concepts of uncertainty and confidence as they pertain to location information are defined. Methods for the manipulation of location estimates that include uncertainty information are outlined. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 31, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "A Location Dereferencing Protocol Using HELD", James Winterbottom, Hannes Tschofenig, Henning Schulzrinne, Martin Thomson, Martin Dawson, 27-Jul-09, This document describes how to use the Hypertext Transfer Protocol (HTTP) over Transport Layer Security (TLS) as a dereferencing protocol to resolve a reference to a Presence Information Data Format Location Object (PIDF-LO). The document assumes that a Location Recipient possesses a secure HELD URI that can be used in conjunction with the HELD protocol to request the location of the Target. "Definition of Master Key between PANA Client and Enforcement Point", Yoshihiro Ohba, Alper Yegin, 7-Jan-10, This document defines a master key used between a client of the Protocol for carrying Authentication for Network Access (PANA) and an enforcement point, for bootstrapping lower-layer ciphering. The master key is derived from the Master Session Key of Extensible Authentication Protocol as a result of successful PANA authentication. The master key guarantees cryptographic independence among enforcement points bootstrapped from PANA authentication across different address families. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 11, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "Mutual Authentication Protocol for HTTP", Yutaka Oiwa, 18-Aug-09, This document specifies the "Mutual authentication protocol for Hyper-Text Transport Protocol". This protocol provides true mutual authentication between HTTP clients and servers using simple password-based authentication. Unlike Basic and Digest HTTP access authentication protocol, the protocol ensures that server knows the user's entity (encrypted password) upon successful authentication. This prevents common phishing attacks: phishing attackers cannot convince users that the user has been authenticated to the genuine website. Furthermore, even when a user has been authenticated against an illegitimate server, the server cannot gain any bit of information about user's passwords. The protocol is designed as an extension to the HTTP protocol, and the protocol design intends to replace existing authentication mechanism such as Basic/Digest access authentications and form-based authentications. "IGMP and MLD Hold and Release Extensions for Mobility", Hitoshi Asaeda, Thomas Schmidt, 13-Jul-09, This document describes IGMP and MLD Hold and Release protocol extensions for hosts and routers. The interoperability with the standard IGMPv3/MLDv2 protocols and these previous versions is also taken into account. "BGP protocol extensions for Path Computation Element (PCE) Discovery in a BGP/MPLS IP-VPN", Tomohiro Yamagata, Chikara Sasaki, Kenji Kumaki, Tomoki Murai, 23-Oct-09, In order to provide an end-to-end MPLS TE LSP between customer sites within a BGP/MPLS IP-VPN, it is highly desirable for a Path Computation Element (PCE) to be able to dynamically discover a set of Path Computation Elements (PCEs) that know VPN routes. In BGP/MPLS IP-VPNs, it is advantageous to use BGP to distribute PCE information. This document defines a new attribute and describes how PCE information can be carried using BGP. "Mobile and Wireless Multicast Requirements on IGMP/MLD Protocols", Hui Liu, 13-Jul-09, This document presents the requirements for IGMP/MLD protocols to allow the deployment of mobile multicast service. It is intended to provide useful guideline when adapting current IGMP/MLD protocols to support terminal mobility. "BGP based Virtual Private Multicast Service Auto-Discovery and Signaling", Rahul Aggarwal, Yuji Kamite, Frederic JOUNAY, 13-Jul-09, A Point-to-Multipoint (P2MP) Pseudowire (PW) is a mechanism that emulates the essential attributes of a unidirectional P2MP Telecommunications service such as P2MP ATM over a Packet Switched Network (PSN). One of the applicabilities of a P2MP PW is to deliver a Layer 2 multicast service, that carries multicast frames (encoded using Layer 2 or IP mechanisms) from a multicast source to one or more multicast receivers. [RFC4664] describes a number of different ways in which sets of PWs may be combined together into "Provider Provisioned Layer 2 VPNs" (L2 PPVPNs, or L2VPNs), resulting in a number of different kinds of L2VPN. P2MP PWs enable a L2VPN to provide a Virtual Private Multicast Service (VPMS), which may be in addition to the Virtual Private Wire Service (VPWS) offered by the L2VPN. A VPMS is a L2VPN service that provides point-to-multipoint connectivity traffic to customers. VPMS framework and requirements are described in [VPLS-REQ]. One of the VPMS requirements is auto-discovery. This document describes how procedures outlined in [VPLS-MCAST] can be used for auto-discovery (A-D) in VPMS using BGP. This document also describes BGP based procedures for P2MP PW signaling for VPMS that may be used when BGP is used for VPMS auto-discovery. "RTP Payload Format for MVC Video", Ye-Kui Wang, Thomas Schierl, 22-Oct-09, This memo describes an RTP payload format for the multiview extension of the ITU-T Recommendation H.264 video codec that is technically identical to ISO/IEC International Standard 14496-10. The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units, produced by the video encoder, in each RTP payload. The payload format has wide applicability, such as 3D video streaming, free-viewpoint video, and 3DTV. "Reporting of DKIM Verification Failures", Murray Kucherawy, 20-Oct-09, This memo presents an extension to the DomainKeys Identified Mail (DKIM) specifications to allow public keys for verification to include a reporting address to be used to report message verification issues, and extends an Internet Message reporting format to be followed when generating such reports. "Text media handling in RTP based real-time conferences", Gunnar Hellstrom, Arnoud Wijk, 12-Jul-09, This memo specifies methods for text media handling in multi-party calls, where the text is carried by the RTP protocol. Real-time text is carried in a time-sampled mode according to RFC 4103. Centralized multi-party handling of real-time text is achieved through a media control unit coordinating multiple RTP text streams into one RTP session, identifying each stream with its own SSRC. Identification for the streams are provided through the RTCP messages. This mechanism enables the receiving application to present the received real-time text medium in different ways according to user preferences. Some presentation related features are also described explaining suitable variations of transmission and presentation of text. Call control features are described for the SIP environment, while the transport mechanisms should be suitable for any IP based call control environment using RTP transport. An alternative method using a single RTP stream and source identification inline in the text stream is also described. "On Using 'Symbiotic Relationship' to Repel Network Flooding Attack", Wassim Haddad, Mats Naslund, 20-Oct-09, This memo describes a simple defense mechanism against a specific type of network flooding attacks. The suggested mechanism requires a mobile node to establish a 'symbiotic relationship' with the infrastructure, in order to empower it to repel such attack while giving enough insurance to the source(s) of the traffic about the need to cease sending traffic to the targeted network. "Syntax for binding documents with time stamps", Adriano Santoni, 20-Apr-09, This document describes an envelope which can be used to bind a file (not necessarily protected by means of cryptographic techniques) with one or more time-stamp tokens obtained for that file, where "time- stamp token" has the meaning defined in RFC 3161 or its successors. Additional types of temporal evidence are also allowed. The proposed envelope is based on the Cryptographic Message Syntax as defined in RFC 3852. "An IPv6 Geographic", Tony Hain, 26-Oct-09, This document defines an IPv6 Geographic global unicast address format for use in the Internet. The address format defined in this document is consistent with the IPv6 Protocol [1] and the "IPv6 Addressing Architecture" [2]. It is designed to facilitate scalable Internet routing when sites attach to multiple service providers, by using a prefix based on a geographic reference to the site. A natural byproduct of this address allocation mechanism is that all addresses are fixed allowing sites to change providers at will without requiring their network to renumber. "The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force", Paul Hoffman, 30-Nov-09, This document describes the inner workings of IETF meetings and Working Groups, discusses organizations related to the IETF, and introduces the standards process. It is not a formal IETF process document but instead an informational overview. "Using OpenPGP Keys for Transport Layer Security (TLS) Authentication", Nikos Mavrogiannopoulos, 30-Nov-09, This memo proposes extensions to the Transport Layer Security (TLS) protocol to support the OpenPGP key format. The extensions discussed here include a certificate type negotiation mechanism, and the required modifications to the TLS Handshake Protocol. This memo replaces the Experimental [RFC5081]. Status of This Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 3, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "Shim6 Implementation Report : LinShim6", Sebastien Barre, 24-Sep-09, LinShim6 is an implementation of the Shim6 and REAP protocols, on the Linux platform. This draft provides a description of the architecture and describes the current state of our implementation. The level of support of each protocol feature is detailed. Protocol conformance is evaluated against the main drafts. "Special Use IPv4 Addresses", Michelle Cotton, Leo Vegoda, 19-Aug-09, This document obsoletes RFC 3330. It describes the global and other specialized IPv4 address blocks that have been assigned by the Internet Assigned Numbers Authority (IANA). It does not address IPv4 address space assigned to operators and users through the Regional Internet Registries, nor does it address IPv4 address space assigned directly by IANA prior to the creation of the Regional Internet Registries. It also does not address allocations or assignments of IPv6 addresses or autonomous system numbers. "EAP Authentication Using Only A Password", Dan Harkins, Glen Zorn, 22-Oct-09, This memo describes an Extensible Authentication Protocol (EAP) method, EAP-pwd, which uses a shared password for authentication. The password may be a low-entropy one and may be drawn from some set of possible passwords, like a dictionary, which is available to an attacker. The underlying key exchange is resistant to active attack, passive attack and dictionary attack. "Probabilistic Routing Protocol for Intermittently Connected Networks", Anders Lindgren, Avri Doria, Elwyn Davies, Samo Grasic, 30-Nov-09, 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. This document defines PRoPHET, a Probabilistic Routing Protocol using History of Encounters and Transitivity. PRoPHET is a routing protocol for intermittently connected networks, where there is no guarantee that a fully connected path between source and destination exists at any time, rendering traditional routing protocols unable to deliver messages between hosts. These networks are examples of networks where there is a disparity between the latency requirements of applications and the capabilities of the underlying network (networks often referred to as Delay and Disruption Tolerant). The document presents an architectural overview followed by the protocol specification. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 3, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "The Subnetwork Encapsulation and Adaptation Layer (SEAL)", Fred Templin, 19-Aug-08, For the purpose of this document, subnetworks are defined as virtual topologies that span connected network regions bounded by encapsulated border nodes. These virtual topologies may span multiple IP- and/or sub-IP layer forwarding hops, and can introduce failure modes due to packet duplication and/or links with diverse Maximum Transmission Units (MTUs). This document specifies a Subnetwork Encapsulation and Adaptation Layer (SEAL) that accommodates such virtual topologies over diverse underlying link technologies. "Datagram Congestion Control Protocol (DCCP) Encapsulation for NAT Traversal (DCCP-NAT)", Thomas Phelan, 18-Nov-09, This document specifies an alternative encapsulation of the Datagram Congestion Control Protocol (DCCP), referred to as DCCP-NAT. This encapsulation will allow DCCP to be carried through the current generation of Network Address Translation (NAT) middleboxes without modification of those middleboxes. "Linguistic Guidelines for the Use of the Arabic Language in Internet Domains", Abdulaziz Al-Zoman, Ayman El-Sherbiny, Mansour Farah, Ibaa Oueichek, 6-Feb-09, This document constitutes technical specifications for the use of Arabic in Internet Domain names and provides linguistic guidelines for Arabic Domain Names. It addresses Arabic-specific linguistic issues pertaining to the use of Arabic language in domain names. "Usage of Host Generating Interface Identifier in DHCPv6", Frank Xia, Behcet Sarikaya, Sheng Jiang, 22-Oct-09, This document describes a procedure for configuring a host's IPv6 address which prefix is allocated from a DHCPv6 server while it's interface identifier is independently generated by the host. The method is applicable to Cryptographically Generated Addresses (CGA). "Change Process for the Session Initiation Protocol (SIP) and the Real- time Applications and Infrastructure Area", Jon Peterson, Cullen Jennings, Robert Sparks, 23-Oct-09, This memo documents a process intended to organize the future development of the Session Initiation Protocol (SIP) and related work in the Real-Time Applications and Infrastructure (RAI) Area. As the environments in which SIP is deployed grow more numerous and diverse, modifying or extending SIP in certain ways may threaten the interoperability and security of the protocol; however, the IETF process must also cater to the realities of existing deployments and serve the needs of the implementers working with SIP. This document therefore defines the functions of two long-lived working groups in the RAI Area which are, respectively, responsible for the maintenance of the core SIP specifications and development of new efforts to extend and apply work in this space. This document obsoletes RFC3427. "EAP Method Support for Transporting AAA Payloads", Charles Clancy, Avi Lior, Glen Zorn, Katrin Hoeper, 12-Nov-09, This document defines bindings for existing EAP methods to transport Diameter AVPs, called "AAA payloads". The primary application is to support EAP channel bindings, but this could be used for other applications as well. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 16, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. "Hierarchical Host Identity Tag Architecture", Xiaohu Xu, Sheng Jiang, Dacheng Zhang, tao chen, 26-Oct-09, The current flat-structured Host Identity Tag architecture has various problems and limitation. Hence, a hierarchical HIT architecture that is compatible with the flat-structured HIT architecture is introduced in the document. This architecture and the process of HIT generation ensure the global uniqueness of HITs. This architecture also enables the multiple Host Identity Protocol administrative domains, solves the deployment problem of current flat-structured HIT architecture. It also enhances the scalability and resolution efficiency of the mapping system from HIT to IP or FQDN. "Stream Control Transmission Protocol (SCTP)-Based Media Transport in the Session Description Protocol (SDP)", Salvatore Loreto, Gonzalo Camarillo, 13-Jul-09, SCTP (Stream Control Transmission Protocol) is a transport protocol used to establish associations between two endpoints. This document describes how to express media transport over SCTP in SDP (Session Description Protocol). This document defines the 'SCTP' and 'SCTP/ DTLS' protocol identifiers for SDP. "Diameter Application for Authentication and Authorization in Web Applications", Niklas Neumann, Xiaoming Fu, 13-Jul-09, This document specifies the Diameter Application for Authentication and Authorization in Web Applications (Diameter WebAuth). This Diameter application is intended to be used by Diameter clients to perform authentication and authorization operations with a Diameter server in web-based environments. It provides facilities to allow web sites to authenticate their web user clients using a number of (HTTP) authentication schemes. In addition, it supports user authorization using dedicated service identifiers. Diameter WebAuth may also be used by non web-based Diameter clients and servers that require a lightweight authentication and authorization Diameter application. "Kerberos Option for DHCPv6", Shoichi Sakane, Masahiro Ishiyama, 26-Oct-09, This document defines a new DHCPv6 option to carry a set of configuration information related to the Kerberos protocol [RFC4120]. This document also defines three sub-options to be used within this new option, which specify a realm name of the Kerberos, a list of IP addresses of the Key Distribution Center of that realm, and a client principal name to distinguish a Kerberos client by the DHCPv6 server. "P-Charge-Info - A Private Header (P-Header) Extension to the Session Initiation Protocol (SIP)", Dan York, Tolga Asveren, 14-Aug-09, This document describes 'P-Charge-Info', a private Session Initiation Protocol (SIP) header (P-header) used to convey billing information about the party to be charged. This P-Header is currently in production usage by a number of equipment vendors and carriers and this document is submitted to request the registration of this header with IANA as required by section 4.2 of RFC 3427 and RFC 3968. This P-Header may also be used in some situations to carry the ISUP Charge Number parameter for PSTN interconnection. "Cryptographic Algorithm Implementation Requirements for Routing Protocols", Manav Bhatia, Vishwas Manral, 11-Nov-09, The interior gateway routing protocols Open Shortest Path First version 2 (OSPFv2) [RFC2328], Intermediate System to Intermediate System (IS-IS) [ISO] [RFC1195] and Routing Information Protocol (RIP) [RFC2453] currently define Clear Text and Message Digest 5 (MD5) [RFC1321] algorithms for authenticating their protocol packets. There have recently been documents adding support of the Secure Hash Algorithm (SHA) family of hash functions for authenticating routing protocol packets for RIP [RFC4822], IS-IS [ISIS-HMAC] and OSPF [OSPF- HMAC]. To ensure interoperability between disparate implementations, it is imperative that we specify a set of mandatory-to-implement algorithms thereby ensuring that there is at least one algorithm that all implementations will have available. This document defines the current set of mandatory-to-implement algorithms to be used for the cryptographic authentication of these routing protocols as well as specifying the algorithms that should be implemented because they may be promoted to mandatory at some future time. "Using HTTP for delivery in Delay/Disruption-Tolerant Networks", Lloyd Wood, Peter Holliday, 25-Oct-09, This document describes how to use the Hypertext Transfer Protocol, HTTP, for communication across delay- and disruption-tolerant networks, by making every transit node in the network HTTP-capable, and doing peer HTTP transfers between nodes to move data hop-by-hop or subnet-by-subnet towards its final destination. HTTP is well- known and straightforward to implement in these networks. "Filename Preservation for EDIINT", Terry Harding, 5-Oct-09, The intent of this document is to be placed on the RFC track as an Informational RFC. The EDIINT [AS1], [AS2] and [AS3] message formats do not currently contain any provisions for preservation of the filename of a transmitted EDI business document from one Trading Partner to another. However,within certain trading communities, it is not uncommon for Trading Partners to require a specific filenames for EDI business documents to trigger specific backend processing. So it is the goal of this informational document to outline the procedures and mechanisms required to preserve filenames of EDI business documents. "TOTP: Time-based One-time Password Algorithm", Salah Machani, Mingliang Pei, Johan Rydell, 10-Dec-09, This document describes an extension of one-time password algorithm HOTP as defined in [RFC4226] to support time based moving factor. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 13, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "X.509 Key and Signature Encoding for the KeyNote Trust Management System", Angelos Keromytis, 30-Mar-09, This memo describes X.509 key identifiers and signature encoding for version 2 of the KeyNote trust-management system [KEYNOTE]. X.509 certificates [RFC3280] can be directly used in the Authorizer or Licensees field (or in both fields) in a KeyNote assertion, allowing for easy integration with protocols that already use X.509 certificates for authentication. In addition, the document defines additional signature types that use other hash functions (beyond the MD5 and SHA1 hash functions that are defined in [RFC2792]). "Distributed Internet Archive Protocol (DIAP)", Damian Brasher, 26-Nov-09, DIAP has been created to solve mid-range and below, long term archiving requirements of the small medium enterprise. Where tape has been deployed in the past, DIAP now offers an alternative solution designed to be more robust and manageable in the long term than network attached storage devices or simple disk storage alone. The system provides a well defined structure for storing and managing long term archives. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 30, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "Better Approach To Mobile Ad-hoc Networking (B.A.T.M.A.N.)", Axel Neumann, Corinna Aichele, Marek Lindner, Simon Wunderlich, 7-Apr-08, This document specifies a simple and robust algorithm for establishing multi-hop routes in mobile ad-hoc networks. It ensures highly adaptive and loop-free routing while causing only low processing and traffic cost. "PCEP extensions for a BGP/MPLS IP-VPN", Tomohiro Yamagata, Chikara Sasaki, Kenji Kumaki, Tomoki Murai, 23-Oct-09, It is highly desirable for VPN customers to be able to dynamically establish their MPLS TE LSPs in the context of a BGP/MPLS IP-VPN. In such a scenario, it is advantageous to use PCE to calculate customer MPLS TE LSPs. This document defines PCEP extensions for BGP/MPLS IP- VPNs. "PPP Over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics", Bo Berry, Stan Ratliff, Ed Paradise, Tim Kaiser, Mike Adams, 24-Apr-08, This document extends the Point-to-Point over Ethernet (PPPoE) Protocol with an optional credit-based flow control mechanism and an optional Link Quality Metric report. These optional extensions improve the performance of PPPoE over media with variable bandwidth and limited buffering, such as mobile point-to-point radio links. "Conversion of MIB to XSD for NETCONF", Xiaoqiong Wu, Debao Xiao, Yanan Chang, 11-Sep-09, NETCONF needs a data model for its process of standardization. This documentation defines a standard expression of SMI MIBs in XSD for NETCONF to ensure uniformity, general interoperability and reusability of existing MIBs. In addition, we define a XML schema to give a restriction and validation to translated XSD files. "ECC in OpenPGP", Andrey Jivsov, 26-Dec-09, This document proposes an Elliptic Curve Cryptography extension to the OpenPGP public key format and specifies three Elliptic Curves that enjoy broad support by other standards, including NIST standards. The document aims to standardize an optimal but narrow set of parameters for best interoperability and it does so within the framework it defines that can be expanded in the future to allow more choices. "IP Flow Information Accounting and Export Benchmarking Methodology", Jan Novak, Benoit Claise, 9-Oct-09, This document provides methodology and framework for quantifying performance impact of monitoring of IP flows on a network device and export of this information to a collector. It identifies the rate at which the IP flows are created, expired and exported as the performance metric. The metric is only applicable to the devices compliant with the Architecture for IP Flow Information Export [RFC5470]. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Novak Expires April, 2010 "Location-to-Service Translation Protocol (LoST) Extension: ServiceListBoundary", Karl Wolf, 1-Oct-09, LoST maps service identifiers and location information to service contact URIs. If a LoST client wants to discover available services for a particular location, it will perform a query to the LoST server. However, the response from the LoST server does not provide information about the geographical region for which the returned service list is valid. Therefore, this document proposes a ServiceListBoundary to assist the client to not miss a change in available services when moving. "Random Data Encryption Mechanism (RDEM)", Mukul Jaitly, 1-Jun-08, This document describe an data encryption specification which is based on random bytes selection of data and random key generation. This encryption process accepts variable input and the key size is dependent on the input data. This encryption process does not depend upon any 128 or 256 fixed block encryption. The mechanism for encryption is simpler to implement, but gives key complexity of more than 256 bit encryption. "BGP Extended Community for QoS Marking", Thomas Martin Knoll, 7-Jan-10, This document specifies a simple signalling mechanism for inter- domain QoS marking using several instances of a new BGP Extended Community. Class based packet marking and forwarding is currently performed independently within ASes. The new QoS marking community makes the targeted Per Hop Behaviour within the IP prefix advertising AS and the currently applied marking at the interconnection point known to all access and transit ASes. This enables individual (re-)marking and possibly forwarding treatment adaptation to the original QoS class setup of the respective originating AS. The extended community provides the means to signal QoS markings on different layers, which are linked together in QoS Class Sets. It provides inter-domain and cross-layer insight into the QoS class mapping of the source AS with minimal signalling traffic. "ISP Shared Address", Yasuhiro Shirasaki, Shin Miyakawa, Akira Nakagawa, Jiro Yamaguchi, Hiroyuki Ashida, 7-Sep-09, This document defines IPv4 ISP Shared Address to be jointly used among Internet Service Providers (ISPs). This space is intended to be used in NAT444 model which is used during the transition period to IPv6. "HIP support for RFID", Pascal Urien, 7-Dec-09, This document describes an architecture based on the Host Identity Protocol (HIP), for active tags, i.e. RFIDs that include tamper resistant computing resources, as specified for example in the ISO 14443 or 15693 standards. HIP-Tags never expose their identity in clear text, but hide this value (typically an EPC-Code) by a particular equation (f) that can be only solved by a dedicated entity, referred as the portal. HIP exchanges occurred between HIP- Tags and portals; they are shuttled by IP packets, through the Internet cloud. "Things To Be Considered for RFC 3484 Revision", Arifumi Matsumoto, Tomohiro Fujisaki, Ruri Hiromi, 21-Oct-09, RFC 3484 has several known issues to be fixed mainly because of the deprecation of IPv6 site-local unicast address and the coming of ULA. Additionally, the rule 9 of the destination address selection rules, namely the longest matching rule, is known for its adverse effect on the round robin DNS technique. This document covers these essential points to be modified and proposes possible useful changes to be included in the revision of RFC 3484. "Signaling Cryptographic Algorithm Understanding in DNSSEC", Steve Crocker, Scott Rose, 12-Nov-09, The DNS Security Extensions (DNSSEC) were developed to provide origin authentication and integrity protection for DNS data by using digital signatures. These digital signatures can be generated using different algorithms. This draft sets out to specify a way for validating end-system resolvers to signal to a server which cryptographic algorithms they support. "Safe IKE Recovery", Frederic Detienne, Pratima Sethi, Yoav Nir, 29-Jul-09, The Internet Key Exchange protocol version 2 (IKEv2) suffers from the limitation of not having a means to quickly recover from a stale state known as dangling Security Associations (SA's) where one side has SA's that the corresponding party does not have anymore. This Draft proposes to address the limitation by offering an immediate, DoS-free recovery mechanism for IKE that can be used in all failover or post-crash situations. "IPv6 Rapid Deployment on IPv4 infrastructures (6rd)", Remi Despres, 7-Apr-09, IPv6 rapid deployment (6rd) builds upon mechanisms of 6to4 (RFC3056) to enable a service provider to rapidly deploy IPv6 unicast service to IPv4 sites to which it provides customer premise equipment. Like 6to4, it utilizes stateless IPv6 in IPv4 encapsulation in order to transit IPv4-only network infrastructure. Unlike 6to4, a 6rd service provider uses an IPv6 prefix of its own in place of the fixed 6to4 prefix. A service provider has used this mechanism for its own IPv6 "rapid deployment": five weeks from first exposure to 6rd principles to more than 1,500,000 residential sites being provided native IPv6, under the only condition that they activate it. "Clarification of sender behaviour in persist condition.", Murali Bashyam, Mahesh Jethanandani, Anantha Ramaiah, 8-Jan-10, This document attempts to clarify the notion of the Zero Window Probes (ZWP) described in RFC 1122 [RFC1122]. In particular, it clarifies the actions that can be taken on connections which are experiencing the ZWP condition. The motivation for this document stems from the belief that TCP implementations strictly adhering to the current RFC language have the potential to become vulnerable to Denial of Service (DoS) scenarios. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 12, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "Certified Electronic Mail", Francesco Gennai, Alba Shahin, Claudio Petrucci, Alessandro Vinciarelli, 17-Sep-09, Since 1997, the Italian Laws have recognized electronic delivery systems as legally usable. In 2005 after two years of technical tests, the characteristics of an official electronic delivery service, named certified electronic mail (in Italian "Posta Elettronica Certificata") were defined, giving the system legal standing. Design of the entire system was carried out by the National Center for Informatics in the Public Administration of Italy (CNIPA), followed by efforts for the implementation and testing of the service. The CNIPA has given the Italian National Research Council (CNR), and in particular The Institute of Information Science and Technologies at the CNR (ISTI), the task of running tests on providers of the service to guarantee the correct implementation and interoperability. This document describes the certified email system adopted in Italy. It represents the system as it is at the moment of writing, following the technical regulations that were written based upon the Italian Law DPR. November 2, 2005. "Common Functions of Large Scale NAT (LSN)", Tomohiro Nishitani, Ikuhei Yamagata, Shin Miyakawa, Akira Nakagawa, Hiroyuki Ashida, 30-Nov-09, This document defines common functions of multiple types of Large Scale Network Address Translation (NAT) that handles Unicast UDP, TCP and ICMP. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 3, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "MVPN: Optimized use of PIM, Wild Card Selectors, S-PMSI Join Extensions, Bidirectional Tunnels, Extranets, Hub and Spoke", Arjen Boers, Yiqun Cai, Eric Rosen, IJsbrand Wijnands, 24-Aug-09, Specifications for a number of important topics were arbitrarily omitted from the initial MVPN specifications, so that those specifications could be "frozen" and advanced. The current document provides some of the missing specifications. The topics covered are: (a) Extending PE-PE PIM control mechanisms to support MPLS tunnels and IPv6 flows, (b) using Wild Card selectors to bind multicast data streams to tunnels, (c) using Multipoint-to-Multipoint Label Switched Paths as tunnels, (d) binding bidirectional customer multicast data streams to specific tunnels, (e) running PIM (i.e., sending and receiving multicast control traffic) over a set of tunnels that are created only if needed to carry multicast data traffic, (f) extranets, (g) support for anycast sources, (h) support for "hub and spoke" VPNs. "ATN Topology Considerations for Aeronautical NEMO RO", Christian Bauer, Serkan Ayaz, 9-Sep-09, The aviation industry is in the process of moving from legacy and ISO-based protocols to an IP-based environment. This task will require adoption, modification and/or creation of IETF related protocols. The intention of this draft is therefore to provide an overview of the operational environment and the topology of the Aeronautical Telecommunications Network to the IETF. "Secure DHCPv6 Using CGAs", Sheng Jiang, Sean Shen, 13-Jul-09, The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) enables DHCP servers to pass configuration parameters. It offers configuration flexibility. If not secured, DHCPv6 is vulnerable to various attacks, particularly fake attack. This document analyzes the security issues of DHCPv6 and specifies security mechanisms, mainly using CGAs. "The CERNET IVI Translation Design and Deployment for the IPv4/IPv6 Coexistence and Transition", Xing Li, Congxiao Bao, Maoke Chen, Hong Zhang, Jianping Wu, 6-Jan-10, This document presents the China Education and Research Network (CERNET)'s IVI translation design and deployment for the IPv4/IPv6 coexistence and transition. The IVI is a prefix-specific and stateless address mapping mechanism for "an IPv6 network to the IPv4 Internet" and "the IPv4 Internet to an IPv6 network" scenarios. In the IVI design, subsets of the ISP's IPv4 addresses are embedded in the ISP's IPv6 addresses and the hosts using these IPv6 addresses can therefore communicate with the global IPv6 Internet directly and can communicate with the global IPv4 Internet via stateless translators, the communications can either be IPv6 initiated or IPv4 initiated. The IVI mechanism supports the end-to-end address transparency and incremental deployment. The IVI is an early design deployed in CERNET as a reference for the IETF standard documents on IPv4/IPv6 translation. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 10, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "Signaling RSVP-TE P2MP LSPs in an Inter-domain Environment", Zafar Ali, Nic Neate, 25-Oct-09, Point-to-MultiPoint (P2MP) Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may be established using signaling techniques described in [RFC4875]. However, [RFC4875] does not address issues that arise when a P2MP-TE LSP is signaled in multi-domain networks. Specifically, it does not provide a mechanism to avoid re-merges in inter-domain P2MP TE LSPs. This document provides a framework and protocol extensions for establishing and controlling P2MP MPLS and GMPLS TE LSPs in multi-domain networks. This document borrows inter-domain TE terminology from [RFC4726], e.g., for the purposes of this document, a domain is considered to be any collection of network elements within a common sphere of address management or path computational responsibility. Examples of such domains include Interior Gateway Protocol (IGP) areas and Autonomous Systems (ASes). "GMPLS RSVP-TE Recovery Extension for data plane initiated reversion and protection timer signalling", Attila Takacs, Benoit Tremblay, 26-Oct-09, GMPLS RSVP-TE recovery extensions are specified in [RFC4872] and [RFC4873]. Currently recovery signalling does not support the request for revertive protection, neither the configuration of recovery timers. This document extends the PROTECTION Object format allowing sub-TLVs, and defines two sub-TLVs to carry wait-to-restore and hold-off intervals. "The References Header for SIP", Dale Worley, 6-Jan-10, This document defines a SIP extension header, References, to be used within SIP messages to signify that the message (and the dialog containing it) is related to one or more other dialogs. It is expected to be used largely for diagnostic purposes. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 10, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "Signaled PID When Multiplexing Multiple PIDs over RSVP-TE LSPs", Zafar Ali, 25-Oct-09, There are many deployment scenarios where an RSVP-TE LSP carries multiple payloads. In these cases, it gets ambiguous on what should value should be carried as L3PID in the Label Request Object [RFC3209] or G-PID in the Generalized Label Request Object [RFC3471], [RFC3473]. The document proposes use of some dedicated PID values to cover some typical cases of multiple payloads carried by the LSP. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. "Applicability of Access Node Control Mechanism to PON based Broadband Networks", Nabil Bitar, Sanjay Wadhwa, 25-Oct-09, The purpose of this document is to provide applicability of Access Node Control Mechanism, as described in [ANCP-FRAMEWORK], to PON based broadband access. The need for an Access Node Control Mechanism between a Network Access Server (NAS) and an Access Node Complex (a combination of Optical Line Termination (OLT) and Optical Network Termination (ONT) elements), is described in a multi-service reference architecture in order to perform QoS-related, service- related and Subscriber-related operations. The Access Node Control Mechanism is also extended for interaction between components of the Access Node Complex (OLT and ONT). The Access Node Control mechanism will ensure that the transmission of the information does not need to go through distinct element managers but rather uses a direct device- device communication. This allows for performing access link related operations within those network elements to meet performance objectives. "A Uniform Resource Name (URN) Namespace for CableLabs", Eduardo Cardona, Sumanth Channabasappa, Jean-Francois Mule, 26-Oct-09, This document describes the Namespace Identifier (NID) 'cablelabs' for Uniform Resource Names (URNs) used to identify resources published by Cable Television Laboratories, Inc. (CableLabs). CableLabs specifies and manages resources that utilize this URN identification model. Management activities for these and other resource types are handled by the manager of the CableLabs' Assigned Names and Numbers registry. "Proxy Mobile IPv6 Management Information Base", Glenn Mansfield, Kazuhide Koide, Sri Gundavelli, Aramoto Masafumi, 12-Jul-09, This memo defines a portion of the Management Information Base (MIB), the Proxy Mobile-IPv6 MIB, for use with network management protocols in the Internet community. In particular, the Proxy Mobile-IPv6 MIB will be used to monitor and control the mobile access gateway (MAG) node and the local mobility anchor (LMA) functions of a Proxy Mobile IPv6 (PMIPv6) entity. "Camellia Cipher Suites for TLS", Akihiro Kato, Masayuki Kanda, Satoru Kanno, 5-Apr-09, This document specifies a set of cipher suites for the Transport Security Layer (TLS) protocol to support the Camellia encryption algorithm as a block cipher. It amends the ciphersuites originally specifed in RFC 4132 by counterparts using the newer cryptographic hash algorithms from the SHA-2 familiy. This document obsoletes RFC 4132. "BGP Class of Service Interconnection", Thomas Martin Knoll, 9-Nov-09, This document focuses on Class of Service Interconnection at inter- domain interconnection points. It specifies two new transitive attributes, which enable adjacent peers to signal Class of Service Capabilities and certain Class of Service admission control Parameters. The new "CoS Capability" is deliberately kept simple and denotes the general EF, AF Group BE and LE forwarding support across the advertising AS. The second "CoS Parameter Attribute" is of variable length and contains a more detailed description of available forwarding behaviours using the PHB id Code encoding. Each PHB id Code is associated with rate and size based traffic parameters, which will be applied in the ingress AS Border Router for admission control purposes to a given forwarding behaviour. "Bulk Re-registration for Proxy Mobile IPv6", Domagoj Premec, Sri Gundavelli, Kent Leung, Suresh Krishnan, Basavaraj Patil, 7-Oct-09, Proxy Mobile IPv6 specification requires the Mobile Access Gateway (MAG) to send a separate Proxy Binding Update (PBU) message to the Local Mobility Agent (LMA) for each mobile node (MN) to renew the MN's mobility binding. This document defines a mechanism by which a MAG can update the mobility bindings of multiple MNs attached to it with a single PBU message to the serving LMA. This document also specifies a new mobility option that can be used by the mobility entities in a Proxy Mobile IPv6 domain for carrying the group affiliation of a mobile node in any of the mobility signaling messages. "A Session Initiation Protocol (SIP) Load Control Event Package", Charles Shen, Henning Schulzrinne, Arata Koike, 25-Oct-09, This document defines a load control event package for the Session Initiation Protocol (SIP). It allows SIP servers to distribute user load control information to SIP servers. The load control information can throttle outbound calls based on their destination domain, telephone number prefix or for a specific user. The mechanism helps to prevent signaling overload and complements feedback-based SIP overload control efforts. "Teredo Extensions", Dave Thaler, 9-Nov-09, This document specifies a set of extensions to the Teredo protocol. These extensions provide additional capabilities to Teredo, including support for more types of Network Address Translations (NATs), and support for more efficient communication. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 12, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "Updated Specification of the IPv4 ID Field", Joseph Touch, Matt Mathis, 13-Jul-09, The IPv4 Identification (ID) field enables fragmentation and reassembly, and as currently specified is required to be unique within the maximum lifetime on all IP packets. If enforced, this uniqueness requirement would limit all connections to 6.4 Mbps. Because this is obviously not the case, it is clear that existing systems violate the current specification. This document updates the specification of the IP ID field to more closely reflect current practice and to more closely match IPv6, so that the field is defined only when a packet is actually fragmented and that fragmentation occurs only at originating hosts or their equivalent. When fragmentation occurs, this document recommends that the ID field be unique within the reordering context, rather than an arbitrary, unenforced upper bound on packet lifetime. "Trustworthy Location Information", Hannes Tschofenig, Henning Schulzrinne, Bernard Aboba, 13-Jul-09, For some location-based applications, such as emergency calling or roadside assistance, it appears that the identity of the requestor is less important than accurate and trustworthy location information. To ensure adequate help location has to be left untouched by the end point or by entities in transit. This document lists different threats, an adversary model, outlines three frequentlly discussed solutions and discusses operational considerations. Finally, the document concludes with a suggestion on how to move forward. "Mapping and interworking of Diversion information Between Diversion and History-Info Headers in the Session Initiation Protocol (SIP)", Marianne Mohali, 24-Jun-09, The Diversion header is not standardized but widely used to convey diverting information in Session Initiation Protocol (SIP) signaling. This informational document proposes a way to interwork call diversion information contained in Diversion header with a History- Info header. In addition, an interworking policy is proposed to manage the headers coexistence. The History-Info header is described in [RFC4244] and the Diversion header is described in [draft-levy-sip-diversion-09]. Note to the RFC-Editor: The reference to this draft should be replaced by the Historic RFC reference (work in progress). Since the Diversion header is used in many existing networks implementations for transport of diversion information and its interworking with standardized solutions is not obvious, an interworking recommendation is needed. "RTP Payload Format for the iSAC Codec", Pascal Huart, Tina le Grand, Paul Jones, 16-Oct-09, iSAC is a proprietary wideband speech and audio codec developed by Global IP Solutions, suitable for use in Voice over IP applications. This document describes the payload format for iSAC generated bit streams within a Real-Time Protocol (RTP) packet. Also included here are the necessary details for the use of iSAC with the Session Description Protocol (SDP). "Border Router Discovery Protocol (BRDP) based Address Autoconfiguration", Teco Boot, Arjen Holtzer, 13-Jul-09, Mobile Ad hoc Networks (MANET) may be attached to a fixed infrastructure network, like the Internet. This document specifies a mechanism for Border Router discovery and utilization in such a subordinate, possibly multi-homed, MANET. It provides facilities for choosing preferred Border Router(s) and configuring IP address(es) needed for communication between MANET nodes and nodes on the Internet via the selected Border Router. Autonomous MANETs do not have Border Routers; a self-sufficient Address Autoconfiguration mechanism for Autonomous MANETs is defined as well. "FTP Command and Extension Registry", John Klensin, Alfred Hoenes, 17-Dec-09, Every version of the FTP specification has added a few new commands, with the early ones summarized in RFC 959. RFC 2389 established a mechanism for specifying and negotiating FTP extensions. The number of extensions, both supported by the mechanism and some that are not, continues to increase. An IANA registry of FTP Command and Feature names is established to reduce the likelihood of conflict of names and the consequent ambiguity. This specification establishes that registry. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 20, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "HIP (Host Identity Protocol) Immediate Carriage and Conveyance of Upper- layer Protocol Signaling (HICCUPS)", Pekka Nikander, Gonzalo Camarillo, Jan Melen, 20-Aug-09, This document defines a new HIP (Host Identity Protocol) packet type called DATA. HIP DATA packets are used to securely and reliably convey arbitrary protocol messages over the Internet and various overlay networks. "Dynamic Host Configuration Protocol (DHCPv6) Option for Dual-Stack Lite", David Hankins, Tomasz Mrugalski, 12-Nov-09, This document describes how Dual-Stack Lite configuration (the Softwire Concentrator (SC)'s address) can be obtained by a Softwire Initiator (SI) via DHCPv6. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 16, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "Auto Issued X.509 Certificate Mechanism (AIXCM)", Thierry Moreau, 6-Aug-08, The Transport Layer Security (TLS) protocol does not support the use of client public key pairs without X.509 security certificates. This document circumvents this limitation: an end-entity has access to the public domain private key of a dummy (or "explicitly meaningless") Certification Authority (CA), and can thus freely issue an X.509 security certificate for interoperability purposes. Given these workaround requirement and solution approach, the document limits itself to the strict minimal set of standardization provisions. This supports the orderly cohabitation of auto issued certificates and normal TLS traffic relying on the full Public Key Infrastructure (PKI) model. "GSS-API: Delegate if approved by policy", Love Astrand, Sam Hartman, 15-Jan-09, Several GSS-API applications work in a multi-tiered architecture, where the server takes advantage of delegated user credentials to act on behalf of the user and contact additional servers. In effect, the server acts as an agent on behalf of the user. Examples include web applications that need to access e-mail or file servers as well as CIFS file servers. However, delegating the user credentials to a party who is not sufficiently trusted is problematic from a security standpoint. Kerberos provides a flag called OK-AS-DELEGATE that allows the administrator of a Kerberos realm to communicate that a particular service is trusted for delegation. This specification adds support for this flag and similar facilities in other authentication mechanisms to GSS-API (RFC 2743). "Application of RFC 2231 Encoding to Hypertext Transfer Protocol (HTTP) Header Fields", Julian Reschke, 27-Dec-09, By default, message header field parameters in Hypertext Transfer Protocol (HTTP) messages can not carry characters outside the ISO- 8859-1 character set. RFC 2231 defines an escaping mechanism for use in Multipurpose Internet Mail Extensions (MIME) headers. This document specifies a profile of that encoding suitable for use in HTTP. "Alert-Info URNs for the Session Initiation Protocol (SIP)", Denis Alexeitsev, Laura Liess, Roland Jesske, Martin Huelsemann, Alan Johnston, 13-Jul-09, The Session Initiation Protocol (SIP) supports the capability to provide a reference to the alternative ringback tone (RBT) for caller, or ring tone (RT) for callee using the Alert-Info header. However, the reference addresses only the network resources with specific rendering properties. There is currently no support for predefined standard identifiers for ringback tones or semantic indications without tied rendering. To overcome this limitations and support new applications a family of the URNs is defined in this specification. "Inter-Technology Handoff support in Mobile Node for Proxy Mobile IPv6", Hidetoshi Yokota, Sri Gundavelli, Kent Leung, 26-Oct-09, Proxy Mobile IPv6 supports a handoff between different access technologies, by which the assigned IP address is preserved regardless of the access technology type. From the perspective of the mobile node, this involves the change of the network interfaces, through which the IP address is assigned and the IP session is established. Some implementations, however, do not assume this interface switching in the middle of the session and it could cause a disconnection by the event of unavailability of the current interface; hence it is not guaranteed to be able to maintain the IP session simply by assigning the same IP address to the new interface. This document analyzes the handling of the network interfaces on the mobile node and presents several measures to avoid a disconnection due to the interface switching. "The Metalink Download Description Format", Anthony Bryan, Metalinker Project, Neil McNab, Peter Poeml, 11-Jan-10, This document specifies Metalink, an XML-based download description format. Metalink describes download locations (mirrors), checksums, and other information. Clients can transparently use this information to reliably transfer files. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 15, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "SOS Uniform Resource Identifier (URI) Parameter for Marking of Session Initiation Protocol (SIP) Requests related to Emergency Services", Milan Patel, 26-Oct-09, This document defines a new Session Initiation Protocol (SIP) Uniform Resource Identifier (URI) parameter intended for marking SIP registration requests related to emergency services. The URI parameter is extensible to allow future values to be defined if required by other use cases that require specific SIP registrations to be distinctly identified. The usage of this new URI parameter complements the usage of the Service Uniform Resource Name (URN) and is not intended to replace it. "Delay-Tolerant Networking Metadata Extension Block", Susan Symington, 12-Nov-09, This document defines an extension block that may be used with the DTN Bundle Protocol. This Metadata Extension Block is designed to carry additional information that DTN nodes can use to make processing decisions regarding bundles, such as deciding whether to store a bundle or determining to which nodes to forward a bundle. The metadata that is carried in a metadata block must be formatted according to the metadata type that is identified in the block's metadata type field. One specific metadata type, for carrying URIs as metadata, is defined in this document. Other metadata types may be defined in separate documents. 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. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 16, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "BU/BA Based Prefix Delegation Support for Mobile Networks", Behcet Sarikaya, Frank Xia, 13-Jul-09, This document defines prefix delegation support for mobile networks. Mobile Router dynamically requests its Mobile Network Prefixes from its Home Agents using Binding Update both at the home link and at the visited links. Home agents get the prefixes delegated using DHCPv6 Prefix Delegation or by other means and reply to the Mobile Router with Binding Acknowledgement. "Multicast Support Requirements for Proxy Mobile IPv6", Hui Deng, Gang Chen, Thomas Schmidt, Pierrick Seite, Peng Yang, 13-Jul-09, This document summarizes requirements for multicast listener support in Proxy Mobile IPv6 (PMIPv6) scenarios. In correspondance to PMIPv6, multicast mobility management requirements do not request any active participation of the mobile node. "IPv4 Run-Out and IPv4-IPv6 Co-Existence Scenarios", Jari Arkko, Mark Townsley, 13-Jul-09, When IPv6 was designed, it was expected that the transition from IPv4 to IPv6 would occur more smoothly and expeditiously than experience has revealed. The growth of the IPv4 Internet and predicted depletion of the free pool of IPv4 address blocks on a foreseeable horizon has highlighted an urgent need to revisit IPv6 deployment models. This document provides an overview of deployment scenarios with the goal of helping to understand what types of additional tools the industry needs to assist in IPv4 and IPv6 co-existence and transition. This document was originally created as input to the Montreal co- existence interim meeting in October 2008, which led to the rechartering of the Behave and Softwire working groups to take on new IPv4 and IPv6 coexistence work. This document is published as a historical record of the thinking at the time. "RTP Payload Format for MPEG-4 Audio/Visual Streams", Malte Schmidt, Frans Bont, Stefan Doehla, Jaehwan Kim, 23-Dec-09, This document describes Real-Time Transport Protocol (RTP) payload formats for carrying each of MPEG-4 Audio and MPEG-4 Visual bitstreams without using MPEG-4 Systems. For the purpose of directly mapping MPEG-4 Audio/Visual bitstreams onto RTP packets, it provides specifications for the use of RTP header fields and also specifies fragmentation rules. It also provides specifications for Media Type registration and the use of Session Description Protocol (SDP). Comments are solicited and should be addressed to the working group's mailing list at avt@ietf.org and/or the author(s). Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 24, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "Comparison of OSPF-MDR and OSPF-MPR", Richard Ogier, 2-Sep-09, This document presents a comparison of two proposed MANET extensions of OSPF: OSPF-MDR and OSPF-MPR. It includes a qualitative comparison, which discusses the different design choices and how they can affect performance and scalability, and a simulation comparison. "Comparison of OSPF-MDR and OSPF-OR", Richard Ogier, 2-Sep-09, This document presents a comparison of two proposed MANET extensions of OSPF: OSPF-MDR and OSPF-OR. It includes a simulation comparison and a qualitative comparison, which discusses the different design choices and how they can affect performance and scalability. "Using POST to add Members to Web Distributed Authoring and Versioning (WebDAV) Collections", Julian Reschke, 22-Nov-09, The Hypertext Transfer Protocol (HTTP) Extensions for the Web Distributed Authoring and Versioning (WebDAV) do not define the behavior for the "POST" method when applied to collections, as the base specification (HTTP) leaves implementers lots of freedom for the semantics of "POST". This has led to a situation where many WebDAV servers do not implement POST for collections at all, although it is well suited to be used for the purpose of adding new members to a collection, where the server remains in control of the newly assigned URL. As a matter of fact, the Atom Publishing Protocol (AtomPub) uses POST exactly for that purpose. On the other hand, WebDAV-based protocols such as the Calendar Extensions to WebDAV (CalDAV) frequently require clients to pick a unique URL, although the server could easily perform that task. This specification defines a discovery mechanism through which servers can advertise support for POST requests with the aforementioned "add collection member" semantics. "Scalable Multihoming across IPv6 Local-Address Routing Zones Global-Prefix/Local-Address Stateless Address Mapping (SAM)", Remi Despres, 13-Jul-09, The continuous growth of routing tables in the core of Internet is a challenge. It would become overwhelming if each multihomed customer site would need a provider independent prefix to take full advantage of its multihoming. IPv6 has the potential to solve this problem, but a complete specification is still missing. This draft proposes an approach for a solution. The Stateless Address Mapping (SAM) model, introduced for this, is applicable to a hierarchy of routing zones with multihoming permitted at each level, and with each zone using local addresses for its internal routing plan. End-to-end transparency of the Internet is maintains across these local-address zones, thanks to a systematic encapsulation of global-address packets into local-address packets. Local addresses are statelessly derived from prefixes found in global addresses, and from static parameters of traversed zones. Global prefixes delegated by a zone to its child interfaces can be obtained by autoconfiguration, thanks to to a bidirectional correspondence between SAM local addresses and SAM global prefixes. Deployment can be incremental. "The OAuth Core 1.0 Protocol", Eran Hammer-Lahav, 3-Dec-09, OAuth provides a method for clients to access server resources on behalf of a resource owner (such as a different client or an end- user). It also provides a process for end-users to authorize third party access to their server resources without sharing their credentials (typically, a username and password pair), using user- agent redirections. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 6, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "A Profile for AS Adjacency Attestation Objects", Geoff Huston, George Michaelson, 3-Dec-09, This document describes a profile for AS Adjacency Attestation Objects (AAOs). An AAO is a digitally signed object that provides a means of verifying that an AS holder has made an attestation that it has a inter-domain routing adjacency with one or more other AS's, with the associated inference that this AS is prepared to announce or receive routes with these adjacent AS's in the inter-domain domain environment. "Clearance Sponsor Attribute", Sean Turner, 20-Oct-09, This document defines the clearance sponsor attribute. This attribute may be included in locations or protocols that support X.500 attributes. "Device Owner Attribute", Sean Turner, 19-Oct-09, This document defines the Device Owner attribute. This attribute may be included in locations or protocols that support ASN.1 attributes. "IANA Considerations for IAX: Inter-Asterisk eXchange Version 2", Ed Guy, 5-Oct-08, This document establishes the IANA registries for 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. "Routing and Addressing in Next-Generation EnteRprises (RANGER)", Fred Templin, 26-Oct-09, RANGER is an architectural framework for scalable routing and addressing in next generation enterprise networks. The term "enterprise network" within this context extends to a wide variety of use cases and deployment scenarios, where an "enterprise" can be as small as a SOHO network, as dynamic as a Mobile Ad-hoc Network, as complex as a multi-organizational corporation, or as large as the global Internet itself. Such networks will require an architected solution for the coordination of routing and addressing plans with accommodations for scalability, provider-independence, mobility, multi-homing and security. These considerations are particularly true for existing deployments, but the same principles apply even for clean-slate approaches. The RANGER architecture addresses these requirements, and provides a comprehensive framework for IPv6/IPv4 coexistence. "Defining Well-Known URIs", Mark Nottingham, Eran Hammer-Lahav, 29-Dec-09, This memo defines a path prefix for "well-known locations", "/.well- known/" in selected URI schemes. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 3, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "RADIUS Attributes for IEEE 802.16 Privacy Key Management Version 1 (PKMv1) Protocol Support", Glen Zorn, 27-Aug-09, This document defines a set of RADIUS Attributes which are designed to provide RADIUS support for IEEE 802.16 Privacy Key Management Version 1. "IPv6 Ephemeral Addresses", Hiroshi Kitamura, Shingo Ata, Masayuki Murata, 28-Jul-09, This document describes a new address type that is called "Ephemeral Addresses". Ephemeral Addresses are designed to be used as clients' source addresses of TCP / UDP sessions. An idea Ephemeral Addresses is simple enough. They are achieved by deriving existing "ephemeral ports" specifications. In other words, they are achieved by naturally upgrading their concept from the port space to the address space. Since Ephemeral Addresses functions are implemented only in the kernel side of the OS, we can use the Ephemeral Addresses functions in current exiting enormous client applications without modifying them. Ephemeral Addresses functions can contribute to various types of security enhancements that include privacy protections etc. "Asymmetric Key Packages", Sean Turner, 20-Oct-09, This document defines the syntax for private key information and a content type for it. Private-key information includes a private key for a specified public-key algorithm and a set of attributes. The Cryptographic Message Syntax (CMS), as defined in RFC 3852, can be used to digitally sign, digest, authenticate, or encrypt the asymmetric key format content type. This document updates RFC 5208. "Guidelines for Internationalized Email Deployment", Jiankang Yao, XiaoDong Lee, 12-Jul-09, Key RFCs for internationalized email address have been published, specifying the basic protocols for using it. This document provides some guidelines for implementing the email systems that support Email Address Internationalization (EAI). Its aim is to give some suggestions and help the engineers to implement these protocols. "RTP Payload Format for Bluetooth's SBC audio codec", Christian Hoene, Frans Bont, 15-Dec-09, This document specifies a Real-time Transport Protocol (RTP) payload format to be used for the low complexity subband codec (SBC), which is the mandatory audio codec of the Advanced Audio Distribution Profile (A2DP) Specification written by the Bluetooth(r) Special Interest Group (SIG). The payload format is designed to be able to interoperate with existing Bluetooth A2DP devices, to provide high streaming audio quality, interactive audio transmission over the internet, and ultra-low delay coding for jam sessions on the internet. This document contains also a media type registration which specifies the use of the RTP payload format. "Using mLDP through a Backbone where there is no Route to the Root", IJsbrand Wijnands, Eric Rosen, Maria Napierala, 9-Oct-09, The control protocol used for constructing Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths ("MP LSPs") contains a field that identifies the address of a "root node". Intermediate nodes are expected to be able to look up that address in their routing tables. However, if the route to the root node is a BGP route, and the intermediate nodes are part of a BGP-free core, this is not possible. This document specifies procedures which enable a MP LSP to be constructed through a BGP-free core. In these procedures, the root node address is temporarily replaced by an address which is known to the intermediate nodes. "Renumbering still needs work", Brian Carpenter, Randall Atkinson, Hannu Flinck, 22-Oct-09, This document reviews the existing mechanisms for site renumbering for both IPv4 and IPv6, and identifies operational issues with those mechanisms. It also summarises current technical proposals for additional mechanisms. Finally there is a gap analysis identifying possible areas for future work. "Learning the IPv6 Prefix of a Network's IPv6/IPv4 Translator", Dan Wing, 26-Oct-09, Some IPv6 applications obtain IPv4 address literals and want to communicate with those IPv4 hosts through an IPv6/IPv4 translator. The IPv6 application can send an IPv6 packet through the translator if it knows the IPv6 prefix of the IPv6/IPv4 translator. In many IPv6/IPv4 translation deployments, that IPv6 prefix is not fixed; rather, the prefix is chosen by the network operator. This specification provides three methods for a host to learn the IPv6 prefix of its IPv6/IPv4 translator. Unicast, any-source multicast (ASM), and source-specific multicast (SSM) are supported. "An extension to RELOAD to support Direct Response and Relay Peer routing", XingFeng Jiang, Ning Zong, Roni Even, Yunfei Zhang, 4-Oct-09, This document proposes an optional extension to RELOAD to support direct response and relay peer routing modes. RELOAD recommends symmetric recursive routing for routing messages. The new optional extensions provide a shorter route for responses reducing the overhead on intermediary peers and describe the potential cases where these extensions can be used. "LDAP schema for storing SCRAM secrets", Alexey Melnikov, 8-Nov-09, This memo describes how the "authPassword" LDAP attribute can be used for storing secrets used by the Salted Challenge Response (SCRAM) mechanism in the Simple Authentication and Security Layer (SASL) framework. Note A revised version of this draft document will be submitted to the RFC editor as a Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested, and should be sent to sasl@ietf.org mailing list. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 12, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "PMIPv6 Extensions for Multicast", Hitoshi Asaeda, Pierrick Seite, Jinwei Xia, 13-Jul-09, This document describes Proxy Mobile IPv6 (PMIPv6) extensions to support IP multicast. The Mobile Access Gateway (MAG) and the Local Mobility Anchor (LMA) are the mobility entities defined in the PMIPv6 protocol. The proposed protocol extension provides; 1) a dedicated multicast tunnel (M-Tunnel) between LMA and MAG, and 2) local routing to deliver IP multicast packets for mobile nodes. This document defines the roles of LMA and MAG to support IP multicast for the mobile nodes. "Use of the IPv6 Flow Label as a Transport-Layer Nonce to Defend Against Off-Path Spoofing Attacks", Steven Blake, 26-Oct-09, TCP and other transport-layer protocols are vulnerable to spoofing attacks from off-path hosts. These attacks can be prevented through the use of cryptographic authentication. However, it is difficult to use cryptographic authentication in all circumstances. A variety of obfuscation techniques -- such as initial sequence number randomization and source port randomization -- increase the effort required of an attacker to successfully guess the packet header fields which uniquely identify a transport connection. This memo proposes the use of the IPv6 Flow Label field as a random, per- connection nonce value, to add entropy to the set of packet header fields used to identify a transport connection. This mechanism is easily implementable, allows for incremental deployment, and is fully compliant with the rules for Flow Label use defined in RFC 3697. "Considerations for IPv6 Address Selection Policy Changes", Tim Chown, 13-Jul-09, Where the source and/or destination node of an IPv6 communication is multi-addressed, a mechanism is required for the initiating node to select the most appropriate address pair for the communication. RFC 3484 (IPv6 Default Address Selection) [RFC3484] defines such a mechanism for nodes to perform source and destination address selection. While RFC3484 recognised the need for implementations to be able to change the policy table, it did not define how this could be achieved. Requirements have now emerged for administrators to be able to dynamically change the RFC 3484 policy tables from a central control point, and for nomadic hosts to be able to obtain the policy for the network that they are currently attached to without manual user intervention. This text discusses considerations for such policy changes, including examples of cases where a change of policy is required, and the likely frequency of such policy changes. This text also includes some discussion on the need to also update RFC 3484, where default policies are currently defined. "Security implications of Network Address Translators (NATs)", Fernando Gont, Pyda Srisuresh, 27-Oct-09, This document analyzes the security implications of Network Address Translators (NATs). It neither deprecates nor encourages the use of NATs, but rather aims to raise awareness about their security implications, and possible implementation approaches to improve their security. "On the generation of TCP timestamps", Fernando Gont, 17-Sep-09, This document describes an algorithm for selecting the timestamps (TS value) used for TCP connections that use the TCP timestamp option, such that the resulting timestamps are monotonically-increasing across connections that involve the same four-tuple {local IP address, local TCP port, remote IP address, remote TCP port}. The properties of the algorithm are such that it reduces the possibility of an attacker of guessing the exact value. Additionally, it describes an algorithm for processing incoming SYN segments that allows higher connection-establishment rates between any two TCP endpoints when a TCP timestamps option is present in the incoming SYN segment. "Creation of a Registry for DNS SRV Record Service Prefixes", Olafur Gudmundsson, Alfred Hoenes, 26-Oct-09, The DNS SRV record has been specified in RFC 2052 and RFC 2782. These two RFCs did not specify an IANA registry for names of the services using SRV records as defined by various protocols. This document creates such a registry and populates it. "On Secure Neighbor Discovery Proxying Using 'Symbiotic' Relationship", Wassim Haddad, Mats Naslund, 29-Jul-09, This document introduces a simple mechanism which enables a host using a cryptographically generated IPv6 address to delegate the task of secure neighbor discovery to another node, i.e., proxying, by means of establishing a 'symbiotic' relationship with that node. "Enabling Source Address Verification via Prefix Reachability Detection", Wassim Haddad, Mats Naslund, Christian Vogt, 25-Oct-09, In this memo, we introduce an approach called "Prefix Reachability Detection", which aims to address certain man-in-the middle misbehavior problems and enable a location-based authentication. "DHCPv6 and CGA Interaction: Problem Statement", Sheng Jiang, 18-Sep-09, This document describes potential issues in the interaction between DHCPv6 and Cryptographically Generated Addresses (CGAs). Firstly, the scenario of using CGAs in DHCPv6 environments is discussed. Some operations are clarified for the interaction of DHCPv6 servers and CGA-associated hosts. We then also discuss how CGAs and DHCPv6 may have mutual benefits for each other, including using CGAs in DHCPv6 operations to enhance its security features and using DHCPv6 to provide the CGA generation function. "Harmless IPv6 Address State Extension (Uncertain State)", Hiroshi Kitamura, Shingo Ata, Masayuki Murata, 28-Jul-09, This document describes a new IPv6 address state called "Uncertain" address state as an extension of IPv6 address state specification. "Uncertain" address state is designed to introduce two functionalities. One is to achieve "Temporary Address Reservation" function. The other is to avoid a DAD (Duplicate Address Detection) time consuming problem for dynamically created addresses. New "Uncertain" Address State is inserted between "Tentative" address state and "Valid" address state. After "Tentative" address state (DAD operation has finished) for a newly created address, its state will enter to "Uncertain" address state. While an address stay at "Uncertain" address state, the address is behaved as if it is temporary reserved by the node exclusively. (The other nodes can not obtain such a reserved address.) When it becomes really necessary for the node to utilize the temporary reserved address, its address state is changed into "Valid" address state without accompanying time consuming DAD operation. By these procedures, we can avoid the DAD problem. "Real-time Transport Control Protocol (RTCP) in Overlay Multicast", Jegadish Devadoss, Joerg Ott, Igor Curcio, 26-Oct-09, The Real-time Transport Control Protocol (RTCP) is designed to operate along with Real-time Transport Protocol (RTP) in unicast, single-source multicast and any-source multicast environments. With the availability of overlay multicast and Application Layer Multicast (ALM), the suitability of RTCP in such environments needs to be analyzed. The applicability of the existing RTCP reporting architectures in overlay multicast and ALM environments are investigated and the new features that may be required are discussed in this document. "Problems with the use of IPsec as the security protocol for Mobile IPv6", Basavaraj Patil, Domagoj Premec, Charles Perkins, Hannes Tschofenig, 26-Oct-09, Mobile IPv6 as specified in RFC3775 relies on IPsec for securing the signaling messages and user plane traffic between the mobile node and home agent. An IPsec SA between the mobile node and the home agent provides security for the mobility signaling. Use of IPsec for securing the data traffic between the mobile node and home agent is optional. This document analyses the implications of the design decision to mandate IPsec as the default security protocol for Mobile IPv6 and consequently Dual-stack Mobile IPv6 and recommends revisiting this decision in view of the experience gained from implementation and adoption in other standards bodies. "BGP Prefix Origin Validation", Pradosh Mohapatra, John Scudder, David Ward, Randy Bush, Rob Austein, 26-Oct-09, A BGP route associates an address prefix with a set of autonomous systems (AS) that identify the interdomain path the prefix has traversed in the form of BGP announcements. This set is represented as the AS_PATH attribute in BGP and starts with the AS that originated the prefix. To help reduce well-known threats against BGP including prefix hijacking and monkey-in-the-middle attacks, one of the security requirements is the ability to validate the origination AS of BGP routes. More specifically, one needs to validate that the AS number claiming to originate an address prefix (as derived from the AS_PATH attribute of the BGP route) is in fact authorized by the prefix holder to do so. This document describes a simple validation mechanism to partially satisfy this requirement. "IPv4 Support for DSMIPv6 IPv6 Home Link", Fuad Abinader, Domagoj Premec, Jouni Korhonen, 8-Oct-09, Mobile IPv6 for Dual Stack Hosts and Routers enables mobility for the mobile node's IPv6 home address or prefix as well as an IPv4 home address, irrespective of the IP version supported on the link that the mobile node is attached to. The home agent maintains binding cache entries for the IPv6 and IPv4 home addresses assigned to the mobile node when the mobile node is connected via a foreign link. The binding cache entries are deprecated when the mobile node attaches to its home link. This document addresses an issue related to the de-registration procedure and the continued connectivity for the IPv4 home address when the mobile node attaches to its IPv6-only home link. "A Uniform Resource Name (URN) for Early Warning Emergency Services and Location-to-Service Translation (LoST) Protocol Usage", Brian Rosen, Henning Schulzrinne, Hannes Tschofenig, 13-Jul-09, The Common Alerting Protocol (CAP) is an XML document format for exchanging emergency alerts and public warnings. Different organizations issue alerts for specific geographic regions. The Location-to-Service Translation (LoST) protocol provides a way to discover servers that distribute these alerts for a geographical region. This document defines the Service Uniform Resource Names (URN)s for warnings in the same way as they have been defined with RFC 5031 for citizen-to-authority emergency services. Additionally, this document suggests to use LoST for the discovery of servers distributing alerts. "NAT444 with ISP Shared Address", Yasuhiro Shirasaki, Shin Miyakawa, Akira Nakagawa, Jiro Yamaguchi, Hiroyuki Ashida, 7-Sep-09, This document describes one of the network models that are designed for smooth transition to IPv6. It is called NAT444 model. NAT444 model is composed of IPv6, and IPv4 with Large Scale NAT (LSN). NAT444 is the only scheme not to require replacing Customer Premises Equipment (CPE) even if IPv4 address exhausted. But it must be noted that NAT444 has serious restrictions i.e. it limits the number of sessions per CPE so that rich applications such as AJAX and RSS feed cannot work well. Therefore, IPv6 which is free from such a difficulty has to be introduced into the network at the same time. In other words, NAT444 is just a tool to make IPv6 transition easy to be swallowed. It is designed for the days IPv4 and IPv6 co-existence. "Diameter Routing Problem Statement", Tina Tsou (Ting ZOU), 13-Jul-09, This document describes use cases that suggest a requirement to be able to add constraints to the existing Diameter routing mechanisms so that subsequent messages in a session pass through specific proxies that were on the initial path that set up the session. Routing between these proxies may use the present Diameter rules. "Virtual IPv6 Connectivity for IPv4-Only Networks", Christian Vogt, Alain Durand, 26-Oct-09, Although the impetus to invest in interworking between IP versions 4 and 6 is initially on the side of early IPv6 adopters, more substantial IPv6 deployment in the future will shift this impetus towards the side of the legacy IPv4 Internet. However, interworking techniques for IPv4-only networks are as yet largely unexplored. This document proposes Virtual IPv6 Connectivity, a technique for IPv4-only networks to communicate with the IPv6 Internet. "The A+P Approach to the IPv4 Address Shortage", Randy Bush, 26-Oct-09, We are facing the exhaustion of the IANA IPv4 free IP address pool. Unfortunately, IPv6 is not yet deployed widely enough to fully replace IPv4, and it is unrealistic to expect that this is going to change before we run out of IPv4 addresses. Letting hosts seamlessly communicate in an IPv4-world without assigning a unique globally routable IPv4 address to each of them is a challenging problem. This draft discusses the possibility of address sharing by treating some of the port number bits as part of an extended IPv4 address (Address plus Port, or A+P). Instead of assigning a single IPv4 address to a customer device, we propose to extended the address by "stealing" bits from the port number in the TCP/UDP header, leaving the applications a reduced range of ports. This means assigning the same IPv4 address to multiple clients (e.g., CPE, mobile phones), each with its assigned port-range. In the face of IPv4 address exhaustion, the need for addresses is stronger than the need to be able to address thousands of applications on a single host. If address translation is needed, the end-user should be in control of the translation process - not some smart boxes in the core. "The Solution for Pmipv6 Multicast Service", YuanKui ZHAO, Pierrick Seite, 13-Jul-09, To mobility scenario, multicast service is a valuable feature to those mobile customers. We need to consider how to integrate current multicast service in PMIPv6 domain. This draft will introduce this kind of solution about proxy mobile multicast. It explains the system solution and framework about how to provide the proxy mobile multicast system. "Line identification in IPv6 Router Solicitation messages", Suresh Krishnan, Alan Kavanagh, Sven Ooghe, Balazs Varga, 14-Jul-09, In ethernet and PON based aggregation networks, several subscriber premises may be connected to the same interface of an edge router. This document proposes a method for the edge router to identify the subscriber premises using the contents of the received router solicitation messages. "Multicast VPN fast upstream failover", Thomas Morin, Yakhov Rekhter, Rahul Aggarwal, Wim Henderickx, Praveen Muley, Ray Qiu, 26-Oct-09, This document defines multicast VPN extensions and procedures that allow fast failover for upstream failures, by allowing downstream PEs to take into account the status of Provider-Tunnels (P-tunnels) when selecting the upstream PE for a VPN multicast flow, and extending BGP MVPN routing so that a C-multicast route can be advertised toward a standby upstream PE. "IP Router Alert Considerations and Usage", Francois Le Faucheur, 26-Oct-09, The IP Router Alert Option is an IP option that alerts transit routers to more closely examine the contents of an IP packet. RSVP, PGM, IGMP/MLD, MRD and GIST are some of the protocols that make use of the IP Router Alert option. This document discusses security aspects and usage guidelines around the use of the current IP Router Alert option. Specifically, it provides recommendation against using the Router Alert in the end-to-end open Internet as well as identify controlled environments where protocols depending on Router Alert can be used safely. It also provides recommendation about protection approaches for Service Providers. Finally it provides brief guidelines for Router Alert implementation on routers. "BFD Generic Cryptographic Authentication", Manav Bhatia, Vishwas Manral, 11-Nov-09, This document proposes an extension for Bidirectional Forwarding Detection (BFD) to allow the use of any cryptographic authentication algorithm in addition to the already documented authentication schemes, described in the base specification. Although this document has been written specifically to introduce two new Authentication types it describes how BFD can use National Institute of Standards and Technology (NIST) Secure Hash Standard family of algorithms (SHS) to authenticate the control packets, the method described in this document is generic and can be used to extend BFD to support any cryptographic hash function in the future. "Hierarchical OLSR", Yannick Lacharite, Maoyu Wang, Pascale Minet, Thomas Clausen, 13-Jul-09, This document describes the Hierarchical Optimized Link State Routing (HOLSR) mechanism for heterogeneous mobile ad hoc networks. In this specification a heterogeneous mobile ad hoc network is defined as a network of mobile routers that are characterized by different communication capabilities, such as communication channels, processing powers or energy levels. The HOLSR mechanism is an extension to the OLSRv2 protocol. HOLSR takes advantage of the router's distinct communications capabilities to reduce the routing control overhead in large heterogeneous ad hoc networks, thus improving the performance of the routing mechanism. More precisely, HOLSR defines a hierarchy in the network and presents a routing scheme for this hierarchical structure with a better scalability. "An IRI/URI Namespace for International Object Identifiers (OIDs)", John Larmouth, Olivier Dubuisson, 20-Oct-09, This internet draft defines the IRI/URI scheme for International Object Identifiers. The syntax and semantics of the IRI is specified below using the International Object Identifier tree specified in ITU-T X.660: "International Object Identifiers". "The Remote Framebuffer Protocol", Tristan Richardson, John Levine, 30-Jul-09, RFB ("remote framebuffer") is a simple protocol for remote access to graphical user interfaces which allows a client to view and control a window system on another computer. Because it works at the framebuffer level RFB is applicable to all windowing systems and applications. This document describes the protocol used to communicate between an RFB client and RFB server. RFB is the protocol used in VNC, Virtual Network Computing. "vCard XML Schema", Simon Perreault, 13-Jul-09, This document defines the XML schema of the vCard data format. "Single PCN Threshold Marking by using PCN baseline encoding for both admission and termination controls", Daisuke Satoh, Harutaka Ueno, Yukari Maeda, Oratai Phanachet, 10-Sep-09, Pre-congestion notification (PCN) gives early warning of congestion by metering and marking packets in order to protect the quality of service of inelastic flows. PCN traffic load is divide into three pre-congestion states by two rates that [I-D.ietf.pcn.architecture] defines per link: PCN-admissible- and PCN-supportable-rates. PCN admission control and flow termination mechanisms operate in accordance with these three states. [I-D.ietf.pcn.baseline.encoding] defines two PCN encoding states. This document proposes an algorithm for marking and metering by using PCN baseline encoding for both flow admission and flow termination. The ratio of marked packets determines the three link states: no packets marked, some packets marked, and all packets marked. To achieve this marking behaviour, we use two token buckets. One is not used for marking but for a marking switch; the other is used for marking. The token bucket for marking has two thresholds. One is TBthreshold.threshold, already defined in [I-D.ietf-pcn-marking-behaviour], and the other is a new threshold, which is set to be the number of bits of a metered-packet smaller than the token bucket size. Therefore, the new threshold is larger than TBthreshold.threshold. If the amount of tokens is less than TBthreshold.threshold, all the packets are marked as defined in [I-D.ietf-pcn-marking-behaviour]. If the amount of tokens is less than the new threshold and greater than TBthreshold.threshold, one- Nth packets are marked. We evaluated the performance of admission control and flow termination using a simulation. For admission control, the results show that the performance of the algorithm was almost the same as, but slightly inferior to, that of CL [draft-briscoe-tsvwg-cl-phb-03]. For flow termination, the performance of the algorithm was almost the same as CL when the load was 1.2 times the supportable rate, but it was superior to CL when the load was high (two times the supportable rate). Furthermore, in the algorithm, over termination percentages of all the bottleneck links are almost the same in the case of multi-bottleneck. In CL, the over termination percentages of all the bottleneck links are different and those at upstream bottleneck links are higher than those at downstream bottleneck links because of accumulation of marked packets. "A SIP Event Package for Subscribing to Changes to an HTTP Resource", Adam Roach, 18-Dec-09, The Session Initiation Protocol (SIP) is increasingly being used in systems that are tightly coupled with Hypertext Transport Protocol (HTTP) servers for a variety of reasons. In many of these cases, applications can benefit from being able to discover, in near-real- time, when a specific HTTP resource is created, changed, or deleted. This document proposes a mechanism, based on the SIP events framework, for doing so. "HTTP Cache-Control Extensions for Stale Content", Mark Nottingham, 28-Nov-08, This document defines two independent HTTP Cache-Control extensions that allow control over the use of stale responses by caches. "Suite B Certificate and Certificate Revocation List (CRL) Profile", Jerome Solinas, L Zieglar, 1-Jul-09, This document specifies a base profile for X.509 v3 Certificates and X.509 v2 Certificate Revocation Lists (CRLs) for use with the United States National Security Agency's Suite B Cryptography. The reader is assumed to have familiarity with RFC 5280, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile." "Compressed Bundle Header Encoding (CBHE)", Scott Burleigh, 12-Nov-09, This document describes a convention by which Delay-Tolerant Networking (DTN) Bundle Protocol (BP) "convergence-layer" adapters may represent endpoint identifiers in a compressed manner within the primary blocks of bundles, provided those endpoint identifiers conform to the structure prescribed by this convention. CBHE compression is a convergence-layer adaptation. It is opaque to bundle processing. It therefore has no impact on the interoperability of different Bundle Protocol implementations, but instead affects only the interoperability of different convergence layer adaptation implementations. 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. "Real-time Transport Control Protocol Extension Report for Run Length Encoding of Discarded Packets", Joerg Ott, Igor Curcio, Varun Singh, 14-Sep-09, The Real-time Transport Control Protocol (RTCP) is used in conjunction with the Real-time Transport Protocol (RTP) in to provide a variety of short-term and long-term reception statistics. The available reporting may include aggregate information across longer periods of time as well as individual packet reporting. This document specifies a per-packet report metric capturing individual packets discarded from the jitter buffer after successful reception. "Transmission of IPv4 Packets over ISATAP Interfaces", Fred Templin, 24-Mar-09, The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) specifies a Non-Broadcast, Multiple Access (NBMA) interface type for the transmission of IPv6 packets over IPv4 networks using automatic IPv6-in-IPv4 encapsulation. The original specifications make no provisions for the encapsulation and transmission of IPv4 packets, however. This document specifies a method for transmitting IPv4 packets over ISATAP interfaces. "Takeover Suggestion Flag for the ENRP Handle Update Message", Thomas Dreibholz, Xing Zhou, 4-Jan-10, This document describes the Takeover Suggestion Flag for the ENRP_HANDLE_UPDATE message of the ENRP protocol. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 9, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "Bidirectional Forwarding Detection (BFD) with Graceful Restart", Palanivelan A, 1-Dec-09, This document proposes an extension for Bidirectional Forwarding Detection (BFD) to support Graceful restart, in complementing Graceful restart support of the underlying protocol.This shall work consistently irespective of the bfd mode or protocol or the type of restart.This document describes the challenges to bfd in surviving a graceful restart and a generic solution to succeed. "Specifying transport mechanisms in Uniform Resource Identifiers", Lloyd Wood, 25-Oct-09, This document describes a simple extension of the Uniform Resource Identifier (URI) format that allows preferred transport mechanisms, including protocols, ports and interfaces, to be specified as parseable additions to the scheme name. This explicit configuration is beneficial for separation of the HyperText Transfer Protocol (HTTP) from underlying transports, which has been increasingly recognised as useful when a variety of ways of transporting or configuring use of HTTP are available and a choice of mechanism to use must be indicated. "Multi-hop Ad Hoc Wireless Communication", Emmanuel Baccelli, Charles Perkins, 17-Nov-09, This document describes some important characteristics of communication between nodes in a multi-hop ad hoc wireless network. These are not requirements in the sense usually understood as applying to formulation of a requirements document. Nevertheless, protocol engineers and system analysts involved with designing solutions for ad hoc networks must maintain awareness of these characteristics. Status of This Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 21, 2010.Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. "Explicit Notification Extension (ECN) Support for RTP Sessions", Ken Carlberg, Piers O'Hanlon, 13-Jul-09, This document describes a design to support Explicit Congestion Notification (ECN) for the RTP layer. The design defines a means of end-to-end negotiated support of ECN using the Session Description Protocol (SDP) and a new RTCP Extended Report. "draft-kumar-mpls-fec-to-nhlfe-mib-01", Subodh Kumar, Ronald Bonica, 13-Jul-09, This memo defines a portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects for FEC-to-NHLFE for use in Multiprotocol Label Switching (MPLS)network. The MIB module defined in this document is used for configuring, and monitoring Forwarding Equivalence Class (FEC) to Next Hop Label Forwarding Entry (NHLFE) mappings and corresponding actions for use with Multiprotocol Label Switching (MPLS). "Self-organizing network model", Xingwei Wang, XiuShuang Yi, Yu Wang, Ming Dong, Qiang Chen, 18-Nov-09, In this paper, a swarm intelligence based self-organizing network model was introduced to network providers. The problems of the existing network as well as the characteristics of the NGI (Next Generation Internet) were described to illustrate the motivation of the proposed self-organizing network model. A network architecture model based on swarm intelligence was introduced, the used technical terms was defined. The network parameters, network behaviors and node stability under the proposed model were described. Especially, some important QoS routing elements under the proposed model, such as the user QoS routing requirements, link satisfaction degree, utility computation, unicast path and multicast tree evaluation, mathematical model of QoS route optimization and small-world behaviors, were introduced. "Adaptive Routing Protocol", Xingwei Wang, ZhanKao Wen, WeiXin Wu, WeiDong Wang, Yao Fu, 18-Nov-09, This document describes an Adaptive Routing Protocol. It provides a routing protocol of Swarm Intelligence based network model, to a certain extent, this protocol can solve problems accompanied by network expansion and Dynamic network Increasing. This paper presents a routing protocol to adapt the self-organizing network, defines a set of terms and describes the message format and appropriate action sequences. "Secure and Scalable Location Routing Protocol (SSLRP) for Ad Hoc Networks", Xian-wei Zhou, Shuai Du, Xiao-bo Wu, Guang Yang, Jin Jin, Yao Wang, 3-Jan-10, The Secure and Scalable Location Routing Protocol (SSLRP) is a secure and distributed routing protocol designed for ad hoc networks of mobile nodes with location information. Commonly, each node acquires its own geographic position using a mechanism such as the Global Position System (GPS). The SSLRP addresses each node using the hybrid of its multi-level hierarchical address and unique identifier at the moment of network initialization. Certain measures were adopted to ensure security of the network. "The Web Socket protocol", Ian Hickson, 16-Dec-09, The Web Socket protocol enables two-way communication between a user agent running untrusted code running in a controlled environment to a remote host that has opted-in to communications from that code. The security model used for this is the Origin-based security model commonly used by Web browsers. The protocol consists of an initial handshake followed by basic message framing, layered over TCP. The goal of this technology is to provide a mechanism for browser-based applications that need two-way communication with servers that does not rely on opening multiple HTTP connections (e.g. using XMLHttpRequest or