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) ---------------------------------- "Design and Application Spaces for 6LoWPANs", Eunsook Kim, Dominik Kaspar, Nicolas Chevrollier, JP Vasseur, 26-Jul-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-Oct-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. The document, thus updates RFC 4944 to specify the use of the optimizations defined here. "Problem Statement and Requirements for 6LoWPAN Routing", Eunsook Kim, Dominik Kaspar, Carles Gomez, Carsten Bormann, 20-Nov-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", Johanna Nieminen, Basavaraj Patil, Teemu Savolainen, Markus Isomaki, Zach Shelby, Carles Gomez, 10-Jan-12, Bluetooth Low Energy is a low power air interface technology defined by the Bluetooth Special Interest Group (BT 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. The low power variant of Bluetooth is commonly specified in revision 4.0 of the Bluetooth specifications and commonly refered to as Bluetooth 4.0. This document describes how IPv6 is transported over Bluetooth Low Energy using 6LoWPAN techniques. IPv6 Maintenance (6man) ----------------------- "Considerations for IPv6 Address Selection Policy Changes", Tim Chown, Arifumi Matsumoto, 31-Oct-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, 23-Dec-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, 11-Jan-12, 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 describes the issues that can arise when defining new extension headers and discusses the alternate extension mechanisms in IPv6. It also provides a common format for defining any new IPv6 extension headers if they are needed. "RPL Option for Carrying RPL Information in Data-Plane Datagrams", Jonathan Hui, JP Vasseur, 14-Dec-11, The RPL protocol includes routing information in data-plane datagrams to quickly identify inconsistencies in the routing topology. This document describes the RPL Option for use among RPL routers to include such routing information. "An IPv6 Routing Header for Source Routes with RPL", Jonathan Hui, JP Vasseur, David Culler, Vishwas Manral, 15-Dec-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 Instance. "Update to RFC 3484 Default Address Selection for IPv6", Arifumi Matsumoto, Jun-ya Kato, Tomohiro Fujisaki, Tim Chown, 31-Oct-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. "The Line Identification Destination Option", Suresh Krishnan, Alan Kavanagh, Balazs Varga, Sven Ooghe, Erik Nordmark, 31-Oct-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. "UDP Checksums for Tunneled Packets", Marshall Eubanks, Phil Chimento, 31-Oct-11, This document provides an update of RFC 2460[RFC2460] in order to improve the performance of IPv6 in an increasingly important use case, the use of tunneling to carry new transport protocols. The performance improvement is obtained by relaxing the IPv6 UDP checksum requirement for suitable tunneling protocol where header information is protected on the "inner" packet being carried. This relaxation removes the overhead associated with the computation of UDP checksums on tunneled IPv6 packets and thereby improves the efficiency of the traversal of firewalls and other network middleware by such new protocols. We describe how the IPv6 UDP checksum requirement can be relaxed in the situation where the encapsulated packet itself contains a checksum, the limitations and risks of this approach, and provides restrictions on the use of this relaxation to mitigate these risks. "Neighbor Unreachability Detection is too impatient", Erik Nordmark, Igor Gashinsky, 14-Nov-11, IPv6 Neighbor Discovery includes Neighbor Unreachability Detection. That function is very useful when a host has an alternative, for instance multiple default routers, since it allows the host to switch to the alternative in short time. This time is 3 seconds after the node starts probing. However, if there are no alternatives, this is far too impatient. This document proposes an approach where an implementation can choose the timeout behavior to be different based on whether or not there are alternatives. "RFC3627 to Historic status", Wesley George, 19-Dec-11, This document moves RFC3627 (Use of /127 Prefix Length Between Routers Considered Harmful) to HISTORIC status to reflect the updated guidance contained in RFC6164 (Using 127-Bit IPv6 Prefixes on Inter- Router Links). While a standards track document already supersedes an informational document and therefore RFC6164 is the appropriate guidance to follow when the two documents are in conflict, this links the two documents so that it is clearer that the IETF has updated guidance on the matter. "Processing of IPv6 "atomic" fragments", Fernando Gont, 1-Feb-12, The IPv6 specification allows packets to contain a Fragment Header without the packet being actually fragmented into multiple pieces. Such packets typically result from hosts that have received an ICMPv6 "Packet Too Big" error message that advertises a "Next-Hop MTU" smaller than 1280 bytes, and are currently processed by some implementations as "fragmented traffic". Thus, by forging ICMPv6 "Packet Too Big" error messages an attacker can cause hosts to employ "atomic fragments", and then launch any fragmentation-based attacks against such traffic. This document discusses the generation of the aforementioned "atomic fragments", the corresponding security implications, and formally updates RFC 2460 and RFC 5722 such that fragmentation-based attack vectors against traffic employing "atomic fragments" are completely eliminated. IPv6 Site Renumbering (6renum) ------------------------------ "IPv6 Enterprise Network Renumbering Scenarios and Guidelines", Sheng Jiang, Bing Liu, Brian Carpenter, 6-Feb-12, This document analyzes enterprise renumbering events and describes the best current practice among the existing renumbering mechanisms. According to the different stages of renumbering events, considerations and best current practices are described in three categories: during network design, for preparation of renumbering, and during a renumbering operation. A gap inventory is listed at the end of this document. "IPv6 Site Renumbering Gap Analysis", Bing Liu, Sheng Jiang, Brian Carpenter, 6-Feb-12, This document briefly introduces the existing mechanisms could be utilized by IPv6 site renumbering and envisions the effort could be done. This document tries to cover the most explicit issues and requirements of IPv6 renumbering. Through the gap analysis, the document provides a basis for future work to identify and develop solutions or to stimulate such development as appropriate. The gap analysis is presented following a renumbering event procedure clue. Application Bridging for Federated Access Beyond web (abfab) ------------------------------------------------------------ "A GSS-API Mechanism for the Extensible Authentication Protocol", Sam Hartman, Josh Howlett, 30-Oct-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. "Name Attributes for the GSS-API EAP mechanism", Sam Hartman, Josh Howlett, 21-Oct-11, The naming extensions to the Generic Security Services Application Programming interface provide a mechanism for applications to discover authorization and personalization information associated with GSS-API names. The Extensible Authentication Protocol GSS-API mechanism allows an Authentication/Authorization/Accounting peer to provide authorization attributes along side an authentication response. It also provides mechanisms to process Security Assertion Markup Language (SAML) messages provided in the AAA response. This document describes the necessary information to use the naming extensions API to access that information. "A RADIUS Attribute, Binding and Profiles for SAML", Josh Howlett, Sam Hartman, 31-Oct-11, This document specifies a RADIUS attribute, binding and two profiles for the Security Assertion Mark-up Language (SAML). The attribute provides RADIUS encapsulation of SAML protocol messages, while the binding describes the transport of this attribute, and the SAML protocol messages within, using RADIUS. The profiles describe the application of this binding for Abfab authentication and assertion query/request. The SAML RADIUS attribute and binding are defined generically to permit application in other scenarios, such as network access. ADSL MIB (adslmib) ------------------ "xDSL multi-pair bonding (G.Bond) MIB", Edward Beili, Moti Morgenstern, 1-Feb-12, 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, 9-Feb-12, 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, 2-Feb-12, 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, 16-Jan-12, 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 capable of providing 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, 31-Oct-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 network information (e.g., basic network location structure, preferences of network paths) with the goal of modifying network resource consumption patterns while maintaining or improving application performance. The basic information of ALTO is based on abstract maps of a network. These maps provide simplified, yet enough information of a network for applications to effectively utilize. Additional services are built on top the maps. This document describes a protocol implementing the ALTO Service. Although the ALTO 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-Nov-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, 14-Sep-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 deployment scenarios. Access Node Control Protocol (ancp) ----------------------------------- "Access Node Control Protocol (ANCP) MIB module for Access Nodes", Stefaan De Cnodder, Moti Morgenstern, 4-Jan-12, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines objects for managing access nodes that are using the Access Node Control Protocol (ANCP). "Multicast Control Extensions for ANCP", Francois Faucheur, Roberta Maglione, Tom Taylor, 5-Dec-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. "Applicability of Access Node Control Mechanism to PON based Broadband Networks", Nabil Bitar, Sanjay Wadhwa, Li Hongyu, Thomas Haag, 17-Jan-12, The purpose of this document is to provide applicability of the Access Node Control Mechanism, as described in [RFC5851], to PON based broadband access. The need for an Access Node Control Mechanism between a Network Access Server (NAS) and an Access Node Complex (a combination of Optical Line Termination (OLT) and Optical Network Termination (ONT) elements) is described in a multi-service reference architecture in order to perform QoS- related, service-related and Subscriber-related operations. The Access Node Control Mechanism is also extended for interaction between components of the Access Node Complex (OLT and ONT). The Access Node Control mechanism will ensure that the transmission of information between the NAS and Access Node Complex (ANX) and between the OLT and ONT within an ANX does not need to go through distinct element managers but rather uses a direct device-to- device communication and stays on net. This allows for performing access link related operations within those network elements to meet performance objectives. Applications Area Working Group (appsawg) ----------------------------------------- "Deprecating Use of the "X-" Prefix in Application Protocols", Peter Saint-Andre, D. Crocker, Mark Nottingham, 24-Oct-11, Historically, designers and implementers of application protocols have often distinguished between "standard" and "non-standard" parameters by prefixing the latter with the string "X-" or similar constructions. In practice, this convention causes more problems than it solves. Therefore, this document deprecates the "X-" convention for most application protocol parameters. "The "about" URI Scheme", Lachlan Hunt, Mykyta Yevstifeyev, 9-Dec-11, This document specifies the "about" URI scheme, that is widely used by Web browsers and some other applications to designate access to their internal resources, such as settings, application information, hidden built-in functionality, and so on. "Email Greylisting: An Applicability Statement for SMTP", Murray Kucherawy, 30-Jan-12, This memo describes the art of email greylisting, the practice of providing temporarily degraded service to unknown email clients as an anti-abuse mechanism. "JSON Patch", Paul Bryan, 3-Jan-12, JSON Patch defines the media type "application/json-patch", a JSON document structure for expressing a sequence of operations to apply to a JSON document. "JSON Pointer", Paul Bryan, Kris Zyp, 3-Jan-12, JSON Pointer defines a string syntax for identifying a specific value within a JSON document. "Forwarded HTTP Extension", Andreas Petersson, Martin Nilsson, 27-Jan-12, This document standardizes an HTTP extension header field that allows proxy components to disclose information lost in the proxying process, e.g. the originating IP number of a request or IP number of the proxy on the incoming side. Given a trusted path of proxying components, each subsequent component will have access to all IP numbers used in the chain of proxied HTTP requests. This document also standardizes ways for a proxy administrator to anonymize the origin of a request. "Update to MIME regarding Charset Parameter Handling in Textual Media Types", Alexey Melnikov, Julian Reschke, 1-Feb-12, This document changes RFC 2046 rules regarding default charset parameter values for text/* media types to better align with common usage by existing clients and servers. "Media Type Specifications and Registration Procedures", Ned Freed, John Klensin, Tony Hansen, 4-Feb-12, This document defines procedures for the specification and registration of media types for use in HTTP, MIME and other Internet protocols. Address Resolution for Massive numbers of hosts in the Data center (armd) ------------------------------------------------------------------------- "Problem Statement for ARMD", Thomas Narten, 17-Oct-11, This document examines issues related to the massive scaling of data centers. Our initial scope is relatively narrow. Specifically, we focus on address resolution (ARP and ND) within the data center. Authority-to-Citizen Alert (atoca) ---------------------------------- "Requirements, Terminology and Framework for Exigent Communications", Henning Schulzrinne, Steve Norreys, Brian Rosen, Hannes Tschofenig, 25-Oct-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 Core Maintenance (avtcore) ------------------------------------------------ "Why RTP Does Not Mandate a Single Security Mechanism", Colin Perkins, Magnus Westerlund, 31-Oct-11, 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. It also discusses how applications using RTP can meet the goals of BCP 61 to have strong and mandatory to implement security. "AES-GCM and AES-CCM Authenticated Encryption in Secure RTP (SRTP)", David McGrew, Kevin Igoe, 31-Oct-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, Dan Wing, Kai Fischer, 31-Oct-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, 30-Dec-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-Oct-11, This memo specifies how Explicit Congestion Notification (ECN) can be used with the 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 initialization method using Interactive Connectivity Establishment (ICE). Signalling and procedures for negotiation of capabilities and initialization methods are also defined. "RTCP Extension for Third-party Loss Report", Wenson Wu, Frank Xia, Roni Even, 9-Feb-12, 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 cases where it is not recommended to forward feedback reports, and this may allow feedback implosion. This memo discusses these cases and defines a new RTCP third-party loss report that can be used to inform receivers that the 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, 12-Jan-12, 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, following RTCP guideline established 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, 28-Oct-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. "RTCP for inter-destination media synchronization", Ray van Brandenburg, Hans Stokking, Oskar van Deventer, Fernando Boronat, Mario Montagud, Kevin Gross, 31-Oct-11, This document gives information on an RTCP Packet Type and RTCP XR Block Type including associated SDP parameters for inter-destination media synchronization (IDMS). The RTCP XR Block Type, registered with IANA based on an ETSI specification, is used to collect media play- out information from participants in a group playing-out (watching, listening, etc.) a specific RTP media stream. The RTCP packet type specified by this document is used to distribute a summary of the collected information so that the participants can synchronize play- out. Typical applications for IDMS are social TV, shared service control (i.e. applications where two or more geographically separated users are watching a media stream together), distance learning, networked video walls, networked speakers, etc. Audio/Video Transport Extensions (avtext) ----------------------------------------- "Support for multiple clock rates in an RTP session", Marc Petit-Huguenin, 3-Jan-12, 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 for Deploying the Rapid Acquisition of Multicast RTP Sessions (RAMS) Method", Ali Begen, 17-Jan-12, 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. "Content Splicing for RTP Sessions", Jinwei Xia, 6-Feb-12, This memo outlines RTP splicing. Splicing is a process that replaces the content of the main multimedia stream with other multimedia content, and delivers the substitutive multimedia content to receiver for a period of time. This memo provides some RTP splicing use cases, then we enumerate a set of requirements and analyze whether an existing RTP level middlebox can meet these requirements, at last we provide concrete guidelines for how the chosen middlebox works to handle RTP splicing. Behavior Engineering for Hindrance Avoidance (behave) ----------------------------------------------------- "Dual Stack Hosts Using "Bump-in-the-Host" (BIH)", Bill Huang, Hui Deng, Teemu Savolainen, 16-Jan-12, 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. This document obsoletes RFC 2767 and RFC 3338. "Common requirements for Carrier Grade NATs (CGNs)", Simon Perreault, Ikuhei Yamagata, Shin Miyakawa, Akira Nakagawa, Hiroyuki Ashida, 30-Nov-11, This document defines common requirements for Carrier-Grade NAT (CGN). "Analysis of Stateful 64 Translation", Reinaldo Penno, Tarun Saxena, Mohamed Boucadair, Senthil Sivakumar, 22-Dec-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, Dan Wing, 25-Jan-12, 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 well-known IPv4-only domain name "ipv4only.arpa". 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, 9-Dec-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. Binary Floor Control Protocol Bis (bfcpbis) -------------------------------------------- "Revision of the Binary Floor Control Protocol (BFCP) for use over an unreliable transport", Tom Kristensen, Charles Eckel, Alfred Heggestad, Mark Thompson, Geir Sandbakken, Eoin McLeod, 24-Jan-12, This draft describes how to extend the Binary Floor Control Protocol (BFCP) for use over an unreliable transport. It details the differences from the BFCP protocol definition document and the Session Description Protocol (SDP) format specified for BFCP streams. Bidirectional Forwarding Detection (bfd) ---------------------------------------- "BFD Generic Cryptographic Authentication", Manav Bhatia, Vishwas Manral, Dacheng Zhang, 8-Oct-11, This document proposes an extension to Bidirectional Forwarding Detection (BFD) to allow the use of any cryptographic authentication algorithm in addition to the already-documented authentication schemes described in the base specification. This document adds the basic infrastructure thats required for supporting algorithm and key agility for BFD. "BFD for Multipoint Networks", Dave Katz, Dave Ward, 18-Oct-11, This document describes extensions to the Bidirectional Forwarding Detection (BFD) protocol for its use in multipoint and multicast networks. Comments on this draft should be directed to rtg-bfd@ietf.org. "Authenticating BFD using HMAC-SHA-2 procedures", Dacheng Zhang, Manav Bhatia, Vishwas Manral, 11-Jan-12, This document describes how Hashed Message Authentication Mode (HMAC) in conjunction with the SHA-256, SHA-384, and SHA-512 algorithms can be used for authenticating Bidirectional Forwarding Detection (BFD). It uses the Generic Cryptographic Authentication and Generic Meticulous Cryptographic Authentication sections to carry the authentication data. This updates, but does not supercede, the cryptographic authentication mechanism specified in RFC 5880. Basic Level of Interoperability for SIP Services (bliss) -------------------------------------------------------- "Call Completion for Session Initiation Protocol (SIP)", Dale Worley, Martin Huelsemann, Roland Jesske, Denis Alexeitsev, 29-Nov-11, The call completion feature defined in this specification allows the caller of a failed call to be notified when the callee becomes available to receive a call. For the realization of a basic solution without queuing, this document references the usage of 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 , this document introduces an architecture for implementing these features in the Session Initiation Protocol where "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 of the original, failed call is made. The architecture is designed to interoperate well 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, 29-Dec-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) ------------------------------- "Methodology for benchmarking MPLS protection mechanisms", Rajiv Papneja, Samir Vapiwala, Jay Karthik, Scott Poretsky, Shankar Rao, Jean-Louis Le Roux, 28-Oct-11, This draft describes the methodology for benchmarking MPLS Protection mechanisms for link and node protection as defined in [MPLS-FRR-EXT]. This document provides test methodologies and testbed setup for measuring failover times while considering all dependencies that might impact faster recovery of real-time applications bound to MPLS based traffic engineered tunnels. The benchmarking terms used in this document are defined in [TERM-ID]. "IP Flow Information Accounting and Export Benchmarking Methodology", Jan Novak, 30-Jan-12, This document provides a methodology and framework for quantifying the 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]. "RFC 2544 Applicability Statement: Use on Production Networks Considered Harmful", Scott Bradner, Kevin Dubray, Jim McQuaid, Al Morton, 20-Oct-11, Benchmarking Methodology Working Group (BMWG) has been developing key performance metrics and laboratory test methods since 1990, and continues this work at present. Recent application of the methods beyond their intended scope is cause for concern. This memo clarifies the scope of RFC 2544 and other benchmarking work for the IETF community. "Benchmarking Methodology for Content-Aware Network Devices", Mike Hamilton, Sarah Banks, 14-Sep-11, This document defines a set of test scenarios and metrics that can be used to benchmark content-aware network devices. More specifically, these scenarios are designed to most accurately predict performance of these devices when subjected to relevant traffic patterns. This document will operate within the constraints of the Benchmarking Working Group charter, namely black box characterization in a laboratory environment. "IMIX Genome: Specification of variable packet sizes for additional testing", Al Morton, 8-Jan-12, Benchmarking Methodologies have always relied on test conditions with constant packet sizes, with the goal of understanding what network device capability has been tested. Tests with constant packet size reveal device capabilities but differ significantly from the conditions encountered in operational deployment, and so additional tests are sometimes conducted with a mixture of packet sizes, or "IMIX". The mixture of sizes a networking device will encounter is highly variable and depends on many factors. An IMIX suited for one networking device and deployment will not be appropriate for another. However, the mix of sizes may be known and the tester may be asked to augment the fixed size tests. To address this need, and the perpetual goal of specifying repeatable test conditions, this draft defines a way to specify the exact repeating sequence of packet sizes from the usual set of fixed sizes, and other forms of mixed size specification. Common Control and Measurement Plane (ccamp) -------------------------------------------- "Traffic Engineering Database Management Information Base in support of MPLS-TE/GMPLS", Masanori Miyazawa, Tomohiro Otani, Kenji Kumaki, Thomas Nadeau, 11-Jan-12, 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", Young Lee, Greg Bernstein, Dan Li, Wataru Imajuku, 31-Oct-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 lightpath computation in WSONs. This model takes into account compatibility constraints between WSON signal attributes and network elements but does not include constraints due to optical impairments. Aspects of this information that may be of use to other technologies utilizing a GMPLS control plane are discussed. "Routing and Wavelength Assignment Information Encoding for Wavelength Switched Optical Networks", Greg Bernstein, Young Lee, Dan Li, Wataru Imajuku, 31-Oct-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, Jia He, 11-Jan-12, 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, Hao Long, 11-Jan-12, 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, 5-Jan-12, 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. Specifically, this document discusses key computing constraints, scenarios and architectural processes: Routing, Wavelength Assignment, and Impairment Validation. 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. "GMPLS OSPF Enhancement for Signal and Network Element Compatibility for Wavelength Switched Optical Networks", Young Lee, Greg Bernstein, 30-Oct-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, 13-Dec-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 Operations, Administration, and Maintenance (OAM) Functions for MPLS-based Transport Networks using RSVP-TE", Elisa Bellagamba, Loa Andersson, Pontus Skoldstrom, Dave Ward, Attila Takacs, 31-Oct-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 are carried by the RSVP-TE protocol. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network. "GMPLS RSVP-TE Extensions for SONET/SDH and OTN OAM Configuration", Andras Kern, Attila Takacs, 26-Oct-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, 8-Sep-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 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, 31-Jan-12, 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, Sugang Xu, Young Lee, Giovanni Martinelli, Hiroaki Harai, 13-Sep-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, 16-Jan-12, 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. "Usage of The RSVP Association Object", Lou Berger, 25-Oct-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, 19-Aug-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 attribute are to be carried in RSVP Path and Resv messages using the Routing Backus-Naur Form, and clarifies related Resv message formats. This document updates RFC 4875 and RFC 5420. "OSPF-TE Extensions for General Network Element Constraints", Fatai Zhang, Young Lee, Jianrui Han, Greg Bernstein, Yunbin Xu, 22-Sep-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 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 for Associated Bidirectional LSPs", Fei Zhang, Ruiquan Jing, 13-Oct-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-Jan-12, 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, Papadimitriou Dimitri, 8-Aug-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, 28-Oct-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. "Traffic Engineering Extensions to OSPF for Generalized MPLS (GMPLS) Control of Evolving G.709 OTN Networks", Daniele Ceccarelli, Diego Caviglia, Fatai Zhang, Dan Li, Sergio Belotti, Pietro Grandi, Rajan Rao, Khuzema Pithewan, John Drake, 18-Jan-12, The recent revision of ITU-T Recommendation G.709 [G709-V3] has introduced new fixed and flexible ODU containers, enabling optimized support for an increasingly abundant service mix. This document describes OSPF routing protocol extensions to support Generalized MPLS (GMPLS) control of all currently defined ODU containers, in support of both sub-lambda and lambda level routing granularity. "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for the evolving G.709 Optical Transport Networks Control", Fatai Zhang, Guoying Zhang, Sergio Belotti, Daniele Ceccarelli, Khuzema Pithewan, 25-Oct-11, Recent progress in ITU-T Recommendation G.709 standardization has introduced new ODU containers (ODU0, ODU4, ODU2e and ODUflex) and enhanced Optical Transport Networking (OTN) flexibility. Several recent documents have proposed ways to modify GMPLS signaling protocols to support these new OTN features. It is important that a single solution is developed for use in GMPLS signaling and routing protocols. This solution must support ODUk multiplexing capabilities, address all of the new features, be acceptable to all equipment vendors, and be extensible considering continued OTN evolution. This document describes the extensions to the Generalized Multi- Protocol Label Switching (GMPLS) signaling to control the evolving Optical Transport Networks (OTN) addressing ODUk multiplexing and new features including ODU0, ODU4, ODU2e and ODUflex. Content Delivery Networks Interconnection (cdni) ------------------------------------------------ "Content Distribution Network Interconnection (CDNI) Problem Statement", Ben Niven-Jenkins, Francois Faucheur, Nabil Bitar, 21-Jan-12, Content Delivery Networks (CDNs) provide numerous benefits: reduced delivery cost for cacheable content, improved quality of experience for End Users and increased robustness of delivery. For these reasons they are frequently used for large-scale content delivery. As a result, existing CDN Providers are scaling up their infrastructure and many Network Service Providers (NSPs) are deploying their own CDNs. It is generally desirable that a given content item can be delivered to an End User regardless of that End User's location or attachment network. This creates a requirement for interconnecting standalone CDNs so they can interoperate as an open content delivery infrastructure for the end-to-end delivery of content from Content Service Providers (CSPs) to End Users. However, no standards or open specifications currently exist to facilitate such CDN interconnection. The goal of this document is to outline the problem area of CDN interconnection for the IETF CDNI (CDN Interconnection) working group. "Content Distribution Network Interconnection (CDNI) Requirements", Kent Leung, Yiu Lee, 7-Dec-11, Content Delivery Networks (CDNs) are frequently used for large-scale content delivery. As a result, existing CDN providers are scaling up their infrastructure and many Network Service Providers (NSPs) are deploying their own CDNs. There is a requirement for interconnecting standalone CDNs so that their collective CDN footprint can be leveraged for the end-to-end delivery of content from Content Service Providers (CSPs) to end users. The Content Distribution Network Interconnection (CDNI) working group has been chartered to develop an interoperable and scalable solution for such CDN interconnection. The goal of the present document is to outline the requirements for the solution and interfaces to be specified by the CDNI working group. This draft is a work in progress and requirements may be added, modified, or removed by the working group. Requirements Language The key words "High Priority", "Medium Priority" and "Low Priority" in this document are to be interpreted in the following way: o "High Priority" indicates requirements that are to be supported by the CDNI interfaces. A requirement is stated as "High Priority" when it is established by the working group that it can be met without compromising the targeted schedule for WG deliverables, or when it is established that specifying a solution without meeting this requirement would not make sense and would justify re- adjusting the WG schedule, or both. This is tagged as "[HIGH]". o "Medium Priority" indicates requirements that are to be supported by the CDNI interfaces unless the WG realizes at a later stage that attempting to meet this requirement would compromise the overall WG schedule (for example it would involve complexities that would result in significantly delaying the deliverables). This is tagged as "[MED]". o "Low Priority" indicates requirements that are to be supported by the CDNI interfaces provided that dedicating WG resources to this work does not prevent addressing "High Priority" and "Medium Priority" requirements and that attempting to meet this requirement would not compromise the overall WG schedule. This is tagged as "[LOW]". "Use Cases for Content Delivery Network Interconnection", Bertrand Gilles, Stephan Emile, Grant Watson, Trevor Burbridge, Philip Eardley, Kevin Ma, 30-Jan-12, Content Delivery Networks (CDNs) are commonly used for improving the End User experience of a content delivery service, at a reasonable cost. This document outlines real world use cases (not technical solutions) for interconnecting CDNs. It focuses on use cases that correspond to identified industry needs and that are expected to be realized once a CDN Interconnection (CDNI) solution is available. This document can be used to provide guidance to the CDNI WG about the interconnection arrangements to be supported and to validate the requirements of the various CDNI interfaces. ControLling mUltiple streams for tElepresence (clue) ---------------------------------------------------- "Use Cases for Telepresence Multi-streams", Allyn Romanow, Stephen Botzko, Mark Duckworth, Roni Even, Iformata Communications, 9-Jan-12, Telepresence conferencing systems seek to create the sense of really being present for the participants. A number of techniques for handling audio and video streams are used to create this experience. When these techniques are not similar, interoperability between different systems is difficult at best, and often not possible. Conveying information about the relationships between multiple streams of media would allow senders and receivers to make choices to allow telepresence systems to interwork. This memo describes the most typical and important use cases for sending multiple streams in a telepresence conference. "Requirements for Telepresence Multi-Streams", Allyn Romanow, Stephen Botzko, 31-Oct-11, This memo discusses the requirements for a specification that enables telepresence interoperability, by describing the relationship between multiple RTP streams. In addition, the problem statement and definitions are also covered herein. "Framework for Telepresence Multi-Streams", Allyn Romanow, Mark Duckworth, Andrew Pepperell, Brian Baldino, 4-Feb-12, This memo offers a framework for a protocol that enables devices in a telepresence conference to interoperate by specifying the relationships between multiple media streams. Internet Wideband Audio Codec (codec) ------------------------------------- "Definition of the Opus Audio Codec", Jean-Marc Valin, Koen Vos, Timothy Terriberry, 31-Oct-11, This document defines the Opus interactive speech and audio codec. Opus is designed to handle a wide range of interactive audio applications, including Voice over IP, videoconferencing, in-game chat, and even live, distributed music performances. It scales from low bit-rate narrowband speech at 6 kb/s to very high quality stereo music at 510 kb/s. Opus uses both linear prediction (LP) and the Modified Discrete Cosine Transform (MDCT) to achieve good compression of both speech and music. "Guidelines for Development of an Audio Codec Within the IETF", Jean-Marc Valin, Slava Borilin, Koen Vos, Christopher Montgomery, Juin-Hwey Chen, 10-Jan-12, This document provides general guidelines for work on developing and specifying an interactive audio codec within the IETF. These guidelines cover the development process, evaluation, requirements conformance, and intellectual property issues. "Summary of Opus listening test results", Jean-Marc Valin, Christian Hoene, Koen Vos, Jan Skoglund, 24-Oct-11, This document describes and examines listening test results obtained for the Opus codec and how they relate to the requirements. Congestion Exposure (conex) --------------------------- "ConEx Concepts and Use Cases", Bob Briscoe, Richard Woundy, Alissa Cooper, 25-Oct-11, This document provides the entry point to the set of documentation about the Congestion Exposure (ConEx) protocol. It explains the motivation for including a ConEx field at the IP layer: to expose information about congestion to network nodes. Although such information may have a number of uses, this document focuses on how the information communicated in the ConEx field can serve as the basis for significantly more efficient and effective traffic management than what exists on the Internet today. "Congestion Exposure (ConEx) Concepts and Abstract Mechanism", Matt Mathis, Bob Briscoe, 31-Oct-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, where it could, for example, be used to provide input to traffic management. "IPv6 Destination Option for Conex", Suresh Krishnan, Mirja Kuehlewind, Carlos Ucendo, 30-Oct-11, Conex is a mechanism by which senders inform the network about the congestion encountered by packets earlier in the same flow. This document specifies an IPv6 destination option that is capable of carrying conex markings in IPv6 datagrams. "TCP modifications for Congestion Exposure", Mirja Kuehlewind, Richard Scheffenegger, 21-Dec-11, Congestion Exposure (ConEx) is a mechanism by which senders inform the network about the congestion encountered by previous packets on the same flow. This document describes the necessary modifications to use ConEx with the Transmission Control Protocol (TCP). Constrained RESTful Environments (core) --------------------------------------- "Constrained Application Protocol (CoAP)", Zach Shelby, Klaus Hartke, Carsten Bormann, Brian Frank, 31-Oct-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, 27-Jan-12, CoAP is a RESTful transfer protocol for constrained nodes and networks. Basic CoAP messages work well for the small payloads we expect from temperature sensors, light switches, and similar building-automation devices. Occasionally, however, applications will need to transfer larger payloads -- for instance, for firmware updates. With HTTP, TCP does the grunt work of slicing large payloads up into multiple packets and ensuring that they all arrive and are handled in the right order. CoAP is based on datagram transports such as UDP or DTLS, which limits the maximum size of resource representations that can be transferred without too much fragmentation. Although UDP supports larger payloads through IP fragmentation, it is limited to 64 KiB and, more importantly, doesn't really work well for constrained applications and networks. Instead of relying on IP fragmentation, this specification extends basic CoAP with a pair of "Block" options, for transferring multiple blocks of information from a resource representation in multiple request-response pairs. In many important cases, the Block options enable a server to be truly stateless: the server can handle each block transfer separately, with no need for a connection setup or other server-side memory of previous block transfers. In summary, the Block options provide a minimal way to transfer larger representations in a block-wise fashion. "CoRE Link Format", Zach Shelby, 30-Jan-12, 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, 31-Oct-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 document specifies a simple protocol extension for CoAP that gives clients the ability to observe such changes. "Group Communication for CoAP", Akbar Rahman, Esko Dijk, 10-Jan-12, This is a working document intended to develop draft text for the CoAP protocol specification in the area of group communication. A solution based on IP multicast is proposed and detailed. Also, guidance is provided for deployment in various constrained network topologies. Cga & Send maIntenance (csi) ---------------------------- "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. 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, 3-Jan-12, 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. In addition to interworking with the ISDN UUI Service, this extension will also be used for native SIP endpoints requiring application UUI. "A Mechanism for Transporting User to User Call Control Information in SIP", Alan Johnston, James Rafferty, 31-Oct-11, There is a class of applications which benefit from using SIP to exchange User to User Information (UUI) data during session establishment. This information, known as call control UUI data, is a small piece of data inserted by an application initiating the session, and utilized by an application accepting the session. The rules which apply for a certain application are defined by a UUI package. This UUI 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 data, along with an extension mechanism. "Interworking ISDN Call Control User Information with SIP", Keith Drage, Alan Johnston, 31-Oct-11, The motivation and use cases for interworking and transporting ITU-T DSS1 User-user information element data in SIP are described in the "Problem Statement and Requirements for Transporting User to User Call Control Information in SIP" document. 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 defines a usage of the User-to-User header field to enable interworking with this ISDN service. This document covers the interworking with both public ISDN and private ISDN capabilities, so the potential interworking with QSIG will also be addressed. DNS-based Authentication of Named Entities (dane) ------------------------------------------------- "Using Secure DNS to Associate Certificates with Domain Names For TLS", Paul Hoffman, Jakob Schlyter, 8-Feb-12, 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. Decoupled Application Data Enroute (decade) ------------------------------------------- "DECoupled Application Data Enroute (DECADE) Problem Statement", Haibin Song, Ning Zong, Yang Yang, Richard Alimi, 7-Feb-12, 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. Traditional caches (e.g., P2P and Web caches) provide such storage, but they are complex (due to explicitly supporting individual P2P application protocols and cache refresh mechanisms) and they do not allow users to manage access to content in the cache. For example, content providers wishing to use in- network storage cannot easily control cache access and resource usage policies to satisfy their own requirements. This document discusses the introduction of in-network storage for P2P applications, and shows the need for a standard protocol for accessing this storage. "DECADE Requirements", Gu Yingjie, David Bryan, Yang Yang, Richard Alimi, 31-Oct-11, The target of DECoupled Application Data Enroute (DECADE) is to provide an open and standard in-network storage system for applications, primarily P2P (peer-to-peer) applications, to store, retrieve and manage their data. This draft enumerates and explains requirements, not only for storage and retrieval, 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., a protocol used to read and write data from the storage system). The requirements in this document are intended to ensure that the DECADE architecture includes all of the desired functionality for intended applications. "DECADE Architecture", Richard Alimi, Yang Yang, Akbar Rahman, Dirk Kutscher, Hongqiang Liu, 31-Oct-11, Content Distribution Applications (e.g., P2P applications) are widely used on the Internet and make up a large portion of the traffic in many networks. One technique to improve the network efficiency of these applications is to introduce storage capabilities within the networks; this is the capability to be provided by DECADE (DECoupled Application Data Enroute). This document presents an architecture for DECADE, discusses the underlying principles, and identifies core components and protocols for introducing in-network storage for these applications. "Integration Examples of DECADE System", Lijiang Chen, Hongqiang Liu, Zhigang Huang, Xiaohui Chen, 31-Oct-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)ALTO+DECADE based file distribution platform; 5) tests on our DECADE integrarions and 6) 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, 26-Jan-12, 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]. This memo updates RFC 3046 [RFC3046] regarding details relating to copying of sub-options (see Section 8). "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. "Client Identifier Option in DHCP Server Replies", Narasimha Swamy, Gaurav Halwasia, SEZ Unit, 16-Aug-11, This document updates RFC2131 [RFC2131]. The changes to [RFC2131] defined in this draft clarifies the use of 'client identifier' option by the DHCP servers. The clarification addresses the issues arising out of the point specified by [RFC2131] that the server 'MUST NOT' return client identifier' option to the client. Requirements "Rebind Capability in DHCPv6 Reconfigure Messages", D. Evans, Ralph Droms, Sheng Jiang, 15-Dec-11, This document updates RFC 3315 to allow the Rebind message type to appear in the Reconfigure Message option of a Reconfigure message, which extends the Reconfigure message to allow a DHCPv6 server to cause a DHCPv6 client to send a Rebind message. The document also clarifies how a DHCPv6 client responds to a received Reconfigure message. "Guidelines for Creating New DHCP Options", David Hankins, 1-Oct-11, This document seeks to provide guidance to prospective DHCP Option authors, to help them in producing option formats that are easily adoptable. "Layer 2 Relay Agent Information", Bharat Joshi, Pavan Kurapati, 25-Jan-12, 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, D.T.V. Ramakrishna Rao, Mark Stapp, 10-Jan-12, 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 normally 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, Mark Stapp, Bharat Joshi, Neil Russell, Pavan Kurapati, 18-Nov-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. "Dynamic Host Configuration Protocol DHCPINFORM Message Clarifications", David Hankins, 1-Oct-11, The DHCPINFORM message within the DHCPv4 protocol has in operation diverged incompatibly from the current defined standard. This document seeks to provide clarification of actual behaviour and guidance for some situations that were previously omitted. "Forcerenew Nonce Authentication", David Miles, Wojciech Dec, James Bristow, Roberta Maglione, 21-Dec-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 sends 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, Sean Shen, 30-Dec-11, 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. "Prefix Exclude Option for DHCPv6-based Prefix Delegation", Jouni Korhonen, Teemu Savolainen, Suresh Krishnan, Ole Troan, 19-Dec-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. The new mechanism updates RFC 3633. "DHCPv6 Redundancy Deployment Considerations", John Jason Brzozowski, Jean-Francois Tremblay, Jack Chen, Tomasz Mrugalski, 31-Oct-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, 11-Oct-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, 20-Nov-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. "DHCPv6 Failover Requirements", Tomasz Mrugalski, Kim Kinnear, 18-Oct-11, The DHCPv6 protocol, defined in [RFC3315] allows for multiple servers to operate on a single network, however it does not define any way to decide which server responds to which client queries. Some sites are interested in running multiple servers in such a way as to provide increased availability in case of server failure. In order for this to work reliably, the cooperating primary and secondary servers must maintain a consistent database of the lease information. [RFC3315] allows for but does not define any redundancy or failover mechanisms. This document outlines requirements for DHCPv6 failover, enumerates related problems, and discusses the proposed scope of work to be conducted. This document does not define a DHCPv6 failover protocol. "DHCPv4 over IPv6 Transport", Yong Cui, Peng Wu, Jianping Wu, Ted Lemon, 30-Nov-11, Recently, there are demands arising for IPv4 address allocation under IPv6 environment, especially in IPv6 transition scenarios. This document describes the mechanism to survive DHCPv4 over IPv6 network. DHCPv4 messages are transported in IPv6 packets when traversing the IPv6 network. DHCPv4 protocol behavior of the client and server is extended to support this IPv6 transport. For the relay case, a new suboption of the Relay Agent Information Option is defined to carry the remote IPv6 address of the clients. "DHCPv6 through Tunnels", Ole Troan, Marc Blanchet, Xiaohu Xu, Dayong Guo, 12-Oct-11, The host configuration protocol DHCPv6 [RFC3315] relies on link-local addressing and multicast to function. However, most of the existing 6over4 tunnel link types (e.g., 6rd [RFC5969] ) don't support IPv6 link-local addresses and even IPv6 multicast addresses. Taking 6rd as an example, this document specifies how DHCPv6 can be used across such tunnel links . Diameter Maintenance and Extensions (dime) ------------------------------------------ "Diameter Base Protocol", Victor Fajardo, Jari Arkko, John Loughney, Glenn Zorn, 30-Aug-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 obsoletes RFC 3588 and must be supported by all new Diameter implementations. "Diameter Applications Design Guidelines", Victor Fajardo, Hannes Tschofenig, Lionel Morand, 11-Jan-12, The Diameter Base protocol provides facilities for protocol extensibility enabling to define new Diameter applications or modify existing applications. This document is a companion document to the Diameter Base protocol that further explains and clarifies the rules to extend the Diameter Base protocol. It is meant as a guidelines document and therefore it does not add, remove or change existing rules. "Diameter Support for the EAP Re-authentication Protocol (ERP)", Julien Bournelle, Lionel Morand, Sebastien Decugis, Wenson Wu, Glen Zorn, 9-Feb-12, The EAP Re-authentication Protocol (ERP) defines extensions to the Extensible Authentication Protocol (EAP) to support efficient re- authentication between the peer and an EAP Re-authentication (ER) server through a compatible authenticator. This document specifies Diameter support for ERP. It defines a new Diameter ERP application to transport ERP messages between an ER authenticator and the ER server, and a set of new AVPs that can be used to transport the cryptographic material needed by the re-authentication server. "Diameter Base Protocol MIB", Glen Zorn, Subash Comerica, 13-Jun-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. "Realm-Based Redirection In Diameter", Tina Tsou, Tom Taylor, 10-Jan-12, RFC 3588 allows a Diameter redirect agent to specify one or more individual hosts to which a Diameter message may be redirected by an upstream Diameter node. However, in some circumstances an operator may wish to redirect messages to an alternate domain without specifying individual hosts. This document specifies a mechanism by which this can be achieved. New applications may incorporate this capability by reference to the present document. "Diameter Network Address and Port Translation Control Application", Frank Brockners, Shwetha Bhandari, Vaneeta Singh, Victor Fajardo, 10-Jan-12, 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 networks to cope with IPv4-address space depletion. 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 IKEv2 SK: Shared Key-based Support for IKEv2 Server to Diameter Server Interaction", Violeta Cakulev, Avi Lior, Semyon Mizikovsky, 13-Nov-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 shared key. 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 shared key based authentication available with IKEv2. This document specifies the IKEv2 Server to the Diameter server communication when the IKEv2 Peer authenticates using the Internet Key Exchange v2 with Shared Key. "Diameter Attribute-Value Pairs for Cryptographic Key Transport", Glen Zorn, Wenson Wu, Violeta Cakulev, 18-Aug-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, 26-Jan-12, 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 between an MN's MAG and the MAG of its Correspondent Node (CN) without involving any 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, 31-Oct-11, 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, 4-Feb-12, This document describes the Diameter protocol application used for Authentication, Authorization, and Accounting (AAA) services in the Network Access Server (NAS) environment; it obsoletes RFC 4005. When combined with the Diameter Base protocol, Transport Profile, and Extensible Authentication Protocol specifications, this application specification satisfies typical network access services requirements. Distributed Mobility Management (dmm) ------------------------------------- "Guidelines for firewall administrators regarding MIPv6 traffic", Suresh Krishnan, Niklas Steinleitner, Ying Qiu, Gabor Bajko, 17-Oct-11, This document presents some recommendations for firewall administrators to help them configure their existing firewalls in a way that allows in certain deployment scenarios the Mobile IPv6 and DSMIPv6 signaling and data messages to pass through. For other scenarios, the support of additional mechanisms to create pinholes required for MIPv6 will be necessary. This document assumes that the firewalls in question include some kind of stateful packet filtering capability. "Guidelines for firewall vendors regarding MIPv6 traffic", Suresh Krishnan, Yaron Sheffer, Niklas Steinleitner, Gabor Bajko, 17-Oct-11, This document presents some recommendations for firewall vendors to help them implement their firewalls in a way that allows Mobile IPv6 and DSMIPv6 signaling and data messages to pass through. This document describes how to implement stateful packet filtering capability for MIPv6 and DSMIPv6. "Transport Layer Security-based Mobile IPv6 Security Framework for Mobile Node to Home Agent Communication", Jouni Korhonen, Basavaraj Patil, Hannes Tschofenig, Dirk Kroeselberg, 11-Oct-11, Mobile IPv6 signaling between a mobile node and its home agent is secured using IPsec. The security association between a mobile node and the home agent is established using IKEv1 or IKEv2. The security model specified for Mobile IPv6, which relies on IKE/IPsec, requires interaction between the Mobile IPv6 protocol component and the IKE/ IPsec module of the IP stack. This document proposes an alternate security framework for Mobile IPv6 and Dual-Stack Mobile IPv6, which relies on Transport Layer Security for establishing keying material and other bootstrapping parameters required to protect Mobile IPv6 signaling and data traffic between the mobile node and home agent. DNS Extensions (dnsext) ----------------------- "Clarifications and Implementation Notes for DNSSECbis", Samuel Weiler, David Blacka, 13-Jan-12, This document is a collection of technical clarifications to the DNSSECbis document set. It is meant to serve as a resource to implementors as well as a repository of DNSSECbis errata. This document updates the core DNSSECbis documents (RFC4033, RFC4034, and RFC4035) as well as the NSEC3 specification (RFC5155). It also defines NSEC3 and SHA-2 as core parts of the DNSSECbis specification. "DNAME Redirection in the DNS", Scott Rose, Wouter Wijngaards, 14-Nov-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 to the original specification in RFC 2672 (which this document obsoletes) as well as updating RFC 3363 and RFC 4294 to align with this revision. "Extension Mechanisms for DNS (EDNS0)", Joao Damas, Michael Graff, Paul Vixie, 7-Feb-12, 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 (RFC 2671) based on feedback from deployment experience in several implementations. It also closes the IANA registry for extended labels created as part of RFC 2671 and obsoletes RFC 2673 ("Binary Labels in the Domain Name System") which depends on the existence of extended labels. "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, 3-Jan-12, 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, 19-Jan-12, 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. "xNAME RCODE and Status Bits Clarification", Donald Eastlake, 11-Jan-12, The Domain Name System (DNS) has long provided means, such as CNAME (Canonical Name), where a query can be redirected to a different name. A DNS response header has an RCODE (Response Code) field, used for indicating errors, and response status bits. This document clarifies, in the case of such redirected queries, how the RCODE and status bits correspond to the initial query cycle (where the CNAME or the like was detected) and subsequent or final query cycles. "Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm Implementation Status", Scott Rose, 30-Jan-12, 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 recommended implementation status of each algorithm. This document provides an applicability statement on algorithm implementation compliance status for DNSSEC implementations. This document lists each algorithm's status based on the current reference. In the case that an algorithm is specified without an implementation status, this document assigns one. "DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry Updates", Scott Rose, 30-Jan-12, The DNS Security Extensions (DNSSEC) requires the use of cryptographic algorithm suites for generating digital signatures over DNS data. The algorithms specified for use with DNSSEC are reflected in an IANA maintained registry. This document presents a set of changes for some entries of the registry and presents a new registry table. Domain Name System Operations (dnsop) ------------------------------------- "DNS Referral Response Size Issues", Paul Vixie, Akira Kato, 13-Sep-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. "DNSSEC Operational Practices, Version 2", Olaf Kolkman, Matthijs Mekking, 31-Oct-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, 2-Sep-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. Data for Reachability of Inter/tra-NetworK SIP (drinks) ------------------------------------------------------- "Session Peering Provisioning Framework (SPPF)", Kenneth Cartwright, Syed Ali, Alexander Mayrhofer, Vikas Bhatia, 30-Jan-12, This document specifies the data model and the overall structure for a framework to provision session establishment data into Session Data Registries and SIP Service Provider data stores. The framework is called the Session Peering Provisioning Framework (SPPF). The provisioned data is typically used by network elements for session peering. "Session Peering Provisioning (SPP) Protocol over SOAP", Kenneth Cartwright, Vikas Bhatia, 30-Jan-12, The Session Peering Provisioning Framework (SPPF) is an XML framework 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 protocol for SPPF 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 SPPF XML structures over SOAP and HTTP(s). Email Address Internationalization (eai) ---------------------------------------- "Overview and Framework for Internationalized Email", John Klensin, YangWoo Ko, 29-Oct-11, 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 a replacement for RFC 4952; it reflects additional issues identified since that document was published. "SMTP Extension for Internationalized Email", Jiankang Yao, Wei MAO, 9-Nov-11, This document specifies an SMTP extension for transport and delivery of email messages with internationalized email addresses or header information. This specification replaces RFC 5336. "Internationalized Email Headers", Abel Yang, Shawn Steele, Ned Freed, 21-Oct-11, Internet mail was originally limited to 7-bit ASCII. MIME added support for the use of 8-bit character sets in body parts, and also defined an encoded-word construct so other character sets could be used in certain header field values. But full internationalization of electronic mail requires additional enhancements to allow the use of Unicode, including characters outside the ASCII repertoire, in mail addresses as well as direct use of Unicode in header fields like From:, To:, and Subject:, without requiring the use of complex encoded-word constructs. This document specifies an enhancement to the Internet Message Format and to MIME that allows use of Unicode in mail addresses and most header field content. This specification replaces RFC 5335. This specification also updates Section 6.4 of RFC 2045 to eliminate the restriction prohibiting the use of non-identity content-transfer-encodings on subtypes of "message/". "POP3 Support for UTF-8", Randall Gellens, Chris Newman, Jiankang Yao, Kazunori Fujiwara, 16-Nov-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 strings. This specification replaces RFC 5721. "Post-delivery Message Downgrading for Internationalized Email Messages", Kazunori Fujiwara, 31-Oct-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, 14-Nov-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, 26-Dec-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. This specification replaces RFC 5738. "Mailing Lists and UTF-8 Addresses", John Levine, Randall Gellens, 15-Dec-11, This document describes considerations for mailing lists with the introduction of internationalized email addresses. It outlines some possible scenarios for handling lists with mixtures of internationalized and traditional addresses, but does not offer implementation or deployment advice. Emergency Context Resolution with Internet Technologies (ecrit) --------------------------------------------------------------- "Best Current Practice for Communications Services in support of Emergency Calling", Brian Rosen, James Polk, 6-Sep-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 using IETF protocols should use such standards to make emergency calls. "Synchronizing Location-to-Service Translation (LoST) Protocol based Service Boundaries and Mapping Elements", Henning Schulzrinne, Hannes Tschofenig, 13-Jan-12, 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. "Additional Data related to an Emergency Call", Brian Rosen, Hannes Tschofenig, Roger Marshall, 31-Oct-11, When an emergency call is sent to a Public Safety Answering Point (PSAP), the device that sends it, as well as any service provider in the path of the call, or access network may have information about the call which the PSAP may be able to use. This document describes an XML data structure that contains this kind of information in a standardized form. A Uniform Resource Identifier (URI) that points to the structure can be included in the SIP signaling with the call, or the data may be included in the body of a SIP message. "Public Safety Answering Point (PSAP) Callback", Henning Schulzrinne, Hannes Tschofenig, Christer Holmberg, Milan Patel, 27-Oct-11, After an emergency call is completed (either prematurely terminated by the emergency caller or normally by the call-taker) it is possible that the call-taker feels the need for further communication. For example, the call may have been dropped by accident without the call- taker having sufficient information about the current situation of a wounded person. A call-taker may trigger a callback towards the emergency caller using the contact information provided with the initial emergency call. This callback could, under certain circumstances, be treated like any other call and as a consequence it may get blocked by authorization policies or may get forwarded to an answering machine. The IETF emergency services architecture offers capabilities to allow callbask to bypass authorization policies to reach the caller without unnecessary delays. However, the mechanism specified prior to this document supports only limited scenarios. This document discusses some shortcomings, presents additional scenarios where better-than- normal call treatment behavior would be desirable, and specifies a protocol solution. Energy Management (eman) ------------------------ "Requirements for Energy Management", Juergen Quittek, Rolf Winter, Thomas Dietz, Benoit Claise, Mouli Chandramouli, 1-Nov-11, This document defines requirements for standards specifications for energy management. The requirements presented in this document include monitoring functions as well as control functions. In detail, the focus of the requirements is on the following features: identification of powered entities, monitoring of their power state, power inlets, power outlets, actual power, power quality, consumed energy, and contained batteries. Further, requirements are included to enable control of powered entities' power supply and power state. This document does not specify the features that must be implemented by compliant implementations but rather features that must be supported by standards for energy management. "Energy-aware Networks and Devices MIB", John Parello, Benoit Claise, 31-Oct-11, This document defines a subset of a Management Information Base (MIB) for energy management of devices. The module addresses device identification, context information, and the relationships between reporting devices, remote devices, and monitoring devices. "Energy Management Framework", Benoit Claise, John Parello, Little Silver, Juergen Quittek, 30-Oct-11, This document defines a framework for providing Energy Management for devices within or connected to communication networks. The framework defines an Energy Management Domain as a set of Energy Objects, for which each Energy Object is identified, classified and given context. Energy Objects can be monitored and/or controlled with respect to Power, Power State, Energy, Demand, Power Quality, and battery. Additionally the framework models relationships and capabilities between Energy Objects. "Definition of Managed Objects for Battery Monitoring", Juergen Quittek, Rolf Winter, Thomas Dietz, 31-Oct-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. "Power and Energy Monitoring MIB", Mouli Chandramouli, Little Silver, Juergen Quittek, Thomas Dietz, Benoit Claise, 31-Oct-11, This document defines a subset of the Management Information Base (MIB) for power and energy monitoring of devices. "Energy Management (EMAN) Applicability Statement", Little Silver, Mouli Chandramouli, Bruce Nordman, 20-Dec-11, The objective of Energy Management (EMAN) is to provide an energy management framework for networked devices. This document presents the applicability of the EMAN framework for a variety of scenarios. This document lists use cases and target devices that can potentially implement the EMAN framework and associated SNMP MIB modules. These use cases are useful for identifying requirements for the framework. Further, we describe the relationship of the EMAN framework to relevant other energy monitoring standards and architectures. 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, T. Clancy, Katrin Hoeper, 10-Jan-12, 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. "Tunnel EAP Method (TEAP) Version 1", Hao Zhou, Nancy Cam-Winget, Joseph Salowey, Stephen Hanna, 20-Oct-11, This document defines the Tunnel Extensible Authentication Protocol (TEAP) protocol version 1. TEAP is a tunnel based 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. FEC Framework (fecframe) ------------------------ "Methods to convey FEC Framework Configuration Information", Rajiv Asati, 25-Sep-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, 24-Nov-11, 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. "Pseudo Content Delivery Protocol (CDP) for Protecting Multiple Source Flows in FEC Framework", Ulas Kozat, Ali Begen, 31-Oct-11, This document provides a pseudo Content Delivery Protocol (CDP) to protect multiple source flows with one or more repair flows based on the FEC Framework and the Session Description Protocol (SDP) elements defined for the framework. The purpose of the document is not to provide a full-pledged protocol, but to show how the defined framework and SDP elements can be combined together to design a CDP. "RTP Payload Format for Raptor FEC", Mark Watson, Thomas Stockhammer, Michael Luby, 25-Nov-11, This document specifies an RTP Payload Format for Forward Error Correction repair data produced by the Raptor FEC Schemes. Raptor FEC Schemes are specified for use with the IETF FEC Framework which supports transport of repair data over both UDP and RTP. This document specifies the Payload Format which is required for the use of RTP to carry Raptor repair flows. "Simple Reed-Solomon Forward Error Correction (FEC) Scheme for FECFRAME", Vincent Roca, Mathieu Cunche, Jerome Lacan, Amine Bouabdallah, Kazuhisa Matsuzono, 29-Nov-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. "Simple LDPC-Staircase Forward Error Correction (FEC) Scheme for FECFRAME", Vincent Roca, Mathieu Cunche, Jerome Lacan, 29-Nov-11, This document describes a fully-specified simple FEC scheme for LDPC- Staircase codes that can be used to protect media streams along the lines defined by the FECFRAME framework. These codes have many interesting properties: they are systematic codes, they perform close to ideal codes in many use-cases and they also feature very high encoding and decoding throughputs. LDPC-Staircase codes are therefore a good solution to protect a single high bitrate source flow, or to protect globally several mid-rate flows within a single FECFRAME instance. They are also a good solution whenever the processing load of a software encoder or decoder must be kept to a minimum. Forwarding and Control Element Separation (forces) -------------------------------------------------- "ForCES Logical Function Block (LFB) Library", Weiming Wang, Evangelos Haleplidis, Kentaro Ogawa, Chuanhuang Li, Joel Halpern, 11-Jan-12, This document defines basic classes of Logical Function Blocks (LFBs) used in the Forwarding and Control Element Separation (ForCES). The basic LFB classes are defined according to ForCES FE model and ForCES protocol specifications, and are scoped to meet requirements of typical router functions and considered as the basic LFB library for ForCES. The library includes the descriptions of the LFBs and the XML definitions. "ForCES Intra-NE High Availability", Kentaro Ogawa, Weiming Wang, Evangelos Haleplidis, Jamal Salim, 24-Aug-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 Salim, 9-Jan-12, This document captures test results from the second Forwarding and control Element Separation (ForCES) interoperability test which took place on February 24-25, 2011 in the Internet Technology Lab (ITL) of Zhejiang Gongshang University, China. FTP Extensions, 2nd edition (ftpext2) ------------------------------------- "File Transfer Protocol HOST Command for Virtual Hosts", Paul Hethmon, Robert McMurray, 7-Dec-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. "FTP consideration for IPv4/IPv6 transition", Dapeng Liu, Iljitsch Beijnum, Zhen Cao, 11-Jan-12, The File transfer protocol(FTP) has a long histroy,, but still being widely used. The first concept of FTP was described RFC 114, and then was specified in RFC 354. FTP can work in IPv4 environment and then was extended to IPv6. RFC 2428 defines IPv6 extensions of FTP. In the IPv6-IPv4 translation scenario, considerations should be applied to FTP client, server and translation box to ensure FTP protocol work properly. This document discusses the details for FTP to work in IPv4-IPv6 transitiion scenario. This document gives recommendation regarding how IPv6 FTP client should behave in 6to4 scenario. General Area Open Meeting (genarea) ----------------------------------- "Requirements for Remote Participation Services for the IETF", Paul Hoffman, 18-Jan-12, The IETF has provided some tools for remote participation in its activities for many years, and some IETF participants have also used their own tools when they felt the need arise. The IETF now wishes to support enhanced remote participation that is as seamless as possible, approaching the quality of direct physical attendance for the various roles, including chair, presenter and simple attendee. Before deploying the new tools and services needed for this enhanced remote participation, the requirements for such tools and services must be defined. This document is meant to be that definition. Geographic Location/Privacy (geopriv) ------------------------------------- "Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information", Henning Schulzrinne, Hannes Tschofenig, Jorge Cuellar, James Polk, John Morris, Martin Thomson, 14-Oct-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. "Dynamic Host Configuration Protocol (DHCP) IPv4 and IPv6 Option for a Location Uniform Resource Identifier (URI)", James Polk, 3-Oct-11, This document creates a Dynamic Host Configuration Protocol (DHCP) Option for transmitting a client's geolocation Uniform Resource Identifier (URI). This Location URI can then be dereferenced in a separate transaction by the client or sent to another entity and dereferenced to learn physically where the client is located. "A Location Dereferencing Protocol Using HELD", James Winterbottom, Hannes Tschofenig, Henning Schulzrinne, Martin Thomson, Martin Dawson, 30-Oct-11, 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 HTTP-Enabled Location Delivery (HELD) protocol to request the location of the Target. "Using Device-provided Location-Related Measurements in Location Configuration Protocols", Martin Thomson, James Winterbottom, 27-Oct-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, 31-Oct-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, 28-Nov-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, 12-Sep-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, 17-Oct-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. The LoST protocol mechanism that returns civic address element names used for validation of location information is clarified to require a namespace on each element. Global Routing Operations (grow) -------------------------------- "BGP Monitoring Protocol", John Scudder, Rex Fernando, Stephen Stuart, 1-Dec-11, 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, 30-Dec-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 can be deployed autonomously by an ISP without requiring cooperation between adjacent ISPs, and can co-exist with legacy routers in the ISP. "Graceful BGP session shutdown", Pierre Francois, Bruno Decraene, Cristel Pelsser, Keyur Patel, Clarence Filsfils, 8-Dec-11, This draft describes operational procedures aimed at reducing the amount of traffic lost during planned maintenances of routers or links, involving the shutdown of BGP peering sessions. "Auto-Configuration in Virtual Aggregation", Paul Francis, Xiaohu Xu, Hitesh Ballani, Dan Jen, Robert Raszuk, Lixia Zhang, 30-Dec-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. A Non-transitive Extended Communities Attribute is used to convey to other routers that a given route can be FIB-suppressed. "Simple Virtual Aggregation (S-VA)", Robert Raszuk, Alton Lo, Lixia Zhang, Xiaohu Xu, 15-Sep-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 RIB and FIB requirements substantially and therefore increase their useful lifetime. S-VA does not increase FIB requirements for core routers. S-VA is extremely easy to configure considerably more so than the various tricks done today to extend the life of edge routers. S-VA can be deployed autonomously by an ISP (cooperation between ISPs is not required), and can co-exist with legacy routers in the ISP. "Distribution of diverse BGP paths.", Robert Raszuk, Rex Fernando, Keyur Patel, Danny McPherson, Kenji Kumaki, 16-Nov-11, The BGP4 protocol specifies the selection and propagation of a single best path for each prefix. As defined and widely deployed today BGP has no mechanisms to distribute alternate paths which are not considered 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 built in parallel or they can co-exist 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. "Operational Requirements for Enhanced Error Handling Behaviour in BGP-4", Rob Shakir, 20-Oct-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-Based Overlay Networking Environment (HIP BONE) Instance Specification for REsource LOcation And Discovery (RELOAD)", Ari Keranen, Gonzalo Camarillo, Jouni Maenpaa, 28-Oct-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, 1-Sep-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. "Host Identity Protocol Version 2 (HIPv2)", Robert Moskowitz, Tobias Heer, Petri Jokela, Tom Henderson, 31-Oct-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", Tom Henderson, Christian Vogt, Jari Arkko, 13-Sep-11, This document defines mobility extensions to the Host Identity Protocol (HIP). Specifically, this document defines a general "LOCATOR_SET" 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_SET parameter can also be used to support end-host multihoming, detailed procedures are out of scope for this document. This document obsoletes RFC 5206. "Native NAT Traversal Mode for the Host Identity Protocol", Ari Keranen, Jan Melen, 22-Dec-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, Wenson Wu, Glen Zorn, 8-Feb-12, The Extensible Authentication Protocol (EAP) is a generic framework supporting multiple types of authentication methods. The EAP Re-authentication Protocol (ERP) specifies extensions to EAP and the EAP keying hierarchy to support an EAP method-independent protocol for efficient re-authentication between the peer and an EAP re-authentication server through any authenticator. Authenticated Anticipatory Keying (AAK) is a method by which cryptographic keying material may be established upon one or more candidate attachment points (CAPs) prior to handover. AAK uses the AAA infrastructure for key transport. This document specifies the extensions necessary to enable AAK support in ERP. "Handover Keying (HOKEY) Architecture Design", Glen Zorn, Qin Wu, Tom Taylor, Yoav Nir, Katrin Hoeper, Sebastien Decugis, 13-Jan-12, 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 basic 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 defines 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, Glen Zorn, Yang Shi, Baohong He, 15-Nov-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 avoid repeating 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. This memo obsoletes RFC 5296. Home Networking (homenet) ------------------------- "Home Networking Architecture for IPv6", Jari Arkko, Anders Brandt, Tim Chown, Jason Weil, Ole Troan, 30-Jan-12, This text describes evolving networking technology within small "residential home" networks. The goal of this memo is to define the architecture for IPv6-based home networking and the associated principles, considerations and requirements. The text highlights the impact of IPv6 on home networking, illustrates topology scenarios, and shows how standard IPv6 mechanisms and addressing can be employed in home networking. The architecture describes the need for specific protocol extensions for certain additional functionality. It is assumed that the IPv6 home network is not actively managed, and runs as an IPv6-only or dual-stack network. There are no recommendations in this text for the IPv4 part of the network. Hypertext Transfer Protocol Bis (httpbis) ----------------------------------------- "HTTP/1.1, part 1: URIs, Connections, and Message Parsing", Roy Fielding, Jim Gettys, Jeffrey Mogul, Henrik Nielsen, Larry Masinter, Paul Leach, Tim Berners-Lee, Yves Lafon, Julian Reschke, 3-Jan-12, 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 and moves it to historic status, along with its predecessor RFC 2068. 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. This part also obsoletes RFCs 2145 (on HTTP version numbers) and 2817 (on using CONNECT for TLS upgrades) and moves them to historic status. "HTTP/1.1, part 2: Message Semantics", Roy Fielding, Jim Gettys, Jeffrey Mogul, Henrik Nielsen, Larry Masinter, Paul Leach, Tim Berners-Lee, Yves Lafon, Julian Reschke, 3-Jan-12, 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 2 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages as expressed by request methods, request header fields, response status codes, and response header fields. "HTTP/1.1, part 3: Message Payload and Content Negotiation", Roy Fielding, Jim Gettys, Jeffrey Mogul, Henrik Nielsen, Larry Masinter, Paul Leach, Tim Berners-Lee, Yves Lafon, Julian Reschke, 3-Jan-12, 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 3 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 3 defines HTTP message content, metadata, and content negotiation. "HTTP/1.1, part 4: Conditional Requests", Roy Fielding, Jim Gettys, Jeffrey Mogul, Henrik Nielsen, Larry Masinter, Paul Leach, Tim Berners-Lee, Yves Lafon, Julian Reschke, 3-Jan-12, 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 4 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 4 defines request header fields for indicating conditional requests and the rules for constructing responses to those requests. "HTTP/1.1, part 5: Range Requests and Partial Responses", Roy Fielding, Jim Gettys, Jeffrey Mogul, Henrik Nielsen, Larry Masinter, Paul Leach, Tim Berners-Lee, Yves Lafon, Julian Reschke, 3-Jan-12, 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 5 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 5 defines range-specific requests and the rules for constructing and combining responses to those requests. "HTTP/1.1, part 6: Caching", Roy Fielding, Jim Gettys, Jeffrey Mogul, Henrik Nielsen, Larry Masinter, Paul Leach, Tim Berners-Lee, Yves Lafon, Mark Nottingham, Julian Reschke, 3-Jan-12, 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 6 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 6 defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages. "HTTP/1.1, part 7: Authentication", Roy Fielding, Jim Gettys, Jeffrey Mogul, Henrik Nielsen, Larry Masinter, Paul Leach, Tim Berners-Lee, Yves Lafon, Julian Reschke, 3-Jan-12, 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 the HTTP Authentication framework. "Initial Hypertext Transfer Protocol (HTTP) Method Registrations", Julian Reschke, 3-Jan-12, 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, 24-Aug-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. Internet Architecture Board (iab) --------------------------------- "Architectural Considerations on Application Features in the DNS", Olaf Kolkman, Jon Peterson, Hannes Tschofenig, Bernard Aboba, 31-Oct-11, A number of Internet applications rely on the Domain Name System (DNS) to support their operations. Many applications use the DNS to locate services for a domain, for example; more recently, some applications have begun transforming identifiers other than domain names into formats that the DNS can process. Proposals to incorporate more sophisticated application behavior into the DNS, however, have raised questions about the applicability and extensibility of the DNS. This document explores the architectural consequences of installing certain application features in the DNS, and provides guidance to future application designers as to the sorts of ways that application can make use of the DNS. Inter-Domain Routing (idr) -------------------------- "Dynamic Capability for BGP-4", Enke Chen, Srihari Sangli, 5-Dec-11, This document defines a new BGP capability termed "Dynamic Capability", which would allow the dynamic update of capabilities over an established BGP session. This capability would facilitate non-disruptive capability changes by BGP speakers. "Issues in Revising BGP-4 (RFC1771 to RFC4271)", Andrew Lange, 11-Aug-11, This document records the issues discussed and the consensus reached in the Interdomain Routing (IDR) Working Group during its efforts to revise and bring up to date the base specification for the BGP-4 protocol as documented in RFC1771. The document focuses on the changes tracked from August 2002 when the last major push for revision began. The results of these efforts are encoded in RFC4271, which should be taken as normative for any of the issues that were discussed. The discussion here is intended to record how and why some of the changes to BGP were made. "Revisions to the BGP 'Minimum Route Advertisement Interval'", Paul Jakma, 20-Sep-11, This document updates the specification of the BGP MRAI timer in [RFC4271], by deprecating the previously recommended values and by allowing for withdrawals to be exempted from the MRAI. "Advertisement of Multiple Paths in BGP", Daniel Walton, Enke Chen, Alvaro Retana, John Scudder, 15-Sep-11, In this document we propose a BGP extension that allows the advertisement of multiple paths for the same address prefix without the new paths implicitly replacing any previous ones. The essence of the extension is that each path is identified by a path identifier in addition to the address prefix. "BGP Link Bandwidth Extended Community", Pradosh Mohapatra, Rex Fernando, 2-Oct-11, This document describes an application of BGP extended communities that allows a router to perform unequal cost load balancing. "The Accumulated IGP Metric Attribute for BGP", Pradosh Mohapatra, Rex Fernando, Eric Rosen, James Uttaro, 12-Dec-11, Routing protocols that have been designed to run within a single administrative domain ("IGPs") generally do so by assigning a metric to each link, and then choosing as the installed path between two nodes the path for which the total distance (sum of the metric of each link along the path) is minimized. BGP, designed to provide routing over a large number of independent administrative domains ("autonomous systems"), does not make its path selection decisions through the use of a metric. It is generally recognized that any attempt to do so would incur significant scalability problems, as well as inter-administration coordination problems. However, there are deployments in which a single administration runs several contiguous BGP networks. In such cases, it can be desirable, within that single administrative domain, for BGP to select paths based on a metric, just as an IGP would do. The purpose of this document is to provide a specification for doing so. "Advertisement of the best external route in BGP", Pedro Marques, Rex Fernando, Enke Chen, Pradosh Mohapatra, Hannes Gredler, 3-Jan-12, The current BGP-4 protocol specification [RFC4271] states that the selection process chooses the best path for a given route which is added to the Loc-Rib and advertised to all peers. Previous versions [RFC1771] of the specification defined a different rule for Internal BGP Updates. Given that Internal paths are not re- advertised to Internal peers, it was specified that the best of the external paths, as determined by the path selection tie breaking algorithm, would be advertised to Internal peers. This document extends that procedure to operate in environments where Route Reflection [RFC4456] or Confederations [RFC5065] are used and explains why advertising the additional routing information can improve convergence time without causing routing loops. Additional benefits include reduction of inter-domain churn and avoidance of permanent route oscillation. "BGP Bestpath Selection Criteria Enhancement", Rajiv Asati, 23-Aug-11, BGP specification [RFC4271] prescribes 'BGP next-hop reachability' as one of the key 'Route Resolvability Condition' that must be satisfied before the BGP bestpath candidate selection. This condition, however, may not be sufficient (as explained in the Appendix section) and desire further granularity. This document defines enhances the "Route Resolvability Condition" to facilitate the next-hop to be resolved in the chosen data plane. "Subcodes for BGP Finite State Machine Error", Jie Dong, Mach Chen, Anantharamu Suryanarayana, 10-Aug-11, This document defines several subcodes for BGP Finite State Machine (FSM) Error that could provide more information to help network operators in diagnosing BGP FSM issues and correlating network events. "Best Practices for Advertisement of Multiple Paths in IBGP", James Uttaro, Place Barbe, Pierre Francois, Roberto Fragassi, Adam Simpson, Pradosh Mohapatra, 25-Nov-11, Add-Paths is a BGP enhancement that allows a BGP router to advertise multiple distinct paths for the same prefix/NLRI. This provides a number of potential benefits, including reduced routing churn, faster convergence and better loadsharing. This document provides recommendations to implementers of Add-Paths so that network operators have the tools needed to address their specific applications and to manage the scalability impact of Add- Paths. A router implementing Add-Paths may learn many paths for a prefix and must decide which of these to advertise to peers. This document analyses different algorithms for making this selection and provides recommendations based on the target application. "Multiprotocol Extensions for BGP-4", Tony Bates, Ravi Chandra, Dave Katz, 16-Aug-11, This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, L3VPN, etc...). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions. "Assigned BGP extended communities", Bruno Decraene, Pierre Francois, 5-Dec-11, This document defines two IANA registries in order to assign transitive and non-transitive extended communities from. These are similar to the existing well-known BGP communities defined in RFC 1997 but provide an easier control of inter-AS community advertisement as a community could be chosen as transitive or non- transitive across ASes. For that purpose, this document defines the use of the reserved AS number 0 for the transitive and non-transitive generic four-octet AS specific extended community types. "BGP Optimal Route Reflection (BGP-ORR)", Robert Raszuk, Christian Cassar, Erik Aman, Bruno Decraene, 15-Sep-11, [RFC4456] asserts that, because the Interior Gateway Protocol (IGP) cost to a given point in the network will vary across routers, "the route reflection approach may not yield the same route selection result as that of the full IBGP mesh approach." One practical implication of this assertion is that the deployment of route reflection may thwart the ability to achieve hot potato routing. Hot potato routing attempts to direct traffic to the closest AS egress point in cases where no higher priority policy dictates otherwise. As a consequence of the route reflection method, the choice of exit point for a route reflector and its clients will be the egress point closest to the route reflector - and not necessarily closest to the RR clients. Section 11 of [RFC4456] describes a deployment approach and a set of constraints which, if satsified, would result in the deployment of route reflection yielding the same results as the iBGP full mesh approach. Such a deployment approach would make route reflection compatible with the application of hot potato routing policy. As networks evolved to accommodate architectural requirements of new services, tunneled (LSP/IP tunneling) networks with centralized route reflectors became commonplace. This is one type of common deployment where it would be impractical to satisfy the constraints described in Section 11 of [RFC4456]. Yet, in such an environment, hot potato routing policy remains desirable. This document proposes two new solutions which can be deployed to facilitate the application of closest exit point policy centralized route reflection deployments. "Enhanced Route Refresh Capability for BGP-4", Keyur Patel, Enke Chen, Balaji Venkatachalapathy, 16-Dec-11, In this document we enhance the existing BGP route refresh mechanisms to provide for the demarcation of the beginning and the ending of a route refresh. The enhancement can be used to facilitate on-line, non-disruptive consistency validations of BGP routing updates. "Extended Message support for BGP", Keyur Patel, David Ward, Randy Bush, 10-Jan-12, The BGP specification mandates a maximum BGP message size of 4096 octets. As BGP is extended to support newer AFI/SAFIs, there is a need to extend the maximum message size beyond 4096 octets. This draft provides an extension to BGP to extend its current message size from 4096 octets to 65535 octets. "Dissemination of Flow Specification Rules for IPv6", Robert Raszuk, Burjiz Pithawala, Danny McPherson, 25-Oct-11, Dissemination of Flow Specification Rules [RFC5575] provides a protocol extension for propagation of traffic flow information for the purpose of rate limiting or filtering. The [RFC5575] specifies those extensions for IPv4 protocol data packets. This specification extends the current [RFC5575] and defines changes to the original document in order to make it also usable and applicable to IPv6 data packets. "IPv6 Extensions for Route Target Distribution", Keyur Patel, Robert Raszuk, Martine Djernaes, Jie Dong, Mach Chen, 30-Oct-11, The current route target distribution specification described in RFC4684 defines Route Target NLRIs of maximum length of 12 bytes. The IPv6 specific Route Target extended community is defined in [RFC5701] as length of 20 bytes. Since the current specification only supports prefixes of maximum length of 12 bytes, the lack of an IPv6 specific Route Target reachability information may be a problem when an operator wants to use this application in a pure IPv6 environment. This document defines an extension that allows BGP to exchange longer length IPv6 Route Target prefixes. "Revised Error Handling for BGP UPDATE Messages", John Scudder, Enke Chen, Pradosh Mohapatra, Keyur Patel, 15-Dec-11, According to the base BGP specification, a BGP speaker that receives an UPDATE message containing a malformed attribute is required to reset the session over which the offending attribute was received. This behavior is undesirable as a session reset would impact not only routes with the offending attribute, but also other valid routes exchanged over the session. This document partially revises the error handling for UPDATE messages, and provides guidelines for the authors of documents defining new attributes. Finally, it revises the error handling procedures for several existing attributes. "Codification of AS 0 processing.", Warren Kumari, Randy Bush, Heather Schiller, Keyur Patel, 18-Jan-12, This document proscribes the use of AS 0 in BGP OPEN and AS_PATH / AS4_PATH BGP attribute. "BGP Custom Decision Process", Alvaro Retana, Russ White, 21-Nov-11, The BGP specification defines a Decision Process for installation of routes into the Loc-RIB. This process takes into account an extensive series of path attributes, which can be manipulated to indicate preference for specific paths. It is cumbersome (if at all possible) for the end user to define policies that will select, after partial comparison, a path based on subjective local (domain and/or node) criteria. This document defines a new Extended Community, called the Cost Community, which may be used in tie breaking during the best path selection process. The end result is a local custom decision process. "Notification Message support for BGP Graceful Restart", Keyur Patel, Rex Fernando, John Scudder, Jeffrey Haas, 6-Dec-11, The current BGP Graceful Restart mechanism limits the usage of BGP Graceful Restart to BGP protocol messages other than a BGP NOTIFICATION message. This document defines an extension to the BGP Graceful Restart that permits the Graceful Restart procedures to be performed when the BGP speaker receives a BGP NOTIFICATION Message. This document also defines a new BGP NOTIFICATION Cease Error subcode to prevent BGP speakers supporting the extension defined in this document from performing a Graceful Restart. "Accelerated Routing Convergence for BGP Graceful Restart", Keyur Patel, Enke Chen, Rex Fernando, John Scudder, 5-Dec-11, In this document we specify extensions to BGP graceful restart in order to avoid unnecessary transmission of the routing information preserved across a session restart, thus accelerating the routing convergence. "Automatic Route Target Filtering for legacy PEs", Pradosh Mohapatra, Arjun Sreekantiah, Keyur Patel, Burjiz Pithawala, Alton Lo, 18-Jan-12, This document describes a simple procedure that allows "legacy" BGP speakers to exchange route target membership information in BGP without using mechanisms specified in RFC 4684. The intention of the proposed technique is to help in partial deployment scenarios and is not meant to replace RFC 4684. "Carrying next-hop cost information in BGP", Ilya Varlashkin, Robert Raszuk, 30-Jan-12, This document describes new BGP SAFI to exchange cost information to next-hops for the purpose of calculating best path from a peer perspective rather than local BGP speaker own perspective. Internet Area Working Group (intarea) ------------------------------------- "Updated Specification of the IPv4 ID Field", Joseph Touch, 16-Sep-11, The IPv4 Identification (ID) field enables fragmentation and reassembly, and as currently specified is required to be unique within the maximum lifetime for all datagrams with a given source/destination/protocol tuple. If enforced, this uniqueness requirement would limit all connections to 6.4 Mbps. Because individual connections commonly exceed this speed, it is clear that existing systems violate the current specification. This document updates the specification of the IPv4 ID field in RFC791, RFC1122, and RFC2003 to more closely reflect current practice and to more closely match IPv6 so that the field's value is defined only when a datagram is actually fragmented. It also discusses the impact of these changes on how datagrams are used. "IPv6 Support Required for all IP-capable Nodes", Wesley George, Chris Donley, Christopher Liljenstolpe, Lee Howard, 8-Dec-11, Given the global lack of available IPv4 space, and limitations in IPv4 extension and transition technologies, this document advises that IPv6 support is no longer considered optional. It also cautions that there are places in existing IETF documents where the term "IP" is used in a way that could be misunderstood by implementers as the term "IP" becomes a generic which can mean IPv4 + IPv6, IPv6-only, or IPv4-only, depending on context and application. "Analysis of Solution Candidates to Reveal a Host Identifier in Shared Address Deployments", Mohamed Boucadair, Joseph Touch, Pierre Levis, Reinaldo Penno, 7-Feb-12, This document analyzes a set of solution candidates to mitigate some of the issues encountered when address sharing is used. In particular, this document focuses on means to reveal a host identifier (HOST_ID) when a Carrier Grade NAT (CGN) or application proxies are involved in the path. This host identifier must be unique to each host under the same shared IP address. IP Flow Information Export (ipfix) ---------------------------------- "IPFIX Export per SCTP Stream", Benoit Claise, Paul Aitken, Andrew Johnson, Gerhard Muenz, 31-May-10, This document specifies an extension to the specifications in RFC5101, IP Flow Information Export (IPFIX), when using the Partial Reliability extension of SCTP (PR-SCTP, Partial Reliability Stream Control Transmission Protocol). When implemented at both the Exporting and Collecting Processes, this method offers several advantages such as the ability to calculate Data Record losses for PR-SCTP, immediate export of Template Withdrawal Messages, immediate reuse of Template IDs within an SCTP stream, reduced likelihood of Data Record loss, and reduced demands on the Collecting Process. When implemented in only the Collecting or Exporting Process then normal IPFIX behavior will be seen without these additional benefits. "Configuration Data Model for IPFIX and PSAMP", Gerhard Muenz, Benoit Claise, Paul Aitken, 11-Jul-11, This document specifies a data model for configuring and monitoring Selection Processes, Caches, Exporting Processes, and Collecting Processes of IPFIX and PSAMP compliant Monitoring Devices using the NETCONF protocol. The data model is defined using UML (Unified Modeling Language) class diagrams and formally specified using YANG. The configuration data is encoded in Extensible Markup Language (XML). "Flow Selection Techniques", Salvatore D'Antonio, Tanja Zseby, Christian Henke, Lorenzo Peluso, 14-Nov-11, Flow selection is the process of selecting a subset of flows from all observed flows. The Flow Selection Process may be located at an observation point, or on an IPFIX Mediator. Flow selection reduces the effort of post-processing flow data and transferring Flow Records. This document describes motivations for flow selection and presents flow selection techniques. It provides an information model for configuring flow selection techniques and discusses what information about a flow selection process should be exported. "Definitions of Managed Objects for Packet Sampling", Thomas Dietz, Benoit Claise, Juergen Quittek, 31-Oct-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 describes extensions to the IPFIX SELECTOR MIB module [I-D.dkcm-ipfix-rfc5815bis]. For IPFIX implementations that use packet Sampling (PSAMP) techniques as described in [RFC5475], this memo defines the PSAMP MIB module containing managed objects for providing information on applied packet selection functions and their parameters. "Definitions of Managed Objects for IP Flow Information Export", Thomas Dietz, Atsushi Kobayashi, Benoit Claise, Gerhard Muenz, 20-Jan-12, This document defines managed objects for IP Flow Information eXport (IPFIX). These objects provide information for monitoring IPFIX Exporters and IPFIX Collectors including the basic configuration information. "Flow Aggregation for the IP Flow Information Export (IPFIX) Protocol", Brian Trammell, Arno Wagner, Benoit Claise, 3-Feb-12, This document describes the export of aggregated Flow information using IPFIX. An Aggregated Flow is essentially an IPFIX Flow representing packets from multiple Original Flows sharing some set of common properties. The document describes Aggregated Flow export within the framework of IPFIX Mediators and defines an interoperable, implementation-independent method for Aggregated Flow export. "Guidelines for Authors and Reviewers of IPFIX Information Elements", Brian Trammell, Benoit Claise, 10-Feb-12, This document provides guidelines for the definition of IPFIX Information Elements for addition to the IANA IPFIX Information Element registry, in order to extend the applicability of the IPFIX protocol to new operations and management areas. "Specification of the IP Flow Information eXport (IPFIX) Protocol for the Exchange of IP Traffic Flow Information", Benoit Claise, Brian Trammell, 29-Nov-11, This document specifies the IP Flow Information Export (IPFIX) protocol that serves for transmitting IP Traffic Flow information over the network. In order to transmit IP Traffic Flow information from an Exporting Process to an information Collecting Process, a common representation of flow data and a standard means of communicating them is required. This document describes how the IPFIX Data and Template Records are carried over a number of transport protocols from an IPFIX Exporting Process to an IPFIX Collecting Process. This document obsoletes RFC 5101. "Specification of the Protocol for IPFIX Mediation", Benoit Claise, Atsushi Kobayashi, Brian Trammell, 6-Dec-11, This document specifies the IP Flow Information Export (IPFIX) protocol specific to Mediation. "Information Model for IP Flow Information eXport (IPFIX)", Benoit Claise, Brian Trammell, 24-Jan-12, This memo defines an overview of the information model for the IP Flow Information eXport (IPFIX) protocol. It is used by the IPFIX protocol for encoding measured traffic information and information related to the traffic Observation Point, the traffic Metering Process, and the Exporting Process. Although developed for the IPFIX protocol, the model is defined in an open way that easily allows using it in other protocols, interfaces, and applications. This document obsoletes RFC 5102. IP Performance Metrics (ippm) ----------------------------- "Reporting Metrics: Different Points of View", Al Morton, Gomathi Ramachandran, Ganga Maguluri, 7-Jan-12, Consumers of IP network performance metrics have many different uses in mind. The memo provides "long-term" reporting considerations (e.g, days, weeks or months, as opposed to 10 seconds), based on analysis of the two key audience points-of-view. It describes how the audience categories affect the selection of metric parameters and options when seeking info that serves their needs. "Loss Episode Metrics for IPPM", Nick Duffield, Al Morton, Joel Sommers, 18-Jan-12, The IETF has developed a one way packet loss metric that measures the loss rate on a Poisson probe stream between two hosts. However, the impact of packet loss on applications is in general sensitive not just to the average loss rate, but also to the way in which packet losses are distributed in loss episodes (i.e., maximal sets of consecutively lost probe packets). This document defines one-way packet loss episode metrics, specifically the frequency and average duration of loss episodes, and a probing methodology under which the loss episode metrics are to be measured. "IPPM standard advancement testing", Ruediger Geib, Al Morton, Reza Fardid, Alexander Steinmitz, 30-Nov-11, This document specifies tests to determine if multiple independent instantiations of a performance metric RFC have implemented the specifications in the same way. This is the performance metric equivalent of interoperability, required to advance RFCs along the standards track. Results from different implementations of metric RFCs will be collected under the same underlying network conditions and compared using statistical methods. The goal is an evaluation of the metric RFC itself; whether its definitions are clear and unambiguous to implementors and therefore a candidate for advancement on the IETF standards track. This document is an Internet Best Current Practice. "Round-trip Loss Metrics", Al Morton, 6-Jan-12, Many user applications (and the transport protocols that make them possible) require two-way communications. To assess this capability, and to achieve test system simplicity, round-trip loss measurements are frequently conducted in practice. The Two-Way Active Measurement Protocol specified in RFC 5357 establishes a round-trip loss measurement capability for the Internet. However, there is currently no metric specified according to the RFC 2330 framework. This memo adds round-trip loss to the set of IP Performance Metrics (IPPM). "Test Plan and Results for Advancing RFC 2679 on the Standards Track", Len Ciavattone, Ruediger Geib, Al Morton, Matthias Wieser, 21-Oct-11, This memo proposes to advance a performance metric RFC along the standards track, specifically RFC 2679 on One-way Delay Metrics. Observing that the metric definitions themselves should be the primary focus rather than the implementations of metrics, this memo describes the test procedures to evaluate specific metric requirement clauses to determine if the requirement has been interpreted and implemented as intended. Two completely independent implementations have been tested against the key specifications of RFC 2679. "TWAMP Value-Added Octets", Steve Baillargeon, Christofer Flinta, Andreas Johnsson, Svante Ekelin, 8-Feb-12, This memo describes optional extensions to the TWAMP test protocol for identifying and managing packet trains, which enables measuring capacity metrics like the available path capacity, tight section capacity and UDP delivery rate in the forward and reverse path directions. Internationalized Resource Identifiers (iri) -------------------------------------------- "Internationalized Resource Identifiers (IRIs)", Martin Duerst, Michel Suignard, Larry Masinter, 9-Jan-12, This document defines the Internationalized Resource Identifier (IRI) protocol element, as an extension of the Uniform Resource Identifier (URI). An IRI is a sequence of characters from the Universal Character Set (Unicode/ISO 10646). Grammar and processing rules are given for IRIs and related syntactic forms. Defining IRI as new protocol element (rather than updating or extending the definition of URI) allows independent orderly transitions: other protocols and languages that use URIs must explicitly choose to allow IRIs. Guidelines are provided for the use and deployment of IRIs and related protocol elements when revising protocols, formats, and software components that currently deal only with URIs. This document is part of a set of documents intended to replace RFC 3987. "Guidelines and Registration Procedures for New URI/IRI Schemes", Tony Hansen, Ted Hardie, Larry Masinter, 13-Dec-11, This document updates the guidelines and recommendations for the definition of Uniform Resource Identifier (URI) schemes, and extends the registry and guidelines to apply when the schemes are used with Internationalized Resource Identifiers (IRIs). It also updates the process and IANA registry for URI/IRI schemes. It obsoletes RFC 4395. "Guidelines for Internationalized Resource Identifiers with Bi- directional Characters (Bidi IRIs)", Martin Duerst, Larry Masinter, 13-Aug-11, This specification gives guidelines for selection, use, presentation of International Resource Identifiers (IRI) which include characters with in inherent right-to-left (rtl) writing direction. "Equivalence and Canonicalization of Internationalized Resource Identifiers (IRIs)", Larry Masinter, Martin Duerst, 13-Aug-11, Internationalized Resource Identifiers (IRIs) are unicode strings used to identify resources on the Internet. Applications that use IRIs often define a means of comparing two IRIs to determine when two IRIs are equivalent for the purpose of that application. Some applications also define a method for 'canonicalizing' or 'normalizing' an IRI -- translating one IRI into another which is equivalent under the comparison method used. This document gives guidelines and best practices for defining and using IRI comparison, equivalence, normalization and canonicalization methods. IS-IS for IP Internets (isis) ----------------------------- "Advertising Generic Information in IS-IS", Les Ginsberg, Stefano Previdi, Mike Shand, 10-Nov-10, This draft describes the manner in which generic application information (i.e. information not directly related to the operation of the IS-IS protocol) should be advertised in IS-IS LSPs and defines guidelines which should be used when flooding such information. "IS-IS Multi-Instance", Stefano Previdi, Les Ginsberg, Mike Shand, Abhay Roy, Dave Ward, 30-Oct-11, This draft describes a mechanism that allows a single router to share one or more circuits among multiple Intermediate System To Intermediate System (IS-IS) routing protocol instances. Multiple instances allow the isolation of resources associated with each instance. Routers will form instance specific adjacencies. Each instance can support multiple topologies. Each topology has a unique Link State Database (LSDB). Each Protocol Data Unit (PDU) will contain a new Type Length Value (TLV) identifying the instance and the topology(ies) to which the PDU belongs. "IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging", Don Fedyk, Peter Ashwood-Smith, David Allan, Nigel Bragg, Paul Unbehagen, 9-Mar-11, 802.1aq Shortest Path Bridging (SPB) is being standardized by the IEEE as the next step in the evolution of the various spanning tree and registration protocols. 802.1aq allows for true shortest path forwarding in a mesh Ethernet network context utilizing multiple equal cost paths. This permits it to support much larger layer 2 topologies, with faster convergence, and vastly improved use of the mesh topology. Combined with this is single point provisioning for logical connectivity membership, which includes point-to-point, point-to-multi-point and multi-point-to-multipoint variations. This memo documents the IS-IS changes required to support this IEEE protocol and provides some context and examples. Javascript Object Signing and Encryption (jose) ----------------------------------------------- "JSON Web Encryption (JWE)", Michael Jones, Eric Rescorla, Joe Hildebrand, 16-Jan-12, JSON Web Encryption (JWE) is a means of representing encrypted content using JSON data structures. Cryptographic algorithms and identifiers used with this specification are enumerated in the separate JSON Web Algorithms (JWA) specification. Related digital signature and HMAC capabilities are described in the separate JSON Web Signature (JWS) specification. "JSON Web Key (JWK)", Michael Jones, 16-Jan-12, A JSON Web Key (JWK) is a JSON data structure that represents a set of public keys. "JSON Web Signature (JWS)", Michael Jones, John Bradley, Nat Sakimura, 16-Jan-12, JSON Web Signature (JWS) is a means of representing content secured with digital signatures or Hash-based Message Authentication Codes (HMACs) using JSON data structures. Cryptographic algorithms and identifiers used with this specification are enumerated in the separate JSON Web Algorithms (JWA) specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification. "JSON Web Algorithms (JWA)", Michael Jones, 16-Jan-12, The JSON Web Algorithms (JWA) specification enumerates cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS) and JSON Web Encryption (JWE) specifications. Keying and Authentication for Routing Protocols (karp) ------------------------------------------------------ "The Threat Analysis and Requirements for Cryptographic Authentication of Routing Protocols' Transports", Gregory Lebovitz, Manav Bhatia, Russ White, 18-Jun-11, Different routing protocols exist and each employs its own mechanism for securing the protocol packets on the wire. While most already have some method for accomplishing cryptographic message authentication, in many cases the existing methods are dated, vulnerable to attack, and employ cryptographic algorithms that have been deprecated. The "Keying and Authentication for Routing Protocols" (KARP) effort aims to overhaul and improve these mechanisms. This document has two main parts - the first describes the threat analysis for attacks against routing protocols' transports and the second enumerates the requirements for addressing the described threats. This document, along with the KARP design guide will be used by KARP design teams for specific protocol review and overhaul. This document reflects the input of both the IETF's Security Area and Routing Area in order to form a jointly agreed upon guidance. "Database of Long-Lived Symmetric Cryptographic Keys", Russ Housley, Tim Polk, 31-Oct-11, This document specifies the information contained in a database of long-lived cryptographic keys used by many different security protocols. The database design supports both manual and automated key management. In many instances, the security protocols do not directly use the long-lived key, but rather a key derivation function is used to derive a short-lived key from a long-lived key. "Analysis of OSPF Security According to KARP Design Guide", Sam Hartman, Dacheng Zhang, 24-Aug-11, This document analyzes OSPFv2 and OSPFv3 according to the guidelines set forth in section 4.2 of draft-ietf-karp-design-guide. "Operations Model for Router Keying", Sam Hartman, Dacheng Zhang, 23-Oct-11, Developing an operational and management model for routing protocol security that works across protocols will be critical to the success of routing protocol security efforts. This document discusses issues and begins to consider development of these models. Common Authentication Technology Next Generation (kitten) --------------------------------------------------------- "GSS-API Naming Extensions", Nicolas Williams, Leif Johansson, Sam Hartman, Simon Josefsson, 16-Dec-11, The Generic Security Services API (GSS-API) provides a simple naming architecture that supports name-based authorization. This document introduces new APIs that extend the GSS-API naming model to support name attribute transfer between GSS-API peers. "A SASL & GSS-API Mechanism for OpenID", Eliot Lear, Hannes Tschofenig, Henry Mauldin, Simon Josefsson, 23-Nov-11, OpenID has found its usage on the Internet for Web Single Sign-On. Simple Authentication and Security Layer (SASL) and the Generic Security Service Application Program Interface (GSS-API) are application frameworks to generalize authentication. This memo specifies a SASL and GSS-API mechanism for OpenID that allows the integration of existing OpenID Identity Providers with applications using SASL and GSS-API. "A SASL and GSS-API Mechanism for SAML", Klaas Wierenga, Eliot Lear, Simon Josefsson, 12-Jan-12, Security Assertion Markup Language (SAML) has found its usage on the Internet for Web Single Sign-On. Simple Authentication and Security Layer (SASL) and the Generic Security Service Application Program Interface (GSS-API) are application frameworks to generalize authentication. This memo specifies a SASL mechanism and a GSS-API mechanism for SAML 2.0 that allows the integration of existing SAML Identity Providers with applications using SASL and GSS-API. "SAML Enhanced Client SASL and GSS-API Mechanisms", Scott Cantor, Simon Josefsson, 29-Aug-11, Security Assertion Markup Language (SAML) 2.0 is a generalized framework for the exchange of security-related information between asserting and relying parties. Simple Authentication and Security Layer (SASL) and the Generic Security Service Application Program Interface (GSS-API) are application frameworks to facilitate an extensible authentication model. This document specifies a SASL and GSS-API mechanism for SAML 2.0 that leverages the capabilities of a SAML-aware "enhanced client" to address significant barriers to federated authentication in a manner that encourages reuse of existing SAML bindings and profiles designed for non-browser scenarios. "A SASL and GSS-API Mechanism for OAuth", William Mills, Tim Showalter, Hannes Tschofenig, 13-Nov-11, OAuth enables a third-party application to obtain limited access to a protected resource, either on behalf of a resource owner by orchestrating an approval interaction, or by allowing the third-party application to obtain access on its own behalf. This document defines how an application client uses OAuth over the Simple Authentication and Security Layer (SASL) or the Generic Security Service Application Program Interface (GSS-API) to access a protected resource at a resource serve, and additionally defines authorization and token issuing endpoint discovery. Thereby, it enables schemes defined within the OAuth framework for non-HTTP-based application protocols. Clients typically store the user's long term credential. This does, however, lead to significant security vulnerabilities, for example, when such a credential leaks. A significant benefit of OAuth for usage in those clients is that the password is replaced by a token. Tokens typically provided limited access rights and can be managed and revoked separately from the user's long-term credential (password). Kerberos (krb-wg) ----------------- "Kerberos Principal Name Canonicalization and KDC-Generated Cross-Realm Referrals", Sam Hartman, Kenneth Raeburn, Larry Zhu, 31-Oct-11, The memo documents a method for a Kerberos Key Distribution Center (KDC) to respond to client requests for Kerberos tickets when the client does not have detailed configuration information on the realms of users or services. The KDC will handle requests for principals in other realms by returning either a referral error or a cross-realm TGT to another realm on the referral path. The clients will use this referral information to reach the realm of the target principal and then receive the ticket. This memo also provides a mechanism for verifying that a request has not been tampered with in transit. "PKINIT Algorithm Agility", Love Astrand, Larry Zhu, Margaret Wasserman, 6-Jan-12, This document updates PKINIT, as defined in RFC 4556, to remove protocol structures tied to specific cryptographic algorithms. The PKINIT key derivation function is made negotiable, the digest algorithms for signing the pre-authentication data and the client's X.509 certificates are made discoverable. These changes provide preemptive protection against vulnerabilities discovered in the future against any specific cryptographic algorithm, and allow incremental deployment of newer algorithms. "Kerberos Version 5 GSS-API Channel Binding Hash Agility", Shawn Emery, 6-Jan-12, Currently, channel bindings are implemented using a MD5 hash in the Kerberos Version 5 Generic Security Services Application Programming Interface (GSS-API) mechanism [RFC4121]. This document updates RFC4121 to allow channel bindings using algorithms negotiated based on Kerberos crypto framework as defined in RFC3961. In addition, because this update makes use of the last extensible field in the Kerberos client-server exchange message, extensions are defined to allow future protocol extensions. "OTP Pre-authentication", Gareth Richards, 23-Nov-11, The Kerberos protocol provides a framework authenticating a client using the exchange of pre-authentication data. This document describes the use of this framework to carry out One Time Password (OTP) authentication. "An information model for Kerberos version 5", Leif Johansson, 31-May-11, This document describes an information model for Kerberos version 5 from the point of view of an administrative service. There is no standard for administrating a kerberos 5 KDC. This document describes the services exposed by an administrative interface to a KDC. "Kerberos Options for DHCPv6", Shoichi Sakane, Masahiro Ishiyama, 27-Dec-11, This document defines new four options of Dynamic Host Configuration Protocol for IPv6 (DHCPv6) to carry a set of configuration information related to the Kerberos protocol [RFC4120]. "A Generalized PAC for Kerberos V5", Simo Sorce, Tom Yu, Thomas Hardjono, 31-Oct-11, This draft proposes a generalized authorization structure for the Kerberos V5 protocol. Such an authorization structure would allow for greater interoperability among directory services and other related Kerberos services across differing realms. "Camellia Encryption for Kerberos 5", Greg Hudson, 6-Oct-11, This document specifies two encryption types and two corresponding checksum types for the Kerberos cryptosystem suite. The new types use the Camellia block cipher in CBC-mode with ciphertext stealing and the CMAC algorithm for integrity protection. "Deprecate DES support for Kerberos", Love Astrand, Tom Yu, 9-Feb-12, The Kerberos 5 network authentication protocol, originally specified in RFC1510, can use the Data Encryption Standard (DES) for encryption. Almost 30 years after first publishing DES, the National Institute of Standards and Technology (NIST) finally withdrew the standard in 2005, reflecting a long-established consensus that DES is insufficiently secure. By 2008, commercial hardware costing less than USD 15,000 could break DES keys in less than a day on average. DES is long past its sell-by date. Accordingly, this document updates RFC1964, RFC4120, and RFC4121 to deprecate the use of DES in Kerberos. Because RFC1510 (obsoleted by RFC4120) supports only DES, this document reclassifies RFC1510 as Historic. This document also deprecates the weak "export strength" RC4 enctype of RFC4757. "Container Authenticated by Multiple MACs", Simo Sorce, Tom Yu, Thomas Hardjono, 9-Feb-12, Abstract: This document proposes a Kerberos Authorization Data container similar to AD-KDC-ISSUED, but that allows for multiple MACs or signatures on the contained Authorization Data elements. "POSIX Authorization Data", Simo Sorce, Tom Yu, Thomas Hardjono, 9-Feb-12, This document proposes a Kerberos Authorization Data element containing user and group directory information similar to that provided by RFC 2307, typically used by POSIX and POSIX-like systems in the course of login type activities. Layer 2 Virtual Private Networks (l2vpn) ---------------------------------------- "ARP Mediation for IP Interworking of Layer 2 VPN", Himanshu Shah, Eric Rosen, Giles Heron, Vach Kompella, 12-Jan-12, The Virtual Private Wire Service (VPWS) [RFC4664] provides point-to-point connections between pairs of Customer Edge (CE) devices. It does so by binding two Attachment Circuits (each connecting a CE device with a Provider Edge, PE, device) to a pseudowire (connecting the two PEs). In general, the Attachment Circuits must be of the same technology (e.g., both Ethernet, both ATM), and the pseudowire must carry the frames of that technology. However, if it is known that the frames' payload consists solely of IP datagrams, it is possible to provide a point-to-point connection in which the pseudowire connects Attachment Circuits of different technologies. This requires the PEs to perform a function known as "ARP Mediation". ARP Mediation refers to the process of resolving Layer 2 addresses when different resolution protocols are used on either Attachment Circuit. The methods described in this document are applicable even when the CEs run a routing protocol between them, as long as the routing protocol runs over IP. "OAM Procedures for VPWS Interworking", Mustapha Aissaoui, Peter Busschbach, David Allan, Monique Morrow, Thomas Nadeau, 6-Jan-12, This draft proposes OAM procedures for the Ethernet interworking, IP interworking and FR-ATM interworking Virtual Private Wire Service (VPWS). "Multicast in VPLS", Rahul Aggarwal, Yakov Rekhter, Yuji Kamite, Luyuan Fang, 2-Feb-12, This document describes a solution for overcoming a subset of the limitations of existing VPLS multicast solutions. It describes procedures for VPLS multicast that utilize multicast trees in the sevice provider (SP) network. One such multicast tree can be shared between multiple VPLS instances. Procedures by which a single multicast tree in the SP network can be used to carry traffic belonging only to a specified set of one or more IP multicast streams from one or more VPLSes are also described. "Virtual Private Lan Services (VPLS) Management Information Base", Thomas Nadeau, Kiran Koushik, Rohit Mediratta, Virtual Services, 27-Oct-11, This memo defines an experimental portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of Virtual Private LAN services. It needs to be used in conjunction with Pseudo Wire (PW) Management Information Base [RFC5601]. "LDP Extensions for Optimized MAC Address Withdrawal in H-VPLS", Pranjal Dutta, Florin Balus, Olen Stokes, Geraldine Calvignac, 31-Oct-11, [RFC4762] describes a mechanism to remove or unlearn MAC addresses that have been dynamically learned in a VPLS Instance for faster convergence on topology change. The procedure also removes MAC addresses in the VPLS that do not require relearning due to such topology change. This document defines an enhancement to the MAC Address Withdrawal procedure with empty MAC List [RFC4762], which enables a Provider Edge(PE) device to remove only the MAC addresses that need to be relearned. Additional extensions to [RFC4762] MAC Withdrawal procedures are specified to provide optimized MAC flushing for the PBB-VPLS specified in [PBB-VPLS Model]. "Extensions to VPLS PE model for Provider Backbone Bridging", Florin Balus, Matthew Bocci, Mustapha Aissaoui, Ali Sajassi, Nabil Bitar, Raymond Zhang, 4-Oct-11, IEEE 802.1ah standard [IEEE802.1ah], also known as Provider Backbone Bridges (PBB) defines an architecture and bridge protocols for interconnection of multiple Provider Bridge Networks (PBNs). PBB was defined in IEEE as a connectionless technology based on multipoint VLAN tunnels. MSTP is used as the core control plane for loop avoidance and load balancing. As a result, the coverage of the solution is limited by STP scale in the core of large service provider networks. PBB on the other hand can be used to attain better scalability in terms of number of customer MAC addresses and number of service instances that can be supported. Virtual Private LAN Service (VPLS) [RFC4664] provides a framework for extending Ethernet LAN services, using MPLS tunneling capabilities, through a routed MPLS backbone without running (M)STP across the backbone. As a result, VPLS has been deployed on a large scale in service provider networks. This draft discusses extensions to the VPLS PE model required to incorporate desirable PBB components while maintaining the Service Provider fit of the initial model. "Extension to LDP-VPLS for Ethernet Broadcast and Multicast", Simon DeLord, Raymond Key, Frederic JOUNAY, Yuji Kamite, Zhihua Liu, Manuel Paul, Ruediger Kunze, Mach Chen, LiZhong Jin, 5-Dec-11, This document proposes a simple extension to LDP-VPLS to improve bandwidth efficiency for Ethernet broadcast/multicast traffic within a carrier's network. It makes use of unidirectional point-to-multipoint PseudoWires to minimise payload frame duplication on physical links. "Requirements for MEF E-Tree Support in VPLS", Raymond Key, Simon DeLord, Frederic JOUNAY, Lu Huang, Zhihua Liu, Manuel Paul, Ruediger Kunze, Nick Del Regno, Joshua Rogers, 15-Oct-11, This document provides functional requirements for Metro Ethernet Forum (MEF) Ethernet Tree (E-Tree) support in Virtual Private LAN Service (VPLS). It is intended that potential solutions will use these requirements as guidelines. Layer 3 Virtual Private Networks (l3vpn) ---------------------------------------- "Multicast in MPLS/BGP IP VPNs", Rahul Aggarwal, Sarveshwar Bandi, Yiqun Cai, Thomas Morin, Yakov Rekhter, Eric Rosen, IJsbrand Wijnands, Seisho Yasukawa, 28-Jan-10, In order for IP multicast traffic within a BGP/MPLS IP VPN (Virtual Private Network) to travel from one VPN site to another, special protocols and procedures must be implemented by the VPN Service Provider. These protocols and procedures are specified in this document. "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", Rahul Aggarwal, Eric Rosen, Thomas Morin, Yakov Rekhter, 30-Sep-09, This document describes the BGP encodings and procedures for exchanging the information elements required by Multicast in MPLS/BGP IP VPNs, as specified in [MVPN]. "BGP ACCEPT_OWN Community Attribute", James Uttaro, Pradosh Mohapatra, David Smith, Robert Raszuk, John Scudder, 2-Oct-11, Under certain conditions it is desirable for a BGP route reflector to be able to modify the Route Target list of a VPN route that is distributed by the route reflector, enabling the route reflector to control how a route originated within one VRF is imported into other VRFs. This technique works effectively as long as the VRF that exports the route is not on the same PE as the VRF(s) that import the route. However, due to the constraints of the BGP protocol, it does not work if the two are on the same PE. This document describes a modification to the BGP protocol allowing this technique to work when the VRFs are on the same PE, allowing the technique to be used in a standard manner throughout an autonomous system. "OSPFv3 as a PE-CE routing protocol", Padma Pillay-Esnault, Peter Moyer, Jeff Doyle, Emre Ertekin, Michael Lundberg, 10-Jan-12, Many Service Providers (SPs) offer Virtual Private Network (VPN) services to their customers using a technique in which Customer Edge (CE) routers are routing peers of Provider Edge (PE) routers. The Border Gateway Protocol (BGP) is used to distribute the customer's routes across the provider's IP backbone network, and Multiprotocol Label Switching (MPLS) is used to tunnel customer packets across the provider's backbone. Support currently exists for both IPv4 and IPv6 VPNs, however only Open Shortest Path First protocol version 2 (OSPFv2) as PE-CE protocol is specified. This document extends those specifications to support OSPF version 3 (OSPFv3) as a PE-CE routing protocol. The OSPFv3 PE-CE functionality is identical to that of OSPFv2 except for the differences described in this document. "Mandatory Features in a Layer 3 Multicast BGP/MPLS VPN Solution", Thomas Morin, Ben Niven-Jenkins, Yuji Kamite, Raymond Zhang, Nicolai Leymann, Nabil Bitar, 2-Feb-10, More that one set of mechanisms to support multicast in a layer 3 BGP/MPLS VPN has been defined. These are presented in the documents that define them as optional building blocks. To enable interoperability between implementations, this document defines a subset of features that is considered mandatory for a multicast BGP/MPLS VPN implementation. This will help implementers and deployers understand which L3VPN multicast requirements are best satisfied by each option. "IPv6 MVPN Support Using PIM Control Plane and S-PMSI Join Messages", Yiqun Cai, Eric Rosen, IJsbrand Wijnands, 8-Nov-10, The specification for Multicast Virtual Private Networks (MVPN) contains an option that allows the use of PIM as the control protocol between provider edge routers. It also contains an option that allows UDP-based messages, known as S-PMSI ("Selective Provider Multicast Service Interface") Join messages, to be used to bind particular customer multicast flows to particular tunnels through a service provider's network. This document extends the MVPN specification so that these options can be used when the customer multicast flows are IPv6 flows. "IPv4 and IPv6 Infrastructure Addresses in BGP Updates for Multicast VPN", Rahul Aggarwal, Eric Rosen, 6-Jul-11, To provide Multicast VPN (MVPN) service, Provider Edge routers originate BGP Update messages that carry Multicast-VPN ("MCAST-VPN") BGP routes; they also originate unicast VPN routes that carry MVPN- specific attributes. These routes encode addresses from the customer's address space, as well as addresses from the provider's address space. These two address spaces are independent, and the address family (IPv4 or IPv6) of the two spaces may or may not be the same. These routes always contain an "address family" field that specifies whether the customer addresses are IPv4 addresses or whether they are IPv6 addresses. However, there is no field that explicitly specifies the address family of the provider addresses. To ensure interoperability, this document specifies that provider IPv4 addresses are always encoded in these update messages as four- octet addresses, and that the distinction between IPv4 and IPv6 is signaled solely by the length of the address field. Specific cases are explained in detail. This document updates draft-ietf- l3vpn-2547bis-mcast-bgp-08.txt. "MVPN: Using Bidirectional P-Tunnels", Yiqun Cai, Eric Rosen, IJsbrand Wijnands, Arjen Boers, 6-Feb-12, The documents specifying multicast support for BGP/MPLS IP VPNs allow customer multicast data to be transported through a service provider's network through a set multicast tunnels. Such tunnels are advertised by BGP in a BGP attribute known as the "Provider Multicast Service Interface (PMSI) Tunnel Attribute". The base specifications allow the PMSI Tunnel Attribute to advertise bidirectional multicast distribution trees as "PMSI Tunnels"; however, those documents do not provide all the necessary details for using those tunnels. These details are provided in this document. This document also specifies the procedures for assigning customer multicast flows to specific bidirectional PMSI tunnels. "Wildcards in Multicast VPN Auto-Discovery Routes", Eric Rosen, Yakov Rekhter, Ray Qiu, 9-Feb-12, In "Multicast Virtual Private Networks" (MVPNs), customer multicast flows are carried in "tunnels" through a service provider's network. The base specifications for MVPN define BGP multicast VPN "auto-discovery routes", and specify how to use an auto-discovery route to advertise the fact that an individual customer multicast flow is being carried in a particular tunnel. However, those specifications do not provide a way to specify, in a single such route, that multiple customer flows are being carried in a single tunnel. Those specifications also do not provide a way to advertise that a particular tunnel is to be used by default to carry all customer flows, except in the case where that tunnel is joined by all the provider edge routers of the MVPN. This document eliminates these restrictions by specifying the use of "wildcard" elements in the customer flow identifiers. With wildcard elements, a single auto-discovery route can refer to multiple customer flows, or even to all customer flows. Low Extra Delay Background Transport (ledbat) --------------------------------------------- "Low Extra Delay Background Transport (LEDBAT)", Stanislav Shalunov, Greg Hazel, Janardhan Iyengar, Mirja Kuehlewind, 31-Oct-11, LEDBAT is an experimental delay-based congestion control algorithm that attempts to utilize the available bandwidth on an end-to-end path while limiting the consequent increase in queueing delay on the path. LEDBAT uses changes in one-way delay measurements to limit congestion that the flow itself induces in the network. LEDBAT is designed for use by background bulk-transfer applications; it is designed to be no more aggressive than TCP congestion control and to yield in the presence of any competing flows when latency builds, thus limiting interference with the network performance of the competing flows. Locator/ID Separation Protocol (lisp) ------------------------------------- "Locator/ID Separation Protocol (LISP)", Dino Farinacci, Vince Fuller, Dave Meyer, Darrel Lewis, 7-Feb-12, This draft describes a network layer based protocol that enables separation of IP addresses into two new numbering spaces: Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). No changes are required to either host protocol stacks or to the "core" of the Internet infrastructure. LISP can be incrementally deployed, without a "flag day", and offers traffic engineering, multi-homing, and mobility benefits to early adopters, even when there are relatively few LISP-capable sites. Design and development of LISP was largely motivated by the problem statement produced by the October 2006 IAB Routing and Addressing Workshop. "LISP Alternative Topology (LISP+ALT)", Vince Fuller, Dino Farinacci, Dave Meyer, Darrel Lewis, 6-Dec-11, This document describes a simple distributed index system to be used by a Locator/ID Separation Protocol (LISP) Ingress Tunnel Router (ITR) or Map Resolver (MR) to find the Egress Tunnel Router (ETR) which holds the mapping information for a particular Endpoint Identifier (EID). The MR can then query that ETR to obtain the actual mapping information, which consists of a list of Routing Locators (RLOCs) for the EID. Termed the Alternative Logical Topology (ALT), the index is built as an overlay network on the public Internet using the Border Gateway Protocol (BGP) and the Generic Routing Encapsulation (GRE). "Interworking LISP with IPv4 and IPv6", Darrel Lewis, Dave Meyer, Dino Farinacci, Vince Fuller, 9-Feb-12, This document describes techniques for allowing sites running the Locator/ID Separation Protocol (LISP) to interoperate with Internet sites (which may be using either IPv4, IPv6, or both) but which are not running LISP. A fundamental property of LISP speaking sites is that they use Endpoint Identifiers (EIDs), rather than traditional IP addresses, in the source and destination fields of all traffic they emit or receive. While EIDs are syntactically identical to IPv4 or IPv6 addresses, normally routes to them are not carried in the global routing system so an interoperability mechanism is needed for non- LISP-speaking sites to exchange traffic with LISP-speaking sites. This document introduces three such mechanisms. The first uses a new network element, the LISP Proxy Ingress Tunnel Routers (PITR) (Section 5) to act as a intermediate LISP Ingress Tunnel Router (ITR) for non-LISP-speaking hosts. Second the document adds Network Address Translation (NAT) functionality to LISP Ingress and LISP Egress Tunnel Routers (xTRs) to substitute routable IP addresses for non-routable EIDs. Finally, this document introduces a Proxy Egress Tunnel Router (PETR) to handle cases where a LISP ITR cannot send packets to non-LISP sites without encapsulation. "LISP Map Server Interface", Vince Fuller, Dino Farinacci, 11-Jan-12, This draft describes the Maping Service for the Locator Identifier Separation Protocol (LISP), implemented by two new types of LISP- speaking devices, the LISP Map Resolver and LISP Map Server, that provides a simplified "front end" to for one or more Endpoint ID to Routing Locator mapping databases. By using this service interface and communicating with Map Resolvers and Map Servers, LISP Ingress Tunnel Routers and Egress Tunnel Routers, are not dependent on the details of mapping database systems, which facilitates experimentation with different database designs. Since these devices implement the "edge" of the LISP infrastructure, connect directly to LISP-capable Internet end sites, and comprise the bulk of LISP-speaking devices, reducing their implementation and operational complexity should also reduce the overall cost and effort of deploying LISP. "LISP for Multicast Environments", Dino Farinacci, Dave Meyer, John Zwiebel, Stig Venaas, 8-Feb-12, This draft describes how inter-domain multicast routing will function in an environment where Locator/ID Separation is deployed using the LISP architecture. "LISP Internet Groper (LIG)", Dino Farinacci, Dave Meyer, 9-Sep-11, A simple tool called the LISP Internet Groper or 'lig' can be used to query the LISP mapping database. This draft describes how it works. "LISP Map-Versioning", Luigi Iannone, Damien Saucez, Olivier Bonaventure, 19-Jan-12, This document describes the LISP (Locator/ID Separation Protocol) Map-Versioning mechanism, which provides in-packet information about Endpoint-ID to Routing Locator (EID-to-RLOC) mappings used to encapsulate LISP data packets. The proposed approach is based on associating a version number to EID-to-RLOC mappings and transport such a version number in the LISP specific header of LISP- encapsulated packets. LISP Map-Versioning is particularly useful to inform communicating Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs) about modifications of the mappings used to encapsulate packets. The mechanism is transparent to implementations not supporting this feature, since in the LISP-specific header and in the Map Records, bits used for Map-Versioning can be safely ignored by ITRs and ETRs that do not support the mechanism. "LISP MIB", Gregg Schudel, Amit Jain, Victor Moreno, 29-Nov-11, This document defines managed objects for the Locator/ID Separation Protocol (LISP). These objects provide information useful for monitoring LISP devices, including basic configuration information, LISP status, and operational statistics. "LISP Network Element Deployment Considerations", Lorand Jakab, Albert Cabellos-Aparicio, Florin Coras, Jordi Domingo-Pascual, Darrel Lewis, 31-Oct-11, This document discusses the different scenarios for the deployment of the new network elements introduced by the Locator/Identifier Separation Protocol (LISP). "LISP-Security (LISP-SEC)", Fabio Maino, Vina Ermagan, Albert Cabellos-Aparicio, Damien Saucez, Olivier Bonaventure, 31-Dec-11, This memo specifies LISP-SEC, a set of security mechanisms that provide origin authentication, integrity and anti-replay protection to LISP's EID-to-RLOC mapping data conveyed via mapping lookup process. LISP-SEC also enables verification of authorization on EID- prefix claims in Map-Reply messages. "LISP EID Block", Luigi Iannone, Darrel Lewis, Dave Meyer, Vince Fuller, 31-Oct-11, This is a direction to IANA to allocate a /16 IPv6 prefix for use with the Locator/ID Separation Protocol (LISP). The prefix will be used by sites deploying LISP as EID (Endpoint IDentifier) addressing space for local intra-domain routing and global endpoint identification. Mobile Ad-hoc Networks (manet) ------------------------------ "Simplified Multicast Forwarding", Joseph Macker, 27-Jan-12, This document describes a Simplified Multicast Forwarding (SMF) mechanism that provides basic Internet Protocol (IP) multicast forwarding suitable for limited wireless mesh and mobile ad hoc network (MANET) use. It is mainly applicable in situations where efficient flooding represents an acceptable engineering design trade- off. It defines techniques for multicast duplicate packet detection (DPD), to be applied in the forwarding process, for both IPv4 and IPv6 protocol use. This document also specifies optional mechanisms for using reduced relay sets to achieve more efficient multicast data distribution within a mesh topology as compared to classic flooding. Interactions with other protocols, such as use of information provided by concurrently running unicast routing protocols, or interaction with other multicast protocols, as well as multiple deployment approaches are also described. Distributed algorithms for selecting reduced relay sets and related discussion are provided in the appendices. Basic issues relating to the operation of multicast MANET border routers are discussed, but ongoing work remains in this area, and is beyond the scope of this document. "The Optimized Link State Routing Protocol version 2", Thomas Clausen, Christopher Dearlove, Philippe Jacquet, 14-Oct-11, This document describes version 2 of the Optimized Link State Routing (OLSRv2) protocol for Mobile Ad hoc NETworks (MANETs). "Definition of Managed Objects for the Manet Simplified Multicast Framework Relay Set Process", Robert Cole, Joseph Macker, Brian Adamson, Sean Harnedy, 2-Oct-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 describes objects for configuring aspects of the Simplified Multicast Forwarding (SMF) process for Mobile Ad-Hoc Networks (MANETs). The SMF-MIB also reports state information, performance metrics, and notifications. In addition to configuration, the additional state and performance information is useful to operators troubleshooting multicast forwarding problems. "Definition of Managed Objects for the Neighborhood Discovery Protocol", Ulrich Herberg, Robert Cole, Ian Chakeres, 6-Jan-12, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring parameters of the Neighborhood Discovery Protocol (NHDP) process on a router. The MIB defined in this memo, denoted NHDP-MIB, also reports state, performance information and notifications. This additional state and performance information is useful to troubleshoot problems and performance issues during neighbor discovery. "MANET Cryptographical Signature TLV Definition", Ulrich Herberg, Thomas Clausen, 31-Jan-12, This document describes general and flexible TLVs (type-length-value structure) for representing cryptographic signatures as well as timestamps, using the generalized MANET packet/message format defined in RFC 5444. It defines two Packet TLVs, two Message TLVs, and two Address Block TLVs, for affixing cryptographic signatures and timestamps to a packet, message and address, respectively. "Definition of Managed Objects for Performance Reporting", Robert Cole, Joseph Macker, Andy Bierman, 31-Jan-12, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring autonomous report generation on any device that supports MIBs containing counter and gauge objects for performance monitoring. This allows a management station to instruct a device to build off-line reports to be collected asynchronously by the management station. Further, this REPORT-SAMPLED-MIB can be configured in a proxy configuration where the report generation is performed on a device in close network proximity to the device containing the referenced counter objects. Hence, this capability allows network operators to reduce the SNMP polling traffic burden on Mobile Ad-Hoc and Disruption Tolerant Networks which is typical of SNMP performance management applications. "Dynamic Link Exchange Protocol (DLEP)", Stan Ratliff, Cisco Cisco, Greg Harrison, Darryl Satterwhite, Shawn Jury, 6-Feb-12, When routing devices rely on modems to effect communications over wireless links, they need timely and accurate knowledge of the characteristics of the link (speed, state, etc.) in order to make forwarding decisions. In mobile or other environments where these characteristics change frequently, manual configurations or the inference of state through routing or transport protocols does not allow the router to make the best decisions. A bidirectional, event- driven communication channel between the router and the modem is necessary. Messaging Abuse Reporting Format (marf) --------------------------------------- "Extensions to DKIM for Failure Reporting", Murray Kucherawy, 5-Feb-12, This memo presents extensions to the DomainKeys Identified Mail (DKIM) specification to allow for detailed reporting of message authentication failures in an on-demand fashion. "Redaction of Potentially Sensitive Data from Mail Abuse Reports", J.D. Falk, M. Kucherawy, 27-Jan-12, Email messages often contain information that might be considered private or sensitive, per either regulation or social norms. When such a message becomes the subject of a report intended to be shared with other entities, the report generator may wish to redact or elide the sensitive portions of the message. This memo suggests one method for doing so effectively. "Authentication Failure Reporting using the Abuse Report Format", Hilda Fontana, 18-Jan-12, This memo registers an extension report type to the Abuse Reporting Format (ARF), affecting multiple registries, for use in generating receipt-time reports about messages that fail one or more email message authentication checks. "SPF Authentication Failure Reporting using the Abuse Report Format", Scott Kitterman, 8-Feb-12, This memo presents extensions to the Abuse Reporting Format (ARF), and Sender Policy Framework (SPF) specifications to allow for detailed reporting of message authentication failures in an on-demand fashion. "Creation and Use of Email Feedback Reports: An Applicability Statement for the Abuse Reporting Format (ARF)", J.D. Falk, M. Kucherawy, 10-Feb-12, RFC 5965 defines an extensible, machine-readable format intended for mail operators to report feedback about received email to other parties. This document describes common methods for utilizing this format for reporting both abuse and authentication failure events. Mailbox Providers of any size, mail sending entities, and end users can use these methods as a basis to create procedures that best suit them. MBONE Deployment (mboned) ------------------------- "Multicast Addresses for Documentation", Stig Venaas, Rishabh Parekh, Gunter Van de Velde, Tim Chown, Marshall Eubanks, 8-Feb-12, This document discusses which multicast addresses should be used for documentation purposes and reserves multicast addresses for such use. Some multicast addresses are derived from AS numbers or unicast addresses. This document also explains how these can be used for documentation purposes. "IPv4-Embedded IPv6 Multicast Address Format", Mohamed Boucadair, Jacni Qin, Yiu Lee, Stig Venaas, Xing Li, Mingwei Xu, 6-Feb-12, This document specifies an extension to the IPv6 multicast addressing architecture to be used in the context of IPv4-IPv6 interconnection. In particular, this document defines an address format for IPv4- embedded IPv6 multicast addresses. This address format can be used for IPv4-IPv6 translation or encapsulation schemes. This document updates RFC4291. Media Server Control (mediactrl) -------------------------------- "A Mixer Control Package for the Media Control Channel Framework", Scott McGlashan, Tim Melanchuk, Chris Boulton, 6-Jan-11, This document defines a Media Control Channel Framework Package for managing mixers for media conferences and connections. The package defines request elements for managing conference mixers, managing mixers between conferences and/or connections, as well as associated responses and notifications. The package also defines elements for auditing package capabilities and mixers. "Media Control Channel Framework (CFW) Call Flow Examples", Alessandro Amirante, Tobia Castaldi, Lorenzo Miniero, Simon Romano, 9-Jan-12, This document provides a list of typical Media Control Channel Framework [RFC6230] call flows. It aims at being a simple guide to the use of the interface between Application Servers and MEDIACTRL- based Media Servers, as well as a base reference documentation for both implementors and protocol researchers. "Media Resource Brokering", Chris Boulton, Lorenzo Miniero, Gary Munson, 9-Jan-12, The MediaCtrl work group in the IETF has proposed an architecture for controlling media services. The Session Initiation Protocol (SIP) is used as the signalling protocol which provides many inherent capabilities for message routing. In addition to such signalling properties, a need exists for intelligent, application level media service selection based on non-static signalling properties. This is especially true when considered in conjunction with deployment architectures that include 1:M and M:N combinations of Application Servers and Media Servers. This document introduces a Media Resource Broker (MRB) entity which manages the availability of Media Servers and the media resource demands of Application Servers. The document includes potential deployment options for an MRB and appropriate interfaces to Application Servers and Media Servers. Multiple Interfaces (mif) ------------------------- "DHCPv6 Route Options", Wojciech Dec, Tomasz Mrugalski, Tao Sun, Behcet Sarikaya, 10-Sep-11, This document describes DHCPv6 Route Options for provisioning IPv6 routes on DHCPv6 client nodes. This is expected to improve the ability of an operator to configure and influence a nodes' ability to pick an appropriate route to a destination when this node is multi- homed and where other means of route configuration may be impractical. "Improved DNS Server Selection for Multi-Interfaced Nodes", Teemu Savolainen, Jun-ya Kato, Ted Lemon, 25-Oct-11, A multi-interfaced node is connected to multiple networks, some of which may be utilizing private DNS namespaces. A node commonly receives DNS server configuration information from all connected networks. Some of the DNS servers may have information about namespaces other servers do not have. When a multi-interfaced node needs to utilize DNS, the node has to choose which of the servers to contact to. This document describes DHCPv4 and DHCPv6 options that can be used to configure nodes with information required to perform informed DNS server selection decisions. Managed Incident Lightweight Exchange (mile) -------------------------------------------- "Real-time Inter-network Defense (RID)", Kathleen Moriarty, 31-Jan-12, Security incidents, such as system compromises, worms, viruses, phishing incidents, and denial of service, typically result in the loss of service, data, and resources both human and system. Service providers and Computer Security Incident Response Teams need to be equipped and ready to assist in communicating and tracing security incidents with tools and procedures in place before the occurrence of an attack. Real-time Inter-network Defense (RID) outlines a proactive inter-network communication method to facilitate sharing incident handling data while integrating existing detection, tracing, source identification, and mitigation mechanisms for a complete incident handling solution. Combining these capabilities in a communication system provides a way to achieve higher security levels on networks. Policy guidelines for handling incidents are recommended and can be agreed upon by a consortium using the security recommendations and considerations. This document obsoletes RFC6045. "Transport of Real-time Inter-network Defense (RID) Messages over HTTP/ TLS", Brian Trammell, 25-Jan-12, The Incident Object Description Exchange Format (IODEF) defines a common XML format for document exchange, and Realtime Internetwork Defense (RID) defines extensions to IODEF intended for the cooperative handling of security incidents within consortia of network operators and enterprises. This document specifies a application-layer protocol for RID based upon the passing of RID messages over HTTP/TLS. "Guidelines for Extensions to IODEF for Managed Incident Lightweight Exchange", Brian Trammell, 16-Nov-11, This document provides guidelines for extensions to IODEF [RFC5070] for lightweight exchange of incident management data, and contains a template for Internet-Drafts describing those extensions, in order to ease the work and improve the quality of extension descriptions. It also specifies additional Expert Review of XML Schemas used to describe these extensions. "IODEF-extension to support structured cybersecurity information", Takeshi Takahashi, Kent Landfield, Thomas Millar, Youki Kadobayashi, 31-Jan-12, This document extends the Incident Object Description Exchange Format (IODEF) defined in RFC 5070 [RFC5070] to facilitate enriched cybersecurity information exchange among cybersecurity entities by embedding structured information formatted by specifications, including CAPEC[TM] [CAPEC], CEE[TM] [CEE], CPE[TM] [CPE], CVE(R) [CVE], CVRF [CVRF], CVSS [CVSS], CWE[TM] [CWE], CWSS[TM] [CWSS], OCIL [OCIL], OVAL(R) [OVAL], and XCCDF [XCCDF]. Mobility for IPv4 (mip4) ------------------------ "Generic Notification Message for Mobile IPv4", Hui Deng, Henrik Levkowetz, Vijay Devarapalli, Sri Gundavelli, Brian Haley, 25-Oct-10, This document specifies protocol enhancements that allow Mobile IPv4 entities to send and receive explicit notification messages using a Mobile IPv4 message type designed for this purpose. "Dynamic Prefix Allocation for NEMOv4", George Tsirtsis, Vincent Park, Kent Leung, 28-Apr-11, The base NEMOv4 specification defines extensions to Mobile IPv4 for mobile networks. This specification defines a dynamic prefix allocation mechanism. "Home Agent assisted Route Optimization between Mobile IPv4 Networks", Antti Makela, Jouni Korhonen, 16-Nov-11, This document describes a Home Agent assisted Route Optimization functionality to IPv4 Network Mobility Protocol. The function is designed to facilitate optimal routing in cases where all nodes are connected to a single Home Agent, thus the use case is Route Optimization within single organization or similar entity. The functionality adds the possibility to discover eligible peer nodes based on information received from Home Agent, Network Prefixes they represent, and how to establish a direct tunnel between such nodes. "Flow Binding Support for Mobile IPv4", Sri Gundavelli, Kent Leung, George Tsirtsis, Hesham Soliman, Alexandru Petrescu, 16-Aug-11, This specification defines extensions to Mobile IPv4 protocol for allowing a mobile node with multiple interfaces to register a care-of address for each of its network interfaces and to simultaneously establish multiple Mobile IP tunnels with its home agent. This essentially allows the mobile node to utilize all the available network interfaces and build an higher aggregated data pipe with the home agent for its home address traffic. Furthermore, these extensions also allow the mobile node and the home agent to negotiate flow policies for binding individual traffic flows with the registered care-of addresses. Mobility for IPv6 (mip6) ------------------------ "MIP6-bootstrapping for the Integrated Scenario", Kuntal Chowdhury, Alper Yegin, 21-Apr-08, Mobile IPv6 bootstrapping can be categorized into two primary scenarios, the split scenario and the integrated scenario. In the split scenario, the mobile node's mobility service is authorized by a different service authorizer than the network access authorizer. In the integrated scenario, the mobile node's mobility service is authorized by the same service authorizer as the network access service authorizer. This document defines a method for home agent information discovery for the integrated scenario. "DHCP Options for Home Information Discovery in MIPv6", Hee-Jin Jang, Alper Yegin, Kuntal Chowdhury, JinHyeock Choi, 22-May-08, This draft defines a DHCP-based scheme to enable dynamic discovery of Mobile IPv6 home network information. New DHCP options are defined which allow a mobile node to request the home agent IP address, FQDN, or home network prefix and obtain it via the DHCP response. Multiparty Multimedia Session Control (mmusic) ---------------------------------------------- "Real Time Streaming Protocol 2.0 (RTSP)", Henning Schulzrinne, Anup Rao, Rob Lanphier, Magnus Westerlund, Martin Stiemerling, 28-Oct-11, This memorandum defines RTSP version 2.0 which obsoletes RTSP version 1.0 which is defined in RFC 2326. The Real Time Streaming Protocol, or RTSP, is an application-level protocol for setup and control of the delivery of data with real-time properties. RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and video. Sources of data can include both live data feeds and stored clips. This protocol is intended to control multiple data delivery sessions, provide a means for choosing delivery channels such as UDP, multicast UDP and TCP, and provide a means for choosing delivery mechanisms based upon RTP (RFC 3550). "A Network Address Translator (NAT) Traversal mechanism for media controlled by Real-Time Streaming Protocol (RTSP)", Jeff Goldberg, Magnus Westerlund, Thomas Zeng, 27-Oct-11, This document defines a solution for Network Address Translation (NAT) traversal for datagram based media streams setup and controlled with Real-time Streaming Protocol version 2 (RTSP 2.0). It uses Interactive Connectivity Establishment (ICE) adapted to use RTSP as a signalling channel, defining the necessary extra RTSP extensions and procedures. "An Extension to the Session Description Protocol (SDP) for Media Loopback", C Sivachelvan, Nagarjuna Venna, Paul Jones, Nathan Stratton, Arjun Roychowdhury, Kaynam Hedayat, 15-Sep-11, The wide deployment of Voice over IP (VoIP), Real-time Text and Video over IP services has introduced new challenges in managing and maintaining voice/real-time Text/video quality, reliability, and overall performance. In particular, media delivery is an area that needs attention. One method of meeting these challenges is monitoring the media delivery performance by looping media back to the transmitter. This is typically referred to as "active monitoring" of services. Media loopback is especially popular in ensuring the quality of transport to the edge of a given VoIP, Real-time Text or Video over IP service. Today in networks that deliver real-time media, short of running 'ping' and 'traceroute' to the edge, service providers are left without the necessary tools to actively monitor, manage, and diagnose quality issues with their service. The extension defined herein adds new SDP media attributes which enables establishment of media sessions where the media is looped back to the transmitter. Such media sessions will serve as monitoring and troubleshooting tools by providing the means for measurement of more advanced VoIP, Real-time Text and Video over IP performance metrics. "TCP Candidates with Interactive Connectivity Establishment (ICE)", Jonathan Rosenberg, Ari Keranen, Bruce Lowekamp, Adam Roach, 15-Nov-11, Interactive Connectivity Establishment (ICE) defines a mechanism for NAT traversal for multimedia communication protocols based on the offer/answer model of session negotiation. ICE works by providing a set of candidate transport addresses for each media stream, which are then validated with peer-to-peer connectivity checks based on Session Traversal Utilities for NAT (STUN). ICE provides a general framework for describing candidates, but only defines UDP-based media streams. This specification extends ICE to TCP-based media, including the ability to offer a mix of TCP and UDP-based candidates for a single stream. "SDP Media Mapabilities Negotiation", Robert Gilman, Roni Even, Flemming Andreasen, 31-Oct-11, Session Description Protocol (SDP) capability negotiation provides a general framework for indicating and negotiating capabilities in SDP. The base framework defines only capabilities for negotiating transport protocols and attributes. In this document, we extend the framework by defining media capabilities that can be used to negotiate media types and their associated parameters. "The Evaluation of Different Network Addres Translator (NAT) Traversal Techniques for Media Controlled by Real-time Streaming Protocol (RTSP)", Magnus Westerlund, Thomas Zeng, 27-Oct-11, This document describes several Network Address Translator (NAT) traversal techniques that was considered to be used by Real-time Streaming Protocol (RTSP). Each technique includes a description on how it would be used, the security implications of using it and any other deployment considerations it has. There are also disussions on how NAT traversal techniques relates to firewalls and how each technique can be applied in different use cases. These findings where used when selecting the NAT traversal for RTSP 2.0 standardized in the MMUSIC WG. "SDP: Session Description Protocol", Mark Handley, Van Jacobson, Colin Perkins, Ali Begen, 24-Oct-11, This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. "Analysis of Middlebox Interactions for Signaling Protocol Communication along the Media Path", Brian Stucker, Hannes Tschofenig, Gonzalo Salgueiro, 29-Jan-12, Middleboxes are defined as any intermediary box performing functions apart from normal, standard functions of an IP router on the data path between a source host and destination host. Two such functions are network address translation and firewalling. When Application Layer Gateways, such as SIP entities, interact with NATs and firewalls, as described in the MIDCOM architecture, then problems may occur in the transport of media traffic when signaling protocol interaction takes place along the media path, as it is the case for recent key exchange proposals (such as DTLS-SRTP). This document highlights problems that may arise. Unfortunately, it is difficult for the end points to detect or predict problematic behavior and to determine whether the media path is reliably available for packet exchange. This document aims to summarize the various sources and effects of NAT and firewall control, the reasons that they exist, and possible means of improving their behavior to allow protocols that rely upon signaling along the media path to operate effectively. "Session Description Protocol (SDP) Extension For Setting Up Audio and Video Media Streams Over Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN)", Miguel Garcia-Martin, Simo Veikkolainen, 31-Oct-11, This memo describes use cases, requirements, and protocol extensions for using the Session Description Protocol (SDP) Offer/Answer model for establishing audio and video media streams over circuit-switched bearers in the Public Switched Telephone Network (PSTN). "The Session Description Protocol (SDP) 'trafficclass' Attribute", James Polk, Subha Dhesikan, Paul Jones, 24-Oct-11, This document proposes a new Session Description Protocol (SDP) attribute to identify the traffic class a session is requesting in its offer/answer exchange. "SDP attribute to signal parallax", Bert Greevenbosch, Hui Yu, 21-Nov-11, This document introduces a "ParallaxInfo" attribute in SDP. This attribute can be used in stereoscopic applications, to signal the depth positioning of 2D media data within the 3D space. Note Discussion and suggestions for improvement are requested, and should be sent to mmusic@ietf.org. "Signal 3D format", Bert Greevenbosch, Hui Yu, 21-Nov-11, This document introduces the SDP attribute "3dFormat", which provides format description of stereoscopic 3D video. In addition, the grouping mechanism for SDP is extended to cater for stereoscopic 3D video. Note Discussion and suggestions for improvement are requested, and should be sent to mmusic@ietf.org. Message Organization (morg) --------------------------- "IMAP4 Multimailbox SEARCH Extension", Barry Leiba, Alexey Melnikov, 7-Mar-11, The IMAP4 specification allows the searching only of the selected mailbox. A user often wants to search multiple mailboxes, and a client that wishes to support this must issue a series of SELECT and SEARCH commands, waiting for each to complete before moving on to the next. This extension allows a client to search multiple mailboxes with one command, limiting the round-trips and waiting for various searches to complete, and not requiring disruption of the currently selected mailbox. This also uses MAILBOX and TAG fields in ESEARCH responses, allowing a client to pipeline the searches if it chooses. Multiprotocol Label Switching (mpls) ------------------------------------ "Non Penultimate Hop Popping Behavior and out-of-band mapping for RSVP-TE Label Switched Paths", Zafar Ali, George Swallow, Rahul Aggarwal, 17-Aug-11, There are many deployment scenarios which require Egress Label Switching Router (LSR) to receive binding of the Resource ReserVation Protocol Traffic Engineered (RSVP-TE) Label Switched Path (LSP) to an application, and payload identification, using some "out-of-band" (OOB) mechanism. This document defines protocol mechanisms to address this requirement. The procedures described in this document are equally applicable for point-to- point (P2P) and point-to-multipoint (P2MP) LSPs. "A Thesaurus for the Terminology used in Multiprotocol Label Switching Transport Profile (MPLS-TP) drafts/RFCs and ITU-T's Transport Network Recommendations.", Huub Helvoort, Loa Andersson, Nurit Sprecher, 17-Jan-12, MPLS-TP is based on a profile of the MPLS and PW procedures as specified in the MPLS-TE and (MS-)PW architectures developed by the IETF. The ITU-T has specified a Transport Network architecture. This document provides a thesaurus for the interpretation of MPLS-TP terminology within the context of the ITU-T Transport Network recommendations. It is important to note that MPLS-TP is applicable in a wider set of contexts than just Transport Networks. The definitions presented in this document do not provide exclusive nor complete interpretations of MPLS-TP concepts. This document simply allows the MPLS-TP terms to be applied within the Transport Network context. "An Overview of the OAM Tool Set for MPLS based Transport Networks", Nurit Sprecher, Luyuan Fang, 21-Dec-11, This document provides an overview of the OAM toolset for MPLS based Transport Networks. The toolset consists of a comprehensive set of fault management and performance monitoring capabilities (operating in the data-plane) which are appropriate for transport networks as required in RFC 5860 and support the network and services at different nested levels. This overview includes a brief recap of MPLS-TP OAM requirements and functions, and of generic mechanisms created in the MPLS data plane to allow the OAM packets run in-band and share their fate with data packets. The protocol definitions for each of the MPLS-TP OAM tools are defined in separate documents (RFCs or Working Group drafts) which are referenced by this document. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications Union Telecommunications Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. "Multipoint LDP in-band signaling for Point-to-Multipoint and Multipoint- to-Multipoint Label Switched Paths", IJsbrand Wijnands, Toerless Eckert, Nicolai Leymann, Maria Napierala, 1-Dec-11, Consider an IP multicast tree, constructed by Protocol Independent Multicast (PIM), needs to pass through an MPLS domain in which Multipoint LDP (mLDP) Point-to-Multipoint and/or Multipoint-to- Multipoint Labels Switched Paths (LSPs) can be created. The part of the IP multicast tree that traverses the MPLS domain can be instantiated as a multipoint LSP. When a PIM Join message is received at the border of the MPLS domain, information from that message is encoded into mLDP messages. When the mLDP messages reach the border of the next IP domain, the encoded information is used to generate PIM messages that can be sent through the IP domain. The result is an IP multicast tree consisting of a set of IP multicast sub-trees that are spliced together with a multipoint LSP. "Return Path Specified LSP Ping", Mach Chen, Wei Cao, Ning So, Frederic JOUNAY, Simon Delord, 30-Oct-11, This document defines extensions to the failure-detection protocol for Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) known as "LSP Ping" that allow selection of the LSP to use for the echo reply return path. Enforcing a specific return path can be used to verify bidirectional connectivity and also increase LSP ping robustness. It may also be used by Bidirectional Forwarding Detection (BFD) for MPLS bootstrap signaling thereby making BFD for MPLS more robust. "Using Multipoint LDP when the Backbone has no Route to the Root", IJsbrand Wijnands, Eric Rosen, Maria Napierala, Nicolai Leymann, 25-Jul-11, The control protocol used for constructing Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths ("MP LSPs") contains a field that identifies the address of a "root node". Intermediate nodes are expected to be able to look up that address in their routing tables. However, if the route to the root node is a BGP route, and the intermediate nodes are part of a BGP-free core, this is not possible. This document specifies procedures which enable a MP LSP to be constructed through a BGP-free core. In these procedures, the root node address is temporarily replaced by an address that is known to the intermediate nodes and is on the path to the true root node. "Updates to LDP for IPv6", Rajiv Asati, Vishwas Manral, Rajiv Papneja, Carlos Pignataro, 23-Jan-12, The Label Distribution Protocol (LDP) specification defines procedures to exchange label bindings over either IPv4, IPv6 or both networks. This document corrects and clarifies the LDP behavior when IPv6 network is used (with or without IPv4). This document updates RFC 5036. "Multiprotocol Label Switching Transport Profile (MPLS-TP) MIB-based Management Overview", Daniel King, Venkatesan Mahalingam, 31-Jan-12, A range of Management Information Base (MIB) modules has been developed to help model and manage the various aspects of Multiprotocol Label Switching (MPLS) networks. These MIB modules are defined in separate documents that focus on the specific areas of responsibility of the modules that they describe. The MPLS Transport Profile (MPLS-TP) is a profile of MPLS functionality specific to the construction of packet-switched transport networks. This document describes the MIB-based architecture for MPLS-TP, and indicates the interrelationships between different existing MIB modules that can be leveraged for MPLS-TP network management and identifies areas where additional MIB modules are required. "Configuration of Pro-Active Operations, Administration, and Maintenance (OAM) Functions for MPLS-based Transport Networks using LSP Ping", Elisa Bellagamba, Loa Andersson, Pontus Skoldstrom, Dave Ward, John Drake, 31-Oct-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 are carried by the LSP Ping protocol This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network. "Indication of Client Failure in MPLS-TP", Jia He, Han Li, Elisa Bellagamba, 13-Sep-11, This document describes a Multi-Protocol Label Switching Transport Profile (MPLS-TP) Operations, Administration and Maintenance (OAM) protocol to propagate a client failure indication across an MPLS-TP network in the case that propagation of failure status in the client layer is not supported as required in [RFC5860]. "MPLS-TP Security Framework", Luyuan Fang, Ben Niven-Jenkins, Scott Mansfield, Richard Graveman, 31-Oct-11, This document provides a security framework for Multiprotocol Label Switching Transport Profile (MPLS-TP). Extended from MPLS technologies, MPLS-TP introduces new OAM capabilities, a transport- oriented path protection mechanism, and strong emphasis on static provisioning supported by network management systems. This document addresses the security aspects that are relevant in the context of MPLS-TP specifically. It describes the security requirements for MPLS-TP and potential security threats and mitigation procedures for MPLS-TP networks and MPLS-TP inter-connection to MPLS and GMPLS networks. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network. This Informational Internet-Draft is aimed at achieving IETF Consensus before publication as an RFC and will be subject to an IETF Last Call. [RFC Editor, please remove this note before publication as an RFC and insert the correct Streams Boilerplate to indicate that the published RFC has IETF Consensus.] "The Use of Entropy Labels in MPLS Forwarding", Kireeti Kompella, John Drake, Shane Amante, Wim Henderickx, Lucy Yong, 31-Oct-11, Load balancing is a powerful tool for engineering traffic across a network. This memo suggests ways of improving load balancing across MPLS networks using the concept of "entropy labels". It defines the concept, describes why entropy labels are useful, enumerates properties of entropy labels that allow maximal benefit, and shows how they can be signaled and used for various applications. "The Generalized TTL Security Mechanism (GTSM) for Label Distribution Protocol (LDP)", Carlos Pignataro, Rajiv Asati, 14-Nov-11, The Generalized TTL Security Mechanism (GTSM) describes a generalized use of a packets Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to verify that the packet was sourced by a node on a connected link, thereby protecting the router's IP control-plane from CPU utilization based attacks. This technique improves security and is used by many protocols. This document defines the GTSM use for Label Distribution Protocol (LDP). This specification uses a bit reserved in RFC 5036 and therefore updates RFC 5036. "Inter-Area P2MP Segmented LSPs", Yakov Rekhter, Rahul Aggarwal, 7-Dec-11, This document describes procedures for building inter-area point-to- multipoint (P2MP) segmented service LSPs by partitioning such LSPs into intra-area segments and using BGP as the inter-area routing and label distribution protocol. Within each IGP area the intra-area segments are either carried over intra-area P2MP LSPs, using P2MP LSP hierarchy, or instantiated using ingress replication. The intra-area P2MP LSPs may be signaled using P2MP RSVP-TE or P2MP mLDP. If ingress replication is used within an IGP area, then MP2P LDP LSPs or P2P RSVP-TE LSPs may be used in the IGP area. The applications/services that use such inter-area service LSPs may be BGP MVPN, VPLS multicast or IP multicast over MPLS. "MPLS-TP Traffic Engineering (TE) Management Information Base (MIB)", Venkatesan Mahalingam, Kannan Sampath, Sam Aldrin, Thomas Nadeau, 15-Dec-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 describes managed objects of Tunnels, Identifiers, Label Switch Router and Textual conventions for Multiprotocol Label Switching (MPLS) based Transport Profile (TP). "Definition of Time-to-Live TLV for LSP-Ping Mechanisms", Siva Sivabalan, Sami Boutros, George Swallow, Shaleen Saxena, Vishwas Manral, Sam Aldrin, 28-Oct-11, LSP-Ping is a widely deployed Operation, Administration, and Maintenance (OAM) mechanism in MPLS networks. However, in the present form, this mechanism is inadequate to verify connectivity of a segment of a Multi-Segment PseudoWire (MS-PW) from any node on the path of the MS-PW. This document defines a TLV to address this shortcoming. "MPLS-TP Identifiers Following ITU-T Conventions", Rolf Winter, Eric Gray, Huub Helvoort, Malcolm Betts, 31-Oct-11, This document specifies an extension to the identifiers to be used in the Transport Profile of Multiprotocol Label Switching (MPLS-TP). Identifiers that follow IP/MPLS conventions have already been defined. This memo augments that set of identifiers for MPLS-TP management and OAM functions to include identifier information in a format typically used by the ITU-T. "LDP Extensions for Multi Topology Routing", Quintin Zhao, Luyuang Fang, Chao Zhou, Lianyuan Li, Ning So, Raveendra Torvi, 21-Nov-11, Multi-Topology (MT) routing is supported in IP through extension of IGP protocols, such as OSPF and IS-IS. It would be advantageous to extend Multiprotocol Label Switching (MPLS), using Label Distribution Protocol (LDP), to support multiple topologies. These LDP extensions, known as Multiple Topology Label Distribution Protocol (MT LDP), would allow the configuration of multiple topologies within an MPLS LDP enabled network. This document describes the protocol extensions required to extend the existing MPLS LDP signalling protocol for creating and maintaining LSPs in an MT environment. "Applicability of MPLS-TP Linear Protection for Ring Topologies", Yaacov Weingarten, Stewart Bryant, Nurit Sprecher, Daniele Ceccarelli, Diego Caviglia, Francesco Fondelli, Marco Corsi, Bo Wu, Xuehui Dai, 13-Nov-11, This document presents an applicability statement to address the requirements for protection of ring topologies for Multi-Protocol Label Switching Transport Profile (MPLS-TP) Label Switched Paths (LSP) on multiple layers. The MPLS-TP Requirements document specifies specific criteria for justification of dedicated protection mechanism for particular topologies, including optimizing the number of OAM entities needed, minimizing the number of labels for protection paths, minimizing the number of recovery elements in the network, and minimizing the number of control and management transactions necessary. The document proposes a methodology for ring protection based on existing MPLS-TP survivability mechanisms, specifically those defined in MPLS-TP Linear Protection, without the need for specification of new constructs or protocols. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications Union Telecommunications Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. "Handling MPLS-TP OAM Packets Targeted at Internal MIPs", Adrian Farrel, Hideki Endo, Rolf Winter, Yoshinori Koike, Manuel Paul, 19-Dec-11, The Framework for Operations, Administration and Maintenance (OAM) within the MPLS Transport Profile (MPLS-TP) describes how Maintenance Entity Group Intermediate Points (MIPs) may be situated within network nodes at the incoming and outgoing interfaces. This document describes a way of forming OAM messages so that they can be targeted at MIPs on incoming or MIPs on outgoing interfaces, forwarded correctly through the "switch fabric", and handled efficiently in node implementations where there is no distinction between the incoming and outgoing MIP. The material in this document is provided for discussion within the MPLS-TP community in the expectation that this idea or some similar mechanism will be subsumed into a more general MPLS-TP OAM 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 PWE3 architectures to support the capabilities and functionalities of a packet transport network. "MPLS-TP Applicability; Use Cases and Design", Luyuan Fang, Nabil Bitar, Raymond Zhang, Masahiro Daikoku, 20-Dec-11, This document provides applicability, use case studies and network design considerations for Multiprotocol Label Switching Transport profile (MPLS-TP). In the recent years, MPLS-TP has emerged as the technology of choice for the new generation of packet transport. Many service providers (SPs) are working to replace the legacy transport technologies, e.g. SONET/SDH, TDM, and ATM technologies, with MPLS-TP for packet transport, in order to achieve higher efficiency, lower operational cost, while maintaining transport characteristics. The use cases for MPLS-TP include Metro Ethernet access and aggregation, Mobile backhaul, and packet optical transport. The design considerations discussed in this documents ranging from operational experience; standards compliance; technology maturity; end-to-end forwarding and OAM consistency; compatibility with IP/MPLS networks; multi-vendor interoperability; and optimization vs. simplicity design trade off discussion. The general design principle is to provide reliable, manageable, and scalable transport solutions. "LDP Downstream-on-Demand in Seamless MPLS", Thomas Beckhaus, Bruno Decraene, Kishore Tiruveedhula, Maciek Konstantynowicz, Luca Martini, 4-Jan-12, Seamless MPLS design enables a single IP/MPLS network to scale over core, metro and access parts of a large packet network infrastructure using standardized IP/MPLS protocols. One of the key goals of Seamless MPLS is to meet requirements specific to access, including high number of devices, their position in network topology and their compute and memory constraints that limit the amount of state access devices can hold.This can be achieved with LDP Downstream-on-Demand (LDP DoD) label advertisement. This document describes LDP DoD use cases and lists required LDP DoD procedures in the context of Seamless MPLS design. In addition, a new optional TLV type in the LDP label request message is defined for fast-up convergence. "MPLS Generic Associated Channel (G-ACh) Advertisement Protocol", Dan Frost, Stewart Bryant, Matthew Bocci, 27-Jan-12, The MPLS Generic Associated Channel (G-ACh) provides an auxiliary logical data channel associated with a Label Switched Path (LSP), a pseudowire, or a section (link) over which a variety of protocols may flow. These protocols are commonly used to provide Operations, Administration, and Maintenance (OAM) mechanisms associated with the primary data channel. This document specifies simple procedures by which an endpoint of an LSP, pseudowire, or section may inform the other endpoints of its capabilities and configuration parameters, or other application-specific information. This information may then be used by the receiver to validate or adjust its local configuration, and by the network operator for diagnostic purposes. "MPLS-TP Next-Hop Ethernet Addressing", Dan Frost, Stewart Bryant, Matthew Bocci, 27-Jan-12, The Multiprotocol Label Switching (MPLS) Transport Profile (MPLS-TP) is the set of MPLS protocol functions applicable to the construction and operation of packet-switched transport networks. This document presents considerations for link-layer addressing of Ethernet frames carrying MPLS-TP packets. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network. Multipath TCP (mptcp) --------------------- "TCP Extensions for Multipath Operation with Multiple Addresses", Alan Ford, Costin Raiciu, Mark Handley, Olivier Bonaventure, 31-Jan-12, TCP/IP communication is currently restricted to a single path per connection, yet multiple paths often exist between peers. The simultaneous use of these multiple paths for a TCP/IP session would improve resource usage within the network, and thus improve user experience through higher throughput and improved resilience to network failure. Multipath TCP provides the ability to simultaneously use multiple paths between peers. This document presents a set of extensions to traditional TCP to support multipath operation. The protocol offers the same type of service to applications as TCP (i.e. reliable bytestream), and provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths. "MPTCP Application Interface Considerations", Michael Scharf, Alan Ford, 30-Nov-11, Multipath TCP (MPTCP) adds the capability of using multiple paths to a regular TCP session. Even though it is designed to be totally backward compatible to applications, the data transport differs compared to regular TCP, and there are several additional degrees of freedom that applications may wish to exploit. This document summarizes the impact that MPTCP may have on applications, such as changes in performance. Furthermore, it discusses compatibility issues of MPTCP in combination with non-MPTCP-aware applications. Finally, the document describes a basic application interface for MPTCP-aware applications that provides access to multipath address information and a level of control equivalent to regular TCP. Multicast Mobility (multimob) ----------------------------- "Tuning the Behavior of IGMP and MLD for Routers in Mobile and Wireless Networks", Hitoshi Asaeda, Hui Liu, Qin Wu, 17-Jan-12, IGMP and MLD are the protocols used by hosts and multicast routers to exchange their IP multicast group memberships with each other. This document describes the ways of IGMPv3 and MLDv2 protocol optimization for mobility, and aims to become a guideline for tuning of IGMPv3/ MLDv2 Queries and timer and counter values. "Mobile Multicast Sender Support in Proxy Mobile IPv6 (PMIPv6) Domains", Thomas Schmidt, Shuai Gao, Hong-Ke Zhang, Matthias Waehlisch, 9-Jan-12, Multicast communication can be enabled in Proxy Mobile IPv6 domains via the Local Mobility Anchors by deploying MLD Proxy functions at Mobile Access Gateways, via a direct traffic distribution within an ISP's access network, or by selective route optimization schemes. This document describes the support of mobile multicast senders in Proxy Mobile IPv6 domains for all three scenarios. Mobile sources always remain agnostic of multicast mobility operations. Network Endpoint Assessment (nea) --------------------------------- "PT-TLS: A TCP-based Posture Transport (PT) Protocol", Paul Sangster, Nancy Cam-Winget, Joseph Salowey, 19-Sep-11, This document specifies PT-TLS, a TCP-based Posture Transport (PT) protocol. The PT-TLS protocol carries the Network Endpoint Assessment (NEA) message exchange under the protection of a Transport Layer Security (TLS) secured tunnel. "PT-EAP: Posture Transport (PT) Protocol For EAP Tunnel Methods", Paul Sangster, Nancy Cam-Winget, 30-Aug-11, This document specifies PT-EAP, a Posture Broker Protocol compatible with the Trusted Computing Group's IF-T Protocol Bindings for Tunneled EAP Methods (also known as EAP-TNC). The document then evaluates PT-EAP against the requirements defined in the NEA Requirements and PB-TNC specifications. Network Configuration (netconf) ------------------------------- "Network Configuration Protocol (NETCONF) Access Control Model", Andy Bierman, Martin Bjorklund, 23-Dec-11, The standardization of network configuration interfaces for use with the NETCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF protocol access for particular users to a pre- configured subset of all available NETCONF protocol operations and content. This document defines such an access control model. "Network Configuration Protocol (NETCONF) Base Notifications", Andy Bierman, 9-Dec-11, The NETCONF protocol provides mechanisms to manipulate configuration datastores. However, client applications often need to be aware of common events such as a change in NETCONF server capabilities, that may impact management applications. Standard mechanisms are needed to support the monitoring of the base system events within the NETCONF server. This document defines a YANG module that allows a NETCONF client to receive notifications for some common system events. Network-Based Mobility Extensions (netext) ------------------------------------------ "Runtime LMA Assignment Support for Proxy Mobile IPv6", Jouni Korhonen, Sri Gundavelli, Hidetoshi Yokota, Xiangsong Cui, 12-Oct-11, This document describes a runtime Local Mobility Anchor assignment functionality and corresponding mobility options for Proxy Mobile IPv6. The runtime Local Mobility Anchor assignment takes place during a Proxy Binding Update and a Proxy Binding Acknowledgement message exchange between a Mobile Access Gateway and a Local Mobility Anchor. The runtime Local Mobility Anchor assignment functionality defined in this specification can be used, for example, for load balancing purposes. "Bulk Binding Update Support for Proxy Mobile IPv6", Fuad Abinader, Sri Gundavelli, Kent Leung, Suresh Krishnan, Domagoj Premec, 10-Jan-12, For extending the lifetime of a mobility session, the Proxy Mobile IPv6 specification requires the mobile access gateway to send a Proxy Binding Update message to the local mobility anchor on a per-session basis. In the absence of signaling semantics for performing operations with group specific scope, it results in significant amount of signaling traffic on a periodic basis between a given mobile access gateway and a local mobility anchor. This document defines optimizations to the binding update and revocation operations in Proxy Mobile IPv6 for performing operations with group specific scope with the use of a group identifier. "RADIUS Support for Proxy Mobile IPv6", Frank Xia, Behcet Sarikaya, Jouni Korhonen, Sri Gundavelli, Damjan Damic, 30-Jan-12, This document defines new attributes to facilitate Proxy Mobile IPv6 operations using the RADIUS infrastructure. The protocol defined in this document uses Radius based interfaces of the mobile access gateway and the local mobility anchor with the AAA server for authentication, authorization and policy functions. The RADIUS interactions between the mobile access gateway and the RADIUS-based AAA server take place when the Mobile Node attaches, authenticates and authorizes to a Proxy Mobile IPv6 domain. Furthermore, this document defines the RADIUS-based interface between the local mobility anchor and the AAA RADIUS server for authorizing received Proxy Binding Update messages for the mobile node's mobility session. In addition to the mobility session setup related interactions, this document defines the baseline for the mobile access gateway and the local mobility anchor generated accounting. "Logical Interface Support for multi-mode IP Hosts", Telemaco Melia, Sri Gundavelli, 31-Oct-11, A Logical Interface is a software semantic internal to the host operating system. This semantic is available in all popular operating systems and is used in various protocol implementations. The Logical Interface support is required on the mobile node operating in a Proxy Mobile IPv6 domain, for leveraging various network-based mobility management features such as inter-technology handoffs, multihoming and flow mobility support. This document explains the operational details of Logical Interface construct and the specifics on how the link-layer implementations hide the physical interfaces from the IP stack and from the network nodes on the attached access networks. Furthermore, this document identifies the applicability of this approach to various link-layer technologies and analyzes the issues around it when used in context with various mobility management features. "Localized Routing for Proxy Mobile IPv6", Suresh Krishnan, Rajeev Koodli, Paulo Loureiro, Wenson Wu, Ashutosh Dutta, 24-Jan-12, Proxy Mobile IPv6 (PMIPv6) is a network based mobility management protocol that enables IP mobility for a host without requiring its participation in any mobility-related signaling. PMIPv6 requires all communications to go through the local mobility anchor. As this can be suboptimal, localized routing (LR) allows mobile nodes attached to the same or different mobile access gateways to route traffic by using localized forwarding or a direct tunnel between the gateways. This document proposes initiation, utilization and termination mechanisms for localized routing between mobile access gateways within a proxy mobile IPv6 domain. It defines two new signaling messages, Localized Routing Initiation (LRI) and Local Routing Acknowledgment (LRA), that are used to realize this mechanism. "Access Network Identifier (ANI) Option for Proxy Mobile IPv6", Sri Gundavelli, Jouni Korhonen, Mark Grayson, Kent Leung, Rajesh Pazhyannur, 9-Feb-12, This specification defines a mechanism and a related mobility option for carrying the access network identifier and the access operator identification information from the mobile access gateway to the local mobility anchor over Proxy Mobile IPv6. Based on the received information, the local mobility anchor is able to provide access network and access operator specific handling or policing for the mobile node traffic. "Prefix Delegation for Proxy Mobile IPv6", Xingyue Zhou, Jouni Korhonen, Carl Williams, Sri Gundavelli, 30-Oct-11, DHCPv6 Prefix Delegation can be used to assign a prefix or prefixes to a mobile router for use on the links in the mobile network as specified in [RFC6276] but not supported in Proxy Mobile IPv6. This document specifies an extension to Proxy Mobile IPv6 protocol for supporting network mobility using DHCPv6-based Prefix Delegation. "IPv4 Traffic Offload Selector Option for Proxy Mobile IPv6", Sri Gundavelli, Xingyue Zhou, Jouni Korhonen, Rajeev Koodli, 9-Feb-12, This specification defines a mechanism and a related mobility option for carrying IPv4 Offload traffic selectors between a mobile access gateway and a local mobility anchor in a Proxy Mobile IPv6 domain. Based on the received offload flow selectors from the local mobility anchor, a mobile access gateway can enable offload traffic rule on the selected IPv4 flows. "Proxy Mobile IPv6 Extensions to Support Flow Mobility", Carlos Bernardos, 30-Oct-11, Proxy Mobile IPv6 allows a mobile node to connect to the same Proxy Mobile IPv6 domain through different interfaces. However, the ability of movement of selected flows from one access technology to another is missing in the basic Proxy Mobile IPv6 protocol. This document describes enhancements to the Proxy Mobile IPv6 protocol that are required to support network based flow mobility over multiple physical interfaces. This document assumes that the mobile node implements the logical interface model, therefore allowing the support of traffic flows on different physical interfaces regardless of the assigned prefixes on these physical interfaces. NETCONF Data Modeling Language (netmod) --------------------------------------- "IANA Interface Type YANG Module", Martin Bjorklund, 7-Sep-11, This document defines the initial version of the iana-if-type YANG module. "A YANG Data Model for Interface Configuration", Martin Bjorklund, 7-Feb-12, This document defines a YANG data model for the configuration of network interfaces. It is expected that interface type specific configuration data models augment the generic interfaces data model defined in this document. "Translation of SMIv2 MIB Modules to YANG Modules", Juergen Schoenwaelder, 19-Jan-12, YANG is a data modeling language used to model configuration and state data manipulated by the NETCONF protocol, NETCONF remote procedure calls, and NETCONF notifications. The Structure of Management Information (SMIv2) defines fundamental data types, an object model, and the rules for writing and revising MIB modules for use with the SNMP protocol. This document defines a translation of SMIv2 MIB modules into YANG modules, enabling read-only access to data objects defined in SMIv2 MIB modules via NETCONF. "A YANG Data Model for Routing Configuration", Ladislav Lhotka, 23-Sep-11, This document contains a specification of three YANG modules that together provide a data model for essential configuration of a routing subsystem. It is expected that this module will serve as a basis for further development of data models for individual routing protocols and other related functions. The present data model defines the common building blocks for such configurations - router instances, routes, routing tables, routing protocols and route filters. "A YANG Data Model for IP Configuration", Martin Bjorklund, 8-Feb-12, This document defines a YANG data model for configuration of IP addresses on network interfaces. "YANG Data Model for System Management", Andy Bierman, Martin Bjorklund, 31-Jan-12, This document defines a YANG data model for the configuration and identification of the management system of a device. Network File System Version 4 (nfsv4) ------------------------------------- "Administration Protocol for Federated Filesystems", James Lentini, Craig Everhart, Daniel Ellard, Renu Tewari, Manoj Naik, 6-Jun-11, This document describes the administration protocol for a federated file system that enables file access and namespace traversal across collections of independently administered fileservers. The protocol specifies a set of interfaces by which fileservers with different administrators can form a fileserver federation that provides a namespace composed of the filesystems physically hosted on and exported by the constituent fileservers. "Using DNS SRV to Specify a Global File Name Space with NFS version 4", Craig Everhart, Andy Adamson, Jiaying Zhang, 21-Dec-11, The NFS version 4 protocol provides a mechanism for a collection of NFS file servers to collaborate in providing an organization-wide file name space. The DNS SRV RR allows a simple way for an organization to publish the root of its filesystem name space, even to clients that might not be intimately associated with such an organization. The DNS SRV RR can be used to join these organization- wide file name spaces together to allow construction of a global, uniform NFS file name space. "NSDB Protocol for Federated Filesystems", James Lentini, Craig Everhart, Daniel Ellard, Renu Tewari, Manoj Naik, 11-Mar-11, This document describes a filesystem federation protocol that enables file access and namespace traversal across collections of independently administered fileservers. The protocol specifies a set of interfaces by which fileservers with different administrators can form a fileserver federation that provides a namespace composed of the filesystems physically hosted on and exported by the constituent fileservers. "Network File System (NFS) Version 4 Protocol", Thomas Haynes, David Noveck, 30-Oct-11, The Network File System (NFS) version 4 is a distributed filesystem protocol which owes heritage to NFS protocol version 2, RFC 1094, and version 3, RFC 1813. Unlike earlier versions, the NFS version 4 protocol supports traditional file access while integrating support for file locking and the mount protocol. In addition, support for strong security (and its negotiation), compound operations, client caching, and internationalization have been added. Of course, attention has been applied to making NFS version 4 operate well in an Internet environment. This document, together with the companion XDR description document, RFCNFSv4XDR, replaces RFC 3530 as the definition of the NFS version 4 protocol. "Network File System (NFS) Version 4 External Data Representation Standard (XDR) Description", Thomas Haynes, David Noveck, 30-Oct-11, The Network File System (NFS) version 4 is a distributed filesystem protocol which owes heritage to NFS protocol version 2, RFC 1094, and version 3, RFC 1813. Unlike earlier versions, the NFS version 4 protocol supports traditional file access while integrating support for file locking and the mount protocol. In addition, support for strong security (and its negotiation), compound operations, client caching, and internationalization have been added. Of course, attention has been applied to making NFS version 4 operate well in an Internet environment. This document, together with RFC3530bis replaces RFC 3530 as the definition of the NFS version 4 protocol. "NFS Version 4 Minor Version 2", Thomas Haynes, 4-Jan-12, This Internet-Draft describes NFS version 4 minor version two, focusing mainly on the protocol extensions made from NFS version 4 minor version 0 and NFS version 4 minor version 1. Major extensions introduced in NFS version 4 minor version two include: Server-side Copy, Space Reservations, and Support for Sparse Files. "NFSv4 Minor Version 2 Protocol External Data Representation Standard (XDR) Description", Thomas Haynes, 4-Jan-12, This Internet-Draft provides the XDR description for NFSv4 minor version two. "Remote Procedure Call (RPC) Security Version 3", Thomas Haynes, Nico Williams, 14-Nov-11, This document specifies version 3 of the Remote Procedure Call (RPC) security protocol (RPCSEC_GSS). This protocol provides for: compound authentication of client hosts and users to server (constructed by generic composition), channel binding, security label assertions for multi-level and type enforcement, privilege assertions and identity assertions. "Object-Based Parallel NFS (pNFS) Operations", Benny Halevy, Boaz Harrosh, Brent Welch, 5-Sep-11, Parallel NFS (pNFS) extends Network File System version 4 (NFSv4) to allow clients to directly access file data on the storage used by the NFSv4 server. This ability to bypass the server for data access can increase both performance and parallelism, but requires additional client functionality for data access, some of which is dependent on the class of storage used, a.k.a. the Layout Type. The main pNFS operations and data types in NFSv4 Minor version 1 specify a layout- type-independent layer; layout-type-specific information is conveyed using opaque data structures whose internal structure is further defined by the particular layout type specification. This document specifies the NFSv4.1 Object-Based pNFS Layout Type as a companion to the main NFSv4 Minor version 1 specification. "pNFS block disk protection", David Black, Jason Glasgow, Sorin Faibish, 21-Nov-11, Parallel NFS (pNFS) extends Network File System version 4 (NFSv4) to enable direct client access to file data on storage, bypassing the NFSv4 server. This can increase both performance and parallelism, but requires additional client functionality, some of which depends upon the type of storage used. The pNFS specification for block storage (RFC 5663) describes how clients can identify the volumes used for pNFS, but this mechanism requires communication with the NFSv4 server. This document adds a mechanism to RFC 5663 that enables identification of block storage devices used by pNFS file systems without communicating with the server. This enables clients to control access to pNFS block devices when the client initially boots, as opposed to waiting until the client can communicate with the NFSv4 server. Individual Submissions (none) ----------------------------- "Simple Certificate Enrollment Protocol", Max Pritikin, Andrew Nourse, J Vilhuber, 7-Sep-11, This document specifies the Simple Certificate Enrollment Protocol (SCEP), a Public Key Infrastructure (PKI) communication protocol which leverages existing technology by using PKCS#7 and PKCS#10 over HTTP. SCEP is the evolution of the enrollment protocol developed by VeriSign, Inc. for Cisco Systems, Inc. It now enjoys wide support in both client and a Certification Authority implementations. "Multicast DNS", Stuart Cheshire, Marc Krochmal, 9-Dec-11, As networked devices become smaller, more portable, and more ubiquitous, the ability to operate with less configured infrastructure is increasingly important. In particular, the ability to look up DNS resource record data types (including, but not limited to, host names) in the absence of a conventional managed DNS server is useful. Multicast DNS (mDNS) provides the ability to perform DNS-like operations on the local link in the absence of any conventional unicast DNS server. In addition, mDNS designates a portion of the DNS namespace to be free for local use, without the need to pay any annual fee, and without the need to set up delegations or otherwise configure a conventional DNS server to answer for those names. The primary benefits of mDNS names are that (i) they require little or no administration or configuration to set them up, (ii) they work when no infrastructure is present, and (iii) they work during infrastructure failures. "The 'tdb' and 'duri' URI schemes, based on dated URIs", Larry Masinter, 21-Jan-12, This document defines two URI schemes. The first, 'duri' (standing for "dated URI"), identifies a resource as of a particular time. This allows explicit reference to the "time of retrieval", similar to the way in which bibliographic references containing URIs are often written. The second scheme, 'tdb' ( standing for "Thing Described By"), provides a way of minting URIs for anything that can be described, by the means of identifying a description as of a particular time. These schemes were posited as "thought experiments", and therefore this document is designated as Experimental. "Requirements for a Protocol to Replace AppleTalk NBP", Stuart Cheshire, Marc Krochmal, 12-Jan-11, One of the goals of the authors of Multicast DNS (mDNS) and DNS-Based Service Discovery (DNS-SD) was the desire to retire AppleTalk and the AppleTalk Name Binding Protocol, and to replace them with an IP-based solution. This document presents a brief overview of the capabilities of AppleTalk NBP, and outlines the properties required of an IP-based replacement. The views expressed in this Informational document represent the opinions of the authors, not IETF consensus. "An IPv4 Flowlabel Option", Thomas Dreibholz, 31-Dec-11, This draft defines an IPv4 option containing a flowlabel that is compatible to IPv6. It is required for simplified usage of IntServ and interoperability with IPv6. "BGP Persistent Route Oscillation Solutions", Daniel Walton, Enke Chen, Alvaro Retana, John Scudder, 15-Dec-11, In this document we present two sets of paths for an address prefix that can be advertised by a BGP route reflector or confederation ASBR to eliminate the MED-induced route oscillations in a network. The first set involves all the available paths, and would achieve the same routing consistency as the full IBGP mesh. The second set, which is a subset of the first one, involves the neighbor-AS based Group Best Paths, and would be sufficient to eliminate the MED- induced route oscillations (subject to certain commonly adopted topological constrains). "EAP Support in Smartcard", Pascal Urien, Guy Pujolle, 27-Jan-12, This document describes the functional interface, based on the ISO7816 standard, to EAP methods, fully and securely executed in smart cards. This class of tamper resistant device may deliver client or server services; it can compute Root Keys from an Extended Master Session Key (EMSK). "DNS-Based Service Discovery", Stuart Cheshire, Marc Krochmal, 9-Dec-11, This document specifies how DNS resource records are named and structured to facilitate service discovery. Given a type of service that a client is looking for, and a domain in which the client is looking for that service, this allows clients to discover a list of named instances of that desired service, using standard DNS queries. This is referred to as DNS-based Service Discovery, or DNS-SD. "Reliable Server Pooling Applicability for IP Flow Information Exchange", Thomas Dreibholz, Lode Coene, Phillip Conrad, 31-Dec-11, This document describes the applicability of the Reliable Server Pooling architecture to the IP Flow Information Exchange using the Aggregate Server Access Protocol (ASAP) functionality of RSerPool only. Data exchange in IPFIX between the router and the data collector can be provided by a limited retransmission protocol. "Prepaid Extensions to Remote Authentication Dial-In User Service (RADIUS)", Avi Lior, Parviz Yegani, Kuntal Chowdhury, Hannes Tschofenig, Andreas Pashalidis, 31-Oct-11, This document specifies an extension to the Remote Authentication Dial-In User Service (RADIUS) protocol that enables service providers to charge for prepaid services. The supported charging models supported are volume-based, duration-based, and based on one-time events. "Lumas - Language for Universal Message Abstraction and Specification", Peter Cordell, 2-Feb-07, A number of methods and tools are available for defining the format of messages used for application protocols. However, many of these methods and tools have been designed for purposes other than message definition, and have been adopted on the basis that they are available rather than being ideally suited to the task. This often means that the methods make it difficult to get definitions correct, or result in unnecessary complexity and verbosity both in the definition and on the wire. Lumas - Language for Universal Message Abstraction and Specification - has been custom designed for the purpose of message definition. It is thus easy to specify messages in a compact, extensible format that is readily machine manipulated to produce a compact encoding on the wire. "Definitions of Managed Objects for VRRPv3", Kalyan Tata, 8-Sep-11, This specification defines a portion of the Management Information Base (MIB) for use with SNMP-based network management. In particular, it defines objects for configuring, monitoring, and controlling routers that employ the Virtual Router Redundancy Protocol Version 3 for both IPv4 and IPv6 as defined in RFC 5798. This memo obsoletes RFC 2787. "Layer 2 Virtual Private Networks Using BGP for Auto-discovery and Signaling", Kireeti Kompella, Bhupesh Kothari, Rao Cherukuri, 13-Jan-12, Layer 2 Virtual Private Networks (L2VPNs) based on Frame Relay or ATM circuits have been around a long time; more recently, Ethernet VPNs, including Virtual Private LAN Service, have become popular. Traditional L2VPNs often required a separate Service Provider infrastructure for each type, and yet another for the Internet and IP VPNs. In addition, L2VPN provisioning was cumbersome. This document presents a new approach to the problem of offering L2VPN services where the L2VPN customer's experience is virtually identical to that offered by traditional Layer 2 VPNs, but such that a Service Provider can maintain a single network for L2VPNs, IP VPNs and the Internet, as well as a common provisioning methodology for all services. "A QoS Model for Signaling IntServ Controlled-Load Service with NSIS", Cornelia Kappler, Xiaoming Fu, Bernd Schloer, 4-Sep-11, This document describes a QoS Model to signal IntServ controlled load service with QoS NSLP. QoS NSLP is QoS Model agnostic. All QoS Model specific information is carried in an opaque object, the QSPEC. This document hence specifies the QSPEC for controlled load service, how the QSPEC must be processed in QoS NSLP nodes, and how QoS NSLP messages must be used. "IP Fast Reroute using tunnels", Stewart Bryant, Clarence Filsfils, Stefano Previdi, Mike Shand, 16-Nov-07, This draft describes an IP fast re-route mechanism that provides backup connectivity in the event of a link or router failure. In the absence of single points of failure and asymmetric costs, the mechanism provides complete protection against any single failure. If perfect repair is not possible, the identity of all the unprotected links and routers is known in advance. This IP Fast Reroute advanced method was invented in 2002 and draft (draft-bryant-ipfrr-tunnels-00.txt) describing it was submitted to the IETF in May 2004. It was one of the first methods of achieving full repair coverage in an IP Network, and as such the draft has been widely referenced in the academic literature. The authors DO NOT propose that this IPFRR method be implemented since better IPFRR advanced method capable of achieving full repair coverage have subsequently been invented. "DISCOVER: Supporting Multicast DNS Queries", Bill Manning, 13-Jan-12, This document describes the DISCOVER opcode, an experimental extension to the Domain Name System (DNS) to use multicast queries for resource discovery. This opcode was tested in experiments run during 1995 and 1996 for the TBDS project. This was the first known use of multicast transport for DNS. A client multicasts a DNS query using the DISCOVER opcode and processes the multiple responses that may result. "HIP Experiment Report", Tom Henderson, Andrei Gurtov, 16-Dec-11, This document is a report from the IRTF HIP research group documenting the collective experiences and lessons learned from studies, related experimentation, and designs completed by the research group. The documents summarizes implications of adding HIP to host protocol stacks, Internet infrastructure, and applications. The perspective of a network operator, as well as a list of HIP experiments, are presented as well. Portions of this report may be relevant also to other network overlay-based architectures or to attempts to deploy alternative networking architectures. "Certificate Exchange Messaging for EDIINT draft-meadors-certificate-exchange-14.txt Abstract", Kyle Meadors, Dale Moberg, 22-Dec-11, The EDIINT AS1, AS2 and AS3 message formats do not currently contain any neutral provisions for transporting and exchanging trading partner profiles or digital certificates. EDIINT Certificate Exchange Messaging provides the format and means to effectively exchange certificates for use within trading partner relationships. The messaging consists of two types of messages, Request and Response, which allow trading partners to communicate certificates, their intended usage and their acceptance through XML. Certificates can be specified for use in digital signatures, data encryption or SSL/TLS over HTTP (HTTPS). "The OCB Authenticated-Encryption Algorithm", Ted Krovetz, Phillip Rogaway, 22-Jan-12, This document specifies OCB, a shared-key blockcipher-based encryption scheme that provides privacy and authenticity for plaintexts and authenticity for associated data. "CalDAV Scheduling Extensions to WebDAV", Cyrus Daboo, Bernard Desruisseaux, 7-Sep-11, This document defines extensions to the CalDAV "calendar-access" feature to specify a standard way of performing scheduling transactions with iCalendar-based calendar components. This document defines the "calendar-auto-schedule" feature of CalDAV. "Applicability of Reliable Server Pooling for Real-Time Distributed Computing", Thomas Dreibholz, 31-Dec-11, This document describes the applicability of the Reliable Server Pooling architecture to manage real-time distributed computing pools and access the resources of such pools. "RADIUS Attributes for IEEE 802 Networks", Bernard Aboba, Jouni Malinen, Paul Congdon, Joseph Salowey, 22-Oct-11, RFC 3580 provides guidelines for the use of the Remote Authentication Dialin User Service (RADIUS) within IEEE 802 local area networks (LANs). This document proposes additional attributes for use within IEEE 802 networks, as well as providing clarifications on the usage of the EAP-Key-Name attribute, updating RFC 4072. The attributes defined in this document are usable both within RADIUS and Diameter. "Secure SCTP", Carsten Hohendorf, Esbold Unurkhaan, Thomas Dreibholz, 31-Dec-11, This document explains the reason for the integration of security functionality into SCTP, and gives a short description of S-SCTP and its services. S-SCTP is fully compatible with SCTP defined in RFC4960, it is designed to integrate cryptographic functions into SCTP. "Combined Presence Schemas Utilizing RELAX NG", Jari Urpalainen, 9-Oct-08, This memo describes a batch of Presence Information Data Format (PIDF) and its extension schemas written with the RELAX NG schema language. Unlike with the current W3C XML Schema language it is possible to write reasonable forwards and backwards compatible presence combination schemas. These RELAX NG schemas are stricter than the W3C Schemas and thus the instance documents that validate with these schemas follow the intended content model more closely. Especially, these schemas are targeted to actual implementations in order to decrease interoperability problems. "Operational Reliability for EDIINT AS2", John Duker, Dale Moberg, 17-Oct-11, The goal of this document is to define approaches to achieve a "once and only once" delivery of messages. The EDIINT AS2 protocol [AS2] is implemented by a number of software tools on a variety of platforms with varying capabilities and with varying network service quality. Although the AS2 protocol defines a unique "Message-ID", current implementations of AS2 do not provide a standard method to prevent the same message (re-transmitted by the initial sender) from reaching back-end business applications at the initial receiver. TCP underpinnings of HTTP over which AS2 operates generally provide a good quality of network connectivity, but experience indicates a need to be able to compensate for both transient server and socket exceptions, including "Connection refused" as well as "Server busy." In addition, difficulties with server availability, stability, and loads can result in reduced operational reliability. This document describes some ways to compensate for exceptions and enhance the reliability of AS2 protocol operation. Implementation of these reliability features is indicated by presence of the "AS2- Reliability" value in the EDIINT-Features header. Intended Status The intent of this document is to be placed on the RFC track as an Informational RFC. Feedback Instructions: NOTE TO RFC EDITOR: This section should be removed by the RFC editor prior to publication. If you want to provide feedback on this draft, follow these guidelines: -Send feedback via e-mail to the ietf-ediint list for discussion, with "AS2 Reliability" in the Subject field. To enter or follow the discussion, you need to subscribe to ietf-ediint@imc.org. -Be specific as to what section you are referring to, preferably quoting the portion that needs modification, after which you state your comments. -If you are recommending some text to be replaced with your suggested text, again, quote the section to be replaced, and be clear on the section in question. "Enhanced Fast Handover for Mobile IPv6 based on IEEE 802.11 Network", Youngsong Mun, Seonggeun Ryu, Kyujin Lee, 23-Sep-11, In MIPv6 [1], whenever a mobile node changes its attached point, handover process should be followed to inform its home agent and correspondent of a MN's current location. The handover process is decomposed into layer 2 and layer 3 handovers again, and these two handovers are accomplished sequentially, which causes long latency problem. This problem is a critical issue in MIPv6. To make up for this, we propose an enhanced Fast Handover scheme to reduce the overall latency on handover, revising the Fast Handover [2]. Especially, several messages in layer 3 are sent in one frame during layer 2 handover. "Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP)", Keith Drage, Christer Holmberg, Roland Jesske, 9-Jan-12, This document describes a set of private Session Initiation Protocol (SIP) header fields (P-headers) used by the 3rd-Generation Partnership Project (3GPP), along with their applicability, which is limited to particular environments. The P-header fields are for a variety of purposes within the networks that the partners use, including charging and information about the networks a call traverses. "DTCP: Dynamic Tasking Control Protocol", David Cavuto, 11-Nov-09, Dynamic Tasking Control Protocol is a message-based interface by which an authorized client may connect to a server -- usually a network element (NE) or security policy enforcement point (PEP) -- and issue dynamic requests for data. These tasking requests contain, among other parameters, packet matching criteria that may apply to certain packets flowing through that network element. The primary intent of the tasking request is to instruct that network element to send copies of packets matching those criteria to a destination (usually via tunneling) for further inspection or other action. The protocol contains a security architecture to address client or server spoofing as well as replay prevention. The protocol assumes that multiple clients may simultaneously control a single server. "The Atom "deleted-entry" Element", James Snell, 24-Jan-12, This specification adds mechanisms to the Atom Syndication Format which publishers of Atom Feed and Entry documents can use to explicitly identify Atom entries that have been removed. "The "pack" URI Scheme", Andrey Shur, Jerry Dunietz, 17-Feb-09, A package is a logical entity that holds a collection of parts. Given the URI for a complete package, the "pack" URI scheme provides for the construction and use of URIs referring to individual parts within the package. It also provides for the use of part's URIs as base URIs for resolving relative references between the parts in a single package. "Applicability of Reliable Server Pooling for SCTP-Based Endpoint Mobility", Thomas Dreibholz, Jobin Pulinthanath, 31-Dec-11, This document describes a novel mobility concept based on a combination of SCTP with Dynamic Address Reconfiguration extension and Reliable Server Pooling (RSerPool). "Reliable Server Pooling (RSerPool) Bakeoff Scoring", Thomas Dreibholz, Michael Tuexen, 31-Dec-11, This memo describes some of the scoring to be used in the testing of Reliable Server Pooling protocols ASAP and ENRP at upcoming bakeoffs. "Extended Community Based Outbound Route Filter for BGP-4", Enke Chen, Keyur Patel, Alton Lo, 5-Dec-11, This document defines two new Outbound Router Filter types for BGP, termed "Extended Community Outbound Route Filter Type I", and "Extended Community Outbound Route Filter Type II", that can be used to perform extended community based route filtering. "Considerations for Information Services and Operator Services Using SIP", John Haluska, Richard Ahern, Marty Cruze, Chris Blackwell, 15-Aug-11, Information Services are services whereby information is provided in response to user requests, and may include involvement of a human or automated agent. A popular existing Information Service is Directory Assistance (DA). Moving ahead, Information Services providers envision exciting multimedia services that support simultaneous voice and data interactions with full operator backup at any time during the call. Information Services providers are planning to migrate to SIP based platforms, which will enable such advanced services, while continuing to support traditional DA services. Operator Services are traditional PSTN services which often involve providing human or automated assistance to a caller, and often require the specialized capabilities traditionally provided by an operator services switch. Market and/or regulatory factors in some jurisdictions dictate that some subset of Operator Services continue to be provided going forward. This document aims to identify how Operator and Information Services can be implemented using existing or currently proposed SIP mechanisms, to identity existing protocol gaps, and to provide a set of Best Current Practices to facilitate interoperability. For Operator Services, the intention is to describe how current operator services can continue to be provided to PSTN based subscribers via a SIP based operator services architecture. It also looks at how current operator services might be provided to SIP based subscribers via such an architecture, but does not consider the larger question of the need for or usefulness or suitability of each of these services for SIP based subscribers. This document addresses the needs of current Operator and Information Services providers; as such, the intended audience includes vendors of equipment and services to such providers. "DNS Scoped Data Through Attribute Leaves", Dave Crocker, 13-Oct-11, Historically, any DNS RR may occur for any domain name. Recent additions have defined DNS leaf nodes that contain a reserved node name, beginning with an underscore. The underscore construct is used to define a semantic scope for DNS records associated with the parent domain. This note explores the nature of this DNS usage and defines the "underscore names" registry with IANA. "Delay-Tolerant Networking Previous Hop Insertion Block", Susan Symington, 27-Jan-11, This document defines an extension block for use with the DTN Bundle Protocol. This Previous Hop Insertion Block (PHIB) extension block is designed to be inserted by a forwarding node to provide the endpoint identifier (EID) of an endpoint of which the forwarding node is a member so that this EID may be conveyed to the next-hop receiving node. Knowledge of an EID of an endpoint of which a previous-hop node is a member may be required in some circumstances to support certain routing protocols (e.g., flood routing). If this EID cannot be provided by the convergence layer or other means, the PHIB defines the mechanism whereby the EID can be provided with the bundle. Each PHIB is always removed from the bundle by the receiving node so that its presence within the bundle is limited to exactly one hop. This document defines the format and processing of this PHIB. This document is a product of the Delay Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised." "URI Template", Joe Gregorio, Roy Fielding, Marc Hadley, Mark Nottingham, David Orchard, 26-Jan-12, A URI Template is a compact sequence of characters for describing a range of Uniform Resource Identifiers through variable expansion. This specification defines the URI Template syntax and the process for expanding a URI Template into a URI reference, along with guidelines for the use of URI Templates on the Internet. "A Uniform Resource Name Namespace for the GSM Association (GSMA) and the International Mobile station Equipment Identity (IMEI)", Michael Montemurro, Andrew Allen, David McDonald, Paul Gosden, 9-Jan-12, This specification defines a Uniform Resource Name namespace for the GSMA and a sub namespace for the IMEI (International Mobile station Equipment Identity), and associated parameter for the IMEISV (International Mobile station Equipment Identity and Software Version number). The IMEI is 15 decimal digits long and the IMEISV is 16 decimal digits long and both are encoded using Binary Encoded Decimal (BCD). The IMEI and IMEISV were introduced as part of the specification for Global System for Mobile (GSM) and are also now incorporated by the 3rd Generation Partnership Project (3GPP) as part of the 3GPP specification for GSM, the Universal Mobile Telecommunications System (UMTS) and 3GPP LTE (Long Term Evolution). The IMEI and IMEISV are used to uniquely identify Mobile Equipment within these systems and are managed by the GSMA (GSM Association). "Credential Protection Ciphersuites for Transport Layer Security (TLS)", Ibrahim Hajjeh, Mohamad Badra, 13-Nov-09, This document defines a set of cipher suites to add client credential protection to the Transport Layer Security (TLS) protocol. By negotiating one of those ciphersuites, the TLS clients will be able to determine for themselves when, how, to what extent and for what purpose information about them is communicated to others. The ciphersuites defined in this document can be used only when public key certificates are used in the client authentication process. "Fast Macro Mobility Handovers in HMIPv6", Youngsong Mun, Kyunghye Lee, 22-Sep-11, In Hierarchical Mobile IPv6 (HMIPv6), a mobile node (MN) moving from one MAP domain to another can experience both long handover latency and packet loss due to the distance between the two MAPs. To solve the problems, this document describes two fast handover schemes that support fast macro mobility handover. These fast handover schemes can reduce both the handover latency and the pakcet loss. The schemes described in this document adopt the fast handover of FMIPv6 protocol to the edge access routers in MAP domains. The schemes support two fast handover modes for macro mobility handover in HMIPv6. "Distributed DNS Implementation in IpV6", Lican Huang, 27-Jan-12, This file is a proposal for P2P based Domain Name query strategy in IpV6. The DNS servers construct n-tuple overlay virtual hierarchical overlay network. With cached addresses of DNS servers, the overload of traffic in tree structure can be avoided and more security can be enhanced due to the random lookup paths. This strategy may use for Domain Name query and reverse Domain Name query in IpV6 for a large number of domain names. "A Framework for Distributed Conferencing", Simon Romano, Alessandro Amirante, Tobia Castaldi, Lorenzo Miniero, Alfonso Buono, 19-Dec-11, This document defines the framework for Distributed Conferencing (DCON). The framework draws inspiration from the work carried out in the XCON working group, which has defined a complete architecture for centralized conferencing. DCON is based on the idea that a distributed conference can be setup by appropriately orchestrating the operation of a number of XCON focus elements, each in charge of managing a certain number of participants. Interaction between each participant and the corresponding conference focus is based on the standard XCON framework, whereas inter-focus interaction is defined in this document. "Requirements for Distributed Conferencing", Simon Romano, Alessandro Amirante, Tobia Castaldi, Lorenzo Miniero, Alfonso Buono, 19-Dec-11, This document examines the requirements for Distributed Conferencing (DCON). Separate documents will map the requirements to existing protocol primitives, define new protocol extensions, and introduce new protocols as needed. Together, these documents will provide a guideline for building interoperable conferencing applications. The current works in SIPPING and XCON working groups marginally address the matter, which is nonetheless considered as out-of-scope. The requirements listed in this document are in part based on thoughts derived from the cited working groups activities. "Requirements for the XCON-DCON Synchronization Protocol", Simon Romano, Alessandro Amirante, Tobia Castaldi, Lorenzo Miniero, Alfonso Buono, 19-Dec-11, The Distributed Conferencing (DCON) framework provides the means to distribute Centralized Conference (XCON) information by appropriately orchestrating a number of centralized focus entities (clouds). The mechanism we propose to make each XCON cloud communicate with its related DCON peer is based on the use of some kind of XCON-DCON Synchronization Protocol (XDSP). This document gives the requirements for XDSP. "Media Gateway Control Protocol (MGCP) Voiceband Data Package (VBD) and General Purpose Media Descriptor Parameter Package", Joe Stone, Rajesh Kumar, Flemming Andreasen, 5-Dec-11, This document defines Media Gateway Control Protocol (MGCP) packages that enable a Call Agent to authorize and monitor the transition of a connection to and from voiceband data (VBD) with or without redundancy and FEC (forward error correction). Although the focus is on VBD, the General-Purpose Media Descriptor Parameter package can be used to authorize other modes of operation, not relevant to VBD, for a particular codec. In addition to the definition of these new packages, this document describes the use of the Media Format Parameter package and Fax package with VBD, redundancy and FEC. "Reclassification of the APEX RFCs to Historic", Marshall T. Rose, 4-Jun-07, This memo reclassifies the APEX RFCs (RFCs 3340-3343) from PROPOSED STANDARD to HISTORIC. "An XCON Client Conference Control Package for the Media Control Channel Framework", Chris Boulton, Mary Barnes, 31-Oct-11, The Centralized Conferencing framework defines a model whereby client initiated interactions are required for creation, deletion, manipulation and querying the state of a of conference. This document defines a Media Control Channel Package for XCON client initiated Conference Control. The Package is based on the Media Control Channel Framework, which is also used for media server control, thus optimizing the implementation for some entities participating in an XCON system. "Handle Resolution Option for ASAP", Thomas Dreibholz, 31-Dec-11, This document describes the Handle Resolution option for the ASAP protocol. "NERD: A Not-so-novel EID to RLOC Database", Eliot Lear, 6-Mar-10, LISP is a protocol to encapsulate IP packets in order to allow end sites to multihome without injecting routes from one end of the Internet to another. This memo presents an experimental database and a discussion of methods to transport the mapping of EIDs to RLOCs to routers in a reliable, scalable, and secure manner. Our analysis concludes that transport of of all EID/RLOC mappings scales well to at least 10^8 entries. "A Flexible Authentication Framework for the Transport Layer Security (TLS) Protocol using the Extensible Authentication Protocol (EAP)", Yoav Nir, Yaron Sheffer, Hannes Tschofenig, Peter Gutmann, 19-Dec-11, Many of today's Web security problems have their root in the widespread usage of weak authentication mechanisms bundled with the usage of password based credentials. Dealing with both of these problems is the basis of this publication. This document extends the Transport Layer Security (TLS) protocol with a flexible and widely deployed authentication framework, namely the Extensible Authentication Protocol (EAP), to improve security of Web- as well as non-Web-based applications. The EAP framework allows so-called EAP methods, i.e. authentication and key exchange protocols, to be plugged into EAP without having to re-design the underlying protocol. The benefit of such an easy integration is the ability to run authentication protocols that fit a specific deployment environment, both from a credential choice as well as from the security and performance characteristics of the actual protocol. This work follows the example of IKEv2, where EAP has been added to allow clients to seamlessly use different forms of authentication credentials, such as passwords, token cards, and shared secrets. "Definition of a Delay Measurement Infrastructure and Delay-Sensitive Least-Used Policy for Reliable Server Pooling", Thomas Dreibholz, Xing Zhou, 31-Dec-11, This document contains the definition of a delay measurement infrastructure and a delay-sensitive Least-Used policy for Reliable Server Pooling. "Collection Synchronization for WebDAV", Cyrus Daboo, Arnaud Quillaud, 30-Jan-12, This specification defines an extension to Web Distributed Authoring and Versioning (WebDAV) that allows efficient synchronization of the contents of a WebDAV collection. Editorial Note (To be removed by RFC Editor before publication) Please send comments to the Distributed Authoring and Versioning (WebDAV) working group at , which may be joined by sending a message with subject "subscribe" to . Discussions of the WEBDAV working group are archived at . "The Lightweight Global Navigation Satellite System (GNSS) Support Protocol (LGSP)", Mike Tyson, Carlo Kopp, 21-Dec-07, This document presents the Lightweight GNSS (Global Navigation Satellite System) Support Protocol (LGSP). The Lightweight GNSS Support Protocol (LGSP) is being developed in order to provide a comprehensive solution which solves the problems inherent in traditional radio-based Differential GPS (DGPS) protocols. LGSP will also provide additional support for GNSS user equipment, such as a GPS almanac retrieval method, allowing compatible units to perform faster almanac acquisition, thus resulting in less time until an initial position measurement can be established. Other supporting features include alternative distribution of GPS navigation messages and differential correction messages, a hierarchical mirroring architecture, redundant backup operation and load balancing functions. "Prefer Header for HTTP", James Snell, 8-Feb-12, This specification defines an HTTP header field that can be used by a client to request that certain behaviors be implemented by a server while processing a request. "Chatrooms within a Centralized Conferencing (XCON) System", Mary Barnes, Chris Boulton, Salvatore Loreto, 31-Oct-11, The document "A Framework for Centralized Conferencing" defines a centralized conference as both signaling and protocol agnostic. The primary examples within this framework focus on audio and video as the media types for the session. This document provides an overview of the mechanisms defined in the centralized conferencing framework that can be used to support multi-user chat. In addition, the document describes additional functionality and requirements necessary to provide feature rich functionality. "Non-Renegable Selective Acknowledgements (NR-SACKs) for SCTP", Nasif Ekiz, Paul Amer, Preethi Natarajan, Randall Stewart, Janardhan Iyengar, 15-Aug-11, Stream Control Transmission Protocol (SCTP) [RFC4960] specifies Selective Acknowledgements (SACKs) to allow an SCTP data receiver to acknowledge DATA chunks which arrive out-of-order. In SCTP, SACK information is advisory -- though SACKs notify a data sender about the reception of specific out-of-order data, the SCTP data receiver is permitted to later discard the data, a.k.a reneging. Since delivery of a SACKed out-of-order DATA chunk is not guaranteed, a copy of this DATA chunk MUST be kept in the data sender's retransmission queue until this DATA chunk is cumulatively acked. By definition, data that has been delivered to the application is non-renegable by the SCTP data receiver. (Recall that, in SCTP, out- of-order data can sometimes be delivered.) Also, SCTP implementations can be configured such that the SCTP data receiver is not allowed to, and therefore, never reneges on out-of-order data. With SCTP's current SACK mechanism, non-renegable out-of-order data is selectively acked, and is (wrongly) deemed renegable by the SCTP data sender. This document specifies an extension to SCTP's acknowledgment mechanism called Non-Renegable Selective Acknowledgements (NR-SACKs.) NR-SACKs enable a data receiver to explicitly inform the data sender of non-renegable out-of-order data. As opposed to renegable data, a data sender can consider non-renegable data as never requiring retransmission, and therefore can remove non-renegable data from the retransmission queue. "Saratoga: A Scalable Data Transfer Protocol", Lloyd Wood, Wesley Eddy, Charles Smith, Will Ivancic, Chris Jackson, 26-Sep-11, This document specifies the Saratoga transfer protocol. Saratoga was originally developed to transfer remote-sensing imagery efficiently from a low-Earth-orbiting satellite constellation, but is useful for many other scenarios, including ad-hoc peer-to-peer communications, delay-tolerant networking, and grid computing. Saratoga is a simple, lightweight, content dissemination protocol that builds on UDP, and optionally uses UDP-Lite. Saratoga is intended for use when moving files or streaming data between peers which may have permanent, sporadic or intermittent connectivity, and is capable of transferring very large amounts of data reliably under adverse conditions. The Saratoga protocol is designed to cope with highly asymmetric link or path capacity between peers, and can support fully-unidirectional data transfer if required. In scenarios with dedicated links, Saratoga focuses on high link utilization to make the most of limited connectivity times, while standard congestion control mechanisms can be implemented for operation over shared links. Loss recovery is implemented via a simple negative-ack ARQ mechanism. The protocol specified in this document is considered to be appropriate for experimental use on private IP networks. "Session Initiation Protocol Service Example -- Music on Hold", Dale Worley, 22-Aug-11, The "music on hold" feature is one of the most desired features of telephone systems in the business environment. "Music on hold" is where, when one party to a call has the call "on hold", that party's telephone provides an audio stream (often music) to be heard by the other party. Architectural features of SIP make it difficult to implement music-on-hold in a way that is fully compliant with the standards. The implementation of music-on-hold described in this document is fully effective and standards-compliant, and has a number of advantages over the methods previously documented. In particular, it is less likely to produce peculiar user interface effects and more likely to work in systems which perform authentication than the method of RFC 5359. "End-Host Authentication for HIP Middleboxes", Rene Hummen, Tobias Heer, Miika Komu, 31-Oct-11, The Host Identity Protocol [RFC5201] is a signaling protocol for secure communication, mobility, and multihoming that introduces a cryptographic namespace. This document specifies an extension for HIP that enables middleboxes to unambiguously verify the identities of hosts that communicate across them. This extension allows middleboxes to verify the liveness and freshness of a HIP association and, thus, to secure access control in middleboxes. "Mutual Authentication Protocol for HTTP", Yutaka Oiwa, Hajime Watanabe, Hiromitsu Takagi, Boku Kihara, Tatsuya Hayashi, Yuichi Ioku, 31-Oct-11, This document specifies a mutual authentication method for the Hyper- text Transport Protocol (HTTP). This method provides a true mutual authentication between an HTTP client and an HTTP server using password-based authentication. Unlike the Basic and Digest authentication methods, the Mutual authentication method specified in this document assures the user that the server truly knows the user's encrypted password. This prevents common phishing attacks: a phishing attacker controlling a fake website cannot convince a user that he authenticated to the genuine website. Furthermore, even when a user authenticates to an illegitimate server, the server cannot gain any information about the user's password. The Mutual authentication method is designed as an extension to the HTTP protocol, and is intended to replace the existing authentication methods used in HTTP (the Basic method, Digest method, and authentication using HTML forms). "A Session Description Protocol (SDP) Control Package Attribute", Chris Boulton, 5-Sep-11, This document defines a new Session Description Protocol (SDP) media- level attribute: "ctrl-package". The "ctrl-package" attribute conveys details of the SIP Control Framework extension packages that are supported by a client participating in an offer/answer exchange. "Additional XML Security Uniform Resource Identifiers (URIs)", Donald Eastlake, 9-Sep-11, This document expands and updates the list of URIs intended for use with XML Digital Signatures, Encryption, Canonnicalization, and Key Management specified in RFC 4051 and it obsoletes that RFC. These URIs identify algorithms and types of information. "The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force", Paul Hoffman, 15-Oct-11, This document describes the inner workings of IETF meetings and Working Groups, discusses organizations related to the IETF, and introduces the standards process. It is not a formal IETF process document but instead an informational overview. "Specification of 3GPP IM CN Subsystem XML body handling", John-Luc Bakker, 2-Dec-11, This document registers new disposition-types for the Content- Disposition header field that apply to the application/3gpp-ims+xml body used by 3GPP. The applicability of these content-disposition values are limited to 3GPP IMS. The application/3gpp-ims+xml body has the following three distinct uses: (1) for redirecting the emergency session to use a different domain (e.g. using a Circuit Switched call), (2) for delivering user profile specific information from the SIP registrar to an Application Server, and (3) for causing a UAC to attempt to re-register with the IMS. "P-Charge-Info - A Private Header (P-Header) Extension to the Session Initiation Protocol (SIP)", Dan York, Tolga Asveren, 15-Sep-11, This document describes 'P-Charge-Info', a private Session Initiation Protocol (SIP) header (P-header) used to convey billing information about the party to be charged. This P-Header is currently in production usage by a number of equipment vendors and carriers and this document is submitted to request the registration of this header with IANA. This P-Header may also be used in some situations to carry the ISUP Charge Number parameter for PSTN interconnection. "Sender Policy Framework: Email Address Internationalization", Frank Ellermann, 13-Nov-11, UTF8SMTP is an extension of SMTP (Simple Mail Transfer Protocol) allowing the use of UTF-8 in the SMTP envelope for EAI (Email Address Internationalization) and message headers. This memo discusses the consequences for SPF (Sender Policy Framework). Editorial note This note, the IANA considerations (Section 6), and the document history (Appendix A) should be removed before publication. For some imported terms in Section 1.1 the sources have to be fixed. The draft can be discussed on the mailing list. "Better Approach To Mobile Ad-hoc Networking (B.A.T.M.A.N.)", Axel Neumann, Corinna Aichele, Marek Lindner, Simon Wunderlich, 7-Apr-08, This document specifies a simple and robust algorithm for establishing multi-hop routes in mobile ad-hoc networks. It ensures highly adaptive and loop-free routing while causing only low processing and traffic cost. "PCEP extensions for a BGP/MPLS IP-VPN", Kenji Kumaki, Tomoki Murai, Dhruv Dhody, PENG JIANG, 30-Oct-11, IP Virtual Private Networks (IP-VPNs) allow Service Providers to offer customers connectivity between sites across an IP Backbone. These VPNs can be supported using BGP/MPLS and the connections can be created by using MPLS Traffic Engineered (TE) Label Switched Paths (LSPs). The paths of these LSPs must be computed to provide the connectivity between customer sites. Path selection may be dependent on a variety of factors including traffic engineering constraints and bandwidth requirements. It is highly desirable for VPN customers to be able to dynamically establish their MPLS TE LSPs for interconnectivity between BGP/MPLS IP-VPN sites. The Path Computation Element (PCE) can determine the optimal paths of TE LSPs within an MPLS network. This document defines the PCEP extensions for the dynamic creation of MPLS TE LSPs between BGP/MPLS IP-VPN sites. "ECC in OpenPGP", Andrey Jivsov, 27-Sep-11, This document proposes an Elliptic Curve Cryptography extension to the OpenPGP public key format and specifies three Elliptic Curves that enjoy broad support by other standards, including NIST standards. The document aims to standardize an optimal but narrow set of parameters for best interoperability and it does so within the framework it defines that can be expanded in the future to allow more choices. "Labels for Common Location-Based Services", Andrea Forte, Henning Schulzrinne, 15-Jan-10, This document creates a registry for describing the types of services available at a specific location. The registry is expected to be referenced by other protocols that need a common set of service terms as protocol constants. In particular, we define location-based service as either a point at a specific geographic location (e.g., bus stop) or a service covering a specific region (e.g., pizza delivery). "Random Data Encryption Mechanism (RDEM)", Mukul Jaitly, 1-Jun-08, This document describe an data encryption specification which is based on random bytes selection of data and random key generation. This encryption process accepts variable input and the key size is dependent on the input data. This encryption process does not depend upon any 128 or 256 fixed block encryption. The mechanism for encryption is simpler to implement, but gives key complexity of more than 256 bit encryption. "BGP Extended Community for QoS Marking", Thomas Martin Knoll, 6-Jan-12, This document specifies a simple signalling mechanism for inter- domain QoS marking using several instances of a new BGP Extended Community. Class based packet marking and forwarding is currently performed independently within ASes. The new QoS marking community makes the targeted Per Hop Behaviour within the IP prefix advertising AS and the currently applied marking at the interconnection point known to all access and transit ASes. This enables individual (re-)marking and possibly forwarding treatment adaptation to the original QoS class setup of the respective originating AS. The extended community provides the means to signal QoS markings on different layers, which are linked together in QoS Class Sets. It provides inter-domain and cross-layer insight into the QoS class mapping of the source AS with minimal signalling traffic. "ISP Shared Address", Ikuhei Yamagata, Shin Miyakawa, Akira Nakagawa, Jiro Yamaguchi, Hiroyuki Ashida, 5-Jan-12, This document defines IPv4 ISP Shared Address to be jointly used among Internet Service Providers (ISPs). This space is intended to be used in NAT444 model which is used during the transition period to IPv6. "The application/opensearchdescription+xml media type", Frank Ellermann, 13-Nov-11, This draft suggests to register the application/opensearchdescription+xml media type for OpenSearch descriptions. Atom and XHTML elements are examples where this media type is used. "MVPN: Optimized use of PIM via MS-PMSIs", Yiqun Cai, Eric Rosen, IJsbrand Wijnands, Maria Napierala, Arjen Boers, 6-Feb-12, This document specifies an optimized method that a service provider can use to provide MVPN service when using PIM as the MVPN control protocol. As in prior MVPN methods, PIM control messages are sent over multicast tunnels through the provider network. However, unlike older MVPN methods, the tunnels are only created if they are needed to carry multicast data traffic; no tunnels are used only for control traffic. "Management Information Base for Cryptographically Generated Addresses (CGA)", Alberto Garcia-Martinez, Marcelo Bagnulo, 14-Oct-11, This memo defines a portion of the Management Information Base (MIB) for managing Cryptographically Generated Addresses (CGA). "Management Information Base for the SEcure Neighbor Discovery (SEND) protocol", Alberto Garcia-Martinez, Marcelo Bagnulo, 14-Oct-11, This memo defines a portion of the Management Information Base (MIB) for managing the SEND (SEcure Neighbor Discovery) Protocol. "SACK-IMMEDIATELY Extension for the Stream Control Transmission Protocol", Michael Tuexen, Irene Ruengeler, Randall Stewart, 29-Oct-11, This document defines a method for the sender of a DATA chunk to indicate that the corresponding SACK chunk should be sent back immediately and not be delayed. "Signaling RSVP-TE P2MP LSPs in an Inter-domain Environment", Zafar Ali, Rakesh Gandhi, Cisco Systems, 10-Feb-12, Point-to-MultiPoint (P2MP) Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may be established using signaling techniques described in [RFC4875]. However, [RFC4875] does not address many issues that come when a P2MP-TE LSP is signaled in inter-domain networks. Specifically, one of the issues in inter- domain networks is how to allow computation of a loosely routed P2MP-TE LSP such that it is re-merge free. Another issue is reoptimization of a P2MP-TE tree vs. reoptimization of an individual destination sub-LSP, as loosely routing domain border node is not aware of the reoptimization scope. This document provides a framework and required protocol extensions needed for establishing, controlling and reoptimizing P2MP MPLS and GMPLS TE LSPs in inter-domain networks. This document borrows inter-domain TE terminology from [RFC 4726], e.g., for the purposes of this document, a domain is considered to be any collection of network elements within a common sphere of address management or path computational responsibility. Examples of such domains include Interior Gateway Protocol (IGP) areas and Autonomous Systems (ASes). "The References Header for SIP", Dale Worley, 10-Oct-11, This document defines a SIP extension header, References, to be used within SIP messages to signify that the message (and the dialog containing it) is related to one or more other dialogs. It is expected to be used largely for diagnostic purposes. "BGP Class of Service Interconnection", Thomas Martin Knoll, 13-Nov-11, This document focuses on Class of Service Interconnection at inter- domain interconnection points. It specifies two new transitive attributes, which enable adjacent peers to signal Class of Service Capabilities and certain Class of Service admission control Parameters. The new "CoS Capability" is deliberately kept simple and denotes the general EF, AF Group BE and LE forwarding support across the advertising AS. The second "CoS Parameter Attribute" is of variable length and contains a more detailed description of available forwarding behaviours using the PHB id Code encoding. Each PHB id Code is associated with rate and size based traffic parameters, which will be applied in the ingress AS Border Router for admission control purposes to a given forwarding behaviour. "GDOI Generic Message Authentication Code Policy", Brian Weis, Sheela Rowles, 13-Sep-11, A number of IETF signaling and routing applications require a set of devices to share the same policy and keying material and include a message authentication code in their protocols packets for authentication . It is often beneficial for this keying material to be chosen dynamically using a group key management protocol. This memo describes the policy required for the Group Domain of Interpretation (GDOI) group key management system to distribute a message authentication code key and associated policy. "Auto Issued X.509 Certificate Mechanism (AIXCM)", Thierry Moreau, 6-Aug-08, The Transport Layer Security (TLS) protocol does not support the use of client public key pairs without X.509 security certificates. This document circumvents this limitation: an end-entity has access to the public domain private key of a dummy (or "explicitly meaningless") Certification Authority (CA), and can thus freely issue an X.509 security certificate for interoperability purposes. Given these workaround requirement and solution approach, the document limits itself to the strict minimal set of standardization provisions. This supports the orderly cohabitation of auto issued certificates and normal TLS traffic relying on the full Public Key Infrastructure (PKI) model. "PF_KEY Extension as an Interface between Mobile IPv6 and IPsec/IKE", Arnaud Ebalard, Sebastien Decugis, 30-Sep-10, This document describes the need for an interface between Mobile IPv6 and IPsec/IKE and shows how the two protocols can interwork. An extension of the PF_KEY framework is proposed which allows smooth and solid operation of IPsec/IKE in a Mobile IPv6 environment. This document is heavily based on a previous draft [MIGRATE] written by Shinta Sugimoto, Masahide Nakamura and Francis Dupont. It simply reuses the MIGRATE mechanism defined in the expired document, removes a companion extension (SADB_X_EXT_PACKET) based on implementation feedback (complexity, limitations, ...) and fills the gap by very simple changes to MIGRATE mechanism. This results in a more simple and consistent mechanism, which also proved to be easier to implement. This document is expected to serve as a continuation of [MIGRATE] work. For that reason, the name of the extension has been kept. PF_KEY MIGRATE message serves as a carrier for updated information for both the in-kernel IPsec structures (Security Policy Database / Security Association Database) and those maintained by the key managers. This includes in-kernel Security Policy / Security Association endpoints, key manager maintained equivalents, and addresses used by IKE_SA (current and to be negotiated). The extension is helpful for assuring smooth interworking between Mobile IPv6 and IPsec/IKE for the bootstrapping of mobile nodes and their movements. "Fast Connectivity Restoration Using BGP Add-path", Pradosh Mohapatra, Rex Fernando, Clarence Filsfils, Robert Raszuk, 2-Oct-11, A BGP route defines an association of an address prefix with an "exit point" from the current Autonomous System (AS). If the exit point becomes unreachable due to a failure, the route becomes invalid. This usually triggers an exchange of BGP control messages after which a new BGP route for the given prefix is installed. However, connectivity can be restored more quickly if the router maintains precomputed BGP backup routes. It can then switch to a backup route immediately upon learning that an exit point is unreachable, without needing to wait for the BGP control messages exchange. This document specifies the procedures to be used by BGP to maintain and distribute the precomputed backup routes. Maintaining these additional routes is also useful in promoting load balancing, performing maintenance without causing traffic loss, and in reducing churn in the BGP control plane. "Interactions between PMIPv6 and MIPv6: scenarios and related issues", Gerardo Giaretta, 28-Oct-10, The use of Proxy Mobile IPv6 (PMIPv6) and Mobile IPv6 (MIPv6) in the same network requires some care. This document discusses scenarios where such mixed usage is appropriate and points out the need for interaction between the two mechanisms. Solutions and recommendations to enable these scenarios are also described. "Service Differentiation Using Virtualization of Mobile Network", Eun Paik, Chulhyun Park, 23-Oct-11, A mobile network can be multihomed as described in [RFC4980]. This document describes the experimental result of service differentiation using multihoming with multiple prefixes. The multiple prefixes in IPv6 NEMO implements multiple virtual mobile networks on a single physical NEMO. The multiple virtual mobile networks provide service differentiation on a single mobile network. Each mobile network node inside the mobile network prioritizes for service differenciation. It can be differenciated among the virutal mobile networks or forwarding traffic from each virtual mobile network to different access networks. In this experiment, a mobile router with multiple interfaces can make connection to several access networks simultaneoulsly. "PMIPv6 Extensions for PIM-SM", Hitoshi Asaeda, Pierrick Seite, Jinwei Xia, 31-Oct-11, This document describes Proxy Mobile IPv6 (PMIPv6) extensions to support IP multicast. The Mobile Access Gateway (MAG) and the Local Mobility Anchor (LMA) are the mobility entities defined in the PMIPv6 protocol and act as PIM-SM routers. The proposed protocol extension addresses the tunnel convergence problem and provides seamless handover. This document defines the Proxy Binding Update and the Proxy Binding Acknowledgement messages with multicast extension. "Healthy Food and Special Dietary Requirements for IETF meetings", Mary Barnes, 31-Oct-11, This document describes the basic requirements for food for folks that attend IETF meetings require special diets, as well as those that prefer to eat healthy. While, the variety of special diets is quite broad, the most general categories are described. There can be controversy as to what constitutes healthy eating, but there are some common, generally available foods that comprise the basis for healthy eating and special diets. This document provides some recommendations to meeting planners, as well as participants, in handling these requirements. "Problems with the use of IPsec as the security protocol for Mobile IPv6", Basavaraj Patil, Charles Perkins, Hannes Tschofenig, Domagoj Premec, 10-Oct-11, Mobile IPv6 as specified in RFC3775 relies on IPsec for securing the signaling messages and user plane traffic between the mobile node and home agent. An IPsec SA between the mobile node and the home agent provides security for the mobility signaling. Use of IPsec for securing the data traffic between the mobile node and home agent is optional. This document analyses the implications of the design decision to mandate IPsec as the default security protocol for Mobile IPv6 and consequently Dual-stack Mobile IPv6 and recommends revisiting this decision in view of the experience gained from implementation and adoption in other standards bodies. "NAT444 addressing models", Jiro Yamaguchi, Yasuhiro Shirasaki, Shin Miyakawa, Akira Nakagawa, Hiroyuki Ashida, 5-Jan-12, This document describes addressing models of NAT444. There are some addressing models of NAT444. The addressing models have some issues of network behaviors, operations, and addressing. This document helps network architects to use NAT444 after IPv4 address exhaustion. "Takeover Suggestion Flag for the ENRP Handle Update Message", Thomas Dreibholz, Xing Zhou, 31-Dec-11, This document describes the Takeover Suggestion Flag for the ENRP_HANDLE_UPDATE message of the ENRP protocol. "A Record of Discussions of Graceful Restart Extensions for Bidirectional Forwarding Detection (BFD)", Palanivelan Appanasamy, 17-Nov-11, This document is a historical record of discussions about extending the Bidirectional Forwarding Detection (BFD) protocol to provide additional capabilities to handle Graceful Restart. These discussions took place in the context of the IETF's BFD working group, and the consensus in that group was that these extensions should not be made. This document presents a summary of the challenges to BFD in surviving a graceful restart, and outlines a potential protocol solution that was discussed and rejected within the BFD working group. The purpose of this document is to provide a record of the work done so that future effort will not be wasted. This document does not propose or document any extensions to BFD, and there is no intention that it should be implemented in its current form. "Session Initiation Protocol (SIP) Header Parameter for Debugging", Peter Dawes, 24-Oct-11, Networks that use SIP to start and stop sessions between their users will frequently be upgraded with software and hardware changes. Users will similarly frequently change their client software and the way they use the network. In order to allow troubleshooting and regression testing, it is useful to provide debugging as part of the network fabric. This draft describes an event package that provides debugging configuration to SIP entities and a SIP private header that triggers logging of SIP signalling and identifies logs at mulitiple SIP entities as belonging to a single end-to-end session. "Service Identifiers for HIP", Tobias Heer, Hanno Wirtz, Samu Varjonen, 4-Sep-11, The Host Identity Protocol [RFC5201] is a signaling protocol for secure communication, mobility, and multihoming that introduces a cryptographic namespace. This document specifies an extension for HIP that enables HIP end-hosts and HIP-aware middleboxes to announce services to HIP hosts during a HIP Base EXchange (BEX) or HIP update. Service providers are able to specify the type and requirements of a service; clients can then decide to agree on the terms of service. This allows the service provider to verify the accordance of the client with the service conditions while the client is able to verify the authenticity of the used service. "Top Level Domain Name Specification", Lars-Johan Liman, Joe Abley, 29-Nov-11, The syntax for allowed Top-Level Domain (TLD) labels in the Domain Name System (DNS) is not clearly applicable to the encoding of Internationalised Domain Names (IDNs) as TLDs. This document provides a concise specification of TLD label syntax based on existing syntax documentation, extended minimally to accommodate IDNs. This document updates RFC1123. "MPLS-TP OAM based on Y.1731", Italo Busi, Huub van Helvoort, Jia He, 11-Jan-12, This document describes methods to leverage Y.1731 [2] Protocol Data Units (PDU) and procedures (state machines) to provide a set of Operation, Administration, and Maintenance (OAM) mechanisms that meets the MPLS Transport Profile (MPLS-TP) OAM requirements as defined in [8]. In particular, this document describes the MPLS-TP technology specific encapsulation mechanisms to carry these OAM PDUs within MPLS-TP packets to provide MPLS-TP OAM capabilities in MPLS-TP networks. "HTTP Live Streaming", Roger Pantos, 30-Sep-11, This document describes a protocol for transferring unbounded streams of multimedia data. It specifies the data format of the files and the actions to be taken by the server (sender) and the clients (receivers) of the streams. It describes version 4 of this protocol. "Locating CalDAV and CardDAV services", Cyrus Daboo, 16-Sep-10, This specification describes how DNS SRV records, DNS TXT records and well-known URIs can be used together or separately to locate Calendaring Extensions to WebDAV (CalDAV) or vCard Extensions to WebDAV (CardDAV) services. "The i;codepoint collation", Bjoern Hoehrmann, 14-Sep-10, This memo describes the "i;codepoint" collation. Character strings are compared based on the Unicode scalar values of the characters. The collation supports equality, substring, and ordering operations. "DHCPv4 Options for Home Information Discovery in Dual Stack MIPv6", Frank Xia, Behcet Sarikaya, 10-Jan-12, This document defines DHCPv4 options for dynamic discovery of home network information in Dual Stack Mobile IPv6. New DHCPv4 options are defined which allow a mobile node to request the home agent IPv4/v6 address, FQDN, or home network prefix and obtain it via the DHCPv4 response. "The Subnetwork Encapsulation and Adaptation Layer (SEAL)", Fred Templin, 19-Dec-11, For the purpose of this document, a subnetwork is defined as a virtual topology configured over a connected IP network routing region and bounded by encapsulating border nodes. These virtual topologies are manifested by tunnels that may span multiple IP and/or sub-IP layer forwarding hops, and can introduce failure modes due to packet duplication, packet reordering, source address spoofing and traversal of links with diverse Maximum Transmission Units (MTUs). This document specifies a Subnetwork Encapsulation and Adaptation Layer (SEAL) that addresses these issues. "A Session Initiation Protocol (SIP) Event Package for Communication Diversion Information in support of the Communication Diversion (CDIV) Notification (CDIVN) CDIV service", Ranjit Avasarala, John Bakker, 20-Oct-11, 3GPP and TISPAN are defining the protocol specification for the Communication Diversion (CDIV) service using IP Multimedia (IM) Core Network (CN) subsystem supplementary service. As part of CDIV, a SIP based Event package framework is used for notifying users about diversions (re-directions or forwarding) of their incoming communication sessions. This document proposes a new SIP event package for allowing users to subscribe to and receive such notifications. Users can further define filters to control the rate and content of such notifications. The proposed event package is applicable to the CDIV supplementary service in IMS and may not be applicable to the general internet. . "PCEP Extensions for WSON Impairments", Young Lee, Greg Bernstein, Jonas Martensson, Tomonori Takeda, Takehiro Tsuritani, 6-Jan-12, 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 in path computation process in wavelength switched optical networks. This document provides PCEP extensions to support Impairment Aware Routing and Wavelength Assignment (IA-RWA) in wavelength switched optical networks. "Virtual Enterprise Traversal (VET)", Fred Templin, 19-Dec-11, Enterprise networks connect hosts and routers over various link types, and often also connect to provider networks and/or the global Internet. Enterprise network nodes require a means to automatically provision addresses/prefixes and support internetworking operation in a wide variety of use cases including Small Office, Home Office (SOHO) networks, Mobile Ad hoc Networks (MANETs), ISP networks, multi-organizational corporate networks and the interdomain core of the global Internet itself. This document specifies a Virtual Enterprise Traversal (VET) abstraction for autoconfiguration and operation of nodes in enterprise networks. "Web Categories", Sam Johnston, 29-Sep-11, This document specifies the Category header-field for HyperText Transfer Protocol (HTTP), which enables the sending of taxonomy information in HTTP headers in a similar fashion to that employed by Atom. "LISP Mobile Node", Dino Farinacci, Darrel Lewis, Dave Meyer, Chris White, 24-Oct-11, This document describes how a lightweight version of LISP's ITR/ETR functionality can be used to provide seamless mobility to a mobile node. The LISP Mobile Node design described in this document uses standard LISP functionality to provide scalable mobility for LISP mobile nodes. "Design Considerations for Protocol Extensions", Brian Carpenter, Bernard Aboba, Stuart Cheshire, 30-Oct-11, This document discusses issues related to the extensibility of Internet protocols, with a focus on architectural design considerations. It is intended to assist designers of both base protocols and extensions. Case studies are included. "Global HA to HA Protocol Specification", Ryuji Wakikawa, Romain Kuntz, Zhenkai Zhu, Lixia Zhang, 2-Sep-11, This document presents a revised version of the global HAHA protocol specification. Global HAHA allows the deployment of Home Agents over the Internet for reliability, scalability and performance purposes. This version clarifies several issues that were vague in the original specification. Global HAHA makes use of the signaling defined by the Home Agent Reliability protocol (HARP) although it is not designed to operate in conjunction with HARP. "The RADIUS-Diameter Gateway (RADIA) Application", Glen Zorn, Lionel Morand, Tom Hiller, 22-Aug-11, This document describes the Diameter RADIUS-Diameter Gateway (RADIA) Application, which is designed to facillitate the interoperability of Authentication, Authorization and Accounting (AAA) systems based upon RADIUS and Diameter. "Mechanisms for Media Source Selection in the Session Description Protocol (SDP)", Jonathan Lennox, Henning Schulzrinne, 24-Jan-12, Source-specific media attributes in the Session Description Protocol (SDP) allow endpoints to describe Real-Time Transport Protocol (RTP) sources within a media stream. This document extends that mechanism by defining how participants in a multimedia session can request specific sources from a remote party. "Virtual Network Management Information Model", Hideki Okita, Masahiro Yoshizawa, Toshiaki Suzuki, Tomoyuki Iijima, 23-Oct-11, Virtual switches on server virtualization platforms cause a problem in managing data center networks containing several hundred switches. Accordingly, a management information model for the network structure of data center networks containing virtual switches is proposed. The proposed model consists of a physical layer (which represents connections between physical switches) and a virtual layer (which represents connections between virtual switches). These layers also represent the association of the virtual switch with the corresponding physical switch. This document also provides implementation examples of proposed information model in XML and Yang. "Recommendations for the Remediation of Bots in ISP Networks", Jason Livingood, Nirmal Mody, Michael O'Reirdan, 9-Jan-12, This document contains recommendations on how Internet Service Providers can manage the effects of computers used by their subscribers, which have been infected with malicious bots, via various remediation techniques. Internet users with infected computers are exposed to risks such as loss of personal data, as well as increased susceptibility to online fraud. Such computers can also become an inadvertent participant in or component of an online crime network, spam network, and/or phishing network, as well as be used as a part of a distributed denial of service attack. Mitigating the effects of and remediating the installations of malicious bots will make it more difficult for botnets to operate and could reduce the level of online crime on the Internet in general and/or on a particular Internet Service Provider's network. "Extranet in BGP Multicast VPN (MVPN)", Rahul Aggarwal, Yakov Rekhter, Thomas Morin, Wim Henderickx, Praveen Muley, Ray Qiu, 31-Jan-12, This document describes clarifications and extensions to the procedures in [BGP-MVPN] for supporting extranets. The procedures specified in this document assume that BGP is used for transmission of MVPN customers' multicast routing information within the service provider(s) infrastructure. "Session Recording for Conferences using SMIL", Alessandro Amirante, Tobia Castaldi, Lorenzo Miniero, Simon Romano, 20-Dec-11, This document deals with session recording, specifically for what concerns recording of multimedia conferences, both centralized and distributed. Each involved media is recorded separately, and is then properly tagged. A SMIL [W3C.CR-SMIL3-20080115] metadata is used to put all the separate recordings together and handle their synchronization, as well as the possibly asynchronous opening and closure of media within the context of a conference. This SMIL metadata can subsequently be used by an interested user by means of a compliant player in order to passively receive a playout of the whole multimedia conference session. The motivation for this document comes from our experience with our conferencing framework, Meetecho, for which we implemented a recording functionality. "Proxy Mobile IPv6 Management Information Base", Glenn Keeni, Kazuhide Koide, Sri Gundavelli, Ryuji Wakikawa, 25-Oct-11, This memo defines a portion of the Management Information Base (MIB), the Proxy Mobile-IPv6 MIB, for use with network management protocols in the Internet community. In particular, the Proxy Mobile-IPv6 MIB can be used to monitor and control the mobile access gateway (MAG) and the local mobility anchor (LMA) functions of a Proxy Mobile IPv6 (PMIPv6) entity. "RTP Payload Format for DRA Audio", Mao Xu, ChuSheng Zheng, Tian Jiang, WeiXiong Zhang, JingPing Zhang, 23-Aug-09, The present document describes a RTP packaging scheme for DRA compressed audio data transmission, as well as the corresponding RTP payload format. According to the properties of DRA compressed audio frame and the Maximum Transmission Unit (MTU) of network, the scheme provides 3 packaging modes for different coding and transmission requirements. "Chinese Common Name to Uniform Resource Identifier(URI) Dynamic Delegation Discovery System(DDDS) Application(CCN)", Jiankang Yao, XiaoDong Lee, 11-Sep-09, This document discusses the use of the Domain Name System(DNS) for storage of Chinese Common Name to URI mapping. More specifically, how DNS can be used for identifying URIs or services associated with the Chinese Common Names. The method used to discover the mapping is the Dynamic Delegation Discovery System, which can be found in a series of documents specified in RFC 3401. Understanding of RFC 3401 is necessary for understanding this document. "The Network Access Identifier", Alan DeKok, 10-Sep-11, In order to provide roaming services, it is necessary to have a standardized method for identifying users. This document defines the syntax for the Network Access Identifier (NAI), the user identity submitted by the client during network authentication. "Roaming" may be loosely defined as the ability to use any one of multiple Internet Service Providers (ISPs), while maintaining a formal, customer-vendor relationship with only one. Examples of where roaming capabilities might be required include ISP "confederations" and ISP-provided corporate network access support. This document is a revised version of RFC 4282 [RFC4282], which addresses issues with international character sets, as well as a number of other corrections to the previous document. "Link Management Protocol (LMP) extensions for G.709 Optical Transport Networks", Fatai Zhang, Dan Li, Daniele Ceccarelli, Diego Caviglia, Guoying Zhang, Pietro Grandi, Sergio Belotti, 13-Oct-11, Recent progress of the Optical Transport Network (OTN) has introduced new signal types (i.e., ODU0, ODU4, ODU2e and ODUflex) and new Tributary Slot granularity (1.25Gbps). Since equipments deployed prior to recently defined ITU-T recommendations only support 2.5 Gbps Tributary Slot granularity and ODU1, ODU2 and ODU3 containers, the compatibility problem should be considered. In addition, a Higher Order ODU (HO ODU) link may not support all the types of Lower Order ODU (LO ODU) signals defined by the new OTN standard because of the limitation of the devices at the two ends of a link. In these cases, the control plane is required to run the capability discovering functions for the evolutive OTN. This document describes the extensions to the Link Management Protocol (LMP) needed to discover the capability of HO ODU link, including the granularity of Tributary Slot to be used and the LO ODU signal types that the link can support. "AFS Callback Extensions (Draft 14)", Matthew Benjamin, 12-Dec-11, AFS cache-control strategy is callback (invalidate) based. The AFS callback design allows a client to know when an object it has cached is no longer consistent, but the callback notification message itself provides no specific information about the triggering event. This is a protocol inefficiency, as in several scenarios it results in unnecessary round-trips to file servers to verify file status information, file access information, or to fetch file data which has not changed. We propose an extension of the callback mechanism to provide information about the event(s) triggering a callback, in the payload of the callback notification message itself. The proposed mechanism eliminates most or all unnecessary round-trips imposed by the current callback mechanism, and simultaneously allows AFS implementations to (efficiently) provide correct semantics in several scenarios involving multiple writers (ie, where AFS currently provides incorrect semantics). "Control Word Reserved bit for use in E-Tree", Simon DeLord, Raymond Key, Frederic JOUNAY, Wim Henderickx, Lucy Yong, LiZhong Jin, 16-Oct-11, The extension described in this document allows a pair of PEs connected via an Ethernet Pseudowire (PW) to signal via the use of the Control Word (CW) whether the Ethernet frame encapsulated is coming from a Root AC or a Leaf AC. This allows a PE receiving this frame to decide whether it can be forwarded to a Leaf AC or not. Such forward or drop decision is an additional filtering action after the MAC-based forwarding decision. This applies to both P2P PW and P2MP PW. "An Overview of Operations, Administration, and Maintenance (OAM) Mechanisms", Tal Mizrahi, 7-Oct-09, Operations, Administration, and Maintenance (OAM) is a general term that refers to detecting and reporting link failures. OAM mechanisms have been defined for various layers in the protocol stack, and are used with a variety of protocols. This document presents an overview of the OAM mechanisms that have been defined and are currently being defined by the IETF, as well as a comparison to other OAM mechanisms that have been defined by the IEEE and ITU-T. "IANA Registration of the SFUACFG Application Service Tags", Michael Procter, Scott Lawrence, 27-Jan-10, This document defines two application service tags for use according to RFC 3958 and RFC 4848 in the automated SIP User Agent configuration procedures defined by the SIP Forum. "A Generic IPv6 Addresses Registration Solution Using DHCPv6", Sheng Jiang, Gang Chen, 10-Aug-11, In the IPv6 address allocation scenarios, host self-generated addresses are notionally conflicted with the network managed address architecture. These addresses need to be registered in the networking management plate for the purposes of central address administration. This document introduces a generic address registration solution using DHCPv6, and defines one new ND option and one new DHCPv6 option in order to propagate the solicitations of registering self-generated addresses. The registration procedure reuses the existing IA_NA in the DHCPv6 protocol. "Extension to VPLS for E-Tree", Raymond Key, Simon DeLord, Frederic JOUNAY, Wim Henderickx, Lucy Yong, LiZhong Jin, 16-Oct-11, This document proposes a simple and effective approach to emulate E-Tree services over an MPLS network. Section 4 presents a minimal extension to the current VPLS architecture defined in [RFC4761] and [RFC4762] to fulfil the specific E-Tree requirement: Leaf cannot communicate with Leaf. Backward compatibility issues are addressed also. "Information Elements for Data Link Layer Traffic Measurement", Shingo Kashima, Kensuke Nakata, Atsushi Kobayashi, 14-Sep-11, This document describes Information Elements related to data link layer. They are used by the IP Flow Information Export (IPFIX) protocol for encoding measured data link layer traffic information. "IBAKE: Identity-Based Authenticated Key Exchange", Violeta Cakulev, Ganapathy Sundaram, Ioannis Broustis, 13-Nov-11, Cryptographic protocols based on public key methods are based on certificates and public key infrastructure (PKI) to support certificate management. The emerging field of Identity Based Encryption protocols allows to simplify the infrastructure requirements via a Private-key Generator (PKG) while providing the same flexibility. However one significant limitation of Identity Based Encryption methods is that the PKG can end up being a de-facto key escrow server with undesirable consequences. Another observed deficiency is a lack of mutual authentication of communicating parties. Here, Identity Based Authenticated Key Exchange (IBAKE) Protocol is specified which does not suffer from the key escrow problem and in addition provides mutual authentication and a perfect forward and backwards secrecy. "ALTO-Like Activities and Experiments in P2P Network Experiment Council", Satoshi Kamei, Tsuyoshi Momose, Takeshi Inoue, Tomohiro Nishitani, 5-Sep-11, This document introduces experiments to clarify how ALTO-like approach was effective to reduce network traffic made by a Council in Japan to harmonize P2P technology with the infrastructure. And this also provides some suggestions that might be useful for ALTO architecture learned through our experiments. "MIF API consideration", Dapeng Liu, Ted Lemon, Yuri Ismailov, Zhen Cao, 31-Oct-11, This document describes an abstract API that provides the minimal functionality required for a program to communicate effectively with peers and services on the network while running on a host that has more than one active network interface. This API is abstract: we describe the functionality that must be provided, not the bindings that should be used to provide that functionality. The functionality described here provides the building blocks from which higher-level APIs might be built, and is not intended to be used directly by typical applications. "Session Policy Framework using EAP", Stephen McCann, Michael Montemurro, 9-Jan-12, This document specifies a framework for implementing a session policy channel using EAP. It defines a standard mechanism by which a mobile device can conduct a session policy exchange with a policy network component, using EAP as a lower layer protocol, to obtain session policies. EAP Re-authentication Protocol is suggested as a mechanism to allow asynchronous use of SIP at upper layers. "NAT444", Ikuhei Yamagata, Yasuhiro Shirasaki, Akira Nakagawa, Jiro Yamaguchi, Hiroyuki Ashida, 5-Jan-12, This document describes one of the network models that are designed for smooth transition to IPv6. It is called NAT444 model. NAT444 model is composed of IPv6, and IPv4 with Carrier Grade (CGN). NAT444 is the only scheme not to require replacing Customer Premises Equipment (CPE) even if IPv4 address exhausted. But it must be noted that NAT444 has serious restrictions i.e. it limits the number of sessions per CPE so that rich applications such as AJAX and RSS feed cannot work well. Therefore, IPv6 which is free from such a difficulty has to be introduced into the network at the same time. In other words, NAT444 is just a tool to make IPv6 transition easy to be swallowed. It is designed for the days IPv4 and IPv6 co-existence. "Advanced Security for IPv6 CPE", Eric Vyncke, Andrew Yourtchenko, Mark Townsley, 31-Oct-11, This document describes how an IPv6 residential Customer Premise Equipment (CPE) can leverage modern security techniques to have strong security, while retaining as much of the end-to-end reachability of IPv6 as possible. It is a re-submission in the framework of the HOMENET working group. The reputation part of this document should leverage the work done in the REPUTE working group of the Application are. "dIVI: Dual-Stateless IPv4/IPv6 Translation", Congxiao Bao, Xing Li, Yu Zhai, Wentao Shang, 30-Oct-11, This document presents the concepts and the implementations of address-sharing dual-stateless IPv4/IPv6 translation (dIVI). The dIVI is an extension of 1:1 stateless IPv4/IPv6 translation with features of IPv4 address sharing and dual translation. The major benefits of those extensions are using public IPv4 addresses more effectively and removing the requirements of DNS64 and ALG, without loosing the stateless, end-to-end address transparency and bidirectional-initiated communications. "A Uniform Resource Name (URN) Namespace for Sources of Law (LEX)", PierLuigi Spinosa, Enrico Francesconi, Caterina Lupo, 6-Sep-11, This document describes a Uniform Resource Name (URN) Namespace Identification (NID) convention as prescribed by the World Wide Web Consortium (W3C) for identifying, naming, assigning, and managing persistent resources in the legal domain. "Secure PSK Authentication for IKE", Dan Harkins, 13-Jan-12, This memo describes a secure pre-shared key authentication method for IKE. It is resistant to dictionary attack and retains security even when used with weak pre-shared keys. "A Framework for E-Tree Service over MPLS Network", Raymond Key, Simon DeLord, Frederic JOUNAY, Lucy Yong, LiZhong Jin, Yuji Kamite, Wim Henderickx, 16-Oct-11, This document proposes a solution framework for supporting Metro Ethernet Forum (MEF) Ethernet Tree (E-Tree) services over a Multiprotocol Label Switching (MPLS) network. The objective is to provide a simple and effective approach to emulate E-Tree services in addition to Ethernet LAN (E-LAN) services on an existing MPLS network. "Performance Evaluation of Routing Protocol for Low Power and Lossy Networks (RPL)", Joydeep Tripathi, Jaudelice Oliveira, JP Vasseur, 16-Aug-11, This document presents a performance evaluation of the Routing Protocol for Low power and Lossy Networks (RPL) for a small outdoor deployment of sensor nodes and for a large scale smart meter network. Detailed simulations are carried out to produce several routing performance metrics using these real-life deployment scenarios. note "Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers", Marc Petit-Huguenin, 31-Oct-11, This document defines two URI schemes that can be used to provision the configuration values needed by the resolution mechanism defined in [RFC5928]. "Transmission of Syslog Messages over TCP", Rainer Gerhards, Chris Lonvick, 1-Jan-12, There have been many implementations and deployments of legacy syslog over TCP for many years. That protocol has evolved without being standardized and has proven to be quite interoperable in practice. This memo describes how TCP has been used as a transport for syslog messages. "Mesh Structured Hierarchical Networking and IPv6", Shyam Bandyopadhyay, 3-Jan-12, This document tries to address an approach for reorganization of entire network in a large address space. It describes how a three- tier mesh structured hierarchy can be established based on fragmenting the entire space into some regions and sub regions inside each of them. It addresses issues which could be relevant to this architecture in the context of IPv6. This document also tries to come out with an approach how IP switch based network can perform as good as ATM network for the processing of real time traffic. "rxgk: GSSAPI based security class for RX", Simon Wilkinson, 10-Jan-12, rxgk is a security class for the RX RPC protocol. It uses the GSSAPI framework to provide authentication, confidentiality and integrity protection. This document provides a general description of rxgk. A further document will provide details of integration with specific RX applications. "Integrating rxgk with AFS", Simon Wilkinson, 10-Jan-12, This document describes how the new GSSAPI based rxgk security class for RX is integrated with the AFS application protocol. It describes a number of extensions to the basic rxgk protocol, clarifies a number of implementation issues, and provides values for the application specific elements of rxgk. "Stateless Automatic IPv4 over IPv6 Encapsulation / Decapsulation Technology: Global SA46T Address Format", Naoki Matsuhira, 5-Jan-12, This document proposes Stateless Automatic IPv4 over IPv6 Encapsulation / Decapsulation Technology (SA46T) Global Address Format. SA46T can apply to organization's network individually, but if coordination between the organizations made, the total number of times of encapsulations and decapusulations can be reduced. That coordination is achieved by using same SA46T address format, that is Global address. This document proposes SA46T Global address format. SA46T is a gateway technology, not protocol. But SA46T Global Address needs IANA assignment, so this document should be categorized standard track or experimental. "Stateless Automatic IPv4 over IPv6 Encapsulation / Decapsulation Technology: Specification", Naoki Matsuhira, 5-Jan-12, This document specifies Stateless Automatic IPv4 over IPv6 Encapsulation / Decapsulation Technology (SA46T) base specification. SA46T makes backbone network to IPv6 only. And also, SA46T can stack many IPv4 networks, i.e. the networks using same IPv4 (private) addresses, without interdependence. "PMIPv6 Multihoming Support for Flow Mobility", Behcet Sarikaya, Frank Xia, 21-Oct-11, This document specifies extensions to Proxy Mobile IPv6 (PMIPv6) for flow mobility support. Binding cache, binding update list and home network prefix option are slighlty extended to allow indicating the home interface and other interfaces. "MVPN: Extranets, Anycast-Sources, 'Hub & Spoke', with PIM Control Plane", Yiqun Cai, Eric Rosen, Rajesh Sharma, IJsbrand Wijnands, 6-Feb-12, This document provides the specification for using the PIM control plane of to provide Multicast Virtual Private Network support for extranets, for anycast sources, and for "hub and spoke" configurations. "Scalable Operation of Address Translators with Per-Interface Bindings", Jari Arkko, Lars Eggert, Mark Townsley, 4-Feb-11, This document explains how to employ address translation in networks that serve a large number of individual customers without requiring a correspondingly large amount of private IPv4 address space. "Architectural Considerations of IP Anycast", Danny McPherson, David Oran, 26-Oct-11, This memo discusses architectural implications of IP anycast, and provides some historical analysis of anycast use by various IETF protocols. "Session Description Protocol (SDP) Alternate Connectivity (ALTC) Attribute", Mohamed Boucadair, Hadriel Kaplan, Robert Gilman, Simo Veikkolainen, 25-Nov-11, This document proposes a mechanism which allows to carry multiple IP addresses, of different address families (e.g., IPv4, IPv6), in the same SDP offer. The proposed attribute solves the backward compatibility problem which plagued ANAT, due to its syntax. "DHCPv6 Prefix Delegation in Long Term Evolution (LTE) Networks", Behcet Sarikaya, Frank Xia, Ted Lemon, 10-Feb-12, As interest on IPv6 deployment is increasing in cellular networks several migration issues are being raised and IPv6 prefix management is the one addressed in this document. Based on the idea that DHCPv6 servers can manage prefixes, we address prefix management issues such as the access router offloading delegation and release tasks of the prefixes to a DHCPv6 server using DHCPv6 Prefix Delegation. The access router first requests a prefix for an incoming mobile node from the DHCPv6 server. The access router may next do stateless or stateful address allocation to the mobile node, e.g. with a Router Advertisement or using DHCP. We also describe prefix management using Authentication Authorization and Accounting servers. "Capability Exchange for Media Plane Security", Peter Dawes, 3-Feb-12, Negotiating the security mechanisms used between a Session Initiation Protocol (SIP) user agent and its next-hop SIP entity is already described in an RFC. This document extends negotiation of a security mechanism to the media plane by defining a new Session Initiation Protocol (SIP) header field parameter to label security mechanisms that apply to the media plane. "Securing HTTP State Management Information", Gonzalo Salgueiro, Paul Jones, 21-Aug-11, Virtually every application on the web today that allows a user to log in or manipulate information stored on a server maintains some form of state management information. Usually, the session context is established through the use of a Uniform Resource Locator (URL) parameter or a Hypertext Transfer Protocol (HTTP) cookie that identifies the session. Without the use of Transport Layer Security (TLS), such an information exchange introduces a security risk. For a variety of reasons, TLS may not be desired or preferred in all situations and, in those cases, users are left vulnerable. This memo provides a simple method for enabling secure exchange of state management information through HTTP in situations where TLS is not employed. "Quick Failover Algorithm in SCTP", Yoshifumi Nishida, Preethi Natarajan, Armando Caro, 16-Sep-11, One of the major advantages in SCTP is supporting multi-homing communication. If a multi-homed end-point has redundant network connections, SCTP sessions can have a good chance to survive from network failures by migrating inactive network to active one. However, if we follow the SCTP standard, there can be significant delay for the network migration. During this migration period, SCTP cannot transmit much data to the destination. This issue drastically impairs the usability of SCTP in some situations. This memo describes the issue of SCTP failover mechanism and discuss its solutions which require minimal modification to the current standard. "Extensions to RSVP-TE for P2MP LSP Ingress Local Protection", Huaimo Chen, Ning So, Autumn Liu, 30-Oct-11, This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for locally protecting the ingress node of a Traffic Engineered (TE) Point-to-MultiPoint (P2MP) Label Switched Path (LSP) in a Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) network. "A Dual-end Recursive PCE-Based Computation (DRPC) Procedure to Compute Shortest Constrained Inter-domain Traffic Engineering Label Switched Paths", Xihua Fu, Yuanlin Bao, Yongli Zhao, Jie Zhang, 30-Aug-11, A dual-end recursive PCE-based computation procedure (DRPC) is proposed to compute shortest constrained inter-domain traffic engineering label switched paths based on BRPC in Multi-protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. By recursively performing shortest path algorithm and transferring the segmental path computation result from both ends bi-directionally, they meet at one of the Middle PCEs, generating a directional shortest path graph into which the two shortest path trees are stitched together. Therefore, the end-to-end constrained inter- domain traffic engineering label switched path, even k shortest paths can be gained from the directional shortest path graph directly. "HIP-based Virtual Private LAN Service (HIPLS)", Tom Henderson, Steven Venema, David Mattes, 3-Sep-11, The Host Identity Protocol (HIP) and architecture adds a cryptographic name space to name Internet hosts. This draft describes a use case of the HIP architecture, which is to provide a HIP-enabled virtual private LAN service (VPLS) over an untrusted network. In this case, HIP is used to secure tunnels between the provider edge (PE) equipment. "Leaf discovery mechanism for mLDP based P2MP/MP2MP LSP", LiZhong Jin, Kebo Liu, Sriganesh Kini, 31-Oct-11, This document describes a mechanism for a root node to discover the leaf nodes of an mLDP based P2MP/MP2MP LSP. Such kind of function could be used for multiplexing/aggregating root initiated and leaf initiated application which will use mLDP based P2MP/MP2MP LSP. Examples of root initiated applications are P2MP PW [I-D.ietf-pwe3-p2mp-pw], VPLS multicast [I-D.ietf-l2vpn-vpls-mcast], L3VPN multicast [I-D.ietf-l3vpn-2547bis-mcast]. And examples of leaf initiated applications are statically configured mLDP based P2MP/ MP2MP LSP, mLDP in-band signaling [I-D.ietf-mpls-mldp-in-band-signaling]. "Security on Demand for Mobile IPv6 and Dual-stack Mobile IPv6", Gabor Bajko, Basavaraj Patil, Teemu Savolainen, 31-Oct-11, Mobile IPv6 and Dual-stack Mobile IPv6 protocols require the signaling messages between the mobile node and home agent to be secured. However security for the user plane/traffic is optional and is a choice left to the mobile node. This document proposes extensions to Mobile IPv6 signaling which enables the user plane traffic to be secured on a need or on-demand basis. The mobile node or the home agent can request at any time security for the user plane traffic. Security for user plane traffic can be triggered as a result of policy or, mobility or, at the user's choice. "Compressed IPFIX for smart meters in constrained networks", Lothar Braun, Corinna Schmitt, Benoit Claise, Georg Carle, 22-Sep-11, This document specifies the Compressed IPFIX protocol that serves for transmitting smart metering data in 6LoWPAN networks [RFC4944]. Compressed IPFIX is derived from IPFIX [RFC5101] and adopted to the needs of constrained networks. This documents specifies how the Compressed IPFIX Data and Template Records are transmitted in 6LoWPAN networks and how Compressed IPFIX data can be converted into uncompressed IPFIX data in a proxy device. "Extensions to RSVP-TE for P2MP LSP Egress Local Protection", Huaimo Chen, Ning So, Autumn Liu, 30-Oct-11, This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for locally protecting egress nodes of a Traffic Engineered (TE) point-to-multipoint (P2MP) Label Switched Path (LSP) in a Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) network. "MPLS-TP Shared Mesh Protection", Tae-sik Cheung, Jeong-dong Ryoo, Yaacov Weingarten, Nurit Sprecher, Daniel King, 31-Oct-11, This document describes a mechanism to address the requirement to support protection of Label Switched Paths (LSPs) in an MPLS Transport Profile (MPLS-TP) mesh topology. The shared mesh protection mechanism enables multiple protection paths within a shared mesh protection domain to share protection resources for the protection of working paths by coordinating protection switching operations according to the priority assigned to each end-to-end linear protection domain. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications Union Telecommunications Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. "Recommendations on filtering of IP packets containing IP options", Fernando Gont, R. Atkinson, 16-Dec-11, This document document provides advice on the filtering of packets based on the IP options they contain. Additionally, it discusses the operational and interoperability implications of such filtering. "PPSP Tracker Protocol", Rui Cruz, Mario Nunes, Gu Yingjie, Jinwei Xia, David Bryan, Joao Taveira, Deng Lingli, 31-Oct-11, This document outlines the functionality required for an HTTP-based P2P Streaming Tracker Protocol, including requirements, functional entities and architecture, components, message flows, with detailed message processing instructions using an HTTP/XML encoding, the respective parameters, methods, and message formats, formal syntax and semantics. The PPSP Tracker Protocol proposed in this document extends the capabilities of PPSP to support adaptive and scalable video and 3D video, for Video On Demand (VoD) and Live video services. The Tracker Protocol is an application-level protocol for peers to publish/request content, provide peer lists to peers and peer status to Trackers. "VPLS PE Model for E-Tree Support", Yuanlong Jiang, Lucy Yong, Manuel Paul, Frederic JOUNAY, Florin Balus, Wim Henderickx, 28-Oct-11, A generic VPLS solution for E-Tree services is proposed which uses VLANs to indicate root/leaf traffic. A VPLS Provider Edge (PE) model is illustrated as an example for the solution. In the solution, E- Tree VPLS PEs are interconnected by PWs which carry the VLAN indicating the E-Tree attribute, the MAC address based Ethernet forwarding engine and the PW work in the same way as before. A signaling mechanism for E-Tree capability and VLAN mapping negotiation is further described. "Extension to the Path Computation Element Communication Protocol for Enhanced Errors and Notifications", Helia Poullyau, Remi Theillaud, Julien Meuric, 29-Sep-11, This document defines new error and notification TLVs for the PCE Communication Protocol (PCEP) [RFC5440]. It identifies the possible PCEP behaviors in case of error or notification. Thus, this draft extends error and notification types in order to associate predefined PCEP behaviors. "Multicast Listener Extensions for MIPv6 and PMIPv6 Fast Handovers", Thomas Schmidt, Matthias Waehlisch, Rajeev Koodli, Gorry Fairhurst, 13-Nov-11, Fast handover protocols for MIPv6 and PMIPv6 define mobility management procedures that support unicast communication at reduced handover latency. Fast handover base operations do not affect multicast communication, and hence do not accelerate handover management for native multicast listeners. Many multicast applications like IPTV or conferencing, though, are comprised of delay-sensitive real-time traffic and will benefit from fast handover execution. This document specifies extension of the Mobile IPv6 Fast Handovers (FMIPv6) and the Fast Handovers for Proxy Mobile IPv6 (PFMIPv6) protocols to include multicast traffic management in fast handover operations. This multicast support is provided first at the control plane by a management of rapid context transfer between access routers, second at the data plane by an optional fast traffic forwarding that MAY include buffering. "Most Efficient Augmented Password-Only Authentication and Key Exchange for IKEv2", SeongHan Shin, Kazukuni Kobara, 6-Jan-12, This document describes an efficient augmented password-only authentication and key exchange (AugPAKE) protocol where a user remembers a low-entropy password and its verifier is registered in the intended server. In general, the user password is chosen from a small set of dictionary whose space is within the off-line dictionary attacks. The AugPAKE protocol described here is secure against passive attacks, active attacks and off-line dictionary attacks (on the obtained messages with passive/active attacks), and also provides resistance to server compromise (in the context of augmented PAKE security). In addition, this document describes how the AugPAKE protocol is integrated into IKEv2. "Protocol for Carrying Authentication for Network Access (PANA) with IPv4 Unspecified Address", Alper Yegin, Yoshihiro Ohba, Lionel Morand, John Kaippallimalil, 16-Dec-11, This document defines how PANA client (PaC) can perform PANA authentication prior to configuring an IP address. "An Extension of HIP Base Exchange to Support Identity Privacy", Dacheng Zhang, Miika Komu, 11-Jan-12, In this document, an extension of HIP Base Exchange (BEX) is proposed protect the identity privacy of HIP hosts. Apart from describing the protocol and packet formats, the applicability and the security strength of the proposed approach are analyzed. This work is based on BLIND [YLI04]. "Xon/Xoff State Control for Telnet Com Port Control Option", Grant Edwards, 23-Mar-10, This document defines new values for use with the telnet com port control option's SET-CONTROL sub-command defined in RFC2217. These new values provide a mechanism for the telnet client to control and query the outbound Xon/Xoff flow control state of the telnet server's physical serial port. This capability is exposed in the serial port API on some operating systems and is needed by telnet clients that implement a port-redirector service which provides applications local to the redirector/telnet-client with transparent access to the remote serial port on the telnet server. "Linear Protection Switching in MPLS-TP", Huub van Helvoort, Jeong-dong Ryoo, Haiyan Zhang, feng huang, Han Li, Alessandro D'Alessandro, 9-Jan-12, This document specifies a linear protection switching mechanism for MPLS-TP. This mechanism supports 1+1 unidirectional/bidirectional protection switching and 1:1 bidirectional protection switching. It is purely supported by MPLS-TP data plane, and can work without any control plane. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications Union Telecommunications Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. "Considerations for Having a Successful "Bar BOF" Side Meeting", Lars Eggert, Gonzalo Camarillo, 15-Aug-11, New work is typically brought to the IETF by a group of interested individuals. IETF meetings are a convenient place for such groups to hold informal get-togethers to discuss and develop their ideas. Such side meetings, which are not reflected in the IETF meeting agenda and have no official status, are often half-jokingly referred to as "bar BOF" sessions, to acknowledge that some of them may eventually lead to a proposal for an official IETF BOF ("birds of a feather" session) on a given topic. During recent IETF meetings, many such "bar BOF" get-togethers have been organized and moderated in ways that made them increasingly indistinguishable from official IETF BOFs or sometimes even IETF working group meetings. This document argues that this recent trend is not helpful in reaching the ultimate goal of many of these get-togethers, i.e., to efficiently discuss and develop ideas for new IETF work. It encourages the organizers to consider the benefits of holding them in much less formal settings, and to also consider alternative means to develop their ideas. This document also recommends that the community abandon the term "bar BOF" and instead use other terms such "side meeting", in order to stress the unofficial nature of these get-togethers. "Issues with Private IP Addressing in the Internet", Anthony Kirkham, 16-Nov-11, The purpose of this document is to provide a discussion of the potential problems of using private, RFC1918, or non-globally- routable addressing within the core of an SP network. The discussion focuses on link addresses and to a small extent loopback addresses. While many of the issues are well recognised within the ISP community, there appears to be no document that collectively describes the issues. "Requirements for MEF E-Tree Support in VPLS", Raymond Key, Simon DeLord, Frederic JOUNAY, Lu Huang, Zhihua Liu, Manuel Paul, Ruediger Kunze, Nick Del Regno, Joshua Rogers, 28-Sep-11, This document provides functional requirements for Metro Ethernet Forum (MEF) Ethernet Tree (E-Tree) support in Virtual Private LAN Service (VPLS). It is intended that potential solutions will use these requirements as guidelines. "The Generic Multiparty Transport Protocol (swift)", Victor Grishchenko, A. Bakker, 26-Oct-11, The Generic Multiparty Protocol (swift) is a peer-to-peer based transport protocol for content dissemination. It can be used for streaming on-demand and live video content, as well as conventional downloading. In swift, the clients consuming the content participate in the dissemination by forwarding the content to other clients via a mesh-like structure. It is a generic protocol which can run directly on top of UDP, TCP, HTTP or as a RTP profile. Features of swift are short time-till-playback and extensibility. Hence, it can use different mechanisms to prevent freeriding, and work with different peer discovery schemes (centralized trackers or Distributed Hash Tables). Depending on the underlying transport protocol, swift can also use different congestion control algorithms, such as LEDBAT, and offer transparent NAT traversal. Finally, swift maintains only a small amount of state per peer and detects malicious modification of content. This documents describes swift and how it satisfies the requirements for the IETF Peer-to-Peer Streaming Protocol (PPSP) Working Group's peer protocol. "LISP Canonical Address Format (LCAF)", Dino Farinacci, Dave Meyer, Job Snijders, 24-Oct-11, This draft defines a canonical address format encoding used in LISP control messages and in the encoding of lookup keys for the LISP Mapping Database System. "Advanced Groupware Access Protocol", Iulian Radu, 17-Nov-11, The Advanced Groupware Access Protocol, (AGAP) allows a client to access and store electronic mail messages, contacts, events, files, and configurations on a server. The electronic mail messages can be grouped in folders. AGAP also provides the capability for an offline client to resynchronize with the server. AGAP does not specify a means of posting electronic mail messages; this function is handled by a mail transfer protocol such as SMTP [RFC2821]. It also does not specify a means for exchanging messages with contacts that are reported as being online; this function is handled by an instant messaging protocol such as XMPP [RFC3921]. AGAP includes the following operations for electronic mail messages: creating, deleting, renaming, moving and coping mail folders; checking for new messages; permanently removing messages; moving and coping messages between folders; fetching information about a message; setting and clearing tags for messages; searching in messages; retrieving only a part of a message; marking messages as SPAM; deleting attachments from a message. AGAP includes the following operations to manipulate the contacts: creating, deleting, moving, coping, tagging, and searching contacts; checking if a contact is online; fetching information about a contact. AGAP includes the following operations related to the use of the events: creating, deleting, moving, coping and tagging events in calendar; fetching events details; searching for events. All entries are read and written in format XML encoded UTF-8 [RFC3629] and each entry is identified by a unique alphanumeric identifier. AGAP is designed to support access only to a single server per connection. It is also designed to balance the volume of text exchanged between the server and clients and its readability by humans for debugging. "Schema for representing resources for calendaring and scheduling services", Ciny Joy, Cyrus Daboo, Mike Douglass, 28-Oct-11, This specification describes a schema for representing resources for calendaring and scheduling. A resource in the scheduling context is any shared entity that can be scheduled by a calendar user, but does not control its own attendance status. "Password Authenticated Connection Establishment with IKEv2", Dennis Kuegler, Yaron Sheffer, 12-Sep-11, IKEv2 does not allow secure peer authentication when using short credential strings, i.e. passwords. Several proposals have been made to integrate password-authentication protocols into IKE. This document provides an adaptation of PACE (Password Authenticated Connection Establishment) to the setting of IKEv2 and demonstrates the advantages of this integration. "Controlling Session Initiation Protocol (SIP)-Established Content Delivery Channels Using the Real-Time Streaming Protocol (RTSP)", Jan Lindquist, Jouni Maenpaa, Priya Rajagopal, Xavier Marjou, 9-Jun-10, The Session Initiation Protocol (SIP) is widely used for establishing multimedia sessions, whereas the Real Time Streaming Protocol (RTSP) is used in streaming media systems. RTSP has a dual role: it establishes a media session for the delivery of streaming media as well as controls the streaming session once it has been set up. Since SIP is also used for session establishment, there exists an overlap between the functionality provided by SIP and RTSP. In this document, we describe a model adopted by ETSI TISPAN, 3GPP, and Open IPTV Forum (OIPF) in which SIP and the SDP offer/answer model are used to set up a streaming session with an RTSP control channel and one or more media delivery streams. Such a model is beneficial since it allows the reuse of current architecture and functionality (e.g., authentication, charging, and QoS) established around SIP for RTSP- based streaming. The model benefits applications such as Internet Protocol Television (IPTV). In addition to the model, the document specifies two new variants of RTSP. "Implications of Full-Duplex HTTP", Wenbo Zhu, Mike Jennings, 17-Nov-11, Full-duplex HTTP follows the basic HTTP request-response semantics but also allows the server to send response data to the client when the client is still transmitting request body to the server. Requirements for Full-duplex HTTP are under-specified in the existing HTTP specification [RFC2616], and this memo intends to clarify the requirements for implementing Full-duplex HTTP on top of the standard HTTP protocol. "MVPN: S-PMSI Join Extensions for mLDP-Created Tunnels", Yiqun Cai, Eric Rosen, IJsbrand Wijnands, 24-Oct-11, The specification for Multicast Virtual Private Networks (MVPN) contains an option that allows UDP-based "S-PMSI Join" messages to be used to bind particular customer multicast flows to particular tunnels through a service provider's network. This document extends the MVPN specification so that these options can be used when the tunnel through the provider's network are Point-to-Multipoint Label Switched Paths. "Protocol for Stage Illumination", Marcus Ertl, 23-Nov-11, This memo describes a protocol that builds upon UDP/IP to transport illumination and control data for stage, architectural and other illumination requirements. It may be understood as a spiritual successor of the traditional DMX (Digital MultipleX) specification series, removing it's limitations and adding flexibility and usability enhancements like auto-discovery and metadata, among other useful features. "Investigation in HIP Proxies", Dacheng Zhang, Xiaohu Xu, Jiankang Yao, Zehn Cao, 30-Oct-11, HIP proxies play an important role in the transition from the current Internet architecture to the HIP architecture. A core objective of a HIP proxy is to facilitate the communication between legacy (or Non- HIP) hosts and HIP hosts while not modifying the host protocol stacks. In this document, the legacy hosts served by proxies are referred to as Legacy Hosts (LHs). Currently, various design solutions of HIP proxies have been proposed. These solutions may be applicable in different working circumstances. In this document, these solutions are investigated in detail to compare their effectiveness in different scenarios. "xNAME RCODE and Status Bits Clarification", Donald Eastlake, 31-Oct-11, The Domain Name System (DNS) has long provided means, such as CNAME (Canonical Name), where a query can be redirected to a different name. A DNS response header has an RCODE (Response Code) field, used for indicating errors, and response status bits. This document clarifies, in the case of such redirected queries, how the RCODE and status bits correspond to the initial query cycle (where the CNAME or the like was detected) and subsequent or final query cycles. "Host Identifier Revocation in HIP", Dacheng Zhang, Dmitriy Kuptsov, Sean Shen, 31-Oct-11, This document mainly analyzes the key revocation issue with host identifiers (HIs) in the Host Identity Protocol (HIP). Generally, key revocation is an important functionality of key management systems; it is concerned with the issues of removing cryptographic keys from operational use when they are not secure or not secure enough any more. This functionality is particularly important for the security systems expected to execute for long periods. This document also attempts to investigate several issues that a designer of HI revocation mechanisms need to carefully consider. "A Mechanism for Session Initiation Protocol (SIP) Avalanche Restart Overload Control", Charles Shen, Henning Schulzrinne, Arata Koike, 15-Dec-11, When a large number of clients register with a SIP registrar server at approximately the same time, the server may become overloaded. Near-simultaneous floods of SIP SUBSCRIBE and PUBLISH requests may have similar effects. Such request avalanches can occur, for example, after a power failure and recovery in a metropolitan area. This document describes how to avoid such overload situations. Under this mechanism, a server estimates an avalanche restart backoff interval during its normal operation and conveys this interval to its clients through a new Restart-Timer header in normal response messages. Once an avalanche restart actually occurs, the clients perform backoff based on the previously received Restart-Timer header value before sending out the first request attempt. Thus, the mechanism spreads all the initial client requests and prevents them from overloading the server. "The ARIA Algorithm and Its Use with the Secure Real-time Transport Protocol(SRTP)", Woo-Hwan Kim, Jungkeun Lee, Dong-Chan Kim, Je-Hong Park, Daesung Kwon, 21-Dec-11, This document describes the use of the ARIA block cipher algorithm within the Secure Real-time Transport Protocol (SRTP) for providing confidentiality for the Real-time Transport Protocol (RTP) traffic and for the control traffic for RTP, the Real-time Transport Control Protocol (RTCP). It details three modes of operation (CTR, CCM, GCM) and a SRTP Key Derivation Function for ARIA. "AES-CCM Cipher Suites for TLS", David McGrew, Daniel Bailey, 31-Oct-11, This memo describes the use of the Advanced Encryption Standard (AES) in the Counter and CBC-MAC Mode (CCM) of operation within Transport Layer Security (TLS) to provide confidentiality and data origin authentication. The AES-CCM algorithm is amenable to compact implementations, making it suitable for constrained environments. "Considerations on the AS-Level Application-Layer Traffic Optimization", Hirochika Asai, Hiroshi Esaki, Tsuyoshi Momose, 17-Dec-11, Application-layer or overlay routing has been applied to various distributed systems such as content delivery networks and live media streaming systems. The problems with these systems for the layer 3 network providers, such as Internet service providers, are that these systems utilize higher-cost network resources (e.g., transit links) from the viewpoint of the layer 3 network providers but the operators have difficulties in controlling and optimizing the traffic of these systems because these systems construct their own networks over the layer 3 network. The ALTO Working Group has worked on application- layer traffic optimization to fill the gaps in routing policies between the layer 3 network and applications by providing the underlay network topology and cost information to these systems. However, there are considerations on applying application-layer traffic optimization techniques to cross-domain traffic because the cost is assumed to be configured by each AS although ASes are autonomously operated. This document summarizes general problems with overlay networks and considerations on the AS-level application- layer traffic optimization from the viewpoint of inter-AS economics. The main concerns on the AS-level application-layer traffic optimization are unfair policy configuration between distinct administrative domains and asymmetric economic policies on transit links. The underlying problem inducing these concerns is that the economic policies between interconnected ASes are non-disclosure due to commercial contracts. This document also discusses the conceivable approaches to solve the problems and considerations. "Request by JSON ver.1.0 for OAuth 2.0", Nat Sakimura, John Bradley, 26-Oct-11, The authorization request in OAuth 2.0 utilizes query parameter serizalization. This specification defines the authorization request using JWT serialization. The request is sent thorugh 'request' parameter or by reference through 'request_uri' that points to the JWT. "Reputation Reporting Protocol", David Skoll, 16-Dec-11, This draft specifies a protocol for reporting various events associated with IP addresses. These events can be collected and aggregated to form a database containing information about the reputation of IP addresses. "Miscellaneous additions to CoAP", Carsten Bormann, Klaus Hartke, 16-Nov-11, This short I-D makes a number of partially interrelated proposals how to solve certain problems in the CoRE WG's main protocol, the Constrained Application Protocol (CoAP). The current version has been resubmitted to keep information about these proposals available; the proposals are not all fleshed out at this point in time. "Session Initiation Protocol (SIP) History-Info Header Call Flow Examples", Mary Barnes, Francois Audet, Shida Schubert, Detecon Gmbh, Christer Holmberg, 30-Oct-11, This document describes use cases and documents call flows which require the History-Info header field to capture the Request-URIs as a Session Initiation Protocol (SIP) Request is retargeted. The use cases are described along with the corresponding call flow diagrams and messaging details. "Host Identity Protocol Distributed Hash Table Interface", Jeff Ahrenholz, 14-Dec-11, This document specifies a common interface for using the Host Identity Protocol (HIP) with a Distributed Hash Table service to provide a name-to-Host-Identity-Tag lookup service and a Host- Identity-Tag-to-address lookup service. "HIP support for RFIDs", Pascal Urien, Gyu Myoung Lee, Guy Pujolle, 30-Oct-11, This document describes an architecture based on the Host Identity Protocol (HIP), for active RFIDs, i.e. Radio Frequency Identifiers including tamper resistant computing resources, as specified for example in the ISO 14443 or 15693 standards. HIP-RFIDs never expose their identity in clear text, but hide this value (typically an EPC- Code) by a particular equation that can be only solved by a dedicated entity, referred as the portal. HIP exchanges occur between HIP-RFIDs and portals; they are transported by IP packets, through the Internet cloud. "A RELOAD Usage for Distributed Conference Control (DisCo)", Alexander Knauf, Gabriel Hege, Thomas Schmidt, Matthias Waehlisch, 31-Oct-11, This document defines a RELOAD Usage for Distributed Conference Control (DisCo) with SIP. DisCo preserves conference addressing through a single SIP URI by splitting its semantic of identifier and locator using a new Kind data structure. Conference members are enabled to select conference controllers based on proximity awareness and to recover from failures of individual resource instances. DisCo proposes call delegation to balance the load at focus peers. "Uniform Resource Identifier (URI) Scheme for Digital Video Broadcasting (DVB) Programme Resources", Mo McRoberts, Alexander Adolf, 5-Sep-11, Uniform Resource Identifier (URI) schemes for broadcasting programme resources transmitted over MPEG-2 Transport Streams [MPEG-Systems] have been devised in their process of creating standards by the Digital Video Broadcasting Project (DVB), the Association of Radio Industries and Businesses in Japan (ARIB) and the OpenCable Application Platform (OCAP) to acquire current and future scheduled publications of broadcast media content from multimedia applications such as HTTP, MHP [DVB-MHP], OCAP [OCAP1.0] or other XML based metadata. These URI are used to locate the actual digital TV, Radio or other multimedia broadcast programme services (i.e., channels or events) and also the audio-visual components related to that programme, for example an HTTP-based programme guide on the Web or other XML-based electronic programme guides in digital broadcast receivers. This document defines the "dvb" URI scheme for the benefit of the Internet community, given its definition as part of the Digital Video Broadcasting (DVB) suite of ETSI standards. "Rapid acquisition of the MN multicast subscription after handover", Luis Contreras, Carlos Bernardos, Ignacio Soto, 31-Oct-11, A new proposal is presented for speeding up the acquisition by the MAG of the MN's active multicast subscription information, in order to accelerate the multicast delivery to the MN after a handover. To do that, an extension to the current PMIPv6 protocol is proposed. The solution described in this memo is not only applicable to the base solution for multicast support in PMIPv6, but also it can be applied to other solutions envisioned as possible architectural evolutions of it. Furthermore, it is also independent of the role played by the MAG within the multicast network (either acting as MLD proxy or multicast router). "Media Types for Sensor Markup Language (SENML)", Cullen Jennings, Zach Shelby, Jari Arkko, 20-Jan-12, This specification defines media types for representing simple sensor measurements and device parameters in the Sensor Markup Language (SenML). Representations are defined in JavaScript Object Notation (JSON), eXtensible Markup Language (XML) and Efficient XML Interchange (EXI), which share the common SenML data model. A simple sensor, such as a temperature sensor, could use this media type in protocols such as HTTP or CoAP to transport the measurements of the sensor or to be configured. "ISIS Protocol Extensions for Boundary Node Discovery (BND)", Dhruv Dhody, Udayasree Palle, 27-Sep-11, There are various circumstances where it is highly desirable to be able to dynamically and automatically discover a set of Boundary Nodes (BN) along with their domain information. For that purpose, this document defines extensions to the Intermediate System to Intermediate System(IS-IS) routing protocol for the advertisement of Boundary Node (BN)Discovery information within an IS-IS area or within the entire IS-IS routing domain. "OSPF Protocol Extensions for Boundary Node Discovery (BND)", Dhruv Dhody, Udayasree Palle, 27-Sep-11, There are various circumstances where it is highly desirable to be able to dynamically and automatically discover a set of Boundary Nodes (BN) along with their domain information. For that purpose, this document defines extensions to the Open Shortest Path First (OSPF) routing protocol for the advertisement of Boundary Node (BN) Discovery information within an OSPF area or within the entire OSPF routing domain. "Load Sharing for the Stream Control Transmission Protocol (SCTP)", Martin Becke, Thomas Dreibholz, Janardhan Iyengar, Preethi Natarajan, Michael Tuexen, 18-Jan-12, The Stream Control Transmission Protocol (SCTP) supports multi-homing for providing network fault tolerance. However, mainly one path is used for data transmission. Only timer-based retransmissions are carried over other paths as well. This document describes how multiple paths can be used simultaneously for transmitting user messages. "Virtual Subnet: A Scalable Data Center Interconnection Solution", Xiaohu Xu, 27-Aug-11, This document proposes a host route based IP-only L2VPN solution called Virtual Subnet, which reuses BGP/MPLS IP VPN [RFC4364] and ARP proxy [RFC925][RFC1027] technologies. Virtual Subnet provides a much scalable approach for interconnecting geographically dispersed data centers. "HIP-based Failure Detection and Recovery for Multihoming", Tao Yuan, Bo Hu, Shanzhi Chen, Qinqin Chu, Zhangfeng Hu, Wenjun Li, 2-Jan-12, Fault tolerance is one of greatest feature of multihomed host. This document proposes a failure detection and communication recovery mechanism for Host Identity Protocol. It can be applied to HIP by using new defined HIP parameters. A HIP-enabled multihomed host can switch to alternative locator if current link breaks down by adopting this mechanism. "Applicability of Stateless automatic IPv4 over IPv6 Encapsulation / Decapsulation Technology (SA46T)", Naoki Matsuhira, 5-Jan-12, This document provide IPv6 transition scenario using Stateless Automatic IPv4 over IPv6 Encapsulation / Decapsulation Technology (SA46T) and applicability of SA46T. SA46T is just one of automatic Encapsulation / Decapsulation technology, so there are several usage with SA46T. This document shows such possible applicability. "CGN Deployment with MPLS/VPNs", Victor Kuarsingh, John Cianfarani, 10-Oct-11, This document specifies a framework to integrate a Network Address Translation layer into an operator's network to function as a Carrier Grade NAT (also known as CGN or Large Scale NAT). CGN is a concept also described in [I-D.shirasaki-nat444] which specifies NAT444 as a dual layer translation model. Although operators may wish to deploy IPv6 to strategically overcome IPv4 exhaustion, near term needs may not be satisfied with an IPv6 deployment alone. This document provides a practical integration model which allows CGN to be integrated into the network meeting the needs of the customer while being mindful of not disrupting existing services and meeting the technical challenges that CGN brings. The model includes the use of MPLS/VPNs defined in [RFC4364] as a tool to achieve this goal. This document does not intend to defend the merits of CGN. "CoAP Utilization for Building Control", Peter Van der Stok, Kerry Lynn, 31-Oct-11, This draft describes an example use of the RESTful CoAP protocol for building automation and control (BAC) applications such as HVAC and lighting. A few basic design assumptions are stated first, then URI structure is utilized to define group as well as unicast scope for RESTful operations. This proposal supports the view that 1) service discovery is complementary to resource discovery and facilitates control network scaling, and 2) building control is likely to move in steps toward all-IP control networks based on the legacy efforts provided by DALI, LON, BACnet, ZigBee, and other standards. The authority portion of the URI is used to identify a device (group) and the resulting DNS name is bound to a unicast (multicast) address. Group addressing has consequence for the naming convention of the resources of a device. Naming of URI is building or organization dependent, must be flexible, and SHOULD conform to some local convention. Naming of resources MUST be standardised preferrable by a building control related organisation. It is shown that DNS-based service discovery can be used to locate URIs on the scale necessary in large commercial BAC deployments. The relation of DNS-SD and a Resource Directory is discussed. Finally, a method is proposed for mapping URIs onto legacy BAC resources, e.g., to discover application-layer gateways, proxies, and their dependent services. "Experiences from an IPv6-Only Network", Jari Arkko, Ari Keranen, 7-Feb-12, This document discusses our experiences from moving a small number of users to an IPv6-only network, with access to the IPv4-only parts of the Internet via a NAT64 device. The document covers practical experiences as well as road blocks and opportunities for this type of a network setup. The document also makes some recommendations about where such networks are applicable and what should be taken into account in the network design. The document also discusses further work that is needed to make IPv6-only networking applicable in all environments. "Peer-to-Peer Epi-Transport Protocol", Riccardo Bernardini, Roberto Fabbro, Roberto Rinaldo, 9-Jan-12, This document describes PPETP (Peer-to-Peer Epi-Transport Protocol) a peer-to-peer distribution protocol suited for streaming applications over networks made of heterogeneous nodes. "LDP extensions for Explicit Pseudowire to transport LSP mapping", Mach Chen, Wei Cao, Attila Takacs, Ping Pan, 27-Oct-11, A bidirectional Pseudowire (PW) service currently uses two unidirectional PWs each carried over a unidirectional LSP. Each end point of a PW or segment of multi-segment PW (MS-PW) independently selects the LSP to use to carry the PW for which it is the head end. Some transport services may require that bidirectional PW traffic follows the same paths through the network in both directions. Therefore, PWs may be required to use LSP with the same paths. Co- routed bidirectional LSPs or unidirectional LSPs with the same route (links and nodes) allow this service to be provided. This document specifies an optional extension to LDP that allows both ends of a PW (or segment of a MS-PW) to select and bind to the same co-routed bidirectional LSP or two unidirectional LSPs with the same route. "Timezone Service Protocol", Mike Douglass, Cyrus Daboo, 5-Jan-12, This document defines a timezone service protocol that allows reliable, secure and fast delivery of timezone information to client systems such as calendaring and scheduling applications or operating systems. "Peer Protocol", Gu Yingjie, Jinwei Xia, Rui Cruz, Mario Nunes, David Bryan, Joao Taveira, 31-Oct-11, This document presents the architecture of the PPSP Peer protocol outlining the functional entities, message flows and message processing instructions, with the respective parameters. The PPSP Peer Protocol proposed in this document extends the capabilities of PPSP to support adaptive and scalable video and 3D video, for Video On Demand (VoD) and Live video services. The protocol messages formal syntax and semantics, methods, and formats are presented for both Binary and HTTP/XML encoded formats. "Privacy Terminology", Marit Hansen, Hannes Tschofenig, Rhys Smith, 29-Oct-11, Privacy is a concept that has been debated and argued throughout the last few millennia by all manner of people. Its most striking feature is that nobody seems able to agree upon a precise definition of what it actually is. In order to discuss privacy in any meaningful way a tightly defined context needs to be elucidated. The specific context of privacy used within this document is that of "personal data", information about an individual stored and/or transmitted electronically in Internet protocols. This context is highly relevant since a lot of work within the IETF involves defining protocols that can potentially transport (either explicitly or implicitly) personal data. This document aims to establish a basic lexicon around privacy so that IETF contributors who wish to discuss privacy considerations within their work can do so using terminology consistent across the area. Note: This document is discussed at https://www.ietf.org/mailman/listinfo/ietf-privacy "Key Negotiation Protocol (KNP)", Josh Howlett, Sam Hartman, 21-Oct-11, The Key Negotiation Protocol enables an untrusting RADIUS client and RADIUS server to derive a key by reference to a mutually trusted actor called the Introducer. This key may subsequently be used for one of two purposes. First, it can credential a TLS PSK ciphersuite applied to a RadSec connection between the RADIUS client and RADIUS server; or secondly, to establish a trust relationship between the RADIUS client and a second Introducer that is trusted by the first Introducer. The composition of these capabilities enables a RADIUS client to establish a RadSec connection with any RADIUS server with whom it shares a direct or indirect trust relationship via one or more Introducers. "Internet Exchange Route Server", Elisa Jasinska, Nick Hilliard, Robert Raszuk, Niels Bakker, 23-Oct-11, This document outlines a specification for multilateral interconnections at Internet exchange points (IXPs). Multilateral interconnection is a method of exchanging routing information between three or more exterior BGP speakers using a single intermediate broker system, referred to as a route server. Route servers are typically used on shared access media networks, such as Internet exchange points (IXPs), to facilitate simplified interconnection between multiple Internet routers. "EDNS Option Code for SIP and PSTN Source Reference Info", Hadriel Kaplan, Robert Walter, Pierce Gorman, Manjul Maharishi, 24-Oct-11, This document requests an IANA allocation for an EDNS0 Option-Code, per [RFC2671], for a UTF-8 encoded string field containing a URI for private use. The intended use of this field is for providing SIP and PSTN-type source information for ENUM-resolution DNS queries, in private DNS server environments such as Private ENUM. "Routing SIP Requests with ENUM", Hadriel Kaplan, Colin Pons, Pierce Gorman, 24-Oct-11, A common ENUM use-case is for hop-by-hop or domain-by-domain "routing" of SIP requests, using private DNS trees and servers. This document describes this use-case, and a mechanism for a source- based query/answer mechanism for such. "Privacy Preferences for E-Mail Messages", Ulrich Koenig, Jan Schallaboeck, 5-Dec-11, This document proposes a syntax and semantics as an extension of the Internet Message Format (e-mail message) allowing a Sending User of an e-mail message to express his or her preference for how the message content is to be handled by the Receiving Users. For this purpose, semantics of sets of different character combinations ("Privicons") are described. These can syntactically be integrated either in the first-line of the body, in the subject line and/or in a dedicated header of any e-mail message. The Privicons icon set consists of six different icons. They will be machine-readable. The Privicons concept is partly borrowing its approach from the concept of emoticons. For example, to express that the content may be forwarded and even be published. The Sending User could use the Privicon "[>]", which may be followed by an additional explanations, such as "please share". "Temporal and hitless path segment monitoring", Alessandro D'Alessandro, Manuel Paul, Satoshi Ueno, Yoshinori Koike, 31-Oct-11, The MPLS transport profile (MPLS-TP) is being standardized to enable carrier-grade packet transport and complement converged packet network deployments. Among the most attractive features of MPLS-TP are OAM functions, which enable network operators or service providers to provide various maintenance characteristics, such as fault location, survivability, performance monitoring, and preliminary or in-service measurements. One of the most important mechanisms which is common for transport network operation is fault location. A segment monitoring function of a transport path is effective in terms of extension of the maintenance work and indispensable particularly when the OAM function is effective only between end points. However, the current approach defined for MPLS-TP for the segment monitoring (SPME) has some fatal drawbacks. This document elaborates on the problem statement for the Sub-path Maintenance Elements (SPMEs) which provides monitoring of a portion of a set of transport paths (LSPs or MS-PWs). Based on the problems, this document specifies new requirements to consider a new improved mechanism of hitless transport path segment monitoring. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications Union Telecommunications Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network. "Multi-path Label Switched Paths Signaled Using RSVP-TE", Kireeti Kompella, 31-Oct-11, This document describes extensions to Resource ReSerVation Protocol - Traffic Engineering for the set up of multi-path Traffic Engineered Label Switched Paths (LSPs) in Multi Protocol Label Switching and Generalized MPLS networks, i.e., LSPs that conform to traffic engineering constraints, but follow multiple independent paths from the source to the destination that allow load balancing. "ALTO and DECADE service trial within China Telecom", Kai Li, GuangYao Jian, 24-Oct-11, This document reports the experience of China Telecom in a recent experiment with the ALTO service and P2P caches deployment. It is found that the deployment of the ALTO service significantly improves the capability of a Service Provider to affect the distribution of P2P traffic. It is also found that a traffic localized ALTO policy may decrease the download speed of a P2P user. However, the deployment of some P2P caches can compensate such influence. "AES-CCM ECC Cipher Suites for TLS", David McGrew, Daniel Bailey, Matthew Campagna, Robert Dugal, 18-Oct-11, This memo describes the use of the Advanced Encryption Standard (AES) in the Counter and CBC-MAC Mode (CCM) of operation within Transport Layer Security (TLS) to provide confidentiality and data origin authentication. The AES-CCM algorithm is amenable to compact implementations, making it suitable for constrained environments. The ciphersuites defined in this document use Elliptic Curve Cryptography (ECC), and are intended for use in networks with limited bandwidth. "Router Advertisements for Routing between Moving Networks", Alexandru Petrescu, Christophe Janneteau, Nicolas Demailly, Sofiane Imadali, 10-Feb-12, This draft specifies extensions to the ICMPv6 Router Advertisement messages and processing. Traditionally, prefixes contained in RAs are used for on-link determination, on-link address auto- configuration, but not for path setup towards multi-hop destinations. The extensions proposed here still rely on RAs being communicated on a single link (not across several IP hops), but upon RA reception the prefixes are installed in the routing table; they are thus used for forwarding packets further than a single link (multi IP hop). "Analysis of Security Association for Current Routing Protocols", Yinxing Wei, Xiaoping Liang, Hongyan Wang, Changsheng Wan, 26-Oct-11, This document analyzes the security associations used by current routing protocols, including RIPv2, OSPFv2, ISIS, BFD, BGP, OSPFv3, PCE, LDP, LMP, MSDP, RSVP-TE, PIM, and BGP. It also discusses the possible approach to the diversity issue of routing protocol security associations. "RSVP-TE Extensions for Configuration SRLG of an FA", Fatai Zhang, Dan Li, Oscar Gonzalez de Dios, Cyril Margaria, 31-Oct-11, This memo provides extensions for the Resource ReserVation Protocol- Traffic Engineering (RSVP-TE) for the support of the automatic discovery of SRLG of an LSP. "Management Information Base for the PCE Communications Protocol (PCEP) When Requesting Point-to-Multipoint Services", Quintin Zhao, Dhruv Dhody, Udayasree Palle, Daniel King, 19-Sep-11, This memo defines an experimental portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of the Path Computation Element communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs when point- to- multipoint services are requested. "Clarification of Proper Use of "@" (at sign) in URI-style Components", Robert Simpson, 30-Jul-10, Defacto standards have evolved that conflict with existing standards, specifically RFC 3986. This document clarifies the use of the "@" (at sign) in URIs and partial URI-like addresses. "Prefix Management for Mobile IPv6 Fast Handover on Point-to-Point Links", Frank Xia, Behcet Sarikaya, 31-Oct-11, Mobile IPv6 Fast Handovers specification currently does not explicitly define prefix management over point-to-point links when a mobile node uses a prefix to formulate a new care-of-address. In this document a mechanism is developed for a previous access router to request unique prefixes from a new access router, and in turn, the previous access router advertises the prefixes to the mobile node for a new care-of-address configuration. Extensions to Mobile IPv6 Fast Handovers specification are also specified in this document. "Trusted Browser Security Architecture (TBSA)", Sam Caldwell, 10-Aug-10, This document proposes a trusted browser security model intended to secure the mutual automated consent between the end-user and the content provider before allowing a web browser to engage the services of an arbitrary third-party add-on, extension or service. Properly implemented, this proposed security model would create a standardized API across all browsers to further the security of e-commerce and other on-line transactions. "OAuth Dynamic Client Registration Protocol", Thomas Hardjono, Maciej Machulak, Eve Maler, Christian Scholz, 24-Oct-11, This specification proposes an OAuth Dynamic Client Registration protocol. "An Encoding Parameter for HTTP Basic Authentication", Julian Reschke, 29-Jan-12, The "Basic" authentication scheme defined in RFC 2617 does not properly define how to treat non-ASCII characters. This has lead to a situation where user agent implementations disagree, and servers make different assumptions based on the locales they are running in. There is little interoperability for characters in the ISO-8859-1 character set, and even less interoperability for any characters beyond that. This document defines a backwards-compatible extension to "Basic", specifying the server's character encoding expectation, using a new authentication scheme parameter. "Security Assessment of the IPv6 Flow Label", Fernando Gont, 13-Jan-12, This document discusses the security implications of the IPv6 "Flow Label" header field, and analyzes possible schemes for selecting the Flow Label value of IPv6 packets. "RBridges: Support of IEEE 802.1Qbb, 802.1Qaz, and 802.1Qau", Donald Eastlake, Manoj Wadekar, Anoop Ghanwani, Puneet Agarwal, Tal Mizrahi, 14-Aug-11, IEEE 802.1 has developed standards as part of its Data Center Bridging (DCB) activity to (1) efficiently minimize data loss due to queue overflow for selected classes of traffic within Local Area Networks (LANs) meeting certain conditions and (2) provide means to allocate the available bandwidth on links to different classes of traffic. These standards were adopted as the IEEE 802.1Qbb, 802.1Qaz, and 802.1Qau amendmenst to the 802.1Q standard. This document briefly explains the standards and discusses the support of these IEEE 802 standards in RBridges (devices that implement the IETF TRILL standard). "Revealing hosts sharing an IP address using TCP option", Andrew Yourtchenko, Dan Wing, 8-Dec-11, When an IP address is shared among several subscribers -- with a NAT or with an application-level proxy -- it is impossible for the server to differentiate between different clients. Such differentiation is valuable in several scenarios. This memo describes a technique to differentiate TCP clients sharing an IP address. The proposed method uses a TCP option, which avoids altering the application-level payload and works well with SSL-protected connections. "Media Resource Broker (MRB) Location Function (MLF)", Chris Boulton, John Dally, 5-Sep-11, The MediaCtrl work group in the IETF has produced a complete architecture for controlling media server resources in Internet Protocol (IP) based networks. An important function in the MediaCtrl architecture is the Media Resource Broker entity which monitors and allocates media resources to requesting applications. This document introduces a Media Resource Broker (MRB) Location Function (MLF) which works in partnership with MRB's in large deployments providing a light weight scaling and failover mechanism. "Hosts with Any Network Connectivity Using "Bump-in-the-API"(BIA)", Ala Hamarsheh, 19-Jan-11, This document specifies a mechanism for hosts with any network connectivity (IPv4 only, IPv6 only, or dual IPv4/IPv6 connectivity) to run applications of any capability (IPv4 only, IPv6 only, or dual IPv4/IPv6) without any modification to those applications. It is a generalisation of a previous experimental protocol called "Bump-in-the-API" (BIA) [RFC3338]. New mechanism of BIA allows a changeover between the application layer and the IP communication layers from IPv4 to IPv6 and vice versa or IPv6 to IPv4 and vice versa, without requiring those applications to be converted in addressing capabilities, effectively shielding the application layer from IPv4 or IPv6 connectivity. This is considered by the authors to be one of the essential conditions for the transition to IPv6 in the Internet to be successful. "Revision of the Binary Floor Control Protocol (BFCP) for use over an unreliable transport", Charles Eckel, Tom Kristensen, Mark Thompson, Geir Sandbakken, Eoin McLeod, 31-Oct-11, This draft describes how to extend the Binary Floor Control Protocol (BFCP) for use over an unreliable transport. It details the differences from the BFCP protocol definition document and the Session Description Protocol (SDP) format specified for BFCP streams. "Token Revocation", Torsten Lodderstedt, Stefanie Dronia, Marius Scurtescu, 16-Sep-11, This draft proposes an additional endpoint for OAuth authorization servers for revoking tokens. "Hypertext Transfer Protocol (HTTP) Digest Authentication Using GSM 2G Authentication and Key Agreement (AKA)", Lionel Morand, 7-Sep-10, This memo specifies a one-time password generation mechanism for Hypertext Transfer Protocol (HTTP) Digest access authentication based on Global System for Mobile Communications (GSM) authentication and key generation functions A3 and A8, also known as GSM AKA or 2G AKA. The HTTP Authentication Framework includes two authentication schemes: Basic and Digest. Both schemes employ a shared secret based mechanism for access authentication. The GSM AKA mechanism performs user authentication and session key distribution in GSM and Universal Mobile Telecommunications System (UMTS) networks. GSM AKA is a challenge-response based mechanism that uses symmetric cryptography. "Logging of NAT Events", Senthil Sivakumar, Reinaldo Penno, 24-Oct-11, Carrier grade NAT (CGN) devices are required to log events like creation and deletion of translations and information about the resources it is managing. The logs are required in many cases to identify an attacker or a host that was used to launch malicious attacks and/or for various other purposes of accounting. Since there is no standard way of logging this information, different NAT devices behave differently and hence it is difficult to expect a consistent behavior. The lack of a consistent way makes it difficult to write the collector applications that would receive this data and process it to present useful information. This document describes the information that is required to be logged by the NAT devices. "DKIM Authorized Third-Party Signers", Murray Kucherawy, 5-Jan-12, This experimental specification proposes a modification to Domain Keys Identified Mail (DKIM) allowing advertisement of third-party signature authorizations that are to be interpreted as equivalent to a signature added by the administrative domain of the message's author. "6to4 Provider Managed Tunnels", Victor Kuarsingh, Yiu Lee, Olivier Vautrin, 27-Sep-11, 6to4 Provider Managed Tunnels (6to4-PMT) provide a framework which can help manage 6to4 [RFC3056] tunnels operating in an anycast [RFC3068] configuration. The 6to4-PMT framework is intended to serve as an option to operators to help improve the experience of 6to4 operation when conditions of the network may provide sub-optimal performance or break normal 6to4 operation. 6to4-PMT provides a stable provider prefix and forwarding environment by utilizing existing 6to4 Relays with an added function of IPv6 Prefix Translation. This operation may be particularly important in NAT444 infrastructures where a customer endpoint may be assigned a non- RFC1918 address thus breaking the return path for anycast [RFC3068] based 6to4 operation. "Protocol for Carrying Authentication for Network Access (PANA) Extension for Key Wrap", Robert Cragie, Paul Duffy, Yoshihiro Ohba, Alper Yegin, 5-Sep-11, This document specifies an extension to PANA (Protocol for carrying Authentication for Network Access) for secure delivery of keys from a PAA (PANA Authentication Agent) to a PaC (PANA Client). "Traceroute and Ping Message Extension", Naiming Shen, Carlos Pignataro, Rajiv Asati, Enke Chen, Alia Atlas, 31-Oct-11, This document specifies extensions to traceroute and ping techniques to facilitate addition application information to be carried in UDP, TCP and ICMP traceroute probe messages and ICMP echo request and reply messages. This proposal also allows the receiver to authenticate the source of the traceroute and ping senders. "Indication of features supported by proxy", Christer Holmberg, Ivo Sedlacek, Hadriel Kaplan, 12-Dec-11, This document defines a new SIP header field, Feature-Caps, that can be used by SIP entities to indicate support of features and capabilities, in cases where the Contact header field contains a URI that does not represent the SIP entity that wants to indicate support of its features and capabilities. "Default Port for IRC via TLS/SSL", Richard Hartmann, 23-Apr-11, This document describes the commonly accepted practice of listening on TCP port 6697 for incoming IRC connections encrypted via TLS/SSL. "Management Information Base for the PCE Communications Protocol (PCEP) for Path-Key-Based Inter-Domain Path Computation", Dhruv Dhody, Udayasree Palle, Quintin Zhao, Daniel King, 5-Sep-11, This memo defines an experimental portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of the Path Computation Element communication Protocol (PCEP)for communications between a Path Computation Client (PCC)and a Path Computation Element (PCE), or between two PCEs when path-key- based inter-domain path computation is requested. "Support for RSVP-TE in L3VPNs", Kenji Kumaki, Tomoki Murai, Dean Cheng, Satoru Matsushima, PENG JIANG, 30-Oct-11, IP Virtual Private Networks (VPNs) provide connectivity between sites across an IP/MPLS backbone. These VPNs can be operated using BGP/MPLS and a single provider edge (PE) node may provide access to multiple customer sites belonging to different VPNs. The VPNs may support a number of customer services including RSVP and RSVP-TE traffic. This document describes how to support RSVP-TE between customer sites when a single PE supports multiple VPNs. "RBridges: More Proposed TRILL Header Options", Donald Eastlake, 17-Oct-11, The TRILL base protocol standard, RFC 6325, specifies minimal hooks for options and draft-ietf-trill-rbridge-options specifies the format for options and a proposed initial set of options. This draft is a holding location for additional proposed options. It is not intended that this draft will ever progress to be an RFC. "Information Elements for Short Timer", Shingo Kashima, 29-Sep-11, This document describes Information Elements related to short timer. They are used by the IP Flow Information Export (IPFIX) protocol for encoding timer paramerters required for traffic measurment of volume change in a short time. "IANA Registering a SIP Resource Priority Header Field Namespace for Local Emergency Communications", James Polk, 6-Jun-11, This document creates the new Session Initiation Protocol (SIP) Resource Priority header field namespace "esnet" for local emergency usage to a public safety answering point (PSAP), between PSAPs, and between a PSAP and first responders and their organizations, and places this namespace in the IANA registry. "LDP Extensions for Pseudo Wire (PW) Transfer in an MPLS-TP Network", Qilei Wang, Muliu Tao, Xihua Fu, Ruiquan Jing, Xiaoli Huo, 29-Dec-11, As defined in [RFC5654] MPLS-TP transport path includes LSP and PW. And the possibility of transferring the ownership and control of an existing and in-use path between the management plane and the control plane, without actually affecting data plane traffic being carried over it, is a valuable option for carrier. [RFC5493] and [RFC5852] describe the LSP transfer. This memo gives the requirement and LDP extensions for PW transfer in an MPLS-TP network. "IPP over HTTPS Transport Binding and 'ipps' URI Scheme", Ira McDonald, Michael Sweet, 22-Nov-11, This memo defines the Internet Printing Protocol (IPP) over HTTPS transport binding and the corresponding 'ipps' URI scheme, that is used to designate the access to the network location of a secure IPP print service or a network resource (for example, a print job) managed by such a service. This memo is published by the IETF on behalf of the Internet Printing Protocol Working Group of the IEEE-ISTO Printer Working Group. This memo updates RFC 2910 and RFC 2911. "Prefix Pool Option for DHCPv6 Relay Agents on Provider Edge Routers", Leaf Yeh, Tina Tsou, Mohammed Boucadair, Juergen Schoenwaelder, Jie Hu, 20-Jan-12, The DHCPv6 Prefix Pool option provides a mechanism for DHCPv6 Prefix Delegation (DHCPv6-PD), allowing the DHCPv6 server to notify a DHCPv6 relay agent implemented on a Provider Edge (PE) router about active prefix pools allocated by the DHCPv6 server to the PE router. The information of active prefix pools can be used to enforce IPv6 route aggregation on the PE router by adding or removing aggregated routes according to the status of the prefix pools. The advertising of the aggregated routes in the routing protocol enabled on the network- facing interface of PE routers will dramatically decreases the number of the routing table entries in the network. "Using the International Mobile station Equipment Identity(IMEI)URN as an Instance ID", Andrew Allen, 9-Jan-12, This specification defines how the Uniform Resource Name namespace reserved for GSMA (Global Sstandard for Mobiles Association) identities and its sub namespace for the IMEI (International Mobile station Equipment Identity) can be used as an instance-id as specified in RFC 5626 [1] and also as used by RFC 5627 [2]. "Multiprotocol Label Switching Transport Profile p2mp Shared Protection", Yu jinghai, Yuefeng Ji, ZTE Corporation, Zongpeng Du, 30-Aug-11, This document will describle two protection solutions to support protection of failures in p2mp path in MPLS-TP. According to the protection Requirements in RFC 5654, there are requirements for MPLS-TP to support sharing of protection resources such that protection paths that are known not to be required concurrently can share the same protection resources. In addition, there is a requirement for MPLS-TP to support unidirectional 1:n protection for p2mp paths. These requirements are further addressed in draft-ietf-mpls-tp-survive-fwk . so this draft will present proposed solutions . This document is a product of a joint Internet Engineering Task Force(IETF) / International Telecommunications Union Telecommunications Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. "Group Communication for CoAP", Akbar Rahman, Esko Dijk, 12-Oct-11, This is a working document intended to trigger discussion and develop draft text for the CoAP protocol specification in the area of group communication. Engineering tradeoffs become more challenging in constrained environments, therefore group communication is considered within the context of adjacent topics that may impact or be impacted by design choices in the subject area. A solution based on IP multicast is proposed. "An SNMP Usage for RELOAD", YongLin Peng, Wei Wang, ZhenWu Hao, Yu Meng, 24-Oct-11, This document defines a SNMP Usage for REsource LOcation And Discovery(RELOAD), The SNMP Usage provides the functionality of managing the RELOAD network. The SNMP Usage provides lookup service for the network manager's address stored in the overlay. The SNMP Usage also defines the method that allow the registrations to map a network manager'name to a specific node reachable through the overlay. The AppAttach method is used to establish a direct connection between nodes through which SNMP messages are exchanged. "Multi-Cost ALTO", Sabine Randriamasy, Nico Schwan, 31-Oct-11, IETF is designing a new service called ALTO (Application Layer traffic Optimization) that includes a "Network Map Service", an "Endpoint Cost Service" and an "Endpoint (EP) Ranking Service" and thus incentives for application clients to connect to ISP preferred Endpoints. These services provide a view of the Network Provider (NP) topology to overlay clients. The present draft proposes a light way to extend the information provided by the current ALTO protocol. The purpose is to broaden the possibilities of the Application Clients in two ways. Firstly it proposes to include information on multiple cost types in a single ALTO transaction, providing a better mapping of the Selected Endpoints to needs of the growing diversity of Content Networking Applications and to the network conditions. Secondly it proposes new cost types, that are an abstraction of time-sensitive network information as viewed by the Network Provider. All this also helps producing a more robust choice when multiple Endpoints must be selected. There are 2 parts in this draft: the first part initiates protocol extensions to support requests on multiple Cost Types in one single transaction. These first extensions also integrate the discussions within the ALTO Working Group. The second part proposes use cases motivating further definitions of additional CostTypes and Cost related attributes and capabilities. ""Gateway-Initiated" 6rd", Tina Tsou, Cathy Zhou, Tom Taylor, Ole Troan, Qi Chen, 3-Feb-12, This document proposes an alternative 6rd deployment model to that of RFC 5969. The basic 6rd model allows IPv6 hosts to gain access to IPv6 networks across an IPv4 access network using 6-in-4 tunnels. 6rd requires support by a device (the 6rd-CE) on the customer site, which must also be assigned an IPv4 address. The alternative model described in this document initiates the 6-in-4 tunnels from an operator-owned gateway collocated with the operator's IPv4 network edge, rather than from customer equipment. The advantages of this approach are that it requires no modification to customer equipment and avoids assignment of IPv4 addresses to customer equipment. The latter point means less pressure on IPv4 addresses in a high-growth environment. "Secure Extension of BGP by Decoupling Path Propagation and Adoption", Mingui Zhang, Bin Liu, Dacheng Zhang, Beichuan Zhang, 8-Jan-12, This draft proposes a novel mitigation scheme to protect the inter- domain data delivery during false routing announcements. A new path attribute is defined to Decouple propagation of a path and adoption of a path for data forwarding in BGP (DBGP). DBGP does not use suspicious paths for data forwarding, but still propagates them in the routing system to facilitate attack detection. It can extensively protect data delivery from routing announcements of false sub- prefixes, false origins, false nodes and false links, and works well with ongoing attack detection and prevention systems. "Energy Management (EMAN) Applicability Statement", Emmanuel Tychon, Little Silver, Bruce Nordman, 31-Oct-11, The objective of Energy Management (EMAN)is to provide an energy management framework for networked devices. This document presents the applicability of the EMAN framework for a variety of scenarios. This document lists use cases and target devices that can potentially implement the EMAN framework and associated SNMP MIB modules. These use cases are useful for identifying monitoring requirements that need to be considered. Further, we describe the relationship of the EMAN framework to relevant other energy monitoring standards and architectures. "IPsec security for packet based synchronization", Yixian Xu, 16-Sep-11, Cellular networks often use Internet standard technologies to handle synchronization. This document defines an extension based on WESP. Usually, several traffic flows are carried in one IPsec tunnel, for some applications, such as, 1588 or NTP, the packets need to be identified after IPsec encryption to handle specially. In order to achieve high scalability in implement, a separate IPsec tunnel will not be established for some special traffic. This document analyses the need for security methods for synchronization messages distributed over the Internet. This document also gives a solution on how to mark the synchronization message when IPSec is implemented in end to end frequency synchronization." "Extensions to the Path Computation Element Communication Protocol (PCEP) for Backup Egress of a Traffic Engineering Label Switched Path", Huaimo Chen, Cyril Margaria, 30-Oct-11, This document presents extensions to the Path Computation Element Communication Protocol (PCEP) for a PCC to send a request for computing a backup egress for an MPLS TE P2MP LSP or an MPLS TE P2P LSP to a PCE and for a PCE to compute the backup egress and reply to the PCC with a computation result for the backup egress. "Extensions to Path Computation Element Communication Protocol (PCEP) for Backup Ingress of a Traffic Engineering Label Switched Path", Huaimo Chen, 30-Oct-11, This document presents extensions to the Path Computation Element Communication Protocol (PCEP) for a PCC to send a request for computing a backup ingress for an MPLS TE P2MP LSP or an MPLS TE P2P LSP to a PCE and for a PCE to compute the backup ingress and reply to the PCC with a computation result for the backup ingress. "Stateless Automatic IPv4 over IPv6 Tunneling with IPv4 Address Sharing", Naoki Matsuhira, 19-Oct-11, This document specifies Stateless Automatic IPv4 over IPv6 Tunneling with IPv4 Address Sharing (SA46T-AS) base specification. SA46T-AS is basically the same technology with SA46T, however that have IPv4 address sharing capability. SA46T-SA is gateway technology, not protocol. "Extended IPv6 Addressing for Encoding Port Range", Congxiao Bao, Xing Li, 23-Oct-11, This document discusses an extension of the algorithmic translation between IPv4 and IPv4-translatable IPv6 addresses. The extended address format contains transport-layer port range information which allows several IPv6 nodes to share a single IPv4 address with each node managing a different range of ports. This address format extension can be used for IPv4/IPv6 translation, as well as IPv4 over IPv6 tunneling. "6LoWPAN Generic Compression of Headers and Header-like Payloads", Carsten Bormann, 3-Oct-11, This short I-D provides a complete design for a simple addition to 6LoWPAN Header Compression that enables the compression of generic headers and header-like payloads. "MAC Address Withdrawal over Static Pseudowire", Siva Sivabalan, Sami Boutros, Luca Martini, 18-Oct-11, This document specifies a mechanism to signal MAC address withdrawal notification using PW Associated Channel (ACH). Such notification is useful when statically provisioned PWs are deployed in VPLS/H-VPLS environment. This document is a product of a joint Internet Engineering Task Force(IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network. "A Cryptographic Suite for Embedded Systems (SuiteE)", Matthew Campagna, Greg Zaverucha, 18-Oct-11, This document describes a cryptographic suite of algorithms ideal for constrained embedded systems. It uses the existing IEEE 802.15.4 standard as a starting point, builds upon existing embedded cryptographic primitives and suggests additional elliptic curve cryptography (ECC) algorithms and curves. The goal is to define a complete suite of algorithms ideal for embedded systems. "Problem statement for distributed and dynamic mobility management", Anthony Chan, 31-Oct-11, The traditional hierarchical structure of cellular networks has led to deployment models which are heavily centralized. Mobility management with centralized mobility anchoring in existing hierarchical mobile networks is quite prone to suboptimal routing and issues related to scalability. Centralized functions present a single point of failure, and inevitably introduce longer delays and higher signaling loads for network operations related to mobility management. To make matters worse, there are numerous variants of Mobile IP in addition to other protocols standardized outside the IETF, making it much more difficult to create economical and interoperable solutions. In this document we examine the problems of centralized mobility management and identify requirements for distributed and dynamic mobility management. "Link-Local Multicast Name Resolution (LLMNR) Deployment Consideration for PCP Server Discovery", Gang Chen, Hui Deng, Junbin Zhang, 31-Oct-11, The memo has recommended to deploy Link-Local Multicast Name Resolution (LLMNR) in PCP scenarioes. Depending on that, it could not only avoid adherence to DNS during PCP server name resolving, but also company with PCP FQDN DHCP options extention to accomplish PCP server discovery. In order to fit LLMNR into PCP network, particular LLMNR deployment guide and relevant configurations are considerated along with PCP elements installation. "NAT64 Operational Considerations", Gang Chen, 31-Oct-11, The document has summarized NAT64 usages on different modes, in which NAT64 may serve for a large-scale network or would give enterprise or residential service opportunities to be accessed by IPv6 remote subscribers. The document has described different operations for each usage and proposed operational considerations for each particular NAT64-mode. "Export of Application Information in IPFIX", Benoit Claise, Paul Aitken, Nir Ben-Dvora, 3-Dec-11, This document specifies an extension to the IPFIX information model specified in [RFC5102] to export application information. "Lightweight 4over6: An Extension to DS-Lite Architecture", Yong Cui, Qiong Sun, Yiu Lee, Tina Tsou (Ting ZOU), Mohamed Boucadair, 3-Feb-12, This document specifies an extension to DS-Lite called lightweight 4over6. This mechanism moves the translation function from the tunnel concentrator (AFTR) to initiators (B4s), and hence reduces the mapping scale on the concentrator to per-subscriber level. To delegate the NAT function to the initiators, port-restricted IPv4 addresses are allocated to the initiators. "Assessing the Impact of Carrier-Grade NAT on Network Applications", Chris Donley, Lee Howard, Victor Kuarsingh, John Berg, University Colorado, 15-Nov-11, NAT444 is an IPv4 extension technology being considered by Service Providers to continue offering IPv4 service to customers while transitioning to IPv6. This technology adds an extra Carrier-Grade NAT ("CGN") in the Service Provider network, often resulting in two NATs. CableLabs, Time Warner Cable, and Rogers Communications independently tested the impacts of NAT444 on many popular Internet services using a variety of test scenarios, network topologies, and vendor equipment. This document identifies areas where adding a second layer of NAT disrupts the communication channel for common Internet applications. This document was updated to also include Dual-Stack Lite impacts. "Overlapping IPv4 Address Assignment Support for Dual-stack Mobile IPv6", Sri Gundavelli, Julien Laganier, Hidetoshi Yokota, Carl Williams, 22-Oct-11, There are number of deployment scenarios where there is a need for a home agent to allocate the same private IPv4 address to multiple mobile nodes that it is serving. A service provider hosting home agent service fo