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 Low Power and Lossy Networks (6LoWPAN)", Jonathan Hui, Pascal Thubert, 24-Feb-11, This document updates RFC 4944, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks". This document specifies an IPv6 header compression format for IPv6 packet delivery in Low Power and Lossy Networks (6LoWPANs). 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, 18-Jan-11, 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 characteristics of each dimension. A complete list of practical use cases is not the goal of this document. "Neighbor Discovery Optimization for Low Power and Lossy Networks (6LoWPAN)", Zach Shelby, Samita Chakrabarti, Erik Nordmark, 24-May-11, The IETF 6LoWPAN working group defines IPv6 over Low-power Wireless Personal Area Networks 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, 7-Feb-11, 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. "Transmission of IPv6 Packets over Bluetooth Low Energy", Basavaraj Patil, Markus Isomaki, Carles Gomez, Teemu Savolainen, Zach Shelby, Johanna Nieminen, 21-Apr-11, Bluetooth Low Energy is a low power air interface technology that is defined by the Bluetooth SIG. The standard Bluetooth radio has been widely implemented and available in mobile phones, notebook computers, audio headsets and many other devices. The low power version of Bluetooth is a new specification and enables the use of this air interface with devices such as sensors, smart meters, appliances, etc. There is an added value in the ability to communicate with sensors over IPv6. This document describes how IPv6 is transported over Bluetooth Low Energy using 6LoWPAN techniques. IPv6 Maintenance (6man) ----------------------- "IPv6 Node Requirements", Edward Jankiewicz, John Loughney, Thomas Narten, 31-May-11, 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. This document obsoletes RFC4294. "Considerations for IPv6 Address Selection Policy Changes", Tim Chown, 14-Mar-11, 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 UDP Checksum Considerations", Gorry Fairhurst, Magnus Westerlund, 21-Apr-11, This document examines the role of the UDP 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 as an indication that no checksum is present. This method is compared with some other possibilities. The document also describes the issues and design principles that need to be considered when UDP is used with IPv6 to support tunnel encapsulations. It concludes that UDP with a zero checksum in IPv6 can safely be used for this purpose, provided that this usage is governed by a set of constraints. "An uniform format for IPv6 extension headers", Suresh Krishnan, James Woodyatt, Erik Kline, James Hoagland, Manav Bhatia, 14-Mar-11, 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 new IPv6 extension headers. "RPL Option for Carrying RPL Information in Data-Plane Datagrams", Jonathan Hui, JP Vasseur, 29-Mar-11, 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, Vishwas Manral, 29-Mar-11, 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. "Update to RFC 3484 Default Address Selection for IPv6", Arifumi Matsumoto, Jun-ya Kato, Tomohiro Fujisaki, 10-Jun-11, RFC 3484 describes algorithms for source address selection and for destination address selection. The algorithms specify default behavior for all Internet Protocol version 6 (IPv6) implementations. This document specifies a set of updates that modify the algorithms and fix the known defects. "Using the IPv6 flow label for equal cost multipath routing and link aggregation in tunnels", Brian Carpenter, Shane Amante, 2-May-11, The IPv6 flow label has certain restrictions on its use. This document describes how those restrictions apply when using the flow label for load balancing by equal cost multipath routing, and for link aggregation, particularly for IP-in-IPv6 tunneled traffic. "Rationale for update to the IPv6 flow label specification", Shane Amante, Brian Carpenter, Sheng Jiang, 12-May-11, Various published proposals for use of the IPv6 flow label are incompatible with its original specification in RFC 3697. Furthermore, very little practical use is made of the flow label, partly due to some uncertainties about the correct interpretation of the specification. This document discusses and motivates changes to the specification in order to clarify it, and to introduce some additional flexibility. "The Line Identification Destination Option", Suresh Krishnan, Alan Kavanagh, Balazs Varga, Sven Ooghe, Erik Nordmark, 14-Mar-11, In Ethernet based aggregation networks, several subscriber premises may be logically connected to the same interface of an edge router. This document proposes a method for the edge router to identify the subscriber premises using the contents of the received Router Solicitation messages. The applicability is limited to broadband network deployment scenarios where multiple user ports are mapped to the same virtual interface on the Edge Router. "Duplicate Address Detection Proxy", Fabio Costa, Jean-Michel Combes, Xavier Pougnard, Li Hongyu, 10-Jan-11, The document describes a mechanism allowing the use of Duplicate Address Detection (DAD) by IPv6 nodes in a point-to-multipoint architecture with "split-horizon" forwarding scheme. Based on the DAD signalling, the first hop router stores in a Binding Table all known IPv6 addresses used on a point-to-multipoint domain (e.g. VLAN). When a node performs DAD for an address already used by another node, the first hop router replies instead of this last one. "IPv6 Flow Label Specification", Shane Amante, Brian Carpenter, Sheng Jiang, Jarno Rajahalme, 12-May-11, This document specifies the IPv6 Flow Label field and the minimum requirements for IPv6 nodes labeling flows, IPv6 nodes forwarding labeled packets, and flow state establishment methods. Even when mentioned as examples of possible uses of the flow labeling, more detailed requirements for specific use cases are out of scope for this document. The usage of the Flow Label field enables efficient IPv6 flow classification based only on IPv6 main header fields in fixed positions. "UDP Checksums for Tunneled Packets", Marshall Eubanks, 7-Mar-11, We address the problem of computing the UDP checksum on tunneling IPv6 packets when using lightweight tunneling protocols. Application Bridging for Federated Access Beyond web (abfab) ------------------------------------------------------------ "A GSS-API Mechanism for the Extensible Authentication Protocol", Sam Hartman, Josh Howlett, 17-Feb-11, This document defines protocols, procedures, and conventions to be employed by peers implementing the Generic Security Service Application Program Interface (GSS-API) when using the EAP mechanism. Through the GS2 family of mechanisms, these protocols also define how Simple Authentication and Security Layer (SASL, RFC 4422) applications use the Extensible Authentication Protocol. "A RADIUS Attribute for SAML Messages", Josh Howlett, Sam Hartman, 10-Mar-11, This document defines the SAML-Message attribute for use with the RADIUS protocol. This attribute is used for encapsulating Security Assertion Mark-up Language (SAML) messages. "Application Bridging for Federated Access Beyond web (ABFAB) Use Cases", Rhys Smith, Mark Tysom, Simon Cooper, 7-Mar-11, Federated authentication is most commonly associated with Web-based services, but there is growing interest in the application of federated authentication for non-Web services. The goal of this document is to drive the development of requirements. ADSL MIB (adslmib) ------------------ "xDSL multi-pair bonding (G.Bond) MIB", Edward Beili, Moti Morgenstern, 26-May-11, 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, 26-May-11, 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, 26-May-11, 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. "Ethernet-based xDSL multi-pair bonding (G.Bond/Ethernet) MIB", Edward Beili, Moti Morgenstern, 26-May-11, 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 Ethernet-based multi-pair bonded xDSL interfaces, defined in ITU-T recommendation G.998.2. Application-Layer Traffic Optimization (alto) --------------------------------------------- "Application-Layer Traffic Optimization (ALTO) Requirements", Sebastian Kiesel, Stefano Previdi, Martin Stiemerling, Richard Woundy, Yang Yang, 10-Jun-11, 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 specifying, assessing, or comparing protocols and implementations. "ALTO Protocol", Richard Alimi, Reinaldo Penno, Yang Yang, 20-May-11, 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. "ALTO Deployment Considerations", Martin Stiemerling, Sebastian Kiesel, 14-Mar-11, 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 these applications, which have to select one or several hosts from a set of candidates, that are able to provide a desired resource. The protocol is under specification in the ALTO working group. This memo discusses deployment related issues of ALTO for peer-to-peer and CDNs, some preliminary security considerations, and also initial guidance for application designers using ALTO. "ALTO Server Discovery", Sebastian Kiesel, Martin Stiemerling, Nico Schwan, Michael Scharf, Song Yongchao, 5-May-11, 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. Entities seeking guidance need to discover and possibly select an ALTO server to ask. This is called ALTO server discovery. This memo describes an ALTO server discovery mechanism based on several alternative mechanisms that are applicable in a diverse set of ALTO deployments. Access Node Control Protocol (ancp) ----------------------------------- "Protocol for Access Node Control Mechanism in Broadband Networks", Sanjay Wadhwa, Jerome Moisand, Thomas Haag, Norbert Voigt, Tom Taylor, 26-Apr-11, 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 remote line connectivity testing. The design of ANCP allows for protocol extensions in other documents if they are needed to support other use cases and other access technologies. ANCP is based on GSMPv3 (RFC 3292), but with many modifications and extensions, to the point that the two protocols are not interoperable. For this reason, ANCP was assigned a separate version number to distinguish it. "Multicast Control Extensions for ANCP", Francois Le Faucheur, Roberta Maglione, Tom Taylor, 9-Feb-11, 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. Applications Area Working Group (appsawg) ----------------------------------------- "The Unicode code points and IDNA - Unicode 6.0", Patrik Faltstrom, Paul Hoffman, 9-Jun-11, This memo documents IETF consensus for IDNA derived character properties related to the three code points, existing in Unicode 5.2, that changed property values when version 6.0 was released. The consensus is that no update is needed to RFC 5892 based on the changes made in Unicode 6.0. "Terminology Used in Internationalization in the IETF", Paul Hoffman, John Klensin, 9-Jun-11, This document provides a glossary of terms used in the IETF when discussing internationalization. The purpose is to help frame discussions of internationalization in the various areas of the IETF and to help introduce the main concepts to IETF participants. Address Resolution for Massive numbers of hosts in the Data center (armd) ------------------------------------------------------------------------- "ARMD Call for Investigation", Benson Schliesser, Linda Dunbar, 31-May-11, This document is a call for investigation into the topic of address resolution in massive datacenters. It describes the intended work of the ARMD working group, providing both context and direction for investigating the issues outlined in the working group's charter. Authority-to-Citizen Alert (atoca) ---------------------------------- "Requirements, Terminology and Framework for Exigent Communications", Henning Schulzrinne, Steve Norreys, Brian Rosen, Hannes Tschofenig, 15-Jan-11, Before, during and after emergency situations various agencies need to provide information to a group of persons or to the public within a geographical area. While many aspects of such systems are specific to national or local jurisdictions, emergencies span such boundaries and notifications need to reach visitors from other jurisdictions. This document provides terminology, requirements and an architectural description for protocols exchanging alerts between IP-based end points. Audio/Video Transport (avt) --------------------------- "Unicast-Based Rapid Acquisition of Multicast RTP Sessions", Bill Ver Steeg, Ali Begen, Tom Van Caenegem, Zeev Vax, 18-Nov-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 RTP Control Protocol (RTCP) 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, this method can also be used in other types of multicast applications where the acquisition delay is long enough to be a problem. Audio/Video Transport Core Maintenance (avtcore) ------------------------------------------------ "Application Mechanism for keeping alive the Network Address Translator (NAT) mappings associated to RTP/RTCP flows.", Xavier Marjou, Aurelien Sollaud, 4-Mar-11, This document lists the different mechanisms that enable applications using Real-time Transport Protocol (RTP) and RTP control protocol (RTCP) 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, 10-Jun-11, 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). "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. "AES-GCM and AES-CCM Authenticated Encryption in Secure RTP (SRTP)", David McGrew, 27-Jan-11, This document defines how AES-GCM, AES-CCM, and other Authenticated Encryption with Associated Data (AEAD) algorithms, can be used to provide confidentiality and data authentication mechanisms in the SRTP protocol. "Encrypted Key Transport for Secure RTP", David McGrew, Flemming Andreasen, Dan Wing, Kai Fischer, 14-Mar-11, 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, and MIKEY. These other key management protocols provide an EKT key to everyone in a session, and EKT coordinates the keys within the session. "Guidelines for the use of Variable Bit Rate Audio with Secure RTP", Colin Perkins, Jean-Marc Valin, 28-Apr-11, This memo discusses potential security issues that arise when using variable bit rate audio with the secure RTP profile. Guidelines to mitigate these issues are suggested. "Explicit Congestion Notification (ECN) for RTP over UDP", Magnus Westerlund, Ingemar Johansson, Colin Perkins, Piers O'Hanlon, Ken Carlberg, 31-May-11, This memo specifies how Explicit Congestion Notification (ECN) can be used with Real-time Transport Protocol (RTP) running over UDP, using RTP Control Protocol (RTCP) as a feedback mechanism. It defines a new RTCP Extended Report (XR) block for periodic ECN feedback, a new RTCP transport feedback message for timely reporting of congestion events, and a Session Traversal Utilities for NAT (STUN) extension used in the optional initilization method using Interactive Connectivity Establishment (ICE). Signalling and procedures for negotiation of capabilities and initilization methods are also defined. "Port Mapping Between Unicast and Multicast RTP Sessions", Ali Begen, Dan Wing, Tom VanCaenegem, 15-Apr-11, 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 provides protection against denial-of-service or packet amplification attacks that could be used to cause one or more RTP packets to be sent to a victim client. "RTCP Extension for Third-party Loss Report", Wenson Wu, Frank Xia, Roni Even, 26-May-11, In a large RTP session using the RTCP feedback mechanism defined in RFC 4585, a feedback target may experience transient overload if some event causes a large number of receivers to send feedback at once. This overload is usually avoided by ensuring that feedback reports are forwarded to all receivers, allowing them to avoid sending duplicate feedback reports. However, there are certain cases where it is not possible to forward feedback reports, and this may allow feedback implosion. This memo defines a new RTCP third-party loss report that can be used to inform receivers that a feedback target is aware of some loss event, allowing them to suppress feedback. Associated SDP signalling is also defined. "Monitoring Architectures for RTP", Wenson Wu, Geoff Hunt, Philip Arden, 26-May-11, This memo proposes an architecture for extending RTCP with a new RTCP XR (RFC3611) block type to report new metrics regarding media transmission or reception quality, as proposed in RFC5968. This memo suggests that a new block should contain a single metric or a small number of metrics relevant to a single parameter of interest or concern, rather than containing a number of metrics which attempt to provide full coverage of all those parameters of concern to a specific application. Applications may then "mix and match" to create a set of blocks which covers their set of concerns. Where possible, a specific block should be designed to be re-usable across more than one application, for example, for all of voice, streaming audio and video. "Encryption of Header Extensions in the Secure Real-Time Transport Protocol (SRTP)", Jonathan Lennox, 1-Jun-11, The Secure Real-Time Transport Protocol (SRTP) provides authentication, but not encryption, of the headers of Real-Time Transport Protocol (RTP) packets. However, RTP header extensions may carry sensitive information for which participants in multimedia sessions want confidentiality. This document provides a mechanism, extending the mechanisms of SRTP, to selectively encrypt RTP header extensions in SRTP. Audio/Video Transport Extensions (avtext) ----------------------------------------- "A Real-Time Transport Protocol (RTP) Header Extension for Client-to- Mixer Audio Level Indication", Jonathan Lennox, Emil Ivov, Enrico Marocco, 2-Jun-11, This document defines a mechanism by which packets of Real-Time Transport Protocol (RTP) audio streams can indicate, in an RTP header extension, the audio level of the audio sample carried in the RTP packet. In large conferences, this can reduce the load on an audio mixer or other middlebox which wants to forward only a few of the loudest audio streams, without requiring it to decode and measure every stream that is received. "A Real-Time Transport Protocol (RTP) Header Extension for Mixer-to- Client Audio Level Indication", Emil Ivov, Enrico Marocco, Jonathan Lennox, 9-May-11, This document describes a mechanism for RTP-level mixers in audio conferences to deliver information about the audio level of individual participants. Such audio level indicators are transported in the same RTP packets as the audio data they pertain to. "Multicast Acquisition Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs)", Ali Begen, Eric Friedrich, 29-May-11, 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. An RTP receiver can use one or more different approaches to achieve rapid acquisition. Yet, due to various factors, performance of the rapid acquisition methods usually varies. Furthermore, in some cases the RTP receiver can do a simple multicast join (in other cases it is compelled to do so). 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) (RFC 3611). This document also defines the necessary signaling of the new MA report block type in the Session Description Protocol (SDP). "Support for multiple clock rates in an RTP session", Marc Petit-Huguenin, 1-Jun-11, This document clarifies the RTP specification when different clock rates are used in an RTP session. It also provides guidance on how to interoperate with legacy RTP implementations that use multiple clock rates. "Considerations and Guidelines for Deploying the Rapid Acquisition of Multicast RTP Sessions (RAMS) Method", Ali Begen, 10-Jun-11, The Rapid Acquisition of Multicast RTP Sessions (RAMS) solution is a method based on RTP and RTP Control Protocol (RTCP) that enables an RTP receiver to rapidly acquire and start consuming the RTP multicast data. Upon a request from the RTP receiver, an auxiliary unicast RTP retransmission session is set up between a retransmission server and the RTP receiver, over which the reference information about the new multicast stream the RTP receiver is about to join is transmitted at an accelerated rate. This often precedes, but may also accompany, the multicast stream itself. When there is only one multicast stream to be acquired, the RAMS solution works in a straightforward manner. However, when there are two or more multicast streams to be acquired from the same or different multicast RTP sessions, care should be taken to configure each RAMS session appropriately. This document provides example scenarios and offers guidelines. Behavior Engineering for Hindrance Avoidance (behave) ----------------------------------------------------- "Stream Control Transmission Protocol (SCTP) Network Address Translation", Randall Stewart, Michael Tuexen, Irene Ruengeler, 30-Dec-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. "An FTP ALG for IPv6-to-IPv4 translation", Iljitsch van Beijnum, 20-May-11, 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 only have IPv6 connectivity 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 specifies a middlebox that may solve this mismatch. "Dual Stack Hosts Using "Bump-in-the-Host" (BIH)", Bill Huang, Hui Deng, Teemu Savolainen, 12-Apr-11, Bump-In-the-Host (BIH) is a host-based IPv4 to IPv6 protocol translation mechanism that allows a class of IPv4-only applications that work through NATs to communicate with IPv6-only peers. The host on which applications are running may be connected to IPv6-only or dual-stack access networks. BIH hides IPv6 and makes the IPv4-only applications think they are talking with IPv4 peers by local synthesis of IPv4 addresses. "Common requirements for IP address sharing schemes", Simon Perreault, Ikuhei Yamagata, Shin Miyakawa, Akira Nakagawa, Hiroyuki Ashida, 14-Mar-11, This document defines common requirements for Carrier-Grade NAT (CGN) devices. "Analysis of Stateful 64 Translation", Reinaldo Penno, Tarun Saxena, Mohammed Boucadair, Senthil Sivakumar, 18-May-11, Due to specific problems, NAT-PT was deprecated by the IETF as a mechanism to perform IPv6-IPv4 translation. Since then, new efforts have been undertaken within IETF to standardize alternative mechanisms to perform IPv6-IPv4 translation. This document evaluates how the new stateful translation mechanisms avoid the problems that caused the IETF to deprecate NAT-PT. "Discovery of a Network-Specific NAT64 Prefix using a Well-Known Name", Teemu Savolainen, Jouni Korhonen, 25-May-11, This document describes a method for detecting presence of DNS64 and for learning IPv6 prefix used for protocol translation on an access network without explicit support from the access network. The method depends on existence of a known IPv4-only domain name. The information learned enables applications and hosts to perform local IPv6 address synthesis and on dual-stack accesses avoid traversal through NAT64. "Analysis of solution proposals for hosts to learn NAT64 prefix", Jouni Korhonen, Teemu Savolainen, 25-May-11, Hosts and applications may benefit from the knowledge if an IPv6 address is synthesized, which would mean a NAT64 is used to reach the IPv4 network or Internet. This document analyses a number of proposed solutions for communicating whether the synthesis is taking place, used address format, and the IPv6 prefix used by the NAT64 and DNS64. The solutions enable both NAT64 avoidance and intentional utilization by allowing local IPv6 address synthesis. The document concludes by recommending selection of heuristic discovery based solution. Basic Level of Interoperability for SIP Services (bliss) -------------------------------------------------------- "Call Completion for Session Initiation Protocol (SIP)", Dale Worley, Martin Huelsemann, Roland Jesske, Denis Alexeitsev, 6-May-11, 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 queuing call- completion requests, this document references the usage of the the dialog event package (RFC 4235) that is described as 'automatic redial' in the SIP Service Examples (RFC 5359). For the realization of a more comprehensive solution with queuing 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, 3-Jun-11, 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, 16-Feb-11, 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 IS-IS and OSPF. "Terminology for Benchmarking Link-State IGP Data Plane Route Convergence", Scott Poretsky, Brent Imhoff, Kris Michielsen, 16-Feb-11, This document describes the terminology for benchmarking link-state 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 "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", Carol Davids, Vijay Gurbani, Scott Poretsky, 14-Mar-11, 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", Carol Davids, Vijay Gurbani, Scott Poretsky, 14-Mar-11, 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. "IP Flow Information Accounting and Export Benchmarking Methodology", Jan Novak, 15-Apr-11, This document provides methodology and framework for quantifying performance impact of monitoring of IP flows on a network device and export of this information to a collector. It identifies the rate at which the IP flows are created, expired and successfully exported as a new performance metric in combination with traditional throughput. The metric is only applicable to the devices compliant with the Architecture for IP Flow Information Export [RFC5470]. Common Control and Measurement Plane (ccamp) -------------------------------------------- "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 van Helvoort, 4-May-11, 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 RFC 4606 by making modifications to the procedures for supporting virtual concatenation. "Traffic Engineering Database Management Information Base in support of MPLS-TE/GMPLS", Tomohiro Otani, 18-Apr-11, 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. "Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks", Greg Bernstein, Young Lee, Dan Li, Wataru Imajuku, 14-Mar-11, 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 optical path 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. "Routing and Wavelength Assignment Information Encoding for Wavelength Switched Optical Networks", Greg Bernstein, Young Lee, Dan Li, Wataru Imajuku, Jianrui Han, 14-Mar-11, 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 OAM Configuration", Attila Takacs, Don Fedyk, He Jia, 14-Mar-11, OAM is an integral part of transport connections, hence it is required that OAM functions are activated/deactivated in sync with connection commissioning/decommissioning; avoiding spurious alarms and ensuring consistent operation. In certain technologies OAM entities are inherently established once the connection is set up, while other technologies require extra configuration to establish and configure OAM entities. This document specifies extensions to RSVP-TE to support the establishment and configuration of OAM entities along with LSP signaling. "GMPLS RSVP-TE Extensions for Ethernet OAM Configuration", Attila Takacs, Balazs Gero, Don Fedyk, Hao Long, 14-Mar-11, The GMPLS controlled Ethernet Label Switching (GELS) work extended 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 defining Ethernet technology specific TLV based on [OAM-CONF-FWK]. "A Framework for the Control of Wavelength Switched Optical Networks (WSON) with Impairments", Young Lee, Greg Bernstein, Dan Li, Giovanni Martinelli, Ming Chen, Jianrui Han, Gabriele Galimberti, Alberto Tanzi, David Bianchi, Moustafa Kattan, Dirk Schroetter, Daniele Ceccarelli, Elisa Bellagamba, Diego Caviglia, 29-Apr-11, As an optical signal progresses along its path it may be altered by the various physical processes in the optical fibers and devices it encounters. When such alterations result in signal degradation, these processes are usually referred to as "impairments". These physical characteristics may be important constraints to consider when using a GMPLS control plane to support path setup and maintenance in wavelength switched optical networks. This document provides a framework for applying GMPLS protocols and the PCE architecture to support Impairment Aware Routing and Wavelength Assignment (IA-RWA) in wavelength switched optical networks. This document does not define optical data plane aspects; impairment parameters, measurement of, or assessment and qualification of a route, but rather it describes the architectural and information components for protocol solutions. "OSPF Enhancement for Signal and Network Element Compatibility for Wavelength Switched Optical Networks", Young Lee, Greg Bernstein, 8-Mar-11, 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, 25-May-11, 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, 13-Mar-11, This specification describes the configuration of pro-active MPLS-TP Operations, Administration, and Maintenance (OAM) Functions for a given LSP using a set of TLVs that can be carried in the RSVP-TE protocol. "MPLS-TP Control Plane Framework", Loa Andersson, Lou Berger, Luyuan Fang, Nabil Bitar, Eric Gray, Attila Takacs, Martin Vigoureux, Elisa Bellagamba, 10-Feb-11, 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 Label Switched Paths (LSPs). MPLS-TP also uses the Pseudowire (PW) control plane for Pseudowires (PWs). Management plane functions are out of scope of this document. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. This Informational Internet-Draft is aimed at achieving IETF Consensus before publication as an RFC and will be subject to an IETF Last Call. [RFC Editor, please remove this note before publication as an RFC and insert the correct Streams Boilerplate to indicate that the published RFC has IETF consensus.] "GMPLS RSVP-TE Extensions for SONET/SDH and OTN OAM Configuration", Andras Kern, Attila Takacs, 27-Apr-11, 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, Daniele Ceccarelli, Jianrui Han, Malcolm Betts, Pietro Grandi, Eve Varma, 11-Mar-11, 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 Zhang Expires September 2011 [page 1] draft-ietf-ccamp-gmpls-g709-framework-04.txt March 2011 Optical Transport Networks (OTN) as specified in ITU-T Recommendation G.709 as consented in October 2009. "Label Switched Path (LSP) Data Path Delay Metrics in Generalized MPLS/ MPLS-TE Networks", Weiqiang Sun, Guoying Zhang, 23-May-11, 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. "Signaling Extensions for Wavelength Switched Optical Networks", Greg Bernstein, 14-Mar-11, This memo provides extensions to Generalized Multi-Protocol Label Switching (GMPLS) signaling for control of wavelength switched optical networks (WSON). Such extensions are necessary in WSONs under a number of conditions including: (a) when optional processing, such as regeneration, must be configured to occur at specific nodes along a path, (b) where equipment must be configured to accept an optical signal with specific attributes, or (c) where equipment must be configured to output an optical signal with specific attributes. In addition this memo provides mechanisms to support distributed wavelength assignment with bidirectional LSPs, and choice in distributed wavelength assignment algorithms. These extensions build on previous work for the control of lambda and G.709 based networks. "Link Management Protocol Behavior Negotiation and Configuration Modifications", Dan Li, Daniele Ceccarelli, Lou Berger, 6-Jun-11, The Link Management Protocol (LMP) is used to coordinate the properties, use, and faults of data links in Generalized Multiprotocol Label Switching (GMPLS) networks. This document defines an extension to LMP to negotiate capabilities and indicate support for LMP extensions. The defined extension is compatible with non-supporting implementations. "RSVP Resource Sharing Remote Identification Association", Francois Le Faucheur, Ashok Narayanan, Subha Dhesikan, 9-Mar-11, The Resource reSerVation Protocol (RSVP) ASSOCIATION object allows to create association across RSVP path states or across Resv states. Two association types are currently defined: recovery and resource sharing. This document defines a new association type called "Resource Sharing Remote Identification". It can be used by the sender to convey to the receiver the information that can then be used by the receiver to identify a downstream initiated resource sharing association. "Usage of The RSVP Association Object", Lou Berger, 1-May-11, The RSVP ASSOCIATION object was defined in the context of GMPLS (Generalized Multi-Protocol Label Switching) controlled label switched paths (LSPs). In this context, the object is used to associate recovery LSPs with the LSP they are protecting. This document reviews how association is to be provided in the context of GMPLS recovery. No new procedures or mechanisms are defined by this document and it is strictly informative in nature. "LSP Attributes Related Routing Backus-Naur Form", Lou Berger, George Swallow, 12-May-11, Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) established using the Resource Reservation Protocol Traffic Engineering (RSVP-TE) extensions may be signaled with a set of LSP specific attributes. These attributes may be carried in both Path and Resv messages. This document specifies how LSP attributes are to be carried in RSVP Path and Resv messages using the Routing Backus-Naur Form, and clarifies related Resv message formats. "GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs)", Attila Takacs, Lou Berger, Diego Caviglia, Don Fedyk, Julien Meuric, 27-Jan-11, This document defines a method for the support of GMPLS asymmetric bandwidth bidirectional Label Switched Paths (LSPs). The presented approach is applicable to any switching technology and builds on the original Resource Reservation Protocol (RSVP) model for the transport of traffic-related parameters. This document moves the experiment documented in RFC 5467 to the standards track and obsoletes RFC 5467. "OSPF-TE Extensions for General Network Element Constraints", Fatai Zhang, Young Lee, Jianrui Han, Greg Bernstein, Yunbin Xu, Guoying Zhang, Dan Li, Ming Chen, Yabin Ye, 13-Mar-11, Generalized Multiprotocol Label Switching can be used to control a wide variety of technologies including packet switching (e.g., MPLS), time-division (e.g., SONET/SDH, OTN), wavelength (lambdas), and Expires September 2011 [page 1] draft-ietf-ccamp-gmpls-general-constraints-ospf-te-00.txt March 2011 spatial switching (e.g., incoming port or fiber to outgoing port or fiber). 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 describes OSPF routing protocol extensions to support these kinds of constraints under the control of Generalized MPLS (GMPLS). "RSVP-TE Extensions to Establish Associated Bidirectional LSP", Fei Zhang, Ruiquan Jing, 1-Jun-11, The MPLS Transport Profile (MPLS-TP) requirements document [RFC5654], describes that MPLS-TP MUST support associated bidirectional point- to-point LSPs. This document provides a method to bind two unidirectional Label Switched Paths (LSPs) into an associated bidirectional LSP. The association is achieved by using a new Association Type in the Extended ASSOCIATION object. "Information model for G.709 Optical Transport Networks (OTN)", Sergio Belotti, Pietro Grandi, Daniele Ceccarelli, Diego Caviglia, Fatai Zhang, Dan Li, 18-Apr-11, The recent revision of ITU-T recommendation G.709 [G.709-v3] has introduced new fixed and flexible ODU containers in Optical Transport Networks (OTNs), enabling optimized support for an increasingly abundant service mix. This document provides a model of information needed by the routing and signaling process in OTNs to support Generalized Multiprotocol Label Switching (GMPLS) control of all currently defined ODU containers. "Updates to ASON Routing for OSPFv2 Protocols (RFC 5787bis)", Andrew Malis, Acee Lindem, 27-May-11, The ITU-T has defined an architecture and requirements for operating an Automatically Switched Optical Network (ASON). The Generalized Multiprotocol Label Switching (GMPLS) protocol suite is designed to provide a control plane for a range of network technologies including optical networks such as time division multiplexing (TDM) networks including SONET/SDH and Optical Transport Networks (OTNs), and lambda switching optical networks. The requirements for GMPLS routing to satisfy the requirements of ASON routing, and an evaluation of existing GMPLS routing protocols are provided in other documents. This document defines extensions to the OSPFv2 Link State Routing Protocol to meet the requirements for routing in an ASON. Note that this work is scoped to the requirements and evaluation expressed in RFC 4258 and RFC 4652 and the ITU-T Recommendations current when those documents were written. Future extensions of revisions of this work may be necessary if the ITU-T Recommendations are revised or if new requirements are introduced into a revision of RFC 4258. "RSVP Association Object Extensions", Lou Berger, Francois Faucheur, Ashok Narayanan, 3-May-11, The RSVP ASSOCIATION object was defined in the context of GMPLS (Generalized Multi-Protocol Label Switching) controlled label switched paths (LSPs). In this context, the object is used to associate recovery LSPs with the LSP they are protecting. This object also has broader applicability as a mechanism to associate RSVP state, and this document defines how the ASSOCIATION object can be more generally applied. This document also defines extended ASSOCIATION objects which, in particular, can be used in the context of Transport Profile of Multiprotocol Label Switching (MPLS-TP). This document updates RFC 2205, RFC 3209, and RFC 3473. Internet Wideband Audio Codec (codec) ------------------------------------- "Codec Requirements", Jean-Marc Valin, Koen Vos, 19-May-11, 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. "Definition of the Opus Audio Codec", Jean-Marc Valin, Koen Vos, 14-Mar-11, This document describes the Opus codec, designed for interactive speech and audio transmission over the Internet. "Guidelines for the Codec Development Within the IETF", Jean-Marc Valin, Slava Borilin, Koen Vos, Christopher Montgomery, Juin-Hwey Chen, 21-Jan-11, This document provides general guidelines for work on developing and specifying a codec within the IETF. These guidelines cover the development process, evaluation, requirements conformance, and intellectual property issues. Congestion Exposure (conex) --------------------------- "ConEx Concepts and Use Cases", Toby Moncaster, John Leslie, Bob Briscoe, Richard Woundy, Dave McDysan, 14-Mar-11, Internet Service Providers (operators) are facing problems where localized congestion prevents full utilization of the path between sender and receiver at today's "broadband" speeds. Operators desire to control this congestion, which often appears to be caused by a small number of users consuming a large amount of bandwidth. Building out more capacity along all of the path to handle this congestion can be expensive and may not result in improvements for all users so network operators have sought other ways to manage congestion. The current mechanisms all suffer from difficulty measuring the congestion (as distinguished from the total traffic). The ConEx Working Group is designing a mechanism to make congestion along any path visible at the Internet Layer. This document describes example cases where this mechanism would be useful. "Congestion Exposure (ConEx) Concepts and Abstract Mechanism", Matt Mathis, Bob Briscoe, 14-Mar-11, This document describes an abstract mechanism by which senders inform the network about the congestion encountered by packets earlier in the same flow. Today, the network may signal congestion to the receiver by ECN markings or by dropping packets, and the receiver passes this information back to the sender in transport-layer feedback. The mechanism to be developed by the ConEx WG will enable the sender to also relay this congestion information back into the network in-band at the IP layer, such that the total level of congestion is visible to all IP devices along the path, from where it could, for example, provide input to traffic management. Constrained RESTful Environments (core) --------------------------------------- "Constrained Application Protocol (CoAP)", Zach Shelby, Klaus Hartke, Carsten Bormann, Brian Frank, 3-May-11, This document specifies the Constrained Application Protocol (CoAP), a specialized web 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 a 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. "Blockwise transfers in CoAP", Carsten Bormann, Zach Shelby, 3-May-11, CoAP is a RESTful transfer protocol for constrained nodes and networks. CoAP is based on datagram transport, which limits the maximum size of resource representations that can be transferred without too much fragmentation. The Block options provide a minimal way to transfer larger representations in a block-wise fashion. "CoRE Link Format", Zach Shelby, 22-May-11, This document defines Web Linking using a link format for use by constrained web servers to describe hosted resources, their attributes and other relationships between links. Based on the HTTP Link Header format defined in RFC5988, the CoRE Link Format is carried as a payload and is assigned an Internet media type. A well- known URI is defined as a default entry-point for requesting the links hosted by a server. "Observing Resources in CoAP", Klaus Hartke, Zach Shelby, 14-Mar-11, CoAP is a RESTful application protocol for constrained nodes and networks. The state of a resource on a CoAP server can change over time. This specification provides a simple extension for CoAP that gives clients the ability to observe such changes. Cga & Send maIntenance (csi) ---------------------------- "SEND Hash Threat Analysis", Ana Kukec, Suresh Krishnan, Sheng Jiang, 7-Mar-11, 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 currently uses the SHA-1 hash algorithm [SHA1] and PKIX certificates 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, 28-Sep-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 and/or posses a key which authorizes the node to act as a router, so that it is in possession of the private key or keys used to generate the digital signature on each message. This means that the Proxy ND signaling performed by nodes that do not possess knowledge of the address owner's private key and/or knowledge of a router's 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, 24-Nov-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, 29-May-11, This document analyzes the possible interactions between DHCPv6 and Cryptographically Generated Addresses (CGAs), and gives recommendations and reasons whether these possibilities should be developed as solutions or be declined in the future. This document itself does NOT define any concrete solutions. "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). Call Control UUI Service for SIP (cuss) --------------------------------------- "Problem Statement and Requirements for Transporting User to User Call Control Information in SIP", Alan Johnston, Laura Liess, 27-May-11, This document introduces the transport of call control related User to User Information (UUI) using the Session Initiation Protocol (SIP), and develops several requirements for a new SIP mechanism. Some SIP sessions are established by or related to a non-SIP application. This application may have information that needs to be transported between the SIP User Agents during session establishment. A common example in another protocol is the ISDN User to User Information Service. As networks move to SIP it is important that applications requiring this data can continue to function in SIP networks as well as the ability to interwork with this ISDN service for end-to-end transparency. This document discusses requirements and approaches to achieve this. In addition, the extension will also be used for native SIP endpoints implementing similar services and interworking with ISDN services. Example use cases include an exchange between two user agents, retargeting by a proxy, and redirection. An example application is an Automatic Call Distributor (ACD) in a contact center. "A Mechanism for Transporting User to User Call Control Information in SIP", Alan Johnston, Joanne McMillen, James Rafferty, 7-Feb-11, There is a need for applications using SIP to exchange User to User Information (UUI) data during session establishment. This information, known as call control UUI, is a small piece of data inserted by an application initiating the session, and utilized by an application accepting the session. This data is opaque to SIP and its function is unrelated to any basic SIP function. This document defines a new SIP header field, User-to-User, to transport UUI, along with an extension mechanism. DNS-based Authentication of Named Entities (dane) ------------------------------------------------- "Using Secure DNS to Associate Certificates with Domain Names For TLS", Paul Hoffman, Jakob Schlyter, 3-Jun-11, TLS and DTLS use PKIX certificates for authenticating the server. Users want their applications to verify that the certificate provided by the TLS server is in fact associated with the domain name they expect. TLSA provides bindings of keys to domains that are asserted not by external entities, but by the entities that operate the DNS. This document describes how to use secure DNS to associate the TLS server's certificate with the intended domain name. "Use Cases and Requirements for DNS-based Authentication of Named Entities (DANE)", Richard Barnes, 12-Jun-11, Many current applications use the certificate-based authentication features in TLS to allow clients to verify that a connected server properly represents a desired domain name. Traditionally, this authentication has been based on PKIX trust hierarchies, rooted in well-known CAs, but additional information can be provided via the DNS itself. This document describes a set of use cases in which the DNS and DNSSEC could be used to make assertions that support the TLS authentication process. Datagram Congestion Control Protocol (dccp) ------------------------------------------- "Datagram Congestion Control Protocol (DCCP) Encapsulation for NAT Traversal (DCCP-UDP)", Thomas Phelan, Gorry Fairhurst, Colin Perkins, 17-May-11, This document specifies an alternative encapsulation of the Datagram Congestion Control Protocol (DCCP), referred to as DCCP-UDP. This encapsulation allows DCCP to be carried through the current generation of Network Address Translation (NAT) middleboxes without modification of those middleboxes. This document also updates the SDP information for DCCP defined in RFC 5762. "Sender RTT Estimate Option for DCCP", Gerrit Renker, Gorry Fairhurst, 20-Apr-11, This document specifies an update to the round trip time (RTT) estimation algorithm used for TFRC (TCP Friendly Rate Control) congestion control by the Datagram Congestion Control Protocol (DCCP). It updates specifications for the CCID-3 and CCID-4 Congestion Control IDs of DCCP. The update addresses parameter-estimation problems occurring with TFRC-based DCCP congestion control. It uses a recommendation made in the original TFRC specification to avoid the inherent problems of receiver-based RTT sampling, by utilising higher-accuracy RTT samples already available at the sender. It is integrated into the feature set of DCCP as an end-to-end negotiable extension. Decoupled Application Data Enroute (decade) ------------------------------------------- "DECoupled Application Data Enroute (DECADE) Problem Statement", Haibin Song, Ning Zong, Yang Yang, Richard Alimi, 14-Mar-11, 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 transit and uplink P2P traffic is to introduce storage capabilities within the network (the download traffic may increase because the in- network storage is likely much better connected). Traditional P2P and Web caches provide such storage, but they are complex (due to explicitly supporting individual P2P application protocols and cache refreshing mechanisms) and they do not allow users to manage access to content in the cache. For example, content providers cannot easily control cache access and resource usage policies to satisfy their own requirements, in the case when the content provider is also the user of in-network storage. 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 access protocol can also be used by other applications with similar requirements. "A Survey of In-network Storage Systems", Richard Alimi, Akbar Rahman, Yang Yang, 4-Mar-11, This document surveys deployed and experimental in-network storage systems and describes their applicability for DECADE. "DECADE Requirements", Gu Yingjie, David Bryan, Yang Yang, Richard Alimi, 20-May-11, The target of DECoupled Application Data Enroute (DECADE) is to provide an open and standard in-network storage system for applications, primarily P2P applications, to store, retrieve and manage their data. This draft enumerates and explains requirements, not only for store and retrieve, but also for data management, access control and resource control, that should be considered during the design and implementation of a DECADE system. These are requirements on the entire system; some of the requirements may eventually be implemented by an existing protocol with/without some extensions (e.g., the data transport level). A user of DECADE as a complete architecture would be guaranteed complete functionality. "DECADE Architecture", Richard Alimi, Yang Yang, Akbar Rahman, Dirk Kutscher, Hongqiang Liu, 21-May-11, 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. One technique to improve the network efficiency of P2P applications is to introduce storage capabilities within the networks. The DECADE Working Group has been formed with the goal of developing an architecture to provide this capability. This document presents an architecture, discusses the underlying principles, and identifies core components and protocols supporting the architecture. "Integration Examples of DECADE System", Lijiang Chen, Hongqiang Liu, Zhigang Huang, Xiaohui Chen, 16-May-11, DECADE is an in-network storage infrastructure which is under discussions and constructions. It can be integrated into Peer-to- Peer (P2P) applications to achieve more efficient content distributions. This document represents two detailed examples of how to integrate DECADE into P2P applications (live streaming and file sharing). Specifically, it describes mainly about: 1) a preliminary DECADE client API; 2) a P2P live streaming integration with DECADE; 3) a P2P file sharing integration with DECADE; 4) tests on our DECADE integrarions and 5) an application performance analysis from the tests. Dynamic Host Configuration (dhc) -------------------------------- "Virtual Subnet Selection Options for DHCPv4 and DHCPv6", Kim Kinnear, Richard Johnson, Mark Stapp, Jay Kumarasamy, 29-Apr-11, This memo defines a Virtual Subnet Selection (VSS) option for each of DHCPv4 and DHCPv6, and a VSS sub-option carried in the DHCPv4 relay- agent-information 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, 3-Jun-11, 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. "Layer 2 Relay Agent Information", Bharat Joshi, Pavan Kurapati, 6-Apr-11, In some networks, DHCP servers rely on Relay Agent Information option appended by Relay Agents for IP address and other parameter assignment policies. This works fine when end hosts are directly connected to Relay Agents. In some network configurations, one or more Layer 2 devices may reside between DHCP clients and Relay agent. In these network scenarios, it is difficult to use the Relay Agent Information option for IP address and other parameter assignment policies effectively. So there is a need for the device that is closest to the end hosts to append a Relay Agent Information option in DHCP messages. These devices are typically known as Layer 2 Relay Agents. This document aims to describe the network scenarios where a Layer 2 Relay Agent is in use and also how it handles DHCP messages. "The DHCPv4 Relay Agent Identifier Suboption", Bharat Joshi, Mark Stapp, 4-Jun-11, This draft 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 within the administrative domain. The value is typically administratively-configured in the relay agent. The suboption allows a DHCP relay agent to include the identifier in the DHCP messages it sends. "Bulk DHCPv4 Lease Query", Kim Kinnear, Bernie Volz, Neil Russell, Mark Stapp, D.T.V. Ramakrishna Rao, Bharat Joshi, Pavan Kurapati, 2-May-11, 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. "Forcerenew Nonce Authentication", David Miles, Wojciech Dec, James Bristow, Roberta Maglione, 10-Mar-11, DHCP Forcerenew allows for the reconfiguration of a single host by forcing the DHCP client into a Renew state on a trigger from the DHCP server. In Forcerenew Nonce Authentication the server exchanges a nonce with the client on the initial DHCP ACK that is used for subsequent validation of a Forcerenew message. "Secure DHCPv6 Using CGAs", Sheng Jiang, 20-Dec-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. "Relay-Supplied DHCP Options", Ted Lemon, Wenson Wu, 8-May-11, This document describes a mechanism whereby a DHCPv6 relay agent can provide options to a DHCPv6 server that the DHCPv6 server can then provide to the DHCPv6 client in certain restricted cases where this is necessary. "Definition of the UUID-based DHCPv6 Unique Identifier (DUID-UUID)", Thomas Narten, Jarrod Johnson, 4-Feb-11, This document defines a new DHCPv6 Unique Identifier (DUID) type, called DUID-UUID. DUID-UUIDs are derived from the already standardized UUID format. DUID-UUID makes it possible for devices to use UUIDs to identify themselves to DHC servers and vice versa. UUIDs are globally unique and readily available on many systems, making them convenient identifiers to leverage within DHCP. "Prefix Exclude Option for DHCPv6-based Prefix Delegation", Jouni Korhonen, Teemu Savolainen, Suresh Krishnan, Ole Troan, 11-Jan-11, This specification defines an optional mechanism to allow exclusion of one specific prefix from a delegated prefix set when using DHCPv6- based prefix delegation. "DHCPv6 Redundancy Deployment Considerations", John Jason Brzozowski, Jean-Francois Tremblay, Jack Chen, Tomasz Mrugalski, 9-Apr-11, This document documents some deployment considerations for those who wishing to use DHCPv6 to support their deployment of IPv6. Specifically, providing semi-redundant DHCPv6 services is discussed in this document. "Configuring Cryptographically Generated Addresses (CGA) using DHCPv6", Sheng Jiang, Zhongqi Xia, 11-Apr-11, A Cryptographically Generated Address is an IPv6 addresses binding with a public/private key pair. However, the current CGA specifications are lack of procedures to enable proper management of the usage of CGAs. This document defines the process using DHCPv6 to manage CGAs in detail. A new DHCPv6 option is defined accordingly. This document also analyses the configuration of the parameters, which are used to generate CGAs, using DHCPv6. Although the document does not define new DHCPv6 option to carry these parameters for various reasons, the configuration procedure is described. "Prefix Assignment in DHCPv6", Sheng Jiang, Frank Xia, Behcet Sarikaya, 15-May-11, This document describes a procedure for configuring hosts' IPv6 address which the prefix is assigned from a DHCPv6 server through DHCPv6 protocol while the interface identifiers are independently generated by the hosts. The method is applicable to Cryptographically Generated Addresses (CGA), and other IPv6 addresses with host-generated interface identifiers. Diameter Maintenance and Extensions (dime) ------------------------------------------ "Diameter Base Protocol", Victor Fajardo, Jari Arkko, John Loughney, Glen Zorn, 21-Jan-11, 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 support for EAP Re-authentication Protocol (ERP)", Julien Bournelle, Lionel Morand, Sebastien Decugis, Wenson Wu, Glen Zorn, 4-May-11, 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, 4-May-11, 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, 24-Oct-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. "Diameter Network Address and Port Translation Control Application", Frank Brockners, Cisco Systems, Vaneeta Singh, Victor Fajardo, 16-Feb-11, This document describes the framework, messages, and procedures for the Diameter Network address and port translation Control Application. This Diameter application allows per endpoint control of Network Address Translators and Network Address and Port Translators, which are added to cope with IPv4-address space completion. This Diameter application allows external devices to configure and manage a Network Address Translator device - expanding the existing Diameter-based AAA and policy control capabilities with a Network Address Translators and Network Address and Port Translators control component. These external devices can be network elements in the data plane such as a Network Access Server, or can be more centralized control plane devices such as AAA-servers. This Diameter application establishes a context to commonly identify and manage endpoints on a gateway or server, and a Network Address Translator and Network Address and Port Translator device. This includes, for example, the control of the total number of Network Address Translator bindings allowed or the allocation of a specific Network Address Translator binding for a particular endpoint. In addition, it allows Network Address Translator devices to provide information relevant to accounting purposes. "Diameter S-NAPTR Usage", Mark Jones, Jouni Korhonen, Lionel Morand, 9-May-11, The Diameter base protocol specifies mechanisms whereby a given realm may advertise Diameter nodes and the supported transport protocol. However, these mechanisms do not reveal the Diameter applications that each node supports. A peer outside the realm would have to perform a Diameter capability exchange with every node until it discovers one that supports the required application. This document updates [RFC3588] and describes an improvement using an extended format for the Straightforward-Naming Authority Pointer (S-NAPTR) Application Service Tag that allows for discovery of the supported applications without doing Diameter capability exchange beforehand. "Diameter IKEv2 PSK: Pre-Shared Secret-based Support for IKEv2 Server to Diameter Server Interaction", Violeta Cakulev, Avi Lior, 1-Jun-11, 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. 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 specifies IKEv2 server, as a Diameter client, to the Diameter server communication for IKEv2 with pre- shared secret based authentication. "Diameter Attribute-Value Pairs for Cryptographic Key Transport", Glen Zorn, Wenson Wu, Violeta Cakulev, 25-May-11, 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, 5-May-11, 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: "Diameter Priority Attribute Value Pairs", Ken Carlberg, Tom Taylor, 20-Oct-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, 7-Jan-11, 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, 3-Jun-11, DomainKeys Identified Mail (DKIM) allows an administrative mail domain (ADMD) to assume some responsibility for a message. Based on deployment experience with DKIM, this document provides guidance for the use of DKIM with scenarios that include Mailing List Managers (MLMs). "DomainKeys Identified Mail (DKIM) Signatures", D. Crocker, Tony Hansen, M. Kucherawy, 11-May-11, 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. This memo obsoletes RFC4871 and RFC5672. "RFC4871 Implementation Report", Murray Kucherawy, 28-Mar-11, This document contains an implementation report for the IESG covering DomainKeys Identified Mail (DKIM) in support of the advancement of that specification along the Standards Track. DNS Extensions (dnsext) ----------------------- "Update to DNAME Redirection in the DNS", Scott Rose, Wouter Wijngaards, 2-May-11, 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)", Joao Damas, Michael Graff, Paul Vixie, 7-Mar-11, 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. "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, 26-May-11, 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 implementation compliance status for DNSSEC implementations. This status is to measure compliance to this RFC only. This document replaces that registry table with a new IANA registry table for Domain Name System Security (DNSSEC) Algorithm Numbers that lists (or assigns) each algorithm's status based on the current reference. "Signaling Cryptographic Algorithm Understanding in DNSSEC", Steve Crocker, Scott Rose, 30-Mar-11, The DNS Security Extensions (DNSSEC) were developed to provide origin authentication and integrity protection for DNS data by using digital signatures. These digital signatures can be generated using different algorithms. This draft sets out to specify a way for validating end-system resolvers to signal to a server which cryptographic algorithms they support. "Elliptic Curve DSA for DNSSEC", Paul Hoffman, Wouter Wijngaards, 12-Jan-11, This document describes how to specify Elliptic Curve DSA keys and signatures in DNSSEC. It lists curves of different sizes, and uses the SHA-2 family of hashes for signatures. "Problem Statement: DNS Resolution of Aliased Names", Suzanne Woolf, XiaoDong Lee, Jiankang Yao, 14-Mar-11, This document attempts to describe a set of issues that arises from the desire to treat a set or group of names as "aliases" of each other, "bundled," "variants," or "the same," which is problematic in terms of corresponding behavior for DNS labels and FQDNs. With the emergence of internationalized domain names, among other potential use cases, two or more names that users will regard as having identical meaning may sometimes require corresponding behavior in the underlying infrastructure, possibly in the DNS itself. It's not clear how to accommodate this required behavior of such names in DNS resolution; in particular, it's not clear when they are best accommodated in registry practices for generating names for lookup in the DNS, existing DNS protocol elements and behavior, existing application-layer mechanisms and practices, or some set of protocol elements or behavior not yet defined. This document attempts to describe some of these cases and the behavior of some of the possible solutions discussed to date. Domain Name System Operations (dnsop) ------------------------------------- "DNS Referral Response Size Issues", Paul Vixie, Akira Kato, 13-Mar-11, With a mandated default minimum maximum UDP message size of 512 octets, the DNS protocol presents some special problems for zones wishing to expose a moderate or high number of authority servers (NS RRs). This document explains the operational issues caused by, or related to this response size limit, and suggests ways to optimize the use of this limited space. Guidance is offered to DNS server implementors and to DNS zone operators. "Locally-served DNS Zones", Mark Andrews, 14-Mar-11, 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, 11-May-11, Many sites connected to the Internet make use of IPv4 addresses that are not globally-unique. Examples are the addresses designated in RFC 1918 for private use within individual sites. Devices in such environments may occasionally originate Domain Name System (DNS) queries (so-called "reverse lookups") corresponding to those private-use addresses. Since the addresses concerned have only local significance, it is good practice for site administrators to ensure that such queries 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 IN-ADDR.ARPA authoritative servers. The AS112 project is named after the Autonomous System Number (ASN) that was assigned to it. 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-Apr-11, 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. "DNSSEC Operational Practices, Version 2", Olaf Kolkman, Matthijs Mekking, 11-Mar-11, 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. 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, 14-Mar-11, 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 Key Timing Considerations", Stephen Morris, Johan Ihren, John Dickinson, 10-Mar-11, 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, 12-Mar-11, 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, 3-May-11, 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, 19-Apr-11, 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) ---------------------------------------- "Overview and Framework for Internationalized Email", John Klensin, YangWoo Ko, 27-Sep-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, W. Mao, 1-Jun-11, This document specifies an SMTP extension for transport and delivery of email messages with internationalized email addresses or header information. "Internationalized Email Headers", Abel Yang, Shawn Steele, 15-Mar-11, Internet mail was originally limited to 7-bit ASCII. Recent enhancements support Unicode's UTF-8 encoding in portions of a message. Full internationalization of electronic mail requires additional enhancement, including support for UTF-8 in user-oriented header fields, such as in the To, From, and Subject fields. This document specifies an enhancement to Internet mail that permits native UTF-8 support in the header and body of a message. "POP3 Support for UTF-8", Randall Gellens, Chris Newman, Jiankang Yao, Kazunori Fujiwara, 30-Mar-11, This specification extends the Post Office Protocol version 3 (POP3) to support un-encoded international characters in user names, passwords, mail addresses, message headers, and protocol-level textual error strings. "Post-delivery Message Downgrading for Internationalized Email Messages", Kazunori Fujiwara, 17-Apr-11, The Email Address Internationalization (UTF8SMTP) extension allows UTF-8 characters in mail header fields. POP and IMAP servers support internationalized email messages. If a POP/IMAP client does not support Email Address Internationalization, POP/IMAP servers cannot send Internationalized Email Headers to the client and cannot remove the message. To avoid the situation, this document describes a conversion mechanism for internationalized Email messages to be traditional message format. "Internationalized Delivery Status and Disposition Notifications", Tony Hansen, Chris Newman, Alexey Melnikov, 1-Apr-11, Delivery status notifications (DSNs) are critical to the correct operation of an email system. However, the existing Draft Standards (RFC 3461, RFC 3462, RFC 3464) are presently limited to US-ASCII text in the machine-readable portions of the protocol. This specification adds a new address type for international email addresses so an original recipient address with non-US-ASCII characters can be correctly preserved even after downgrading. This also provides updated content return media types for delivery status notifications and message disposition notifications to support use of the new address type. This document extends RFC 3461, RFC 3462, RFC 3464, and RFC 3798. It replaces the experimental RFC 5337. "IMAP Support for UTF-8", Pete Resnick, Chris Newman, Sean Shen, 30-Mar-11, This specification extends the Internet Message Access Protocol version 4rev1 (IMAP4rev1) to support UTF-8 encoded international characters in user names, mail addresses and message headers. Emergency Context Resolution with Internet Technologies (ecrit) --------------------------------------------------------------- "Best Current Practice for Communications Services in support of Emergency Calling", Brian Rosen, James Polk, 28-Mar-11, 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, 25-Oct-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, 29-Mar-11, 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. "Using Imprecise Location for Emergency Context Resolution", Richard Barnes, Matt Lepinski, 29-Mar-11, 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. "Trustworthy Location Information", Hannes Tschofenig, Henning Schulzrinne, Bernard Aboba, 24-May-11, For some location-based applications, such as emergency calling or roadside assistance, it is important to be able to determine whether location information is trustworthy. This document outlines potential threats to trustworthy location and analyzes the operational issues with potential solutions. "Extensions to the Emergency Services Architecture for dealing with Unauthenticated and Unauthorized Devices", Henning Schulzrinne, Stephen McCann, Gabor Bajko, Hannes Tschofenig, Dirk Kroeselberg, 29-Mar-11, The IETF emergency services architecture assumes that the calling device has acquired rights to use the access network or that no authentication is required for the access network, such as for public wireless access points. Subsequent protocol interactions, such as obtaining location information, learning the address of the Public Safety Answering Point (PSAP) and the emergency call itself are largely decoupled from the underlying network access procedures. In some cases, however, the device does not have these credentials for network access, does not have a VoIP service provider, or the credentials have become invalid, e.g., because the user has exhausted their prepaid balance or the account has expired. This document provides a problem statement, introduces terminology and describes an extension for the base IETF emergency services architecture to address these scenarios. Energy Management (eman) ------------------------ "Requirements for Energy Management", Juergen Quittek, Rolf Winter, Thomas Dietz, Benoit Claise, Mouli Chandramouli, 14-Mar-11, This memo discusses requirements for energy management, particularly for monitoring energy consumption and controlling power states of managed devices. This memo further shows that existing IETF standards are not sufficient for energy management and that energy management requires architectural considerations that are different from common other management functions. "Energy-aware Networks and Devices MIB", Benoit Claise, John Parello, 13-Mar-11, This document defines a subset of the Management Information Base (MIB) for power and energy monitoring of devices. The module addresses devices identification, context information, and the relationship between reporting devices, remote devices, and monitoring probes. "Energy Management Framework", Benoit Claise, John Parello, Little Silver, 14-Mar-11, This document defines an energy management framework. Expires September 14, 2011 [page 2] Internet-Draft March 2011 "Definition of Managed Objects for Battery Monitoring", Juergen Quittek, Rolf Winter, Thomas Dietz, 8-Apr-11, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines managed objects that provide information on the status of batteries in managed devices. EAP Method Update (emu) ----------------------- "Requirements for a Tunnel Based EAP Method", Katrin Hoeper, Stephen Hanna, Hao Zhou, Joseph Salowey, 16-Dec-10, This memo defines the requirements for a tunnel-based Extensible Authentication Protocol (EAP) Method. This tunnel 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, 9-Feb-11, 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. "Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST) Version 2", Hao Zhou, Nancy Cam-Winget, Joseph Salowey, Stephen Hanna, 13-May-11, This document defines the Extensible Authentication Protocol (EAP) based Flexible Authentication via Secure Tunneling (EAP-FAST) protocol version 2. EAP-FAST is an EAP method that enables secure communication between a peer and a server by using the Transport Layer Security (TLS) to establish a mutually authenticated tunnel. Within the tunnel, Type-Length-Value (TLV) objects are used to convey authentication related data between the EAP peer and the EAP server. Telephone Number Mapping (enum) ------------------------------- "IANA Registration for Enumservice 'iax'", Ed Guy, Klaus Darilion, 28-Mar-11, This document registers an Enumservice for the IAX protocol according to the guidelines given in RFC 6117. FEC Framework (fecframe) ------------------------ "Forward Error Correction (FEC) Framework", Mark Watson, Ali Begen, Vincent Roca, 9-Jun-11, 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 FEC 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 FEC 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 Elements for FEC Framework", Ali Begen, 20-Oct-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, 30-May-11, 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. "Raptor FEC Schemes for FECFRAME", Mark Watson, Thomas Stockhammer, Michael Luby, 9-Dec-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, Thomas Stockhammer, 25-Nov-10, This document specifies an RTP payload format for Forward Error Correction /(FEC) 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. "Simple Reed-Solomon Forward Error Correction (FEC) Scheme for FECFRAME", Vincent Roca, Mathieu Cunche, Jerome Lacan, Amine Bouabdallah, Kazuhisa Matsuzono, 28-Feb-11, This document describes a fully-specified simple FEC scheme for Reed- Solomon codes over GF(2^^m), with 2 <= m <= 16, that can be used to protect arbitrary media streams along the lines defined by the FECFRAME framework. Reed-Solomon codes belong to the class of Maximum Distance Separable (MDS) codes which means they offer optimal protection against packet erasures. They are also systematic codes, which means that the source symbols are part of the encoding symbols. The price to pay is a limit on the maximum source block size, on the maximum number of encoding symbols, and a computational complexity higher than that of LDPC codes for instance. Forwarding and Control Element Separation (forces) -------------------------------------------------- "ForCES Logical Function Block (LFB) Library", Weiming Wang, Evangelos Haleplidis, Kentaro Ogawa, Chuanhuang Li, J. Halpern, 2-Jun-11, This document defines basic classes of Logical Function Blocks (LFBs) used in the Forwarding and Control Element Separation (ForCES). It is defined according to ForCES FE model [RFC5812] and ForCES protocol [RFC5810] specifications. These basic LFB classes are scoped to meet requirements of typical router functions and considered as the basic LFB library for ForCES. Descriptions of individual LFBs are presented and detailed XML definitions are included in the library. Several use cases of the defined LFB classes are also proposed. "ForCES Intra-NE High Availability", Kentaro Ogawa, Weiming Wang, Evangelos Haleplidis, Jamal Hadi Salim, 23-Feb-11, This document discusses CE High Availability within a ForCES NE. "Interoperability Report for Forwarding and Control Element Separation (ForCES)", Weiming Wang, Kentaro Ogawa, Evangelos Haleplidis, Ming Gao, Jamal Hadi Salim, 13-Mar-11, This document captures test results from the second Forwarding and control Element Separation (ForCES) interop testing which took place on March 24-25, 2011 at the Internet Technology Lab (ITL) of Zhejiang Gongshang University in China. FTP Extensions, 2nd edition (ftpext2) ------------------------------------- "File Transfer Protocol HASH Command for Cryptographic Hashes", Anthony Bryan, Tim Kosse, Daniel Stenberg, 1-Feb-11, The File Transfer Protocol does not offer any method to verify the integrity of a transferred file, nor can two files be compared against each other without actually transferring them first. Cryptographic hashes are a possible solution to this problem. In the past, several attempts have been made to add commands to obtain checksums and hashes, however none have been formally specified, leading to non-interoperability and confusion. To solve these issues, this document specifies a new FTP command to be used by clients to request cryptographic hashes of files. "File Transfer Protocol HOST Command for Virtual Hosts", Paul Hethmon, Robert McMurray, 7-Mar-11, The File Transfer Protocol, as defined in RFC 959 [RFC0959], does not provide a way for FTP clients and servers to differentiate between multiple DNS names that are registered for a single IP address. This document defines a new FTP command that provides a mechanism for FTP clients and servers to identify individual virtual hosts on an FTP server. General Area Open Meeting (genarea) ----------------------------------- "Requirements for a Working Group Charter Tool", Paul Hoffman, 14-Apr-11, The IETF intends to provide a new tool to Area Directors for the creation, re-chartering, and closing of Working Groups. The tool will also allow the IETF community to view the status of the chartering process. This document describes the requirements for the proposed new tool, and it is intended as input to a later activity for the design and development of such a tool. "Requirements for Internet-Draft Tracking by the IETF Community in the Datatracker", Paul Hoffman, 14-Apr-11, The document gives a set of requirements for extending the IETF Datatracker to give individual IETF community members, including the IETF leadership, easy methods for tracking the progress of the Internet-Drafts and RFCs of interest to them. "Datatracker Extensions to Include IANA and RFC Editor Processing Information", Sandy Ginoza, Michelle Cotton, Alexa Morris, 14-Apr-11, This document captures the requirements for integrating IANA and RFC Editor state information into the Datatracker to provide the community with a unified tool to track the status of their document as it progresses from Internet-Draft (I-D) version -00 to RFC. Extending the Datatracker to hold document data from I-D version -00 to RFC allows for increased automation between the Datatracker, IANA, and RFC Editor, thus reducing manual labor, processing errors, and potential delay. Therefore, this document also describes the requirements to make such automation possible. "Requirements for a Working Group Milestones Tool", Paul Hoffman, 28-May-11, The IETF intends to provide a new tool to Working Group chairs and Area Directors for the creation and updating of milestones for Working Groups. This document describes the requirements for the proposed new tool, and it is intended as input to a later activity for the design and development of such a tool. 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, 14-Mar-11, 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, this document defines two algorithms for reducing the granularity of returned location information. The first algorithm is defined for usage with civic location information while the other one applies to geodetic location information. Both algorithms come with limitations, i.e. they provide location obfuscation under certain conditions and may therefore not be appropriate for all application domains. "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). "Dynamic Host Configuration Protocol (DHCP) IPv4 and IPv6 Option for a Location Uniform Resource Identifier (URI)", James Polk, 11-Feb-11, 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, Marc Linsner, Martin Thomson, Bernard Aboba, 26-Feb-11, 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. This document obsoletes RFC 3825. "An Architecture for Location and Location Privacy in Internet Applications", Richard Barnes, Matt Lepinski, Alissa Cooper, John Morris, Hannes Tschofenig, Henning Schulzrinne, 11-Oct-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. "A Location Dereferencing Protocol Using HELD", James Winterbottom, Hannes Tschofenig, Henning Schulzrinne, Martin Thomson, Martin Dawson, 16-Dec-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 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, 10-Mar-11, 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, 28-Mar-11, 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. "Location Configuration Extensions for Policy Management", Richard Barnes, Martin Thomson, James Winterbottom, Hannes Tschofenig, 12-Jan-11, Current location configuration protocols are capable of provisioning an Internet host with a location URI that refers to the host's location. These protocols lack a mechanism for the target host to inspect or set the privacy rules that are applied to the URIs they distribute. This document extends the current location configuration protocols to provide hosts with a reference to the rules that are applied to a URI, so that the host can view or set these rules. "Location Information Server (LIS) Discovery using IP address and Reverse DNS", Martin Thomson, Ray Bellis, 14-Mar-11, The residential gateway is a device that has become an integral part of home networking equipment. Discovering a Location Information Server (LIS) is a necessary part of acquiring location information for location-based services. However, discovering a LIS when a residential gateway is present poses a configuration challenge, requiring a method that is able to work around the obstacle presented by the gateway. This document describes a solution to this problem. The solution provides alternative domain names as input to the LIS discovery process based on the network addresses assigned to a Device. "Specifying Civic Address Extensions in PIDF-LO", James Winterbottom, Martin Thomson, Richard Barnes, Brian Rosen, Robins George, 10-Mar-11, New fields are occasionally added to civic addresses. A backwardly- compatible mechanism for adding civic address elements to the Geopriv civic address format is described. A formal mechanism for handling unsupported extensions when translating between XML and DHCP civic address forms is defined for entities that need to perform this translation. Intial extensions for some new elements are also defined. Global Routing Operations (grow) -------------------------------- "MRT routing information export format", Larry Blunk, Manish Karir, Craig Labovitz, 20-Apr-11, 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, 15-Dec-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, 22-Feb-11, 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. There are no changes from the 03 version. "Auto-Configuration in Virtual Aggregation", Paul Francis, Xiaohu Xu, Hitesh Ballani, Dan Jen, Robert Raszuk, Lixia Zhang, 22-Feb-11, 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. This draft has no changes from the 02 draft. "Simple Virtual Aggregation (S-VA)", Paul Francis, Xiaohu Xu, Hitesh Ballani, Robert Raszuk, Lixia Zhang, 2-Mar-11, 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. There are no changes from the 01 version to this version. "Distribution of diverse BGP paths.", Robert Raszuk, Rex Fernando, Keyur Patel, Danny McPherson, Kenji Kumaki, 4-Jan-11, 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. "MRT BGP routing information export format with geo-location extensions", Terry Manderson, 23-May-11, This document extends the Border Gateway Protocol (BGP) Multi- threaded Routing Toolkit (MRT) export format for routing information to include terrestrial coordinates of a BGP Collector and its BGP Peers. "Unique Per-Node Origin ASNs for Globally Anycasted Services", Danny McPherson, Ryan Donnelly, Frank Scalzo, 14-Nov-10, This document makes recommendations regarding the use of per-node unique origin ASNs for globally anycasted critical infrastructure services in order to provide routing system discriminators for a given anycasted prefix. Network managment and monitoring techniques, or other operational mechanisms may employ this new discriminator in whatever manner fits their operating environment. "Time to Remove Filters for Previously Unallocated IPv4 /8s", Leo Vegoda, 12-May-11, It has been common for network administrators to filter IP traffic from and BGP prefixes of unallocated IPv4 address space. Now that there are no longer any unallocated IPv4 /8s, this practise is more complicated, fragile and expensive. Network administrators are advised to remove filters based on the registration status of the address space. This document explains why any remaining packet and BGP prefix filters for unallocated IPv4 /8s should now be removed on border routers and documents those IPv4 unicast prefixes that should not be routed across the public Internet. "Operational Requirements for Enhanced Error Handling Behaviour in BGP-4", Rob Shakir, 15-Apr-11, BGP-4 is utilised as a key intra- and inter-Autonomous System routing protocol in modern IP networks. The failure modes as defined by the original protocol standards are based on a number of assumptions around the impact of session failure. Numerous incidents both in the global Internet routing table and within Service Provider networks have been caused by strict handling of a single invalid UPDATE message causing large-scale failures in one or more Autonomous Systems. This memo describes the current use of BGP-4 within Service Provider networks, and outlines a set of requirements for further work to enhance the mechanisms available to a BGP-4 implementation when erroneous data is detected. Whilst this document does not provide specification of any standard, it is intended as an overview of a set of enhancements to BGP-4 to improve the protocol's robustness to suit its current deployment. Host Identity Protocol (hip) ---------------------------- "Host Identity Protocol (HIP) Registration Extension", Julien Laganier, Teemu Koponen, Lars Eggert, 14-Mar-11, 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. "Host Identity Protocol-Based Overlay Networking Environment (HIP BONE) Instance Specification for REsource LOcation And Discovery (RELOAD)", Ari Keranen, Gonzalo Camarillo, Jouni Maenpaa, 11-Jan-11, 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 Architecture", Robert Moskowitz, 25-Feb-11, 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, 14-Mar-11, 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, 14-Mar-11, 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, 14-Mar-11, 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 Version 2 (HIPv2)", Robert Moskowitz, Tobias Heer, Petri Jokela, Tom Henderson, 14-Mar-11, 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. "Host Mobility with the Host Identity Protocol", Pekka Nikander, Tom Henderson, Christian Vogt, Jari Arkko, 14-Mar-11, This document defines mobility 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 out of scope for this document. "Native NAT Traversal Mode for the Host Identity Protocol", Ari Keranen, Jan Melen, 28-Jan-11, This document specifies a new Network Address Translator (NAT) traversal mode for the Host Identity Protocol (HIP). The new mode is based on the Interactive Connectivity Establishment (ICE) methodology and UDP encapsulation of data and signaling traffic. The main difference from the previously specified modes is the use of HIP messages for all NAT traversal procedures. Handover Keying (hokey) ----------------------- "EAP Re-authentication Protocol Extensions for Authenticated Anticipatory Keying (ERP/AAK)", Zehn Cao, Hui Deng, Yungui Wang, Wenson Wu, Glen Zorn, 13-Mar-11, The Extensible Authentication Protocol (EAP) is a generic framework supporting multiple 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 ERP Local Domain Name DHCPv6 Option", Glen Zorn, Wenson Wu, Yungui Wang, 22-Apr-11, 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 using the EAP Re-authentication Protocol (ERP) EAP method of the name of the local domain for ERP. "Handover Keying (HOKEY) Architecture Design", Glen Zorn, Wenson Wu, Tom Taylor, Katrin Hoeper, Sebastien Decugis, 28-Apr-11, The Handover Keying (HOKEY) Working Group seeks to minimize handover delay due to authentication when a peer moves from one point of attachment to another. Work has progressed on two different approaches to reduce handover delay: early authentication (so that authentication does not need to be performed during handover), and reuse of cryptographic material generated during an initial authentication to save time during re-authentication. A starting assumption is that the mobile host or "peer" is initially authenticated using the Extensible Authentication Protocol (EAP), executed between the peer and an EAP server as defined in RFC 3748. This document documents the HOKEY architecture. Specifically, it describes design objectives, the functional environment within which handover keying operates, the functions to be performed by the HOKEY architecture itself, and the assignment of those functions to architectural components. It goes on to illustrate the operation of the architecture within various deployment scenarios that are described more fully in other documents produced by the HOKEY Working Group. "EAP Extensions for EAP Re-authentication Protocol (ERP)", Wenson Wu, Zhen Cao, Yang Shi, Baohong He, 31-May-11, The Extensible Authentication Protocol (EAP) is a generic framework supporting multiple types of authentication methods. In systems where EAP is used for authentication, it is desirable to not repeat the entire EAP exchange with another authenticator. This document 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. The re-authentication server may be in the home network or in the local network to which the peer is connecting. Hypertext Transfer Protocol Bis (httpbis) ----------------------------------------- "HTTP/1.1, part 1: URIs, Connections, and Message Parsing", Roy Fielding, Jim Gettys, Jeffrey Mogul, Henrik Nielsen, Larry Masinter, Paul Leach, Tim Berners-Lee, Julian Reschke, 18-Apr-11, The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 1 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 1 provides an overview of HTTP and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the generic message syntax and parsing requirements for HTTP message frames, and describes general security concerns for implementations. "HTTP/1.1, part 2: Message Semantics", Roy Fielding, Jim Gettys, Jeffrey Mogul, Henrik Nielsen, Larry Masinter, Paul Leach, Tim Berners-Lee, Julian Reschke, 18-Apr-11, The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages as expressed by request methods, request header fields, response status codes, and response header fields. "HTTP/1.1, part 3: Message Payload and Content Negotiation", Roy Fielding, Jim Gettys, Jeffrey Mogul, Henrik Nielsen, Larry Masinter, Paul Leach, Tim Berners-Lee, Julian Reschke, 18-Apr-11, The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 3 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 3 defines HTTP message content, metadata, and content negotiation. "HTTP/1.1, part 4: Conditional Requests", Roy Fielding, Jim Gettys, Jeffrey Mogul, Henrik Nielsen, Larry Masinter, Paul Leach, Tim Berners-Lee, Julian Reschke, 18-Apr-11, The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 4 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 4 defines request header fields for indicating conditional requests and the rules for constructing responses to those requests. "HTTP/1.1, part 5: Range Requests and Partial Responses", Roy Fielding, Jim Gettys, Jeffrey Mogul, Henrik Nielsen, Larry Masinter, Paul Leach, Tim Berners-Lee, Julian Reschke, 18-Apr-11, The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 5 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 5 defines range-specific requests and the rules for constructing and combining responses to those requests. "HTTP/1.1, part 6: Caching", Roy Fielding, Jim Gettys, Jeffrey Mogul, Henrik Nielsen, Larry Masinter, Paul Leach, Tim Berners-Lee, Julian Reschke, 18-Apr-11, The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. This document is Part 6 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 6 defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages. "HTTP/1.1, part 7: Authentication", Roy Fielding, Jim Gettys, Jeffrey Mogul, Henrik Nielsen, Larry Masinter, Paul Leach, Tim Berners-Lee, Julian Reschke, 18-Apr-11, 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. "Initial Hypertext Transfer Protocol (HTTP) Method Registrations", Julian Reschke, 6-Jan-11, 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. "Initial Hypertext Transfer Protocol (HTTP) Authentication Scheme Registrations", Julian Reschke, 2-May-11, This document registers Hypertext Transfer Protocol (HTTP) authentication schemes which have been defined in standards-track RFCs before the IANA HTTP Authentication Scheme Registry was established. BiDirectional or Server-Initiated HTTP (hybi) --------------------------------------------- "HyBi WebSocket Requirements and Features", Gabriel Montenegro, 14-Mar-11, This document states the requirements 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, 8-Jun-11, The WebSocket protocol enables two-way communication between a client 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 opening handshake followed by basic message framing, layered over TCP. (In theory, any transport protocol could be used so long as it provides for reliable transport, is byte clean, and supports relatively large message sizes. However, for this document, we consider only 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