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", David Culler, Jonathan Hui, JP Vasseur, 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, Tim Chown, Tomohiro Fujisaki, 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. "Distributing Address Selection Policy using DHCPv6", Arifumi Matsumoto, Tomohiro Fujisaki, Jun-ya Kato, Tim Chown, 21-Feb-12, RFC 3484 defines default address selection mechanisms for IPv6 that allow nodes to select appropriate address when faced with multiple source and/or destination addresses to choose between. The RFC 3484 allowed for the future definition of methods to administratively configure the address selection policy information. This document defines a new DHCPv6 option for such configuration, allowing a site administrator to distribute address selection policy overriding the default address selection policy table, and thus control the address selection behavior of nodes in their site. "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, 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. "Representing IPv6 Zone Identifiers in Uniform Resource Identifiers", Brian Carpenter, Robert Hinden, 17-Feb-12, This document describes how the Zone Identifier of an IPv6 scoped address can be represented in a Uniform Resource Identifier that includes a literal IPv6 address. It updates RFC 3986 and RFC 4007. "Default Address Selection for Internet Protocol version 6 (IPv6)", Dave Thaler, Richard Draves, Tim Chown, 22-Feb-12, This document describes two algorithms, for source address selection and for destination address selection. The algorithms specify default behavior for all Internet Protocol version 6 (IPv6) implementations. They do not override choices made by applications or upper-layer protocols, nor do they preclude the development of more advanced mechanisms for address selection. The two algorithms share a common context, including an optional mechanism for allowing administrators to provide policy that can override the default behavior. In dual stack implementations, the destination address selection algorithm can consider both IPv4 and IPv6 addresses - depending on the available source addresses, the algorithm might prefer IPv6 addresses over IPv4 addresses, or vice-versa. All IPv6 nodes, including both hosts and routers, must implement default address selection as defined in this specification. IPv6 Site Renumbering (6renum) ------------------------------ "IPv6 Enterprise Network Renumbering Scenarios and Guidelines", Bing Liu, Sheng Jiang, 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", Sheng Jiang, Bing Liu, 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", Josh Howlett, Sam Hartman, 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", Josh Howlett, Sam Hartman, 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. "Application Bridging for Federated Access Beyond web (ABFAB) Use Cases", Rhys Smith, 21-Feb-12, Federated authentication has so far been typically associated with Web-based services, but there is growing interest in the application of federated authentication for non-Web services. The goal of this document is to document a selection of the wide variety of contexts whose user experience could be improved through the use of technologies based on the ABFAB architecture and specifications. ADSL MIB (adslmib) ------------------ "xDSL multi-pair bonding (G.Bond) MIB", Edward Beili, Moti Morgenstern, 13-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, 13-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 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", Reinaldo Penno, Richard Alimi, 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, 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 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, 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, Dave Crocker, Mark Nottingham, 13-Feb-12, 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 textual parameters in application protocols. "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, Dave Crocker, 22-Feb-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", John Klensin, Tony Hansen, Ned Freed, 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, Manish Karir, Ian Foo, 21-Feb-12, 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", Brian Rosen, Henning Schulzrinne, Hannes Tschofenig, Steve Norreys, 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", Dan Wing, David McGrew, 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, Ken Carlberg, 17-Feb-12, 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, 22-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 Architecture for RTP", Geoff Hunt, Philip Arden, 24-Feb-12, This memo proposes an architecture for extending RTP Control Protocol (RTCP) with a new RTCP Extended Reports (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 Brandenburg, Hans Stokking, Mario Montagud, Oskar Deventer, Fernando Boronat, 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, 19-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", Mohamed Boucadair, Reinaldo Penno, Senthil Sivakumar, Tarun Saxena, 21-Feb-12, 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", Teemu Savolainen, Jouni Korhonen, 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, Geir Sandbakken, 17-Feb-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, David 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)", Martin Huelsemann, Roland Jesske, Dale Worley, 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", Jean-Louis Roux, Samir Vapiwala, Scott Poretsky, Jay Karthik, Rajiv Papneja, Shankar Rao, 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", Al Morton, Jim McQuaid, Kevin Dubray, Scott Bradner, 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", Dan Li, Greg Bernstein, Wataru Imajuku, Young Lee, 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, He Jia, 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", Greg Bernstein, Young Lee, 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", Attila Takacs, David Ward, Elisa Bellagamba, Loa Andersson, Pontus Skoldstrom, 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", Dan Li, Daniele Ceccarelli, Fatai Zhang, Han Li, Sergio Belotti, 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", Daniele Ceccarelli, Lou Berger, Dan Li, 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. "OSPF-TE Extensions for General Network Element Constraints", Fatai Zhang, Greg Bernstein, Jianrui Han, Young Lee, 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, 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, 17-Feb-12, 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", Daniele Ceccarelli, Fatai Zhang, Guoying Zhang, Khuzema Pithewan, Sergio Belotti, 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, Grant Watson, Kevin Ma, Philip Eardley, Stephan Emile, Trevor Burbridge, 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, Andrew Pepperell, Brian Baldino, Mark Duckworth, 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, Tim Terriberry, 17-Feb-12, 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 bitrate 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)", Brian Frank, Carsten Bormann, Klaus Hartke, Zach Shelby, 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, 15-Feb-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, 14-Feb-12, 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", Sean Shen, Sheng Jiang, 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", Alan Johnston, Keith Drage, 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", Jakob Schlyter, Paul Hoffman, 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, Mark Stapp, Richard Johnson, 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", Jay Kumarasamy, Kim Kinnear, Mark Stapp, Richard Johnson, 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. "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. 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, 14-Feb-12, Dynamic Host Configuration Protocol (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 to the client on the initial DHCP ACK that is used for subsequent validation of a FORCERENEW message. This document updates RFC 3203. "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", Jean-Francois Tremblay, John Brzozowski, 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 through Tunnels", Xiaohu Xu, Marc Blanchet, Dayong Guo, Ole Troan, 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 . "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", Ted Lemon, Yong Cui, Peng Wu, Jianping Wu, 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. Diameter Maintenance and Extensions (dime) ------------------------------------------ "Diameter Base Protocol", Victor Fajardo, Jari Arkko, John Loughney, Glen 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)", Sebastien Decugis, Lionel Morand, Wenson Wu, Julien Bournelle, 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", Glen Zorn, Jiao Kang, 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, Cisco Systems, 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, 21-Feb-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, 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, Ying Qiu, Niklas Steinleitner, 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, 14-Feb-12, 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, 15-Feb-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, 14-Feb-12, 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, 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)", Alexander Mayrhofer, Kenneth Cartwright, Syed Ali, 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) ---------------------------------------- "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. "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", Christer Holmberg, Hannes Tschofenig, Henning Schulzrinne, 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 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. "Energy-aware Networks and Devices MIB", John Parello, Benoit Claise, 16-Feb-12, 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. "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", Benoit Claise, Little Silver, Juergen Quittek, Mouli Chandramouli, Thomas Dietz, 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", 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", Hao Zhou, Joseph Salowey, Katrin Hoeper, Stephen Hanna, 19-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, 21-Feb-12, FEC Framework document [RFC6363] defines the FEC Framework Configuration Information necessary for the FEC framework operation. This document describes using existing signaling protocols such as Session Announcement Protocol (SAP), Session Initiation Protocol (SIP), Real Time Stream Protocol (RTSP) etc. 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-Feb-12, 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", Ali Begen, Ulas Kozat, 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, 24-Feb-12, 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", Chuanhuang Li, Evangelos Haleplidis, Joel Halpern, Kentaro Ogawa, Weiming Wang, 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, 20-Feb-12, This document discusses CE High Availability within a ForCES NE. "Interoperability Report for Forwarding and Control Element Separation (ForCES)", Evangelos Haleplidis, Jamal Salim, Kentaro Ogawa, Ming Gao, Weiming Wang, 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. Geographic Location/Privacy (geopriv) ------------------------------------- "Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information", Jorge Cuellar, Hannes Tschofenig, Henning Schulzrinne, 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", Martin Thomson, Martin Dawson, James Winterbottom, Hannes Tschofenig, Henning Schulzrinne, 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, Dorothy Stanley, Brian Rosen, Allan Thomson, Gabor Bajko, 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", Martin Thomson, James Winterbottom, Richard Barnes, 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", Robins George, Martin Thomson, Richard Barnes, Brian Rosen, James Winterbottom, 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, 17-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, Glen Zorn, Zhen Cao, 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", Anders Brandt, Jari Arkko, Jason Weil, Ole Troan, Tim Chown, 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, 20-Feb-12, 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. Inter-Domain Routing (idr) -------------------------- "Dynamic Capability for BGP-4", Srihari Ramachandra, Enke Chen, 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. "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. "Subcodes for BGP Finite State Machine Error", Jie Dong, Mach Chen, Anantharamu Suryanarayana, 13-Feb-12, 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. This document updates RFC 4271. "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. "Assigned BGP extended communities", Pierre Francois, Bruno Decraene, 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. "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. "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. "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. "Extended Message support for BGP", Keyur Patel, 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. "IPv6 Extensions for Route Target Distribution", Keyur Patel, Robert Raszuk, Jie Dong, 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. "BGP Custom Decision Process", Russ White, Alvaro Retana, 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. "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. "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. "Notification Message support for BGP Graceful Restart", Keyur Patel, Rex Fernando, John Scudder, 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. "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", Lee Howard, Chris Donley, Wesley George, Chris Donley, 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", Pierre Levis, Mohamed Boucadair, 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, 1-Jun-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", Tanja Zseby, 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", Atsushi Kobayashi, Benoit Claise, Gerhard Muenz, Thomas Dietz, 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", Arno Wagner, Benoit Claise, Brian Trammell, 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", Benoit Claise, Brian Trammell, 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, 13-Feb-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", Andreas Johnsson, Christofer Flinta, Steve Baillargeon, 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. 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", Abhay Roy, David Ward, Les Ginsberg, Mike Shand, Stefano Previdi, 14-Feb-12, 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, 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 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. "JSON Web Encryption (JWE)", Joe Hildebrand, Eric Rescorla, Michael Jones, 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)", Nat Sakimura, Michael Jones, John Bradley, 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. 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. "Operations Model for Router Keying", Dacheng Zhang, Sam Hartman, 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", Leif Johansson, Nicolas Williams, 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, 24-Feb-12, 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, 20-Feb-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, Thomas Hardjono, Tom Yu, 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, "export strength" RC4, and other weak cryptographic algorithms in Kerberos", Love Astrand, Tom Yu, 16-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, RFC4121, and RFC4757 to deprecate the use of DES, "export strength" RC4, and other weak cryptographic algorithms in Kerberos. Because RFC1510 (obsoleted by RFC4120) supports only DES, this document reclassifies RFC1510 as Historic. "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, Giles Heron, Vach Kompella, Eric Rosen, 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, 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", Kiran Koushik, Rohit Mediratta, Thomas Nadeau, 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", Raymond Key, Yuji Kamite, Zhihua Liu, Manuel Paul, Ruediger Kunze, 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, Lu Huang, Zhihua Liu, Manuel Paul, Ruediger Kunze, Nick 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. "A Framework for E-Tree Service over MPLS Network", Lucy Yong, Yuji Kamite, Wim Henderickx, 30-Jan-12, 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. Layer 3 Virtual Private Networks (l3vpn) ---------------------------------------- "BGP ACCEPT_OWN Community Attribute", David Smith, James Uttaro, John Scudder, Pradosh Mohapatra, Robert Raszuk, 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. "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", Ray Qiu, Eric Rosen, Yakov Rekhter, 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)", Greg Hazel, Janardhan Iyengar, Mirja Kuehlewind, Stanislav Shalunov, 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, 12-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, 17-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)", Dave Meyer, Dino Farinacci, 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, 14-Feb-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", Darrel Lewis, Lorand Jakab, Jordi Domingo-Pascual, Albert Cabellos-Aparicio, Florin Coras, 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 EID Block", Darrel Lewis, Dave Meyer, Luigi Iannone, 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. "LISP-Security (LISP-SEC)", Albert Cabellos-Aparicio, Damien Saucez, Fabio Maino, Olivier Bonaventure, Vina Ermagan, 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. 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", Christopher Dearlove, Philippe Jacquet, Thomas Clausen, 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", Brian Adamson, Joseph Macker, Robert Cole, 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, 12-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", Murray Kucherawy, Return Path, 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, 16-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. This memo updates RFC4408 by providing an IANA registry for SPF modifiers. "Creation and Use of Email Feedback Reports: An Applicability Statement for the Abuse Reporting Format (ARF)", Return Path, Murray Kucherawy, 23-Feb-12, RFC 5965 defines an extensible, machine-readable format intended for mail operators to report feedback about received email to other parties. This Applicability Statement 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. Some related optional mechanisms are also discussed. MBONE Deployment (mboned) ------------------------- "Automatic Multicast Tunneling", Gregory Bumgardner, Thomas Morin, 16-Feb-12, This document describes Automatic Multicast Tunneling (AMT), a protocol for delivering multicast traffic from sources in a multicast-enabled network to receivers that lack multicast connectivity to the source network. The protocol uses UDP encapsulation and unicast replication to provide this functionality. The AMT protocol is specifically designed to support rapid deployment by requiring minimal changes to existing network infrastructure. "Multicast Addresses for Documentation", Stig Venaas, Rishabh Parekh, Gunter 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, Lorenzo Miniero, Simon Romano, Tobia Castaldi, 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, Gary Munson, Lorenzo Miniero, 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. "IANA Registry for MEDIACTRL Interactive Voice Response Control Package", Eric Burger, 14-Feb-12, This document creates an IANA registry for the response codes for the MEDIACTRL Interactive Voice Response Control Package, RFC6231. Multiple Interfaces (mif) ------------------------- "DHCPv6 Route Options", Wojciech Dec, Tomasz Mrugalski, Tao Sun, Behcet Sarikaya, 24-Feb-12, 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", Jun-ya Kato, Ted Lemon, Teemu Savolainen, 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 Defining Extensions to IODEF", Brian Trammell, 17-Feb-12, This document provides guidelines for extensions to IODEF [RFC5070] for 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", Brian Haley, Henrik Levkowetz, Hui Deng, Sri Gundavelli, Vijay Devarapalli, 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, 22-Feb-12, 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", Alexandru Petrescu, George Tsirtsis, Hesham Soliman, Kent Leung, Sri Gundavelli, 12-Feb-12, 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", Alper Yegin, Hee-Jin Jang, JinHyeock Choi, Kuntal Chowdhury, 22-May-08, This draft defines a DHCP-based scheme to enable dynamic discovery of Mobile IPv6 home network information. New DHCP options are defined which allow a mobile node to request the home agent IP address, FQDN, or home network prefix and obtain it via the DHCP response. Mobility for IP: Performance, Signaling and Handoff Optimization (mipshop) -------------------------------------------------------------------------- "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. 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", 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, 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. "Multiplexing Negotiation Using Session Description Protocol (SDP) Port Numbers", Christer Holmberg, Harald Alvestrand, 23-Feb-12, This specification defines a new SDP Grouping Framework SDP grouping framework extension, "BUNDLE", that can be used with the Session Description Protocol (SDP) Offer/Answer mechanism to negotiate the usage of bundled media, which refers to the usage of a single 5-tuple for media associated with multiple SDP media descriptions ("m=" lines). Multiprotocol Label Switching (mpls) ------------------------------------ "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", Luyuan Fang, Nurit Sprecher, 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", Frederic JOUNAY, Mach Chen, Simon DeLord, Ning So, Wei Cao, 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. "Updates to LDP for IPv6", Carlos Pignataro, Rajiv Asati, Rajiv Papneja, Vishwas Manral, 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", David Ward, Elisa Bellagamba, John Drake, Loa Andersson, Pontus Skoldstrom, 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", Elisa Bellagamba, Han Li, He Jia, 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", Ben Niven-Jenkins, Luyuan Fang, Richard Graveman, Scott Mansfield, 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", John Drake, Kireeti Kompella, Lucy Yong, Shane Amante, Wim Henderickx, 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", Rahul Aggarwal, Yakov Rekhter, 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. "LDP IP and PW Capability", Kamran Raza, Sami Boutros, 15-Feb-12, Currently, no LDP capability is exchanged for LDP applications like IP label switching and L2VPN/PW signaling. When an LDP session comes up, an LDP speaker may unnecessarily advertise its local state for such LDP applications even when the peer session may be established for some other applications like ICCP. This document proposes a solution by which an LDP speaker announces its disinterest or non- support for IP label switching or L2VPN/PW application, hence disabling corresponding application state exchange over the established LDP session. "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", George Swallow, Sam Aldrin, Sami Boutros, Shaleen Saxena, Siva Sivabalan, Vishwas Manral, 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", Eric Gray, Huub Helvoort, Malcolm Betts, Rolf Winter, 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", Luyuan Fang, Raveendra Torvi, Quintin Zhao, Ning So, Chao Zhou, Lianyuan Li, 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", Wu Bo, Daniele Ceccarelli, Diego Caviglia, Francesco Fondelli, Marco Corsi, Nurit Sprecher, Stewart Bryant, Xuehui Dai, Yaacov Weingarten, 15-Feb-12, 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, 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, Matthew Bocci, Stewart Bryant, 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, Matthew Bocci, Stewart Bryant, 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", Alan Ford, Michael Scharf, 16-Feb-12, 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-Based Mobility Extensions (netext) ------------------------------------------ "Bulk Binding Update Support for Proxy Mobile IPv6", Fuad Abinader, Sri Gundavelli, Kent Leung, Suresh Krishnan, Domagoj Premec, 14-Feb-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", Sri Gundavelli, Telemaco Melia, 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, Ashutosh Dutta, Wenson Wu, Paulo Loureiro, 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. Network-based Localized Mobility Management (netlmm) ---------------------------------------------------- "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. "Proxy Mobile IPv6 Management Information Base", Glenn Mansfield, 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. 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, 20-Feb-12, This document contains a specification of four YANG modules. Together they form the core routing data model which serves as a basis for configuring a routing subsystem. It is therefore expected that this module will be augmented by additional YANG modules defining data models for individual routing protocols and other related functions. The core routing data model provides 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", Craig Everhart, Daniel Ellard, James Lentini, Manoj Naik, Renu Tewari, 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, Jiaying Zhang, Andy Adamson, 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", Nico Williams, Thomas Haynes, 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) ----------------------------- "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. "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). "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)", Andreas Pashalidis, Kuntal Chowdhury, Avi Lior, Parviz Yegani, Hannes Tschofenig, 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. "Stream Control Transmission Protocol (SCTP) Packet Drop Reporting", Randall Stewart, Peter Lei, Michael Tuexen, 17-Feb-12, This document describes a new chunk type for SCTP. This new chunk type can be used by both endhosts and routers to report the loss of SCTP datagrams due to errors in transmission or other drops not due to congestion. "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. "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. "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 Ph.D., 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. "Improving DNS Service Availability by Using Long TTL Values", Eric Osterweil, Vasileios Pappas, 23-Feb-12, Due to the hierarchical tree structure of the Domain Name System [RFC1034][RFC1035], losing all of the authoritative servers that serve a zone can disrupt services to not only that zone but all of its descendants. This problem is particularly severe if all the authoritative servers of the root zone, or of a top level domain's zone, fail. Although proper placement of secondary servers, as discussed in [RFC2182], can be an effective means against isolated failures, it is insufficient to protect the DNS service against a Distributed Denial of Service (DDoS) attack. This document proposes to reduce the impact of DDoS attacks against top level DNS servers by setting long TTL values for NS records and their associated A and AAAA records. Our proposed changes are purely operational and can be deployed incrementally. "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 "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, Alton Lo, Keyur Patel, 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. "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. "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. "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. "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. "The Lightweight Global Navigation Satellite System (GNSS) Support Protocol (LGSP)", Carlo Kopp, Mike Tyson, 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. "Saratoga: A Scalable Data Transfer Protocol", Charles Smith, Chris Jackson, Lloyd Wood, Wesley Eddy, Will Ivancic, 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. "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. "Session Initiation Protocol Service Example -- Music on Hold", Dale Worley, 13-Feb-12, 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", Tobias Heer, Rene Hummen, 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, 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, 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, 17-Feb-12, 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 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", Randall Stewart, Michael Tuexen, Irene Ruengeler, 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. "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. "Signaling RSVP-TE P2MP LSPs in an Inter-domain Environment", Zafar Ali, Rakesh Gandhi, 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). "BGP Class of Service Interconnection", Thomas 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. "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. "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. "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. "MPLS-TP OAM based on Y.1731", Italo Busi, Huub Helvoort, He Jia, 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. "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. "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. "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. "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-Luc 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", Greg Bernstein, Jonas Martensson, Takehiro Tsuritani, Tomonori Takeda, Young Lee, 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. "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 Ph.D., Stuart Cheshire, 21-Feb-12, 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", Lixia Zhang, Romain Kuntz, Ryuji Wakikawa, Zhenkai Zhu, 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, 13-Feb-12, 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. "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. "RTP Payload Format for DRA Audio", ChuSheng Zheng, JingPing Zhang, Mao Xu, Tian Jiang, WeiXiong 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", Dan Li, Daniele Ceccarelli, Diego Caviglia, Fatai Zhang, 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). "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. "Control Word Reserved bit for use in E-Tree", Simon DeLord, Raymond Key, 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. "Extension to VPLS for E-Tree", Raymond Key, Simon DeLord, 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. "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. "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. "MIF API consideration", Yuri Ismailov, Ted Lemon, Dapeng Liu, 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", Wentao Shang, Xing Li, Yu Zhai, Congxiao Bao, 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)", 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. "A Framework for E-Tree Service over MPLS Network", Raymond Key, Simon DeLord, 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. "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]. "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. "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", Mohammed 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. "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, 19-Feb-12, 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. "HIP-based Virtual Private LAN Service (HIPLS)", Steven Venema, David Mattes, Tom Henderson, 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. "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. "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. "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. "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. "PPSP Tracker Protocol (PPSP-TP)", Mario Nunes, David Bryan, Joao Taveira, Jinwei Xia, Gu Yingjie, Rui Cruz, Deng Lingli, 24-Feb-12, This document specifies the Peer-to-Peer Streaming Protocol--Tracker Protocol (PPSP-TP), an application-layer control (signaling) protocol for the exchange of meta information between trackers and peers, such as initial offer/request of participation in multimedia content streaming, content information, peer lists and reports of activity and status. The specification outlines the architecture of the protocol and its functionality, and describes message flows, message processing instructions, message formats, formal syntax and semantics. The PPSP Tracker Protocol enables cooperating peers to form content streaming overlay networks to support near real-time Structured Media content (audio, video, associated text/metadata) delivery, such as adaptive multi-rate, layered (scalable) and multi- view (3D), in live, time-shifted and on-demand modes. "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]. "Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP)", Petri Jokela, Robert Moskowitz, Jan Melen, 14-Feb-12, This memo specifies an Encapsulated Security Payload (ESP) based mechanism for transmission of user data packets, to be used with the Host Identity Protocol (HIP). "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. "Protocol for Carrying Authentication for Network Access (PANA) with IPv4 Unspecified Address", Alper Yegin, Yoshihiro Ohba, Lionel Morand, John Kaippallimalil, 14-Feb-12, 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]. "Recommendations on filtering of IPv4 packets containing IPv4 options", Fernando Gont, R. Atkinson, Carlos Pignataro, 17-Feb-12, This document document provides advice on the filtering of IPv4 packets based on the IPv4 options they contain. Additionally, it discusses the operational and interoperability implications of such filtering. "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. "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", Telecom Italia, Feng Huang, Zhang Haiyan, Han Li, Huub Helvoort, Jeong-dong Ryoo, 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. "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 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. "Controlling Session Initiation Protocol (SIP)-Established Content Delivery Channels Using the Real-Time Streaming Protocol (RTSP)", Jouni Maenpaa, Priya Rajagopal, Jan Lindquist, 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. "KX509 Kerberized Certificate Issuance Protocol", Henry Hotz, Russ Allbery, 21-Feb-12, This document describes a protocol, called kx509, for using Kerberos tickets to acquire X.509 certificates. These certificates may be used for many of the same purposes as X.509 certificates acquired by other means, but if a Kerberos infrastructure already exists then the overhead of using kx509 may be much less. While not (previously) standardized, this protocol is already in use at several large organizations, and certificates issued with this protocol are recognized by the International Grid Trust Federation. "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", Jiankang Yao, Dacheng Zhang, Xiaohu Xu, 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. "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. "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. "Request by JSON ver.1.0 for OAuth 2.0", John Bradley, Nat Sakimura, 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. "Miscellaneous additions to CoAP", Carsten Bormann, Klaus Hartke, 15-Feb-12, 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, Hans Elburg, 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. "HIP support for RFIDs", Pascal Urien, Gyu 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. "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. "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. "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, 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, 20-Feb-12, 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.ietf-behave-lsn-requirements] and describes the model 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 connectivity 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 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. "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. "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. "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". "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. "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", Changsheng Wan, Hongyan Wang, Xiaoping Liang, Yinxing Wei, 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", Cyril Margaria, Dan Li, Fatai Zhang, Oscar Dios, 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, 22-Feb-12, 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. "LDP extensions for Explicit Pseudowire to transport LSP mapping", 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. "Temporal and hitless path segment monitoring", Telecom Italia, 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. "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. "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, 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. "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. "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, 13-Feb-12, 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, 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. "6to4 Provider Managed Tunnels", Victor Kuarsingh, Yiu Lee, Olivier Vautrin, 15-Feb-12, 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", Alia Atlas, Carlos Pignataro, Enke Chen, Naiming Shen, Rajiv Asati, 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 (MIB) for the PCE Communications Protocol (PCEP) for Path-Key based Confidentiality in Inter-Domain Path Computation.", Dhruv Dhody, Udayasree Palle, Quintin Zhao, Daniel King, 21-Feb-12, 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 confidentiality in 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. "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. "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]. "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. "Prefix Pool Option for DHCPv6 Relay Agents on Provider Edge Routers", Leaf Yeh, Tina Tsou, 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. "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. "Multiprotocol Label Switching Transport Profile p2mp Shared Protection", Yu jinghai, Zongpeng Du, Yuefeng Ji, Yu jinghai, 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. "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", Cathy Zhou, Ole Troan, Qi Chen, Tina Tsou, Tom Taylor, 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. "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." "Secure Extension of BGP by Decoupling Path Propagation and Adoption", Beichuan Zhang, Bin Liu, Dacheng Zhang, Mingui 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. "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. "Energy Management (EMAN) Applicability Statement", Little Silver, Bruce Nordman, Emmanuel Tychon, 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. "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. "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. "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, 20-Feb-12, 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", Mohamed Boucadair, Qiong Sun, Tina Tsou, Yiu Lee, Yong Cui, 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, University Colorado, Victor Kuarsingh, 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", Hidetoshi Yokota, Carl Williams, Sri Gundavelli, Julien Laganier, 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 for enterprises, or for supporting some of the IPv6 transitioning solutions related to IPv4 address exhaust problem, a home agent may have to allocate the same private IPv4 address to multiple mobile nodes. The Dual-stack Mobile IPv6 does not have such support. This document specifies extensions to Dual-stack Mobile IPv6 for supporting overlapping private IPv4 address assignment support. "Multicast Router Key Management Protocol (MaRK)", Dacheng Zhang, Gregory Lebovitz, Sam Hartman, 11-Jan-12, Several routing protocols engage in one-to-many communication. In order to authenticate these communications using symmetric cryptography, a group key needs to be established. This specification defines a group protocol for establishing and managing such keys. "Performance Measurement Metrics of Label Switched Path (LSP) Establishment in Multi-Layer and Multi-Domain Networks", Yuefeng Ji, Weiwei Bian, Hongxiang Wang, Shanguo Huang, Guoying Zhang, 19-Oct-11, As the increment of network scale, optical networks need to be partitioned into multi-layer and multi-domain networks for the purpose of better management. Meanwhile, as the variety of user requests, different LSPs need to be established. In order to meet different requirements of users, the LSP establishment performance is necessary to be measured in multi-layer and multi-domain networks. For this reason, typical performance measurement metrics need to be proposed. In this document, the LSP establishment delay and bit error ratio (BER), which are both as the performance measurement metrics, are illustrated, and the definition and methodologies are proposed. "Exporting MIB Variables using the IPFIX Protocol", Andrew Johnson, Benoit Claise, Paul Aitken, Juergen Schoenwaelder, 31-Oct-11, This document specifies a way to complement IPFIX Flow Records with Management Base (MIB) objects, avoiding the need to define new IPFIX Information Elements for existing Management Information Base objects that are already fully specified. This method requires an extension to the current IPFIX protocol. New Template Set and Options Template Sets are specified to allow the export of Simple Network Management Protocol (SNMP) MIB Objects along with IPFIX Information Elements. "Multi-access Indicator for Mobility", Rajeev Koodli, Jouni Korhonen, 30-Aug-11, When a Mobile Node attaches to the mobile network using multiple access networks, it is important for the Mobile Network Gateway to know whether the Mobile Node is capable of simultaneous multi-access, so that the former can distribute the traffic flows using the most appropriate interface. This document defines a new EAP attribute which can be used for such an indication to the Mobile Network Gateway. The document also reserves a new MIP6-Feature-Vector flag. "PMIPv6 inter-working with WiFi access authentication", Marco Liebsch, Pierrick Seite, Sri Gundavelli, 22-Oct-11, Proxy Mobile IPv6, the IETF's protocol for network-based mobility management, requires a completed and successful authentication of the mobile node before it is registered at the mobility anchor. This document describes inter-working between access authentication mechanisms, such as IEEE 802.1X, and the Proxy Mobile IPv6 protocol to enable trusted WiFi access to a network-based mobility management domain. Furthermore, the use of authentication method specific identifiers for unique identification of mobile nodes during setup and maintenance of their mobility session is described, following recommendations of related standards organizations, such as 3GPP and the WiMAX Forum. "Privacy Considerations for Internet Protocols", Bernard Ph.D., John Morris, Jon Peterson, Hannes Tschofenig, 14-Mar-11, This document aims to make protocol designers aware of privacy- related design choices and offers guidance for developing privacy considerations for IETF documents. While specifications cannot police the implementation community, nonetheless protocol architects must play in the improvement of privacy, both by making a conscious decision to design for privacy, and by documenting privacy risks in protocol designs. This document is discussed on the Internet Privacy Discussion mailing list (see https://www.ietf.org/mailman/listinfo/ietf-privacy). "Distributed Authentication in Wireless Mesh Networks Through Kerberos Tickets", Gilles Bourdon, Hassnaa Moustafa, Tom Yu, 17-Oct-11, This document presents the problem of authentication and authorization in wireless mesh networks constituted by several users communicating with application servers and communicating with each other in a single or multi-hop fashion. Each user in this environment can also play the role of an application provider. Imagine a large music event where the provided network infrastructure is enhanced with network storage equipment to allow visitors to access content relating to the bands playing at the events, such as recorded video of previous performances, supplementary audio and video material relevant to the bands playing, etc. Certain content is, however, not necessarily available to everyone under the same conditions. Instead access control is applied before the full range of audio, and video material can be accessed. Other content, such as previews, might be offered for free. How can such authentication, and authorization infrastructure be made available with minimal configuration complexity for a temporary event like a music festival? This document lists the requirements for a potentially needed Kerberos extension and presents a solution proposal based on the attempt to use a Kerberos extension for mutual authentication in wireless mesh networks. "Alternate Tunnel Source Address for Home Agent", Charles Perkins, 31-Oct-11, Widely deployed mobility management systems for wireless communications have isolated the path for forwarding data from the control plane signaling for mobility management. To realize this requirement with Mobile IP requires that the control functions of the home agent be addressable at a different IP address than the source IP address of the tunnel between the home agent and mobile node. Similar considerations hold for mobility anchors implementing Hierarchical Mobile IP or PMIP. "BGP MPLS Based Ethernet VPN", Rahul Aggarwal, Ali Sajassi, Wim Henderickx, Aldrin Isaac, James Uttaro, Nabil Bitar, Ravi Shekhar, 12-Sep-11, This document describes procedures for BGP MPLS based Ethernet VPNs (E-VPN). "Definition of Managed Objects for the IPv6 Routing Protocol for Low Power and Lossy Networks (RPL)", Anuj Sehgal, Cathy Zhou, Juergen Schoenwaelder, Kevin Korte, Tina Tsou, 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 objects for managing the IPv6 Routing Protocol for Low Power and Lossy Networks (RPL). "ARP Broadcast Reduction for Large Data Centers", Anoop Ghanwani, Himanshu Shah, Nabil Bitar, 31-Oct-11, With advent of server virtualization technologies, a host is able to support multiple Virtual Machines (VMs) in a single physical machine. Data Centers can leverage these capabilities to instantiate on the order of 10s to 100s of VMs in a single server with current technology. It is conceivable that this number can be much higher in the future. Each VM operates as an independent IP host with a set of Virtual Network Interface Cards (vNICs), each having its own MAC address and mapping to a physical Ethernet interface. These physical servers are typically installed in a rack with their Ethernet interfaces connected to a top-of-the-rack (ToR) switch. The ToR switches are interconnected through End-of-the-Row (EoR) or aggregation switches which are in turn connected to core switches. As discussed in [ARP-Problem] the host VMs use ARP broadcasts to find other host VMs and use periodic (broadcast) Gratuitous ARPs to refresh their IP to MAC address binding in other VM hosts. Such broadcasts in a large data center with potentially thousands of VM hosts in a Layer 2 based topology can overwhelm the network. This memo proposes mechanisms to reduce the number of broadcasts that are sent throughout the network. This is done by having the ToRs intelligently process ARP and frames, rather than simply broadcasting them throughout the broadcast domain. While this document addresses ARP, the Neighbor Discovery mechanisms used by the IPv6 hosts that make use of multicast rather than broadcast also pose similar issues in the Data Center. The solutions defined herein should be equally applicable to hosts running IPv6. The details will be specified in a subsequent revision. "Stateful PCE", Kexin Tang, Xuping Cao, Xuerong Wang, 31-Oct-11, A PCE can be either stateful or stateless. The information carried in a stateful PCE is more detailed than that of a stateless PCE. This draft focus on stateful PCE, describes the problems without stateful PCE, and gives the IGP and PCEP extensions to realize stateful PCE. "A PPSP Tracker Usage for Reload", Xuan Tai, Lin Xiao, Gu Yingjie, David Bryan, 25-Oct-11, This document defines PPSP tracker usages for REsource LOcation And Discovery (RELOAD). Although PPSP assumes a centralized tracker from peer's point of view, the logical centralized tracker could be realized by a cluster of geographically distributed trackers. In this draft, we design distributed trackers system, which are organized by RELOAD. It provides lookup service for file/channel indexes and Peer Status among the distributed trackers. "Performance Metric of Convergence Time of Information Flooding in Multi- Area GMPLS Networks", Hui Ding, Yunbin Xu, Haiyi Zhang, Yongli Zhao, Min Zhang, 21-Oct-11, As one of the requirements of link state based routing protocols such as OSPF, link state update packets are intervally or reactively disseminate in the network in order to keep the information of topology and links resource synchronized at each control node. Considering large scale networks, massive messages are flooded in the control plane of General Multi-Protocol Label Switching (GMPLS) based multi-area networks. The convergence time of link state based routing protocols will have a significant impact on the performance of the networks. So measuring and analyzing the convergence time of information flooding in multi-areas becomes very important. This document provides suggestions for measuring OSPF multi-area control plane convergence. A performance metric of convergence time of information flooding is proposed to characterize the ability of information synchronization in multi-area networks. "Network Survivability Evaluation Metrics in Multi-domain Generalized MPLS Networks", Yunbin Xu, Yuefeng Ji, Yu Wang, Lifang Zhang, Min Zhang, 18-Oct-11, The ubiquitous presence of the internet coupled with the increasing demand for high bandwidth dedicated large scale network has made it imperative that the multi-domain networks are facilitated by the development of GMPLS. In such large scale network, the high performance network survivability is a significant factor to resist the fault service discontinue and interruption even to decrease economic loss and the society impact. This document proposes a series of network survivability evaluation metrics and methodologies that can be used to demonstrate the network survivability performance in single and multi-domain GMPLS networks, more specifically, the network fault restoration performance. "Protocol Extension Requirement for Cooperation between PCE and Distributed Routing Controller in GMPLS Networks", Dajiang Wang, Jie Zhang, Ruiquan Jing, Xihua Fu, Yongli Zhao, 20-Oct-11, Path Computation Element (PCE) is proposed for path computation in multi-layer and multi-domain networks where PCE can be implemented in either centralized method or distributed method. In the former case, PCE can serve tens or hundreds of nodes simultaneously, while in the later case, each node is equipped with a PCE, which can be regarded as a distributed routing controller (DRC) in GMPLS networks and each one of those provides similar path computation capability. PCE and DRC have different advantages in path computation respectively. PCE is suitable for cross-layer and cross-domain path computation, especially in multi-constraints environment. But distributed routing controller is good at path computation in parallel ways and distributed network control in local domain. A cooperative path computation architecture named Dual Routing Engine (DRE) is necessary to be used in the future networks, for it based on the ideas of the cooperation of these two types of path computation engines and can take the advantages of both centralized and distributed method by which the PCE is implemented. The corresponding PCE communication protocol extension and other protocol requirements for cooperation between PCE and distributed routing controller are listed in this document to recommend the standard interfaces between different components in DRE architecture. "A Lightweight Approach to Node-to-Node Security in Diameter", Glen Zorn, Wenson Wu, 25-Jan-12, This document describes a lightweight method for cryptographically protecting a portion of the contents of a Diameter message in transit between an arbitrary pair of Diameter nodes. The scheme assumes that the destination node possesses an X.509 certificate containing an RSA public key and that that certificate is retrievable through a DNS query by the node originating the message. In addition to describing the operation of the protocol, this note specifies an Attribute-Value Pair (AVP) for the encapsulation of encrypted AVPs. "The Internet of Things - Concept and Problem Statement", Noel Crespi, Gyu Lee, Park Jung-Soo, Ning Kong, 31-Oct-11, This document explains the concept of the Internet of Things and several characteristics of objects. In addition, this document specifies problems considering technical issues for the IoT. Based on this, this document discusses a new architectural framework in order to solve problems. "Basic BGP Convergence Benchmarking Methodology for Data Plane Convergence", Rajiv Papneja, Bhavani Parise, Susan Hares, Ilya Varlashkin, 21-Oct-11, BGP is widely deployed and used by several service providers as the default Inter AS routing protocol. It is of utmost importance to ensure that when a BGP peer or a downstream link of a BGP peer fails, the alternate paths are rapidly used and routes via these alternate paths are installed. This document provides the basic BGP Benchmarking Methodology using existing BGP Convergence Terminology, RFC 4098. "SCTP Socket API Extensions for Concurrent Multipath Transfer", Thomas Dreibholz, Martin Becke, 26-Oct-11, This document describes extensions to the SCTP sockets API for configuring the CMT-SCTP and CMT/RP-SCTP extensions. "Sender Queue Info Option for the SCTP Socket API", Thomas Dreibholz, Robin Seggelmann, Martin Becke, 26-Oct-11, This document describes an extension to the SCTP sockets API for querying information about the sender queue. "Reference Model for Energy Management", Juergen Quittek, Bruce Nordman, Rolf Winter, 31-Oct-11, Managing energy consumption of devices is different from several well understood network management functions because of the special nature of energy supply and use. This document explains issues of energy management arising from its special nature and proposes a layered reference model for energy management addressing these issues. "Security Bootstrapping of Resource-Constrained Devices", Behcet Sarikaya, Robert Cragie, Robert Moskowitz, Yoshihiro Ohba, Zhen Cao, 31-Oct-11, This document describes how to initially configure the network of resource constrained nodes securely, a.k.a., security bootstrapping. Bootstrapping architecture, communication channel and bootstrap security methods are described. System level objectives for security bootstrapping are stated followed by the protocols that can be used. Requirements on these protocols to be used as security bootstrapping protocols are identified. "HTTP framework for time-based access to resource states -- Memento", Herbert Sompel, Michael Nelson, Robert Sanderson, 20-Dec-11, The HTTP-based Memento framework bridges the present and past Web by interlinking current resources with resources that encapsulate their past. It facilitates obtaining representations of prior states of a resource, available from archival resources in Web archives or version resources in content management systems, by leveraging the resource's URI and a preferred datetime. To this end, the framework introduces datetime negotiation (a variation on content negotiation), and new Relation Types for the HTTP "Link" header aimed at interlinking resources with their archival/version resources. It also introduces various discovery mechanisms that further support bridging the present and past Web. "Applicability of Proxy Mobile IPv6 Protocol for WLAN Access Networks", Sri Gundavelli, 22-Oct-11, Proxy Mobile IPv6 is a network-based mobility management protocol. The protocol is designed for providing mobility management support to a mobile node, without requiring its participation in any IP mobility related signaling. The base protocol is defined in an access technology independent manner, it identifies the general requirements from the link-layer for supporting the protocol operation. However, it does not provide any specific details on how it can be supported on a specific access technology. This specification identifies the key considerations for supporting Proxy Mobile IPv6 protocol on the widely deployed wireless LAN access architectures, based on IEEE 802.11 standards. It explores the current dominant wireless LAN deployment models and provides the needed interworking details. "Mobile Ad-hoc On-Demand Data Delivery Protocol (MAODDP)", Humayun Bakht, 28-Jul-11, Routing in mobile ad-hoc network is achieved through the mutual cooperation of mobile devices that form routes in between two mobile nodes.It is one of the challenging issues in mobile ad-hoc network [1]. The current protocols for an ad-hoc network can generally be categorized into two groups i.e. pro-active and re-active[15,16,17,18]. Pro-active protocols by continuously evaluating the known and attempting to discover new routes. These protocols try to maintain the most up-to-date view of the network[2]. This allows them to efficiently forward packets as the route is known in advanced [14]. In contrast reactive protocols determine the route only when require [3, 5, 6]. Mobile Ad-hoc On Demand Data Delivery protocol (MAODDP) establishes route on demand and delivers the data at the same time one after the other [22].MAODDP support both unicast and multicast routing. It is designed to minimize reaction to topological changes. In order to ensure the freshness of route MAODDP uses combination of sequence numbers and broadcast ID. MAODDP is loop-free, self-starting protocol whic can scales to different size of networks. MAODDP offers quick adaptation to the dynamic link conditions and determines routes to the destinations on demand. "End-to-End Session Identification in IP-Based Multimedia Communication Networks", Chris Pearce, Gonzalo Salgueiro, James Polk, Paul Jones, 30-Jan-12, This document describes an end-to-end Session Identifier for use in IP-based Multimedia Communication systems that enables endpoints, intermediate devices, and management systems to identify a session end-to-end, associate multiple endpoints with a given multipoint conference, track communication sessions when they are redirected, and associate one or more media flows with a given communication session. "Specifying That a Server Supports TLS", Paul Hoffman, 8-Sep-11, A server that hosts applications that can be run with or without TLS may want to communicate with clients whether the server is hosting an application only using TLS or also hosting the application without TLS. Many clients have a policy to try to set up a TLS session but fall back to insecure if the TLS session cannot be set up. If the server can securely communicate whether or not it can fall back to insecure tells such a client whether or not they should even try to set up an insecure session with the server. This document describes the use cases for this type of communication and a secure method for communicating that information. "Ethics Search Protocol (ESP) for Internet Search Engines", Bernhard Fastenrath, 9-Dec-10, This document contains a specification for imprints, ethical policies and social contracts, the annotation of these, as well as the annotation of arbitrary content that can be referenced by fully qualified URIs, the submission of digitally signed tickets concerning imprints, ethical policies, social contracts or annotations, and a search interface for internet search engines. "TCP and SCTP RTO Restart", Per Hurtig, Michael Welzl, Andreas Petlund, 29-Oct-11, This document describes a modified algorithm for managing the TCP and SCTP retransmission timers, that provides faster loss recovery when a connection's amount of outstanding data is small. The modification allows the transport to restart its retransmission timer more aggressively in situations where fast retransmit can not be used. This enables faster loss detection, and recovery, for connections that are short-lived or application-limited. "Definition of Managed Objects for SAVI Protocol", Changqing An, Jiahai Yang, Jianping Wu, Jun Bi, 19-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 defines objects for managing SAVI (Source Address Validation Improvements) protocol instance. "Automating the Initial Window in TCP", Joseph Touch, 17-Jan-12, The Initial Window (IW) provides the starting point for TCP's feedback-based congestion control algorithm. Its value has increased over time to increase performance and to reflect increased capability of Internet devices. This document describes a mechanism to adjust the IW over long timescales, to make future changes more safely deployed and to potentially avoid reexamination of this value in the future. "JSON Web Token (JWT)", Michael Jones, Dirk Balfanz, John Bradley, Yaron Goland, John Panzer, Nat Sakimura, Paul Tarjan, 14-Dec-11, JSON Web Token (JWT) is a means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is digitally signed using JSON Web Signature (JWS) and/or encrypted using JSON Web Encryption (JWE). The suggested pronunciation of JWT is the same as the English word "jot". "Cloud/DataCenter SDO Activities Survey and Analysis", Bhumip Khasnabish, Chu JunSheng, 28-Dec-11, The objective of this draft is to present a snapshot of industry standards activities related to Cloud/DataCenter computing, networking and services including relevant features and functions. This document is a survey of current activities of cloud standards development organizations (SDOs). At the end of this survey a section on gap analysis is also presented. "Cloud Industry Workitem Survey Results", Bhumip Khasnabish, Chu JunSheng, Yu Meng, 1-Jan-12, This document presents a survey of the industry work items related to cloud computing, networking and services. At the end of this survey a section on gaps related to work items is presented. "Cloud Reference Framework", Bhumip Khasnabish, Chu JunSheng, SuAn Ma, Yu Meng, Ning So, Paul Unbehagen, Monique Morrow, Masum Hasan, 27-Dec-11, This document presents a cloud reference framework. In general, a cloud based system utilizes virtualized resources and applications. The reference framework is based on the survey of the SDOs and WGs that are focusing on cloud-based systems and services (draft- Khasnabish-cloud-sdo-survey). Both intra-cloud and inter-cloud reference frameworks are presented and the requirements of each layer are discussed. "Encoding the graphemes of the SignWriting Script with the x-ISWA-2010", Stephen Slevinski, Valerie Sutton, 3-Jan-11, For concreteness, because the universal character set is not yet universal, because an undocumented and unlabeled coded character set hampers information interchange, a 12-bit coded character set has been created that encodes the graphemes of the SignWriting script as described in the open standard of the International SignWriting Alphabet 2010. The x-ISWA-2010 coded character set is defined with hexadecimal characters and described with Unicode characters, either proposed characters on plane 1 or interchange characters on plane 15. This memo defines a standard coded character set for the Internet community. It is published for reference, examination, implementation, and evaluation. Distribution of this memo is unlimited. "RADIUS Extensions for Port Control Protocol", Dean Cheng, Roberta Maglione, 22-Dec-11, This memo proposes a new Remote Authentication Dial In User Service (RADIUS) attribute to carry the Fully Qualified Domain Name (FQDN) of a Port Control Protocol (PCP) server, such that while the PCP server information is configured on a RADIUS server, the information can be conveyed to Network Access Server (NAS) via RADIUS protocol, and the co-located Dynamic Host Configuration Protocol (DHCP/DHCPv6) server can then populate the information to PCP client. "ECN for Stream Control Transmission Protocol (SCTP)", Randall Stewart, Michael Tuexen, Xuesong Dong, 17-Feb-12, This document describes the addition of the ECN to the Stream Control Transmission Protocol (SCTP). "Port Control Protocol (PCP) Failure Scenarios", Mohammed Boucadair, Francis Dupont, Reinaldo Penno, 12-Sep-11, This document identifies and analyzes several PCP failure scenarios. A procedure to retrieve the explicit dynamic mapping(s) from the PCP Server is proposed. This procedure relies upon the use of a new PCP OpCode and Option: GET/NEXT. "Simple Web Discovery (SWD)", Michael Jones, Yaron Goland, 14-Dec-11, Simple Web Discovery (SWD) defines an HTTPS GET based mechanism to discover the location of a given type of service for a given principal starting only with a domain name. "Multicast Support for NAT64", Behcet Sarikaya, Teemu Kiviniemi, 10-Jan-12, This memo specifies modifications required to NAT64 so that IPv6 only hosts can receive multicast data from IPv4 only servers. The protocol is based on translating IPv4 multicast data before delivering it to the host in IPv6. The protocol also allows IPv6 only host to join IPv4 any source/ source specific multicast group in IPv6 using Multicast Listener Discovery protocol. "TWAMP Value-Added Octets", Steve Baillargeon, Christofer Flinta, Andreas Johnsson, Svante Ekelin, 24-Jan-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. "A Session Initiation Protocol (SIP) INFO package for Private Wire", Chris Boulton, 18-Oct-11, Application level data exchanged using the SIP INFO method are supported and documented in specifications known as 'INFO Packages'. This document defines functionality associated with Session Initiation Protocol (SIP) Private Wire functionality and creates an 'INFO Package' for carrying such application level data. "Virtual Private LAN Service (VPLS) Using IS-IS", Himanshu Shah, Xiaohu Xu, 13-Oct-11, This document describes a light-weight Virtual Private LAN Service (VPLS) which uses IS-IS for auto-discovery and signaling. "Requirements for Message Access Control", Trevor Freeman, Jim Schaad, Patrick Patterson, 20-Oct-11, There are many situations where organizations want to protect information with robust access control, either for implementation of intellectual property right protections, enforcement of information contractual confidentiality agreements or because of externally imposed legal regulations. The Enhanced Security Services (ESS) for S/MIME defines an access control mechanism which is enforced by the recipients client after decryption of the message. The ESS mechanism therefore is dependent on the correct access policy configuration of every recipients client. This mechanism also provides full access to the data to all recipients prior to the access control check which is considered to be inadequate for due to the difficulty in demonstrating policy compliance. This document lays out the deficiencies of the current ESS security label, and presents requirements for new model for doing access control to messages where the access check is performed prior to message content decryption. This new model also does not require policy configuration on the client to simplify deployment and compliance verification. The proposed model additionally provides a method where non-X.509 certificate credentials can be used for encryption/decryption of S/MIME messages. "Using LDP Multipoint Extensions on Targeted LDP Sessions", Maria Napierala, Eric Rosen, 24-Oct-11, Label Distribution Protocol (LDP) can be used to set up Point-to-Multipoint (P2MP) and Multipoint-to-Multipoint (MP2MP) Label Switched Paths. The existing specification for this functionality assumes that a pair of LDP neighbors are directly connected. However, the LDP base specification allows for the case where a pair of LDP neighbors are not directly connected; the LDP session between such a pair of neighbors is known as a "Targeted LDP" session. This document specifies the use of the LDP P2MP/MP2MP extensions over a Targeted LDP session. "A Simple Method for Segmenting Multicast Tunnels for Multicast VPNs", Maria Napierala, Eric Rosen, 24-Oct-11, To provide Multicast VPN (MVPN) Service, Service Providers (SPs) need to instantiate multicast tunnels (known as "P-tunnels") that enable the Provider Edge (PE) routers of a given VPN to transmit multicast packets to each other. Some SPs organize their networks in a hierarchical manner, with the PE routers in "edge areas", and the edge areas connected to each other via a "core area". A P-tunnel that connects PE routers in different edge areas can be thought of as having three segments: a segment through one edge area, a segment through the core area, and a segment through the second edge area. It is desirable to preserve the independence of the core area by allowing it to use a different tunneling technology than that used in the edge areas. However, it is not desirable for the core area Border Routers (BRs) to participate in the MVPN-specific signaling, or even to have any knowledge of which MVPNs are in the edge areas that attach to it. This document specifies a simple method for segmenting MVPN P-tunnels at the BRs, subject to these constraints. "Carrying next-hop cost information in BGP", Ilya Varlashkin, Robert Raszuk, 16-Sep-11, 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. "Network Management Scenarios for RELOAD", YongLin Peng, Wei Wang, Jin Peng, Lifeng Le, ZhenWu Hao, Yu Meng, 6-Sep-11, The RELOAD protocol can be applied in different kinds of scenarios, including the Internet, carrier's dedicated network, enterprise network, etc. This document summarizes the network management scenarios by analyzing typical application model for each of the above three kinds of scenarios. "Reserving N and N+1 Ports with PCP", Mohamed Boucadair, Senthil Sivakumar, 18-Oct-11, This document defines a new PCP Option to reserve a pair of ports in a PCP-controlled device while preserving the parity and contiguity. This PCP Option eases the NAT traversal for RTP/RTCP flows. "Media level ice-options SDP attribute", Marc Petit-Huguenin, 20-Dec-11, This document normatively updates RFC 5245 by redefining the ice- options SDP attribute as a session-level and media-level attribute. "ICE Updated Offer Problematic", John Elwell, Andrew Hutton, Thomas Stach, 12-Dec-11, Interactive Connectivity Establishment (ICE) requires an updated offer-answer cycle under some circumstances, to satisfy the needs of some devices on the signalling path. When used with SIP, this additional offer-answer cycle interacts with other things, such as fax and third party call control (3PCC). This document describes the problems and discusses possible remedies. This work is being discussed on the mmusic@ietf.org mailing list. "A Uniform Resource Name Namespace for the Device Identity and the Mobile Equipment Identity (MEID)", Roozbeh Atarius, 25-Aug-11, The specification fulfills the requirement from Third Generation Partnership Project 2 (3GPP2) by registering a Uniform Resource Name (URN) namespace for the device identity and a sub namespace for the Mobile Equipment Identity (MEID). The structure of the MEID is 15 hexadecimal encoded digits long and is defined in 3GPP2 to uniquely identify a mobile equipment. "RTCP XR Blocks for QoE metric reporting", Geoff Hunt, Alan Clark, Wenson Wu, Roland Schott, Glen Zorn, 30-Dec-11, This document defines an RTCP XR Report Block and associated SDP parameters that allow the reporting of QoE metrics for use in a range of RTP applications. "RTCP XR Report Block for TS Decodability Statistics Metric Reporting", Rachel Huang, Qin Wu, Hitoshi Asaeda, Glen Zorn, 14-Feb-12, Transport Stream is a standard container format used in the transmission and storage of multimedia data. This document defines an RTCP XR Report Block that allows the reporting of decodability statistics metrics related to transmissions in Transport Stream format. "Content Distribution Network Interconnection (CDNI) Experiments", Francois Faucheur, Larry Peterson, 15-Feb-12, This document reports studies and related experiments on CDN interconnection performed by France Telecom-Orange Labs. The document summarizes implications of CDN interconnection to CDN service providers and lessons learned through CDNI experiments. The main purpose of the experiments was to test the interconnection of CDN solutions from two vendors (namely, Cisco and Verivue) and to identify the gaps and needs for standardization work for CDN interconnection. "PCEP Extension for WSON Routing and Wavelength Assignment", Ramon Casellas, Young Lee, 31-Oct-11, This draft provides the Path Computation Element communication Protocol (PCEP) extensions for the support of Routing and Wavelength Assignment (RWA) in Wavelength Switched Optical Networks (WSON). Lightpath provisioning in WSONs requires a routing and wavelength assignment (RWA) process. From a path computation perspective, wavelength assignment is the process of determining which wavelength can be used on each hop of a path and forms an additional routing constraint to optical light path computation. "Recommendations for Efficient Implementation of RPL", Omprakash Gnawali, P Levis, 13-Sep-11, RPL is a flexible routing protocol applicable to a wide range of Low Power and Lossy Networks. To enable this wide applicability, RPL provides many configuration options and gives implementers choices on how to implement various components of RPL. Drawing on our experiences, we distill the design choices and configuration parameters that lead to efficient RPL implementations and operations. "SCS: Secure Cookie Sessions for HTTP", Stefano Barbato, Steven Dorigotti, Thomas Fossati, 20-Dec-11, This document provides an overview of SCS, a small cryptographic protocol layered on top of the HTTP cookie facility, that allows its users to produce and consume authenticated and encrypted cookies, as opposed to usual cookies, which are un-authenticated and sent in clear text. An interesting property, rising naturally from the given confidentiality and authentication properties, is that by using SCS cookies, it is possible to avoid storing the session state material on the server side altogether. In fact, an SCS cookie presented by the user agent to the origin server can always be validated (i.e. possibly recognized as self-produced, untampered material) and, as such, be used to safely restore application state. Hence, typical use cases may include devices with little or no storage offering some functionality via an HTTP interface, as well as web applications with high availability or load balancing requirements which would prefer to handle application state without the need to synchronize the pool through shared storage or peering. Nevertheless, its security properties allow SCS to be used whenever the privacy and integrity of cookies is a concern, by paying an affordable price in terms of increased cookie size, additional CPU clock cycles needed by the symmetric key encryption and HMAC algorithms, and related key management, which can be made a nearly transparent task. "MPLS-TP Ring Protection Switching (MRPS)", Huub Helvoort, Jeong-dong Ryoo, 27-Aug-11, This document describes a mechanism to address the requirements for protection of the Multi-Protocol Label Switching Transport Profile (MPLS-TP) Label Switched Paths (LSP) in a ring topology. The mechanism defined herein is designed to support point-to-point as well as point-to-multipoint LSPs. The MPLS-TP section layer OAM is used to monitor the connectivity between each two adjacent nodes using the mechanisms defined in the [MPLS-TP OAM]. The Automatic Protection Switching (APS) protocol is used for coordination of protection switching actions between the ring nodes. "Network Time Mechanisms for Improving Computer Clock Accuracy", Sterling Knickerbocker, Timothy Plunkett, 30-Oct-11, This draft describes network time synchronization mechanisms that may enable increased accuracy, beyond that possible with the current Network Time Protocol version 4 standard, to the time of computer clocks. The mechanisms considered are those that will provide improved estimates as to when a packet is put on the network, transferred across a network, or taken from the network. Potential standardization actions will be considered for the mechanisms considered, though no such actions are recommended at this time. "Multipath RTP (MPRTP)", Varun Singh, Teemu Karkkainen, Joerg Ott, Saba Ahsan, Lars Eggert, 31-Oct-11, The Real-time Transport Protocol (RTP) is used to deliver real-time content and, along with the RTP Control Protocol (RTCP), forms the control channel between the sender and receiver. However, RTP and RTCP assume a single delivery path between the sender and receiver and make decisions based on the measured characteristics of this single path. Increasingly, endpoints are becoming multi-homed, which means that they are connected via multiple Internet paths. Network utilization can be improved when endpoints use multiple parallel paths for communication. The resulting increase in reliability and throughput can also enhance the user experience. This document extends the Real-time Transport Protocol (RTP) so that a single session can take advantage of the availability of multiple paths between two endpoints. "Throughput Measurement for MPLS-based Transport Networks", Feng Huang, Han Li, Min Xiao, Ruiquan Jing, Sriganesh Kini, 11-Oct-11, An important Operation, Administration and Maintenance (OAM) requirement of the MPLS Transport Profile (MPLS-TP) is the ability to measure the throughput (i.e. bandwidth) of an MPLS-TP connection which could be an MPLS-TP PseudoWire (PW), Label Switched Path (LSP) or Section. This document specifies the OAM packet formats and procedures for both one-way and two-way throughput measurement in MPLS-TP. "Scalable, Loop-Free BGP FRR using Repair Label", Ahmed Bashandy, Burjiz Pithawala, Jakob Heitz, 30-Oct-11, Consider a BGP free core scenario. Suppose the provider edge BGP speakers PE1, PE2,..., PEn know about a prefix P/p via the external routers CE1, CE2,..., CEm. If the PE router PEi loses connectivity to the primary path, it is desirable to immediately restore traffic by rerouting packets arriving from the core to PEi and destined to the prefix P/p to one of the other PE routers that advertised P/p, say PEj, until BGP re-converges. However if the loss of connectivity of PEi to the primary path also resulted in the loss of connectivity between PEj and CEj, rerouting a packet before the control plane converges may result in a loop. In this document, we propose using a repair label for traffic restoration while avoiding loops. We propose advertising the "repair" label through BGP. "Extending the Virtual Router Redundancy Protocol for TRILL campus", ZTE Corporation, fangwei hu, 29-Dec-11, TRILL can be implemented in data center networks, which requires high reliability and stability. Whenever the egress RBridges or links break down, the TRILL rerouting time depends on the IS-IS topology convergence time, which may do not meet data center service requirements in terms of resiliency. VRRP provides a redundancy mechanism to avoid single point of failure and fast switching over. This draft proposes to extend VRRP protocol to TRILL in data center networks. "Lightweight Secure Neighbor Discovery for Low-power and Lossy Networks", Behcet Sarikaya, Frank Xia, Greg Zaverucha, 31-Oct-11, This document defines lightweight secure neighbor discovery for low- power and lossy networks. The nodes generate a Cryptographically Generated Address, register the Cryptographically Generated Address with a default router and periodically refresh the registration. Modifications to 6lowpan Neighbor Discovery protocol are described for secure neighbor discovery for low-power and lossy networks. Cryptographically generated address and digital signatures are calculated using elliptic curve cryptography, so that the cryptographic operations are suitable for low power devices. "Analysis of Solution Candidates to Reveal a Host Identifier in Shared Address Deployments", Mohammed Boucadair, Joseph Touch, Pierre Levis, Reinaldo Penno, 2-Sep-11, This document analyzes a set of solution candidates which have been proposed to mitigate some of the issues encountered when address sharing is used. In particular, this document focuses on means to reveal a host identifier 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. The ultimate goal is to assess the viability of proposed solutions and hopefully to make a recommendation on the more suitable solution(s). "Signal 3D format", Bert Greevenbosch, Hui Yu, 31-Oct-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. "Using Secure DNS to Associate Certificates with Domain Names For S/MIME", Paul Hoffman, Jakob Schlyter, 22-Feb-12, S/MIME uses certificates for authenticating and encrypting messages. Users want their mail user agents to securely associate a certificate with the sender of an encrypted and/or signed message. DNSSEC provides a mechanism for a zone operator to sign DNS information directly. This way, bindings of certificates to users within a domain are asserted not by external entities, but by the entities that operate the DNS. This document describes how to use secure DNS to associate an S/MIME user's certificate with the intended domain name. IMPORTANT NOTE: This draft is intentionally sketchy. It is meant as a possible starting point for the DANE WG if it wants to consider making a protocol similar to TLSA, as described in draft-ietf-dane-protocol, but that applies to S/MIME. The WG may or may not want to adopt such work, or if it does, may want to use a very different scheme from the one described here. "Standard Representation Of Domain Sequence", Dhruv Dhody, Udayasree Palle, Ramon Casellas, 9-Feb-12, The ability to compute shortest constrained Traffic Engineering Label Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains has been identified as a key requirement for P2P and P2MP scenarios. In this context, a domain is a collection of network elements within a common sphere of address management or path computational responsibility such as an IGP area or an Autonomous Systems. This document specifies a standard representation and encoding of a domain sequence, which is defined as an ordered sequence of domains traversed to reach the destination domain. This document also defines new sub-objects to be used to encode domain identifiers. "OSPF Traffic Engineering (TE) Express Path", Spencer Giacalone, David Ward, John Drake, Alia Atlas, Stefano Previdi, 21-Sep-11, In certain networks, such as, but not limited to, financial information networks (e.g. stock market data providers), network performance criteria (e.g. latency) are becoming as critical to data path selection as other metrics. This document describes extensions to OSPF TE [RFC3630] such that network performance information can be distributed and collected in a scalable fashion. The information distributed using OSPF TE Express Path can then be used to make path selection decisions based on network performance. Note that this document only covers the mechanisms with which network performance information is distributed. The mechanisms for measuring network performance or acting on that information, once distributed, are outside the scope of this document. "NETCONF over WebSocket", Tomoyuki Iijima, Hiroyasu Kimura, Yoshifumi Atarashi, Hidemitsu Higuchi, 20-Oct-11, This memo proposes transporting NETCONF over WebSocket protocol[I-D.ietf-hybi-thewebsocketprotocol]. The use of HTTP and Web-based applications are increasing with the emergence of advanced drawing technologies and cloud computing. IT management systems supporting browser-based interface are getting common. It's natural for network management systems to support Web-based interface. Currently, however, few network management protocols support the transportation over HTTP. Although NETCONF[RFC6241] was defined to be sent over SOAP/HTTPS[RFC4743], it was excluded from the options of realizing notification mechanism[RFC5277] since HTTP lacks bi- directional capabilty. At present, WebSocket protocol, the update of HTTP with bi-directional capability, is available. This memo describes the way NETCONF is sent over WebSocket protocol. "Stateless 4Via6 Address Sharing", Wojciech Dec, Rajiv Asati, Hui Deng, 14-Oct-11, This document presents an overview of the characteristics of stateless 4V6 solutions, alongside a assessment of the issues attributes. The impact of translated or mapped tunnel transport modes is also presented in the broader context of other industry standard reference architectures and existing deployments. "Duplication Grouping Semantics in the Session Description Protocol", Ali Begen, Yiqun Cai, Heidi Ou, 10-Oct-11, Packet loss is undesirable for real-time multimedia sessions, but it is not avoidable due to congestion or other unplanned network outages. This is especially the case for IP multicast networks. One technique to recover from packet loss without incurring unbounded delay for all the receivers is to duplicate the packets and send them in separate redundant streams. This document defines the semantics for grouping redundant streams in the Session Description Protocol (SDP). The semantics defined in this document are to be used with the SDP Grouping Framework [RFC5888]. SSRC-level (Synchronization Source) grouping semantics are also defined in this document for RTP streams using SSRC multiplexing. "Delayed Duplication Attribute in the Session Description Protocol", Ali Begen, Yiqun Cai, Heidi Ou, 10-Oct-11, A straightforward approach to provide protection against packet losses due to network outages with a longest duration of T time units is to simply duplicate the original packets and send each copy separated in time by at least T time units. This approach is commonly referred to as Time-shifted Redundancy, Temporal Redundancy or simply Delayed Duplication. This document defines an attribute to indicate the presence of temporally redundant media streams and the duplication delay in the Session Description Protocol. "Configuration of Access Control Policy in REsource LOcation And Discovery (RELOAD) Base Protocol", Marc Petit-Huguenin, 31-Oct-11, This document describes an extension to the REsource LOcation And Discovery (RELOAD) base protocol to distribute the code of new Access Control Policies without having to upgrade the RELOAD implementations in an overlay. "IPFIX Information Elements for Flow Performance Measurement", Aamer Akhter, 8-Sep-11, There is a need to be able to quantify and report the performance of network applications and the network service in handling user data. This performance data provides information essential in validating service level agreements, fault isolation as well as early warnings of greater problems. This document describes IPFIX Information Elements related to performance measurement of network based applications. In addition, to the performance information several non-metric information elements are also included to provide greater context to the reports. The measurements use audio/video applications as a base but are not restricted to these class of applications. "Methodology for Network Flow Performance Measurement", Aamer Akhter, 8-Sep-11, There is a need to be able to quantify and report the performance of network applications and the network service in handling user data. This performance data provides information essential in validating service level agreements, fault isolation as well as early warnings of network greater problems. This document describes a generic methodology for calculating metrics related to network based applications. In addition, to the performance metrics, several additional information elements are included to help provide greater context to the reports. The measurements use audio/video applications as base examples but are not restricted to these class of applications. "Cloning Domain Name System (DNS) Labels for Fun and Profit", Douglas Barton, 15-Sep-11, This document describes a method for making one or more Domain Name System (DNS) labels behave in the DNS "as if" they were actually an entirely different label. E.g., the delegee for the example.org zone could define bar.example.org to be a CLONE of foo.example.org. This method is designed to meet the needs of those managing Internationalized Domain Name (IDN) zones that have been determined to be semantically similar, and therefore should be treated "as if" they were identical. This method can also be used more generally to handle situations where either CNAME or DNAME Resource Records are currently being used. A key design goal for the CLONE method is that all of the semantic benefits are available by updating only the authoritative servers for the zone. Domain managers who want to support DNSSEC for the CLONEd labels/zones may do so with dynamic signing of the CLONEs, or rely on users being behind a CLONE-Aware resolving name server. Foreword [RFC Editor, please remove this Section at publication time. Thanks.] This is my first draft, please be gentle. :) I'm definitely open to the possibility that there are better ways to accomplish the concepts presented herein. I'm sure that there are a non-zero number of errors in the formatting, references, etc. Also Sections 2 and 3 may be under-specified, unclear, or unworkable. So please don't be afraid to offer (constructive) criticism. TODO: Update/add/improve references? Add/improve examples? Revision History: "Port Control Protocol (PCP) Proxy Function", Mohammed Boucadair, Reinaldo Penno, Dan Wing, Francis Dupont, 12-Sep-11, This document specifies the behavior of a PCP Proxy element, for instance embedded in Customer Premise routers. "An EAP Authentication Method Based on Identity-Based Authenticated Key Exchange", Violeta Cakulev, Ioannis Broustis, 1-Sep-11, The Extensible Authentication Protocol (EAP) is an authentication framework which supports multiple authentication methods. This document defines an authentication method for EAP called EAP-IBAKE, which is based on the Identity-Based Authenticated Key Exchange (IBAKE) protocol. The IBAKE method provides mutual authentication through the use of identity-based encryption. In addition to mutual authentication this method also provides perfect forward and backwards secrecy. "Happy Eyeballs Extension for Multiple Interfaces", Gang Chen, Carl Williams, Dan Wing, Andrew Yourtchenko, 31-Oct-11, The memo has been proposed to extend happy eyeballs algorithm to fit into multiple interfaces environment. Based on this extended heuristic algorithm, a client with multiple interface could determine the optimal flow path in which specific interface has been chosen. Furthermore, an appropriate IP address family for each interface can be also identified to guarantee user experiences during IPv6 transition period. "A Forward-Search P2P TE LSP Inter-Domain Path Computation", Huaimo Chen, Oscar Dios, 30-Oct-11, This document presents a forward search procedure for computing paths for Point-to-Point (P2P) Traffic Engineering (TE) Label Switched Paths (LSPs) crossing a number of domains through using multiple Path Computation Elements (PCEs). In addition, extensions to the Path Computation Element Communication Protocol (PCEP) for supporting the forward search procedure are described. "Softwire Mesh Management Information Base(MIB)", Yong Cui, Jiang Dong, Peng Wu, Mingwei Xu, 29-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 defines objects for managing softwire mesh [RFC5565]. "Base Types for Time in AFS-3", Andrew Deason, 26-Aug-11, This document defines three types to be used in future AFS-3 Rx Remote Procedure Calls (RPCs) to represent time. Current AFS-3 RPCs represent time as 32-bit integers representing seconds. This is insufficient in both granularity and range, so new types to represent time are defined in this document to overcome these limitations. Internet Draft Comments Comments regarding this draft are solicited. Please include the AFS-3 protocol standardization mailing list (afs3-standardization@openafs.org) as a recipient of any comments. "The 'annotation-server' Link Relation Type", Martin Duerst, 7-Sep-11, This document defines the 'annotation-server' Link Relation Type to suggest a server to store and retreive Web annotations. "The 'mailto' URI/IRI Scheme", Martin Duerst, Larry Masinter, Jamie Zawinski, 6-Sep-11, This document defines the format of Uniform Resource Identifiers (URIs) and Internationalized Resource Identfiers (IRIs) to identify resources that are reached using Internet mail. It adds the possibility to use Email Address Internationalization (EAI) email addresses (RFC4952bis) to the previous syntax of 'mailto' URIs (RFC 6068). "The FNV Non-Cryptographic Hash Algorithm", Glenn Fowler, Landon Noll, Kiem-Phong Vo, Donald Eastlake, 24-Sep-11, FNV (Fowler/Noll/Vo) is a fast, non-cryptographic hash algorithm with good dispersion. The purpose of this document is to make information on FNV and open source code performing FNV conveniently available to the Internet community. "pNFS block disk protection", Sorin Faibish, Jason Glasgow, David Black, 27-Sep-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. "Updating TCP to support Variable-Rate Traffic", Gorry Fairhurst, Israfil Biswas, 23-Dec-11, This document addresses issues that arise when TCP is used to support variable-rate traffic that exhibts periods where the transmission rate is limited by the application rather than the congestion window. It updates TCP to allow a TCP sender to restart quickly following either an idle or applications-limited interval. The method is expected to benefit variable-rate TCP applications, while also providing an appropriate response if congestion is experienced. The document also evaluates TCP Congestion Window Validation (CWV), an IETF experimental specification defined in RFC 2861, and concludes that CWV sought to address important issues, but failed to deliver a widely used solution. This document recommends that the IETF should consider moving RFC 2861 from Experimental to Historic status, and that this is replaced by the current specification. "Security Considerations in the IP-based Internet of Things", Oscar Garcia-Morchon, Sye Keoh, Sandeep Kumar, Rene Hummen, Rene Struik, 31-Oct-11, A direct interpretation of the Internet of Things concept refers to the usage of standard Internet protocols to allow for human-to-thing or thing-to-thing communication. Although the security needs are well-recognized, it is still not fully clear how existing IP-based security protocols can be applied to this new setting. This Internet-Draft first provides an overview of security architecture, its deployment model and general security needs in the context of the lifecycle of a thing. Then, it presents challenges and requirements for the successful roll-out of new applications and usage of standard IP-based security protocols when applied to get a functional Internet of Things. "RTP with TCP Friendly Rate Control", Ladan Gharai, Colin Perkins, 6-Sep-11, This memo specifies how the TCP Friendly Rate Control (TFRC) of RTP flows can be supported using the RTP/AVPF profile and the general RTP header extension mechanism. AVPF feedback packets and RTP header extensions are defined to support the exchange of control information between RTP TFRC senders and receivers. TFRC is an equation-based congestion control scheme for unicast flows operating in a best effort Internet environment. "Web Security Framework: Problem Statement and Requirements", Jeff Hodges, 8-Sep-11, Web-based malware and attacks are proliferating rapidly on the Internet. New web security mechanisms are also rapidly growing in number, although in an incoherent fashion. This document provides a brief overview of the present situation and the various seemingly piece-wise approaches being taken to mitigate the threats. It then provides an overview of requirements as presently being expressed by the community in various online and face-to-face discussions. "RFC Editor Model (Version 2)", Joel Halpern, Olaf Kolkman, 9-Feb-12, The RFC Editor performs a number of functions that may be carried out by various people or entities. The RFC Editor model described in this document divides the responsibilities for the RFC Series into three functions: The RFC Series Editor, the RFC Production Center, and the RFC Publisher. The Internet Architecture Board (IAB) oversight by way of delegation to the RFC Series Oversight Committee (RSOC) is described, as is the relationship between the IETF Administrative Oversight Committee (IAOC) and the RSOC. This document reflects the experience gained with RFC Editor Model version 1, documented in [RFC5620] and obsoletes that document. "A Common API for Transparent Hybrid Multicast", Matthias Waehlisch, Stig Venaas, Thomas Schmidt, 27-Jan-12, Group communication services exist in a large variety of flavors, and technical implementations at different protocol layers. Multicast data distribution is most efficiently performed on the lowest available layer, but a heterogeneous deployment status of multicast technologies throughout the Internet requires an adaptive service binding at runtime. Today, it is difficult to write an application that runs everywhere and at the same time makes use of the most efficient multicast service available in the network. Facing robustness requirements, developers are frequently forced to use a stable, upper layer protocol provided by the application itself. This document describes a common multicast API that is suitable for transparent communication in underlay and overlay, and grants access to the different multicast flavors. It proposes an abstract naming by multicast URIs and discusses mapping mechanisms between different namespaces and distribution technologies. Additionally, it describes the application of this API for building gateways that interconnect current multicast domains throughout the Internet. "IPv4-IPv6 Multicast: Problem Statement and Use Cases", Christian Jacquenet, Mohamed Boucadair, Yiu Lee, Jacni Qin, Tina Tsou, 31-Oct-11, This document discusses issues and requirements raised by IPv4-IPv6 multicast interconnection and co-existence scenarios. It also discusses various multicast use cases which may occur during IPv6 transitioning. "Aggregate Route Option for Dynamic Host Control Protocol version 6 (DHCPv6)", Shrinivas Joshi, 7-Sep-11, The Aggregate Route option provides a mechanism for a requestor to retrieve an aggregate route(s) from a DHCPv6 server using the information-request message. The aggregate route is a single route representing multiple prefixes delegated by a DHCP server using Prefix Delegation, and maybe advertised using routing protocols instead of individual routes learnt from DHCPv6 Prefix Delegation. This document specifies the data contained in aggregate route option as well as the behavior of Requestor and DHCPv6 Server in requesting and processing of this option. "Extensible XDR Discriminated Union Primitive Type", Thomas Keiser, 3-Feb-12, AFS-3 relies upon XDR to carry Rx RPC call payloads. XDR discriminated unions are ill-suited to cases where the protocol needs to evolve without inventing new RPCs, i.e., unknown discriminant values cause the entire XDR payload to fail the decoding step. While this can be circumvented through the use of opaque payloads (and recursive XDR invocations), such solutions are inelegant and difficult to implement. This memo defines a new XDR primitive type, "ext-union", which is derived from the XDR discriminated union primitive type, but with two key variations: 1) each leg contains a length field, and 2) no default leg is supported. "MPLS Fast Re-route using extensions to LDP", Sriganesh Kini, Srikanth Narayanan, 31-Oct-11, LDP is widely deployed in MPLS networks to signal LSPs. Since LDP establishes LSPs along IGP routed paths, its failure recovery is gated by IGP's re-convergence. Mechanisms such as IPFRR and RSVP-TE based FRR have been used to provide faster re-route for LDP LSPs. However these techniques have significant complexity and/or may not have full coverage. In this document we describe a method to perform fast re-route of LDP LSPs. The goal is to have recovery characteristics similar to the methods in [RSVP-TE-FRR] without depending on additional protocols but at the same time provide full coverage. "A Usage for Shared Resources in RELOAD (ShaRe)", Alexander Knauf, Gabriel Hege, Thomas Schmidt, Matthias Waehlisch, 24-Oct-11, This document defines a RELOAD Usage for managing shared write access to RELOAD Resources. Shared Resources in RELOAD (ShaRe) form a basic primitive for enabling various coordination and notification schemes among distributed peers. Access in ShaRe is controlled by a hierarchical trust delegation scheme maintained within an access list. A new USER-CHAIN-ACL access policy allows authorized peers to write a Shared Resource without owning its corresponding certificate. This specification also adds mechanisms to store Resources with a variable name which is useful whenever peer-independent rendezvous processes are required. "Changing DNS Operators for DNSSEC signed Zones", Peter Koch, Marcos Sanz, 31-Oct-11, Changing the DNS delegation for a DNS zone is quite involved if done by the books, but most often handled pragmatically in today's operational practice at the top level with registries and registrars. This document describes a proposal for a delegation change procedure that will maintain consistency and validation under DNSSEC. "Controlling Traffic Offloading Using Neighbor Discovery Protocol", Teemu Savolainen, Jouni Korhonen, Yi Ding, 31-Oct-11, This specification defines an extension to IPv6 Neighbor Discovery Protocol, which allows management of IPv6 traffic offloading to IPv4 and moving IPv4 traffic away from a specific interface. "Mobile Communication Congestion Exposure Scenario", Dirk Kutscher, Faisal Mir, Rolf Winter, Suresh Krishnan, Ying Zhang, 31-Oct-11, This memo describes a mobile communications use case for congestion exposure (CONEX) with a particular focus on mobile communication networks such as 3GPP LTE. The draft describes the architecture of these networks (access and core networks), current QoS mechanisms and then discusses how congestion exposure concepts could be applied. Based on this, this memo suggests a set of requirements for CONEX mechanisms that particularly apply to mobile networks. "Universal Object Delivery using RaptorQ", Michael Luby, Thomas Stockhammer, 7-Sep-11, This document describes a Fully-Specified FEC scheme, identified by the FEC Encoding ID 7 (to be determined (tbd)), for Universal Object Delivery using the RaptorQ Forward Error Correction (FEC) Scheme for Object Delivery. This document introduces a new FEC Payload ID, called the Universal Object Symbol Identifier (UOSI), and describes how to use the UOSI together with RaptorQ FEC Scheme to provide simplified and enhanced object delivery capabilities. In particular, flexible and simple support is provided for basic object delivery, and support is also provided for unequal error protection (UEP) object delivery, for bundled object delivery, and for any combination of UEP and bundled object delivery. "AS112 Nameserver Delegations for IPv6", George Michaelson, Geoff Huston, Joe Abley, 7-Sep-11, To reduce longterm traffic to the DNS root servers and the IP6.ARPA authoritative servers, the IAB is requested to instruct the IANA to delegate a set of sub-domains of IP6.ARPA to the AS112 Project [RFC6304]. These domains represent IPv6 address prefixes that are not conventionally populated in the global reverse-DNS, including IPv6 prefixes that are not globally scoped and certain prefixes used in an anycast context. The reverse DNS query load associated with these IPv6 address prefixes appear to have unacceptable scaling consequences as IPv6 uptake increases. By delegating these sub-domains to the AS112 project, the DNS query load can be passed to a distributed sink, reducing the query load on the root servers and the IP6.ARPA authoritative servers. "Approaches to Distributed mobility management using Mobile IPv6 and its extensions", Basavaraj Patil, Carl Williams, Jouni Korhonen, 31-Oct-11, Mobility solutions at the IP layer have been specified in the IETF for IPv4 and IPv6. These solutions include host and network based mobility. All of the mobility protocols enable IP session continuity by providing the mobile host with an IP address or prefix that remains constant even as the host moves and attaches to different access networks and points of attachment. Mobile hosts are anchored at a gateway via a tunnel and the address/prefix provided to the host via the gateway remains unchanged across mobility events. All IP sessions initiated or terminated at a mobile host are anchored via the gateway. A gateway centric approach raises certain concerns in terms of cost and efficiency. A mobility model wherein the mobility functions are distributed is a way of alleviating the concerns of a gateway centric approach. This document considers ways to alleviate anchored mobility issues with approaches that could be considered in a deployment. "Negotiation of security protocol for Mobile IPv6 operation", Bruno Faria, Basavaraj Patil, Gabor Bajko, 31-Oct-11, Mobile IPv6 has relied on IPsec and IKEv2 for securing the signaling and user traffic. A single security mechanism for Mobile IPv6 does not adequately address various deployment scenarios. The one-size- fits-all security approach is ill suited for Mobile IPv6, as different deployments have different security requirements. Multiple alternatives to securing signaling and user traffic have been proposed and are being considered for standardization. When multiple security protocols coexist for providing security for mobile IPv6 nodes, there is a need to negotiate the choice of security protocol between a mobile node and home agent a priori. This document proposes a method for negotiating the security protocol to be used between mobile IPv6 nodes. "RBridges: Multilevel TRILL", Radia Perlman, Donald Eastlake, Anoop Ghanwani, ZTE Corporation, 31-Oct-11, This is an informational document describing issues and comparing advantages and disadvantages of various possible approaches to extending TRILL to use multiple levels of IS-IS. "Data Center Mobility based on BGP/MPLS, IP Routing and NHRP", Rahul Aggarwal, Ravi Shekhar, Wim Henderickx, Yakov Rekhter, 2-Feb-12, This document describes a set of network-based solutions for seamless Virtual Machine mobility in the data center. These solutions provide a toolkit which is based on IP routing, BGP/MPLS E-VPNs, BGP/MPLS IP VPNs, and NHRP. "Virtual Hub-and-Spoke in BGP/MPLS VPNs", Huajin Jeng, James Uttaro, Luay Jalil, Bruno Decraene, Yakov Rekhter, Rahul Aggarwal, 6-Sep-11, With BGP/MPLS VPNs any-to-any connectivity among sites of a given Virtual Private Network would require each Provider Edge router that has one or more of these sites connected to it to hold all the routes of that Virtual Private Network. The approach described in this document allows to reduce the number of Provider Edge routers that have to maintain all these routes by requiring only a subset of these routers to maintain all these routes. Specification of Requirements "PBB E-VPN", Ali Sajassi, Lizhong Jin, Nabil Bitar, Samer Salam, Sami Boutros, 31-Oct-11, This document discusses how Ethernet Provider Backbone Bridging [802.1ah] can be combined with E-VPN in order to reduce the number of BGP MAC advertisement routes by aggregating Customer/Client MAC (C-MAC) addresses via Provider Backbone MAC address (B-MAC), provide client MAC address mobility using C-MAC aggregation and B-MAC sub- netting, confine the scope of C-MAC learning to only active flows, offer per site policies and avoid C-MAC address flushing on topology changes. The combined solution is referred to as PBB-EVPN. Conventions "Additional negotiation in the TCP Timestamp Option field during the TCP handshake", Mirja Kuehlewind, Richard Scheffenegger, 31-Oct-11, A number of TCP enhancements in so diverse fields as congestion control, loss recovery or side-band signaling could be improved by allowing both ends of a TCP session to interpret the values carried in the Timestamp option. Further enhancements are enabled by changing the receiver side processing of timestamps in the presence of Selective Acknowledgements. This documents updates RFC1323 and specifies a backwards compatible way of negotiating for Timestamp capabilities, and lists a number of benefits and drawbacks of this approach. "A packet-based method for passive performance monitoring", Alberto Bonda, Alessandro Capello, Luca Castaldelli, Mauro Cociglio, 28-Oct-11, This document describes a method to accomplish performance monitoring measurements on real traffic, applicable to any packet-based stream, including L2, L3, MPLS traffic, unicast and multicast. The method can be easily implemented using tools and features already available on existing routing platforms without any protocol extension and, for this reason, it does not raise any interoperability issue. However, the method could be further improved by means of some extension to existing protocols, but this aspect is left for further study and it is out of the scope of the document. "Using PCP To Coordinate Between the CGN and Home Gateway Via Port Allocation", Cathy Zhou, Tina Tsou, Xiaohong Deng, Mohammed Boucadair, Qiong Sun, 8-Jan-12, Consider a situation where a subscriber's packets are subject to two levels of NAT, with both NATs operating under the control of the ISP. An example of this would be a NATing Home Gateway forwarding packets to a Large Scale NAT. This memo proposes that advantage be taken of the presence of the second NAT, to offload the burden on the Large Scale NAT by delegation to the Home Gateway. Enhancements to the Port Control Protocol are specified to achieve this. The proposed solution applies also for DS-Lite where the AFTR offloads it NAT to the B4 element. "Secure Object Delivery Protocol (SODP)", Sean Turner, 10-Jan-12, This document describes the Secure Object Delivery Protocol (SODP). SODP enables clients to obtain secured packages from a Secure Object Management System (SOMS). Packages supported by a SOMS server include but are not limited to: firmware packages [RFC4108], trust anchor (TA) packages [RFC5934], symmetric key packages [RFC6031], asymmetric key packages [RFC5958], encrypted key packages [RFC6031], public key certificate enrollment packages [RFC5272], public key certificates [RFC5280], and Certificate Revocation Lists (CRLs) [RFC5280]. Client access is ideally direct and web-based, but access via agents acting on behalf of clients is supported. "Interface description with WADL in CoRE", Matthieu Vial, Zach Shelby, 9-Sep-11, This document provides guidelines to use the Web Application Description Language (WADL) in Constrained RESTful environments. The document mainly focuses on how to combine WADL with the CoRE Link Format to describe a REST interface. "Making Route Flap Damping Usable", Cristel Pelsser, Keyur Patel, Olaf Maennel, Pradosh Mohapatra, Randy Bush, 22-Dec-11, Route Flap Damping (RFD) was first proposed to reduce BGP churn in routers. Unfortunately, RFD was found to severely penalize sites for being well-connected because topological richness amplifies the number of update messages exchanged. Many operators have turned RFD off. Based on experimental measurement, this document recommends adjusting a few RFD algorithmic constants and limits, to reduce the high risks with RFD, with the result being damping a non-trivial amount of long term churn without penalizing well-behaved prefixes' normal convergence process. "One-time Address-Prefix Based Outbound Route Filter for BGP-4", Jakob Heitz, Jie Dong, Keyur Patel, Qing Zeng, Rob Shakir, ZhiLan Huang, 30-Oct-11, This document defines a new Outbound Router Filter (ORF) type for BGP, termed "One-time Address Prefix Outbound Route Filter", which would allow a BGP speaker to send to its BGP peer a route refresh request with a set of address-prefix-based filters to make the peer re-advertise only the specific routes matching the filters to the speaker. This ORF-type enables a BGP speaker to replay or recover some specific "problematic" routes without requiring its peer to re- advertise the whole Adj-RIB-Out of a specific address family, which makes the trouble shooting operation (such as packets tracking) more efficient and reduces the impact on network stability. This filter does not change the outbound route filters on BGP peers and should only be used for one-time filtering. "Applicability of Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI)", Adrian Farrel, Daniele Ceccarelli, Fatai Zhang, Greg Bernstein, Oscar Dios, 29-Oct-11, Generalized Multiprotocol Label Switching (GMPLS) defines a series of protocols for the creation of Label Switched Paths (LSPs) in various switching technologies. The GMPLS User-Network Interface (UNI) was developed in RFC4208 in order to be applied to an overlay network architectural model. This document examines a number of GMPLS UNI application scenarios. It shows how techniques developed after the GMPLS UNI can be applied to automate or enable critical processes for these applications. This document also suggested simple extensions to existing technologies to further enable the UNI and points out some existing unresolved issues. "Adaptive VLAN Assignment for Data Center RBridges", Dacheng Zhang, Mingui Zhang, 31-Oct-11, If RBridges are casually assigned as Appointed Forwarders for VLANs without considering the number of MAC addresses and traffic load of these VLANs, it may overload some of the RBridges while leave other RBridges lightly loaded, which reduces the scalability of a RBridge network and undermines its performance. A new protocol is designed in this document to support the adaptive VLAN assignment (or Appointed Forwarder selection) based on the forwarders' reporting of their usage of MAC tables and available bandwidth. "Depth-First Forwarding in Unreliable Networks", Ulrich Herberg, Alvaro Cardenas, Tadashige Iwao, Sandra Cespedes, 13-Nov-11, This document describes the Depth-First Forwarding (DFF) protocol for IPv6 networks based on the LoWPAN adaptation layer. The protocol is a mesh-under data forwarding mechanism that increases reliability of data delivery. DFF forwards data packets using a network-wide "depth-first search" for the Final Destination of the packet. DFF may be used in conjunction with a mesh-under routing protocol, which provides "hints" for DFF in which order to try to send the packet to the neighbors discovered by the neighborhood discovery mechanism. In that case, DFF can be used as local repair mechanism. "A Forward-Search P2MP TE LSP Inter-Domain Path Computation", Huaimo Chen, Oscar Dios, 30-Oct-11, This document presents a forward search procedure for computing a path for a Point-to-MultiPoint (P2MP) Traffic Engineering (TE) Label Switched Path (LSP) acrossing a number of domains through using multiple Path Computation Elements (PCEs). In addition, extensions to the Path Computation Element Communication Protocol (PCEP) for supporting the forward search procedure are described. "TCP Fast Open", Yuchung Cheng, Sivasankar Radhakrishnan, Arvind Jain, Jerry Chu, 8-Dec-11, TCP Fast Open (TFO) allows data to be carried in the SYN and SYN-ACK packets and consumed by the receiving end during the initial connection handshake, thus providing a saving of up to one full round trip time (RTT) compared to standard TCP requiring a three-way handshake (3WHS) to complete before data can be exchanged. Terminology "On demand IPv4 address provisioning in Dual-Stack PPP deployment scenarios", Karsten Fleischhauer, Olaf Bonness, 7-Sep-11, Today the Dual-Stack approach is the most straightforward and the most common way for introducing IPv6 into existing systems and networks. However a typical drawback of implementing Dual-Stack is that each node will still require at least one IPv4 address. Hence, solely deploying Dual-Stack does not provide a sufficient solution to the IPv4 address exhaustion problem. Assuming a situation where most of the IP communication (e.g. always-on, VoIP etc.) can be provided via IPv6, the usage of public IPv4 addresses can significantly be reduced and the unused public IPv4 addresses can under certain circumstances be returned to the public IPv4 address pool of the service provider. New Dual-Stack enabled services can be introduced without increasing the public IPv4 address demand, when IPv6 will be the preferred network layer protocol. This document describes such a solution in a Dual-Stack PPP session network scenario and explains the protocol mechanisms which are used. "Comcast IPv6 Trial/Deployment Experiences", John Brzozowski, Chris Griffiths, 2-Oct-11, This document outlines the various technologies Comcast has trialed as part of the company's ongoing IPv6 initiatives. The focus here are the technologies and experiences specific to enabling IPv6 for subscriber services like high speed data or Internet. Comcast has learned a great deal about various technologies that we feel are important to share with the community. "Policy Signaling for Multi-access Mobility", Kuntal Chowdhury, Rajeev Koodli, 30-Aug-11, The mobile nodes are increasingly capable of simultaneous multi-radio connectivity. This allows them to be attached to the Internet through multiple access technologies at the same time. With such multi-access, the mobile node (MN) can make use of the best-available access technology for a particular application at any given time. And, the network may be able to balance the flow of traffic across the available access technologies. The Mobile IPv6 flow binding work provides a mechanism for the MN to signal the Home Agent to balance the flows based on the MN'e needs. This document specifies a simple protocol for a mobile IP gateway (such as a Mobile IP Home Agent or a Proxy Mobile IP Local Mobility Anchor) to signal the MN of gateway's policy for traffic treatment across access technologies. Based on the response and the prevailing network conditions, the gateway then balances the traffic. "Requesting Suboptions in DHCPv6", Tomasz Mrugalski, 23-Oct-11, DHCPv6 clients may use Option Request Option (ORO) defined in RFC3315 [RFC3315] to specify, which options they would like to have configured by DHCPv6 servers. Clients may also be interested in specific options that do not appear in DHCPv6 message directly (top- level options), but rather as nested options or sub-options (i.e. options conveyed within other options). This document clarifies how to use already defined ORO to request specific options within scopes other than top-level. This document updates RFC3315. "Supporting Shared Mesh Protection in MPLS-TP Networks", Ping Pan, Rajan Rao, Biao Lu, Luyuan Fang, Andrew Malis, Fatai Zhang, Sam Aldrin, Fei Zhang, Mohana Singamsetty, 31-Oct-11, Shared mesh protection is a common protection and recovery mechanism in transport networks, where multiple paths can share the same set of network resources for protection purposes. In the context of MPLS-TP, it has been explicitly requested as a part of the overall solution (Req. 67, 68 and 69 in RFC5654 [1]). It's important to note that each MPLS-TP LSP may be associated with transport network resources. In event of network failure, it may require explicit activation on the protecting paths before switching user traffic over. In this memo, we define a lightweight signaling mechanism for protecting path activation in shared mesh protection-enabled MPLS-TP networks. "Route Flap Damping Deployment Status Survey", Cristel Pelsser, Randy Bush, Seiichi Kawamura, Shishio Tsuchiya, 26-Dec-11, BGP Route Flap Damping [RFC2439] is a mechanism that targets route stability. It penalyzes routes that flap with the aim of reducing CPU load on the routers. But it has side-effects. Thus, in 2006, RIPE recommended not to use Route Flap Damping (see [RIPE-378]). Now, some researchers propose to turn RFD, with less aggressive parameters, back on [draft-ymbk-rfd-usable]. This document describes results of a survey conducted amoung service provider on their use of BGP Route Flap Damping. "Trends in Web Applications and the Implications on Standardization", Bernard Ph.D., Danny McPherson, Hannes Tschofenig, Jon Peterson, 31-Oct-11, Advancements in the design of web browsers have introduced fundamental changes to the architecture of application protocols. The widespread availability and growing sophistication of JavaScript interpreters in browsers enables web servers to push to browsers all of the application logic required to implement a client-server protocol. Consequently, many client-server applications that once required an installed client on a host computer now can rely simply on a modern browser to act as a client for the purposes of a particular application. For example, where once email clients required a custom application to access an inbox, increasingly a web browser can serve this purpose as well as the purpose-built applications of the past. Similarly, HTTP with the assistance of JavaScript can subsume the functions performed by the protocols like POP3 and IMAP. The need for Internet standards beyond HTTP to implement an email inbox application consequently diminishes - why author standards and worry about interoperability of clients and servers when the server can simply push to the client all the code it needs to be interoperable? Many client-server applications on the Internet could potential migrate to this code distribution methodology. [Note: A separate mailing list has been created for discussions related to this document and it can be found here: https://www.ietf.org/mailman/listinfo/webapps ] "IEEE 1588/802.1AS Synchronisation for RTP Streams", Aidan Williams, 31-Oct-11, This memo specificies an RTP header extension for carrying in-band synchronization metadata provided by the IEEE1588/802.1AS Precision Time Protocols. "IP Fast Re-Route with Fast Notification", Andras Csaszar, Jeff Tantsura, Sriganesh Kini, John Sucec, Subir Das, 31-Oct-11, This document describes a mechanism that provides IP fast reroute (IPFRR) by using a failure notification (FN) to nodes beyond the ones that first detect the failure (i.e. nodes that are directly connected to the failure point). The paths used when IPFRR-FN is active are in most cases identical to those used after Interior Gateway Protocol (IGP) convergence. The proposed mechanism can address all single link, node, and SRLG failures in an area and has been designed to allow traffic recovery traffic to happen quickly (The goal being to keep traffic loss under 50msec). IPFRR-FN can be a supplemental tool to provide FRR when LFA cannot repair a failure case. "Network Portability Requirements and Models for Cloud Environment", Keiichi Shima, Yuji Sekiya, Katsuhiro Horiba, 17-Oct-11, Recent progress of virtual machine technology made it possible to host various Internet service nodes in a so called cloud environment. The virtual machine hosting technology provides a method to migrate a virtual machine from one hypervisor to another. However, such a technology is mainly focusing on a migration between hypervisors attached to the same link, and tend not to consider migration over the Internet. This document mentions the purpose of that type of operation and describe several possible operation methods to provide network portability in cloud systems. "JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0", Brian Campbell, Chuck Mortimore, Michael Jones, 14-Dec-11, This specification defines the use of a JSON Web Token (JWT) Bearer Token as means for requesting an OAuth 2.0 access token as well as for use as a means of client authentication. "CoAP Option Extension : Size", Kepeng Li, Linyi Tian, Barry Leiba, 20-Oct-11, This document defines an extension to the Constrained Application Protocol (CoAP) to add a new option Size, which is used to indicate the resource size in a PUT/POST request or in a GET response. Note Discussion and suggestions for improvement are requested, and should be sent to core@ietf.org. "Mobile Multicast Sender Support in PMIPv6 Domains with Base Multicast Deployment", Matthias Waehlisch, Muhamma Farooq, Thomas Schmidt, 31-Oct-11, Multicast communication can be enabled in Proxy Mobile IPv6 domains by deploying MLD Proxy functions at Mobile Access Gateways, and multicast routing functions at Local Mobility Anchors. This document describes the support of mobile multicast senders in Proxy Mobile IPv6 domains that is provided by this base deployment scenario. Mobile sources remain agnostic of multicast mobility operations. "IPv4 and IPv6 Options to support Information Centric Networking", Andrea Detti, Stefano Salsano, Nicola Blefari-Melazzi, 25-Nov-11, The Information Centric Networking (ICN) paradigm, shifts the focus of networking from providing connections between hosts to efficiently providing content to the users. The work on ICN has traditionally been performed looking at "clean-slate" solutions which aims to replace IP with a new paradigm. On the other hand, in this memo we propose an "integration" approach to Information Centric Networking, i.e. we extend the IP protocol using a new IP Option (both for IPv4 and IPv6). The new IP option is used by routers to support networking based on content rather than (or better in addition to) end-point addresses. "A Description of KCipher-2 Encryption Algorithm", Shinsaku Kiyomoto, Wook Shin, 19-Dec-11, This document describes the KCipher-2 encryption algorithm. KCipher-2 is a stream cipher with a 128-bit key and a 128-bit initialization vector. Since the algorithm for KCipher-2 was published in 2007, security and efficiency have been rigorously evaluated through academic and industrial studies. No security vulnerability has been found as of the time this document was written. KCipher-2 offers fast encryption and decryption by means of simple operations that enable efficient implementation. KCipher-2 has been used for industrial applications, especially for mobile health monitoring and diagnostic services in Japan. "NAT offload extension to Dual-Stack lite", Cathy Zhou, Mohamed Boucadair, Xiaohong Deng, 31-Oct-11, Dual-Stack Lite, combining IPv4-in-IPv6 tunnel and Carrier Grade NAT technologies, provides an approach that offers IPv4 service via IPv6 network by sharing IPv4 addresses among customers during IPv6 transition period. Dual-stack lite, however, requires CGN to maintain active NAT sessions, which means processing performance, memory size and log abilities for NAT sessions should scale with number of sessions of subscribers; Hence increasing in CAPEX for operators would be resulted in when traffic increase. This document propose the NAT offload extensions to DS-Lite, which allows offloading NAT translation function from centralized network side (AFTR) to distributed customer equipments (B4), thereby offering a trade-off between CAPEX (e.g. less performance requirements on AFTR device) and OPEX (e.g., easy and fast deployment of Dual-Stack Lite) for operators. The ability of easily co-deploying with basic Dual- Stack Lite is essential to NAT offload extension to DS-Lite. "Labeled NFS", James Morris, Jarrett Lu, Thomas Haynes, Stephen Smalley, 26-Oct-11, This Internet-Draft describes additions to NFSv4 to support Mandatory Access Control systems. The current draft describes the mechanism for transporting a MAC security label using the NFSv4 protocol and the semantics required for that label. In addition to this it describes an example system of using this label in a fully MAC aware environment. "PCP Rapid Recovery", Stuart Cheshire, 27-Oct-11, Port Control Protocol (PCP) Rapid Recovery allows PCP clients to repair failed mappings within seconds, rather than the minutes or hours it might take if they relied solely on waiting for the next routine renewal of the mapping. Mapping failures may occur when a NAT gateway is rebooted and loses its mapping state, or when a NAT gateway has its external IP address changed so that its current mapping state becomes invalid. "Verification Involving PSTN Reachability: Requirements and Architecture Overview", Mary Barnes, Cullen Jennings, Jonathan Rosenberg, Marc Petit-Huguenin, 28-Sep-11, The Session Initiation Protocol (SIP) has seen widespread deployment within individual domains, typically supporting voice and video communications. Though it was designed from the outset to support inter-domain federation over the public Internet, such federation has not materialized. The primary reasons for this are the complexities of inter-domain phone number routing and concerns over security. This document reviews this problem space, outlines requirements, and then describes a new model and technique for inter-domain federation with SIP involving the Public Switched Telephone Network (PSTN), called Verification Involving PSTN Reachability (VIPR). VIPR addresses the problems that have prevented inter-domain federation over the Internet. It provides fully distributed inter-domain routing for phone numbers, authorized mappings from phone numbers to domains, a new technique for automated SIP anti-spam, and privacy of number ownership, all while preserving the trapezoidal model of SIP. "Use of KCipher-2 in Transport Layer Security", Shinsaku Kiyomoto, Wook Shin, 30-Sep-11, This document offers a set of new cipher suit specifications to support KCipher-2 encryption in the Transport Layer Security protocol. KCipher-2 is a stream cipher with a 128-bit key and a 128-bit initialization vector, which provides fast, efficient encryption and decryption. "The Public Switched Telephone Network (PSTN) Validation Protocol (PVP)", Marc Petit-Huguenin, Jonathan Rosenberg, Cullen Jennings, 13-Feb-12, One of the main challenges in inter-domain federation of Session Initiation Protocol (SIP) calls is that many domains continue to utilize phone numbers, and not email-style SIP URI. Consequently, a mechanism is needed that enables secure mappings from phone numbers to domains. The main technical challenge in doing this securely is to verify that the domain in question truly is the "owner" of the phone number. This specification defines the PSTN Validation Protocol (PVP), which can be used by a domain to verify this ownership by means of a forward routability check in the PSTN. "A Usage of Resource Location and Discovery (RELOAD) for Public Switched Telephone Network (PSTN) Verification", Marc Petit-Huguenin, Jonathan Rosenberg, Cullen Jennings, 31-Oct-11, Verification Involving PSTN Reachability (VIPR) is a technique for inter-domain SIP federation. VIPR makes use of the RELOAD protocol to store unverified mappings from phone numbers to RELOAD nodes, with whom a validation process can be run. This document defines the usage of RELOAD for this purpose. "Session Initiation Protocol (SIP) Extensions for Blocking VoIP Spam Using PSTN Validation", Marc Petit-Huguenin, Jonathan Rosenberg, Cullen Jennings, 11-Jan-12, Verification Involving PSTN Reachability (ViPR) is a new technique for inter-domain federation of SIP calls. ViPR makes use of the PSTN as an introduction mechanism to verify the correctness of mappings from phone numbers to domains. The PSTN introduction mechanism can also be used as a technique for blocking spam - a SIP caller is only authorized when its calling domain has previously called that same number over the PSTN. This document describes an extension to SIP which enables authorization of SIP calls based on a prior PSTN introduction. "Forwarded HTTP Extension", Andreas Petersson, Martin Nilsson, 17-Nov-11, 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. "A SAVI solution for WLAN", Jun Bi, Jianping Wu, You Wang, Tao Lin, 4-Oct-11, This document describes a source address validation solution for WLAN enabling 802.11i or other security mechanisms. This mechanism snoops NDP and DHCP to bind IP address with MAC address, and relies on the security of MAC address guaranteed by 802.11i or other mechanisms to filter IP spoofing packets. It can work in the special situations described in the charter of SAVI workgroup, such as multiple MAC addresses on one interface. This document describes three different deployment scenarios, with solutions for migration of mapping entries when hosts move from one access point to another. "Suite B Profile for Datagram Transport Layer Security / Secure Real-time Transport Protocol (DTLS-SRTP)", Kevin Igoe, Michael Peck, 15-Feb-12, The United States government has published guidelines for "NSA Suite B Cryptography", which defines cryptographic algorithm policy for national security applications. This document describes the use of Suite B cryptography with the Datagram Transport Layer Security (DTLS) protocol, the Secure Real-Time Transport Protocol (SRTP), and the Secure Real-Time Transport Control Protocol (SRTCP) to provide a robust architecture for securing real-time data. "True mobility of MobileIPv6", Mohd. Altamash, 8-Oct-11, This document enhances the mobility of Mobile node's home agent (HAMN) and correspondence node's home agent (HACN) along with the mobility of Mobile Node (MN) and Correspondence Node (CN). Hence this document shows true and complete mobility of MobileIPv6 protocol. "SIP Message Information Export using IPFIX", Benoit Claise, Brian Trammell, Hadriel Kaplan, Saverio Niccolini, 27-Oct-11, This draft defines a set of Information Elements and example Templates for IP Flow Information Export (IPFIX) based on the SIP Common Log Format data model, as well as additional useful SIP Information Elements, to allow IPFIX export of application-layer information about SIP messages. "Analysis of Bidirectional Forwarding Detection (BFD) Security According to KARP Design Guide", Manav Bhatia, Dacheng Zhang, 25-Jan-12, This document analyzes the Bidirectional Forwarding Detection protocol (BFD) according to the guidelines set forth in section 4.2 of draft-ietf-karp-design-guide. "Launch Phase Mapping for the Extensible Provisioning Protocol (EPP)", Gavin Brown, Wil Tan, 13-Oct-11, This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of domain names during the launch phase of a domain name registry. "Extensions to Path Computation Element Communication Protocol (PCEP) for Hierarchical Path Computation Elements (PCE)", Daniel King, Fatai Zhang, Oscar Dios, Quintin Zhao, Ramon Casellas, 13-Oct-11, The hierarchical Path Computation Element (PCE) architecture, defined in the companion framework document [I-D.ietf-pce-hierarchy-fwk], allows the selection of an optimum domain sequence and the optimum end-to-end path, to be derived through the use of a hierarchical relationship between domains. This document defines the Path Computation Element Protocol (PCEP) extensions for the purpose of implementing hierarchical PCE procedures which are described the aforementioned document. "Indicating Character Encoding and Language for HTTP Header Field Parameters", Julian Reschke, 18-Dec-11, By default, message header field parameters in Hypertext Transfer Protocol (HTTP) messages cannot carry characters outside the ISO- 8859-1 character set. RFC 2231 defines an encoding mechanism for use in Multipurpose Internet Mail Extensions (MIME) headers. This document specifies an encoding suitable for use in HTTP header fields that is compatible with a profile of the encoding defined in RFC 2231. "RTP Payload Format for Standard apt-X and Enhanced apt-X Codecs", James Hunter, Derrick Rea, 7-Oct-11, This document specifies a scheme for packetizing Standard apt-X, or Enhanced apt-X, encoded audio data into Real-time Transport Protocol (RTP) packets. The document describes a payload format that permits transmission of multiple related audio channels in a single RTP payload, and a means of establishing Standard apt-X and Enhanced apt-X connections through the Session Description Protocol (SDP). "claimSigning Extended Key Usage (EKU)", Chris Louden, Dave Silver, Matt King, Matt Tebo, Patrick Patterson, Wendy Brown, 27-Dec-11, This document specifies an Extended Key Usage (EKU) value which indicates that the certificate holder is authorized to sign security tokens to assert claims, or attributes, about a subject. When a certificate that asserts the claimSigning EKU signs a claim, the owner of the service holding that certificate is asserting that a statement about the subject is true. For example, a IdP secure token service (STS) would use an X.509 certificate containing the claimSigning EKU to sign SAML assertions containing an identifier and attributes about a user. This EKU value would allow for a separation between the designation that a given Identity belongs within a given Federation, and the empowerment of that entity within the federation to sign claims.. This approach allows for greater flexibility for the operators of Federated systems and for Certification Authorities and avoids the overloading of other, already established methods (such as Assurance Level designation via certificatePolicy OID). "Standardised ECC Cipher Suites for TLS", Peter Gutmann, 22-Nov-11, This document describes a set of standard ECC cipher suites for TLS that simplify the complex selection procedure described in the existing ECC RFC, simplifying implementation and easing interoperability problems. "Stitching Dynamically and Statically Provisioned Segments To Construct End-To-End Multi-Segment Pseudowires", Hyunwoo Cho, Jeong-dong Ryoo, Daniel King, 28-Oct-11, The MPLS Transport Profile (MPLS-TP) transport paths can be statically provisioned via a Network Management System (NMS) or dynamically provisioned via a control plane. The transport paths provided by MPLS-TP are used as a server layer for pseudowires carrying client signals other than IP or MPLS. It may be necessary to support MPLS-TP pseudowires, to extend across multiple domains. This document outlines the requirements and solution for coordinating MPLS-TP transport paths and a multi-segment PWs that will traverse multiple domains, where some domains are statically provisioned, and other domains that are dynamically provisioned. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. "Transmission of IPv6 Packets over DECT Ultra Low Energy", Peter Mariager, Jens Petersen, 31-Oct-11, DECT Ultra Low Energy is a low power air interface technology that is defined by the DECT Forum and specified by ETSI. The DECT air interface technology has been used world-wide in communication devices for more than 15 years, primarily carrying voice for cordless telephony but has also been deployed for data centric services. The DECT Ultra Low Energy is a recent addition to the DECT interface primarily intended for low-bandwidth, low-power applications such as sensor devices, smart meters, home automation etc. As the DECT Ultra Low Energy interface inherits many of the capabilities from DECT, it benefits from long range, interference free operation, world wide reserved frequency band, low silicon prices and maturity. There is an added value in the ability to communicate with IPv6 over DECT ULE. This document describes how IPv6 is transported over DECT ULE using 6LoWPAN techniques. "Use Cases for ALTO within CDNs", Stefano Previdi, Grant Watson, Jan Medved, Nabil Bitar, Ben Niven-Jenkins, 7-Dec-11, For some time, Content Distribution Networks (CDNs) have been used in the delivery of some Internet services (e.g. delivery of websites, software updates and video delivery) as they provide numerous benefits including reduced delivery cost for cacheable content, improved quality of experience for end users and increased robustness of delivery. In order to derive the optimal benefit from a CDN it is preferable to deliver content from the servers (caches) that are "closest" to the End User requesting the content, where "closest" may be as simple as "geographical or network distance" combined with CDN server load within a location, but may also consider other more complex combinations of metrics and CDN or Network Service Provider (NSP) policies. There are a number of different ways in which a CDN may obtain the necessary network topology and/or cost information to allow it to serve End Users from the most optimal servers/locations, such as static configuration, passively listening to routing protocols directly, active probing of underlying network(s), or obtaining topology and cost by querying an information service such as the ALTO map & cost services. This document describes the use cases for a CDN to be able to obtain network topology and cost information from an ALTO server(s). "WebSocket Per-frame DEFLATE Extension", Takeshi Yoshino, 1-Feb-12, This specification defines a per-frame DEFLATE compression extension for the WebSocket Protocol. This extension compresses the "Application data" part of WebSocket data frames using DEFLATE. Please send feedback to the hybi@ietf.org mailing list. "An IKEv2 Extension for Supporting ERP", Yoav Nir, 19-Nov-11, This document describes an extension to the IKEv2 protocol that allows an IKE Security Association (SA) to be created and authenticated using the EAP Re-authentication Protocol extension as described in RFC 5296 and its bis document. "OAuth Dynamic Client Registration Protocol", Thomas Hardjono, Maciej Machulak, Eve Maler, 24-Oct-11, This specification proposes an OAuth Dynamic Client Registration protocol. "Multicast Support for 6rd", Behcet Sarikaya, 11-Oct-11, This memo specifies modifications required to 6rd so that both IPv6 hosts can receive multicast data from IPv6 servers. In AMT based solution, AMT Gateway at the 6rd Customer Edge router uses AMT protocol to establish a tunnel interface with AMT Relay at the 6rd Border Relay and this tunnel is used to exchange MLD messages to establish multicast state at AMT Relay so that AMT Relay can tunnel IPv6 multicast data to IPv6 hosts connected to AMT Gateway. In 6rd Proxy Multicast solution, the protocol is based on proxying MLD at the 6rd Customer Edge router and then tunneling MLD messages to 6rd Border Relays where IPv6 multicast routing is supported. Multicast data received at 6rd Border Relay is tunneled to 6rd Customer Edge node and then delivered to the hosts. We show that IPv4 multicast and IGMP can be supported in a similar way. "GSS-API pre-authentication for Kerberos", Alejandro Perez-Mendez, Fernando Pereniguez-Garcia, Gabriel Lopez-Millan, Rafael Lopez, 4-Jan-12, This document describes a pre-authentication mechanism for Kerberos based on the Generic Security Service Application Program Interface (GSS-API), which allows a Key Distribution Center (KDC) to authenticate clients by using any GSS mechanism. "DS-Lite Management Information Base (MIB)", Yu Fu, Sheng Jiang, Yong Cui, Jiang Dong, 22-Feb-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 defines managed objects for DS-Lite. "Operational Guidance for IPv6 Deployment in IPv4 Sites using ISATAP", Fred Templin, 13-Oct-11, Many end user sites in the Internet today still have predominantly IPv4 internal infrastructures. These sites range in size from small home/office networks to large corporate enterprise networks, but share the commonality that IPv4 continues to provide satisfactory internal routing and addressing services for most applications. As more and more IPv6-only services are deployed in the Internet, however, end user devices within such sites will increasingly require at least basic IPv6 functionality for external access. This document therefore provides operational guidance for deployment of IPv6 within predominantly IPv4 sites using the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP). "Rapid Transition of IPv4 contents to be IPv6-accessible", Qiong Sun, Dong Liu, Qin Zhao, Qian Liu, Chongfeng Xie, Xing Li, Jacni Qin, 29-Oct-11, This document describes several deployment models for the transition of IPv4 services to IPv6, aiming at rapidly increasing the amount of IPv6 accessible contents for users from IPv6 Internet while preserving the continuity of IPv4 service delivery. "Radius Extensions for CGN Configurations", Dean Cheng, Jouni Korhonen, 5-Jan-12, This document defines new RADIUS attributes that can be used by a Carried Grade NAT device to communicate with a RADIUS server using RADIUS protocol to configure or report TCP/UDP ports and ICMP identifiers mapping behavior for specific Internet subscribers. "Extension to VPLS for E-Tree", Yuqun Cao, 29-Jan-12, This document proposes an approach to support Metro Ethernet Forum (MEF) Ethernet Tree (E-Tree) in Virtual Private LAN Service [RFC4761] [RFC4762]. The proposed solution is characterized by breaking pseudowire setup between Leaf endpoints in E-Tree instance to fulfill the specific E-Tree requirement: Leaf cannot communicate with Leaf. Backward compatibility is also considered in this document. "ICCP extension for the MSP application", Hongjie Hao, Wanming Cao, Yu jinghai, 14-Nov-11, This document presents some extensions on the Inter-Chassis Communication Protocol(ICCP) to support the application of multiplex section protection(MSP) that is described in the G.841. Linear multiplex section protection(MSP) is used to protect the Synchronous Digital Hierarchy (SDH) network. In the case of inter-chassis linear MSP, it needs a mechanism to synchronize the state and configuration data between the two chassis. The ICCP is appropriate for that. "A Taxonomy on Private Use Fields in Protocols", Chris Lonvick, 12-Feb-12, This document attempts to provide some clarification for the way that private use fields have been used in protocols developed in the IETF. It is strictly a taxonomy of what has been published and offers a minimal amount of advice about how to design or use private use options. "Multi-Protocol Label Switching Transport Profile (MPLS-TP) Operator Identifier Object", Lianshu Zheng, 31-Oct-11, Two formats of operator identifier are specified in Multi-Protocol Label Switching Transport Profile (MPLS-TP) networks, to uniquely identify an operator. One is Global_ID, the other is ICC_Operator_ID. In MPLS-TP networks, operator identifier as part of the global identifier of an MPLS-TP LSP may be required to be carried in the Path/Resv message when setting up the LSP. This document defines a new RSVP-TE Object: Operator Identifier object (OIO). It has two types, the Global_ID object and the ICC_Operator_ID object. Similar as Session and Sender Template object, OIO could be carried in the Path or Resv message to communicate the Operator ID that the two ends of an LSP in use. At the same time, it makes sure all the nodes that the LSP traverses to use the same format of Operator ID. "ICC_Operator_ID Attachment Individual Identifier (AII)", Mach Chen, Lianshu Zheng, 31-Oct-11, This document defines a new Attachment Individual Identifier (AII) type which could be used when ICC_Operator_ID is used to uniquely identify an operator. The new AII (ICC_Operator_ID AII) consists a ICC_Operator_ID, a prefix and a AC ID field. "POP3 over TLS", Alexey Melnikov, Chris Newman, Mykyta Yevstifeyev, 30-Aug-11, This document specifies how the Post Office Protocol, Version 3 (POP3) may be secured with Transport Layer Security (TLS) protocol, by establishing TLS connection directly before POP3 transaction. It updates RFC 2595. "MPLS-TP Linear Protection Applicability to MS-PW", Daniel Cohn, Rafi Ram, Ma Yuxia, Masahiro Daikoku, 4-Jan-12, One of the requirements of the MPLS transport profile [RFC5654] is to provide linear protection for transport paths, which include both LSPs and PWs. The functional architecture described in [SurvivFwk] is applicable to both LSP and PWs, however [LinearProt] does not explicitly describe mechanisms for PW protection in MPLS-TP. This document extends the applicability of the linear protection mechanism described in [LinearProt] to MPLS-TP segmented PWs as defined in [RFC6073]. "RTCP XR Blocks for layered Stream statistics metric reporting", Glen Zorn, Jinwei Xia, Wenson Wu, Roland Schott, 14-Sep-11, This document defines an RTCP XR Report Block and associated SDP parameters that allow the reporting of layered stream statistics metrics for use in a range of RTP applications. "RTCP XR for Summary Statistics Metrics Reporting", Glen Zorn, Wenson Wu, Rachel Huang, Roland Schott, 18-Jan-12, This document defines three RTCP XR Report Blocks and associated SDP parameters that allows the reporting of loss, duplication and discard summary statistics metrics for use in a range of RTP applications. "RTCP XR Blocks for Synchronization Delay and Offset Metrics Reporting", Hitoshi Asaeda, Rachel Huang, 21-Feb-12, This document defines two RTCP XR Report Blocks and associated SDP parameters that allow the reporting of synchronization delay and offset metrics for use in a range of RTP applications. "Distributed Mobility Management Protocol with Multicast Support", Behcet Sarikaya, 26-Oct-11, As networks are moving towards flat architectures, a distributed approach is needed to Mobile IPv6. This document defines a distributed mobility management protocol with multicast support. Protocol is based on Mobile IPv6 and its extensions for multiple care of address registration, flow mobility and dual stack mobile IPv6 with minimum extensions. Control and data plane separation is achieved by separating Home Agent functionalities into the control and data planes. "Multiple Topology Routing Extensions for Transparent Interconnection of Lots of Links (TRILL)", Vishwas Manral, Donald Eastlake, Mingui Zhang, Ayan Banerjee, 30-Dec-11, This document describes optional extensions to the TRILL protocol's use of IS-IS (Intermediate System to Intermediate Systems). These extensions support multiple topologies (MT) within the same TRILL campus and protocol instance of IS-IS. "Some Extensions to Port Control Protocol (PCP)", Mohamed Boucadair, Reinaldo Penno, Dan Wing, 21-Oct-11, This document extends Port Control Protocol (PCP) with new functionalities. "CLUE Definitions", Stephan Wenger, 31-Oct-11, This document collects terminology and definitions to be used consistently among documents produced in the CLUE working group. "Definitions of Managed Objects for 6rd", Lei Cai, Jacni Qin, Shishio Tsuchiya, 3-Feb-12, This document defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it defines objects for managing 6rd devices. "Requirements for an End-to-End Session Identification in IP-Based Multimedia Communication Networks", Gonzalo Salgueiro, Hadriel Kaplan, James Polk, Laura Liess, Parthasarathi R, Paul Jones, Roland Jesske, Salvatore Loreto, 30-Jan-12, This document specifies the requirements for an end-to-end session identifier in IP-based multimedia communication networks. This identifier would enable endpoints, intermediate devices, and management and monitoring systems to identify a session end-to-end, associate multiple endpoints with a given multipoint conference, track communication sessions when they are redirected, and associate one or more media flows with a given communication session. "The 'ftp' URI Scheme", Mykyta Yevstifeyev, 24-Sep-11, This document specifies the 'ftp' Uniform Resource Identifier (URI) scheme, which is used to refer to resources accessible via File Transfer Protocol (FTP). It updates RFC 959, RFC 1738 and RFC 4002. "Fundamental Architecture of Services Provider's network Transitioning to IPv6 (FAST6) -- PPPoE Broadband Access", Cancan Huang, GuoLiang Yang, Zhijing Peng, 10-Jan-12, Although there have already been some transition solutions and technologies, it is still lack of a complete solution for large scale broadband ISPs based on the network architecture considering service providers' requirements and constraints in the real world. This document proposes an IPv6 transitioning architecture, the FAST6, which is based on the common broadband network architecture and providing IPv6 transition solutions going through the whole transition period. "Inter-Carrier OAM Requirements", Oscar Dios, Michael Georgiades, David Berechya, Filippo Cugini, 24-Nov-11, This draft specifies requirements for inter-carrier OAM supporting end-to-end OAM functionality and mechanisms development in a multi- operator environment. It reviews the already proposed OAM requirements addressed in IETF [RFC5706, RFC5860], ITU-T [Y.1730], MEF [MEFOAM] and IEEE [IEEE1, IEEE2] which were mainly proposed on a per transport technology basis. This document specifies additional requirements for the inter-carrier OAM operations. "Linked Cache Invalidation", Mark Nottingham, Mike Kelly, 24-Nov-11, This memo defines Web link types that invalidate HTTP caches, along with an HTTP cache-control extension that allows caches that understand those link types to use responses containing them. Together, these mechanisms offer a way to avoid use of a response that has become stale due to another request that changes server-side state. Collectively, this is referred to as Linked Cache Invalidation (LCI). "Security Implications of the Use of IPv6 Extension Headers with IPv6 Neighbor Discovery", Fernando Gont, 12-Jan-12, This document analyzes the security implications of using IPv6 Extension Headers with Neighbor Discovery (ND) messages. It updates RFC 4861 such that use of the IPv6 Fragmentation Header is forbidden in all Neighbor Discovery messages, thus allowing for simple and effective counter-measures for Neighbor Discovery attacks. Finally, it discusses the security implications of using IPv6 fragmentation with SEcure Neighbor Discovery (SEND), and provides advice such that the aforementioned security implications are mitigated. "Update to the EAP Applicability Statement", Joseph Salowey, Stefan Winter, 27-Oct-11, This document updates the EAP applicability statement from RFC3748 to reflect recent usage of the EAP protocol in unprecedented contexts. "YANG Data Model for System Management", Andy Bierman, Martin Bjorklund, 30-Oct-11, This document defines a YANG data model for the configuration and identification of the management system of a device. "SP URN", Penn Pfautz, 17-Feb-12, This document requests a service provider identifier URN namespace. "The 'xri' URI Scheme", Drummond Reed, Mykyta Yevstifeyev, P. Davis, 23-Oct-11, The purpose of this document is to register the 'xri' Uniform Resource Identifier (URI) scheme, which is used in URIs mapped from Extensible Resource Identifiers (XRIs), in the corresponding IANA registry under 'provisional' category. "Network Configuration Protocol Light (NETCONF Light)", Juergen Schoenwaelder, Kent Watsen, Mehmet Ersue, Vladislav Perelman, 18-Jan-12, This document describes a profile of the NETCONF protocol called NETCONF Light. This profile modularizes the NETCONF protocol and allows devices to announce that they only support a subset of the NETCONF protocol operations. This is useful in situations where devices are either too resource constrained to support all NETCONF operations or where devices are gradually updated from proprietary configuration interfaces to support NETCONF. "Requirements For Internet Registry Services", Murray Kucherawy, 31-Jan-12, This document enumerates a base set of requirements that should be included in any system that provides registration information for Internet network entities, i.e., network assignments. Some of these, in turn, will define requirements for registrars; this, however, is an issue outside of the scope of this document. It is hoped that this work will influnce the development of requirements and specifications for domain name registries at some point in the future. "Expand NAT TCP/UDP ports deferring IPv4 Exhaustion", Jianping Sun, 29-Nov-11, This document describes the TCP/UDP port extension (EPORT) model to enhance Network Address Translation (NAT)capability. EPORT based NAT helps service provider and enterprise to save mass public IPv4 addresses with enough application sessions offered at same time. "Real-time Transport Protocol (RTP) Recommendations for SIPREC", Charles Eckel, 31-Oct-11, This document provides recommendations and guidelines for RTP and RTCP in the context of SIPREC. This document exists as a standalone document to facilitate discussion of the RTP recommendations, and it is anticipated that portions of this document will be incorporated into [I-D.ietf-siprec-protocol] rather than this document itself being adopted as a working group document. "Application Bridging for Federated Access Beyond web (ABFAB) OID Registry", Rhys Smith, 21-Oct-11, The IETF ABFAB working group has been assigned an OID arc by IANA. The goal of this document is to catalogue usage within the arc and the procedures for IANA to use to control the arc after the ABFAB working group has handed the arc over. "IMAP4 Extension for Multi-Account Situations", Yan Lu, 20-Nov-11, Simultaneous authentication of multiple mail accounts belonging to a single user is an attractive feature but is not supported in the current Internet Message Access Protocol [RFC3501]. This document introduces an extension of the Internet Message Access Protocol, Version 4rev1 (IMAP4rev1). With this extension, when a client is authenticated with one of its user identifiers, all the other associated user identifiers (if present) are also regarded as authenticated ones. Furthermore, this document specifies the syntax of LISTA and SELECTA commands for the IMAP4rev1 protocol. With LISTA command, a client can obtain a list of all the identifiers authenticated for the user. With SELECTA command, a client can select one of the user's authenticated identifiers and then gain access to all the mailboxes belonging to that identifier, without having to log out and re-log in with that identifier. "An Authentication Method based on Certificate for DHCP", Marcus Wong, Serge Manning, Yixian Xu, 20-Sep-11, This document defines a technique that can provide both entity authentication and message authentication based on certificate. This protocol combines three existing options, authentication option as specified in delay authentication mechanism in [RFC3118] and the user authentication protocol option defined in [RFC2485]. The goal of this specification is to define methods based certificate to protect the integrity of DHCP message and stop the gaps of the existing delay authentication mechanism. In order to meet these goals, we use the asymmetrical cryptography protection and some options about authentication that have been defined in other specifications. "PCP Support for Multi-Zone Environments", Reinaldo Penno, 21-Oct-11, A zone is a notion which denotes a routing instance, a set interfaces or prefixes characterized by having a different address realm and/or security policy. A NAT device can route packets with the same source IP address to different zones depending on configuration policies such as destination IP address. This functionality has been present for many years in NAT devices from multiple vendors. PCP allows a host to interact with a PCP-controlled NAT device and request an external IP and port. Therefore a PCP Server that controls the NAT device and receives a PCP request from a host needs to know from which NAT pool to allocate an external IP address and port. This document specifies an extension to PCP to support the zone concept. "Proposed Improvements for REsource LOcation And Discovery (RELOAD)", Marc Petit-Huguenin, 31-Oct-11, This document proposes some improvements for [RELOAD]. "Survey and Gap Analysis for State Migration in Data Center", Wang Danhua, 31-Oct-11, In this draft, we made gap analysis with some exisitng IETF work that could be related to State Migration. First of all, a short description of general state migration requirements is listed, and then we presents a brief survey of MIDCOM, PCP and Forces. The goal of this draft is to figure out whether there are existing protocols we can reuse. "An extension to RELOAD to support Direct Response Routing", Ning Zong, Roni Even, XingFeng Jiang, Yunfei Zhang, 19-Sep-11, This document proposes an optional extension to RELOAD to support direct response routing mode. RELOAD recommends symmetric recursive routing for routing messages. The new optional extension provides a shorter route for responses reducing the overhead on intermediary peers and describes the potential cases where this extension can be used. "An extension to RELOAD to support Relay Peer Routing", Ning Zong, Roni Even, XingFeng Jiang, Yunfei Zhang, 19-Sep-11, This document proposes an optional extension to RELOAD to support relay peer routing mode. RELOAD recommends symmetric recursive routing for routing messages. The new optional extension provides a shorter route for responses reducing the overhead on intermediary peers and describes the potential cases where this extension can be used. "Cloud Service Broker", Bhumip Khasnabish, Hu Jie, Shao Weixiang, 27-Dec-11, This document introduces a Cloud Service Broker (CSB) entity to provide brokering functions between different Cloud Service Providers and Cloud Service consumers. "Syslog Extension for Cloud Using Syslog Structured Data", Gene Golovinsky, Sam Johnston, Dominik Birk, 20-Dec-11, This document provides an open and extensible log format to be used by any cloud entity or cloud application to log and trace activities that occur in the cloud. It is equally applicable for cloud infrastructure (IaaS), platform (PaaS), and application (SaaS) services. CloudLog is defferent in content, but not in nature from the traditional logging as it takes in account transient nature of identities and resources in the cloud. "Home Agent Initiated Flow Binding for Mobile IPv6", Hidetoshi Yokota, Dae-Sun Kim, Behcet Sarikaya, Frank Xia, 22-Dec-11, There are scenarios in which the home agent needs to trigger flow binding operations towards the mobile node such as moving a flow from one access network to another based on the network resource availability. In order for the home agent to be able to initiate interactions for flow bindings with the mobile node, this document defines new signaling messages and sub-options for Mobile IPv6. Home agent initiated flow bindings are supported for both IPv4 and IPv6 enabled mobile nodes. "State Migration", Gu Yingjie, Yang Jingtao, Fan Yongbing, Zhuo Zhiqiang, Liu Ming, 31-Oct-11, While Virtual Machine (VM) lively migrate around, not only the OS, memory, and the states on Hypervisor need to be migrated with VM, but also the states on the network side, e.g. on Firewall. Otherwise, the running services on the migrated VM could be disrupted, even stopped, In this draft, we describe the background and use cases of this proposal. We also raise a clear scope for the proposal. "CoRE Resource Directory", Srdjan Krco, Zach Shelby, 31-Oct-11, In many M2M scenarios, direct discovery of resources is not practical due to sleeping nodes, disperse networks, or networks where multicast traffic is inefficient. These problems can be solved by employing an entity called a Resource Directory (RD), which hosts descriptions of resources held on other servers, allowing lookups to be performed for those resources. This document specifies the web interfaces that a Resource Directory supports in order for web servers to discover the RD and to registrer, maintain, lookup and remove resources descriptions. Furthermore, new link attributes useful in conjunction with an RD are defined. "MPLS-TP Operations, Administration, and Management (OAM) Identifiers Management Information Base (MIB)", Kannan Sampath, Ping Pan, Sam Aldrin, Sami Boutros, Thomas Nadeau, Venkatesan Mahalingam, 17-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 Operations, Administration, and Management (OAM) identifiers related managed objects for Multiprotocol Label Switching (MPLS) based Transport Profile (TP). "Encoding of Data Structure (DS) in the Path Computation Element Communication Protocol (PCEP)", Dhruv Dhody, Udayasree Palle, 17-Feb-12, The ability to compute shortest constrained Traffic Engineering Label Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains has been identified as a key requirement for P2P and P2MP scenarios. Backward-Recursive PCE-Based Computation (BRPC) [RFC5441] defines VSPT [Virtual Shortest Path Tree] as a default de-facto data structure for PCRep message in inter-domain scenarios. AS PCE will get used in newer scenarios like inter-domain, protection, P2MP etc. As well as PCE is being explored to be used in Cross Stratrum Optimization (CSO) environment (see [CSO-PCE]). Limiting PCEP protocol to just one data structure limits the usage of PCEP. Its important to keep PCEP generic enough to use differnt data structure and apply different algorithms. This document defines extensions to the PCE communication Protocol (PCEP) to allow multiple data structures. Extensions are defined for PCE to indicate the set of Data Structure (DS) it supports; also PCC/ PCE can indicate in a path computation request the required DS, and a PCE can report in a path computation reply the Data Structure that was used in the path reply message. "Supporting explicit-path per destination in Path Computation Element Communication Protocol (PCEP) P2MP Path Request Message.", Dhruv Dhody, Udayasree Palle, 15-Feb-12, The ability to determine paths of point-to-multipoint (P2MP) Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) is one the key requirements for Path Computation Element (PCE). [RFC6006] and [PCE-P2MP-PROCEDURES] describes these mechanisms for intra and inter domain environment. Explicit Path in this document refers to the configured list of network elements that MUST be traversed or MUST be excluded in the final path computation. This should not be confused with the RSVP terminology. Network elements can further be strict or loose hop. This document describes extensions to the PCE communication Protocol (PCEP) to define explicit-path per destination in P2MP context. "October 28, 2011", Parag Jain, Sami Boutros, Sam Aldrin, 28-Oct-11, LSP-Ping is a widely deployed Operation, Administration, and Maintenance (OAM) mechanism in MPLS networks. This document describes a mechanism to verify connectivity of Point-to-Multipoint (P2MP) Pseudowires (PW) using LSP Ping. "Security Framework for Virtualized Data Center Services", Suren Karavettil, Bhumip Khasnabish, Ning So, Wei Dong, 30-Dec-11, This document discusses the requirements and technology gaps related to security in the virtualized data center services (VDCS). The objective is to ensure end-to-end security for various types of carrier services built on virtualized infrastructure. The issues covered in this draft are focused on confidentiality and integrity of the services in the virtualized environment; including but not limited to infrastructure (IaaS), platform (PaaS), and application (SaaS) services. This draft also takes into account transient nature of identity, resources and connectivity in the virtualized environment. "FCoE over TRILL", David Melman, Tal Mizrahi, Donald Eastlake, 11-Sep-11, Fibre Channel over Ethernet (FCoE) and TRILL are two emerging standards in the data center environment. While these two protocols are seemingly unrelated, they have a very similar behavior in the forwarding plane, as both perform hop-by-hop forwarding over Ethernet, modifying the packet's MAC addresses at each hop. This document describes an architecture for the integrated deployment of these two protocols. "Requirements for VPN-Oriented Data Center Services", Dave McDysan, Henry Yu, John Heinz, Ning So, 26-Oct-11, This contribution addresses the service providers' requirements to support VPN-Oriented data center services. It describes the characteristics and the framework of VPN-oriented data center services and specifies the requirements on how to maintain and manage the virtual resources within data center resources and the supporting network infrastructures for those services. "WebRTC Codec and Media Processing Requirements", Cary Bran, Cullen Jennings, 29-Oct-11, This document outlines the codec and media processing requirements for WebRTC client application and endpoint devices. "WebRTC Network Address Translation", Cary Bran, Matthew Kaufman, Cullen Jennings, Jonathan Rosenberg, 29-Oct-11, This document outlines the network address translation (NAT) traversal requirements and for WebRTC client applications. "Framework for CDN Interconnection", Bruce Davie, Larry Peterson, 31-Oct-11, This document presents a framework for Content Distribution Network Interconnection (CDNI). The purpose of the framework is to provide an overall picture of the problem space of CDNI and to describe the relationships among the various components necessary to interconnect CDNs. CDN Interconnection requires the specification of several interfaces and mechanisms to address issues such as request routing, metadata exchange, and the acquisition of content by one CDN from another. The intent of this document is to outline what each interface needs to accomplish, and to describe how these interfaces and mechanisms fit together, while leaving their detailed specification to other documents. "A SNMP MIB to manage black-link optical interface parameters of DWDM applications", Ruediger Kunze, 31-Oct-11, This memo defines a portion of the Management Information Base (MIB) used by Simple Network Management Protocol (SNMP) in TCP/IP- based internets. In particular, it defines objects for managing Optical parameters associated with Wavelength Division Multiplexing (WDM) systems or characterized by the Optical Transport Network (OTN) in accordance with the Black-Link approach defined in ITU-T Recommendation G.698.2. [ITU.G698.2] The MIB module defined in this memo can be used for Optical Parameters monitoring and/or configuration of the endpoints of Black Links. "IPv6 Support Within IETF work", Wesley George, Chris Donley, Lee Howard, 21-Feb-12, This document recommends that IETF formally require its standards work to be IP version agnostic or to explicitly include support for IPv6, with some exceptions. It recommends that future IPv4 work be limited to solving documented operational problems identified through deployment experience. "A framework for Management and Control of optical interfaces supporting G.698.2", Ruediger Kunze, Gert Grammel, Hans-Juergen Schmidtke, 31-Oct-11, This document provides a framework that describes a solution space for the control and management of optical interfaces according to the Black Link approach as specified by ITU-T [ITU.G698.2] and further revisions. In particular, it examines topological elements and related network management measures. Optical Routing and Wavelength assignment based on WSON is out of scope. This document concentrates on the management of optical interfaces. The application of a dynamic control plane, e.g. for auto-discovery or for the distribtion of interface parameters, is complementary. Anyway, this work is not in conflict with WSON but leverages and supports related work already done for management plane and control plane. The framework document will not address the client mapping into G.709. This document only addresses the lower layers. Furthermore, support for Fast Fault Detection, to e.g. trigger Protection Switching is provided by the WDM interface capability of the client interface (e.g. ITU-T G.709) is out of scope for this work. Additionally the wavelength ordering process and the process how to determine the demand for a new wavelength from A to Z is out of scope. "Incremental Label Announcement Extensions for LDP", Alton Lo, Keyur Patel, Vanson Lim, 1-Jan-12, The current LDP Graceful Restart (GR) mechanism specified in RFC3478 requires a complete re-advertisement of the LDP label binding information across a session restart, even though complete label binding information might be preserved. In this document we specify extensions to LDP graceful restart in order to support avoiding unnecessary transmission of the label binding information preserved across a session restart, thus accelerating the router re-convergence. More specifically, we describe a version number based batching mechanism for keeping track of the label binding information across a session restart. The new 1) LDP ILA capability TLV, 2) LDP VERSION ID TLV and 3) LDP ILA Version message type, is introduced for checkpointing the label binding version maintained for a neighbor. We also specify procedures for handling label binding table version update across a session restart. "Node redundancy provisioning for VPLS Inter-domain", Ran Chen, Zhihua Liu, 28-Sep-11, In many VPLS deployment based on [RFC4762], inter-domain has been deployed without node redundancy, or only with node redundancy in one domain. This document describes how to deploy inter-domain VPLS based on [RFC4762] with node redundancy in both domain. The draft reuses the existing protocols without introducing any new protocols. "Applicability of LDP Label Advertisement Mode", Kamran Raza, Sami Boutros, Luca Martini, Nicolai Leymann, 13-Jan-12, An LDP speaker negotiates the label advertisement mode with its LDP peer at the time of session establishment. Although different applications sharing the same LDP session may need different modes of label distribution and advertisement, there is only one type of label advertisement mode that is negotiated and used per LDP session. This document clarifies the use and the applicability of session's negotiated label advertisement mode, and categorizes LDP applications into two broad categories of negotiated mode-bound and mode-independent applications. The document also suggests an update to RFC5036 and RFC4447 to remove any ambiguity and conflict in the area of using correct label advertisement mode for a given application. "Energy Aware IPv6 Neighbor Discovery Optimizations", Samita Chakrabarti, Erik Nordmark, Margaret Wasserman, 31-Oct-11, IPv6 Neighbor Discovery (RFC 4861) protocol has been designed for neighbor's address resolution, unreachability detection, address autoconfiguration, router advertisement and solicitation. With the progress of Internet adoption on various industries including home, wireless and machine-to-machine communications, there is a desire for optimizing legacy IPv6 Neighbor Discovery protocol for energy- efficient networks and nodes. Research indicates that often networked- nodes require more energy than stand-alone nodes because a node's energy usage depends on network messages it receives and responds. While reducing energy consumption is essential for battery operated nodes in some machines, saving energy actually a cost factor in business in general as the explosion of more device usage is leading to usage of more servers and network infrastructure in all sectors of the society and business. This document describes a method of optimizations by reducing periodic multicast messages, frequent Neighbor Solicitation messages and discusses interoperability with legacy IPv6 nodes. This document also addresses the ND denial of service issues by introducing node Registration procedure. "One Hop Lookups Algorithm Plugin for RELOAD", Jin Peng, Lifeng Le, Kai Feng, 30-Oct-11, This document proposes an implementation of overlay plugin algorithm which is called one hop lookups to provide examples and references for the research of one hop based RELOAD. With the development of the real time communications, there are high demands for the improvement of routing efficiency. In the one hop algorithm, each peer maintains complete membership information which can guarantee one hop lookups to improve the routing efficiency. For the RELOAD, using the one hop lookups algorithm to construct Topology Plugin with the same RELOAD core can have a better support for VoIP applications, and the implementation of one hop lookups algorithm plugin is based on the methods provided by RELAOD. "Proposals for RELOAD to support Promotion and Demotion for User-owned Nodes", Jin Peng, Lifeng Le, Gang Li, Xiao Ma, 30-Oct-11, This document proposes extensions to RELOAD to support flexible client promotion and demotion modes. RELOAD aims at providing a uniform protocol for both overlay clients and peers, where promotion of a client to peer is triggered and completed at the client's pleasure. It is proposed that RELOAD provide a more restrictive framework to enable passive promotion and demotion, where decisions are made by the network rather than individual user-owned nodes. "RBridges: TRILL Link Data Optimizations", Radia Perlman, Donald Eastlake, Anoop Ghanwani, 14-Jan-12, Under certain circumstances, it is possible to encode TRILL (TRansparent Interconnection of Lots of Links) Data frames so as to make more efficient use of communications links. This document specifies two such optional optimizations. One, called Compact Format, improves the compactness of encoding in the case where a TRILL link is a point-to-point Ethernet link. The other, called Specific Addressing, optionally decreases the burden on multi-access TRILL links for multi-destination TRILL Data frames under some circumstances. This document updates RFC 6325. "User-Managed Access (UMA) Core Protocol", Thomas Hardjono, 3-Feb-12, This specification defines the User-Managed Access (UMA) core protocol. This protocol provides a method for users to control access to their protected resources, residing on any number of host sites, through an authorization manager that governs access decisions based on user policy. "Textual Conventions for Proxy Mobile IPv6 Management", Glenn Mansfield, Sri Gundavelli, 26-Sep-11, This memo defines a Management Information Base (MIB) module which contains Textual Conventions to represent commonly used Proxy Mobile-IPv6 (PMIPv6) management information. The intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and used in PMIPv6 related MIB modules that would otherwise define their own representation(s). "RELOAD Client Extension", LiChun Li, Jun Wang, 31-Oct-11, This draft describes mechanisms of multiple access peers and backup access peer. This draft also proposes additional ways to route message to client. "Motivation for developing Stateless Automatic IPv4 over IPv6 Encapsulation / Decapsulation Technology (SA46T)", Naoki Matsuhira, 3-Jan-12, This document describe a motivation for developing IPv4 over IPv6 encapsulation / decapsulation solution from standing position of Stateless Autimatic IPv4 over IPv6 Encapsulation / Decapsulation Technology (SA46T) and SA46T with address sharing (SA46T-AS). "Framework for Telepresence Multi-Streams", Allyn Romanow, Andrew Pepperell, Brian Baldino, Mark Duckworth, 2-Oct-11, This memo offers a framework for a protocol that enables devices in a telepresence conference to interoperate by specifying the relationships between multiple RTP streams. "Managing Service Mobility for Virtualized Networks", Ashutosh Dutta, Carl Williams, Fuchun Lin, Hidetoshi Yokota, Vishwas Manral, 18-Oct-11, In virtualized networks, machines with processing and storage are virtualized resources on which network functional entities can be allocated and relocated dynamically. Such dynamic allocation and relocation of network entities imposes the challenge of service mobility, i.e., how to maintain not only coupling relations between those network entities but also sessions established between those entities in a virtualized environment. This document provides a reference model for managing service mobility in the virtual environment and defines the control protocol between the virtualized platform and the managing controller to realize service mobility. Such capability is especially longed for realizing more scalable and reliable telecom networks. "Cisco Specific Information Elements for IPFIX", Andrew Yourtchenko, Paul Aitken, Benoit Claise, 31-Oct-11, This document describes some additional Information Elements of Cisco Systems, Inc. that are not listed in RFC3954. "An Architecture for IP/LDP Fast-Reroute Using Maximally Redundant Trees", Alia Atlas, Robert Kebler, Maciek Konstantynowicz, Andras Csaszar, Russ White, Mike Shand, 31-Oct-11, As IP and LDP Fast-Reroute are increasingly deployed, the coverage limitations of Loop-Free Alternates are seen as a problem that requires a straightforward and consistent solution for IP and LDP, for unicast and multicast. This draft describes an architecture based on redundant backup trees where a single failure can cut a point-of-local-repair from the destination only on one of the pair of redundant trees. One innovative algorithm to compute such topologies is maximally disjoint backup trees. Each router can compute its next-hops for each pair of maximally disjoint trees rooted at each node in the IGP area with computational complexity similar to that required by Dijkstra. The additional state, address and computation requirements are believed to be significantly less than the Not-Via architecture requires. "ARIN Draft Policy 2011-5: Shared Transition Space", Stan Barber, Owen Delong, Chris Grundemann, Victor Kuarsingh, Benson Schliesser, 20-Sep-11, This memo discusses the applicability of a Shared Transition Space, an IPv4 prefix designated for local use within service provider networks during the period of IPv6 transition. This address space has been proposed at various times in the IETF, and more recently come to consensus within the ARIN policy development community where it was recommended for adoption as Draft Policy 2011-5. "Guidance for Light-Weight Implementations of the Internet Protocol Suite", Carsten Bormann, 24-Jan-12, Implementation of Internet protocols on small devices benefits from light-weight implementation techniques, which are often not documented in an accessible way. This document provides a first outline of and some initial content for the Light-Weight Implementation Guidance document planned by the IETF working group LWIG. "Best practices for HTTP-CoAP mapping implementation", Angelo Castellani, Salvatore Loreto, Akbar Rahman, Thomas Fossati, Esko Dijk, 31-Oct-11, This draft aims at being a base reference documentation for HTTP-CoAP proxy implementors. It details deployment options, discusses possible approaches for URI mapping, and provides useful considerations related to protocol translation. "RSVP-TE Extensions for Lock Instruct and Loopback in MPLS Transport Profile", Jie Dong, Mach Chen, Zhenqiang Li, 30-Oct-11, This document specifies extensions to RSVP-TE to support lock instruct and loopback mechanism for MPLS-TP LSPs. The mechanisms are intended to be applicable to other aspects of MPLS as well. "Directory Assisted RBridge Edge", Linda Dunbar, Donald Eastlake, Radia Perlman, Igor Gashinsky, 26-Oct-11, RBridge edge nodes currently learn the mapping between MAC addresses and their corresponding RBridge edge nodes by observing the data packets traversed through. When ingress RBridge receives a data packet with its destination address (MAC&VLAN) unknown, the data packet is flooded across RBridge domain. When there are more than one RBridge ports connected to one bridged LAN, only one of them can be designated as AF port for forwarding/receiving traffic for each LAN, the rest have to be blocked for that LAN. This draft describes why and how directory assisted RBridge edge can improve TRILL network scalability in data center environment. "RBridge and Switching Device Layering and Compatibility", Donald Eastlake, Susan Hares, Jon Hudson, 29-Aug-11, This document describes a layering and peering model for network switches and end stations. It also discusses, using this model, the compatibility of RBridges (Routing Bridges) with Layer 3 routers and various types of bridges including Shortest Path Bridges. RBridges are devices that implement the IETF TRILL (TRansparent Interconnection of Lots of Links) standard. "RBridges: Fine-Grained Labeling", Donald Eastlake, Mingui Zhang, Puneet Agarwal, Dinesh Dutt, Radia Perlman, 28-Oct-11, The IETF has standardized RBridges (Routing Bridges), devices that implement the TRILL (TRansparent Interconnection of Lots of Links) protocol, a standard for least cost transparent frame routing in multi-hop networks with arbitrary topologies, using link-state routing and encapsulation with a hop count. The TRILL base protocol standard supports up to 4K VLAN IDs (Virtual Local Area Network IDentifiers). However, there are applications that require more fine-grained labeling of data and end stations. This document updates RFC 6325 by specifying extensions to the TRILL protocol to accomplish this. "Multiple Topology TRILL", Donald Eastlake, Mingui Zhang, Radia Perlman, Ayan Banerjee, Vishwas Manral, 10-Jan-12, The IETF TRILL (TRansparent Interconnection of Lots of Links) protocol is a solution for least cost transparent frame routing in multi-hop networks with arbitrary topologies and link technologies, using IS-IS (Intermediate System to Intermediate System) link-state routing and encapsulation with a hop count. IS-IS supports multiple topology routing. This document specifies a TRILL data plane encoding and procedures to make use of such routing. "RBridge: Pseudonode Nickname", Radia Perlman, ZTE Corporation, 13-Nov-11, The Appointed Forwarder on a link for VLAN-x is the RBridge that ingresses native frames from the link and egresses native frames to the link in VLAN-x. If the appointed forwarder for an end station is changed, the remote data traffic to the end station could fail. This document is proposed to assign a nickname for pseudonode identifying a multi-access link to solve the issue. When any appointed forwarder encapsulates a packet, it uses the pseudonode nickname as "ingress nickname" rather than its own nickname. If it does, then if the appointed forwarder changes, or the DRB changes, and the pseudonode still uses the same nickname, then the remote RBridge caches won't need to change, and the data traffic to the end station would reach the link uninterruptedly. "RBridges: The ESADI Protocol", Donald Eastlake, fangwei hu, ZTE Corporation, Radia Perlman, 31-Dec-11, The IETF TRILL (TRansparent Interconnection of Lots of Links) protocol provides least cost pair-wise data forwarding without configuration in multi-hop networks with arbitrary topologies and safe forwarding even during periods of temporary loops. TRILL supports the multi-pathing of both unicast and multicast traffic. TRILL accomplishes this by using IS-IS (Intermediate System to Intermediate System) link state routing and encapsulating traffic using a header that includes a hop count. The ESADI (End System Address Distribution Information) protocol is a VLAN (Virtual Local Area Network) scoped way that RBridge can communicate end station addresses to each other. An RBridge announcing VLAN-x connectivity (normally a VLAN-x forwarder) and running the TRILL ESADI protocol can receive remote address information and/or transmit local address information for VLAN-x to other such RBridges. The purpose of this document is to improve and update the documentation of the ESADI protocol. It updates RFC 6325. The ESADI RBridge instance states, DRB (Designated RBridge) election procedure, and ESADI sub-TLV are specified in this document. "CLEFIA Cipher Suites for Transport Layer Security (TLS)", Masanobu Katagi, Shiho Moriai, 31-Oct-11, This document specifies a set of cipher suites for the Transport Security Layer (TLS) protocol to support the CLEFIA encryption algorithm as a block cipher. CLEFIA is a lightweight block cipher and suitable for constrained devices. "Some Measurements on World IPv6 Day from End-User Perspective", Ari Keranen, Jari Arkko, 4-Jan-12, During the World IPv6 Day on June 8th, 2011, several key content providers enabled their networks to offer both IPv4 and IPv6 services. Hundreds of organizations participated in this effort, and in the months and weeks leading up to the event worked hard on preparing their networks to support this event. The event was largely unnoticed by the general public, which is a good thing since it means that no major problems were detected. For the Internet, however, there was a major change on such a small timescale. This memo discusses measurements that the authors made from the perspective of an end-user with good IPv4 and IPv6 connectivity. Our measurements include the number of most popular networks providing AAAA records for their service as well as delay and connection failure statistics. "Accurate ECN Feedback in TCP", Mirja Kuehlewind, Richard Scheffenegger, 31-Oct-11, Explicit Congestion Notification (ECN) is an IP/TCP mechanism where network nodes can mark IP packets instead of dropping them to indicate congestion to the end-points. An ECN-capable receiver will feedback this information to the sender. ECN is specified for TCP in such a way that only one feedback signal can be transmitted per Round-Trip Time (RTT). Recently new TCP mechanisms like ConEx or DCTCP need more accurate feedback information in the case where more than one marking is received in one RTT. "TCP modifications for Congestion Exposure", Mirja Kuehlewind, Richard Scheffenegger, 31-Oct-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). "Recommendation for DNS64-based NAT64 Round Robin Load-balancing", Zhenqiang Li, Gang Chen, Qin Zhao, Xiaohong Huang, Yan Ma, 31-Oct-11, This document compares some stateful prefix selection policies and suggests that the DNS64-based Round Robin Prefix Selection Policy be proper for the NAT64 load-balancing. This document also illustrates two recommended implementations of Round Robin Prefix Selection Policy in detail. "Management Information Base for Load Balancers", Chen Li, Lianyuan Li, 13-Nov-11, Load balancer is deployed widely in datacenter nowadays. There is a requirement to build a unique LB network management system where two or more vendors' LB devices are used. We propose the standard MIBs for unique NMS. Load balancer description is introduced at "http://en.wikipedia.org/wiki/Load_balancing_(computing)". This memo defines an portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a MIB module for load balance device. "Analysis on Load Balancing Requirement in IPv4/IPv6 Transition", Zhenqiang Li, Qin Zhao, Xiaohong Huang, Yan Ma, 31-Oct-11, This document first analyzes the critical issues of bottlenecks in existing tunneling and translation technologies, which can be solved by proper load balancing mechanisms(e,g., scalability, availability, and single point of failure). Then, several key factors in designing a valid load balancing mechanism are described. Solutions to specific load balancing requirements can be drawn out by considering these factors. At last, current efforts about load balancing are introduced. "PMIP Based Distributed Mobility Management Approach", Dapeng Liu, 1-Dec-11, Distributed mobility management (DMM) approach is needed, because the mobile networks are moving towards flat architectures. This document defines a PMIPv6 based distributed mobility management protocol. "Transmission of IPv6 over MS/TP Networks", Kerry Lynn, Jerry Martocci, Carl Neilson, Stuart Donaldson, 10-Oct-11, MS/TP (Master-Slave/Token-Passing) is a contention-free access method for the TIA-485-A physical layer that is used extensively in building automation networks. This document describes the frame format for transmission of IPv6 packets and the method of forming link-local and statelessly autoconfigured IPv6 addresses on MS/TP networks. "WSON Optical Interface Class", Giovanni Martinelli, Gabriele Galimberti, Lyndon Ong, Daniele Ceccarelli, 31-Oct-11, Current work on wavelength switched optical network includes several considerations regarding the interface signal compatibility. In particular ingress and egress optical interfaces will require a check on several optical parameters to assess if the signal generated by the ingress interface can be compatible with the receiving interface. Current solution available encode all parameters in WSON protocol extensions while in this draft will propose an alternative method to keep into account the signal compatibility issue at protocol level. "Generation of Deterministic Initialization Vectors (IVs) and Nonces", David McGrew, 31-Oct-11, Many cryptographic algorithms use deterministic IVs, including CTR, GCM, CCM, GMAC. This type of IV is also called a (deterministic) nonce. Deterministic IVs must be distinct, for each fixed key, to guarantee the security of the algorithm. This note describes best practices for the generation of such IVs, and summarizes how they are generated and used in different protocols. Some problem areas are highlighted, and test considerations are outlined. This note will be useful to implementers of algorithms using deterministic IVs, and to protocol or system designers using them. "IPv4 Residual Deployment on IPv6 infrastructure - protocol specification", Tetsuya Murakami, Ole Troan, Satoru Matsushima, 24-Sep-11, This document specifies an automatic tunneling mechanism for providing IPv4 connectivity service to end users over a service provider's IPv6 network. Key aspects include stateless operation, sharing of IPv4 addresses, and an algorithmic mapping between IPv4 addresses and IPv6 tunnel endpoints. "Mutual Authentication Protocol for HTTP: Cryptographic Algorithms", Yutaka Oiwa, Hajime Watanabe, Hiromitsu Takagi, Boku Kihara, Tatsuya Hayashi, Yuichi Ioku, 31-Oct-11, This document specifies some cryptographic algorithms which will be used for the Mutual user authentication method for the Hyper-text Transport Protocol (HTTP). "DMM Comparison Matrix", Charles Perkins, Dapeng Liu, 31-Oct-11, Distributed Mobility Management (DMM) is proposed as a way to enable scalable growth of mobile core networks so that network service providers can meet new requirements for performance and reduced operational expenditures. This requires reconsideration of existing approaches within the IETF and elsewhere in order to determine which if any such approaches may be used as part of a DMM solution. "Pseudowire Communities", Paul Kwok, Pranjal Dutta, 31-Oct-11, [RFC4447]describes a set of procedures for Pseudowire set-up and maintenance using LDP as signaling protocol. [I-D.ietf-pwe3-dynamic-ms-pw] extends the mechanisms described in [RFC4447] for dynamic placement of multi- segment pseudowires. This document describes an extension to [RFC4447]procedures which may be used to pass additional information to S-PE/T-PEs when SS-PWs or MS-PWs are set-up. The intention of the proposed technique is to aid in policy administration, specifically during MS-PW set-up across various S-PEs. The proposed method is very generic so that it can support the management of various parameters or rules while setting up pseudowires with minimal overhead. "IPv6 Rapid Deployment (6rd) in a Large Data Center", Shishio Tsuchiya, Mark Townsley, Shuichi Ohkubo, 14-Nov-11, IPv6 Rapid Deployment (6rd) as defined in RFC 5969 focuses on rapid deployment of IPv6 by an access service provider which has difficulty deploying native IPv6. This document describes how 6rd can be used to deliver IPv6 within a Large Data Center. "Extensions of Probabilistic Routing Protocol for Intermittently Connected Networks", Seok-Kap Ko, Sim-Kwon Yoon, Hong-Yeon Yu, 31-Oct-11, This document defines extensions of PRoPHET, a Probabilistic Routing Protocol using History of Encounters and Transitivity. The document presents two extensions of current PRoPHET draft-09. The first extension is to apply the contact duration to calculate the delivery predictability. The other is to provide a forward strategy which can alleviate the bundle starving problem. "Additional IPv4 Delegations for AS112 Nameservers", Geoff Huston, George Michaelson, Joe Abley, William Sotomayor, 27-Jan-12, This is a direction to IANA concerning the delegation of certain additional IPv4 zones to the AS112 project. "BGPSEC Design Choices and Summary of Supporting Discussions", Kotikalapudi Sriram, 5-Jan-12, This document has been written to capture the design rationale for the draft-00 version of BGPSEC protocol specification (I-D.ietf-sidr- bgpsec-protocol-00). It lists the decisions that have been made in favor of or against each design choice, and presents brief summaries of the arguments that aided the decision process. A similar document can be published in the future as the BGPSEC design discussions make further progress and additional design considerations are discussed and finalized. "Context Transfer Protocol Extension for Multicast", Dirk Hugo, Hitoshi Asaeda, 9-Jan-12, This document describes an extension of the Context Transfer Protocol (CXTP) to support seamless IP multicast services with Proxy Mobile IPv6 (PMIPv6). "Federated Cross-Layer Access", Yinxing Wei, 31-Oct-11, Network stratum and application stratum form a federation to faciliate user's access. Network operator acts as Identity Provider (IdP), and application reuses underlying network's security capabilities to simlify application's access. This document is to introduce such federated cross-layer access use case and message flows. "dIVI-pd: Dual-Stateless IPv4/IPv6 Translation with Prefix Delegation", Qiong Sun, Rajiv Asati, Chongfeng Xie, Xing Li, Wojciech Dec, Congxiao Bao, 23-Sep-11, This document presents the address specifications and deployment considerations of address-sharing dual stateless IPv4/IPv6 translation with prefix delegation (dIVI-pd). The dIVI-pd keeps the features of stateless, end-to-end address transparency and bidirectional-initiated communications of the original stateless IPv4/IPv6 translation, while it can utilize the IPv4 addresses more effectively. In addition, it does not require the DNS64 and ALG, and can be used with prefix delegation. "Definitions of Managed Objects for the RPKI-Router Protocol", Bert Wijnen, Keyur Patel, Michael Baer, Randy Bush, 31-Oct-11, This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for monitoring the RPKI Router protocol. "Maximum Transmission Unit Extended Community for BGP-4", Jie Dong, Qing Zeng, 30-Oct-11, Proper functioning of path Maximum Transmission Unit (MTU) discovery [RFC1191] requires that IP routers have knowledge of the MTU for each link to which they are connected. As MPLS progresses, [RFC3988] specifies extensions to LDP in support of LDP LSP MTU discovery. For the LSP created using Border Gateway Protocol (BGP) [RFC3107], it does not have the ability to signal the path MTU to the ingress Label Switching Router (LSR). In the absence of this functionality, the MTU for the BGP LSP must be statically configured by network operators or by equivalent off-line mechanisms. This document defines the MTU Extended Community for BGP in support of BGP LSP MTU discovery. "LISP Mobile Node extension", Jun Wang, Yu Meng, Ningxia Zhao, 31-Oct-11, LISP describes a network-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. The LISP Mobile Node extension design described in this document uses standard LISP functionality to provide scalable mobility for LISP mobile nodes. This document extends the lisp, it introduces some contents that lisp does not include but the author think it is important and recommendation them to be considered in the lisp. "Mediated RSA cryptography specification for additive private key splitting (mRSAA)", Daniel Wachnik, Przemyslaw Kubiak, Michal Tabor, Miroslaw Kutylowski, 14-Nov-11, This document describes recommendations for the implementation of public key cryptography based on the mediated RSA algorithm. The Mediated RSA algorithm bases on fragmentation of a private key. As a result the signature process consists from multiple stages. The verification process is the same as in the case of RSA algorithm [RFC3447]. "Multihop Federations for Application Bridging for Federation Beyond the Web (ABFAB)", Margaret Wasserman, Hannes Tschofenig, 30-Oct-11, This document describes a mechanism for establishing trust across a multihop federation within the Application Bridging for Federation Beyond the Web (ABFAB) framework. This document introduces a new entity, the Trust Router. Trust Routers exchange information about the availability of Trust Paths across a multihop federation. They can be queried by a Relying Party to obtain the best Trust Path to reach an Identity Provider. They also provide temporary identities that can be used by a Relying Party to traverse a Trust Path. "The Universal Voting Markup Language (UVML)", Erin Phillips, 7-Jan-12, This document describes the Universal Voting Markup Language (UVML), a syntax for the structured representation of opinion in free text. Using UVML, opinions can be encoded in text, image, or video, and reliably interpreted by either human readers or automated-agents. UVML supports both rating and ranking semantics. Ratings may be scored using symbols associated with the five most commonly used opinion dimensions: quality(*), importance(!), outlook($), support- opposition(+), and likelihood(%). In addition, UVML defines a syntax for optionally including a demographic signature by which voters can publish basic demographic information with their UVML votes. The design of UVML leverages cross-cultural sentiment and voting-systems scholarship. "Scalable BGP FRR Protection against Edge Node Failure", Ahmed Bashandy, 28-Oct-11, Consider a BGP free core scenario. Suppose the edge BGP speakers PE1, PE2,..., PEn know about a prefix P/p via the external routers CE1, CE2,..., CEm. If the edge router PEi crashes or becomes totally disconnected from the core, it desirable for a penultimate hop route "P" carrying traffic to the failed edge router PEi to immediately restore traffic by re-tunneling packets originally tunneled to PEi and destined to the prefix P/p to one of the other edge routers that advertised P/p, say PEj, until BGP re-converges. In doing so, it is highly desirable to keep the core BGP-free while not imposing restrictions on external connectivity. Thus (1) a core router should not be required to learn any BGP prefix, (2) the size of the forwarding and routing tables in the core routers should be independent of the number of BGP prefixes,(3) there should be no special router (or group of routers) that handles restoring traffic, and (4) there should be no restrictions on what edge routers advertise what prefixes. For labeled prefixes, (5) the penultimate hop router must swap the label advertised by the failed edge router PEi for the prefix P/p with the label advertised for the same prefix by the edge router PEj before re-tunneling the packet to PEj "Recommendations for the transition of email services from IPv4 to IPv6 for Internet Service Providers", Heather Lord, Jordan Rosenwald, 12-Sep-11, This document contains a phased plan for how providers of email services can effect and manage the transition of email services from IPv4 to IPv6. It is expected that this will be effected over a period of years and it is unlikely that any transition will completely exclude the ongoing possibility of using IPv4 as a transport mechanism for email. This provides one possible implementation plan for transitioning email services on the Internet from a predominantly IPv4-based connectivity model that suports IPv6. "Version Number and Rank Authentication", Amit Dvir, Laszlo Dora, Levente Buttyan, Tamas Holczer, 9-Jan-12, Designing a routing protocol for large low-power and lossy networks (LLNs), consisting of thousands of constrained nodes and unreliable links, presents new challenges. The IPv6 Routing Protocol for Low- power and Lossy Networks (RPL), have been developed by the IETF ROLL Working Group as a preferred routing protocol to provide IPv6 routing functionality in LLNs. Unfortunately, the currently available security services in RPL will not protect against a compromised internal node that can construct and disseminate fake messages. Therefore, in RPL special security care must be taken when the Destination Oriented Directed Acyclic Graph (DODAG) root is updating the Version Number by which reconstruction of the routing topology can be initiated. The same care also must be taken to prevent an internal attacker (compromised DODAG node) to publish decreased Rank value, which causes a large part of the DODAG to connect to the DODAG root via the attacker and give it the ability to eavesdrop or manipulate a large part of the network traffic. In this document, a new security service is described that prevents any misbehaving DODAG node from illegitimately increasing the Version Number or publish illegitimately decreased Rank values. "IPv6 Extension Headers Reserved Space", Hagen Pfeifer, 11-Sep-11, This document specify a mechanism to allow IPv6 stack implementation to parse upcoming IPv6 extension header by reserving a small range of protocol numbers for well defined IPv6 extension headers. IPv6 stack implementors can code these range into their network stack a priori. These reserved range provide an guarantee that a given next header is a well formed extension header and not a next layer protocol. Operators, companies, vendors et cetera are in the ability to deploy and test not standardized extension headers without modifying every middle box parsing the complete extension header chain in between. "Generalized Label for Super-Channel Assignment on Flexible Grid", Zhong Pan, Iftekhar Hussain, Marco Sosa, Abinder Dhillon, Bert Basch, Steve Liu, Andrew Malis, 31-Oct-11, To enable scaling of existing transport systems to ultra high data rates of 1 Tbps and beyond, next generation systems providing super- channel switching capability are currently being developed. To allow efficient allocation of optical spectral bandwidth for such high bit rate systems, International Telecommunication Union Telecommunication Standardization Sector (ITU-T) is extending the G.694.1 grid standard (termed "Fixed-Grid") to include flexible grid (termed "Flex-Grid") support (draft revised ITU-T G.694.1, revision 1.4, Oct 2011). This necessitates definition of new label format for the Flex-Grid. This document defines a super-channel label as a Super-Channel Identifier and an associated list of 12.5 GHz slices representing the optical spectrum of the super-channel. The label information can be encoded using a fixed length or variable length format. This label format can be used in GMPLS signaling and routing protocol to establish super-channel based optical label switched paths (LSPs). "Network Address Translation (NAT) Behavioral Requirements Updates", Sarat Kamiset, Simon Perreault, 16-Nov-11, This document clarifies and updates several requirements of RFC4787, RFC5382 and RFC5508 based on operational and development experience. The focus of this document is NAPT44. "TLS Origin-Bound Certificates", Dirk Balfanz, D Smetters, Adam Barth, 14-Nov-11, This document specifies a Transport Layer Security (TLS) extension and associated semantics that allow clients and servers to negotiate the use of origin-bound, self-signed certificates for TLS client authentication. "Traffic Engineering architecture for services aware MPLS", Qilei Wang, Vishwas Manral, Spencer Giacalone, Xihua Fu, Malcolm Betts, Dave McDysan, John Drake, Andrew Malis, 13-Nov-11, With more and more enterprises using cloud based services, the distances between the user and the applications are growing. A lot of the current applications are designed to work across LAN's and have various inherent assumptions. For multiple applications such as High Performance Computing and Electronic Financial markets, the response times are critical as is packet loss, while other applications require more throughput. [RFC3031] describes the architecture of MPLS based networks. This draft extends the MPLS architecture to allow for latency, loss and jitter as properties. It describes requirements and control plane implication for latency and packet loss as a traffic engineering performance metric in today's network which is consisting of potentially multiple layers of packet transport network and optical transport network in order to make a accurate end-to-end latency and loss prediction before a path is established. Note MPLS architecture for Multicast will be taken up in a future version of the draft. "Energy Management Terminology", John Parello, 4-Dec-11, This document contains definitions and terms used in the Energy Management Working Group. Each term contains a definition(s), example, and reference to a normative, informative or well know source. Terms originating in this draft should be either composed of or adapted from other terms in the draft with a source. The defined terms will then be used in other drafts as defined here. "Design Guidelines for Routing Metrics Composition in LLN", Theodore Zahariadis, 31-Aug-11, This document specifies the guidelines for designing efficient composite routing metrics to be applied to the Routing for Low Power and Lossy Networks (RPL) routing protocol. "Design Guidelines for Routing Metrics Composition in LLN", Theodore Zahariadis, 23-Nov-11, This document specifies the guidelines for designing efficient composite routing metrics to be applied to the Routing for Low Power and Lossy Networks (RPL) routing protocol. "Label Switched Path (LSP) Ping for IPv6 Pseudowire FECs", Ping Pan, Rajiv Asati, Carlos Pignataro, 6-Dec-11, Multi-Protocol Label Switching (MPLS) Label Switched Path (LSP) Ping and Traceroute mechanisms are commonly used to detect and isolate data plane failures in all MPLS LSPs including Pseudowire (PW) LSPs. The PW LSP Ping and Traceroute elements, however, are not specified for IPv6 address usage. This document extends the PW LSP Ping and Traceroute mechanisms so they can be used with IPv6 PWs, and updates RFC 4379. "Security Labels in Internet Email", Alexey Melnikov, Kurt Zeilenga, 2-Sep-11, This document describes a header field, SIO-Label, for use in Internet Mail to convey the sensitivity of the message. The SIO- Label header field which may carry a textual representation (a display marking) and/or a structural representation (a security label) of the sensitivity of the message. "Path Computation Element (PCE) Communication Protocol (PCEP) TCP port number changes", Vishwas Manral, 17-Oct-11, Path Computation Element (PCE) Communication Protocol (PCEP) defined in [RFC 5440] states that "All PCEP messages MUST be sent using the registered TCP port for the source and destination TCP port." This has however lead to a lot of restrictions for the implementation. With these considerations in mind this document updates the TCP behavior. "SDP Grouping for Single RTP Sessions", Harald Alvestrand, 28-Sep-11, This document describes an extension to the Session Description Protocol (SDP) to describe RTP sessions where media of multiple top level types, for example audio and video, are carried in the same RTP session. This document is presented to the RTCWEB, AVTCORE and MMUSIC WGs for consideration. "The Port Control Protocol in Dual-Stack Lite environments", Francis Dupont, Tina Tsou, Jacni Qin, 30-Oct-11, This document specifies the so-called "plain mode" for the use of the Port Control Protocol (PCP) in Dual-Stack Lite (DS-Lite) environments. "An Extension Language for the DNS", John Levine, 15-Nov-11, Adding new RRTYPEs to the DNS requires that DNS servers and provisioning software be upgraded to support each new RRTYPE in Master files. This document defines a DNS extension language intended to allow most new RRTYPEs to be supported by adding a line to a configuration file read by the DNS software, with no changed software. "The Continue Header Field for the Session Initiation Protocol (SIP)", Amardeep Sinha, Subhrajyoti De, Sunil Sinha, 3-Oct-11, Before placing a call, it is quite often useful for the Caller to know whether a Callee is in favourable state to receive a call or not. This document defines an optional tag "continue" and a header "Continue" to address the purpose. The "Continue" header field is to confirm the session continuity with the Callee from the Caller after an option for session continuity is placed by the Callee based on the unfavorable state of the Callee. This functionality is needed to resolve the unwillingness of the Callee to receive any call. An option is given to the Callee by the Service Provider or by the Handset Manufacturer or by the Carrier to establish this requirement. "IPv6 DAD Enhancements for handling Layer1 Loopbacks", Rajiv Asati, Eli Dart, 4-Oct-11, It is a common practice to install a (soft or hard) loopback on a circuit interface for various purposes (e.g. circuit turn-up test). However, this practice results in disabling IPv6 on an interface even after the loopback is removed, due to the way IPv6 duplicate address detection is performed. This document describes a mechanism to allow IPv6 to self-heal after such a loopback is placed & removed. "Support for Application IO Hints", Dean Hildebrand, Mike Eisler, Trond Myklebust, Sam Falkner, 11-Oct-11, This document proposes a new IO_ADVISE operation for NFSv4.2 that clients can use to communicate expected I/O behavior to the server. By communicating future I/O behavior such as whether a file will be accessed sequentially or randomly, and whether a file will or will not be accessed in the near future, servers can optimize future I/O requests for a file by, for example, prefetching or evicting data. This operation can be used to support the posix_fadvise function as well as other applications such as databases and video editors. "A Method for Sharing Record Protocol Keys with a Middlebox in TLS", Yoav Nir, 25-Sep-11, This document contains a straw man proposal for a method for sharing symmetric session keys between a TLS client and a middlebox, so that the middlebox can decrypt the TLS-protected traffic. This method is an alternative to the middlebox becoming a proxy. "Prefix Delegation in 4V6", Gang Chen, Tao Sun, Hui Deng, 26-Aug-11, This draft presents the investigation of 4via6 in the scenario where IPv6 prefix delegation is deployed. A practicable application scenarios with IPv6 prefix delegation have been introduced in the mobile network environments. The applicability of 4via6 mechnism has been analyzed in term of mapping rules and 4via6 address structure. Targeting to alignment with existing 4via6 mapping algorithm and RFC6052 recommendation, an alternative 4via6 address structure have been proposed to be capable of assigning flexible address/port set to 4via6 domains. "IW10 Considered Harmful", Jim Gettys, 26-Aug-11, The proposed change to the initial window to 10 indraft-ietf-tcpm- initcwnd must be considered deeply harmful; not because it is the proposed change is evil taken in isolation, but that other changes in web browsers and web sites that have occurred over the last decade, it makes the problem of transient congestion at a user's broadband connection two and a half times worse. This result has been hidden by the already widespread bufferbloat present in broadband connections. Packet loss in isolation is no longer a useful metric of a path's quality. The very drive to improve latency of web page rendering is already destroying other low latency applications, such as VOIP and gaming, and will prevent reliable rich web real time web applications such as those contemplated by the IETF rtcweb working group. "Spam reporting using IMAP: SREP", Zoltan Ordogh, 26-Aug-11, The Internet Message Access Protocol [IMAP4] does not support reporting spam on its own. There are a number of solutions available based on the multipart/report content type defined in [REPORT]. However, these solutions require including the message contents and hence, consume bandwidth to transmit the entire message. In bandwidth-constrained environments - such as mobile networks - it is highly desirable to send only a minimum set of information - a reference - instead of the entire message. Furthermore, it is desirable to permit individual server implementations to handle spam in any way these systems choose to: do nothing, flag, recommend deletion or relocation, perform deletion or relocation, and, involve any choice of spam aggregator services in the decision process, such as [OMA-SPAMREP]. Solutions that exist today employ manipulating proprietary flags in the IMAP storage to achieve the bare minimum, however more advanced solutions cannot be developed by using flags only; the IMAP server needs to be involved actively in the spam reporting process. This document specifies the syntax of the SREP command, which allows a client to inform the server that the user considered a message (or parts thereof) spam, or, that the user no longer considers a message (or parts thereof) spam. Since all information about the message is readily available on the server, the command also allows the server to implement a more intelligent and accurate decision logic, which may be invoked when the spam is reported and the server can respond with its decision to the client. Additionally, this document contains example flows, illustrating various decisions that the server may choose to evaluate, including invoking a service based on [OMA-SPAMREP]. This document focuses only on the client-server interactions and the scope is limited to messages that either exist on the IMAP server, or, exist elsewhere and the IMAP server is configured to access them. Consequently, deposit-time filtering, messages that have been deleted, or, exist in an external storage but are accessible via an access protocol unknown to the IMAP server are out of scope. "VXLAN: A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", T. Sridhar, Mike Bursell, Lawrence Kreeger, Dinesh Dutt, Chris Wright, Mallik Mahalingam, Kenneth Duda, Puneet Agarwal, 24-Feb-12, This document describes Virtual eXtensible Local Area Network (VXLAN), which is used to address the need for overlay networks within virtualized data centers accommodating multiple tenants. The scheme and the related protocols can be used in cloud service provider and enterprise data center networks. "OAM tool for RBridges: Multi-destination Ping", David Bond, Vishwas Manral, Hao Weiguo, Li Yizhou, 31-Oct-11, Unicast and multi-destination data frame may follow the different path in TRILL network. We need the ping and traceroute like applications for the connectivity testing and fault isolation on the multi-destination path in addition to the unicast path. This document specifies the format and handling of the new TRILL OAM protocol messages and TLVs which can be used for the multi-destination OAM. "NFSv4.0 migration: Implementation experience and spec issues to resolve", Bill Baker, Charles Lever, David Noveck, Piyush Shivam, 16-Jan-12, The migration feature of NFSv4 provides for moving responsibility for a single filesystem from one server to another, without disruption to clients. Recent implementation experience has shown problems in the existing specification for this feature. This document discusses the issues which have arisen and explores the options available for curing the issues via clarification and correction of the NFSv4.0 specification. "Graceful Restart Mechanism for BGP", Srihari Ramachandra, Enke Chen, Rex Fernando, John Scudder, Yakov Rekhter, 29-Aug-11, This document describes a mechanism for BGP that would help minimize the negative effects on routing caused by BGP restart. An End-of-RIB marker is specified and can be used to convey routing convergence information. A new BGP capability, termed "Graceful Restart Capability", is defined that would allow a BGP speaker to express its ability to preserve its forwarding state during BGP restart, as well as to convey its intention of generating the End-of-RIB marker upon the completion of its initial routing update. Finally, procedures are outlined for temporarily retaining routing information across a TCP session termination/re-establishment. The mechanisms described in this document are applicable to all routers, both those with the ability to preserve the forwarding state during BGP restart and those without (although the latter need to implement only a subset of the mechanisms described in this document). "Conformance Terms to Indicate Requirement Levels", Peter Saint-Andre, 29-Aug-11, In many protocol specifications and related documents, special conformance terms (e.g., the uppercase words "MUST", "SHOULD", and "MAY") are often used to signify requirement levels. This document defines these conformance terms and describes how they are to be interpreted in documents produced within the Internet Standards Process. If approved, this document obsoletes RFC 2119 and changes its status to Historic. "A Uniform Resource Name (URN) Formal Namespace for the Local Government ICT Platform Project in Japan", Kazuaki Ohara, 31-Aug-11, This document describes the Namespace Idendifier (NID) 'applic' for Uniform Resource Name (URN) which is used to identify resources released by the Association for Promotion of Public Local Information and Communication (APPLIC). APPLIC publishes and manages specifications that define unique and persistent resources which make use of the namespace. (APPLIC is a nonprofit organization which consists of local governments, private companies and academic experts in Japan.) "OSPFv3-based Intra-Domain Source-Address Validation Implementation", Tao Zijin, 14-Nov-11, This memo describes SAVO SAVI, a source address validation mechanism for IPv6 networks based on the OSPFv3 protocol within Intra-Domain field. The proposed mechanism is intended to complement ingress filtering techniques to provide a higher granularity on the control of the forged source addresses and it can deal with the asymmetric routing for which the common uRPF scheme ([RFC2827]) may fail. The proposed SAVO mechanism does not need any additional communication between the routers in which the SAVO mechanism has been implemented and deployed. It can be incrementally deployed by the network manager and when it is only partially deployed it still helps to restrict the effect of the source address forging. It provides proactive incentives for the users who deploy it for they will be able to filter the packets with forged source address to a certain range, especially when the forged addresses are in the range of OSPF route prefixes. "The Nihao Discovery Protocol", Aidan Follestad, 1-Sep-11, The Nihao Protocol is an open source protocol that uses the Extensible Markup Language (XML), and simple UDP datagram exchange. It's designed for quick (and unencrypted by default) discovery and communication with other devices on a local network. This document will show you how the Nihao protocol works internally, allowing you to write wrapper libraries on the protocol and implement it in your own applications. "BGP prefix priority", Juan Alcaide, Fernando Calabria, 2-Sep-11, This document defines a set of extended communities to carry priority information. This information provides a mechanism for assigning a processing preference to the routes that carries it. It also provides a scheme for processing routes with strict priority order during update reception, best-path computation, and update transmission. "A URN Namespace for the Digital Entertainment Content Ecosystem", P. Davis, 2-Sep-11, This document describes a URN (Uniform Resource Name) namespace that is to be employed by the Digital Entertainment Content Ecosystem (DECE), LLC. for naming persistent resources published by DECE, including XMLSchemas, resource definitions, terms, and other structures. Management activities for these and other resource types, as well as their identifiers are provided by the DECE, LLC. "Session Initiation Protocol (SIP) Rate Control", Eric Noel, Philip Williams, 12-Dec-11, The prevalent use of Session Initiation Protocol (SIP) [RFC3261] in Next Generation Networks necessitates that SIP networks provide adequate control mechanisms to maintain transaction throughput by preventing congestion collapse during traffic overloads. Already [draft-ietf-soc-overload-control-05] proposes a loss-based solution to remedy known vulnerabilities of the [RFC3261] SIP 503 (service unavailable) overload control mechanism. This document proposes a rate-based control solution to complement the loss-based control defined in [draft-ietf-soc-overload-control-05]. "Abuse Reporting", Alessandro Vesely, 3-Sep-11, This documents covers issues of spam reporting by the general public. The Abuse Reporting Format (ARF) was originally developed for use by large operators. However, abuse reporting is also useful for medium and small operators. The need to automate abuse reporting originates from the volume of spam, not the size of the operators. "A Google Congestion Control Algorithm for Real-Time Communication on the World Wide Web", Henrik Lundin, Stefan Holmer, Harald Alvestrand, 29-Oct-11, This document describes two methods of congestion control when using real-time communications on the World Wide Web (RTCWEB); one sender- based and one receiver-based. It is published to aid the discussion on mandatory-to-implement flow control for RTCWEB applications; initial discussion is expected in the RTCWEB WG's mailing list. "Analysis of Port Indexing Algorithms", Nejc Skoberne, Wojciech Dec, 5-Sep-11, This document analyzes various algorithm proposals for building port sets. These algorithms are used to encode the range of ports in an IPv6 address and prefix in the context of stateless solutions. The ultimate goal of this analysis is to converge on one or a set of algorithms to be used by all stateless solutions. This is a companion document to [I-D.boucadair-softwire-stateless-rfc6052-update]. "DIS Modifications", Mukul Goyal, Nicolas Dejean, Dominique Barthel, Emmanuel Baccelli, Jerry Martocci, 5-Sep-11, This document specifies the DIS flags and options that allow an RPL node to control how neighbor RPL routers respond to its solicitiation for DIOs. "Definitions of Managed Objects for Network Address Translators (NAT)", Simon Perreault, Tina Tsou, 5-Sep-11, This memo defines a portion of the Management Information Base (MIB) for devices implementing Network Address Translator (NAT) function. This MIB module may be used for configuration as well as monitoring of a device capable of NAT function. This memo is a revision of the previous NAT-MIB [RFC4008] to take into account new types of NAT. "Auto-Configuration Extention in Virtual Aggregation", Li Cheng, Jun Wang, 6-Sep-11, Auto-Configuration in Virtual Aggregation as specified in [I-D.ietf-grow-va-auto] requires configuration of a "VP-range list" in ASBRs connected to transit and peer ISPs. These ASBRs simply tag some routes whose prefix falls within the VP-Range with a "can- suppress" tag to indicate whether these routes should be FIB installed. This draft specified an extended auto-configuration mechanism in Virtual Aggregation to support the configuration of both "VP-List" and "popular prefixes". Specifically, based on this mechanism, the ratio of lost packets when VP routes fail could be minimized. "Requirements for Extending IPv6 Addressing with Port Sets", Congxiao Bao, Mohammed Boucadair, Nejc Skoberne, Xing Li, 8-Sep-11, This document identifies a set of requirements to be taken into consideration in the design of stateless 4/6 solutions. In particular, these requirements cover the way IPv4-embedded IPv6 address and prefix are to be built when embedding the port information. A companion effort, documented at [I-D.bsd-softwire-stateless-port-index-analysis], is required to converge on one or a set of algorithms to be used by all stateless solutions. "Extensions to the Path Computation Element Communication Protocol (PCEP) to compute service aware Label Switched Path (LSP).", Dhruv Dhody, Vishwas Manral, 14-Dec-11, In certain networks like financial information network (stock/ commodity trading) and enterprises using cloud based applications, Latency (delay), Latency-Variation (jitter) and Packet loss is becoming a key requirement for path computation along with other constraints and metrics. Latency, Latency-Variation and Packet Loss is associated with the Service Level Agreement (SLA) between customers and service providers. [MPLS-DELAY-FWK] describes MPLS architecture to allow latency, loss and jittering as properties. [OSPF-TE-EXPRESS] and [ISIS-TE-EXPRESS] describes mechanisms with which network performance information is distributed via OSPF and ISIS respectivily. This document describes the extension to PCEP to carry Latency, Latency-Variation and Loss as constraints for end to end path computation. "Deployment Considerations for Dual-Stack Lite", Yiu Lee, Roberta Maglione, Carl Williams, Christian Jacquenet, 9-Sep-11, This document discusses the deployment issues and describes requirements for the deployment and operation of Dual-Stack Lite. This document describes the various deployment considerations and applicability of the Dual-Stack Lite architecture. "An Offset Indicating Option for IPv6", Brian Carpenter, Dacheng Zhang, Sheng Jiang, 16-Sep-11, This document defines an Offset Indicating option (OI option) encapsulated within an IPv6 Options header. An OI option can provide offset information to locate the end of the IPv6 header chain so that a node receiving an IPv6 packet is able to skip over the IP header chain and access the transport header or other protocol data unit directly. "CDN Interconnect Metadata", Ben Niven-Jenkins, David Ferguson, Grant Watson, 12-Sep-11, This document focuses on the CDNI Metadata interface, which enables the CDNI Metadata function in a Downstream CDN to obtain CDNI Metadata from an Upstream CDN so that the Downstream CDN can properly process and respond to Redirection Requests received over the CDNI Request Routing protocol and Request Routing and Content Requests received directly from User Agents. "A Novel Emergency Command and Dispatch Communication System Based on Geographic Information", Western Limited, 13-Sep-11, This document describes a novel Emergency Command and Dispatch Communication System (ECDCS), which is designed based on Geographic Information System (GIS). To begin with, some related intelligent notions are overviewed and the scheduling system is proposed. Then, the architecture of wisdom network is proposed. Finally, Function of each part of system is also discussed. "Multiplexing Negotiation Using Session Description Protocol (SDP) Port Numbers", Christer Holmberg, 14-Sep-11, This document defines how to use the Session Description Protocol (SDP) in order to negotiate the usage of multiplexed media. "Service-Oriented Mechanism for Fault Detection and Localization", Li Yiwei, Zhao Jihong, Wang Li, 14-Sep-11, This document describes a Service-Oriented Mechanism for Fault Detection and Localization (SOMFDL). This mechanism brings up the concepts of "Chord supplementary" and "QoS Trigger". By monitoring the real-time QoS level of the forward path, network can launch the mechanism when the QoS level cannot satisfy the requirement of service transmission, so that fault detection and localization can be realized. By designing related protocols, the manipuility of this mechanism can be guaranteed. Utilizing this mechanism, network can accomplish fault detection and localization in a time scale of milliseconds with a few datagram sent. "NVGRE: Network Virtualization using Generic Routing Encapsulation", Murari Sridhavan, Kenneth Duda, Ilango Ganga, Albert Greenberg, Geng Lin, Mark Pearson, Patricia Thaler, Chait Tumuluri, Yu-Shun Wang, 14-Sep-11, We describe a framework for policy-based, software controlled network virtualization to support multitenancy in public and private clouds using Generic Routing Encapsulation (GRE). The framework outlined in this document can be used by cloud hosters, enterprise data centers and enables seamless migration of workloads between public and private clouds. This document is focused on the data plane aspects of the NVGRE framework. "GRC Report Exchange", Kathleen Moriarty, Said Tabet, 7-Oct-11, Governance, risk, and compliance (GRC) programs provide oversight (governance) of risks and compliance initiatives within an organization. GRC reports are increasingly provided in an XML format. This specification defines a common method to securely transport GRC and other XML reports. The defined messaging capability provides policy options and markings in an XML schema, options for confidentiality at the document/report level, and security for the end-to-end communication. XML reports may be shared between service providers and clients, enterprises, or within enterprises. Reports may also be exchanged for official purposes such as business report filings, compliance report filings, and the handling of legal incidents (eWarrant, eDiscovery, etc.) This work is a generalized format derived from the secure exchange of incident information defined by RFC6045-bis, Real-time Inter-network Defense (RID). "The ARIA Cipher Algorithm and Its Use with IPsec", Woo-Hwan Kim, Jungkeun Lee, Je-Hong Park, Daesung Kwon, 15-Sep-11, This document describes the use of the ARIA block cipher algorithm in conjunction with several different modes of operation within IKE and IPsec. It describes the use of ARIA in CBC, CTR, GCM and CCM modes to encrypt and/or authenticate IKE and ESP traffic. It also describes the use of ARIA in XCBC, CMAC, and GMAC modes to authenticate IKE, ESP and AH traffic. The use of ARIA in XCBC and CMAC modes for pseudorandom functions is also included. "BFD Generic Cryptographic Authentication", Manav Bhatia, Vishwas Manral, Dacheng Zhang, 16-Sep-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. "RSVP-TE Extensions to Exchange MPLS-TP LSP Identifiers", Fei Zhang, 13-Nov-11, The MPLS Transport Profile (MPLS-TP) identifiers document [RFC6370] specifies a initial set of identifiers, such as local assigned tunnel number and Global_ID, which can be used to form Maintenance Entity Point Identifier (MEP_ID). As to some Operation, Administration and Maintenance (OAM) functions, such as Connectivity Verification (CV) [I-D.ietf-mpls-tp-cc-cv-rdi], source MEP_ID must be inserted in the OAM packets, so that the peer endpoint can compare the received and expected MEP_IDs to judge whether there is a mismatch [RFC6371], which means that the two MEP nodes need to pre-store each other's MEP_IDs. This document defines the signaling extensions to exchange the Label Switched Path (LSP) identifiers. "Registration of vCard VERSION Property Values", Mykyta Yevstifeyev, 17-Sep-11, This document registers the existing vCard VERSION property values with IANA and contains some provisions on its generic syntax and use. "Moving A6 to Historic Status", Sheng Jiang, David Conrad, Brian Carpenter, 19-Sep-11, This document provides a summary of issues and discusses the current usage status of A6 DNS records and moves the A6 specifications to Historic status, providing clarity to implementers and operators. "Specification of the IP Flow Information eXport (IPFIX) Protocol for the Exchange of IP Traffic Flow Information", Benoit Claise, 26-Oct-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. "Component and Composite Link Membership in IS-IS", Les Ginsberg, Eric Osborne, 20-Sep-11, This document defines the means for IS-IS to advertise TE attributes of component links and their relationship to the composite link of which they are a member. "The Pseudowire (PW) & Virtual Circuit Connectivity Verification (VCCV) Implementation Survey Results", Nick Regno, 20-Sep-11, Most Pseudowire Emulation Edge-to-Edge (PWE3) encapsulations mandate the use of the Control Word (CW) in order to better emulate the services for which the encapsulations have been defined. However, some encapulations treat the Control Word as optional. As a result, implementations of the CW, for encapsulations for which it is optional, vary by equipment manufacturer, equipment model and service provider network. Similarly, Virtual Circuit Connectivity Verification (VCCV) supports three Control Channel (CC) types and multiple Connectivity Verification (CV) Types. This flexibility has led to reports of interoperability issues within deployed networks and associated drafts to attempt to remedy the situation. This survey of the PW/VCCV user community was conducted to determine implementation trends. The survey and results is presented herein. "Security option extension for DHCPv4", Emily Bi, Serge Manning, Marcus Wong, 21-Sep-11, This document defines a new option that can be used by DHCP servers to exchange with DHCP clients specific security configuration information. This new option defines a standard parameter format and code so that there will be no ambiguity in interoperating the information being exchanged and that there will be no issues related to interoperability. It is an option definition extension for DHCPv4 which should be included in [RFC 2132]. "Guidelines for Extensions to IODEF for Managed Incident Lightweight Exchange", Katherine Goodier, Damir Rajnovic, 21-Sep-11, This document provides extensions to Managed Incident Lightweight Exchange (MILE). MILE describes a subset of Incident Object Description Exchange Format (IODEF) defined in RFC 5070. The Data Markers extension is aimed at exchanging data tags or markers that label categories of information that have significance in the exchange of incident information. These data marker extension is aimed at exchanging data tags or markers that label information exchanged during incident handling. Data markers include sensitivity and data handling requirements that can prevent possible criminal errors in mismarking data. Both network and information security incidents typically result in the loss of service, data, and resources both human and system. Existing extensions to the IODEF- Document Class for Reporting Phishing [RFC 5901] have already been introduced for network security incidents. Data markers introduce extensions for information security incidents so that network providers and Computer Security Incident Response Teams (CSIRT) are equipped and ready to assist in communicating and tracing security incidents with tools and procedures in place before the occurrence of an attack. Data Markers also support Real-time Inter-network Defense (RID) [RFC 6045] that 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. "North-Bound Distribution of Link-State and TE Information using BGP", Hannes Gredler, Jan Medved, Adrian Farrel, Stefano Previdi, 21-Sep-11, In a number of environments, a component external to a network is called upon to perform computations based on the network topology and current state of the connections within the network, including traffic engineering information. This is information typically distributed by IGP routing protocols within the network This document describes a mechanism by which links state and traffic engineering information can be collected from networks and shared with external components using the BGP routing protocol. This is achieved using a new BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism is applicable to physical and virtual links. The mechanism described is subject to policy control. Applications of this technique include Application Layer Traffic Optimization (ALTO) servers, and Path Computation Elements (PCEs). "SA46T Multicast Support", Naoki Matsuhira, 21-Sep-11, This document describe Stateless Automatic IPv4 over IPv6 Tunneling (SA46T) multicast support. IPv4 multicast is supported by SA46T with same manner with IPv4 unicast. SA46T multicast address prefix is defined. "A Uniform RESTful URL Query Pattern for RIRs", Andrew Newton, Kaveh Ranjbar, Arturo Servin, 21-Sep-11, This document describes uniform patterns for which to construct HTTP URLs that may be used to retreive information from Regional Internet Registries (RIRs) using "RESTful" web access patterns. "Analysis of Stateless Solutions for IPv4 Service across IPv6 Networks - A synthetic Analysis Tool", Remi Despres, 22-Sep-11, This document proposes a discussion tool for the Softwire interim meeting of 2011/09/26-27. Its contains tables in which the most significant and differentiating functional features of different solutions are identified. "An architecture to support explicit rate signaling over End-to-End paths", Dino Pacheco, Emmanuel Lochin, Arjuna Sathiaseelan, 23-Sep-11, This memo introduces an architecture, called IP-ERN, which allows Explicit Rate Notification (ERN) protocols to be inter-operable with current IP-based networks. IP-ERN is based on the execution of both End-to-End (E2E) and ERN protocols at the end hosts. The resulting E2E-ERN protocol provides inter and intra protocol fairness and benefits from all ERN advantages when possible. We detail the principle of this novel architecture, which is compliant with every TCP feature, as well as IP-in-IP tunneling solutions. In particular, IP-ERN is an alternative to splitting Performance Enhancement Proxies. "Implementing A+P in the provider's IPv6-only network", Xiaohong Deng, Yiu Lee, Tao Zheng, Xiaohong Huang, Qin Zhao, Yan Ma, 31-Oct-11, This memo focuses on the IPv6 flavor of A+P. This memo describes an implementation of A+P in a provider's IPv6- only network. It provides details of the implementation, network elements, configurations and test results as well. Besides traditional port range A+P, a scattered port sets flavor of A+P is also implemented to verify feasibility of offering non-continuous port sets with A+P approach, and to investigate possibility and efforts of making UPnP 1.0 work with A+P. The test results consist of the application compatibility test, UPnP 1.0 extensions and UPnP 1.0 friendly port allocation for A+P, port usage and BitTorrent behaviors with A+P. This memo focuses on the IPv6 flavor of A+P. "Client Hardware Address Option in DHCPv6", Gaurav Halwasia, Cisco Systems, Wojciech Dec, 25-Sep-11, This document specifies the format and mechanism that is to be used for encoding client hardware address in DHCPv6 messages by defining a new DHCPv6 Client Hardware Address option. "Stateless 4over6 in access network", Qiong Sun, Chongfeng Xie, Yong Cui, Jianping Wu, Peng Wu, Cathy Zhou, Yiu Lee, 25-Sep-11, This document specifies a stateless 4over6 mechanism which moves the translation function from tunnel concentrator (AFTR) to initiators (B4s). It is used for service providers offering residual deployment of the IPv4 service across IPv6-only domains. The concentrator will record the full set of prefix mapping rules independent of the number of subscribers, while the initiator will only keep a single rule of its own sub-domain. The BNG devices can learn the rule set further, to achieve traffic optimization between initiators. In this way, it not only achieve scalability and simplicity feature benefits from stateless address mapping, but also keep CPE functions simple. Besides, flexible addressing and scattered IPv4 address blocks can be supported as well. Traffic optimization can be deployed incrementally when necessary. "Deterministic Address Mapping to Reduce Logging in Carrier Grade NAT Deployments", Chris Donley, Chris Grundemann, Vikas Sarawat, Karthik Sundaresan, 18-Jan-12, Many Carrier Grade NAT solutions require per-connection logging. Unfortunately, such logging is not scalable to many residential broadband services. This document suggests a way to manage Carrier Grade NAT translations in such a way as to significantly reduce the amount of logging required while providing traceability for abuse response. "TFRC-based Congestion Control for Saratoga", Wesley Eddy, Lloyd Wood, Will Ivancic, 26-Sep-11, This document specifies the use of TCP-Friendly Rate Control (TFRC) with the Saratoga data transfer protocol. The necessary conventions that a Saratoga sender and receiver implementation must follow if they wish to enable the use of TFRC are described. "TLS Extension For Indicating A Previously-Seen Server Certificate Chain", Florian Weimer, 26-Sep-11, This document describes a TLS extension which enables a TLS client to send to a TLS server a certificate chain which the client has previously received from the same server. Server operators are expected to use this information to detect use of fraudulent certificates on the Internet. "Congestion control for the Saratoga protocol", Wesley Eddy, Will Ivancic, Lloyd Wood, 26-Sep-11, Saratoga is a data transfer protocol designed to carry potentially large volumes of data over difficult network paths, often including only a single high-rate link and only one application flow. As the requirements for use vary across deployment environments, the base Saratoga specification only assumes that an implementation will be able to clock packets out at a configurable rate, and beyond this specifies no inherent or particular congestion-control behaviour. The design of Saratoga deliberately supports the integration of congestion-control algorithms without modification to the base protocol. This document describes how congestion control can be supported in the Saratoga transfer protocol. Saratoga is intended for use in private networks, where its use is engineered as a single flow to fill a link. However, as Saratoga is implemented over UDP, it can be multiplexed, and can be run across the public Internet, in which case congestion control in accordance with the UDP Guidelines becomes necessary. "The di (DIGEST) URI Scheme", Phillip Hallam-Baker, Rob Stradling, 4-Oct-11, A URI scheme for referencing static data abjects by means of a cryptographic digest mechanism is specified. The format is designed to resist content type substitution attacks and supports a choice of digest algorithms. "Update of and Clarification to IANA Policy Definitions in BCP 26", Barry Leiba, 26-Oct-11, Section 4.1 of BCP 26 (RFC 5226) discusses possible IANA registration policies that might be used in documents with IANA actions, and defines some well-known policy terms. This document clarifies the usage of these terms, and discourages the use of overly restrictive registration policies. "Representing DNS messages using XML", Mohan Parthasarathy, Paul Vixie, 27-Sep-11, This memo presents a technique for representing DNS messages using XML. This enables DNS query transactions to be transported over HTTP/HTTPS. "GRE Generic Associated Channel", Dan Frost, Prashant Srinivas, 27-Sep-11, RFC 5586 defines a Generic Associated Channel (G-ACh) mechanism for MPLS paths that enables multiplexing of auxiliary traffic over such paths along with the user traffic they carry. Such auxiliary traffic is commonly used for Operations, Administration, and Maintenance protocols that enable monitoring and management of the path. This document describes the applicability of the G-ACh mechanism to Generic Routing Encapsulation (GRE) tunnels. "DHCP Options for 3GPP Specific Information", Guoyan Liu, 28-Sep-11, This document defines a new option that can be used by DHCP clients to send to DHCP servers. This new option includes some sub-options. It also defines standard parameter format and code so that there will be no ambiguity in interoperating the information being exchanged. It may be used for scenarios interworking with non-3GPP and 3GPP network. "HO from 3GPP to a trusted non-3GPP access", Guoyan Liu, 28-Sep-11, This document defines a new option that can be used by DHCP clients to send to DHCP servers. This new option includes some sub-options. It also defines standard parameter format and code so that there will be no ambiguity in interoperating the information being exchanged. It may be used for scenarios interworking with non-3GPP and 3GPP network. "Infrastructure Overlay", Marc Petit-Huguenin, 16-Jan-12, This document provides requirements for infrastructure overlays, a special kind of peer-to-peer overlay whose main purpose would be defeated if more than one instance would exist on the Internet. "Mesh Link Establishment", Richard Kelsey, 29-Sep-11, This document defines the mesh link establishment (MLE) protocol for establishing and configuring links in an ad hoc mesh radio network. Effective mesh networking using radio links requires identifying, configuring, and securing usable links to neighboring devices. In an ad hoc mesh network a device's neighbors may come and go as the network's membership and physical environment change. Newly usable links need to be identified and configured automatically, where configuration values can include link-layer addresses, transmit and receive modes, security parameters, and so forth. MLE includes the option of securing the configuration messages themselves, as link- layer security may not be available prior to configuration. "Using DNS SRV RRs with URLs", Masataka Ohta, 29-Sep-11, DNS SRV RRs of a domain implicitly specify servers and port numbers corresponding to the domain. By combining URLs and SRV RRs, no port numbers have to be specified explicitly in URLs, even if non-default port numbers are used, which makes URLs more concise for port based virtual and real hosting, where port based real hosting means that multiple servers sharing an IP address are distinguished by port numbers to give service for different URLs, which is the case for port forwarded servers behind NAT and servers with realm specific IP. "Software Driven Networks Problem Statement", Thomas Nadeau, Ping Pan, 31-Oct-11, Software Driven Networks (SDN) is an approach to networks that enables applications to converse with and manipulate the control software of network devices and resources. SDNs are comprised of applications, control software, and interfaces to services that are hosted in an overlay or logical/virtual network as well as those possibly same components that comprise the underlying physical network. Modern applications require the ability to easily interact and manipulate these resources. Applications can benefit from knowing the available resources and from requesting that the network makes the resources available in specific ways. To this end, there is a requirement to couple applications more closely to the underlying resources on which they depend, consume and interact with. SDN infrastructure and components exist in most deployed networks today. Some of these components are being standardized by various organizations, as as well some being already standardized by the IETF. However, no standards or open specifications currently exist to facilitate end-to-end operation of a software defined network, specificlly one that provides open APIs for applications to control the network services and functions offered by device control planes or other "controlling" software. The goal of this document is to outline the problem area of SDN for the IETF. "Problem Statement: Overlays for Network Virtualization", Thomas Narten, Murari Sridhavan, Dinesh Dutt, David Black, Lawrence Kreeger, 31-Oct-11, This document describes issues associated with providing multi- tenancy in large data center networks and an overlay-based network virtualization approach to addressing them. A key multi-tenancy requirement is traffic isolation, so that a tenant's traffic is not visible to any other tenant. This isolation can be achieved by assigning one or more virtual networks to each tenant such that traffic within a virtual network is isolated from traffic in other virtual networks. The primary functionality required is provisioning virtual networks, associating a virtual machine's NIC with the appropriate virtual network, and maintaining that association as the virtual machine is activated, migrated and/or deactivated. Use of an overlay-based approach enables scalable deployment on large network infrastructures. "The MessageBroker WebSocket Subprotocol", Mark Hapner, Clebert Suconic, 1-Oct-11, The WebSocket protocol [I-D.ietf-hybi-thewebsocketprotocol] provides a subprotocol extension facility. The MessageBroker WebSocket Subprotocol (MBWS) is a WebSocket Subprotocol used by messaging clients to send messages to, and receive messages from an internet message broker (herein called a message broker). A message broker is a messaging intermediary that queues messages sent by its clients for asynchronous delivery to its clients. Messages are addressed to message-broker-specific address names. Clients send messages to addresses and consume messages from addresses. Clients do not send messages directly to other clients. Message brokers provide a range of functionality that is outside the scope of MBWS. Typically an internet message broker provides a REST API for working with this functionality; such as configuring client credentials; setting client access controls; configuring address routing; etc. MBWS limits its scope to the definition of a WebSocket subprotocol that provides a full duplex, reliable message transport protocol between message brokers and their clients; and, between message brokers. Since reliable message transport is often independent of a broker's particular features, MBWS can be used as the message transport protocol for a wide range of message brokers. MBWS utilizes two elements of WebSocket extensibility - opcodes and extension data. "RPL applicability in industrial networks", Tom Phinney, Pascal Thubert, Robert Assimiti, 1-Oct-11, The wide deployment of wireless devices, with their low installed cost (compared to wired devices), will significantly improve the productivity and safety of industrial plants, while simultaneously increasing the efficiency and safety of the plant's workers, by extending and making more timely the information set available about plant operations. The new Routing Protocol for Low Power and Lossy Networks (RPL) defines a Distance Vector protocol that is designed for such networks. The aim of this document is to analyze the applicability of that routing protocol in industrial LLNs of field devices. "RPL applicability in industrial networks", Tom Phinney, Pascal Thubert, Robert Assimiti, 1-Oct-11, The wide deployment of wireless devices, with their low installed cost (compared to wired devices), will significantly improve the productivity and safety of industrial plants, while simultaneously increasing the efficiency and safety of the plant's workers, by extending and making more timely the information set available about plant operations. The new Routing Protocol for Low Power and Lossy Networks (RPL) defines a Distance Vector protocol that is designed for such networks. The aim of this document is to analyze the applicability of that routing protocol in industrial LLNs of field devices. "Lightweight Directory Access Protocol (LDAP): Schema for Printer Services", Pat Fleming, Ira McDonald, 2-Oct-11, This document defines a schema, object classes and attributes, for printers and printer services, for use with directories that support Lightweight Directory Access Protocol (RFC 4510). This document is based on the printer attributes listed in Appendix E of Internet Printing Protocol/1.1 (IPP) (RFC 2911). A few additional printer attributes are based on definitions in the Printer MIB (RFC 1759), IEEE-ISTO PWG Command Set for IEEE 1284 Device ID (PWG 5107.2), or IEEE-ISTO PWG IPP Job and Printer Extensions - Set 3 (IPP JPS3). "RFC3627 to Historic status", Wesley George, 10-Oct-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. "Framework for Software Defined Networks", Thomas Nadeau, Ping Pan, 31-Oct-11, This document presents a framework for Software Defined Networks (SDN). The purpose of the framework is to provide an overall picture of the problem space of SDN and to describe the relationships among the various components necessary to manipulate the components that comprise SDNs. SDN requires the specification of several key components including an "orchestrator" and various "plug-ins" between the orchestrator function and network resources. In addition to this, an orchestrator will require interconnection with standard policy bases, as well as other orchestrators in distributed environments or insofar as to support high-availability and fault-tolerance capabilities. To this end, several interfaces and mechanisms to address issues such as enabling the orchestrator to manipulate and interact with the control planes of devices such as routers and switches, as well as a discourse between different orchestrators will be described. The intent of this document is to outline what each interface needs to accomplish, and to describe how these interfaces and mechanisms fit together, while leaving their detailed specification to other documents. "Software-Defined Network (SDN) Problem Statement and Use Cases for Data Center Applications", Ping Pan, Thomas Nadeau, 31-Oct-11, Service providers and enterprises are increasingly offering services and applications from data centers. Subsequently, data centers originate significant amount of network traffic. Without proper network provisioning, user applications and services are subject to congestion and delay. In this document, we argue the necessity in providing network information to the applications, and thereby enabling the applications to directly provision network edge devices and relevant applications. "RTCWeb standard signaling protocol", Parthasarathi Ravindran, 3-Oct-11, The standardization of Real time communication between browsers is to provide the infrastructure for audio, video, text communication using standard interface so that interoperable communication can be established between any compatible browsers. RTCWeb specific Javascript API will be provided by browsers for developing real-time web application. It is possible to develop signaling protocol like Session Initiation Protocol (SIP) or Jingle or websocket extension or custom-made signaling protocol in Javascript. There are lots of issues in Javascript based signaling protocol. This document list the need for standard signaling protocol between RTCWeb client (browser) and RTCWeb server and possible signaling protocol for the same. "States Migration Use Case", Jingtao Yang, Chen Li, Huiyang Xu, 3-Oct-11, Draft I-D.gu-opsawg-policies-migration makes general problem statement on state migration in Data Center (DC). This use case draft is composed to introduce the states on network devices that need to be migrated with VM and the scenario that requires states migration. The authors of this draft make a survey among several DC providers to make sure the use cases introduced in this draft are real problem from these DC providers' perspective, instead of technology driven. The purpose of this draft is to figure out which states should be considered in the beginning stage of state migration effort. "IPv6 Prefix Assignment in Small Networks", Fred Baker, Ralph Droms, 4-Oct-11, It is necessary to allocate prefixes in small networks, which include residential and Small Office/Home Office (SOHO) networks in a manner that minimizes or eliminates manual configuration. This note suggests an approach. Requirements "Multihoming with IPv6-to-IPv6 Network Prefix Translation (NPTv6)", Fred Baker, Margaret Wasserman, Gregory Miller, Warren Kumari, 11-Dec-11, This memo describes an architecture for sites that are homed to multiple upstream providers. The architecture described herein uses IPv6-to-IPv6 Network Prefix Translation (NPTv6) to achieve redundancy, transport-layer survivability, load sharing and address independence. This memo updates Section 2.4 of RFC 6296. "Simple Approach to Prefix Distribution in Basic Home Networks", Erik Nordmark, Samita Chakrabarti, Suresh Krishnan, Wassim Haddad, 29-Oct-11, Modern IPv4 home networks are often configured with multi-level of NATs and Residential gateways to separate islands of networks used for different purposes. With the introduction of IPv6 home networks we'd like to be able to maintain the same topological freedom as we have with IPv4 but without requiring any IPv6 NATs. This document specifies the topological restrictions for what we term Basic Home Networks and specifies how DHCPv6 Prefix Delegation can be used to autoconfigure IPv6 address prefixes in such networks. "Priority PPP MMultiplexing", Jimmy Vincent, Sanjeev Sharma, 4-Oct-11, PPP multiplexing is a technique to encapsulate and carry multiple subframes inside a single PPP superframe as defined in RFC3153. With the existing Muxing mechanism, the carrier superframes waits for certain time for the incoming frames to be multiplexed, but this wait period may have impact on the delay constrains for the subframes. On the other hand lesser wait period for superframes so as to reduce the delay means lesser multiplexing efficiency. This document describe a method to achive maximum multiplexing efficiency for PPP Multiplexing over a link especially during low and medium traffic scenarios with out effecting the delay constraints required for different types of traffic over that link. With priority multiplexing technique delay for real time traffic during Multiplexing can be reduced, still assuring maximum Multiplexing efficiency "Verification Involving PSTN Reachability (VIPR) enabled SIP Intermediaries", Marc Petit-Huguenin, 4-Oct-11, This document presents some of the problems created by SIP intermediaries inside a VIPR federation. "Anti-DDoS Throttling of HTTP Requests by User-Agent", Joi Sigurdsson, 4-Oct-11, Describes a throttling mechanism User-Agents can implement that limits the ability of websites and browser extensions to perpetrate a DDoS (Distributed Denial of Service) attack. "IODEF Extension to Support Mail Abuse Reporting", Alessandro Vesely, 4-Oct-11, This document extends the Incident Object Description Exchange Format (IODEF) to allow mail-abuse reports to be shared as Incidents in the IODEF framework. "Media Type Registration for Common Alerting Protocol", Richard Barnes, Brian Rosen, Hannes Tschofenig, 7-Oct-11, This document registers the media type "application/cap+xml" for Common Alerting Protocol (CAP) format . "Encoding of Secure Common Alert Protocol Entities (ESCAPE)", Richard Barnes, 5-Oct-11, Recipients of emergency alerts need to be able to verify that an alert they receive was issued by an authorized source. The Common Alerting Protocol (CAP) provides a standard way of encoding alert information, but does not provide any security features that would support authentication of alert originators. This document describes a security wrapper for Common Alerting Protocol objects to allow alerts to be signed by alert originators. Please send feedback to the atoca@ietf.org mailing list. "Secure Password Ciphersuites for Transport Layer Security (TLS)", Dan Harkins, Dave Halasz, 31-Oct-11, This memo defines several new ciphersuites for the Transport Layer Security (TLS) protocol to support certificate-less, secure authentication using only a simple, low-entropy, password. The ciphersuites are all based on an authentication and key exchange protocol that is resistant to off-line dictionary attack. "Avoidance of Security Issues in SIP and Internet", Samir Srivastava, 5-Oct-11, This memo lists the security issues not addressed by SIPS and other drafts in progress. It provides two solutions to it. First solution calls for fixing issues one by one. The second solution avoids the security issues altogether. It has potential to obviate the need of 'Security Consideration' section from IETF documents. It requires wider acceptance from the community. Author is requesting IETF community to voice it's opinion and share the second solution with non-IETF members also to have their opinion. "IANA Allocated DNS RRtype Codes Without Documentation", Edward Lewis, 13-Oct-11, In the IANA registry of Resource Record (RR) TYPEs, as of October 1, 2011, there are 10 type code values allocated with references that are individual email boxes and not stable documents. Some of the registrations represent works in progress and such a reference is viable. Some registrations are dormant or dead efforts. In all cases it would be helpful to have some reference to material describing the type. "End-system support for BGP-signaled IP/VPNs.", Pedro Marques, Luyuan Fang, Ping Pan, Amit Shukla, 14-Dec-11, Network Service Providers often use BGP/MPLS IP VPNs [RFC4364] as the control plane for overlay networks. That solution has proven to scale to large number of VPNs and attachment points and is one familiar to network equipment software. There is a significant interest in the industry in building overlay networks in which end-systems are themselves the direct participant, along with network equipment such as service appliances. This document proposes an extension of the BGP IP VPN model to serve as the signaling protocol for host-based overlay networks along with an XMPP interface that provides a bridge between the software concepts familiar to end-points and those familiar to network equipment. "Expressing SNMP SMI Textual Conventions in XML Schema Definition Language", Mark Ellison, Bob Natale, 7-Oct-11, This memo defines the IETF standard expression of Structure of Management Information (SMI) textual conventions in Extensible Markup Language (XML) Schema Definition (XSD) language. The primary objective of this memo is to enable the production of XML documents that are as faithful to the SMI as possible, using XSD as the validation mechanism. "Content Distribution Network Interconnection (CDNI) Metadata Interface", Kevin Ma, 31-Oct-11, Content publishers (CPs) often use multiple Content Delivery Networks (CDNs) to deliver content to consumers. Though existing interactions between CPs and individual CDNs are beyond the scope of CDN interconnection (CDNI), it is important to understand the management capabilities and features available with existing non-interconnected multi-CDN deployments. Before migrating to CDNI, CPs must first assess the suitability of CDNI as a replacement for their existing non-interconnected multi-CDN deployments. CDN feature configuration and capability advertisement and enforcement is likely to occur through the CDNI metadata interface (MI). This document describes an approach to implementing the CDNI MI through the use of an extensible metadata model and a light-weight HTTP-based API. "LDP Bindings Refresh", Andre Pelletier, Kamran Raza, 7-Oct-11, There are situations when there is a need for performing consistency checks for LDP binding state (address/label bindings) exchanged between LDP speakers. For instance, a state refresh may be required to detect and purge stale bindings received by an LDP speaker, which have resulted from an in-service software upgrade. This document specifies mechanics that allow a sender LDP speaker to enclose the initial binding advertisements (or re-advertisements) between explicit START and END of binding markers, thus helping the receiving LDP speaker to detect and purge any extra/stale binding state previously learnt from the sender. In addition to the definition of new LDP Notification message status codes for bindings refresh, this document also extends LDP base specification by introducing the concept of "Wildcard Address" and a new "Wildcard Address Request" message. "Multipoint Label Distribution Protocol In-Band Signaling in a VPN Context", IJsbrand Wijnands, Nicolai Leymann, Paul Hitchen, Wim Henderickx, 7-Oct-11, Sometimes an IP multicast distribution tree (MDT) traverses both MPLS-enabled and non-MPLS-enabled regions of a network. Typically the MDT begins and ends in non-MPLS regions, but travels through an MPLS region. In such cases, it can be useful to begin building the MDT as a pure IP MDT, then convert it to an MPLS Multipoint LSP (Label Switched Path) when it enters an MPLS-enabled region, and then convert it back to a pure IP MDT when it enters a non-MPLS-enabled region. [I-D.ietf-mpls-mldp-in-band-signaling] specifies the procedures for building such a hybrid MDT, using Protocol Independent Multicast (PIM) as the control protocol in the non-MPLS region of the network, and using Multipoint Extensions to Label Distribution Protocol (mLDP) in the MPLS region. This document extends those procedures so that they will work when the links between the MPLS and non-MPLS regions are [RFC4364] interfaces. While these procedures do not provide a good general multicast VPN solution, they are useful in certain specific situations. "SMTP in an IPv4/IPv6 dual stack Environment", S Moonesamy, 8-Oct-11, This memo discusses about SMTP in an IPv4/IPv6 dual stack environment. It documents the algorithm initially specified in RFC 3974 which is used in several SMTP implementations. "Authenticating BFD using HMAC-SHA-2 procedures", Dacheng Zhang, Manav Bhatia, Vishwas Manral, 9-Oct-11, 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. "Generalized Labels for the Flexi-Grid in Lambda-Switch-Capable (LSC) Label Switching Routers", Daniel King, Adrian Farrel, Yao Li, Fei Zhang, Ramon Casellas, 17-Oct-11, A new flexible wavelength grid ("flexi-grid") is being developed within the ITU-T Study Group 15 to allow selection and switching of individual lambdas chosen flexibly from a detailed, fine granularity grid of available wavelengths. This document updates the definition of GMPLS lambda labels to support the flexi-grid. This document updates RFC 3471 and updates RFC 6205. "Traffic classification, filtering and redirection for end-system IP VPNs.", Pedro Marques, Luyuan Fang, Ping Pan, Amit Shukla, 10-Oct-11, When IP VPNs are used to interconnect end-systems [I-D.marques-l3vpn-end-system] it may be desirable to introduce traffic control rules at a finer level of granularity than an IP destination address. This document extends the end-system IP VPN specification with support for fine grain traffic classification, filtering and redirection rules. It applies the existing BGP IP VPN flow specification dissemination mechanism [RFC5575] to end-system IP VPNs in order to provide the ability to control IP packets that match a specific pattern, which may include fields other than the IP destination address. "IS-IS Traffic Engineering (TE) Metric Extensions", Stefano Previdi, Spencer Giacalone, David Ward, John Drake, Alia Atlas, Clarence Filsfils, 10-Oct-11, In certain networks, such as, but not limited to, financial information networks (e.g. stock market data providers), network performance criteria (e.g. latency) are becoming as critical to data path selection as other metrics. This document describes extensions to IS-IS TE [RFC5305] such that network performance information can be distributed and collected in a scalable fashion. The information distributed using ISIS TE Express Path can then be used to make path selection decisions based on network performance. Note that this document only covers the mechanisms with which network performance information is distributed. The mechanisms for measuring network performance or acting on that information, once distributed, are outside the scope of this document. "Enhanced Duplicate Address Detection", Carlos Pignataro, Eli Dart, Hemant Singh, Rajiv Asati, Wes Beebee, Wesley George, 5-Jan-12, Appendix A of the IPv6 Duplicate Address Detection (DAD) document in RFC 4862 discusses Loopback Suppression and DAD. However, RFC 4862 does not settle on one specific automated means to detect loopback of Neighbor Discovery (ND of RFC 4861) messages used by DAD. Several service provider communities have expressed a need for automated detection of looped backed ND messages used by DAD. This document includes mitigation techniques and then outlines the Enhanced DAD algorithm to automate detection of looped back IPv6 ND messages used by DAD. For network loopback tests, the Enhanced DAD algorithm allows IPv6 to self-heal after a loopback is placed and removed. Further, for certain access networks the document automates resolving a specific duplicate address conflict. "New Performance Metrics Composition Framework for Multiparty Services", Tiziano Ionta, 11-Oct-11, One of the best chances for a Service Provider to face the complex growth of IP Services, and their challenging requirements/SLAs along the Core network, is to enrich the current Performance metrics - mainly derived from a "Network-Oriented point of view", and therefore a general perspective, not focused on specific services - with some more Performance factors, so to include a "Service-Oriented point of view", more centred on the particular kind of service, with its own characteristics in terms of protocol, application, manageability, and so on. Almost nothing about this new approach has been standardized yet for the core network. To achieve the above goal, and starting from the one-to-group performance metrics outlined in RFC 5644 [RFC5644], a new metrics composition/aggregation framework is proposed in this memo, where the main focus is on multiparty communications (e.g. video providers, online biding, online stock market, etc.). Finally this memo is tuned to RFC 6390 [RFC6390] in terms of scopes, framework concepts, and need to widen the current performance metrics depending on the application, service etc. "Remote LFA FRR", Stewart Bryant, Clarence Filsfils, Mike Shand, Ning So, 11-Oct-11, This draft describes an extension to the basic IP fast re-route mechanism described in RFC 5286 that provides additional backup connectivity when none can be provided by the basic mechanisms. "Requirements for GMPLS Control of Flexible Grids", Fatai Zhang, Oscar Dios, Ramon Casellas, Xiaobing Zi, 27-Oct-11, A new flexible grid of DWDM is being developed within the ITU-T Study Group 15 to allow more efficient spectrum allocation. This memo describes the requirements of GMPLS control of flexible grid DWDM networks. "Design Principles of a Unified Address Format for 4v6", Gang Chen, Zhen Cao, 12-Oct-11, There are heated discussion over the unified address format and mapping algorithm. In order to converge the solutions, it is desirable to discuss the requirements and principles for the design. This document tries to propose practical principles for 4v6 deployment. The requirements have been derived from this deployment consideration. Based on that, a unified address format has been proposed for easying 4v6 solution implementation . "IPv4 Residual Deployment via IPv6 - Unified Solution (4rd-U)", Remi Despres, 28-Jan-12, This document specifies an automatic tunneling mechanism tailored for residual deployment of public IPv4 via IPv6 networks (the reverse of 6rd whose purpose is rapid deployment of IPv6 via IPv4). In order to deal with the IPv4-address shortage, customers can be assigned shared IPv4 addresses with statically assigned restricted port sets. Operation is stateless, with neither per-connection nor per-customer state needed in network nodes. "Session Initiation Protocol (SIP) Extension for logging and debugging.", Adarsh Kaithal, 12-Oct-11, The current mechanisms to debug issues in SIP network are not very efficient. It requires to enable debugging logs across different devices, recreate the problem and then collect the logs. The idea is to provide a solution to automatically enable relevant logs (SIP messages and any other debugging logs meaningful to SIP devices), and also to indicate where the logs are to be collected or stored. The enabling of logs will happen at all the SIP devices(upstream or downstream). This will help to get the logs from all the SIP devices in a Common logging format (CLF). The solution extends SIP to provide the infrastructure to enable logging for upstream and downstream devices with each server deciding how much troubleshooting information it wants to log - with freedom to simply ignore requests if required. This document specifies a new header called "Log-Me" Header in all the SIP messages. "Using the IPv6 Flow Label for Server Load Balancing", Brian Carpenter, Sheng Jiang, Willy Tarreau, 17-Jan-12, This document describes how the IPv6 flow label can be used in support of layer 3/4 load distribution and balancing for large server farms. "Creating Large Scale Mesh VPNs Problem Statement", Yoav Nir, John Veizades, Chris Ulliott, Jorge Mendoza, 13-Oct-11, This document presents the problem of configuring a large number of IKE/IPsec systems in such a way that any two of them can use IPsec to protect the traffic between them. Manual configuration of all possible tunnels is too cumbersome in such cases, so an automated method is needed. "MN Status Option for Proxy Mobile IPv6", Chunhui Zhu, Yangwei Tu, 13-Oct-11, This document explains how the LMA obtains the MN status in order to decide and perform the flow mobility. "Request Routing Protocol for CDN Interconnection", Xiaoyan He, Spencer Dawkins, Jincheng Li, Ge Chen, 13-Oct-11, The Request Routing Protocol allows the Request Routing system in interconnected Content Delivery Network(CDNs) to communicate to ensure that an end user request can be (re)directed from an upstream CDN to a surrogate in the downstream CDN. This document describes the details of the protocol used to provide this mechanism. "Real-Time Web Communication Simplified Interconnection", Wolfgang Beck, 14-Oct-11, The Real-Time Communication Web (RTCWEB) approach uses browser-based scripts to minimize the number of network protocols between server and browser that need standardization. With traditional interconnection concepts, the success of this effort is limited as different RTCWEB applications still need to interoperate. This document proposes an alternative interconnection model where caller and callee always use the same RTCWEB client and server and avoid any interworking this way. "Protocol Independent Multicast DR Load Balancing", Yiqun Cai, Sri Vallepalli, Heidi Ou, Andy Green, 14-Oct-11, On a multi-access network such as an Ethernet, one of the PIM routers is elected as a Designated Routers (DR). The PIM DR has two roles in the PIM protocol. On the first hop network, the PIM DR is responsible for registering an active source to the RP if the group is operated in PIM SM. On the last hop network, the PIM DR is responsible for tracking local multicast listeners and forwarding traffic to these listeners if the group is operated in PIM SM/SSM/DM. In this document, we propose a modification to the PIM protocol that allows multiple of these last hop routers to be selected so that the forwarding load can be distributed to and handled among these routers. A router responsible for forwarding for a particular group is called a Group Designated Router (GDR). "Modem Link Properties Advertisement Protocol", Lloyd Wood, Rajiv Asati, Daniel Floreani, Dan Shell, 14-Oct-11, Nework devices and applications are increasingly connected to a variety of smart modems whose incoming and outgoing link rates can be varied over time to suit the channel characteristics. Such rate changes can result from use of adaptive coding and modulation. The link rate and conditions offered by the modem to connected devices therefore vary. In order for connected devices and applications to get the most out of the modem's link capacity, it is necessary for the applications and connected devices to condition traffic. Thus, they need some knowledge of the modem's link conditions. This document describes one simple method for a modem to advertise link rate and other characteristics, via UDP messages, and discusses alternative approaches to communicating this information. While the mechanism in this document is described in the context of a modem, it can also be broadly applied to other scenarios such as cryptographic devices. "A Taxonomy of Session Initiation Protocol (SIP) Back-to-Back User Agents", Hadriel Kaplan, 14-Oct-11, There are numerous types of SIP Back-to-Back User Agents (B2BUAs), performing different roles in different ways. This document identifies several common B2BUA roles, in order to provide taxonomy other documents can use and reference. "A Media-based Traceroute Function for the Session Initiation Protocol (SIP)", Hadriel Kaplan, 14-Oct-11, SIP already provides the ability to perform hop-by-hop traceroute for SIP messages using the Max-Forwards header field, in order to determine the reachability path of requests to a target. A new mechanism for media-loopback calls is also being defined separately, which enables test calls to be generated which result in media being looped back to the originator. This document is a strawman proposal for a means of performing hop-by-hop traceroute-style test calls using the media-loopback mechanism, in order to test the media path when SIP sessions go through media-relaying B2BUAs. "Problem Statement for Dynamic Secure Interconnect", Edward Wang, 14-Oct-11, This document examines the problems and challenges associated with the process of setting up secure interconnections between authorized network nodes. The network nodes can be located anywhere in a private or public network, directly connected or behind one or more levels of NAT [NAT]. Setting up a secure interconnection in this environment entails the resolution of various issues such as authentication, peer discovery, virtual network address management, and connection parameters determination. "Relay-Supplied DHCPv6 Precedence Options", Tirumaleswar Reddy, Prashanth Patil, Dan Wing, 14-Oct-11, Network configuration of hosts is currently relatively static with little consideration of dynamic network characteristics. The network infrastructure is aware of dynamic network characteristics. This specification extends DHCPv6 so that the DHCPv6 relay agent can influence a host's configuration. "Multiple RTP Session on a Single Lower-Layer Transport", Magnus Westerlund, Colin Perkins, 31-Oct-11, This document specifies how multiple RTP sessions are to be multiplexed on the same lower-layer transport, e.g. a UDP flow. It discusses various requirements that have been raised and their feasibility, which results in a solution with a certain applicability. A solution is recommended and that solution is provided in more detail, including signalling and examples. "RTCWeb Offer/Answer Protocol (ROAP)", Cullen Jennings, Jonathan Rosenberg, Randell Jesup, 30-Oct-11, This document describes an protocol used to negotiate media between browsers or other compatible devices. This protocol provides the state machinery needed to implement the offer/answer model (RFC 3264), and defines the semantics and necessary attributes of messages that must be exchanged. The protocol uses an abstract transport in that it does not actually define how these messages are exchanged. Rather, such exchanges are handled through web-based transports like HTTP or WebSockets. The protocol focuses solely on media negotiation and does not handle call control, call processing, or other functions. "Securing Header Fields with S/MIME", Laurent Cailleux, 16-Oct-11, This document describes how the S/MIME protocol can be extended in order to secure message header fields. This technology provides security services such as data integrity, non-repudiation and confidentiality. This extension is referred to as 'Secure Headers'. "464XLAT: Combination of Stateful and Stateless Translation", Masataka Mawatari, Masanobu Kawashima, Cameron Byrne, 31-Oct-11, This document describes a method (464XLAT) for IPv4 connectivity across IPv6 network by combination of stateful translation and stateless translation. 464XLAT is a simple technique to provide IPv4 access service while avoiding encapsulation by using twice IPv4/IPv6 translation standardized in [RFC6145] and [RFC6146]. "RSVP-TE Signaling Extensions in support of Flexible Grid", Daniele Ceccarelli, Fatai Zhang, Oscar Dios, 16-Oct-11, This memo describes the signaling extensions of GMPLS control of flexible grid network. "UK Use Cases and Requirements", Andy Sago, Juan Zuniga, Michael Fitch, 16-Oct-11, This document proposes a simplification of the PAWS database discovery use case, two new use cases for indoor networking and machine to machine communications, and a set of requirements that drop out of all the use cases included so far in the working document. These use cases and requirements especially address the TV White Spaces needs in the United Kingdom, as currently known. "Problem Statement for Renumbering IPv6 Hosts with Static Addresses", Brian Carpenter, Sheng Jiang, 5-Dec-11, This document analyses the problems of updating the IPv6 addresses of hosts in enterprise networks that for operational reasons require static addresses. "PCEP Extensions for Stateful PCE", Jan Medved, Ina Minei, Edward Crabbe, Robert Varga, 22-Jan-12, The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. Although PCEP explicitly makes no assumptions regarding the information available to the PCE, it also makes no provisions for synchronization or PCE control of timing and sequence of path computations within and across PCEP sessions. This document describes a set of extensions to PCEP to enable this functionality, providing stateful control of Multiprotocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSP) via PCEP. "Mitigating Neighbor Discovery Based Denial of Service Attacks", Joel Halpern, 17-Oct-11, It has been observed that with the large space of IPv6 addresses within a subnet, remote attackers can send packets that saturate a rotuers ND cache, and potentially saturate a subnet with ND Soliciation messages as well. Some operational techniques and small protocol adjustments have been proposed that can help alleviate this problem. This draft proposes a slightly more drastic optional behavior for routers, which can nearly eliminate this problem. "Software-Defined Network (SDN) Use Case for Bandwidth on Demand Applications", Ping Pan, Lyndon Ong, Shane Amante, 31-Oct-11, Bandwidth on Demand services are offered by network operators in industry and research sectors to support the needs of selected customers needing high bandwidth point-to-point connections. Without a standard interface for controlling the use of network resources, user applications and services are subject to limits of layering, security and interoperability across multiple vendors of network equipment. In this document, we argue the necessity in providing network information to the applications, thereby enabling the applications to directly provision network elements associated with the relevant applications. "PCP Support for Nested NAT Environments", Reinaldo Penno, Dan Wing, Paul Selkirk, Mohamed Boucadair, 21-Oct-11, Nested NATs or multi-layer NATs are already widely deployed. They are characterized by two or more NAT devices in the path of packets from the subscriber to the Internet. Moreover, NAT devices current deployed are PCP unaware and It is assumed that NAT aware PCP devices will take a long time to be rolled out. Therefore in order to lower the adoption barrier of PCP and make it work for current deployed networks, this document proposes a few mechanisms for PCP-enabled applications to work through nested NATs with varying level of PCP protocol support. "Dual Stack Lite and 4rd for Migrating Cloud Networks to IPv6", Behcet Sarikaya, 17-Oct-11, This document specifies how Dual Stack Lite or 4rd can be used to support IPv4 users in a cloud network that is IPv6 based. The cloud network is IPv6 only which simplifies the network operation and management. IPv4 users are supported either one of the transition technologies of DS-Lite or 4rd. This protocol is ideal for new cloud deployments since no new public IPv4 addresses are needed. "Dual Stack Lite and 4rd for Migrating Cloud Networks to IPv6", Behcet Sarikaya, 17-Oct-11, This document specifies how Dual Stack Lite or 4rd can be used to support IPv4 users in a cloud network that is IPv6 based. The cloud network is IPv6 only which simplifies the network operation and management. IPv4 users are supported either one of the transition technologies of DS-Lite or 4rd. This protocol is ideal for new cloud deployments since no new public IPv4 addresses are needed. "RPL adaptation for asymmetrical links", Pascal Thubert, 9-Dec-11, The Routing Protocol for Low Power and Lossy Networks defines a generic Distance Vector protocol for Low Power and Lossy Networks, many of which exhibit strongly asymmetrical characteristics. This draft proposes an extension for that optimizes RPL operations whereby upwards and downwards direction-optimized RPL instances are associated. "Requirements for GMPLS Routing for ASON", Qilei Wang, Xihua Fu, Guoman Liu, 17-Oct-11, The Generalized Multi-Protocol Label Switching (GMPLS) suite of protocols has been defined to control different switching technologies as well as different applications. These include support for requesting Time Division Multiplexing (TDM) connections including Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) and Optical Transport Networks (OTNs). Along with the development of technology, some new routing requirements which are addressed in G.7715.1 emerge. This document concentrates on the new routing requirements addressed in G.7715.1 and placed on the GMPLS suite of protocols in order to support the capabilities and functionalities of an Automatically Switched Optical Network (ASON) as defined by the ITU-T. "DHCPv6 Dynamic Re-Configuration", Dan Wing, Tirumaleswar Reddy, Prashanth Patil, 31-Oct-11, Some networks are expected to support IPv4-only, dual-stack, and IPV6-only hosts at the same time. This makes prioritizing the DNS servers for hosts tricky due to a heterogeneous mix of protocol stacks causing optimal behavior to occur only when the host stack re- initializes. The networks infrastructure is usually well equipped to be aware of single/dual-stack nature of hosts. This specification extends DHCPv6 so that the DHCPv6 Relay Agent can dynamically influence the priority of DNS servers provided to the host, so that the host can use the optimal DNS server for resolution. "CoAP Security Options", Alper Yegin, Zach Shelby, 17-Oct-11, This document specifies a set of Constrained Application Protocol (CoAP) options that are used for providing data origin authentication, integrity and replay protection, and encryption for the CoAP messages. "The MANEMO Route Optimization in the Rescue Operation", Ma Xiaolei, Zhang Jie, Jia Jintao, Liu Yuanan, 18-Oct-11, Network Mobility Basic Support Protocol (NEMO BS) is the protocol proposed for the mobility management of mobile networks. However, NEMO BS cannot deal with the problem of pinball routing in the nested mobile network. And the related solutions are not yet considered and discussed in the IETF. MANEMO (MANET for NEMO) is designed to solve this problem. This article puts forward a novel MANEMO route optimization solution to solve the pinball routing in nested NEMO. "Multicast Support for 4rd", Behcet Sarikaya, 2-Feb-12, This memo specifies 4rd technology's multicast component so that IPv4 hosts can receive multicast data from IPv4 servers over an IPv6 network. In 4rd Translation Multicast solution, IGMP messages are translated into MLD messages at the CE router which is IGMP/MLD Proxy and sent to the network in IPv6. 4rd Border Relay does the reverse translation and joins IPv4 multicast group for 4rd hosts. Border Relay as multicast router receives IPv4 multicast data and translates the packet into IPv6 multicast data using 4rd-U and sends downstream on the multicast tree. Member CEs receive multicast data, translate it back to IPv4 and transmit to the hosts. In AMT based solution, AMT Gateway at the 4rd Customer Edge router uses AMT protocol to establish a tunnel interface with AMT Relay at the 4rd Border Relay and this tunnel is used to exchange IGMP messages to establish multicast state at AMT Relay so that AMT Relay can tunnel IPv4 multicast data to IPv4 hosts connected to AMT Gateway. "Multiplexing Negotiation Using Session Description Protocol (SDP) Port Numbers", Christer Holmberg, Harald Alvestrand, 19-Oct-11, This specification defines a new SDP Grouping Framework SDP grouping framework extension, "BUNDLE", that can be used with the Session Description Protocol (SDP) Offer/Answer mechanism to negotiate the usage of bundled media, which refers to the usage of a single 5-tuple for media associated with multiple SDP media descriptions ("m=" lines). "Key Management for Pairwise Routing Protocol", Mahesh Jethanandani, Dacheng Zhang, Brian Weis, Keyur Patel, Sam Hartman, 19-Oct-11, When running routing protocols such as BGP or RSVP-TE, two routers need to exchange routing messages in a unicast (one-to-one) fashion. In order to authenticate these messages using symmetric cryptography, a secret key needs to be established. This document defines a Router Key Management Protocol for establishing and managing such keys for routing protocols. "ALTO for CDNi Request Routing", Jan Seedorf, 19-Oct-11, Network Service Providers (NSPs) are currently considering to deploy Content Delivery Networks (CDNs) within their networks. As a consequence of this development, there is a need for interconnecting these local CDNs. The necessary interfaces for inter-connecting CDNs are currently being defined in the Content Delivery Networks Interconnection (CDNi) WG. This document focusses on the Request Routing Interface of CDNi, and more specifically on how the solutions currently being defined in the Application Layer Traffic Optimization (ALTO) WG can improve CDNi request routing. The overall intention behind this document is to foster discussions (in the CDNi as well as in the ALTO WG) regarding a) if, b) how, and c) under what conditions ALTO can be useful to optimize CDNi request routing. As basis for this discussion, this document provides concrete examples of how ALTO can be integrated within CDNi request routing. The examples in this document are based on the use cases and examples currently being discussed in the CDNi WG. "Encrypting PANA AVPs", Alper Yegin, Robert Cragie, 4-Jan-12, This document specifies a mechanism for delivering PANA (Protocol for Carrying Authentication for Network Access) AVPs (Attribute-Value Pairs) in encrypted form. "A Hierarchical Mapping System for LISP", Hongke Zhang, 19-Oct-11, This draft proposes a Hierarchical Mapping System (HMS) for Locator/ID Separation Protocol (LISP). HMS uses a hierarchical architecture as well as one-hop DHT (Distributed Hash Tables). HMS composes two levels with the bottom level maintaining EID-to-RLOC mappings in an Autonomous System (AS) and the upper level storing the global EID-prefix-to-AS mappings. The bottom level is organized in one-hop DHT and the upper level propagates EID-prefix-to-AS mappings using a protocol like BGP. HMS builds an efficient and scalable mapping system to provide RLOCs for a given EID. "Reactions to Signaling from ECN Support for RTP/RTCP", Ken Carlberg, 20-Oct-11, This document presents recommendations for response to Congestion Experience (CE) notifications by real time applications that have negotiated end-to-end support of Explicit Congestion Notification (ECN). This document is a follow-on effort of [draft-rtp-ecn], which specifies the signaling used to provide ECN support for RTP/RTCP flows. "Architecture for Service Provisioning with Cross Stratum Optimization", Luis Contreras, Alejandro Tovar, Giada Landi, Nicola Ciulli, 20-Oct-11, A functional architecture able to provide dynamic and on-demand service provisioning with cross stratum optimization is presented. The proposed architecture can handle the seamless provisioning of both IT and network resources in a dynamic manner to satisfy the application demands. "DHCPv4 over IPv6 transport", Yong Cui, Peng Wu, Jianping Wu, Ted Lemon, 20-Oct-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 is extended to support this IPv6 transport. And for the relay case, a new suboption of the Relay Agent Information Option is defined to carry the remote IPv6 address of the clients. "Certificate Manifest Register (Certificate Revocation List v4)", Kyle Hamilton, 20-Oct-11, In the spirit of simple, incremental improvement, we describe a whitelist-based revocation mechanism called the "Certificate Manifest Register". This is a list of all potentially-valid certificates which are (as of the date of production) known to have been legitimately issued by the CA and how they are to be treated by the client. This permits certificates which are checked against it to be presumed invalid unless listed. Several recent events have cast doubt on the sufficiency of blacklist-based PKIX certificate revocation mechanisms. At least one publicly-trusted Certification Authority was recently found to have been penetrated by a state-backed attacker, which issued itself several certificates valid for a particular global web search and email provider and then removed the records that it had done so. In effect, the attacker was able to cause the CA to sleepwalk. There was nothing that the client software developers could do to protect their users and themselves except remove the trust in that CA's root. This event directly caused that particular CA's insolvency. The Certificate Revocation List format and definitions (X.509v2 as described in RFC 5280, its predecessors, and possibly its successors) are used and adapted whole-hog, with no data format changes and the alteration of one rule and one semantic to support whitelist-based processing. CMR is defined to use version integer 3 (v4) to differentiate its processing path from v2 CRL. The changes from the CRL Profile are so minor, though, that they potentially might be implemented without a version bump, without disruption to current v2 CRL consumers. "CoAP Over SMS", Kepeng Li, 20-Oct-11, This document explains how to use CoAP in cellular networks, by using SMS (Short Message Service) as the transport protocol. "Shortest Path Bridging (SPB) over an MPLS Packet Switched Network", Ben Mack-Crane, Lucy Yong, 20-Oct-11, This informational document describes ways to interconnect a Shortest Path Tree (SPT) Region over WAN connections using MPLS Pseudo Wires (PWs) with existing SPB and MPLS standards. It also describes how a combination of SPB and MPLS can provide a hierarchical scalable L2VPN. "Referencing and Validating User Attributes", Kumiko Ono, Henning Schulzrinne, 20-Oct-11, This document describes a mechanism for referencing and validating user attributes in SIP communication. User attributes, such as an organizational affiliation and role, are helpful for the recipients of a communication request to decide whether or not to grant the sender access to the recipient's resources, especially when the sender identity is unknown to the recipients. This mechanism allows the sender to claim her attributes to recipients using an attribute reference identifier without needing to prove the sender identity. This document defines a new SIP "Sender-References" header field to convey one or more attribute reference identifiers. This mechanism satisfies all the requirements for trait-based authorization defined in RFC 4484, except that it provides only one assertion scheme. "Path Computation Requirements for Cross-Stratum-Optimization", Alejandro Tovar, Giada Landi, Luis Contreras, Nicola Ciulli, 20-Oct-11, The cross stratum optimization approach aims for providing a jointly optimized provision of both IT and network resources according to the application demands. In order to do that, the path computation capabilities in the network, which are in charge of finding the optimal connectivity resources, should take into account a new set of requirements. This memo explores the new needs derived from the cross stratum optimization approach. "BGP Persistence", Adam Simpson, Bruno Decraene, Clarence Filsfils, James Uttaro, John Scudder, Pradosh Mohapatra, Rob Shakir, Yakov Rekhter, 20-Oct-11, For certain AFI/SAFI combinations it is desirable that a BGP speaker be able to retain routing state learned over a session that has terminated. By maintaining routing state forwarding may be preserved. This technique works effectively as long as the AFI/SAFI is primarily used to realize services that do not depend on exchanging BGP routing state with peers or customers. There may be exceptions based upon the amount and frequency of route exchange that allow for this technique. Generally the BGP protocol tightly couples the viability of a session and the routing state that is learned over it. This is driven by the history of the protocol and it's application in the internet space as a vehicle to exchange routing state between administrative authorities. This document addresses new services whose requirements for persistence diverge from the Internet routing point of view. "Convergence benchmarking on contemporary routers", Bhavani Parise, Ilya Varlashkin, Rajiv Papneja, Tara Unen, 20-Oct-11, This document specifies methodology for benchmarking convergence of routers without making assumptions about relation and dependencies between data- and control-planes. Provided methodology is primary intended for testing routers running BGP and some form of link-state IGP with or without MPLS. It may also be applicable for environments using MPLS-TE or GRE, however they're beyond scope of this document and such application is left for further study. "PIM source discovery via BSR", IJsbrand Wijnands, Michael Brig, Stig Venaas, 20-Oct-11, PIM Sparse-Mode use a Rendezvous Point (RP) and shared trees to forward multicast packets to Last Hop Routers (LHR). After the first packet is received by the LHR, the source of the multicast stream is learned and the Shortest Path Tree (SPT) can be joined. This draft proposes a solution to support PIM Sparse Mode (SM) without the need for PIM registers, RPs or shared trees. Multicast source information is distributed via Bootstrap Router [RFC5059] messages and flooded throughout the Multicast domain. By removing the need for RPs and shared trees, the PIM-SM procedures are simplified, improving router operations, management and making the protocol more robust. "RTSP Extension for Substream Control", Peiyu Yue, 20-Oct-11, This document defines extensions to RTSP 2.0 protocol, including header "Substream", feature tag "Play.substream" , and related new status codes. These extensions enables the playback control of a media stream on substream basis. "PDV-based PTP LSP Setup,Reoptimization and Recovery", Junhui Zhang, Liang Xia, 20-Oct-11, This document defines a mechanism for the setup,reoptimization and recovery of PTP LSP based on the PDV metrics between the 1588 Master and the 1588 Slave. When a PTP communication path goes through the third party networks (e.g. the MPLS networks), the PDV noise caused by the third party networks will have a significant impact on the synchronization performance. So, the PDV metrics should be considered in the setup of PTP LSP. In addition, when the PDV noise exceeds to a certain degree, it is necessary to notify the head-end LSR(i.e. the 1588 Master) to switch to the backup PTP LSP and to reoptimize the primary PTP LSP in order to improve the PTP reliability. "HOST_ID TCP Options: Implementation & Preliminary Test Results", Elie Abdo, Mohamed Boucadair, Jaqueline Queiroz, 13-Jan-12, This memo documents the implementation of the HOST_ID TCP Options. It also discusses the preliminary results of the tests that have been conducted to assess the technical feasibility of the approach as well as its scalability. Several HOST_ID TCP options have been implemented and tested. "GMPLS-UNI BCP", Vishnu Beeram, Igor Bryskin, Wes Doonan, John Drake, Gert Grammel, Manuel Paul, Ruediger Kunze, 21-Oct-11, This document pools together the best current practices that are being used to apply the GMPLS Overlay model at the User-Network Interface (UNI) reference point (as defined in [G.8080]) "DHCPv6 class based prefix", Cisco Systems, Gaurav Halwasia, Sri Gundavelli, Sindhura Bandi, 21-Oct-11, DHCPv6 defines class based allocation of IA_NA and IA_TA IPv6 addresses. This document extends DHCPv6 prefix delegation with class based prefix allocation. It defines a new prefix class option to classify a prefix. It defines the behavior of a DHCPv6 client requesting a prefix to include the class of the prefix to be allocated and the DHCPv6 server behavior to select and offer a prefix from a given class. It discusses how IA_NA can be requested and assigned from a specific prefix class. "IPv6 Guidance for Internet Content and Application Service Providers", Brian Carpenter, Sheng Jiang, 22-Feb-12, This document provides guidance and suggestions for Internet Content Providers and Application Service Providers who wish to offer their service to both IPv6 and IPv4 customers. Many of the points will also apply to any enterprise network preparing for IPv6 users. "RSVP-TE extensions for services aware MPLS", Qilei Wang, Malcolm Betts, Vishwas Manral, Xihua Fu, Dave McDysan, Andrew Malis, 13-Nov-11, With more and more enterprises using cloud based services, the distances between the user and the applications are growing. For multiple applications such as High Performance Computing and Electronic Financial markets, the response times are critical as is packet loss, while other applications require more throughput. For example, financial or trading companies are very focused on end-to- end private pipe line latency optimizations that improve things 2-3 ms. Latency and latency SLA is one of the key parameters that these "high value" customers use to select a private pipe line provider. This document extends RSVP-TE protocol to promote SLA experince of latency and packet loss application. "Extensions to the Path Computation Element Communication Protocol (PCEP) for Associated Bidirectional LSP", Wenjuan He, 13-Nov-11, The MPLS Transport Profile (MPLS-TP) requirements document[RFC5654], describes that MPLS-TP MUST support associated bidirectional point- to-point LSPs. Path Computation Element (PCE), see [RFC4655], may be used for path computation of an associated bidirectional LSP. This document defines the Path Computation Element Protocol (PCEP)-based [RFC5440] extensions for associated bidirectional LSP. "API Requirements for WebRTC-enabled Browsers", Hadriel Kaplan, Neil Stratford, Tim Panton, 31-Oct-11, This document discusses the advantages and disadvantages of several proposed approaches to what type of API and architectural model WebRTC Browsers should expose and use. The document then defines the requirements for an API that treats the Browser as a library and interface as opposed to a self-contained application agent. "The CLEFIA Cipher Algorithm and Its Use with IPsec", Masanobu Katagi, Shiho Moriai, 21-Oct-11, This document describes the use of the CLEFIA block cipher algorithm in conjunction with several different modes of operation within IKE and IPsec. "Extensible Provisioning Protocol (EPP) Domain Name System Security Extensions (DNSSEC) Mapping for Chinese Domain Names", Hongtao Li, Ning Kong, Jiagui Xie, 21-Oct-11, This document describes an extension of Extensible Provisioning Protocol (EPP) Domain Name System Security Extensions (DNSSEC) mapping for the provisioning and management of Chinese Domain Names (CDNs), especially for variant CDNs. Specified in XML, this extended mapping is applied to provide additional features required for the provisioning of DNS security extensions for CDNs. "Analysis and recommendation for the ULA usage", Sheng Jiang, Bing Liu, 21-Oct-11, This document tries to cover all kinds of ULA use cases. And then tries to identify some potentially valuable use cases which can benefit from ULA. Liu & Jiang "Additional Content Distribution Network Interconnection (CDNI) Requirements Based on ATIS CSF", Serge Manning, Robert Streijl, Vishwa Prasad, Percy Tarapore, Mike Geller, Ramki Krishnan, 21-Oct-11, The purpose of Content Delivery Networks (CDNs) is to deliver content to end users in an efficient manner from the perspective of the network providers and with consistently good performance from the perspective of the end user. Due to footprint limitations of a single network provider, it may be necessary to interconnect CDNs between different providers. The Content Distribution Network Interconnection (CDNI) working group has been chartered to develop an interoperable and scalable solution for such CDN interconnection. The requirements for CDN interconnection are being discussed and developed in various industry forums. One example is the Alliance for Telecommunications Industry Solutions (ATIS) Cloud Services Forum (CSF) which is looking at CDN interconnection requirements from the perspective of telecom providers. This document introduces some additional requirements to be included in the CDNI working group based on conclusions reached by ATIS CSF. The goal is for specifications developed by CDNI to successfully support some of the needs expressed by ATIS CSF as interpreted by the authors of this document. "Test Plan and Results for Advancing RFC 2680 on the Standards Track", Len Ciavattone, Ruediger Geib, Al Morton, Matthias Wieser, 16-Jan-12, This memo proposes to advance a performance metric RFC along the standards track, specifically RFC 2680 on One-way Loss 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 2680. "ALTO home proxy", Fabio Picconi, 21-Oct-11, This documents discusses the use of ALTO proxies running on home devices such as gateways or home NAS servers. An ALTO home proxy caches ALTO information obtained from an origin ALTO server, and uses that information to serve queries originating from the home network. ALTO home proxies reduce ALTO traffic and query latency, improve scalability, and enhance user privacy. "Privacy Concerns relating to the PSTN Validation Protocol (PVP)", Michael Procter, 21-Oct-11, This document describes some issues with privacy leaks (real or imagined) associated with VIPR, and also some of the countermeasures that could be deployed to avoid them. "DHCPv6 Options for IPv6 DS-Lite Multicast Prefix", Jacni Qin, Mohamed Boucadair, Tina Tsou, 31-Oct-11, This document defines Dynamic Host Configuration Protocol version 6 (DHCPv6) Options for multicast transition solutions, aiming to convey the IPv6 prefixes to be used to build unicast and multicast IPv4- embedded IPv6 addresses. These options can be in particular used in the context of DS-Lite, Stateless A+P and other IPv4-IPv6 interconnection techniques. "A Multiplexing Extension for WebSockets", John Tamplin, Takeshi Yoshino, 26-Jan-12, The WebSocket Protocol [RFC6455] requires a new transport connection for every WebSocket connection. This presents a scalability problem when many clients connect to the same server, and is made worse by having multiple clients running in different tabs of the same user agent. This extension provides a way for separate logical WebSocket connections to share an underlying transport connection. Please send feedback to the hybi@ietf.org mailing list. "ICMP based OAM Solution for TRILL", Tissa Senevirathne, Dinesh Dutt, Vishwas Manral, Sam Aldrin, 6-Jan-12, This document presents a solution suite for TRILL data plane monitoring and failure detection. Methods presented herein allow in- cooperating IP payloads, exercising multi-paths, verifying multicast trees, locating end stations, virtual segments and diagnosing connectivity problems. ICMP protocol is proposed as framework for error reporting. Document also presents network wide health monitoring, distribution and reporting methods that are intended for efficient troubleshooting. "OSPFv3 Auto-Configuration", Acee Lindem, Jari Arkko, 23-Oct-11, OSPFv3 is a candidate for deployments in environments where auto- configuration is a requirement. One such environment is the IPv6 home network where users expect to simply plug in a router and have it automatically use OSPFv3 for intra-domain routing. This document describes the necessary mechanisms for OSPFv3 to be self-configuring. "Next-Hop SMTP Traffic Control", Steve Atkins, 23-Oct-11, This document defines an extended SMTP response for mail servers to assist clients in adjusting the rate at which they send mail. Use of this mechanism can reduce wasteful SMTP connections and reduce mail delivery delays; at scale the aggregate benefit to clients and servers can be significant. "NETCONF Over Transport Layer Security (TLS)", Mohamad Badra, 13-Feb-12, The Network Configuration Protocol (NETCONF) provides mechanisms to install, manipulate, and delete the configuration of network devices. This document describes how to use the Transport Layer Security (TLS) protocol to secure NETCONF exchanges. This document obsoletes RFC 5539. "Extended IPv6 Addressing for Encoding Port Range", Congxiao Bao, Xing Li, 30-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 set identification (PSID) 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. "Signalling the Presence of NAT", Ray Bellis, Geoff Huston, 23-Oct-11, End-to-end applications have difficulty distinguishing between packets that have been passed through a Network Address Translator (NAT) and packets that have been passed along a clear end-to-end path. We propose mechanisms for IPv4 and IPv6 whereby NAT devices explicitly signal their operation as a means of allowing applications to distinguish the presence of otherwise undetected NATs in the end- to-end path. "OSPF Topology-Transparent Zone", Huaimo Chen, Renwei Li, 23-Oct-11, This document presents a topology-transparent zone in a domain. A topology-transparent zone comprises a group of routers and a number of links connecting these routers. Any router outside of the zone is not aware of the zone. The information about the links and routers inside the zone is not distributed to any router outside of the zone. Any link state change such as a link down inside the zone is not seen by any router outside of the zone. "Directory Assisted TRILL Encapsulation", Linda Dunbar, Donald Eastlake, Radia Perlman, Igor Gashinsky, 26-Oct-11, This draft describes how data center network can benefit from non- RBridge nodes performing TRILL encapsulation and how directory service can assist a non-RBridge node to encapsulate TRILL header. "VPN4DC Problem Statement", Luyuan Fang, 23-Oct-11, Provider Provisioned IP VPNs are commonly used to interconnect multiple locations of a private network, such as an enterprise with multiple offices. Current developments in data center operations create the need to consider additional connectivity and connectivity management problems described in this document. "Benchmarking Methodology for Evaluating the Security Effectiveness of Content Aware Devices", Tom Alexander, Kenneth Green, 23-Oct-11, This document defines a methodology for evaluating the ability of content-aware network devices to correctly detect and block malicious or administratively disallowed traffic flows. This benchmark addresses the issue of classification accuracy under well defined conditions. It is not concerned with measuring forwarding performance which is covered by other BMWG documents. "Experiences from an IPv6-Only Network in the WIDE Camp Autumn 2011", Hiroaki Hazeyama, Yukito Ueno, 23-Oct-11, This document discusses our experiences from the IPv6 only network experiment with NAT64 and DNS64 in the WIDE camp Autumn 2011. The WIDE camp Autumn 2011 was held from September 6th to September 9th, 2011, with 153 participants.This document reports answers of questionnaire from participants, troubles and causes, with referring IETF's IPv6 only network experiences. "Privacy Considerations for Internet Protocols", Alissa Cooper, Hannes Tschofenig, Bernard Ph.D., Jon Peterson, John Morris, 23-Oct-11, This document offers guidance for developing privacy considerations for IETF documents and aims to make protocol designers aware of privacy-related design choices. Discussion of this document is taking place on the IETF Privacy Discussion mailing list (see https://www.ietf.org/mailman/listinfo/ietf-privacy). "Webfinger", Paul Jones, Gonzalo Salgueiro, Joseph Smarr, 23-Oct-11, This specification defines procedures for discovering information about people. "Rate Measurement Problem Statement", Al Morton, 15-Jan-12, There is a rate measurement scenario which has wide-spread attention of users and seemingly all industry participants, including regulators. This memo presents an access rate-measurement problem statement for IP Performance Metrics. Key aspects require the ability to control packet size on the tested path and enable asymmetrical packet size testing in a controller-responder architecture. "Transparent Interconnection of Lots of Links (TRILL) over IP", Margaret Wasserman, Donald Eastlake, Dacheng Zhang, 23-Oct-11, The Transparent Interconnection of Lots of Links (TRILL) protocol is implemented by devices called Routing Bridges (RBridges). TRILL supports both point-to-point and multi-access links and is designed so that a variety of link protocols can be used between RBridge ports. This document standardizes a methods for encapsulating TRILL in UDP/IP(v4 or v6). "Proportional Quota in REsource LOcation And Discovery (RELOAD)", Marc Petit-Huguenin, Jonathan Rosenberg, Cullen Jennings, 23-Oct-11, This document defines an extension to RELOAD [I-D.ietf-p2psip-base] that limits the number of a specific kind element that can be stored by one RELOAD peer. "Codification of AS 0 processing.", Heather Schiller, Randy Bush, Warren Kumari, 24-Oct-11, This document proscribes the use of AS 0 in BGP OPEN and AS-PATH BGP attribute. "Automagic peering at IXPs.", John Scudder, Keyur Patel, Warren Kumari, 23-Oct-11, This document describes a method for automatically establishing BGP peering sessions at an Internet exchange point. Creation of these peering sessions is facilitated by a host. "dIVI-pd: Dual-Stateless IPv4/IPv6 Translation with Prefix Delegation", Qiong Sun, Rajiv Asati, Chongfeng Xie, Xing Li, Wojciech Dec, Congxiao Bao, 31-Oct-11, This document presents the address specifications and deployment considerations of address-sharing dual stateless IPv4/IPv6 translation with prefix delegation (dIVI-pd). The dIVI-pd keeps the features of stateless, end-to-end address transparency and bidirectional-initiated communications of the original stateless IPv4/IPv6 translation, while it can utilize the IPv4 addresses more effectively. In addition, it does not require the DNS64 and ALG, and can be used with prefix delegation. "Transparent Interconnection of Lots of Links (TRILL) over an MPLS PSN (Packet Switched Network)", Donald Eastlake, Jon Hudson, Lucy Yong, Sam Aldrin, 23-Oct-11, This informational document describes ways to interconnect TRILL RBridges over WAN connections by using MPLS Pseudo Wire (PW) or Virtual Private LAN Service (VPLS) with existing TRILL and MPLS standards. It also describes the combination of RBridge and MPLS to provide a hierarchical scalable L2VPN. "DECADE Content Replication and Access", Ning Zong, Yang Yang, 23-Oct-11, The DECADE Working Group at IETF is working on introducing standard- based, application-agnostic in-network storage for content distribution to improve both network efficiency and application performance. In this document, we introduce content replication trees and then discuss approaches on how a replication tree can be constructed in DECADE. In particular, we introduce concepts including core-stateless content pull, and stateful, open content forwarding table. "LSP Ping extensions for echo reply relay", Lizhong Jin, Zhi Zheng, 23-Oct-11, [RFC4379] describes the LSP Ping mechanism to detect data plane failures. In some deployment scenario for the LSP traceroute, a replying LSR may not have the available route to the initiator, and the echo reply message sent to the initiator would be discarded. Thus, the basic idea of traceroute procedure to localize fault could not be achieved. This document describes extensions to LSP Ping mechanism to enable the replying LSR to have the capability to relay the echo reply by a set of routable intermediate nodes to the initiator. "Transport Layer Security (TLS) Encrypted Client Certificates", Adam Langley, 24-Oct-11, This document describes a Transport Layer Security (TLS) extension that allows client certificates to be encrypted in the initial TLS handshake. "Uniform Resource Names for Device Identifiers", Jari Arkko, Cullen Jennings, Zach Shelby, 31-Oct-11, This memo describes a new Uniform Resource Name (URN) namespace for hardware device identifiers. A general representation of device identity can be useful in many applications, such as in sensor data streams and storage, or equipment inventories. A URN-based representation can be easily passed along in any application that needs the information. "Prefix Assignment in a Home Network", Jari Arkko, Acee Lindem, 31-Oct-11, This memo describes a prefix assignment mechanism for home networks. It is expected that home gateway routers are assigned an IPv6 prefix through DHCPv6 Prefix Delegation (PD). This prefix needs to be divided among the multiple subnets in a home network. This memo describes a mechanism for such division via OSPFv3. This is an alternative design to using DHCPv6 PD also for the prefix assignment. The memo is input to the working group so that it can make a decision on which type of design to pursue. It is expected that a routing- protocol based assignment uses a minimal amount of prefixes. "Data Center Reference Architectures", Manish Karir, Ian Foo, 24-Oct-11, The continued growth of large-scale data centers has resulted in a wide range of architectures and designs. Each design is tuned to address the challenges and requirements of the specific applications and workload that the data is being built for. Each design evolves as engineering solutions are developed to workaround limitations of existing protocols, hardware, as well as software implementations. The goal of this document is to characterize this problem space in detail in order to better understand if there is any gap in making address resolution scale in various network designs for data centers. In particular it is our goal to peel back the various optimization and engineering solutions to develop generalized reference architectures for a data center. We also discuss the various factors that influence design choices in developing various data center designs. "Performance-based Path Selection for Explicitly Routed LSPs", Alia Atlas, John Drake, David Ward, Spencer Giacalone, Stefano Previdi, Clarence Filsfils, 24-Oct-11, In certain networks, it is critical to consider network performance criteria when selecting the path for an explicitly routed RSVP-TE LSP. Such performance criteria can include latency, jitter, and loss or other indications such as the conformance to link SLAs and non- RSVP TE traffic load. This specification uses IGP extension data (which is defined outside the scope of this document) to perform such path selections. "Emergency Alert Service support in IEEE 802.11 networks", Gabor Bajko, 31-Oct-11, The IEEE 802.11 specification is evolving by defining new amendments to it, which are then rolled into the base spec. The 802.11u amendment, published in November 2010, contains support for Citizen to Authority type of Emergency Calls and Authority to Citizen type of Alerts. This document attempts to explain what level of support for Authority to Citizen type of Emergency Alerts has been defined for IEEE 802.11 protocol. "Lightweight Emergency Alerting Protocol (LEAP)", Richard Barnes, 31-Oct-11, Emergency alerts need to be delivered reliably from one source to many recipients at once. TCP is unsuitable for this style of delivery, because the large number of acknowledgements would likely cause network congestion. This document defines a UDP-based protocol for delivering alerts that supports fragmentation and retransmission for reliability, and allows the sender of a datagram to control whether acknowledgements are sent. Please send feedback to the atoca@ietf.org mailing list. "Alert Metadata Protocol (AMP)", Matt Lepinski, Karen Seo, Richard Barnes, 31-Oct-11, Recipients of emergency alerts need to discover information about local alert distribution servers, and to register contact points where they can receive alerts. This document defines a mechanism for IP networks to advertise a local alert server, and a protocol that devices on the network can use to retrieve local information and register information about themselves. Please send feedback to the atoca@ietf.org mailing list. "Transport of CoAP over SMS and GPRS", Koojana Kuladinithi, Markus Becker, Thomas Poetsch, 24-Oct-11, The Short Message Service (SMS) of mobile cellular networks is frequently used in Machine-To-Machine (M2M) communications, such as for telematic devices. The service offers small packet sizes and high delays just as other typical low-power and lossy networks (LLNs), i.e. 6LoWPANs. The design of the Constrained Application Protocol (CoAP), that took the limitations of LLNs into account, is thus also applicable to telematic M2M devices. The adaption of CoAP to the SMS transport mechanism is described in this document. "Duplicating RTP Streams", Ali Begen, Colin Perkins, 24-Oct-11, Packet loss is undesirable for real-time multimedia sessions, but it is not avoidable due to congestion or other unplanned network outages. This is especially the case for IP multicast networks. One technique to recover from packet loss without incurring unbounded delay for all the receivers is to duplicate the packets and send them in separate redundant streams. This document explains how RTP streams can be duplicated without breaking RTP and RTP Control Protocol (RTCP) rules. "Cloud Networking: Framework and VPN Applicability", Nabil Bitar, Florin Balus, Marc Lasserre, Wim Henderickx, Ali Sajassi, Luyuan Fang, Yuichi Ikejiri, Mircea Pisica, 31-Oct-11, Cloud Computing has been attracting a lot of attention from the networking industry. Some of the most publicized requirements are related to the evolution of the Cloud Networking Infrastructure to accommodate a large number of tenants, efficient network utilization, scalable loop avoidance, and Virtual Machine Mobility. This draft describes a framework for cloud networking, highlighting the applicability of existing work in various IETF Working Groups (e.g., RFCs and drafts developed in IETF L2VPN and L3VPN Working Groups) to cloud networking, and the gaps and problems that need to be further addressed. That is, the goal is to understand what may be re-used from the current protocols and call out requirements specific to the Cloud space that need to be addressed by new standardization work with proposed solutions in certain cases. "ISIS MPLS Explicit NULL Label", George Swallow, Himanshu Shah, Nabil Bitar, 24-Oct-11, There is need to support IP interfaces on the top of GMPLS packet Label Switched Paths (LSPs), and enable IP routing (e.g., OSPF-TE, ISIS-TE) and MPLS protocols on these interfaces. Traffic on an IP/MPLS interface can be user traffic or control traffic. In addition, it can be MPLS, IP or ISIS. Multiplexing IP and MPLS packets over the same LSP is supported in the current MPLS architecture. However, multiplexing IP, MPLS, and ISIS packets over the same LSP is not currently supported. This draft proposes the definition of an explicit ISIS NULL label to enable this type of multiplexing to take place. "ICMP Handling in IPv6-to-IPv6 Network Prefix Translation", Steven Blake, Terry Moes, 28-Jan-12, NPTv6 is a stateless, transport-agnostic IPv6-to-IPv6 Network Prefix Translation function that provides the address-independence benefit associated with IPv4-to-IPv4 NAT without some of that mechanism's drawbacks. NPTv6 is intended to be deployed in environments where a host might not know its "external" network prefix(es). In such an environment, a NPTv6 device must also translate network prefixes present in in-bound and out-bound ICMPv6 error message payloads. This document describes the required processing of ICMPv6 error messages. "HTTP-COAP Proxy Discovery using Link-format", Yuanchen Ma, Hui Deng, 24-Oct-11, This document discusses the problem of HTTP-COAP proxy discovery and proposes a method of using Link-format to do the job. "Protocol to query a White Space Database", Jesse Caufield, 31-Oct-11, Regulatory entities in many countries are making spectrum previously used by television stations available for secondary use as a result of the switch from analog to digital. The spectrum in such cases is still owned by the primary user to whom it is licensed. However parts of the spectrum may be unused at a given location or time and hence can be made available for secondary use. In order to use such spectrum a device has to query a database in order to obtain a list of available channels or spectrum at a given location and time. This document specifies protocol elements that can be used to query a white space database and obtain a response by a device. "Content Distribution Network Interconnection (CDNI) Core Metadata", Kent Leung, Matt Caulfield, 24-Oct-11, The CDNI Metadata Interface enables interconnected CDNs to exchange content distribution metadata for the purpose of content acquisition and delivery. The CDNI metadata associated with a piece of content provides a downstream CDN with the information necessary for the downstream CDN to service content requests on behalf of an upstream CDN in accordance with the delivery policies defined by the upstream CDN. This document describes the core set of CDNI metadata that all interconnected CDNs must support. "Deploying mLDP through p2p LSP Tunnels", Emily Chen, Quintin Zhao, 24-Oct-11, Label Distribution Protocol (LDP) can be used to set up Point-to- Multipoint (P2MP) and Multipoint-to-Multipoint (MP2MP) Label Switched Paths. The existing specification for this functionality assumes that a pair of LDP neighbors which support the P2MP/MP2MP capability are directly connected. However, the real deployment may not have all the nodes along the LSP path to be P2MP/MP2MP capable so that the CapEx of the deployment can be reduced or the deployment of the LDP P2MP/MP2MP can be in phases instead of updating the whole network. This document provides a solution for finding the first upstream node which supports the LDP P2MP/MP2MP along the path from the current node to the root node. "IS-IS Extended Sequence number TLV", Uma Chunduri, Wenhu Lu, Albert Tian, Naiming Shen, 24-Oct-11, This document defines Extended Sequence number TLV to protect Intermediate System to Intermediate System (IS-IS) PDUs from replay attacks. "KARP IS-IS security gap analysis", Uma Chunduri, Albert Tian, Wenhu Lu, 24-Oct-11, This document analyzes the threats applicable for Intermediate system to Intermediate system (IS-IS) routing protocol and security gaps according to the KARP Design Guide. This document also provides specific requirements to address the gaps with both manual and auto key management protocols. "Using IKEv2 with TCP-AO", Uma Chunduri, Albert Tian, 24-Oct-11, This document analyzes the TCP based pairwise Routing Protocol (RP) requirements for IKEv2 Key Management Protocol (KMP). This document discusses the various authentication methods available for peer authentication in IKEv2 KMP and the specific Security Association (SA) requirements for IKEv2 protocol to protect the TCP based pairwise RPs. "TCP-AO extensions for KARP-KMP", Uma Chunduri, Albert Tian, 24-Oct-11, This document discusses the possible extensions for TCP Authentication Option (TCP-AO) to better integrate and maximize the benefits, when deployed with Key Management Protocols (KMPs). TCP-AO as defined in RFC5925 can obtain master key from KMP and uses a Key Derivation Function (KDF) to generate traffic keys to protect the TCP sessions. In this mode, not all the benefits from the KMP can be realized. This document introduces an alternative approach for TCP-AO that allows TCP-AO to realize all the operational and security benefits from the deployed KMP. "The LLN On-demand Ad hoc Distance-vector Routing Protocol - Next Generation (LOADng)", Thomas Clausen, Axel Verdiere, Jiazi Yi, Afshin Niktash, Yuichi Igarashi, Ulrich Herberg, 31-Oct-11, This document describes the LLN Ad hoc On-Demand - Next Generation (LOADng) distance vector routing protocol, a reactive routing protocol intended for use in Low power and Lossy Networks (LLN). The protocol is derived from AODV and extended for use in LLNs. "CalDAV Managed Attachments", Cyrus Daboo, 24-Oct-11, This document defines how CalDAV servers can provide server managed collections to allow attachments associated with iCalendar data, to be stored and managed on the server. "Collected Extensions to CalDAV", Cyrus Daboo, 28-Oct-11, This document defines a set of extensions to the CalDAV calendar access protocol. "OSPFTE extension to support GMPLS for Flex Grid", Iftekhar Hussain, Rajan Rao, Abinder Dhillon, 23-Nov-11, This document specifies the extension to TELINK LSA of OSPF routing protocol [RFC4203] [3] in support of GMPLS [1] for flex-grid networks [2]. "Definitions of Managed Objects for IP Flow Information Export", Thomas Dietz, Atsushi Kobayashi, Benoit Claise, Gerhard Muenz, 24-Oct-11, 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. "MPLS-TE Fast Reroute Resource Classification", Jie Dong, Mach Chen, Curtis Villamizar, 31-Oct-11, This document describes simple and backward compatible extensions to Fast-Reroute (FRR) MPLS Traffic Engineering (TE). The purpose of these extensions include the following. These extensions provide a classification of SRLG to support LSP with differing protection requirements. These extensions allow highly reliable nodes or links, typically resources with redundancy at a lower layer, to be identified to allow LSP to optionally not consider these resources as potential points of failure. "Purge LSA for OSPF flushing", Jie Dong, Xudong Zhang, 24-Oct-11, In some scenarios current OSPF flushing mechanism may incur problem of delaying the deletion of invalid Link State Advertisement (LSA) and result in desynchronization of link state database. This document proposes a backward compatible solution to solve this problem. "Pseudowire Redundancy on S-PE", Jie Dong, Haibo Wang, 24-Oct-11, This document describes Multi-Segment Pseudowire (MS-PW) protection scenarios in which the pseudowire redundancy is provided on the Switching-PE (S-PE). Signaling of preferential forwarding defined in [I-D.ietf-pwe3-redundancy-bit] is reused. "VPN4DC Problem Statement", Linda Dunbar, Ning So, 24-Oct-11, VPN4DC is for extending an existing VPN to connect hosts in public data center(s) which are purchased or leased by VPN client. This draft describes the issues and problems associated with this kind of services. "Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS", Anoop Ghanwani, Ayan Banerjee, Dinesh Dutt, Donald Eastlake, Radia Perlman, 31-Jan-12, The IETF TRILL (Transparent Interconnection of Lots of Links) protocol provides optimal pair-wise data frame forwarding without configuration in multi-hop networks with arbitrary topology, and support for multipathing of both unicast and multicast traffic. This document specifies the data formats and code points for the IS-IS extensions to support TRILL. These data formats and code points may also be used by technologies other than TRILL. This document obsoletes RFC 6326. "TRILL: Clarifications, Corrections, and Updates", Donald Eastlake, Mingui Zhang, Anoop Ghanwani, Ayan Banerjee, Vishwas Manral, 8-Jan-12, The IETF TRILL (TRansparent Interconnection of Lots of Links) protocol provides least cost pair-wise data forwarding without configuration in multi-hop networks with arbitrary topology, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. TRILL accomplishes this by using IS-IS (Intermediate System to Intermediate System) link state routing and by encapsulating traffic using a header that includes a hop count. Since the TRILL base protocol was approved in March 2010, active development of TRILL has revealed a few errata in the original RFC 6325 and some cases that could use clarifications or updates. RFCs 6327, RFC 6439, and RFC XXXX, provide clarifications with respect to Adjacency, Appointed Forwarders, and the TRILL ESADI protocol. This document provide other known clarifications, corrections, and updates to RFCs 6325, 6327, and 6439. "Algorithms for computing Maximally Redundant Trees for IP/LDP Fast- Reroute", Alia Atlas, Andras Csaszar, 24-Oct-11, A complete solution for IP and LDP Fast-Reroute using Maximally Redundant Trees is presented in [I-D.atlas-rtgwg-mrt-frr-architecture]. This document describes an algorithm that can be used to compute the necessary Maximally Redundant Trees and the associated next-hops. "The Named Information (ni) URI Scheme: Core Syntax", Stephen Farrell, Christian Dannewitz, Borje Ohlman, Dirk Kutscher, Phillip Hallam-Baker, 24-Oct-11, This document defines a URI-based name form that identifies a named object via hash-based binding. The URI name form defined is intended for use in applications that need to uniquely identify resources in a location-independent way such as accessing in-network storage (DECADE), information-centric networking and more generally. The format is designed to support a strong link to the referenced object such that the referenced object may be authenticated to the same degree as the reference to it. "Catalogue of Advanced Use Cases for Content Delivery Network Interconnection", Theodore Zahariadis, Yannick Louedec, Christian Timmerer, Spiros Spirou, David Griffin, 24-Oct-11, The purpose of this draft is to complement the current CDNi WG use- cases with a catalogue of advanced, longer-term CDN interconnection use cases. The work has been the contribution of six European Commission (EC) co-funded projects, which are part of the EC Future Media networks (FMN) cluster. "Associate PW label with PTP application", Xihua Fu, Muliu Tao, 24-Oct-11, [1588overMPLS] defines two methods for transporting PTP messages (PDUs) over an MPLS network. The second method is to transport PTP messages inside a PW via Ethernet encapsulation. When PHP is applied to PTP LSP or the PW is etablished between two routers directly and no PTP LSP is needed, PW label must be associated with PTP application at the PW termination point. This document introduces a mechanism to associate PW label with PTP application. "A URN Namespace for Digital Television Group (DTG)", Mykyta Yevstifeyev, Will Godfrey, 27-Jan-12, This document describes a Uniform Resource Name (URN) namespace which is maintained by the Digital Television Group (DTG) for naming persistent resources (specifically, various DTG specifications). "IP VPN Scaling Considerations", Wesley George, Rob Shakir, 24-Oct-11, This document discusses scaling considerations unique to implementation of Layer 3 (IP) Virtual Private Networks, discusses a few best practices, and identifies gaps in the current tools and techniques which are making it more difficult for operators to cost- effectively scale and manage their L3VPN deployments. "Ensuring Home Network Visibility to Home Gateway", Wassim Haddad, Joel Halpern, 24-Oct-11, This memo describes a mechanism designed to increase the home gateway visibility on the home network that it is serving. This includes knowledge of all IPv6 addresses configured using prefixes assigned by the home gateway and advertised by router(s) attached to it. "The Named Information (ni) URI Scheme: Parameters", Phillip Hallam-Baker, Rob Stradling, Stephen Farrell, Dirk Kutscher, 24-Oct-11, This document specifies some optional algorithms and parameters that may be used in the query string of ni URIs. "Security Policy Distribution Format (SPDF)", Phillip Hallam-Baker, Rob Stradling, 29-Oct-11, This document describes a format for distributing collections of security policy statments as static documents. Individual security policy statements are expressed in a HTTP compatible header syntax. Lists of security policy statements are signed for exchange. Strong references to static data objects are formed using Named Information (ni) URI specifiers. "Bibliography for the BGP Path Selection", Susan Hares, 24-Oct-11, BGP-v4?s [RFC4271]path selection rule has been enforce since the 1990s. The Inter-Domain Working Group [IDR] will be considering additions to the path selection [add-path][add-path-guidelines][path- select-criteria] in 2011-2012. This document provides a bibliography of publications (research and public) regarding the bgp path selection. "Energy Aware Proxy Discovery for CoAP", Xuan He, 24-Oct-11, CoRE defines a mechanism for resource discovery based on Web linking with discovery, registration,modification, and other procedures. But energy efficiency is very important for resource constrained devices. This specification shows an efficient method for CoAP proxy finding the resource from end-points by reducing multicast messages. The current version -00 of this document is just an initial draft that is intended to spark discussion. "Internet Exchange Route Server Operations", Nick Hilliard, Elisa Jasinska, Robert Raszuk, Niels Bakker, 24-Oct-11, The growing popularity of Internet exchange points (IXPs) brings a new set of requirements to interconnect participating networks. While bilateral exterior BGP sessions between exchange participants were previously the most common means of exchanging reachability information, the overhead associated with dense interconnection has caused substantial operational scaling problems for Internet exchange point participants. Multilateral interconnection can dramatically reduce the administrative and operational overhead of IXP participation and is now used by many IXP participants as a means of exchanging routing information. This document outlines operational considerations for multilateral interconnections at IXPs. "Session Initiation Protocol (SIP) emergency call back identification", Christer Holmberg, 24-Oct-11, This specification define a new type of Globally Routable User Agent URI (GRUU) [RFC5627], called emergency GRUU (eGRUU). When a User Agent (UA) provides makes an emergency call, it can provide the eGRUU to a PSAP, which can then use it to make a PSAP callback call. The specification also defines a new URI parameter, "psapcb", which can be used to indicate that a URI can be used for PSAP callback calls. A registrar will provide the URI parameter as part of the generated eGRUU value. Later, when a PSAP makes a PSAP callback call the URI, including the "psapcb" URI parameter, can be used by SIP entities to identity callback calls. "PIM Route Flap Damping", Jacni Qin, Zheng Zhang, BenChong Xu, 24-Oct-11, This document describes the route flap damping functions for PIM-SM [RFC4601], to reduce the processing load caused by the instability of routing peers. "SIP to RTCWeb Offer/Answer Protocol (ROAP) Gateway", Cullen Jennings, Suhas Nandakumar, Christer Holmberg, 24-Oct-11, This document proposes behavior of a RTCWeb signaling gateway for mapping message representations between RTCWeb Offer/Answer Protocol (ROAP) scheme and native SIP messaging scheme. Such a signaling gateway is intended to translate to and from/SIP for enabling use cases between a RTCWeb enabled browser and legacy SIP devices. "RTCWeb Datagram Connection", Randell Jesup, Salvatore Loreto, Michael Tuexen, 31-Oct-11, This document investigates the possibilities for designing a generic transport service that allows Web Browser to exchange generic data in a peer to peer way. Several, already standardized by IETF, transport protocols and their properties are investigated in order to identify the most appropriate one. "Multicast Proxy in IPv6/IPv4 Transition", Sheng Jiang, Dujuan Gu, Yu Fu, 24-Oct-11, During the long co-existing period of IPv6 and IPv4, the interoperation between IPv6 network and IPv4 network is essential. Multicast services across IPv6 and IPv4 networks are also needed. Besides the packet-based multicast translation mechanism, this document describes a multicast proxy solution. The solution is a multicast deployment for transition scenario. It does not propose any new protocol for multicast. The multicast proxy is deployed at the border of IPv6/IPv4 networks. It is mainly based on content cache concept. Without packet-based translation, it retires the content data from IPvX network, caches the data, and multicasts the data in IPvY network. It acts as a multicast leaf in the IPvX network where the data source locates. It also acts as a multicast source in IPvY network where the multicast client locates. "L3VPN automatical interconnection for VPN4DC", Ning So, Bhumip Khasnabish, Wu Bo, 24-Oct-11, VPN4DC provides VPN oriented datacenter service to customer through L3VPN which is consisted of (private) L3VPN in datacenter and network provider's L3VPN over wide geographical area. If we considering the two L3VPN in two different AS, [RFC4364] providers three options to achieve L3VPN inter-AS connection. Both option A and B could be used to connect L3VPN in VPN4DC. This draft discusses a novel method for implementing option A, to automatically configure the VRF interface in order to interconnect the two segments of the end-to-end L3VPN. This L3VPN interconnection automation mechanism is expected to significantly reduce the VPN oriented inter-connection/service provisioning time. "Diameter Group Signaling", Mark Jones, 24-Oct-11, In large network deployments, a single Diameter peer can support over a million concurrent Diameter sessions. Recent use cases have revealed the need for Diameter peers to apply the same operation to a large group of Diameter sessions concurrently. The Diameter base protocol commands operate on a single session so these use cases could result in many thousands of command exchanges in order to enforce the same operation on each session in the group. In order to reduce signaling, it would be desirable to enable bulk operations on all (or part of) the sessions managed by a Diameter peer using a single or a few command exchanges. This document specifies the Diameter protocol extensions to achieve this signaling optimization. "Loop Detection Mechanisms for Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs)", Hadriel Kaplan, Victor Pascual, 24-Oct-11, SIP Back-to-Back User Agents (B2BUAs) can cause unending SIP request routing loops because, as User Agent Clients, they can generate SIP requests with new Max-Forwards values. This document discusses the difficulties associated with loop detection for B2BUAs, and requirements for them to prevent infinite loops. "Requirements for Interworking WebRTC with Current SIP Deployments", Hadriel Kaplan, 22-Nov-11, The IETF RTCWEB WG has been discussing how to interwork WebRTC with deployed SIP equipment and domains. Doing so may require an Interworking Function middlebox in the media-plane. This document lists some WebRTC-to-SIP use-cases, the WebRTC requirements to support such, and the complexity involved in interworking if the requirements cannot be met. "Data Center Reference Architectures", Manish Karir, Ian Foo, 24-Oct-11, The continued growth of large-scale data centers has resulted in a wide range of architectures and designs. Each design is tuned to address the challenges and requirements of the specific applications and workload that the data is being built for. Each design evolves as engineering solutions are developed to workaround limitations of existing protocols, hardware, as well as software implementations. The goal of this document is to characterize this problem space in detail in order to better understand if there is any gap in making address resolution scale in various network designs for data centers. In particular it is our goal to peel back the various optimization and engineering solutions to develop generalized reference architectures for a data center. We also discuss the various factors that influence design choices in developing various data center designs. "Corresponding Auto Names for IPv6 Addresses", Hiroshi Kitamura, Shingo Ata, 24-Oct-11, This document discusses notion and actual mechanisms of "Corresponding Auto Names" for IPv6 Addresses. With this mechanism, all IPv6 addresses (even if they are link-local scoped addresses) can obtain their own Names, and it will be able to use Names anywhere instead of IPv6 Addresses. IPv6 address is too long and complicated to remember, and it is very nuisance thing to type a literal IPv6 address manually as an argument of applications. Also, it is very difficult for human beings to tell which IPv6 address is set to which actual IPv6 node. In this sense, literal IPv6 address information can be called meaningless information for human beings. In order to solve above problems and to make the information meaningful, mechanisms called Corresponding Auto Names for IPv6 addresses is introduced. They will become gentle information for human beings. By applying a simple naming rule to the Auto Names (e.g., use the same name-prefix for IPv6 addresses that are set to the same interface (node)), this will contribute to help people to understand which IPv6 address / Name indicates which actual IPv6 node. "Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1", D. Kitterman, Wayne Schlitt, 24-Oct-11, E-mail on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction on what a sending host can use as the reverse-path of a message or the domain given on the SMTP HELO/EHLO commands. This document describes version 1 of the Sender Policy Framework (SPF) protocol, whereby a domain may explicitly authorize the hosts that are allowed to use its domain name, and a receiving host may check such authorization. "Problem Statement for VPN As A Service", Edward Wang, Robert Raszuk, 28-Oct-11, This document examines the problems and challenges associated with the process of setting up secure connections between authorized network nodes. The network nodes can be located anywhere in a private or public network, directly connected or behind one or more levels of NAT. Setting up a secure connection in this environment entails the resolution of various issues such as authentication, peer discovery, virtual network address management, routing information exchange and connection parameters determination. "Service Selection for Mobile IPv6", Vijay Devarapalli, Ulf Nilsson, Jouni Korhonen, 24-Oct-11, In some Mobile IPv6 deployments, identifying the mobile node or the mobility service subscriber is not enough to distinguish between multiple services possibly provisioned to the said mobile node and its mobility service subscription. A capability to specify different services in addition to the mobile node identity can be leveraged to provide flexibility for mobility service providers on provisioning multiple services to one mobility service subscription. This document describes a Service Selection Mobility Option for both conventional Mobile IPv6 and Proxy Mobile IPv6 that is intended to assist home agents and local mobility agents to make a specific service selection for the mobility service subscription during the binding registration procedure. This specification updates RFC 5213. "Accurate ECN Feedback Option in TCP", Mirja Kuehlewind, Richard Scheffenegger, 24-Oct-11, This document specifies an TCP option to get accurate Explicit Congestion Notification (ECN) feedback from the receiver. ECN is an IP/TCP mechanism where network nodes can mark IP packets instead of dropping them to indicate congestion to the end-points. An ECN- capable receiver will feedback this information to the sender. ECN is specified for TCP in such a way that only one feedback signal can be transmitted per Round-Trip Time (RTT). Recently new TCP mechanisms like ConEx or DCTCP need more accurate feedback information in the case where more than one marking is received in one RTT. This TCP extension can be used in addition to the classic ECN as well as with a more accurate ECN scheme recently proposed which reuses the ECN bit in the TCP header. "Design Considerations for a DECADE SDT", Dirk Kutscher, Martin Stiemerling, Jan Seedorf, 24-Oct-11, This memo provides some considerations for the design of a specific DECADE protocol. "Experience with the LOADng routing protocol for LLNs", Thomas Clausen, Alberto Camacho, Jiazi Yi, Axel Verdiere, Yuichi Igarashi, Yoko Morii, 27-Oct-11, This document reports experience with the LOADng routing protocol for LLNs which is specified in the draft-clausen-lln-loadng internet draft. This report is providing information resulting from interoperability testing performed at Hitachi YRL facilities in Yokohama, Japan, from october 17th to october 19th 2011. "Real-Time Transport Protocol (RTP) Usage for Telepresence Sessions", Allyn Romanow, Jonathan Lennox, Paul Witty, 6-Feb-12, This document describes mechanisms and recommended practice for transmitting the media streams of telepresence sessions using the Real-Time Transport Protocol (RTP). "Multiplexing Multiple Media Types In a Single Real-Time Transport Protocol (RTP) Session", Jonathan Rosenberg, Jonathan Lennox, 24-Oct-11, This document describes mechanisms and recommended practice for transmitting media streams of multiple media types (e.g., audio and video) over a single Real-Time Transport Protocol (RTP) session, primarily for the use of Real-Time Communication for the Web (rtcweb). "DS-Lite Intra-Domain Automatic Tunnel", Zhenqiang Li, Qin Zhao, Xiaohong Huang, Yan Ma, 24-Oct-11, This document specifies an automatic tunneling mechanism for providing IPv4 connectivity service to IPv6 end users in the same DS- Lite domain. Key aspects include stateless operation and algorithmic mapping between IPv4 addresses and IPv6 tunnel endpoints. "Per-Host Locators for Distributed Mobility Management", Marco Liebsch, 24-Oct-11, Mobile operators consider the distribution of mobility anchors to enable offloading some traffic from their core network. In scope of a solution for Distributed Mobility Management is the maintenance of IP sessions and IP address continuity when mobile nodes get a new mobility anchor assigned during handover. This document proposes the use of identifier-locator split concepts to achieve optimal routing of data packets to a mobile node's current mobility anchor. The use of per-host locator IP addresses allows translation of addresses within the mobile operator network to route packets to the mobile node's current mobility anchor, while address translation is kept transparent to the communication endpoints. "Quality of Service Option for Proxy Mobile IPv6", Pierrick Seite, Marco Liebsch, Jouni Korhonen, Sri Gundavelli, Hidetoshi Yokota, 24-Oct-11, This specification defines a new mobility option that can be used by the mobiliy entities in the Proxy Mobile IPv6 domain for exchanging the Quality of Service parameters associated with the subscriber flows. Specifically, the local mobility anchor in the home network can potentially send the QoS parameters to the mobile access gateway in the access network. This document also explains how the mobile access gateway in the access network can map the received QoS options to the access specific semantics, such us using 802.11e in case of IEEE 802.11 and apply it on the air interface. "A Cost Perspective on Using Multiple CDNs", Hongqiang Liu, 24-Oct-11, This document describes several potential price and charge issues in CDN interconnection. It discusses some optional charge models when CDNs are interconnected and presents a need from Content Service Providers (CSP) or CDNs to optimize their cost locally and guarantee their performance. It finally shows how can CDNI frameworks and protocols support price, charge and policy information exchanging. "MPLS-TP protection for interconnected rings", Yaacov Weingarten, 24-Oct-11, According to the ring protection Requirements in RFC 5654, Requirement 93 : When a network is constructed from interconnected rings, MPLS-TP MUST support recovery mechanisms that protect user data that traverses more than one ring. This includes the possibility of failure of the ring-interconnect nodes and links,so this document will describle all kinds of interconnected rings Scenario and a few possible solutions for recovery the failure of the ring-interconnect nodes and Links. . This document is a product of a joint Internet 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. "dhcp option for CoAP Proxy Discovery", Yuanchen Ma, Xuan He, 24-Oct-11, CoAP utilizes DNS to discovery the IP address of the CoAP server. However DNS is heavy for the most resource constrained end-points. In this case the assistance from CoAP proxy or research directory (RD) is needed for CoAP transaction. This specification proposes to define one new dhcp option for proxy/RD discovery for the most resource constrained end-points. "Network-based Inter-domain handover Support for Proxy Mobile IPv6", Zhengming Ma, Ke Wang, Fei Zhang, 4-Jan-12, [RFC5213] prompts the Inner-domain handover of the MN in Proxy Mobile IPv6(PMIPv6).This document describes network-based Inter-domain handover functionality and corresponding mobility options for PMIPv6.This document strictly abides by the three principle describes in PMIPv6: (a)The movement of MN is transparent to CN. (b)MN doesn't participate in any mobility-related signaling.LMA and MAG are responsible for managing IP mobility on behalf of the host. (c)This document is compatible with RFC5213. The points of this document are as follows: (1) Concepts: The MN's Home Agent(HA) ,Home Address (HoA) and Care-of address(CoA) is not only for user but also for the specific session.MN initiating a session uses the address assigned by the LMA which the MN is registered at the moment as the HoA for the session.The user initiating a session uses the address assigned by the LMA which the MN moves to as the CoA for the session. (2) Binding Cache:Every local mobility anchor must maintain two Binding Cache entries for each currently registered mobile node. One is Inner-domain BCE,the other is Inter-domain BCE. Inner-domain BCE maintains the binding between MN's Proxy-CoA and MN's HoA. Inter- domain BCE maintains the bingding between CN's HoA and CN's CoA. (3)Communication:For the user initiating a session or accepting a session,no matter how it moves,the HoA for the session is unchanged,the source address of the data packets is the user's own HoA,and the destination address of the the data packets is the HoA of CN.The local mobility anchor will check all the packets received from the mobile access gateway.If both the source address of the data packets is the MN's HoA recorded in Inner-domain BCE,and the CN's HoA and CoA recorded in Inter-domain BCE are the same,the LMA will route the packets directly to CN as described in RFC5213.Otherwise, according to looking up the Inter-domain BCE,LMA gets the CoA of CN. Then ,LMA encapsulates the packets to route to CN.On receiving a packet from a correspondent node with the destination address matching a mobile node's home network prefix(es), the CN's LMA MUST first check the source address and the destination address of the data packets,if the source address of the data packets is MN's HoA recorded in Inter-domain BCE and the destination address is CN's HoA recorded in Inner-domain BCE ,the CN'LMA will forward the packets to the right MAG directly as described in RFC5213.Otherwise, CN'LMA will remove the outer header before forwarding the packet. Then,LMA looks up the Inner-domain BCE to forward the packets to the right MAG. (4)Updates:When MN moves to visited LMA(MN-vLMA),MN-vLMA will do three things. Firstly MN-vLMA will assign a MN-CoA for MN and build up the Inner- domain BCE for MN. Secondly,MN-vLMA will sends message to MN-hLMA to get the HoA of CN .Then,MN-vLMA builds up the binding between CN-HoA and CN-HoA in the Inter-domain BCE.Thirdly, MN-vLMA sends message to CN-LMA wiht the MN-CoA and MN-HoA included in the message to help CN- LMA updating the Inter-domain BCE for MN. Compared with "draft-ma-netext-pmip-handover-00.txt", this document is compatible with RFC5213 and the LMA described in this document should decide if it is necessary to encapsulate the packets.In other word,if MN and CN are both in their home domain,they will communicate just as the way described in RFC5213 and otherwise they will communicate in the way described in this document. "Cloud Bursting Use Case", Dave McDysan, 24-Oct-11, This draft describes a use case for the overall coordination, control and management of "cloud bursting" in a hybrid cloud computing environment involving a private data center and a public or virtual private multi-tenant data center. This use case may be relevant to the Software Driven Network Protocol [SDN_UC], VPN for Data Center [VPN4DC], or Cross Stratum Optimization [CSO] discussions in the IETF. "DHCPv6 Options for Mapping of Address and Port", Tomasz Mrugalski, Mohamed Boucadair, Xiaohong Deng, Ole Troan, Congxiao Bao, 23-Jan-12, Generic mechanism for mapping between an IPv4 prefix, address or parts of thereof, and transport layer ports and an IPv6 prefix or address is specified in [I-D.mdt-softwire-mapping-address-and-port]. This is a companion document that specifies provisioning mechanism of MAP rules. It defines DHCPv6 options which are meant to be used between Customer Edge (CE) devices and DHCPv6 server to obtain necessary parameters to configure MAP rules. Since specification of MAP architecture is still expected to evolve, DHCPv6 options may have to evolve too to fit the revised MAP specification. "Mapping of Address and Port (MAP)", Congxiao Bao, Ole Troan, Satoru Matsushima, Tetsuya Murakami, Xing Li, 30-Jan-12, This document describes a generic mechanism for mapping between IPv4 addresses and IPv6 addresses and transport layer ports. "2547 egress PE Fast Failure Protection", Maciek Konstantynowicz, Jeyananth Jeganathan, 24-Oct-11, This document specifies a mechanism for protecting RFC2547 based VPN service against egress node failure. The mechanism enables local repair to be performed immediately upon a egress node failure. In particular, the router at point of local repair (PLR) can redirect VPN traffic to a protector to repair in the order of tens of milliseconds, achieving fast protection that is comparable to MPLS fast reroute. "TICTOC Security Requirements", Tal Mizrahi, 24-Oct-11, As time synchronization protocols are becoming increasingly common and widely deployed, concern about their exposure to various security threats is increasing. This document defines a set of requirements for security solutions for time synchronization protocols, focusing on the IEEE 1588 and NTP. This document also discusses the security impacts of time synchronization protocol practices, the time synchronization performance implications of external security practices, the dependencies between other security services and time synchronization. "Application Bridging for Federation Beyond the Web (ABFAB) Trust Router Protocol", Margaret Wasserman, Sam Hartman, Josh Howlett, 31-Oct-11, A Trust Router is an infrastucture element used to construct multihop Application Bridging for Federated Authentication Beyond the Web (ABFAB) federations, as discussed in draft-mrw-abfab-multihop-fed-01.txt. This document defines both the Trust Router Protocol and the Trust Path Query, as discussed in the multihop federation document. "URI Scheme for Session Traversal Utilities for NAT (STUN) Protocol", Suhas Nandakumar, Gonzalo Salgueiro, Paul Jones, 24-Oct-11, This document is the specification of the syntax and semantics of the Uniform Resource Identifier (URI) scheme for the Session Traversal Utilities for NAT (STUN) protocol. "URI Scheme for Traversal Using Relays around NAT (TURN) Protocol", Suhas Nandakumar, Gonzalo Salgueiro, Paul Jones, 24-Oct-11, This document is the specification of the syntax and semantics of the Uniform Resource Identifier (URI) scheme for the Traversal Using Relays around NAT (TURN) protocol. "Configuration and service discovery of IPv6 capable sensors", Basavaraj Patil, Carles Gomez, Johanna Nieminen, Markus Isomaki, Teemu Savolainen, Zach Shelby, 31-Oct-11, The number and type of Internet connected devices continues to grow rapidly. Sensors are a new category of devices that are becoming Internet connected. While sensors have existed for a long time, it is only now that we see sensors being capable of communicating via an IP stack. Sensors are used in a multitude of industries and applications. By enabling these devices to be Internet connected, they open up new vistas in terms of applications and uses. Most sensors are generally small with minimal power and processing capabilities. The ability to configure these devices is a challenge. However, in order to make the usage and deployment of Internet connected sensors easier, it is essential that there exist a well defined configuration, control, and service discovery mechanism. This document illustrates various use cases of sensors in different types of deployments and a solution for configuring and controlling them in addition to the ability for sensors and devices to discover services. "Basic Device Classification", Bruce Nordman, 24-Oct-11, This specification addresses how to communicate a basic sense of the type of each device present on the network. This is particularly important as the range of devices with connectivity greatly expands, and as indirect interests in device characteristics increase, such as energy consumption. Many applications will benefit from a single standard enumeration of basic device types. This draft does not address detailed device characteristics or subtypes. The draft also discusses related identify information. It is an initial discussion document to generate feedback and improvement. "Power Locator", Bruce Nordman, Steven Lanzisera, 24-Oct-11, This specification addresses how to request that a device should enter a "power locator" mode for a limited period of time. The mode involves a device cycling between a low and high power level in a predictable manner so that a power metering device upstream in the power distribution system can sense the signal and so determine where the device draws its power from. This will be useful in many types of buildings, particularly data centers and large commercial buildings. This draft addresses operation of the device carrying out the request, but not detailed operation of the device that makes the request and interprets the results. This draft is an initial discussion document to generate feedback and improvement. "Control Messages Protocol for Use with Network Time Protocol Version 4", David Mills, David Hart, Harlan Stenn, 31-Oct-11, This document describes the structure of the control messages used with the Network Time Protocol. These control messages can be used to monitor and control the Network Time Protocol application running on any IP network attached computer. The information in this informational RFC was originally described in Appendix B of RFC 1305. "Practically Secure DNS", Masataka Ohta, 24-Oct-11, Plain DNS without PKI is secure, if a chain of query/response communications between a client and an authoritative server relayed by zero or more intermediate resolvers and the authoritative server and all the resolvers are secure. However, because of short (16bit) message ID, the communications composing the chain are not very secure without, or even with (port exhaustion attack is possible), source port randomization. Still, plain DNS can be made practically secure, if the client makes two queries with independent message IDs to an address of a server (a resolver or a name server) and confirm that two replies are identical. "draft-oiwa-http-auth-extension", Tatsuya Hayashi, Yuichi Ioku, Boku Kihara, Yutaka Oiwa, Hiromitsu Takagi, Hajime Watanabe, 24-Oct-11, This document specifies an extension of HTTP authentication framework for use with interactive clients. Recently, the fundamental features of HTTP-level authentication is not enough for complex requirements of various Web-based applications. This makes these applications to implement their own authentication frameworks using HTML Forms and other means, which becomes one of the hurdles against introducing secure authentication mechanisms handled jointly by servers and user- agent clients. The extended framework fills gaps between Web application requirements and HTTP authentication provisions to solve the above problems, while maintaining some upper-compatibility against existing Web and non-Web uses of HTTP authentications. "Stateless Deterministic NAT", Reinaldo Penno, Alain Durand, Lionel Hoffmann, 31-Oct-11, This memo define a simple stateless and deterministic mode of operating a carrier-grade NAT in both a NAT44 and DS-Lite environment. "Verification Involving PSTN Reachability (VIPR): Framework", Marc Petit-Huguenin, Cullen Jennings, Jonathan Rosenberg, 24-Oct-11, This document describes the framework for Verification Involving PSTN Reachability (VIPR), a set of protocols to automatically and securely provision SIP routes between domains. "CDNI Footprint Advertisement", Stefano Previdi, Francois Faucheur, Francois Faucheur, Jan Medved, 24-Oct-11, This document describes the use of BGP for Content Delivery Networks (CDNs) in order to advertise information about footprint and connectivity to footprint in the context of CDNI. "The Generalized Object Encoding (GOE) LDPC-Staircase FEC Scheme", Aline Roumy, Bessem Sayadi, Vincent Roca, 24-Oct-11, This document describes a Generalized Object Encoding (GOE) FEC Scheme for the protection of one or multiple objects, in the context of a Content Delivery Protocol (CDP) like FLUTE/ALC, FCAST/ALC or FCAST/NORM. Unlike [RFC5052], the GOE approach [GOE] decouples the definition of Generalized Objects over which FEC encoding takes place homogeneously, from the natural source object boundaries. This separation enables either an Unequal Erasure Protection (UEP) of different portions of a given source object, or an efficient and global protection of a set of potentially small files, depending on the way the Generalized Objects are defined. The present document defines the GOE LDPC-Staircase FEC Scheme, i.e., the GOE version of the FEC Encoding ID 3 (LDPC-Staircase) defined in [RFC5170] with the further restriction that the number of encoding symbols per group (i.e., the number of symbols sent in the same packet) MUST be equal to 1 (G=1). This document does not change the LDPC-Staircase code definition, and therefore it inherits most of [RFC5170]. It only modifies the FEC Payload ID and FEC OTI, i.e., it addresses the problem of UEP and efficient file bundle protection by means of pure signaling approach. "JavaScript Object Notation (JSON) Namespaces", Joe Hildebrand, Matthew Miller, Peter Saint-Andre, 24-Oct-11, This document defines a convention for namespaced variable names in JavaScript Object Notation (JSON) data. "SMTP Service Extension for Greylisting Operations", Evan Harris, Hector Santos, 26-Oct-11, GREYLIST is a SMTP extension to formalize the widely supported Greylisting mail filtering method and to help support SMTP rejected transports by following a new formal structured 4yz server temporary rejection response by including a "retry=time-delay" tag string which SMTP clients can use to optimize the rescheduling of the mail delivery attempts. With adoption, network overhead reduction in wasteful mail delivery attempts will be realized. "Considerations for Route Reflection and EBGP", John Scudder, 24-Oct-11, Although originally conceived of as a purely IBGP device, in some cases a route reflector may function as an EBGP speaker in addition to its role as envisioned in RFC 4456. When it does so, just like any other EBGP speaker it must advertise its routes to its IBGP peers. This document explains what behavior is required of a route reflector that also functions as an EBGP speaker. It also clarifies the use of the ORIGINATOR_ID and CLUSTER_LIST attributes in this environment. "SM2 Digital Signature Algorithm", Sean Shen, Sean Shen, 24-Oct-11, This document discribles an Digital Signature Algorithm based on elliptic curves which is invented by Xiaoyun Wang et al. This digital signature algorithm is published by Chinese Commercial Cryptography Administration Office for the use of electronic authentication service system. The document *** published by Chinese Commercial Cryptography Administration Office includes four parts: general introdocution, Digital Signature Algorithm, Key Exchange Protocol and Public Key Encryption Algorithm. This document only gives the general introduction and digital signature algorithm. "SM3 Hash function", Sean Shen, Sean Shen, 24-Oct-11, This document discribles an hash function which is invented by Xiaoyun Wang et al. This hash function is published by Chinese Commercial Cryptography Administration Office for the use of electronic authentication service system. "Multicast services support for distributed mobility architecture", Seil Jeon, Young-Han Kim, 24-Oct-11, IP multicasting is expected to become essential technique for mobile video services. As the mobility management is being covered with distributed manner, corresponding IP multicasting is also required to fit the distributed manner. This document specifies IP multicasting support method and procedures for distributed mobility architecture. "Open In-The-Wire Protocol for RTC-Web", Inaki Castillo, Jose Millan, Saul Corretge, 24-Oct-11, RTC-Web clients communicate with a server in order to request or manage realtime communications with other users. This document exposes four hypothetical and different RTC-Web scenarios and analyzes the requirements of the in-the-wire protocol in each of them. The aim of this document is to make RTC-Web properly fit in the nature of the Web. "A Survey of Trust Models and Relationships in Internet Protocols", Joel Snyder, Karen O'Donoghue, 24-Oct-11, This document reviews common Internet protocols and discusses how each protocol establishes, maintains, and tears down trust relationships within the protocol. This document includes discussion of "meta" trust issues, including extra-protocol trust creation, management, and destruction. In cases where specific issues related to establishment of trust have been documented, these are discussed as well. By examining both similarities and differences between different protocols, this document can help protocol designers and maintainers in IETF working groups learn from successful (and un- successful) Internet protocols. "Requirements of Layer 3 Virtual Private Network for Data Centers", Dave McDysan, Ning So, Henry Yu, John Heinz, 24-Oct-11, This contribution addresses service provider requirements to provide host-to-host connectivity through Layer 3 Virtual Private Networks (L3VPNs). It describes the use cases and the characteristics of hosts in data centers automatically joining the L3VPN. It specifies the requirements on how to maintain and manage such host-to-host connectivity through L3VPN, so that automated provisioning, monitoring, and reporting of the cloud services can be achieved. "metadata for CDNs Interconnection", Bertrand Gilles, Fieau Frederic, Pages Remi, Stephan Emile, 24-Oct-11, There are use cases where the delivery of contents by a CDN on the behalf of another requires the exchange of extra information between these CDNs. This memo proposes a RESTful framework for the exchange of content distribution metadata between an upstream and a downstream CDN. Then it applies this framework to the use cases selected by te CDNi WG [I-D.ietf-cdni-use-cases] to identify relevant operations, objects and information elements of the CDNi metadata interface and to verify that the RESTful approach suits for these operations. "Software Driven Networks: Use Cases and Framework", Dimitri Stiliadis, Florin Balus, Mircea Pisica, Nabil Bitar, Wim Henderickx, 31-Oct-11, This document presents an application framework and associated use cases to help define the scope of the SDNP working group. The use cases start with an abstract representation of a multi-tier application and illustrate the composition of a network service that can meet the requirements of the particular application. The service composition process is split into several steps, including application requirement specification, network mapping, service binding, and policy control. We also provide examples of interactions between an SDNP controller and L2 and L3 control layer protocols in order to deliver the end-to-end service. Finally, as a derivate of that, an architecture framework for SDNP that meets these requirements is proposed. "Problem Statement of Flow Mobility Triggering", Tian Tian, Wei Yan, Yuan Wei, 24-Oct-11, This document is a contribution draft which summaries the potential approaches for flow mobility triggering and gives analysis of these trigger methods based on the long-standing active discussion in the mailing list, which aims to achieve a common consensus on the issues and the working scope related to flow mobility trigger in Netext WG. "Shared Use of Experimental TCP Options", Joseph Touch, 24-Oct-11, This document describes how TCP option codepoints can support concurrent experiments. The suggested mechanism avoids the need for a coordinated registry, and is backward-compatible with currently known uses. "The Use of G-IKEv2 for Multicast Router Key Management", Brian Weis, Paulina Tran, 24-Oct-11, The G-IKEv2 key management protocol protects group traffic, usually in the form of IP multicast communications between a set of network devices. G-IKEv2 can be used to protect the communications of routing protocols using a one-to-many or many-to-many communications model. "An Inquiry into the Nature and the Causes of Web Insecurity", Hannes Tschofenig, Mike Hanson, Sean Turner, 24-Oct-11, The year 2011 has been quite exciting from a Web security point of view: a number of high-profile security incidents have gotten a lot of press attention but also new initiatives, such as the National Strategy for Trusted Identities in Cyberspace (NSTIC), had been launched to improve the Web identity eco-system. The NSTIC strategy paper, for example, observes problems with Internet security due to the widespread usage of low-entropy passwords and the lack of widely deployed authentication and attribute assurance services. With this memorandum we try to develop a shared vision for how to deal with the most pressing Internet security problems. "Measuring IPv6 Traffic in BitTorrent Networks", Eric Vyncke, Martin Defeche, 24-Oct-11, This document is a follow-up of a University thesis which aims to measure the evolution over time of IPv6 traffic and to analyze the geographical distribution of IPv6 nodes. The first measurements were done during the Summer 2009 using a specific-purpose program which connects to the BitTorrent peer-to-peer network and this document adds measurements done with the same program but in October 2011 (2 years later). The study was made in Peer-to-Peer (P2P) networks because they are responsible for most Internet traffic and because their structure and functioning permit a rapid discovery of a large number of nodes from all over the world. In addition, the P2P users are more likely to be interested by IPv6 as IPv6 does not have the same NAT problems as IPv4. "Port Control Protocol (PCP) Authentication Mechanism", Dacheng Zhang, Margaret Wasserman, Sam Hartman, 31-Oct-11, An IPv4 or IPv6 host can use the Port Control Protocol (PCP) to flexibly manage the IP address and port mapping information on Network Address Translators (NATs) or firewalls, to facilitate communications with remote hosts. However, the un-controlled generation or deletion of IP address mappings on such network devices may cause security risks and should be avoided. In some cases the client may need to prove that it is authorized to modify, create or delete PCP mappings. This document proposes an in-band authentication mechanism for PCP that can be used in those cases. The Extensible Authentication Protocol (EAP) is used to perform authentication between PCP devices. "Transport Options for Clue", Stephan Wenger, Marshall Eubanks, Roni Even, Gonzalo Camarillo, 24-Oct-11, This memo describes the assumption and the proposed options for the coding and transport of CLUE messages as outlined in version 01 of the framework draft. "Multiple Synchronization sources (SSRC) in RTP Session Signaling", Magnus Westerlund, Bo Burman, Fredrik Jansson, 24-Oct-11, RTP has always been a protocol that supports multiple participants each sending their own media streams in an RTP session. Unfortunately many implementations are designed only for point to point voice over IP with a single source in each end-point. Even client implementations aimed at video conferences have often been built with the assumption around central mixers that only deliver a single media stream per media type. Thus any application that wants to allow for more advance usage where multiple media streams are sent and received by an end-point has an issue with legacy implementations. This document describes the problem and proposes a solution for how to use multiple SSRCs within one RTP session and at the same time handle the legacy issues. "RTP Multiplexing Architecture", Magnus Westerlund, Bo Burman, Colin Perkins, 24-Oct-11, RTP has always been a protocol that supports multiple participants each sending their own media streams in an RTP session. Thus relying on the three main multiplexing points in RTP; RTP session, SSRC and Payload Type for their various needs. However, most usages of RTP have been less complex often with a single SSRC in each direction, with a single RTP session per media type. But the more complex usages start to be more common and thus guidance on how to use RTP in various complex cases are needed. This document analyzes a number of cases and discusses the usage of the various multiplexing points and the need for functionality when defining RTP/RTCP extensions that utilize multiple RTP streams and multiple RTP sessions. "Using Simulcast in RTP sessions", Magnus Westerlund, Bo Burman, Morgan Lindqvist, Fredrik Jansson, 24-Oct-11, In some applications it may be necessary to send multiple media streams derived from the same media source. This is called Simulcast. This document discusses the best way of accomplishing this in RTP. It is concluded that a session based solution provides best support for simulcast, and a solution for that is defined. There are two necessary extensions. The first extension is how to group RTP sessions belonging to the same simulcast source using the grouping framework, and the second is how to identify which SSRCs that are the same media source by using a new RTCP SDES item SRCNAME. "RTCP SDES Item SRCNAME to Label Individual Sources", Magnus Westerlund, Bo Burman, Patrik Sandgren, 24-Oct-11, This document defines a new SDES item called SRCNAME which uniquely identifies a single media source, like a camera or a microphone. That way anyone receiving the SDES information from a set of interlinked RTP sessions can determine which SSRCs are related to the same source. It can equally be used to label SSRC multiplexed related streams, such as FEC or Retransmission streams related to the original source stream in the same session. In addition the new SDES item is also defined for usage with the SDP source specific media attribute ("a=ssrc") enabling an end-point to declare and learn the source bindings ahead of receiving RTP/RTCP packets through signalling. "RTP Media Stream Pause and Resume", Azam Akram, Bo Burman, Daniel Grondal, Magnus Westerlund, 24-Oct-11, With the increased popularity of real-time multimedia applications, users demand more control over communication sessions. This document describes how a receiver in a multimedia conversation can pause and resume incoming data from a sender by sending real-time feedback messages when using Real-time Transport Protocol (RTP) for real time data transport. This document extends the Codec Control Messages (CCM) RTCP feedback package by adding a group of new real-time feedback messages used to pause and resume RTP data streams. "Media Stream Selection (MESS)", Daniel Grondal, Bo Burman, Magnus Westerlund, 24-Oct-11, This document describes how media stream selection can be achieved in both a conferencing scenario and peer to peer communication. To allow endpoints to select specific media streams, all available media in the session must be identifiable and there is a need for messages than can be securely transported between endpoints and network nodes. This document also describes a way to distribute the identification information to all participating endpoints. The necessary messages can potentially be mapped onto several different encodings, and this document proposes one mapping that uses an extended version of the Binary Floor Control Protocol. "Extensible Bandwidth Attribute for SDP", Tomas Frankkila, Magnus Westerlund, Bo Burman, 24-Oct-11, Knowledge of what bandwidths the end-points intend to use is important both for the other end-point and for resource allocation in various types of networks. This is especially important for wireless access networks which typically have quite limited resources. The bandwidth attribute in Session Description Protocol (SDP), 'b=AS', is today quite widely used to define the bandwidth that the end-points intends to use, in various types of sessions. This document will show that the existing bandwidth attribute, such as 'b=AS', although widely used in todays scenarios, has limitations that make it hard or even impossible for the end-points to express their intentions accurately when it comes to bandwidth usage. To solve the identified problems, this document defines a new extensible SDP bandwidth attribute 'a=bw' which enables more detailed control over the bandwidth declarations, request, and allocations. With the new bandwidth attribute it is possible to define different scopes in the session setup and then negotiate the bandwidth individually for each scope. "DNS update for MIPv6", Jong-Hyouk Lee, Zhiwei Yan, 24-Oct-11, In order to update the DNS (Domain Name System)[1] resource records (RRs) for the node when its name or address changes, the DDNS (Dynamic DNS) protocol[2] has been standardized as an extension of basic DNS protocol. Then the security DDNS scheme[3] was proposed to enhance the security of DDNS. Based on these two protocols, the DNS update can be used in many scenarios, for example in the DHCP (Dynamic Host Configuration Protocol)[4] deployed environment. Based on these specifications, this document defines the extension in MIPv6 (Mobile IPv6)[5] to achieve DNS update for the named MN (Mobile Node). Specifically speaking, the FQND Option defined in the RFC4704[6] is included in the MIPv6 BU (Binding Update) signaling message. Then the PTR RR or AAAA and PTR RRs may be updated by the HA (Home Agent) when the HoA (Home Address) or name of MN changes. "Cross Stratum Optimization Architecture for Optical as a Service", Young Lee, Hui Yang, Yi Lin, Yongli Zhao, Fatai Zhang, Jie Zhang, 24-Oct-11, Data centers based applications provide a wide variety of services such as cloud computing, video gaming, grid application and others. Currently application decisions are made with little information concerning underlying network used to deliver those services so that such decisions cannot be the most optimal from both network and application resource utilization and quality of service objectives. This document presents a novel architecture of Cross Stratum Optimization for application and network resource in dynamic optical networks. Several global load balancing strategies are proposed and demonstrated by experiments in Optical as a Service experimental environment. "RADIUS Accounting Extensions of Traffic Statistics", Leaf Yeh, 31-Oct-11, This document specifies the RADIUS attributes extensions of IPv4 and IPv6 traffic statistics for the differentiated accounting policies and traffic recording on the AAA server. "L3VPN Protocol Gap Analysis for Data Centers", Lucy Yong, Susan Hares, 24-Oct-11, An enterprise may need to connect their applications hosted in offsite provider data centers to their own premises via their dedicated L3VPN. The draft reviews L3VPN protocols for this application and discusses the protocol gaps to meet the requirements of VPN4DC. [VPN4DC] "Experiment of Example Solution for VPN4DC", Delei Yu, Qing Zeng, 31-Oct-11, More and more service providers proposed VPN4DC requirements. That is how to maintain and manage the host-to-host connectivity through Layer 3 Virtual Private Networks (L3VPNs) between an enterprise legacy VPN site and the virtual datacenter (VDC) in datacenter, including automated provisioning, monitoring, and so on[VPN4DC]. This document provides an example solution by prototyping experiment for VPN4DC auto-provision. This solution is focus on the network side and the DC Edge, the DC inside is out of scope. "GMPLS OSPF-TE Extensions in support of Flexible-Grid in DWDM Networks", Daniele Ceccarelli, Fatai Zhang, Oscar Dios, Ramon Casellas, Xiaobing Zi, 24-Oct-11, This memo describes the OSPF-TE extensions in support of GMPLS control for flexible-grid in DWDM networks. "RBridge Aggregation", Donald Eastlake, Mingui Zhang, 31-Oct-11, TRILL supports multi-access TRILL links that can have multiple RBridges attached. This draft specifies RBridge Aggregation that enables concurrent data forwarding by multiple RBridges for the end stations in the same VLAN on a TRILL link without partition. RBridge Aggregation offers active/active multi-homing to multi-access TRILL links, which improves their reliability and increases the access bandwidth of RBridge campus. "TRILL IS-IS MTU Negotiation", Mingui Zhang, Xudong Zhang, Donald Eastlake, 13-Dec-11, The IETF TRILL protocol provides least cost pair-wise layer 2 data forwarding by using IS-IS link state routing. This document defines a new link MTU size negotiation mechanism to update the TRILL documents "Routing Bridges (RBridges): Base Protocol Specification" and "Routing Bridges (RBridges): Adjacency". "OSPF-TE Protocol Extension for Constraint-aware RSA in Flexi-Grid Networks", Jie Zhang, Ziyan Yu, Yongli Zhao, 24-Oct-11, ITU-T Study Group 15 has introduced a new flexible grids technology of DWDM network which is an effective solution to improve the efficiency of spectrum resource utilization. This memo extends the OSPF-TE protocol to support constraint-aware routing and spectrum assignment (RSA) in flexi-grid networks. "Protection Mechanisms for Label Distribution Protocol P2MP/MP2MP Label Switched Paths", Quintin Zhao, Emily Chen, 22-Nov-11, Service providers continue to deploy real-time multicast applications using Multicast LDP (mLDP) across MPLS networks. There is a clear need to protect these real-time applications and to provide the shortest switching times in the event of failure. This document outlines the requirements, describes the protection mechanisms available, and where necessary proposes extensions to facilitate mLDP P2MP and MP2MP LSP protection within an MPLS network. "PCEP Protocol Extension for spectrum utilization optimization in Flexi- Grid Networks", Dajiang Wang, Jie Zhang, Tiantian Peng, Xiaosong Yu, Xuping Cao, Yongli Zhao, 24-Oct-11, Flexi-grid networks overcomes the fixed grid channel of Wavelength Switched Optical Network(WSON) by flexible spectrum to allow non- uniform and dynamic allocation of spectrum based on the demand of the incoming services' LSP. Flexi-grid networks is an effective solution to solve the problem of efficient spectrum utilization. Because the client LSP needs to be assigned contiguous spectrum in flexi-grid networks, there will be two problems that would affect spectrum utilization, i.e. RSA and fragmentation. We introduce two kinds of methods which can improve the spectrum utilization further, and some related PCEP extensions are defined in this document. "Multicast Mobility Routing Optimizations for Proxy Mobile IPv6", Carlos Bernardos, Juan Zuniga, Luis Contreras, Seil Jeon, Younghan Kim, 30-Oct-11, The MULTIMOB group has specified a base solution to support IP multicasting in a PMIPv6 domain [RFC6224]. In this document, some enhancements are proposed to the base solution. These enhancements include the use of a multicast tree mobility anchor as the topological anchor point for multicast traffic, as well as a direct routing option where the MAG can provide access to multicast content in the local network. These enhancements provide benefits such as reducing multicast traffic replication and supporting different PMIPv6 deployments scenarios. "Avoid Unnecessary Upstream Traffic in BIDIR-PIM", Weesan Lee, 24-Oct-11, In a BIDIR-PIM network, data packets could be forwarded from the source to the RP and then get dropped there because there is no receiver on the other side of the distribution tree. This document specifies a way to prune the unnecessary traffic with minimum additional states and procedures. "Initial Congestion Exposure (ConEx) Deployment Examples", Bob Briscoe, 24-Nov-11, This document gives examples of how ConEx deployment might get started, focusing on unilateral deployment by a single network. "Optimizing IP Mobility Authentication with EAP", Charles Perkins, Basavaraj Patil, 27-Oct-11, The Extensible Authentication Protocol (EAP) is commonly used for access authentication in many wireless networks. EAP methods often involve AAA servers to effect the required authentications; notifications about success or failure are then relayed back to a functional module in the access network known as the Network Access Server. The Binding Authentication Data option has been defined for enabling alternative methods for authentication in the context of Mobile IPv6, and there is a subtype allocated for AAA-based authentication methods such as EAP. However, some EAP methods require additional handling that requires specification not yet available in the existing documentation for the Binding Authentication Data option. This document provides the required specification for at least some very widely deployed EAP methods. In many situations requiring the use of EAP, this enables much faster operation for Mobile IPv6 tunnel redirection to a wireless device's new care-of address by avoiding having to do multiple authentications. "An HTTP-based Decade Resource Protocol", Wang Danhua, 31-Oct-11, This document explorers the design of an HTTP-based DECADE Resource Protocol (DRP), which can be used for content and resource management between a DECADE Client and a DECADE Server, or between two DECADE Servers. We identify the function entities, and present initial protocol message flow and syntax design. The purpose of this document is to get design discussion started, not to provide a complete solution. "BFD Management Information Base (MIB) extensions for MPLS and MPLS-TP Networks", Kannan Sampath, Sam Aldrin, Thomas Nadeau, Venkatesan Mahalingam, 1-Feb-12, This draft defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it extends the BFD Management Information Base BFD- STD-MIB and describes the managed objects for modeling Bidirectional Forwarding Detection (BFD) protocol for MPLS and MPLS-TP networks. "Device to Database Protocol for White Space", John Malyar, Dan Harasty, Subir Das, 13-Nov-11, This version of the document describes a protocol design framework for Whitespace Devices to access Whitespace Database. "Improved Hierarchical Mobile IPv6 (IHMIPv6) Mobility Management", Zhengming Ma, Lin Wang, 13-Nov-11, In HMIPv6 (RFC5213), a mobile node has three IPv6 addresses: HoA, RCoA and LCoA. Outside the domain of a MAP, RCoA is used for routing, while HoA is used for authentication. Hence HA and CN should maintain the binding of RCoA and HoA. Inside the domain of a MAP, RCoA is used for authentication, while LCoA is used for routing. Hence MAP should maintain the binding of RCoA and LCoA. Since RCoA is used for authentication, it should be unique to a mobile node. Therefore, how many mobile nodes there are inside domain of a MAP, how many different RCoAs the MAP has to allocate to the mobile nodes. In this Internet Draft, an improved or alternative solution to HMIPv6 is presented, where RCoA is no longer used for authentication inside the domains of a MAP. RCoA is used only for routing outside the domain of a MAP, as LCoA does inside the domain of a MAP. Inside the domain of a MAP, HoA is used for authentication, as it does outside the domain of a MAP. Since RCoA is no longer used for authentication, only one RCoA will be enough for all mobile nodes inside the domain of a MAP. Remark: This Internet Draft is based on HMIPv6 (RFC5380). Only those parts in HMIPv6 related to RCoA have been rewritten, while the other parts in HMIPv6 remain almost unchanged. "Dynamic Mobility Anchoring", Pierrick Seite, Philippe Bertin, 13-Nov-11, Most existing IP mobility solutions are derived from Mobile IP principles where a given mobility anchor maintains Mobile Nodes (MNs) binding up-to-date. Data traffic is then encapsulated between the mobility anchor and the MN or its Access Router. These approaches are usually implemented on a centralised architectures where both MN context and traffic encapsulation need to be processed at a central network entity, i.e. the mobility anchor. However, one of the trend in mobile network evolution is to "flatten" mobility architecture by confining mobility support in the access network, e.g. at the access routers level, keeping the rest of the network unaware of the mobility events and their support. This document discusses the deployment of a Proxy Mobile IP approach in such a flat architecture. The solution allows to dynamically distribute mobility functions among access routers. The goal is also to dynamically adapt the mobility support of the MN's needs by applying traffic redirection only to MNs' flows when an IP handover occurs. "RTCP XR Report Block for QoE Metrics Reporting", Alan Clark, Martin Kastner, Geoff Hunt, 14-Nov-11, This document defines an RTCP XR Report Block that allows the reporting of QoE metrics for use in voice, audio and video services. "Modification to Default Value of MAX_SOL_RT", Ralph Droms, 14-Nov-11, This document updates RFC 3315 by redefining the default value for SOL_MAX_RT and defining an option through which a DHCPv6 server can override the client's default value for SOL_MAX_RT with a new value. "mLDP Extensions for Multi Topology Routing", IJsbrand Wijnands, Kamran Raza, 9-Jan-12, The Multi-Topology Routing (MTR) enables service differentiation through class-based forwarding. IGP protocols (OSPF and IS-IS) have already been extended to setup MTR. In order to deploy mLDP in an MTR setup, mLDP is also required to become topology-aware. This document specifies extensions to mLDP to support Multi-Topology Routing. "Jumbo Frame Deployment at Internet Exchange Points (IXPs)", Martin Levy, 14-Nov-11, This document provides guidelines on how to deploy Jumbo Frame support on Internet Exchange Points (IXP). Jumbo Frame support allows packets larger than 1,500 Bytes to be passed between IXP customers over the IXPs layer 2 fabric. This document describes methods to enable Jumbo Frame support and keep in place existing 1,500 Byte communications. This document strongly recommends that IXP operators choose 9,000 Bytes for their Jumbo Frame implementation. "JSON Reference", Paul Bryan, Kris Zyp, 24-Nov-11, JSON Reference allows a JSON value to reference another JSON value in a JSON document. "Mobile Multicast Sender Support in PMIPv6 Domains", Thomas Schmidt, Shuai Gao, Hong-Ke Zhang, Matthias Waehlisch, 14-Nov-11, Multicast communication can be enabled in Proxy Mobile IPv6 domains by deploying MLD Proxy functions at Mobile Access Gateways and multicast routing functions at Local Mobility Anchors, or by additional route optimization schemes. This document describes the support of mobile multicast senders in Proxy Mobile IPv6 domains that is provided by this base deployment scenario, as well as in settings of further optimization. Mobile sources remain agnostic of multicast mobility operations. "6rd Sunsetting", Alexandre Cassen, Mark Townsley, 14-Nov-11, This document provides guidelines for transitioning an IPv6 deployment using IPv6 Rapid Deployment (6rd) to an IPv6 deployment using Native IPv6. It is targeted at both 6rd operators and 6rd implementors." "xNAME loop detection and its usage suggestion", Jiankang Yao, XiaoDong Lee, 14-Nov-11, The Domain Name System (DNS) has provided some means, such as CNAME or DNAME, where a query can be redirected to a different name. The zone operator should be careful about this redirection, which may forms a loop. The detail analysis of xNAME loop detection and its impacts are not specified in the RFC 1035 and RFC 2672. This document gives a detail analysis of xNAME loop and its impacts. It also gives some advices for using xNAME. "Extended ICMP to support 1:N NAT64", Kevin Fang, Yu Jiang, 14-Nov-11, This memo defines the ICMP mechanism for Dual-Stateless Ipv4/Ipv6 Translation(dIVI) "dIVI Port error handling and range allocation", 14-Nov-11, This memo defines port error handling and port range allocation mechanism for Dual-Stateless Ipv4/Ipv6 Translation(dIVI) "Extended ICMP to support dIVI", Yu Jiang, 14-Nov-11, This memo defines the ICMP mechanism for Dual-Stateless Ipv4/Ipv6 Translation(dIVI) "A framework for the use of SPMEs for shared mesh protection", David Allan, Greg Mirsky, 15-Nov-11, Shared mesh protection allows a set of diversely routed paths with diverse endpoints to collectively oversubcribe protection resources. Under normal conditions no single failure will result in the capacity of the associated protection resources to be exhausted. When multiple failures occur such that more than one path in the set of paths utilizing shared protection resources is affected, the necessity arises of pre-empting traffic on the basis of business priority rather than application priority. This memo describes the use of SPMEs and TC marking as a means of indicating business priority for shared mesh protection. "Licklider Transmission Protocol (LTP), Compressed Bundle Header Encoding (CBHE), and Bundle Protocol IANA Registries", Keith Scott, Stephen Farrell, 24-Feb-12, The DTNRG research group has defined the experimental Licklider Transmission Protocol (LTP) [RFC5326] and the Compressed Bundle Header Encoding (CBHE) [RFC6260] mechanism for the 'ipn' URI scheme. Finally, RFC5050 [RFC5050] defines values for the Bundle Administrative Record Type. All of these describe fields that are subject to a registry. For the purpose of its research work, the group has created ad-hoc registries. As the specifications are stable and have multiple interoperable implementations, the group would like to hand off the registries to IANA for official custody. This document describes the actions needed to be executed by IANA. "IETF Email List Archiving, Web-based Browsing and Search Tool Requirements", Robert Sparks, 21-Feb-12, The IETF makes heavy use of email lists to conduct its work. Participants frequently need to search and browse the archives of these lists, and have asked for improved search capabilities. The current archive mechanism could also be made more efficient. This memo captures the requirements for improved email list archiving and searching systems. "Route Leak Attacks Against BGPSEC", Danny McPherson, Shane Amante, 16-Nov-11, This document describes a very simple attack vector that illustrates how RPKI-enabled BGPSEC machinery as currently defined can be easily circumvented in order to launch a Man In The Middle (MITM) attack via BGP. It is meant to serve as input to the IETF's Secure Inter-Domain Routing working group during routing security requirements discussions and subsequent specification. "The UP PIO Field: Finding Up in an Unmanaged Network", Lee Howard, 16-Nov-11, It is difficult to find a path through an unmanaged network with multiple routers. This document describes a new Prefix Information Option field which can provide information to routers to find a path. "Internet International Bank Account Number (IIBAN)", Walter Stanish, 16-Nov-11, An Internet IBAN (IIBAN) identifies an internet-based financial endpoint in a manner that is superset-compatible with the existing European Committee for Banking Standards (ECBS) International Bank Acccount Number (IBAN) standard [ISO13616]. "Internet Market Identification Code (IMIC)", Walter Stanish, 16-Nov-11, An Internet MIC (IMIC) identifies an internet-based financial market in a manner that is superset-compatible with the ISO's existing Market Identification Code (MIC) standard [ISO10383]. "Indicating Email Handling States in Trace Fields", Dave Crocker, Murray Kucherawy, 13-Jan-12, This memo registers a trace field clause for use in indicating transitions between handling queues or processing states, including enacting inter- and intra-host message transitions. This might include message quarantining, mailing list moderation, timed delivery, queueing for further analysis, or other similar causes. "SCSV for TLS Client Credential Protection", Mohamad Badra, 17-Nov-11, This document defines a special Signaling Cipher Suite Value (SCSV) "TLS_IDENTITY_PROTECTION_SCSV" to add client credential protection to the TLS protocol. "Evaluation of using SIP or an independent protocol for CLUE messaging", Robert Hansen, Allyn Romanow, 17-Nov-11, This document evaluates the advantages and disadvantages of using SIP or an independent protocol for conveying CLUE messages/ "A Modest Proposal to Update IKE's IANA Registry", Dan Harkins, 17-Nov-11, The "IPSEC Authentication Methods" registry created by IKE states that it can only be updated by Standards Track RFC. In practice, this has not been the case. This memo proposed to relax that requirement. "A Hierarchical Mobility Management in LISP network", Hongke Zhang, 19-Nov-11, This draft proposes a Hierarchical Mobility Management (HMM) in Locator/ID Separation Protocol (LISP) networks. The Internet is divided into a number of mapping domains (MDs). An agent Tunnel Router (ATR) as an agent of each MD manages the Mobile Node's EID-to- RLOC mapping. For the movement within the MD, the ATR keeps the EID- to-RLOC mapping invariable, so it avoids the mapping update in the mapping system and the Tunnel Router (TR) of each correspondent node. For the handover between different MDs, to support fast update and handover, a united mapping table is proposed in the ATR. "Access Control Protocol (ACP)", Karel Burda, I Strasil, T Pelka, P Stancik, 5-Dec-11, Access Control Protocol (ACP) is a protocol for unified implementation of various methods for computer device access control. The protocol allows two devices to negotiate required assets, negotiate an authentication method, do authentication, deliver the access parameters and do accounting, all within one so called "transaction". Separate transactions can be joined so that more devices can be added to the access control operation. "The Requirements and Tentative Solutions for SAVI in IPv4/IPv6 Transition", Hui Deng, Guangwu Hu, Jun Bi, Mingwei Xu, Fan Shi, 21-Nov-11, SAVI Working Group is developing standardize mechanisms that prevent nodes attached to the same IP link from spoofing each other's IP addresses, and achieve IP source address validation at a finer granularity. Unfortunately, up to now, SAVI switch only works under the scenario of pure wire/wireless IPv6 Ethernet access subnet. In the current stage of IPv4/IPv6 transition which can't be cross over, SAVI has to make more progress to adapt it. This document describes the requirements and gives tentative solutions for the SAVI in IP4/IPv6 transition period. In RFC5565, Wu et.al proposal a softwire mesh framework to address the problem of routing information and data packets of one protocol how to pass through a single-protocol network of the other protocol. According to the real situation of CNGI-CERNET and China Telecom, document takes scenario of IPv4 packets transit IPv6 network into account. "Certificate Revocation List (CRL) Extensions for Backward-Compatible Whitelist Provision", Kyle Hamilton, 22-Nov-11, We describe two extensions to the Certificate Revocation List v2 to more strongly identify revoked and legitimately issued certificates. This creates a means for non-CA OCSP responders which are fed by CRL and can parse these extensions to presume that unlisted or non- matching certificates from that Issuer are REVOKED rather than UNKNOWN, as well as creating a means by which the Issuer can provide digest values for stronger certificate authentication. Placing issuance data within the CRL in some ways violates the original intent of the CRL, but CRLv2 has places for Extensions. It is a logical extension to permit existing buildout to address newly- exploited vulnerabilities in the model. A new crlEntryExtension is defined to permit the optional provision of several hashes of each certificate on the list of revoked certificates. In addition, a new crlExtension is defined to provide serial numbers and hashes of issued certificates. Neither of these extensions needs to be marked critical, and the original semantics are preserved for existing clients. Notably, no data format or protocol of PKIX can currently utilize any extra hashes to provide any extra authentication or security. Nevertheless, until there is a standard way for the CA issuer to provide these digest values, it's impossible to build anything which uses them. The downside: Whitelist CRLs with strong certificate authentication data are *huge*. The canonical 1MB CRL example would, if extended with this extra information, balloon to at a minimum 2.5MB (presuming random 20-byte serial numbers) to a single-digest maximum of approximately 400MB. CAs are encouraged not to alter their current CRL production, and produce these extensions only when needed by a certificate status server or consuming client. "SAVI Requirements and Solutions for ISP IPv6 Access Network", Fan Shi, Hui Deng, Liang Zhu, Guangwu Hu, 22-Nov-11, The Source Address Validation Improvement (SAVI) was developed to prevent IP source address spoofing which can enable impersonation and malicious traffic redirection. An Internet Service Provider (ISP) who provides Internet access services, information services and value- added services to the customers should guarantee security of its network and customers' privacy. Thus, the mechanism is essential for ISPs. However, due to a diversity of ISPs' access network, SAVI solution is also different accordingly. This document describes five scenarios of ISPs'IPv6 access network, and moreover, states its SAVI requirements and according tentative solutions. "Multi-hop Ad Hoc Wireless Communication", Emmanuel Baccelli, Charles Perkins, 23-Nov-11, This document describes some characteristics of communication between nodes in a multi-hop ad hoc wireless network. These are not requirements in the sense usually understood as applying to formulation of a requirements document. Nevertheless, protocol engineers and system analysts involved with designing solutions for ad hoc networks must maintain awareness of these characteristics. "The WebSocket Protocol as a Transport for the Session Initiation Protocol (SIP)", Inaki Castillo, Jose Millan, Victor Pascual, 15-Jan-12, This document specifies a WebSocket Sub-Protocol for a new transport in SIP (Session Initiation Protocol). The WebSocket protocol enables two-way realtime communication between clients and servers. "The "U" Encoding for Encoded-Words in Email", John Klensin, 24-Nov-11, The "Encoded Word" conventions have been used extensively in email headers and elsewhere to permit the encoding of non-ASCII characters where only ASCII ones are normally permitted. The existing specification defines only two kinds of encoding, one of which cannot be understood easily by people and the other of which has been widely discredited. This document specifies a third encoding that is easily accessible by users and much more closely tied to contemporary practices. The current version of the proposal is intended for possible discussion in the EAI, IRI, and PRECIS WGs to see if it sheds light on other issues being discussed in those WGs. It is not, at this point, proposed for adoption. "Receiver driven trasport protocol for CONET ICN", Stefano Salsano, Matteo Cancellieri, Andrea Detti, 25-Nov-11, Let us consider an Information Centric Networking (ICN) solution, in which an End Node requests for a content sending "content requests" (or "interest packets"). The content is provided back to the requestor by the "origin" node or by an intermediate node that had cached the content. The content is usually divided into "chunks" that can be individually requested, sent back to the requester, cached into intermediate nodes. The sending rate of content requests can be adjusted in order to perform congestion control, implementing a receiver driven transport protocol. As it can be useful to have large chunks (significantly larger than the Maximum Tranfer Unit across the network), the trasport protocol should also be used to further segment the chunks rather than relying to IP fragmentation. In this memo we define a receiver driven trasport protocol for ICN, which relies on the CONET ICN solution described in a companion draft. "The "nomap" Network Identifier Suffix", Bjoern Hoehrmann, 26-Nov-11, This memo defines a method for network operators to indicate that information about their network is broadcast only to allow legitimate participants in the network to connect or re-connect to them, and that other uses of such information are to be avoided. ""Unified MPLS Framework"", Loa Andersson, Riccardo Martinotti, 25-Jan-12, This document is framework for Unified MPLS. "LISP Delegated Database Tree", Darrel Lewis, Dino Farinacci, Vince Fuller, 28-Nov-11, This draft describes the LISP Delegated Database Tree (LISP-DDT), a hierarchical, distributed database which embodies the delegation of authority to provide mappings from LISP Endpoint Identifiers (EIDs) to Routing Locators (RLOCs). It is a statically-defined distribution of the EID namespace among a set of LISP-speaking servers, called DDT nodes. Each DDT node is configured with an EID-prefix that it "owns" plus information, including the RLOCs for Map Servers or other DDT nodes for each defined more-specific EID-prefix of the "owned" prefix. "Audio/telephone-event Codes for Operator Services and SIT Tones", John Haluska, 30-Nov-11, This document provides additional information on the use of several specific event codes related to North American Operator Services and Special Information Tones that have been registered in the IANA "audio/telephone-event" registry. "Session Description Protocol (SDP) Alternate Connectivity (ALTC): Use Cases", Mohamed Boucadair, 1-Dec-11, This memo identifies a set of use cases which motivate the specification of Session Description Protocol (SDP) Alternate Connectivity (ALTC) attribute. These use cases are specific to IPv4/ IPv6 co-existence, IPv4/IPv6 interworking and IPv6 migration. Both IPv6-related unicast and multicast are covered. ""From" and other Message Header Fields as SPF Policy Scopes", Julian Mehnle, 1-Dec-11, This document defines a new modifier for the SPF e-mail authentication protocol allowing the SPF record for a domain to be declared as being applicable to message identities other than the MAIL FROM identity, such as the "From" or "Sender" message header identities. "ALTO Incremental Updates", Nico Schwan, Bill Roome, 1-Dec-11, The goal of Application-Layer Traffic Optimization (ALTO) is to bridge the gap between network and applications by provisioning network related information. This allows applications to make informed decisions, for example when selecting a target host from a set of candidates. Therefore an ALTO server provides network and cost maps to its clients. This draft discusses options on how to provide incremental updates for these maps, with the goal of reducing the amount of data needed for transmitting the maps. "Analysis of Comparisons between OpenFlow and ForCES", Jing Huang, Xia Yin, Xingang Shi, Zhiliang Wang, Tina Tsou, 2-Dec-11, While both ForCES and OpenFlow follow the basic idea of separations of forwarding plane and control plane in network elements, they are technically very different. This document analyzes the differences between OpenFlow and ForCES technically from the aspects of goals, architecture, forwarding model and protocol interface. The two techniques can learn much from each other in their standardization process. "Allocation of an Associated Channel Code Point for Use by ISOEG Self- Destruct OAM", Doug Evil, 3-Dec-11, This document assigns an Associated Channel Type code point for carrying Self-Destruct Operations, Administration, and Management messages in the MPLS Generic Associated Channel (G-ACh). "Extending TRILL over WAN", XiaoLan Wan, XiaoPeng Yang, 6-Dec-11, TRILL is a key technology for large-scale layer 2 networking within data center, most enterprises have multiple data centers in different physical sites, TRILL over WAN(ToW) provides a scalable and simple solution that interconnect multiple TRILL networks to form a single TRILL domain using the currently deployed enterprise or service provider networks. This document provides an overview of this solution. "Representing IPv6 Zone Identifiers in Uniform Resource Identifiers", Brian Carpenter, Robert Hinden, 8-Feb-12, This document describes how the Zone Identifier of an IPv6 scoped address can be represented in a Uniform Resource Identifier that includes a literal IPv6 address. It updates RFC 3986 and RFC 4007. "Basic Requirements for Customer Edge Routers - multihoming and transition", Mark Townsley, Ole Troan, 16-Dec-11, This document specifies general IPv6 multihoming and specific 6rd transitioning requirements for an IPv6 Customer Edge (CE) router. It also provides an illustrative implementation model for IPv4 multihoming in order to support shared IPv4 transition mechanisms that utilize IPv6 as a transport for IPv4. "Why RTP Sessions Should Be Content Neutral", Harald Alvestrand, 9-Dec-11, This document is not intended for publication as an RFC. It gives the underpinning arguments for why the idea that RTP sessions and MIME top level types are related is a deeply broken paradigm, and that we need to get away from it. These arguments are solely the opinion of the listed author. "Modification to Default Value of SOL_MAX_RT", Ralph Droms, 17-Jan-12, This document updates RFC 3315 by redefining the default value for SOL_MAX_RT and defining an option through which a DHCPv6 server can override the client's default value for SOL_MAX_RT with a new value. "Address Acquisition For Multicast Content When Source and Receiver Support Differing IP Versions", Tina Tsou, 11-Dec-11, In a typical IP television (IPTV) system, the receiver acquires information about available program content, the subscriber selects a program to watch, and the receiver signals to the network to begin receiving the program in the form of multicast content. The program content information is typically XML-encoded, can be transmitted in multiple segments, possibly over multiple channels, but includes media stream descriptions for the individual program descriptions that may also be XML-encoded or may use the Session Description Protocol (SDP, RFC 4566). The media stream descriptions provide multicast group and unicast source addresses that are used in the subsequent signalling to the network. During the transition from IPv4 to IPv6, scenarios can occur where the IP version supported by the receiver differs from that supported by the source. This memo examines and evaluates alternative strategies for allowing the receiver to acquire addresses in such scenarios in the version it supports. "Content Distribution Network Interconnection (CDNI) Metadata Interface", Xiaomei Liu, Lakshminarayanan Gunaseelan, Xiaoyan He, Jincheng Li, 19-Dec-11, The Metadata Interface is one of the core interfaces defined by the IETF Content Distribution Network Interconnection (CDNI) Working Group. The primary function of the CDNI Metadata Interface is to allow interconnected CDNs to communicate metadata in order to ensure content delivery and content acquisition. This document defines the metadata exchange protocol between an upstream CDN and a downstream CDN for the content delivery. It also defines metadata objects especially condition metadata object for CDNI. "Problem Statement of IPv4 Private Addressing Support for Fixed Mobile Convergence over IPSec Tunneling", Tricci So, 12-Dec-11, IPSec IKEv2, RFC 5996 [RFC5996], has been adopted by many standardized network solutions to provide the secure transport between network elements over third party's infrastructure. For example, the emerging Fixed Mobile Convergence (FMC) network solution that involves Femtocell deployment requires the mobile operator's Femtocell AP to leverage the IPSec IKEv2 to support mutual authentication and remote IP address configuration as well as other auto configuration support over the broadband fixed network (BBF) of which the mobile and fixed networks may be operated by two different operators. Most of today broadband fixed networks are still relying on the IPv4 private addressing plan to support its attached devices including the mobile operator's Femtocell AP. Hence, the private IPv4 addressing and Network Address and Port Translation (NA(P)T) support mostly likely stays for many years to come. In FMC interworking scenario, there is a need for the mobile network to pass on it mobile subscribers' policies to the broadband fixed network (BBF) to maintain the service level agreement (SLA) and to support remote network management. In addition, a broadband fixed network (BBF) may partnership with more than one mobile operator. Therefore it is important for the BBF and the mobile network to be able to overcome the limitation of the private IPv4 addressing and to be able to identify the user's subscription as well as to determine the location of the Femtocell AP that serves its mobile user over the BBF network. This document presents the problems for the IPSec tunneling support with private IPv4 addressing for FMC interworking and proposes a simple extension to the IKEv2 to resolve the issues. "Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces", Manav Bhatia, Sami Boutros, Marc Binderberger, Jeffrey Haas, 1-Feb-12, This document proposes a mechanism to run BFD on Link Aggregation Group (LAG) interfaces. It does so by running an independent BFD async session on every LAG member link. The mechanism allows to verify the link connectivity, either in combination with or in absence of LACP, with a shorter detection time than what LACP offers. The connectivity check can also cover elements of layer 3. A dedicated well-known UDP port is introduced that all BFD packets over member links use to disambiguate those from ordinary BFD packets. "Throttling RAs on constrained interfaces", Pascal Thubert, 13-Dec-11, In a large switched topology with either many routers or routers that transmit a high rate of multicast advertisements per router, as suggested to support mobile nodes, the cost of distributing the many resulting multicast messages to certain classes of devices might be prohibitive. This is the case of a device that runs on batteries, or a device that is reachable over a wireless interface. For this device, it can be beneficial to filter a certain amount of multicast messages such as the Router Advertisement while preserving the functionality expected in the IPv6 Neighbor Discovery Protocol. "Forcing Fragmentation of IPv6 Packets", Mark Andrews, 22-Jan-12, Extend The Advanced Sockets API for IPv6 (RFC 3542) to provide a mechanism to force a Fragment header to be added to a packet. "DNS and UDP Fragmentation", Mark Andrews, 22-Jan-12, This document provides advice to DNS developers about sending DNS UDP messages and Path MTU Discovery. "Multiprotocol Label Switching Transport Profile Ring Protection", Yu jinghai, Yuefeng Ji, Guoman Liu, 14-Dec-11, according to RFC 5654 MPLS-TP Requirement, there is a paragraph for recovery requirements just as section 2.5.6.1 in RFC5654 describles: within the context of recovery in MPLS-TP networks,the optimization criteria considered in ring topologies are as follows: 1 minimize the number of OAM entities that are needed to trigger the recovery operation; 2 Minimize the number of elements of recovery in the ring; 3 Minimize the number of labels required for the protection paths across the ring; 4 minimize the amount of control and management plane transactions during maintenance operation. this document will describle two types of ring protection solutions to implement these requirements. "Prefix Delegation for Hierarchy Mobile IPv6", Zhengming Ma, Lin Wang, 14-Dec-11, This document explains how network mobility and DHCPv6-based Prefix Delegation works with hierarchy mobile IPv6. It is an extension of HMIPv6 and allows a mobile network to attach to a MAP via a mobile router. It also makes use of the mechanism of DHCPv6PD to assign mobile network prefix (es) to the mobile router which plays the role of requesting router. "IF-MAP schema for IP VPNs.", Pedro Marques, 14-Dec-11, This document defines the metadata schema used to define the route exchange policies of an IP VPN network. Information elements conforming to this schema can be distributed using the IF-MAP [if- map] specification. The schema is applicable both to the standard BGP IP VPN [RFC4364] deployments within service provider environments as well as end-system [I-D.marques-l3vpn-end-system] based deployments. "Mapping of VCard 4 Properties to LDAP objectclasses and attributes", Ciny Joy, Cyrus Daboo, 15-Dec-11, This specification describes a mapping of standard VCard 4 properties to standard LDAP objectclasses and attributes. "NARA : Network Architecture with Recursive Addressing", Dae Kim, 15-Dec-11, This document describes network architecture based on recursive addressing. The Internet is modeled as a network of autonomous sites, each being a collection of nodes. Each site is named by a site address drawn from a global number space while each node is named by a node address drawn from a number space local to each site. Routing among sites depends solely on site addresses while that within each site on node addresses. Flat routing to render inherent mobility as well as mapped routing to additionally cope with table size are proposed. The model can recursively repeat itself both outwards and inwards in the network, enabling its applicability, for example, to inter-planetary as well as body area networks. "Processing of IPv6 "atomic" fragments", Fernando Gont, 15-Dec-11, IPv6 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 hosts as "fragmented traffic". By forging ICMPv6 "Packet Too Big" error messages an attacker can cause hosts to employ "atomic fragments", and the 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 the attack vector based on "atomic fragments" is completely eliminated. "Security Implications of IPv6 options of Type 10xxxxxx", Fernando Gont, 15-Dec-11, When an IPv6 node processing an IPv6 packet does not support an IPv6 option whose two-highest-order bits of the Option Type are '10', it is required to respond with an ICMPv6 Parameter Problem error message, even if the Destination Address of the packet was a multicast address. This feature provides an amplification vector, opening the door to an IPv6 version of the 'Smurf' Denial-of-Service (DoS) attack found in IPv4 networks. This document discusses the security implications of the aforementioned options, and formally updates RFC 2460 such that this attack vector is eliminated. Additionally, it describes a number of operational mitigations that could be deployed against this attack vector. "Managing the Address Generation Policy for Stateless Address Autoconfiguration in IPv6", Fernando Gont, 15-Dec-11, This document describes an operational problem that arises due to the impossibility of managing the address generation policy employed by hosts participating in IPv6 Stateless Address Autoconfiguration (SLAAC). Additionally, it specifies a new field in the Prefix Information option of Router Advertisement messages, such that routers can advertise, for each network prefix included in a Router Advertisement message, the desired address generation policy to be used for SLAAC. "Security Implications of Predictable Fragment Identification Values", Fernando Gont, 15-Dec-11, IPv6 specifies the Fragment Header, which is employed for the fragmentation and reassembly mechanisms. The Fragment Header contains an "Identification" field which, together with the IPv6 Source Address and the IPv6 Destination Address of the packet, identifies fragments that correspond to the same original datagram, such that they can be reassembled together at the receiving host. The only requirement for setting the "Identification" value is that it must be different than that of any other fragmented packet sent recently with the same Source Address and Destination Address. Some implementations simply use a global counter for setting the Fragment Identification field, thus leading to predictable values. This document analyzes the security implications of predictable Identification values, and updates RFC 2460 specifying additional requirements for setting the Fragment Identification, such that the aforementioned security implications are mitigated. "A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)", Fernando Gont, 15-Dec-11, This document specifies a method for generating IPv6 Interface Identifiers to be used with IPv6 Stateless Address Autoconfiguration (SLAAC), such that addresses configured using this method are stable within each subnet, but the Interface Identifier changes when hosts move from one network to another. The aforementioned method is meant to be an alternative to generating Interface Identifiers based on IEEE identifiers, such that the same manageability benefits can be achieved without sacrificing the privacy of users. "Specification of a Provider-Managed Adaptive Function Between a Multicast Receiver and a Provider Network Supporting a Different IP Version", Cathy Zhou, Tom Taylor, 15-Dec-11, Discussion of the problem of multicast transition has brought out a number of scenarios that are the most likely to be encountered in practice. In some of these scenarios the IP version supported by the multicast receiver differs from that supported by the provider network to which it is attached. In such cases an adaptation function is required between the receiver and the network, to mediate the signalling and data flows between them. This memo uses the term "Type 1 Adaptation Function" (AF1) for such a function. It is written for the purpose of specifying the functions performed by an AF1. The scope of this memo is limited to the case where flows are unidirectional, from a designated set of sources to a designated (and normally much more numerous) set of receivers. The IP television (IPTV) case falls within this scope. "Applicability of Access Node Control Mechanism to WLAN based Broadband Networks", Xiangqing Chang, Yang Shi, Tom Taylor, 16-Dec-11, The purpose of this document is to provide applicability of Access Node Control Mechanism ,as described in [ANCP-FRAMEWORK],to WLAN based broadband access. The need for an Access Node Control Mechanism between a Network Access Server (NAS) and an WLAN Access Node is described.The Access Node Control Mechanism is also extended for WLAN. "An AODV Extension for Stable Route Selection", Sanghyun Ahn, Hyun Yu, 18-Dec-11, This document describes an enhancement on AODV that can allow a route with more stable intermediate nodes to be selected. For this, a new field, called the 'RouteStability' field, is introduced in the RREQ message and in the AODV routing table entry. "A Centralized MANET DNS Mechanism", Sanghyun Ahn, 18-Dec-11, This document describes a Domain Name System (DNS) mechanism for the MANET based on the centralized DNS mechanism used in the wired Internet. In order to adapt to the dynamic topology changes of the MANET, the mechanism handles the movement of the DNS server and the MANET merge/partition. "IPv6 Router Advertisement Option for NTP Server Configuration", Manav Bhatia, Dacheng Zhang, Dacheng Zhang, 19-Dec-11, This document specifies a new IPv6 Router Advertisement option to allow IPv6 routers to advertise Network Time Protocol version 4 or greater server location information to IPv6 hosts. "Experiences from Cross-Area Work at the IETF", Jari Arkko, 20-Dec-11, This memo discusses the reasons for IETF work on topics that cross area boundaries. Such cross-area work presents challenges for the organization of the IETF as well as on how interested parties can participate the work. The memo also provides some suggestions on managing these challenges. "Accurate ECN Feedback in TCP", Mirja Kuehlewind, Richard Scheffenegger, 21-Dec-11, Explicit Congestion Notification (ECN) is an IP/TCP mechanism where network nodes can mark IP packets instead of dropping them to indicate congestion to the end-points. An ECN-capable receiver will feedback this information to the sender. ECN is specified for TCP in such a way that only one feedback signal can be transmitted per Round-Trip Time (RTT). Recently new TCP mechanisms like ConEx or DCTCP need more accurate feedback information in the case where more than one marking is received in one RTT. "Internationalized Domain Name Mapping Extension for the Extensible Provisioning Protocol (EPP)", Francisco Obispo, Luis Munoz, 21-Dec-11, This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning of Internationalized Domain Names (IDN) stored in a shared central repository. This mapping extends the EPP domain name mapping to provide additional features required to implement registrations of domain names in characters sets other than ASCII. "Specification of an Adaptation Function Between Two Multicast Networks Supporting Different IP Versions", Tom Taylor, Cathy Zhou, 21-Dec-11, In some transitional multicast scenarios, the multicast signalling and content have to pass across network boundaries where one network supports IPv4, the other, IPv6. An adaptation function is required at the boundary to support such a scenario. This memo uses the term "Type 2 Adaptation Function" (AF2) for such a function. "A Mechanism for Negotiating Multi-Stream Continuous Presence Video in SIP", Adel Mostafa, 23-Dec-11, The NextGen video conferencing clients require multiple concurrent video streams to provide a User eXperience (UX) in which multiple participants can be viewed at the same time, this user experience is called Continuous Presence (CP) video. The multi-stream CP video provides more client control of the UX and less processing on the conference server since the video streams are relayed by the server rather than mixed to compose a CP video stream. The client CP layout, processing power and bandwidth limitations require a per stream bandwidth and resolution to be negtiated in the SIP Offer/ Answer with the conference server. Standard methods are used to achieve this negotiation in addition to a new SDP parameter. This document explains the methodology and solution to achieve this in SIP and SDP. "An AR-level solution support for Distributed Mobility Management", Zhengming Ma, Xun Zhang, 26-Dec-11, The number of mobile users and their traffic demand is expected to be ever-increasing in future years, and this growth can represent a limitation for deploying current mobility management schemes that are intrinsically centralized, e.g., Mobile IPv6 and Proxy MIPv6. This evolution in user traffic demand is tackled by a different approach for IP mobility, called Distributed Mobility Management, which is focusing on moving the mobility anchors from the core network and pushing them closer to the users, at the edge of the network. The work presented here copes with the distributed approach, describing a novel solution for distributed mobility management support in a flat architecture without central mobility anchors. This document strictly abides by the two principles: (a)The movement of MN is transparent to CN. (b)MN doesn't participate in any mobility-related signaling.MAAR and AAA are responsible for managing IP mobility on behalf of the host. "Working Group Consensus", S Moonesamy, 26-Dec-11, This memo discusses about Working Group rough consensus within the IETF. "Root Name Server Operational Requirements", Root Committee, 6-Feb-12, As the Internet has become critical to the world's social and economic infrastructure, attention has focused on the correct, safe, reliable, and secure operation of the Internet infrastructure itself. The DNS is considered a crucial part of that technical infrastructure. The root domain and its authoritative name servers are a part of that technical infrastructure. The primary focus of this document is to provide guidelines for secure, stable, and resilient authoritative name service for the root zone. Additionally it will look into some specifics for the operation of the name servers. Other operators of authoritative name servers such as those for generic top-level domains (gTLDs), country code top-level domains (ccTLDs) and other zones may also find this document useful. "Requirements for Mobility and Interconnection of Virtual Machine and Virtual Network Elements", Bhumip Khasnabish, Bin Liu, 28-Dec-11, In this draft, we discuss the issues and requirements related to migration, mobility, and interconnection of Virtual Machines (VMs)and Virtual Network Elements (VNEs). We also describe the limitations of various types of virtual local area networking (VLAN) and virtual private networking (VPN) techniques that are traditionally expected to support such migration, mobility, and interconnection. "Moving Authentication Header (AH) to Historic", Manav Bhatia, 29-Dec-11, This document recommends retiring Authentication Header (AH) and discusses the reasons for doing so. It recommends moving RFC 4302 to Historic status. "Evaluation of Proposed Homenet Routing Solutions", Lee Howard, 29-Dec-11, This document evaluates the various proposals for routing in an unmanaged home network. "Homenet Routing Requirements", Lee Howard, 29-Dec-11, This document describes the requirements for routing in an unmanaged home network. "Load sharing support for MAGs in Proxy Mobile IPv6", Haisheng Jiang, 29-Dec-11, Proxy Mobile IPv6 (PMIPv6) is standardized by IETF to supply mobility management for mobile nodes (MN) in a local small area. When the numbers of MNs which attaching to the same MAG is very large, it will cause the problem that the arrival rate of data traffic is far surpass the process capacity of the MAG. So the MAG will suffer from process bottleneck. The IETF is working on optimization for PMIPv6. This document proposes a load sharing solution for MAGs by migrating the Picked Mobile Node (PMN) to some MAGs without overload to sharing the traffic load, which can relieve stress of the overloaded MAG and improve the performance of PMIPv6 network. "p2mp pw protection for mpls-tp network", Yu jinghai, Guoman Liu, Tu XiaoPing, Xu Xueqiong, 29-Dec-11, According to one protection Requirement in RFC 5654, Requirement 63 :It MUST be possible to provide protection for the MPLS-TP data plane without any IP forwarding capability in the MPLS-TP data plane. and it requires mpls-tp date plane should be independent of its control plane. so it is necessary for the 1:1 protection of p2mp pw to have a return path to coordinate the switch state between root node and each leaf node. for the above problem statement, the document provides a solution to protect p2mp pw by using one leaf node as protector for another leaf node. so it may avoid setting up a return path for each leaf node. This document is a product of a joint Internet 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. "IKEv2 Configuration Payload Extension for Private IPv4 Support for Fixed Mobile Convergence", Tricci So, 7-Feb-12, IPSec IKEv2, RFC 5996 [RFC5996], has been adopted by many standardized network solutions to provide the secure transport between network elements over third party's infrastructure. For example, the emerging Fixed Mobile Convergence (FMC) network solution that involves Femtocell deployment requires the mobile operator's Femtocell AP to leverage the IPSec IKEv2 to support mutual authentication and remote IP address configuration as well as other auto configuration support over the broadband fixed network (BBF) of which the mobile and fixed networks may be operated by two different operators. Most of today broadband fixed networks are still relying on the IPv4 private addressing plan to support its attached devices including the mobile operator's Femtocell AP. Hence, the private IPv4 addressing and Network Address and Port Translation (NA(P)T) support mostly likely stays for many years to come. In FMC interworking scenario, there is a need for the mobile network to pass on it mobile subscribers' policies to the broadband fixed network (BBF) to maintain the service level agreement (SLA) and to support remote network management. In addition, a broadband fixed network (BBF) may partnership with more than one mobile operator. Therefore it is important for the BBF and the mobile network to be able to overcome the limitation of the private IPv4 addressing and to be able to identify the user's subscription as well as to determine the location of the Femtocell AP that serves its mobile user over the BBF network. This document presents the problems for the IPSec tunneling support with private IPv4 addressing for FMC interworking and proposes a simple extension to the IKEv2 to resolve the issues. "Resource Reservation Protocol - Traffic Engineering(RSVP-TE) Extensions for Inter-AS P2MP TE LSPs", KeJun Li, 29-Dec-11, [RFC4875] describes extensions to RSVP-TE protocol for building a P2MP TE LSP in MPLS/GMPLS network environment.However, [RFC4875] doesn't specify path selecting problem of inter-AS P2MP TE LSP.This document specifies an inter-AS P2MP path computation method based on extentions to RSVP-TE Protocol. "Datacenter Solution Approaches", Ashish Dalela, 30-Dec-11, There are many approaches to addressing virtualized datacenter scaling problems. Examples of these approaches include, L2 vs. L3 forwarding, host-based vs. network-based solutions, fat-access and lean-core vs. fat-core and lean-access, flat addressing vs. encapsulation, protocol learning vs. directories for location discovery, APIs vs. protocols for orchestration, etc. Different solutions being proposed today take one or more of these approaches in combination, although sometimes the question of approach itself may not be settled. Given the multiple facets of the datacenter problem, and many approaches to solve each problem, it becomes hard to discuss a solution when some approaches may be acceptable while others are not. This document discusses the pros and cons of various approaches. The goal is not to describe a specific solution, but to evaluate the various approaches. This document concludes with a set of recommendations on which approaches are most optimal for a holistic solution to the entire problem set. "Datacenter Network and Operations Requirements", Ashish Dalela, 30-Dec-11, The problems of modern datacenters are rooted in virtualized host scaling. Virtualization implies VM mobility, which may be intra- datacenter or inter-datacenter. Mobility may cross administrative boundaries, such as across private-public domains. A public datacenter may be multi-tenant, extending several private networks into the public domain. Running these massively scaled, virtualized, multi-tenant datacenters poses some unique networking and operational challenges. This document describes these challenges. "Hierachical PCE Extensions for Inter-Domain Point-to-Multipoint Path Computation", KeJun Li, 30-Dec-11, The hierachical Path Computation Element (PCE) architecture defined in [PCE-HIERARCHY-FWK] allows the optimum sequence of domains to be selected, and the optimum end-to-end path to be derived through the use of a hierarchical relationship between domains. This document defines the hierachical PCE (H-PCE) extensions for the purpose of implementing inter-domain P2MP Path Computation. "Avoiding Authentication Header (AH)", Manav Bhatia, 1-Jan-12, This document recommends retiring Authentication Header (AH) and discusses the reasons for doing so. It recommends that AH must not be used for new applications and protocols, since Encapsulating Security Payload (ESP) using NULL encryption algorithm provides the same level of security in most real deployments. "CoRE Interfaces", Zach Shelby, 31-Jan-12, This document defines well-known REST interface descriptions for Batch, Sensor, Parameter and Actuator types for use in contrained web servers using the CoRE Link Format. A short reference is provided for each type that can be efficiently included in the interface description attribute of the CoRE Link Format. These descriptions are intended to be for general use in resource designs or for inclusion in more specific interface profiles. "RPKI Router Implementation Report", Randy Bush, Rob Austein, Keyur Patel, Hannes Gredler, Matthias Waehlisch, 8-Jan-12, This document provides an implementation report for RPKI Router protocol as defined in [I-D.ietf-sidr-rpki-rtr]. The editor did not verify the accuracy of the information provided by respondents or by any alternative means. The respondents are experts with the implementations they reported on, and their responses are considered authoritative for the implementations for which their responses represent. Respondents were asked to only use the YES answer if the feature had at least been tested in the lab. "Service Orchestration Protocol (SOP) Requirements", Ashish Dalela, Mike Hammer, 3-Jan-12, Cloud services need to interoperate across cloud providers, service vendors and private/public domains. To enable this interoperability, there is need for a standard protocol for exchanging service information. This draft describes requirements for such a protocol. Current cloud implementations expose application level APIs, which are not syntactically and semantically compatible with each other. One approach to interoperate cloud services is to standardize the protocol while leaving the API definition implementation specific. Standard protocols have been used widely in the Internet and can be extended to cloud. Use of such protocols is compatible with existing cloud APIs, which can exchange information in a standard protocol. New APIs may also be developed using a standard protocol. By this, it would be possible to interoperate diverse APIs across service providers, service vendors and service users. "Service Description Framework (SDF)", Ashish Dalela, Mike Hammer, 3-Jan-12, Cloud services need to interoperate across providers, vendors and private/public domains. To enable this interoperability, there should be a standard way to exchange service information. The purpose of this document is to detail different kinds of information necessary to describe services. We identify the following kinds of service- dependant information needed for any kind of service: - Method for naming services and identifying service classes. - Method for describing syntax for properties of service classes. - Method for defining semantics in a service class, by establishing "Service Orchestration Protocol", Ashish Dalela, Mike Hammer, 3-Jan-12, Cloud services need to interoperate across cloud providers, service vendors and private/public domains. To enable this interoperability, there is need for a standard wire-format for exchanging service information. This document describes a Service Orchestration Protocol (SOP) to be used as a standard wire-format for cloud exchanges. Similar to widely used protocols like HTTP, SIP and SMTP, SOP uses text-based messages, which are easily extensible and may be inspected at cloud proxies. While SOP carries service-independent information, service-dependant information is attached as a Service Description Framework [SDF] payload to SOP packets. This is similar to how HTML is transported over HTTP. SDF is a XML schema for describing services. SOP and SDF enable any kind of service to be discovered and orchestrated across private and public domains. Simple protocol compliance tests can be employed to ensure interoperability across domains. SOP wire-formats can be used with existing cloud APIs. Using these, it would be possible to interoperate diverse APIs and cloud services across service providers, service vendors and service users. "SOP Network Architecture", Ashish Dalela, Mike Hammer, 3-Jan-12, Cloud services need to interoperate across cloud providers, service vendors and private/public domains. To enable this interoperability, there is need for network level deployment architecture to connect users and providers. This document describes functionality partitioning in network deployment and the different advantages of using distributed functionality deployments. "SOP Message Flows", Ashish Dalela, Mike Hammer, 3-Jan-12, This document describes the Service Orchestration Protocol (SOP) message flows for some important service orchestration scenarios. The flows contain complete packet information including both SOP and Service Description Framework (SDF) payloads. The message flows in this document are by no means exhaustive, but they carry sufficient information using which other flows can be easily constructed. The deployment scenarios for services are varied, and it is not possible to cover every possible scenario. Nevertheless, those flows will follow closely the information given in this document. "BCP for ARP-ND Scaling for Large Data Centers", Igor Gashinsky, Linda Dunbar, Warren Kumari, 3-Jan-12, This draft is intended to document some simple well established practices which can scale ARP/ND in data center environment. "Hashed Password Exchange", Steven Bellovin, 4-Jan-12, Many systems (e.g., cryptographic protocols relying on symmetric cryptography) require that plaintext passwords be stored. Given how often people reuse passwords on different systems, this poses a very serious risk if a single machine is compromised. We propose a scheme to derive passwords limited to a single machine from a typed password, and explain how a protocol definition can specify this scheme. "DNS Security (DNSSEC) Authenticated Denial of Existence", R. Gieben, 4-Jan-12, The Domain Name System Security (DNSSEC) Extensions introduced the NSEC resource record for authenticated denial of existence, and the NSEC3 resource record for hashed authenticated denial of existence. This document introduces an alternative resource record, NSEC4, which similarly provides authenticated denial of existence. It permits gradual expansion of delegation-centric zones, just like NSEC3 does. With NSEC4 it is possible, but not required, to provide measures against zone enumeration. NSEC4 reduces the size of the denial of existence response and adds Opt-Out to unhashed names. "A Route Optimization solution support for Distributed Mobility Management", Xun Zhang, Zhengming Ma, 4-Jan-12, The mobile users and their traffic demands are expected to be ever- increasing in future years, and this growth will impose a limitation for deploying current mobility management schemes that are intrinsically centralized, e.g., Mobile IPv6 and Proxy MIPv6. This evolution in user traffic demand can be tackled by a different approach for IP mobility, called Distributed Mobility Management, which is focusing on moving the mobility anchors from the core network and pushing them closer to the users, at the edge of the network. Following this idea, in our proposal, the central anchor is being deployed in the access router of the mobile node(MN). That is, the first elements that provide IP connectivity to a set of MNs are also the mobility managers for those MNs. In the following, we will call MAAR (Mobility anchor and Access Router). This draft strictly abides by the three principles: (1) The MN doesn't participate in any mobility-related signaling.MAAR and AAA are responsible for managing IP mobility on behalf of the host. (2) The MN's movement is transparent to the communication node (CN).The Home Address (HoA) and Care-of address (CoA) are not for users but for specific sessions in this draft.A MN initiates a session by using the MN's address assigned by a MAAR which the MN is registered as the HoA for this session.The MN's address assigned by a new MAAR which the MN moves to its access link as the CoA for the session. (3) The MN can directly forward packages to the CN and the packages don't need to pass the home mobility anchor. It can reduce the heavy burdens on home mobility anchor and maintain all the continuity of the conversation. "Fragmentation support across RADIUS packets", Alejandro Perez-Mendez, Fernando Pereniguez-Garcia, Gabriel Lopez-Millan, Diego Lopez, 4-Jan-12, This document describes a mechanism providing fragmentation support of RADIUS attributes across several RADIUS packets. This is intended to support attributes that exceed the 4 KB limit per RADIUS packet. "IRON Applicability for Multiple Interface Nodes", Fred Templin, 4-Jan-12, The Internet Routing Overlay Network (IRON) is a new internetworking and routing architecture that addresses important issues including routing scaling, network renumbering, mobility management, mobile networks, multihoming, traffic engineering, NAT traversal and security. In this document, we focus on IRON's applicability for multiple interface (mif) nodes. "Coordinated Multicast Trees (CMT)for TRILL", Tissa Senevirathne, Jon Hudson, 5-Jan-12, TRILL facilitates loop free connectivity to non TRILL legacy networks via choice of an Appointed Forwarder for set of VLANs. Appointed Forwarder provides VLAN level load sharing with active- standby model. Mission critical operations such as High Performance Data Centers require active-active load sharing model. Active-Active load sharing model can be accomplished by representing any given non TRILL legacy network with a single virtual RBridge. Virtual representation of the non-TRILL legacy network with a single RBridge poses serious challenges in multi-destination RPF calculations. This document presents the required enhancements to build Coordinated Multicast Trees (CMT) within the TRILL campus. CMT provides flexibility to RBridges to select desired path of association to a given distribution tree. "RTCP XR Report Block for One Way Delay metric Reporting", Kevin Gross, Mario Montagud, 5-Jan-12, This document defines an RTCP XR Report Block that allows the reporting of One Way Delay metrics for use in a range of RTP applications. "vCard KIND:device", Gonzalo Salgueiro, Joe Clarke, Peter Saint-Andre, 6-Jan-12, This document defines a value of "device" for the vCard KIND property so that the vCard format can be used to represent computing devices such as appliances, computers, or network elements (e.g., a server, router, switch, printer, sensor, or phone). "Neighbor Discovery Enhancements for DOS mititgation", Warren Kumari, 8-Jan-12, In IPv4, subnets are generally small, made just large enough to cover the actual number of machines on the subnet. In contrast, the default IPv6 subnet size is a /64, a number so large it covers trillions of addresses, the overwhelming number of which will be unassigned. Consequently, simplistic implementations of Neighbor Discovery can be vulnerable to denial of service attacks whereby they attempt to perform address resolution for large numbers of unassigned addresses. Such denial of attacks can be launched intentionally (by an attacker), or result from legitimate operational tools that scan networks for inventory and other purposes. As a result of these vulnerabilities, new devices may not be able to "join" a network, it may be impossible to establish new IPv6 flows, and existing ipv6 transported flows may be interrupted. This document describes possible modifications to the traditional [RFC4861] neighbor discovery protocol for improving the resilience of the neighbor discovery process as well as an alternative method for maintaining ND caches. "ILNP Architectural Description", R. Atkinson, SN Bhatti, 9-Jan-12, This document provides an Architectural description and the Concept of Operations for the Identifier-Locator Network Protocol (ILNP), which is an experimental, evolutionary enhancement to IP. This is a product of the IRTF Routing RG. "Multicast Geo-Distribution Control", Huajin Jeng, Yakov Rekhter, 9-Jan-12, Consider a content provider that wants to deliver a particular content to a set of customers/subscribers, where the provider and the subscribers are connected by an IP service provider. This document covers two areas needed to accomplish this: (1) providing the content provider with the information of whether it can use the multicast connectivity service provided by the IP service provider to deliver a particular content to a particular set of subscribers, and (2) providing the content provider with a mechanism to restrict delivery of a given content to a particular set of the subscribers. "Media Multihoming in SIP Sessions", Rohit verma, 9-Jan-12, This document discusses the requirements and procedures to achieve the multihoming of media for voice over IP sessions using the transport layer protocol as signaling Control Transmission Protocol. Media is an essential part of any voice over IP session. SIP (RFC 3261) is a text based signaling protocol and Multihoming using SIP can be achieved by using the SCTP as a transport protocol (RFC 4168), therefore the application level resiliency can be guaranteed even in case of any middle node or terminal failures. But any voice over IP or multimedia session is nearly insignificant, if the media path is broken during a call and is waiting for a timeout which further shall lead to a call drop.A complete solution to Multihoming can be achieved if a system is capable of a performing the failovers at both application and media plane and still maintaining the session irrespective of the application or media path failures or at least to detect a signaling or media path failure and terminate the session rather than waiting for timeouts. The requirement of Multihoming in media can also be derived from the fact that in any voice, video or data session, the signaling and call setup time use to be incomparably short than that of real media session at media plane. Therefore providing the resiliency at the signaling level does not provide the guaranteed and best effort service from a media session point of view as not only signaling but media is an integral part of it. "Multicast Transition Overview", Hitoshi Asaeda, Marshall Eubanks, Tina Tsou, Stig Venaas, 17-Feb-12, IPTV providers must serve content to their customers during the period of transition from IPv4 to IPv6. During this period, the content provider may support only one version of IP while the customer supports only the other. Likewise, the network between the provider and its customer may include segments supporting only one version of IP or another. This document provides an overview of the multicast transition problem. It also provides an overview of the solution space. The solution space is characterized by an adaptation function (AF) that provides an interface between IPv4 and IPv6 multicast domains. "Mitigating Teredo Rooting Loop Attacks", Fernando Gont, 10-Jan-12, Recently, a number of routing loop vulnerabilities were discovered in the Teredo mechanism, which typically result in a Denial of Service of the involved systems, possibly also affecting the intervening networks. This document describes a number of security checks that can be performed by Teredo hosts and Teredo servers such that these vulnerabilities are eliminated. "Privacy Terminology", Marit Hansen, Hannes Tschofenig, Rhys Smith, 10-Jan-12, 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", any information relating to a data subject; a data subject is an identified natural person or a natural person who can be identified, directly or indirectly. 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 "DNS Resource Records for ILNP", R. Atkinson, S Bhatti, Scott Rose, 10-Jan-12, This note describes additional optional Resource Records for use with the Domain Name System (DNS). These optional resource records are for use with the Identifier-Locator Network Protocol (ILNP). This document is a product of the IRTF Routing RG. "ILNP Engineering Considerations", R. Atkinson, SN Bhatti, 10-Jan-12, This document describes common (i.e. version independent) engineering details for the Identifier-Locator Network Protocol (ILNP), which is an experimental, evolutionary enhancement to IP. This document is a product of the IRTF Routing RG. "ICMP Locator Update message for ILNPv4", R. Atkinson, SN Bhatti, 10-Jan-12, This document defines a new ICMP message type for IPv4 that is used only with ILNP for IPv4 (ILNPv4). The Identifier-Locator Network Protocol (ILNP) is an experimental, evolutionary enhancement to IP. This document is a product of the IRTF Routing RG. "Status of this Memo", R. Atkinson, 10-Jan-12, This note specifies an experimental ICMPv6 message type used with the Identifier-Locator Network Protocol (ILNP). This message is used to dynamically update Identifier/Locator bindings for an existing ILNP session. This is a product of the IRTF Routing RG. "IPv6 Nonce Destination Option for ILNPv6", R. Atkinson, S Bhatti, 10-Jan-12, The Identifier-Locator Network Protocol (ILNP) is an experimental, evolutionary enhancement to IP. ILNP has multiple instantiations. This document describes an experimental Nonce Destination Option used only with ILNP for IPv6 (ILNPv6). This document is a product of the IRTF Routing RG. "IPv4 Options for ILNPv4", R. Atkinson, SN Bhatti, 10-Jan-12, This document defines 2 new IPv4 options that are used with ILNP for IPv4 (ILNPv4). ILNP is is an experimental, evolutionary enhancement to IP. This document is a product of the IRTF Routing RG. "MAP Translation (MAP-T) - specification", Congxiao Bao, Xing Li, Yu Zhai, Tetsuya Murakami, Wojciech Dec, 10-Jan-12, This document specifies the "Mapping of Address and Port" (MAP) double stateless translation based solution (MAP-T) for providing IPv4 hosts connectivity to and across an IPv6 domain. "Email Policy Service Trust Processing", Jim Schaad, 10-Jan-12, Write Me "Auto-Configuration of Designated VLANs", Mingui Zhang, Liangliang Ma, Xudong Zhang, 10-Jan-12, When RBridges are connected by a bridge LAN link, they need to select out a Designated VLAN to be used for PDU exchange and TRILL data forwarding. This document specifies an approach for RBridges to automatically determine a Designated VLAN on a LAN link for default configured RBridges. When a DVLAN has to be changed for the sake of a better connectivity of a LAN link, RBridges can change their Designated VLAN with least traffic interruption according to the soft Designated VLAN change method. "Signalling Media Stream ID in the Session Description Protocol", Harald Alvestrand, 25-Jan-12, This document specifies how the association between the RTP concept of SSRC and the WebRTC concept of "media stream" / "media stream track" is carried using SDP signalling. This document is an input document for discussion. It should be discussed in the RTCWEB WG list, rtcweb@ietf.org. "TRILL: Traffic Engineering", Jacni Qin, Donald Eastlake, Radia Perlman, 11-Jan-12, This document specifies the control plane procedures to support Traffic Engineering (TE) in the TRILL protocol. Traffic Engineering permits management configuration of the path followed by certain unicast frames in a TRILL campus. "RADIUS Attribute for MAP", Peter Deacon, Sheng Jiang, Yu Fu, 11-Jan-12, Mapping of Address and Port (MAP) is a stateless mechanism for running IPv4 over IPv6-only infrastructure. It provides both IPv4 and IPv6 connectivity services simultaneously during the IPv4/IPv6 co- existing period. The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) MAP options has been defined to configure MAP Customer Edge (CE). However, in many networks, the configuration information may be stored in Authentication Authorization and Accounting (AAA) servers while user configuration is mainly from Broadband Network Gateway (BNG) through DHCPv6 protocol. This document defines a Remote Authentication Dial In User Service (RADIUS) attribute that carries MAP configuration information from AAA server to BNG. The MAP RADIUS attribute are designed following the simplify principle. It provides just enough information to form the correspondent DHCPv6 MAP option. "The SEAL IPv6 Destination Option", Fred Templin, 13-Jan-12, The Subnetwork Encapsulation and Adaptation Layer (SEAL) provides a mid-layer header designed for the encapsulation of an inner network layer packet within outer network layer headers. SEAL also supports a transport mode of operation, where the inner payload corresponds to an ordinary transport layer payload. However, SEAL can also provide benefit when used as an IPv6 destination option that contains a digital signature inserted by the source. The source can thereafter use the signature to verify that any ICMPv6 messages received actually came from a router on the path, while destinations that share a secret key with the source can verify the signature to ensure data origin authentication. "Internet+ Architectural Framework", Jean-Francois Morfin, 9-Feb-12, This memo acknowledges the change of scale in network and people centricities within the whole digital ecosystem. It shows how the Internet technology can sustain the resulting network and societal effects in scaling itself from the end to end Internet to a fringe to fringe fully optional and compatible Internet+ which strictly conforms to the Internet architecture and RFCs. It introduces the Internet+ architectural framework and the IUTF to document it. It explores a transition that can be seamlessly immediate and will probably start a complete review and extension of the Internet schemas towards the semiotic Internet (Intersem). "Miscellaneous CoAP Group Communication Topics", Esko Dijk, Akbar Rahman, 13-Jan-12, This document contains miscellaneous text around the topic of group communication for the Constrained Application Protocol (CoAP). The first part contains, for reference, text that was removed from the Group Communication for CoAP draft. The second part describes group communication and multicast functionality that may be input to future standardization in the CoRE WG. "Optional Advanced Deployment Scenarios for ILNP", R. Atkinson, SN Bhatti, 14-Jan-12, This document provides an Architectural description and the Concept of Operations of some optional advanced deployment scenarios for the Identifier-Locator Network Protocol (ILNP), which is an evolutionary enhancement to IP. None of the functions described here is required for the use or deployment of ILNP. Instead, it offers descriptions of engineering and deployment options that might provide either enhanced functionality or convenience in administration or management of ILNP-based systems. "ARP Extension for ILNPv4", R. Atkinson, SN Bhatti, 14-Jan-12, This document defines an Address Resolution Protocol (ARP) extension to support ILNP for IPv4 (ILNPv4). ILNP is is an experimental, evolutionary enhancement to IP. This document is a product of the IRTF Routing RG. "464XLAT: Combination of Stateful and Stateless Translation", Masataka Mawatari, Masanobu Kawashima, Cameron Byrne, 15-Jan-12, This document describes an architecture (464XLAT) for providing IPv4 connectivity across an IPv6-only network by combining existing and well-known stateful protocol translation RFC 6146 and stateless protocol translation RFC 6145. 464XLAT is a simple and scalable technique to quickly deploy IPv4 access service to mobile and wireline IPv6-only networks without encapsulation. "Stateless IPv6 delivery within IPv4 (V6 via V4)", Peter Tattam, 15-Jan-12, This document describes a method for transmitting IPv6 packets directly to and from IPv4 hosts via the IPv4 network in a stateless manner using an IPv4 header option and transponders. Additionally described is a mechanism to automatically locate IPv6 network transponders via well known IPv4 and IPv6 network prefixes. "RTCP message for Receiver Estimated Maximum Bitrate", Harald Alvestrand, 17-Jan-12, This document proposes an RTCP message for use in experimentally- deployed congestion control algorithms for RTP-based media flows. "Trace Fields in mail-related specifications", S Moonesamy, 17-Jan-12, The memo provides background information about trace fields in mail standards. It discusses about the use of trace fields in mail- related specifications. "Overlay Path Option for IP and TCP", Brandon Williams, 17-Jan-12, Data transport through overlay networks often uses either connection termination or network address translation (NAT) in such a way that the public IP addresses of the true endpoint machines involved in the data transport are invisible to each other. This document describes IPv4, IPv6, and TCP options for communicating this information from the overlay network to the endpoint machines. "Labels for Common Location-Based Services", Andrea Forte, Henning Schulzrinne, 18-Jan-12, 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). "CDNi Content De-duplication Optimization", WeiYi Jin, Wei Wang, ZhenWu Hao, Yu Meng, 18-Jan-12, Some CDNi deployments are likely to lead to content repetition in the same dCDN. This document gives the cases and then discusses the optimization approach to de-duplicate of the repeated content in CDNi network. To implement the optimization, the enhancement to CDNi metadata model and interface is required. "Mail Header Trace Fields", S Moonesamy, John Levine, 22-Jan-12, SMTP mail software adds trace fields to messages as they pass through the mail system. This memo provides background information about trace fields in mail standards. It discusses the use of trace fields in mail-related specifications. It updates the definition of trace header fields, and adds trace field information to the relevant registries. "IKEv2 Configuration Payload Extension for Notarizing Femtocell in Mobile Core Network", Zaifeng Zong, 18-Jan-12, IPSec IKEv2, RFC 5996 [RFC5996], has been adopted by many standardized network solutions to provide the secure transport between network elements over third party's infrastructure. Today Femtocell deployment requires the mobile operator's Femtocell AP (FAP) to leverage the IPSec IKEv2 to support mutual authentication and data protection between the insecure Femtocell, which typically deployed in customer's premise, and its corresponding mobile core network. A known security threat exists in Femto architecture for failing to validate the FAP's identity and information provided by FAP at the mobile operator's core network. This document reviews this security threat and proposes a simple extension of the IKEv2 to resolve the issue. "On Firewalls in Internet Security", Fred Baker, 20-Jan-12, There is an ongoing discussion regarding the place of firewalls in security. This note is intended to capture and try to make sense out of it. "Using PCP to Find an External Address in an NPTv6 Network", Fred Baker, Dan Wing, 20-Jan-12, This note describes an approach to finding the set of External Addresses associated with an Internal Address. Requirements "Link Management Protocol Extensions for Grid Property Negotiation", Yao Li, 20-Jan-12, The recent updated version of ITU-T [G.694.1] has introduced the flexible grid DWDM technique which provides a new tool that operators can implement to provide a higher degree of network optimization than is possible with fixed grid systems. This document describes the extensions to the Link management protocol (LMP) to negotiate link grid property between the adjacent DWDM nodes before the link is brought up. "Extending the Application-Layer Traffic Optimization (ALTO) Protocol", Enrico Marocco, Vijay Gurbani, 20-Jan-12, The Application-Layer Traffic Optimization (ALTO) protocol is designed to allow entities with knowledge about the network infrastructure to export such information to applications that need to choose one or more endpoints to connect to among large sets of logically equivalent ones. The primary use case for the ALTO protocol was peer-to-peer applications for file sharing, video streaming and realtime communications, usually running on end-user devices. However, a number of other applications executing in more controlled environments may also benefit from the information that can be exported through the ALTO protocol. The use cases that have received significant attention include Content Delivery Networks (CDNs), distributed applications running in large datacenters, as well as systems made of inter-communicating ALTO servers. To apply ALTO to these new use cases, this document aims to foster a discussion to determine if, and how, the ALTO protocol could be extended to provide a simple yet useful view of a computational environment that goes beyond the static (or near static) network topology and cost map information. "IPv4-Embedded IPv6 Multicast Address Format", Mohamed Boucadair, Jacni Qin, Yiu Lee, Stig Venaas, Xing Li, Mingwei Xu, 23-Jan-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. "Support of SDES in WebRTC", Oscar Ohlsson, 23-Jan-12, Which key management protocols to support has been lively debated in WebRTC on several occasions. This document explains the benefits of SDES and argues why allowing it as an alternative option has little impact on security. "Session Initiation Protocol (SIP) Load balancing survey", Parthasarathi Ravindran, Vijay Gurbani, Paul Erkkila, 23-Jan-12, SIP Load balancing across a farm of SIP servers can be done today, but without generally agreed upon principles on how to best do accomplish this. Confounding the problem is that a SIP farm may consist of hosts with varying capabilities, example, a SIP proxy, a back-to-back user agent (B2BUA), a public-switched telephone system (PSTN) gateway, SIP Media servers etc. The capabilities and processing capacity on hosts in the farm may be different, sometimes vastly, from each other. This document present the survey of existing literature and common practice on SIP load balancing. "RTCWEB Generic Identity Provider Interface", Eric Rescorla, 23-Jan-12, Security for RTCWEB communications requires that the communicating endpoints be able to authenticate each other. While authentication may be mediated by the calling service, there are settings in which this is undesirable. This document describes a generic mechanism for leveraging existing identity providers (IdPs) such as BrowserID or OAuth to provide this authentication service. "Traceflow", Balaji Venkataswami, Richard Groves, Peter Hoose, 24-Jan-12, This document describes a new OAM protocol - TraceFlow that captures information pertaining to a traffic flow along the path that the flow takes through the network. TraceFlow is ECMP and link-aggregation aware and captures the information about constituent members through which the traffic flow passes. TraceFlow gathers information that is relevant to the flow such as outgoing interface Layer 3 address, Next-hop to which the packet of the flow is forwarded, effect of network policies such as access control lists on the flow. This draft requires the Traceflow protocol to be processed by Layer 3 devices only. Devices such as Layer 2 devices, MPLS LERs/LSRs along the way are passed through without any processing as if in a pass-through mode. IP tunnels such as IP-in-IP, IP-in-GRE mechanisms are expected to pass the Traceflow packets through them using the pass through mode. For achieving its purpose Traceflow advocates the use of a specific UDP destination port to be assigned from IANA. "CoAP Proxy Encode-To Option", Guido Moritz, 24-Jan-12, The scope of this document is to propose a new option to be used in conjunction with the CoAP proxy mechanisms. Several content types can be converted stateless into each other. The conversion may result in much more efficient representation of the resource. But currently no mechanism exists to indicate the proxy to perform the compression. "Javascript Session Establishment Protocol", Justin Uberti, Cullen Jennings, 15-Feb-12, This document proposes a mechanism for allowing a Javascript application to fully control the signaling plane of a multimedia session, and discusses how this would work with existing signaling protocols. This document is an input document for discussion. It should be discussed in the RTCWEB WG list, rtcweb@ietf.org. "A PMIPv6-based solution for Distributed Mobility Management", Carlos Bernardos, Antonio Oliva, Fabio Giust, Telemaco Melia, 26-Jan-12, The number of mobile users and their traffic demand is expected to be ever-increasing in future years, and this growth can represent a limitation for deploying current mobility management schemes that are intrinsically centralized, e.g., Mobile IPv6 and Proxy MIPv6. For this reason it has been waved a need for distributed and dynamic mobility management approaches, with the objective of reducing operators' burdens, evolving to a cheaper and more efficient architecture. This draft describes a solution to distribute the data forwarding plane on Proxy Mobile IPv6 domains, thus trying to overcome the suboptimal data path introduced when the LMA is traversed. "Sanctions Available for Application to Violators of IETF IPR Policy", Adrian Farrel, Pete Resnick, 26-Jan-12, The IETF has developed and documented policies that govern the behavior of all IETF participants with respect to intellectual property about which they might reasonably be aware. The IETF takes conformance to these IPR policies very seriously. However, there has been some ambiguity as to what the appropriate sanctions are for the violation of these policies, and how and by whom those sanctions are to be applied. This document discusses these issues and provides a suite of potential actions that may be taken within the IETF community. "MPLS Transport Profile Linear Protection MIB", Kingston Selvaraj, Vishwas Manral, Daniel King, 26-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 MPLS Transport Profile (MPLS-TP) Linear Protection. "Text Encodings of Some Security Related Structures", Simon Josefsson, 27-Jan-12, This document describe and discuss the text encodings of Public-Key Infrastructure using X.509 (PKIX) Certificates, PKIX Certificate Revocation Lists (CRLs), PKCS #10 Certificate Request Syntax, PKCS #7 structures, and Attribute Certificates. The text encodings are well- known, implemented by several applications and libraries, and is widely deployed. This document is intended to articulate the de- facto rules that existing implementations operate by, and to give recommendations that will promote interoperability going forward. "Unified User-Agent String (UUAS)", Mateusz Karcz, 27-Jan-12, User-Agent is a header used by certain protocols, e.g. HTTP. Unified User-Agent String is intended to unification of that complicated strings. "MAP Encapsulation (MAP-E) - specification", Ole Troan, Satoru Matsushima, Tetsuya Murakami, 27-Jan-12, This document specifies the "Mapping of Address and Port" (MAP) encapsulation based solution (MAP-E) with an automatic tunneling mechanism for providing IPv4 connectivity service to end users over a service provider's IPv6 network. "Problem Statement of SAVI Beyond the First Hop", Jun Bi, Bingyang Liu, 30-Jan-12, IETF Source Address Validation Improvements (SAVI) working group is chartered for source address validation within the first hop from the end hosts, i.e. preventing a node from spoofing the IP source address of another node in the same IP link. For source address validation beyond the first hop (SAVI-BF), Ingress Filtering [BCP38]/[BCP84] is the best current practice. However Ingress Filtering may drop legitimate packets (false positive) or fail to recognize spoofing packets (false negative) in case of asymmetric routing, which is not rare under SAVI-BF scenario. This document states the possible scenarios in which Ingress Filtering may have problems (false positive or false negative). We claim that the reason of the problems is that the routers are lack of sufficient routing information to predict the incoming direction of a packet, since source address validation beyond the first hop should act consistently with the behavior of the routing system. We also discuss the availability of the needed routing information under different routing environments. "SRV record query extension for XMPP", Akari Harada, Hirotaka Sato, Nobuo Ogashiwa, Yoshihiro Suzuki, 29-Jan-12, According to RFC 6120, XMPP clients should use SRV records within the connection establishment process to servers. There are two purposes for using SRV records. The one is to advertise the FQDN of at least one server to clients to establish an initial TCP connection. The other purpose is to advertise at least two or more FQDN with priority and weight information to clients to accomplish load balancing, a redundant server environment and so on. However, most standard resolver libraries of recent client OSs don't support SRV record resolution. Furthermore, many DNS hosting services also don't support SRV records. This document proposes a solution that enables a server and client to achieve load balancing and a redundant server environment in case SRV records cannot be used. Moreover, the proposed IQ-result message can include minimum wait time to reconnect, allowing clients to reconnect after the most suitable wait time avoiding congestion. "Reporting Unobserved Fields in IPFIX", Paul Aitken, 30-Jan-12, The IPFIX protocol is designed to export information about observations, and lacks a method for reporting that observations are unavailable. This document discusses several methods for reporting when fields are unavailable, reviews the advantages and disadvantage of each, and recommends methods which should be used. "Experiences with RPL: IPv6 Routing Protocol for Low power and Lossy Networks", Thomas Clausen, Axel Verdiere, Jiazi Yi, Ulrich Herberg, 30-Jan-12, With RPL - the "IPv6 Routing Protocol for Low-power Lossy Networks" - having been published as a Proposed Standard after a ~2-year development cycle, this document presents an evaluation of the resulting protocol of its applicability and of its limits. The documents presents a selection of observations of the protocol characteristics, exposes experiences acquired when producing various prototype implementations of RPL, and presents results obtained from testing this protocol - by way of network simulations, in network testbeds and in deployments. The document aims at providing a better understanding of possible weaknesses and limits of RPL, notably the possible directions that further protocol developments should explore, in order to address these. "Network Virtualization Overlay Control Protocol Requirements", David Black, Dinesh Dutt, Lawrence Kreeger, Murari Sridhavan, Thomas Narten, 30-Jan-12, The document draft-narten-nvo3-overlay-problem-statement-01 discusses the needs for network virtualization using overlay networks in highly virtualized data centers. The problem statement outlines a need for control protocols to facilitate running these overlay networks. This document outlines the high level requirements to be fulfilled by the control protocols. "Routes Optimization for PMIPv6 Multicast", Juan Liu, Wen Luo, Wei Yan, 30-Jan-12, To support IP multicasting in PMIPv6 domain, MULTIMOB WG has issued several proposals including the base solution,dedicated schemes and direct routing which requires all communications to go through the local mobility anchor(LMA),the dedicated server and the native multicasting infrastructure ,respectively. As this can be suboptimal, localized routing (LR) allows multicast source attached to the same or different mobile access gateways(MAG) with mobile node to send multicast data by using localized forwarding or a direct tunnel between the gateways without any dedicated devices or dependence of the native multicasting infrastructure. This document describes multicast routes optimazition mechanisms for localized routing.The MAG and the LMA are the mobility entities defined in the PMIPv6 protocol and act as PIM-SM routers. "Reverse Path Forwarding Check under Multiple Topology TRILL", Mingui Zhang, 30-Jan-12, Multi-homing (RBridge Aggregation) is a promising approach to increase the reliability and access bandwidth of TRILL edge. Active- active forwarding in multi-homing allows multiple RBridges forward data frames for VLAN-x on a LAN link, which creates the possibility that multicast frames from a specific ingress RBridge may arrive at multiple incoming ports of a remote RBridge. This violates the Reverse Path Forwarding Check and multicast frames arrives at unexpected incoming ports will be discarded by this RBridge. This document makes use of multiple topology TRILL to solve this problem. Multiple topology TRILL provides physical separation of traffic from different members of aggregation. Multicast frames from aggregation members comply with the Reverse Path Forwarding Check per topology. "SADI: Semantic Automated Discovery and Integration", Ben Vandervalk, E. McCarthy, Mark Wilkinson, 31-Jan-12, This document describes Semantic Automated Discovery and Integration (SADI), a set of best practices for implementing stateless web services that consume RDF data as input and generate RDF data as output. The goal of SADI is to establish conventions that will enable a much higher level of interoperability between web services from independent providers than is currently possible under the widespread use of WSDL/XML and RESTful services. Under SADI, interoperability depends on the shared use of predicate vocabularies, rather than the shared use of particular XML schemas, JSON structures, or ad hoc data formats. Through the use of OWL to describe service input and output datatypes, SADI enables: i) automated discovery of services that provide data or computations of interest, and ii) automated matchmaking between local data and available services. By iterative application of the former two capabilities, SADI enables semi-automated construction of arbitrarily complex workflows across independent service providers. "Definitions of Managed Objects for 4rd", Yu Fu, Sheng Jiang, Jiang Dong, Peng Wu, 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 defines managed objects for 4rd. "A CoAP REST API for XMPP Publish-Subscribe", Klaus Hartke, 31-Jan-12, The REST API defined in this document enables Constrained Application Protocol (CoAP) clients to interact with Extensible Messaging Protocol (XMPP) Publish-Subscribe services by delegating the task of creating, retrieving, updating and deleting pubsub items and nodes to a CoAP/XMPP proxy. "JSON Responses to RESTful URL Queries for RIRs", Andrew Newton, Kaveh Ranjbar, Arturo Servin, 31-Jan-12, This document describes responses in the JSON format to the RESTful queries described in draft-newton-et-al-weirds-rir-query. "Carrying PIM-SM in ASM mode Trees over P2MP mLDP LSPs", Yakov Rekhter, Rahul Aggarwal, 31-Jan-12, When IP multicast trees created by PIM-SM in ASM mode need to pass through an MPLS domain, it may be desirable to map such trees to Point-to-Multipoint Label Switched Paths. This document describes how to accomplish this in the case where such Point-to-Multipoint Label Switches Paths are established using mLDP. Specification of Requirements "Security Descriptions Extension for Media Streams", Sujing Zhou, Tian Tian, 31-Jan-12, This document provides an extension to the cryptographic attribute (RFC 4568) defined for Session Description Protocol (RFC 4566) to enhance end-to-end communication security in scenarios, e.g., forking and re-targeting. The usage of the provided extension in Secure Real-time Transport Protocol (SRTP, RFC3711) is also defined in this document. "CDNi Content De-duplication Optimization", WeiYi Jin, Wei Wang, ZhenWu Hao, Yu Meng, 1-Feb-12, Some CDNi deployments are likely to lead to content repetition in the same dCDN. This document gives the cases and then discusses the optimization approach to de-duplicate of the repeated content in CDNi network. To implement the optimization, the enhancement to CDNi metadata model and interface is required. "Distributed Mobile IPv6", Behcet Sarikaya, 1-Feb-12, As networks are moving towards flat architectures, a distributed approach is needed to Mobile IPv6. This document defines a distributed mobility management protocol. Protocol is based on Mobile IPv6 and its extensions for multiple care of address registration, flow mobility and dual stack mobile IPv6 with minimum extensions. Control and data plane separation is achieved by separating Home Agent functionalities into the control and data planes. "Tiny Fragments in IPv6", Vishwas Manral, 2-Feb-12, IPv6 fragmentation allows fragments to be sent only by the source of a packet. The Fragment header is used by an IPv6 source to send a packet larger than would fit in the path MTU to its destination. Firewalls generally use 5-tuples to filter out packets. However there are cases where fragmentation can be used to disguise TCP packets from IP filters used in routers and hosts. This document specifies where tiny fragments can be issues. "Constructing protection paths for inter-AS, inter-sub-AS P2MP TE-LSPs", Balaji Venkat, Gaurav Raina, 2-Feb-12, Constructing primary and backup explicit path Point-to-Multipoint Label Switched Paths is important from the point of view of providing protection switching in case the primary fails. It is absolutely essential that the backup P2MP LSPs constructed do not share risk with any of the links and nodes of the primary path. In the case of inter-AS P2MP TE-LSPs or in the case of inter-sub-AS (in the case of BGP-Confederations being deployed) P2MP TE-LSPs where BGP confederations are deployed within an AS, such protection switching can be provided by calculating primary and backup multicast distribution trees (read P2MP TE-LSPs) that dont intersect with each other. In this paper we propose a method by which inter-sub-AS P2MP TE-LSPs (hence even inter-AS P2MP TE-LSPs) can be constructed by first finding the AS level topology of the network (be it inter-AS or inter-sub-AS within a single AS) in question and secondly to compute the paths in such a way that they dont intersect or if necessary in the worst case partially intersect each other. The proposed scheme is explained with an example and subsequent discussion is done to elucidate its benefits to multicast in particular. "A More Granular Web Origin Concept", Yoav Nir, 2-Feb-12, This document defines an HTTP header that allows to partition a single origin as defined in RFC 6454 into multiple origins, so that the same origin policy applies among them. The header introduced in this document allows the portal to specify that resources that appear to be from the same origin should, in fact, be treated as though they are from different origins, by extending the 3-tuple of the origin to a 4-tuple. The user agent is expected to apply the same-origin policy according to the 4-tuple rather than the 3-tuple. "Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers", Marc Petit-Huguenin, Suhas Nandakumar, Gonzalo Salgueiro, Paul Jones, 2-Feb-12, This document specifies the syntax of Uniform Resource Identifier (URI) schemes for the Traversal Using Relays around NAT (TURN) protocol. It defines two URI schemes that can be used to provision the configuration values needed by the resolution mechanism defined in [RFC5928]. "A Convention for HTTP Access to JSON-Based Resources", Paul Bryan, 15-Feb-12, A convention for accessing JSON representations of resources via HTTP, promoting a uniform interface across multiple disparate resources and reuse of software components. "Distributed Mobility Anchoring", Pierrick Seite, Philippe Bertin, 3-Feb-12, Most existing IP mobility solutions are derived from Mobile IP principles where a given mobility anchor maintains Mobile Nodes (MNs) binding up-to-date. Data traffic is then encapsulated between the mobility anchor and the MN or its Access Router. These approaches are usually implemented on a centralised architectures where both MN context and traffic encapsulation need to be processed at a central network entity, i.e. the mobility anchor. However, one of the trend in mobile network evolution is to "flatten" mobility architecture by confining mobility support in the access network, e.g. at the access routers level, keeping the rest of the network unaware of the mobility events and their support. This document discusses the deployment of a Proxy Mobile IP approach in such a flat architecture. The solution allows to dynamically distribute mobility functions among access routers. The goal is also to dynamically adapt the mobility support of the MN's needs by applying traffic redirection only to MNs' flows when an IP handover occurs. "Multi-Stream Media Conferencing", Magnus Westerlund, Bo Burman, 3-Feb-12, This memo describes a multimedia multi-party conferencing architecture based on use of multiple Real-Time Transport Protocol (RTP) streams. "Requirements for Labeled NFS", David Quigley, James Morris, Jarrett Lu, Stephen Smalley, Thomas Haynes, 9-Feb-12, This Internet-Draft outlines high-level requirements for the integration of flexible Mandatory Access Control (MAC) functionality into NFSv4.2. It describes the level of protections that should be provided over protocol components and the basic structure of the proposed system. It also gives a brief explanation of what kinds of protections MAC systems offer. "Requirements and Framework for Unified MPLS Sub-Network Interconnection", David Allan, 7-Feb-12, The definition of a transport profile for MPLS means that MPLS network architectures will emerge that combines both managed and control plane driven MPLS sub-networks and requires interconnection of same to achieve a unified MPLS architecture. This document generalizes the problem of sub-network interconnect, discusses issues in general and suggests ways forward. "Challenges in Smart Object Security: too many layers, not enough ram", Michael Richardson, 7-Feb-12, This is a position paper for the pre-IETF83 Workshop on Smart Object Security. The author contends that layer-2 security solutions are not only in-adequate, but may in fact be harmful when deployed into smart object systems. While layer-2 security services may be valuable, they must be channel bound up to the layer-7 application layer. "MPTCP Proxies and Anchors", Georg Hampel, Thierry Klein, 8-Feb-12, MPTCP proxies and anchors are network-based functions, which support MPTCP connections. The MPTCP proxy provides multipath support for MPTCP-capable hosts on behalf of their MPTCP-unaware peers. This facilitates incremental deployment of MPTCP. The MPTCP anchor permits subflow establishment for MPTCP connections when direct interaction between end hosts fails. This permits tolerance to local IP protocol restrictions and it provides robustness in case of break- before-make mobility events. MPTCP proxies and anchors are especially suited for wireless access environments. "IP Address Schemes for Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces", Manav Bhatia, Marc Binderberger, Sami Boutros, Nobo Akiya, 8-Feb-12, This document describes techniques which can be used by a router to obtain or discover remote neighbor IP address in order to establish micro Bidirectional Forwarding Detection (BFD) sessions [BFD-ON-LAGS]. "Reducing Power Consumption using BGP", Gaurav Raina, 9-Feb-12, In this paper, we propose a framework to reduce the aggregate power consumption of the Internet using a collaborative approach between Autonomous Systems (AS). We identify the low-power paths among the AS and then use Traffic Engineering (TE) techniques to route the packets along the paths. Such low-power paths can be identified by using the available power-to-bandwidth (PWR) ratio as an additional constraint in the Constrained Shortest Path First (CSPF) algorithm. For re- routing the data traffic through these low-power paths, the Inter-AS Traffic Engineered Label Switched Path (TE-LSP) that spans multiple AS can be used. Extensions to the Border Gateway Protocol (BGP) can be used to disseminate the PWR ratio metric among the AS thereby creating a collaborative approach to reduce the power consumption. Since calculating the low-power paths can be computationally intensive, a graph-labeling heuristic is also proposed. This heuristic reduces the computational complexity but may provide a sub- optimal low-power path. The feasibility of our approaches is illustrated by applying our algorithm to a subset of the Internet. The techniques proposed in this paper for the Inter-AS power reduction require minimal modifications to the existing features of the Internet. The proposed techniques can be extended to other levels of Internet hierarchy, such as Intra-AS paths, through suitable modifications. "Radio to Router Interface Framework and Requirements", Bow-Nan Cheng, David Ward, Leonid Veytser, 10-Feb-12, In highly dynamic, heterogeneous radio MANET environments where links are constantly changing, standardizing information exchange between the radio and router such that routers can make informed routing decision based on link layer information over heterogeneous link types becomes a key area to address. This document defines the basic framework for radio-to-router interface communications as well as requirements and considerations for evaluating radio-to-router interface technologies for use in MANETs. "Automatic VLAN allocation in E-tree", Ran Chen, 10-Feb-12, This document proposes to use automatically allocated VLAN ID to indicate E-Tree attribute. For the E-Tree requirement, please refer to [I-D.ietf-l2vpn-etree-reqt] for detail. "Mapping RTP streams to CLUE media captures", Roni Even, 12-Feb-12, This document describes mechanisms and recommended practice for mapping RTP media streams defined in SDP to CLUE media captures. "CDNI Logging Interface", Bertrand Gilles, Stephan Emile, 13-Feb-12, This memo specifies the Logging interface between a downstream CDN (dCDN) and an upstream CDN (uCDN). It introduces a framework, an architecture design and a set of new requirements. Then it drafts an information model. "NAT64 Operational Experiences", Cameron Byrne, Gang Chen, Qibo Niu, Zhen Cao, 13-Feb-12, This document summarizes some stateful NAT64 deployment scenarios and operational experiences for NAT64-CGN and NAT64-CE. "IPv6 packet staining", Tyson Macaulay, 13-Feb-12, This document specifies the application of security staining on an IPv6 datagrams and the minimum requirements for IPv6 nodes staining flows, IPv6 nodes forwarding stained packets and interpreting stains on flows. The usage of the packet staining destination option enables proactive delivery of security intelligence to IPv6 nodes such as firewalls and intrusion prevention systems, and end-points such servers, workstations, mobile and smart devices and an infinite array of as- yet-to-be-invented sensors and controllers. "Extension to VPLS for E-Tree Using Multiple PWs", Rafi Ram, Daniel Cohn, Raymond Key, Puneet Agarwal, 13-Feb-12, This document proposes a solution for Metro Ethernet Forum (MEF) Ethernet Tree (E-Tree) support in Virtual Private LAN Service using LDP Signaling (LDP-VPLS) [RFC4762] or BGP signaling (BGP-VPLS) [RFC4761]. The proposed solution is characterized by the use of two PWs between a pair of PEs. This solution is applicable for both VPLS and H-VPLS. "Representing CoRE Link Collections in JSON", Carsten Bormann, 14-Feb-12, Web Linking (RFC5988) provides a way to represent links between Web resources as well as the relations expressed by them and attributes of such a link. In constrained networks, a collection of Web links can be exchanged in the CoRE link format (I-D.ietf-core-link-format). Outside of constrained environments, it may be useful to represent these collections of Web links in JSON format (RFC4627). This specification defines a common format for representing Web links in JSON format. "Cross Stratum Optimization enabled Path Computation.", Dhruv Dhody, Young Lee, 14-Feb-12, Applications like cloud computing, video gaming, HD Video streaming, Live Concerts, Remote Medical Surgery, etc are offered by Data Centers. These data centers are geographically distributed and connected via a network. Many decisions are made in the Application space without any concern of the underlying network. Cross stratum application/network optimization focus on the challenges and opportunities presented by data center based applications and carriers networks together [CSO-DATACNTR]. Constraint-based path computation is a fundamental building block for traffic engineering systems such as Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) networks. [RFC4655] explains the architecture for a Path Computation Element (PCE)-based model to address this problem space. This document explains architecture for CSO enabled Path Computation. "Conclusion of SenderID and SPF experiments", S Moonesamy, 15-Feb-12, This memo concludes the SMTP Service Extension for Indicating the Responsible Submitter of an E-Mail Message (RFC4405), Sender ID: Authenticating E-Mail (RFC4406), Purported Responsible Address in E-Mail Messages (RFC4407) and Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1 (RFC4408), experiments. "OSPF Extensions for Routing Constraint Encoding in Flexible-Grid Networks", Lei Wang, Yao Li, 15-Feb-12, In Flexible-Grid networks, network elements and links may impose additional routing constraints, which cannot be ignored in Routing and Spectrum Assignment (RSA) process. This document describes the requirements of such constraints, and then provides efficient encodings to specify how the information is carried. "Public Key Checking Protocol", Stephen Farrell, 18-Feb-12, Some asymmetric key generation implementations do not use sufficient randomness giving rise to a number of bad public keys, for example with known factors, being used on the Internet. This memo specifies [[for now: just outlines]] an experimental protocol that could be used by a private key holder to talk to a responder that knows the values of (some of) those bad keys that have been seen in the wild. The protocol only allows a holder of the relevant private key to request information, as doing otherwise could weaken the overall security of the Internet and also considers confidentiality and privacy as important requirements, as information that a given bad public key is associated with a particular identifier could also weaken the security of the Internet. "Reverse DNS Naming Convention for CIDR Address Blocks", Joe Gersch, Dan Massey, 16-Feb-12, The current reverse DNS naming method is used to specify a complete IP address. It has not been used to handle address ranges; for example, there is no formal mechanism for specifying a reverse DNS name for the block of addresses specified by the IPv4 prefix 129.82.0.0/16. Defining such a reverse DNS naming convention would be useful for a number of applications. These include applications for secure BGP routing, and applications that need host-information for a device owning a complete IPv6 address block. This draft proposes a naming convention for encoding CIDR address blocks in the reverse DNS. "Security and Interoperability Implications of Oversized IPv6 Header Chains", Fernando Gont, Vishwas Manral, 16-Feb-12, The IPv6 specification allows IPv6 header chains of an arbitrary size. The specification also allows options which can in turn extend each of the headers. In those scenarios in which the IPv6 header chain or options are unusually long and packets are fragmented, or scenarios in which the fragment size is very small, the first fragment of a packet may fail to include the entire IPv6 header chain. This document discusses the interoperability and security problems of such traffic, and updates RFC 2460 such that all IPv6 packets are required to contain the entire IPv6 header chain within the 'minimum IPv6 MTU' (1280) bytes of the packet. "Capability Information Advertising for CDN Interconnection", Xiaoyan He, Spencer Dawkins, Ge Chen, Yunfei Zhang, Wei Ni, 16-Feb-12, This document describes protocol for Capability Information Advertising which is used to communicate capability information among interconnected Content Delivery Networks(CDNs). "Routing Request Redirection for CDN Interconnection", Xiaoyan He, Spencer Dawkins, Ge Chen, Wei Ni, Yunfei Zhang, 21-Feb-12, The Request Routing Interface comprises the asynchronous advertisement of footprint and capabilities by a dCDN that allows a uCDN to decide whether to redirect particular user requests to that dCDN; and the synchronous operation of actually redirecting a user request. This document describes protocol for the part of user requests redirection. "Conditioanal observe in CoAP", Shitao Li, 16-Feb-12, CoAP is a RESTful application protocol for constrained nodes and networks. This document defines a new mechanism in CoAP Observe so that a CoAP client can conditional observe a resource on a CoAP server. Note Discussion and suggestions for improvement are requested, and should be sent to core@ietf.org. "Tunneling Compressed Multiplexed Traffic Flows (TCMTF)", Jose Saldana, 16-Feb-12, This document describes a method to improve the bandwidth utilization of network paths that carry multiple streams in parallel between two endpoints, as in voice trunking. The method combines standard protocols that provide compression, multiplexing, and tunneling over a network path for the purpose of reducing the bandwidth used when multiple streams are carried over that path. "Address Acquisition For Multicast Content When Source and Receiver Support Differing IP Versions", Axel Clauberg, Mohamed Boucadair, Qiong Sun, Stig Venaas, Tina Tsou, 16-Feb-12, During the transition from IPv4 to IPv6, scenarios can occur where the IP version supported by the receiver differs from that supported by the source. This memo examines and evaluates alternative strategies for allowing the receiver to acquire multicast address information in such scenarios in the version it supports. "A Transparent Performance Enhancing Proxy Architecture To Enable TCP over Multiple Paths for Single-Homed Hosts", Tacettin Ayar, Berthold Rathke, Lukasz Budzisz, Adam Wolisz, 17-Feb-12, This draft complements the work of MPTCP by defining a TCP Splitter/ Combiner Architecture (SCA) that enables non-MPTCP-capable single- homed hosts to benefit from the multiple paths within Internet by means of performance enhancing proxies (PEPs) placed in the access networks. SCA Proxies (SCAPs) make use of multiple paths in a way which is completely transparent to end-hosts. Since the existence of the SCAPs is shielded from the TCP end-points, they can be deployed in the Internet as well as on the end-systems. "MIB Classification based use of SNMP cache or shared database", Haresh Khandelwal, 19-Feb-12, This memo defines classification of MIBs to use SNMP cache or shared database mechanism to reduce high CPU usage while SNMP MIBs are polled or GET operations performed from MIB browser. "List-Sequence header field for mailing lists", S Moonesamy, 19-Feb-12, The List-Sequence header field provides a standard location for identifying the sequence position of an individual message for a mailing list. "Practical Considerations and Implementation Experiences in Securing Smart Object Networks", Ari Keranen, Jari Arkko, Mohit Sethi, 20-Feb-12, This memo describes challenges associated with securing smart object devices in constrained implementations and environments. The memo describes a possible deployment model suitable for these environments, discusses the availability of cryptographic libraries for small devices, presents some experiences in implementing small devices using those libraries, and discusses trade-offs involving different types of approaches. "Session Initiation Protocol (SIP) Header Parameter for Debugging", Peter Dawes, 20-Feb-12, 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. A list of related IETF drafts and non-IETF specifications is included to help develop this topic. "Original-Authentication-Results Header Field", Monica Chew, Murray Kucherawy, 20-Feb-12, This memo defines a message header field for relaying message authentication results. The new field differs from the existing Authentication-Results message header field in that it is specifically used to relay message authentication results from one administrative domain to another. "ALTO Caching and Subscription", Nandiraju Ravishankar, Sreekanth Madhavan, 21-Feb-12, The specification of the ALTO protocol uses map based approaches assuming that the information provided is static for a longer period of time. But in some cases network operators reallocate IP subnets from time to time which in turn changes the mapping partitions[I- D.ietf-alto-deployments]. Since the ALTO clients are unaware of the map information changes, clients need to query the servers for every service request and many such requests are redundant because the information was not changed. The purpose of this memo is to provide two mechanisms which will help the ALTO clients to be informed of the map information changes. a) ALTO clients cache the map information and the servers provide the expiration time for invalidation. b) ALTO clients can subscribe for event notifications from the server "Revised Definition of The GMPLS Switching Capability and Type Fields", Lou Berger, Julien Meuric, 21-Feb-12, GMPLS provides control for multiple switching technologies, and hierarchical switching within a technology. GMPLS routing and signaling use common values to indicate switching technology type. These values are carried in routing in the Switching Capability field, and in signaling in the Switching Type field. While the values using in these fields are the primary indicators of the technology and hierarchy level being controlled, the values are not consistently defined and used across the different technologies supported by GMPLS. This document is intended to resolve the inconsistent definition and use of the Switching Capability and Type fields by narrowly scoping the meaning and use of the fields. This document updates any document that uses the GMPLS Switching Capability and Types fields, in particular RFC 3471, RFC 4202, RFC 4203, and RFC 5307. "Multiple APN Support for Trusted Wireless LAN Access", Sri Gundavelli, Mark Grayson, Yiu Lee, Hui Deng, Hidetoshi Yokota, 22-Feb-12, This specification defines a mechanism for extending multiple APN/ home-network support for a mobile node. "Laminar TCP and the case for refactoring TCP congestion control", Matt Mathis, 21-Feb-12, The primary state variables used by all TCP congestion control algorithms, cwnd and ssthresh are heavily overloaded, carrying different semantics in different states. This leads to excess implementation complexity and poorly defined behaviors under some combinations of events, such as loss recovery during cwnd validation. We propose a new framework for TCP congestion control, and to recast current standard algorithms to use new state variables. This new framework will not generally change the behavior of any of the primary congestion control algorithms when invoked in isolation but will to permit new algorithms with better behaviors in many corner cases, such as when two distinct primary algorithms are invoked concurrently. It will also foster the creation of new algorithms to address some events that are poorly treated by today's standards. For the vast majority of traditional algorithms the transformation to the new state variables is completely straightforward. However, the resulting implementation will technically be in violation of all existing TCP standards, even if it is fully compliant with their principles and intent. "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-Feb-12, 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. "IMAP Access to IETF Email List Archives", Robert Sparks, 21-Feb-12, The IETF makes heavy use of email lists to conduct its work. This often involves accessing the archived history of those email lists. Participants would like to have the ability to browse and search those archives using standard IMAP clients. This memo captures the requirements for providing a service that would allow such browsing and searching. "Default Nickname Based Approach for Multilevel TRILL", Ayan Banerjee, Janardhanan Pathangi, Jon Hudson, Les Ginsberg, Sam Aldrin, Sameer Merchant, Tissa Senevirathne, 21-Feb-12, Multilevel TRILL allows the interconnection of multiple TRILL networks to form a larger TRILL network without proportionally increasing the size of the IS-IS LSP DB. In this document, an approach based on default route concept is presented. Also, presented in the document is a novel method of constructing multi- destination trees using partial nickname space. Methods presented in this document are compatible with the RFC6325 specified data plane operations. "IPv6 Prefix Mobility Management Properties", Basavaraj Patil, Jouni Korhonen, Sri Gundavelli, 22-Feb-12, This specification defines an extension to the IPv6 Neighbor Discovery protocol and its Prefix Information Option. The Prefix Information Option is extended with flag bits that describe the mobility management properties associated to the prefix. This specification updates RFC4861. "An AR-level solution support for Distributed Mobility Management", Zhengming Ma, Xun Zhang, 22-Feb-12, The number of mobile users and their traffic demand is expected to be ever-increasing in future years, and this growth can represent a limitation for deploying current mobility management schemes that are intrinsically centralized, e.g., Mobile IPv6 and Proxy MIPv6. This evolution in user traffic demand is tackled by a different approach for IP mobility, called Distributed Mobility Management, which is focusing on moving the mobility anchors from the core network and pushing them closer to the users, at the edge of the network. The work presented here copes with the distributed approach, describing a novel solution for distributed mobility management support in a flat architecture without central mobility anchors. This document strictly abides by the two principles: (a)The movement of MN is transparent to CN. (b)MN doesn't participate in any mobility-related signaling.MAAR and AAA are responsible for managing IP mobility on behalf of the host. "A Route Optimization solution support for Distributed Mobility Management", Xun Zhang, Zhengming Ma, 22-Feb-12, The mobile users and their traffic demands are expected to be ever- increasing in future years, and this growth will impose a limitation for deploying current mobility management schemes that are intrinsically centralized, e.g., Mobile IPv6 and Proxy MIPv6. This evolution in user traffic demand can be tackled by a different approach for IP mobility, called Distributed Mobility Management, which is focusing on moving the mobility anchors from the core network and pushing them closer to the users, at the edge of the network. Following this idea, in our proposal, the central anchor is being deployed in the access router of the mobile node(MN). That is, the first elements that provide IP connectivity to a set of MNs are also the mobility managers for those MNs. In the following, we will call MAAR (Mobility anchor and Access Router). This draft strictly abides by the three principles: (1) The MN doesn't participate in any mobility-related signaling.MAAR and AAA are responsible for managing IP mobility on behalf of the host. (2) The MN's movement is transparent to the communication node (CN).The Home Address (HoA) and Care-of address (CoA) are not for users but for specific sessions in this draft.A MN initiates a session by using the MN's address assigned by a MAAR which the MN is registered as the HoA for this session.The MN's address assigned by a new MAAR which the MN moves to its access link as the CoA for the session. (3) The MN can directly forward packages to the CN and the packages don't need to pass the home mobility anchor. It can reduce the heavy burdens on home mobility anchor and maintain all the continuity of the conversation. "VCCV MPLS-TP Connectivity Verification (CV) Capability Advertisement", Greg Mirsky, 22-Feb-12, This document specifies how use of proactive Connectivity Verification, Continuity Check, and Remote Defect Indication for the MPLS Transport Profile [RFC6428] affects operation and management function election for PW VCCV [RFC5085], [RFC5885]. "Composite Link USe Cases and Design Considerations", Andrew Malis, Curtis Villamizar, Dave McDysan, Lucy Yong, Ning So, 22-Feb-12, This document provides a set of use cases and design considerations for composite links. Composite link is a formalization of multipath techniques currently in use in IP and MPLS networks and a set of extensions to multipath techniques. Note: symmvo in the draft name is the initials of the set of authors: So, Yong, McDysan, Malis, Villamizar, Osborne. This paragraph will be removed when/if this document is adopted as a WG item. "Using ITU-T-based IDs for MPLS-TP On-demand Connectivity Verification", Zhenlong Cui, Rolf Winter, 23-Feb-12, This document defines how to use ICC-based MPLS-TP identifiers for on-demand connectivity verification (CV) analogous to RFC 6426. New TLVs are defined to support on-demand CV based on identifiers following ITU-T conventions. "Proposal for selecting the default-route according to source address", Guillaume Habault, Laurent Toutain, Etienne Santerre, 23-Feb-12, SDSA approach is to assure that packets, going out the multihomed site, have the correct source address, regarding to the ISP and thus to avoid the ingress filtering problem. In that purpose, SDSA takes into account the source address in the site routing decision for outgoing packets, when default-route is involved. "SPDY Protocol", Mike Belshe, Roberto Peon, 23-Feb-12, This document describes SPDY, a protocol designed for low-latency transport of content over the World Wide Web. SPDY introduces two layers of protocol. The lower layer is a general purpose framing layer which can be used atop a reliable transport (likely TCP) for multiplexed, prioritized, and compressed data communication of many concurrent streams. The upper layer of the protocol provides HTTP- like RFC2616 [RFC2616] semantics for compatibility with existing HTTP application servers. "IDNA2008 implementation report", Takahiro NEMOTO, Yoshiro Yoneya, 23-Feb-12, This document reports implementation experience of IDNA2008 and findings from the implementation. "Additional Link Relation Types", James Snell, 23-Feb-12, This specification defines a number of additional Link Relation Types. "A framework for the use of SPMEs for shared mesh protection", David Allan, Greg Mirsky, 24-Feb-12, Shared mesh protection allows a set of diversely routed paths with diverse endpoints to collectively oversubcribe protection resources. Under normal conditions no single failure will result in the capacity of the associated protection resources to be exhausted. When multiple failures occur such that more than one path in the set of paths utilizing shared protection resources is affected, the necessity arises of pre-empting traffic on the basis of business priority rather than application priority. This memo describes the use of SPMEs and TC marking as a means of indicating business priority for shared mesh protection. "Models for adaptive-streaming-aware CDN Interconnection", Ray Brandenburg, 24-Feb-12, This documents presents thougths on the potential impact of supporting HTTP Adaptive Streaming technologies in CDN Interconnection scenarios. Our intent is to spur discussion on how the different CDNI interfaces should deal with content delivered using adaptive streaming technologies. "Certified Electronic Mail", Francesco Gennai, Luca Frosini, Alba Shahin, Claudio Petrucci, 24-Feb-12, This document specifies the requirements for a Certified Electronic Mail (CEM) system which provides people with proof of communication when exchanging emails, giving strong evidences to the users involved in the interchange. "A Constrained Application Protocol (CoAP) Usage for REsource LOcation And Discovery (RELOAD)", Jaime Jimenez, Jose Lopez-Vega, Jouni Maenpaa, Gonzalo Camarillo, 24-Feb-12, This document defines a Constrained Application Protocol (CoAP) Usage for REsource LOcation And Discovery (RELOAD). The CoAP Usage provides the functionality to federate Wireless Sensor Networks (WSN) in a peer-to-peer fashion. The CoAP Usage also provides a rendezvous service for CoAP Nodes and caching of sensor information. The RELOAD AppAttach method is used to establish a direct connection between nodes through which CoAP messages are exchanged. "CDNI Logging Formats for HTTP and HTTP Adaptive Streaming Deliveries", Francois Faucheur, Mahesh Viveganandhan, Kent Leung, 24-Feb-12, The interconnection of Content Distribution Networks (CDNs) is motivated by several use cases. CDN Interconnection can be achieved through four CDNI interfaces, one of which is the CDNI Logging interface. This document discusses CDNI logging formats for content deliveries performed using HTTP or HTTP adaptive streaming. "Offer/Answer Considerations for G.723 Annex A and G.729 Annex B", Muthu Perumal, Parthasarathi Ravindran, 24-Feb-12, [RFC4856] describes the annexa parameter for G723 and the annexb parameter for G729, G729D and G729E. However, the specification does not describe the offerer and answerer behavior when the value of the annexa or annexb parameter does not match in the SDP offer and answer. This document provides the offer/answer considerations for these parameters. "Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Translation ("IGMP/MLD Translation")", Simon Perreault, Tina Tsou, 24-Feb-12, This document describes translation between IPv4 and IPv6 of multicast flows by an IGMP/MLD proxy. This allows single-stack nodes to participate in multicast groups from a different address family. Both sending and receiving is supported by this translation mechanism. Both any-source and source-specific multicast (ASM and SSM) are supported as well. "Pro-active connectivity monitoring for TRILL", Rohit Watve, Tissa Senevirathne, Gayatri Ramachandran, 24-Feb-12, Pro-active fault monitoring for TRILL monitors all the paths between any two given RBridges in the network. Number of paths to be monitored can be of exponential order based on the distance between two RBridges. In this document novel fault monitoring mechanism based on a distributed approach is presented. "Encoding mLDP FECs in the NLRI of BGP MCAST-VPN Routes", IJsbrand Wijnands, Eric Rosen, Uwe Joorde, 24-Feb-12, Many service providers offer "BGP/MPLS IP VPN" service to their customers. Existing IETF standards specify the procedures and protocols that a service provider uses in order to offer this service to customers who have IP unicast and IP multicast traffic in their VPNs. It is also desirable to be able to support customers who have MPLS multicast traffic in their VPNs. This document specifies the procedures and protocol extensions that are needed to support customers who use the Multicast Extensions to Label Distribution Protocol (mLDP) as the control protocol for their MPLS multicast traffic. Existing standards do provide some support for customers who use mLDP, but only under a restrictive set of circumstances. This document generalizes the existing support to include all cases where the customer uses mLDP, without any restrictions. "New IP address format", C.V. Sreeraj, 24-Feb-12, This document specifies new addressing format and routing technique for the IP (Internet Protocol).This is a hierarchical, scalable design , the source and destination address varies depending on the level of network. "mLDP Node Protection", IJsbrand Wijnands, Eric Rosen, Kamran Raza, Jeff Tantsura, Alia Atlas, 24-Feb-12, This document describes procedures to support node protection for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths (MP LSPs) built by LDP ("Label Distribution Protocol"), or simply mLDP. In order to protect a node N, the Point of Local Repair (PLR) LSR of N must learn the Merge Point (MPT) LSR(s) of node N such that traffic can be redirected to them in case node N fails. Redirecting the traffic around the failed node N depends on existing P2P LSPs originated from the PLR LSR to the MPT LSRs while bypassing LSR node N. Web Authorization Protocol (oauth) ---------------------------------- "The OAuth 2.0 Authorization Protocol", Eran Hammer-Lahav, David Recordon, Dick Hardt, 20-Jan-12, The OAuth 2.0 authorization protocol enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. "The OAuth 2.0 Authorization Protocol: Bearer Tokens", Michael Jones, Dick Hardt, David Recordon, 17-Feb-12, This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport. "SAML 2.0 Bearer Assertion Profiles for OAuth 2.0", Chuck Mortimore, 3-Jan-12, This specification defines the use of a SAML 2.0 Bearer Assertion as means for requesting an OAuth 2.0 access token as well as for use as a means of client authentication. "HTTP Authentication: MAC Access Authentication", Eran Hammer-Lahav, 8-Feb-12, This document specifies the HTTP MAC access authentication scheme, an HTTP authentication method using a message authentication code (MAC) algorithm to provide cryptographic verification of portions of HTTP requests. The document also defines an OAuth 2.0 binding for use as an access-token type. "OAuth 2.0 Threat Model and Security Considerations", Mark McGloin, Phil Hunt, Torsten Lodderstedt, 19-Feb-12, This document gives security considerations based on a comprehensive threat model for the OAuth 2.0 Protocol. "OAuth 2.0 Assertion Profile", Michael Jones, Brian Campbell, Yaron Goland, 31-Oct-11, This specification provides a general framework for the use of assertions as client credentials and/or authorization grants with OAuth 2.0. It includes a generic mechanism for transporting assertions during interactions with a token endpoint, as wells as rules for the content and processing of those assertions. The intent is to provide an enhanced security profile by using derived values such as signatures or HMACs, as well as facilitate the use of OAuth 2.0 in client-server integration scenarios where the end-user may not be present. This specification only defines abstract message flow and assertion content. Actual use requires implementation of a companion protocol binding specification. Additional profile documents provide standard representations in formats such as SAML and JWT. "An IETF URN Sub-Namespace for OAuth", Hannes Tschofenig, 3-Jan-12, This document establishes an IETF URN Sub-namespace for use with OAuth related specifications. Operations and Management Area Working Group (opsawg) ----------------------------------------------------- "Problem Statement for the Automated Configuration of Large IP Networks", Tina Tsou, Juergen Schoenwaelder, Yang Shi, Tom Taylor, 31-Oct-11, This memo discusses the steps required to bring a large number of devices into service in IP networks in an automated fashion. The goal of this document is to list known solutions where they exist and to identify gaps that require further specifications. "An Overview of the IETF Network Management Standards", Benoit Claise, Mehmet Ersue, 19-Feb-12, This document gives an overview of the IETF network management standards and summarizes existing and ongoing development of IETF standards-track network management protocols and data models. The purpose of this document is on the one hand to help system developers and users to select appropriate standard management protocols and data models to address relevant management needs. On the other hand, the document can be used as an overview and guideline by other Standard Development Organizations or bodies planning to use IETF management technologies and data models. Operational Security Capabilities for IP Network Infrastructure (opsec) ----------------------------------------------------------------------- "Security Best Practices Efforts and Documents", Chris Lonvick, David Spak, 23-Sep-11, This document provides a snapshot of the current efforts to define or apply security requirements in various Standards Developing Organizations (SDO). "Recommendations for filtering ICMP messages", Carlos Pignataro, Fernando Gont, Guillermo Gont, 17-Feb-12, This document document provides advice on the filtering of ICMPv4 and ICMPv6 messages. Additionaly, it discusses the operational and interoperability implications of such filtering. Open Shortest Path First IGP (ospf) ----------------------------------- "OSPFv2 Multi-Instance Extensions", Acee Lindem, Abhay Roy, Sina Mirtorabi, 19-Jan-12, OSPFv3 includes a mechanism to support multiple instances of the protocol running on the same interface. OSPFv2 can utilize such a mechanism in order to support multiple routing domains on the same subnet. This document defines the OSPFv2 instance ID to enable separate OSPFv2 protocol instances on the same interface. Unlike OSPFv3 where the instance ID can be used for multiple purposes, such as putting the same interface in multiple areas, the OSPFv2 instance ID is reserved for identifying protocol instances. This document updates RFC 2328. "OSPF Transport Instance Extensions", Acee Lindem, Abhay Roy, Sina Mirtorabi, 10-Oct-11, OSPFv2 and OSPFv3 include a reliable flooding mechanism to disseminate routing topology and Traffic Engineering (TE) information within a routing domain. Given the effectiveness of these mechanisms, it is convenient to envision using the same mechanism for dissemination of other types of information within the domain. However, burdening OSPF with this additional information will impact intra-domain routing convergence and possibly jeopardize the stability of the OSPF routing domain. This document presents mechanism to relegate this ancillary information to a separate OSPF instance and minimize the impact. "Routing for IPv4-embedded IPv6 Packets", Dean Cheng, Mohammed Boucadair, 11-Oct-11, This document describes routing packets destined to IPv4-embedded IPv6 addresses across IPv6 transit core using OSPFv3 with a separate routing table. "Security Extension for OSPFv2 when using Manual Key Management", Manav Bhatia, Sam Hartman, Dacheng Zhang, Acee Lindem, 26-Oct-11, The current OSPFv2 cryptographic authentication mechanism as defined in the OSPF standards is vulnerable to both inter-session and intra- session replay attacks when its uses manual keying. Additionally, the existing cryptographic authentication schemes do not cover the IP header. This omission can be exploited to carry out various types of attacks. This draft proposes changes to the authentication sequence number mechanism that will protect OSPFv2 from both inter-session and intra- session replay attacks when its using manual keys for securing its protocol packets. Additionally, we also describe some changes in the cryptographic hash computation so that we eliminate most attacks that result because OSPFv2 does not protect the IP header. "Hiding Transit-only Networks in OSPF", Abhay Roy, Alvaro Retana, Yi Yang, 2-Feb-12, A transit-only network is defined as a network connecting routers only. In OSPF, transit-only networks are usually configured with routable IP addresses, which are advertised in Link State Advertisements (LSAs) but not needed for data traffic. In addition, remote attacks can be launched against routers by sending packets to these transit-only networks. This document presents a mechanism to hide transit-only networks to speed up network convergence and minimize remote attack vulnerability. "OSPF Hybrid Broadcast and P2MP Interface Type", Nischal Sheth, Lili Wang, Jeffrey Zhang, 5-Oct-11, This document describes a mechanism to model a broadcast network as a hybrid of broadcast and point-to-multipoint networks for purposes of OSPF operation. Neighbor discovery and maintenance as well as LSA database synchronization are performed using the broadcast model, but the network is represented using the point-to-multipoint model in the router LSAs of the routers connected to it. This allows an accurate representation of the cost of communication between different routers on the network, while maintaining the network efficiency of broadcast operation. This approach is relatively simple and requires minimal changes to OSPF. "Use of OSPF-MDR in Single-Hop Broadcast Networks", Richard Ogier, 13-Oct-11, RFC 5614 (OSPF-MDR) extends OSPF to support mobile ad hoc networks (MANETs) by specifying its operation on the new OSPF interface of type MANET. This document describes the use of OSPF-MDR in a single-hop broadcast network, which is a special case of a MANET in which each router is a (one-hop) neighbor of each other router. Unlike an OSPF broadcast interface, such an interface can have a different cost associated with each neighbor. The document includes configuration recommendations and simplified mechanisms that can be used in single-hop broadcast networks. "OSPF Traffic Engineering (TE) Metric Extensions", Alia Atlas, John Drake, Spencer Giacalone, Stefano Previdi, David Ward, 1-Nov-11, In certain networks, such as, but not limited to, financial information networks (e.g. stock market data providers), network performance criteria (e.g. latency) are becoming as critical to data path selection as other metrics. This document describes extensions to OSPF TE [RFC3630] such that network performance information can be distributed and collected in a scalable fashion. The information distributed using OSPF TE Express Path can then be used to make path selection decisions based on network performance. Note that this document only covers the mechanisms with which network performance information is distributed. The mechanisms for measuring network performance or acting on that information, once distributed, are outside the scope of this document. Peer-to-Peer Session Initiation Protocol (p2psip) ------------------------------------------------- "Concepts and Terminology for Peer to Peer SIP", David Bryan, Dean Willis, Eunsoo Shim, Philip Matthews, Spencer Dawkins, 31-Oct-11, This document defines concepts and terminology for the use of the Session Initiation Protocol in a peer-to-peer environment where the traditional proxy-registrar and message routing functions are replaced by a distributed mechanism. These mechansims may be implemented using a distributed hash table or other distributed data mechanism with similar external properties. This document includes a high-level view of the functional relationships between the network elements defined herein, a conceptual model of operations, and an outline of the related problems addressed by the P2PSIP working group and the RELOAD protocol ([I-D.ietf-p2psip-base], [I-D.ietf-p2psip-sip]) defined by the working group. "REsource LOcation And Discovery (RELOAD) Base Protocol", Cullen Jennings, Bruce Lowekamp, Eric Rescorla, Salman Baset, Henning Schulzrinne, 17-Jan-12, This specification defines REsource LOcation And Discovery (RELOAD), a peer-to-peer (P2P) signaling protocol for use on the Internet. A P2P signaling protocol provides its clients with an abstract storage and messaging service between a set of cooperating peers that form the overlay network. RELOAD is designed to support a P2P Session Initiation Protocol (P2PSIP) network, but can be utilized by other applications with similar requirements by defining new usages that specify the kinds of data that must be stored for a particular application. RELOAD defines a security model based on a certificate enrollment service that provides unique identities. NAT traversal is a fundamental service of the protocol. RELOAD also allows access from "client" nodes that do not need to route traffic or store data for others. "A SIP Usage for RELOAD", Cullen Jennings, Bruce Lowekamp, Eric Rescorla, Salman Baset, Henning Schulzrinne, 17-Jan-12, This document defines a SIP Usage for REsource LOcation And Discovery (RELOAD), The SIP Usage provides the functionality of a SIP proxy or registrar in a fully-distributed system. The SIP Usage provides lookup service for AoRs stored in the overlay. The SIP Usage also defines GRUUs that allow the registrations to map an AoR to a specific node reachable through the overlay. The AppAttach method is used to establish a direct connection between nodes through which SIP messages are exchanged. "P2PSIP Overlay Diagnostics", David Bryan, XingFeng Jiang, Roni Even, Haibin Song, 28-Dec-11, This document describes mechanisms for P2PSIP diagnostics. It defines extensions to the RELOAD P2PSIP base protocol RELOAD [I-D.ietf-p2psip-base] to collect diagnostic information, and details the protocol specifications for these extensions. Useful diagnostic information for connection and node status monitoring is also defined. The document also describes the usage scenarios and provides examples of how these methods are used to perform diagnostics in a P2PSIP overlay networks. "A Self-tuning Distributed Hash Table (DHT) for REsource LOcation And Discovery (RELOAD)", Jouni Maenpaa, Gonzalo Camarillo, Jani Hautakorpi, 6-Jan-12, REsource LOcation And Discovery (RELOAD) is a peer-to-peer (P2P) signaling protocol that provides an overlay network service. Peers in a RELOAD overlay network collectively run an overlay algorithm to organize the overlay, and to store and retrieve data. This document describes how the default topology plugin of RELOAD can be extended to support self-tuning, that is, to adapt to changing operating conditions such as churn and network size. "Service Discovery Usage for REsource LOcation And Discovery (RELOAD)", Jouni Maenpaa, Gonzalo Camarillo, 6-Jan-12, REsource LOcation and Discovery (RELOAD) does not define a generic service discovery mechanism as part of the base protocol. This document defines how the Recursive Distributed Rendezvous (ReDiR) service discovery mechanism used in OpenDHT can be applied to RELOAD overlays to provide a generic service discovery mechanism. "An extension to RELOAD to support Direct Response Routing", Yunfei Zhang, Ning Zong, Roni Even, 29-Nov-11, This document proposes an optional extension to RELOAD to support direct response routing mode. RELOAD recommends symmetric recursive routing for routing messages. The new optional extension provides a shorter route for responses reducing the overhead on intermediary peers and describes the potential cases where this extension can be used. "An extension to RELOAD to support Relay Peer Routing", Ning Zong, Roni Even, Yunfei Zhang, 29-Nov-11, This document proposes an optional extension to RELOAD to support relay peer routing mode. RELOAD recommends symmetric recursive routing for routing messages. The new optional extension provides a shorter route for responses reducing the overhead on intermediary peers and describes the potential cases where this extension can be used. Protocol to Access WS database (paws) ------------------------------------- "Protocol to Access White Space database: PS, use cases and rqmts", Scott Probasco, Basavaraj Patil, 26-Jan-12, Portions of the radio spectrum that are allocated to a licensed, primary user but are unused or unoccupied at specific locations and times are defined as "white space". The concept of allowing secondary transmissions (licensed or unlicensed) in white space is a technique to "unlock" existing spectrum for new use. An obvious requirement is that these secondary transmissions do not interfere with the primary use of the spectrum. One approach to using the white space spectrum at a given time and location is to verify with a database available channels. This document describes the concept of TV White Spaces. It also describes the problems that need to be addressed for enabling the use of the primary user owned white space spectrum for secondary users, without causing interference, by querying a database which knows the channel availability at any given location and time. A number of possible use cases of this spectrum and derived requirements are also described. Audio/Video Transport Payloads (payload) ---------------------------------------- "RTP payload format for Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW)", Zheng Fang, 22-Feb-12, This document specifies real-time transport protocol (RTP) payload formats to be used for the Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW). Three media type registrations are included for EVRC-NW RTP payload formats. In addition, a file format is specified for transport of EVRC-NW speech data in storage mode applications such as e-mail. "RTP Payload Format for MVC Video", Robert Skupin, Thomas Schierl, Ye-Kui Wang, 7-Sep-11, This memo describes an RTP payload format for the multiview extension of the ITU-T Recommendation H.264 video codec that is technically identical to ISO/IEC International Standard 14496-10. The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units, produced by the video encoder, in each RTP payload. The payload format can be applied in RTP based 3D video transmissions such as such as 3D video streaming, free-viewpoint video, and 3DTV. "RTP Payload Format for G.718 Speech/Audio", Ari Lakaniemi, Yekui Wang, Glen Zorn, 15-Nov-11, This document specifies the Real-Time Transport Protocol (RTP) payload format for the Embedded Variable Bit-Rate (EV-VBR) speech/ audio codec, specified in ITU-T G.718. A media type registration for this RTP payload format is also included. "RTP Payload Format for VP8 Video", Patrik Westin, Henrik Lundin, 24-Jan-12, This memo describes an RTP payload format for the VP8 video codec. The payload format has wide applicability, as it supports applications from low bit-rate peer-to-peer usage, to high bit-rate video conferences. "RTP Payload Format for SMPTE 336M Encoded Data", Jeff Downs, J. Arbeiter, 1-Feb-12, This document specifies the payload format for packetization of KLV (Key-Length-Value) Encoded Data, as defined by the Society of Motion Picture and Television Engineers (SMPTE) in SMPTE 336M, into the Real-time Transport Protocol (RTP). "RTP Payload Format for Bluetooth's SBC Audio Codec", Christian Hoene, Frans Bont, 4-Jan-12, This document specifies a Real-time Transport Protocol (RTP) payload format to be used for the low complexity subband codec (SBC), which is the mandatory audio codec of the Advanced Audio Distribution Profile (A2DP) Specification written by the Bluetooth(r) Special Interest Group (SIG). The payload format is designed to be able to interoperate with existing Bluetooth A2DP devices, to provide high streaming audio quality, interactive audio transmission over the internet, and ultra-low delay coding for jam sessions on the internet. This document contains also a media type registration which specifies the use of the RTP payload format. Path Computation Element (pce) ------------------------------ "Extensions to the Path Computation Element communication Protocol (PCEP) for Inter-Layer MPLS and GMPLS Traffic Engineering", Eiji Oki, Tomonori Takeda, Adrian Farrel, Fatai Zhang, 3-Jan-12, The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. MPLS and GMPLS networks may be constructed from layered service networks. It is advantageous for overall network efficiency to provide end-to-end traffic engineering across multiple network layers through a process called inter-layer traffic engineering. PCE is a candidate solution for such requirements. The PCE communication Protocol (PCEP) is designed as a communication protocol between Path Computation Clients (PCCs) and PCEs. This document presents PCEP extensions for inter-layer traffic engineering. "Document:", Diego Caviglia, Fatai Zhang, Kenichi Ogaki, Tomohiro Otani, 5-Jan-12, The initial effort of PCE WG is specifically focused on MPLS (Multi- protocol label switching). As a next step, this draft describes functional requirements for GMPLS (Generalized MPLS) application of PCE (Path computation element). "Conveying Vendor-Specific Constraints in the Path Computation Element Protocol", Fatai Zhang, Adrian Farrel, Greg Bernstein, 1-Dec-11, The Path Computation Element Protocol (PCEP) is used to convey path computation requests and responses between Path Computation Clients (PCCs) and Path Computation Elements (PCEs), and also between cooperating PCEs. In PCEP the path computation requests carry details of the constraints and objective functions that the PCC wishes the PCE to apply in its computation. The mechanisms defined for indicating objective functions include the capability to convey vendor-specific objective functions. This document defines a facility to carry vendor-specific constraints in PCEP. "PCEP Requirements for WSON Routing and Wavelength Assignment", Greg Bernstein, Jonas Martensson, Oscar Dios, Takehiro Tsuritani, Tomonori Takeda, Young Lee, 30-Oct-11, This memo provides application-specific requirements for the Path Computation Element communication Protocol (PCEP) for the support of Wavelength Switched Optical Networks (WSON). Lightpath provisioning in WSONs requires a routing and wavelength assignment (RWA) process. From a path computation perspective, wavelength assignment is the process of determining which wavelength can be used on each hop of a path and forms an additional routing constraint to optical light path computation. Requirements for Optical impairments will be addressed in a separate document. "PCEP extensions for GMPLS", Cyril Margaria, Fatai Zhang, Oscar Dios, 31-Oct-11, This memo provides extensions for the Path Computation Element communication Protocol (PCEP) for the support of GMPLS control plane. "Applicability of the Path Computation Element to Inter-Area and Inter-AS MPLS and GMPLS Traffic Engineering", Daniel King, Julien Meuric, Olivier Dugeon, Quintin Zhao, Oscar Dios, Francisco Chico, 16-Jan-12, The Path Computation Element (PCE) may be used for computing services that traverse multi-area and multi-AS Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered (TE) networks. This document examines the applicability of the PCE architecture, protocols, and protocol extensions for computing multi-area and multi-AS paths in MPLS and GMPLS networks. "PCE-based Computation Procedure To Compute Shortest Constrained P2MP Inter-domain Traffic Engineering Label Switched Paths", Quintin Zhao, Dhruv Dhody, Zafar Ali, Siva Sivabalan, Daniel King, Ramon Casellas, 30-Oct-11, The ability to compute paths for constrained point-to-multipoint (P2MP) Traffic Engineering Label Switched Paths (TE LSPs) across multiple domains has been identified as a key requirement for the deployment of P2MP services in MPLS and GMPLS networks. The Path Computation Element (PCE) has been recognized as an appropriate technology for the determination of inter-domain paths of P2MP TE LSPs. This document describes the procedures and extensions to the PCE communication Protocol (PCEP) to handle requests and responses for the computation of inter-domain paths for P2MP TE LSPs. "The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS and GMPLS", Adrian Farrel, Daniel King, 4-Oct-11, Computing optimum routes for Label Switched Paths (LSPs) across multiple domains in MPLS Traffic Engineering (MPLS-TE) and GMPLS networks presents a problem because no single point of path computation is aware of all of the links and resources in each domain. A solution may be achieved using the Path Computation Element (PCE) architecture. Where the sequence of domains is known a priori, various techniques can be employed to derive an optimum path. If the domains are simply-connected, or if the preferred points of interconnection are also known, the Per-Domain Path Computation technique can be used. Where there are multiple connections between domains and there is no preference for the choice of points of interconnection, the Backward Recursive Path Computation Procedure (BRPC) can be used to derive an optimal path. This document examines techniques to establish the optimum path when the sequence of domains is not known in advance. The document shows how the PCE architecture can be extended to allow the optimum sequence of domains to be selected, and the optimum end-to-end path to be derived through the use of a hierarchical relationship between domains. Congestion and Pre-Congestion Notification (pcn) ------------------------------------------------ "Encoding 3 PCN-States in the IP header using a single DSCP", Bob Briscoe, Toby Moncaster, Michael Menth, 18-Aug-11, The objective of Pre-Congestion Notification (PCN) is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain. The overall rate of the PCN-traffic is metered on every link in the PCN domain, and PCN-packets are appropriately marked when certain configured rates are exceeded. Egress nodes pass information about these PCN-marks to decision points which then decide whether to admit or block new flow requests or to terminate some already-admitted flows during serious pre-congestion. This document specifies how PCN-marks are to be encoded into the IP header by re-using the Explicit Congestion Notification (ECN) codepoints within a PCN-domain. This encoding provides for up to three different PCN marking states using a single DSCP: not-marked (NM), threshold-marked (ThM) and excess-traffic-marked (ETM). Hence, it is called the 3-in-1 PCN encoding. This document obsoletes RFC5696. "PCN Boundary Node Behaviour for the Controlled Load (CL) Mode of Operation", Anna Charny, Fortune Huang, Georgios Karagiannis, Michael Menth, Tom Taylor, 22-Feb-12, Pre-congestion notification (PCN) is a means for protecting the quality of service for inelastic traffic admitted to a Diffserv domain. The overall PCN architecture is described in RFC 5559. This memo is one of a series describing possible boundary node behaviours for a PCN-domain. The behaviour described here is that for a form of measurement-based load control using three PCN marking states, not- marked, threshold-marked, and excess-traffic-marked. This behaviour is known informally as the Controlled Load (CL) PCN-boundary-node behaviour. "Overview of Pre-Congestion Notification Encoding", Georgios Karagiannis, Kwok Chan, Toby Moncaster, Michael Menth, Philip Eardley, Bob Briscoe, 8-Feb-12, The objective of Pre-Congestion Notification (PCN) is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain. On every link in the PCN domain, the overall rate of the PCN-traffic is metered, and PCN-packets are appropriately marked when certain configured rates are exceeded. Egress nodes provide decision points with information about the PCN-marks of PCN-packets which allows them to take decisions about whether to admit or block a new flow request, and to terminate some already admitted flows during serious pre- congestion. The PCN Working Group explored a number of approaches for encoding this pre-congestion information into the IP header. This document provides details of all those approaches along with an explanation of the constraints that had to be met by any solution. "PCN Boundary Node Behaviour for the Single Marking (SM) Mode of Operation", Anna Charny, Georgios Karagiannis, Michael Menth, Tom Taylor, 22-Feb-12, Pre-congestion notification (PCN) is a means for protecting the quality of service for inelastic traffic admitted to a Diffserv domain. The overall PCN architecture is described in RFC 5559. This memo is one of a series describing possible boundary node behaviours for a PCN-domain. The behaviour described here is that for a form of measurement-based load control using two PCN marking states, not- marked, and excess-traffic-marked. This behaviour is known informally as the Single Marking (SM) PCN-boundary-node behaviour. "Requirements for Signaling of (Pre-) Congestion Information in a DiffServ Domain", Georgios Karagiannis, Tom Taylor, Kwok Chan, Michael Menth, Philip Eardley, 8-Feb-12, Precongestion notification (PCN) is a means for protecting quality of service for inelastic traffic admitted to a Diffserv domain. The overall PCN architecture is described in RFC 5559. This memo describes the requirements for the signaling applied within the PCN domain: (1) PCN-feedback-information is carried from the PCN-egress- node to the decision point;(2) the decision point may ask the PCN- ingress-node to measure, and report back, the rate of sent PCN- traffic between that PCN-ingress-node and PCN-egress-node. The decision point may be either collocated with the PCN-ingress-node or a centralized node (in the first case, (2) is not required). The signaling requirements pertain in particular to two edge behaviors, "controlled load (CL)" and "single marking (SM)". Port Control Protocol (pcp) --------------------------- "Port Control Protocol (PCP)", Stuart Cheshire, Mohammed Boucadair, Paul Selkirk, Dan Wing, Reinaldo Penno, 10-Feb-12, The Port Control Protocol allows an IPv6 or IPv4 host to control how incoming IPv6 or IPv4 packets are translated and forwarded by a network address translator (NAT) or simple firewall, and also allows a host to optimize its outgoing NAT keepalive messages. "DHCP Options for the Port Control Protocol (PCP)", Mohamed Boucadair, Reinaldo Penno, Dan Wing, 12-Jan-12, This document specifies DHCP (IPv4 and IPv6) options to configure hosts with Port Control Protocol (PCP) Server addresses. The use of DHCPv4 or DHCPv6 depends on the PCP deployment scenario. "Universal Plug and Play (UPnP) Internet Gateway Device (IGD)-Port Control Protocol (PCP) Interworking Function", Mohamed Boucadair, Francis Dupont, Reinaldo Penno, Dan Wing, 21-Nov-11, This document specifies the behavior of the UPnP IGD (Internet Gateway Device)/PCP Interworking Function. An UPnP IGD-PCP Interworking Function (IGD-PCP IWF) is required to be embedded in CP routers to allow for transparent NAT control in environments where UPnP is used in the LAN side and PCP in the external side of the CP router. Protocol Independent Multicast (pim) ------------------------------------ "Population Count Extensions to PIM", Dino Farinacci, Greg Shepherd, Yiqun Cai, Stig Venaas, 5-Jan-12, This specification defines a method for providing multicast distribution-tree accounting data. Simple extensions to the PIM protocol allow a rough approximation of tree-based data in a scalable fashion. "A Reliable Transport Mechanism for PIM", Dino Farinacci, IJsbrand Wijnands, Stig Venaas, Maria Napierala, 24-Oct-11, This document defines a reliable transport mechanism for the PIM protocol for transmission of Join/Prune messages. This eliminates the need for periodic Join/Prune message transmission and processing. The reliable transport mechanism can use either TCP or SCTP as the transport protocol. "Protocol Independent Multicast ECMP Redirect", Yiqun Cai, Liming Wei, Heidi Ou, Vishal Arya, Sunil Jethwani, 2-Feb-12, A PIM router uses the RPF procedure to select an upstream interface and router to build forwarding state. When there are equal cost multiple paths (ECMP), existing implementations often use hash algorithms to select a path. Such algorithms do not allow the spread of traffic among the ECMPs according to administrative metrics. This usually leads to inefficient or ineffective use of network resources. This document introduces the ECMP Redirect, a mechanism to improve the RPF procedure over ECMPs. It allows ECMP path selection to be based on administratively selected metrics, such as data transmission delays, path preferences and routing metrics. "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", Bill Fenner, Hugh Holbrook, Isidor Kouvelas, Lianshu Zheng, Mark Handley, Rishabh Parekh, Jeffrey Zhang, 27-Oct-11, This document specifies Protocol Independent Multicast - Sparse Mode (PIM-SM). PIM-SM is a multicast routing protocol that can use the underlying unicast routing information base or a separate multicast- capable routing information base. It builds unidirectional shared trees rooted at a Rendezvous Point (RP) per group, and optionally creates shortest-path trees per source. This document addresses errata filed against RFC 4601, and removes the optional (*,*,RP) feature that lacks sufficient deployment experience. "IGMP/MLD-Based Explicit Membership Tracking Function for Multicast Routers", Hitoshi Asaeda, Nicolai Leymann, 10-Oct-11, This document describes the IGMP/MLD-based explicit membership tracking function for multicast routers. The explicit tracking function is useful for accounting and contributes to saving network resource and fast leaves (i.e. shortened leave latency). Public-Key Infrastructure (X.509) (pkix) ---------------------------------------- "Internet X.509 Public Key Infrastructure -- HTTP Transport for CMP", Tomi Kause, Martin Peylo, 16-Feb-12, This document describes how to layer the Certificate Management Protocol over HTTP. It is the "CMPtrans" document referenced in RFC 4210 and therefore updates the reference given therein. "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", Dave Cooper, Stefan Santesson, 3-Oct-11, This document specifies a protocol useful in determining the current status of a digital certificate without requiring CRLs. "S/MIME Capabilities for Public Key Definitions", Jim Schaad, 15-Nov-11, This document defines a set of S/MIME Capability types for ASN.1 encoding for the current set of public keys define in the PKIX working group. This facilitates the ability for a requester to specify information on the public keys and signature algorithms to be used in responses. An example of where this is used is with the OCSP Agility draft. "DNS Certification Authority Authorization (CAA) Resource Record", Phillip Hallam-Baker, Rob Stradling, 13-Feb-12, The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify the certificate signing certificate(s) authorized to issue certificates for that domain. CAA resource records allow a public Certification Authority to implement additional controls to reduce the risk of unintended certificate mis- issue. "CMC Extensions: Server Key Generation", Jim Schaad, Paul Timmel, Sean Turner, 2-Jan-12, This document defines a set of extensions to the Certificate Management over CMS (CMC) protocol that addresses the desire to support server-side generation of keys. This service is provided by the definition of additional control statements within the CMC architecture. Additional CMC errors are also defined. "Enrollment over Secure Transport", Max Pritikin, Peter Yee, 6-Jan-12, This document profiles certificate enrollment for clients using Certificate Management over CMS (CMC) messages over a secure transport. This profile, called Enrollment over Secure Transport (EST), describes a simple yet functional certificate management protocol targeting simple Public Key Infrastructure clients that need to acquire client certificate(s) and associated Certification Authority (CA) certificate(s). Peer to Peer Streaming Protocol (ppsp) -------------------------------------- "Problem Statement of Peer-to-Peer Streaming Protocol (PPSP)", Yunfei Zhang, Gonzalo Camarillo, Yang Yang, 15-Nov-11, Peer-to-Peer(P2P for short) streaming systems show more and more popularity in current Internet with proprietary protocols. This document identifies problems of the proprietary protocols, proposes a Peer to Peer Streaming Protocol(PPSP) including tracker and peer signaling components, and discusses the scope and uses cases of PPSP. "P2P Streaming Protocol (PPSP) Requirements", Carl Williams, Lin Xiao, Ning Zong, Victor Pascual, Yunfei Zhang, 8-Oct-11, The objective of the PPSP work is to standardize the key signaling protocols that apply to tracker and peers in a Peer-to-Peer (P2P) streaming system. These protocols are called PPSP. This document enumerates the requirements for the PPSP, which should be considered when designing PPSP. "Peer-to-Peer Streaming Peer Protocol (PPSPP)", A. Bakker, 29-Jan-12, The Peer-to-Peer Streaming Peer Protocol (PPSPP) 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 PPSPP, 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, or as a RTP profile. Features of PPSPP 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, PPSPP can also use different congestion control algorithms, such as LEDBAT, and offer transparent NAT traversal. Finally, PPSPP maintains only a small amount of state per peer and detects malicious modification of content. This documents describes PPSPP and how it satisfies the requirements for the IETF Peer-to-Peer Streaming Protocol (PPSP) Working Group's peer protocol. Preparation and Comparison of Internationalized Strings (precis) ---------------------------------------------------------------- "Stringprep Revision Problem Statement", Andrew Sullivan, Marc Blanchet, 13-Jan-12, Using Unicode codepoints in protocol strings that expect comparison with other strings requires preparation of the string that contains the Unicode codepoints. Internationalizing Domain Names in Applications (IDNA2003) defined and used Stringprep and Nameprep. Other protocols subsequently defined Stringprep profiles. A new approach different from Stringprep and Nameprep is used for a revision of IDNA2003 (called IDNA2008). Other Stringprep profiles need to be similarly updated or a replacement of Stringprep needs to be designed. This document outlines the issues to be faced by those designing a Stringprep replacement. "PRECIS Framework: Handling Internationalized Strings in Protocols", Marc Blanchet, Peter Saint-Andre, 30-Oct-11, Application protocols that make use of Unicode code points in protocol strings need to prepare such strings in order to perform comparison operations (e.g., for purposes of authentication or authorization). In general, this problem has been labeled the "preparation and comparison of internationalized strings" or "PRECIS". This document defines a framework that enables application protocols to prepare various classes of strings in a way that depends on the properties of Unicode code points. Because this framework does not depend on large tables of Unicode code points as in stringprep (RFC 3454), it is more agile with regard to changes in the underlying Unicode database and thus provides improved flexibility to application protocols. A specification that uses this framework either can directly use the base string classes defined in this document or can subclass the base string classes as needed. This framework uses an approach similar to that of the revised internationalized domain names in applications (IDNA) technology (RFC 5890, RFC 5891, RFC 5892, RFC 5893, RFC 5894) and thus adheres to the high-level design goals described in RFC 4690, albeit for application technologies other than the Domain Name System (DNS). This document obsoletes RFC 3454. Pseudowire Emulation Edge to Edge (pwe3) ---------------------------------------- "Encapsulation Methods for Transport of Fibre Channel Traffic over MPLS Networks", David Black, Linda Dunbar, Moran Roth, Ronen Solomon, 3-May-11, A Fibre Channel pseudowire (PW) is used to carry Fibre Channel traffic over an MPLS network. This enables service providers to take advantage of MPLS to offer "emulated" Fibre Channel services. This document specifies the encapsulation of Fibre Channel traffic within a pseudowire. It also specifies the common procedures for using a PW to provide a Fibre Channel service. "Pseudowire Preferential Forwarding Status Bit", Praveen Muley, Mustapha Aissaoui, 21-Sep-11, This document describes a mechanism for standby status signaling of redundant pseudowires (PWs) between their termination points. A set of redundant PWs is configured between provider edge (PE) nodes in single-segment pseudowire (SS-PW) applications, or between terminating provider edge (T-PE) nodes in multi-segment pseudowire (MS-PW) applications. In order for the PE/T-PE nodes to indicate the preferred PW to use for forwarding PW packets to one another, a new status bit is needed to indicate a preferential forwarding status of Active or Standby for each PW in a redundant set. In addition, a second status bit is defined to allow peer PE nodes to coordinate a switchover operation of the PW. "Pseudowire Redundancy", Praveen Muley, Mustapha Aissaoui, Matthew Bocci, 16-Feb-12, This document describes a framework comprised of a number of scenarios and associated requirements for pseudowire (PW) redundancy. A set of redundant PWs is configured between provider edge (PE) nodes in single segment PW applications, or between Terminating PE nodes in Multi-Segment PW applications. In order for the PE/T-PE nodes to indicate the preferred PW to use for forwarding PW packets to one another, a new PW status is required to indicate the preferential forwarding status of active or standby for each PW in the redundancy set. "Requirements and Framework for Point-to-Multipoint Pseudowires over MPLS PSNs", Matthew Bocci, Giles Heron, Yuji Kamite, 8-Sep-11, This document presents a set of requirements and a framework for providing a Point-to-Multipoint Pseudowire (PW). The requirements identified in this document are related to architecture, signaling and maintenance aspects of Point-to-Multipoint PW operation. They are proposed as guidelines for the standardization of such mechanisms. Among other potential applications Point-to-Multipoint PWs SHOULD be used to optimize the support of multicast layer 2 services (Virtual Private LAN Service and Virtual Private Multicast Service) as defined in the Layer 2 Virtual Private Network Working Group. "Inter-Chassis Communication Protocol for L2VPN PE Redundancy", Ali Sajassi, Luca Martini, Samer Salam, Satoru Matsushima, 7-Feb-12, This document specifies an inter-chassis communication protocol (ICCP) that enables Provider Edge (PE) device redundancy for Virtual Private Wire Service (VPWS) and Virtual Private LAN Service (VPLS) applications. The protocol runs within a set of two or more PEs, forming a redundancy group, for the purpose of synchronizing data amongst the systems. It accommodates multi-chassis attachment circuit as well as pseudowire redundancy mechanisms. "Pseudowire Status for Static Pseudowires", Luca Martini, George Swallow, Giles Heron, Matthew Bocci, 15-Nov-11, This document specifies a mechanism to signal Pseudowire (PW) status messages using an PW associated channel (ACh). Such a mechanism is suitable for use where no PW dynamic control plane exits, known as static PWs, or where a Terminating Provider Edge (T-PE) needs to send a PW status message directly to a far end T-PE. The mechanism allows PW OAM message mapping and PW redundancy to operate on static PWs. This document also updates rfc5885 in the case when Bi-directional Forwarding Detection (BFD) is used to convey PW status signaling information. "Signaling Root-Initiated Point-to-Multipoint Pseudowire using LDP", Gianni Vecchio, Lizhong Jin, Luca Martini, Maciek Konstantynowicz, Sami Boutros, Siva Sivabalan, Yuji Kamite, 28-Oct-11, This document specifies a mechanism to signal Point-to-Multipoint (P2MP) Pseudowires (PW) tree using LDP. Such a mechanism is suitable for any Layer 2 VPN service requiring P2MP connectivity over an IP or MPLS enabled PSN. A P2MP PW established via the proposed mechanism is root initiated. "Packet Pseudowire Encapsulation over an MPLS PSN", Andrew Malis, Luca Martini, George Swallow, Stewart Bryant, 28-Jan-12, This document describes a pseudowire mechanism that is used to transport a packet service over an MPLS PSN is the case where the client Label Switching Router (LSR) and the server Provider Edge equipments are co-resident in the same equipment. This pseudowire mechanism may be used to carry all of the required layer 2 and layer 3 protocols between the pair of client LSRs. "Pseudowire Control Word Negotiation Mechanism Update", Raymond Key, Thomas Nadeau, Vishwas Manral, Sami Boutros, Reshad Rahman, 19-Oct-11, This document describes the problem of control word negotiation mechanism specified in [RFC4447]. Based on the problem analysis, a message exchanging mechanism is introduced to solve this control word negotiation issue. This document is to update [RFC4447] control word negotiation mechanism. "LDP Typed Wildcard FEC for PWid and Generalized PWid FEC Elements", Kamran Raza, Sami Boutros, Carlos Pignataro, 6-Feb-12, The "Typed Wildcard Forwarding Equivalence Class (FEC) Element" defines an extension to the Label Distribution Protocol (LDP) that can be used when it is desired to request or withdraw or release all label bindings for a given FEC Element type. However, a typed wildcard FEC element must be individually defined for each FEC element type. This specification defines the typed wildcard FEC elements for the PWid (0x80) and Generalized PWid (0x81) FEC element types. "MPLS LSP PW status refresh reduction for Static Pseudowires", Luca Martini, George Swallow, Elisa Bellagamba, 14-Sep-11, This document describes a method for generating an aggregated pseudowire status message on Multi-Protocol Label Switching (MPLS) network Label Switched Path (LSP). The method for transmitting the pseudowire (PW) status information is not new, however this protocol extension allows a Service Provider (SP) to reliably monitor the individual PW status while not overwhelming the network of multiple periodic status messages. This is achieved by sending a single cumulative summary status verification message for all the PWs grouped in the same LSP. "The Pseudowire (PW) & Virtual Circuit Connectivity Verification (VCCV) Implementation Survey Results", Nick Regno, 20-Sep-11, Most Pseudowire Emulation Edge-to-Edge (PWE3) encapsulations mandate the use of the Control Word (CW) in order to better emulate the services for which the encapsulations have been defined. However, some encapulations treat the Control Word as optional. As a result, implementations of the CW, for encapsulations for which it is optional, vary by equipment manufacturer, equipment model and service provider network. Similarly, Virtual Circuit Connectivity Verification (VCCV) supports three Control Channel (CC) types and multiple Connectivity Verification (CV) Types. This flexibility has led to reports of interoperability issues within deployed networks and associated drafts to attempt to remedy the situation. This survey of the PW/VCCV user community was conducted to determine implementation trends. The survey and results is presented herein. "Explicit Path Routing for Dynamic Multi-Segment Pseudowires", Pranjal Dutta, Matthew Bocci, Luca Martini, 22-Sep-11, Dynamic Multi-Segment Pseudowire (MS-PW) setup through an explicit path may be required to provide a simple solution for 1:1 protection with diverse primary and backup MS-PWs for a service, or to enable controlled signaling (strict or loose) for special MS-PWs. This document describes the extensions and procedures necessary for setting up of dynamic MS-PWs through explicit path routing. "A Unified Control Channel for Pseudowires", Luca Martini, Thomas Nadeau, 27-Jan-12, This document describes a unified mode of operation for Virtual Circuit Connectivity Verification (VCCV), which provides a control channel that is associated with a pseudowire (PW). VCCV applies to all supported access circuit and transport types currently defined for PWs, as well as those being transported by The MPLS Transport Profile. This new mode is intended to augment those described in RFC5085, but this document describes new rules requiring this mode to be used as the default/mandatory mode of operation for VCCV. The older types will remain optional. "Label Distribution Protocol Extensions for Proactive Operations, Administration and Maintenance Configuration of Dynamic MPLS Transport Profile PseudoWire", Fei Zhang, Wu Bo, Elisa Bellagamba, 28-Jan-12, This document specifies extensions to the Label Distribution Protocol (LDP) to configure and control proactive Operations, Adminstration and Maintenance (OAM) functions, suitable for dynamic Single-Segment PseudoWire (SS-PW) and Multi-Segment PseudoWire (MS-PW). RADIUS EXTensions (radext) -------------------------- "Transport Layer Security (TLS) encryption for RADIUS", Klaas Wierenga, Mike McCauley, Stefan Winter, Stig Venaas, 13-Feb-12, This document specifies a transport profile for RADIUS using Transport Layer Security (TLS) over TCP as the transport protocol. This enables dynamic trust relationships between RADIUS servers. "RADIUS Over TCP", Alan DeKok, 12-Oct-10, The Remote Authentication Dial In User Server (RADIUS) Protocol has until now required the User Datagram Protocol (UDP) as the underlying transport layer. This document defines RADIUS over the Transmission Control Protocol (RADIUS/TCP), in order to address handling issues related to RADIUS over Transport Layer Security (RADIUS/TLS). It permits TCP to be used as a transport protocol for RADIUS only when a transport layer such as TLS or IPsec provides confidentialy and security. "RADIUS attributes for IPv6 Access Networks", Benoit Lourdelet, Wojciech Dec, Behcet Sarikaya, Glen Zorn, David Miles, 13-Nov-11, This document specifies additional IPv6 RADIUS attributes useful in residential broadband network deployments. The attributes, which are used for authorization and accounting, enable assignment of a host IPv6 address and IPv6 DNS server address via DHCPv6; assignment of an IPv6 route announced via router advertisement; assignment of a named IPv6 delegated prefix pool; and assignment of a named IPv6 pool for host DHCPv6 addressing. "Remote Authentication Dial In User Service (RADIUS) Protocol Extensions", Alan DeKok, Avi Lior, 2-Jan-12, The Remote Authentication Dial In User Service (RADIUS) protocol is nearing exhaustion of its current 8-bit Attribute Type space. In addition, experience shows a growing need for complex grouping, along with attributes which can carry more than 253 octets of data. This document defines changes to RADIUS which address all of the above problems. Reputation Services (repute) ---------------------------- "A Reputation Vocabulary for Email Identifiers", Nathaniel Borenstein, Murray Kucherawy, 13-Jan-12, This document defines a vocabulary for describing assertions a reputation service provider can make about email identifers, for use with the application/reputon media type. "A Media Type for Reputation Interchange", Nathaniel Borenstein, Murray Kucherawy, 13-Jan-12, This document defines a media type for exchanging reputation information about an arbitrary class of object. "Reputation Data Interchange using HTTP and XML", Nathaniel Borenstein, Murray Kucherawy, 13-Jan-12, This document defines a mechanism to conduct queries for reputation information using the Domain Name System. "A Model for Reputation Interchange", Nathaniel Borenstein, Murray Kucherawy, 29-Nov-11, This document describes the general model underlying a set of proposals for the exchange of reputation information on the Internet, and provides a roadmap to the four additional documents that collectively define a reputation interchange protocol. It is intended roughly to follow the recommendations of RFC4101 for describing a protocol model. Reliable Multicast Transport (rmt) ---------------------------------- "FLUTE - File Delivery over Unidirectional Transport", Toni Paila, Rod Walsh, Michael Luby, Vincent Roca, Rami Lehtonen, 13-Jan-12, This document defines FLUTE, a protocol for the unidirectional delivery of files over the Internet, which is particularly suited to multicast networks. The specification builds on Asynchronous Layered Coding, the base protocol designed for massively scalable multicast distribution. This document obsoletes RFC3926. "Simple Authentication Schemes for the ALC and NORM Protocols", Vincent Roca, 9-Dec-11, This document introduces four schemes that provide per-packet authentication, integrity and anti-replay services in the context of the ALC and NORM protocols. The first scheme is based on RSA digital signatures. The second scheme relies on the Elliptic Curve Digital Signature Algorithm (ECDSA). The third scheme relies on a group- keyed Message Authentication Code (MAC). Finally, the fourth scheme merges the digital signature and group schemes. These schemes have different target use cases and they do not all provide the same service. "FCAST: Scalable Object Delivery for the ALC and NORM Protocols", Vincent Roca, Brian Adamson, 19-Oct-11, This document introduces the FCAST object (e.g., file) delivery application on top of the ALC and NORM reliable multicast protocols. FCAST is a highly scalable application that provides a reliable object delivery service. "SDP Descriptors for FLUTE", Harsh Mehta, Igor Curcio, Jani Peltotalo, Rod Walsh, Sami Peltotalo, 5-Oct-11, This document specifies the use of SDP to describe the parameters required to begin, join, receive data from, and/or end FLUTE sessions. It also provides a Composite Session SDP media grouping semantic for grouping media streams into protocol-specific sessions, such as multiple-channel FLUTE sessions. Routing Over Low power and Lossy networks (roll) ------------------------------------------------ "Terminology in Low power And Lossy Networks", JP Vasseur, 14-Sep-11, The documents defines a terminology for discussing routing requirements and solutions for networks referred to as Low power and Lossy Networks (LLN). A LLN is typically composed of many embedded devices with limited power, memory, and processing resources interconnected by a variety of links. There is a wide scope of application areas for LLNs, including industrial monitoring, building automation (e.g. Heating, Ventilating, Air Conditioning, lighting, access control, fire), connected home, healthcare, environmental monitoring, urban sensor networks, energy management, assets tracking, refrigeration. "Routing Metrics used for Path Calculation in Low Power and Lossy Networks", Dominique Barthel, JP Vasseur, Kris Pister, Mijeom Kim, Nicolas Dejean, 1-Mar-11, Low power and Lossy Networks (LLNs) have unique characteristics compared with traditional wired and ad-hoc networks that require the specification of new routing metrics and constraints. By contrast with typical Interior Gateway Protocol (IGP) routing metrics using hop counts or link metrics, this document specifies a set of link and node routing metrics and constraints suitable to LLNs to be used by the Routing for Low Power and lossy networks (RPL) routing protocol. "RPL: IPv6 Routing Protocol for Low power and Lossy Networks", Anders Brandt, JP Vasseur, Jonathan Hui, Kris Pister, Pascal Thubert, P Levis, Rene Struik, Richard Kelsey, Thomas Clausen, Tim Winter, 14-Mar-11, Low power and Lossy Networks (LLNs) are a class of network in which both the routers and their interconnect are constrained. LLN routers typically operate with constraints on processing power, memory, and energy (battery power). Their interconnects are characterized by high loss rates, low data rates, and instability. LLNs are comprised of anything from a few dozen and up to thousands of routers. Supported traffic flows include point-to-point (between devices inside the LLN), point-to-multipoint (from a central control point to a subset of devices inside the LLN), and multipoint-to-point (from devices inside the LLN towards a central control point). This document specifies the IPv6 Routing Protocol for LLNs (RPL), which provides a mechanism whereby multipoint-to-point traffic from devices inside the LLN towards a central control point, as well as point-to- multipoint traffic from the central control point to the devices inside the LLN, is supported. Support for point-to-point traffic is also available. "RPL Objective Function Zero", Pascal Thubert, 7-Sep-11, The Routing Protocol for Low Power and Lossy Networks (RPL) specification defines a generic Distance Vector protocol that is adapted to a variety of networks types by the application of specific Objective Functions (OFs). An OF states the outcome of the process used by a RPL node to select and optimize routes within a RPL Instance based on the information objects available; an OF is not an algorithm. This document specifies a basic Objective Function that relies only on the objects that are defined in RPL and does not use any protocol extension "A Security Framework for Routing over Low Power and Lossy Networks", Tzeta Tsao, Roger Alexander, Mischa Dohler, Vanesa Daza, Angel Lozano, 12-Jan-12, This document presents a security framework for routing over low power and lossy networks (LLN). The development builds upon previous work on routing security and adapts the assessments to the issues and constraints specific to low power and lossy networks. A systematic approach is used in defining and evaluating the security threats and identifying applicable countermeasures. These assessments provide the basis of the security recommendations for incorporation into low power, lossy network routing protocols. As an illustration, this framework is applied to IPv6 Routing Protocol for Low Power and Lossy Networks (RPL). "Reactive Discovery of Point-to-Point Routes in Low Power and Lossy Networks", Mukul Goyal, Emmanuel Baccelli, Matthias Philipp, Anders Brandt, Jerry Martocci, 28-Jan-12, This document specifies a point-to-point route discovery mechanism, complementary to the RPL core functionality. This mechanism allows an IPv6 router to discover and establish, on demand, a route to another IPv6 router in the LLN such that the discovered route meets specified metrics constraints, without necessarily going along the DAG links established by core RPL. "The Minimum Rank Objective Function with Hysteresis", Omprakash Gnawali, P Levis, 17-May-11, The Routing Protocol for Low Power and Lossy Networks (RPL) uses objective functions to construct routes that optimize or constrain the routes it selects and uses. This specification describes the Minimum Rank Objective Function with Hysteresis (MRHOF), an objective function that selects routes that minimize a metric, while using hysteresis to reduce churn in response to small metric changes. MRHOF works with metrics that are additive along a route, and the metric it uses is determined by the metrics RPL Destination Information Object (DIO) messages advertise. "A Mechanism to Measure the Quality of a Point-to-point Route in a Low Power and Lossy Network", Mukul Goyal, Emmanuel Baccelli, Anders Brandt, Jerry Martocci, 29-Oct-11, This document specifies a mechanism that enables an RPL router to measure the quality of an existing route towards another RPL router in a low power and lossy network, thereby allowing the router to decide if it wants to initiate the discovery of a better route. "Applicability Statement for the Routing Protocol for Low Power and Lossy Networks (RPL) in AMI Networks", Daniel Popa, Jorjeta Jetcheva, Nicolas Dejean, Ruben Salazar, Jonathan Hui, Kazuya Monden, 31-Oct-11, This document discusses the applicability of RPL in Advanced Metering Infrastructure (AMI) networks. Real-Time Communication in WEB-browsers (rtcweb) ------------------------------------------------ "Web Real-Time Communication Use-cases and Requirements", Christer Holmberg, Goran Eriksson, Stefan Hakansson, 4-Oct-11, This document describes web based real-time communication use-cases. Based on the use-cases, the document also derives requirements related to the browser, and the API used by web applications to request and control media stream services provided by the browser. "Overview: Real Time Protocols for Brower-based Applications", Harald Alvestrand, 28-Sep-11, This document gives an overview and context of a protocol suite intended for use with real-time applications that can be deployed in browsers - "real time communication on the Web". It intends to serve as a starting and coordination point to make sure all the parts that are needed to achieve this goal are findable, and that the parts that belong in the Internet protocol suite are fully specified and on the right publication track. This work is an attempt to synthesize the input of many people, but makes no claims to fully represent the views of any of them. All parts of the document should be regarded as open for discussion, unless the RTCWEB chairs have declared consensus on an item. This document is a work item of the RTCWEB working group. "Web Real-Time Communication (WebRTC): Media Transport and Use of RTP", Colin Perkins, Joerg Ott, Magnus Westerlund, 31-Oct-11, The Web Real-Time Communication (WebRTC) framework aims to provide support for direct interactive rich communication using audio, video, collaboration, games, etc. between two peers' web-browsers. This memo describes the media transport aspects of the WebRTC framework. It specifies how the Real-time Transport Protocol (RTP) is used in the WebRTC context, and gives requirements for which RTP features, profiles, and extensions need to be supported. "Security Considerations for RTC-Web", Eric Rescorla, 30-Oct-11, The Real-Time Communications on the Web (RTC-Web) working group is tasked with standardizing protocols for real-time communications between Web browsers. The major use cases for RTC-Web technology are real-time audio and/or video calls, Web conferencing, and direct data transfer. Unlike most conventional real-time systems (e.g., SIP- based soft phones) RTC-Web communications are directly controlled by some Web server, which poses new security challenges. For instance, a Web browser might expose a JavaScript API which allows a server to place a video call. Unrestricted access to such an API would allow any site which a user visited to "bug" a user's computer, capturing any activity which passed in front of their camera. This document defines the RTC-Web threat model and defines an architecture which provides security within that threat model. "RTCWEB Security Architecture", Eric Rescorla, 23-Jan-12, The Real-Time Communications on the Web (RTCWEB) working group is tasked with standardizing protocols for real-time communications between Web browsers. The major use cases for RTCWEB technology are real-time audio and/or video calls, Web conferencing, and direct data transfer. Unlike most conventional real-time systems (e.g., SIP- based soft phones) RTCWEB communications are directly controlled by some Web server, which poses new security challenges. For instance, a Web browser might expose a JavaScript API which allows a server to place a video call. Unrestricted access to such an API would allow any site which a user visited to "bug" a user's computer, capturing any activity which passed in front of their camera. [I-D.ietf- rtcweb-security] defines the RTCWEB threat model. This document defines an architecture which provides security within that threat model. Routing Area Working Group (rtgwg) ---------------------------------- "IP Fast Reroute Using Not-via Addresses", Stewart Bryant, Stefano Previdi, Mike Shand, 21-Dec-11, This draft describes a mechanism that provides fast reroute in an IP network through encapsulation to "not-via" addresses. A single level of encapsulation is used. The mechanism protects unicast, multicast and LDP traffic against link, router and shared risk group failure, regardless of network topology and metrics. "Requirements for MPLS Over a Composite Link", Andrew Malis, Curtis Villamizar, Dave McDysan, Lucy Yong, Ning So, 30-Jan-12, There is often a need to provide large aggregates of bandwidth that are best provided using parallel links between routers or MPLS LSR. In core networks there is often no alternative since the aggregate capacities of core networks today far exceed the capacity of a single physical link or single packet processing element. The presence of parallel links, with each link potentially comprised of multiple layers has resulted in additional requirements. Certain services may benefit from being restricted to a subset of the component links or a specific component link, where component link characteristics, such as latency, differ. Certain services require that an LSP be treated as atomic and avoid reordering. Other services will continue to require only that reordering not occur within a microflow as is current practice. Current practice related to multipath is described briefly in an appendix. "LFA applicability in SP networks", Clarence Filsfils, Pierre Francois, 18-Jan-12, In this document, we analyze the applicability of the Loop-Free Alternates method of providing IP fast re-route in both the core and the access parts of Service Provider networks. We consider both the link and node failure cases, and provide guidance on the applicability of LFA to different network topologies, with special emphasis on the access parts of the network. "An Architecture for IP/LDP Fast-Reroute Using Maximally Redundant Trees", Alia Atlas, Robert Kebler, Maciek Konstantynowicz, Andras Csaszar, Russ White, Mike Shand, 26-Jan-12, As IP and LDP Fast-Reroute are increasingly deployed, the coverage limitations of Loop-Free Alternates are seen as a problem that requires a straightforward and consistent solution for IP and LDP, for unicast and multicast. This draft describes an architecture based on redundant backup trees where a single failure can cut a point-of-local-repair from the destination only on one of the pair of redundant trees. One innovative algorithm to compute such topologies is maximally disjoint backup trees. Each router can compute its next-hops for each pair of maximally disjoint trees rooted at each node in the IGP area with computational complexity similar to that required by Dijkstra. The additional state, address and computation requirements are believed to be significantly less than the Not-Via architecture requires. Sip ALerting for User Devices (salud) ------------------------------------- "Alert-Info URNs for the Session Initiation Protocol (SIP)", Laura Liess, Roland Jesske, Alan Johnston, Dale Worley, Paul Kyzivat, 17-Jan-12, The Session Initiation Protocol (SIP) supports the capability to provide a reference to a specific rendering to be used by the UA when the user is alerted. This is done using the Alert-Info header field. However, the reference addresses only network resources with specific rendering properties. There is currently no support for predefined standard identifiers for describing the semantics of the alerting situation or the characteristics of the alerting signal, without being tied to a particular rendering. To overcome this limitation and support new applications, a new family of URNs for use in SIP Alert-Info header fields is defined in this specification. This document normatively updates [RFC3261], the Session Initiation Protocol (SIP). It changes the usage of the SIP Alert-Info header field defined in the [RFC3261] by additionally allowing its use in all provisional responses to INVITE (except the 100 response). Source Address Validation Improvements (savi) --------------------------------------------- "FCFS SAVI: First-Come First-Serve Source-Address Validation for Locally Assigned IPv6 Addresses", Erik Nordmark, Marcelo Bagnulo, Eric Levy-Abegnoli, 18-Feb-12, This memo describes FCFS SAVI a mechanism to provide source address validation for IPv6 networks using the First-Come First-Serve principle. The proposed mechanism is intended to complement ingress filtering techniques to help detect and prevent source address spoofing. "SEND-based Source-Address Validation Implementation", Alberto Garcia-Martinez, Marcelo Bagnulo, 4-Oct-11, This memo describes SEND SAVI, a mechanism to provide source address validation using the SEND protocol. The proposed mechanism is intended to complement ingress filtering techniques to provide a finer granularity on the control of the source addresses used. "SAVI Threat Scope", Danny McPherson, Fred Baker, Joel Halpern, 11-Apr-11, Source Address Validation Improvement (SAVI) effort aims to complement ingress filtering with finer-grained, standardized IP source address validation. This document describes threats enabled by IP source address spoofing both in the global and finer-grained context, describes currently available solutions and challenges, and provides a starting point analysis for finer-grained (host granularity) anti-spoofing work. "SAVI Solution for DHCP", Jun Bi, Jianping Wu, Guang Yao, Fred Baker, 10-Feb-12, This document specifies the procedure for creating bindings between a DHCPv4 [RFC2131]/DHCPv6 [RFC3315] assigned source IP address and a binding anchor [I-D.ietf-savi-framework] on SAVI (Source Address Validation Improvements) device. The bindings can be used to filter packets generated on the local link with forged source IP address. "Source Address Validation Improvement Framework", Jianping Wu, Jun Bi, Marcelo Bagnulo, Fred Baker, Christian Vogt, 8-Jan-12, Source Address Validation Improvement methods were developed to prevent nodes attached to the same IP link from spoofing each other's IP addresses, so as to complement ingress filtering with finer- grained, standardized IP source address validation. This document is a framework document, which describes and motivates the design of the SAVI methods. Particular SAVI methods are described in other documents. "SAVI for Mixed Address Assignment Methods Scenario", Jun Bi, Guang Yao, Joel Halpern, Eric Levy-Abegnoli, 26-Oct-11, This document reviews how multiple address discovery methods can coexist in a single SAVI device and collisions are resolved when the same binding entry is discovered by two or more methods. Secure Inter-Domain Routing (sidr) ---------------------------------- "Use Cases and Interpretation of RPKI Objects for Issuers and Relying Parties", Terry Manderson, Kotikalapudi Sriram, Russ White, 26-Jan-12, This document provides use cases, directions, and interpretations for organizations and relying parties when creating or encountering RPKI object scenarios in the public RPKI. All of the above are discussed here in relation to the Internet routing system. "BGP Prefix Origin Validation", David Ward, John Scudder, Pradosh Mohapatra, Randy Bush, Rob Austein, 31-Oct-11, To help reduce well-known threats against BGP including prefix mis- announcing and monkey-in-the-middle attacks, one of the security requirements is the ability to validate the origination AS of BGP routes. More specifically, one needs to validate that the AS number claiming to originate an address prefix (as derived from the AS_PATH attribute of the BGP route) is in fact authorized by the prefix holder to do so. This document describes a simple validation mechanism to partially satisfy this requirement. "The RPKI/Router Protocol", Randy Bush, Rob Austein, 2-Feb-12, In order to verifiably validate the origin ASs of BGP announcements, routers need a simple but reliable mechanism to receive RPKI [I-D.ietf-sidr-arch] prefix origin data from a trusted cache. This document describes a protocol to deliver validated prefix origin data to routers. "Local Trust Anchor Management for the Resource Public Key Infrastructure", Mark Reynolds, Stephen Kent, 4-Dec-11, This document describes a facility to enable a relying party (RP) to manage trust anchors (TAs) in the context of the Resource Public Key Infrastructure (RPKI). It is common to allow an RP to import TA material in the form of self-signed certificates. The facility described in this document allows an RP to impose constraints on such TAs. Because this mechanism is designed to operate in the RPKI context, the relevant constraints are the RFC 3779 extensions that bind address spaces and/or autonomous system (AS) numbers to entities. The primary motivation for this facility is to enable an RP to ensure that resource allocation information that it has acquired via some trusted channel is not overridden by the information acquired from the RPKI repository system or by the putative TAs that the RP imports. Specifically, the mechanism allows an RP to specify a set of bindings between public key identifiers and RFC 3779 extension data and will override any conflicting bindings expressed via the putative TAs and the certificates downloaded from the RPKI repository system. Although this mechanism is designed for local use by an RP, an entity that is accorded administrative control over a set of RPs may use this mechanism to convey its view of the RPKI to a set of RPs within its jurisdiction. The means by which this latter use case is effected is outside the scope of this document. "RPKI-Based Origin Validation Operation", Randy Bush, 13-Nov-11, Deployment of RPKI-based BGP origin validation has many operational considerations. This document attempts to collect and present them. It is expected to evolve as RPKI-based origin validation is deployed and the dynamics are better understood. "Algorithm Agility Procedure for RPKI.", Roque Gagliano, Stephen Kent, Sean Turner, 18-Jan-12, This document specifies the process that Certification Authorities (CAs) and Relying Parties (RP) participating in the Resource Public Key Infrastructure (RPKI) will need to follow to transition to a new (and probably cryptographically stronger) algorithm set. The process is expected to be completed in a time scale of months or years. Consequently, no emergency transition is specified. The transition procedure defined in this document supports only a top-down migration (parent migrates before children). "BGPSEC Protocol Specification", Matt Lepinski, 31-Oct-11, This document describes BGPSEC, an extension to the Border Gateway Protocol (BGP) that provides security for the AS-PATH attribute in BGP update messages. BGPSEC is implemented via a new optional non- transitive BGP path attribute that carries a digital signature produced by each autonomous system on the AS-PATH. "An Overview of BGPSEC", Matt Lepinski, Sean Turner, 31-Oct-11, This document provides an overview of a security extension to the Border Gateway Protocol (BGP) referred to as BGPSEC. BGPSEC improves security for BGP routing. "Threat Model for BGP Path Security", Stephen Kent, Andrew Chi, 22-Feb-12, This document describes a threat model for BGP path security (BGPSEC). It assumes the context established by the SIDR WG charter, as of April 19, 2011. The charter established two goals for the SIDR work: o Enabling an AS to verify the authorization of an origin AS to originate a specified set of prefixes o Enabling an AS to verify that the AS-PATH represented in a route matches the path travelled by the NLRI for the route The charter further mandates that SIDR build upon the Resource Public Key Infrastructure (RPKI), the first product of the WG. Consistent with the charter, this threat model includes an analysis of the RPKI, and focuses on the ability of an AS to verify the authenticity of the AS path info received in a BGP update. The model assumes that BGP path security is achieved through the application of digital signatures to AS_Path Info. The document characterizes classes of potential adversaries that are considered to be threats, and examines classes of attacks that might be launched against BGPSEC. It concludes with brief discussion of residual vulnerabilities. "Security Requirements for BGP Path Validation", Steven Bellovin, Randy Bush, David Ward, 19-Oct-11, This document describes requirements for a future BGP security protocol design to provide cryptographic assurance that the origin AS had the right to announce the prefix and to provide assurance of the AS Path of the announcement. "BGPsec Operational Considerations", Randy Bush, 19-Oct-11, Deployment of the BGPsec architecture and protocols has many operational considerations. This document attempts to collect and present them. It is expected to evolve as BGPsec is formalized and initially deployed. "BGP Algorithms, Key Formats, & Signature Formats", Sean Turner, 5-Dec-11, This document specifies the algorithms, algorithms' parameters, asymmetric key formats, asymmetric key size and signature format used in BGPSEC (Border Gateway Protocol Security). This document updates the Profile for Algorithms and Key Sizes for use in the Resource Public Key Infrastructure (draft-ietf-sidr-rpki-algs). "A Profile for BGPSEC Router Certificates, Certificate Revocation Lists, and Certification Requests", Mark Reynolds, Sean Turner, 5-Dec-11, This document defines a standard profile for X.509 certificates for the purposes of supporting validation of Autonomous System (AS) paths in the Border Gateway Protocol (BGP), as part of an extension to that protocol known as BGPSEC. BGP is a critical component for the proper operation of the Internet as a whole. The BGPSEC protocol is under development as a component to address the requirement to provide security for the BGP protocol. The goal of BGPSEC is to design a protocol for full AS path validation based on the use of strong cryptographic primitives. The end-entity (EE) certificates specified by this profile are issued under Resource Public Key Infrastructure (RPKI) Certification Authority (CA) certificates, containing the AS Identifier Delegation extension, to routers within the Autonomous System (AS). The certificate asserts that the router(s) holding the private key are authorized to send out secure route advertisements on behalf of the specified AS. This document also profiles the Certificate Revocation List (CRL), profiles the format of certification requests, and specifies Relying Party certificate path validation procedures. The document extends the RPKI; therefore, this documents updates the RPKI Resource Certificates Profile (draft- ietf-sidr-res-cert-profile). Sieve Mail Filtering Language (sieve) ------------------------------------- "Sieve Notification Mechanism: SIP MESSAGE", Kepeng Li, Qian Sun, Alexey Melnikov, Barry Leiba, 11-Oct-11, This document describes a profile of the Sieve extension for notifications, to allow notifications to be sent over SIP MESSAGE. "Sieve Email Filtering: Include Extension", Cyrus Daboo, Aaron Stone, 31-Jan-12, The Sieve Email Filtering "include" extension permits users to include one Sieve script inside another. This can make managing large scripts or multiple sets of scripts much easier, and allows a site and its users to build up libraries of scripts. Users are able to include their own personal scripts or site-wide scripts. "Sieve Extension for Converting Messages Before Delivery", Kepeng Li, Qian Sun, Alexey Melnikov, Barry Leiba, 1-Dec-11, This document describes how the "CONVERT" IMAP extension can be used within the Sieve mail filtering language to transform messages before final delivery. SIP for Instant Messaging and Presence Leveraging Extensions (simple) --------------------------------------------------------------------- "Multi-party Chat Using the Message Session Relay Protocol (MSRP)", Miguel Garcia, Geir Sandbakken, Aki Niemi, 23-Jan-12, The Message Session Relay Protocol (MSRP) defines a mechanism for sending instant messages within a peer-to-peer session, negotiated using the Session Initiation Protocol (SIP) and the Session Description Protocol (SDP). This document defines the necessary tools for establishing multi-party chat sessions, or chat rooms, using MSRP. "Connection Establishment for Media Anchoring (CEMA) for the Message Session Relay Protocol (MSRP)", Christer Holmberg, Staffan Blau, Eric Burger, 5-Oct-11, This document defines a Message Session Relay Protocol (MSRP) extension, Connection Establishment for Media Anchoring (CEMA). Support of the extension is optional. The extension allows middleboxes to anchor the MSRP connection, without the need for middleboxes to modify the MSRP messages, and thus also enables a secure end-to-end MSRP communication in networks where such middleboxes are deployed. The document also defines a Session Description Protocol (SDP) attribute, 'msrp-cema', that MSRP endpoints use to indicate support of the CEMA extension. Session Initiation Protocol (sip) --------------------------------- "A Framework for Session Initiation Protocol (SIP) Session Policies", Gonzalo Camarillo, Jonathan Rosenberg, Volker Hilt, 18-Feb-11, Proxy servers play a central role as an intermediary in the Session Initiation Protocol (SIP) as they define and impact policies on call routing, rendezvous, and other call features. This document specifies a framework for SIP session policies that provides a standard mechanism by which a proxy can define or influence policies on sessions, such as the codecs or media types to be used. It defines a model, an overall architecture and new protocol mechanisms for session policies. SIP Common Log Format (sipclf) ------------------------------ "The Common Log Format (CLF) for the Session Initiation Protocol (SIP): Framework and Data Model", Vijay Gurbani, Eric Burger, Tricha Anjali, Humberto Abdelnur, Olivier Festor, 6-Feb-12, Well-known web servers such as Apache and web proxies like Squid support event logging using a common log format. The logs produced using these de-facto standard formats are invaluable to system administrators for trouble-shooting a server and tool writers to craft tools that mine the log files and produce reports and trends. Furthermore, these log files can also be used to train anomaly detection systems and feed events into a security event management system. The Session Initiation Protocol (SIP) does not have a common log format, and as a result, each server supports a distinct log format that makes it unnecessarily complex to produce tools to do trend analysis and security detection. We propose a common log file format for SIP servers that can be used uniformly by user agents, proxies, registrars, redirect servers as well as back-to-back user agents. "Format for the Session Initiation Protocol (SIP) Common Log Format (CLF)", Gonzalo Salgueiro, Vijay Gurbani, Adam Roach, 17-Dec-11, The SIPCLF Workgroup has defined a common log format framework for Session Initiation Protocol (SIP) servers. This common log format mimics the successful event logging format found in well-known web servers like Apache and web proxies like Squid. This document proposes an indexed text encoding format for the SIP Common Log Format (CLF) that retains the key advantages of a text-based format, while significantly increasing processing performance over a purely text-based implementation. This file format adheres to the SIP CLF data model and provides an effective encoding scheme for all mandatory and optional fields that appear in a SIP CLF record. Session Initiation Protocol Core (sipcore) ------------------------------------------ "SIP-Specific Event Notification", Adam Roach, 23-Feb-12, This document describes an extension to the Session Initiation Protocol (SIP). The purpose of this extension is to provide an extensible framework by which SIP nodes can request notification from remote nodes indicating that certain events have occurred. Note that the event notification mechanisms defined herein are NOT intended to be a general-purpose infrastructure for all classes of event subscription and notification. This document represents a backwards-compatible improvement on the original mechanism described by RFC 3265, taking into account several years of implementation experience. Accordingly, this document obsoletes RFC 3265. This document also updates RFC 4660 slightly to accomodate some small changes to the mechanism that were discussed in that document. "An Extension to the Session Initiation Protocol (SIP) for Request History Information", Christer Holmberg, Francois Audet, Mary Barnes, Hans Elburg, Shida Schubert, 30-Oct-11, This document defines a standard mechanism for capturing the history information associated with a Session Initiation Protocol (SIP) request. This capability enables many enhanced services by providing the information as to how and why a SIP request arrives at a specific application or user. This document defines an optional SIP header field, History-Info, for capturing the history information in requests. The document also defines SIP header field parameters for the History-Info and Contact header fields to tag the method by which the target of a request is determined. In addition, this specification defines a value for the Privacy header field specific to the History-Info header field. This document obsoletes RFC 4244. "Requirements for indication of features supported by a SIP proxy", Christer Holmberg, Ivo Sedlacek, 5-Dec-11, The Session Initiation Protocol (SIP) "Caller Preferences" extension defined in RFC 3840 provides a mechanism that allows a SIP message to convey information relating to the originator's supported features/ capabilities. This document defines requirements for a mechanism that would allow SIP proxies to convey information relating to the proxy's supported features/capabilities. Session Initiation Proposal Investigation (sipping) --------------------------------------------------- "A User Agent Profile Data Set for Media Policy", Volker Hilt, Dale Worley, Gonzalo Camarillo, Jonathan Rosenberg, 20-Feb-12, This specification defines an XML document format to describe the media properties of Session Initiation Protocol (SIP) sessions. Examples for media properties are the codecs or media types used in the session. This document also defines an XML document format to describe policies that limit the media properties of SIP sessions. "A Session Initiation Protocol (SIP) Event Package for Session-Specific Session Policies.", Gonzalo Camarillo, Volker Hilt, 23-Mar-10, This specification defines a Session Initiation Protocol (SIP) event package for session-specific policies. This event package enables user agents to subscribe to session policies for a SIP session and to receive notifications if these policies change. SIP Recording (siprec) ---------------------- "An Architecture for Media Recording using the Session Initiation Protocol", Leon Portman, Ken Rehor, Rajnish Jain, Andrew Hutton, 3-Oct-11, Session recording is a critical requirement in many communications environments such as call centers and financial trading. In some of these environments, all calls must be recorded for regulatory, compliance, and consumer protection reasons. Recording of a session is typically performed by sending a copy of a media stream to a recording device. This document describes architectures for deploying session recording solutions in an environment which is based on the Session Initiation Protocol (SIP). "Session Initiation Protocol (SIP) Recording Metadata", Parthasarathi Ravindran, Paul Kyzivat, 31-Oct-11, Session recording is a critical requirement in many communications environments such as call centers and financial trading. In some of these environments, all calls must be recorded for regulatory, compliance, and consumer protection reasons. Recording of a session is typically performed by sending a copy of a media stream to a recording device. This document describes the metadata model as viewed by Session Recording Server(SRS) and the Recording metadata format. "Session Recording Protocol", Leon Portman, Alan Johnston, Henry Lum, Andrew Hutton, 31-Oct-11, This document specifies the use of the Session Initiation Protocol (SIP), the Session Description Protocol (SDP), and the Real Time Protocol (RTP) for delivering real-time media and metadata from a Communication Session (CS) to a recording device. The Session Recording Protocol specifies the use of SIP, SDP, and RTP to establish a Recording Session (RS) from the Session Recording Client (SRC), which is on the path of the CS, to a Session Recording Server (SRS) at the recording device. SIP Overload Control (soc) -------------------------- "Session Initiation Protocol (SIP) Overload Control", Vijay Gurbani, Volker Hilt, Henning Schulzrinne, 18-Jan-12, Overload occurs in Session Initiation Protocol (SIP) networks when SIP servers have insufficient resources to handle all SIP messages they receive. Even though the SIP protocol provides a limited overload control mechanism through its 503 (Service Unavailable) response code, SIP servers are still vulnerable to overload. This document defines the behaviour of SIP servers involved in overload control, and in addition, it specifies a loss-based overload scheme for SIP. "A Session Initiation Protocol (SIP) Load Control Event Package", Charles Shen, Henning Schulzrinne, Arata Koike, 10-Jan-12, We define a load control event package for the Session Initiation Protocol (SIP). It allows SIP servers to distribute load filters to other SIP servers in the network. The load filters contain rules to throttle calls based on their source or destination domain, telephone number prefix or for a specific user. The mechanism helps to prevent signaling overload and complements feedback-based SIP overload control efforts. "Session Initiation Protocol (SIP) Rate Control", Eric Noel, Philip Williams, 16-Feb-12, The prevalent use of Session Initiation Protocol (SIP) [RFC3261] in Next Generation Networks necessitates that SIP networks provide adequate control mechanisms to maintain transaction throughput by preventing congestion collapse during traffic overloads. Already [draft-ietf-soc-overload-control-07] proposes a loss-based solution to remedy known vulnerabilities of the [RFC3261] SIP 503 (service unavailable) overload control mechanism. This document proposes a rate-based control solution to complement the loss-based control defined in [draft-ietf-soc-overload-control-07]. Softwires (softwire) -------------------- "Gateway Initiated Dual-Stack Lite Deployment", David Ward, Frank Brockners, Sebastian Speicher, Sri Gundavelli, 16-Dec-11, Gateway-Initiated Dual-Stack lite (GI-DS-lite) is a variant of Dual- Stack lite (DS-lite) applicable to certain tunnel-based access architectures. GI-DS-lite extends existing access tunnels beyond the access gateway to an IPv4-IPv4 NAT using softwires with an embedded context identifier that uniquely identifies the end-system the tunneled packets belong to. The access gateway determines which portion of the traffic requires NAT using local policies and sends/ receives this portion to/from this softwire. "RADIUS Attribute for 6rd", Dayong Guo, Sheng Jiang, Remi Despres, Roberta Maglione, 25-Oct-11, IPv6 Rapid Deployment (6rd) is one of the most popular methods to provide both IPv4 and IPv6 connectivity services simultaneously during the IPv4/IPv6 co-existing period. The Dynamic Host Configuration Protocol (DHCP) 6rd option has been defined to configure 6rd Customer Edge (CE). However, in many networks, the configuration information may be stored in Authentication Authorization and Accounting (AAA) servers while user configuration is mainly from Broadband Network Gateway (BNG) through DHC protocol. This document defines a Remote Authentication Dial In User Service (RADIUS) attribute that carries 6rd configuration information from AAA server to BNG. "Public IPv4 over Access IPv6 Network", Yong Cui, Jianping Wu, Peng Wu, Chris Metz, Olivier Vautrin, Yiu Lee, 8-Sep-11, This draft proposes a mechanism for bidirectional IPv4 communication between IPv4 Internet and end hosts or IPv4 networks sited in IPv6 access network. This mechanism follows the softwire hub and spoke model and uses IPv4-over-IPv6 tunnel as basic method to traverse IPv6 network. By allocating public IPv4 addresses to end hosts/networks in IPv6, it can achieve IPv4 end-to-end bidirectional communication between these hosts/networks and IPv4 Internet. This mechanism is an IPv4 access method for hosts and IPv4 networks sited in IPv6. "Motivations for Stateless IPv4 over IPv6 Migration Solutions", Gang Chen, Isabel Borges, Mohamed Boucadair, Olaf Bonness, Satoru Matsushima, Yiu Lee, 10-Feb-12, IPv4 service continuity is one of the most pressing problems that must be resolved by Service Providers during the IPv6 transition period - especially after the exhaustion of the public IPv4 address space. Current standardization effort that addresses IPv4 service continuity focuses on stateful mechanisms. This document elaborates on the motivations for the need to undertake a companion effort to specify stateless IPv4 over IPv6 approaches. "Multicast Extensions to DS-Lite Technique in Broadband Deployments", Christian Jacquenet, Jacni Qin, Mohamed Boucadair, Qian Wang, Yiu Lee, 31-Oct-11, This document specifies a solution for the delivery of multicast service offerings to DS-Lite serviced customers. The proposed solution relies upon a stateless IPv4-in-IPv6 encapsulation scheme and uses the IPv6 multicast distribution tree to deliver IPv4 multicast traffic over an IPv6 multicast-enabled network. "Softwire Mesh Multicast", Mingwei Xu, Yong Cui, Shu Yang, Jianping Wu, Chris Metz, Greg Shepherd, 28-Oct-11, The Internet needs to support IPv4 and IPv6 packets. Both address families and their attendant protocol suites support multicast of the single-source and any-source varieties. As part of the transition to IPv6, there will be scenarios where a backbone network running one IP address family internally (referred to as internal IP or I-IP) will provide transit services to attached client networks running another IP address family (referred to as external IP or E-IP). It is expected that the I-IP backbone will offer unicast and multicast transit services to the client E-IP networks. Softwires Mesh is a solution to E-IP unicast and multicast support across an I-IP backbone. This document describes the mechanisms for supporting Internet-style multicast across a set of E-IP and I-IP networks supporting softwires mesh. "Deployment Considerations for Dual-Stack Lite", Yiu Lee, Roberta Maglione, Carl Williams, Christian Jacquenet, 31-Oct-11, This document discusses the deployment issues and describes requirements for the deployment and operation of Dual-Stack Lite. This document describes the various deployment considerations and applicability of the Dual-Stack Lite architecture. Speech Services Control (speechsc) ---------------------------------- "Media Resource Control Protocol Version 2 (MRCPv2)", Daniel Burnett, Saravanan Shanmugham, 15-Nov-11, The MRCPv2 protocol allows client hosts to control media service resources such as speech synthesizers, recognizers, verifiers and identifiers residing in servers on the network. MRCPv2 is not a "stand-alone" protocol - it relies on other protocols, such as Session Initiation Protocol (SIP) to rendezvous MRCPv2 clients and servers and manage sessions between them, and the Session Description Protocol (SDP) to describe, discover and exchange capabilities. It also depends on SIP and SDP to establish the media sessions and associated parameters between the media source or sink and the media server. Once this is done, the MRCPv2 protocol exchange operates over the control session established above, allowing the client to control the media processing resources on the speech resource server. STORage Maintenance (storm) --------------------------- "iSCSI Extensions for RDMA Specification", Alexander Nezhinsky, 15-Jan-12, iSCSI Extensions for RDMA provides the RDMA data transfer capability to iSCSI by layering iSCSI on top of an RDMA-Capable Protocol. An RDMA-Capable Protocol provides RDMA Read and Write services, which enable data to be transferred directly into SCSI I/O Buffers without intermediate data copies. This document describes the extensions to the iSCSI protocol to support RDMA services as provided by an RDMA- Capable Protocol. This document obsoletes RFC 5046. "Internet Small Computer Systems Interface (iSCSI) SCSI Features Update", Frederick Knight, Mallikarjun Chadalapaka, 13-Dec-11, Internet Small Computer Systems Interface (iSCSI) is a SCSI transport protocol that maps the SCSI family of protocols onto TCP/IP. The iSCSI protocol as specified in [draft-ietf-storm- iscsi-cons-xx] (and as previously specified by the combination of RFC 3720 and RFC 5048) is based on the SAM-2 (SCSI Architecture Model - 2) version of the SCSI family of protocols. This document defines enhancements to the iSCSI protocol to support certain additional features of the SCSI protocol that were defined in SAM-3, SAM-4, and SAM-5. This document is a companion document to [draft-ietf-storm- iscsi-cons-xx]. -------------------------------------------------------- RFC EDITORS NOTE: The above references to [draft-ietf-storm- iscsi-cons-xx] should reference the RFC number assigned to that document, and this note should be removed. -------------------------------------------------------- "iSCSI Protocol (Consolidated)", Kalman Meth, Mallikarjun Chadalapaka, Julian Satran, 10-Jan-12, This document describes a transport protocol for SCSI that works on top of TCP. The iSCSI protocol aims to be fully compliant with the standardized SCSI Architecture Model (SAM-2). RFC 3720 defined the original iSCSI protocol. RFC 3721 discusses iSCSI Naming examples and discovery techniques. Subsequently, RFC 3980 added an additional naming format to iSCSI protocol. RFC 4850 followed up by adding a new public extension key to iSCSI. RFC 5048 offered a number of clarifications and a few improvements and corrections to the original iSCSI protocol. This document obsoletes RFCs 3720, 3980, 4850 and 5048 by consolidating them into a single document and making additional updates to the consolidated specification. This document also updates RFC 3721 and RFC 3723. The text in this document thus supersedes the text in all the noted RFCs wherever there is a difference in semantics. "Enhanced RDMA Connection Establishment", Caitlin Bestler, Robert Sharp, Steve Wise, 14-Dec-11, This document updates RFC 5043 and RFC 5044 by extending Marker Protocol Data Unit (PDU) Aligned Framing (MPA) negotiation for Remote Direct Memory Access (RDMA) connection establishment. The first enhancement extends RFC 5044, enabling peer-to-peer connection establishment over MPA/ Transmission Control Protocol (TCP). The second enhancement extends both RFC 5043 and RFC 5044, by providing an option for standardized exchange of RDMA-layer connection configuration. "RDMA Protocol Extensions", Hemal Shah, Felix Marti, Wael Noureddine, Asgeir Eiriksson, Robert Sharp, 9-Jan-12, This document specifies extensions to the IETF Remote Direct Memory Access Protocol (RDMAP [RFC5040]). RDMAP provides read and write services directly to applications and enables data to be transferred directly into Upper Layer Protocol (ULP) Buffers without intermediate data copies. The extensions specified in this document provide the following capabilities and/or improvements: Atomic Operations and Immediate Data. "Definitions of Managed Objects for Internet Small Computer System Interface (iSCSI)", Prakash Venkatesen, Mark Bakke, 25-Oct-11, This document defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular, it defines objects for managing a client using the Internet Small Computer System Interface (iSCSI) protocol (SCSI over TCP). This document obsoletes RFC4544. "IANA Registries for the RDDP (Remote Direct Data Placement) Protocols", David Black, 17-Jan-12, The original RFCs that specified the RDDP protocol suite did not create IANA registries for RDDP error codes, operation codes and function codes. Extensions to the RDDP protocols now require these registries to be created. This memo creates the RDDP registries, populates them with values defined in the original RDDP RFCs, and provides guidance to IANA for future assignment of code points within these registries. TCP Maintenance and Minor Extensions (tcpm) ------------------------------------------- "Increasing TCP's Initial Window", Jerry Chu, Nandita Dukkipati, Yuchung Cheng, Matt Mathis, 17-Oct-11, This document proposes an increase in the permitted TCP initial window (IW) from between 2 and 4 segments, as specified in RFC 3390, to 10 segments. It discusses the motivation behind the increase, the advantages and disadvantages of the higher initial window, and presents results from several large scale experiments showing that the higher initial window improves the overall performance of many web services without risking congestion collapse. The document closes with a discussion of a list of concerns, and some results from recent studies to address the concerns. Terminology "The NewReno Modification to TCP's Fast Recovery Algorithm", Andrei Gurtov, Tom Henderson, Sally Floyd, Yoshifumi Nishida, 20-Jan-12, RFC 5681 documents the following four intertwined TCP congestion control algorithms: slow start, congestion avoidance, fast retransmit, and fast recovery. RFC 5681 explicitly allows certain modifications of these algorithms, including modifications that use the TCP Selective Acknowledgement (SACK) option (RFC 2883), and modifications that respond to "partial acknowledgments" (ACKs which cover new data, but not all the data outstanding when loss was detected) in the absence of SACK. This document describes a specific algorithm for responding to partial acknowledgments, referred to as NewReno. This response to partial acknowledgments was first proposed by Janey Hoe. This document obsoletes RFC 3782. "Proportional Rate Reduction for TCP", Matt Mathis, Nandita Dukkipati, Yuchung Cheng, 24-Feb-12, This document describes an experimental algorithm, Proportional Rate Reduction (PPR) to improve the accuracy of the amount of data sent by TCP during loss recovery. Standard Congestion Control requires that TCP and other protocols reduce their congestion window in response to losses. This window reduction naturally occurs in the same round trip as the data retransmissions to repair the losses, and is implemented by choosing not to transmit any data in response to some ACKs arriving from the receiver. Two widely deployed algorithms are used to implement this window reduction: Fast Recovery and Rate Halving. Both algorithms are needlessly fragile under a number of conditions, particularly when there is a burst of losses that such that the number of ACKs returning to the sender is small. Proportional Rate Reduction minimizes these excess window reductions such that at the end of recovery the actual window size will be as close as possible to ssthresh, the window size determined by the congestion control algorithm. It is patterned after Rate Halving, but using the fraction that is appropriate for target window chosen by the congestion control algorithm. "A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP", Ethan Blanton, Ilpo Jarvinen, Lili Wang, Mark Allman, Markku Kojo, Yoshifumi Nishida, 26-Jan-12, This document presents a conservative loss recovery algorithm for TCP that is based on the use of the selective acknowledgment (SACK) TCP option. The algorithm presented in this document conforms to the spirit of the current congestion control specification (RFC 5681), but allows TCP senders to recover more effectively when multiple segments are lost from a single flight of data. "Shared Use of Experimental TCP Options", Joseph Touch, 17-Jan-12, This document describes how TCP option codepoints can support concurrent experiments. The suggested mechanism avoids the need for a coordinated registry, and is backward-compatible with currently known uses. "TCP Fast Open", Yuchung Cheng, Jerry Chu, Sivasankar Radhakrishnan, Arvind Jain, 17-Feb-12, TCP Fast Open (TFO) allows data to be carried in the SYN and SYN-ACK packets and consumed by the receiving end during the initial connection handshake, thus providing a saving of up to one full round trip time (RTT) compared to standard TCP requiring a three-way handshake (3WHS) to complete before data can be exchanged. Terminology Timing over IP Connection and Transfer of Clock (tictoc) -------------------------------------------------------- "Transporting PTP messages (1588) over MPLS Networks", Shahram Davari, Amit Oren, Manav Bhatia, Peter Roberts, Laurent Montini, 6-Oct-11, This document defines the method for transporting PTP messages (PDUs) over an MPLS network. The method allows for the easy identification of these PDUs at the port level to allow for port level processing of these PDUs in both LERs and LSRs. The basic idea is to transport PTP messages inside dedicated MPLS LSPs. These LSPs only carry PTP messages and possibly Control and Management packets, but they do not carry customer traffic. Two methods for transporting 1588 over MPLS are defined. The first method is to transport PTP messages directly over the dedicated MPLS LSP via UDP/IP encapsulation, which is suitable for IP/MPLS networks. The second method is to transport PTP messages inside a PW via Ethernet encapsulation, which is more suitable for MPLS-TP networks. "Precision Time Protocol Version 2 (PTPv2) Management Information Base", Greg Dowd, Laurent Montini, Tim Frost, Vinay Shankarkumar, 6-Feb-12, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing networks using Precision Time Protocol. This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions. "TICTOC Security Requirements", Tal Mizrahi, 29-Nov-11, As time synchronization protocols are becoming increasingly common and widely deployed, concern about their exposure to various security threats is increasing. This document defines a set of requirements for security solutions for time synchronization protocols, focusing on the IEEE 1588 and NTP. This document also discusses the security impacts of time synchronization protocol practices, the time synchronization performance implications of external security practices, the dependencies between other security services and time synchronization. Transport Layer Security (tls) ------------------------------ "Transport Layer Security (TLS) Cached Information Extension", Stefan Santesson, Hannes Tschofenig, 26-Dec-11, Transport Layer Security (TLS) handshakes often include fairly static information, such as the server certificate and a list of trusted Certification Authorities (CAs). This information can be of considerable size, particularly if the server certificate is bundled with a complete certificate path (including all intermediary certificates up to the trust anchor public key). This document defines an extension that omits the exchange of already available information. The TLS client informs a server of cached information, for example from a previous TLS handshake, allowing the server to omit the already available information. "TLS Out-of-Band Public Key Validation", Hannes Tschofenig, John Gilmore, Paul Wouters, Samuel Weiler, Tero Kivinen, 20-Jan-12, This document specifies a new TLS certificate type for exchanging raw public keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) for use with out-of-band authentication. Currently, TLS authentication can only occur via PKIX or OpenPGP certificates. By specifying a minimum resource for raw public key exchange, implementations can use alternative authentication methods. One such method is using DANE Resource Records secured by DNSSEC, Another use case is to provide authentication functionality when used with devices in a constrained environment that use whitelists and blacklists, as is the case with sensors and other embedded devices that are constrained by memory, computational, and communication limitations where the usage of PKIX is not feasible. The new certificate type specified can also be used to reduce the latency of a TLS client that is already in possession of a validated public key of the TLS server before it starts a (non-resumed) TLS handshake. Transparent Interconnection of Lots of Links (trill) ---------------------------------------------------- "RBridges: Campus VLAN and Priority Regions", Anil Rijhsinghani, Ayan Banerjee, Dinesh Dutt, Donald Eastlake, Radia Perlman, 28-Oct-11, Within an RBridge campus, the VLAN and priority of TRILL encapsulated frames is preserved. However, in some cases it may be desired that data VLAN and/or priority be mapped at the boundary between regions of such a campus. This document describes an optional RBridge feature to provide this function. "RBridges: Further TRILL Header Extensions", Donald Eastlake, Anoop Ghanwani, Vishwas Manral, Caitlin Bestler, 2-Dec-11, The TRILL base protocol standard specifies minimal hooks to safely support TRILL Header extensions. Initial extensions have been specified in RFC [ExtendHeader]. This document specifies the format for further such extensions and specifies some further specific extensions. "Definitions of Managed Objects for RBridges (Routing Bridges)", Anil Rijhsinghani, Kate Zebrose, 30-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 an RBridge (Routing Bridge), also known as a TRILL Switch, based on the IETF TRILL (Transparent Interconnection of Lots of Links) protocol. "TRILL: RBridge Channel Support", Donald Eastlake, Vishwas Manral, Li Yizhou, Sam Aldrin, 21-Feb-12, This document specifies a general channel mechanism for sending messages, such as BFD (Bidirectional Forwarding Detection) messages, between RBridges (Routing Bridges) and between RBridges and end stations in an RBridge campus through extensions to the TRILL (TRansparent Interconnection of Lots of Links) protocol. "Rbridges: Bidirectional Forwarding Detection (BFD) support for TRILL", Ayan Banerjee, David Ward, Donald Eastlake, Vishwas Manral, 24-Jan-12, This document specifies use of the BFD (Bidirectional Forwarding Detection) protocol in RBridge campuses based on the Rbridge Channel extension to the the TRILL (TRansparent Interconnection of Lots of Links) protocol. BFD is a widely deployed OAM (Operations, Administration, and Maintenance) mechanism in IP and MPLS networks, using UDP and ACH encapsulation respectively. This document specifies the BFD encapsulation over TRILL. "Routing Bridges (RBridges): Operations, Administration, and Maintenance (OAM) Support", David Bond, Vishwas Manral, 28-Oct-11, Routing Bridges (RBridges) implement the TRansparent Interconnection of Lots of Links (TRILL) protocol which provide a transparent least- cost frame routing in multi-hop networks with arbitrary topologies, while also inherently providing loop mitigation. As RBridges are deployed in real-world situations, operators will need tools for debugging problems that arise. This document specifies a set of RBridge features for operations, administration, and maintenance (OAM) purposes in RBridge campuses. The features specified in this document include tools for traceroute, ping, and error reporting. "TRILL: Header Extension", Donald Eastlake, Anoop Ghanwani, Vishwas Manral, Caitlin Bestler, 9-Jan-12, The IETF TRILL (Transparent Interconnection of Lots of Links) base protocol specifies minimal hooks to safely support TRILL Header extensions. This document specifies an initial extension providing additional flag bits and specifies two of those bits. "TRILL: Fine-Grained Labeling", Dinesh Dutt, Donald Eastlake, Mingui Zhang, Puneet Agarwal, Radia Perlman, 8-Dec-11, The IETF has standardized TRILL (TRansparent Interconnection of Lots of Links), a protocol for least cost transparent frame routing in multi-hop networks with arbitrary topologies and link technologies, using link-state routing and encapsulation with a hop count. The TRILL base protocol standard supports labeling of TRILL data with up to 4K IDs. However, there are applications that require more fine- grained labeling of data. This document updates RFC 6325 by specifying extensions to the TRILL base protocol to accomplish this. "TRILL: Clarifications, Corrections, and Updates", Donald Eastlake, Mingui Zhang, Anoop Ghanwani, Ayan Banerjee, Vishwas Manral, 27-Jan-12, The IETF TRILL (TRansparent Interconnection of Lots of Links) protocol provides least cost pair-wise data forwarding without configuration in multi-hop networks with arbitrary topology, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. TRILL accomplishes this by using IS-IS (Intermediate System to Intermediate System) link state routing and by encapsulating traffic using a header that includes a hop count. Since the TRILL base protocol was approved in March 2010, active development of TRILL has revealed a few errata in the original RFC 6325 and some cases that could use clarifications or updates. RFC 6327, RFC 6439, and RFC XXXX, provide clarifications with respect to Adjacency, Appointed Forwarders, and the TRILL ESADI protocol. This document provide other known clarifications, corrections, and updates to RFC 6325, RFC 6327, and RFC 6439. Transport Area Working Group (tsvwg) ------------------------------------ "Byte and Packet Congestion Notification", Bob Briscoe, Jukka Manner, 20-Feb-12, This memo concerns dropping or marking packets using active queue management (AQM) such as random early detection (RED) or pre- congestion notification (PCN). We give three strong recommendations: (1) packet size should be taken into account when transports read and respond to congestion indications, (2) packet size should not be taken into account when network equipment creates congestion signals (marking, dropping), and therefore (3) the byte-mode packet drop variant of the RED AQM algorithm that drops fewer small packets should not be used. "Stream Control Transmission Protocol (SCTP) Stream Reconfiguration", Randall Stewart, Michael Tuexen, Peter Lei, 8-Dec-11, Many applications that use SCTP want the ability to "reset" a stream. The intention of resetting a stream is to set the numbering sequence of the stream back to 'zero' with a corresponding notification to the application layer that the reset has been performed. Applications requiring this feature want it so that they can "re-use" streams for different purposes but still utilize the stream sequence number so that the application can track the message flows. Thus, without this feature, a new use of an old stream would result in message numbers greater than expected unless there is a protocol mechanism to "reset the streams back to zero". This document also includes methods for resetting the transport sequence numbers, adding additional streams and resetting all stream sequence numbers. "Deprecation of ICMP Source Quench messages", Fernando Gont, 24-Feb-12, This document formally deprecates the use of ICMP Source Quench messages by transport protocols, formally updating RFC 792, RFC 1122, and RFC 1812. "UDP Encapsulation of SCTP Packets", Michael Tuexen, Randall Stewart, 7-Dec-11, This document describes a simple method of encapsulating SCTP Packets into UDP packets and its limitations. This allows the usage of SCTP in networks with legacy NAT not supporting SCTP. It can also be used to implement SCTP on hosts without directly accessing the IP-layer, for example implementing it as part of the application without requiring special privileges. "Generic Aggregation of Resource ReSerVation Protocol (RSVP) for IPv4 And IPv6 Reservations over PCN domains", Georgios Karagiannis, Anurag Bhargava, 8-Oct-11, This document specifies the extensions to the Generic Aggregated RSVP [RFC4860] for support of the PCN Controlled Load (CL) and Single Marking (SM) edge behaviors over a Diffserv cloud using Pre- Congestion Notification. Uniform Resource Names, Revised (urnbis) ---------------------------------------- "Uniform Resource Name (URN) Syntax", Alfred Hoenes, 31-Oct-11, Uniform Resource Names (URNs) are intended to serve as persistent, location-independent, resource identifiers. This document serves as the foundation of the 'urn' URI Scheme according to RFC 3986 and sets forward the canonical syntax for URNs, which subdivides URNs into "namespaces". A discussion of both existing legacy and new namespaces and requirements for URN presentation and transmission are presented. Finally, there is a discussion of URN equivalence and how to determine it. This document supersedes RFC 2141. The requirements and procedures for URN Namespace registration documents are currently set forth in RFC 3406, which is also being updated by a companion, revised specification dubbed RFC 3406bis. "Uniform Resource Name (URN) Namespace Definition Mechanisms", Alfred Hoenes, 31-Oct-11, Uniform Resource Names (URNs) are intended to serve as persistent, location-independent, resource identifiers. To structure and organize their usage, the URN syntax specifies a hierarchy that divides the set of possible URNs into "URN Namespaces" that can be individually defined and managed. URN Namespaces in particular serve to map existing identifier systems into the URN system and thereby make available generic, network-based resolution services for the identified documents, artifacts, and other objects (and their metadata). To actually leverage such synergetic advantage, URN Namespaces need to be specified in a comparable manner, and their Namespace Identifiers (NIDs) need to be registered with IANA, so that naming conflicts are avoided and implementers of services can follow a structured approach in support of various namespaces, guided by the registry to the related documents and the particularities of specific namespaces, as described in these namespace registration documents. This document serves as a guideline for authors of URN Namespace definition and registration documents. It describes the essential content of such documents and how they shall be structured to allow readers familar with the scheme to quickly assess the properties of a specific URN Namespace. Further, this RFC describes the process to be followed to get a URN Namespace registered with IANA. This document is a companion document to the revised URN Syntax specification, RFC 2141bis; it supersedes and replaces RFC 3406. "Using International Standard Book Numbers as Uniform Resource Names", Maarit Huttunen, Alfred Hoenes, 16-Feb-12, The International Standard Book Number, ISBN, is a widely used identifier for monographic publications. Since 2001, the URN (Uniform Resource Name) namespace "ISBN" has been reserved for ISBNs. The namespace registration was performed in RFC 3187 and applied only to the ISBN as specified in the ISO Standard 2108-1992, now known as "ISBN-10". To allow for further growth in use, the successor ISO Standard, ISO 2108:2005, has defined an expanded format for the ISBN, known as "ISBN-13". This document defines how both of these ISBN standard versions can be supported within the URN framework. Moreover, additional syntax related information required by RFC 2141[bis] has been included. An updated namespace registration is provided. It describes how both the old and the new ISBN format can share the same namespace. This document replaces RFC 3187; it also obsoletes and moves to Historic status the predecessor thereof, RFC 2288. "Using National Bibliography Numbers as Uniform Resource Names", Juna Hakala, Alfred Hoenes, 16-Feb-12, National Bibliography Numbers, NBNs, are widely used by the national libraries and other organizations in order to identify various resources such as digitized monographs. Generally, NBNs may be applied to all kinds of resources that do not have an established (standard) identifier system of their own. A URN (Uniform Resource Names) namespace for NBNs was established in 2001 in RFC 3188. Since then, several European national libraries have implemented URN:NBN-based systems. This document replaces RFC 3188 and defines how NBNs can be supported within the updated URN framework. A revised namespace registration (version 4) is included. IPv6 Operations (v6ops) ----------------------- "Considerations for Transitioning Content to IPv6", Jason Livingood, 23-Feb-12, This document describes considerations for the transition of end user content on the Internet to IPv6. While this is tailored to address end user content, which is typically web-based, many aspects of this document may be more broadly applicable to the transition to IPv6 of other applications and services. This document explores the challenges involved in the transition to IPv6, potential migration tactics, possible migration phases, and other considerations. The audience for this document is the Internet community generally, particularly IPv6 implementers. "Happy Eyeballs: Success with Dual-Stack Hosts", Dan Wing, Andrew Yourtchenko, 20-Dec-11, When a server's IPv4 path and protocol is working but the server's IPv6 path and protocol are not working, a dual-stack client application experiences significant connection delay compared to an IPv4-only client. This is undesirable because it causes the dual- stack client to have a worse user experience. This document specifies requirements for algorithms that reduce this user-visible delay, and provides an algorithm. "IPv6 Multihoming without Network Address Translation", Satoru Matsushima, Tadahisa Okimoto, Ole Troan, David Miles, Dan Wing, 21-Feb-12, Network Address and Port Translation (NAPT) works well for conserving global addresses and addressing multihoming requirements, because an IPv4 NAPT router implements three functions: source address selection, next-hop resolution and optionally DNS resolution. For IPv6 hosts one approach could be the use of NPTv6. However, NAT should be avoided, if at all possible, to permit transparent end-to- end connectivity. In this document, we analyze the use cases of multihoming. We also describe functional requirements and possible solutions for multihoming without the use of NAT in IPv6 for hosts and small IPv6 networks that would otherwise be unable to meet minimum IPv6 allocation criteria. We conclude that DHCPv6 based solutions are suitable to solve the multihoming issues, described in this document, while NPTv6 may be required as an intermediate solution. "Basic Requirements for IPv6 Customer Edge Routers", Barbara Stark, Chris Donley, Hemant Singh, Ole Troan, Wes Beebee, 22-Dec-11, This document specifies requirements for an IPv6 Customer Edge (CE) router. Specifically, the current version of this document focuses on the basic provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attached to it. The document also covers IP transition technologies. Two transition technologies in RFC 5969's 6rd and RFC 6333's DS-Lite. are covered in the document. The document obsoletes RFC 6204, if approved. "A Discard Prefix for IPv6", Nick Hilliard, 9-Jan-12, Remote triggered black hole filtering describes a method of militating against denial-of-service attacks by selectively discarding traffic based on source or destination address. Remote triggered black hole routing describes a method of selectively re- routing traffic into a sinkhole router (for further analysis) based on destination address. This document updates RFC5156 by explaining why a unique IPv6 prefix should be formally assigned by IANA for the purpose of facilitating IPv6 remote triggered black hole filtering and routing. "Operational Neighbor Discovery Problems", Joel Jaeggli, Igor Gashinsky, Warren Kumari, 3-Feb-12, In IPv4, subnets are generally small, made just large enough to cover the actual number of machines on the subnet. In contrast, the default IPv6 subnet size is a /64, a number so large it covers trillions of addresses, the overwhelming number of which will be unassigned. Consequently, simplistic implementations of Neighbor Discovery (ND) can be vulnerable to deliberate or accidental denial of service, whereby they attempt to perform address resolution for large numbers of unassigned addresses. Such denial of attacks can be launched intentionally (by an attacker), or result from legitimate operational tools or accident conditions. As a result of these vulnerabilities, new devices may not be able to "join" a network, it may be impossible to establish new IPv6 flows, and existing IPv6 transported flows may be interrupted. This document describes the potential for DOS in detail and suggests possible implementation improvements as well as operational mitigation techniques that can in some cases be used to protect against or at least alleviate the impact of such attacks. "Stateless Source Address Mapping for ICMPv6 Packets", Xing Li, Congxiao Bao, Dan Wing, Ramji Vaithianathan, Geoff Huston, 24-Feb-12, A stateless IPv4/IPv6 translator may receive ICMPv6 packets containing non IPv4-translatable addresses as the source that should be passed across the translator as an ICMP packet directed to the the IPv4-translatable destination. This document discusses the considerations and presents a stateless address mapping algorithm for source address translation in ICMPv6 headers for such cases. "Wireline Incremental IPv6", Victor Kuarsingh, Lee Howard, 1-Feb-12, Operators worldwide are in various stages of preparing for, or deploying IPv6 into their networks. The operators often face difficult challenges related to both IPv6 introduction along with those related to IPv4 run out. Operators will need to meet the simultaneous needs of IPv6 connectivity and continue support for IPv4 connectivity for legacy devices with a depleting supply of IPv4 addresses. The IPv6 transition will take most networks from an IPv4- only environment to an IPv6 focused environment with long period of dual stack operation varying by operator. This document helps provide a framework for Wireline providers who are faced with the challenges of introducing IPv6 along meeting the legacy needs of IPv4 connectivity utilizing well defined and commercially available IPv6 transition technologies. "Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)", Fernando Gont, 12-Feb-12, The IPv6 Router Advertisement Guard (RA-Guard) mechanism is commonly employed to mitigate attack vectors based on forged ICMPv6 Router Advertisement messages. Many existing IPv6 deployments rely on RA- Guard as the first line of defense against the aforementioned attack vectors. However, some implementations of RA-Guard have been found to be prone to circumvention by employing IPv6 Extension Headers. This document describes the evasion techniques that affect the aforementioned implementations, and provides advice on the implementation of RA-Guard, such that the RA-Guard evasion vectors are eliminated. "464XLAT: Combination of Stateful and Stateless Translation", Masataka Mawatari, Masanobu Kawashima, Cameron Byrne, 14-Feb-12, This document describes an architecture (464XLAT) for providing IPv4 connectivity across an IPv6-only network by combining existing and well-known stateful protocol translation RFC 6146 in the core and stateless protocol translation RFC 6145 at the edge. 464XLAT is a simple and scalable technique to quickly deploy IPv4 access service to mobile and wireline IPv6-only edge networks without encapsulation. vCard and CardDAV (vcarddav) ---------------------------- "vCard Format extension : represent vCard extensions defined by the Open Mobile Alliance (OMA) Converged Address Book (CAB) group", Dany Cauchie, Barry Leiba, Kepeng Li, 20-Oct-11, This document defines extensions to the vCard data format for representing and exchanging certain contact information. The properties covered here have been defined by the Open Mobile Alliance Converged Address Book group, in order to synchronize, using OMA Data Synchronization, important contact fields that were not already defined in the base vCard 4.0 specification. "vCard Format Extension : To Represent the Social Network Information of an Individual", Robins George, Barry Leiba, Kepeng Li, Alexey Melnikov, 24-Oct-11, This document defines an extension to the vCard data format for representing and exchanging a variety of social network information. Virtual Router Redundancy Protocol (vrrp) ----------------------------------------- "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. Web Security (websec) --------------------- "HTTP Strict Transport Security (HSTS)", Jeff Hodges, Collin Jackson, Adam Barth, 27-Jan-12, This specification defines a mechanism enabling Web sites to declare themselves accessible only via secure connections, and/or for users to be able to direct their user agent(s) to interact with given sites only over secure connections. This overall policy is referred to as HTTP Strict Transport Security (HSTS). The policy is declared by Web sites via the Strict-Transport-Security HTTP response header field, and/or by other means, such as user agent configuration, for example. "Public Key Pinning Extension for HTTP", Chris Evans, Chris Palmer, 9-Dec-11, This memo describes an extension to the HTTP protocol allowing web host operators to instruct user agents (UAs) to remember ("pin") the hosts' cryptographic identities for a given period of time. During that time, UAs will require that the host present a certificate chain including at least one Subject Public Key Info structure whose fingerprint matches one or more of the pinned fingerprints for that host. By effectively reducing the scope of authorities who can authenticate the domain during the lifetime of the pin, pinning may reduce the incidence of man-in-the-middle attacks due to compromised Certification Authorities and other authentication errors and attacks. Centralized Conferencing (xcon) ------------------------------- "Conference Information Data Model for Centralized Conferencing (XCON)", David Ph.D., Gonzalo Camarillo, Jari Urpalainen, Oscar Novo, 19-Sep-11, RFC5239 defines the idea of a centralized conferencing (XCON) as an association of participants with a central focus. The state of a conference is represented by a conference object. This document defines an Extensible Markup Language (XML)-based conference information data model to be used for conference objects. A conference information data model is designed to convey information about the conference and about participation in the conference. The conference information data model defined in this document constitutes an extension of the data format specified in the Session Initiation Protocol (SIP) Event Package for Conference State. "Conference Event Package Data Format Extension for Centralized Conferencing (XCON)", Gonzalo Camarillo, Srivatsa Srinivasan, Roni Even, Jari Urpalainen, 3-Sep-08, This document specifies the notification mechanism for XCON (centralized conferencing). This mechanism reuses the SIP (Session Initiation Protocol) event package for conference state. Additionally, the notification mechanism includes support for the XCON data model and for partial notifications. "Centralized Conferencing Manipulation Protocol", Mary Barnes, Chris Boulton, Simon Romano, Henning Schulzrinne, 2-Aug-11, The Centralized Conferencing Manipulation Protocol (CCMP) allows an XCON conferencing system client to create, retrieve, change, and delete objects that describe a centralized conference. CCMP is a means to control basic and advanced conference features such as conference state and capabilities, participants, relative roles, and details. CCMP is a state-less, XML-based, client server protocol that carries, in its request and response messages, conference information in the form of XML documents and fragments conforming to the centralized conferencing data model schema. "Centralized Conferencing Manipulation Protocol (CCMP) Call Flow Examples", Mary Barnes, Lorenzo Miniero, Roberta Presta, Simon Romano, 1-Aug-11, This document provides detailed call flows for the scenarios documented in the Centralized Conferencing (XCON) Framework and the XCON Scenarios. The call flows document the use of the interface between a conference control client and a conference control server using the Centralized Conferencing Manipulation Protocol (CCMP). The objective is to provide a base reference for both protocol researchers and developers. Extensible Messaging and Presence Protocol (xmpp) ------------------------------------------------- "Extensible Messaging and Presence Protocol (XMPP): Address Format", Peter Saint-Andre, 17-Nov-11, This document defines the address format for the Extensible Messaging and Presence Protocol (XMPP), including support for code points outside the US-ASCII range. This document obsoletes RFC 6122. Metric Blocks for use with RTCP's Extended Report Framework (xrblock) --------------------------------------------------------------------- "Measurement Identity and information Reporting using SDES item and XR Block", Alan Clark, Geoff Hunt, Wenson Wu, 12-Jan-12, This document defines a RTCP SDES item and a RTCP XR Block carrying parameters which identify a measurement, to which one or more other RTCP XR Report Blocks may refer. "RTCP XR Report Block for Packet Delay Variation Metric Reporting", Geoff Hunt, Alan Clark, 7-Dec-11, This document defines an RTCP XR Report Block that allows the reporting of Packet Delay Variation metrics for a range of RTP applications. "RTCP XR Report Block for Burst/Gap Discard metric Reporting", Alan Clark, Geoff Hunt, Wenson Wu, Rachel Huang, 19-Jan-12, This document defines an RTCP XR Report Block that allows the reporting of Burst and Gap Discard metrics for use in a range of RTP applications. "RTCP XR Report Block for Burst/Gap Loss metric Reporting", Alan Clark, Geoff Hunt, Jing Zhao, Wenson Wu, Sunshine Zhang, 18-Jan-12, This document defines an RTCP XR Report Block that allows the reporting of Burst and Gap Loss metrics for use in a range of RTP applications. "RTCP XR Report Block for Delay metric Reporting", Geoff Hunt, Kevin Gross, Alan Clark, 7-Dec-11, This document defines an RTCP XR Report Block that allows the reporting of Delay metrics for use in a range of RTP applications. "RTCP XR Report Block for Discard metric Reporting", Geoff Hunt, Alan Clark, Glen Zorn, 9-Dec-11, This document defines an RTCP XR Report Block that allows the reporting of a simple discard count metric for use in a range of RTP applications. "Real-time Transport Control Protocol (RTCP) Extension Report (XR) for Run Length Encoding of Discarded Packets", Joerg Ott, Varun Singh, Igor Curcio, 2-Feb-12, The Real-time Transport Control Protocol (RTCP) is used in conjunction with the Real-time Transport Protocol (RTP) in to provide a variety of short-term and long-term reception statistics. The available reporting may include aggregate information across longer periods of time as well as individual packet reporting. This document specifies a per-packet report metric capturing individual packets discarded from the jitter buffer after successful reception. "RTCP XR Blocks for QoE Metric Reporting", Geoff Hunt, Alan Clark, Roland Schott, Glen Zorn, 1-Feb-12, This document defines an RTCP XR Report Block and associated SDP parameters that allow the reporting of QoE metrics for use in a range of RTP applications.