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. IPv6 over Low power WPAN (6lowpan) ---------------------------------- "Compression Format for IPv6 Datagrams in 6LoWPAN Networks", Jonathan Hui, Pascal Thubert, 1-Sep-10, 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. UDP header compression is specified within this framework. "Design and Application Spaces for 6LoWPANs", Eunsook Kim, Dominik Kaspar, Nicolas Chevrollier, JP Vasseur, 28-Jul-10, 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. "Neighbor Discovery Optimization for Low-power and Lossy Networks", Zach Shelby, Samita Chakrabarti, Erik Nordmark, 2-Aug-10, The IETF 6LoWPAN working group defines IPv6 for low-power and lossy networks (LLNs) such as IEEE 802.15.4. This and other similar link technologies have limited or no usage of multicast signaling due to energy conservation. In addition, the wireless network may not strictly follow traditional concept of IP subnets and IP links. IPv6 Neighbor Discovery was not designed for non-transitive wireless links. The traditional IPv6 link concept and heavy use of multicast make the protocol inefficient and sometimes impractical in a low power and lossy network. This document describes simple optimizations to IPv6 Neighbor Discovery, addressing mechanisms and duplicate address detection for 6LoWPAN and similar networks. "Problem Statement and Requirements for 6LoWPAN Routing", Eunsook Kim, Dominik Kaspar, Carles Gomez, Carsten Bormann, 4-Aug-10, 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) ----------------------- "Solution approaches for address-selection problems", Arifumi Matsumoto, Tomohiro Fujisaki, Ruri Hiromi, 8-Mar-10, In response to address selection problem statement and requirement documents, this document describes solution approaches and evaluates proposed solution mechanisms in line with requirements. It also examines the applicability for each solution mechanism, and concludes that no single solution solves the problems and the combination of the solutions should be the way forward. "IPv6 Node Requirements RFC 4294-bis", Ed Jankiewicz, John Loughney, Thomas Narten, 12-Jul-10, 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. "Considerations for IPv6 Address Selection Policy Changes", Tim Chown, 12-Jul-10, 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 configure and potentially dynamically change RFC 3484 policy 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. "IPv6 Router Advertisement Options for DNS Configuration", Jaehoon Jeong, Soohong Daniel Park, Luc Beloeil, Syam Madanapalli, 26-Jul-10, This document specifies IPv6 Router Advertisement options to allow IPv6 routers to advertise a list of DNS recursive server addresses and a DNS search list to IPv6 hosts. "IPv6 UDP Checksum Considerations", Gorry Fairhurst, Magnus Westerlund, 12-Aug-10, This document examines the role of the transport checksum when used with IPv6, as defined in RFC2460. It presents a summary of the trade-offs for evaluating the safety of updating RFC 2460 to permit an IPv6 UDP endpoint to use a zero value in the checksum field to indicate that no checksum is present. The document describes issues and design principles that need to be considered when UDP is used with IPv6 to support tunnel encapsulations and provides recommendations. "An uniform format for IPv6 extension headers", Suresh Krishnan, James Woodyatt, Erik Kline, James Hoagland, 17-Jun-10, 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. "RPL Option for Carrying RPL Information in Data-Plane Datagrams", Jonathan Hui, JP Vasseur, 26-Jul-10, The RPL protocol requires data-plane datagrams to carry RPL routing information that is processed by RPL routers when forwarding those datagrams. This document describes the RPL option for use within a RPL domain. "An IPv6 Routing Header for Source Routes with RPL", Jonathan Hui, JP Vasseur, David Culler, 26-Jul-10, In Low power and Lossy Networks (LLNs), memory constraints on routers may limit them to maintaining at most a few routes. In some configurations, it is necessary to use these memory constrained routers to deliver datagrams to nodes within the LLN. The Routing for Low Power and Lossy Networks (RPL) protocol can be used in some deployments to store most, if not all, routes on one (e.g. the Directed Acyclic Graph (DAG) root) or few routers and forward the IPv6 datagram using a source routing technique to avoid large routing tables on memory constrained routers. This document specifies a new IPv6 Routing header type for delivering datagrams within a RPL domain. ADSL MIB (adslmib) ------------------ "xDSL multi-pair bonding (G.Bond) MIB", Edward Beili, Moti Morgenstern, 28-May-10, 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 Interfaces Group MIB with a set of common objects for managing multi-pair bonded Digital Subscriber Line (xDSL) interfaces, defined in ITU-T recommendations G.998.1, G.998.2 and G.998.3. The MIB modules specific to each bonding technology are defined in GBOND-ATM-MIB, GBOND-ETH-MIB and GBOND-TDIM-MIB respectively. "xDSL multi-pair bonding using Time-Division Inverse Multiplexing (G.Bond/TDIM) MIB", Edward Beili, 31-May-10, 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 GBOND-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. "ATM-Based xDSL Bonded Interfaces MIB", Edward Beili, 27-May-10, This document defines Management Information Base (MIB) module for use with network management protocols in TCP/IP based networks. This document proposes an extension to the GBOND-MIB module with a set of objects for managing ATM-based multi-pair bonded xDSL interfaces, defined in ITU-T recommendation G.998.1. Application-Layer Traffic Optimization (alto) --------------------------------------------- "Application-Layer Traffic Optimization (ALTO) Requirements", Sebastian Kiesel, Stefano Previdi, Martin Stiemerling, Richard Woundy, Yang Yang, 14-Jun-10, 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, 12-Jul-10, 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 a 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) ----------------------------------- "Protocol for Access Node Control Mechanism in Broadband Networks", Sanjay Wadhwa, Jerome Moisand, Thomas Haag, Norbert Voigt, Tom Taylor, 23-Aug-10, This document describes the Access Node Control Protocol (ANCP). ANCP operates 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. Use cases for ANCP are documented in RFC 5851. As well as describing the base ANCP protocol, this document specifies capabilities for Digital Subscriber Line (DSL) topology discovery, line configuration, and line testing. The design of ANCP anticipates the specification in other documents of extensions to the protocol to support additional ANCP protocol capabilities covering other use cases and other technologies. ANCP is based on GSMPv3 (RFC 3292), but with many modifications and extensions, to the point that the two protocols are not interoperable. "Access Node Control Protocol (ANCP) MIB module for Access Nodes", Stefaan De Cnodder, Moti Morgenstern, 2-Jul-10, 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). "Multicast Control Extensions for ANCP", Francois Le Faucheur, Roberta Maglione, Tom Taylor, 5-Aug-10, 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 and one additional use case described in this document. These 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; o committed bandwidth reporting. 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, 22-Mar-10, 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. Audio/Video Transport (avt) --------------------------- "The use of AES-192 and AES-256 in Secure RTP", David McGrew, 8-Mar-10, This memo describes the use of the Advanced Encryption Standard (AES) with 192 and 256 bit keys within the Secure RTP protocol. It details Counter Mode encryption for SRTP and SRTCP and a new SRTP Key Derivation Function (KDF) for AES-192 and AES-256. "RTP Payload Format for SVC Video", Stephan Wenger, Ye-Kui Wang, Thomas Schierl, Alex Eleftheriadis, 25-Aug-10, 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.Table of Contents "RTP Payload Format for MIDI", John Lazzaro, John Wawrzynek, 26-Jul-10, 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. "RTP Payload Format for DV (IEC 61834) Video", Katsushi Kobayashi, Kazuhiro Mishima, Stephen Casner, Carsten Bormann, 7-Mar-10, This document specifies the packetization scheme for encapsulating the compressed digital video data streams commonly known as "DV" into a payload format for the Real-Time Transport Protocol (RTP). This document Obsoletes RFC 3189. "Application Mechanism for keeping alive the Network Address Translator (NAT) mappings associated to RTP flows.", Xavier Marjou, Aurelien Sollaud, 18-Jun-10, 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. "Forward-shifted RTP Redundancy Payload Support", Qiaobing Xie, 18-Aug-10, This document defines a simple enhancement 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). "RTP Payload Format for H.264 RCDO Video", Tom Kristensen, Patrick Luthi, 11-May-10, 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 RCDO RTP Payload format is based on the H.264 RTP Payload format. "RTP Payload Format for IP-MR Speech Codec draft-ietf-avt-rtp-ipmr-12.txt", SPIRIT DSP, 3-Feb-10, 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 "Guidelines for Extending the RTP Control Protocol (RTCP)", Jörg Ott, Colin Perkins, 11-May-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 adaptation 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, 1-Jul-10, 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, 25-Jun-10, 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 15. Issues on backward compatibility to RFC 3984 are discussed in section 14. Table of Contents "RTP payload format for G.718 speech/audio", Ari Lakaniemi, Ye-Kui Wang, 22-Apr-10, 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, 9-Jul-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, 21-Jan-10, 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, 30-Aug-10, When an RTP receiver joins a 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 (or appearance) 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 can 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 multicast stream. This unicast RTP flow can be transmitted at a faster than natural bitrate 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. "Policy for Registering SRTP Transforms", Dan Wing, 20-Apr-10, IETF procedure requires country-specific cryptographic transforms to be Informational RFCs. This document allows such Informational RFCs to be used by SRTP and SRTP Security Descriptions. "Multicast Acquisition Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs)", Ali Begen, Eric Friedrich, 20-May-10, In most RTP-based multicast applications, the RTP source sends inter- related data. Due to this interdependency, randomly joining RTP receivers usually cannot start consuming the multicast data right after they join the session. Thus, they often experience a random acquisition delay. One approach to reduce this delay is to use an auxiliary unicast RTP session with a retransmission server to receive a burst stream that facilitates rapid acquisition of the multicast stream. An RTP receiver may use this approach (or any other approach) to achieve rapid acquisition. Yet, due to various factors, performance of the rapid acquisition methods usually varies. Furthermore, in some cases the RTP receiver may (or may have to) do a simple multicast join. For quality reporting, monitoring and diagnostics purposes, it is important to collect detailed information from the RTP receivers about their acquisition and presentation experiences. This document addresses this issue by defining a new report block type, called Multicast Acquisition (MA) Report Block, within the framework of RTP Control Protocol (RTCP) Extended Reports (XR). This document also defines the necessary signaling of the new MA report block type in the Session Description Protocol (SDP). "Explicit Congestion Notification (ECN) for RTP over UDP", Magnus Westerlund, Ingemar Johansson, Colin Perkins, Ken Carlberg, 10-Jul-10, This document specifies how explicit congestion notification (ECN) can be used with RTP/UDP flows that use RTCP as feedback mechanism. "Port Mapping Between Unicast and Multicast RTP Sessions", Ali Begen, Bill Ver Steeg, 19-May-10, This document presents a port mapping solution that allows RTP receivers to choose their own ports for an auxiliary unicast session in RTP applications using both unicast and multicast services. The solution requires multiplexing RTP and RTCP on a single port on both endpoints in the unicast session. "Encrypted Key Transport for Secure RTP", David McGrew, Flemming Andreasen, Dan Wing, Kai Fischer, 12-Jul-10, 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. "RTP Payload Format for MPEG-4 Audio/Visual Streams", Malte Schmidt, Frans Bont, Stefan Doehla, Jaehwan Kim, 2-Apr-10, 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). "RTP payload format for Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW)", Zheng Fang, 26-Jul-10, This document specifies real-time transport protocol (RTP) payload formats to be used for the Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW). Three media type registrations are included for EVRC-NW RTP payload formats. In addition, a file format is specified for transport of EVRC-NW speech data in storage mode applications such as e-mail. "RTP Payload Format for SMPTE 336M Encoded Data", James H. Arbeiter Arbeiter, 28-Apr-10, This document specifies the payload format for packetization of KLV (Key-Length-Value) Encoded Data, as defined by the Society of Motion Picture and Television Engineers (SMPTE) in SMPTE 336M, into the Real-time Transport Protocol (RTP). "RTP Payload Format for MVC Video", Ye-Kui Wang, Thomas Schierl, 28-Apr-10, 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. "RTP Payload Format for the iSAC Codec", Tina le Grand, Pascal Huart, Paul Jones, 29-Apr-10, 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). "RTP Payload Format for Bluetooth's SBC audio codec", Christian Hoene, Frans Bont, 9-Jun-10, 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. "RTP Control Protocol (RTCP) Port for Source-Specific Multicast (SSM) Sessions", Ali Begen, 25-Aug-10, The Session Description Protocol (SDP) has an attribute that allows RTP applications to specify an address and a port associated with the RTP Control Protocol (RTCP) traffic. In RTP-based source-specific multicast (SSM) sessions, the same attribute is used to designate the address and the RTCP port of the Feedback Target in the SDP description. However, the RTCP port associated with the SSM session itself cannot be specified by the same attribute to avoid ambiguity, and thus, is required to be derived from the "m=" line of the media description. Deriving the RTCP port from the "m=" line imposes an unnecessary restriction. This document removes this restriction by introducing a new SDP attribute. "Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)", Ali Begen, Colin Perkins, Dan Wing, 26-Aug-10, The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a persistent transport-level identifier for an RTP endpoint. While the Synchronization Source (SSRC) identifier of an RTP endpoint may change if a collision is detected, or when the RTP application is restarted, its RTCP CNAME is meant to stay unchanged, so that RTP endpoints can be uniquely identified and associated with their RTP media streams. For proper functionality, RTCP CNAMEs should be unique within the participants of an RTP session. However, the existing guidelines for choosing the RTCP CNAME provided in the RTP standard are insufficient to achieve this uniqueness. This memo updates these guidelines to allow endpoints to choose unique RTCP CNAMEs. Behavior Engineering for Hindrance Avoidance (behave) ----------------------------------------------------- "Traversal Using Relays around NAT (TURN) Extension for IPv6", Gonzalo Camarillo, Oscar Novo, Simon Perreault, 8-Jul-10, 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). "Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations", Simon Perreault, Jonathan Rosenberg, 8-Jul-10, This specification defines an extension of Traversal Using Relays around NAT (TURN), a relay protocol for Network Address Translation (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. "Stream Control Transmission Protocol (SCTP) Network Address Translation", Randall Stewart, Michael Tuexen, Irene Ruengeler, 29-Jun-10, 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. "IP/ICMP Translation Algorithm", Xing Li, Congxiao Bao, Fred Baker, 22-Aug-10, This document describes the Stateless IP/ICMP Translation Algorithm (SIIT), which translates between IPv4 and IPv6 packet headers (including ICMP headers). This document obsoletes RFC2765. "DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", Marcelo Bagnulo, Andrew Sullivan, Philip Matthews, Iljitsch van Beijnum, 5-Jul-10, 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. "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", Marcelo Bagnulo, Philip Matthews, Iljitsch van Beijnum, 12-Jul-10, This document describes stateful NAT64 translation, which allows IPv6-only clients to contact IPv4 servers using unicast UDP, TCP, or ICMP. The public IPv4 address can be shared among several IPv6-only clients. When the stateful NAT64 is used in conjunction with DNS64 no changes are usually required in the IPv6 client or the IPv4 server. "Framework for IPv4/IPv6 Translation", Fred Baker, Xing Li, Congxiao Bao, Kevin Yin, 17-Aug-10, 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. "IPv6 Addressing of IPv4/IPv6 Translators", Congxiao Bao, Christian Huitema, Marcelo Bagnulo, Mohammed Boucadair, Xing Li, 15-Aug-10, 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. "An FTP ALG for IPv6-to-IPv4 translation", Iljitsch van Beijnum, 1-Sep-10, The File Transfer Protocol (FTP) 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 do not support this mode, and some clients do not ask for it. This document describes specifies a middlebox that may solve this mismatch. Bidirectional Forwarding Detection (bfd) ---------------------------------------- "BFD Management Information Base", Thomas Nadeau, Zafar Ali, Nobo Akiya, 8-Jul-10, This draft defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling Bidirectional Forwarding Detection (BFD) protocol. Basic Level of Interoperability for SIP Services (bliss) -------------------------------------------------------- "An Analysis of Automatic Call Handling (ACH) Implementation Issues in the Session Initiation Protocol (SIP)", John Elwell, 8-Mar-10, 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, 25-Jun-10, 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, 12-Jul-10, 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 feature allows several user agents (UAs) to share a common AOR, learn about calls placed and received by other UAs in the group, and pick up or join calls within the group. This document discusses use cases, lists requirements and defines extensions to implement this feature. Benchmarking Methodology (bmwg) ------------------------------- "Benchmarking Methodology for Link-State IGP Data Plane Route Convergence", Scott Poretsky, Brent Imhoff, Kris Michielsen, 10-May-10, 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, 10-May-10, 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. "Benchmarking Terminology for Protection Performance", Rajiv Papneja, Scott Poretsky, Samir Vapiwala, Jay Karthik, 8-Jul-10, 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 with protection may be provided at the Sub-IP layer. 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 SIP Networking Devices", Scott Poretsky, Vijay Gurbani, Carol Davids, 12-Jul-10, This document describes the methodology for benchmarking Session Initiation Protocol (SIP) performance as described in SIP benchmarking terminology document. The methodology and terminology are to be used for benchmarking signaling plane performance with varying signaling and media load. Both scale and establishment rate are measured by signaling plane performance. The SIP Devices to be benchmarked may be a single device under test (DUT) or a system under test (SUT). Benchmarks can be obtained and compared for different types of devices such as SIP Proxy Server, SBC, and server paired with a media relay or Firewall/NAT device. "Terminology for Benchmarking Session Initiation Protocol (SIP) Networking Devices", Scott Poretsky, Vijay Gurbani, Carol Davids, 12-Jul-10, This document provides a terminology for benchmarking SIP performance in networking devices. Terms are included for test components, test setup parameters, and performance benchmark metrics for black-box benchmarking of SIP networking devices. The performance benchmark metrics are obtained for the SIP control plane and media plane. The terms are intended for use in a companion methodology document for complete performance characterization of a device in a variety of conditions making it possible to compare performance of different devices. It is critical to provide test setup parameters and a methodology document for SIP performance benchmarking because SIP allows a wide range of configuration and operational conditions that can influence performance benchmark measurements. It is necessary to have terminology and methodology standards to ensure that reported benchmarks have consistent definition and were obtained following the same procedures. Benchmarks can be applied to compare performance of a variety of SIP networking devices. "Device Reset Characterization", Rajiv Asati, Carlos Pignataro, Fernando Calabria, Cesar Olvera, 9-Jul-10, An operational forwarding device may need to be re-started (automatically or manually) for a variety of reasons, an event that we call a "reset" in this document. Since there may be an interruption in the forwarding operation during a reset, it is useful to know how long a device takes to begin forwarding packets again. This document specifies a methodology for characterizing reset during benchmarking of forwarding devices, and provides clarity and consistency in reset test procedures beyond what's specified in RFC2544. It therefore updates RFC2544. Calendaring and Scheduling Standards Simplification (calsify) ------------------------------------------------------------- "iCalendar Message-Based Interoperability Protocol (iMIP)", Alexey Melnikov, 28-Jul-10, 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 (iCalendar) are wrapped using constructs from RFC 5322 and MIME (RFC 2045, RFC 2046, RFC 2047 and RFC 2049), and then transported over SMTP. Common Control and Measurement Plane (ccamp) -------------------------------------------- "Procedures for Dynamically Signaled Hierarchical Label Switched Paths", Kohei Shiomoto, Adrian Farrel, Richard Rabbat, Arthi Ayyangar, Zafar Ali, 26-Feb-10, 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, 21-Jan-10, 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. "Operating Virtual Concatenation (VCAT) and the Link Capacity Adjustment Scheme (LCAS) with Generalized Multi-Protocol Label Switching (GMPLS)", Greg Bernstein, Diego Caviglia, Richard Rabbat, Huub Helvoort, 12-Jul-10, This document describes requirements for, and use of, the Generalized Multi-Protocol Label Switching (GMPLS) control plane in support of the Virtual Concatenation (VCAT) layer 1 inverse multiplexing data plane 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. This document updates the procedures for supporting virtual concatenation in [RFC4606]. "Traffic Engineering Database Management Information Base in support of MPLS-TE/GMPLS", Masanori Miyazawa, Tomohiro Otani, Kenji Kumaki, Thomas Nadeau, 3-Aug-10, 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, 22-Feb-10, 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 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, 18-Aug-10, This specification is complementary to the GMPLS Ethernet Label Switching Architecture and Framework and describes the technology specific aspects of GMPLS control for Provider Backbone Bridge Traffic Engineering (PBB-TE). 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, Richard Rabbat, Sidney Shiba, Hongxiang Guo, Keiji Miyazaki, Diego Caviglia, Dan Li, Takehiro Tsuritani, 8-Apr-10, 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, 18-Feb-10, 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, 12-Jul-10, 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. This model takes into account compatibility constraints between WSON signal attributes and network elements but does not include constraints due to optical impairments. Aspects of this information that may be of use to other technologies utilizing a GMPLS control plane are discussed. "Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks (WSON)", Greg Bernstein, 7-Apr-10, 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. In addition, electro-optical network elements and their compatibility constraints relative to optical signal parameters are characterized. 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. "Routing and Wavelength Assignment Information Encoding for Wavelength Switched Optical Networks", Greg Bernstein, 12-Jul-10, 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. Part of the WSON information model contains aspects that may be of general applicability to other technologies, while other parts are fairly specific to WSONs. This document provides efficient, protocol-agnostic encodings for the WSON specific information elements. It is intended that protocol- specific documents will reference this memo to describe how information is carried for specific uses. Such encodings can be used to extend GMPLS signaling and routing protocols. In addition these encodings could be used by other mechanisms to convey this same information to a path computation element (PCE). "GMPLS RSVP-TE Extensions for Ethernet OAM Configuration", Attila Takacs, Balazs Gero, Don Fedyk, Hao Long, 12-Jul-10, 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, 9-Jul-10, 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, 5-Mar-10, 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. "General Network Element Constraint Encoding for GMPLS Controlled Networks", Greg Bernstein, Young Lee, Dan Li, Wataru Imajuku, Jianrui Han, 9-Jun-10, Generalized Multiprotocol Label Switching can be used to control a wide variety of technologies. In some of these technologies network elements and links may impose additional routing constraints such as asymmetric switch connectivity, non-local label assignment, and label range limitations on links. This document provides efficient, protocol-agnostic encodings for general information elements representing connectivity and label constraints as well as label availability. It is intended that protocol-specific documents will reference this memo to describe how information is carried for specific uses. "Configuration of pro-active MPLS-TP Operations, Administration, and Maintenance (OAM) Functions Using RSVP-TE", Elisa Bellagamba, Loa Andersson, Pontus Skoldstrom, David Ward, Attila Takacs, 9-Jul-10, This specification describes the configuration of pro-active MPLS-TP Operations, Administration, and Maintenance (OAM) Functions for a given LSP using a common set of TLVs that can be carried on RSVP-TE protocol. "MPLS-TP Control Plane Framework", Loa Andersson, Lou Berger, Luyuan Fang, Nabil Bitar, Attila Takacs, Martin Vigoureux, Elisa Bellagamba, Eric Gray, 18-Jun-10, The MPLS Transport Profile (MPLS-TP) supports static provisioning of transport paths via a Network Management System (NMS), and dynamic provisioning of transport paths via a control plane. This document provides the framework for MPLS-TP dynamic provisioning, and covers control plane addressing, routing, path computation, signaling, traffic engineering,, and path recovery. MPLS-TP uses GMPLS as the control plane for MPLS-TP LSPs and provides for compatibility with MPLS. MPLS-TP also uses the control plane for Pseudowires (PWs). Management plane functions such as manual configuration and the initiation of LSP setup are out of scope of this document. "GMPLS RSVP-TE Extensions for SONET/SDH and OTN OAM Configuration", Andras Kern, Attila Takacs, 23-Mar-10, GMPLS has been extended to support connection establishment in both SONET/SDH [RFC4606] and OTN [RFC4328] networks. However support for the configuration of the supervision functions is not specified. Both SONET/SDH and OTN implement supervision functions to qualify the transported signals. This document defines extensions to RSVP-TE for SONET/SDH and OTN OAM configuration based on the OAM Configuration Framework defined in [GMPLS-OAM-FWK]. "Framework for GMPLS and PCE Control of G.709 Optical Transport Networks", Fatai Zhang, Dan Li, Han Li, Sergio Belotti, Jianrui Han, Malcolm Betts, Pietro Grandi, Eve Varma, 11-Jul-10, This document provides a framework to allow the development of protocol extensions to support Generalized Multi-Protocol Label Switching (GMPLS) and Path Computation Element (PCE) control of Optical Transport Networks (OTN) as specified in ITU-T Recommendation G.709 as consented in October 2009. Zhang Expires January 2011 [page 1] draft-ietf-ccamp-gmpls-g709-framework-02.txt July 2010 "Label Switched Path (LSP) Data Path Delay Metric in Generalized MPLS/ MPLS-TE Networks", Weiqiang Sun, Guoying Zhang, Jianhua Gao, Guowu Xie, Rajiv Papneja, Bin Gu, Xueqing Wei, Tomohiro Otani, Ruiquan Jing, 27-May-10, When setting up a label switched path (LSP) in Generalized MPLS and MPLS/TE networks, the completion of the signaling process does not necessarily mean that the cross connection along the LSP have been programmed accordingly and in a timely manner. Meanwhile, the completion of signaling process may be used by applications as indication that data path has become usable. The existence of this delay and the possible failure of cross connection programming, if not properly treated, will result in data loss or even application failure. Characterization of this performance can thus help designers to improve the application model and to build more robust applications. This document defines a series of performance metrics to evaluate the availability of data path in the signaling process. Internet Wideband Audio Codec (codec) ------------------------------------- "Codec Requirements", Jean-Marc Valin, Koen Vos, 24-Aug-10, This document provides specific requirements for an Internet audio codec. These requirements address quality, sampling rate, bit-rate, and packet loss robustness, as well as other desirable properties. Constrained RESTful Environments (core) --------------------------------------- "Constrained Application Protocol (CoAP)", Zach Shelby, Brian Frank, Don Sturek, 8-Jul-10, This document specifies the Constrained Application Protocol (CoAP), a specialized RESTful transfer protocol for use with constrained networks and nodes for machine-to-machine applications such as smart energy and building automation. These constrained nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while networks such as 6LoWPAN often have high packet error rates and a typical throughput of 10s of kbit/s. CoAP provides the REST Method/ Response interaction model between application end-points, supports built-in resource discovery, and includes key web concepts such as URIs and content-types. CoAP easily translates to HTTP for integration with the web while meeting specialized requirements such as multicast support, very low overhead and simplicity for constrained environments. Cga & Send maIntenance (csi) ---------------------------- "SEND Hash Threat Analysis", Ana Kukec, Suresh Krishnan, Sheng Jiang, 11-Jul-10, This document analyzes the use of hashes in Secure Neighbor Discovery (SEND), the possible threats to these hashes and the impact of recent attacks on hash functions used by SEND. The SEND specification [RFC3971] currently uses the SHA-1 [SHA1] hash algorithm and PKIX certificates [RFC5280] and does not provide support for hash algorithm agility. This document provides an analysis of possible threats to the hash algorithms used in SEND. "Secure Proxy ND Support for SEND", Suresh Krishnan, Julien Laganier, Marco Bonola, Alberto Garcia-Martinez, 31-May-10, Secure Neighbor Discovery (SEND) specifies a method for securing Neighbor Discovery (ND) signaling against specific threats. As defined today, SEND assumes that the node sending a ND message is the owner of the address from which the message is sent, so that it is in possession of the private key used to generate the digital signature on the message. This means that the Proxy ND signaling performed 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 in order to secure Proxy ND operation. "Certificate profile and certificate management for SEND", Roque Gagliano, Suresh Krishnan, Ana Kukec, 29-Aug-10, 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, 23-Jun-10, 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. "Subject Key Identifier (SKI) SEND Name Type fields.", Roque Gagliano, Suresh Krishnan, Ana Kukec, 3-Jun-10, SEcure Neighbor Discovery (SEND) defines the Name Type field in the ICMPv6 Trust Anchor option. This document specifies new Name Type fields based on certificate Subject Key Identifiers (SKI). Datagram Congestion Control Protocol (dccp) ------------------------------------------- "Datagram Congestion Control Protocol (DCCP) Encapsulation in UDP for NAT Traversal (DCCP-UDP)", Thomas Phelan, 26-Aug-10, This document specifies an alternative encapsulation of the Datagram Congestion Control Protocol (DCCP), referred to as DCCP-UDP. This encapsulation will allow DCCP to be carried through the current generation of Network Address Translation (NAT) middleboxes without modification of those middleboxes. Decoupled Application Data Enroute (decade) ------------------------------------------- "DECoupled Application Data Enroute (DECADE) Problem Statement", Song Yongchao, Ning Zong, Yang Yang, Richard Alimi, 23-Aug-10, Peer-to-peer (P2P) applications have become widely used on the Internet today and make up a large portion of the traffic in many networks. In P2P applications, one technique for reducing the total amount of P2P traffic is to introduce storage capabilities within the network. Traditional caches (e.g., P2P and Web caches) provide such storage, but they are complex (due to explicitly supporting individual P2P application protocols) and they do not allow users to manage access to content in the cache. For example, Content Providers cannot easily control access and resource usage policies to satisfy their own requirements. This document discusses the introduction of in-network storage for P2P applications, shows the need for a standard protocol for accessing this storage, and identifies the scope of this protocol. The accessing protocol can also be used by other applications with similar requirements. 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, 13-May-10, 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. "Guidelines for Creating New DHCP Options", David Hankins, 5-Mar-10, This document seeks to provide guidance to prospective DHCP Option authors, to help them in producing option formats that are easily adoptable. "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 options for network boot", Thomas Huth, Jens Freimann, Vincent Zimmer, Dave Thaler, 26-Jul-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 SHOULD be used for booting a node from the network. "DHCPv4 Leasequery by Relay Agent Remote ID", Pavan Kurapati, Bharat Joshi, 6-Aug-10, Some Relay Agents extract lease information from the DHCP messages 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, 5-Mar-10, 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. "Dynamic Host Configuration Protocol DHCPINFORM Message Clarifications", David Hankins, 9-Jul-10, The DHCPINFORM message within the DHCPv4 protocol has in operation diverged incompatibly from the current defined standard. This document seeks to provide clarification of actual behaviour and guidance for some situations that were previously omitted. "Lightweight DHCPv6 Relay Agent", David Miles, Sven Ooghe, Wojciech Dec, Suresh Krishnan, 7-Jun-10, 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. "Secure DHCPv6 Using CGAs", Sheng Jiang, 21-Jun-10, 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. Diameter Maintenance and Extensions (dime) ------------------------------------------ "Diameter Base Protocol", Victor Fajardo, Jari Arkko, John Loughney, Glen Zorn, 2-Sep-10, 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 Applications Design Guidelines", Victor Fajardo, Hannes Tschofenig, Lionel Morand, 1-Sep-10, 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. "Diameter support for the EAP Re-authentication Protocol (ERP)", Julien Bournelle, Lionel Morand, Wenson Wu, Glen Zorn, 7-Mar-10, The 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 an ER authenticator and the ER server, and a set of new AVPs that can be used to transport the cryptographic material needed by the re-authentication server. "Diameter Base Protocol MIB", Glen Zorn, Subash Comerica, 14-Jan-10, 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. "Diameter Credit Control Application MIB", Glen Zorn, Subash Comerica, 14-Jan-10, 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. "The Diameter Capabilities Update Application", Jiao Kang, Glen Zorn, 18-Jun-10, This document defines a new Diameter application and associated command codes. The Capabilities Update application is intended to allow the dynamic update of certain Diameter peer capabilities while the peer-to-peer connection is in the open state. "Realm-Based Redirection In Diameter", Tina Tsou (Ting ZOU), Tom Taylor, 12-Jul-10, 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 a mechanism by which this can be achieved. New applications may incorporate this capability by reference to the present document. "Diameter Network Address and Port Translation Control Application", Frank Brockners, Cisco Systems, Vaneeta Singh, Victor Fajardo, 12-Jul-10, This document describes the framework, messages, and procedures for the Diameter Network address and port translation Control Application (DNCA). The DNCA allows per endpoint control of large scale Network Address Translators (NATs) and Network Address and Port Translators (NAPTs), which are added to cope with IPv4-address space completion. The DNCA allows external devices to configure and manage a NAT device - expanding the existing Diameter-based AAA and policy control capabilities with a NAT and NAPT 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/ NAPT 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, 4-May-10, This document describes an extended format for the S-NAPTR Application Service Tag used in dynamic Diameter agent discovery. The extended format allows NAPTR queries to contain Diameter Application-Id information. "Diameter IKEv2 PSK: Pre-Shared Secret-based Support for IKEv2 Server to Diameter Server Interaction", Violeta Cakulev, Avi Lior, 30-Aug-10, The Internet Key Exchange protocol version 2 (IKEv2) is a component of the IPsec architecture and is used to perform mutual authentication as well as to establish and to maintain IPsec security associations (SAs) between the respective parties. IKEv2 supports several different authentication mechanisms, such as the Extensible Authentication Protocol (EAP), certificates, and pre-shared secrets. With [RFC 5778] the Diameter interworking for Mobile IPv6 between the Home Agent, as a Diameter client, and the Diameter server has been specified. However, that specification focused on the usage of EAP and did not include support for pre-shared secret based authentication available with IKEv2. This document therefore extends the functionality offered by [RFC 5778] with pre-shared key based authentication offered by IKEv2 when no EAP is used. "Diameter Attribute-Value Pairs for Cryptographic Key Transport", Glen Zorn, Wenson Wu, Violeta Cakulev, 30-Jun-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. "Diameter Support for Proxy Mobile IPv6 Localized Routing", Glen Zorn, Wenson Wu, Marco Liebsch, Jouni Korhonen, 25-May-10, In Proxy Mobile IPv6, packets received from a Mobile Node (MN) by the Mobile Access Gateway (MAG) to which it is attached are typically tunneled to a Local Mobility Anchor (LMA) for routing. The term "localized routing" refers to a method by which packets are routed directly by the MAG without involving the LMA. In order to establish a localized routing session between two Mobile Access Gateways in a Proxy Mobile IPv6 domain, two tasks must be accomplished: 1. The usage of local routing must be authorized for both MAGs and 2. The address of the MAG to which the Correspondent Node (CN) is attached must be ascertained This document specifies how to accomplish these tasks using the Diameter protocol. "Diameter Priority Attribute Value Pairs", Ken Carlberg, Tom Taylor, 8-Jul-10, This document defines Attribute-Value Pair (AVP) containers for various priority parameters for use with Diameter and the AAA framework. The parameters themselves are defined in several different protocols that operate at either the network or application layer. "Diameter Network Access Server Application", Glen Zorn, 11-Aug-10, This document describes the Diameter protocol application used for Authentication, Authorization, and Accounting (AAA) services in the Network Access Server (NAS) environment. When combined with the Diameter Base protocol, Transport Profile, and Extensible Authentication Protocol specifications, this application specification satisfies typical network access services requirements. Domain Keys Identified Mail (dkim) ---------------------------------- "DKIM And Mailing Lists", Murray Kucherawy, 10-Aug-10, DomainKeys Identified Mail (DKIM) allows an administrative mail domain (ADMD) to assume some responsibility for a message. As the industry has now gained some deployment experience, the goal for this document is to explore the use of DKIM for scenarios that include intermediaries, such as Mailing List Managers (MLMs). "DomainKeys Identified Mail (DKIM) Signatures", Dave Crocker, Murray Kucherawy, Tony Hansen, 16-Aug-10, DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. This can be an author's organization, an operational relay or one of their agents. DKIM separates the question of the identity of the signer of the message from the purported author of the message. Assertion of responsibility is validated through a cryptographic signature and querying the signer's domain directly to retrieve the appropriate public key. Message transit from author to recipient is through relays that typically make no substantive change to the message content and thus preserve the DKIM signature. "RFC4871 Implementation Report", Murray Kucherawy, 17-Aug-10, This document contains an implementation report for the IESG covering DKIM in support of the advancement of that specification along the Standards Track. Detecting Network Attachment (dna) ---------------------------------- "Simple procedures for Detecting Network Attachment in IPv6", Suresh Krishnan, Greg Daley, 25-Aug-10, 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) ----------------------- "Clarifications and Implementation Notes for DNSSECbis", Samuel Weiler, David Blacka, 27-Mar-10, 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, 20-Apr-10, 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, 25-Mar-10, 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 (RFC2671) based on 10 years of deployment experience. "Cryptographic Algorithm Identifier Allocation for DNSSEC", Paul Hoffman, 22-Mar-10, This document specifies how DNSSEC cryptographic algorithm identifiers in the IANA registries are allocated. It changes the requirement from "standard required" to "RFC required". It does not change the list of algorithms that are recommended or required for DNSSEC implementations. "Handling of Unknown DNS Resource Record (RR) Types", Andreas Gustafsson, 24-Feb-10, 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. "Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry", Scott Rose, 11-Aug-10, The DNS Security Extensions (DNSSEC) requires the use of cryptographic algorithm suites for generating digital signatures over DNS data. There is currently an IANA registry for these algorithms that is incomplete in that it lacks the implementation status of each algorithm. This document provides an applicability statement on algorithm status for DNSSEC implementations. This document replaces that registry table with a new IANA registry table for Domain Name System Security (DNSSEC) Algorithm Numbers which lists each algorithm's status based on the current reference. If that status is not defined in the original specification, this document assigns a status. Domain Name System Operations (dnsop) ------------------------------------- "Locally-served DNS Zones", Mark Andrews, 30-Apr-10, 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. "AS112 Nameserver Operations", Joe Abley, William Maton, 29-Jul-10, 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, 29-Jul-10, 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. "Requirements for Management of Name Servers for the DNS", Wesley Hardaker, 11-Jun-10, Management of name servers for the Domain Name System (DNS) has traditionally been done using vendor-specific monitoring, configuration and control methods. Although some service monitoring platforms can test the functionality of the DNS itself there is not an interoperable way to manage (monitor, control and configure) the internal aspects of a name server itself. This document discusses the requirements of a management system for name servers and can be used as a shopping list of needed features for such a system. "DNSSEC Operational Practices, Version 2", Olaf Kolkman, 2-Aug-10, This document describes a set of practices for operating the DNS with security extensions (DNSSEC). The target audience is zone administrators deploying DNSSEC. The document discusses operational aspects of using keys and signatures in the DNS. It discusses issues of key generation, key storage, signature generation, key rollover, and related policies. [When approved] This document obsoletes RFC 4641 as it covers more operational ground and gives more up-to-date requirements with respect to key sizes and the DNSSEC operations. "DNSSEC Policy & Practice Statement Framework", Fredrik Ljunggren, Anne-Marie Eklund-Lowinder, Tomofumi Okubo, 31-Jul-10, This document presents a framework to assist writers of DNSSEC Policy and Practice Statements such as Domain Managers and Zone Operators on both the top-level and secondary level, who is managing and operating a DNS zone with Security Extensions (DNSSEC) implemented. In particular, the framework provides a comprehensive list of topics that should be considered for inclusion into a DNSSEC Policy definition and Practice Statement. "DNSSEC Trust Anchor History Service", Wouter Wijngaards, Olaf Kolkman, 29-Jun-10, When DNS validators have trusted keys, but have been offline for a longer period, key rollover will fail and they are stuck with stale trust anchors. History service allows validators to query for older DNSKEY RRsets and pick up the rollover trail where they left off. "DNSSEC Key Timing Considerations", Stephen Morris, Johan Ihren, John Dickinson, 1-Jul-10, This document describes the issues surrounding the timing of events in the rolling of a key in a DNSSEC-secured zone. It presents timelines for the key rollover and explicitly identifies the relationships between the various parameters affecting the process. Data for Reachability of Inter/tra-NetworK SIP (drinks) ------------------------------------------------------- "DRINKS Use cases and Protocol Requirements", Sumanth Channabasappa, 24-May-10, This document captures the use cases and associated requirements for interfaces that provision session establishment data into SIP Service Provider components, to assist with session routing. Specifically, the current version of this document focuses on the provisioning of one such element, termed the registry. "SPPP Over SOAP and HTTP", Kenneth Cartwright, 11-Jun-10, The Session Peering Provisioning Protocol (SPPP) is an XML protocol that exists to enable the provisioning of session establishment data into Session Data Registries or SIP Service Provider data stores. Sending XML data structures over Simple Object Access Protocol (SOAP) and HTTP(s) is a widely used, de-facto standard for messaging between elements of provisioning systems. Therefore the combination of SOAP and HTTP(s) as a transport for SPPP is a natural fit. The obvious benefits include leveraging existing industry expertise, leveraging existing standards, and a higher probability that existing provisioning systems can be more easily integrated with this protocol. This document describes the specification for transporting SPPP XML structures over SOAP and HTTP(s). "Session Peering Provisioning Protocol", Jean-Francois Mule, Kenneth Cartwright, Syed Ali, Alexander Mayrhofer, 12-Jul-10, This document defines a protocol for provisioning session establishment data into Session Data Registries and SIP Service Provider data stores. The provisioned data is typically used by various network elements for session peering. This document describes the Session Peering Provisioning Protocol used by clients to provision registries. The document provides a set of guiding principles for the design of this protocol including extensibility and independent transport definitions, a basic data model and an XML Schema Document. Email Address Internationalization (eai) ---------------------------------------- "Mailing Lists and Internationalized Email Addresses", Randall Gellens, 27-Jun-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. "Overview and Framework for Internationalized Email", John Klensin, YangWoo Ko, 31-Aug-10, Full use of electronic mail throughout the world requires that (subject to other constraints) people be able to use close variations on their own names (written correctly in their own languages and scripts) as mailbox names in email addresses. This document introduces a series of specifications that define mechanisms and protocol extensions needed to fully support internationalized email addresses. These changes include an SMTP extension and extension of email header syntax to accommodate UTF-8 data. The document set also includes discussion of key assumptions and issues in deploying fully internationalized email. This document is an update of RFC 4952; it reflects additional issues identified since that document was published. "SMTP Extension for Internationalized Email Address", Jiankang Yao, Wei MAO, 19-Aug-10, This document specifies an SMTP extension for transport and delivery of email messages with internationalized email addresses or header information. Communication with systems that do not implement this specification is specified in another document. This document updates some syntaxes and rules defined in RFC 5321 and RFC 5322. "Internationalized Email Headers", Abel Yang, Shawn Steele, 19-Aug-10, Full internationalization of electronic mail requires not only the capabilities to transmit non-ASCII content, to encode selected information in specific header fields, and to use non-ASCII characters in envelope addresses. It also requires being able to express those addresses and the information based on them in mail header fields. This document specifies an variant of Internet mail that permits the use of Unicode encoded in UTF-8, rather than ASCII, as the base form for Internet email header field. This form is permitted in transmission only if authorized by an SMTP extension, as specified in an associated specification. This specification Updates section 6.4 of [RFC2045] to conform with the requirements. Emergency Context Resolution with Internet Technologies (ecrit) --------------------------------------------------------------- "Best Current Practice for Communications Services in support of Emergency Calling", Brian Rosen, James Polk, 12-Jul-10, 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, 12-Jul-10, 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, 21-Feb-10, 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. "Synchronizing Location-to-Service Translation (LoST) Protocol based Service Boundaries and Mapping Elements", Henning Schulzrinne, Hannes Tschofenig, 6-Mar-10, 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. "IANA Registering a SIP Resource Priority Header Field Namespace for Local Emergency Communications", James Polk, 7-Mar-10, This document creates the new Session Initiation Protocol (SIP) Resource Priority header field namespace "esnet" for local emergency usage to a public safety answering point (PSAP), between PSAPs, and between a PSAP and first responders and their organizations, and places this namespace in the IANA registry. "LoST Service List Boundary Extension", Karl Wolf, 6-Aug-10, 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 LoST server, in its response, does not provide context information, that is, it does not provide any additional information about the geographical region for which the returned list of services is considered valid within. Therefore, this document proposes a Service List Boundary that returns a local context along with the list of services returned, in order to assist the client to not miss a change in available services when moving. "Using Imprecise Location for Emergency Context Resolution", Richard Barnes, Matt Lepinski, 15-Aug-10, 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, 23-Jun-10, 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", Sam Hartman, Charles Clancy, Katrin Hoeper, 12-Jul-10, 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, 26-Apr-10, 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, 23-Jun-10, This document discusses the use of the Domain Name System (DNS) for storage of data associated with E.164 numbers, and for resolving those numbers into URIs that can be used (for example) in 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 RFC3761. "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, 1-Jul-10, This document revises all Enumservices that were IANA registered under the now obsolete specification of the Enumservice registry defined in RFC 3761. FEC Framework (fecframe) ------------------------ "Forward Error Correction (FEC) Framework", Mark Watson, 6-Jul-10, This document describes a framework for using forward error correction (FEC) codes with applications in public and private IP networks to provide protection against packet loss. The framework supports applying Forward Error Correction to arbitrary packet flows over unreliable transport and is primarily intended for real-time, or streaming, media. This framework can be used to define Content Delivery Protocols that provide Forward Error Correction for streaming media delivery or other packet flows. Content Delivery Protocols defined using this framework can support any FEC Scheme (and associated FEC codes) which is compliant with various requirements defined in this document. Thus, Content Delivery Protocols can be defined which are not specific to a particular FEC Scheme and FEC Schemes can be defined which are not specific to a particular Content Delivery Protocol. "Session Description Protocol (SDP) Elements for FEC Framework", Ali Begen, 12-Aug-10, 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. "Methods to convey FEC Framework Configuration Information", Rajiv Asati, 24-Jun-10, FEC Framework document [FECARCH] defines the FEC Framework Configuration Information necessary for the FEC framework operation. This document describes how to use existing signaling protocols to determine and dynamically communicate the Configuration information between sender(s) and receiver(s). "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. "RTP Payload Format for 1-D Interleaved Parity FEC", Ali Begen, 12-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 should only be used (with some exceptions) as a part of the DVB-IPTV Application-layer FEC specification. "Raptor FEC Schemes for FECFRAME", Mark Watson, 7-Mar-10, This document describes Fully-Specified Forward Error Correction (FEC) Schemes for the Raptor and RaptorQ codes and their application to reliable delivery of media streams in the context of FEC Framework. The Raptor and RaptorQ codes are systematic codes, where a number of repair symbols are generated from a set of source symbols and sent in one or more repair flows in addition to the source symbols that are sent to the receiver(s) within a source flow. The Raptor and RaptorQ codes offer close to optimal protection against arbitrary packet losses at a low computational complexity. Six FEC Schemes are defined, two for protection of arbitrary packet flows, two that are optimised for small source blocks and another two for protection of a single flow that already contains a sequence number. Repair data may be sent over arbitrary datagram transport (e.g. UDP) or using RTP. "RTP Payload Format for Raptor FEC", Mark Watson, 7-Mar-10, 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, 27-Jun-10, 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 LFB Library", Weiming Wang, Evangelos Haleplidis, Kentaro Ogawa, Fenggen Jia, Joel Halpern, 3-Mar-10, 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). That control is accomplished through manipulating components of Logical Function Blocks (LFBs), whose structure is defined in a model RFC produced by the working group.In order to build an actual solution using this protocol, there needs to be a set of Logical Function Block definitions that can be instantiated by FEs and controlled by CEs. This document provides a sample space of such definitions. It is anticipated that additional defining documents will be produced over time. "Implementation Report for ForCES", Evangelos Haleplidis, Kentaro Ogawa, Weiming Wang, Jamal Hadi Salim, 27-Jun-10, 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. 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, 15-Jan-10, 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, 27-Mar-10, 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). "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. "Discovering the Local Location Information Server (LIS)", Martin Thomson, James Winterbottom, 7-Mar-10, 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. "Dynamic Host Configuration Protocol (DHCP) IPv4 and IPv6 Option for a Location Uniform Resource Identifier (URI)", James Polk, 28-Jul-10, 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. "Dynamic Host Configuration Protocol Options for Coordinate-based Location Configuration Information", James Polk, John Schnizlein, Marc Linsner, Martin Thomson, Bernard Aboba, 5-Jul-10, 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, 27-May-10, 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, 20-Jun-10, 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 the 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 addressed 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. "Prefix elements for Road and House Numbers in PIDF-LO", Brian Rosen, 20-Jan-10, RFC4119 updated by RFC5139 defines suffixes for street names and house numbers, but does not define prefixes. Both occur regularly in addresses and CAtypes are needed for them. This memo defines STP Street Prefix and HNP house number prefix CAtypes. "A Location Dereferencing Protocol Using HELD", James Winterbottom, Hannes Tschofenig, Henning Schulzrinne, Martin Thomson, Martin Dawson, 4-Jul-10, 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. "Using Device-provided Location-Related Measurements in Location Configuration Protocols", Martin Thomson, James Winterbottom, 4-Jul-10, 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. "Relative Location Representation", Martin Thomson, Brian Rosen, Dorothy Stanley, Gabor Bajko, Allan Thomson, 5-Jul-10, This document defines an extension to PIDF-LO (RFC4119) for the expression of location information that is defined relative to a reference point. The reference point may be expressed as a geodetic or civic location, and the relative offset may be one of several shapes. Optionally, a reference to a secondary document (such as a map image) can be included, along with the relationship of the map coordinate system to the reference/offset coordinate system to allow display of the map with the reference point and the relative offset. Also included in this document is a Type/Length/Value (TLV) representation of the relative location for use in other protocols that use TLVs. Global Routing Operations (grow) -------------------------------- "MRT routing information export format", Larry Blunk, Manish Karir, Craig Labovitz, 8-Mar-10, 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-Jun-10, 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. "FIB Suppression with Virtual Aggregation", Paul Francis, Xiaohu Xu, Hitesh Ballani, Dan Jen, Robert Raszuk, Lixia Zhang, 31-Aug-10, 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", Tomonori Takeda, Bruno Decraene, Pierre Francois, cristel pelsser, Zubair Ahmad, Antonio Jose Elizond Armengol, 11-Jun-10, 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 bringing 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. "Auto-Configuration in Virtual Aggregation", Paul Francis, Xiaohu Xu, Hitesh Ballani, Dan Jen, Robert Raszuk, Lixia Zhang, 31-Aug-10, Virtual Aggregation as specified in [I-D.ietf-grow-va] requires configuration of a static "VP-List" on all routers. The VP-List allows routers to know which prefixes may or may not be FIB- installed. This draft specified an optional method of determining this that requires far less configuration. Specifically, it requires the configuration of a "VP-Range" in ASBRs connected to transit and peer ISPs. An Extended Communities Attribute is used to convey to other routers that a given route can be FIB-suppressed. "Simple Virtual Aggregation (S-VA)", Paul Francis, Xiaohu Xu, Hitesh Ballani, Robert Raszuk, Lixia Zhang, 31-Aug-10, 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. Simple Virtual Aggregation (S-VA) is a simple form of Virtual Aggregation (VA) that allows any and all edge routers to shrink their FIB requirements substantially and therefore increase their useful lifetime. S-VA does not change FIB requirements for core routers. S-VA is extremely easy to configure---considerably more so than the various tricks done today to extend the life of edge routers. S-VA can be deployed autonomously by an ISP (cooperation between ISPs is not required), and can co-exist with legacy routers in the ISP. "Distribution of diverse BGP paths.", Robert Raszuk, Rex Fernando, Keyur Patel, Danny McPherson, Kenji Kumaki, 7-Jul-10, The BGP4 protocol specifies the selection and propagation of a single best path for each prefix. As defined today BGP has no mechanisms to distribute paths other then best path between its speakers. This behaviour results in number of disadvantages for new applications and services. This document presents an alternative mechanism for solving the problem based on the concept of parallel route reflector planes. Such planes can be build in parallel or they can co-exit on the current route reflection platforms. Document also compares existing solutions and proposed ideas that enable distribution of more paths than just the best path. This proposal does not specify any changes to the BGP protocol definition. It does not require upgrades to provider edge or core routers nor does it need network wide upgrades. The authors believe that the GROW WG would be the best place for this work. Host Identity Protocol (hip) ---------------------------- "Host Identity Protocol (HIP) Registration Extension", Julien Laganier, Teemu Koponen, Lars Eggert, 20-Aug-10, This document specifies a registration mechanism for the Host Identity Protocol (HIP) that allows hosts to register with services, such as HIP rendezvous servers or middleboxes. "Basic Socket Interface Extensions for Host Identity Protocol (HIP)", Miika Komu, Tom Henderson, 13-Jan-10, 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. "HIP Certificates", Tobias Heer, Samu Varjonen, 28-Apr-10, 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, 22-Jun-10, 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)", Gonzalo Camarillo, Jan Melen, 12-Jul-10, This document defines a new HIP (Host Identity Protocol) packet type called DATA. HIP DATA packets are used to reliably convey authenticated arbitrary protocol messages over various overlay networks. "Host Identity Protocol (HIP) Multi-hop Routing Extension", Gonzalo Camarillo, Ari Keranen, 29-Jun-10, This document specifies two extensions to HIP to implement multi-hop routing. The first extension allows implementing source routing in HIP. That is, a node sending a HIP packet can define a set of nodes that the HIP packet should traverse. The second extension allows a HIP packet to carry and record the list of nodes that forwarded it. "Host Identity Protocol-Based Overlay Networking Environment (HIP BONE) Instance Specification for REsource LOcation And Discovery (RELOAD)", Ari Keranen, Gonzalo Camarillo, Jouni Maenpaa, 12-Jul-10, This document is the Host Identity Protocol-Based Overlay Networking Environment (HIP BONE) instance specification for the REsource LOcation And Discovery (RELOAD) protocol. The document provides the details needed to build a RELOAD-based overlay that uses HIP. "Host Identity Protocol Signaling Message Transport Modes", Ari Keranen, 12-Jul-10, This document specifies two transport modes for Host Identity Protocol signaling messages that allow conveying them over encrypted connections initiated with the Host Identity Protocol. "Host Identity Protocol Architecture", Robert Moskowitz, 24-Aug-10, This memo describes a new namespace, the Host Identity namespace, and a new protocol layer, the Host Identity Protocol, between the internetworking and transport layers. Herein are presented the basics of the current namespaces, their strengths and weaknesses, and how a new namespace will add completeness to them. The roles of this new namespace in the protocols are defined. This document obsoletes RFC 4423 and addresses the concerns raised by the IESG, particularly that of crypto agility. It incorporates lessons learned from the implementations of RFC 5201 and goes further to explain how HIP works as a secure signalling channel. "An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID)", Julien Laganier, Francis Dupont, 20-Aug-10, This document introduces Overlay Routable Cryptographic Hash Identifiers (ORCHID) as a new, experimental class of IPv6-address- like identifiers. These identifiers are intended to be used as endpoint identifiers at applications and Application Programming Interfaces (API) and not as identifiers for network location at the IP layer, i.e., locators. They are designed to appear as application layer entities and at the existing IPv6 APIs, but they should not appear in actual IPv6 headers. To make them more like vanilla IPv6 addresses, they are expected to be routable at an overlay level. Consequently, while they are considered non-routable addresses from the IPv6 layer point-of-view, all existing IPv6 applications are expected to be able to use them in a manner compatible with current IPv6 addresses. This document requests IANA to allocate a temporary prefix out of the IPv6 addressing space for Overlay Routable Cryptographic Hash Identifiers. By default, the prefix will be returned to IANA in 2014, with continued use requiring IETF consensus. "Host Identity Protocol (HIP) Rendezvous Extension", Julien Laganier, Lars Eggert, 20-Aug-10, This document defines a rendezvous extension for the Host Identity Protocol (HIP). The rendezvous extension extends HIP and the HIP registration extension for initiating communication between HIP nodes via HIP rendezvous servers. Rendezvous servers improve reachability and operation when HIP nodes are multi-homed or mobile. "Host Identity Protocol (HIP) Domain Name System (DNS) Extension", Julien Laganier, 20-Aug-10, This document specifies a new resource record (RR) for the Domain Name System (DNS), and how to use it with the Host Identity Protocol (HIP). This RR allows a HIP node to store in the DNS its Host Identity (HI, the public component of the node public-private key pair), Host Identity Tag (HIT, a truncated hash of its public key), and the Domain Names of its rendezvous servers (RVSs). "Host Identity Protocol", Robert Moskowitz, Petri Jokela, Tom Henderson, Tobias Heer, 1-Sep-10, This document specifies the details of the Host Identity Protocol (HIP). HIP allows consenting hosts to securely establish and maintain shared IP-layer state, allowing separation of the identifier and locator roles of IP addresses, thereby enabling continuity of communications across IP address changes. HIP is based on a Sigma- compliant Diffie-Hellman key exchange, using public key identifiers from a new Host Identity namespace for mutual peer authentication. The protocol is designed to be resistant to denial-of-service (DoS) and man-in-the-middle (MitM) attacks. When used together with another suitable security protocol, such as the Encapsulated Security Payload (ESP), it provides integrity protection and optional encryption for upper-layer protocols, such as TCP and UDP. This document obsoletes RFC 5201 and addresses the concerns raised by the IESG, particularly that of crypto agility. It also incorporates lessons learned from the implementations of RFC 5201. "End-Host Mobility and Multihoming with the Host Identity Protocol", Pekka Nikander, Tom Henderson, Christian Vogt, Jari Arkko, 23-Aug-10, This document defines mobility and multihoming extensions to the Host Identity Protocol (HIP). Specifically, this document defines a general "LOCATOR" parameter for HIP messages that allows for a HIP host to notify peers about alternate addresses at which it may be reached. This document also defines elements of procedure for mobility of a HIP host -- the process by which a host dynamically changes the primary locator that it uses to receive packets. While the same LOCATOR parameter can also be used to support end-host multihoming, detailed procedures are left for further study. Handover Keying (hokey) ----------------------- "EAP Re-authentication Protocol Extensions for Authenticated Anticipatory Keying (ERP/AAK)", Zehn Cao, Hui Deng, Yungui Wang, Wenson Wu, Glen Zorn, 10-May-10, The Extensible Authentication Protocol (EAP) is a generic framework supporting multiple types of authentication methods. The EAP Re-authentication Protocol (ERP) specifies extensions to EAP and the EAP keying hierarchy to support an EAP method-independent protocol for efficient re-authentication between the peer and an EAP re-authentication server through any authenticator. Authenticated Anticipatory Keying (AAK) is a method by which cryptographic keying material may be established prior to handover upon one or more candidate attachment points (CAPs), AAK uses the AAA infrastructure for key transport. This document specifies the extensions necessary to enable AAK support in ERP. "The Local Domain Name DHCPv6 Option", Glen Zorn, Wenson Wu, Yungui Wang, 4-Aug-10, In order to derive a Domain-Specific Root Key (DSRK) from the Extended Master Session Key (EMSK) generated as a side-effect of an Extensible Authentication Protocol (EAP) method, the EAP peer must discover the name of the domain to which it is attached. This document specifies a Dynamic Host Configuration Protocol Version 6 (DHCPv6) option designed to allow a DHCPv6 server to inform clients of the name of the local domain.. 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, Yves Lafon, Julian Reschke, 4-Aug-10, 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, Yves Lafon, Julian Reschke, 4-Aug-10, 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, Yves Lafon, Julian Reschke, 4-Aug-10, 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, Yves Lafon, Julian Reschke, 4-Aug-10, 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, Yves Lafon, Julian Reschke, 4-Aug-10, 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, Yves Lafon, Mark Nottingham, Julian Reschke, 4-Aug-10, 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, Yves Lafon, Julian Reschke, 4-Aug-10, 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. "Security Requirements for HTTP", Jeff Hodges, Barry Leiba, 10-Mar-10, Recent IESG practice dictates that IETF protocols must specify mandatory-to-implement (MTI) security mechanisms, so that all conformant implementations share a common baseline. This document examines all widely deployed HTTP security technologies, and analyzes the trade-offs of each. "Initial Hypertext Transfer Protocol (HTTP) Method Registrations", Julian Reschke, 12-Jul-10, This document registers those Hypertext Transfer Protocol (HTTP) methods which have been defined in standards-track RFCs before the IANA HTTP Method Registry was established. HTTP State Management Mechanism (httpstate) ------------------------------------------- "HTTP State Management Mechanism", Adam Barth, 26-Jul-10, This document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol. Although cookies have many historical infelicities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet.Editorial Note (To be removed by RFC Editor) If you have suggestions for improving this document, please send email to . Suggestions with test cases are especially appreciated. Further Working Group information is available from . BiDirectional or Server-Initiated HTTP (hybi) --------------------------------------------- "HyBi WebSocket Requirements and Features", Gabriel Montenegro, 23-Aug-10, This document considers the requirements and resulting features needed for the design of the WebSocket Protocol. The goal of the document is to provide a stable base for protocol design and related discussion. "The WebSocket protocol", Ian Fette, 1-Sep-10, The WebSocket 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