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. Generated 2013-05-24 18:10:58 UTC IPv6 over Low power WPAN (6lowpan) ---------------------------------- "Transmission of IPv6 Packets over BLUETOOTH Low Energy", Johanna Nieminen, Teemu Savolainen, Markus Isomaki, Basavaraj Patil, Zach Shelby, Carles Gomez, 12-Feb-13, 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 that enables the use of this air interface with devices such as sensors, smart meters, appliances, etc. The low power variant of BLUETOOTH is currently specified in the revision 4.0 of the BLUETOOTH specifications (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, 1-Apr-13, This ducument is intended to capture the address selection design team's considerations about the address selection issues mainly raised in [RFC5220]. This considerations led to the revision of RFC 3484 [RFC6724], and Address Selection DHCP option. Although it does not perfectly match the current state, this document captures the past discussion and considerations for the historical record. "Distributing Address Selection Policy using DHCPv6", Arifumi Matsumoto, Tomohiro Fujisaki, Tim Chown, 29-Apr-13, RFC 6724 defines default address selection mechanisms for IPv6 that allow nodes to select an appropriate address when faced with multiple source and/or destination addresses to choose between. The RFC 6724 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 parameters and policy table, and thus control the address selection behavior of nodes in their site. "Duplicate Address Detection Proxy", Fabio Costa, Jean-Michel Combes, Xavier Pougnard, Li Hongyu, 9-Apr-13, The document describes a proxy based mechanism allowing the use of Duplicate Address Detection (DAD) by IPv6 nodes in a point-to- multipoint architecture with "split-horizon" forwarding scheme, primarily deployed for Digital Subscriber Line (DSL) and Fiber access architectures. Based on the DAD signalling, the first hop router stores in a Binding Table all known IPv6 addresses used on a point- to-multipoint domain (e.g. VLAN). When a node performs DAD for an address already used by another node, the first hop router replies instead of this last one. "Neighbor Unreachability Detection is too impatient", Erik Nordmark, Igor Gashinsky, 24-Apr-13, IPv6 Neighbor Discovery includes Neighbor Unreachability Detection. That function is very useful when a host has an alternative neighbor, for instance when there are multiple default routers, since it allows the host to switch to the alternative neighbor in short time. This time is 3 seconds after the node starts probing by default. However, if there are no alternative neighbors, this is far too impatient. This document specifies relaxed rules for Neighbor Discovery retransmissions that allow an implementation to choose different timeout behavior based on whether or not there are alternative neighbors. This document updates RFC 4861. "Enhanced Duplicate Address Detection", Rajiv Asati, Hemant Singh, Wes Beebee, Eli Dart, Wesley George, Carlos Pignataro, 24-May-13, 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. "A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)", Fernando Gont, 23-May-13, 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. This method is meant to be an alternative to generating Interface Identifiers based on hardware address (e.g., using IEEE identifiers), such that the benefits of stable addresses can be achieved without sacrificing the privacy of users. The method specified in this document applies to all prefixes a host may be employing, including link-local, global, and unique- local addresses. "Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery", Fernando Gont, 22-Mar-13, This document analyzes the security implications of employing IPv6 fragmentation 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 formally updates RFC 3971 to provide advice regarding how the aforementioned security implications can be prevented. "Packet loss resiliency for Router Solicitations", Suresh Krishnan, Dmitry Anipko, Dave Thaler, 6-May-13, When an interface on a host is initialized, the host transmits Router Solicitations in order to minimize the amount of time it needs to wait until the next unsolicited multicast Router Advertisement is received. In certain scenarios, these router solicitations transmitted by the host might be lost. This document specifies a mechanism for hosts to cope with the loss of the initial Router Solicitations. Furthermore, on some links, unsolicited multicast Router Advertisements are never sent and the mechanism in this document is intended to work even in such scenarios. "Security Implications of Predictable Fragment Identification Values", Fernando Gont, 22-Mar-13, 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. "Transmission of IPv6 Extension Headers", Brian Carpenter, Sheng Jiang, 29-Mar-13, Various IPv6 extension headers have been defined since the IPv6 standard was first published. This document updates RFC 2460 to clarify how intermediate nodes should deal with such extension headers and with any that are defined in future. It also specifies how extension headers should be registered by IANA, with a corresponding minor update to RFC 2780. "The U and G bits in IPv6 Interface Identifiers", Brian Carpenter, Sheng Jiang, 29-Mar-13, The IPv6 addressing architecture defines a method by which the Universal and Group bits of an IEEE link-layer address are mapped into an IPv6 unicast interface identifier. This document clarifies the status of those bits for interface identifiers that are not derived from an IEEE link-layer address, and updates RFC 4291 accordingly. "Updates to the IPv6 Multicast Addressing Architecture", Mohamed Boucadair, Stig Venaas, 23-May-13, This document updates the IPv6 multicast addressing architecture by defining the 17-20 reserved bits as generic flag bits. The document provides also some clarifications related to the use of these flag bits. This document updates RFC 3956, RFC 3306, RFC 4607 and RFC 4291. IPv6 Site Renumbering (6renum) ------------------------------ "IPv6 Site Renumbering Gap Analysis", Bing Liu, Sheng Jiang, Brian Carpenter, Stig Venaas, Wesley George, 10-May-13, This document briefly introduces the existing mechanisms that could be utilized for IPv6 site renumbering and tries to cover most of the explicit issues and requirements of IPv6 renumbering. Through the gap analysis, the document provides a basis for future works that identify and develop solutions or to stimulate such development as appropriate. The gap analysis is organized by the main steps of a renumbering process. Application Bridging for Federated Access Beyond web (abfab) ------------------------------------------------------------ "A GSS-API Mechanism for the Extensible Authentication Protocol", Sam Hartman, Josh Howlett, 13-Aug-12, 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 Extensible Authentication Protocol mechanism. Through the GS2 family of mechanisms defined in RFC 5801, these protocols also define how Simple Authentication and Security Layer (SASL, RFC 4422) applications use the Extensible Authentication Protocol. "Name Attributes for the GSS-API EAP mechanism", Sam Hartman, Josh Howlett, 14-Nov-12, 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, Profiles, Name Identifier Format, and Confirmation Methods for SAML", Josh Howlett, Sam Hartman, 25-Feb-13, This document specifies a RADIUS attribute, a binding, a name identifier format, two profiles, and two confirmation methods for the Security Assertion Mark-up Language (SAML). The attribute provides RADIUS encapsulation of SAML protocol messages, and the binding describes the use of this attribute, and the SAML protocol messages within, with RADIUS transport. The two profiles describe the application of this binding for ABFAB authentication and assertion query/request respectively. The name identifier format allows a subject to be named using an NAI, and the subject confirmation methods allow queries to be issued for a principal without needing to explicitly name the intended subject within the request. These artefacts have been defined to permit application in scenarios other than ABFAB, such as network access. "Application Bridging for Federated Access Beyond web (ABFAB) Use Cases", Rhys Smith, 25-Sep-12, Federated identity is typically associated with Web-based services at present, but there is growing interest in its application in non Web- based contexts. The goal of this document is to document a selection of the wide variety of these contexts whose user experience could be improved through the use of technologies based on the ABFAB architecture and specifications. "Application Bridging for Federated Access Beyond Web (ABFAB) Architecture", Josh Howlett, Sam Hartman, Hannes Tschofenig, Eliot Lear, Jim Schaad, 18-Apr-13, Over the last decade a substantial amount of work has occurred in the space of federated access management. Most of this effort has focused on two use cases: network access and web-based access. However, the solutions to these use cases that have been proposed and deployed tend to have few common building blocks in common. This memo describes an architecture that makes use of extensions to the commonly used security mechanisms for both federated and non- federated access management, including the Remote Authentication Dial In User Service (RADIUS) and the Diameter protocol, the Generic Security Service (GSS), the GS2 family, the Extensible Authentication Protocol (EAP) and the Security Assertion Markup Language (SAML). The architecture addresses the problem of federated access management to primarily non-web-based services, in a manner that will scale to large numbers of identity providers, relying parties, and federations. "Update to the EAP Applicability Statement for ABFAB", Stefan Winter, Joseph Salowey, 17-Mar-13, This document updates the Extensible Authentication Protocol (EAP) applicability statement from RFC3748 to reflect recent usage of the EAP protocol in the Application Bridging for Federated Access Beyond web (ABFAB) working group. ADSL MIB (adslmib) ------------------ "Definitions of Managed Objects for Very High Speed Digital Subscriber Line 2 (VDSL2)", Moti Morgenstern, Scott Baillie, Markus Freudenberger, 4-Dec-12, This document defines a Management Information Base (MIB) module for use with network management protocols in the Internet community. In particular, it describes objects used for managing parameters of the "Very High Speed Digital Subscriber Line 2 (VDSL2)" interface type, which are also applicable for managing Asymmetric Digital Subscriber Line (ADSL), ADSL2, and ADSL2+ interfaces. Application-Layer Traffic Optimization (alto) --------------------------------------------- "ALTO Protocol", Richard Alimi, Reinaldo Penno, Yang Yang, 21-May-13, Applications using the Internet already have access to topology information of Internet Service Provider (ISP) networks. For example, views to Internet routing tables at looking glass servers are available and can be practically downloaded to many application clients. What is missing is knowledge of the underlying network topologies from the point of view of ISPs (henceforth referred as Providers). In other words, what a Provider prefers in terms of traffic optimization -- and a way to distribute it. The Application-Layer Traffic Optimization (ALTO) Service provides network information (e.g., basic network location structure and 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 a simplified view, yet enough information about a network for applications to effectively utilize them. Additional services are built on top of the maps. This document describes a protocol implementing the ALTO Service. Although the ALTO Service would primarily be provided by the network service providers (e.g., Internet service providers), content service providers and third parties could also operate an ALTO service. Applications that could use this service are those that have a choice to which end points to connect. Examples of such applications are peer-to-peer (P2P) and content delivery networks. "ALTO Deployment Considerations", Martin Stiemerling, Sebastian Kiesel, Stefano Previdi, 25-Feb-13, Many Internet applications are used to access resources, such as pieces of information or server processes, which are available in several equivalent replicas on different hosts. This includes, but is not limited to, peer-to-peer file sharing applications. The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to these applications, which have to select one or several hosts from a set of candidates, that are able to provide a desired resource. The protocol is under specification in the ALTO working group. This memo discusses deployment related issues of ALTO for peer-to-peer and CDNs, some preliminary security considerations, and also initial guidance for application designers using ALTO. "ALTO Server Discovery", Sebastian Kiesel, Martin Stiemerling, Nico Schwan, Michael Scharf, Song Yongchao, 21-Mar-13, The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications that have to select one or several hosts from a set of candidates capable of providing a desired resource. ALTO is realized by a client-server protocol. Before an ALTO client can ask for guidance it needs to discover one or more ALTO servers that can provide suitable guidance. This document specifies a procedure for resource consumer initiated ALTO server discovery, which can be used if the ALTO client is embedded in the resource consumer. Access Node Control Protocol (ancp) ----------------------------------- "Access Node Control Protocol (ANCP) MIB module for Access Nodes", Stefaan De Cnodder, Moti Morgenstern, 29-Jan-13, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines objects for managing access nodes that are using the Access Node Control Protocol (ANCP). "Multicast Control Extensions for ANCP", Francois Le Faucheur, Roberta Maglione, Tom Taylor, 24-Feb-13, 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, Thomas Haag, Li Hongyu, 24-Feb-13, The purpose of this document is to provide applicability of the Access Node Control mechanism to Passive Optical Network (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 (app) ----------------------- "Prefer Header for HTTP", James Snell, 7-Jan-13, This specification defines an HTTP header field that can be used by a client to request that certain behaviors be employed by a server while processing a request. "Internet Calendar Scheduling Protocol (iSchedule)", Cyrus Daboo, Bernard Desruisseaux, 3-May-13, This document defines the Internet Calendar Scheduling Protocol (iSchedule), which is a binding from the iCalendar Transport- independent Interoperability Protocol (iTIP) to the Hypertext Transfer Protocol (HTTP) to enable interoperability between calendaring and scheduling systems over the Internet. "The Hypertext Transfer Protocol (HTTP) Status Code 308 (Permanent Redirect)", Julian Reschke, 26-Mar-12, This document specifies the additional HyperText Transfer Protocol (HTTP) Status Code 308 (Permanent Redirect). "A Uniform Resource Name (URN) Namespace for Examples", Peter Saint-Andre, 19-Apr-13, This document defines a Uniform Resource Name (URN) namespace identifier enabling generation of URNs that are appropriate for use in documentation and in URN-related testing and experimentation. "A Uniform Resource Name (URN) Namespace for IANA Registries", Peter Saint-Andre, Michelle Cotton, 13-Feb-13, This document defines a Uniform Resource Name (URN) namespace for uniquely identifying information contained in registries maintained by the Internet Assigned Numbers Authority (IANA). Applications Area Working Group (appsawg) ----------------------------------------- "Advice for Safe Handling of Malformed Messages", Murray Kucherawy, Gregory Shapiro, 17-May-13, Although Internet mail formats have been precisely defined since the 1970s, authoring and handling software often show only mild conformance to the specifications. The distributed and non- interactive nature of email has often prompted adjustments to receiving software, to handle these variations, rather than trying to gain better conformance by senders, since the receiving operator is primarily driven by complaining recipient users and has no authority over the sending side of the system. Processing with such flexibility comes at some cost, since mail software is faced with decisions about whether or not to permit non-conforming messages to continue toward their destinations unaltered, adjust them to conform (possibly at the cost of losing some of the original message), or outright rejecting them. A core requirement for interoperability is that both sides of an exchange work from the same details and semantics. By having receivers be flexible, beyond the specifications, there can be -- and often has been -- a good chance that a message will not be fully interoperable. Worse, a well-established pattern of tolerance for variations can sometimes be used as an attack vector. This document includes a collection of the best advice available regarding a variety of common malformed mail situations, to be used as implementation guidance. It must be emphasized, however, that the intent of this document is not to standardize malformations or otherwise encourage their proliferation. The messages are manifestly malformed, and the code and culture that generates them needs to be fixed. Therefore, these messages should be rejected outright if at all possible. Nevertheless, many malformed messages from otherwise legitimate senders are in circulation and will be for some time, and, unfortunately, commercial reality shows that we cannot always simply reject or discard them. Accordingly, this document presents alternatives for dealing with them in ways that seem to do the least additional harm until the infrastructure is tightened up to match the standards. "Spam reporting using IMAP: SREP", Zoltan Ordogh, 11-Mar-13, This document defines an IMAP extension which allows a client to report spam by reference and allows an IMAP server to perform any action on the reported messages, including leaving the action at the client's discretion. In addition, this document discusses how an IMAP server can tap into spam aggregator services, ultimately allowing the IMAP server to improve its decision-making process. Conventions Used In This Document In examples, "C:" and "S:" indicate lines sent by the client or the server, respectively. "Forwarded HTTP Extension", Andreas Petersson, Martin Nilsson, 9-Oct-12, This document defines an HTTP extension header field that allows proxy components to disclose information lost in the proxying process, for example, the originating IP address of a request or IP address of the proxy on the user-agent-facing interface. In a path of proxying components, this makes it possible to arrange it so that each subsequent component will have access to, for example, all IP addresses used in the chain of proxied HTTP requests. This document also specifies guidelines for a proxy administrator to anonymize the origin of a request. "WebFinger", Paul Jones, Gonzalo Salgueiro, Joseph Smarr, 16-Apr-13, This specification defines the WebFinger protocol, which can be used to discover information about people or other entities on the Internet using standard HTTP methods. WebFinger discovers information for a URI that might not be usable as a locator otherwise, such as account or email URIs. "The 'acct' URI Scheme", Peter Saint-Andre, 1-May-13, This document defines the 'acct' Uniform Resource Identifier (URI) scheme as a way to identify a user's account at a service provider, irrespective of the particular protocols that can be used to interact with the account. "XML Media Types", Chris Lilley, Murata Makoto, Alexey Melnikov, Henry Thompson, 23-Nov-12, This specification standardizes three media types -- application/xml, application/xml-external-parsed-entity, and application/xml-dtd -- for use in exchanging network entities that are related to the Extensible Markup Language (XML) while defining text/xml and text/ xml-external-parsed-entity as aliases for the respective application/ types. This specification also standardizes a convention (using the suffix '+xml') for naming media types outside of these five types when those media types represent XML MIME entities. XML MIME entities are currently exchanged via the HyperText Transfer Protocol on the World Wide Web, are an integral part of the WebDAV protocol for remote web authoring, and are expected to have utility in many domains. Major differences from [RFC3023] are alignment of charset handling for text/xml and text/xml-external-parsed-entity with application/ xml, the addition of XPointer and XML Base as fragment identifiers and base URIs, respectively, mention of the XPointer Registry, and updating of many references. "A Media Type for XML Patch Operations", Erik Wilde, 21-Feb-13, The XML Patch media type "application/xml-patch+xml" defines an XML document structure for expressing a sequence of patch operations that are applied to an XML document. The XML Patch document format's foundations are defined in RFC 5261, this specification defines a document format and a media type registration, so that XML Patch documents can be labeled with a media type, for example in HTTP conversations. In addition to the media type registration, this specification also updates RFC 5261 in some aspects, limiting these updates to cases where RFC 5261 needed to be fixed, or was hard to understand. "Message Header Field for Indicating Message Authentication Status", Murray Kucherawy, 23-May-13, This document specifies a header field for use with electronic mail messages to indicate the results of message authentication efforts. Any receiver-side software, such as mail filters or Mail User Agents (MUAs), can use this header field to relay that information in a convenient and meaningful way to users, or make sorting and filtering decisions. This document is a candidate for Internet Standard status. [RFC Editor: Please delete this notation, as I imagine it will be indicated some other way.] "The application/json-merge-patch Media Type", James Snell, 20-May-13, This specification defines the application/json-merge-patch media type and it's intended use with the HTTP PATCH method defined by RFC 5789. "Sieve Email Filtering: Detecting Duplicate Deliveries", Stephan Bosch, 22-May-13, This document defines a new test command "duplicate" for the "Sieve" email filtering language. This test adds the ability to detect duplicate message deliveries. The main application for this new test is handling duplicate deliveries commonly caused by mailing list subscriptions or redirected mail addresses. The detection is normally performed by matching the message ID to an internal list of message IDs from previously delivered messages. For more complex applications, the "duplicate" test can also use the content of a specific header or other parts of the message. Audio/Video Transport Core Maintenance (avtcore) ------------------------------------------------ "Securing the RTP Protocol Framework: Why RTP Does Not Mandate a Single Media Security Solution", Colin Perkins, Magnus Westerlund, 7-May-13, 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. Guidelines for designers and reviewers of future RTP extensions are provided, to ensure that appropriate security mechanisms are mandated, and that any such mechanisms are specified in a manner that conforms with the RTP architecture. "Inter-destination Media Synchronization using the RTP Control Protocol (RTCP)", Ray van Brandenburg, Hans Stokking, Oskar van Deventer, Fernando Boronat, Mario Montagud, Kevin Gross, 19-Mar-13, This document defines a new RTP Control Protocol (RTCP) Packet Type and RTCP Extended Report (XR) Block Type to be used for achieving Inter-Destination Media Synchronization (IDMS). IDMS is the process of synchronizing playout across multiple geographically distributed media receivers. Using the RTCP XR IDMS Reporting Block defined in this document, media playout information from participants in a synchronization group can be collected. Based on the collected information, an RTCP IDMS Settings Packet can then be send to distribute a common target playout point to which all the distributed receivers, sharing a media experience, can synchronize. Typical use cases in which IDMS is usefull 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 loudspeakers, etc. "AES-GCM and AES-CCM Authenticated Encryption in Secure RTP (SRTP)", David McGrew, Kevin Igoe, 20-May-13, This document defines how AES-GCM and AES-CCM Authenticated Encryption with Associated Data algorithms can be used to provide confidentiality and data authentication in the SRTP protocol. "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, 3-Dec-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. "RTP and Leap Seconds", Kevin Gross, Ray van Brandenburg, 19-Feb-13, This document discusses issues that arise when RTP sessions span Universal Coordinate Time (UTC) leap seconds. It updates RFC 3550 to describe how RTP senders and receivers should behave in the presence of leap seconds. "RTP Clock Source Signalling", Aidan Williams, Kevin Gross, Ray van Brandenburg, Hans Stokking, 8-May-13, NTP format timestamps are used by several RTP protocols for synchronisation and statistical measurements. This memo specifies SDP signalling identifying timestamp reference clock sources and SDP signalling identifying the media clock sources in a multimedia session. "Options for Securing RTP Sessions", Magnus Westerlund, Colin Perkins, 6-May-13, The Real-time Transport Protocol (RTP) is used in a large number of different application domains and environments. This heterogeneity implies that different security mechanisms are needed to provide services such as confidentiality, integrity and source authentication of RTP/RTCP packets suitable for the various environments. The range of solutions makes it difficult for RTP-based application developers to pick the most suitable mechanism. This document provides an overview of a number of security solutions for RTP, and gives guidance for developers on how to choose the appropriate security mechanism. "Multiple Media Types in an RTP Session", Magnus Westerlund, Colin Perkins, Jonathan Lennox, 25-Feb-13, This document specifies how an RTP session can contain media streams with media from multiple media types such as audio, video, and text. This has been restricted by the RTP Specification, and thus this document updates RFC 3550 and RFC 3551 to enable this behaviour for applications that satisfy the applicability for using multiple media types in a single RTP session. "Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions", Colin Perkins, Varun Singh, 25-Feb-13, The Real-time Transport Protocol (RTP) is widely used in telephony, video conferencing, and telepresence applications. Such applications are often run on best-effort UDP/IP networks. If congestion control is not implemented in the applications, then network congestion will deteriorate the user's multimedia experience. This document does not propose a congestion control algorithm; instead, it defines a minimal set of RTP "circuit-breakers". Circuit-breakers are conditions under which an RTP sender needs to stop transmitting media data in order to protect the network from excessive congestion. It is expected that, in the absence of severe congestion, all RTP applications running on best-effort IP networks will be able to run without triggering these circuit breakers. Any future RTP congestion control specification will be expected to operate within the constraints defined by these circuit breakers. "Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)", Ali Begen, Colin Perkins, Dan Wing, Eric Rescorla, 23-Apr-13, The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a persistent transport-level identifier for an RTP endpoint. While the Synchronization Source (SSRC) identifier of an RTP endpoint may change if a collision is detected or when the RTP application is restarted, its RTCP CNAME is meant to stay unchanged, so that RTP endpoints can be uniquely identified and associated with their RTP media streams. For proper functionality, RTCP CNAMEs should be unique within the participants of an RTP session. However, the existing guidelines for choosing the RTCP CNAME provided in the RTP standard are insufficient to achieve this uniqueness. RFC 6222 was published to update those guidelines to allow endpoints to choose unique RTCP CNAMEs. Unfortunately, later investigations showed that some parts of the new algorithms were unnecessarily complicated and/or ineffective. This document addresses these concerns and replaces RFC 6222. "Update to Recommended Codecs for the RTP Profile for Audio and Video Conferences with Minimal Control (RTP/AVP)", Timothy Terriberry, 10-Apr-13, The RTP Profile for Audio and Video Conferences with Minimal Control (RTP/AVP) is the basis for many other profiles, such as the Secure Real-time Transport Protocol (RTP/SAVP), the Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/ AVPF), and the Extended Secure RTP Profile for RTCP-Based Feedback (RTP/SAVPF). This document updates the RTP/AVP profile (and by extension, the profiles that build upon it) to reflect changes in audio codec usage since the document was originally published. "Guidelines for using the Multiplexing Features of RTP", Magnus Westerlund, BoB, Colin Perkins, Harald Alvestrand, 22-Apr-13, Real-time Transport Protocol (RTP) is a flexible protocol possible to use in a wide range of applications and network and system topologies. This flexibility and the implications of different choices should be understood by any application developer using RTP. To facilitate that understanding, this document contains an in-depth discussion of the usage of RTP's multiplexing points; the RTP session and the Synchronisation Source Identifier (SSRC). The document tries to give guidance and source material for an analysis on the most suitable choices for the application being designed. "RTP Considerations for Endpoints Sending Multiple Media Streams", Jonathan Lennox, Magnus Westerlund, Wenson Wu, Colin Perkins, 22-Apr-13, This document expands and clarifies the behavior of the Real-Time Transport Protocol (RTP) endpoints when they are sending multiple media streams in a single RTP session. In particular, issues involving Real-Time Transport Control Protocol (RTCP) messages are described. This document updates RFC 3550 in regards to handling of multiple SSRCs per endpoint in RTP sessions. "RTP Topologies", Magnus Westerlund, Stephan Wenger, 22-Apr-13, This document discusses point to point and multi-endpoint topologies used in Real-time Transport Protocol (RTP)-based environments. In particular, centralized topologies commonly employed in the video conferencing industry are mapped to the RTP terminology. This document is updated with additional topologies and are intended to replace RFC 5117. Audio/Video Transport Extensions (avtext) ----------------------------------------- "Support for Multiple Clock Rates in an RTP Session", Marc Petit-Huguenin, Glen Zorn, 21-Apr-13, 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. "Duplicating RTP Streams", Ali Begen, Colin Perkins, 21-Mar-13, Packet loss is undesirable for real-time multimedia sessions, but can occur due to congestion, or other unplanned network outages. This is especially true for IP multicast networks, where packet loss patterns can vary greatly between receivers. One technique that can be used 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 Real-time Transport Protocol (RTP) streams can be duplicated without breaking RTP or RTP Control Protocol (RTCP) rules. Behavior Engineering for Hindrance Avoidance (behave) ----------------------------------------------------- "Stream Control Transmission Protocol (SCTP) Network Address Translation", Randall Stewart, Michael Tuexen, Irene Ruengeler, 25-Feb-13, Stream Control Transmission Protocol [RFC4960] provides a reliable communications channel between two end-hosts in many ways similar to TCP [RFC0793]. With the widespread deployment of Network Address Translators (NAT), specialized code has been added to NAT for TCP that allows multiple hosts to reside behind a NAT and yet use only a single globally unique IPv4 address, even when two hosts (behind a NAT) choose the same port numbers for their connection. This additional code is sometimes classified as Network Address and Port Translation or NAPT. To date, specialized code for SCTP has NOT yet been added to most NATs so that only pure NAT is available. The end result of this is that only one SCTP capable host can be behind a NAT. This document describes an SCTP specific variant of NAT which provides similar features of NAPT in the single point and multi-point traversal scenario. "Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis", Teemu Savolainen, Jouni Korhonen, Dan Wing, 4-Apr-13, This document describes a method for detecting the presence of DNS64 and for learning the IPv6 prefix used for protocol translation on an access network. The method depends on the existence of a well-known IPv4-only fully qualified domain name "ipv4only.arpa". The information learned enables nodes to perform local IPv6 address synthesis and to potentially avoid NAT64 on dual-stack and multi- interface deployments. "Analysis of solution proposals for hosts to learn NAT64 prefix", Jouni Korhonen, Teemu Savolainen, 8-Mar-12, 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. "Additional Managed Objects for Network Address Translators (NAT)", Simon Perreault, Tina Tsou, Senthil Sivakumar, 1-May-13, 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 monitoring of a device capable of NAT function. "Syslog Format for NAT Logging", Zhonghua Chen, Cathy Zhou, Tina Tsou, Tom Taylor, 8-May-13, With the wide deployment of Carrier Grade NAT (CGN) devices, the logging of NAT-related events has become very important for legal purposes. The logs may be required to identify a host that was used to launch malicious attacks or engage in illegal behaviour, and/or may be required for accounting purposes. This document identifies the events that need to be logged and the parameters that are required in the logs depending on the context in which the NAT is being used. It goes on to standardize formats for reporting these events and parameters using SYSLOG (RFC 5424). A companion document specifies formats for reporting the same events and parameters using IPFIX (RFC 5101). Applicability statements are provided in this document and its companion to guide operators and implementors in their choice of which technology to use for logging. "IPFIX Information Elements for logging NAT Events", Senthil Sivakumar, Reinaldo Penno, 19-Mar-13, NAT devices are required to log events like creation and deletion of translations and information about the resources it is managing. With the wide deployment of Carrier Grade NAT (CGN) devices, the logging of events have become very important for legal purposes. 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. Binary Floor Control Protocol Bis (bfcpbis) -------------------------------------------- "The Binary Floor Control Protocol (BFCP)", Gonzalo Camarillo, Keith Drage, Tom Kristensen, Joerg Ott, Charles Eckel, 26-Apr-13, Floor control is a means to manage joint or exclusive access to shared resources in a (multiparty) conferencing environment. Thereby, floor control complements other functions -- such as conference and media session setup, conference policy manipulation, and media control -- that are realized by other protocols. This document specifies the Binary Floor Control Protocol (BFCP). BFCP is used between floor participants and floor control servers, and between floor chairs (i.e., moderators) and floor control servers. This document obsoletes RFC 4582. Changes from RFC 4582 are summarized in Section 16. "Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams", Gonzalo Camarillo, Tom Kristensen, 26-Apr-13, This document specifies how to describe Binary Floor Control Protocol (BFCP) streams in Session Description Protocol (SDP) descriptions. User agents using the offer/answer model to establish BFCP streams use this format in their offers and answers. This document obsoletes RFC 4583. Changes from RFC 4583 are summarized in Section 12. Bidirectional Forwarding Detection (bfd) ---------------------------------------- "BFD Management Information Base", Thomas Nadeau, Zafar Ali, Nobo Akiya, 17-Dec-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 describes managed objects for modeling Bidirectional Forwarding Detection (BFD) protocol. "BFD Generic Cryptographic Authentication", Manav Bhatia, Vishwas Manral, Dacheng Zhang, 18-Apr-13, This document proposes an extension to Bidirectional Forwarding Detection (BFD) to allow the use of arbitary cryptographic authentication algorithms in addition to the already-documented authentication schemes described in the base specification. This document adds the basic infrastructure that is required for supporting algorithm and key agility for BFD. "BFD for Multipoint Networks", Dave Katz, David Ward, 17-May-13, 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, 18-Apr-13, This document describes the mechanism to authenticate Bidirectional Forwarding Detection (BFD) protocol packets using Hashed Message Authentication Mode (HMAC) with the SHA-256, SHA-384, and SHA-512 algorithms. The described mechanism uses the Generic Cryptographic Authentication and Generic Meticulous Cryptographic Authentication sections to carry the authentication data. This document updates, but does not supercede, the cryptographic authentication mechanism specified in RFC 5880. "BFD Management Information Base (MIB) extensions for MPLS and MPLS-TP Networks", Sam Aldrin, Venkatesan Mahalingam, Kannan Sampath, Thomas Nadeau, 26-Dec-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. "Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces", Manav Bhatia, Mach Chen, Sami Boutros, Marc Binderberger, Jeffrey Haas, 10-May-13, This document proposes a mechanism to run BFD on Link Aggregation Group (LAG) interfaces. It does so by running an independent Asynchronous mode BFD session on every LAG member link. This mechanism allows the verification of member link continuity, either in combination with, or in absence of, LACP. It provides a shorter detection time than what LACP offers. The continuity check can also cover elements of layer 3 bidirectional forwarding. This mechanism utilizes a well-known UDP port distinct from that of single-hop BFD over IP. This new UDP port removes the ambiguity of BFD over LAG packets from BFD over single-hop IP. Basic Level of Interoperability for SIP Services (bliss) -------------------------------------------------------- "Shared Appearances of a Session Initiation Protocol (SIP) Address of Record (AOR)", Alan Johnston, Mohsen Soroushnejad, Venkatesh Venkataramanan, 16-Jan-13, 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. This specification updates RFC3261 and RFC4235. Benchmarking Methodology (bmwg) ------------------------------- "Methodology for Benchmarking SIP Networking Devices", Carol Davids, Vijay Gurbani, Scott Poretsky, 8-Jan-13, This document describes the methodology for benchmarking Session Initiation Protocol (SIP) performance as described in SIP benchmarking terminology document. The methodology and terminology are to be used for benchmarking signaling plane performance with varying signaling and media load. Both scale and establishment rate are measured by signaling plane performance. The SIP Devices to be benchmarked may be a single device under test (DUT) or a system under test (SUT). Benchmarks can be obtained and compared for different types of devices such as SIP Proxy Server, SBC, and server paired with a media relay or Firewall/NAT device. "Terminology for Benchmarking Session Initiation Protocol (SIP) Networking Devices", Carol Davids, Vijay Gurbani, Scott Poretsky, 8-Jan-13, This document provides a terminology for benchmarking the SIP performance of networking devices. The term performance in this context means the capacity of the device- or system-under-test to process SIP messages. Terms are included for test components, test setup parameters, and performance benchmark metrics for black-box benchmarking of SIP networking devices. The performance benchmark metrics are obtained for the SIP signaling plane only. The terms are intended for use in a companion methodology document for characterizing the performance of a SIP networking device under a variety of conditions. The intent of the two documents is to enable a comparison of the capacity of SIP networking devices. Test setup parameters and a methodology document are necessary because SIP allows a wide range of configuration and operational conditions that can influence performance benchmark measurements. A standard terminology and methodology will ensure that benchmarks have consistent definition and were obtained following the same procedures. "Benchmarking Methodology for Content-Aware Network Devices", Mike Hamilton, Sarah Banks, 6-Feb-13, This document defines a set of test scenarios and metrics that can be used to benchmark content-aware network devices. The scenarios in the following document are intended to more accurately predict the performance of these devices when subjected to dynamic 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, 13-Dec-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) -------------------------------------------- "Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks", Young Lee, Greg Bernstein, Dan Li, Wataru Imajuku, 13-May-13, This document provides a model of information needed by the routing and wavelength assignment (RWA) process in wavelength switched optical networks (WSONs). The purpose of the information described in this model is to facilitate constrained lightpath computation in WSONs. This model takes into account compatibility constraints between WSON signal attributes and network elements but does not include constraints due to optical impairments. Aspects of this information that may be of use to other technologies utilizing a GMPLS control plane are discussed. "Routing and Wavelength Assignment Information Encoding for Wavelength Switched Optical Networks", Greg Bernstein, Young Lee, Dan Li, Wataru Imajuku, 15-Mar-13, 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, 25-Jan-13, 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, 25-Feb-13, 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 entities of Ethernet LSPs, and defines the Ethernet technology specific TLV based on [OAM-CONF-FWK]. "GMPLS OSPF Enhancement for Signal and Network Element Compatibility for Wavelength Switched Optical Networks", Young Lee, Greg Bernstein, 6-Feb-13, 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, 6-May-13, Generalized Multiprotocol Label Switching can be used to control a wide variety of technologies. In some of these technologies network elements and links may impose additional routing constraints such as asymmetric switch connectivity, non-local label assignment, and label range limitations on links. This document provides efficient, protocol-agnostic encodings for general information elements representing connectivity and label constraints as well as label availability. It is intended that protocol-specific documents will reference this memo to describe how information is carried for specific uses. "Configuration of Pro-Active Operations, Administration, and Maintenance (OAM) Functions for MPLS-based Transport Networks using RSVP-TE", Elisa Bellagamba, Loa Andersson, Pontus Skoldstrom, David Ward, Attila Takacs, 12-Dec-12, 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. "Framework for GMPLS and PCE Control of G.709 Optical Transport Networks", Fatai Zhang, Dan Li, Han Li, Sergio Belotti, Daniele Ceccarelli, 21-Feb-13, 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 published in 2012. "Signaling Extensions for Wavelength Switched Optical Networks", Greg Bernstein, Sugang Xu, Young Lee, Giovanni Martinelli, Hiroaki Harai, 18-Feb-13, 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. "RSVP-TE Extensions for Associated Bidirectional LSPs", Fei Zhang, Ruiquan Jing, Rakesh Gandhi, 18-Mar-13, 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 defining the new Association Types in the Extended ASSOCIATION object. "Evaluation of existing GMPLS encoding against G.709v3 Optical Transport Networks (OTN)", Sergio Belotti, Pietro Grandi, Daniele Ceccarelli, Diego Caviglia, Fatai Zhang, Dan Li, 4-Apr-13, ITU-T recommendation G.709 [G.709-2012] has introduced new fixed and flexible Optical Data Unit (ODU) containers in Optical Transport Networks (OTNs). This document provides an evaluation of existing Generalized Multiprotocol Label Switching (GMPLS) routing and signaling methods against the G.709 [G.709-2012] OTN networks. "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, 4-Apr-13, ITU-T Recommendation G.709 [G.709-2012] has introduced new fixed and flexible Optical Data Unit (ODU) containers, enabling optimized support for an increasingly abundant service mix. This document describes Open Shortest Path First - Traffic Engineering (OSPF-TE) routing protocol extensions to support Generalized MPLS (GMPLS) control of all currently defined ODU containers, in support of both sub-lambda and lambda level routing granularity. "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for the evolving G.709 Optical Transport Networks Control", Fatai Zhang, Guoying Zhang, Sergio Belotti, Daniele Ceccarelli, Khuzema Pithewan, 7-Apr-13, ITU-T Recommendation G.709 [G709-2012] has introduced new Optical channel Data Unit (ODU) containers (ODU0, ODU4, ODU2e and ODUflex) and enhanced Optical Transport Networking (OTN) flexibility. This document updates RFC4328 to provide the extensions to the Generalized Multi-Protocol Label Switching (GMPLS) signaling to control the evolving OTN addressing ODUk multiplexing and new features including ODU0, ODU4, ODU2e and ODUflex. "RSVP-TE Extensions for Collecting SRLG Information", Fatai Zhang, Dan Li, Oscar de Dios, Cyril Margaria, Matt Hartley, 25-Feb-13, This document provides extensions for the Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) to support automatic collection of Shared Risk Link Group (SRLG) Information for the TE link formed by a LSP. "Revised Definition of The GMPLS Switching Capability and Type Fields", Lou Berger, Julien Meuric, 17-Apr-13, 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 used 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. "LSP Attribute in ERO", Cyril Margaria, Giovanni Martinelli, Steve Balls, Ben Wright, 25-Feb-13, LSP attributes can be specified or recorded for whole path, but they cannot be targeted to a specific hop. This document proposes alternative ways to extend the semantic for RSVP ERO object to target LSP attributes to a specific hop. "Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Routes", Zafar Ali, George Swallow, Clarence Filsfils, Matt Hartley, Ori Gerstel, Gabriele Galimberti, Kenji Kumaki, Ruediger Kunze, Julien Meuric, 18-Feb-13, RFC 4874 specifies methods by which route exclusions may be communicated during RSVP-TE signaling in networks where precise explicit paths are not computed by the LSP source node. This document specifies signaling for additional route exclusions based on Paths currently existing or expected to exist within the network. "Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) extension for recording TE Metric of a Label Switched Path", Zafar Ali, George Swallow, Clarence Filsfils, Matt Hartley, Kenji Kumaki, Ruediger Kunze, 25-Feb-13, There are many scenarios in which Traffic Engineering (TE) metrics such as cost, latency and latency variation associated with a Forwarding Adjacency (FA) or Routing Adjacency (RA) Label Switched Path (LSP) are not available to the ingress and egress nodes. This draft provides extensions for the Resource ReserVation Protocol- Traffic Engineering (RSVP-TE) for the support of the discovery of cost, latency and latency variation of an LSP. "GMPLS RSVP-TE Extensions for Lock Instruct and Loopback", Jie Dong, Mach Chen, Zhenqiang Li, Daniele Ceccarelli, 23-May-13, This document specifies extensions to RSVP-TE to support lock instruct and loopback mechanism for LSPs. The mechanisms are applicable to technologies which use GMPLS as control plane. Content Delivery Networks Interconnection (cdni) ------------------------------------------------ "Content Distribution Network Interconnection (CDNI) Requirements", Kent Leung, Yiu Lee, 9-Apr-13, 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]". "Framework for CDN Interconnection", Larry Peterson, Bruce Davie, 18-Feb-13, 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, distribution metadata exchange, and logging information exchange across CDNs. 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. It obsoletes RFC 3466. "CDN Interconnect Metadata", Ben Niven-Jenkins, Rob Murray, Grant Watson, Matt Caulfield, Kent Leung, Kevin Ma, 25-Feb-13, The CDNI Metadata Interface enables interconnected CDNs to exchange content distribution metadata in order to enable content acquisition and delivery. The CDNI metadata associated with a piece of content provides a downstream CDN with sufficient information for the downstream CDN to service content requests on behalf of an upstream CDN. This document describes both the core set of CDNI metadata and the protocol for exchanging that metadata. "CDNI Logging Interface", Gilles Bertrand, Iuniana Oprescu, Stephan Emile, Roy Peterkofsky, Francois Le Faucheur, Pawel Grochocki, 22-Feb-13, This memo specifies the Logging interface between a downstream CDN (dCDN) and an upstream CDN (uCDN) that are interconnected as per the CDN Interconnection (CDNI) framework. First, it describes a reference model for CDNI logging. Then, it specifies the actual protocol for CDNI logging information exchange covering the information elements as well as the transport of those elements. "CDNI Control Interface / Triggers", Rob Murray, Ben Niven-Jenkins, 8-Apr-13, This document describes the part of the CDN Interconnect Control Interface that allows a CDN to trigger activity in an interconnected CDN that is configured to deliver content on its behalf. The upstream CDN can use this mechanism to request that the downstream CDN pre-positions metadata or content, or that it re-validate or purge metadata or content. The upstream CDN can monitor the status of activity that it has triggered in the downstream CDN. "Request Routing Redirection Interface for CDN Interconnection", Wang Danhua, Ben Niven-Jenkins, Xiaoyan He, Ge Chen, Wei Ni, 15-Apr-13, The Request Routing Interface comprises of (1) the asynchronous advertisement of footprint and capabilities by a downstream CDN that allows a upstream CDN to decide whether to redirect particular user requests to that downstream CDN; and (2) the synchronous operation of an upstream CDN requesting whether a downstream CDN is prepared to accept a user request and of a downstream CDN responding with how to actually redirect the user request. This document describes an interface for the latter part, i.e. the CDNI request routing/ Redirection Interface. ControLling mUltiple streams for tElepresence (clue) ---------------------------------------------------- "Use Cases for Telepresence Multi-streams", Allyn Romanow, Stephen Botzko, Mark Duckworth, Roni Even, 6-Apr-13, 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, 15-Jan-13, 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", Mark Duckworth, Andrew Pepperell, Stephan Wenger, 16-May-13, This document offers a framework for a protocol that enables devices in a telepresence conference to interoperate by specifying the relationships between multiple media streams. "Mapping RTP streams to CLUE media captures", Roni Even, Jonathan Lennox, 17-Feb-13, This document describes mechanisms and recommended practice for mapping RTP media streams defined in SDP to CLUE media captures. Internet Wideband Audio Codec (codec) ------------------------------------- "Summary of Opus listening test results", Christian Hoene, Jean-Marc Valin, Koen Vos, Jan Skoglund, 17-May-13, This document describes and examines listening test results obtained for the Opus codec and how they relate to the requirements. "Ogg Encapsulation for the Opus Audio Codec", Timothy Terriberry, Ron Lee, Ralph Giles, 24-May-13, This document defines the Ogg encapsulation for the Opus interactive speech and audio codec. This allows data encoded in the Opus format to be stored in an Ogg logical bitstream. Ogg encapsulation provides Opus with a long-term storage format supporting all of the essential features, including metadata, fast and accurate seeking, corruption detection, recapture after errors, low overhead, and the ability to multiplex Opus with other codecs (including video) with minimal buffering. It also provides a live streamable format, capable of delivery over a reliable stream-oriented transport, without requiring all the data, or even the total length of the data, up-front, in a form that is identical to the on-disk storage format. Congestion Exposure (conex) --------------------------- "IPv6 Destination Option for ConEx", Suresh Krishnan, Mirja Kuehlewind, Carlos Ucendo, 28-Mar-13, 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. "Mobile Communication Congestion Exposure Scenario", Dirk Kutscher, Faisal Mir, Rolf Winter, Suresh Krishnan, Ying Zhang, Carlos Bernardos, 10-Jan-13, This memo describes a mobile communications use case for congestion exposure (CONEX) with a particular focus on mobile communication networks such as 3GPP Evoled Packet System (EPS). The draft provides a brief overview of the architecture of these networks (both 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. Constrained RESTful Environments (core) --------------------------------------- "Constrained Application Protocol (CoAP)", Zach Shelby, Klaus Hartke, Carsten Bormann, 1-May-13, The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as 6LoWPAN often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine-to-machine (M2M) applications such as smart energy and building automation. CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with 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, 30-Mar-13, 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 -\u002D 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. The present revision -11 fixes one example and adds the text and examples about the Block/Observe interaction, taken from -observe. It also adds a couple of formatting bugs from the new xml2rfc. The "grand rewrite" is next. "Observing Resources in CoAP", Klaus Hartke, 25-Feb-13, 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 enables CoAP clients to "observe" resources, i.e., to retrieve a representation of a resource and keep this representation updated by the server over a period of time. The protocol follows a best- effort approach for sending new representations to clients, and provides eventual consistency between the state observed by each client and the actual resource state at the server. "Group Communication for CoAP", Akbar Rahman, Esko Dijk, 7-May-13, CoAP is a RESTful transfer protocol for constrained devices and networks. It is anticipated that constrained devices will often naturally operate in groups (e.g. in a building automation scenario all lights in a given room may need to be switched on/off as a group). This document provides guidance for how the CoAP protocol should be used in a group communication context. An approach for using CoAP on top of IP multicast is detailed for both constrained and un-constrained networks. Also, various use cases and corresponding protocol flows are provided to illustrate important concepts. Finally, guidance is provided for deployment in various network topologies. Call Control UUI Service for SIP (cuss) --------------------------------------- "A Mechanism for Transporting User to User Call Control Information in SIP", Alan Johnston, James Rafferty, 9-Apr-13, 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 specific 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. DNS-based Authentication of Named Entities (dane) ------------------------------------------------- "Using Secure DNS to Associate Certificates with Domain Names For S/MIME", Paul Hoffman, Jakob Schlyter, 19-Mar-13, This document describes how to use secure DNS to associate an S/MIME user's certificate with the intended domain name, similar to the way that DANE (RFC 6698) does for TLS. "Secure SMTP using DNS-Based Authentication of Named Entities (DANE) TLSA records.", Tony Finch, 25-Feb-13, SMTP has a STARTTLS extension, but (especially in the case of inter- domain mail transfer) it only provides very limited security because it does not specify how to authenticate the server's certificate. This memo specifies how TLSA records in the DNS can be used for proper SMTP server authentication. "Using DNS-Based Authentication of Named Entities (DANE) TLSA records with SRV and MX records.", Tony Finch, 25-Feb-13, The DANE specification [RFC6698] describes how to use TLSA resource records in the DNS to associate a server's host name with its TLS certificate. The association is secured with DNSSEC. Some application protocols can use SRV records [RFC2782] to indirectly name the server hosts for a service domain. (SMTP uses MX records for the same purpose.) This specification gives generic instructions for how these application protocols locate and use TLSA records. Separate documents give the details that are specific to particular application protocols. Dynamic Host Configuration (dhc) -------------------------------- "Guidelines for Creating New DHCPv6 Options", David Hankins, Tomek Mrugalski, Marcin Siodelski, Sheng Jiang, Suresh Krishnan, 9-Apr-13, This document provides guidance to prospective DHCPv6 Option developers to help them creating option formats that are easily adoptable by existing DHCPv6 software. This document updates RFC3315. "Container Option for Server Configuration", Ralph Droms, Reinaldo Penno, 8-Apr-13, In some DHCP service deployments, it is desirable for a DHCP server in one administrative domain to pass configuration options to a DHCP server in a different administrative domain. This DHCP option carries a set of DHCP options that can be used by another DHCP server. "Prefix Assignment in DHCPv6", Sheng Jiang, Frank Xia, Behcet Sarikaya, 25-Feb-13, This document introduces a generic host-oriented prefix assignment mechanism using DHCPv6. In this new address configuration procedure, the prefix is assigned from a DHCPv6 server to hosts through DHCPv6 message exchanging while the interface identifiers are independently generated by the hosts. It enables both integral address assignment and self-generated addresses in one single mechanism, DHCPv6. It also enables stateless address configuration without RA attendance. The technique described in this document can be used in networks which assign IPv6 addresses using DHCPv6, e.g. WiMAX. "DHCPv6 Failover Requirements", Tomek Mrugalski, Kim Kinnear, 9-May-13, The DHCPv6 protocol, defined in [RFC3315] allows for multiple servers to operate on a single network, however it does not define any way the servers could share information about currently active clients and their leases. Some sites are interested in running multiple servers in such a way as to provide increased availability in case of server failure. In order for this to work reliably, the cooperating primary and secondary servers must maintain a consistent database of the lease information. [RFC3315] allows for but does not define any redundancy or failover mechanisms. This document outlines requirements for DHCPv6 failover, enumerates related problems, and discusses the proposed scope of work to be conducted. This document does not define a DHCPv6 failover protocol. "DHCPv4 over IPv6 Transport", Yong Cui, Peng Wu, Jianping Wu, Ted Lemon, 20-Mar-13, In IPv6 networks, there remains a need to provide IPv4 service for some residual devices. This document describes a mechanism for allocating IPv4 addresses to such devices, using DHCPv4 with an IPv6 transport. It is done by putting a special relay agent function (Client Relay Agent) on the client side, as well as extending the behavior of the server; in the case where DHCP server only supports IPv4 transport, a relay agent is extended to support IPv6 transport (IPv6-Transport Relay Agent) and relay DHCP traffic for the server, with a new Relay Agent Information sub-option added to carry the IPv6 address of the Client Relay Agent. "RADIUS Option for DHCPv6 Relay Agent", leaf.yeh.sdo@gmail.com, Mohamed Boucadair, 20-May-13, The DHCPv6 RADIUS option provides a mechanism to exchange authorization and identification information between the DHCPv6 relay agent and the DHCPv6 server. This mechanism is meant for the centralized DHCPv6 server to select the right configuration for the requesting DHCPv6 client based on the authorization information received from the RADIUS server, which is not co-located with the DHCPv6 server. The Network Access Server (NAS) acts as DHCPv6 relay agent and RADIUS client simultaneously in this document. "Issues with multiple stateful DHCPv6 options", Ole Troan, Bernie Volz, 13-May-13, Dynamic Host Configuration Protocol for IPv6 (DHCPv6) was not written with the expectation that additional stateful DHCPv6 options would be developed. IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6 shoe-horned the new options for Prefix Delegation into DHCPv6. Implementation experience of the CPE model described in [RFC6204] has shown multiple issues with the DHCPv6 protocol in supporting multiple stateful options. "A Generic IPv6 Addresses Registration Solution Using DHCPv6", Sheng Jiang, Gang Chen, Suresh Krishnan, 25-Feb-13, In networks that are centrally managed, self-generated addresses cause traceability issues due to their decentralized nature. To minimize the issues due to lack of traceability, these self-generated addresses can be registered with the network for allowing centralized address administration. This document defines a generic address registration solution using DHCPv6, using a new ND option and a new DHCPv6 option in order to communicate the use of self-generated addresses. A new Addr-registration-request message type is defined for initiate the address registration request, among with two new Status codes to indicate registration errors on the server side. "Prefix Pool Option for DHCPv6 Relay Agent on the Provider Edge Routers", leaf.yeh.sdo@gmail.com, Ted Lemon, Mohamed Boucadair, 25-Apr-13, 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 through adding or removing aggregation routes according to the status of the prefix pools. The advertising of the aggregation 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 ISP network. "Reconfigure Triggered by DHCPv6 Relay Agents", Mohamed Boucadair, Xavier Pougnard, 15-May-13, This document defines new DHCPv6 messages: Reconfigure-Request and Reconfigure-Reply. Reconfigure-Request message is sent by a DHCPv6 relay agent to notify a DHCPv6 server about a configuration information change, so that the DHCPv6 server can send a Reconfigure message accordingly. Reconfigure-Reply message is used by the server to acknowledge the receipt of Reconfigure-Request. "Modification to Default Value of SOL_MAX_RT", Ralph Droms, 13-Dec-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. "DHC Load Balancing Algorithm for DHCPv6", Andre Kostur, 14-Dec-12, This document proposes a method of algorithmic load balancing for IPv6 Dynamic Host Configuration Protocol (DHCPv6) traffic. It enables multiple, cooperating servers to decide which one should service a client, without exchanging any information beyond initial configuration. The server selection is based on the servers hashing client DHCP Unique Identifiers (DUIDs) when multiple DHCPv6 (DHCPv6) servers are available to service DHCPv6 clients. The proposed technique provides for efficient server selection when multiple DHCPv6 servers offer services on a network without requiring any changes to existing DHCPv6 clients. The same method is proposed to select the target server of a DHCPv6 relay. "Populating the DNS Reverse Tree for DHCP Delegated Prefixes", Ted Lemon, 11-Mar-13, This document describes three alternatives for populating the DNS reverse tree for prefixes delegated using DHCP, and provides mechanisms for implementing each alternative. "Customizing DHCP Configuration on the Basis of Network Topology", Ted Lemon, 13-Apr-13, DHCP servers have evolved over the years to provide significant functionality beyond that which is described in the DHCP base specifications. One aspect of this functionality is support for context-specific configuration information. This memo describes some such features and makes recommendations as to how they can be used. "Handling Unknown DHCPv6 Messages", Yong Cui, Qi Sun, Ted Lemon, 23-Apr-13, Dynamic Host Configuration Protocol version 6 (DHCPv6) isn't specific about handling messages with unknown types. This document describes the problems and defines how a DHCPv6 function node should behave in this case. This document updates RFC3315. "DHCPv4 over DHCPv6 Transport", Qi Sun, Yong Cui, Marcin Siodelski, Suresh Krishnan, Ian Farrer, 26-Apr-13, This document describes a mechanism for obtaining IPv4 address and other parameters in IPv6 networks by carrying DHCPv4 messages over DHCPv6 transport. "Provisioning IPv4 Configuration Over IPv6 Only Networks", Branimir Rajtar, Ian Farrer, 13-May-13, As IPv6 becomes more widely adopted, some service providers are taking the approach of deploying IPv6 only networks, without dual- stack functionality for IPv4. However, access to IPv4 based services is still an ongoing requirement and approaches such as IPv4-in-IPv6 softwire tunnels are being developed to meet this need. In order to provision end-user's hosts with the necessary IPv4 configuration, a number of different mechanisms have been proposed. This memo discusses the benefits and drawbacks of each, with the aim of recommending a single approach as the basis for future work. "Access-Network-Identifier Option in DHCP", Cisco Systems, Sri Gundavelli, Jouni Korhonen, Mark Grayson, 14-May-13, This document specifies the format and mechanism that is to be used for encoding access network identifiers in DHCPv4 and DHCPv6 messages by defining new access network identifier options and sub-options. Diameter Maintenance and Extensions (dime) ------------------------------------------ "Realm-Based Redirection In Diameter", Tina Tsou, Ruibing Hao, Tom Taylor, 29-Apr-13, The Diameter protocol 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. This memo updates Sections 6.13 and 6.14 of RFC6733 with respect to the usage of the Redirect-Host-Usage and Redirect-Max-Cache-Time AVPs. "Diameter Support for Proxy Mobile IPv6 Localized Routing", Glen Zorn, Wenson Wu, Jouni Korhonen, 1-Aug-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 a Proxy Mobile IPv6 deployment, it may be desirable to control the establishment of localized routing sessions between two MAGs in a Proxy Mobile IPv6 domain by requiring that the session be authorized. This document specifies how to accomplish this using the Diameter protocol. "Diameter Network Access Server Application", Glen Zorn, 13-May-13, 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. "Diameter Overload Control Requirements", Eric McMurry, Ben Campbell, 20-Apr-13, When a Diameter server or agent becomes overloaded, it needs to be able to gracefully reduce its load, typically by informing clients to reduce sending traffic for some period of time. Otherwise, it must continue to expend resources parsing and responding to Diameter messages, possibly resulting in congestion collapse. The existing Diameter mechanisms, listed in Section 3 are not sufficient for this purpose. This document describes the limitations of the existing mechanisms in Section 4. Requirements for new overload management mechanisms are provided in Section 7. Distributed Mobility Management (dmm) ------------------------------------- "Requirements for Distributed Mobility Management", Anthony Chan, Dapeng Liu, Pierrick Seite, Hidetoshi Yokota, Jouni Korhonen, 7-May-13, This document defines the requirements for Distributed Mobility Management (DMM) in IPv6 deployments. The hierarchical structure in traditional wireless networks has led to deployment models which are in practice centralized. Mobility management with logically centralized mobility anchoring in current mobile networks is prone to suboptimal routing and raises scalability issues. Such centralized functions can lead to single points of failure and inevitably introduce longer delays and higher signaling loads for network operations related to mobility management. The objective is to enhance mobility management in order to meet the primary goals in network evolution, i.e., improve scalability, avoid single points of failure, enable transparent mobility support to upper layers only when needed, and so on. Distributed mobility management must be secure and may co-exist with existing network deployments and end hosts. "Distributed Mobility Management: Current practices and gap analysis", Dapeng Liu, Juan Zuniga, Pierrick Seite, Anthony Chan, Carlos Bernardos, 11-Feb-13, This document discusses how to best deploy the current IP mobility protocols in distributed mobility management (DMM) scenarios and analyzes the gaps of such best current practices against the DMM requirements. These best current practices are achieved by redistributing the existing MIPv6 and PMIPv6 functions in the DMM scenarios. The analyses is also applied to the real world deployment of IP mobility in WiFi network and in cellular network. DNS Extensions (dnsext) ----------------------- "Signaling Cryptographic Algorithm Understanding in DNSSEC", Steve Crocker, Scott Rose, 8-Apr-13, 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 digital signature and hash algorithms they support. The proposed extensions allow the signaling of new algorithm uptake in client code to allow zone administrators to know when it is possible to complete an algorithm rollover in a DNSSEC signed zone. Data for Reachability of Inter/tra-NetworK SIP (drinks) ------------------------------------------------------- "Session Peering Provisioning Framework (SPPF)", Kenneth Cartwright, Vikas Bhatia, Syed Ali, David Schwartz, 25-Feb-13, 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 establishment. Emergency Context Resolution with Internet Technologies (ecrit) --------------------------------------------------------------- "Additional Data related to an Emergency Call", Brian Rosen, Hannes Tschofenig, Roger Marshall, Randy, 5-May-13, When an emergency call is sent to a Public Safety Answering Point (PSAP), the device that sends it, as well as any application service provider in the path of the call, or access network provider through which the call originated may have information about the call or the caller which the PSAP may be able to use. This document describes data structures to convey such data to the PSAP. In addition, data may also be included by reference, via a Uniform Resource Identifier (URI) pointing to data found at an external resource. Consequently, this document follows the tradition of prior emergency services standardization work where data can be conveyed by value within the call signaling (i.e., in body of the SIP message) and also by reference. "Data-Only Emergency Calls", Brian Rosen, Henning Schulzrinne, Hannes Tschofenig, 25-Feb-13, RFC 6443 'Framework for Emergency Calling Using Internet Multimedia' describes how devices use the Internet to place emergency calls and how Public Safety Answering Points (PSAPs) can handle Internet multimedia emergency calls natively. The exchange of multimedia traffic typically involves a SIP session establishment starting with a SIP INVITE that negotiates various parameters for that session. In some cases, however, the transmission of application data is everything that is needed. Examples of such environments include a temperature sensors issuing alerts, or vehicles sending crash data. Often these alerts are conveyed as one-shot data transmissions. These type of interactions are called 'data-only emergency calls'. This document describes a container for the data based on the Common Alerting Protocol (CAP) and its transmission using the SIP MESSAGE transaction. "Public Safety Answering Point (PSAP) Callback", Henning Schulzrinne, Hannes Tschofenig, Christer Holmberg, Milan Patel, 19-Mar-13, 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 specification already offers a solution approach for allowing PSAP callbacks to bypass authorization policies to reach the caller without unnecessary delays. Unfortunately, the specified mechanism only supports limited scenarios. This document discusses shortcomings of the current mechanisms and illustrates additional scenarios where better-than- normal call treatment behavior would be desirable. A solution based on a new header field value, called "psap-callback", for the SIP Priority header field is specified to accomplish the PSAP callback marking. "Trustworthy Location", Hannes Tschofenig, Henning Schulzrinne, Bernard Aboba, 13-Mar-13, For some location-based applications, such as emergency calling or roadside assistance, the trustworthiness of location information is critically important. This document describes how to convey location in a manner that is inherently secure and reliable. It also provides guidelines for assessing the trustworthiness of location information. "Extensions to the Emergency Services Architecture for dealing with Unauthenticated and Unauthorized Devices", Henning Schulzrinne, Stephen McCann, Gabor Bajko, Hannes Tschofenig, Dirk Kroeselberg, 30-Apr-13, The IETF emergency services architecture assumes that the calling device has acquired rights to use the access network or that no authentication is required for the access network, such as for public wireless access points. Subsequent protocol interactions, such as obtaining location information, learning the address of the Public Safety Answering Point (PSAP) and the emergency call itself are largely decoupled from the underlying network access procedures. In some cases, however, the device does not have these credentials for network access, does not have a VoIP service provider, or the credentials have become invalid, e.g., because the user has exhausted their prepaid balance or the account has expired. This document provides a problem statement, introduces terminology and describes an extension for the base IETF emergency services architecture to address these scenarios. "Policy for defining new service-identifying lables", Andrea Forte, Henning Schulzrinne, 17-Dec-12, In order to provide location-based services, descriptive terms for services need to be defined. This document updates the policy for defining new service-identifying labels. "URN For Country Specific Emergency Services", Christer Holmberg, Ivo Sedlacek, 29-Apr-13, This document updates section 4.2 of RFC 5031, in order to allow the registration of service URNs with the 'sos' service type for emergency services that, at the time of registration, are offered in one country only. Energy Management (eman) ------------------------ "Requirements for Energy Management", Juergen Quittek, Mouli Chandramouli, Rolf Winter, Thomas Dietz, Benoit Claise, 2-May-13, This document defines requirements for standards specifications for energy management. The requirements defined in this document concern monitoring functions as well as control functions. Monitoring functions include identification of energy-managed devices and their components, monitoring of their power states, power inlets, power outlets, actual power (the instantaneous power, as opposed to the demand, which is an averaged power), power attributes, received energy, provided energy, and contained batteries. Control functions serve for controlling power supply and power state of energy-managed devices and their components. 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, Brad Schoening, Juergen Quittek, Bruce Nordman, 25-Feb-13, This document defines a framework for providing Energy Management for devices and device components 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 Attributes, and Battery. Additionally the framework models relationships and capabilities between Energy Objects. "Energy Object Context MIB", John Parello, Benoit Claise, Mouli Chandramouli, 19-Apr-13, 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, 25-Feb-13, This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines managed objects that provide information on the status of batteries in managed devices. "Power and Energy Monitoring MIB", Mouli Chandramouli, Brad Schoening, Juergen Quittek, Thomas Dietz, Benoit Claise, 22-Apr-13, This document defines a subset of the Management Information Base (MIB) for power and energy monitoring of devices. "Energy Management (EMAN) Applicability Statement", Brad Schoening, Mouli Chandramouli, Bruce Nordman, 18-Apr-13, 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 to 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 and MIBs. Further, we describe the relationship of the EMAN framework to relevant other energy monitoring standards and architectures. "Entity MIB (Version 4)", Andy Bierman, Dan Romascanu, Juergen Quittek, Mouli Chandramouli, 12-Feb-13, 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 used for managing multiple logical and physical entities managed by a single SNMP agent. This document specifies version 4 of the Entity MIB. This memo obsoletes version 3 of Entity MIB module published as RFC 4133. EAP Method Update (emu) ----------------------- "Tunnel EAP Method (TEAP) Version 1", Hao Zhou, Nancy Cam-Winget, Joseph Salowey, Stephen Hanna, 22-Mar-13, This document defines the Tunnel Extensible Authentication Protocol (TEAP) 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. "EAP Mutual Cryptographic Binding", Sam Hartman, Margaret Wasserman, Dacheng Zhang, 14-Mar-13, As the Extensible Authentication Protocol (EAP) evolves, EAP peers rely increasingly on information received from the EAP server. EAP extensions such as channel binding or network posture information are often carried in tunnel methods; peers are likely to rely on this information. [RFC 3748] is a facility that protects tunnel methods against man-in-the-middle attacks. However, cryptographic binding focuses on protecting the server rather than the peer. This memo explores attacks possible when the peer is not protected from man-in- the-middle attacks and recommends mutual cryptographic binding, a new form of cryptographic binding that protects both peer and server along with other mitigations. Forwarding and Control Element Separation (forces) -------------------------------------------------- "ForCES Logical Function Block (LFB) Library", Weiming Wang, Evangelos Haleplidis, Kentaro Ogawa, Chuanhuang Li, Joel Halpern, 28-Mar-13, 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 Hadi Salim, 8-May-13, This document discusses Control Element High Availability within a ForCES Network Element. "Interoperability Report for Forwarding and Control Element Separation (ForCES)", Weiming Wang, Kentaro Ogawa, Evangelos Haleplidis, Ming Gao, Jamal Hadi Salim, 23-May-13, This document captured results of 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. RFC 6053 has reported the results of the first ForCES interoperability test, and this document updates RFC 6053 by providing further interoperability results. General Area (gen) ------------------ "Experiences from Cross-Area Work at the IETF", Jari Arkko, 6-Feb-13, 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. "IMAP Access to IETF Email List Archives", Robert Sparks, 7-May-13, 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, and it is intended as input to a later activity for the design and development of such a service. "The Internet Numbers Registry System", Russ Housley, John Curran, Geoff Huston, David Conrad, 7-Apr-13, This document provides information about the current Internet Numbers Registry System used in the distribution of globally unique Internet Protocol (IP) address space and autonomous system (AS) numbers. This document also provides information about the processes for further evolution of the Internet Numbers Registry System. This document replaces RFC 2050. This document does not propose any changes to the Internet Numbers Registry System. Geographic Location/Privacy (geopriv) ------------------------------------- "Dynamic Host Configuration Protocol (DHCP) IPv4 and IPv6 Option for a Location Uniform Resource Identifier (URI)", James Polk, 24-Feb-13, 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, but only while valid. "Using Device-provided Location-Related Measurements in Location Configuration Protocols", Martin Thomson, James Winterbottom, 10-Apr-13, A method is described by which a Device is able to provide location- related measurement data to a LIS within a request for location information. Location-related measurement information are observations concerning properties related to the position of a Device, which could be data about network attachment or about the physical environment. When a LIS generates location information for a Device, information from the Device can improve the accuracy of the location estimate. A basic set of location-related measurements are defined, including common modes of network attachment as well as assisted Global Navigation Satellite System (GNSS) parameters. "Relative Location Representation", Martin Thomson, Brian Rosen, Dorothy Stanley, Gabor Bajko, Allan Thomson, 19-Mar-13, This document defines an extension to PIDF-LO (RFC4119) for the expression of location information that is defined relative to a reference point. The reference point may be expressed as a geodetic or civic location, and the relative offset may be one of several shapes. Optionally, a reference to a secondary document (such as a map image) can be included, along with the relationship of the map coordinate system to the reference/offset coordinate system to allow display of the map with the reference point and the relative offset. Also included in this document is a Type/Length/Value (TLV) representation of the relative location for use in other protocols that use TLVs. "Location Configuration Extensions for Policy Management", Richard Barnes, Martin Thomson, James Winterbottom, Hannes Tschofenig, 4-Oct-12, 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, 5-Apr-13, 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. Global Routing Operations (grow) -------------------------------- "Operational Requirements for Enhanced Error Handling Behaviour in BGP-4", Rob Shakir, 27-Dec-12, BGP 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 within service provider networks, and outlines a set of requirements for further work to enhance the mechanisms available to a BGP 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 to improve the protocol's robustness to suit its current deployment. "IRR & Routing Policy Configuration Considerations", Danny McPherson, Shane Amante, Eric Osterweil, Larry Blunk, Dave Mitchell, 10-May-13, The purpose of this document is to catalog past issues influencing the efficacy of Internet Routing Registries (IRR) for inter-domain routing policy specification and application in the global routing system over the past two decades. Additionally, it provides a discussion regarding which of these issues are still problematic in practice, and which are simply artifacts that are no longer applicable but continue to stifle inter-provider policy-based filtering adoption and IRR utility to this day. "Route Leaks & MITM Attacks Against BGPSEC", Danny McPherson, Shane Amante, Eric Osterweil, Dave Mitchell, 10-May-13, 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. Host Identity Protocol (hip) ---------------------------- "Host Identity Protocol-Based Overlay Networking Environment (HIP BONE) Instance Specification for REsource LOcation And Discovery (RELOAD)", Ari Keränen, Gonzalo Camarillo, Jouni Maenpaa, 6-May-13, 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. "An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2)", Julien Laganier, Francis Dupont, 6-May-13, This document specifies an updated Overlay Routable Cryptographic Hash Identifiers format that obsoletes the earlier format defined in [RFC4843]. These identifiers are intended to be used as endpoint identifiers at applications and Application Programming Interfaces (API) and not as identifiers for network location at the IP layer, i.e., locators. They are designed to appear as application layer entities and at the existing IPv6 APIs, but they should not appear in actual IPv6 headers. To make them more like regular IPv6 addresses, they are expected to be routable at an overlay level. Consequently, while they are considered non-routable addresses from the IPv6 layer point-of-view, all existing IPv6 applications are expected to be able to use them in a manner compatible with current IPv6 addresses. The Overlay Routable Cryptographic Hash Identifiers originally defined in [RFC4843] lacked a mechanism for cryptographic algorithm agility. The updated ORCHID format specified in this document removes this limitation by encoding in the identifier itself an index to the suite of cryptographic algorithms in use. "Host Identity Protocol Version 2 (HIPv2)", Robert Moskowitz, Tobias Heer, Petri Jokela, Tom Henderson, 25-Feb-13, 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, 16-Jan-13, 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 Keränen, Jan Melen, 14-Dec-12, 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. "Host Multihoming with the Host Identity Protocol", Tom Henderson, Christian Vogt, Jari Arkko, 16-Jan-13, This document defines host multihoming extensions to the Host Identity Protocol (HIP), by leveraging protocol components defined for host mobility. "Host Identity Protocol Certificates", Tobias Heer, Samu Varjonen, 1-Apr-13, The CERT parameter is a container for digital certificates. It is used for carrying these certificates in Host Identity Protocol (HIP) control packets. This document specifies the certificate parameter and the error signaling in case of a failed verification. Additionally, this document specifies the representations of Host Identity Tags in X.509 version 3 (v3) and SPKI certificates. The concrete use of certificates including how certificates are obtained, requested, and which actions are taken upon successful or failed verification are specific to the scenario in which the certificates are used. Hence, the definition of these scenario- specific aspects are left to the documents that use the CERT parameter. This document updates RFC 5201. Home Networking (homenet) ------------------------- "Home Networking Architecture for IPv6", Tim Chown, Jari Arkko, Anders Brandt, Ole Troan, Jason Weil, 21-May-13, This text describes evolving networking technology within increasingly large residential home networks. The goal of this document is to define a general architecture for IPv6-based home networking, describing the associated principles, considerations and requirements. The text briefly highlights specific implications of the introduction of IPv6 for home networking, discusses the elements of the architecture, and suggests 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 Authentication (httpauth) ----------------------------------------------------- "An Encoding Parameter for HTTP Basic Authentication", Julian Reschke, 8-May-13, 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 the non-ASCII 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. "HTTP Origin-Bound Authentication (HOBA)", Stephen Farrell, Paul Hoffman, Michael Thomas, 14-May-13, HTTP Origin-Bound Authentication (HOBA) is a design for an HTTP authentication method with credentials that are not vulnerable to phishing attacks, and that does not require a server-side password database. The design can also be used in Javascript-based authentication embedded in HTML. HOBA is an alternative to HTTP authentication schemes that require passwords with all the negative attributes that come with password-based systems. HOBA can be integrated with account management and other applications running over HTTP and supports portability, so a user can associate more than one device or origin-bound key with the same service. We also describe a way in which the HOBA design can be used from a Javascript web client. When deployed, HOBA will be a drop-in replacement for password-based HTTP authentication or JavaScript authentication. "An Encoding Parameter for HTTP Basic Authentication", Julian Reschke, 16-May-13, 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 the non-ASCII 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. Hypertext Transfer Protocol Bis (httpbis) ----------------------------------------- "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", Roy Fielding, Julian Reschke, 23-Feb-13, 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 provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes general security concerns for implementations. "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", Roy Fielding, Julian Reschke, 23-Feb-13, The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation. "Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests", Roy Fielding, Julian Reschke, 23-Feb-13, The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP/1.1 conditional requests, including metadata header fields for indicating state changes, request header fields for making preconditions on such state, and rules for constructing the responses to a conditional request when one or more preconditions evaluate to false. "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", Roy Fielding, Yves Lafon, Julian Reschke, 23-Feb-13, The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines range requests and the rules for constructing and combining responses to those requests. "Hypertext Transfer Protocol (HTTP/1.1): Caching", Roy Fielding, Mark Nottingham, Julian Reschke, 23-Feb-13, The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages. "Hypertext Transfer Protocol (HTTP/1.1): Authentication", Roy Fielding, Julian Reschke, 23-Feb-13, The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. This document defines the HTTP Authentication framework. "Initial Hypertext Transfer Protocol (HTTP) Method Registrations", Julian Reschke, 23-Feb-13, 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, 23-Feb-13, 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. "Hypertext Transfer Protocol version 2.0", Mike Belshe, Roberto Peon, Martin Thomson, Alexey Melnikov, 3-Apr-13, This specification describes an optimised expression of the syntax of the Hypertext Transfer Protocol (HTTP). The HTTP/2.0 encapsulation enables more efficient transfer of representations by providing compressed header fields, simultaneous requests, and also introduces unsolicited push of representations from server to client. This document is an alternative to, but does not obsolete the HTTP message format. HTTP semantics remain unchanged. BiDirectional or Server-Initiated HTTP (hybi) --------------------------------------------- "A Multiplexing Extension for WebSockets", John Tamplin, Takeshi Yoshino, 15-May-13, 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. "Compression Extensions for WebSocket", Takeshi Yoshino, 25-Apr-13, This document specifies a framework for creating WebSocket extensions that add compression functionality to the WebSocket Protocol. An extension based on this framework compresses the payload data portion of non-control WebSocket messages on a per-message basis using parameters negotiated during the opening handshake. This framework provides a general method to apply a compression algorithm to the contents of WebSocket messages. For each compression algorithm, an extension is defined by specifying parameter negotiation and compression algorithm in detail. This document also specifies one specific compression extension using the DEFLATE algorithm. Please send feedback to the hybi@ietf.org mailing list. Inter-Domain Routing (idr) -------------------------- "Advertisement of Multiple Paths in BGP", Daniel Walton, Alvaro Retana, Enke Chen, John Scudder, 17-Dec-12, 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, 21-Jan-13, 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", Prodosh Mohapatra, Rex Fernando, Eric Rosen, James Uttaro, 23-May-13, Routing protocols that have been designed to run within a single administrative domain ("IGPs") generally do so by assigning a metric to each link, and then choosing as the installed path between two nodes the path for which the total distance (sum of the metric of each link along the path) is minimized. BGP, designed to provide routing over a large number of independent administrative domains ("autonomous systems"), does not make its path selection decisions through the use of a metric. It is generally recognized that any attempt to do so would incur significant scalability problems, as well as inter-administration coordination problems. However, there are deployments in which a single administration runs several contiguous BGP networks. In such cases, it can be desirable, within that single administrative domain, for BGP to select paths based on a metric, just as an IGP would do. The purpose of this document is to provide a specification for doing so. "BGP Bestpath Selection Criteria Enhancement", Rajiv Asati, 25-Feb-13, BGP specification [RFC4271] prescribes 'BGP next-hop reachability' as one of the key 'Route Resolvability Condition' that must be satisfied before the BGP bestpath candidate selection. This condition, however, may not be sufficient (as explained in the Appendix section) and desire further granularity. This document defines enhances the "Route Resolvability Condition" to facilitate the next-hop to be resolved in the chosen data plane. "Best Practices for Advertisement of Multiple Paths in IBGP", James Uttaro, Virginie Van den Schrieck, Pierre Francois, Roberto Fragassi, Adam Simpson, Pradosh Mohapatra, 26-Nov-12, 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", Bruno Decraene, Pierre Francois, 21-May-13, This document defines an IANA registry in order to assign non- transitive extended communities from. These are similar to the existing well-known BGP communities defined in RFC 1997 but provide a control over inter-AS community advertisement as, per RFC RFC 4360, they are not transitive across Autonomous System boundaries. For that purpose, this document defines the use of the reserved Autonomous System number 0.65535 in the non-transitive generic four- octet AS specific extended community type. "Enhanced Route Refresh Capability for BGP-4", Keyur Patel, Enke Chen, Balaji Venkatachalapathy, 17-Dec-12, 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. "BGP Optimal Route Reflection (BGP-ORR)", Robert Raszuk, Christian Cassar, Erik Aman, Bruno Decraene, Stephane Litkowski, 4-Dec-12, [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, David Ward, Randy Bush, 24-Dec-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 document updates [RFC4271] by providing 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, Martine Djernaes, Jie Dong, Mach Chen, 18-Dec-12, 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, 21-Nov-12, 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 a number of existing attributes. "BGP Custom Decision Process", Alvaro Retana, Russ White, 20-May-13, 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, 26-Aug-12, This document updates RFC 4271 and proscribes the use of Autonomous System (AS) 0 in the Border Gateway Protocol (BGP) OPEN and AS_PATH / AS4_PATH BGP attribute. "Accelerated Routing Convergence for BGP Graceful Restart", Keyur Patel, Enke Chen, Rex Fernando, John Scudder, 7-Dec-12, 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, Jeffrey Haas, 25-Apr-13, 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, 13-Mar-13, This document describes a simple procedure that allows "legacy" BGP speakers to exchange route target membership information in BGP without using mechanisms specified in [RFC4684]. The intention of the proposed technique is to help in partial deployment scenarios and is not meant to replace [RFC4684]. "Internet Exchange Route Server", Elisa Jasinska, Nick Hilliard, Robert Raszuk, Niels Bakker, 25-Feb-13, 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. "Making Route Flap Damping Usable", Cristel Pelsser, Randy Bush, Keyur Patel, Pradosh Mohapatra, Olaf Maennel, 11-Mar-13, 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. "Revised Validation Procedure for BGP Flow Specifications", James Uttaro, Clarence Filsfils, Pradosh Mohapatra, David Smith, 22-Jan-13, This document describes a modification to the validation procedure defined in RFC 5575 for the dissemination of BGP flow specifications. RFC 5575 requires that the originator of the flow specification matches the originator of the best-match unicast route for the destination prefix embedded in the flow specification. This allows only BGP speakers within the data forwarding path (such as autonomous system border routers) to originate BGP flow specifications. Though it is possible to disseminate such flow specifications directly from border routers, it may be operationally cumbersome in an autonomous system with a large number of border routers having complex BGP policies. The modification proposed herein enables flow specifications to be originated from a centralized BGP route controller. "North-Bound Distribution of Link-State and TE Information using BGP", Hannes Gredler, Jan Medved, Stefano Previdi, Adrian Farrel, Saikat Ray, 21-May-13, 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 IGP 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). "Autonomous System (AS) Reservation for Private Use", Jon Mitchell, 12-Apr-13, This document describes the reservation of Autonomous System numbers (ASNs) that are for Private Use only and MUST NOT be advertised to the Internet, known as Private Use ASNs. This document enlarges the total space available for Private Use ASNs by documenting the reservation of a second, larger range and updates RFC 1930 by replacing Section 10. "Inter-domain SLA Exchange", Shitanshu Shah, Keyur Patel, Sandeep Bajaj, Luis Tomotaki, Mohamed Boucadair, 3-Jan-13, Network administrators typically provision QoS policies for their application traffic (such as voice, video) based on SLAs negotiated with their providers, and translate those SLAs to vendor specific configuration language. Both learning of SLA, either thru SLA documents or via some other out-of-band method, and translating them to vendor specific configuration language is a complex, many times manual, process and prone to errors. This document proposes an in- band method of SLA signaling which can help to simplify some of the complexities. This document defines an operational transitive attribute to signal SLA details in-band, across administrative boundaries (considered as Autonomous Systems (AS)), and thus simplify/speed-up some of the complex tasks. Though the use-case with the proposed attribute is explicitly defined in this document, purpose of this attribute is not limited to this use-case only. INtermediary-safe SIP session ID (insipid) ------------------------------------------ "Requirements for an End-to-End Session Identification in IP-Based Multimedia Communication Networks", Paul Jones, Gonzalo Salgueiro, James Polk, Laura Liess, Hadriel Kaplan, 27-Feb-13, 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 across multiple SIP devices, hops, and administrative domains. "End-to-End Session Identification in IP-Based Multimedia Communication Networks", Paul Jones, Chris Pearce, James Polk, Gonzalo Salgueiro, 12-Mar-13, 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. Internet Area (int) ------------------- "Mesh Link Establishment", Richard Kelsey, 21-Feb-13, This document defines the mesh link establishment (MLE) protocol for establishing and configuring secure radio links in IEEE 802.15.4 radio mesh networks. MLE extends IEEE 802.15.4 for use in multihop mesh networks by adding three capabilities: 1) dynamically configuring and securing radio links, 2) enabling network-wide changes to radio parameters, and 3) detecting neighboring devices. MLE operates below the routing layer, insulating it from the details of configuring, securing, and maintaining individual radio links within a larger mesh network. Internet Area Working Group (intarea) ------------------------------------- "Analysis of Solution Candidates to Reveal a Host Identifier (HOST_ID) in Shared Address Deployments", Mohamed Boucadair, Joseph Touch, Pierre Levis, Reinaldo Penno, 24-Apr-13, This document is a collection of solutions to reveal a host identifier (denoted as HOST_ID) when a Carrier Grade NAT (CGN) or application proxies are involved in the path. This host identifier could be used by a remote server to sort out the packets by sending host. The host identifier must be unique to each host under the same shared IP address. This document analyzes a set of solution candidates to reveal a host identifier; no recommendation is sketched in the document. "Using the IPv6 Flow Label for Server Load Balancing", Brian Carpenter, Sheng Jiang, Willy Tarreau, 15-Jan-13, This document describes how the IPv6 flow label as currently specified can be used to enhance layer 3/4 load distribution and balancing for large server farms. IP Flow Information Export (ipfix) ---------------------------------- "Flow Selection Techniques", Salvatore D'Antonio, Tanja Zseby, Christian Henke, Lorenzo Peluso, 24-May-13, Intermediate Flow Selection Process is the process of selecting a subset of Flows from all observed Flows. The Intermediate Flow Selection Process may be located at an IPFIX Exporter, Collector, or within an IPFIX Mediator. It reduces the effort of post-processing Flow data and transferring Flow Records. This document describes motivations for using the Intermediate Flow Selection process and presents Intermediate Flow Selection techniques. It provides an information model for configuring Intermediate Flow Selection Process techniques and discusses what information about an Intermediate Flow Selection Process should be exported. "Flow Aggregation for the IP Flow Information Export (IPFIX) Protocol", Brian Trammell, Arno Wagner, Benoit Claise, 19-Nov-12, This document provides a common implementation-independent basis for the interoperable application of the IP Flow Information Export (IPFIX) Protocol to the handling of Aggregated Flows, which are IPFIX Flows representing packets from multiple Original Flows sharing some set of common properties. It does this through a detailed terminology and a descriptive Intermediate Aggregation Process architecture, including a specification of methods for Original Flow counting and counter distribution across intervals. "Guidelines for Authors and Reviewers of IPFIX Information Elements", Brian Trammell, Benoit Claise, 3-Oct-12, This document provides guidelines for how to write definitions of new Information Elements for the IP Flow Information Export (IPFIX) protocol. It provides instructions on using the proper conventions for Information Elements to be registered in the IANA IPFIX Information Element registry, and provides guidelines for expert reviewers to evaluate new registrations. "Specification of the IP Flow Information eXport (IPFIX) Protocol for the Exchange of Flow Information", Benoit Claise, Brian Trammell, 23-May-13, This document specifies the IP Flow Information Export (IPFIX) protocol that serves for transmitting Traffic Flow information over the network. In order to transmit Traffic Flow information from an Exporting Process to a 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. "Operation of the IP Flow Information Export (IPFIX) Protocol on IPFIX Mediators", Benoit Claise, Atsushi Kobayashi, Brian Trammell, 25-Feb-13, This document specifies the operation of the IP Flow Information Export (IPFIX) protocol specific to IPFIX Mediators, including Template and Observation Point management, timing considerations, and other Mediator-specific concerns. "Information Model for IP Flow Information eXport (IPFIX)", Benoit Claise, Brian Trammell, 12-Feb-13, This document defines the datatypes and management policy for the information model for the IP Flow Information eXport (IPFIX) protocol. This information model is maintained as the IANA IPFIX Information Element Registry, the initial contents of which were defined by RFC 5102. This information model 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. "Information Elements for Data Link Layer Traffic Measurement", Shingo Kashima, Atsushi Kobayashi, Paul Aitken, 22-Feb-13, 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. "Exporting MIB Variables using the IPFIX Protocol", Benoit Claise, Paul Aitken, Juergen Schoenwaelder, 25-Feb-13, This document specifies a way to complement IPFIX Flow Records with Management Information 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 Extended Field Specifiers, which may represent IPFIX Information Elements and Simple Network Management Protocol (SNMP) MIB Objects. IP Performance Metrics (ippm) ----------------------------- "Rate Measurement Test Protocol Problem Statement", Al Morton, 23-Apr-13, This memo presents an access rate-measurement problem statement for test protocols to measure IP Performance Metrics. The rate measurement scenario has wide-spread attention of Internet access subscribers and seemingly all industry players, including regulators. Key test protocol aspects require the ability to control packet size on the tested path and enable asymmetrical packet size testing in a controller-responder architecture. "Test Plan and Results for Advancing RFC 2680 on the Standards Track", Len Ciavattone, Ruediger Geib, Al Morton, Matthias Wieser, 17-Feb-13, 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. In this version, the results are presented in the R-tool output form. Beautification is future work. IP Security Maintenance and Extensions (ipsecme) ------------------------------------------------ "Auto Discovery VPN Problem Statement and Requirements", Stephen Hanna, Vishwas Manral, 22-Apr-13, This document describes the problem of enabling a large number of systems to communicate directly using IPsec to protect the traffic between them. It then expands on the requirements, for such a solution. Manual configuration of all possible tunnels is too cumbersome in many such cases. In other cases the IP address of endpoints change or the endpoints may be behind NAT gateways, making static configuration impossible. The Auto Discovery VPN solution will address these requirements. "A TCP transport for the Internet Key Exchange", Yoav Nir, 3-Dec-12, This document describes using TCP for IKE messages. This facilitates the transport of large messages over paths where fragments are either dropped, or where packet loss makes the use of large UDP packets unreliable. "Additional Diffie-Hellman Tests for IKEv2", Yaron Sheffer, Scott Fluhrer, 4-May-13, This document adds a small number of mandatory tests required for the secure operation of IKEv2 with elliptic curve groups. No change is required to IKE implementations that use modular exponential groups, other than a few rarely used so-called DSA groups. This document updates the IKEv2 protocol, RFC 5996. "Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)", David McGrew, Wajdi Feghali, 12-Mar-13, This Internet Draft is standards track proposal to update to the Cryptographic Algorithm Implementation Requirements for ESP and AH; it also adds usage guidance to help in the selection of these algorithms. The Encapsulating Security Payload (ESP) and Authentication Header (AH) protocols makes use of various cryptographic algorithms to provide confidentiality and/or data origin authentication to protected data communications in the IP Security (IPsec) architecture. To ensure interoperability between disparate implementations, the IPsec standard specifies a set of mandatory-to- implement algorithms. This document specifies the current set of mandatory-to-implement algorithms for ESP and AH, specifies algorithms that should be implemented because they may be promoted to mandatory at some future time, and also recommends against the implementation of some obsolete algorithms. Usage guidance is also provided to help the user of ESP and AH best achieve their security goals through appropriate choices of cryptographic algorithms. "More Raw Public Keys for IKEv2", Tero Kivinen, Paul Wouters, Hannes Tschofenig, 8-Apr-13, The Internet Key Exchange Version 2 (IKEv2) protocol currently only supports raw RSA keys. In some environments it is useful to make use of other types of public keys, such as those based on Elliptic Curve Cryptography. This documents adds support for other types of raw public keys to IKEv2 and obsoletes the old raw RSA key format. IS-IS for IP Internets (isis) ----------------------------- "IS-IS Operational Enhancements for Network Maintenance Events", Naiming Shen, Tony Li, Shane Amante, Mikael Abrahamsson, 14-Feb-13, This document describes an improved IS-IS neighbor management scheme which can be used to enhance operational experience in terms of convergence speed and finer control of neighbor cost over a LAN. "IS-IS Reverse Metric TLV for Network Maintenance Events", Naiming Shen, Tony Li, Shane Amante, Mikael Abrahamsson, 14-Feb-13, This document describes an improved IS-IS neighbor management scheme which can be used to enhance network performance by allowing operators to quickly and accurately shift traffic away from a point- to-point or multi-access LAN interface by allowing one IS-IS router to signal to a second, adjacent IS-IS neighbor to adjust its IS-IS metric that should be used to temporarily reach the first IS-IS router during network maintenance events. "Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS", Donald Eastlake, Tissa Senevirathne, Anoop Ghanwani, Dinesh Dutt, Ayan Banerjee, 9-Apr-13, 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 link technology, 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. JSON data formats for vCard and iCalendar (jcardcal) ---------------------------------------------------- "jCal: The JSON format for iCalendar", Philipp Kewisch, Cyrus Daboo, Mike Douglass, 30-Apr-13, This specification defines "jCal", a JSON format for iCalendar data. "jCard: The JSON format for vCard", Philipp Kewisch, 18-May-13, This specification defines "jCard", a JSON format for vCard data. Javascript Object Signing and Encryption (jose) ----------------------------------------------- "JSON Web Algorithms (JWA)", Michael Jones, 26-Apr-13, The JSON Web Algorithms (JWA) specification enumerates cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications. "JSON Web Encryption (JWE)", Michael Jones, Eric Rescorla, Joe Hildebrand, 26-Apr-13, JSON Web Encryption (JWE) is a means of representing encrypted content using JavaScript Object Notation (JSON) data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification. Related digital signature and MAC capabilities are described in the separate JSON Web Signature (JWS) specification. "JSON Web Key (JWK)", Michael Jones, 26-Apr-13, A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JSON Web Key Set (JWK Set) JSON data structure for representing a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification. "JSON Web Signature (JWS)", Michael Jones, John Bradley, Nat Sakimura, 26-Apr-13, JSON Web Signature (JWS) is a means of representing content secured with digital signatures or Message Authentication Codes (MACs) using JavaScript Object Notation (JSON) data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification. "Use Cases and Requirements for JSON Object Signing and Encryption (JOSE)", Richard Barnes, 20-Mar-13, Many Internet applications have a need for object-based security mechanisms in addition to security mechanisms at the network layer or transport layer. In the past, the Cryptographic Message Syntax has provided a binary secure object format based on ASN.1. Over time, the use of binary object encodings such as ASN.1 has been overtaken by text-based encodings, for example JavaScript Object Notation. This document defines a set of use cases and requirements for a secure object format encoded using JavaScript Object Notation, drawn from a variety of application security mechanisms currently in development. Keying and Authentication for Routing Protocols (karp) ------------------------------------------------------ "Database of Long-Lived Symmetric Cryptographic Keys", Russ Housley, Tim Polk, Sam Hartman, Dacheng Zhang, 12-Mar-13, This document specifies the information contained in a conceptual database of long-lived cryptographic keys used by many different security protocols. The database is designed to support both manual and automated key management. In addition to describing the schema for the database, this document describes the operations that can be performed on the database as well as the requirements for the security protocols that wish to use the database. In many typical scenarios, 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", Sam Hartman, Dacheng Zhang, 20-May-13, 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. "Analysis of BGP, LDP, PCEP and MSDP Issues According to KARP Design Guide", Mahesh Jethanandani, Keyur Patel, Lianshu Zheng, 8-Apr-13, This document analyzes TCP based routing protocols, Border Gateway Protocol (BGP), Label Distribution Protocol (LDP), Path Computation Element Communication Protocol (PCEP), and Multicast Source Distribution Protocol (MSDP) according to guidelines set forth in section 4.2 of Keying and Authentication for Routing Protocols Design Guidelines (RFC6518). "Analysis of Bidirectional Forwarding Detection (BFD) Security According to KARP Design Guide", Manav Bhatia, Dacheng Zhang, Mahesh Jethanandani, 11-Mar-13, This document analyzes the Bidirectional Forwarding Detection protocol (BFD) according to the guidelines set forth in section 4.2 of KARP Design Guidelines [RFC6518]. "KARP IS-IS security analysis", Uma Chunduri, Albert Tian, Wenhu Lu, 11-Mar-13, 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. Common Authentication Technology Next Generation (kitten) --------------------------------------------------------- "SAML Enhanced Client SASL and GSS-API Mechanisms", Scott Cantor, Simon Josefsson, 13-May-13, 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 set of SASL and GSS-API Mechanisms for OAuth", William Mills, Tim Showalter, Hannes Tschofenig, 24-Feb-13, 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 credentials obtained via 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. 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 Authorization Data Container Authenticated by Multiple MACs", Simo Sorce, Tom Yu, Thomas Hardjono, 25-Feb-13, Abstract: This document specifies a Kerberos Authorization Data container that supersedes AD-KDC-ISSUED. It allows for multiple Message Authentication Codes (MACs) or signatures to authenticate the contained Authorization Data elements. "Move Kerberos protocol parameter registries to IANA", Tom Yu, 25-Feb-13, The Keberos 5 network authentication protocol has several numeric protocol parameters. Most of these parameters are not currently under IANA maintenance. This document requests that IANA take over the maintenance of the remainder of these Kerberos parameters. "Initial and Pass Through Authentication Using Kerberos V5 and the GSS- API (IAKERB)", Jim Schaad, Larry Zhu, Jeffrey Altman, 10-Apr-13, This document defines extensions to the Kerberos protocol and the GSS-API Kerberos mechanism that enable a GSS-API Kerberos client to exchange messages with the KDC using the GSS-API acceptor as the proxy, by encapsulating the Kerberos messages inside GSS-API tokens. With these extensions a client can obtain Kerberos tickets for services where the KDC is not accessible to the client, but is accessible to the application server. "AES Encryption with HMAC-SHA2 for Kerberos 5", Kelley Burgin, Michael Peck, 19-Apr-13, This document specifies two encryption types and two corresponding checksum types for Kerberos 5. The new types use AES in CTS mode (CBC mode with ciphertext stealing) for confidentiality and HMAC with a SHA-2 hash for integrity. Layer 2 Virtual Private Networks (l2vpn) ---------------------------------------- "IP-Only LAN Service (IPLS)", Himanshu Shah, Eric Rosen, Francois Le Faucheur, Giles Heron, 10-Dec-12, A Virtual Private LAN Service (VPLS) [VPLS] is used to interconnect systems across a wide-area or metropolitan-area network, making it appear that they are on a private LAN. The systems which are interconnected may themselves be LAN switches. If, however, they are IP hosts or IP routers, certain simplifications to the operation of the VPLS are possible. We call this simplified type of VPLS an "IP-only LAN Service" (IPLS). In an IPLS, as in a VPLS, LAN interfaces are run in promiscuous mode, and frames are forwarded based on their destination MAC addresses. However, the maintenance of the MAC forwarding tables is done via signaling, rather than via the MAC address learning procedures specified in [IEEE 802.1D]. This draft specifies the protocol extensions and procedures for support of the IPLS service. "Multicast in VPLS", Rahul Aggarwal, Yakov Rekhter, Yuji Kamite, Luyuan Fang, 30-Jan-13, 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. "PIM Snooping over VPLS", Olivier Dornon, Jayant Kotalwar, Jeffrey Zhang, Venu Hemige, Ray Qiu, 15-Jan-13, In Virtual Private LAN Service (VPLS), as also in IEEE Bridged Networks, the switches simply flood multicast traffic on all ports in the LAN by default. IGMP Snooping is commonly deployed to ensure multicast traffic is not forwarded on ports without IGMP receivers. The procedures and recommendations for IGMP Snooping are defined in [IGMP-SNOOP]. But when any protocol other than IGMP is used, the common practice is to simply flood multicast traffic to all ports. PIM-SM, PIM-SSM, PIM-BIDIR are widely deployed routing protocols. PIM Snooping procedures are important to restrict multicast traffic to only the routers interested in receiving such traffic. While most of the PIM Snooping procedures defined here also apply to IEEE Bridged Networks, VPLS demands certain special procedures due to the split-horizon rules that require the Provider Edge (PE) devices to co-operate. This document describes the procedures and recommendations for PIM-Snooping in VPLS to facilitate replication to only those ports behind which there are interested PIM routers and/or IGMP hosts. This document also describes procedures for PIM Proxy. PIM Proxy is required on PEs for VPLS Multicast to work correctly when Join suppression is enabled in the VPLS. PIM Proxy also helps scale VPLS Multicast much better than just PIM Snooping. "Virtual Private Lan Services (VPLS) Management Information Base", Thomas Nadeau, Kiran Koushik, Rohit Mediratta, 22-May-13, 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 Pseudowire (PW) Management Information Base [RFC5601]. "LDP Extensions for Optimized MAC Address Withdrawal in H-VPLS", Pranjal Dutta, Florin Balus, Olen Stokes, Geraldine Calvignac, 25-Feb-13, [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 [I-D.ietf-l2vpn-pbb-vpls-pe-model] . "Extensions to VPLS PE model for Provider Backbone Bridging", Florin Balus, Ali Sajassi, Nabil Bitar, 22-Oct-12, 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. "BGP based Multi-homing in Virtual Private LAN Service", Bhupesh Kothari, Kireeti Kompella, Wim Henderickx, Florin Balus, James Uttaro, Senad Palislamovic, Wen Lin, 25-Feb-13, Virtual Private LAN Service (VPLS) is a Layer 2 Virtual Private Network (VPN) that gives its customers the appearance that their sites are connected via a Local Area Network (LAN). It is often required for the Service Provider (SP) to give the customer redundant connectivity to some sites, often called "multi-homing". This memo shows how BGP-based multi-homing can be offered in the context of LDP and BGP VPLS solutions. "MAC Flush Loop Detection in VPLS", Paul Kwok, Pranjal Dutta, 31-Mar-13, MAC Address Withdrawal is a mechanism described in [RFC4762] to remove or unlearn MAC addresses that have been dynamically learned in a VPLS instance, for faster convergence on topology change. Failure of mechanisms that control loop free connectivity among VPLS PE-rs nodes may cause MAC Address Withdrawal messages looping among those nodes, leading to Denial of Service (DoS) or complete failure of control plane in the PE-rs nodes. This document describes a mechanism to detect and prevent loops of MAC Address Withdrawal messages in a VPLS PE-rs node on such failures. "Extension to LDP-VPLS for Ethernet Broadcast and Multicast", Frederic JOUNAY, Yuji Kamite, Zhihua Liu, Manuel Paul, Ruediger Kunze, Mach Chen, Lizhong Jin, 22-Feb-13, 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 L2VPN", Simon DeLord, Frederic JOUNAY, Lu Huang, Zhihua Liu, Manuel Paul, Ruediger Kunze, Nick Regno, Joshua Rogers, 3-Apr-13, This document provides functional requirements for Metro Ethernet Forum (MEF) Ethernet Tree (E-Tree) support in multipoint L2VPN solutions (referred to as simply L2VPN). It is intended that potential solutions will use these requirements as guidelines. "A Framework for E-Tree Service over MPLS Network", Simon DeLord, Frederic JOUNAY, Lucy Yong, Lizhong Jin, Yuji Kamite, Wim Henderickx, 22-Feb-13, 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. "BGP MPLS Based Ethernet VPN", Ali Sajassi, Rahul Aggarwal, Wim Henderickx, Florin Balus, Aldrin Isaac, James Uttaro, 25-Feb-13, This document describes procedures for BGP MPLS based Ethernet VPNs (E-VPN). "PBB-EVPN", Ali Sajassi, Samer Salam, Sami Boutros, Nabil Bitar, Aldrin Isaac, Lizhong Jin, 25-Feb-13, 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 "Requirements for Ethernet VPN (E-VPN)", Ali Sajassi, Rahul Aggarwal, Nabil Bitar, Aldrin Isaac, 24-Feb-13, The widespread adoption of Ethernet L2VPN services and the advent of new applications for the technology (e.g., data center interconnect) have culminated in a new set of requirements that are not readily addressable by the current VPLS solution. In particular, multi-homing with all-active forwarding is not supported and there's no existing solution to leverage MP2MP LSPs for optimizing the delivery of multi- destination frames. Furthermore, the provisioning of VPLS, even in the context of BGP-based auto-discovery, requires network operators to specify various network parameters on top of the access configuration. This document specifies the requirements for an Ethernet VPN (E-VPN) solution which addresses the above issues. "VPLS PE Model for E-Tree Support", Yuanlong Jiang, Lucy Yong, Manuel Paul, Frederic JOUNAY, Florin Balus, Wim Henderickx, Ali Sajassi, 6-Feb-13, 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. Layer 3 Virtual Private Networks (l3vpn) ---------------------------------------- "BGP ACCEPT_OWN Community Attribute", James Uttaro, Pradosh Mohapatra, David Smith, Robert Raszuk, John Scudder, 21-Jan-13, 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. "MVPN: Using Bidirectional P-Tunnels", Eric Rosen, IJsbrand Wijnands, Yiqun Cai, Arjen Boers, 10-Apr-13, A set of prior RFCs specify procedures for supporting multicast in BGP/MPLS IP VPNs. These procedures allow customer multicast data to travel across a service provider's backbone network through a set of multicast tunnels. The tunnels are advertised in certain BGP "auto- discovery" routes, by means of a BGP attribute known as the "Provider Multicast Service Interface (PMSI) Tunnel attribute". Encodings have been defined that allow the PMSI Tunnel attribute to identify bidirectional (multipoint-to-multipoint) multicast distribution trees. However, the prior RFCs do not provide all the necessary procedures for using bidirectional tunnels to support multicast VPNs. This document updates RFCs 6513 and 6625 by specifying those procedures. In particular, it specifies the procedures for assigning customer multicast flows (unidirectional or bidirectional) to specific bidirectional tunnels in the provider backbone, for advertising such assignments, and for determining which flows have been assigned to which tunnels. "Virtual Hub-and-Spoke in BGP/MPLS VPNs", Huajin Jeng, James Uttaro, Luay Jalil, Bruno Decraene, Yakov Rekhter, Rahul Aggarwal, 19-Apr-13, With BGP/MPLS VPNs, providing 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. Furthermore, when Provider Edge routers use ingress replication to carry multicast traffic of VPN customers, the approach described in this document may under certain circumstances allow to reduce bandwidth inefficiency associated with ingress replication, and to redistribute the replication load among Provider Edge routers. "MPLS/BGP Layer 3 VPN Multicast Management Information Base", Saud Asif, Andy Green, Sameer Gulrajani, Pradeep Jain, Jeffrey Zhang, 25-Feb-13, 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 managed objects to configure and/or monitor multicast in MPLS/BGP-based Layer-3 VPN (MVPN) on an MVPN router. "BGP-signaled end-system IP/VPNs.", Pedro Marques, Luyuan Fang, Ping Pan, Amit Shukla, Maria Napierala, Nabil Bitar, 1-Apr-13, This document describes a solution in which the control plane protocol specified in BGP/MPLS IP VPNs [RFC4364] is used to provide a Virtual Network service to end-systems. These end-systems may be used to provide network services or may directly host end-to-end applications. "Encoding mLDP FECs in the NLRI of BGP MCAST-VPN Routes", IJsbrand Wijnands, Eric Rosen, Uwe Joorde, 15-May-13, 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. "Multipoint Label Distribution Protocol In-Band Signaling in a VRF Context", IJsbrand Wijnands, Paul Hitchen, Nicolai Leymann, Wim Henderickx, arkadiy.gulko@thomsonreuters.com, 20-Dec-12, 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. Other documents specify the procedures for building such a hybrid MDT, using Protocol Independent Multicast (PIM) 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 to handle the case where the link connecting the two regions is a "Virtual Routing and Forwarding Table" (VRF) link, as defined in the "BGP IP/MPLS VPN" specifications. However, this document is primarily aimed at particular use cases where VRFs are used to support multicast applications other than Multicast VPN. "Extranet Multicast in BGP/IP MPLS VPNs", Yakov Rekhter, Eric Rosen, Rahul Aggarwal, Yiqun Cai, Wim Henderickx, Thomas Morin, Praveen Muley, Ray Qiu, IJsbrand Wijnands, 8-Feb-13, Previous RFCs specify the procedures necessary to allow IP multicast traffic to travel from one site to another within a BGP/MPLS IP VPN (Virtual Private Network). However, it is sometimes desirable to allow multicast traffic whose source is in one VPN to be received by systems that are in another VPN. This is known as a "Multicast VPN (MVPN) extranet". This document updates RFCs 6513, 6514, and 6625 by specifying the procedures that are necessary in order to provide MVPN extranet service. Locator/ID Separation Protocol (lisp) ------------------------------------- "LISP MIB", Gregg Schudel, Amit Jain, Victor Moreno, 23-May-13, This document defines managed objects for the Locator/ID Separation Protocol (LISP). These objects provide information useful for monitoring LISP devices, including determining basic LISP configuration information, LISP functional status, and operational counters and other statistics. "LISP Network Element Deployment Considerations", Lorand Jakab, Albert Cabellos-Aparicio, Florin Coras, Jordi Domingo-Pascual, Darrel Lewis, 20-Mar-13, 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", Luigi Iannone, Darrel Lewis, David Meyer, Vince Fuller, 25-Feb-13, 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 for local intra-domain routing and global endpoint identification, by sites deploying LISP as EID (Endpoint IDentifier) addressing space. "LISP Threats Analysis", Damien Saucez, Luigi Iannone, Olivier Bonaventure, 25-Feb-13, This document analyzes the potential threats against the security of the Locator/Identifier Separation Protocol (LISP) if deployed in the Internet. This document proposes a set of recommendations to mitigate the identified security risks and keep a security level equivalent to what is observed in the Internet today (i.e., without LISP). By following the recommendations of this draft a LISP deployment can achieve a security level that is comparable to the existing Internet architecture. "LISP Canonical Address Format (LCAF)", Dino Farinacci, David Meyer, Job Snijders, 10-Mar-13, 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. "LISP Delegated Database Tree", Vince Fuller, Darrel Lewis, Vina Ermagan, Amit Jain, 28-Mar-13, 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 as "authoritative" for one or more EID-prefixes, along with the set of RLOCs for Map Servers or "child" DDT nodes to which more-specific EID-prefixes are delegated. "An Architectural Perspective on the LISP Location-Identity Separation System", J. Chiappa, 18-Feb-13, LISP upgrades the architecture of the IPvN internetworking system by separating location and identity, current intermingled in IPvN addresses. This is a change which has been identified by the IRTF as a critically necessary evolutionary architectural step for the Internet. In LISP, nodes have both a 'locator' (a name which says _where_ in the network's connectivity structure the node is) and an 'identifier' (a name which serves only to provide a persistent handle for the node). A node may have more than one locator, or its locator may change over time (e.g. if the node is mobile), but it keeps the same identifier. This document gives additional architectural insight into LISP, and considers a number of aspects of LISP from a high-level standpoint. [NOTE: This is still a somewhat rough draft version; a few sections at the end are just rough frameworks, but almost all the key sections, and all the front part of the document, are here, and in something like reasonably complete form.] Light-Weight Implementation Guidance (lwig) ------------------------------------------- "Guidance for Light-Weight Implementations of the Internet Protocol Suite", Carsten Bormann, 25-Feb-13, 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. "Terminology for Constrained Node Networks", Carsten Bormann, Mehmet Ersue, Ari Keränen, 22-Apr-13, The Internet Protocol Suite is increasingly used on small devices with severe constraints, creating constrained node networks. This document provides a number of basic terms that have turned out to be useful in the standardization work for constrained environments. "Minimal IKEv2", Tero Kivinen, 11-Apr-13, This document describes minimal version of the Internet Key Exchange version 2 (IKEv2) protocol. IKEv2 is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs). IKEv2 includes several optional features, which are not needed in minimal implementations. This document describes what is required from the minimal implementation, and also describes various optimizations which can be done. The protocol described here is compliant with full IKEv2 with exception that this document only describes shared secret authentication (IKEv2 requires support for certificate authentication in addition to shared secret authentication). This document does not update or modify RFC 5996, but provides more compact description of the minimal version of the protocol. If this document and RFC 5996 conflicts then RFC 5996 is the authoritative description. Mobile Ad-hoc Networks (manet) ------------------------------ "The Optimized Link State Routing Protocol version 2", Thomas Clausen, Christopher Dearlove, Philippe Jacquet, Ulrich Herberg, 23-Mar-13, This specification describes version 2 of the Optimized Link State Routing (OLSRv2) protocol for Mobile Ad hoc NETworks (MANETs). "Definition of Managed Objects for the Manet Simplified Multicast Framework Relay Set Process", Robert Cole, Joseph Macker, Brian Adamson, 21-Mar-13, 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 Optimized Link State Routing Protocol version 2", Ulrich Herberg, Robert Cole, Thomas Clausen, 9-May-13, This document defines the Management Information Base (MIB) module for configuring and managing the Optimized Link State Routing protocol version 2 (OLSRv2). The OLSRv2-MIB module is structured into state information, performance information, and notifications. This additional state and performance information is useful to troubleshoot problems and performance issues of the routing protocol. Different levels of compliance allow implementers to use smaller subsets of all defined objects, allowing for this MIB module to be deployed on more constrained routers. "Dynamic Link Exchange Protocol (DLEP)", Stan Ratliff, Cisco Cisco, Greg Harrison, Darryl Satterwhite, Shawn Jury, 25-Mar-13, 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. "Security Threats for NHDP", Ulrich Herberg, Jiazi Yi, Thomas Clausen, 10-Apr-13, This document analyses common security threats of the Neighborhood Discovery Protocol (NHDP), and describes their potential impacts on MANET routing protocols using NHDP. "Link Metrics for the Mobile Ad Hoc Network (MANET) Routing Protocol OLSRv2 - Rationale", Christopher Dearlove, Thomas Clausen, Philippe Jacquet, 1-May-13, OLSRv2 includes the ability to assign metrics to links and to use those metrics to allow routing by other than minimum hop count routes. This document provides a historic record of the rationale for, and design considerations behind, how link metrics were included in OLSRv2. "Dynamic MANET On-demand (AODVv2) Routing", Charles Perkins, Stan Ratliff, John Dowdell, 12-Mar-13, The revised Ad Hoc On-demand Distance Vector (AODVv2) routing protocol is intended for use by mobile routers in wireless, multihop networks. AODVv2 determines unicast routes among AODVv2 routers within the network in an on-demand fashion, offering on-demand convergence in dynamic topologies. "Integrity Protection for Control Messages in NHDP and OLSRv2", Ulrich Herberg, Christopher Dearlove, Thomas Clausen, 15-Apr-13, This document specifies integrity and replay protection for required implementation in the MANET Neighborhood Discovery Protocol (NHDP) and the Optimized Link State Routing Protocol version 2 (OLSRv2). This document specifies how an included integrity check value (ICV) and a timestamp TLV, defined in RFC6622bis, are used by NHDP and OLSRv2 for countering a number of security threats. The ICV TLV uses a SHA-256 based HMAC and one or more shared secret keys. The timestamp TLV is based on POSIX time, and assumes that the clocks in all routers in the network can be synchronized with sufficient precision. The mechanism in this specification can also be used for other MANET protocols using RFC5444. "Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs)", Ulrich Herberg, Thomas Clausen, Christopher Dearlove, 15-Apr-13, This document revises, extends and replaces RFC 6622. It describes general and flexible TLVs for representing cryptographic Integrity Check Values (ICVs) and timestamps, using the generalized Mobile Ad Hoc Network (MANET) packet/message format defined in RFC 5444. It defines two Packet TLVs, two Message TLVs, and two Address Block TLVs for affixing ICVs and timestamps to a packet, a message, and one or more addresses, respectively. MBONE Deployment (mboned) ------------------------- "Automatic Multicast Tunneling", Gregory Bumgardner, 12-Jun-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. "IPv6 Multicast Address With Embedded IPv4 Multicast Address", Mohamed Boucadair, Jacni Qin, Yiu Lee, Stig Venaas, Xing Li, Mingwei Xu, 18-Apr-13, This document reserves one bit (M-bit) of the unicast prefix-based multicast IPv6 address for ASM and an IPv6 multicast prefix for SSM mode to be used in the context of IPv4-IPv6 interconnection. The document specifies an algorithmic translation of an IPv6 multicast address to a corresponding IPv4 multicast address, and vice versa. This algorithmic translation can be used in both IPv4-IPv6 translation or encapsulation schemes. "IPv4-IPv6 Multicast: Problem Statement and Use Cases", Christian Jacquenet, Mohamed Boucadair, Yiu Lee, Jacni Qin, Tina Tsou, Qiong Sun, 13-Mar-13, 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. "Address Acquisition For Multicast Content When Source and Receiver Support Differing IP Versions", Tina Tsou, Axel Clauberg, Mohamed Boucadair, Stig Venaas, Qiong Sun, 3-Jan-13, Each IPTV operator has their own arrangements for pre-provisioning program information including addresses of the multicast groups corresponding to broadcast programs on the subscriber receiver. 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 what has to be done to allow the receiver to acquire multicast address information in the version it supports in such scenarios. "Multicast in the Data Center Overview", Mike McBride, 19-Feb-13, There has been much interest in issues surrounding massive amounts of hosts in the data center. These issues include the prevalent use of IP Multicast within the Data Center. Its important to understand how IP Multicast is being deployed in the Data Center to be able to understand the surrounding issues with doing so. This document provides a quick survey of uses of multicast in the data center and should serve as an aid to further discussion of issues related to large amounts of multicast in the data center. Media Server Control (mediactrl) -------------------------------- "Media Control Channel Framework (CFW) Call Flow Examples", Alessandro Amirante, Tobia Castaldi, Lorenzo Miniero, Simon Romano, 23-May-13, This document provides a list of typical Media Control Channel Framework call flows. It aims at being a simple guide to the use of the interface between Application Servers and MEDIACTRL-based Media Servers, as well as a base reference documentation for both implementors and protocol researchers. Multiple Interfaces (mif) ------------------------- "Happy Eyeballs Extension for Multiple Interfaces", Gang Chen, Carl Williams, Dan Wing, Andrew Yourtchenko, 25-Feb-13, Currently the interface selection in multi-interface environment is exclusive - only one interface can be used at the time, frequently needing manual intervention. Happy Eyeballs in MIF would make the selection process smoother by using the connectivity checks over a pre-filtered interfaces according to defined policy. This would choose "best" interface with an automatic fallback. Managed Incident Lightweight Exchange (mile) -------------------------------------------- "IODEF-extension to support structured cybersecurity information", Takeshi Takahashi, Kent Landfield, Tom Millar, Youki Kadobayashi, 12-Feb-13, This document extends the Incident Object Description Exchange Format (IODEF) defined in RFC 5070 [RFC5070] to exchange enriched cybersecurity information among cybersecurity entities and facilitate their operations. It provides the capability of embedding structured information, such as identifier- and XML-based information. "IODEF Usage Guidance", Panos Kampanakis, 29-Apr-13, The Incident Object Description Exchange Format [RFC5070] defines a data representation that provides a framework for sharing information commonly exchanged by Computer Security Incident Response Teams (CSIRTs) about computer security incidents. Since the IODEF model includes a wealth of available options that can be used to describe a security incident or issue, it can be challenging for implementers to develop tools that can Leverage IODEF for incident sharing. This document provides guidelines for IODEF users and implementers. It will also address how common security indicators can be represented in IODEF. The goal of this document is to make IODEF's adoption by vendors easier and encourage faster and wider adoption of the model by Computer Security Incident Response Teams (CSIRTs) around the world. "The Incident Object Description Exchange Format", Roman Danyliw, Paul Stoecker, 5-May-13, The Incident Object Description Exchange Format (IODEF) defines a data representation that provides a framework for sharing information commonly exchanged by Computer Security Incident Response Teams (CSIRTs) about computer security incidents. This document describes the information model for the IODEF and provides an associated data model specified with XML Schema. Mobility for IPv4 (mip4) ------------------------ "Flow Binding Support for Mobile IPv4", Sri Gundavelli, Kent Leung, George Tsirtsis, Hesham Soliman, Alexandru Petrescu, 31-Jan-13, 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 IP: Performance, Signaling and Handoff Optimization (mipshop) -------------------------------------------------------------------------- "Prefix Management for Mobile IPv6 Fast Handover on Point-to-Point Links", Frank Xia, Behcet Sarikaya, 21-Dec-12, 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, 4-Apr-13, This memorandum defines RTSP version 2.0 which obsoletes RTSP version 1.0 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, 2-May-13, 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. "The Evaluation of Different Network Address Translator (NAT) Traversal Techniques for Media Controlled by Real-time Streaming Protocol (RTSP)", Magnus Westerlund, Thomas Zeng, 23-May-13, This document describes several Network Address Translator (NAT) traversal techniques that were considered to be used for establishing the RTP media flows controlled by the 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 discussions 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. "SDP: Session Description Protocol", Mark Handley, Van Jacobson, Colin Perkins, Ali Begen, 11-Mar-13, 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. This document obsoletes RFC 4566. "Analysis of Middlebox Interactions for Signaling Protocol Communication along the Media Path", Brian Stucker, Hannes Tschofenig, Gonzalo Salgueiro, 10-Jan-13, 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, 24-Apr-13, 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). "Stream Control Transmission Protocol (SCTP)-Based Media Transport in the Session Description Protocol (SDP)", Salvatore Loreto, Gonzalo Camarillo, 21-Jan-13, SCTP (Stream Control Transmission Protocol) is a transport protocol used to establish associations between two endpoints. This document describes how to express media transport over SCTP in SDP (Session Description Protocol). This document defines the 'SCTP', 'SCTP/DTLS' and 'DTLS/SCTP' protocol identifiers for SDP. "The Session Description Protocol (SDP) 'trafficclass' Attribute", James Polk, Subha Dhesikan, Paul Jones, 18-Feb-13, This document proposes a new Session Description Protocol (SDP) attribute to identify the traffic class a session is requesting in its offer/answer exchange. "Multiplexing Negotiation Using Session Description Protocol (SDP) Port Numbers", Christer Holmberg, Harald Alvestrand, Cullen Jennings, 18-Feb-13, This specification defines a new 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). "Miscellaneous Capabilities Negotiation in the Session Description Protocol (SDP)", Miguel Garcia, Simo Veikkolainen, Robert Gilman, 3-May-13, SDP has been extended with a capability negotiation mechanism framework that allows the endpoints to negotiate transport protocols and attributes. This framework has been extended with a media capabilities negotiation mechanism that allows endpoints to negotiate additional media-related capabilities. This negotiation is embedded into the widely-used SDP offer/answer procedures. This memo extends the SDP capability negotiation framework to allow endpoints to negotiate three additional SDP capabilities. In particular, this memo provides a mechanism to negotiate bandwidth ('b=' line), connection data ('c=' line), and titles ('i=' line for each session or media). "Delayed Duplication Attribute in the Session Description Protocol", Ali Begen, Yiqun Cai, Heidi Ou, 19-Mar-13, 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. "Duplication Grouping Semantics in the Session Description Protocol", Ali Begen, Yiqun Cai, Heidi Ou, 19-Mar-13, Packet loss is undesirable for real-time multimedia sessions, but can occur due to congestion, or other unplanned network outages. This is especially true for IP multicast networks, where packet loss patterns can vary greatly between receivers. One technique that can be used 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. "Latching: Hosted NAT Traversal (HNT) for Media in Real-Time Communication", Emil Ivov, Hadriel Kaplan, Dan Wing, 7-May-13, This document describes behavior of signalling intermediaries in Real-Time Communication (RTC) deployments, sometimes referred to as Session Border Controllers (SBCs), when performing Hosted NAT Traversal (HNT). HNT is a set of mechanisms, such as media relaying and latching, that such intermediaries use to enable other RTC devices behind NATs to communicate with each other. This document is non-normative, and is only written to explain HNT in order to provide a reference to the IETF community, as well as an informative description to manufacturers, and users. "Offer/Answer Considerations for G.723 Annex A and G.729 Annex B", Muthu Perumal, Parthasarathi Ravindran, 20-May-13, 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 and updates RFC4856. "Cross Session Stream Identification in the Session Description Protocol", Harald Alvestrand, 10-Feb-13, This document specifies a grouping mechanism for RTP media streams that can be used to specify relations between media streams within different RTP sessions as well as within a single RTP session, and independently of whether these media streams are described within one SDP m-line or in multiple m-lines. This mechanism is used to signal the association between the RTP concept of SSRC and the WebRTC concept of "MediaStream" / "MediaStreamTrack" using SDP signaling. This document is a work item of the MMUSIC WG, whose discussion list is mmusic@ietf.org. 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 van Helvoort, Loa Andersson, Nurit Sprecher, 12-Feb-13, 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. "Return Path Specified LSP Ping", Mach Chen, Wei Cao, So Ning, Frederic JOUNAY, Simon DeLord, 21-Oct-12, 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", Rajiv Asati, Vishwas Manral, Rajiv Papneja, Carlos Pignataro, 25-Feb-13, The Label Distribution Protocol (LDP) specification defines procedures to exchange label bindings over either IPv4, or 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. "Configuration of Pro-Active Operations, Administration, and Maintenance (OAM) Functions for MPLS-based Transport Networks using LSP Ping", Elisa Bellagamba, Loa Andersson, Pontus Skoldstrom, David Ward, John Drake, 21-Feb-13, 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. "Hub and Spoke Multipoint Label Switched Path Tunnels", Lizhong Jin, Frederic JOUNAY, Manav Bhatia, Sriganesh Kini, 13-May-13, There are applications that require bi-directional, co-routed and guaranteed communication from a root node to several leaf nodes in a hub and spoke fashion. To meet such application requirements in a Multi-protocol Label Switching (MPLS) network this draft defines a Hub and Spoke Multipoint Traffic Engineered Label Switched Path (HSMP TE LSP) with resource reservations for guaranteed communication. This draft also defines a protocol to setup such LSPs by re-using and extending P2MP RSVP-TE. "Seamless MPLS Architecture", Nicolai Leymann, Bruno Decraene, Clarence Filsfils, Maciek Konstantynowicz, Dirk Steinberg, 13-May-13, This documents describes an architecture which can be used to extend MPLS networks to integrate access and aggregation networks into a single MPLS domain ("Seamless MPLS"). The Seamless MPLS approach is based on existing and well known protocols. It provides a highly flexible and a scalable architecture and the possibility to integrate 100.000 of nodes. The separation of the service and transport plane is one of the key elements; Seamless MPLS provides end to end service independent transport. Therefore it removes the need for service specific configurations in network transport nodes (without end to end transport MPLS, some additional services nodes/configurations would be required to glue each transport domain). This draft defines a routing architecture using existing standardized protocols. It does not invent any new protocols or defines extensions to existing protocols. "Inter-Area P2MP Segmented LSPs", Yakov Rekhter, Rahul Aggarwal, 14-May-13, 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 global table multicast over MPLS. "Disabling IPoMPLS and P2P PW LDP Application's State Advertisement", Kamran Raza, Sami Boutros, 10-May-13, Currently, no LDP capability is exchanged for LDP applications like IP Label Switching and L2VPN P2P 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 is established for some other applications like mLDP or ICCP. This document defines a solution by which an LDP speaker announces to its peer its disinterest in such non-negotiated applications. This, in turn, disables the advertisement of corresponding application state, which would have otherwise be advertised by default, over the established LDP session. "MPLS-TP Traffic Engineering (TE) Management Information Base (MIB)", Venkatesan Mahalingam, Kannan Sampath, Sam Aldrin, Thomas Nadeau, 8-May-13, 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", Sami Boutros, Siva Sivabalan, George Swallow, Shaleen Saxena, Vishwas Manral, Sam Aldrin, 20-Apr-13, 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. "LDP Extensions for Multi Topology Routing", Quintin Zhao, Luyuan Fang, Chao Zhou, Lianyuan Li, Kamran Raza, 13-May-13, Multi-Topology (MT) routing is supported in IP networks with the use of MT aware IGP protocols. In order to provide MT routing within Multiprotocol Label Switching (MPLS) Label Distribution Protocol (LDP) networks new extensions are required. This document updates RFC4379. This document describes the LDP protocol extensions required to support MT routing in an MPLS environment. "Performance-based Path Selection for Explicitly Routed LSPs", Alia Atlas, John Drake, Spencer Giacalone, David Ward, Stefano Previdi, Clarence Filsfils, 6-Feb-13, 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. "Applicability of MPLS-TP Linear Protection for Ring Topologies", Yaacov Weingarten, Stewart Bryant, Daniele Ceccarelli, Diego Caviglia, Francesco Fondelli, Marco Corsi, Wu Bo, Xuehui Dai, 30-Apr-13, This document presents an applicability of existing MPLS protection mechanisms, both local and end-to-end, to Multi-Protocol Label Switching Transport Profile (MPLS-TP) in ring topologies. This document does not propose any new mechanisms or protocols. Protection on rings offers a number of opportunities for optimization as the protection choices are starkly limited (all traffic traveling one way around a ring can only be switched to travel the other way on the ring), but also suffers from some complications caused by the limitations of the topology. Requirements for MPLS-TP protection especially for protection in ring topologies are discussed in "Requirements of an MPLS Transport Profile" (RFC 5654) and "MPLS Transport Profile (MPLS-TP) Survivability Framework" (RFC 6372). This document shows how MPLS-TP linear protection as defined in RFC 6378 can be applied to single ring topologies, discusses how most of the requirements are met, and describes scenarios in which the function provided by applying linear protection in a ring topology falls short of some of the requirements. 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. "Per-Interface MIP Addressing Requirements and Design Considerations", Adrian Farrel, Hideki Endo, Rolf Winter, Yoshinori Koike, Manuel Paul, 22-Apr-13, 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 elaborates on important considerations for internal MIP addressing. More precisely it describes important restrictions for any mechanism that specifies a way of forming OAM messages so that they can be targeted at MIPs on incoming or MIPs on outgoing interfaces and forwarded correctly through the forwarding engine. Furthermore, the document includes considerations for node implementations where there is no distinction between the incoming and outgoing MIP. "MPLS-TP Applicability; Use Cases and Design", Luyuan Fang, Nabil Bitar, Raymond Zhang, Masahiro Daikoku, Ping Pan, 1-May-13, This document provides the applicability of Multiprotocol Label Switching Transport Profile (MPLS-TP) with use case studies and network design considerations. The use cases include Metro Ethernet access and aggregation transport, Mobile backhaul, and packet optical transport. "LDP Downstream-on-Demand in Seamless MPLS", Thomas Beckhaus, Bruno Decraene, Kishore Tiruveedhula, Maciek Konstantynowicz, Luca Martini, 13-May-13, Seamless MPLS design enables a single IP/MPLS network to scale over core, metro and access parts of a large packet network infrastructure using standardized IP/MPLS protocols. One of the key goals of Seamless MPLS is to meet requirements specific to access, including high number of devices, their position in network topology and their compute and memory constraints that limit the amount of state access devices can hold.This can be achieved with LDP Downstream-on-Demand (LDP DoD) label advertisement. This document describes LDP DoD use cases and lists required LDP DoD procedures in the context of Seamless MPLS design. In addition, a new optional TLV type in the LDP Label Request message is defined for fast-up convergence. "MPLS Generic Associated Channel (G-ACh) Advertisement Protocol", Dan Frost, Stewart Bryant, Matthew Bocci, 26-Apr-13, The MPLS Generic Associated Channel (G-ACh) provides an auxiliary logical data channel associated with a Label Switched Path (LSP), a pseudowire, or a section (link) over which a variety of protocols may flow. These protocols are commonly used to provide Operations, Administration, and Maintenance (OAM) mechanisms associated with the primary data channel. This document specifies simple procedures by which an endpoint of an LSP, pseudowire, or section may inform the other endpoints of its capabilities and configuration parameters, or other application-specific information. This information may then be used by the receiver to validate or adjust its local configuration, and by the network operator for diagnostic purposes. "MPLS-TP Next-Hop Ethernet Addressing", Dan Frost, Stewart Bryant, Matthew Bocci, 8-Apr-13, 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. "mLDP Node Protection", IJsbrand Wijnands, Eric Rosen, Kamran Raza, Jeff Tantsura, Alia Atlas, Quintin Zhao, 20-Dec-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. "Temporal and hitless path segment monitoring", Alessandro D'Alessandro, Manuel Paul, Satoshi Ueno, Yoshinori Koike, 7-May-13, 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. "MPLS-TP Operations, Administration, and Management (OAM) Identifiers Management Information Base (MIB)", Sam Aldrin, Venkatesan Mahalingam, Kannan Sampath, Thomas Nadeau, 7-Feb-13, 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). "LDP Hello Cryptographic Authentication", Lianshu Zheng, Mach Chen, Manav Bhatia, 21-Jan-13, This document introduces a new optional Cryptographic Authentication TLV that LDP can use to secure its Hello messages. It secures the Hello messages against spoofing attacks and some well known attacks against the IP header. This document describes a mechanism to secure the LDP Hello messages using National Institute of Standards and Technology (NIST) Secure Hash Standard family of algorithms. "Using LDP Multipoint Extensions on Targeted LDP Sessions", Maria Napierala, Eric Rosen, 28-Jan-13, 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 provides the specification for using the LDP P2MP/MP2MP extensions over a Targeted LDP session. "MPLS-TP 1toN Protection", Eric Osborne, Fei Zhang, Yaacov Weingarten, 4-Feb-13, As part of the Transport Profile for Multiprotocol Label Switching (MPLS-TP) there is a requirement to support 1:n linear protection for transport paths. This requirement is further elaborated in RFC6372 [SurvivFwk]. The basic protocol for linear protection, specified in RFC6378 [LinProt], is limited to 1+1 and 1:1 protection. This document extends that protocol to address the additional functionality necessary to support scenarios where a single protection path is preconfigured to provide protection of multiple transport paths between two joint endpoints. 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. "Applicability of LDP Label Advertisement Mode", Kamran Raza, Sami Boutros, Luca Martini, Nicolai Leymann, 14-Feb-13, 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 updates RFC5036 and RFC4447 to remove any ambiguity and conflict in the area of using correct label advertisement mode for a given application. "LDP Extensions for Hub & Spoke Multipoint Label Switched Path", Lizhong Jin, Frederic JOUNAY, IJsbrand Wijnands, Nicolai Leymann, 19-Apr-13, This draft introduces a hub & spoke multipoint LSP (short for HSMP LSP), which allows traffic both from root to leaf through P2MP LSP and also leaf to root along the co-routed reverse path. That means traffic entering the HSMP LSP from application/customer at the root node travels downstream, exactly as if it was traveling downstream along a P2MP LSP to each leaf node, and traffic entering the HSMP LSP at any leaf node travels upstream along the tree to the root as if it is unicast to the root, except that it follows the path of the tree rather than ordinary unicast to the root. "Allocating and Retiring Special Purpose MPLS Labels", Kireeti Kompella, Loa Andersson, Adrian Farrel, 15-Mar-13, Some MPLS labels have been allocated for specific purposes. A block of labels (0-15) has been set aside to this end, and are commonly called "reserved labels". They will be called "special purpose labels" in this document. As there are only 16 of these labels, caution is needed in the allocation of new special purpose labels, yet at the same time allow forward progress when one is called for. This memo defines some procedures to follow in the allocation and retirement of special purpose labels, as well as a method to extend the special purpose label space. Finally, this memo renames the IANA registry for these labels to "Special Purpose MPLS Label Values", and creates a new one called the "Extended Special Purpose MPLS Label Values" registry. "Proxy MPLS Echo Request", George Swallow, Vanson Lim, Sam Aldrin, 7-May-13, This document defines a means of remotely initiating Multiprotocol Label Switched Protocol Pings on Label Switched Paths. A proxy ping request is sent to any Label Switching Routers along a Label Switched Path. The primary motivations for this facility are first to limit the number of messages and related processing when using LSP Ping in large Point-to-Multipoint LSPs, and second to enable leaf to leaf/ root tracing. "Signaling RSVP-TE P2MP LSPs in an Inter-domain Environment", Zafar Ali, Rakesh Gandhi, Cisco Systems, Robert Venator, Yuji Kamite, 12-Apr-13, Point-to-MultiPoint (P2MP) Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) are established using signaling procedures defined in [RFC4875]. However, [RFC4875] does not address several issues that arise when a P2MP-TE LSP is signaled in inter-domain networks. One such issue is the computation of a loosely routed inter-domain P2MP- TE LSP paths that are re-merge free. Another issue is the reoptimization of the inter-domain P2MP-TE LSP tree vs. an individual destination(s), since the loosely routing domain ingress border node is not aware of the reoptimization scope. This document defines the required protocol extensions needed for establishing and reoptimizing P2MP MPLS and GMPLS TE LSPs in inter-domain networks. "Encapsulating MPLS in UDP", KuiKe Building, Nischal Sheth, Lucy Yong, Carlos Pignataro, Fan Yongbing, 1-Apr-13, Existing technologies to encapsulate Multi-Protocol Label Switching (MPLS) over IP are not adequate for efficient load balancing of MPLS application traffic, such as MPLS-based Layer2 Virtual Private Network (L2VPN) or Layer3 Virtual Private Network (L3VPN) traffic across IP networks. This document specifies additional IP-based encapsulation technology, referred to as MPLS-in-User Datagram Protocol (UDP), which can facilitate the load balancing of MPLS application traffic across IP networks. "A Framework for Point-to-Multipoint MPLS in Transport Networks", Dan Frost, Stewart Bryant, Matthew Bocci, Lou Berger, 8-Apr-13, The Multiprotocol Label Switching (MPLS) Transport Profile (MPLS-TP) is the common set of MPLS protocol functions defined to enable the construction and operation of packet transport networks. The MPLS-TP supports both point-to-point and point-to-multipoint transport paths. This document defines the elements and functions of the MPLS-TP architecture applicable specifically to supporting point-to- multipoint transport paths. 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 functions of a packet transport network. "MPLS Transport Profile Linear Protection MIB", Kingston Selvaraj, Venkatesan Mahalingam, Vishwas Manral, Daniel King, Sam Aldrin, 9-Feb-13, 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. ""MPLS LSP Ping TLVs and sub-TLVs registry"", Loa Andersson, Mach Chen, Tom Petch, 1-May-13, This document addresses issues with the structure, allocation policies and clarity in the use of the "TLVs and sub-TLVs" of the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" in the "Multiprotocol Label Switching Architecture (MPLS)" name space. This document does not change any existing allocations and the new structure is backwards compatible with the existing registries. The policy for the allocation of TLVs is unchanged but future allocations of sub-TLVs will come from a single namespace, common to all TLVs of LSP Ping Parameters. "Use of Multipath with MPLS-TP and MPLS", Curtis Villamizar, 25-Feb-13, Many MPLS implementations have supported multipath techniques and many MPLS deployments have used multipath techniques, particularly in very high bandwidth applications, such as provider IP/MPLS core networks. MPLS-TP has strongly discouraged the use of multipath techniques. Some degradation of MPLS-TP OAM performance cannot be avoided when operating over many types of multipath implementations. Using MPLS Entropy label, MPLS LSPs can be carried over multipath links while also providing a fully MPLS-TP compliant server layer for MPLS-TP LSPs. This document describes the means of supporting MPLS as a server layer for MPLS-TP. The use of MPLS-TP LSPs as a server layer for MPLS LSPs is also discussed. "Relayed Echo Reply mechanism for LSP Ping", Zhi Zheng, Lizhong Jin, Thomas Nadeau, George Swallow, 10-Mar-13, In some inter-AS and inter-area deployment scenarios for LSP Ping and 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 resulting in false negatives or complete failure of operation of LSP Ping and Traceroute. This document describes extensions to LSP Ping mechanism to enable the replying LSR to have the capability to relay the echo response by a set of routable intermediate nodes to the initiator during the traceroute process in inter-AS and inter-area scenarios. "Requirements for MPLS Shared Mesh Protection", Yaacov Weingarten, Sam Aldrin, Ping Pan, Jeong-dong Ryoo, Greg Mirsky, 26-Mar-13, This document presents the basic network objectives for the behavior of shared mesh protection (SMP) not based on control-plane support. This is an expansion of the basic requirements presented in the MPLS Transport Profile Requirements (RFC5654) and MPLS Transport Profile Survivability Framework (RFC6372) documents. This document should be used as a basis for the definition of the mechanism that would be used to implement SMP for MPLS-TP data paths, in networks that do not employ a control plane for their operation. "MPLS Forwarding Compliance and Performance Requirements", Curtis Villamizar, Kireeti Kompella, Shane Amante, Andrew Malis, Carlos Pignataro, 16-Apr-13, This document provides guidelines for implementors regarding MPLS forwarding and a basis for evaluations of forwarding implementations. Guidelines cover many aspects of MPLS forwarding. Topics are highlighted where implementors might potentially overlook practical requirements which are unstated or underemphasized or are optional for conformance to RFCs. "Retiring TLVs from the Associated Channel Header of the MPLS Generic Associated Channel", Adrian Farrel, Stewart Bryant, 23-May-13, The MPLS Generic Associated Channel (G-ACh) is a generalization of the applicability of the Pseudowire (PW) Associated Channel Header (ACH). RFC 5586 defines the concept of TLV constructs that can be carried in messages on the G-ACh by placing them in the ACH between the fixed header fields and the G-ACh message. These TLVs are called ACH TLVs No Associated Channel Type yet defined uses an ACH TLV. Furthermore, it is believed that handling TLVs in hardware introduces significant problems to the fast-path, and since G-ACh messages are intended to be processed substantially in hardware, the use of TLVs in undesirable. This document updates RFC 5586 by retiring ACH TLVs and removing the associated registry. Multicast Mobility (multimob) ----------------------------- "Mobile Multicast Sender Support in Proxy Mobile IPv6 (PMIPv6) Domains", Thomas Schmidt, Shuai Gao, Hong-Ke Zhang, Matthias Waehlisch, 25-Feb-13, 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. Protocol optimizations for synchronizing PMIPv6 with PIM, as well as extended MLD Proxy functions are presented. Mobile sources always remain agnostic of multicast mobility operations. "Multicast Mobility Routing Optimizations for Proxy Mobile IPv6", Juan Zuniga, Luis Contreras, Carlos Bernardos, Seil Jeon, Younghan Kim, 13-May-13, The MULTIMOB group has specified a base solution to support IP multicasting in a PMIPv6 domain [RFC6224]. In this document, some enhancements to the base solution are described. 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 deployment scenarios. "PMIPv6 multicast handover optimization by the Subscription Information Acquisition through the LMA (SIAL)", Luis Contreras, Carlos Bernardos, Ignacio Soto, 25-Feb-13, This document specifies a multicast handover optimization mechanism for Proxy Mobile IPv6 to accelerate the delivery of multicast traffic to mobile nodes after handovers. The mechanism is based on speeding up the acquisition of mobile nodes' multicast context by the mobile access gateways. To do that, extensions to the current Proxy Mobile IPv6 protocol are proposed. These extensions are not only applicable to the base solution for multicast support in Proxy Mobile IPv6, but they can also be applied to other solutions being developed to avoid the tunnel convergence problem. Furthermore, they are also independent of the role played by the mobile access gateway within the multicast network (either acting as multicast listener discovery proxy or multicast router). "Multicast Listener Extensions for MIPv6 and PMIPv6 Fast Handovers", Thomas Schmidt, Matthias Waehlisch, Rajeev Koodli, Gorry Fairhurst, Dapeng Liu, 25-Feb-13, 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. Network Endpoint Assessment (nea) --------------------------------- "PT-EAP: Posture Transport (PT) Protocol For EAP Tunnel Methods", Nancy Cam-Winget, Paul Sangster, 28-Mar-13, This document specifies PT-EAP, an Extensible Authentication Protocol (EAP) based Posture Transport (PT) protocol designed to be used only inside a TLS protected EAP tunnel method. The document also describes the intended applicability of PT-EAP. Network Configuration (netconf) ------------------------------- "Using the NETCONF Protocol over Transport Layer Security (TLS)", Mohamad Badra, Alan Luchuk, Juergen Schoenwaelder, 10-May-13, 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 the exchange of NETCONF messages. This document obsoletes RFC 5539. Network-Based Mobility Extensions (netext) ------------------------------------------ "Logical Interface Support for multi-mode IP Hosts", Telemaco Melia, Sri Gundavelli, 24-Apr-13, 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. "Prefix Delegation Support for Proxy Mobile IPv6", Xingyue Zhou, Jouni Korhonen, Carl Williams, Sri Gundavelli, Carlos Bernardos, 19-May-13, This specification defines extensions to Proxy Mobile IPv6 protocol for allowing a mobile router in a Proxy Mobile IPv6 domain to obtain delegated IP prefixes for its attached mobile networks. The mobility entities in the network will provide network-based mobility management support for those delegated IP prefixes just as how IP mobility support is provided for the mobile node's home address. Even as the mobile router performs an handoff and changes its network point of attachment, mobility support is ensured for all the delegated IP prefixes and for all the IP nodes in the mobile network that use IP address configuration from those delegated IP prefixes. "Proxy Mobile IPv6 Extensions to Support Flow Mobility", Carlos Bernardos, 25-Feb-13, 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 extensions to the Proxy Mobile IPv6 protocol that are required to support network based flow mobility over multiple physical interfaces. The extensions required consist on the operations performed by the local mobility anchor and the mobile access gateway to manage the prefixes assigned to the different interfaces of the mobile node, as well as how the forwarding policies are handled by the network to ensure consistent flow mobility management. "EAP Attributes for WiFi - EPC Integration", Ravi Valmikam, Rajeev Koodli, 15-Jan-13, With WiFi beginning to establishing itself as a trusted access network for service providers, it has become important to provide functions commonly available in 3G and 4G networks in WiFi access networks. Such functions include Access Point Name (APN) Selection, multiple Packet Data Network (PDN) connections and seamless mobility between WiFi and 3G/4G networks. EAP/AKA (and EAP/AKA') is standardized by 3GPP as the access authentication protocol for trusted access networks. This IETF specification is required for mobile devices to access the 3GPP Evolved Packet Core (EPC) networks. This document defines a few new EAP attributes and procedures to provide the above-mentioned functions in trusted WiFi access networks. "Quality of Service Option for Proxy Mobile IPv6", Marco Liebsch, Pierrick Seite, Hidetoshi Yokota, Jouni Korhonen, Sri Gundavelli, 25-Feb-13, This specification defines a new mobility option that can be used by the mobility entities in the Proxy Mobile IPv6 domain to exchange Quality of Service parameters associated with a subscriber's IP flows. Using the QoS option, the local mobility anchor and the mobile access gateway can exchange available QoS attributes and associated values. This enables QoS policing and labeling of packets to enforce QoS differentiation on the path between the local mobility anchor and the mobile access gateway. Furthermore, making QoS parameters available on the MAG enables mapping these parameters to QoS rules being specific to the access technology which operates below the mobile access gateway. After such mapping, QoS rules can be enforced on the access technology components, such as an IEEE 802.11e Wireless LAN controller. "Update Notifications for Proxy Mobile IPv6", Suresh Krishnan, Sri Gundavelli, Marco Liebsch, Hidetoshi Yokota, Jouni Korhonen, 9-May-13, This document specifies protocol enhancements for allowing the local mobility anchor in a Proxy Mobile IPv6 domain to asynchronously notify the mobile access gateway about changes related to a mobility session. These update notification messages are exchanged using a new Mobility Header message type specifically designed for this purpose. NETCONF Data Modeling Language (netmod) --------------------------------------- "IANA Interface Type and Address Family YANG Modules", Martin Bjorklund, 19-Apr-13, This document defines the initial versions of the iana-if-type and iana-afn-safi YANG modules. "A YANG Data Model for Interface Management", Martin Bjorklund, 15-May-13, This document defines a YANG data model for the management of network interfaces. It is expected that interface type specific data models augment the generic interfaces data model defined in this document. The data model includes configuration data, state data and counters for the collection of statistics. "A YANG Data Model for Routing Management", Ladislav Lhotka, 23-Feb-13, This document contains a specification of three YANG modules. Together they form the core routing data model which serves as a framework for configuring and managing a routing subsystem. It is expected that these modules 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 extensions - router instances, routes, routing tables, routing protocols and route filters. "A YANG Data Model for IP Management", Martin Bjorklund, 10-Feb-13, This document defines a YANG data model for management of IP implementations. "YANG Data Model for System Management", Andy Bierman, Martin Bjorklund, 21-Apr-13, This document defines a YANG data model for the configuration and identification of the management system of a device. "A YANG Data Model for SNMP Configuration", Martin Bjorklund, Juergen Schoenwaelder, 25-Apr-13, This document defines a collection of YANG definitions for configuring SNMP engines. "IANA Timezone Database YANG Module", Jeffrey Lange, 9-Jul-12, This document defines the initial version of the iana-timezones YANG module. "Common YANG Data Types", Juergen Schoenwaelder, 7-May-13, This document introduces a collection of common data types to be used with the YANG data modeling language. This document obsoletes RFC 6021. Network File System Version 4 (nfsv4) ------------------------------------- "Administration Protocol for Federated Filesystems", James Lentini, Daniel Ellard, Renu Tewari, Charles Lever, 12-Dec-12, 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. "NSDB Protocol for Federated Filesystems", James Lentini, Daniel Ellard, Renu Tewari, Charles Lever, 12-Dec-12, 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", Tom, David Noveck, 8-May-13, 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, obsoletes RFC 3530 as the definition of the NFS version 4 protocol. "Network File System (NFS) Version 4 External Data Representation Standard (XDR) Description", Tom, David Noveck, 8-May-13, The Network File System (NFS) version 4 is a distributed filesystem protocol which owes its 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. RFC3530bis formally obsoleting RFC 3530. This document, together with RFC3530bis replaces RFC 3530 as the definition of the NFS version 4 protocol. "NFS Version 4 Minor Version 2", Tom, 14-Mar-13, 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, Application I/O Advise, Space Reservations, Sparse Files, Application Data Blocks, and Labeled NFS. "NFSv4 Minor Version 2 Protocol External Data Representation Standard (XDR) Description", Tom, 13-Mar-13, This Internet-Draft provides the XDR description for NFSv4 minor version two. "Requirements for Labeled NFS", Tom, 18-May-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. "NFSv4 migration: Implementation experience and spec issues to resolve", David Noveck, Piyush Shivam, Charles Lever, Bill Baker, 21-Mar-13, 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, explores the options available for curing the issues, and explains the choices made in updating the NFSv4.0 and NFSv4.1 specifications, to address migration. "NFSv4.0 migration: Specification Update", David Noveck, Piyush Shivam, Charles Lever, Bill Baker, 15-Feb-13, The migration feature of NFSv4 allows for responsibility for a single filesystem to move from one server to another, without disruption to clients. Recent implementation experience has shown problems in the existing specification for this feature in NFSv4.0. This document clarifies and corrects the NFSv4.0 specification (RFC3530 and possible successors) to address these problems. Individual Submissions (none) ----------------------------- "The ARK Identifier Scheme", John Kunze, R. Rodgers, 5-Apr-13, The ARK (Archival Resource Key) naming scheme is designed to facilitate the high-quality and persistent identification of information objects. A founding principle of the ARK is that persistence is purely a matter of service and is neither inherent in an object nor conferred on it by a particular naming syntax. The best that an identifier can do is to lead users to the services that support robust reference. The term ARK itself refers both to the scheme and to any single identifier that conforms to it. An ARK has five components: [http://NMAH/]ark:/NAAN/Name[Qualifier] an optional and mutable Name Mapping Authority Hostport (usually a hostname), the "ark:" label, the Name Assigning Authority Number (NAAN), the assigned Name, and an optional and possibly mutable Qualifier supported by the NMA. The NAAN and Name together form the immutable persistent identifier for the object independent of the URL hostname. An ARK is a special kind of URL that connects users to three things: the named object, its metadata, and the provider's promise about its persistence. When entered into the location field of a Web browser, the ARK leads the user to the named object. That same ARK, inflected by appending a single question mark (`?'), returns a brief metadata record that is both human- and machine- readable. When the ARK is inflected by appending dual question marks (`??'), the returned metadata contains a commitment statement from the current provider. Tools exist for minting, binding, and resolving ARKs. "An IPv4 Flowlabel Option", Thomas Dreibholz, 31-Dec-12, 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, Alvaro Retana, Enke Chen, John Scudder, 13-Dec-12, 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, 26-Jan-13, 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-12, This document describes the applicability of the Reliable Server Pooling architecture to the IP Flow Information Exchange using the Aggregate Server Access Protocol (ASAP) functionality of RSerPool only. Data exchange in IPFIX between the router and the data collector can be provided by a limited retransmission protocol. "Prepaid Extensions to Remote Authentication Dial-In User Service (RADIUS)", Avi Lior, Parviz Yegani, Kuntal Chowdhury, Hannes Tschofenig, Andreas Pashalidis, 25-Feb-13, 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. "Stream Control Transmission Protocol (SCTP) Packet Drop Reporting", Randall Stewart, Peter Lei, Michael Tuexen, 17-Apr-13, 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. "Applicability of Reliable Server Pooling for Real-Time Distributed Computing", Thomas Dreibholz, 31-Dec-12, 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. "Secure SCTP", Carsten Hohendorf, Esbold Unurkhaan, Thomas Dreibholz, 31-Dec-12, 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. "Operational Reliability for EDIINT AS2", John Duker, Dale Moberg, 17-Apr-13, One 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. A second goal is to reduce retransmissions and failures when AS2 is used in a synchronous mode for transmitting MDNs. There can be a large latency between receipt of the POSTed entity body and the MDN response caused by the operations of decompressing, decrypting, and signature checks. Uncoordinated timeout policies and intermediate devices dropping connections have interfered with reliable data exchange. The use of an HTTP 102(Processing) status code is described to mitigate these difficulties. Use 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. "Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP)", Keith Drage, Christer Holmberg, Roland Jesske, 15-Mar-13, 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. "Applicability of Reliable Server Pooling for SCTP-Based Endpoint Mobility", Thomas Dreibholz, Jobin Pulinthanath, 31-Dec-12, 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-12, This memo describes some of the scoring to be used in the testing of Reliable Server Pooling protocols ASAP and ENRP at upcoming bakeoffs. "Distributed DNS Implementation in IpV6", Lican Huang, 30-Jan-13, 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, 14-Dec-12, 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, 14-Dec-12, 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, 14-Dec-12, 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. "Using Saratoga with a Bundle Agent as a Convergence Layer for Delay- Tolerant Networking", Lloyd Wood, Jim McKim, Wesley Eddy, Will Ivancic, Chris Jackson, 21-Apr-13, Saratoga is a simple, lightweight, UDP-based transfer protocol. This describes how to use Saratoga as a Delay-Tolerant Networking (DTN) "convergence layer" with the Bundle Protocol and its Bundle Agents, building on the Saratoga specification in draft-wood-tsvwg-saratoga. "Handle Resolution Option for ASAP", Thomas Dreibholz, 31-Dec-12, This document describes the Handle Resolution option for the ASAP protocol. "Definition of a Delay Measurement Infrastructure and Delay-Sensitive Least-Used Policy for Reliable Server Pooling", Thomas Dreibholz, Xing Zhou, 31-Dec-12, 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. "Saratoga: A Scalable Data Transfer Protocol", Lloyd Wood, Wesley Eddy, Charles Smith, Will Ivancic, Chris Jackson, 21-Apr-13, 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. Saratoga can also cope with very large files for exascale computing. In scenarios with dedicated links, Saratoga focuses on high link utilization to make the most of limited connectivity times, while standard congestion control mechanisms can be implemented for operation over shared links. Loss recovery is implemented via a simple negative-ack ARQ mechanism. The protocol specified in this document is considered to be appropriate for experimental use on private IP networks. "Session Initiation Protocol Service Example -- Music on Hold", Dale Worley, 16-Apr-13, 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 music-on-hold method described in section 2.3 of RFC 5359. "Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): One-to-One Text Chat", Peter Saint-Andre, Eddy Gavita, Nazin Hossain, Salvatore Loreto, 4-Apr-13, This document defines a bidirectional protocol mapping for the exchange of instant messages in the context of a one-to-one chat session between a user of the Session Initiation Protocol (SIP) and a user of the Extensible Messaging and Presence Protocol (XMPP). Specifically for SIP text chat, this document specifies a mapping to the Message Session Relay Protocol (MSRP). "Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Addresses and Error Conditions", Peter Saint-Andre, Avshalom Houri, Joe Hildebrand, 2-Apr-13, As a foundation for the definition of bidirectional protocol mappings between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP), this document specifies the architectural assumptions underlying such mappings as well as the mapping of addresses and error conditions. "Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Instant Messaging", Peter Saint-Andre, Avshalom Houri, Joe Hildebrand, 4-Apr-13, This document defines a bidirectional protocol mapping for the exchange of single instant messages between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP). "Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Media Sessions", Peter Saint-Andre, 20-Feb-13, This document defines a bi-directional protocol mapping for use by gateways that enable the exchange of media signalling messages between systems that implement the Jingle extensions to the Extensible Messaging and Presence Protocol (XMPP) and those that implement the Session Initiation Protocol (SIP). "Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Presence", Peter Saint-Andre, Avshalom Houri, Joe Hildebrand, 2-Apr-13, This document defines a bi-directional protocol mapping for the exchange of presence information between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP). "The Uniform Resource Identifier (URI) DNS Resource Record", Patrik Faltstrom, Olaf Kolkman, 22-Jan-13, This document defines a new DNS resource record, called the Uniform Resource Identifier (URI) RR, for publishing mappings from hostnames to URIs. This document updates RFC 3958 and RFC 3404. "6LoWPAN Backbone Router", Pascal Thubert, 25-Feb-13, Some LLN subnets are expected to scale up to the thousands of nodes and hundreds of routers. This paper proposes an IPv6 version of the Backbone Router concept that enables such a degree of scalability using a high speed network as a backbone to the subnet. "The BagIt File Packaging Format (V0.97)", Andy Boyko, John Kunze, Justin Littman, Liz Madden, Brian Vargas, 5-Apr-13, This document specifies BagIt, a hierarchical file packaging format for storage and transfer of arbitrary digital content. A "bag" has just enough structure to enclose descriptive "tags" and a "payload" but does not require knowledge of the payload's internal semantics. This BagIt format should be suitable for disk-based or network-based storage and transfer. "PCEP extensions for a BGP/MPLS IP-VPN", Kenji Kumaki, Tomoki Murai, Dhruv Dhody, PENG JIANG, 26-Apr-13, 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 how to extend the PCEP to support the dynamic creation of MPLS TE LSPs between BGP/MPLS IP-VPN sites. "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). "BGP Extended Community for QoS Marking", Thomas Knoll, 4-Jan-13, 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. "BGP Class of Service Interconnection", Thomas Knoll, 11-May-13, 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. "Internet Protocol-based In-Vehicle Emergency Call", Brian Rosen, Hannes Tschofenig, Randy, 24-Feb-13, This document describes how to re-use the emergency services mechanisms specified for the Session Initiation Protocol (SIP) to accomplishing emergency calling support in vehicles. Profiling and simplifications are possible due to the nature of the functionality that is going to be provided in vehicles with the usage of Global Positioning System (GPS). "RSVP-TE Recovery Extension for data plane initiated reversion, protection timer and SNC options signalling", Attila Takacs, Francesco Fondelli, Benoit Tremblay, Zafar Ali, 25-Feb-13, RSVP-TE recovery extensions are specified in [RFC4872] and [RFC4873]. Currently recovery signalling does not support the request for revertive protection, recovery timers values, and sub-network connection (SNC) protection options. This document extends the PROTECTION Object format allowing sub-TLVs, and defines three sub-TLVs to carry wait-to-restore and hold-off intervals and SNC protection options. "Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management", Vishwas Manral, Tina Tsou, Will Liu, 21-May-13, This memo defines a Management Information Base (MIB) module which contains Textual Conventions to represent commonly used Multiprotocol Label Switching (MPLS) management information. The intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and used in MPLS related MIB modules that would otherwise define their own representations. This document obsoletes RFC3811 as it addresses the need to support IPv6 extended TunnelID's by defining a new TC- MplsNewExtendedTunnelID which suggests using IPv4 address of the ingress or egress LSR for the tunnel for an IPv6 network. Changes from RFC3811 and the effect of the new TC to other related documents are summarized in Section 4 and 5, respectively. "Fast Connectivity Restoration Using BGP Add-path", Pradosh Mohapatra, Rex Fernando, Clarence Filsfils, Robert Raszuk, 22-Jan-13, 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. "Healthy Food and Special Dietary Requirements for IETF meetings", Mary Barnes, 25-Feb-13, 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. "Information Model for Impaired Optical Path Validation", Young Lee, Greg Bernstein, Xian Zhang, 20-Feb-13, This document provides an information model for the optical impairment characteristics of optical network elements for use in GMPLS/PCE control plane protocols and mechanisms. This information model supports Impairment Aware Routing and Wavelength Assignment (IA-RWA) in optical networks in which path computation and optical path validation are essential components. This is not a general network management information model. This model is based on ITU-T defined optical network element characteristics as given in ITU-T recommendation G.680 and related specifications. This model is intentionally compatible with a previous impairment free optical information model used in optical path computations and wavelength assignment. "Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Groupchat", Peter Saint-Andre, Salvatore Loreto, Saul Corretge, Fabio Forno, 2-May-13, This document defines a bidirectional protocol mapping for the exchange of instant messages in the context of a multiparty chat session among users of the Session Initiation Protocol (SIP) and users of the Extensible Messaging and Presence Protocol (XMPP). Specifically, this document defines a mapping between the XMPP Multi- User Chat (MUC) extension and the SIP-based Message Session Relay Protocol (MSRP). "Extreme Networks' Ethernet Automatic Protection Switching (EAPS), Version 1.3", Arnel Lim, Steven Blake, Sunil Shah, 5-Jul-11, This document describes version 1.3 of the Ethernet Automatic Protection Switching (EAPS) (TM) technology invented by Extreme Networks to increase the availability and robustness of Ethernet rings. An Ethernet ring built using EAPS can have resilience comparable to that provided by SONET rings, at lower cost and without some of the constraints (e.g. ring size) of SONET. "Takeover Suggestion Flag for the ENRP Handle Update Message", Thomas Dreibholz, Xing Zhou, 31-Dec-12, This document describes the Takeover Suggestion Flag for the ENRP_HANDLE_UPDATE message of the ENRP protocol. "Information Encoding for Impaired Optical Path Validation", Greg Bernstein, Young Lee, Xian Zhang, 21-Feb-13, This document provides an information encoding for the optical impairment characteristics of optical network elements for use in path computation and optical path impairment validation. This encoding is based on ITU-T defined optical network element characteristics as given in ITU-T recommendation G.680 and related specifications. This encoding is intentionally compatible with a previous impairment free optical information encoding used in optical path computations and wavelength assignment. "HTTP Live Streaming", Roger Pantos, 16-Apr-13, 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 5 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. "The Subnetwork Encapsulation and Adaptation Layer (SEAL)", Fred Templin, 3-May-13, This document specifies a Subnetwork Encapsulation and Adaptation Layer (SEAL). SEAL operates over virtual topologies configured over connected IP network routing regions bounded by encapsulating border nodes. These virtual topologies are manifested by tunnels that may span multiple IP and/or sub-IP layer forwarding hops, where they may incur packet duplication, packet reordering, source address spoofing and traversal of links with diverse Maximum Transmission Units (MTUs). SEAL uniquely addresses these issues through the encapsulation and messaging mechanisms specified in this document. "A Session Initiation Protocol (SIP) Event Package for Communication Diversion Information in support of the Communication Diversion (CDIV) Notification (CDIVN) CDIV service", John-Luc Bakker, Ranjit Avasarala, 24-Mar-13, 3GPP and TISPAN are defining the protocol specification for the Communication Diversion (CDIV) service using IP Multimedia (IM) Core Network (CN) subsystem (IMS) supplementary service. As part of CDIV, a SIP based event package is used for notifying users about diversions (re-directions or forwarding) of requests for communication sessions targetting the user. This document defines the SIP event package to support subscription and notification of diversions. The proposed event package is applicable to the CDIV supplementary service in IMS and may not be applicable to the general internet. "Virtual Enterprise Traversal (VET)", Fred Templin, 3-May-13, Enterprise networks connect hosts and routers over various link types, and often also connect to the global Internet either directly or via a provider network. Enterprise network nodes require a means to automatically provision addresses/prefixes and support internetworking operation in a wide variety of use cases including Small Office / Home Office (SOHO) networks, Mobile Ad hoc Networks (MANETs), ISP networks, multi-organizational corporate networks and the interdomain core of the global Internet itself. This document specifies a Virtual Enterprise Traversal (VET) abstraction for autoconfiguration and operation of nodes in dynamic enterprise networks. "Reverse DNS in IPv6 for Internet Service Providers", Lee Howard, 26-Mar-13, In IPv4, Internet Service Providers (ISPs) commonly provide IN- ADDR.ARPA. information for their customers by prepopulating the zone with one PTR record for every available address. This practice does not scale in IPv6. This document analyzes different approaches for ISPs to manage the ip6.arpa zone for IPv6 address space assigned to many customers. "Session Recording for Conferences using SMIL", Alessandro Amirante, Tobia Castaldi, Lorenzo Miniero, Simon Romano, 14-Dec-12, 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. "Session Policy Framework using EAP", Stephen McCann, Michael Montemurro, 8-Jan-13, 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. "A TCP Authentication Option Extension for NAT Traversal", Joseph Touch, 23-May-13, This document describes an extension to the TCP Authentication Option (TCP-AO) to support its use over connections that pass through network address and/or port translators (NATs/NAPTs). This extension changes the data used to compute traffic keys, but does not alter TCP-AO's packet processing or key generation algorithms. "Mesh Structured Hierarchical Networking and IPv6", Shyam Bandyopadhyay, 19-May-13, 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. "JSON Schema: core definitions and terminology", Francis Galiegue, Kris Zyp, Gary Court, 31-Jan-13, JSON Schema defines the media type "application/schema+json", a JSON based format for defining the structure of JSON data. JSON Schema provides a contract for what JSON data is required for a given application and how to interact with it. JSON Schema is intended to define validation, documentation, hyperlink navigation, and interaction control of JSON data. "Delay-Tolerant Networking LTP Convergence Layer (LTPCL) Adapter", Scott Burleigh, 25-Apr-13, This document describes the procedures by which the Licklider Transmission Protocol (LTP) is used as a "convergence-layer" protocol to convey Delay-Tolerant Networking (DTN) "bundles" between DTN nodes. "rxgk: GSSAPI based security class for RX", Simon Wilkinson, Benjamin Kaduk, 22-May-13, rxgk is a security class for the RX RPC protocol. It uses the GSSAPI framework to provide an authentication service that provides authentication, confidentiality and integrity protection for the rxgk security class. This document provides a general description of rxgk and how to integrate it into generic RX applications. Application specific behaviour will be described, as necessary, in future documents. "Integrating rxgk with AFS", Simon Wilkinson, 18-Mar-13, 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, 6-Jan-13, 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, 6-Jan-13, 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. "Server Message Block and NetBIOS", Palanivelan Appanasamy, 10-Jan-13, The Server Message Block (SMB) is a presentation layer protocol providing file and print sharing functions for LAN Manager, and other network operating systems. The Network Basic I/O System (NetBIOS) NetBIOS was developed in the early 1980s to allow applications to communicate over a network. The TCP/IP version called NetBIOSoverTCP/IP(NetBT), was developed to support communications between symbolically named stations and transfer of arbitrary data.NetBT supports all three services (Name, Datagram and Session) supported by NetBIOS. This document attempts to provide, Control and Operational details on SMB over NetBT session, which is otherwise not clearly explained in the RFCs [Netbios concepts] and [Netbios specification] or any available documentation. This document is intended for documentation purpose and for informational use only.This document does not attempt to define a standard, rather tries explaining an existing implementation. This document puts together pieces of information scattered in multiple documents and offers a single complete documentation for this specific application (smb over NetBT). "New Properties for iCalendar", Cyrus Daboo, 31-Jan-13, This document defines a set of new properties for iCalendar data. "Extensions to RSVP-TE for P2MP LSP Egress Local Protection", Huaimo Chen, So Ning, Autumn Liu, Lei Liu, 26-Feb-13, 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, So Ning, Autumn Liu, Lei Liu, 26-Feb-13, 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. "The PKCS#11 URI Scheme", Jan Pechanec, Darren Moffat, 14-May-13, This memo specifies a PKCS#11 Uniform Resource Identifier (URI) Scheme for identifying PKCS#11 objects stored in PKCS#11 tokens, for identifying PKCS#11 tokens themselves, or for identifying PKCS#11 libraries. The URI is based on how PKCS#11 objects, tokens, and libraries are identified in the PKCS#11 Cryptographic Token Interface Standard. "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. "Group Key Management using IKEv2", Sheela Rowles, Aldous Yeung, Paulina Tran, Yoav Nir, 28-Apr-13, This document presents a new group key distribution protocol. The protocol is in conformance with MSEC key management architecture it contains two components: member registration and group rekeying, both downloading group security associations from the Group Controller Key Server to a member of the group. The new protocol is similar to IKEv2 in message and payload formats as well as message semantics. "Xon/Xoff State Control for Telnet Com Port Control Option", Grant Edwards, 23-Mar-10, This document defines new values for use with the telnet com port control option's SET-CONTROL sub-command defined in RFC2217. These new values provide a mechanism for the telnet client to control and query the outbound Xon/Xoff flow control state of the telnet server's physical serial port. This capability is exposed in the serial port API on some operating systems and is needed by telnet clients that implement a port-redirector service which provides applications local to the redirector/telnet-client with transparent access to the remote serial port on the telnet server. "Linear Protection Switching in MPLS-TP", Huub van Helvoort, Jeong-dong Ryoo, Zhang Haiyan, Feng Huang, Han Li, Alessandro D'Alessandro, 6-May-13, 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. "Overlay Transport Virtualization", Hasmit Grover, Dhananjaya Rao, Dino Farinacci, Victor Moreno, 23-Feb-13, In today's networking environment most enterprise networks span multiple physical sites. Overlay Transport Virtualization (OTV) provides a scalable solution for L2/L3 connectivity across different sites using the currently deployed service provider and enterprise networks. It is a very cost-effective and simple solution requiring deployment of a one or more OTV functional device at each of the enterprise sites. This solution is agnostic to the technology used in the service provider network and connectivity between the enterprise and the service provider network. This document provides an overview of this technology. "Advanced Groupware Access Protocol", Iulian Radu, 8-May-13, 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. "Benchmarking Power usage of networking devices", Vishwas Manral, Puneet Sharma, Sujata Banerjee, Yang Ping, 12-Mar-13, With the rapid growth of networks around the globe there is an ever increasing need to improve the energy efficiency of network devices. Operators are begining to seek more information of power consumption in the network, have no standard mechanism to measure, report and compare power usage of different networking equipment under different network configuration and conditions. This document provides suggestions for measuring power usage of live networks under different traffic loads and various switch router configuration settings. It provides a benchmarking suite which can be employed for any networking device . "Implications of Full-Duplex HTTP", Wenbo Zhu, Mike Jennings, 15-May-13, Full-duplex HTTP follows the basic HTTP request-response semantics but also allows the server to send response body to the client at the same time when the client is 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 of full-duplex HTTP on top of the basic HTTP protocol semantics. "Protocol for Stage Illumination", Marcus Ertl, 24-May-13, 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. "A Mechanism for Session Initiation Protocol (SIP) Avalanche Restart Overload Control", Charles Shen, Henning Schulzrinne, Arata Koike, 31-Dec-12, 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. "Additional Methods for Generating Subject Key Identifiers and Subject Key Identifier Semantics Extension", Sean Turner, Stephen Kent, James Manger, 9-Jul-12, This document specifies additional methods for generating Subject Key Identifiers (SKI). This document also specifies an extension to identify the algorithms used to generate the SKI. "Miscellaneous additions to CoAP", Carsten Bormann, Klaus Hartke, 22-May-13, 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. "Uniform Resource Identifier (URI) Scheme for Digital Video Broadcasting (DVB) Programme Resources", Mo McRoberts, Alexander Adolf, 26-Mar-13, 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. "Load Sharing for the Stream Control Transmission Protocol (SCTP)", Paul Amer, Martin Becke, Thomas Dreibholz, Nasif Ekiz, Janardhan Iyengar, Preethi Natarajan, Randall Stewart, Michael Tuexen, 26-Mar-13, 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, 21-Feb-13, The Path Computation Element (PCE) may be used for computing multi- domain (Area or AS) Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered (TE) Label Switch Path (LSP). In this circumstance, 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, 21-Feb-13, The Path Computation Element (PCE) may be used for computing multi- domain (Area or AS) Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered (TE) Label Switch Path (LSP). In this circumstance, 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 L3VPN-based Subnet Extension Solution", KuiKe Building, Susan Hares, Fan Yongbing, Christian Jacquenet, 24-Feb-13, This document describes a Layer3 Virtual Private Network (L3VPN)- based subnet extension solution referred to as Virtual Subnet, which can be used as a kind of Layer3 network virtualization overlay approach for data center interconnect. "Applicability of Stateless automatic IPv4 over IPv6 Encapsulation / Decapsulation Technology (SA46T)", Naoki Matsuhira, 6-Jan-13, 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. "Registry Data Escrow Specification", Francisco Arias, Gustavo Lozano, Shoji Noguchi, 4-Apr-13, This document specifies the format and contents of data escrow deposits targeted primarily for domain name registries. However, the specification was designed to be independent of the underlying objects that are being escrowed, therefore it could be used for purposes other than domain name registries. "Timezone Service Protocol", Mike Douglass, Cyrus Daboo, 29-Nov-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. "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. "Multi-path Label Switched Paths Signaled Using RSVP-TE", Kireeti Kompella, 2-May-13, 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. "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. "Port Management To Reduce Logging In Large-Scale NATs", Tina Tsou, Weibo Li, Tom Taylor, 9-May-13, Various IPv6 transition strategies require the introduction of large- scale NATs (e.g. AFTR, NAT64) to share the limited supply of IPv4 addresses available in the network until transition is complete. There has recently been debate over how to manage the sharing of ports between different subscribers sharing the same IPv4 address. One factor in the discussion is the operational requirement to log the assignment of transport addresses to subscribers. It has been argued that dynamic assignment of individual ports between subscribers requires the generation of an excessive volume of logs. This document suggests a way to achieve dynamic port sharing while keeping log volumes low. "Media Resource Broker (MRB) Location Function (MLF)", Chris Boulton, John Dally, 28-Jan-13, 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. "Hypertext Transfer Protocol (HTTP) Digest Authentication Using GSM 2G Authentication and Key Agreement (AKA)", Lionel Morand, 21-Jan-13, 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. "Default Port for IRC via TLS/SSL", Richard Hartmann, 30-Jul-12, This document describes the commonly accepted practice of listening on TCP port 6697 for incoming IRC connections encrypted via TLS/SSL. "DNSSEC Trust Anchor Publication for the Root Zone", Joe Abley, Jakob Schlyter, Guy Bailey, 16-Dec-12, The root zone of the Domain Name System (DNS) has been cryptographically signed using DNS Security Extensions (DNSSEC). In order to obtain secure answers from the root zone of the DNS using DNSSEC, a client must configure a suitable trust anchor. This document describes how such trust anchors are published. "IPP over HTTPS Transport Binding and 'ipps' URI Scheme", Ira McDonald, Michael Sweet, 12-May-13, 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, 6-May-13, This specification defines how the Uniform Resource Name namespace reserved for the GSMA (GSM 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]. Its purpose is to fulfil the requirements in RFC 5626 [1] that state "If a URN scheme other than UUID is used, the UA MUST only use URNs for which an RFC (from the IETF stream) defines how the specific URN needs to be constructed and used in the "+sip.instance" Contact header field parameter for outbound behavior." "Secure Extension of BGP by Decoupling Path Propagation and Adoption", Mingui Zhang, Bin Liu, Dacheng Zhang, Beichuan Zhang, Beichuan Zhang, 24-Dec-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, 6-Jan-13, 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. "6LoWPAN Generic Compression of Headers and Header-like Payloads", Carsten Bormann, 29-Mar-13, This short I-D provides a simple addition to 6LoWPAN Header Compression that enables the compression of generic headers and header-like payloads, without a need to define a new header compression scheme for each new such header or header-like payload. "Extensions to the Path Computation Element Communication Protocol (PCEP) for Backup Egress of a Traffic Engineering Label Switched Path", Huaimo Chen, 25-Feb-13, 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, 25-Feb-13, 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. "Assessing the Impact of Carrier-Grade NAT on Network Applications", Chris Donley, Lee Howard, Victor Kuarsingh, John Berg, University Colorado, 5-Apr-13, 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. "Definition of Managed Objects for the IPv6 Routing Protocol for Low Power and Lossy Networks (RPL)", Kevin Korte, Juergen Schoenwaelder, Anuj Sehgal, Tina Tsou, Cathy Zhou, 22-Feb-13, 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). "SCTP Socket API Extensions for Concurrent Multipath Transfer", Thomas Dreibholz, Martin Becke, Hakim Adhari, 31-Dec-12, 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, 31-Dec-12, This document describes an extension to the SCTP sockets API for querying information about the sender queue. "HTTP framework for time-based access to resource states -- Memento", Herbert Van de Sompel, Michael Nelson, Robert Sanderson, 29-Mar-13, The HTTP-based Memento framework bridges the present and past Web. It facilitates obtaining representations of prior states of a given resource by introducing datetime negotiation and TimeMaps. Datetime negotiation is a variation on content negotiation that leverages the given resource's URI and a user agent's preferred datetime. TimeMaps are lists that enumerate URIs of resources that encapsulate prior states of the given resource. The framework also facilitates recognizing a resource that encapsulates a frozen prior state of another resource. "Applicability of Proxy Mobile IPv6 Protocol for WLAN Access Networks", Sri Gundavelli, 23-Apr-13, 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. "Commentary on the Design of the Authenticated-Enveloped-Data Content Type", Jim Schaad, 6-Apr-11, The Authenticated-Enveloped-Data Content Type allows for the use of Authenticated-Enveloped modes with block cipher algorithms. At the time of the original design there was discussion about the relative location of the authenticated attributes and the encrypted content in the ASN.1 structure. With the benefits of implementation experience I revisit the discussion made at the time and re-evaluate the decision made. "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. "An XMPP Sub-protocol for WebSocket", Lance Stout, Jack Moffitt, Eric Cestari, 18-May-13, This document defines a binding for the XMPP protocol over a WebSocket transport layer. A WebSocket binding for XMPP provides higher performance than the current HTTP binding for XMPP. "File Transfer Protocol RANG Command for Octet Ranges", Anthony Bryan, Tatsuhiro Tsujikawa, Daniel Stenberg, Tim Kosse, 1-Feb-13, The File Transfer Protocol offers the REST command to designate a starting point for a transfer, but does not currently offer any method to specify an end point. This document specifies a new FTP RANG command to be used by clients to designate an octet range to a file, including a start and end point. This range can be used to permit restarts and repairs of interrupted data transfers in STREAM mode, among other things. "Definition of Managed Objects for SAVI Protocol", Changqing An, Jiahai Yang, Jianping Wu, Jun Bi, 17-Dec-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 objects for managing SAVI (Source Address Validation Improvements) protocol instance. "Cloud SDO Activities Survey and Analysis", Bhumip Khasnabish, JunSheng Chu, 26-Dec-12, The objective of this draft is to present a snapshot of industry standards activities related to cloud 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, JunSheng Chu, Meng Yu, 26-Dec-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, JunSheng Chu, SuAn Ma, So Ning, Paul Unbehagen, Monique Morrow, Masum Hasan, Yuri Demchenko, Meng Yu, 26-Dec-12, This document presents a cloud reference framework that intends to provide a basis for designing interoperable cloud services and their integration into existing open Internet and enterprise IT infrastructures. In general, a cloud-based system utilizes virtualized computing / communications / storage resources and applications, and allows their combined provisioning as complex infrastructure services. In the emerging cloud-based virtualized infrastructures and services are provisioned on on-demand basis, and configured for specific customer needs or tasks. The reference framework is based on the survey of the SDOs and WGs that are focusing on cloud-based systems and services (Cloud SDO, I-D.Khasnabish-cloud-sdo-survey), on-going standardisation activities and other research and developments in the cloud computing technology area. Both intra-cloud and inter-cloud reference frameworks are presented and the requirements to the general functional layers and components 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 (PCP)", Roberta Maglione, Dean Cheng, Mohamed Boucadair, 23-May-13, This document specifies a new Remote Authentication Dial In User Service (RADIUS) attribute to carry a Port Control Protocol (PCP) Server Names. This attribute can be configured on a RADIUS server so that 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-Apr-13, This document describes the addition of the ECN to the Stream Control Transmission Protocol (SCTP). "Analysis of Port Control Protocol (PCP) Failure Scenarios", Mohamed Boucadair, Reinaldo Penno, 16-May-13, This document identifies and analyzes several PCP failure scenarios. Identifying these failure scenarios is useful to assess the efficiency of the protocol and also to decide whether new PCP extensions are needed. "Multicast Support for NAT64", Behcet Sarikaya, Teemu Kiviniemi, 7-Jan-13, 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. "A Session Initiation Protocol (SIP) INFO package for Private Wire", Richard Beauchamp, Finlay Fraser, Chris Boulton, 28-Jan-13, 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. "A Simple Method for Segmenting Multicast Tunnels for Multicast VPNs", Maria Napierala, Eric Rosen, 10-Apr-13, 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. "A Uniform Resource Name Namespace for the Device Identity and the Mobile Equipment Identity (MEID)", Roozbeh Atarius, 21-Feb-13, 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. "PCEP Extension for WSON Routing and Wavelength Assignment", Young Lee, Ramon Casellas, 6-Feb-13, 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, 14-Mar-13, 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. "MPLS-TP Ring Protection Switching (MRPS)", Huub van Helvoort, Jeong-dong Ryoo, 13-Apr-13, 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 [RFC6371]. The Automatic Protection Switching (APS) protocol is used for coordination of protection switching actions between the ring nodes. "Multipath RTP (MPRTP)", Varun Singh, Teemu Karkkainen, Joerg Ott, Saba Ahsan, Lars Eggert, 11-Jan-13, 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. "Diverse Path Implementation Report", Jeff Tantsura, Selma Yilmaz, Keyur Patel, Satish Mynam, Robert Raszuk, 7-May-13, This document provides an implementation report for Diverse Path as defined in RFC6774. 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. "Chain Grant Type for OAuth2", Phil Hunt, 28-Nov-12, This specification defines a method by which an OAuth protected service, can use a received oauth token from its client, to in turn, act as a client and access another OAuth protected service in a 'chained' profile. "Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP", Bob Briscoe, John Kaippallimalil, Patricia Thaler, 25-Feb-13, The purpose of this document is to guide the design of congestion notification in any lower layer or tunnelling protocol that encapsulates IP. The aim is for explicit congestion signals to propagate consistently from lower layer protocols into IP. Then the IP internetwork layer can act as a portability layer to carry congestion notification from non-IP-aware congested nodes up to the transport layer (L4). Following these guidelines should assure interworking between new lower layer congestion notification mechanisms, whether specified by the IETF or other standards bodies. "6LoWPAN Roadmap and Implementation Guide", Carsten Bormann, 13-Apr-13, 6LoWPAN is defined in RFC 4944 in conjunction with a number of specifications that are currently nearing completion. The entirety of these specifications may be hard to understand, pose specific implementation problems, or be simply inconsistent. The present guide aims to provide a roadmap to these documents as well as provide specific advice how to use these specifications in combination. In certain cases, it may provide clarifications or even corrections to the specifications referenced. This guide is intended as a continued work-in-progress, i.e. a long- lived Internet-Draft, to be updated whenever new information becomes available and new consensus on how to handle issues is formed. Similar to the ROHC implementation guide, RFC 4815, it might be published as an RFC at some future time later in the maintenance curve of the specifications. This document does not describe a new protocol or attempt to set a new standard of any kind - it mostly describes good practice in using the existing specifications, but it may also document emerging consensus where a correction needs to be made. "A Forward-Search P2P TE LSP Inter-Domain Path Computation", Huaimo Chen, Dhruv Dhody, 29-Apr-13, 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 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. "The FNV Non-Cryptographic Hash Algorithm", Glenn Fowler, Landon Noll, Kiem-Phong Vo, Donald Eastlake, 6-Apr-13, 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. "Security Considerations in the IP-based Internet of Things", Oscar Garcia-Morchon, Sye Keoh, Sandeep Kumar, Rene Hummen, Rene Struik, 11-Mar-13, 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. "DECADE Protocol", Richard Alimi, Akbar Rahman, Dirk Kutscher, Yang Yang, Haibin Song, Kostas Pentikousis, 7-Feb-13, 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 provided by a DECADE (DECoupled Application Data Enroute) compatible system. This document presents an architecture, discusses the underlying principles, and identifies key functionalities in the architecture for introducing a DECADE in- network storage system. In addition, some examples are given to illustrate these concepts. "Alternatives for Multilevel TRILL (Transparent Interconnection of Lots of Links)", Radia Perlman, Donald Eastlake, Anoop Ghanwani, ZTE Corporation, 5-Dec-12, This is an informational document describing issues and comparing general advantages and disadvantages of various approaches to extending TRILL (Transparent Interconnection of Lot of Links) to use multilevel IS-IS (Intermediate System to Intermediate System) routing to improve TRILL's scalability. "Data Center Mobility based on E-VPN, BGP/MPLS IP VPN, IP Routing and NHRP", Rahul Aggarwal, Yakov Rekhter, Wim Henderickx, Ravi Shekhar, Luyuan Fang, Ali Sajassi, 17-Dec-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, E-VPNs, BGP/MPLS IP VPNs, and NHRP. "A packet based method for passive performance monitoring", Alessandro Capello, Mauro Cociglio, Luca Castaldelli, Alberto Bonda, 25-Feb-13, This document describes a passive method to perform packet loss, delay and jitter measurements on live traffic. Implementation and deployment details are also explained in order to clarify how the tools and features currently available on existing routing platforms can be used to implement the method. This method has been invented and engineered in Telecom Italia and it's currently being used in Telecom Italia's network. "Port Control Protocol (PCP) Extension for Port Set Allocation", Qiong Sun, Mohamed Boucadair, Senthil Sivakumar, Cathy Zhou, Tina Tsou, Simon Perreault, 25-Feb-13, This document defines an extension to PCP allowing clients to manipulate sets of ports as a whole. This is accomplished by a new MAP option: PORT_SET. "Multipath TCP Support for Single-homed End-systems", Rolf Winter, Andreas Ripke, 25-Feb-13, Multipath TCP relies on the existence of multiple paths at the end- systems typically provided through different IP addresses obtained by different ISPs. While this scenario is certainly becoming increasingly a reality (e.g. mobile devices), currently most end- systems are single-homed (e.g. desktop PCs in an enterprise). This memo describes mechanisms to make multiple paths available to multipath TCP-capable end-systems that are not available directly at the end-systems but somewhere within the network. "Applicability of Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI)", Fatai Zhang, Oscar de Dios, Adrian Farrel, Xian Zhang, Daniele Ceccarelli, 21-Feb-13, Generalized Multiprotocol Label Switching (GMPLS) defines a set 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 suggests simple extensions that could be made to existing technologies to further enable the UNI and points out some unresolved issues. "Adaptive VLAN Assignment for Data Center RBridges", Mingui Zhang, Dacheng Zhang, 23-Apr-13, 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 mechanism 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 (DFF)", Ulrich Herberg, Alvaro Cardenas, Tadashige Iwao, Michael Dow, Sandra Cespedes, 7-May-13, This document specifies the "Depth-First Forwarding" (DFF) protocol for IPv6 networks, a data forwarding mechanism that can increase reliability of data delivery in networks with dynamic topology and/or lossy links. The protocol operates entirely on the forwarding plane, but may interact with the routing plane. DFF forwards data packets using a mechanism similar to a "depth-first search" for the destination of a packet. The routing plane may be informed of failures to deliver a packet or loops. This document specifies the DFF mechanism both for IPv6 networks (as specified in RFC2460) and in addition also for LoWPAN "mesh-under" networks (as specified in RFC4944). The design of DFF assumes that the underlying link layer provides means to detect if a packet has been successfully delivered to the next hop or not. It is applicable for networks with little traffic, and is used for unicast transmissions only. "A Forward-Search P2MP TE LSP Inter-Domain Path Computation", Huaimo Chen, Dhruv Dhody, 29-Apr-13, This document presents a forward search procedure for computing a path for a Point-to-MultiPoint (P2MP) Traffic Engineering (TE) Label Switched Path (LSP) 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. "On demand IPv4 address provisioning in Dual-Stack PPP deployment scenarios", Karsten Fleischhauer, Olaf Bonness, 12-Mar-13, 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, whereas 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. "Route Flap Damping Deployment Status Survey", Shishio Tsuchiya, Seiichi Kawamura, Randy Bush, Cristel Pelsser, 21-Jun-12, 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 among service provider on their use of BGP Route Flap Damping. "Transport of Fast Notification Messages", Wenhu Lu, Sriganesh Kini, Andras Csaszar, Gabor Envedi, Jeff Tantsura, 25-Feb-13, This document specifies mechanisms for fast and light-weight dissemination of event notifications. The purpose is to enable dataplane dissemination of Fast Notifications (FNs). The draft discusses the design goals, the message container and options for delivering the notifications to all routers within a routing area. "Layer 2 (L2) LISP Encapsulation Format", Michael Smith, Dinesh Dutt, Dino Farinacci, Fabio Maino, 24-Jan-13, This memo describes an encapsulation method for carrying Ethernet and IEEE 802 media access control (MAC) frames within the Locator/ID Separation Protocol (LISP). "Deterministic Usage of DSA and ECDSA Digital Signature Algorithms", Thomas Pornin, 27-Aug-12, This document defines a deterministic digital signature generation procedure. Such signatures are compatible with standard DSA and ECDSA digital signatures, and can be processed with unmodified verifiers, which need not be aware of the procedure described therein. Deterministic signatures retain the cryptographic security features associated with digital signatures, but can be more easily implemented in various environments since they do not need access to a source of high quality randomness. "IPv4 and IPv6 Options to support Information Centric Networking", Andrea Detti, Stefano Salsano, Nicola Blefari-Melazzi, 30-Nov-12, 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, 16-Dec-12, 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. "Verification Involving PSTN Reachability: Requirements and Architecture Overview", Mary Barnes, Cullen Jennings, Jonathan Rosenberg, Marc Petit-Huguenin, 25-Feb-13, 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. "A SAVI solution for WLAN", Jun Bi, Jianping Wu, You Wang, Tao Lin, 5-Feb-13, 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 binding entries when hosts move from one access point to another. "Launch Phase Mapping for the Extensible Provisioning Protocol (EPP)", James Gould, Wil Tan, Gavin Brown, 17-May-13, This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of domain name registrations and applications during the launch of a domain name registry. "Extensions to Path Computation Element Communication Protocol (PCEP) for Hierarchical Path Computation Elements (PCE)", Fatai Zhang, Quintin Zhao, Oscar de Dios, Ramon Casellas, Daniel King, 25-Feb-13, The Hierarchical Path Computation Element (H-PCE) architecture, defined in the companion framework document [RFC6805], provides a mechanism 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. This document defines the Path Computation Element Protocol (PCEP) extensions for the purpose of implementing Hierarchical PCE procedures which are described in the aforementioned document. "Indicating Character Encoding and Language for HTTP Header Field Parameters", Julian Reschke, 10-Dec-12, 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. "Standardised ECC Cipher Suites for TLS", Peter Gutmann, 20-Mar-13, 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. "URI Fragment Identifiers for the text/csv Media Type", Michael Hausenblas, Erik Wilde, Jeni Tennison, 3-May-13, This memo defines URI fragment identifiers for text/csv MIME entities. These fragment identifiers make it possible to refer to parts of a text/csv MIME entity, identified by row, column, or cell. Fragment identification can use single items, or ranges. Note to Readers This draft should be discussed on the apps-discuss mailing list [11]. Online access to all versions and files is available on github [12]. "IPv6 Multicast in a 6rd Deployment", Behcet Sarikaya, Tina Tsou, Hui Ji, Cathy Zhou, 13-Mar-13, This memo specifies 6rd's multicast component so that IPv6 hosts can receive multicast data from IPv6 servers. In the 6rd encapsulation solution, multicast communication is completely integrated into the 6rd tunnel. In the 6rd translation solution, the protocol is based on proxying MLD at the 6rd Customer Edge router interworking the MLD messages to IGMP messages and sending them upstream through a network which supports IPv4 multicast. The 6rd Border Relay is a multicast router and interworks the IGMP to MLD for onward propasgation toward the IPv6 multicast source. IPv6 Multicast data received at 6rd Border Relay is translated into IPv4 multicast data and and delivered through the IPv4 multicast tree downstream to the 6rd Customer Edge. The latter translates it back to IPv6 multicast data then delivers it to the hosts. "Operational Guidance for IPv6 Deployment in IPv4 Sites using ISATAP", Fred Templin, 18-Apr-13, 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 provides satisfactory internal routing and addressing services for most applications. As more and more IPv6-only services are deployed, however, end user devices within such sites will increasingly require at least basic IPv6 functionality. This document therefore provides operational guidance for deployment of IPv6 within predominantly IPv4 sites using the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP). "RADIUS Extensions for Port Set Configuration and Reporting", Dean Cheng, Jouni Korhonen, Mohamed Boucadair, Senthil Sivakumar, 21-May-13, This document defines new RADIUS attributes that can be used by a device implementing port ranges to communicate with a RADIUS server to configure and/or report TCP/UDP port sets and ICMP identifiers mapping behavior for specific hosts. This mechanism can be used in various deployment scenarios such as CGN, NAT64, Provider WiFi Gateway, etc. This document does not make any assumption about the deployment context. "A Taxonomy on Private Use Fields in Protocols", Chris Lonvick, 23-Mar-13, 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-Segment Pseudowire Signaling with Availability Information", Hao Long, Min Ye, 18-Feb-13, This document describes a signaling mechanism for setting up a multi-segment pseudowire between different domains in case that at least one domain has the feature that bandwidth capacity is variable for different availability values. The signaling mechanism is an extension on the multi-segment pseudowire signaling [DYN-MS-PW]. "HTTP Origin and Hop Hints", Mark Nottingham, 11-Feb-13, Over time, HTTP clients -- especially Web browsers -- have adapted how they use the protocol based upon common server configurations and behaviours. While this is necessary in the common case, it can be detrimental for performance and interoperability. This document establishes a mechanism whereby both origin servers and intermediaries can make hints available to clients about their preferences and capabilities, without imposing undue overhead on their interactions or requiring support for them. This is intended to allow clients to safely optimise connections to servers. "Inter-Carrier OAM Requirements", Michael Georgiades, Filippo Cugini, David Berechya, Oscar de Dios, 26-Nov-12, 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, but aims to differentiate and focus on the requirements and additional requirements resulting from inter- operator considerations only. "Linked Cache Invalidation", Mark Nottingham, Mike Kelly, 20-Dec-12, This memo defines two new link types that indicate relationships between resources in terms of cache invalidation, along with a HTTP cache-control extension that takes advantage of those relationships to use them to extend response freshness. Collectively, this is referred to as Linked Cache Invalidation (LCI). "File Transfer Protocol LOCK Command for Using a Single Port", Anthony Bryan, Daniel Stenberg, Tatsuhiro Tsujikawa, 1-Feb-13, One of the biggest hurdles for FTP in real life usage is its use of two connections. First, it uses a primary connection to send control commands on, and when it sends or receives data, it opens a second TCP stream for that purpose. This document specifies a new FTP LOCK command to be used by clients to request the server to use the control connection for data transfers, using a single port instead of two. "RTP Payload Format for G.711.0", Michael Ramalho, Paul Jones, Noboru Harada, Muthu Perumal, Miao Lei, 28-Mar-13, This document specifies the Real-Time Transport Protocol (RTP) payload format for ITU-T Recommendation G.711.0. ITU-T Rec. G.711.0 defines a lossless and stateless compression for G.711 packet payloads typically used in IP networks. This document also defines a storage mode format for G.711.0 and a media type registration for the G.711.0 RTP payload format. "Home Agent Initiated Flow Binding for Mobile IPv6", Hidetoshi Yokota, Dae-Sun Kim, Behcet Sarikaya, Frank Xia, 28-Dec-12, 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. "Requirements of GMPLS Extensions for Energy Efficient Traffic Engineering", Satoru Okamoto, 14-Mar-13, This document discusses some of extensions required in existing GMPLS OSPF routing protocol, RSVP signaling protocol, and LMP to support the energy efficient traffic engineering technology. "CoRE Resource Directory", Zach Shelby, Srdjan Krco, Carsten Bormann, 25-Feb-13, In many M2M applications, 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 register, maintain, lookup and remove resources descriptions. Furthermore, new link attributes useful in conjunction with an RD are defined. "Encoding of Data Structure (DS) in the Path Computation Element Communication Protocol (PCEP)", Dhruv Dhody, Udayasree Palle, 21-Feb-13, 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 point-to-point (P2P) and point- to-multipoint (P2MP) scenarios. Backward-Recursive Path Computation (BRPC) [RFC5441] defines Virtual Shortest Path Tree (VSPT) as a default de-facto data structure for path reply message in inter- domain scenarios. As Path Computation Element (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]) as well as in [ABNO]. Limiting PCE communication Protocol (PCEP) 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 PCEP to allow multiple data structures. Extensions are defined for PCE to indicate the set of Data Structure (DS) it supports; also Path Computation Client (PCC) or 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 inclusion or exclusion of abstract nodes for a subset of P2MP destinations in Path Computation Element Communication Protocol (PCEP).", Dhruv Dhody, Udayasree Palle, Venugopal Kondreddy, 15-Apr-13, 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 path computation via PCE. This document describes the motivation and PCE communication Protocol (PCEP) extension for explicitly specifying abstract nodes for inclusion or exclusion for a subset of destinations during the Point to Multipoint (P2MP) path computation via PCE. "Security Framework for Virtualized Data Center Services", Suren Karavettil, Bhumip Khasnabish, So Ning, Wei Dong, 26-Dec-12, 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. "One Hop Lookups Algorithm Plugin for RELOAD", Jin Peng, Yu Qing, Yuan Li, 18-Feb-13, This document defines a specific Topology Plugin using a ramification of the basic One Hop Lookups based DHT algorithm which is called ONE- HOP-RELOAD. In the One Hop Lookups algorithm, each peer maintains a full routing table containing information about every node on the overlay in order to route RELOAD message in one hop. Compared with CHORD-RELOAD algorithm, ONE-HOP-RELOAD improves the routing efficiency, and can maintain complete membership information with reasonable bandwidth requirements. This algorithm is able to handle frequent membership changes by superimposing a well-defined hierarchy on the system that guarantees topology disturbance events notification reach every peer in the overlay within a specified amount of time. Currently some typical peer-to-peer storages systems have stringent latency requirements, such as Amazon's Dynamo which is built for latency sensitive applications uses One-Hop algorithm, so that each node maintains enough routing information locally to route a request to the appropriate node directly. "Proposals for RELOAD to support Promotion and Demotion for User-owned Nodes", Jin Peng, Deng Lingli, Lifeng Le, Gang Li, Xiao Ma, 18-Feb-13, 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, Li Yizhou, Anoop Ghanwani, 7-Jan-13, TRILL (TRansparent Interconnection of Lots of Links) Data frames can be encoded so as to make more efficient use of communications links under certain circumstances. This document specifies two such optional optimizations. One, called Compact Format, improves the compactness of encoding 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. This document updates RFC 6325. "In-Band Authentication Extension for Protocol Independent Multicast", Manav Bhatia, Dacheng Zhang, Bharat Joshi, 27-Mar-13, Existing security mechanisms for the Protocol Independent Multicast - Sparse Mode (PIM-SM) routing protocol mandates the use of IPsec to provide message authenticity and integrity. This draft proposes an embedded authentication mechanism to facilitate data origin authentication and integrity verification for PIM packets in the cases where IPsec cannot be applied. "User-Managed Access (UMA) Profile of OAuth 2.0", Thomas Hardjono, 27-Dec-12, User-Managed Access (UMA) is a profile of OAuth 2.0. UMA defines how resource owners can control access to their protected resources made by clients operated by arbitrary rquesting parties, where the resources reside on any number of resource servers, and where a centralized authorization server governs access based on resource owner policy. "Motivation for developing Stateless Automatic IPv4 over IPv6 Encapsulation / Decapsulation Technology (SA46T)", Naoki Matsuhira, 6-Jan-13, 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). "Cisco Specific Information Elements reused in IPFIX", Andrew Yourtchenko, Paul Aitken, Benoit Claise, 25-Feb-13, This document describes some additional Information Elements of Cisco Systems, Inc. that are not listed in RFC3954. "RO Extensions for PMIPv6-LR (ROEXT)", Michael Boc, Christophe Janneteau, Alexandru Petrescu, 22-Apr-13, The communication path between two Hosts within a Proxy Mobile IPv6 domain is artificially long - it involves the LMA, even if straight paths exist (under same MAG, or MAG-to-MAG). Localized Routing PMIPv6-LR concepts developped by NETEXT WG make use of LRI/LRA messages to achieve optimized MAG-to-MAG straight paths. This may prove inconvenient for the network operator, in that it may loose ability to control traffic (LMA control point is skipped). In this draft we present a middle-ground solution. It employs new Intermediary Anchors (IAs) in the paths between MAGs and offers points of control of traffic useful for QoS and lawful interception. "Best Practices for HTTP-CoAP Mapping Implementation", Angelo Castellani, Salvatore Loreto, Akbar Rahman, Thomas Fossati, Esko Dijk, 25-Feb-13, This draft provides reference information for HTTP-CoAP protocol translation proxy implementors, focusing primarily on the reverse proxy case. It details deployment options, discusses possible approaches for URI mapping, and provides a set of guidelines and considerations related to protocol translation. "RBridge: Pseudo-Nickname", ZTE Corporation, Tissa Senevirathne, Radia Perlman, Donald Eastlake, Mingui Zhang, fangwei hu, 12-Dec-12, RBridges provide frame forwarding service to layer2 switches or end stations at the edge of TRILL campus. As defined in [RFC6325], when there are multiple RBridges attached to the same LAN segment, only one edge RBridge is allowed to be the frame forwarder of a specific VLAN in order to avoid potential frame duplication and loops in the TRILL campus. However, in some application scenarios, for example an end station is multi-homed to multiple RBridges needs to improve the resiliency and increase the available network bandwidth of the connection. This means all those RBriges attached to the end station can act as the frame forwarders of a specific VLAN. This kind of active-active connection violates the definition above. Frame duplication and forwarding loops may happen and it may cause the flip-flopping of the egress RBridge nickname associated to the MAC address of such an end station in remote RBridges' forwarding tables. The Reverse Path Forwarding Check does not work as well, which has been addressed in [CMT]. This document proposes the concept of Virtual RBridge, along with the pseudo-nickname configuration for this Virtual RBridge, to address the above problems in accompany with [CMT]. "Some Measurements on World IPv6 Day from End-User Perspective", Ari Keränen, Jari Arkko, 11-Sep-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. "BGP Flow-Spec Extended Community for Traffic Redirect to IP Next Hop", James Uttaro, Matthieu Texier, David Smith, Pradosh Mohapatra, Wim Henderickx, Adam Simpson, 26-Nov-12, Flow-spec is an extension to BGP that allows for the dissemination of traffic flow specification rules. This has many possible applications but the primary one for many network operators is the distribution of traffic filtering actions for DDoS mitigation. The flow-spec standard [RFC 5575] defines a redirect-to-VRF action for policy-based forwarding but this mechanism can be difficult to use, particularly in networks without L3 VPNs. This draft proposes a new redirect-to-IP flow-spec action that provides a simpler method of policy-based forwarding. This action is indicated by the presence of a new BGP extended community in the flow-spec route. Many routers already support a redirect-to-IP filter action and, in this case, the only new functionality implied by this draft is the ability to signal the action using flow-spec. "Application Bridging for Federated Access Beyond web (ABFAB) Usability and User Interface Considerations", Rhys Smith, 8-Jan-13, The use of ABFAB-based technologies requires that each user's device is configured with the user's identities that they wish to use in ABFAB transactions. This will require something on that device, either built into the operating system or a standalone utility, that will manage the user's identities and identity to service mappings. Anyone designing that "something" will face the same set of challenges. This document aims to document these challenges with the aim of producing well-thought out UIs with some degree of consistency. "BGPSEC Design Choices and Summary of Supporting Discussions", Kotikalapudi Sriram, 6-Jan-13, This document has been written to capture the design rationale for the individual draft-00 version of BGPSEC protocol specification (I-D.lepinski-bgpsec-protocol-00). It lists the decisions that were 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", DH, Hitoshi Asaeda, 12-Feb-13, This document describes an extension of the Context Transfer Protocol (CXTP) to support seamless IP multicast services with Proxy Mobile IPv6 (PMIPv6). "Mediated RSA cryptography specification for additive private key splitting (mRSAA)", Miroslaw Kutylowski, Przemyslaw Kubiak, Michal Tabor, Daniel Wachnik, 5-Nov-12, 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]. "The Universal Voting Markup Language (UVML)", Erin Phillips, 11-Jan-13, 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. "PW Endpoint Fast Failure Protection", Yimin Shen, Rahul Aggarwal, Wim Henderickx, 8-Feb-13, This document specifies a fast mechanism for protecting pseudowires (PWs) against egress endpoint failures, including egress attachment circuit failure, egress PE failure, multi-segment PW terminating PE failure, and multi-segment PW switching PE failure. Designed on the basis of multi-homed CE, PW redundancy, upstream label assignment and context specific label switching, the mechanism enables local repair to be performed by a router upstream adjacent to a failure. In particular, the router can restore PW traffic in the order of tens of milliseconds, by transmitting the traffic to a protector through a pre-established bypass tunnel. Therefore, the mechanism can be used to reduce traffic loss before a global repair mechanism reacts to the failure or the network converges on the topology changes due to the failure. "Generalized Label for Super-Channel Assignment on Flexible Grid", Iftekhar Hussain, Zhong Pan, Marco Sosa, Andrew Malis, Abinder Dhillon, 13-Apr-13, 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", Reinaldo Penno, Simon Perreault, Sarat Kamiset, Mohamed Boucadair, Kengo Naito, 7-Jan-13, 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. "Energy Management Terminology", John Parello, 23-Apr-13, 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, Panagiotis Trakadas, 23-Nov-12, 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. "The Interior Routing Overlay Network (IRON)", Fred Templin, 3-May-13, Since large-scale Internetworks such as the public Internet must continue to support escalating growth due to increasing demand, it is clear that Autonomous Systems (ASes) must avoid injecting excessive de-aggregated prefixes into the interdomain routing system and instead mitigate de-aggregation internally. This document describes an Interior Routing Overlay Network (IRON) architecture that supports sustainable growth within AS-interior routing domains while requiring no changes to end systems and no changes to the exterior routing system. In addition to routing scaling, IRON further addresses other important issues including mobility management, mobile networks, multihoming, traffic engineering, NAT traversal and security. While business considerations are an important determining factor for widespread adoption, they are out of scope for this document. "Security Labels in Internet Email", Kurt Zeilenga, Alexey Melnikov, 4-Apr-13, This document describes a header field, SIO-Label, for use in Internet Mail to convey the sensitivity of the message. This 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. This document also describes a header field, SIO-Label-History, for recording changes in the message's label. "An Extension Language for the DNS", John Levine, Paul Vixie, 18-Dec-12, 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 entries to configuration data read by the DNS software, with no software changes needed for each RRTYPE. "VXLAN: A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", Mallik Mahalingam, Dinesh Dutt, Kenneth Duda, Puneet Agarwal, Lawrence Kreeger, T. Sridhar, Mike Bursell, Chris Wright, 8-May-13, 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. "Extensions to the Path Computation Element Communication Protocol (PCEP) to compute service aware Label Switched Path (LSP).", Dhruv Dhody, Vishwas Manral, Zafar Ali, George Swallow, Kenji Kumaki, 25-Feb-13, 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 (delay), Latency-Variation (jitter) and Packet loss as properties. [OSPF-TE-EXPRESS] and [ISIS-TE-EXPRESS] describes mechanisms with which network performance information is distributed via OSPF and ISIS respectively. This document describes the extension to PCEP to carry Latency, Latency-Variation and Loss as constraints for end to end path computation. "NVGRE: Network Virtualization using Generic Routing Encapsulation", Murari Sridharan, Albert Greenberg, Narasimhan Venkataramaiah, Yu-Shun Wang, Kenneth Duda, Ilango Ganga, Geng Lin, Mark Pearson, Patricia Thaler, Chait Tumuluri, 24-Feb-13, This document describes the usage of Generic Routing Encapsulation (GRE) header for Network Virtualization (NVGRE) in multi-tenant datacenters. Network Virtualization decouples virtual networks and addresses from physical network infrastructure, providing isolation and concurrency between multiple virtual networks on the same physical network infrastructure. This document also introduces a Network Virtualization framework to illustrate the use cases, but the focus is on specifying the data plane aspect of NVGRE. "SA46T Multicast Support", Naoki Matsuhira, 30-Mar-13, This document describe Stateless Automatic IPv4 over IPv6 Encapsulation / Decapsutation Technology (SA46T) multicast support. IPv4 multicast is supported by SA46T with same manner with IPv4 unicast. SA46T multicast address prefix is defined. "Deterministic Address Mapping to Reduce Logging in Carrier Grade NAT Deployments", Chris Donley, Chris Grundemann, Vikas Sarawat, Karthik Sundaresan, Olivier Vautrin, 12-Jan-13, In some instances, Service Providers have a legal logging requirement to be able to map a subscriber's inside address with the address used on the public Internet (e.g. for abuse response). Unfortunately, many Carrier Grade NAT logging solutions require active logging of dynamic translations. Carrier Grade NAT port assignments are often per-connection, but could optionally use port ranges. Research indicates that per-connection logging is not scalable in 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. While the authors acknowledge that IPv6 is a preferred solution, Carrier Grade NAT is a reality in many networks, and is needed in situations where either customer equipment or Internet content only supports IPv4; this approach should in no way slow the deployment of IPv6. "TFRC-based Congestion Control for Saratoga", Wesley Eddy, Lloyd Wood, Will Ivancic, 21-Apr-13, 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. "Congestion control for the Saratoga protocol", Lloyd Wood, Wesley Eddy, Will Ivancic, 21-Apr-13, 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. "DHCP Options for 3GPP Service", Guoyan Liu, Yangwei Tu, Chunhui Zhu, Wim Henderickx, Daniel Derksen, Laurent Thiebaut, 12-Mar-13, This document defines a new option that can be used by DHCP clients in their signaling sent to DHCP servers, when those clients need to associate a request for an IP address or IPv6 prefix with a given 3GPP packet service.It is intended for scenarios of interworking between a non-3GPP access and a 3GPP network. "HO from 3GPP to a trusted non-3GPP access", Guoyan Liu, Yangwei Tu, Chunhui Zhu, 15-Feb-13, This document adds DHCP client and server behavior description in a scenario for handover from 3GPP to a trusted non-3GPP access. "Lightweight Directory Access Protocol (LDAP): Schema for Printer Services", Pat Fleming, Ira McDonald, 17-May-13, This document defines a schema, object classes and attributes, for Printers and Print 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). Additional Printer attributes are based on definitions in the Printer MIB v2 (RFC 3805), IEEE-ISTO PWG Command Set for IEEE 1284 Device ID (PWG 5107.2), IEEE-ISTO PWG IPP Job and Printer Extensions - Set 3 (PWG 5100.13), and IEEE-ISTO PWG IPP Everywhere (PWG 5100.14). This document is published by the IETF on behalf of the Internet Printing Protocol Working Group of the IEEE-ISTO Printer Working Group. This document updates RFC 3712. "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. "LDP Bindings Refresh", Andre Pelletier, Kamran Raza, 25-Feb-13, 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. "Generalized Labels for the Flexi-Grid in Lambda Switch Capable (LSC) Label Switching Routers", Daniel King, Adrian Farrel, Yao Li, 9-Apr-13, GMPLS supports the description of optical switching by identifying entries in fixed lists of switchable wavelengths (called grids) through the encoding of lambda labels. Work within the ITU-T Study Group 15 has defined a finer granularity grid, and the facility to flexibly select different widths of spectrum from the grid. This document defines a new GMPLS lambda label format to support this flexi-grid. This document updates RFC 3471 and RFC 6205 by introducing a new label format. "IS-IS Traffic Engineering (TE) Metric Extensions", Stefano Previdi, Spencer Giacalone, David Ward, John Drake, Alia Atlas, Clarence Filsfils, 25-Feb-13, 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 Metric Extensions 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. "Multiple RTP Sessions on a Single Lower-Layer Transport", Magnus Westerlund, Colin Perkins, 25-Feb-13, This memo defines a mechanism to allow multiple RTP sessions to be multiplexed onto a single lower-layer transport flow (e.g., onto a single UDP 5-tuple). Requirements for multiplexing RTP sessions are discussed, along with the trade-off between the different options. A shim-based multiplexing layer is proposed, along with associated signalling. "Securing Header Fields with S/MIME", Laurent Cailleux, Chris Bonatti, 10-Jan-13, 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'. "PCP Support for Nested NAT Environments", Reinaldo Penno, Dan Wing, Mohamed Boucadair, 21-Jan-13, 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 NATs with varying levels of PCP protocol support. "Multicast Support for MAP-E", Behcet Sarikaya, 19-Feb-13, This memo specifies MAP-E (together with MAP-T and 4rd)'s multicast component so that IPv4 hosts can receive multicast data from IPv4 servers over an IPv6 network. In the encapsulation solution for encapsulation variant of Mapping of Address and Port (MAP), MAP-E, IGMP Proxy at the MAP-E Customer Edge router uses IPv4-in-IPv6 tunnel established by MAP-E to exchange IGMP messages to establish multicast state at MAP-E Border Relay so that MAP-E Border Relay can tunnel IPv4 multicast data to IPv4 hosts connected to MAP-E Customer Edge device. In the Translation Multicast solution for the translation variant of MAP, MAP-T and 4rd, IGMP messages are translated into MLD messages at the CE router which is IGMP/MLD Proxy and sent to the network in IPv6. MAP-T/4rd Border Relay does the reverse translation and joins IPv4 multicast group for MAP-T/4rd hosts. Border Relay as multicast router receives IPv4 multicast data and translates the packet into IPv6 multicast data and sends downstream on the multicast tree. Member CEs receive multicast data, translate it back to IPv4 and transmit to the hosts. "Negotiation for Keying Pairwise Routing Protocols in IKEv2", Mahesh Jethanandani, Brian Weis, Keyur Patel, Dacheng Zhang, Sam Hartman, Uma Chunduri, Albert Tian, Joseph Touch, 25-Feb-13, This document describes a mechanism to secure the routing protocols which use unicast to transport their signaling messages. Most of such routing protocols are TCP-based (e.g., BGP and LDP), and the TCP Authentication Option (TCP-AO) is primarily employed for securing the signaling messages of these routing protocols. There are also two exceptions: BFD which is over UDP or MPLS, and RSVP-TE which is over IP (but employs an integrated approach to protecting the signaling messages instead of using IPsec). The proposed mechanism secures pairwise TCP-based Routing Protocol (RP) associations, BFD associations and RSVP-TE associations using the IKEv2 Key Management Protocol (KMP) integrated with TCP-AO, BFD, and RSVP-TE respectively. Included are extensions to IKEv2 and its Security Associations to enable its key negotiation to support TCP-AO, BFD, and RSVP-TE. "A Hierarchical Mapping System for LISP", Hongke Zhang, Zhengxin Zhang, 18-Dec-12, 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, Piers O'Hanlon, 8-Mar-13, This document presents an examination of various responses 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 [rfc6679], which specifies the signaling used to provide ECN support for RTP/RTCP flows. "PIM source discovery via BSR", IJsbrand Wijnands, Stig Venaas, Michael Brig, 20-Dec-12, 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. "DHCPv6 class based prefix", Cisco Systems, Gaurav Halwasia, Sri Gundavelli, Hui Deng, Laurent Thiebaut, Jouni Korhonen, 18-Feb-13, This document introduces options to communicate property and associate metadata with prefixes. It extends DHCPv6 prefix delegation and address allocation using the metadata for selection of prefixes and addresses. "Guidance of Using Unique Local Addresses", Bing Liu, Sheng Jiang, Cameron Byrne, 25-Feb-13, This document provides guidance of how to use ULA. It analyzes ULA usage scenarios and recommends use cases where ULA address may be beneficially used. "Extended IPv6 Addressing for Encoding Port Range", Congxiao Bao, Xing Li, 31-Dec-12, 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. "OSPF Topology-Transparent Zone", Huaimo Chen, Renwei Li, Gregory Cauchie, So Ning, Lei Liu, Alvaro Retana, 3-May-13, 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, 25-Feb-13, This draft describes how data center network can benefit from non- RBridge nodes performing TRILL encapsulation with assistance from directory service. "Prefix Assignment in a Home Network", Jari Arkko, Acee Lindem, Benjamin Paterson, 23-May-13, This memo describes a prefix assignment mechanism for home networks. It is expected that home gateway routers are allocated an IPv6 prefix through DHCPv6 Prefix Delegation (PD) or that a prefix is made available through other means. This prefix needs to be divided among the multiple subnets in a home network. This memo describes a mechanism for such division, or assignment, via OSPFv3. This is an alternative design to also using DHCPv6 PD for the 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. "Transport of CoAP over SMS, USSD and GPRS", Markus Becker, Kepeng Li, Koojana Kuladinithi, Thomas Poetsch, 4-Feb-13, The Short Message Service (SMS) and Unstructured Supplementary Service Data (USSD) 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 adaptation of CoAP to the SMS or USSD transport mechanisms and the combination with IP transported over cellular networks is described in this document. "IS-IS Extended Sequence number TLV", Uma Chunduri, Wenhu Lu, Albert Tian, Naiming Shen, 18-Jan-13, 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, 16-Jan-13, 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. "A framework for RPs to use IKEv2 KMP", Uma Chunduri, Albert Tian, Joseph Touch, 25-Feb-13, This document describes a mechanism to secure pairwise Routing Protocol associations using the IKEv2 Key Management Protocol (KMP). Most of the pairwise Routing Protocols (RPs) are TCP-based but the framework described here is applicable to other pairwise RPs, which not necessarily use the TCP at transport layer. A Gatekeeper mechanism is introduced to allow all pairwise RPs to coordinate with IKEv2 Protocol to pass the policy, get the keying material and to maintain the security associations. The Gatekeeper also allows pairwise RPs which use TCP-AO to coordinate with IKEv2 without fundamental modification to either. "The Lightweight On-demand Ad hoc Distance-vector Routing Protocol - Next Generation (LOADng)", Thomas Clausen, Axel Verdiere, Jiazi Yi, Afshin Niktash, Yuichi Igarashi, Hiroki Satoh, Ulrich Herberg, Cedric Lavenu, Thierry Lys, Charles Perkins, Justin Dean, 11-Jan-13, This document describes the Lightweight Ad hoc On-Demand - Next Generation (LOADng) distance vector routing protocol, a reactive routing protocol intended for use in Mobile Ad hoc NETworks (MANETs). "OSPFTE extension to support GMPLS for Flex Grid", Abinder Dhillon, Iftekhar Hussain, Rajan Rao, Marco Sosa, 21-Nov-12, This document specifies the extension to TELINK LSA of OSPF routing protocol [RFC4203] [3] in support of GMPLS [1] for flex-grid networks [2]. "IP VPN Scaling Considerations", Wesley George, Rob Shakir, 21-Dec-12, 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. "Internet Exchange Route Server Operations", Nick Hilliard, Elisa Jasinska, Robert Raszuk, Niels Bakker, 4-Dec-12, The popularity of Internet exchange points (IXPs) brings new challenges to interconnecting networks. While bilateral eBGP sessions between exchange participants were historically the most common means of exchanging reachability information over an IXP, the overhead associated with this interconnection method causes serious operational and administrative scaling problems for IXP participants. Multilateral interconnection using Internet route servers can dramatically reduce the administrative and operational overhead of IXP participation and these systems used by many IXP participants as a preferred means of exchanging routing information. This document describes operational considerations for multilateral interconnections at IXPs. "Interoperability Report for the Lightweight On-demand Ad hoc Distance- vector Routing Protocol - Next Generation (LOADng)", Thomas Clausen, Alberto Camacho, Jiazi Yi, Axel Verdiere, Yuichi Igarashi, Hiroki Satoh, Yoko Morii, Ulrich Herberg, Cedric Lavenu, 11-Dec-12, This document reports experience with the LOADng routing protocol, as obtained by way of a number of interoperability tests during the protocol development. "MPLS-TP protection for interconnected rings", Guoman Liu, Masahiro Daikoku, Takeshi Maruyama, 22-Apr-13, The requirements for MPLS Transport Profile include a requirement (R93) that requires MPLS-TP must support recovery mechanisms for a network constructed from interconnected rings that protect user data that traverses more than one ring. In particular, This includes protecting against cases of failure at the ring-interconnect nodes and links. This document presents different scenario of interconnected rings and special mechanism to address recovery of the failure of ring-interconnect nodes and links. . 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. "Application Bridging for Federation Beyond the Web (ABFAB) Trust Router Protocol", Margaret Wasserman, Sam Hartman, Josh Howlett, 27-Feb-13, A Trust Router is an infrastucture element used to construct multihop Application Bridging for Federated Authentication Beyond the Web (ABFAB) federations. This document defines both the Trust Router Protocol and the Temporary Identity Protocol, which can be used together to enable multihop ABFAB federations without requiring a centralized Public Key Infrastructure (PKI). "URI Scheme for Session Traversal Utilities for NAT (STUN) Protocol", Suhas Nandakumar, Gonzalo Salgueiro, Paul Jones, Marc Petit-Huguenin, 7-May-13, 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. "Using Simulcast in RTP Sessions", Magnus Westerlund, BoB, Morgan Lindqvist, Fredrik Jansson, 25-Feb-13, In some applications it may be necessary to send multiple media encodings derived from the same media source in independent RTP media streams. This is called Simulcast. This document discusses the best way of accomplishing this in RTP and how to signal it in SDP. It is concluded that a solution where the different simulcast versions are based on separate SDP media descriptions provides best support for simulcast. A solution is defined by making two extensions to SDP. The first extension consists of two new attributes in SDP that express capability to send or receive simulcast streams, respectively. The second extension describes how to group media descriptions belonging to the same simulcast source by using the grouping framework. "Cross Stratum Optimization Architecture for Optical as a Service", Hui Yang, Yongli Zhao, Jie Zhang, Chunhui Lv, Young Lee, Yi Lin, Fatai Zhang, 1-Jan-13, 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. "Problem Statement: TRILL Active/Active Edge", Mingui Zhang, Donald Eastlake, 17-Feb-13, This document specifies TRILL active/active edge which allows multiple RBridges concurrently forward data frames of the same VLAN on links bundled by Link Aggregation. With this kind of connection, end nodes may increase the bandwidth and reliability of the access at the edge of TRILL campuses. It's required that no loop or duplication is caused by this new connection type. Besides this basic requirement, this document outlines other potential issues associated with TRILL active/active edge and investigates how these issues may be addressed. "Licklider Transmission Protocol (LTP), Compressed Bundle Header Encoding (CBHE), and Bundle Protocol IANA Registries", Keith Scott, Marc Blanchet, 10-May-13, 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. "A Hierarchical Mobility Management in LISP network", Hongke Zhang, Zhengxin Zhang, 18-Dec-12, 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. "A General Framework of Source Address Validation and Traceback for IPv4/IPv6 Transition Scenarios", Hui Deng, Guangwu Hu, Jun Bi, Mingwei Xu, Fan Shi, 7-May-13, IP spoofing always is bothering us along with the Internet invention. With the rapid development of IPv6 next generation Internet, this issue is more prominent. Though many studies have made their contributions to the prevention of IP-spoofing, the most excellent one is the SAVI (Source Address Validation Improvement) proposal advocated by IETF, since it can prevent IP-spoofing from happening by automatically binding the key properties of hosts in layer2 access subnet. Nevertheless, till now, SAVI only focuses on the IPv6 stack and simple network access scenarios. To the best of our knowledge, there is no solution even has paid attention to IPv4/IPv6 transition scenarios. Given the fact that IPv4/IPv6 transition will continue to be adopted for a long period of time, this issue is becoming increasingly urgent. However, since transition schemes are plenty and diverse, hardly can an ordinary solution satisfy all the requirements of various transition scenarios. In this document, we present an improved general SAVI-based framework of IP source address validation and traceback for IPv4/IPv6 transition scenarios. To achieve this goal, we extract essential and mutual properties from these transition schemes, and create sub-solutions for each property. Naturally, if one transition scheme is proposed by combining some properties, the corresponding sub-solutions would be included into its IP source address validation and traceback solution. Therefore, the advantage of this framework is its capability to adapt to all the transition schemes. "SAVI Requirements and Solutions for ISP IPv6 Access Network", Fan Shi, Hui Deng, Liang Zhu, Guangwu Hu, 7-May-13, Internet is always confronted with many security threats based on IP address spoofing which can enable impersonation and malicious traffic redirection. Unfortunately, the Internet architecture fails to provide the defense mechanism. Source Address Validation Improvement (SAVI) was developed to prevent IP source address spoofing. Especially, the mechanism is essential for ISPs. However, due to the diversity of address assignment methods, SAVI solution is also different accordingly. This document describes five scenarios of ISPs'IPv6 access network, and moreover, states its SAVI requirements and tentative solutions accordingly. "Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces", Manav Bhatia, Mach Chen, Sami Boutros, Marc Binderberger, Jeffrey Haas, 12-Apr-13, This document proposes a mechanism to run BFD on Link Aggregation Group (LAG) interfaces. It does so by running an independent Asynchronous mode BFD session on every LAG member link. This mechanism allows the verification of member link continuity, either in combination with, or in absence of, LACP. It provides a shorter detection time than what LACP offers. The continuity check can also cover elements of layer 3 bidirectional forwarding. This mechanism utilizes a well-known UDP port distinct from that of single-hop BFD over IP. This new UDP port removes the ambiguity of BFD over LAG packets from BFD over single-hop IP. "Security Implications of IPv6 Options of Type 10xxxxxx", Fernando Gont, Will Liu, 20-Mar-13, 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 and RFC 4443 such that this attack vector is eliminated. Additionally, it describes a number of operational mitigations that could be deployed against this attack vector. "Internationalized Domain Name Mapping Extension for the Extensible Provisioning Protocol (EPP)", Francisco Obispo, Luis Munoz, 6-May-13, 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. "Mobility and Interconnection of Virtual Machines and Virtual Network Elements", Bhumip Khasnabish, Bin Liu, Baohua Lei, Feng Wang, 30-Dec-12, In this draft, we discuss the challenges and requirements related to the migration, mobility, and interconnection of Virtual Machines (VMs)and Virtual Network Elements (VNEs). VM migration scheme across IP subnets is needed to implement virtual computing resources sharing across multiple network administrative domains. Many technologies are involved in the VM migration across DCs. These technologies are classified and discussed according to their different locations in the inter-DC and intra-DC network. For the seamless online migration in various scenarios, many problems need to be resolved in the control plane. The VM migration process should be adapted to these aspects. We also describe the limitations of various types of virtual local area(VLAN) networking technologies and virtual private networking (VPN) technologies that are traditionally expected to support such migration, mobility, and interconnections. "p2mp pw protection for MPLS-TP network", Guoman Liu, Yu jinghai, 11-Dec-12, The requirements of MPLS-TP in RFC 5654 include a requirement(R63) that requires MPLS-TP MUST be possible to provide protection for MPLS-TP data plane without any IP forwarding capability and control plane.If applying 1:1 protection for the p2mp traffic in rfc6718 , it must have a return path to coordinate the switch state to select the same path to receive and send the traffic packet.As there exists the above problem statement,This document describes a kind of protection solution to recovery and protect the p2mp traffic under the failure condition. 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. "CoRE Interfaces", Zach Shelby, Matthieu Vial, 16-Mar-13, 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. In addition, this document defines the concepts of Function Set and Binding. The former is the basis element to create RESTful profiles and the latter helps the configuration of links between resources located on one or more endpoints. "Support of fragmentation of RADIUS packets", Alejandro Perez-Mendez, Rafael Lopez, Fernando Pereniguez-Garcia, Gabriel Lopez-Millan, Diego Lopez, Alan DeKok, 8-Feb-13, This document describes a mechanism providing fragmentation support of RADIUS packets that exceed the 4096 bytes limit. "Multicast Geo-Distribution Control", Huajin Jeng, Jeffrey Haas, Yakov Rekhter, Jeffrey Zhang, 31-Dec-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. "Plasma Service Trust Processing", Jim Schaad, 11-Jan-13, RFC TBD describes a new model and set of requirements to implement a labeling system on Cryptographic Message Syntax (CMS) objects where the entity in charge of doing the label enforcement is under the control of a central authority rather than the recipient of the object. This document describes a protocol to be used by senders and recipients of CMS objects to communicate with a centralized label enforcement server. The document outlines how a client will get the set of labels or policies that it can use for sending messages, composes a secure CMS object with a label on it and gets the necessary keys to decrypt a CMS object from the server. This document is designed to be used with RFC TBD2 which describes the extensions used in CMS objects to hold the label information. "Auto-Configuration of Designated VLANs", Mingui Zhang, Liangliang Ma, Xudong Zhang, 8-Jan-13, 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. "Miscellaneous CoAP Group Communication Topics", Esko Dijk, Akbar Rahman, 20-Dec-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. "RTCP message for Receiver Estimated Maximum Bitrate", Harald Alvestrand, 16-Jan-13, This document proposes an RTCP message for use in experimentally- deployed congestion control algorithms for RTP-based media flows. "Overlay Path Option for IP and TCP", Brandon Williams, 20-Dec-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. "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. "Problem Statement of SAVI Beyond the First Hop", Jun Bi, Bingyang Liu, 23-Nov-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. However, since SAVI requires the edge routers or switches to be upgraded, the deployment of SAVI will need a long time. During this transition period, some source address validation techniques beyond the first hop (SAVI-BF) may be needed to complement SAVI and protect the networks from spoofing based attacks. In this document, we first propose three desired features of the SAVI-BF techniques. Then we analyze the problems of the current SAVI-BF technique, ingress filtering. Finally, we discuss the directions that we can explore to improve SAVI-BF. "Observations of RPL: IPv6 Routing Protocol for Low power and Lossy Networks", Thomas Clausen, Axel Verdiere, Jiazi Yi, Ulrich Herberg, Yuichi Igarashi, 25-Feb-13, 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 limits of RPL, notably the possible directions that further protocol developments should explore, in order to address these. "Definitions of Managed Objects for 4rd", Yu Fu, Sheng Jiang, Bing Liu, 17-Jan-13, 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. "Carrying PIM-SM in ASM mode Trees over P2MP mLDP LSPs", Yakov Rekhter, Rahul Aggarwal, 22-Jan-13, 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 "Content De-duplication for CDNi Optimization", WeiYi Jin, Mian Li, Bhumip Khasnabish, 28-Mar-13, Recent explosive growth of content delivery/distribution networks (CDNs) and their interconnection are causing unintended repetition of content storage in the same dCDN. This can be avoided by using a suitable de-duplication mechanism. This document explores the scenarios which create the problem, and then discusses the approaches to eliminate the duplicated transmission of the same content from uCDN(s) to dCDN in CDNi networks. To implement the optimization, some enhancement to the CDNi metadata model and interface is required. We realize that for business-specific purposes the same content may be encrypted/packaged with different keys for different providers. The impact of DRM (Digital Rights Management) technology on de- duplication will be discussed in a future version of this draft. "Constructing protection paths for inter-AS, inter-sub-AS P2MP TE-LSPs", Shankar Raman, Balaji Venkat, Gaurav Raina, 25-Jan-13, 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. "Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers", Marc Petit-Huguenin, Suhas Nandakumar, Gonzalo Salgueiro, Paul Jones, 6-May-13, 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]. "Distributed Mobility Anchoring", Pierrick Seite, Philippe Bertin, Jong-Hyouk Lee, 9-Jan-13, 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 for an optimal routing management. 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. "Reducing Power Consumption using BGP", Shankar Raman, Balaji Venkat, Gaurav Raina, 27-Apr-13, 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 consumed-power-to-available-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. "Mapping RTP streams to CLUE media captures", Roni Even, Jonathan Lennox, 1-Feb-13, This document describes mechanisms and recommended practice for mapping RTP media streams defined in SDP to CLUE media captures. "Representing CoRE Link Collections in JSON", Carsten Bormann, 25-Feb-13, 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 (RFC6690). 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, Nicola Ciulli, Luis Contreras, Oscar de Dios, 25-Feb-13, 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 the architecture for CSO enabled Path Computation. "Reverse DNS Naming Convention for CIDR Address Blocks", Joe Gersch, Dan Massey, Eric Osterweil, Cathie Olschanowsky, 25-Feb-13, This draft proposes a naming convention for encoding CIDR address blocks into the reverse DNS namespace. The reverse DNS naming method is commonly used to specify a complete IP address. This document describes how to encode an IPv4 or IPv6 CIDR address block such as 129.82.128.0/17. By defining a common naming convention, one can associate information with a prefix. The convention builds on past work in RFC 1101 that associates network names with prefixes. However, this previous work pre-dated the introduction of CIDR and has several critical ambiguities. This convention corrects the ambiguities and enables new applications ranging from routing information to geolocation. "Request Routing Redirection Interface for CDN Interconnection", Wang Danhua, Ben Niven-Jenkins, Xiaoyan He, Ge Chen, Wei Ni, 31-Mar-13, The Request Routing Interface comprises of (1) the asynchronous advertisement of footprint and capabilities by a downstream CDN that allows a upstream CDN to decide whether to redirect particular user requests to that downstream CDN; and (2) the synchronous operation of an upstream CDN requesting whether a downstream CDN is prepared to accept a user request and of a downstream CDN responding with how to actually redirect the user request. This document describes an interface for the latter part, i.e. the CDNI request routing/ Redirection Interface. "Tunneling Compressed Multiplexed Traffic Flows (TCMTF)", Jose Saldana, Dan Wing, Julian Navajas, Muthu Perumal, Fernando Blanco, 9-Jan-13, This document describes a method to improve the bandwidth utilization of network paths that carry multiple streams in parallel sharing a common path. 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. "SNMPD to use cache and shared database based on MIB Classification", Haresh Khandelwal, 29-Mar-12, This memo defines classification of SNMP MIBs to either use SNMP cache database and shared database (SDB) mechanism to reduce high CPU usage while SNMP GET REQUEST, GETNEXT REQUEST, GETBULK REQUEST are continuously performed from network management system (NMS)/SNMP manager/SNMP MIB browser to managed device. "IDNA2008 implementation report", Takahiro NEMOTO, Yoshiro Yoneya, 27-Feb-13, This document reports implementation experience of IDNA2008 and findings from the implementation. "Models for adaptive-streaming-aware CDN Interconnection", Ray van Brandenburg, Oskar van Deventer, Francois Le Faucheur, Kent Leung, 12-Apr-13, This documents presents thoughts on the potential impact of supporting HTTP Adaptive Streaming technologies in CDN Interconnection (CDNI) scenarios. The intent is to present the authors' analysis of the CDNI-HAS problem space and discuss different options put forward both by the authors (and by others during informal discussions) on how to deal with HAS in the context of CDNI. THis document has been used as input information during the WG process for making its decision regarding support for HAS. "A Constrained Application Protocol (CoAP) Usage for REsource LOcation And Discovery (RELOAD)", Jaime Jimenez, Jose Lopez-Vega, Jouni Maenpaa, Gonzalo Camarillo, 17-Feb-13, 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. "Pro-active connectivity monitoring for TRILL", Rohit Watve, Tissa Senevirathne, Chandan Mishra, Gayatri Ramachandran, 4-Feb-13, 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. "CoAP Option Extension: Patience", Kepeng Li, Bert Greevenbosch, Esko Dijk, Salvatore Loreto, 23-Apr-13, CoAP is a RESTful application protocol for constrained nodes and networks. This specification provides a simple extension for CoAP, the Patience option. This option informs a recipient of the preferred time frame for a request or response depending on usage context. In a unicast request, it indicates the patience a client has in waiting for a response. The CoAP server tries to return the response within the specified time frame. In a multicast request, it indicates the patience a server should have in sending its response. The recipient would then try to randomly delay its response within the time frame that the requester indicated or computed by the recipient itself. In a CoAP observe notification, it indicates the patience an observer should have in both waiting for a subsequent notification and in re-establishing an observation relation. "DNS Resource Records for Authorized Routing Information", Joe Gersch, Dan Massey, Cathie Olschanowsky, Lixia Zhang, 25-Feb-13, This draft discusses the use of two DNS record types for storing BGP routing information in the reverse DNS. The RLOCK record allows prefix owners to indicate whether the DNS is being used to publish routing data. The SRO record allows operators to indicate whether an IPv4 or IPv6 prefix ought to appear in global routing tables and identifies authorized origin Autonomous System Number(s) for that prefix. The resulting published data can be used in a variety of contexts from routing security to address ownership. "OSPF extensions for support spectrum sub-band allocation", Qilei Wang, Xihua Fu, 26-Feb-13, This document addresses the requirements and routing protocol extension of spectrum sub-band allocation in order to help reduce non-linear effect and raise spectrum utilization rate in the scenario of indiscriminately positioning of various channels with different bit rates. "A Stateless Transport Tunneling Protocol for Network Virtualization (STT)", Bruce Davie, Jesse Gross, 12-Mar-13, Network Virtualization places unique requirements on tunneling protocols. This draft describes STT (Stateless Transport Tunneling), a tunnel encapsulation that enables overlay networks to be built in virtualized networks. STT is particularly useful when some tunnel endpoints are in end-systems, as it utilizes the capabilities of the network interface card to improve performance. "End-to-End Object Encryption and Signatures for the Extensible Messaging and Presence Protocol (XMPP)", m&m, 25-Feb-13, This document defines a method of encrypting and signing objects (often referred to as stanzas) for the Extensible Messaging and Presence Protocol (XMPP). "Constructing power optimal P2MP TE-LSPs within an AS", Shankar Raman, Balaji Venkat, Gaurav Raina, 18-Feb-13, Power consumption in multicast replication operations is an area of concern and choosing suitable replication points that can decrease power consumption overall assumes importance. Multicast replication capacity is an attribute of every line card of major routers and multi-layer switches that support multicast in the core of an Internet Service Provider (ISP) or an enterprise network. Currently multicast replication points on Point-to-Multipoint Traffic Engineering Label-Switched-Paths (P2MP TE-LSPs) consume power while delivering multiple output streams of data from a given input stream. The multicast distribution trees are constructed without any regard for a proper placement of the replication points and consequent optimal power consumption at these points. This results in overloading certain routers while under-utilizing others. An optimal usage of these replication resources could substantially reduce power consumption on these routers. In this paper, we propose a mechanism by which P2MP TE-LSPs are constructed for carrying multicast traffic across multiple areas within a given AS. We propose that these LSPs be built by using the advertisements of the power-replication capacity ratio advertised by fine grained components such as multicast capable line-cards of routers and multi- layer switches deployed within an AS. "CDNI Control Interface / Triggers", Rob Murray, Ben Niven-Jenkins, 3-Apr-13, This document describes the part of the CDN Interconnect Control Interface that allows a CDN to trigger activity in an interconnected CDN that is configured to deliver content on its behalf. The upstream CDN can use this mechanism to request that the downstream CDN pre-positions metadata or content, or that it re-validate or purge metadata or content. The upstream CDN can monitor the status of activity that it has triggered in the downstream CDN. "PCP Server Discovery with IPv4 traffic offload for Proxy Mobile IPv6", Tirumaleswar Reddy, Prashanth Patil, Ravikumar Chandrasekaran, Dan Wing, 11-Feb-13, This document proposes a solution to PCP Server Discovery problems in Proxy Mobile IPv6 (PMIPv6) networks when both home network traffic and traffic off-loaded to local access network require traversing a gateway implementing NAT and/or Firewall. This draft proposes enhancements to DHCPv4 Relay Agent by introducing a new sub-option under DHCPv4 Relay Option and to PMIPv6 signaling through additional options to Proxy Binding Update/Acknowledgement messages. "Formal Specification Framework for Software-Defined Networks (SDN)", Myung-Ki Shin, Ki-Hyuk Nam, Miyoung Kang, Jin-Young Choi, 13-Feb-13, This document discusses formally verifiable networking framework for software-defined networks (SDN). In SDN, incomplete or malicious programmable entities could cause break-down of underlying networks shared by heterogeneous devices and stake-holders. Formally verifiable networking can provide a logic-based framework to unify the design, specification, verification, and implementation of SDN. This framework describes formal specification and verification process for SDN. In addition, we present two examples of formal specification for a part of SDN using a process algebra called Algebra of Communicating Shard Resources (ACSR) and Z specification languages. "New IP address structure", C.V. Sreeraj, 24-Feb-13, This document specifies new address structure and routing technique for the IP (Internet Protocol),a hierarchical scalable design. This version is backward compatible with IPv4. "LDP Extensions for Lock Instruct and Loopback of Pseudowire in MPLS Transport Profile", Jie Dong, Mach Chen, Greg Mirsky, 18-Apr-13, This document specifies extensions to the Label Distribution Protocol (LDP) to support provisioning of lock instruct and loopback mechanism for MPLS-TP Pseudowires. "IGMP/MLD Optimizations in Wireless and Mobile Networks", Hui Liu, Mike McBride, Hitoshi Asaeda, 22-Feb-13, This document proposes a variety of optimization approaches for IGMP and MLD in wireless and mobile networks. It aims to provide useful guidelines to allow efficient multicast communication in these networks using IGMP or MLD protocols. "Analysis of Algorithms For Deriving Port Sets", Tina Tsou, Tetsuya Murakami, Simon Perreault, 17-May-13, This memo analyzes some port set definition algorithms used for stateless IPv4 to IPv6 transition technologies. The transition technologies using port set algorithms can be divided into two categories: fully stateless approach and binding approach. Some algorithms can work for both approaches. "Super-Channel Optical Parameters GMPLS Signaling Extensions", Iftekhar Hussain, Vinayak Dangui, Michael VanLeeuwen, Marco Sosa, 12-Apr-13, This document builds on [6][7] and defines GMPLS signaling extensions to carry super-channel optical parameters for efficient spectrum assignment on flexible grid networks. "Super-Channel Optical Parameters GMPLS Routing Extensions", Iftekhar Hussain, Marco Sosa, 12-Apr-13, This document builds on [6][7] and defines GMPLS routing extensions to allow added CSPF constraints for efficient super-channel spectrum assignment on flexible grid networks. "STUN Usage for Consent Freshness", Muthu Perumal, Dan Wing, Ram R, Hadriel Kaplan, 25-Feb-13, Verification of peer consent before sending traffic is necessary in WebRTC deployments to ensure that a malicious JavaScript cannot use the browser as a platform for launching attacks. A related problem is session liveness. WebRTC applications may want to detect connection failure and take appropriate actions. This document describes a STUN usage that enables a WebRTC browser to perform the following on a candidate pair ICE is using for a media component after session establishment: "Scaling the Address Resolution Protocol for Large Data Centers (SARP)", Youval Nachum, Linda Dunbar, Ilan Yerushalmi, Tal Mizrahi, 24-Feb-13, This document provides a recommended architecture and network operation named SARP. SARP is based on fast proxies that significantly reduce broadcast domains and ARP/ND broadcast transmissions. SARP supports smooth and fast virtual machine (VM) mobility without any modification to the VM, while keeping the connection up and running efficiently. SARP is targeted for massive scaling data centers with a significant number of VMs using ARP and ND protocols. "Applicability of PCEP Extensions for Stateful PCE", Xian Zhang, Ina Minei, 22-Feb-13, A Stateful PCE maintains information about LSP characteristics and resource usage within the network in order to provide traffic engineering calculations for its associated PCCs. This document describes general considerations for stateful PCEP and examines its applicability and benefits through a number of use cases. PCEP extensions required for stateful PCE usage are covered in separate documents. "Include Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)", Zafar Ali, George Swallow, Clarence Filsfils, Ori Gerstel, Kenji Kumaki, Ruediger Kunze, 25-Feb-13, There are scenarios that require two or more LSPs or segments of LSPs to follow same route in the network. This document specifies methods to communicate route inclusions along the loose hops during path setup using the Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) protocol. "An Architecture for Multicast Protection Using Maximally Redundant Trees", Alia Atlas, Robert Kebler, IJsbrand Wijnands, Andras Csaszar, Gabor Envedi, 25-Feb-13, Failure protection is desirable for multicast traffic, whether signaled via PIM or mLDP. Different mechanisms are suitable for different use-cases and deployment scenarios. This document describes the architecture for global protection (aka multicast live- live) and for local protection (aka fast-reroute). The general methods for global protection and local protection using alternate-trees are dependent upon the use of Maximally Redundant Trees. Local protection can also tunnel traffic in unicast tunnels to take advantage of the routing and fast-reroute mechanisms available for IP/LDP unicast destinations. The failures protected against are single link or node failures. While the basic architecture might support protection against shared risk group failures, algorithms to dynamically compute MRTs supporting this are for future study. "PMIPv6-based distributed anchoring", Carlos Bernardos, Juan Zuniga, 8-Apr-13, Distributed Mobility Management solutions allow for setting up networks so that traffic is distributed in an optimal way and does not rely on centralized deployed anchors to provide IP mobility support. There are many different approaches to address Distributed Mobility Management, as for example extending network-based mobility protocols (like Proxy Mobile IPv6), or client-based mobility protocols (as Mobile IPv6), among others. This document follows the former approach, and proposes a solution based on Proxy Mobile IPv6 in which mobility sessions are anchored at the last IP hop router (called distributed gateway). The distributed gateway is an enhanced access router which is also able to operate as local mobility anchor or mobility access gateway, on a per prefix basis. The draft focuses on the required extensions to effectively support simultaneously anchoring several flows at different distributed gateways. This draft introduces the concept of distributed logical interface (at the distributed gateway), which is a software construct that allows to easily hide the change of anchor from the mobile node. Additionally, the draft describes how to provide session continuity in inter-domain scenarios in which dynamic tunneling or signaling between distributed gateways from different operators is not allowed. "The Applicability of the PCE to Computing Protection and Recovery Paths for Single Domain and Multi-Domain Networks.", Huaimo Chen, Dhruv Dhody, 29-Apr-13, The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. A link or node failure can significantly impact network services in large-scale networks. Therefore it is important to ensure the survivability of large scale networks which consist of various connections provided over multiple interconnected networks with varying technologies. This document examines the applicability of the PCE architecture, protocols, and procedures for computing protection paths and restoration services, for single and multi-domain networks. This document also explains the mechanism of Fast Re-Route (FRR) where a point of local repair (PLR) needs to find the appropriate merge point (MP) to do bypass path computation using PCE. "Analysis of Port Control P0rotocol in Mobile Network", Gang Chen, Zhen Cao, Mohamed Boucadair, Vizdal Ales, Laurent Thiebaut, 25-Apr-13, This memo provides a motivation description for the Port Control Protocol (PCP) deployment in a 3GPP mobile network environment. The document focuses on a mobile network specific issues (e.g. cell phone battery power consumption, keep-alive traffic reduction), PCP applicability to these issues is further studied and analyzed. "NAT traversal for LISP", Vina Ermagan, Dino Farinacci, Darrel Lewis, Jesper Skriver, Fabio Maino, Chris White, 29-Mar-13, This document describes a mechanism for IPv4 NAT traversal for LISP tunnel routers (xTR) and LISP Mobile Nodes (LISP-MN) behind a NAT device. A LISP device both detects the NAT and initializes its state. Forwarding to the LISP device through a NAT is enabled by a new network element, the LISP Re-encapsulating Tunnel Router (RTR), which acts as an anchor point in the data plane, forwarding traffic from unmodified LISP devices through the NAT. "Requirements for Message Access Control", Trevor Freeman, Jim Schaad, Patrick Patterson, 29-Apr-13, There are many situations where organizations want to protect information with robust access control, either for implementation of intellectual property right protections, enforcement of contractual confidentiality agreements or because of legal regulations. The Enhanced Security Services (ESS) for S/MIME defines an access control mechanism for email which is enforced by the recipient's client after decryption of the message. The ESS mechanism therefore is dependent on the correct access policy configuration of every recipient's client. This mechanism also provides full access to the data to all recipients prior to the access control check, this is considered to be inadequate due to the difficulty in demonstrating policy compliance. This document lays out the deficiencies of the current ESS security label, and presents requirements for a new model for doing/providing 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. "Service Provider Wi-Fi Services Over Residential Architectures", Sri Gundavelli, Mark Grayson, Pierrick Seite, Yiu Lee, 23-Apr-13, The tremendous growth in Wi-Fi technology adoption over the last decade has met the ultimate possible goal of 100% adoption rate. All most every new mobile device is now equipped with IEEE 802.11-based wireless interface and with pre-configured policy to prefer Wi-Fi to cellular access. Matching this evolution is every service provider's desire to offer Wi-Fi based broadband services; a new business opportunity even for fixed line operators. Operators are exploring options to monetize their existing networks, most with nation-wide footprint, to build a high-speed Wi-Fi service that can be the basis for offering new wireless broadband services. This document identifies the requirements for supporting these new Wi-Fi community services and the mobility tools which have been standardized in IETF that can be used for enabling these architectures. "CUSAX: Combined Use of the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP)", Emil Ivov, Peter Saint-Andre, Enrico Marocco, 2-May-13, This document describes suggested practices for combined use of the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP). Such practices aim to provide a single fully featured real-time communication service by using complementary subsets of features from each of the protocols. Typically such subsets would include telephony capabilities from SIP and instant messaging and presence capabilities from XMPP. This specification does not define any new protocols or syntax for either SIP or XMPP. However, implementing it may require modifying or at least reconfiguring existing client and server-side software. Also, it is not the purpose of this document to make recommendations as to whether or not such combined use should be preferred to the mechanisms provided natively by each protocol (for example, SIP's SIMPLE or XMPP's Jingle). It merely aims to provide guidance to those who are interested in such a combined use. "WebRTC Data Channel Protocol", Randell Jesup, Salvatore Loreto, Michael Tuexen, 26-Feb-13, The Web Real-Time Communication (WebRTC) working group is charged to provide protocols to support for direct interactive rich communication using audio, video, and data between two peers' web- browsers. This document specifies an actual (minor) protocol for how the JS-layer DataChannel objects provide the data channels between the peers. "IPv6 Operational Guidelines for Datacenters", Diego Lopez, Zhonghua Chen, Tina Tsou, Cathy Zhou, Arturo Servin, 5-Feb-13, This document is intended to provide operational guidelines for datacenter operators planning to deploy IPv6 in their infrastructures. It aims to offer a reference framework for evaluating different products and architectures, and therefore it is also addressed to manufacturers and solution providers, so they can use it to gauge their solutions. We believe this will translate in a smoother and faster IPv6 transition for datacenters of these infrastuctures. The document focuses on the DC infrastructure itself, its operation, and the aspects related to DC interconnection through IPv6. It does not consider the particular mechanisms for making Internet services provided by applications hosted in the DC available through IPv6 beyond the specific aspects related to how their deployment on the DC infrastructure. Apart from facilitating the transition to IPv6, the mechanisms outlined here are intended to make this transition as transparent as possible (if not completely transparent) to applications and services running on the DC infrastructure, as well as to take advantage of IPv6 features to simplify DC operations, internally and across the Internet. "Building power shortest inter-Area TE LSPs using pre-computed paths", Shankar Raman, Balaji Venkat, Gaurav Raina, 4-May-13, In this paper, we propose a framework to reduce the aggregate power consumption of an Autonomous System (AS) using a collaborative approach between areas within an AS. We identify the low-power paths within non-backbone areas and then use Traffic Engineering (TE) techniques to route the packets along the stitched paths from non- backbone areas / backbone area to other non-backbone areas. Such low- power paths can be identified by using the power-to-available- bandwidth (PWR) ratio as an additional constraint in the Constrained Shortest Path First (CSPF) algorithm. For routing the data traffic through these low-power paths, the Inter-Area Traffic Engineered Label Switched Path (TE-LSP) that spans multiple areas can be used. Extensions to the Interior Gateway Protocols like OSPF and IS-IS that support TE extensions can be used to disseminate information about low-power paths in the respective areas (backbone or non-backbone) that minimize the PWR ratio metric on the links within the areas and between the areas thereby creating a collaborative approach to reduce the power consumption. The feasibility of our approaches is illustrated by applying our algorithm to an AS with a backbone area and several non-backbone areas. The techniques proposed in this paper for the Inter-Area power reduced paths require a few modifications to the existing features of the IGPs supporting TE extensions. The proposed techniques can be extended to other levels of Internet hierarchy, such as Inter-AS paths, through suitable modifications as in [11]. When link state routing protocols like OSPF or ISIS are used to discover TE topology, there is the limitation that traffic engineered paths can be set up only when the head and tail end of the label switched path are in the same area. There are solutions to overcome this limitation either using offline Path Computation Engine (PCE) that attach to multiple areas and know the topology of all areas. This document proposes an alternative approach that does not require any centralized PCE and uses selective leaking of low-power TE path information from one area into other areas. "A Framework and Information Model for Queries about Telephone-Related Queries (TeRQ)", Jon Peterson, 25-Feb-13, As telephone services migrate to the Internet, Internet applications require access to diverse information about telephone numbers. ENUM, for example, applied the DNS to the problem of finding URIs for telephone services on the Internet. The intrinsic limitations in the query/response semantics of the DNS, however, have often been strained by the requirements for accessing information about telephone numbers. This document therefore proposes a protocol- independent framework and information model for querying and responding to requests concerning telephone numbers and call routing that allows a richer expression of both questions and answers. "New Differentiated Services Code Point Assignments for Rich Media Traffic", James Polk, 25-Feb-13, This document requests five new Differentiated Services Code Point (DSCP) values (DSCP) from the Internet Assigned Numbers Authority (IANA) for new classes of rich media traffic and one additional DSCP value for the signaling of multimedia sessions. "Standard Configuration of DiffServ Service Classes", James Polk, 5-Mar-13, This document describes service classes configured with DiffServ and identifies how they are used and how to construct them using Differentiated Services Code Points (DSCPs), traffic conditioners, Per-Hop Behaviors (PHBs), and Active Queue Management (AQM) mechanisms. There is no intrinsic requirement that particular DSCPs, traffic conditioners, PHBs, and AQM be used for a certain service class, but for consistent behavior under the same network conditions, configuring networks as described here is appropriate. "RSVP Setup Protection", Yimin Shen, Yuji Kamite, 8-Feb-13, RFC 4090 specifies an RSVP facility-backup fast reroute mechanism for protecting established LSPs against link and node failures. This document extends the mechanism to provide so-called "setup protection" for LSPs during their initial Path message signaling time. In particular, it enables a router to reroute an LSP via an existing bypass LSP, when there is a failure of the immediate downstream link or node along the desired path. Therefore, it can be used to reduce LSP setup time in such a situation, or allow LSPs with strict paths to be established successfully when alternative paths are unavailable in the network or unable to be computed by ingress. "CDNI Request Routing: Footprint and Capabilities Semantics", Jan Seedorf, Jon Peterson, Stefano Previdi, Ray van Brandenburg, Kevin Ma, 25-Feb-13, This document tries to capture the semantics of the "Footprint and Capabilities Advertisement" part of the CDNI Request Routing interface, i.e. the desired meaning and what "Footprint and Capabilities Advertisement" is expected to offer within CDNI. The discussion in this document has the goal to facilitate the choosing of one or more suitable protocols for "Footprint and Capabilities Advertisement" within CDNI Request Routing. "Accessing Cloud Services", Yaakov Stein, Yuri Gittik, Daniel Kofman, Konstantinos Katsaros, Monique Morrow, Luyuan Fang, Wim Henderickx, 8-Jan-13, Cloud services are revolutionizing the way computational resources are provided, but at the expense of requiring an even more revolutionary overhaul of the networking infrastructure needed to deliver them. Much recent work has focused on intra- and inter- datacenter connectivity requirements and architectures, while the "access segment" connecting the cloud services user to the datacenter still needs to be addressed. In this draft we consider tighter integration between the network and the datacenter, in order to improve end-to-end Quality of Experience, while minimizing both networking and computational resource costs. "ALTO session for CDN Interconnection", Stephan Emile, Selim Ellouze, 16-Apr-13, The selection of a downstream CDN by an upstream CDN is based on multi-dimensional criteria. Various protocols, such as BGP or ALTO, may be used by a downstream CDN to expose content routing information and interconnection preferences to an upstream CDN. The selection of such a protocol is premature as the WG, and especially the Footprint/ Capabilities Design Team, is currently working on this topic. So this draft does not promote the usage of the ALTO protocol for CDN interconnection. It presents the limitations of the current ALTO protocol in the case it would be selected for CDN interconnection. It specifies the mechanism for controlling the session initialization and for limiting the information exchanged. Then it discusses the need of incremental update and proposes to study the usage of Netconf /Yang to provide ALTO server with notifications. "Deployment Considerations for Lightweight 4over6", Qiong Sun, Chongfeng Xie, Yiu Lee, Maoke Chen, 14-Jan-13, Lightweight 4over6 is a mechanism which moves the translation function from tunnel Concentrator (AFTR) to Initiators (B4s), and hence reduces the mapping scale on the Concentrator to per-customer level. This document discusses various deployment models of Lightweight 4over6. It also describes the deployment considerations and applicability of the Lightweight 4over6 architecture. "DS-Lite Failure Detection and Failover", Tina Tsou, Brandon Li, Cathy Zhou, Juergen Schoenwaelder, Reinaldo Penno, Mohamed Boucadair, 1-Feb-13, In DS-Lite, the tunnel is stateless, not associated with any state information, and no failure detection and failover mechanism is available. This makes it difficult to manage and diagnose if there is a problem. This draft analyzes the applicability of some of the possible solutions. "Context Transfer for Multicast support in Distributed Mobility Management (DMM)", DH, Hitoshi Asaeda, Pierrick Seite, 19-Mar-13, This document describes a context transfer based concept to support overarching IP multicast services applicable to various existing approaches for Distributed Mobility Management. "VLAN based Tree Selection for Multi-destination Frames", Li Yizhou, Hao Weiguo, Radia Perlman, Naveen Nimmu, Somnath Chatterjee, Sunny Rajagopalan, 14-Jan-13, TRILL uses the distribution trees to deliver multi-destination frames. Multiple trees can be used by an ingress RBridge for different flow based on VLAN and/or multicast group. Different ingress RBridges may choose different distribution trees for the same VLAN and/or multicast group traffic. Distribution trees are normally pruned based on VLAN. For any RBridge RBn, if RBn has downstream receivers of VLAN x in a distribution tree t, there will be an entry of (t, x, port list) in the multicast forwarding table on RBn. If there are n trees and m VLANs, the multicast forwarding table size on RBn is typically n*m entries. The value of m is up to 4096 and n is the total number of distribution trees in the campus. If fine grained labeling is implemented or finer granularity filtering such as VLAN plus L2/L3 multicast address is used for pruning, the multicast forwarding table size further increases dramatically. TRILL multicast forwarding table size is limited by hardware and L3 multicasting may share the same table with it in hardware implementations. Therefore multicast table entry is a precious resource. This document specifies a VLAN based tree selection mechanism to reduce the TRILL multicast forwarding table size on RBridge. "Multicast transition path optimization in IPv4 and IPv6 networks", Qiong Sun, Cathy Zhou, 21-Feb-13, This document describes a mechanism to optimize the path between the multicast router and multicast source in both IPv4 and IPv6 networks. The basic idea is that when a multicast translation router has an IPv4 path and an IPv6 path to the same multicast data source, and both IPv4 and IPv6 joins are received, only one path is used. One path is pruned, instead of the same traffic flowing over both v4 and v6 paths. By adding a metric to the IPv4 path, the multicast translation router can determine which path to receive multicast data: IPv4 path, IPv6 path or both. Therefore, an optimization path will typically be chosen when an identical v4/v6 traffic flow exists. "Domain Name Registration Data (DNRD) Objects Mapping", Francisco Arias, Gustavo Lozano, Shoji Noguchi, James Gould, Chethan Thippeswamy, 4-Apr-13, This document specifies the format, contents and semantics of Domain Name Registration Data (DNRD) Escrow deposits for a Domain Name Registry. "TRILL: Directory Assistance Mechanisms", Linda Dunbar, Donald Eastlake, Radia Perlman, Igor Gashinsky, Li Yizhou, 25-Feb-13, This document describes optional mechanisms for using directory server(s) to assist TRILL (Transparent Interconnection of Lots of Links) edge switches in reducing multi-destination traffic, particularly ARP/ND and unknown unicast flooding. "Trust Requirements in a Federated World", Josh Howlett, Rhys Smith, Margaret Wasserman, 11-Mar-13, TODO: This document outlines the requirements for trust in a federated environment, and enumerates the requirements for a trust infrastructure. It also examines existing trust infrastructures given these requirements and concludes that none fulfil all of the requirements, and suggests that maybe a new one is required that does. "TFTP Windowsize Option", Patrick Masotta, 15-May-13, The Trivial File Transfer Protocol [1] is a simple, lock-step, file transfer protocol which allows a client to get or put a file onto a remote host. One of its primary uses is the early stages of nodes booting from a Local Area Network. TFTP has been always used because it is very simple to implement. However, the choice of a lock-step schema is not the most efficient for use on a LAN. This document describes a TFTP option which allows the client and server to negotiate a windowsize of consecutive blocks to send as an alternative for replacing the single block lock-step schema. The TFTP Option Extension mechanism is described in [2]. "Plasma Service Cryptographic Message Syntax (CMS) Processing", Jim Schaad, 18-Mar-13, Secure MIME (S/MIME) defined a method of placing security labels on a Cryptographic Message Syntax (CMS) object. These labels are placed as part of the data signed and validated by the parties. This means that the message content is visible to the recipient prior to the label enforcement. A new model for enforcement of policy using a third party is described in RFC TBD [I.D-draft-freeman-plasma-requirements]. This is the Policy Augmented S/MIME (PLASMA) system. This document provides the details needed to implement the new Plasma model in the CMS infrastructure. An additional benefit of using the Plasma module is that the server, based on policy, manages who has access to the message and how the keys are protected. The document details how the client encryption and decryption processes are performed, defines how to construct the CMS recipient info structure, a new content to hold the data required for the Plasma server to store the keys and policy information. The document does not cover the protocol between the client and the Plasma policy enforcement server. One example of the client/server protocol can be found in RFC TBD [plasma-token]. "LISP Traffic Engineering Use-Cases", Dino Farinacci, Parantap Lahiri, Michael Kowal, 7-Jan-13, This document describes how LISP reencapsulating tunnels can be used for Traffic Engineering purposes. The mechanisms described in this document require no LISP protocol changes but do introduce a new locator (RLOC) encoding. The Traffic Engineering features provided by these LISP mechanisms can span intra-domain, inter-domain, or combination of both. "End-to-End Session Identification in IP-Based Multimedia Communication Networks", Paul Jones, Chris Pearce, James Polk, Gonzalo Salgueiro, 20-Feb-13, 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. "Securing Model-C Inter-Provider VPNs with Label Hopping and TicToc", Shankar Raman, Balaji Venkat, Gaurav Raina, 8-Apr-13, In certain models of inter-provider Multi- Protocol Label Switching (MPLS) based Virtual Private Networks (VPNs) spoofing attack against VPN sites is a key concern. For example, MPLS-based VPN inter- provider model "C" is not favoured, owing to security concerns in the dataplane, even though it can scale with respect to maintenance of routing state. Since the inner labels associated with VPN sites are not encrypted during transmission, a man-in-themiddle attacker can spoof packets to a specific VPN site. In this paper, we propose a label-hopping technique which uses a set of randomized labels and a method for hopping amongst these labels using the time instant the packet leaves the port from a sending Provider Edge Router. To prevent the attacker from identifying the labels in polynomial time, we also use an additional label. The proposed technique can be applied to other variants of inter-provider MPLS based VPNs where Multi-Protocol exterior-BGP (MP-eBGP) multi-hop is used. As we address a key security concern, we can make a case for the deployment of MPLS based VPN inter-provider model "C". Specifically we use the TicToc based Precision Time Protocol LSP to provide the timing for determining the time instant at which the packet is sent from the remote end Provider Edge Router and hence calculating when it must have left that peer at the Provider Edge Router in the near / receiving end. This version of the document suggests a better method for gaining more finely granular time slices. This is done by running the PTP LSP between the ASBRs in the ASes that are providing the inter-AS L3VPN service. "Power Based Topologies and TE-Shortest Power Paths in OSPF", Shankar Raman, Balaji Venkat, Gaurav Raina, Vasan Srini, 27-Apr-13, In a Interior Gateway Protocol like OSPF (Open Shortest Path First) the computation of the Constrained shortest path to destinations is computed for an area say a backbone or a non-backbone area using the TE-metrics advertised in the area. With importance given to the reduction of power within a network it becomes important to provide a solution that reduces the power consumed amongst routers and links that make up the network (in this case an area or a collection of areas including the backbone and non-backbone areas). This proposal aims at providing such a solution by producing a power topology of the area / areas. This power topology is constructed by assigning metrics to links based on the power consumed by the linecards (and hence their respective ports in an indirect way) of adjacent routers that are interconnected by each such link. "Definition and Use of DNSSEC Negative Trust Anchors", Jason Livingood, Chris Griffiths, 22-Feb-13, DNS Security Extensions (DNSSEC) is now entering widespread deployment. However, domain signing tools and processes are not yet as mature and reliable as is the case for non-DNSSEC-related domain administration tools and processes. One potential technique to mitigate this is to use a Negative Trust Anchor, which is defined in this document. This document discusses Trust Anchors for DNSSEC and defines a Negative Trust Anchor, which is potentially useful during the transition to ubiquitous DNSSEC deployment. These are configured locally on a particular instance of a validating DNS recursive resolver and can shield end users of such a resolver from the DNSSEC- related authoritative name server operational errors that appear to be somewhat typical during the transition to ubiquitous DNSSEC deployment. Negative Trust Anchors are intended to be temporary, and should not be distributed by IANA or any other organization outside of the administrative boundary of the organization locally implementing a Negative Trust Anchor. Finally, Negative Trust Anchors pertain only to DNSSEC and not to Public Key Infrastructures (PKI) such ad X.509. "CoRE Roadmap and Implementation Guide", Carsten Bormann, 1-May-13, The CoRE set of protocols, in particular the CoAP protocol, is defined in draft-ietf-core-coap in conjunction with a number of specifications that are currently nearing completion. There are also several dozen more individual Internet-Drafts in various states of development, with various levels of WG review and interest. Today, this is simply a bewildering array of documents. Beyond the main four documents, it is hard to find relevant information and assess the status of proposals. At the level of Internet-Drafts, the IETF has only adoption as a WG document to assign status - too crude an instrument to assess the level of development and standing for anyone who does not follow the daily proceedings of the WG. With a more long-term perspective, as additional drafts mature and existing specifications enter various levels of spec maintenance, the entirety of these specifications may become harder to understand, pose specific implementation problems, or be simply inconsistent. The present guide aims to provide a roadmap to these documents as well as provide specific advice how to use these specifications in combination. In certain cases, it may provide clarifications or even corrections to the specifications referenced. This guide is intended as a continued work-in-progress, i.e. a long- lived Internet-Draft, to be updated whenever new information becomes available and new consensus on how to handle issues is formed. Similar to the ROHC implementation guide, RFC 4815, it might be published as an RFC at some future time later in the acceptance curve of the specifications. This document does not describe a new protocol or attempt to set a new standard of any kind - it mostly describes good practice in using the existing specifications, but it may also document emerging consensus where a correction needs to be made. "Reducing Power Consumption using BGP path selection", Shankar Raman, Balaji Venkat, Gaurav Raina, Vasan Srini, 27-Apr-13, 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 suitable modifications to the BGP path selection algorithm to route the packets along the paths. Such low-power paths can be identified by using the consumed-power-to-available-bandwidth (PWR) ratio as an additional parameter in the BGP Path Selection Algorithm. For re-routing the data traffic through these low-power paths, the power based best path is selected and advertised as per the modified algorithm proposed in this document. 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. 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. A recent addition is the use of this method in AIGP domains and also the use of power source data in the calculation of low power paths using the BGP path selection algorithm. "LLN Fragment Forwarding and Recovery", Pascal Thubert, Jonathan Hui, 25-Feb-13, In order to be routed, a fragmented packet must be reassembled at every hop of a multihop link where lower layer fragmentation occurs. Considering that the IPv6 minimum MTU is 1280 bytes and that an an 802.15.4 frame can have a payload limited to 74 bytes in the worst case, a packet might end up fragmented into as many as 18 fragments at the 6LoWPAN shim layer. If a single one of those fragments is lost in transmission, all fragments must be resent, further contributing to the congestion that might have caused the initial packet loss. This draft introduces a simple protocol to forward and recover individual fragments that might be lost over multiple hops between 6LoWPAN endpoints. "Fundamental Architecture of Services Provider's network Transitioning to IPv6 (FAST6)", GuoLiang Yang, Yangchun Li, Cancan Huang, Jinhua Tan, Youming Wu, 1-Apr-13, The IANA free pool of IPv4 addresses was depleted, IPv6 migration has become the most imperative task. There are many transition mechanisms designed for different scenarios, however, some problems arosed in the practice. FAST6, specified in this draft, is based on the ideas of native dual stack and address sharing. It can solves the mixed route problem and simplify the planning of private IPv4 address space by using tunnel technology. FAST6 is an economical and stable technology for smooth network transition. "An M-party, N-state Game of Rochambeau", Dan Harkins, Paul Lambert, 1-Apr-13, A protocol for the fair selection and random distribution of a single winner in a game with an arbitrary number of players is described. "Definition of Managed Objects for the MANET Essential Connected Dominating Set (E-CDS) Process", James Nguyen, Robert Cole, 3-Jan-13, 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 Essential Connected Dominating Set (E-CDS) process for Mobile Ad-Hoc Networks (MANETs). The ECDS-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. "File Transfer Protocol HASH Command for Cryptographic Hashes", Anthony Bryan, Tim Kosse, Daniel Stenberg, 18-Feb-13, The File Transfer Protocol does not offer any method to verify the integrity of a transferred file, nor can two files be compared against each other without actually transferring them first. Cryptographic hashes are a possible solution to this problem. In the past, several attempts have been made to add commands to obtain checksums and hashes, however none have been formally specified, leading to non-interoperability and confusion. To solve these issues, this document specifies a new FTP command to be used by clients to request cryptographic hashes of files. "vCard representation of resources", Ciny Joy, Cyrus Daboo, Mike Douglass, 31-Jan-13, This specification describes the vCard representation of resources. "Grazed and Lightweight Open Protocol (GaLOP), v. 1.0", Lukasz Ruminski, Michal Kutzner, Adrian Dymek, Szymon Kwiatkowski, Marcin Langa, 18-Apr-13, This informational memo specifies a Grazed and Lightweight Open Protocol (GaLOP), designed to exchange information within the Hackney project [HACKNEY]. The document describes messages' structures, defined message types used in the communication and standard connection scenarios. "IPv6 RA Options for Multiple Interface Next Hop Routes", Behcet Sarikaya, 25-Feb-13, This draft defines new Router Advertisement options for configuring next hop routes on the mobile or fixed nodes. Using these options, an operator can easily configure nodes with multiple interfaces (or otherwise multi-homed) to enable them to select the routes to a destination. Each option is defined together with definitions of host and router behaviors. "Adaptation Layer Fragmentation Indication", Carsten Bormann, 10-Mar-13, IPv6 defines a minimum MTU of 1280 bytes. Many link layers are more limited in the maximum size of packets they can communicate. In order to enable the transport of IP packets that are too large for these link layers, typically their IP adaptation layers define a segmentation or fragmentation scheme to transport an IP packet in a sequence of multiple link layer packets. Often, adaption layer fragmentation schemes reduce some performance metric, such as the packet delivery probability. Application or transport protocols may be able to reduce the maximum size of packets they send, e.g. by transport layer segmentation or choice of application layer data object size, which may have less of a performance impact. It would therefore be desirable for them to know about any adaptation layer fragmentation that is going on, so they can choose packet sizes that minimize adaptation layer fragmentation. At the IP layer, fragmentation can be detected using a number of mechanisms used in Packetization Layer Path MTU Discovery [RFC4821]. However, adaptation layer fragmentation schemes are often designed to be "transparent", i.e. there is no way at higher layers to find out whether they had to be employed (except maybe by elaborate measurement schemes targeting one of the impacted performance metrics; this approach does not appear to be viable) [WEI]. The present specification defines a mechanism for IPv6 adaptation layers to indicate the presence of adaptation layer fragmentation on one or more hops on the path from an IP sender to an IP receiver, and to provide an indication of preferred (smaller) packet sizes on these hops. The main objective of this version of the draft is to present a complete design in order to be able to gauge the complexity of the approach against the gains to be expected from implementing it. Comments are appreciated and should go to the intarea@ietf.org mailing list. "Using the IPv6 Flow Label for Server Load Balancing", Brian Carpenter, Sheng Jiang, Willy Tarreau, 5-Dec-12, This document describes how the IPv6 flow label as currently specified can be used to enhance layer 3/4 load distribution and balancing for large server farms. "Home Documents for HTTP APIs", Mark Nottingham, 8-May-13, This document proposes a "home document" format for non-browser HTTP clients. Note to Readers This draft should be discussed on the apps-discuss mailing list; see [apps-discuss]. "Representing phonetics for Japanese names in Atom feeds", Murata Makoto, 17-Mar-13, This specification introduces an attribute for representing Japanese phonetics within feeds of the Atom Syndication Format [RFC4287]. Such phonetics MAY be attached to author names and article titles. This attribute is applicable to OPDS(Open Publication Distribution System)[OPDS], which is based on Atom. "Supercharged Codes", Erik Stauffer, BZ Shen, Soumen Chakraborty, Djordje Tujkovic, Jing Huang, Shiv Shet, Kamlesh Rath, 29-Mar-13, This document describes a fully-specified FEC scheme for the Supercharged forward error correction code. Supercharged codes are designed for use on the erasure channel. Coding for the erasure channel commonly arises for data transmission over the internet, where lower layers either successfully deliver packets or fail to deliver them. Coding is required to insure that data is not lost, even if packets are lost at the lower layers. Error free reception is important for multimedia applications, such as streaming, where it may not be possible to correct an error in time by any other means. Coding insures that lost packets can be recovered. "Constructing inter-AS power shortest protection TE-LSPs using BGP", Shankar Raman, Balaji Venkat, Gaurav Raina, Vasan Srini, 29-Jan-13, In this paper, we propose a framework to build protection / backup paths for power shortest primary inter-AS TE-LSPs. The primary path is built within 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 consumed-power-to-available-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. Once the primary paths have been built we use the same techniques to build backup power shortest paths in a similar manner except by excluding the nodes (ASes) and links (between these ASes) that are present in the primary path. This way the backup path does not traverse any of the ASes or links between these ASes of the primary path so constructed. 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. "NVO3 Data Plane Requirements", Nabil Bitar, Marc Lasserre, Florin Balus, Thomas Morin, Lizhong Jin, Bhumip Khasnabish, 28-Nov-12, Several IETF drafts relate to the use of overlay networks to support large scale virtual data centers. This draft provides a list of data plane requirements for Network Virtualization over L3 (NVO3) that have to be addressed in solutions documents. "Operational Considerations for Tunnel Fragmentation and Reassembly", Fred Templin, 27-Mar-13, The Maximum Transmission Unit (MTU) for popular IP-in-IP tunnels is currently recommended to be set to 1500 (or less) minus the length of the encapsulation headers when static MTU determination is used. This requires the tunnel ingress to either fragment any IP packet larger than the MTU or drop the packet and return an ICMP Packet Too Big (PTB) message. Concerns for operational issues with Path MTU Discovery (PMTUD) point to the possibility of MTU-related black holes when a packet is dropped due to an MTU restriction. The current "Internet cell size" is effectively 1500 bytes (i.e., the minimum MTU configured by the vast majority of links in the Internet) and should therefore also be the minimum MTU assigned to tunnels, but this has proven to be problematic in common operational practice. This document therefore discusses operational considerations for tunnel fragmentation and reassembly necessary to accommodate this Internet cell size. "Trust Assertions for Certificate Keys", Moxie Marlinspike, 7-Jan-13, This document defines a TLS Extension that enables a TLS server to support "pinning" to a self-chosen signing key. A client contacting a pinned host will require the server to present a signature from the signing key over the TLS server's public key. "Forwarding and Control Element Separation (ForCES) OpenFlow Model Library", Evangelos Haleplidis, Omar Cherkaoui, Susan Hares, Weiming Wang, 25-Apr-13, This document describes the OpenFlow switch in Logical Function Blocks (LFBs) used in the Forwarding and Control Element Separation (ForCES). The LFB classes are defined according to the ForCES Forwading Element (FE) model and ForCES protocol specifications. The library includes the descriptions of the OpenFlow LFBs and the XML definitions. "CoAP Payload-Length Option Extension", Kepeng Li, Xianghui Sun, 26-Jan-13, This document defines an extension to the Constrained Application Protocol (CoAP) to add one new option: Payload-Length, which is used to indicate the length of the payload of the message. "Conference Focus Indicating CCMP Support", Rifaat Shekh-Yusef, Mary Barnes, 10-May-13, The Centralized Conferencing Manipulation Protocol document defines a way for a client to discover a conference control server that supports CCMP. However, it does not define a way for a client involved in a conference to determine if the conference focus supports CCMP. This information would allow a CCMP-enabled client that joins a conference using SIP to also register for the XCON conference event package RFC 4575 [RFC4575] and take advantage of CCMP operations on the conference. This document describes a few options to address the above limitation with the pros and cons for each approach, and recommends two to be used depending on the need of the UA. The first approach uses the Call-Info header and as a result this document updates RFC 3261 [RFC3261]. The second approach defines a new value for the 'purpose' parameter in the 'service-uris' element in the SIP conferencing event package, and as a result this document updates RFC 4575 [RFC4575]. "ICTP - Information Centric Transport Protocol for CONET ICN", Stefano Salsano, Andrea Detti, Nicola Blefari-Melazzi, Matteo Cancellieri, 30-Nov-12, 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 transport protocol should also be used to further segment the chunks rather than relying to IP fragmentation. In this memo we define ICTP (Information Centric Transport Protocol), a receiver driven transport protocol for ICN, which relies on the CONET ICN solution described in a companion draft. "YANG-API Protocol", Andy Bierman, Martin Bjorklund, 30-Nov-12, This document describes a RESTful protocol that provides a programmatic interface over HTTP for accessing data defined in YANG, using the datastores defined in NETCONF. "Omniscient AS112 Servers", Warren Kumari, William Sotomayor, Joe Abley, Ray Bellis, 25-Feb-13, The AS112 Project loosely coordinates Domain Name System (DNS) servers to which DNS zones corresponding to private use addresses are delegated. Queries for names within those zones have no useful responses in a global context. The purpose of this project is to reduce the load of such junk queries on the authoritative name servers that would otherwise receive them, and instead direct the load to name servers operated within the AS112 project. Adding and dropping zones from the AS112 servers is difficult, due to the loosely-coordinated nature of the project. This document proposes a mechanism by which AS112 name servers could answer authoritatively for all possible zones. This eliminates the add/drop problem, changing it to a matter of delegation within the DNS and requiring no operational changes on the servers themselves. This document updates RFC 6304. "JSON Hypertext Application Language", Mike Kelly, 12-Feb-13, This document proposes a media type for representing resources and their relations with hyperlinks. "Using DNS Security Extensions (DNSSEC) and DNS-based Authentication of Named Entities (DANE) as a Prooftype for XMPP Domain Name Associations", m&m, Peter Saint-Andre, 22-Feb-13, This document defines a prooftype that uses DNS-based Authentication of Named Entities (DANE) for associating a domain name with an XML stream in the Extensible Messaging and Presence Protocol (XMPP). It also defines a method that uses DNS Security (DNSSEC) for securely delegating a source domain to a derived domain in XMPP. "Indoor Signal Position Conveyance", Kipp Jones, Christopher Steger, 8-May-13, Location Information Servers rely on signal surveys to create a signal map allowing for subsequent device location determination. This document describes a method by which a Survey Device is able to provide indoor location related measurement data to a LIS for positioning purposes. Location related measurement information comprises observations concerning properties related to the position of a Survey Device and the radio, electromagnetic, and other observable environmental measures as perceived by the Survey Device. These measurements could be data about Wi-Fi signals, Bluetooth signals, barometric pressure, or any other environmental measurement which could sent to a LIS for subsequent processing to help determine the location of devices that later enter the venue. A basic set of location-related measurements, data rights disclosure and location types are defined. "Definition of Managed Objects for the Lightweight On-demand Ad hoc Distance-vector Routing Protocol - Next Generation (LOADng)", Ulrich Herberg, Robert Cole, Thomas Clausen, 7-Jan-13, 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 Lightweight On-demand Ad hoc Distance-vector Routing Protocol - Next Generation (LOADng) process on a router. The MIB module defined in this memo, denoted LOADng-MIB, also reports state. While LOADng is layer agnostic and can be run with different address families (e.g., on L2 using MAC addreses, or on L3 using IP addresss), this MIB module assumes that LOADng is used on L3, and uses only IPv4/IPv6 addresses. "A New HTTP Status Code to Report Legal Obstacles", Tim Bray, 11-Jan-13, This document specifies an additional Hypertext Transfer Protocol (HTTP) status code for use when resource access is denied due to legal demands. "Extending Use of the IPv6 Flow Label for Load Balancing Persistence", Brian Carpenter, Sheng Jiang, Willy Tarreau, 5-Dec-12, This document describes how the IPv6 flow label could be used in an extended role to simplify persistence mechanisms for load distribution and balancing for large server farms. "Link relation Type Registrations for OAuth 2", William Mills, 4-Feb-13, Defines link relation type registrations for the OAuth 2 authentication framework and OAuth 1.0a. "DNS Extension for Autonomous Internet(AIP)", Yuping Diao, Diao Yongping, Ming Liao, 22-Dec-12, With the reality of Internet, Autonomous Internet technology in this article constructs independent autonomous extensible domain name architecture and domain name hierarchy through current domain name architecture, provides independent root DNS server, inner/outer DNS resolution mechanism for each autonomous internet network system, and provides reformation and transition solution from current Internet to realize autonomy even in unilateral action. "NVO3 Operational Requirements", Peter Ashwood-Smith, Ranga Iyengar, Tina Tsou, Ali Sajassi, Mohamed Boucadair, Christian Jacquenet, Masahiro Daikoku, 31-Jan-13, This document provides framework and requirements for Network Virtualization over Layer 3 (NVO3) Operations, Administration, and Maintenance (OAM). This document for the most part gathers requirements from existing IETF drafts and RFCs which have already extensively studied this subject for different data planes and layering. As a result this draft is high level and broad. We begin to ask which are truly required for NVO3 and expect the list to be narrowed by the working group as subsequent versions of this draft are created. "IP Fast Re-Route with Fast Notification", Andras Csaszar, Gabor Envedi, Jeff Tantsura, Sriganesh Kini, John Sucec, Subir Das, 25-Feb-13, This document describes the benefits and main applications of sending explicit fast notification (FN) packets to routers in an area. FN packets are generated and processed in the dataplane, and a single FN service can substitute existing OAM methods for remote failure detection, such as a full mesh of multi-hop BFD session. The FN service, therefore, decreases network overhead considerable. The main application is fast reroute in pure IP and in IP/LDP-MPLS networks called IPFRR-FN. The detour 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; moreover it is an efficient solution to protect against BGP ASBR failures as well as VPN PE router failures. IPFRR-FN can be a supplemental tool to provide FRR when LFA cannot repair a failure case, while it can be a replacement of existing ASBR/PE protection mechanisms by overcoming their scalability and complexity issues. "An FTP Application Layer Gateway (ALG) for IPv4-to-IPv6 Translation", Tina Tsou, Simon Perreault, Jing Huang, 15-Jun-12, An FTP ALG for NAT64 was defined in RFC 6384. Its scope was limited to an IPv6 client connecting to an IPv4 server. This memo updates RFC 6384 with the case of an IPv4 client connecting to an IPv6 server. "Stateless IPv4 Network Address Translation", Tina Tsou, Will Liu, Simon Perreault, Reinaldo Penno, Maoke Chen, 22-Oct-12, This memo describes a protocol for decentralizing IPv4 NAT to the customer-premises equipment (CPE) such that no state information is kept on the central NAT device. The CPE uses a restricted source port set that is encoded in its provisioned IPv4 WAN address. The NAT device performs only strictly stateless address (not port) translation. "Indication of support for reverse keep-alive", Christer Holmberg, Oscar Gallego, 19-Dec-12, This specification defines a new Session Initiation Protocol (SIP) Via header field parameter, "rkeep". The "rkeep" parameter allows a SIP entity to indicate willingness to receive keep-alives from its adjacent downstream SIP entity, the adjacent downstream SIP entity to indicate willingness to send keep-alives, and for SIP entities willing to send keep-alives to inform the receiver about the keep- alive interval. "An SNMP MIB extension to RFC3591 to manage optical interface parameters of DWDM applications", Gabriele Galimberti, Ruediger Kunze, Dharini Hiremagalur, 23-Feb-13, This memo defines a module 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 Dense Wavelength Division Multiplexing (DWDM) interfaces or characterized by the Optical Transport Network (OTN). This is an extension of the RFC3591 to support the optical parameters mainly but not only described in recommendations like ITU-T 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. "Request Routing and Content Acquisition", Ge Chen, Mian Li, Hongfei Xia, Jie Liang, 24-Dec-12, This document illustrates the details of an alternative method that can be used to provide request routing and content acquisition services. "OmniBroker Protocol", Phillip Hallam-Baker, 17-May-13, An Omnibroker is an agent chosen and trusted by an Internet user to provide information such as name and certificate status information that are in general trusted even if they are not trustworthy. Rather than acting as a mere conduit for information provided by existing services, an Omnibroker is responsible for curating those sources to protect the user. The Omnibroker Protocol (OBP) provides an aggregated interface to trusted Internet services including DNS, OCSP and various forms of authentication service. Multiple transport bindings are supported to permit efficient access in virtually every common deployment scenario and ensure access in any deployment scenario in which access is not being purposely denied. "Using PKIX over Secure HTTP (POSH) as a Prooftype for XMPP Domain Name Associations", m&m, Peter Saint-Andre, 22-Feb-13, This document defines a prooftype involving PKIX over Secure HTTP (POSH) for associating a domain name with an XML stream in the Extensible Messaging and Presence Protocol (XMPP). It also defines a method involving HTTPS redirects (appropriate for use with the POSH prooftype) for securely delegating a source domain to a derived domain in XMPP. "Domain Name Associations (DNA) in the Extensible Messaging and Presence Protocol (XMPP)", Peter Saint-Andre, m&m, 15-Apr-13, This document improves the security of the Extensible Messaging and Presence Protocol (XMPP) in two ways. First, it specifies how "prooftypes" can establish a strong association between a domain name and an XML stream. Second, it describes how to securely delegate a source domain to a derived domain, which is especially important in virtual hosting environments. "Use Cases for ALTO with Software Defined Networks", Haiyong Xie, Tina Tsou, Diego Lopez, Hongtao Yin, 9-Jan-13, The introduction of SDN fundamentally changes the way that the application layer traffic optimization (ALTO) works. This draft describes two architectures, the Vertical Architecture and the Horizontal Architecture, allowing coherent coexistence of ALTO and software defined network (SDN). Unique requirements for design and operations are identified and summarized, suggesting that the Vertical Architecture allows better division, management, flexibility, privacy control and long-term evolution of the network. We also define the main interactions and information flows, and present a set of use cases to illustrate how we extend ALTO to support SDN, in the Vertical Architecture. "CDNI Request Routing with SDN", Myung-Ki Shin, Seungik Lee, Dukhyun Chang, Ted Kwon, 13-Feb-13, Software-defined networking (SDN) is emerging and intensively discussed as one of the most promising technologies to provide centralized, programmable control planes for network service providers (NSPs). In this sense, SDN could be also considered as one of candidates to facilitate CDNI Request Routing. This document discusses how SDN can be used for downstream CDN selection within CDNI request routing. "VPWS support in E-VPN", Sami Boutros, Ali Sajassi, Samer Salam, John Drake, Jeff Tantsura, 25-Feb-13, This document describes how E-VPN can be used to support virtual private wire service (VPWS) in MPLS/IP networks. E-VPN enables the following characteristics for VPWS: active/standby as well as active/active multi-homing with flow-based load-balancing, eliminates the need for single-segment and multi-segment PW signaling, and provides fast protection using data-plane prefix independent convergence upon node or link failure. "Routing optimization in DMM", Kaiping Xue, Lin Li, Peilin Hong, Pete McCann, 25-Dec-12, This draft proposes a PMIP-based routing optimization method in distributed anchor architecture. The anchor of the mobile node is able to communicate with the anchor of corresponding node directly using optimized routing. In this draft, there are two modes for the setup of routing optimization: the direct mode and the relay mode. The difference of them lies in that the routing optimization is set up directly or under the assistance of a third anchor. The situation that Communication Node(CN) is a fixed terminal or a content server is also considered and 3 solutions are provided correspondingly. The method proposed in this draft can reduce the delay and ve signaling overhead in the current scheme. "TMPP for Both Two MPTCP-unaware Hosts", Kaiping Xue, Jing Guo, Peilin Hong, Lei Zhu, Fang Yu, 25-Dec-12, Transparent MPTCP Proxy(TMPP) is an introduced network-based function, which is under MPTCP architecture. It can help two MPTCP- unaware hosts enjoy multipath support, and can be extensively used both in the access networks and operators' networks. Meanwhile, in MPTCP architecture with TMPP, TMPP needs to modify the received packets and transmit them again(just like gateway in NAT environment). In this document, we also discuss the guarantee for data transfer on TMPP's side. The consideration of data transfer can be expanded to the MPTCP architecture with proxy. "Flow Mobility In Multi-LMA Environment", Kaiping Xue, Dan Ni, Peilin Hong, Anthony Chan, 25-Dec-12, PMIPv6 allows multiple Local Mobility Anchors(LMA) to exist in a PMIPv6 domain, it MAY cause that different interfaces of a mobile node(MN) are anchored to different LMAs. In this document, we propose to discuss how to support flow mobility in multi-LMA environment. Among the discussed scenarios, The scenario of different interfaces with different MAGs in multi-LMA environment cannot use traditional ways to realize flow mobility to an existing interface. "Path Computation Element (PCE) Extensions for Link State Conflict Avoidance Mechanism in Optical Transport Networks", Xuefeng Lin, Li Xin, Jie Zhang, Min Zhang, Hongxiang Wang, 1-Jan-13, This document proposes a PCE based link state conflict avoidance mechanism. Path Computation Element (PCE) can compute a network path or route based on the information stored in Traffic Engineering Database (TED) and TED collects the link resources information through the OSPF-TE protocol. The proposed conflict avoidance mechanism gives each link two state which respectively represents the resource in this link is changed or not. The extended OSPF-TE protocol will also flood the link state information when it floods the link resources information. PCE will add the link state to the calculated path when it returns the calculated path to Path Computation Clients (PCC). When the RSVP-TE protocol reserves the resource along the calculated path, it will compare the link state stored in the calculated path with the link state stored in the local. If the link state between the calculated path and the local is inconsistent then the RSVP-TE protocol will stop the resource reservation process, release the reserved resource and promote the OSPF-TE protocol to flood the Link resources information immediately. "LISP ITR Graceful Restart", Damien Saucez, Olivier Bonaventure, Luigi Iannone, Clarence Filsfils, 26-Dec-12, The Locator/ID Separation Protocol (LISP) is a map-and-encap mechanism to enable the communication between hosts identified with their Endpoint IDentifier (EID) over the Internet where EIDs are not routable. To do so, packets toward EIDs are encapsulated in packets with routing locators (RLOCs) to form dynamic tunnels. An Ingress Tunnel Router (ITR) that encapsulates EID packets determines tunnel endpoints via mappings that associate EIDs to RLOCs. Before encapsulating a packet, the ITR queries the mapping system to obtain the mapping associated to the EID of the packet it must encapsulate. Such mapping is cached by the ITR in its local EID-to-RLOC cache for any subsequent encapsulation for the same EID. LISP is scalable because the EID-to-RLOC cache of an ITR, which is initially empty, is populated progressively according to the traffic going through the ITR. However, after an ITR is restarted, e.g., for maintenance reason, its cache is empty which means that all packets that are re- routed to the freshly restarted ITR will cause cache misses and a potentially high loss rate. In this draft, we present mechanisms to reduce the negative impact on traffic caused by the restart of an ITR in a LISP network. "A Roadmap for Transmission Control Protocol (TCP) Specification Documents", Martin Duke, Robert Braden, Wesley Eddy, Ethan Blanton, Alexander Zimmermann, 21-May-13, This document contains a "roadmap" to the Requests for Comments (RFC) documents relating to the Internet's Transmission Control Protocol (TCP). This roadmap provides a brief summary of the documents defining TCP and various TCP extensions that have accumulated in the RFC series. This serves as a guide and quick reference for both TCP implementers and other parties who desire information contained in the TCP-related RFCs. "IPv6 Path MTU Updates", Fred Templin, 14-Jan-13, IPv6 intentionally deprecates fragmentation by routers in the network. Instead, links with restricting Maximum Transmission Units (MTUs) must either drop each too-large packet and return an ICMPv6 Packet Too Big (PTB) message or perform link-specific fragmentation and reassembly (also known as "link adaptation") at a layer below IPv6. This latter category of links is often performance-challenged to accommodate steady-state link adaptation. A common case that exhibits these link characteristics is seen for IPv6-in-IP tunnels. Additionally, IPv6 nodes can avoid path MTU discovery issues even when no link adaptation is necessary by performing a small amount of fragmentation and/or by probing the path as necessary. This document therefore proposes an update to the base IPv6 specification to better accommodate path MTU issues. "Loop Free RPL", Jianlin Guo, Philip Orlik, Ghulam Bhatti, 27-Dec-12, IETF has been developing IPv6 based standards for Low-power and Lossy Networks (LLNs) to meet requirements of constrained applications, such as field monitoring, inventory control and so on. IPv6 Routing Protocol for LLNs (RPL) has been published in [RFC6550]. Based on routing metrics and constraints [RFC6551], RPL builds Directed Acyclic Graph (DAG) topology to establish bidirectional routes for LLNs for traffic types of multipoint-to-point, point-to-multipoint, and point-to-point. RPL routes are optimized for traffic to or from one or more roots that act as sinks. As a result, a DAG is partitioned into one or more Destination Oriented DAGs (DODAGs), one DODAG per sink. RPL is widely considered as a feasible routing protocol for LLNs. However, DODAG loops and lack of a loop free DODAG local repair mechanism are two open issues to be addressed. This draft introduces an alternative rank and an Objective Function to eliminate DODAG loops in RPL. Based on the proposed rank and Objective Function, this draft introduces a loop free RPL. "Connecting Disparate TRILL-based Data Center/PBB/Campus sites using BGP", Radia Perlman, Bhargav Bhikkaji, Balaji Venkataswami, Ramasubramani Mahadevan, Shivakumar Sundaram, Narayana Swamy, 19-Feb-13, There is a need to connect (a) TRILL based data centers or (b) TRILL based networks which provide Provider Backbone like functionalities or (c) Campus TRILL based networks over the WAN using one or more ISPs that provide regular IP+GRE or IP+MPLS transport. Some of the solutions proposed as in [DRAFT-EVPN] have not dealt with the scalable methods in their details as to how these services could be provided such that multiple TRILL sites can be inter-connected with issues like nick-name collisions for unicast and multicast being taken care of. It has been found that with extensions to BGP and a scalable method on Provider edge devices the problem statement which we will define below can be handled. Specifically the division of the nick-name into site-id and Rbridge-ID is one that can limit the number of sites that can be interconnected and the number of Rbridges within each such site that can be provisioned. The draft proposed herein deals / overcomes these issues by not limiting the number of sites and Rbridges within a TRILL site interconnect. Only the maximum space for a nick-name which happens to be 16 bits is the actual limit. MAC moves across TRILL sites and within TRILL sites can also be realized. This document / proposal envisions the use of BGP-MAC- VPN vrfs at the ISP cloud PE devices. We deal in depth with the control plane and data plane particulars for unicast and multicast in this scheme. Additionally Provider Backbone like functionality is also covered. "Practices for scaling ARP and ND for large data centers", Linda Dunbar, Warren Kumari, Igor Gashinsky, 13-Mar-13, This draft documents some operational practices that allow ARP/ND to scale in data center environments. "Problem Details for HTTP APIs", Mark Nottingham, Erik Wilde, 25-Feb-13, This document defines a "problem detail" as a way to carry machine- readable details of errors in a HTTP response, to avoid the need to invent new error response formats for HTTP APIs. Note to Readers This draft should be discussed on the apps-discuss mailing list [1]. "Managing and removing automatic version rollback in TLS Clients", Yngve Pettersen, 9-Jan-13, Ever since vendors started deploying TLS 1.0 clients, these clients have had to handle server implementations that do not tolerate the TLS version supported by the client, usually by automatically signaling an older supported version instead. Such version rollbacks represent a potential security hazard, if the older version should become vulnerable to attacks. The same history repeated when TLS Extensions were introduced, as some servers would not negotiate with clients that sent these protocol extensions, forcing clients to reduce protocol functionality in order to maintain interoperability. This document outlines a procedure to help clients decide when they may use version rollback to maintain interoperability with legacy servers, under what conditions the clients should not allow version rollbacks, such as when the server has indicated support for the TLS Renegotiation Information extension. The intention of this procedure is to limit the use of automatic version rollback to legacy servers and eventually eliminate its use. "TRILL Resilient Distribution Trees", Mingui Zhang, Tissa Senevirathne, Janardhanan Pathangi, Ayan Banerjee, Anoop Ghanwani, 23-Apr-13, TRILL protocol provides layer 2 multicast data forwarding using IS-IS link state routing. Distribution trees are computed based on the link state information through Shortest Path First calculation and shared among VLANs across the campus. When a link on the distribution tree fails, a campus-wide recovergence of this distribution tree will take place, which can be time consuming and may cause considerable disruption to the ongoing multicast service. This document proposes to build the backup distribution tree to protect links on the primary distribution tree. Since the backup distribution tree is built up ahead of the link failure, when a link on the primary distribution tree fails, the pre-installed backup forwarding table will be utilized to deliver multicast packets without waiting for the campus-wide recovergence, which minimizes the service disruption. "Metalink/XML Clients, Publishers, and Caches", Anthony Bryan, Tatsuhiro Tsujikawa, Neil McNab, 17-Jan-13, This document specifies behavior for Metalink/XML clients, publishers, and proxy caches. Metalink XML files contain multiple download locations (mirrors and Peer-to-Peer), cryptographic hashes, digital signatures, and other information. Metalink clients can use this information to make file transfers more robust and reliable. Normative requirements for Metalink/XML clients, publishers, and proxy caches are described here. "Best Practices for HTTP-CoAP Mapping Implementation", Angelo Castellani, Salvatore Loreto, Akbar Rahman, Thomas Fossati, Esko Dijk, 3-Jan-13, This draft describes advanced features for HTTP-CoAP proxy implementors. It details deployment options, discusses possible approaches for URI mapping, and provides useful considerations related to protocol translation. "Definition of Managed Objects for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", Juergen Schoenwaelder, Anuj Sehgal, Tina Tsou, Cathy Zhou, 6-Feb-13, 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 IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs). "precis implementation report", Takahiro NEMOTO, Yoshiro Yoneya, 25-Feb-13, This document reports implementation experience of precis framework [I-D.ietf-precis-framework], for SASLprepbis [I-D.ietf-precis-saslprepbis], Nickname [I-D.ietf-precis-nickname] and XMPPbis [I-D.ietf-xmpp-6122bis], and findings from the experience. And this document further discusses considerations to implement precis framework. "Framework and Requirements for GMPLS based control of Flexi-grid DWDM networks", Oscar de Dios, Ramon Casellas, Fatai Zhang, Xihua Fu, Daniele Ceccarelli, Iftekhar Hussain, 25-Feb-13, This document defines a framework and the associated control plane requirements for the GMPLS based control of flexi-grid DWDM networks. To allow efficient allocation of optical spectral bandwidth for high bit-rate systems, the International Telecommunication Union Telecommunication Standardization Sector (ITU-T) has extended the recommendations [G.694.1] and [G.872] to include the concept of flexible grid: a new DWDM grid has been developed within the ITU-T Study Group 15 by defining a set of nominal central frequencies, smaller channel spacings and the concept of "frequency slot". In such environment, a data plane connection is switched based on allocated, variable-sized frequency ranges within the optical spectrum. "Enhanced Sleepy Node Support for CoAP", Akbar Rahman, 24-Feb-13, CoAP is a RESTful application protocol for constrained devices. These devices typically have some combination of limited battery power, small memory footprint and low throughput links. It is expected that in CoAP networks there will be a certain portion of devices that are "sleepy" and which may occasionally go into a sleep mode (i.e. go into a low power state to conserve power) and temporarily suspend CoAP protocol communication. This document proposes a minimal and efficient mechanism building on the Resource Directory concept to enhance sleepy node support in CoAP networks. "MSML Package for the Media Control Channel Framework", Adnan Saleem, Steve Dunn, 31-Dec-12, The Media Server Markup Language [RFC5707] is used to control and invoke many different types of services on IP media servers. MSML can be used, for example, to control media server conferencing features such as video layout and audio mixing, create sidebar conferences or personal mixes, and set the properties of media streams. As well, clients can use MSML to define media processing dialogs, which may be used as parts of application interactions with users or conferences. This document describes the use of MSML [RFC5707] language used within the context of Media Control Channel Framework [RFC6230]. The use of MSML [RFC5707] is described here as a standalone package for use within and compliant with the Media Control Channel Framework [RFC6230]. "Deprecation of AS_SET and AS_CONFED_SET in BGP", Warren Kumari, Kotikalapudi Sriram, 6-Jan-13, RFC 6472 (i.e., BCP 172) recommends not using AS_SET and AS_CONFED_SET in BGP. This document updates RFC 4271 and proscribes the use of the AS_SET and AS_CONFED_SET types of the AS_PATH in BGPv4. This is done to simplify the design and implementation of BGP and to make the semantics of the originator of a route more clear. This will also simplify the design, implementation, and deployment of ongoing work in the Secure Inter-Domain Routing Working Group. "Transitive BGP Graceful Restart", Haifeng Zhang, Alvaro Retana, 25-Mar-13, This document defines an extension to BGP Graceful Restart that reduces the negative impact of multiple inter-connected routers restarting. The proposed mechanism does not require any changes to the BGP protocol. "Fast Reroute Extensions to Receiver-Driven RSVP-TE for Multicast Tunnels", Katherine Zhao, Renwei Li, Christian Jacquenet, 8-Jan-13, This document specifies fast reroute procedures to protect multicast LSP tunnels built by mRSVP-TE, a receiver-driven extension to RSVP-TE specified by [I-D.draft-lzj-mpls-receiver-driven-multicast-rsvp-te]. This document is motivated by the observation that the existing FRR solution specified by [RFC4090] and [RFC4875] for the sender-driven RSVP-TE is no longer applicable to the receiver-driven RSVP-TE. "Multi layer implications in GMPLS controlled networks", Daniele Ceccarelli, Francesco Fondelli, Sergio Belotti, Dimitri Papadimitriou, 25-Feb-13, This document describes requirements for MRN application to multiple hierarchies of technologies (e.g. OTN, SDH, ETH). For this purpose, after summarizing MRN definitions, rationales and currently supported applications, a problem statement is introduced together with its implications on GMPLS routing and signaling. New functional requirements are derived and MRN extensions required to address them are identified. "PPSP Tracker Protocol--Extended Protocol", Rachel Huang, Ning Zong, Rui Cruz, Mario Nunes, Joao Taveira, 25-Feb-13, This document specifies an extended Peer-to-Peer Streaming Protocol - Tracker Protocol, which is a new extension protocol complementing the basic core messages and usages specified in the base tracker 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. It extends the base tracker protocol to include new optional messages providing new usages in the communications between peer and tracker. The extension protocol is retro-compatible with the base tracker protocol. "Mapping PMIP Quality of Service in WiFi Network", John Kaippallimalil, 21-Apr-13, This document proposes a model for configuring and mapping PMIP QoS parameters of a mobile network session to the corresponding connection at a WiFi Access Point. In congested network conditions, it is useful for an MN's flows to be policed and shaped at the WLC and WiFi AP to match bandwidth constraints or service priority of the user's subscription. Applying similar QoS management at the WiFi AP and WLC allows optimal use of network resources. Currently, the WiFi AP does not have information on the MNs subscribed bandwidth, or relative priority of its flows or services for per user QoS handling at the WiFi AP. This document provides a model for mapping PMIP QoS to corresponding 802.11e QoS parameters. "Securing Model-C Inter-Provider L2 VPNs with Label Hopping and TicToc", Shankar Raman, Balaji Venkat, Gaurav Raina, Bhargav Bhikkaji, 8-Apr-13, In certain models of inter-provider Multi- Protocol Label Switching (MPLS) based Virtual Private Networks (VPNs) spoofing attack against VPN sites is a key concern. For example, MPLS-based VPN inter- provider model "C" for VPLS, or any L2 VPN purpose is not favoured, owing to security concerns in the dataplane, even though it can scale with respect to maintenance of routing state. Since the inner labels associated with VPN sites are not encrypted during transmission, a man-in-the-middle attacker can spoof packets to a specific L2 VPN site. In this paper, we propose a label-hopping technique which uses a set of randomized labels and a method for hopping amongst these labels using the time instant the packet leaves the port from a sending Provider Edge Router. To prevent the attacker from identifying the labels in polynomial time, we also use an additional label. The proposed technique can be applied to other variants of inter-provider MPLS based VPNs where Multi-Protocol exterior-BGP (MP- eBGP) multi-hop is used. As we address a key security concern, we can make a case for the deployment of MPLS based L2 VPN inter-provider model "C". Specifically we use the TicToc based Precision Time Protocol LSP to provide the timing for determining the time instant at which the packet is sent from the remote end Provider Edge Router and hence calculating when it must have left that peer at the Provider Edge Router in the near / receiving end. This version of the document suggests a better method for gaining more finely granular time slices. This is done by running the PTP LSP between the ASBRs in the ASes that are providing the inter-AS L2VPN service. "Opportunistic Routing based on Users Daily Life Routine", Waldir Moreira, Paulo Mendes, Ronedo Ferreira, Douglas Cirqueira, Eduardo Cerqueira, 25-Apr-13, This document is written in the context of the Delay Tolerant Networking Research Group and will be presented for reviewing by that group. This document defines dLife, an opportunistic routing protocol that takes advantage of time-evolving social structures. dLife belongs to the family of social-aware opportunistic routing protocols for intermittently connected networks. dLife operates based on a representation of the dynamics of social structures as a weighted contact graph, where the weights (i.e., social strengths) express how long a pair of nodes is in contact over different period of times. It considers two complementary utility functions: Time-Evolving Contact Duration (TECD) that captures the evolution of social interaction among pairs of users in the same daily period of time, over consecutive days; and TECD Importance (TECDi) that captures the evolution of user's importance, based on its node degree and the social strength towards its neighbors, in different periods of time. It is intended for use in wireless networks where there is no guarantee that a fully connected path between any source - destination pair exists at any time, a scenario where traditional routing protocols are unable to deliver bundles. Such networks can be sparse mesh, in which case intermittent connectivity is due to lack of physical connections, or dense mesh, in which case intermittent connectivity may be due to high interference or shadowing. In any case, intermittent connectivity can also be due to the availability of devices (e.g., unavailable due to power saving rules). The document presents an architectural overview followed by the protocol specification. "ALTO Extensions for Collecting Data Center Resource Information", Young Lee, Greg Bernstein, Dhruv Dhody, 9-Jan-13, In a networked application environment where resources (e.g., computing, storage, etc.) are geographically distributed in Data Centers, a key decision is to allocate the application request to an "optimal" Data Center location in which to host the application request. Key constraints in this decision include resource availability, network cost, infrastructure constraints (e.g., power) and others. This draft proposes an ALTO extension to support data center resource information model and its related protocol extensions. "", Takuo Suganuma, Naoki Nakamura, Satoru Izumi, Hiroshi Tsunoda, Masahiro Matsuda, Kohei Ohta, 8-Jan-13, This memo defines a portion of the Management Information Base (MIB), the GreenUsage MIB, for use with network management protocols in the Internet community. In particular, the GreenUsage MIB can be used to monitor the power-on/power-off status of electrical devices. "Aware Spanning Tree Topology Change on RBridges", Li Yizhou, Hao Weiguo, Jon, Naveen Nimmu, Anoop Ghanwani, 2-May-13, When a local LAN running spanning tree protocol connecting to TRILL campus via more than one RBridge, there are several ways to perform loop avoidance. One of them illustrated by RFC6325 [RFC6325] A.3 was to make relevant ports on edge RBridges involving in spanning tree calculation. When edge RBridges are emulated as a single highest priority root, the local bridged LAN will be naturally partitioned after running spanning tree protocol. This approach achieves better link utilization and intra-VLAN load balancing in some scenarios. This document describes how the edge RBridges react to topology change occurring in bridged LAN in order to make the abovementioned spanning tree approach function correct. "Path Computation Element (PCE) Protocol Extension for Stateful PCE Usage in GMPLS Networks", Xian Zhang, Young Lee, Fatai Zhang, Ramon Casellas, Oscar de Dios, 21-Feb-13, The Path Computation Element (PCE) facilitates Traffic Engineering (TE) based path calculation in large, multi-domain, multi-region, or multi-layer networks. [Stateful-PCE] provides the fundamental PCEP extensions needed to support stateful PCE functions, without specifying the technology-specific extensions. This memo provides extensions required for PCE communication protocol (PCEP) so as to enable the usage of a stateful PCE capability in GMPLS networks. "PCEP extension for multi-fiber existing in inter-domain link", Jie Zhang, Jingjing Wang, Yongli Zhao, Shanguo Huang, Yun Bai, Zhihong Wang, Xuping Cao, 9-Jan-13, Currently, most route computing algorithms only compute a shortest or an optimal path.The results of this computation just refer to link level, without consideration of fibers. But, in real networks, the link between two adjacent nodes always has multi-fibers. This condition above happens more frequently especially for the gateway nodes in the multi-domain network. Moreover, the number of links between two adjacent domains is always more than one. From the view of parent PCE, the two conditions above will be regarded as the problem of multi-fibers between adjacent nodes. However, most route computing algorithms always can not solve the problem of multi-fiber between adjacent nodes. As a result, parent PCE can not compute the route sequence with specific fibers. It brings distress and problems when parent PCE computing the loose route sequence. In order to solve the problems existing in real networks, an efficient solution will be proposed for parent PCE facing the multi- fiber between adjacent nodes. Some interface and structure will be expanded in this proposal. "Requirements for Supporting P2MP in Flexi-Grid Networks", Yongli Zhao, Xiaosong Yu, Jie Zhang, Jiayu Wang, Xuefeng Lin, 8-Jan-13, Multicasting over WDM optical networks has enabled many popular Point-to-Multipoint (P2MP) applications, such as video conference, interactive distance learning, replicated database, distributed computing, and so on. However, on the one hand, the low-rate multicasting traffic demands cannot make full use of the capacity of the entire wavelength, and on the other hand, new services such as data center migration and cloud applications need higher transmission rates and higher spectrum efficiency. Flexi-grid network is an effective solution to address the problem of transmission rate and spectrum utilization. It overcomes the fixed grid constraint of Wavelength Swithched Optical Network (WSON) by using advanced technologies such as coherent detection and Bandwidth Variable- Wavelength Selective Switches (BV-WSS). Therefore, it is essential to exploit multicasting over flexi-grid networks. This document covers the requirements for supporting P2MP over flexi-grid infrastructure. Specifically, the scope of requirements listed in this document covers the functionality that should be supported by the control plane. "802.1aq and 802.1Qbp Support over EVPN", David Allan, Jeff Tantsura, Don Fedyk, Ali Sajassi, 22-Feb-13, This document describes how Ethernet Shortest Path Bridging MAC mode (802.1aq) and (802.1Qbp) can be combined with EVPN in a way that interworks with PBB-PEs as described in the PBB-EVPN solution in a way that permits operational isolation of each Ethernet network subtending an EVPN core while supporting full interworking between the 3 variations of Ethernet operation. "Automatic Key and Adjacency Management for Routing Protocols", william.atwood@concordia.ca, Revathi Somanatha, 25-Feb-13, When tightening the security of the core routing infrastructure, two steps are necessary. The first is to secure the routing protocols' packets on the wire. The second is to ensure that the keying material for the routing protocol exchanges is distributed only to the appropriate routers. This document specifies requirements on that distribution and proposes the use of a set of protocols to achieve those requirements. "Generalized Multiprotocol Label Switching (GMPLS) External Network Network Interface (E-NNI): Virtual Link Enhancements for the Overlay Model", Igor Bryskin, Wes Doonan, Vishnu Beeram, John Drake, Gert Grammel, Manuel Paul, Ruediger Kunze, Friedrich Armbruster, Cyril Margaria, Oscar de Dios, Daniele Ceccarelli, 12-Mar-13, This memo is a companion document to [RFC4208]. It describes how the client domain networking in the overlay model can be enhanced via presenting to the client the network domain as an overlay topology made of Virtual TE Links. "Network Performance Isolation in Data Centres using Congestion Policing", Bob Briscoe, Murari Sridharan, 25-Feb-13, This document describes how a multi-tenant (or multi-department) data centre operator can isolate tenants from network performance degradation due to each other's usage, but without losing the multiplexing benefits of a LAN-style network where anyone can use any amount of any resource. Zero per-tenant configuration and no implementation change is required on network equipment. Instead the solution is implemented with a simple change to the hypervisor (or container) beneath the tenant's virtual machines on every physical server connected to the network. These collectively enforce a very simple distributed contract - a single network allowance that each tenant can allocate among their virtual machines, even if distributed around the network. The solution uses layer-3 switches that support explicit congestion notification (ECN). It is best if the sending operating system supports congestion exposure (ConEx). Nonetheless, the operator can unilaterally deploy a complete solution while operating systems are being incrementally upgraded to support ConEx and ECN. "Applicability of OSPF Topology-Transparent Zone", Huaimo Chen, Renwei Li, Gregory Cauchie, So Ning, Lei Liu, 3-May-13, This document discusses the applicability of "OSPF Topology- Transparent Zone". It briefs the protocol and its operations first, and then illustrates the application scenarios of OSPF Topology- Transparent Zone. In addition, guidelines for deployment are presented and limitations of the protocol are indicated. This document is intended for accompanying "OSPF Topology-Transparent Zone" to the Internet standards track. "LISP Single-Hop DHT Mapping Overlay", Li Cheng, Jun Wang, 21-Feb-13, This draft specifies the LISP Single-Hop Distributed Hash Table Mapping Overlay (LISP-SHDHT), a distributed mapping database which embodies SHDHT Nodes to maintain (Key, value) pairs for LISP (Locator/ID Separation Protocol)-like architecture, wherein every (key value) pair corresponds to an EID(Endpoint ID)-to-RLOC(Routing Locator) mapping information entry. According to this strategy, EID is hashed to be a unique Resource ID which is used for locating destination DHT Node who maintains mapping entry for the particular EID. Furthermore, adaptive hash space partition method is adopted to solve the load balance problem on SHDHT Nodes which is common on traditional DHT planes. "LISP Replication Engineering", Florin Coras, Albert Cabellos-Aparicio, Jordi Domingo-Pascual, Fabio Maino, Dino Farinacci, 25-Feb-13, This document describes a method to build and optimize inter-domain LISP router distribution trees for locator-based unicast and multicast replication of EID-based multicast packets. "Extension to the Link Management Protocol (LMP/DWDM -rfc4209) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems to manage black-link optical interface parameters of DWDM application", Dharini Hiremagalur, Gert Grammel, John Drake, Gabriele Galimberti, Zafar Ali, Ruediger Kunze, 22-Feb-13, This memo defines extensions to LMP(rfc4209) 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], G.694.1.[ITU.G694.1] and its extendsions./> "Tail Loss Probe (TLP): An Algorithm for Fast Recovery of Tail Losses", Nandita Dukkipati, Neal Cardwell, Yuchung Cheng, Matt Mathis, 25-Feb-13, Retransmission timeouts are detrimental to application latency, especially for short transfers such as Web transactions where timeouts can often take longer than all of the rest of a transaction. The primary cause of retransmission timeouts are lost segments at the tail of transactions. This document describes an experimental algorithm for TCP to quickly recover lost segments at the end of transactions or when an entire window of data or acknowledgments are lost. Tail Loss Probe (TLP) is a sender-only algorithm that allows the transport to recover tail losses through fast recovery as opposed to lengthy retransmission timeouts. If a connection is not receiving any acknowledgments for a certain period of time, TLP transmits the last unacknowledged segment (loss probe). In the event of a tail loss in the original transmissions, the acknowledgment from the loss probe triggers SACK/FACK based fast recovery. TLP effectively avoids long timeouts and thereby improves TCP performance. "Management of Networks with Constrained Devices: Problem Statement, Use Cases and Requirements", Mehmet Ersue, Dan Romascanu, Juergen Schoenwaelder, 14-Feb-13, This document provides a problem statement and discusses the use cases and requirements for the management of networks with constrained devices. "Requirements for IP/MPLS network transmission interruption duration", Peng Fan, Lianyuan Li, 25-Feb-13, The transmission performance of IP/MPLS network affects upper layer services and networks, but there is no consensus in the industry on transmission interruption for IP/MPLS network up to now. This memo studies requirements for the interruption duration criteria in several service scenarios. "LISP Control-Plane Multicast Signaling", Dino Farinacci, Maria Napierala, 7-Jan-13, This document describes an alternate method to signal multicast tree building among xTRs in multicast capable LISP sites. This approach avoids the need to run a multicast routing protocol on the LISP overlay. "Shared Memory Communications over RDMA", Mike Fox, Constantinos Kassimis, Jerry Stevens, 13-Dec-12, This document describes the Shared Memory Communications over RDMA (SMC-R) protocol. This protocol provides RDMA communications to TCP endpoints in a manner that is transparent to socket applications. It further provides for dynamic discovery of partner RDMA capabilities and dynamic setup of RDMA connections, transparent high availability and load balancing when redundant RDMA network paths are available, and it maintains many of the traditional TCP/IP qualities of service such as filtering that enterprise users demand, as well as TCP socket semantics such as urgent data. "Framework for Point-to-Multipoint MPLS-TP OAM", Yoshinori Koike, Takafumi Hamano, Masatoshi Namiki, 25-Feb-13, The MPLS transport profile (MPLS-TP) is being standardized to enable carrier-grade packet transport. This document discusses and specifies the P2MP framework primarily related to OAM and related management in MPLS-TP networks. This document mainly refers to RFC5654 and RFC6371. The main focus is on the details that are not covered or not clarified in relevant RFCs such as RFC5654, RFC5860, RFC5921, RFC5951, RFC6371, and draft-mpls- tp-p2mp-framework. Note: This I-D was made and updated including the discussions in ITU- T SG15, which were described in Liaison Statements such as (https://datatracker.ietf.org/liaison/1235/) 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. "RADIUS Extensions for IPv4-Embedded Multicast and Unicast IPv6 Prefixes", Qian Wang, Wei Meng, Cui Wang, Mohamed Boucadair, 25-Feb-13, This document specifies a new Remote Authentication Dial-In User Service (RADIUS) attribute to carry the Multicast-Prefixes-64 information, aiming to delivery the Multicast and Unicast IPv6 Prefixes to be used to build multicast and unicast IPv4-Embedded IPv6 addresses. this RADIUS attribute is defined based on the equivalent DHCPv6 OPTION_PREFIX64 option. "HIP Middlebox Puzzle Offloading and End-host Notification", Rene Hummen, Martin Henze, Jens Hiller, 9-Jan-13, The Host Identity Protocol [RFC5201] is a secure signaling protocol with a cryptographic namespace. It provides the communicating peers with a cryptographic puzzle mechanism to protect against Denial of Service (DoS) attacks exploiting the computation and memory overheads of the protocol exchange. This document specifies an extension of the protocol that enables an on-path network entity to assist in the choice of the puzzle difficulty in case of an attack. Furthermore, it defines a modification of the puzzle mechanism that enables a host to delegate puzzle solving to an on-path network entity. "LSP-Ping Mechanisms for E-VPN and PBB-EVPN", Parag Jain, Sami Boutros, Samer Salam, 19-Feb-13, LSP-Ping is a widely deployed Operation, Administration, and Maintenance (OAM) mechanism in MPLS networks. This document describes mechanisms for detecting data-plane failures using LSP Ping in MPLS based E-VPN and PBB-EVPN networks. "A Framework for Semantic IPv6 Prefix and Gap Analysis", Sheng Jiang, Qiong Sun, Ian Farrer, 30-Jan-13, Some Internet Service Providers and enterprises require detailed information about the payload of traffic, so that packets can be treated differently and efficiently. Packet-level differentiation can also enable flow-level and user-level differentiation. With its large address space, IPv6 allows semantics to be embedded into addresses by assigning additional significance to specific bits within the prefix. Using these semantics, routers and other intermediary devices can easily apply relevant policies as required. This document describes a framework for such an approach. It also analyses the technical advantages and limitations associated with such an approach. This informational document only discusses the usage of semantics within a single network, or group of interconnected networks which share a common addressing policy, referred to as a Semantic Prefix Domain. The document is NOT intended to suggest the standardization of any common global semantics. "RADIUS Attribute for 4rd", Sheng Jiang, Yu Fu, Bing Liu, 20-Feb-13, IPv4 Residual Deployment via IPv6 (4rd) 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) 4rd options has been defined to configure 4rd 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 4rd configuration information from AAA server to BNG. The 4rd RADIUS attribute are designed following the simplify principle. It provides just enough information to form the correspondent DHCPv6 4rd option. "JSON Web Encryption JSON Serialization (JWE-JS)", Michael Jones, 28-Dec-12, The JSON Web Encryption JSON Serialization (JWE-JS) is a means of representing encrypted content using JavaScript Object Notation (JSON) data structures. This specification describes a means of representing secured content as a JSON data object (as opposed to the JWE specification, which uses a compact serialization with a URL-safe representation). It enables the same content to be encrypted to multiple parties (unlike JWE). Cryptographic algorithms and identifiers used with this specification are described in the separate JSON Web Algorithms (JWA) specification. The JSON Serialization for related digital signature and MAC functionality is described in the separate JSON Web Signature JSON Serialization (JWS-JS) specification. "JSON Web Signature JSON Serialization (JWS-JS)", Michael Jones, John Bradley, Nat Sakimura, 28-Dec-12, The JSON Web Signature JSON Serialization (JWS-JS) is a means of representing content secured with digital signatures or Message Authentication Codes (MACs) using JavaScript Object Notation (JSON) data structures. This specification describes a means of representing secured content as a JSON data object (as opposed to the JWS specification, which uses a compact serialization with a URL-safe representation). It enables multiple digital signatures and/or MACs to be applied to the same content (unlike JWS). Cryptographic algorithms and identifiers used with this specification are described in the separate JSON Web Algorithms (JWA) specification. The JSON Serialization for related encryption functionality is described in the separate JSON Web Encryption JSON Serialization (JWE-JS) specification. "", Ramin Khalili, Nicolas Gast, Miroslav Popovic, Jean-Yves Le Boudec, 18-Feb-13, We show, by measurements over a testbed and by mathematical analysis, that the current MPTCP suffers from two problems: (P1) Upgrading some TCP users to MPTCP can reduce the throughput of others without any benefit to the upgraded users; and (P2) MPTCP users can be excessively aggressive towards TCP users. We attribute these problems to the "Linked Increases" Algorithm (LIA) of MPTCP [4], and more specifically, to an excessive amount of traffic transmitted over congested paths. Our results show that these problems are important and can be mitigated. We believe that the design of the congestion control of MPTCP should be improved. "Object Naming Framework for the Future Internet", Imran Khan, Gyu Lee, Noel Crespi, 27-Feb-13, This document explains the concept of object to object communications and describes object identification for the Future Internet. In order to develop protocols for object to object communications, this document provides the naming architecture according to mapping relationships between host and object(s). In addition, considerations of protocols for naming object are specified. "Third-Party ALTO Server Discovery (3pdisc)", Sebastian Kiesel, Kilian Krause, Martin Stiemerling, 16-May-13, The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications that have to select one or several hosts from a set of candidates capable of providing a desired resource. ALTO is realized by a client-server protocol. Before an ALTO client can ask for guidance it needs to discover one or more ALTO servers that can provide suitable guidance. This document specifies a procedure for third-party ALTO server discovery, which can be used if the ALTO client is not co-located with the actual resource consumer, but instead embedded in a third party such as a peer-to-peer tracker. Technically, the algorithm specified in this document takes one IP address and a U-NAPTR Service Parameter (i.e., "ALTO:http" or "ALTO:https") as parameters. It performs several DNS lookups (for PTR, SOA, and U-NAPTR resource records) and returns one or more URI(s) of information resources related to that IP address. "Using BGP for routing in large-scale data centers", Petr Lapukhov, Ariff Premji, 7-Apr-13, Some service providers build and operate data centers that support over 100,000 servers. In this document, such data centers are referred to as "large-scale" to differentiate them from smaller infrastructures. The environments of this scale have a unique set of network requirements, with emphasis on operational simplicity and network stability. This document summarizes ideas and experience of many people involved in designing and operating large scale data centers using BGP as the only control-plane protocol. The intent here is to report a proven and stable routing design that could be leveraged by others in the industry. "ALTO Extensions to Support Application and Network Resource Information Exchange for High Bandwidth Applications", Young Lee, Greg Bernstein, Taesang Choi, Sreekanth Madhavan, Dhruv Dhody, 8-Jan-13, This draft proposes ALTO information model and protocol extensions to support application and network resource information exchange for high bandwidth applications in partially controlled and controlled environments as part of the infrastructure to application information exposure (i2aex) initiative. "DHCPv6/SLAAC Address Configuration Switching for Host Renumbering", Bing Liu, Wendong Wang, Xiangyang Gong, 14-Jan-13, Sometimes stateful DHCPv6 address configuration and SLAAC may be both available in one network. In ND protocol, there is a "M" (ManagedFlag) flag defined in RA message, which indicates the hosts the DHCPv6 service is available. But for some reason, the ND protocol didn't define the flag as prescriptive but only advisory. This draft proposes to use two reserved bits in RA message to let the network control the hosts that which address configuration mode should be used. This feature is useful for management, especially in a renumbering event. "Transparent SDH/SONET over Packet", Gert Manhoudt, Stephan Roullot, Kin Wong, 8-Feb-13, This document describes the Transparent SDH/SONET over Packet (TSoP) mechanism to encapsulate Synchronous Digital Hierarchy (SDH) or Synchronous Optical NETwork (SONET) bit-streams in a packet format, suitable for Pseudowire (PW) transport over a packet switched network (PSN). The key property of the TSoP method is that it transports the SDH/SONET client signal in its entirety through the PW, i.e., no use is made of any specific characteristic of the SONET/SDH signal format, other than its bit rate. The TSoP transparency includes transporting the timing properties of the SDH/SONET client signal. This ensures a maximum of transparency and a minimum of complexity, both in implementation and during operation. "Software Defined Networks Use Case for Virtual Connection and Network on Demand", Mach Chen, Mike McBride, Liang Ou, 15-Jan-13, Software Defined Networks (SDN) provide a way to virtualize and abstract the network and presents the virtual/abstract resources to the third-party applications/software. The applications/software can, by the programmable interface or Northbound API, request, manipulate and monitor the services that the network provided. With this SDN capability, more innovative services can be introduced and rapidly deployed. Additionally, existing services can be deployed and managed in a much more simple way. This document outlines two use cases that leverage the SDN architecture/model to implement a kind of "self-help" and automated set of network services: Virtual Connection on Demand (VCoD) and Virtual Network on Demand (VNoD). "Congestion control algorithm for lower latency and lower loss media transport", Piers O'Hanlon, Ken Carlberg, 24-Apr-13, This memo provides a design for a congestion control algorithm, for media transport, which aims to provide for lower delay and lower loss communications. "Extensions to OSPF facilitating the deployment of non-backward- compatible changes.", Mike Dubrovsky, Rashmi Shrivastava, Dean Cheng, 16-Feb-13, This document specifies a generic mechanism that facilitates the deployment of non-backward-compatible changes in OSPF protocol. This mechanism allows the OSPF routers to advertise the capability of non- backward-compatible functionality and to make the functionality operational only when supported by all participating routers. Depending on the functionality scope, capability advertisements must be propagated across a link, area or autonomous system (AS). For link and area scope functionality, Router Information Link State Advertisement (LSA) is utilized to propagate the capability information. For the cases when compatibility must be maintained across the whole OSPF autonomous system, new Area Information (AI) LSA is introduced. The AI LSA is a TLV-based analog of Indication- LSA that is used for demand circuit functionality and described in RFC1793. "Intermediate RREP for dynamic MANET On-demand (AODVv2) Routing", Charles Perkins, Ian Chakeres, 28-Nov-12, The Dynamic MANET On-demand (AODVv2) routing protocol is intended for use by mobile routers in wireless, multihop networks. AODVv2 determines unicast routes among AODVv2 routers within the network in an on-demand fashion, offering on-demand convergence in dynamic topologies. This document specifies an extension to AODVv2 (and possibly other reactive routing protocols) enabling intermediate nodes to shorten route discovery times. "Turning off IPv4 Using DHCPv6", Simon Perreault, Wesley George, Tina Tsou, Tianle Yang, 11-Mar-13, This memo defines a new DHCPv6 option for indicating to a dual-stack host or router that IPv4 is to be turned off. "Scenarios and Requirements for IP in Intelligent Transportation Systems", Alexandru Petrescu, Christophe Janneteau, Michael Boc, Witold Klaudel, 26-Mar-13, This draft describes scenarios of vehicular communications that are considered pertinent to Intelligent Transportation Systems. In these scenarios, the necessity of using IP networking technologies and protocols is exposed. "Session Initiation Protocol (SIP) Recording Call Flows", Ram R, Parthasarathi Ravindran, Paul Kyzivat, 25-Feb-13, 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 lists call flows that has snapshot of metadata sent from SRC to SRS, the metadata format for which is described in [I-D.ietf-siprec-metadata] . This is purely an informational document that is written to support the model defined in the metadata draft. "A Framework and Requirements for Energy Aware Control Planes", Alvaro Retana, Russ White, Manuel Paul, 13-Feb-13, There has been, for several years, a rising concern over the energy usage of large scale networks. This concern is strongly focused on campus, data center, and other highly concentrated deployments of network infrastructure. Given the steadily increasing demand for higher network speeds, always-on service models, and ubiquitous network coverage, it is also of growing importance for telecommunication networks both local and wide area in scope. One of the issues in moving forward to reduce energy usage is to ensure that the network can still meet the performance specifications required to support the applications running over it. This document provides an overview of the various areas of concern in the interaction between network performance and efforts at energy aware control planes, as a guide for those working on modifying current control planes or designing new control planes to improve the energy efficiency of high density, highly complex, network deployments. "An Acceptable Use Policy for New ICMP Types and Codes", Melinda Shore, Carlos Pignataro, 26-Mar-13, Concerns about lack of clarity concerning when to add new Internet Control Message Protocol (ICMP) types and/or codes have highlighted a need to describe policies for when adding new features to ICMP is desirable and when it is not. In this document we provide a basic description of ICMP's role in the IP stack and some guidelines for the future. "Multipath RTP (MPRTP) attribute in Session Description Protocol", Varun Singh, Joerg Ott, Teemu Karkkainen, Ralf Globisch, Thomas Schierl, 10-Jan-13, Multipath RTP (MPRTP) is an extension to the Real-time Transport Protocol (RTP) that allows multi-homed endpoints to take advantage of the availability of multiple Internet paths between endpoints to send/receive media packets. This document describes how to express the interface advertisement and negotiation during session setup in SDP (Session Description Protocol). "Multicasting Applications Across Inter-Domain Peering Points", Percy Tarapore, Robert Sayko, ramki, 25-Feb-13, This document examines the process of transporting applications via multicast across inter-domain peering points. The objective is to describe the setup process for multicast-based delivery across administrative domains and document supporting functionality to enable this process. "The OAuth 2.0 Authorization Framework: Holder-of-the-Key Token Usage", John Bradley, Phil Hunt, Anthony Nadalin, Hannes Tschofenig, 25-Feb-13, OAuth 2.0 deployments currently rely on bearer tokens for securing access to protected resources. Bearer tokens require Transport Layer Security to be used between an OAuth client and the resource server when presenting the access token. The security model is based on proof-of-possession: access token storage and transfer has to be done with care to prevent leakage. There are, however, use cases that require a more active involvement of the OAuth client for an increased level of security, particularly to secure against token leakage. This document specifies an OAuth security framework using the holder-of-the-key concept, which requires the OAuth client when presenting an OAuth access token to also demonstrate knowledge of keying material that is bound to the token. "Analysis of Security Automation and Continuous Monitoring (SACM) Use Cases", David Waltermire, Adam Montville, 10-Feb-13, This document identifies use cases, derived functional capabilities, and requirements needed to provide a foundation for creating interoperable automation tools and continuous monitoring solutions that provide visibility into the state of endpoints, user activities, and network behavior. Stakeholders will be able to use these tools to aggregate and analyze relevant security and operational data to understand the organizations security posture, quantify business risk, and make informed decisions that support organizational objectives while protecting critical information. Organizations will be able to use these tools to augment and automate information sharing activities to collaborate with partners to identify and mitigate threats. Other automation tools will be able to integrate with these capabilities to enforce policies based on human decisions to harden systems, prevent misuse and reduce the overall attack surface. "Filtering of Overlapping Routes", Russ White, Alvaro Retana, Susan Hares, 25-Feb-13, This document proposes a mechanism to remove a prefix when it overlaps with a functionally equivalent shorter prefix. The proposed mechanism does not require any changes to the BGP protocol. "Mobility with ICE (MICE)", Dan Wing, Prashanth Patil, Tirumaleswar Reddy, Paal-Erik Martinsen, 16-Jan-13, This specification describes how endpoint mobility can be achieved using ICE. Two mechanisms are shown, one where both endpoints support ICE and another where only one endpoint supports ICE. "MAP Interoperability Testing Results", Xing Li, Congxiao Bao, Guoliang Han, Wojciech Dec, 3-Jan-13, This document presents the testing results of a unified code accommodating encapsulation and translation modes of Mapping of Address and Port (MAP). Experiments show that the unified MAP CE is not only supporting MAP-E and MAP-T modes, but also backward compatible with AFTR of dual-stack lite and stateless/stateful NAT64. "ICMP Extensions for Virtual Network", Derek Yeung, 21-Feb-13, This document specifies the extensions to ICMP that allow virtual network information to be included in an ICMP packet. These extensions can be used to facilitate troubleshooting network problems within a virtual network or across multiple virtual networks. "Power-aware Routing and Traffic Engineering: Requirements, Approaches, and Issues", Beichuan Zhang, Junxiao Shi, Jie Dong, Mingui Zhang, 10-Jan-13, Energy consumption of network infrastructures is rising fast. There are emerging needs for power-aware routing and traffic engineering, which adjust routing paths to help reduce power consumption network- wide. This document gives a high-level analysis on the basic requirements, approaches, and potential issues in power-aware routing and traffic engineering. "Mobility Practices and DMM Gap Analysis", Juan Zuniga, Carlos Bernardos, Telemaco Melia, Charles Perkins, 19-Dec-12, This document describes practices for the deployment of existing mobility protocols in a distributed mobility management (DMM) environment, and identifies the limitations in the current practices with respect to providing the expected DMM functionality. The practices description and gap analysis are performed for IP-based mobility protocols, dividing them into three main families: IP client-based, IP network-based, and 3GPP mobility solutions. "Signaling Virtual Machine Activity to the Network Virtualization Edge", Kireeti Kompella, Yakov Rekhter, Thomas Morin, David Black, 29-Apr-13, This document proposes a simplified approach for provisioning network parameters related to Virtual Machine creation, migration and termination on servers. The idea is to provision the server, then have the server signal the requisite parameters to the relevant network device(s). Such an approach reduces the workload on the provisioning system and simplifies the data model that the provisioning system needs to maintain. It is also more resilient to topology changes in server-network connectivity, for example, reconnecting a server to a different network port or switch. "MPLS PIM Inter-working", Bisong Tao, 13-Mar-13, This document describes a framework for the inter-working between Protocol Independent Multicast [PIM] and a leaf-driven P2MP tunnel signaling protocol so that multiple PIM sites around an MPLS network can form a single PIM domain without compromising PIM's features, scalability, and performance. "File Transfer Protocol HOST Command for Virtual Hosts", Paul Hethmon, Robert McMurray, 16-May-13, The File Transfer Protocol, as defined in RFC 959, 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. "Management Information Base for Virtual Machines Controlled by a Hypervisor", Hirochika Asai, Michael MacFaden, Juergen Schoenwaelder, Yuji Sekiya, Keiichi Shima, Tina Tsou, Cathy Zhou, Hiroshi Esaki, 10-Apr-13, This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, this specifies objects for managing virtual machines controlled by a hypervisor (a.k.a. virtual machine manager). "Stateful Observation in CoAP", Changsha Ma, Peilin Hong, Kaiping Xue, 29-Dec-12, The Observe Option allows a CoAP client to observe changes in the state of resources and obtain a current representation of the last resource state. To be an observer of an origin server's resources, the client is required to register its interest with the server. A successful registration will make the client added into the server's observation list, while a failed one may drive the client to re- register. However, repeated and frequent re-registrations cannot guarantee the client to eventually become an observer of the target server. In the case that the server is unable or unwilling to accept an observer, the time-intensive re-registrations will just bring redundant messages in the constrained network and considerable energy consumption on both the client and the server. This memo defines a new CoAP option, State, for providing stateful observation on the resources of CoAP servers. By observing the state of the server in terms of the Observe Option, a client can explicitly learn when the server will not actively reject an observation registration, and then can wisely performs the re-registration. This avoids the potential registration flooding that causes considerable network overhead and energy consumption on the constrained nodes. "Label-based Provider-Provisioned Lawful Intercept for L2 VPNs", Shankar Raman, Balaji Venkat, Gaurav Raina, Bhargav Bhikkaji, 25-Jan-13, In models of Single-AS and inter-provider Multi- Protocol Label Switching (MPLS) based Virtual Private Networks (VPNs) Lawful Intercept is a key requirement. For example, MPLS-based Layer 2 VPN models like VPLS and the like do not have any provider provisioned methods of lawful intercept that are comprehensive, quick and easy to provision from one single point. More particularly the auto- provisioning of lawful intercept for all sets of streams travelling between VPN sites and consequent re-direction of these streams to the appropriate government network has not been covered without multiple instances of having to configure the intercept at various points in the network both in the Single-AS case and the Inter-Provider VPN case. this paper, we propose a technique which uses a set of pre-defined labels called Lawful Intercept labels and a method for provisioning lawful intercept amongst the various PE devices using these labels both in the Single-AS and the inter-provider VPN cases. A single point of configuration is the key to this idea. The intercepted traffic is mirrored on a PE or a whole set of PEs or on all the PEs participating in the VPN. A technique called the Domino-effect provisioning of these Label-based Provider Provisioned Lawful Intercept mechanism is also outlined. "Label-based Provider-Provisioned Lawful Intercept for L3 VPNs", Shankar Raman, Balaji Venkat, Gaurav Raina, Vasan Srini, Bhargav Bhikkaji, 18-Feb-13, In models of Single-AS and inter-provider Multi- Protocol Label Switching (MPLS) based Virtual Private Networks (VPNs) Lawful Intercept is a key requirement. For example, MPLS-based Layer 3 VPN models do not have any provider provisioned methods of lawful intercept that are comprehensive, quick and easy to provision from one single point. More particularly the auto-provisioning of lawful intercept for all sets of streams travelling between VPN sites and consequent re-direction of these streams to the appropriate government network has not been covered without multiple instances of having to configure the intercept at various points in the network both in the Single-AS case and the Inter-Provider VPN case. In this paper, we propose a technique which uses a set of pre-defined labels called Lawful Intercept labels and a method for provisioning lawful intercept amongst the various PE devices using these labels both in the Single-AS and the inter-provider VPN cases. A single point of action is the key to this idea. The intercepted traffic is mirrored on a PE or a whole set of PEs or on all the PEs participating in the VPN. A technique called the Domino-effect provisioning of these Label-based Provider Provisioned Lawful Intercept mechanism is also outlined. "KARP KMP: Simplified Peer Authentication", Uma Chunduri, Albert Tian, Ari Keränen, Tero Kivinen, 11-Mar-13, This document describes the usage of Router Fingerprint Authentication (RFA) with public keys as a potential peer authentication method with KARP pair wise and group Key Management Protocols (KMPs). The advantage of RFA is, it neither requires out- of-band, mutually agreeable symmetric keys nor a full PKI based system (trust anchor or CA certificates) for mutual authentication of peers with KARP KMP deployments. Usage of Router Fingerprints give a significant operational improvement from symmetric key based systems and yet provide a secure authentication technique. "Loop Detection Mechanisms for Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs)", Hadriel Kaplan, Victor Pascual, 25-Feb-13, 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. "RTCWeb JSEP XMPP/Jingle Mapping", Kepeng Li, 28-Jan-13, This document proposes mapping message representations between RTCWeb Javascript Session Establishment Protocol(JSEP) scheme and XMPP/ Jingle [XEP-0166] messaging scheme. Such a signaling mapping is intended to enable Javascript to use XMPP/Jingle to establish a session between two RTCWeb enabled browsers. "Encoding for WSON Information Model with Impairments Validation.", Giovanni Martinelli, Moustafa Kattan, Gabriele Galimberti, Andrea Zanardi, 23-Feb-13, This document defines proper encoding for the Information Model to support Impairment-Aware (IA) Routing and Wavelength Assignment (RWA) function. This operation might be required in Wavelength Switched Optical Networks (WSON) that already support RWA, encoding defined here goes in addition to available WSON encoding and it is fully compatible with it. As the information model, the encoding is independent from control plane architectures and protocol implementations. Its definitions must be reused in related protocol extensions. "Information Model for Wavelength Switched Optical Networks (WSON) with Optical Impairments Validation.", Giovanni Martinelli, Moustafa Kattan, Gabriele Galimberti, Andrea Zanardi, 23-Feb-13, This document defines the Information Model to support Impairment- Aware (IA) Routing an Wavelength Assignment (RWA) function. This operation might be required in Wavelength Switched Optical Networks (WSON) that already support RWA and the Information model defined here goes in addition and it is fully compatible with the already defined information model for WSON. This information model shall support all control plane architectural options defined for WSON with impairment validation. "Network Time Protocol: autokey Version 2 Specification", Dieter Sibold, Stephen Roettger, 24-Feb-13, This document describes a security protocol that enables authenticated time synchronization using Network Time Protocol (NTP). Autokey Version 2 obsoletes NTP autokey protocol RFC 5906 [RFC5906] which suffers from various security vulnerabilities. Its design considers the special requirements that are related to the task of precise timekeeping. "A Larger Loopback Prefix for IPv6", Mark Smith, 20-Feb-13, During the development and testing of a network application, it can be useful to run multiple instances of the application using the same transport layer protocol port on the same development host, while also having network access to the application instances limited to the local host. Under IPv4, this has commonly been possible by using different loopback addresses within 127/8. It is not possible under IPv6, as the loopback prefix of ::1/128 only provides a single loopback address. This memo proposes a new larger loopback prefix that will provide many IPv6 loopback addresses. The processing rules for this new larger loopback prefix also allow sending or forwarding of packets containing these addresses beyond the originating router under certain circumstances. "Guidelines for Writing an IANA Considerations Section in RFCs", Michelle Cotton, Barry Leiba, Thomas Narten, 29-Mar-13, Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values used in these fields do not have conflicting uses, and to promote interoperability, their allocation is often coordinated by a central authority. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To manage a given namespace prudently, IANA needs guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the guidance given to IANA is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition, and obsoletes RFC 5226. "Request For Action to Establish an Enhanced Cooperation Task Force and a Preparatory Working-Group", Norbert Bollow, 13-Feb-13, This memo calls for the creation of a new governance forum named "Enhanced Cooperation Task Force" (ECTF). The main purpose of the ECTF is to facilitate consensus-seeking discussions regarding information society governance actions that will be taken by national governments and international organizations. "Authenticated Denial of Existence in the DNS", R. Gieben, Matthijs Mekking, 7-Jan-13, Authenticated denial of existence allows a resolver to validate that a certain domain name does not exist. It is also used to signal that a domain name exists, but does not have the specific RR type you were asking for. When returning a negative DNSSEC response, a name server usually includes up to two NSEC records. With NSEC3 this amount is three. This document provides additional background commentary and some context for the NSEC and NSEC3 mechanisms used by DNSSEC to provide authenticated denial of existence responses "ALTO Caching", Sreekanth Madhavan, Nandiraju Ravishankar, 3-Feb-13, The specification of the ALTO protocol uses map based approaches assuming that the information provided is static for a longer period of time. The purpose of this memo is to provide a mechanism where ALTO clients cache the map information and the servers provide the expiration time for invalidation. "ALTO Subscription", Sreekanth Madhavan, Nandiraju Ravishankar, 3-Feb-13, 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 propose a mechanism where ALTO clients can subscribe for event notifications from the server "HTTP/2.0 Discussion: Stored Header Encoding", James Snell, 20-May-13, This memo describes a proposed alternative encoding for headers that combines the best concepts from the proposed Delta and HeaderDiff options with the typed value codecs introduced by previous versions of this draft. "Web Cache Communication Protocol V2, Revision 1", Douglas McLaggan, 2-Aug-12, This document describes version 2 of the Web Cache Communication Protocol (WCCP). The WCCP V2 protocol specifies interactions between one or more routers and one or more web-caches. The interaction may take place within an IPv4 or IPv6 network. The purpose of the interaction is to establish and maintain the transparent redirection of selected types of traffic flowing through a group of routers (or similar devices). The selected traffic is redirected to a group of web-caches (or other traffic optimisation devices) with the aim of optimising resource usage and lowering response times. The protocol does not specify any interaction between the web-caches within a group or between a web-cache and a web-server. "OSPF-TE extensions for MLNMRN based on OTN", Khuzema Pithewan, Rajan Rao, 31-Jan-13, This document specifies OSPF extensions for multi-layer/multi-region where one of the regions is OTN. "Content Distribution Network Interconnection (CDNI) Capabilities Interface", Kevin Ma, 4-Feb-13, The interconnection of Content Distribution Networks (CDNs) is predicated on the ability of downstream CDNs (dCDNs) to handle end- user requests in a functionally equivalent manner to the upstream CDN (uCDN). The uCDN must be able to assess the ability of the dCDN to handle individual requests. A CDN interconnection (CDNI) interface is needed to facilitate the advertisement of capabilities by the dCDN to the uCDN. This document describes an approach to implementing a CDNI capabilities advertisement interface. "LLCPS", Pascal Urien, 7-Feb-13, This document describes the implementation, named LLCPS, of the TLS protocol over the NFC (Near Field Communication) LLCP (Logical Link Control Protocol) layer. The NFC peer to peer (P2P) protocol may be used by any application that needs communication between two devices at very small distances (a few centimeters). LLCPS enforces a strong security in NFC P2P exchanges, and may be deployed for many services, in the Internet Of Things ecosystem, such as access control or ticketing operations. "RPL Routing Pathology In a Network With a Mix of Nodes Operating in Storing and Non-Storing Modes", JeongGil Ko, Jongsoo Jeong, Jongjun Park, Jong Jun, Naesoo Kim, Omprakash Gnawali, 16-Feb-13, The RPL specification allows nodes running with storing or non- storing modes to operate in the same network. We describe how such a mix can result in network partitioning even when there are plenty of physical links available in the network. The partitioning affects both upwards (nodes to root) and downwards (root to leaf) traffic. This routing pathology stems from a recommendation made in the RPL specification forcing nodes with different modes of operation to join the RPL network as leaf nodes only. We propose a solution that modifies RPL by mandating that all the nodes parse and interpret source routing headers and storing mode nodes to sometimes act like a non-storing mode root by attaching source routing headers. "An Architecture for splicing TE-LSPs in Hierarchical CsC scenarios", Bhargav Bhikkaji, Balaji Venkataswami, Shankar Raman, Gaurav Raina, 25-Feb-13, Hierarchical Carrier Supporting Carrier deployments involve a Carrier Core which hereinafter is called the Tier-1 provider and two or more VPN sites that are carriers themselves hereinafter called Tier-2 providers that offer MPLS VPN services to their own customers. In such cases normally LDP is used to distribute labels amongst the routers (P and PE devices) in the Tier-2 provider's sites. When RSVP based TE-LSPs are constructed to explicitly route traffic for Tier-2 ISP's customers from the Tier-2 PEs to the CE of the Tier-1 provider and such TE-LSPs exist on multiple sites of the Tier-2 provider, the Tier-2 ISP may require splicing together through an "auto-match-and- splice-together" facility such that traffic flows from the PE of the Tier-2 ISP through the TE-LSP onto the CE of the Tier-1 ISP and then onto the other site and takes a path through a specific TE-LSP from the CE of the other site to the destination Tier-2 PE and then onto the final customer. This solution offers a lot of advantages such as providing adequate assurance that the bandwidth for the traffic flowing through these spliced TE-LSPs is met. It also provides a explicit routing of the traffic rather than through the regular LDP (which follows IGP) scenarios. Such explicitly routed TE-LSPs would have been constructed taking into account factors such as using under-utilized links for example. Splicing together these TE-LSPs in various sites and doing the splicing on an auto-match based on bandwidth or delay metrics would be a good service to offer to the Tier-2 ISPs customers. This draft outlines a scheme that offers such a feature and service to the Tier-2 ISPs through the addition of certain additional label exchanges and some additional labels such as the RSVP-stitch label and the RSVP-splicing-LDP label in the label stack which can be used to splice together these tunnels. In case of re-optimization of the LSP end-to-end there is a wide variety of choices for the near-end PE to hook up with a suitable far-end tunnel in the other Tier-2 site. Explicit tunnel setup can be obviated by merely choosing from a set of already constructed tunnels based on criterion that may involve various parameters. Also fast-reroute in case of remote tunnel failure is taken care of. "SNMP based Provider-Provisioned label for Lawful Intercept in L3 VPNs", Shankar Raman, Balaji Venkat, Gaurav Raina, Vasan Srini, Bhargav Bhikkaji, 18-Feb-13, In models of Single-AS and inter-provider Multi- Protocol Label Switching (MPLS) based Virtual Private Networks (VPNs) Lawful Intercept is a key requirement. For example, MPLS-based Layer 3 VPN models do not have any provider provisioned methods of lawful intercept that are comprehensive, quick and easy to provision from one single point. More particularly the auto-provisioning of lawful intercept for all sets of streams travelling between VPN sites and consequent re-direction of these streams to the appropriate government network has not been covered without multiple instances of having to configure the intercept at various points in the network both in the Single-AS case and the Inter-Provider VPN case. In this paper, we propose a technique which uses a set of pre-defined labels called Lawful Intercept labels and a method for provisioning lawful intercept amongst the various PE devices using these labels both in the Single-AS and the inter-provider VPN cases. A single point of action is the key to this idea. The intercepted traffic is mirrored on a PE or a whole set of PEs or on all the PEs participating in the VPN. A technique called the Domino-effect provisioning of these Label-based Provider Provisioned Lawful Intercept mechanism is also outlined. This differs from [1] in that there is explicit use of a secure SNMP mechanism to provision the labels for Lawful Intercept at the various PEs instead of a MP-BGP update. "Babel HMAC Cryptographic Authentication", Denis Ovsienko, 18-Apr-13, This document describes a cryptographic authentication mechanism for Babel routing protocol, updating, but not superceding RFC 6126. The mechanism allocates two new TLV types for the authentication data, uses HMAC and is both optional and backward compatible. "The Open vSwitch Database Management Protocol", Ben Pfaff, Bruce Davie, 15-Mar-13, Open vSwitch is an open source software switch designed to be used as a vswitch (virtual switch) in virtualized server environments. A vswitch forwards traffic between different virtual machines (VMs) on the same physical host and also forwards traffic between VMs and the physical network. Open vSwitch is open to programmatic extension and control using OpenFlow and the OVSDB (Open vSwitch Database) management protocol. This document defines the OVSDB management protocol. "Military Message Handling System (MMHS) over SMTP", Alexey Melnikov, Graeme Lunt, Alan Ross, 25-Feb-13, A Military Message Handling System (MMHS) processes formal messages ensuring release, distribution, security, and timely delivery across national and international strategic and tactical networks. The MMHS Elements of Service are defined as a set of extensions to the ITU-T X.400 (1992) international standards and are specified in STANAG 4406 Edition 2 or ACP 123. This document specifies how a comparable messaging service can be provided using SMTP and its extensions. "IPv6 RA Options for Translation Multicast Prefixes", Behcet Sarikaya, 25-Feb-13, This draft defines new Router Advertisement options for configuring multicast prefixes and unicast prefixes for multicast source addresses. Each option is defined together with definitions of host and router behaviors. "Resolution Constraints in Web Real Time Communications", Harald Alvestrand, 25-Feb-13, This document specifies the constraints necessary for a Javascript application to successfully indicate to a browser that supports WebRTC what resolutions it desires on a video stream. "IMAP SUBMIT Extension", Jan Kundrat, 25-Feb-13, This document extends the IMAP protocol with a feature to submit e-mail messages for delivery. It is intended to serve as a better alternative to the URLAUTH/BURL approach. "IMAP Extension for Incremental Threading (INCTHREAD)", Jan Kundrat, 25-Feb-13, This document describes the INCTHREAD IMAP extension which enables clients to retrieve incremental updates of the mailbox threading. The extension repurposes the ESEARCH response for passing along the threading information and builds on top of Arnt Gulbrandsen's work on the INTHREAD search key. The UID THREAD command is also extended to allow activating this extension. Together, these changes make it possible for clients not to fetch the complete mailbox threading each time a new message arrives. "Aggregated Service Discovery", Andrew McMillan, Cyrus Daboo, 9-Jan-13, This specification describes how clients can discover multiple services to configure themselves with a minimum of user-provided information, as short as possible sequence of queries and with a minimum of overhead for administrators of the services. "YANG Data Model for Access Control List Configuration", Lisa Huang, Alex Clemm, Andy Bierman, 4-Mar-13, This document defines a YANG data model for the configuration of Access Control Lists (ACLs) on a device. "IODEF Enumeration Reference Format", Adam Montville, 14-Dec-12, The Incident Object Description Exchange Format [IODEF] provides a Reference class used to reference external entities (such as enumeration identifiers). However, the method of external entity identification has been left unstructured. This document describes a method to provide structure for referencing external entities for the [IODEF] Reference class. "Recommendation for Encoding IP Address and FQDN in DHCP Options", Mohamed Boucadair, Roberta Maglione, 30-Nov-12, This document aims at providing a recommendation for the design of future DHCP options when both IP Address and FQDN encoding are needed to be supported. This design reconciles the flexibility requirement from service providers and the DHC WG recommendation to avoid defining multiple options conveying similar set of configuration data. "Resource-Oriented Lightweight Indicator Exchange", John Field, 15-Feb-13, This document defines a resource-oriented approach to cyber security information sharing. Using this approach, a CSIRT or other stakeholder may share and exchange representations of cyber security incidents, indicators, and other related information as Web- addressable resources. The transport protocol binding is specified as HTTP(S) with a MIME media type of Atom+XML. An appropriate set of link relation types specific to cyber security information sharing is defined. The resource representations leverage the existing IODEF [RFC5070] and RID [RFC6545] specifications as appropriate. Coexistence with deployments that conform to existing specifications including RID [RFC6545] and Transport of Real-time Inter-network Defense (RID) Messages over HTTP/TLS [RFC6546] is supported via appropriate use of HTTP status codes. "OAuth 2.0 Security: Going Beyond Bearer Tokens", Hannes Tschofenig, Phil Hunt, 16-Dec-12, The OAuth working group has finished work on the OAuth 2.0 core protocol as well as the Bearer Token specification. The Bearer Token is a TLS-based solution for ensuring that neither the interaction with the Authorization Server (when requesting a token) nor the interaction with the Resource Server (for accessing a protected resource) leads to token leakage. There has, however, always been the desire to develop a security solution that is "better" than Bearer Tokens (or at least different) where the Client needs to show possession of some keying material when accessing a Resource Server. This document tries to capture the discussion and to come up with requirements to process the work on solutions. This document aims to discuss threats, security requirements and desired design properties of an enhanced OAuth security mechanism. "TRILL Fault Management", Tissa Senevirathne, Samer Salam, Deepak Kumar, Donald Eastlake, Sam Aldrin, 17-Feb-13, TRILL OAM Fault Management solution is presented in this document. Methods proposed in this document follow the IEEE 802.1 CFM framework and reuse OAM tools where possible. Additional messages and TLVs are defined for TRILL specific applications or where different set of information is required than IEEE 802.1 CFM. "The NETCONF Operation", Andy Bierman, 8-Apr-13, This document describes NETCONF protocol enhancements to improve data retrieval capabilities. "CLUE media capture description", Christian Groves, Weiwei Yang, Roni Even, 17-Feb-13, This memo discusses how media captures are described and in particular the content attribute in the current CLUE framework document and proposes several alternatives. "CLUE Telemedical Use Case Callflow", Paul Kyzivat, 18-Mar-13, This is the beginning of an example call flow for an instantiation of the use case described in the telemedical use case [I-D.xiao-clue-telemedical-use-case]. More detail will be added later. "Applicability of MPLS-TP Linear protection for p2mp", Guoman Liu, 13-Mar-13, In MPLS-TP requirement document(rfc5654), there is a requirement to support 1+1 and 1:n protection for p2mp connectivity. The requirement was described in MPLS-TP Survivability Framework document(RFC 6372) and draft-ietf-mpls-tp-p2mp-framework. The basic protocol for linear protection was specified in the MPLS-TP Linear Protection document [RFC 6378] but is limited to 1+1 and 1:1 protection for p2p connectivity. in addtion, The 1:N protection in which all of working transport paths and the protection path have the same end points was specified in MPLS-TP 1:N protection document (draft-ietf-mpls-tp-1toN-protection).This document applies the existing PSC(RFC 6378) and extensive PSC protocol(draft-ietf-mpls-tp- 1toN-protection) to support scenarios of protecting the p2mp path by extending the existing p2p linear protection mechanism. . 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. "RRCP A Receiver-Driven and Router-Feedback Congestion Control Protocol for ICN", Mingwei Xu, Chunmei Xia, 14-Mar-13, Network requirements have evolved from data communications between two hosts to large-scale information access through networks. The current Internet employs an address-centric network communication model, which is efficient for communications between hosts, but not efficient for communications between a host and a network. Given this fact, Information-centric Networking (ICN) has become a hot spot to meet the new requirement. In ICN there exists a congestion problem which hasn't been well solved. We provide a new congestion control protocol, RRCP, since the congestion control protocols in IP networks are not suitable for ICN transport. RRCP, with XCP and ICN transport characteristics, advances a receiver-driven and router- feedback mechanism. RRCP can stay efficient, fair and stable via the validation of simulation. "ENUM Service Registration for acct URI", Laurent Goix, Kepeng Li, 6-May-13, This document registers a Telephone Number Mapping (ENUM) service for 'acct:' URIs (Uniform Resource Identifiers). "Owner Authorization Grant Type Profile for OAuth 2.0", Sujing Zhou, 18-Dec-12, This document proposes to let resource owners directly authorize a relying party to access resources stored in other resource servers . "The Key HTTP Response Header Field", Roy Fielding, Mark Nottingham, 18-Feb-13, The 'Key' header field for HTTP responses allows an origin server to describe the cache key for a negotiated response: a short algorithm that can be used upon later requests to determine if the same response is reusable. Key has the advantage of avoiding an additional round trip for validation whenever a new request differs slightly, but not significantly, from prior requests. Key also informs user agents of the request characteristics that might result in different content, which can be useful if the user agent is not sending Accept* fields in order to reduce the risk of fingerprinting. "Certificate Transparency", Ben Laurie, Adam Langley, Emilia Kasper, 18-Apr-13, This document describes an experimental protocol for publicly logging the existence of TLS certificates as they are issued or observed, in a manner that allows anyone to audit certificate authority activity and notice the issuance of suspect certificates, as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates which do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. Logs are network services which implement the protocol operations for submissions and queries that are defined in this document. "SCIM and vCard mapping", Bert Greevenbosch, 24-Feb-13, This document defines a mapping between Simple Cloud Identity Management (SCIM) and vCard. Note Discussion and suggestions for improvement are requested, and should be sent to scim@ietf.org. "A problem statement on trust in IETF protocols", Melinda Shore, Karen O'Donoghue, 25-Feb-13, This document attempts to set out a problem statement and framework for future discussions regarding "trust" in the IETF. "Experience from MAP-T Testing", Edwin Cordeiro, Rodrigo Carnier, Antonio Moreiras, 26-Mar-13, This document describes the testing result of a network using MAP-T dual translation solution, by providing an overview of user applications' behavior with a shared IPv4 address. The MAP-T software is from CERNET Center and the test environment is on NIC.br network with real and virtualized machines. "eXtensible Access Control Markup Language (XACML) Media Type", Remon Sinnema, Erik Wilde, 20-May-13, This specification registers an XML-based media type for the eXtensible Access Control Markup Language (XACML). Note to Readers This draft should be discussed on the apps-discuss mailing list [1]. Online access to all versions and files is available on github [2]. "Optimizing NAT and Firewall Keepalives Using Port Control Protocol (PCP)", Tirumaleswar Reddy, Markus Isomaki, Dan Wing, Prashanth Patil, 21-Jan-13, This document describes how Port Control Protocol is useful to reduce NAT and firewall keepalive messages for a variety of applications. "IP/MPLS Connectivity Provisioning Profile", Mohamed Boucadair, Christian Jacquenet, Ning Wang, 25-Sep-12, This document describes the Connectivity Provisioning Profile (CPP) and proposes a CPP Template to capture IP connectivity requirements to be met in the context of delivery of services (e.g. Voice over IP or IP TV) which are to be plugged upon an IP/MPLS infrastructure. The CPP defines the set of IP transfer parameters to be supported by the underlying IP/MPLS transport network together with a reachability scope and bandwidth/capacity needs. Appropriate performance metrics such as one-way delay, one-way delay variation are used to characterize an IP transfer service. Both global and restricted reachability scopes can be captured in the CPP. Having the generic CPP template allows for (1) automating the process of service negotiation and activation, thus accelerating service provisioning, (2) setting the (traffic) objectives of Traffic Engineering functions and service management functions and (3) enriching service and network management systems with 'decision- making' capabilities based on negotiated/offered CPPs. "A Language for Rules Describing JSON Content", Andrew Newton, 13-Jan-13, This document describes a language useful for documenting the expected content of JSON structures found in specifications using JSON. "MIF API for Connection Management", Pierrick Seite, Juan Zuniga, 22-Feb-13, There is currently a need to present a coherent connection management behaviour for different terminal platforms (e.g. mobile phones, PCs, tablets, etc.). This document discusses how a connection manager can use the MIF API to provide this coherent behaviour and enhance the end user's experience when a terminal is able to connect to multiple interfaces. The goal of this document is not to define a connection manager specification, but to focus on the interaction with the MIF API and suggest relevant generic messages for the interface. This document is for discussion and its intention is to help clarifying the utilization of the MIF API in a connection management context and propose some relevant considerations. "RFC Series Format Development", Heather Flanagan, Nevil Brownlee, 27-Nov-12, This document describes the current requirements and requests for enhancements for the format of the canonical version of RFCs. Terms are defined to help clarify exactly which stages of document production are under discussion for format changes. The requirements described in this document will determine what changes will be made to RFC format. "Design Discussion and Comparison of Replay-Attack Protection Mechanisms for BGPSEC", Kotikalapudi Sriram, Doug Montgomery, 24-Mar-13, The BGPSEC protocol requires a method for protection from replay attacks, at least to control the window of exposure. In the context of BGPSEC, a replay attack occurs when an adversary suppresses a prefix withdrawal (implicit or explicit) or replays a previously received BGPSEC announcement for a prefix that has since been withdrawn. This informational document provides design discussion and comparison of multiple alternative replay-attack protection mechanisms weighing their pros and cons. It is meant to be a companion document to the standards track I-D.-ietf-sidr-bgpsec- rollover that will specify a method to be used with BGPSEC for replay-attack protection. "Autonomous System (AS) Migration Features and Their Effects on the BGP AS_PATH Attribute", Wesley George, Shane Amante, 19-Feb-13, This draft discusses common methods of managing an ASN migration using some BGP feaures that while commonly-used are not formally part of the BGP4 protocol specification and may be vendor-specific in exact implementation. It is necessary to document these de facto standards to ensure that they are properly supported in BGPSec. "BGPSec Considerations for AS Migration", Wesley George, Sandra Murphy, 1-Feb-13, This draft discusses considerations and methods for supporting and securing a common method for AS-Migration within the BGPSec protocol. "Mechanisms for Optimal LAG/ECMP Component Link Utilization in Networks", ramki, Sanjay Khanna, Lucy Yong, Anoop Ghanwani, So Ning, Bhumip Khasnabish, 24-Apr-13, Demands on networking infrastructure are growing exponentially; the drivers are bandwidth hungry rich media applications, inter-data center communications, etc. In this context, it is important to optimally use the bandwidth in wired networks that extensively use LAG/ECMP techniques for bandwidth scaling. This draft explores some of the mechanisms useful for achieving this. "Making BGP filtering a habit: Impact on policies", Pierre Francois, Camilo Cardona, 22-Feb-13, This draft describes threats to the Internet routing policies of an autonomous system due to filtering of more specific BGP prefixes by its neighboring domains. "CoAP Minimum Request Interval", Bert Greevenbosch, 26-Apr-13, This document defines an "Minimum-Request-Interval" option for CoAP, which can be used to negotiate the minimum time between two subsequent requests within a single client and server pair. It can be used for flow and congestion control, reducing the consumption of server and network resources when needed. Note Discussion and suggestions for improvement are requested, and should be sent to core@ietf.org. "Multihoming in Homenet", Wassim Haddad, Damien Saucez, 29-Mar-13, So far, multihoming in Homenet must be supported by the hosts as there is no mean to use simultaneously the different ISPs of the Homenet without risking flow disruption. In this memo, we propose to revise the way multihoming is conceived in Homenet by relying on the infrastructure instead of the hosts. We also propose a high level solution that answers this particular problem. "NFSv4 Multi-Domain FedFS Requirements", Andy Adamson, Nico Williams, 17-Apr-13, This document describes constraints to the NFSv4.0 and NFSv4.1 protocols as well as the use of multi-domain capable file systems, name resolution services, and security services required to fully enable a multi-domain NFSv4 federated file system. "Multiple Synchronization Sources (SSRC) in SDP Media Descriptions", Christer Holmberg, Magnus Westerlund, BoB, Fredrik Jansson, 27-Mar-13, This document describes use-cases where endpoints, for a given media type, use multiple media sources. It also describes how endpoints normally support media sources, and limitations associated with the support of multiple sources. This document also defines two new SDP attributes, "max-send-ssrc" and "max-recv-ssrc". The attributes allows an entity to, for a given media description, indicate sending and receiving capabilities of multiple media sources, based on codec usage . "Experiments on HTTP Adaptive Streaming over interconnected Content Delivery Networks", Jeroen Famaey, Steven Latre, 24-Jan-13, This document reports experimental results on the delivery of HTTP Adaptive Streaming (HAS) content over interconnected Content Delivery Networks (CDNs). Specifically, the implications that CDN request routing between CDNs and HTTP redirection have on the quality of delivered HAS content are investigated. "Use of the Prefer Header Field in Web Distributed Authoring and Versioning (WebDAV)", Kenneth Murchison, 17-May-13, This specification defines how the HTTP Prefer header can be used by a WebDAV client to request that certain behaviors be employed by a server while constructing a response to a successful request. "An XML Schema for the CLUE data model", Roberta Presta, Simon Romano, 11-Mar-13, This document provides an XML schema file for the definition of CLUE data model types. "Loop Free DODAG Local Repair", Jianlin Guo, Philip Orlik, Ghulam Bhatti, 2-Apr-13, IETF has been developing IPv6 based standards for Low-power and Lossy Networks (LLNs) to meet requirements of constrained applications, such as field monitoring, inventory control and so on. IPv6 Routing Protocol for LLNs (RPL) has been published in [RFC6550]. Based on routing metrics and constraints [RFC6551], RPL builds Directed Acyclic Graph (DAG) topology to establish bidirectional routes for LLNs for traffic types of multipoint-to-point, point-to-multipoint, and point-to-point. RPL routes are optimized for traffic to or from one or more roots that act as sinks. As a result, a DAG is partitioned into one or more Destination Oriented DAGs (DODAGs), one DODAG per sink. RPL is widely considered as a feasible routing protocol for LLNs. However, DODAG loops caused by local DODAG repair mechanism is an issues to be addressed. This draft introduces a loop free local DODAG repair mechanism. This draft also introduces a piggybacked data option for transferring delay sensitive data during route repair process. The piggybacked data can be included in DODAG Repair Request (DRQ) message or DODAG Information Solicitation (DIS) message. "ForCES Model Extension", Evangelos Haleplidis, 1-Apr-13, Forwarding and Control Element Separation (ForCES) defines an architectural framework and associated protocols to standardize information exchange between the control plane and the forwarding plane in a ForCES Network Element (ForCES NE). RFC5812 has defined the ForCES Model provides a formal way to represent the capabilities, state, and configuration of forwarding elements within the context of the ForCES protocol, so that control elements (CEs) can control the FEs accordingly. More specifically, the model describes the logical functions that are present in an FE, what capabilities these functions support, and how these functions are or can be interconnected. RFC5812 has been around for two years and experience in its use has shown room for small extensions without a need to alter the protocol while retaining backward compatibility with older xml libraries. This document extends the model to allow complex datatypes for metadata, optional default values for datatypes and optional access types for structures. The document also introduces two new features, bitmap as a new datatype and a new event condition BecomesEqualTo. "Abstract", Ahmed Bashandy, Clarence Filsfils, Prodosh Mohapatra, 29-Mar-13, In the network comprising thousands of iBGP peers exchanging millions of routes, many routes are reachable via more than one path. Given the large scaling targets, it is desirable to restore traffic after failure in a time period that does not depend on the number of BGP prefixes. In this document we proposed a technique by which traffic can be re-routed to ECMP or pre-calculated backup paths in a timeframe that does not depend on the number of BGP prefixes. The objective is achieved through organizing the forwarding chains in a hierarchical manner and sharing forwarding elements among the maximum possible number of routes. The proposed technique achieves prefix independent convergence while ensuring incremental deployment, complete transparency and automation, and zero management and provisioning effort "JSON Predicate", James Snell, 7-Jan-13, JSON Predicates defines a syntax for serializing various predicate expressions as JSON Objects. "A Mechanism for Diameter Overload Control", Adam Roach, Eric McMurry, 17-May-13, When a Diameter server or agent becomes overloaded, it needs to be able to gracefully reduce its load, typically by informing clients to reduce or stop sending traffic for some period of time. Otherwise, it must continue to expend resources parsing and responding to Diameter messages. This document proposes a concrete, application-independent mechanism to address the challenge of communicating load and overload state among Diameter peers, and specifies an algorithm for load abatement to address such overload conditions as they occur. The load abatement algorithm is extensible, allowing for future documents to define additional load abatement approaches. "Domain Subobjects for Resource ReserVation Protocol - Traffic Engineering (RSVP-TE)", Dhruv Dhody, Udayasree Palle, Venugopal Kondreddy, Ramon Casellas, 2-Apr-13, The RSVP-TE specification [RFC3209] and the GMPLS extensions to RSVP-TE [RFC3473] allow abstract nodes and resources to be explicitly included in a path setup. Further Exclude Routes extensions [RFC4874] allow abstract nodes and resources to be explicitly excluded in a path setup. This document specifies new subobjects to include or exclude domains during path setup where 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 AS (4-Byte)). Note that the use of Autonomous Number (AS) (2-Byte) as an abstract node representing domain is already defined in [RFC3209] and [RFC4874]. "The Diameter Overload Control Application (DOCA)", Jouni Korhonen, Hannes Tschofenig, 25-Feb-13, This specification documents a Diameter Overload Control Application (DOCA), which uses the normal Diameter application approach for the capability negotiation, propagation and management of Diameter overload control information between Diameter nodes. "Add 100.64.0.0/10 prefixes to IPv4 Locally-Served DNS Zones Registry.", Mark Andrews, 1-Apr-13, RFC6598 specified that: "Reverse DNS queries for Shared Address Space addresses [100.64.0.0/10] MUST NOT be forwarded to the global DNS infrastructure." This document formally directs IANA to add the associated zones to the "IPv4 Locally-Served DNS Zones Registry" to prevent such queries accidently leaking to the global DNS infrastructure. "The NetInf Protocol", Dirk Kutscher, Stephen Farrell, Elwyn Davies, 10-Feb-13, This document defines a conceptual protocol and corresponding node requirements for NetInf nodes in a NetInf network. A NetInf network offers an information-centric paradigm that supports the creation, location, exchange and storage of Named Data Objects (NDOs). NetInf nodes can provide different services to other NetInf nodes, e.g., forwarding requests for information objects, delivering corresponding response messages, name resolution services etc. This (abstract) protocol is intended to be run over some "convergence layer" that handles transport issues. Two "wire" formats are defined, one that uses HTTP for message transfer and one layered on UDP. "Parallel NFS (pNFS) Lustre Layout Operations", Sorin Faibish, Peng Tao, 5-May-13, Parallel NFS (pNFS) extends Network File System version 4.1(NFSv4.1) to allow clients to directly access file data on the storage used by the NFSv4.1 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 Lustre pNFS Layout Type as a companion to the main NFSv4 Minor version 1 specification. "Modeling JSON Text with YANG", Ladislav Lhotka, 2-Apr-13, This document defines rules for mapping data models expressed in YANG to configuration and operational state data encoded as JSON text. It does so by specifying a procedure for translating the subset of YANG- compatible XML documents to JSON text, and vice versa. "IMAP4 Extensions for Quick Mailbox Resynchronization", Alexey Melnikov, Dave Cridland, 13-Feb-13, This document defines an IMAP4 extension, which gives an IMAP client the ability to quickly resynchronize any previously opened mailbox as part of the SELECT command, without the need for server-side state or additional client round-trips. This extension also introduces a new response that allows for a more compact representation of a list of expunged messages (and always includes the Unique Identifiers (UIDs) expunged). "Mitigating IPv6 Neighbor Discovery DoS Attack Using Stateless Neighbor Presence Discovery", Mark Smith, 20-Feb-13, One of the functions of IPv6 Neighbor Discovery is to discover whether a specified neighbor is present. During the neighbor presence discovery process state is created. A node's capacity for this state can be intentionally exhausted to perform a denial of service attack, known as the "Neighbor Discovery DoS Attack". This memo proposes a stateless form of neighbor presence discovery to prevent this Neighbor Discovery DoS Attack. "Dynamic Host Configuration Protocol (DHCP) Option for Port Set Assignment", Qiong Sun, Yiu Lee, Qi Sun, Gabor Bajko, Mohamed Boucadair, 10-Apr-13, Because of the exhaustion of the IPv4 address space, several techniques have been proposed to share the same IPv4 address among several uses. As an alternative to introducing a level of NAT in the provider's core network, this document provides a mechanism to assign non-overlapping port set to users assigned with the same IPv4 address: Port Set DHCPv4 Option. "Advanced Stream and Sampling Framework for IPPM", Joachim Fabini, Al Morton, 22-Feb-13, To obtain repeatable results in modern networks, test descriptions need an expanded stream parameter framework that also augments aspects specified as Type-P for test packets. This memo proposes to update the IP Performance Metrics (IPPM) Framework with advanced considerations for measurement methodology and testing. The existing framework mostly assumes deterministic connectivity, and that a single test stream will represent the characteristics of the path when it is aggregated with other flows. Networks have evolved and test stream descriptions must evolve with them, otherwise unexpected network features may dominate the measured performance. This memo describes new stream parameters for both network characterization and support of application design using IPPM metrics. "The application/stream+json Media Type", James Snell, 11-Oct-12, This specification defines and registers the application/stream+json Content Type for the JSON Activity Streams format. "HTTP Link and Unlink Methods", James Snell, 22-Apr-13, This specification defines the semantics of the Link and Unlink HTTP methods. "CoRE Mirror Server", Matthieu Vial, 10-Apr-13, The Constrained RESTful Environments (CoRE) working group aims at realizing the REpresentational State Transfer (REST) architecture in a suitable form for the most constrained nodes. Thanks to the Constrained Application Protocol (CoAP), REST is now applicable to constrained networks. However the most energy-constrained devices may enter sleep mode and disconnect their network link during several minutes to save energy, hence preventing them from acting as traditional web servers. This document describes how a sleeping device can store resource representations in an entity called Mirror Server and participate in a constrained RESTful environment. "SCIM Use Cases", Phil Hunt, Bhumip Khasnabish, Anthony Nadalin, Zachary Zeltsan, Kepeng Li, 5-Feb-13, This document lists the user scenarios and use cases of System for Cross-domain Identity Management (SCIM). "ForCES Packet Parallelization", Evangelos Haleplidis, Joel Halpern, 23-Feb-13, Forwarding and Control Element Separation (ForCES) defines an architectural framework and associated protocols to standardize information exchange between the control plane and the forwarding plane in a ForCES Network Element (ForCES NE). RFC5812 has defined the ForCES Model provides a formal way to represent the capabilities, state, and configuration of forwarding elements within the context of the ForCES protocol, so that control elements (CEs) can control the FEs accordingly. More specifically, the model describes the logical functions that are present in an FE, what capabilities these functions support, and how these functions are or can be interconnected. Many network devices support parallel packet processing. This document describes how ForCES can model a network device's parallelization datapath. "Quick Start Plus", Randall Stewart, Michael Tuexen, 17-Apr-13, This document describes an extension to Quick Start including the missing Stream Control Transmission Protocol (SCTP) QuickStart chunk types and procedures so that SCTP may also use the QuickStart extension. "PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model", Edward Crabbe, Ina Minei, Siva Sivabalan, Robert Varga, 10-Apr-13, 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. The extensions described in [I-D.ietf-pce-stateful-pce] provide stateful control of Multiprotocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSP) via PCEP, for a model where the PCC delegates control over one or more locally configured LSPs to the PCE. This document describes the creation and deletion of PCE- initiated LSPs under the stateful PCE model. "ZSS Short Signature Scheme", Laura Hitt, 11-Feb-13, This document describes the ZSS Short Signature Scheme for implementation from bilinear pairings on supersingular elliptic curves. The ZSS Short Signature Scheme uses general cryptographic hash functions such as SHA-1 or SHA-2 and is efficient in terms of pairing operations. "The BinaryPack1pre2 JSON-like representation format", Carsten Bormann, 25-Feb-13, JSON (RFC 4627) is an extremely successful format for the representation of structured information, supporting Boolean values, numbers, strings, arrays, and tables. Recently, a number of applications have started to look for binary representation formats that solve a similar problem. In particular, constrained node networks can benefit from such a binary representation format. A very successful binary representation that is otherwise comparable to JSON is MessagePack. Recently, a number of implementations have modified or extended MessagePack such that it allows for distinguishing UTF-8 strings from binary data. Further discussion on the MessagePack repository has resulted in proposals how to integrate such an addition back into the MessagePack community. This draft, as an independent effort, documents one such format, tentatively calling it BinaryPack1pre2 while the MessagePack extension proposals make their way through the MessagePack community. The current version -01 of this document is a snapshot that demonstrates a general direction. The details may change in future versions based on the development of the MessagePack specification. "Host Identification: Use Cases", Mohamed Boucadair, David Binet, Sophie Durel, Bruno Chatras, Tirumaleswar Reddy, Brandon Williams, 14-Mar-13, This document describes a set of scenarios in which host identification is required. "Efficiency aware IPv6 Neighbor Discovery Optimizations", Samita Chakrabarti, Erik Nordmark, Margaret Wasserman, 21-Nov-12, 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, m2m and Cellular(LTE) networks, there is a desire for optimizing the legacy IPv6 Neighbor Discovery protocol. This document describes a method of optimization by reducing multicast messages and introducing an IPv6 address Registration mechanism. Efficient IPv6 Neighbor Discovery protocol is useful for energy- efficient IPv6 networks and as well as Data Center and Home Networks. The solution is capable of handling existing legacy IPv6 nodes in the network. "ForCES Inter-FE LFB", Damascane Joachimpillai, Jamal Hadi Salim, 25-Feb-13, Forwarding and Control Element Separation (ForCES) defines an architectural framework and associated protocols to standardize information exchange between the control plane and the forwarding plane in a ForCES Network Element (ForCES NE). RFC5812 has defined the ForCES Model provides a formal way to represent the capabilities, state, and configuration of forwarding elements within the context of the ForCES protocol, so that control elements (CEs) can control the FEs accordingly. More specifically, the model describes the logical functions that are present in an FE, what capabilities these functions support, and how these functions are or can be interconnected. At the moment the ForCES charter restricts the LFB topology to be within an FE. This documents describes a non-intrusive way to extend the LFB topology across FEs. "The WebSocket Protocol as a Transport for the Message Session Relay Protocol (MSRP)", Peter Dunkley, Gavin Llewellyn, 23-Nov-12, The WebSocket protocol enables two-way real-time communication between clients and servers. This document specifies a new WebSocket sub-protocol as a reliable transport mechanism between MSRP (Message Session Relay Protocol) clients and relays to enable usage of MSRP in new scenarios. This document normatively updates RFC 4975 and RFC 4976. "EXI Messaging Requirements", Yusuke Doi, 24-Feb-13, EXI (Efficient XML Interchange) is a specification on efficient encoding of XML. EXI is useful if an application requires XML based message exchange but no sufficient resource is available. However, schema-informed mode of EXI needs some out-of-band coordination between communicating nodes. This document discusses requirement on use of schema-informed EXI as a message exchange format on the Internet systems. "Network Virtualization Overlay Architecture", Roland Schott, Wenson Wu, 18-Feb-13, Multiple virtual machines (VMs) created in a single physical platform Or vServer greatly improve the efficiency of data centers by enabling more work from less hardware. Multiple vServer and associated virtual machines work together as one cluster make good use of resources of each vServer that are scattered into different data centers or vServers. VMs have their lifecycles from VM creation, VM Power on to VM Power off and VM deletion. The VMs may also move across the participating virtualization hosts (e.g., the virtualization server, hypervisor). This document discusses how VMs, vServers and overlay network are managed by leveraging control plane function and management plane function and desired signaling functionalities for Network Virtualization Overlay. "The (Real) Internet Key Exchange", Dan Harkins, 12-Apr-13, The current version (v2) of the Internet Key Exchange failed to address many of the shortcomings of the original version (v1). This memo defines a new version (v3) of the Internet Key Exchange that attempts to do so. "Requirements for DNS-SD/mDNS Extensions", Kerry Lynn, Stuart Cheshire, 24-Jan-13, DNS-SD/mDNS is widely used today for discovery and resolution of services and names on a local link, but there are use cases to extend DNS-SD/mDNS to enable service discovery beyond the local link. This document provides a problem statement and a list of requirements. "Extensions to Resource Reservation Protocol For Fast Reroute of Bidirectional Co-routed Traffic Engineering LSPs", Mike Taillon, Cisco Systems, Rakesh Gandhi, Zafar Ali, Manav Bhatia, Lizhong Jin, Frederic JOUNAY, 26-Apr-13, This document defines RSVP-TE signaling extensions to support Fast Reroute (FRR) of bidirectional co-routed Traffic Engineering (TE) LSPs. These extensions enable the re-direction of bi-directional traffic and signaling onto bypass tunnels that ensure co-routedness of data and signaling paths in the forward and reverse directions after FRR. In addition, the RSVP-TE signaling extensions allow the coordination of bypass tunnel assignment protecting a common facility in both forward and reverse directions prior to or post failure occurrence. "Industrial Deterministic Routing Extension for Low-Power and Lossy Networks", Min Wei, Heng Wang, Ping Wang, Chao Zhou, 15-Apr-13, Low power and Lossy Networks (LLNs) have unique characteristics compared with traditional wired and ad-hoc networks. Deterministic networks is specified in IEEE 802.15.4e which is for deterministic applications in the industrial environment. Some routing metrics and constraints has been described in [RFC6551],[RFC5867] [RFC5826], [RFC5673], and [RFC5548]. There are several special characteristics and requirements in the industrial environment. This document defines a new Link Metric/Constraint Object-Scheduling Waiting Time to make RPL support deterministic scheduling mechanism, which could improve the determinacy and reliability of the LLNs in industrial environment. "Router Key PDU for RPKI-Router Protocol", Randy Bush, Keyur Patel, Sean Turner, 8-Apr-13, The RPKI/Router Protocol v0 is specified to carry the PDUs necessary for RPKI-based Origin Validation. For BGPsec Path Validation, the routers also need data extracted from BGPsec Router Certificates. This document adds a PDU to the RPKI/Router Protocol to carry those data. "Header Delta-Compression for HTTP/2.0", Roberto Peon, 18-Mar-13, This document describes a mechanism for compressing streams of groups of key-value pairs, often known as Headers in an HTTP session. See RFC 2616 [RFC2616] or successors for more information about headers. "Network Performance Measurement for IPsec", Yang Cui, Emily Bi, Kostas Pentikousis, 25-Feb-13, IPsec is a mature technology with several interoperable implementations. Indeed, the use of IPsec tunnels is increasingly gaining popularity in several deployment scenarios, not the least in what used to be solely areas of traditional telecommunication protocols. Wider deployment calls for mechanisms and methods that enable tunnel end-users, as well as operators, to measure one-way and two-way network performance. Unfortunately, however, standard IP performance measurement security mechanisms cannot be readily used with IPsec. This document makes the case for employing IPsec to protect O/TWAMP and proposes a method which combines IKEv2 and O/TWAMP as defined in RFC 4656 and RFC 5357, respectively. This specification aims, on the one hand, to ensure that O/TWAMP can be secured, while on the other hand, it extends the applicability of O/TWAMP to networks that have already deployed IPsec. "P-Charge-Info - A Private Header (P-Header) Extension to the Session Initiation Protocol (SIP)", Dan York, Tolga Asveren, 15-Mar-13, This text documents 'P-Charge-Info', an existing 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. NOTE: This document has been in development since 2008 under the name draft-york-sipping-p-charge-info. This -01 document is identical to draft-york-sipping-p-charge-info-15 except for edits to the text to indicate this is now for the DISPATCH working group as the SIPPING working group no longer exists. "VP8 as RTCWEB Mandatory to Implement", Harald Alvestrand, Adrian Grange, 25-Feb-13, This document recommends that the RTCWEB working group choose the VP8 specification as a mandatory to implement video codec for RTCWEB implementations. This document is not intended for publication as an RFC. "Multiple Upstream Interface Support for IGMP/MLD Proxy", Hitoshi Asaeda, Seil Jeon, 25-Feb-13, This document describes the way of supporting multiple upstream interfaces for an IGMP/MLD proxy device. The proposed extension enables that an IGMP/MLD proxy device receives multicast packets through multiple upstream interfaces. The upstream interface is selected with manually configured supported address prefixes and interface priority value. A take-over operation switching from an inactive upstream interface to an active upstream interface is also considered. "Vulnerability Data Model", harold.booth@nist.gov, Karen Scarfone, 25-Apr-13, This Internet-Draft describes the Vulnerability Data Model (VDM) version 1.0, a vendor neutral data model for expressing data and metadata for individual vulnerabilities, and an XML format that can be used to exchange vulnerability data model information. VDM provides standard fields, formats and vocabularies that can be used to transmit information about software vulnerabilities between entities in an interoperable manner. VDM is suited for a wide variety of use cases, and provides extension points to facilitate additional use cases. "H.264 as Mandatory to Implement Video Codec for WebRTC", BoB, Markus Isomaki, Bernard Aboba, Gaelle Martin-Cocher, Giridhar Mandyam, Xavier Marjou, 25-Feb-13, This document proposes that, and motivates why, H.264 should be a Mandatory To Implement video codec for WebRTC. "Synchronization Layer: an Implementation Method for Energy Efficient Sensor Stack", Zehn Cao, Yuanchen Ma, Hui Tian, 24-Feb-13, This document analyzes the problem of energy efficient protocol implementation, and proposes an energy efficient design of mulitiple protocols by utilizing a common shim layer to synchronize the packet receipt and transimission on a single node. "Service Discovery in a Multiple Connection Environment: Problem Statement", Zehn Cao, Aaron Ding, 25-Feb-13, This document analyzes the problems of service discovery in a multiple connection environment. A multiple connection environment consists of multiple-interfaced nodes connecting to multiple networks or multiple provisioning domains. Given a type of service a multiple-interfaced client is looking for, the discovery progress ought to return a correct pointer to the service instance that the client is able to access without trying every available channel. "Extension of the MLD proxy functionality to support multiple upstream interfaces", Luis Contreras, Carlos Bernardos, Juan Zuniga, 25-Feb-13, This document presents different scenarios of applicability for an MLD proxy running more than one upstream interface. Since those scenarios impose different requirements on the MLD proxy with multiple upstream interfaces, it is important to ensure that the proxy functionality addresses all of them for compatibility. The purpose of this document is to define the requirements in an MLD proxy with multiple interfaces covering a variety of applicability scenarios, and to specify the proxy functionality to satisfy all of them. "H.264/AVC as Mandatory-to-Implement Video Codec for RTCweb", David Benham, David Singer, Krasimir Kolarov, 25-Feb-13, This memo proposes that H.264/AVC be selected as the mandatory-to- implement (MTI) video codec for RTCweb due to is Adoption Advantage, Quality-Power-Bandwidth advantage, Hardware Acceleration Advantage and Well-established IPR Status. "Distribution of MPLS Traffic Engineering (TE) LSP State using BGP", Jie Dong, Mach Chen, 25-Feb-13, This document describes a mechanism to collect the Traffic Engineering (TE) LSP information using BGP. Such information can be used by external components for path reoptimization, service placement and network visualization. "A Framework for L3VPN Performance Monitoring", Jie Dong, Zhenbin Li, Bhavani Parise, 17-Apr-13, The capability of BGP/MPLS IP Virtual Private Networks (L3VPN) performance monitoring (PM) is important to meet the Service Level Agreement(SLA) for the service beared. Since multipoint-to-point or multipoint-to-multipoint (MP2MP) network model applies, flow identifying is a big challenge for L3VPN PM. This document specifies the framework and mechanisms for the application of L3VPN PM. "Requirements for Power Aware Network", Jie Dong, Mingui Zhang, Beichuan Zhang, Mohamed Boucadair, 25-Feb-13, Energy consumption of networks is rising fast, which results in the increase of network operational costs. There are emerging demands from operators for power-aware networking (PANET) which could adaptively reduce the network energy consumption when possible. This document presents the requirements which should be considered in building a power aware network. "Layer-3 virtual network overlays based on BGP Layer-3 VPNs", Dhananjaya Rao, John Mullooly, Rex Fernando, 14-Mar-13, Virtual network overlays are being designed and deployed in various types of networks, including data centers. These network overlays address several requirements including flexible network virtualization and multi-tenancy, increased scale, and support for mobility of virtual machines. Such overlay networks can be used to provide both Layer-2 and Layer-3 network services to hosts at the network edge. New packet encapsulations are being defined and standardized to support these virtual networks. These encapsulations, such as VXLAN and NVGRE, are primarily based on IP and are currently defined to support a Layer-2 forwarding service. BGP based Layer-3 VPNs, as specified in RFC 4364, provide an industry proven and well-defined solution for supporting Layer-3 virtual network services. However, RFC 4364 procedures use MPLS labels to provide the network virtualization capability in the data plane. With the increasing support for IP overlay encapsulations in data center devices, there is a strong preference to utilize this support to deploy Layer-3 virtual networks using the familiarpolicy and operational primitives of Layer-3 VPNs. This document describes the use of BGP Layer-3 VPNs alongwith the new IP-based virtual network overlay encapsulations to provide a Layer-3 virtualization solution for all IP traffic, and specifies mechanisms to use the new encapsulations while continuing to leverage the BGP Layer-3 VPN control plane techniques and extensions. This mechanism provides an efficient incremental solution to support forwarding for IP traffic, irrespective of whether it is destined within or across an IP subnet boundary. "Transport Layer Security (TLS) Authorization Using DTCP Certificate", Darshak Thakore, 24-Feb-13, This document specifies the use of DTCP certificate as an authorization extension in the Transport Layer Security Handshake Protocol, according to guidelines in RFC 5878. Extensions carried in the client and server Hello messages confirm that both parties support the desired authorization data types. Then if supported by both the client and server, DTCP certificates are exchanged in the supplemental data handshake TLS handshake message as specified in RFC4680. "TRILL: Nickname and Label Properties", Donald Eastlake, Hao Weiguo, 17-Apr-13, There are a number of current and prospective requirements to indicate properties of nicknames, labels, and blocks thereof, for use with the TRILL (Transparent Interconnection of Lots of Links, RFC 6325) protocol. To meet that need, this document specifies IS-IS (Intermediate System to Intermediate System) sub-TLVs and some of their uses. "Report from the 'Smart Object Security Workshop', March 23, 2012, Paris, France", Johannes Gilger, Hannes Tschofenig, 25-Feb-13, This document provides a summary of a workshop on 'Smart Object Security', which took place in Paris on March 23, 2012. The main goal of the workshop was to allow participants to share their thoughts about the ability to utilize existing and widely deployed security mechanisms for smart objects. This report summarizes the discussions and lists the conclusions and recommendations to the Internet Engineering Task Force (IETF) community. "Security Requirements in the Software Defined Networking Model", Sam Hartman, Dacheng Zhang, 17-Apr-13, Software defined/driven networks provide new dimensions of flexibility in network design. This document analyzes security requirements as we design protocols to support multiple network applications on an SDN in an open manner. "Observations on the experience and nature of Large Interim Meetings", Joel Jaeggli, Jari Arkko, 14-Jan-13, Planning, particpipation and conclusions from the experience of participating in the IETF LIM activity on september 29th 2012. "A Framework for Semantic IPv6 Prefix and Gap Analysis", Sheng Jiang, Qiong Sun, Ian Farrer, 30-Jan-13, Some Internet Service Providers and enterprises require detailed information about the payload of traffic, so that packets can be treated differently and efficiently. Packet-level differentiation can also enable flow-level and user-level differentiation. With its large address space, IPv6 allows semantics to be embedded into addresses by assigning additional significance to specific bits within the prefix. Using these semantics, routers and other intermediary devices can easily apply relevant policies as required. This document describes a framework for such an approach. It also analyses the technical advantages and limitations associated with such an approach. This informational document only discusses the usage of semantics within a single network, or group of interconnected networks which share a common addressing policy, referred to as a Semantic Prefix Domain. The document is NOT intended to suggest the standardization of any common global semantics. "Prefix Delegation extension to Neighbor Discovery protocol", Arnaud Kaiser, Sylvain Decremps, Nouha Oualha, Alexandru Petrescu, 25-Feb-13, This document describes an extension to the Neighbor Discovery protocol (ND). The proposed extension enhances ND by providing it with a new option: the Prefix Delegation option (ND-PD). ND-PD offers the possibility for routers on a same link to ask for or delegate IPv6 prefixes. "Service Advertisement using BGP", Keyur Patel, Jan Medved, Burjiz Pithawala, 26-Apr-13, A variety of services, such as NATs, firewalls, or caches, can be embedded in a service provider network or instantiated in data centers attached to the network. This document proposes extensions to BGP that facilitate discovery of such service instances by interested clients and allows dissemination of service information, such as services capabilities or capacities, thoughtout the network domain. The proposed extensions allow for optimal routing of requests to service instances that can optimally serve them. "Network Virtualization Hypervisor-to-NVE Overlay Control Protocol Requirements", Lawrence Kreeger, Thomas Narten, David Black, 25-Feb-13, The document "Problem Statement: Overlays for Network Virtualization" 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 related to the interaction between hypervisors and the Network Virtualization Edge device when the two entities are not co-located on the same physical device. "A Framework for Service-Driven Co-Routed MPLS Traffic Engineering LSPs", Zhenbin Li, Jie Dong, 17-Apr-13, MPLS TE has been widely deployed to provide traffic engineering and traffic protection. The complexity in configuration has much effect on the MPLS TE deployment in the large-scale network. The document identifies the configuration issues for MPLS TE deployment and proposes a new mechanism, the service-driven mechanism, by which the setup of co-routed MPLS TE LSPs is triggered by the bidirectional service. Then the document provides the framework for setting up service-driven co-routed MPLS Traffic-Engineered Label-Switched Paths(TE LSPs) for L2VPN and L3VPN. "Routing Extension for Fast-Reroute Using Maximally Redundant Trees", Zhenbin Li, Nan Wu, Quintin Zhao, 28-Mar-13, The document proposes the routing protocol extension and procedures to support fast reroute using maximally redundant trees. "Applicability of LDP Multi-Topology for Unicast Fast-reroute Using Maximally Redundant Trees", Zhenbin Li, Tao Chou, Quintin Zhao, Tianle Yang, 26-Apr-13, In this document, procedures' considerations on the applicability of LDP MT for unicast fast-reroute using MRT are provided. The behaviors of label allocation and label forwarding entry setup with LDP Multi-Topology and MRT fast-reroute are described in details. Different application scenarios of the combining of the LDP multi- topology(MT) and unicast fast-reroute using Maximally Redundant Trees(MRT) are also analyzed. "Distributed Mobility Management - Framework & Analysis", Marco Liebsch, Pierrick Seite, Georgios Karagiannis, 25-Feb-13, Mobile operators consider the distribution of mobility anchors to enable offloading some traffic from their core network. The Distributed Mobility Management (DMM) Working Group is investigating the impact of decentralized mobility management to existing protocol solutions, while taking into account well defined requirements, which are to be met by a future solution. This document discusses DMM using a functional framework. Functional Entities to support DMM as well as reference points between these Functional Entities are introduced and described. The described functional framework allows distribution and co-location of Functional Entities and build a DMM architecture that matches the architecture of available protocols. Such methodology eases the analysis of best current practices with regard to functional and protocol gaps. "Operational management of Loop Free Alternates", Stephane Litkowski, Bruno Decraene, Clarence Filsfils, Kamran Raza, 18-Feb-13, Loop Free Alternates (LFA), as defined in RFC 5286 is an IP Fast ReRoute (IP FRR) mechanism enabling traffic protection for IP traffic (and MPLS LDP traffic by extension). Following first deployment experiences, this document provides operational feedback on LFA, highlights some limitations, and proposes a set of refinements to address those limitations. It also proposes required management specifications. This proposal is also applicable to remote LFA solution. "Session Peering Provisioning (SPP) Protocol over REST", Mickael Marrache, David Schwartz, Syed Ali, 22-Apr-13, The Session Peering Provisioning Framework (SPPF) is a framework that exists to enable the provisioning of session establishment data into Session Data Registries or SIP Service Provider data stores. This SPP Protocol implementation follows the REST architectural principles over HTTP to allow efficient provisioning of session establishment data. The benefits include inter alia better performances under high loads through the use of HTTP caches and proxies and less coupling between clients and servers. This document describes the specification of a protocol for transporting SPPF structures over HTTP(s) following REST architectural principles. "Model Based Internet Performance Metrics", Matt Mathis, Al Morton, 25-Feb-13, We introduce a new class of model based metrics designed to determine if a long path can meet predefined end-to-end application performance targets. This is done by section-by-section testing -- by applying a suite of single property tests to successive sections of a long path. In many cases these single property tests are based on existing IPPM metrics, with the addition of success and validity criteria. The sub-path at a time tests are designed to facilitate IP providers eliminating all known conditions that might prevent the full end-to- end path from meeting the users target performance. This approach makes it possible to to determine the IP performance requirements needed to support the desired end-to-end TCP performance. The IP metrics are based on traffic patterns that mimic TCP but are precomputed independently of the actual behavior of TCP over the sub-path under test. This makes the measurements open loop, eliminating nearly all of the difficulties encountered by traditional bulk transport metrics, which rely on congestion control equilibrium behavior. A natural consequence of this methodology is verifiable network measurement: measurements from any given vantage point are repeatable from other vantage points. "RSVP-TE LSP egress fast-protection", Jeyananth Jeganathan, Hannes Gredler, Yimin Shen, 25-Apr-13, RFC4090 defines a fast reroute mechanism for locally repairing an RSVP-TE LSP in the order of 10s of milliseconds, in the event of a downstream link or node failure. However, this mechanism does not provide node protection for LSP egress nodes, even when an alternate egress node (a backup egress) is available that could carry the traffic to its ultimate destination. This document addresses this scenario and describes how to provide egress protection by establishing a bypass LSP from the penultimate-hop node of a LSP to the backup egress node. The methods described in this document enable local repair in the order of 10s of milliseconds, in the event of the egress node failure. These methods are only applicable if traffic carried by the LSP can be rerouted to its ultimate destination by the backup egress node. "Using NTP Extension Fields without Authentication", Tal Mizrahi, Danny Mayer, 14-Feb-13, The Network Time Protocol Version 4 (NTPv4) defines the optional usage of extension fields. An extension field is an optional field that resides at the end of the NTP header, and can be used to add optional capabilities or additional information that is not conveyed in the standard NTP header. The current definition of extension fields in NTPv4 is somewhat ambiguous regarding the connection between extension fields and the presence of a Message Authentication Code (MAC). This draft clarifies the usage of extension fields in the presence and in the absence of a MAC, while maintaining interoperability with existing implementations. "HTTP 2.0 Negotiation", Willy Tarreau, Stephan Emile, Gabriel Montenegro, 16-Jan-13, This document describes an Upgrade-based protocol negotiation proposal for HTTP 2.0. "A One-Way Delay Metric for IPPM", Guy Almes, Sunil Kalidindi, Matthew Zekauskas, Al Morton, 22-Apr-13, This memo (RFC 2679 bis) defines a metric for one-way delay of packets across Internet paths. It builds on notions introduced and discussed in the IPPM Framework document, RFC 2330; the reader is assumed to be familiar with that document. "Security Analysis of the Open Networking Foundation (ONF) OpenFlow Switch Specification", Margaret Wasserman, Sam Hartman, 17-Apr-13, This document discusses the security properties of the OpenFlow Switch Specification version 1.3.0 (OpenFlow), a Software-Defined Network (SDN) solution produced by the Open Networking Foundation (ONF). It analyzes the suitability of OpenFlow for use in "the cloud" or on the open Internet. It also makes some suggestions about how OpenFlow could be made more secure for use in those environments. "SDP for the WebRTC", Suhas Nandakumar, Cullen Jennings, 24-Feb-13, The Web Real-Time Communication (WebRTC) [WEBRTC] working group is charged to provide protocol support for direct interactive rich communication using audio, video and data between two peers' web browsers. With in the WebRTC framework, Session Description protocol (SDP) [RFC4566] is used for negotiating session capabilities between the peers. Such a negotiataion happens based on the SDP Offer/Answer exchange mechanism described in the RFC 3264 [RFC3264]. This document serves a introductory purpose in describing the role of SDP for the most common WebRTC use-cases. "Cryptographic Security Characteristics of 802.11 Wireless LAN Access Systems", Stephen Orr, Anthony Grieco, Dan Harkins, 15-Oct-12, This note identifies all of the places that cryptography is used in Wireless Local Area Network (WLAN) architectures, to simplify the task of selecting the protocols, algorithms, and key sizes needed to achieve a consistent security level across the entire architecture. "Using Extended Key Usage (EKU) for REsource LOcation And Discovery (RELOAD) X.509 Certificates", Marc Petit-Huguenin, 29-Apr-13, This document describes an Extended Key Usage (EKU) X.509 certificate extension for restricting the usage of a certificate to a REsource LOcation And Discovery (RELOAD) overlay. "Resource Reservation Protocol Multiple Instance Object", James Polk, Subha Dhesikan, 25-Feb-13, This document creates the framework for a new Resource Reservation Protocol version 1 (RSVP) object for instances in which there are multiple occurrences of existing RSVP objects is to be included within the same RSVP message. This document offers two instances for multiple versions of the same object will be valid in RSVP messages, for more than one traffic specification object (TSPEC), and more than one TSPEC priority object (PREEMPTION_PRI). "Transaction SIGnature (TSIG) using CGA Algorithm in IPv6", Hosnieh, martin@v.loewis.de, Christoph Meinel, 24-Feb-13, The first step in the Transaction SIGnature (TSIG) (RFC 2845) process is the generation of a shared secret to be used between a DNS server and a host. The second step consists of modifying the DNS configuration so that the DNS server will know what key to use with which host, because this shared secret is only valid between a pair of hosts. This document, CGA-TSIG, proposes a possible way to eliminate the human intervention needed for the generation and exchange of keys between a DNS server and a host when SEcure Neighbor Discovery (SEND) (RFC 3971) is used. CGA-TSIG will facilitate the authentication process of a host with a DNS server and will reduce the time needed to accomplish DNS Updates. It will also provide a means for securing the authentication process between resolvers and clients. CGA-TSIG will be added, as an extension, to TSIG in order to provide data integrity and proof of IP address ownership. The current signature generation and verification process used in TSIG will be substituted with the use of the same parameters as are used in generating a secure address in IPv6 networks, i.e., Cryptographically Generated Addresses (CGA) (RFC 3972). "LISP Impact", Damien Saucez, Luigi Iannone, Florin Coras, 20-Feb-13, The Locator/Identifier Separation Protocol (LISP) aims at improving the Internet scalability properties leveraging on three simple principles: address role separation, encapsulation, and mapping. In this document, based on implementation, deployment, and theoretical studies, we discuss the impact that deployment of LISP has on both the Internet in general and for the end-users in particular. "Multi-Path Time Synchronization", Alex Shpiner, Richard Tse, Craig Schelp, Tal Mizrahi, 17-Feb-13, Clock synchronization protocols are very widely used in IP-based networks. The Network Time Protocol (NTP) has been commonly deployed for many years, and the last few years have seen an increasingly rapid deployment of the Precision Time Protocol (PTP). As time- sensitive applications evolve, clock accuracy requirements are becoming increasingly stringent, requiring the time synchronization protocols to provide high accuracy. Slave Diversity is a recently introduced approach, where the master and slave clocks (also known as server and client) are connected through multiple network paths, and the slave combines the information received through all paths to obtain a higher clock accuracy compared to the conventional one-path approach. This document describes a multi-path approach to PTP and NTP over IP networks, allowing the protocols to run concurrently over multiple communication paths between the master and slave clocks. The multi-path approach can significantly contribute to clock accuracy, security and fault protection. The Multi-Path Precision Time Protocol (MPPTP) and Multi-Path Network Time Protocol (MPNTP) define an additional layer that extends the existing PTP and NTP without the need to modify these protocols. MPPTP and MPNTP also allow backward compatibility with nodes that do not support the multi-path extension. "Flow Specification Extensions to OSPF Protocol", Rashmi Shrivastava, Mike Dubrovsky, Keyur Patel, Burjiz Pithawala, 17-Apr-13, This document describes the extensions to the OSPF protocol to distribute the traffic flow specification rules and associated actions. The notion and principles of operation of the mechanism were initially introduced into the BGP protocol. The IPv4 part of specification was published in RFC5575 and later the specification was enhanced for IPv6 via draft-raszuk-idr-flow-spec-v6. The mechanism allows the routing protocol to distribute information about the traffic flows and associated actions such as packet filtering with it. "IKEv2 Fragmentation", Valery Smyslov, 10-Apr-13, This document describes the way to avoid IP fragmentation of large IKEv2 messages. This allows IKEv2 messages to traverse network devices that don't allow IP fragments to pass through. "Use case of IPv6 prefix semantics for operators", Qiong Sun, Qiong Sun, Sheng Jiang, 25-Feb-13, Embedding certain semantics into IPv6 addresses will bring a lot of benifits for operators to simplify network management and apply operations accordingly[I-D.jiang-semantic-prefix]. This memo illustrates the use case of semantic bits from operator's point of view, and provides considerations on how to design the semantic bits in IPv6 address. "A Hitchhiker's Guide to the (Datagram) Transport Layer Security Protocol for Smart Objects and Constrained Node Networks", Hannes Tschofenig, Johannes Gilger, Matthias Kovatsch, 25-Feb-13, Transport Layer Security (TLS) is a widely used security protocol that offers communication security services at the transport layer. The initial design of TLS was focused on the protection of applications running on top of the Transmission Control Protocol (TCP), and was a good match for securing the Hypertext Transfer Protocol (HTTP). The Stream Control Transmission Protocol (SCTP), as a more recent connection-oriented transport protocol, also benefits from TLS support. Subsequent standardization efforts lead to the publication of the Datagram Transport Layer Security (DTLS) protocol, which allows TLS payloads to be exchanged on top of the User Datagram Protocol (UDP), and the Datagram Congestion Control Protocol (DCCP). TLS can be customized in a variety of ways and every feature has a certain cost. To offer input for implementers and system architects this document provides guidance for the usage of TLS and DTLS features for smart objects and constraint node networks. "STP Application of ICCP", Mingui Zhang, Huafeng Wen, 1-May-13, Inter-Chassis Communication Protocol (ICCP) supports the inter- chassis redundancy mechanism which achieves high network availability. In this document, the PEs in a Redundant Group (RG) running ICCP are used to offer multi-homed connectivity to Spanning Tree Protocol (STP) networks. The ICCP TLVs for the STP application are defined, therefore PEs from the RG can make use of these TLVs to synchronize the state and configuration data. "Power-Aware Networks (PANET): Problem Statement", Beichuan Zhang, Junxiao Shi, Jie Dong, Mingui Zhang, Mohamed Boucadair, 25-Feb-13, Energy consumption of network infrastructures is growing fast due to exponential growth of data traffic and the deployment of increasingly powerful equipment. There are emerging needs for power-aware routing and traffic engineering, which adapt routing paths to traffic load in order to reduce energy consumption network-wide. This document outlines the design space and problem areas for potential IETF work. "Use Cases for Power-Aware Networks", Mingui Zhang, Jie Dong, Beichuan Zhang, Bithika Khargharia, 7-Feb-13, Power Aware NETwork (PANET) has attracted strong interest from both carriers and vendors. Several use cases are investigated in this document to exhibit the potential usage of PANET in both backbone and data center networks. "Performance Monitoring Analysis for L3VPN", Lianshu Zheng, Zhenbin Li, Bhavani Parise, 17-Apr-13, To perform the measurement of packet loss, delay and other metrics on a particular VPN flow, the egress PE need to tell to which specific ingress VRF a packet belongs to. But for L3VPN, multipoint-to-point or multipoint-to-multipoint (MP2MP) network model applies, flow identifying is a big challenge. This document summarizes the current performance monitoring mechanisms for MPLS networks, and analyzes the challenge for L3VPN performance monitoring. This document also discuss the key points need to be taken in consideration when designing L3VPN performance monitoring mechanisms. "VRRP PIM Interoperability", Wei Zhou, 21-Feb-13, This document introduces VRRP Aware PIM, a redundancy mechanism for the Protocol Independent Multicast (PIM) to interoperate with Virtual Router Redundancy Protocol (VRRP). It allows PIM to track VRRP state and to preserve multicast traffic upon failover in a redundant network with virtual routing groups enabled. "VLAN Identifier option in DHCP", Chunhui Zhu, Yangwei Tu, 17-Apr-13, This document defines a new option for the Dynamic Host Configuration Protocol for IPv4 and IPv6. This option can be used by the DHCP server to carry the VLAN identifier to the DHCP client to distinguish different connections in the access network. "NADA: A Unified Congestion Control Scheme for Real-Time Media", Xiaoqing Zhu, Rong Pan, 12-Mar-13, This document describes a scheme named network-assisted dynamic adaptation (NADA), a novel congestion control approach for interactive real-time media applications, such as video conferencing. In the proposed scheme, the sender regulates its sending rate based on either implicit or explicit congestion signaling, in a unified approach. The scheme can benefit from explicit congestion notification (ECN) markings from network nodes. It also maintains consistent sender behavior in the absence of such markings, by reacting to queuing delays and packet losses instead. We present here the overall system architecture, recommended behaviors at the sender and the receiver, as well as expected network node operations. Results from extensive simulation studies of the proposed scheme are available upon request. "Stateful PCE extensions for MPLS-TE LSPs", Edward Crabbe, Jan Medved, Ina Minei, Robert Varga, 10-May-13, 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. [I-D.ietf-pce-stateful-pce] describes a set of extensions to PCEP to provide stateful control. This document describes the objects and TLVs to be used with these PCEP extensions to control Multiprotocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSP) via a stateful PCE. "A workaround for termination of IPv4 network services", Hiroaki Hazeyama, Atsushi Onoe, Osamu Nakamura, 11-Mar-13, After sun-setting of IPv4, many devices will be connected to IPv6 single stack network. In this document we describe a workaround for IPv6 enabled network configuration. At this moment, the condition of IPv6 adoption on the consumer devices such as PC, tablet, mobile terminal and entertainment device are various. For example, some devices are fully support IPv6 client but some are not. It is very hard to provide IPv6 network service with these various conditioned devices. To solve this problem, we tried to verify some configurations to connect these devices into IPv6 enabled consumer network for termination of IPv4 network services. "I-PAKE: Identity-Based Password Authenticated Key Exchange", Taekyoung Kwon, Hyojin Yoon, Sang Kim, 3-May-13, Although password authentication is the most widespread user authentication method today, cryptographic protocols for mutual authentication and key agreement, i.e., password authenticated key exchange (PAKE), in particular authenticated key exchange (AKE) based on a password only, are not actively used in the real world. This document introduces a quite novel form of PAKE protocols that employ a particular concept of ID-based encryption (IBE). The resulting cryptographic protocol is the ID-based password authenticated key exchange (I-PAKE) protocol which is a secure and efficient PAKE protocol in both soft- and hard-augmented models. I-PAKE achieves the security goals of AKE, PAKE, and hard-augmented PAKE. I-PAKE also achieves the great efficiency by allowing the whole pre-computation of the ephemeral Diffie-Hellman public keys by both server and client. "Domain Name Registration Data (DNRD) Comma-Separated Values (CSV) Objects Mapping", James Gould, Chethan Thippeswamy, 26-Mar-13, This document specifies the format and contents of Data Escrow deposits for the standard set of Domain Name Registration Data (DNRD) objects including domain, host, contact, and registrar using XML for definition and Comma-Separated Values (CSV) Files for data. "ECC Brainpool Curves for Transport Layer Security (TLS)", Johannes Merkle, Manfred Lochter, 13-May-13, This document specifies the use of several ECC Brainpool elliptic curves for authentication and key exchange in the Transport Layer Security (TLS) protocol. "Reducing Power Consumption using BGP path selection", Shankar Raman, Balaji Venkat, Gaurav Raina, Vasan Srini, 26-Mar-13, 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 suitable modifications to the BGP path selection algorithm to route the packets along the paths. Such low-power paths can be identified by using the consumed-power-to-available-bandwidth (PWR) ratio as an additional parameter in the BGP Path Selection Algorithm. For re-routing the data traffic through these low-power paths, the power based best path is selected and advertised as per the modified algorithm proposed in this document. 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. 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. A recent addition is the use of this method in AIGP domains and also the use of power source data in the calculation of low power paths using the BGP path selection algorithm. "Reducing Power Consumption using BGP", Shankar Raman, Balaji Venkat, Gaurav Raina, 26-Mar-13, 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 consumed-power-to-available-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. "Building power shortest inter-Area TE LSPs using pre-computed paths", Shankar Raman, Balaji Venkat, Gaurav Raina, 3-May-13, In this paper, we propose a framework to reduce the aggregate power consumption of an Autonomous System (AS) using a collaborative approach between areas within an AS. We identify the low-power paths within non-backbone areas and then use Traffic Engineering (TE) techniques to route the packets along the stitched paths from non- backbone areas / backbone area to other non-backbone areas. Such low- power paths can be identified by using the power-to-available- bandwidth (PWR) ratio as an additional constraint in the Constrained Shortest Path First (CSPF) algorithm. For routing the data traffic through these low-power paths, the Inter-Area Traffic Engineered Label Switched Path (TE-LSP) that spans multiple areas can be used. Extensions to the Interior Gateway Protocols like OSPF and IS-IS that support TE extensions can be used to disseminate information about low-power paths in the respective areas (backbone or non-backbone) that minimize the PWR ratio metric on the links within the areas and between the areas thereby creating a collaborative approach to reduce the power consumption. The feasibility of our approaches is illustrated by applying our algorithm to an AS with a backbone area and several non-backbone areas. The techniques proposed in this paper for the Inter-Area power reduced paths require a few modifications to the existing features of the IGPs supporting TE extensions. The proposed techniques can be extended to other levels of Internet hierarchy, such as Inter-AS paths, through suitable modifications as in [11]. When link state routing protocols like OSPF or ISIS are used to discover TE topology, there is the limitation that traffic engineered paths can be set up only when the head and tail end of the label switched path are in the same area. There are solutions to overcome this limitation either using offline Path Computation Engine (PCE) that attach to multiple areas and know the topology of all areas. This document proposes an alternative approach that does not require any centralized PCE and uses selective leaking of low-power TE path information from one area into other areas. "Power Based Topologies and TE-Shortest Power Paths in OSPF", Shankar Raman, Balaji Venkat, Gaurav Raina, Vasan Srini, 27-Mar-13, In a Interior Gateway Protocol like OSPF (Open Shortest Path First) the computation of the Constrained shortest path to destinations is computed for an area say a backbone or a non-backbone area using the TE-metrics advertised in the area. With importance given to the reduction of power within a network it becomes important to provide a solution that reduces the power consumed amongst routers and links that make up the network (in this case an area or a collection of areas including the backbone and non-backbone areas). This proposal aims at providing such a solution by producing a power topology of the area / areas. This power topology is constructed by assigning metrics to links based on the power consumed by the linecards (and hence their respective ports in an indirect way) of adjacent routers that are interconnected by each such link. "TCAM power reduction and optimization in Routers", Shankar Raman, Balaji Venkat, Kamakoti Veezhinathan, Gaurav Raina, 4-May-13, This specification entails enabling power and performance management in Routers (multi-chassis and single chassis) with respect to TCAM and SRAM usage on intelligent router line cards that implement Virtual Aggregation of routes. The version 00 of this document had several errata that have been addressed in this version. This scheme relates to unicast alone since multicast entries are programmed only after consultation with the unicast entries in the software plane in the Route processor. Hence this scheme does not apply to multicast. "The SignPuddle Standard for SignWriting Text", Stephen Slevinski, 9-May-13, For concreteness, because the universal character set is not yet universal, and because an international standard for the internet community should be documented and stable, this I-D has been released with the intention of producing an RFC to document the character use and naming conventions of the SignWriting community on the Internet. The SignWriting Script is an international standard for writing sign languages by hand or with computers. From education to research, from entertainment to religion, SignWriting has proven useful because people are using it to write signed languages. The SignWriting Script has two major families: Block Printing for the reader and Handwriting for the writer. The script encoding model presented in this document evolved from the Block Printing half of the SignWriting Script. The SignWriting Text encoding model encompasses the Block Printing family of the SignWriting Script. The plain text model for the mathematical names has been stable since January 12th, 2012. The visual image can be SVG generated on the server or created with an experimental TrueType Font. The coded character sets and character encoding forms are documented with regular expressions. The ad hoc graphemes of informal SignWriting were first created in 1974. Ad hoc graphemes are still used in the handwriting family. The standardized symbols of computerized Block Printing text began in 1986. After several generations of writers and standardized symbolsets, the ISWA 2010 has been optimized and refined as a 16-bit coded character set with several isomorphic encodings based on an ordered hierarchy with 6 degrees of significance. The International SignWriting Alphabet 2010 is a mathematical symbolset that has been stable since its initial release on May 11th, 2010. The SignPuddle Standard for SignWriting Text is an open and freely available encoding model for sign language as text. The licenses include the Open Font License for the fonts, Creative Commons by-sa (Attribution, Share Alike) for the documentation, and the GPL for the software implementation. The technological infrastructure continues to expand and should be fully realized by the time this I-D has become an RFC. SignPuddle Online contains almost 1 million examples of 2-dimensional signs written by the internet community. Each logogram has a mathematical name which describes the freeform placement of the symbols. These strings are the written record of the sign. This standard and emerging infrastructure are used for the sign language Wikipedia project on Wikimedia Labs. This standard is being integrated with the SignTyp linguistic coding system developed by Rachel Channon through an NSF grant. This standard was the origin for the alternate Unicode proposals. For Unicode, the current use of the Private Use Area font characters is documented. The state of the TrueType Font is explained. A character proposal for plane 1 is included that is isomorphic with the characters that are currently used by the community. Three appendices discuss additional topics to the standard. The first discusses the Modern SignWriting theory and example document, stable since January 12, 2012. The second discusses the founding principles of Cartesian SignWriting: a script encoding model for SignWriting Block Printing. The third discusses a common framework for written sign language grammar. This memo concretely defines a conceptual character encoding map for the Internet community. It is published for reference, examination, implementation, and evaluation. Distribution of this memo is unlimited. "Textual Representation of IPFIX Abstract Data Types", Brian Trammell, 22-May-13, This document defines UTF-8 representations for IPFIX abstract data types, to support interoperable usage of the IPFIX Information Elements with protocols based on textual encodings. "Attacks on Cryptographic Hashes in Internet Protocols", Paul Hoffman, Bruce Schneier, 29-Apr-13, Announcements in the past decade of better-than-expected collision attacks in popular hash algorithms have caused some people to question whether common Internet protocols need to be changed, and if so, how. This document summarizes the use of hashes in many protocols, discusses how the collision attacks affect and do not affect the protocols, shows how to thwart known attacks on digital certificates, and discusses future directions for protocol designers. It also gives rationales for moving away from some hash algorithms altogether and for choosing when to start using newer, presumably better, hash algorithms in Internet protocols. This document obsoletes RFC 4270 and introduces significant new material that has been learned since the publication of that document. "ICN Baseline Scenarios", Kostas Pentikousis, Borje Ohlman, Daniel Corujo, Gennaro Boggia, Gareth Tyson, Elwyn Davies, Dorothy Gellert, Priya Mahadevan, 11-Mar-13, This document aims at establishing a common understanding about potential experimental setups where different information-centric networking (ICN) approaches can be tested and compared against each other while showcasing their advantages. Towards this end, we develop several scenarios in an iterative fashion, starting by reviewing pertinent ICN evaluations from the published literature. That is, the document includes scenarios which have all been considered in one or more performance evaluation studies and are already available to the community. The scenarios selected aim to exercise a variety of aspects that an ICN solution can address. On the one hand, we consider general aspects, such as, network efficiency, reduced complexity, increased scalability and reliability, mobility support, multicast and caching performance, real-time communication efficacy, energy consumption frugality, and disruption and delay tolerance. On the other hand, we focus on ICN- specific aspects, such as, information security and trust, persistence, availability, provenance, and location independence. "RPKI validation using a local cache", Tim Bruijnzeels, Carlos Martinez, Andrew Newton, 24-Feb-13, This documents specifies validation of rpki using a local cache that is independent of any particular retrieval mechanism of the objects in this cache. This is useful because it allows for agility in the RPKI to define alternative fetch algorithms and/or multiple publication points of RPKI data. "Interactions between LFA and RSVP-TE", Stephane Litkowski, Bruno Decraene, Clarence Filsfils, Kamran Raza, 18-Feb-13, This document defines the behavior of a node supporting Loopfree Alternates (LFA) when the node has established RSVP TE tunnels. It first describes the decisions to be made by the LFA mechanism with respect to the use of TE tunnels as LFA candidates. Second, it discusses the use of RSVP TE tunnels as a way to complement the LFA coverage, illustrating how these technologies can benefit from each other. "jCal: The JSON format for iCalendar", Philipp Kewisch, Cyrus Daboo, Mike Douglass, 18-Mar-13, This specification defines "jCal", a JSON format for iCalendar data. "HTTP 2.0 Principles for Flow Control", Osama Mazahir, Jitendra Padhye, William Chan, Roberto Peon, Rob Trace, Salvatore Loreto, Gabriel Montenegro, 7-Dec-12, This document states the principles for flow control in HTTP 2.0. "Enhancing Location Based IP Services", Ammar Salih, 17-May-13, This document describes IP-LOC, a proposed extension to IPv6 header which suggests adding optional geo-location field, in order to enhance existing geo-location based IP service as well as adding new ones. The current method of determining geo-location of IP traffic is through RIR (Regional Internet Registry) database, this information is not very accurate as it depends on how the ISP registers its IP subnets, that is normally done in a country/city format. It also assumes that in the future, GPS capability could be added to the router itself (just like smart phones) and packet marking and classification based on geo-location will be required. QoS, firewall and routing based on geo-location might also be required in the future when mobile routers move from one geo-location to another, which has a different policy. "Internet International Bank Account Number (IIBAN)", Walter Stanish, 16-May-13, 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 Account Number (IBAN) standard [ISO13616] and implementation recommendations [ECBS]. This document obsoletes draft-iiban-00. "Internet Market Identification Code (IMIC)", Walter Stanish, 27-Nov-12, 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]. This document obsoletes draft-stanish-imic-00. "Registry of Unofficial Extensions to the ISO 4217 Alpha Three Currency Identification Namespace (X-ISO4217-A3)", Walter Stanish, 27-Nov-12, This document defines a new IANA registry to keep track of identifiers for currencies or currency-like commodities lying outside the traditional scope of the International Organization for Standardization (ISO) 4217 alpha-3 standard, such as digital currencies and commodities, currencies issued by countries (nation- states) with limited international recognition, emerging commodities such as emissions reduction credits, private or commercial currencies, and accounting units for local exchange and trading systems (LETS). Such codes are already in use; the registry simply codifies their existence. This document obsoletes draft-stanish-x- iso4217-a3-00. "NVGRE and VXLAN Encapsulation for L3VPN Extension", Lucy Yong, KuiKe Building, 21-May-13, This document specifies NVGRE and VXLAN encapsulation for L3VPN Extension. Both NVGRE and VXLAN are originally designed for L2 overlay. The draft proposes the enhancement on both to allow L3 overlay completely decoupled from the L2 overlay in terms of encoding schema and data processing. "RPKI Repository Delta Protocol", Tim Bruijnzeels, Oleg Muravskiy, Bryan Weber, 11-Feb-13, In the Resource Public Key Infrastructure (RPKI), certificate authorities publish certificates, including end entity certificates, and CRLs to repositories on publication servers. Relying Parties (RP) retrieve the published information from the repository and MAY store it in a cache. This document specifies a delta protocol which provides relying parties with a mechanism to query a repository for changes, thus enabling the RP to keep its state in sync with the repository. "DSCP and other packet markings for RTCWeb QoS", Subha Dhesikan, Dan Druta, Paul Jones, James Polk, 10-Mar-13, Many networks, such as service provider and private networks, can provide per packet treatments based on Differentiated Services Code Points (DSCP) on a per hop basis. This document provides the recommended DSCP values for browsers to use for various classes of traffic. "Redundant BFD sessions", Marc Binderberger, Nobo Akiya, 7-May-13, This document defines a second or "shadow" BFD session to an existing "primary" BFD session, providing resiliency against BFD failures that are not legitimate. Scenarios will be discussed on how presence of a shadow BFD session will be beneficial in the context of high availability. "OAuth Token Introspection", Justin Richer, 1-May-13, This specification defines a method for a client or protected resource to query an OAuth authorization server to determine meta- information about an OAuth token. "Hypertext Transfer Protocol (HTTP) Form Authentication Scheme", Nicholas Shanks, 30-Nov-12, This document defines the "Form" HTTP authentication scheme. It allows web developers access to standard HTTP-based authentication mechanisms whilst retaining control over the look and feel of their log-in page, without requiring any client-side scripting. Comments are requested and should be addressed to the author. "Using PCP to Reveal a Host behind NAT", Mohamed Boucadair, Tirumaleswar Reddy, Prashanth Patil, Dan Wing, 28-Nov-12, This document describes how to use PCP to retrieve the identify of a host behind a NAT. Two use cases are discussed and the PCP applicability is analyzed. This document extends PCP with a new OpCode: QUERY. The proposed mechanism is valid for all NAT flavors including NAT44, NAT64 or NPTv6. "TRILL Smart Endnodes", Radia Perlman, fangwei hu, Donald Eastlake, Kesava Krupakaran, 3-Jan-13, This draft addresses the problem of the size and freshness of the endnode learning table in access RBridges, by allowing endnodes to volunteer for endnode learning and encapsulation/decapsulation. Such an endnode is known as a "smart endnode". Only the attached RBridge can distinguish a "smart endnode" from a "normal endnode". The smart endnode uses the nickname of the attached RBridge, so this solution does not consume extra nicknames. "Security Assessment of Neighbor Discovery (ND) for IPv6", Fernando Gont, 11-Jan-13, Neighbor Discovery is one of the core protocols of the IPv6 suite, and provides in IPv6 similar functions to those provided in the IPv4 protocol suite by the Address Resolution Protocol (ARP) and the Internet Control Message Protocol (ICMP). Its increased flexibility implies a somewhat increased complexity, which has resulted in a number of bugs and vulnerabilities found in popular implementations. This document provides guidance in the implementation of Neighbor Discovery, and documents issues that have affected popular implementations, in the hopes that the same issues do not repeat in other implementations. "Enhanced Closed Swarm protocol", Dusan Gabrijelcic, 29-Nov-12, The Enhanced Closed Swarm (ECS) protocol is a distributed access control mechanism suitable for usage in Peer-to-Peer content delivery systems. The protocol provides coarse or fine grained authorization of peers participating in content distribution. As a result, only authorized peers are allowed to communicate in a swarm. The protocol also provides data confidentiality, integrity and origin authentication for application data exchanged among peers. The protocol is simple but flexible enough to enable a range of usage scenarios. In addition to the ECS protocol, this document also describes its application in the IETF PPSPP. "Secure Call Origin Identification", Alissa Cooper, Hannes Tschofenig, Jon Peterson, Bernard Aboba, 30-Nov-12, A number of parties have suggested creating mandates such that networks receiving voice calls would be capable of securely identifying the call origin. This document provides insights about the capabilities and limitations of supporting call origin identification in a secure and privacy- friendly way in the PSTN and for IP-based real-time communications. "Multicast Issues in Networks Using NVO3", Anoop Ghanwani, 30-Nov-12, This memo discusses issues with supporting multicast traffic in a network that uses Network Virtualization using Overlays over Layer 3. It lists the various mechanisms that may be used for multicast and describes some of the considerations. "Encapsulation Methods for Transport of Frame Relay over Multiprotocol Label Switching (MPLS) Networks with Multilink Frame Relay UNI/NNI (FRF.16) Endpoints", Eswaran Srinivasan, Luis Tomotaki, 30-Nov-12, A Frame Relay pseudowire (PW) with Multilink Frame Relay UNI/NNI (FRF.16) is a mechanism that can be used for transporting the Frame Relay Protocol Data Units (PDUs) got after reassembling the FRF.16 fragments over a MPLS packet switched network (PSN). The goal of this document is to describe the encapsulation that is required for this. "A Fast-Track way to RFC with Running Code", Stephen Farrell, 6-Jan-13, This memo describes an optional, fast-track way to progress a working group document to IESG review. It is provided as a process experiment as defined in RFC 3933 for use when working group chairs believe that there is running code that implements a working group Internet-Draft. The motivation is to have the IETF process explicitly consider running code, consistent with the IETF's overall philosophy of running code and rough consensus. In this process all of working group last call, IETF last call, and Area Director review are carried out in the same two week period. Only comments that meet IESG Discuss criteria need to be addressed during this stage, and authors are required to make any changes within two weeks. This experiment will run for one year. "A PCE-based Architecture for Application-based Network Operations", Daniel King, Adrian Farrel, 25-Feb-13, Services such as content distribution, distributed databases, or inter-data center connectivity place a set of new requirements on the operation of networks. They need on-demand and application-specific reservation of network connectivity, reliability, and resources (such as bandwidth) in a variety of network applications (such as point-to- point connectivity, network virtualization, or mobile backhaul) and in a range of network technologies from packet (IP/MPLS) down to optical. An environment that operates to meet this type of requirement is said to have Application-Based Network Operations (ABNO). ABNO brings together several existing technologies for gathering information about the resources available in a network, for consideration of topologies and how those topologies map to underlying network resources, for requesting path computation, and for provisioning or reserving network resources. Thus, ABNO may be seen as the use of a toolbox of existing components enhanced with a few new elements. The key component within an ABNO is the Path Computation Element (PCE), which can be used for computing paths and is further extended to provide policy enforcement capabilities for ABNO. This document describes an architecture and framework for ABNO showing how these components fit together. It provides a cookbook of existing technologies to satisfy the architecture and meet the needs of the applications. "JSON Meta Object", Nat Sakimura, 1-Dec-12, Although JSON has become a popular choice of the web services response that tries to be REST like, the lack of its capability to express the hyperlink and other metadata in a standardized manner has been felt. This document proposes a method to minimally represent such metadata that can be inserted into the existing JSON responses to express such metadata. "Creating an IETF Working Group Draft", Adrian Farrel, DCrocker, 2-Dec-12, The productive output of IETF working groups is documents, as mandated by the working group's charter. When a working group is ready to develop a particular document it usually "adopts" it as a working group draft. The document that a working group adopts and then develops further is based on initial input at varying levels of maturity. An initial working group draft might be a document already in wide use, or it might be a blank sheet, wholly created by the working group, or it might represent any level of maturity in between. This document discusses the process of creating formal working group drafts that are targeted for publication. "HTTP User Agent Feature Identifiers", Liam McSherry, 4-Dec-12, HTTP User Agent Feature Identifiers (HAFI, Hah-Fee) is a simple method for user agents, such as web browsers, to reveal the technologies that are supported by them. These technologies include items such as Cascading Style Sheets, and various versions of HTML. "AODV Extensions for MANET Clustering", Sanghyun Ahn, Seoul University, 13-May-13, This document describes an extention on AODV [1] so that clustering of MANET nodes can be allowed for the improvement of MANET scalability. MANET clustering requires some MANET nodes to become Cluster Heads (CHs) and each non-CH MANET nodes to belong to any one appropriate cluster which is represented by a CH node.In this draft, AODV control messages are extended for MANET clustering. "Architecture for MANET Clustering", Sanghyun Ahn, Hyogon Kim, 13-May-13, This document describes the architecture for clustering in the MANET which can be an efficient communication structure for the case when MANET nodes have the tendency of forming groups. In this type of MANET, each group of nodes forms a cluster which is represented by a cluster head. In this draft, we define the terminology for the MANET clustering and the related communication procedure. "remotestorage", Michiel de Jong, F. Kooman, 4-Dec-12, This draft describes a protocol by which client-side applications, running inside a web browser, can communicate with a data storage server that is hosted on a different domain name. This way, the provider of a web application need not also play the role of data storage provider. The protocol supports storing, retrieving, and removing individual documents, as well as listing the contents of an individual directory, and access control is based on bearer tokens. "Signature Authentication in IKEv2", Tero Kivinen, 16-Apr-13, The Internet Key Exchange Version 2 (IKEv2) protocol has limited support for the Elliptic Curve Digital Signature Algorithm (ECDSA). The current version only includes support for three Elliptic Curve groups, and there is fixed hash algorithm tied to each curve. This document generalizes the IKEv2 signature support so it can support any signature method supported by the PKIX and also adds signature hash algorithm negotiation. This is generic mechanism, and is not limited to ECDSA, but can also be used with other signature algorithms. "Mailing list protocol", S Moonesamy, 4-Dec-12, This document discusses about a mailing list protocol. This protocol is not a protocol for communication devices. It is a code of courtesy that the reader may wish to extend to others to facilitate the exchange of opinions and ideas, and to facilitate mailing list discussions. "A convention for URIs operating a HTTP-CoAP reverse proxy", Carsten Bormann, 5-Dec-12, CoAP is a RESTful transfer protocol for constrained nodes and networks. In many applications, CoAP will be used via cross-protocol proxies from HTTP clients. HTTP client libraries may make it hard to operate an HTTP-CoAP forward proxy by not providing a way to put a CoAP URI on the HTTP Request-Line; reverse-proxying may therefore lead to wider applicability of a proxy. This specification will define a convention for URIs operating such a HTTP-CoAP reverse proxy. The current version of this specification is a placeholder only. It is meant to pick up http://trac.tools.ietf.org/wg/core/trac/ticket/259 and provide a home for its considerations. It might be merged with other documents later. "Requirements for Marking SIP Messages to be Logged", Peter Dawes, 9-Jan-13, SIP networks use signalling monitoring tools to diagnose user reported problem and for regression testing if network or client software is upgraded. As networks grow and become interconnected, including connection via transit networks, it becomes impractical to predict the path that SIP signalling will take between clients, and therefore impractical to monitor SIP signalling end-to-end. This draft describes requirements for adding an indicator to the SIP protocol which can be used to mark signalling as subject to logging. Such marking will typically be applied as part of network testing controlled by the network operator and not used in regular client signalling. However, such marking can be carried end-to-end including the SIP terminals, even if a session originates and terminates in different networks. "A DNS Resource Record for Service Descriptions", Eliot Lear, 21-Feb-13, Certain application protocols are highly transactional and require substantial care when dealing with latency. Queries for versioning information are, in these circumstances, costly. In addition, there is a desire to allow for a means to specify a lightweight means to alternative transport protocols, such as making use of SCTP instead of TCP. This memo specifies a new DNS RR with an eye toward the least necessary roundtrips to determine various protocols, port numbers, and options for a given service instance. "Using CoAP with IPsec", Carsten Bormann, 6-Dec-12, CoAP is a RESTful transfer protocol for constrained nodes and networks. Security for the protocol can be supplied in a number of ways. The mandatory-to-implement security mode for CoAP makes use of DTLS. Other applications may want to use IPsec. This document will discuss considerations for the use of IPsec with CoAP. It will be advanced on a timescale separate from the main CoAP specification, as most experience in securing CoAP so far has been made with DTLS. The current version of this specification is a placeholder, built out of text extracted from draft-ietf-core-coap-12. It is meant to pick up http://trac.tools.ietf.org/wg/core/trac/ticket/262 and provide a home for its considerations. It might be merged with other documents later. "SIP signalling for ICE trickling", Shitao Li, 6-Dec-12, Trickle ICE is a mechanism that allows ICE agents to send and receive candidates incrementally rather than exchanging complete lists. This document gives several solutions for trickle ICE with SIP protocol. Note Discussion and suggestions for improvement are requested, and should be sent to dispatch@ietf.org. "Secure Routing Protocol for Delay and Tolerant Networks", Tao Liu, 7-Dec-12, The Secure Routing Protocol (SRP) is a secure and distributed routing protocol designed for Delay and Tolerant Networks networks of mobile nodes with location information. Commonly, each node acquires its own geographic position using a mechanism such as the Global Position System (GPS). The SRP addresses each node using the hybrid of its multi-level hierarchical address and unique identifier at the moment of network initialization. Certain measures were adopted to ensure security of the network. "Intellectual Property Rights in IETF Technology", Scott Bradner, Jorge Contreras, 8-Apr-13, The IETF policies about Intellectual Property Rights (IPR), such as patent rights, relative to technologies developed in the IETF are designed to ensure that IETF working groups and participants have as much information about any IPR constraints on a technical proposal as possible. The policies are intended to benefit the Internet community and the public at large, while respecting the legitimate rights of IPR holders. This memo details the IETF policies concerning IPR related to technology worked on within the IETF. It also describes the objectives that the policies are designed to meet. This memo updates RFC 2026 and obsoletes RFC 3979 and RFC 4879. "Via header field parameter to indicate received realm", Christer Holmberg, Yi Jiang, 10-Dec-12, This specification defines a new Session Initiation Protocol (SIP) Via header field parameter, "received-realm", which allows a SIP entity acting as an entry point to a transit network to indicate from which adjacent upstream network a SIP request is received, using a network realm value associated with the adjacent network. "Compact representation of an elliptic curve point", Andrey Jivsov, 10-Dec-12, This document defines a format for efficient storage representation of an elliptic curve point over prime fields, suitable for use with any IETF format or protocol. "URI Template Descriptions", Erik Wilde, Cornelia Davis, Yiming Liu, 10-Dec-12, Interactions with many resources on the Web are driven by and/or can be described by URI Templates. RFC 6570 says that "a URI Template is a compact sequence of characters for describing a range of Uniform Resource Identifiers through variable expansion." This specification defines Template Descriptions, a schema and a media type that can be used to document and describe a URI Template by supporting descriptive markup that allows variables to be associated with documentation (human-oriented) and/or descriptions (machine- oriented). Template Descriptions can be used by media types (by inclusion or by reference) that seek to make URI Templates self- describing, without having to create their own representation. "A Network Virtualization Overlay Solution using E-VPN", Ali Sajassi, John Drake, Nabil Bitar, Aldrin Isaac, James Uttaro, Wim Henderickx, 11-Dec-12, This document describes how E-VPN can be used as an NVO solution and explores the various tunnel encapsulation options and their impact on the E-VPN control-plane and procedures. In particular, the following encapsulation options are analyzed: MPLS over GRE, VXLAN, and NVGRE. "NVO3 Framework and Data Plane Requirement Addition", Lucy Yong, Linda Dunbar, 11-Dec-12, This document describes some additional functions and requirements for NVO3 framework [NVO3FRWK] and data plane requirements [DPREQ]. These additions are necessary in supporting VM communication and mobility. "JSON Metadata for OAuth Responses 1.0", Mike Kelly, Nat Sakimura, 12-Feb-13, This specification defines an extensible metadata member that may be inserted into the OAuth 2.0 responses to assist the clients to process those responses. It is expressed as a member called "_links" that is inserted as the top level member in the responses. It will allow the client to learn where the members in the response could be used and how, etc. Since it is just a member, any client that does not understand this extension should not break and work normally while supporting clients can utilize the metadata to its advantage. "Improving Awareness of Running Code: the Implementation Status Section", Yaron Sheffer, Adrian Farrel, 14-May-13, This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, by considering the running code as evidence of valuable experimentation and feedback that has made the implemented protocols more mature. The process in this document is offered as an experiment. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. The authors of this document intend to collate experiences with this experiment and to report them to the community. "Maximum Tolerable Delays when using Tunneling Compressed Multiplexed Traffic Flows", Mirko Suznjevic, Jose Saldana, 12-Dec-12, This document contains recommendations of maximum tolerable delays to be added by methods which improve bandwidth utilization through compression, multiplexing, and tunneling over a network path. Recommendations are presented only for real-time network services for which such bandwidth optimization techniques are applicable (i.e., services with low payload size to header size ratio). "Virtualized Integrated Routing & Bridging with centralized control plane", Lizhong Jin, Bhumip Khasnabish, 13-Dec-12, The network in datacenter is required to provide a tenant network, which should be virtualized, and be able to provide L2 switching or L3 routing capability. A combined L2&L3 solution could provide great scalability for both Layer2 and Layer3 switching. In this document, we propose to apply centralized server to be the control plane of the combined L2&L3 solution, to provide better scalability for the control plane. The combined L2&L3 solution in this draft is named Virtualized Integrated Routing&Bridging (shorted as VIRB). "Requirements for Automated (Configuration) Management", Mohamed Boucadair, Christian Jacquenet, 14-Dec-12, Given the ever-increasing complexity of the configuration tasks required for the dynamic provisioning of IP networks and services, this document aims at listing the requirements to drive the specification of an automated configuration management framework, including the requirements for a protocol to convey configuration information towards the managed entities. "Simplified and Minimized Profiles of the Generic Security Services Application Programming Interface", Nico Williams, 14-Dec-12, The Generic Security Service Application Programming Interface (GSS- API) is often mistaken for a bloated framework. The GSS-API is really several things: a basis for formal descriptions of application authentication protocols (what happens when), a pattern for actual programming APIs, a set of constraints and requirements for generic security mechanisms, and concrete programming APIs. Only the first of these is relevant to Internet application protocols. This document describes simplified and minimized profiles of the GSS- API for two purposes: explaining its use, whether in standards specifications or actual applications, and specifying sub-sets of the API for a) newcomers to the API, b) application developers that wish to use it but not have to link the whole thing into their applications. "Analysis of RSVP-TE Security According to KARP Design Guide", Mahesh Jethanandani, Dacheng Zhang, 20-May-13, This document analyzes Resource reSerVation Protocol-Traffic Engineering (RSVP-TE) according to guidelines set forth in section 4.2 of KARP Design Guidelines (RFC 6518). "Lightweight Directory Access Protocol (LDAP): Auxiliary Object Class 'mailboxRelatedObject'", Michael Stroeder, 28-Jan-13, This document defines the auxiliary object class 'mailboxRelatedObject' that can be used to associate an arbitrary object with a RFC 2822 mail address. Furthermore a attribute 'intlMailAdr' is defined for internationalized email addresses. "Lightweight Directory Access Protocol (LDAP): Structural Object Classes for Named Objects", Michael Stroeder, 7-Jan-13, This document defines structural object classes that can be used when no other structural object class seems suitable. Especially the object classes will give the possibility to associate a common name and a free-form description with the object. "The WebSocket Protocol as a Transport for the Message Session Relay Protocol (MSRP)", Peter Dunkley, Gavin Llewellyn, Victor Pascual, 10-May-13, The WebSocket protocol enables two-way real-time communication between clients and servers. This document specifies a new WebSocket sub-protocol as a reliable transport mechanism between MSRP (Message Session Relay Protocol) clients and relays to enable usage of MSRP in new scenarios. This document normatively updates RFC 4975 and RFC 4976. "CoAP Via Option Extension", Xianyou Fan, 18-Dec-12, This document adds an extension option to the Constrained Application Protocol (CoAP): Via. The Via option is used to indicate the proxies between the coap client and the coap server. "IRR & Routing Policy Configuration Considerations", Danny McPherson, Shane Amante, Eric Osterweil, Larry Blunk, 18-Dec-12, The purpose of this document is to catalog past issues influencing the efficacy of Internet Routing Registries (IRR) for inter-domain routing policy specification and application in the global routing system over the past two decades. Additionally, it provides a discussion regarding which of these issues are still problematic in practice, and which are simply artifacts that are no longer applicable but continue to stifle inter-provider policy-based filtering adoption and IRR utility to this day. "Route Leaks & MITM Attacks Against BGPSEC", Danny McPherson, Shane Amante, Eric Osterweil, 18-Dec-12, 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. "ALTO Server Discovery based on well-known IP Address", Sebastian Kiesel, Reinaldo Penno, 27-Dec-12, The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications that have to select one or several hosts from a set of candidates capable of providing a desired resource. ALTO is realized by a client-server protocol. This document establishes a well-known IP address for the ALTO service and specifies how ALTO clients embedded in the resource consumer can use it to access the ALTO service. "vFW state migration problem statement", Yuchen Wang, Gu Yingjie, Dacheng Zhang, 18-Dec-12, This draft introduces the state migration issues with the virtual security mechanisms (e.g., virtual firewalls) in data centers caused by the immgration of the virtual machines. "Problems with Security Descriptions in RTCWEB Architecture", Dan Wing, 18-Dec-12, This document analyzes the problems of deploying Security Descriptions on the RTCWEB architecture. This document contributes to the discussion and analysis of Security Descriptions, and is not intended to become an RFC. "A ROA Status Attribute for RPSL Objects", Larry Blunk, 19-Dec-12, This document describes an attribute for Routing Policy Specification Language (RPSL) route and route6 objects that documents the presense and validity of a Route Origin Authorization (ROA) for the given prefix and origin values contained within the object. It allows parties who employ Internet Routing Registries (IRR's) for routing policy configuration generation to easily ascertain whether a given object has a ROA covering the object. The primary objective is to enable existing IRR tools to make use of the ROA information with minimal modifications. "Backup Path for Point-to-Point Routes in Low Power and Lossy Networks", Dinh-Sy Do, Ngoc-Thanh Dinh, Young-Han Kim, 20-Dec-12, In this draft, a backup path setup mechanism is proposed for the P2P-RPL protocol in Low Power and Lossy Networks (LLNs). This mechanism allows sensor nodes to send packets over the backup path without rediscovering the p2p path in case of path failure, thus improving the reliability of p2p transmission. "Large-Scale Broadband Measurement Use Cases", Marc Linsner, Philip Eardley, Trevor Burbridge, 25-Feb-13, Measuring broadband performance on a large scale is important for network diagnostics by providers and users, as well for as public policy. To conduct such measurements, user networks gather data, either on their own initiative or instructed by a measurement controller, and then upload the measurement results to a designated measurement server. Understanding the various scenarios and users of measuring broadband performance is essential to development of the system requirements. The details of the measurement metrics themselves are beyond the scope of this document. "SCIM 2.0 Token Search Extension", Phil Hunt, Kelly Grizzle, Morteza Ansari, Dale Olds, 23-Dec-12, The SCIM 2.0 Core API defines a simple profile for searching for specific resource types using filters and qualifiers in combination with the HTTP GET verb. The Token Search specification defines the following additional features: o Specification of search terms within an HTTP POST verb to avoid accidental leakage of confidential information via HTTP GET URLs, o An optional result set token enabling clients to page through results in a state consistent fashion, and o The ability to search across multiple resource types (endpoints) and return one or more resource types. "SCIM 2.0 Extended Search", Phil Hunt, Kelly Grizzle, Morteza Ansari, Dale Olds, 23-Dec-12, The SCIM 2.0 Core API defines a simple profile for searching for specific resource types using filters and qualifiers in combination with the HTTP GET verb. The Extended Search specification defines the following additional features: o Specification of search terms within an HTTP POST verb to avoid accidental leakage of confidential information via HTTP GET URLs, o An optional result set representation enabling clients to page through results in a state consistent fashion, and o The ability to search across multiple resource types (endpoints) and return one or more resource types. "OAuth 2.0 Resource Set Registration", Thomas Hardjono, 27-Dec-12, This specification defines a resource set registration mechanism between an OAuth 2.0 authorization server and resource server. The resource server registers information about the semantics and discovery properties of its resources with the authorization server. "E164/214 MPBGP announcement", Shu Ge, 28-Dec-12, Recently, transferring the signaling of mobile network over IP attracts lots of attention from people. Telephone number based on E.164 or E.214 or SP is the traditional routing address for mobile network, but actually, E.164, E.214 and SP is not supported by MP-BGP protocol. This document presents a new way to support for routing the phone number based on E.164, E.214 or SP though MP-BGP, by extending the MP-BGP for the Phone Number Routing. It can bring optimizing for the network architecture and improving efficiency. "JSON Private and Symmetric Key", Michael Jones, 28-Dec-12, The JSON Private Key specification extends the JSON Web Key (JWK) and JSON Web Algorithms (JWA) specifications to define JavaScript Object Notation (JSON) representations of private keys and symmetric keys. "OCSP-lite - Revocation of raw public keys", Bert Greevenbosch, 30-Dec-12, This document provides an online mechanism for checking the revocation status of raw public keys. The mechanism is based on its older brother for X.509 certificates, OCSP. Note Discussion and suggestions for improvement are requested, and should be sent to tls@ietf.org. "MN IP Capability for Wifi-EPC Integration", Yangwei Tu, 30-Dec-12, WiFi is beginning to be considered as a trusted non-3GPP access network which can provide the service of accessing to the EPC core network to the user. And EAP/AKA(and EAP/AKA') is specified as the access authentication protocol in this case. This document defines a new EAP attribute to provide the mobile node IPv4/IPv6/IPv4v6 capability to the network so that mobile node IP address/prefix assignment and PMIP session establishment can be processed accordingly. "Encapsulating IP in UDP", KuiKe Building, Lucy Yong, Yiu Lee, Fan Yongbing, 19-Feb-13, Existing Softwire encapsulation technologies are not adequate for efficient load balancing of Softwire service traffic across IP networks. This document specifies additional Softwire encapsulation technology, referred to as IP-in-User Datagram Protocol (UDP), which can facilitate the load balancing of Softwire service traffic across IP networks. "End-point based Multimedia QoE Management", Bhumip Khasnabish, Gerard Fernando, 31-Dec-12, This draft describes a method for improving the quality of experience (QoE) for real-time video and other multimedia services using features and functions of the end-point only, that is, without requiring any upgrade to the network transport infrastructure. Any upgrade to the network transport infrastructure not only incurs significant costs, these are also time consuming and technology- dependent. Therefore, these QoE improvement mechanisms are significantly more attractive to both network operators and service providers. "Hypertext Transport Protocol (HTTP) Session Continuation: Problem Statement", Nico Williams, 1-Jan-13, One of the most often talked about problems in web security is "cookies". Web cookies are a method of associating requests with "sessions" that may have been authenticated somehow. Cookies are a form of bearer token that leave much to be desired. This document describes the session "continuation" problem for the HyperText Transport Protocol (HTTP). "Hypertext Transport Protocol (HTTP) Session Continuation Protocol", Nico Williams, 1-Jan-13, One of the most often talked about problems in web security is "cookies". Web cookies are a method of associating requests with "sessions" that may have been authenticated somehow. Cookies are a form of bearer token that leave much to be desired. This document proposes a session "continuation" protocol for HyperText Transport Protocol (HTTP). "Tracking of Static/Autoconfigured IPv6 addresses", Rajiv Asati, Dan Wing, 3-Jan-13, Network operators commonly use Dynamic Host Configuration Protocol (DHCP) to assign IP addresses to the hosts, and track them. However, the tracking capability is lost when stateless autoconfiguration or manual methods are used to assign IPv6 addresses. This document proposes a Dynamic Host Configuration Protocol for IPv6 (DHCPv6) based mechanism that the last hop router can use to convey the hosts' IPv6 addresses for the tracking and logging purposes, without requiring any changes to the hosts. "TRILL: Support of IEEE 802.1 Priority-based Flow Control and Enhanced Transmission Selection", Donald Eastlake, Manoj Wadekar, Anoop Ghanwani, Puneet Agarwal, Tal Mizrahi, 3-Jan-13, This document briefly explains the IEEE 802.1 Priority-based Flow Control and Enhanced Transmission standards and discusses the support of these standards in TRILL switches (devices that implement the IETF TRILL protocol standard). "Pausing an RTP Media Stream", Roni Even, 3-Jan-13, In Real-time multimedia applications using multiple media streams in point to point and multipoint calls can benefit from options that will enable them to pause and resume media streams as well as to indicate a mute state. This document describes the difference between pause and mute and describes how to provide this required functionality. This document updates RFC5104. "Self-published IP Geolocation Data", Erik Kline, Krzysztof Duleba, Zoltan Szamonek, 16-May-13, This document records a format whereby a network operator can publish a mapping of IP address ranges to simplified geolocation information, colloquially termed a geolocation "feed". Interested parties can poll and parse these feeds to update or merge with other geolocation data sources and procedures. Some technical organizations operating networks that move from one conference location to the next have already experimentally published small geolocation feeds. At least one consumer (Google) has incorporated these ad hoc feeds into a geolocation data pipeline. "Update Attribute Flag Low Bits Clarification", Susan Hares, John Scudder, 25-Feb-13, This draft provides an update to RFC 4721 to clarify the use of the lower-order four bits of the Attribute flag in the Update message. "ABNF Extensions for Importing and Scoping", Paul Kyzivat, 3-Jan-13, This document proposes extensions to the ABNF defined in [RFC5234] to support importation of ABNF from other documents, and multiple naming scopes for rulenames. "A Simple Secure Address Generation Scheme for IPv6 AutoConfiguration (SSAS)", Hosnieh, Christoph Meinel, 11-Mar-13, The default method for IPv6 address generation uses an Organizationally Unique Identifier (OUI) assigned by the IEEE Standards Association and an Extension Identifier assigned to the hardware manufacturer [1] (section 2.5.1 RFC-4291) [RFC4291]. This fact thus means that a node will always have the same Interface ID (IID) whenever it connects to a new network. Because the node's IP address does not change, the node will be vulnerable to privacy related attacks. Currently this problem is addressed by the use of two mechanisms that do not make use of the MAC address, or other unique values that can be used for ID generation, for randomizing the IID; Cryptographically Generated Addresses (CGA) [RFC3972] and Privacy Extension [RFC4941]. The problem with the former approach is the computational cost involved for the IID generation and in the verification process. The problem with the latter approach is that it lacks necessary security mechanisms and provides the node with only partial protection against privacy related attacks. This document proposes the use of a new algorithm for use in the generation of the IID while, at the same time, securing the node against some types of attack, like IP spoofing. These attacks are prevented by the addition of a signature to messages sent over the network and by direct use of a public key in the IP address. "TRILL: Support of IEEE 802.1 Congestion Notification", Donald Eastlake, Manoj Wadekar, Anoop Ghanwani, Puneet Agarwal, Tal Mizrahi, 4-Jan-13, This document briefly explains the IEEE 802.1 Congestion Notification standard and specifies the support of this standard in TRILL switches (devices that implement the IETF TRILL protocol standard). It updates RFC 6325. "Computing Power Saving Paths using TCAM Power Ratio", Shankar Raman, Balaji Venkat, Kamakoti Veezhinathan, 2-Feb-13, A power saving scheme for switching of TCAM banks of fine granularity is discussed in [ID-TCAM-POWER-EFF]. This scheme switches of TCAM banks of fine granularity and their corresponding SRAM banks depending on the occupancy of routes and their rewrites within the TCAM of a intelligent router line card (where one or more such TCAM entities along with their SRAM banks may reside) by using an algorithm specified in [ID-TCAM-POWER-EFF]. This takes care of switching off TCAM and SRAM banks within a router's line card and correspondingly saves power when the traffic matrix is not large with respect to the routes the packets lookup where the occupancy of such routes is low in the line card. This is with reference to both single and multi-chassis devices. The algorithm specified therein tends to switch off banks which are not in use. The aim of this draft is to use the device level characteristic in the form of a TCAM Power Ratio and disseminate it as a metric within an area or an Autonomous system (where multiple such areas exist within an AS) to compute power saving paths through the set of routers where the TCAM-POWER-RATIO is low. The TCAM-POWER-RATIO is arrived at by dividing the number of bits in the TCAM banks that are switched off by the Total Available TCAM bank space in bits. This ratio is then subjected to the CSPF algorithm as an additional constraint or the only constraint as the case may be in a link state protocol like OSPF or IS-IS with Traffic Engineering Extensions with available utilization on the links also being a factor. This way those routers that have more TCAM banks switched off are avoided and those with higher power consumption but with available bandwidth are used hence not increasing the total power consumed within the area and hence within the AS. This could be achieved by using a PCE like entity that calculates the power shortest paths using this TCAM-POWER-RATIO. "List of Internet Official Protocol Standards: Replaced by an Online Database", Sandy Ginoza, 13-Feb-13, This document obsoletes RFC 5000 ("Internet Official Protocol Standards"), which contained a snapshot of the Standards Track documents as of May 2008, and moves RFC 5000 to Historic. This document also retires the subseries identifier STD 1, which has previously been associated with publications of the "Internet Official Protocol Standrds". "Retiring the RFC Summary Documents", Sandy Ginoza, 7-Jan-13, Beginning in December 1991, a "Request for Comments Summary" was published every 100 RFCs. RFC numbers ending with 99 were reserved for these summary documents. This document retires the publication of the RFC summary documents. Moving forward, RFC numbers ending in 99 will be assigned to RFCs-to-be. "L2L3 VPN Multicast MIB", Jeffrey Zhang, 7-Jan-13, 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 common to both VPLS and VPN Multicast. "Traffic Management Benchmarking", Barry Constantine, Timothy Copley, Ram Krishnan, 19-Apr-13, This framework describes a practical methodology for benchmarking the traffic management capabilities of networking devices (i.e. policing, shaping, etc.). The goal is to provide a repeatable test method that objectively compare performance of the device's traffic management capabilities and to specify the means to benchmark traffic management with representative application traffic. "Efficient Multiplexing of ISDN User-Network Interfaces over TDM Pseudo-wires", Javier Munoz-Calle, Juan Vozmediano, 11-Jan-13, This document defines a mechanism to efficiently multiplex a number of ISDN interfaces over a single TDMPW. This mechanism would allow a single Access Gateway to remotely terminate a high number of distant local loops. "TRILL: Parent Selection in Distribution Trees", Howard Yang, Ayan Banerjee, Donald Eastlake, Radia Perlman, 11-Jan-13, This document describes a protocol extension in TRILL IS-IS and a parent selection tiebreak algorithm in the calculation of distribution trees in TRILL. The proposal is to modify the current algorithm to improve the stability of the distribution trees when multiple equal cost parents are present. It also offers the capabilities of pinning down multi-destination traffic and re-shaping the distribution tree to improve the traffic load splitting. "Reclassifying Internet Registry Allocation Guidelines to Historic", S Moonesamy, 12-Jan-13, RFC 2050 describes the registry system for the distribution of globally unique Internet address space and registry operations. It also discusses about policy issues which are outside the scope of the IETF. This document reclassifies RFC 2050 as Historic. It also reclassifies RFC 1366 and RFC 1466 as Historic. "ICN Wireless Sensor and Actor Network BaseLine Scenarios", Ngoc-Thanh Dinh, Young-Han Kim, 13-Jan-13, This document presents scenarios for information centric wireless sensor and actor networks. The scenarios selected for inclusion in this first draft aim to exercise a variety of aspects in wireless sensor and actor network that an ICN solution could address. "PKCS 12 v1: Personal Information Exchange Syntax", Kathleen Moriarty, Magnus Nystrom, Sean Parkinson, Andreas Rusch, Michael Scott, 25-Mar-13, This standard describes a transfer syntax for personal identity information, including private keys, certificates, miscellaneous secrets, and extensions. Machines, applications, browsers, Internet kiosks, and so on, that support this standard will allow a user to import, export, and exercise a single set of personal identity information. This standard supports direct transfer of personal information under several privacy and integrity modes. "Anycast, Multicast or Broadcast Bootstrap Nodes for REsource LOcation And Discovery (RELOAD)", Marc Petit-Huguenin, 14-Jan-13, This document describes an extension to REsource LOcation And Discovery (RELOAD) that permits to contact a bootstrap node using an Anycast, Multicast or Broadcast IP address. "Considerations with WebRTC in Mobile Networks", Tirumaleswar Reddy, John Kaippallimalil, Ram R, Richard Ejzak, 9-May-13, This document discusses some of the issues with WebRTC applications in Mobile Networks. "IPv6 Prefix Sharing Problem Use Case", Behcet Sarikaya, Marco Spini, DH, 11-Feb-13, The purpose of this document is to present a use case on problems in addressing end user equipment arising from IPv6 prefix sharing. "A registry for commonly used metrics", Marcelo Bagnulo, Trevor Burbridge, Sam Crawford, Philip Eardley, Al Morton, 15-Jan-13, This document creates a registry for commonly used metrics, defines the rules for assignments in the new registry and performs initial allocations. This document proposes one particular registry structure with a single registry with multiple sub-registries. A companion document draft-bagnulo-ippm-new-registry-independent explores an alternative structure with independent registries for each of the fields involved. . "A registry for commonly used metrics. Independent registries", Marcelo Bagnulo, Trevor Burbridge, Sam Crawford, Philip Eardley, Al Morton, 15-Jan-13, This document creates a registry for commonly used metrics, defines the rules for assignments in the new registry and performs initial allocations. This document proposes one particular registry structure with independent registries for each of the fields involved. A companion document draft-bagnulo-ippm-new-registry explores an alternative structure with a single registry with multiple sub-registries. "Chatrooms within a Centralized Conferencing (XCON) System", Mary Barnes, Chris Boulton, Salvatore Loreto, 15-Jan-13, 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. "The problem statement of RBridge edge group state synchronization", Hao Weiguo, Li Yizhou, 15-Jan-13, In TRILL multi-homing scenario, the concept of virtual RBridge in [TRILLPN], was introduced to address the MAC flip-flopping problem at remote RBridges. Based on virtual RBridge mechanism, Coordinated Multicast Trees (CMT) solution in [CMT] was introduced to solve the related RPF issues. In this document, additional problems are described regarding virtual Bridges members' state synchronization in multi-homing scenario, including virtual RBridge membership auto discovery, pseudo-nickname static configuration consistency check, dynamic pseudo-nickname allocation, CMT configuration synchronization ,LACP configuration and state synchronization, and node/link failure detection. To address these problems, a communication protocol among members of a virtual RBridge group should be provided. Requirements for this protocol is also discussed. "IMAP $Important Keyword and \Important Special-Use Attribute", Barry Leiba, Eric Iceman, 15-Apr-13, RFC 6154 created an IMAP Special-Use LIST extension and defined an initial set of attributes. This document defines a new attribute, "\Important", and establishes a new IANA registry for IMAP folder attributes, registering the attributes defined in RFCs 3348, 3501, and 6154. This document also defines a new IMAP keyword, "$Important", and registers it in the registry defined in RFC 5788. "SCIM User Scenarios", Kepeng Li, 15-Jan-13, This document lists the user scenarios of System for Cross-domain Identity Management (SCIM). "Email transfer in the IPv6 introduction phase", Martin Rosenau, 16-Jan-13, During the introduction phase of IPv6 (as of Jan 2013) many existing mail servers are not able to do IPv6 communication, yet. However new networks will be assigned IPv6 addresses only so new mail servers will not be able to do IPv4 communication. This document proposes the installation of special servers that are able to route mail between IPv4-only and IPv6-only mail servers to solve this problem. "PLASMA and Redacted Documents", Jim Schaad, 16-Jan-13, Redacted documents are designed to have a single document which allows different individuals to view different portions of the document basd on the attributes of the individual. In this document, a protocol extension to the basic PLASMA protocol is described that allows for multiple keys, each with a different policy, to be used in a single electronic document for enforcement of redaction levels. This document is agnostic relative to the actual format of the redacted document, the only requirement being that the redacted document be able to carry the PLASMA defined lock box. "Unanswered Questions in the Path Computation Element Architecture", Adrian Farrel, Daniel King, 28-Apr-13, The Path Computation Element (PCE) architecture is set out in RFC 4655. The architecture is extended for multi-layer networking with the introduction of the Virtual Network Topology Manager in RFC 5623, and generalized to Hierarchical PCE in RFC 6805. These three architectural views of PCE deliberately leave some key questions unanswered especially with respect to the interactions between architectural components. This document draws out those questions and discusses them in an architectural context with reference to other architectural components, existing protocols, and recent IETF work efforts. This document does not update the architecture documents and does not define how protocols or components must be used. It does, however, suggest how the architectural components might be combined to provide advanced PCE function. "Autonomous Extensible Internet with Network Address Multiplexing(AEIP NAM)", Yuping Diao, Diao Yongping, Ming Liao, 18-Jan-13, The two key issues of today's Internet are autonomy and extensibility. Autonomous Internet(AIP) technology can provide extensible internet architecture, own independent root DNS servers and self management internet network; Furthermore, based on the Autonomous Internet, here provides a way with extensible address capacity to solve IP address deficiency and realize Autonomous Extensible Internet(AEIP) with global network address and multiplexing local network address. This AEIP with Network Address Multiplexing(AEIP NAM) can realize autonomy and extensibility with minimal cost. "Flow Aware Packet Sampling Techniques", ramki, So Ning, 24-Apr-13, The demands on the networking infrastructure and thus the switch/router bandwidths are growing exponentially; the drivers are bandwidth hungry rich media applications, inter data center communications etc. Using sampling techniques, for a given sampling rate, the amount of samples that need to be processed is increasing exponentially. This draft suggests flow aware sampling techniques for handling various scenarios with minimal sampling overhead. "The TPMKEY URI Scheme", Carolin Latze, Nikos Mavrogiannopoulos, 25-Jan-13, This memo specifies a TPMKEY Uniform Resource Identifier (URI) Scheme for identifying cryptographic keys stored in TPM chips and accessed using the TCG Software Stack (TSS). The URI is based on how TPM keys are identified in the TSS specification. "Coupled congestion control for RTP media", Michael Welzl, 19-Jan-13, When multiple congestion controlled RTP sessions traverse the same network bottleneck, it can be beneficial to combine their controls such that the total on-the-wire behavior is improved. This document describes such a method for flows that have the same sender, in a way that is as flexible and simple as possible while minimizing the amount of changes needed to existing RTP applications. "Key Relay Mapping for the Extensible Provisioning Protocol", R. Gieben, M. Groeneweg, Rik Ribbers, Antoin Verschuren, 3-Apr-13, This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the purpose of relaying DNSSEC key material from one DNS operator to another, by using the administrative registration channel through the registrant, registrar and registry. The mapping introduces "" as a new command in EPP. This command will help facilitate changing the DNS operator of a domain while keeping the DNSSEC chain of trust intact. "Writing I-Ds and RFCs using Pandoc", R. Gieben, 10-Apr-13, This document presents a technique for using a Markdown syntax variant, called Pandoc, as a source format for documents in the Internet-Drafts (I-Ds) and Request for Comments (RFC) series. "Available Routing Constructs", Pascal Thubert, Gabor Enyedi, Srinivasan Ramasubramanian, 21-Jan-13, This draft compares the capabilities offered by the Available Routing Construct (ARC) and the Maximally Redundant Trees (MRT) techniques in order to support applicability statements. "ZSS Short Signature Scheme for BN Curves", Laura Hitt, 11-Feb-13, This document describes the ZSS Short Signature Scheme for implementation from bilinear pairings on Barreto-Naerhig (BN) ordinary elliptic curves. The ZSS Short Signature Scheme uses general cryptographic hash functions such as SHA-1 or SHA-2 and is efficient in terms of pairing operations. "VPOLL: Consensus Scheduling Component for iCalendar", Eric York, Cyrus Daboo, Mike Douglass, 22-Jan-13, This specification introduces a new iCalendar component which allows for consensus scheduling, that is voting on a number of alternative meeting or task alternatives. "New Performance Metrics Framework for Multiparty Services", Tiziano Ionta, 23-Jan-13, 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. "Pausing an RTP Media Stream", Roni Even, 24-Jan-13, In Real-time multimedia applications using multiple media streams in point to point and multipoint calls can benefit from options that will enable them to pause and resume media streams as well as to indicate a mute state. This document describes the difference between pause and mute and describes how to provide this required functionality. This document updates RFC5104. "A mechanism to allocate IPv6 blocks for BGP networks based on the networks AS Number", Martin Levy, Matthew Pounsett, 24-Jan-13, This document provides a methodology for automatically allocating IPv6 [RFC2460] address blocks for networks that run BGP [RFC4271] and are either single-homed or multi-homed [BARBER2011]. The automatic allocation is taken from a specific /16 block assigned by IANA for this purpose. Networks that require more than this single /48 can still request additional allocations via the existing RIR process. Networks are not forced to use this allocation and can ignore this completely. Availability of the /48 assignment via this mechanism does not change existing mechanisms for obtaining IPv6 assignments through the existing RIR (Regional Internet Registry) or LIR (Local Internet Registry) mechanisms. There is an implicit assumption that it's a good thing to promote networks to enable IPv6 with a near-zero effort. "Objectclass property for vCard", Ciny Joy, Cyrus Daboo, Mike Douglass, 24-Jan-13, This specification describes a new property for vCard Format Specification [RFC6350] to allow the specification of objectclasses. "Schedulable Objectclass for vCard", Ciny Joy, Cyrus Daboo, Mike Douglass, 24-Jan-13, This specification describes a new property objectclass value for the vcard objectclass property defined in [REF] allowing schedulable entities to be marked as such. "Hybrid Unicast/Multicast DNS-Based Service Discovery", Stuart Cheshire, 26-Jan-13, Performing DNS-Based Service Discovery using purely Multicast DNS allows discovery only of services present on the local link. Using a very large local link with thousands of hosts improves service discovery, but at the cost of large amounts of multicast traffic. Performing DNS-Based Service Discovery using purely Unicast DNS is more efficient, but requires configuration of DNS Update keys on the devices offering the services, which can be onerous for simple devices like printers and network cameras. Hence a compromise is needed, that provides easy service discovery without requiring either large amounts of multicast traffic or onerous configuration. "Registration Data Access Protocol Search Processing", Scott Hollenbeck, Andrew Newton, 15-Feb-13, This document describes path segments and query parameters needed to construct HTTP URLs that may be used to search for and retrieve registration information from registries (including both Regional Internet Registries (RIRs) and Domain Name Registries (DNRs)) using "RESTful" web access patterns. It also describes a method of encoding responses using Javascript Object Notation (JSON). "Asymmetric OSPF Hold Timer", Madhukar Anand, Hasmit Grover, Abhay Roy, 25-Jan-13, Current OSPF standard requires that the HELLO/Dead interval be symmetric on either side of the link in order to maintain adjacency. There are many scenarios in which this may not be desirable. This memo describes a technique to allow OSPF adjacency to be maintained with asymmetric values of the OSPF Dead interval. "Selection of Future Cryptographic Standards", David McGrew, Anthony Grieco, Yaron Sheffer, 25-Jan-13, The Advanced Encryption Standard (AES) is extensively used and is widely believed to provide security that is more than adequate. Several other cipher designs have been proposed for use in standards, and new designs continue to be developed, while consideration of cost and complexity impels that the number of mandatory-to-implement ciphers be minimized. This note outlines an approach to the selection of cryptographic algorithms that best serves the needs of the users of cryptography: AES should continue in its role as the mandatory-to-implement cipher, while other cipher designs should be reviewed with the goal of selecting a single standby cipher. If future advances in the science of cryptanalysis uncover security issues with the AES, the standby cipher will be ready for adoption as its replacement. "Reducing Power Consumption using BGP with power source data", Shankar Raman, Balaji Venkat, Gaurav Raina, Kamakoti Veezhinathan, 25-Jan-13, 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 consumed-power-to-available-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. The addition to this draft is that the power source of the Autonomous system is broken down to a ratio called PWR- SOURCE Ratio and used in the arrival of the metric to be used for this purpose. "The Use of MPLS Special Purpose Labels for the Computation of Load Balancing", Carlos Pignataro, Loa Andersson, Kireeti Kompella, 16-Feb-13, In addition to being used for forwarding, an MPLS label stack may also be used as an entropy source to perform load balancing computation in various ways. RFC 4928 and RFC 6790 describe this mechanism in great detail. However, those two RFCs differ in the use of MPLS special purpose labels (previously referred to as "reserved labels") for computation of load balancing. This document addresses this difference in specifications by providing a more comprehensive set of recommendations. This document updates RFC 4928 and RFC 6790. "Balanced Security for IPv6 CPE", Martin Gysi, Guillaume Leclanche, Eric Vyncke, Ragnar Anfinsen, 25-Jan-13, This document describes how an IPv6 residential Customer Premise Equipment (CPE) can have a balanced security policy that allows for a mostly end-to-end connectivity while keeping the major threats outside of the home. It is based on an actual IPv6 deployment by Swisscom and proposes to allow all packets inbound/outbound EXCEPT for some layer-4 ports where attacks and vulnerabilities (such as weak passwords) are well-known. "Binding Obligations on User-Managed Access (UMA) Participants", Eve Maler, Thomas Hardjono, 26-Jan-13, User-Managed Access (UMA) is a profile of OAuth 2.0. UMA defines how resource owners can control protected-resource access by clients operated by arbitrary requesting parties, where the resources reside on any number of resource servers, and where a centralized authorization server governs access based on resource owner policy. This document provides a contractual framework that defines the minimum obligations of parties that operate and use UMA-conforming software programs and services. The goal of this framework is to support end-to-end legal enforceability of the terms and conditions of access sharing relationships between authorizing and requesting sides that use UMA. The audience for this document includes technologists, legal professionals, and operators of UMA-conforming services. "Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol", Emil Ivov, Eric Rescorla, Justin Uberti, 11-Mar-13, This document describes an extension to the Interactive Connectivity Establishment (ICE) protocol that allows ICE agents to send and receive candidates incrementally rather than exchanging complete lists. With such incremental provisioning, ICE agents can begin connectivity checks while they are still gathering candidates and considerably shorten the time necessary for ICE processing to complete. The above mechanism is also referred to as "trickle ICE". "On Consensus and Humming in the IETF", Pete Resnick, 18-Mar-13, The IETF has had a long tradition of doing its technical work through a consensus process, taking into account the different views among IETF participants and coming to (at least rough) consensus on technical matters. In particular, the IETF is supposed not to be run by a "majority rules" philosophy. This is why we engage in rituals like "humming" instead of voting. However, more and more of our actions are now indistinguishable from voting, and quite often we are letting the majority win the day, without consideration of minority concerns. This document is a collection of thoughts on what rough consensus is, how we have gotten away from it, and the things we can do in order to really achieve rough consensus. Note: This document contains the musings of an individual. Right now, it is just some rough notes and has lots of holes that need to be filled in. Even if those holes are filled, in its current form, it is not intended to be published as an RFC, let alone being a BCP for a change of IETF policy. If it evolves into such a thing, great. If it simply sparks discussion as an Internet Draft, that's a perfectly fine outcome. "IGP Extensions for Stateful PCE Discovery", Siva Sivabalan, Jan Medved, Xian Zhang, 2-Apr-13, When a PCE is a Label Switching Router (LSR) participating in the Interior Gateway Protocol (IGP), or even a server participating in IGP, its presence and path computation capabilities can be advertised using IGP flooding. Such IGP extensions exist for OSPF and ISIS. This document specifies two new PCE capabilities advertised by IGP. "Lightweight Directory Access Protocol (LDAP): Hashed Attribute values for 'userPassword'", Michael Stroeder, 13-Mar-13, This document describes the widely used syntax for storing hashed passwords in LDAP attribute 'userPassword'. Furthermore it points out some of the deficiencies of the approach. Its purpose is solely to document current practice, it does not define a new standard. "DNS Service Discovery options in DHCP", Stephen Orr, Cisco Systems, Tirumaleswar Reddy, Prashanth Patil, 29-Jan-13, This document specifies DHCPv4 and DHCPv6 options to deliver Service Discovery Domains required for DNS based service registration and discovery. "A Session Initiation Protocol (SIP) usage for Trickle ICE", Emil Ivov, Enrico Marocco, Christer Holmberg, 30-Jan-13, The Interactive Connectivity Establishment (ICE) protocol describes a Network Address Translator (NAT) traversal for UDP-based multimedia sessions established with the offer/answer model. The ICE extension for Incremental Provisioning of Candidates (Trickle ICE) defines a mechanism that allows ICE agents to shorten session establishment delays by making the candidate gathering and connectivity checking phases of ICE non-blocking. This document defines usage semantics for Trickle ICE with SIP. "Path Computation Element Communication Protocol (PCEP) Extensions for remote-initiated GMPLS LSP Setup", Zafar Ali, Siva Sivabalan, Clarence Filsfils, Robert Varga, Victor Lopez, Oscar de Dios, 31-Jan-13, PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model draft [I-D. draft-crabbe-pce-pce-initiated-lsp] specifies procedures that can be used for creation and deletion of PCE- initiated LSPs under the active stateful PCE model. However, this specification is focused on MPLS networks, and does not cover remote instantiation of GMPLS paths. This document complements PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model draft by addressing the extensions required for GMPLS applications, for example for OTN and WSON networks. When active stateful PCE is used for managing PCE-initiated LSP, PCC may not be aware of the intended usage of the LSP (e.g., in a multi-layer network). PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model draft does not address this requirement. This draft also addresses the requirement to specify on how PCC should use the PCEP initiated LSPs. "Data Types in the Remote Authentication Dial-In User Service Protocol (RADIUS)", Alan DeKok, 12-Feb-13, RADIUS specifications have used data types for two decades, without rigorously defining them as managed entities. During this time, RADIUS implementations have named the data types, and have used them to as managed entities in attribute definitions. This document updates the specifications to match established prctice. We do this by naming data types defined in [RFC6158], which have been used since at least [RFC2865]. We provide an IANA registry for the data types, and update the RADIUS Attribute Type registry to include a "data type" field for each attribute. Finally, we recommend that authors of RADIUS specifications use these types in preference to existing practice. "JSON Schema: interactive and non interactive validation", Kris Zyp, Gary Court, 31-Jan-13, JSON Schema (application/schema+json) has several purposes, one of which is instance validation. The validation process may be interactive or non interactive. For instance, applications may use JSON Schema to build a user interface enabling interactive content generation in addition to user input checking, or validate data retrieved from various sources. This specification describes schema keywords dedicated to validation purposes. "Report from the IAB/IRTF Workshop on Congestion Control for Interactive Real-Time Communication", Hannes Tschofenig, Lars Eggert, Zaheduzzaman Sarker, 2-Apr-13, This document provides a summary of the IAB/IRTF Workshop on 'Congestion Control for Interactive Real-Time Communication', which took place in Vancouver, Canada, on July 28, 2012. The main goal of the workshop was to foster a discussion on congestion control mechanisms for interactive real-time communication. This report summarizes the discussions and lists recommendations to the Internet Engineering Task Force (IETF) community. The views and positions in this report are those of the workshop participants and do not necessarily reflect the views and positions of the authors, the Internet Architecture Board (IAB) or the Internet Research Task Force (IRTF). "The "action" Link Relation", Ioseb Dzmanashvili, 31-Jan-13, RFC 5988 [RFC5988] defined the way of indicating resources on the Web. This specification defines link relation type that may be used to express the relationships between a resource and associated actions that may be performed against context resource. Editorial Note (To be removed by RFC Editor) Distribution of this document is unlimited. Comments should be sent to the IETF Apps-Discuss mailing list (see ). "CLUE Signaling", Paul Kyzivat, Lennard Xiao, Christian Groves, 18-Feb-13, This document specifies how signaling is conducted in the course of CLUE sessions. This includes how SIP/SDP signaling is applied to CLUE sessions as well as defining a CLUE-specific signaling protocol that complements SIP/SDP and supports negotiation of CLUE application level data. "JSON Hyper-Schema: Hypertext definitions for JSON Schema", Geraint Luff, Kris Zyp, Gary Court, 31-Jan-13, JSON Schema is a JSON based format for defining the structure of JSON data. This document specifies hyperlink- and hypermedia-related keywords of JSON Schema. "Forward Error Correction for WebRTC using FEC FRAME", Giridhar Mandyam, Mike Luby, Thomas Stockhammer, Christian Foisy, 31-Jan-13, WebRTC provides a solution for peer-to-peer streaming between web applications by leveraging a Real-Time Protocol (RTP) stream between two clients. This RTP stream is expected to be sent over an UDP (Universal Datagram Protocol) connection, which by definition has no built-in reliability. Recently the FEC FRAME Working Group of the IETF has come up with a framework and technical recommendations for applying forward error correction (FEC) to unreliable streams. This framework can be applied to WebRTC with minimal changes to the specification. "A Reference Path and Measurement Points for LMAP", Marcelo Bagnulo, Trevor Burbridge, Sam Crawford, Philip Eardley, Al Morton, 25-Feb-13, This document defines a reference path for Large-scale Measurement of Broadband Access Performance (LMAP) and measurement points for commonly used performance metrics. "Thoughts on syntax for representing multiple media streams", Adam Roach, 31-Jan-13, This document briefly explores the ramifications of combining multiple media streams into one SDP m= section versus expressing each in its own m= section. "Multi-Media Concepts and Relations", BoB, Magnus Westerlund, 1-Feb-13, There are currently significant efforts ongoing in IETF regarding more advanced multi-media functionalities, such as the work related to RTCWEB and CLUE. This work includes use cases for both multi- party communication and multiple media streams from an individual end-point. The usage of scalable encoding or simulcast encoding as well as different types of transport mechanisms have created additional needs to correctly identify different types of resources and describe their relations to achieve intended functionalities. The different usages have both commonalities and differences in needs and behavior. This document attempts to review some usages and identify commonalities and needs. It then continues to highlight important aspects that need to be considered in the definition of these usages. "IPv6 IPID Needed", Nalini Elkins, Lawrence Kratzke, Michael Ackermann, Keven Haining, 1-Feb-13, The IPv4 main header contained a 16-bit IP Identification (IPID) field used for fragmentation and reassembly. In practice, this field was commonly used by network diagnosticians for tracking packets. In IPv6, the IPID has been moved to the Fragment header, and would only be used when fragmentation is required. Thus, the IPID field in IPv6, is no longer able to be utilized in the valuable role it played in IPv4, relative to diagnostics and problem resolution. This causes great concern in particular for end users and large enterprises, for whom Network/Application availability and performance can directly and profoundly affect bottom line financials. Several viable solutions to this situation exist. One potential solution is included in later sections of this RFC, but the primary intention of this RFC is to initiate action by the IETF on this issue, perhaps in the form of a Working Group Subcommittee. "IPv6 IPID Needed", Nalini Elkins, Lawrence Kratzke, Michael Ackermann, Keven Haining, 14-Apr-13, The IPv4 main header contained a 16-bit IP Identification (IPID) field used for fragmentation and reassembly. In practice, this field was commonly used by network diagnosticians for tracking packets. In IPv6, the IPID has been moved to the Fragment header, and would only be used when fragmentation is required. Thus, the IPID field in IPv6, is no longer able to be utilized in the valuable role it played in IPv4, relative to diagnostics and problem resolution. This causes great concern in particular for end users and large enterprises, for whom Network/Application availability and performance can directly and profoundly affect bottom line financials. Several viable solutions to this situation exist. "Using JavaScript Object Notation (JSON) Web Encryption (JWE) for Protecting JSON Web Key (JWK) Objects", m&m, 21-Feb-13, This document specifies an approach to protecting a private key formatted as a JavaScript Syntax Object Notation (JSON) Web Key (JWK) object using JSON Web Encryption (JWE). This document also specifies a set of algorithms for protecting such content using password-based cryptography. "An argument for encoding multiple media sources per m= section of SDP.", Peter Thatcher, Justin Uberti, 3-Feb-13, This document explains why it is preferable to have multiple media sources encoded in SDP as one m= section rather than many m= sections, especially when there are a large number of video sources which change frequently and need dynamic resolution changes, such as in a video conferencing system. "Describing multiple RTP media streams in SDP", Roni Even, Jonathan Lennox, Qin Wu, 17-Feb-13, This document describes issues when describing multiple RTP streams in a single RTP session using SDP and considers the different RTP topologies that should be supported. The document looks at current solutions and provides paths toward addressing the issues. "Operational Issues Associated With Long IPv6 Extension Header Chains", Warren Kumari, Joel Jaeggli, Ronald Bonica, 4-Feb-13, This document outlines a set of issues with the use of long IPv6 extension header chains. It considers their use in the context of today's IPv6 Internet and potential interaction with forwarding devices that require upper-layer headers. "Candidate Technologies for COMAN", Bert Greevenbosch, Kepeng Li, Peter Van der Stok, 24-May-13, This draft identifies candidate technologies and considerations for the COMAN use cases and requirements. Note Discussion and suggestions for improvement are requested, and should be sent to coman@ietf.org. "IPv4-IPv6 multicast address conversion", Yalin Cao, Cui Wang, Wei Meng, Bhumip Khasnabish, 21-Feb-13, This draft describes a mechanism for stateless conversion of IPv4 multicast address to IPv6 multicast address and vice versa,using different rules. These rules can be used in both IPv4-IPv6 translation or encapsulation. This solution can be used in any scenarios describe in [RFC6144]. "Hierarchical Join/Prune Attributes", Stig Venaas, Isidor Kouvelas, Jesus Arango, 6-Feb-13, This document defines a hierachical method of encoding Join attributes, providing a more efficient encoding when the same attribute values need to be specified for multiple sources in a PIM Join/Prune message. "Interconnecting IPv6 Multicast Islands over IPv4 Using IPv6 Multicast Provider Edge Routers", Cui Wang, Wei Meng, Bhumip Khasnabish, Jie Hu, 6-Feb-13, This draft presents a method to interconnect IPv6 multicast islands over an IPv4 cloud. This method relies on IPv6 Multicast Provider Edge routers (6MPE), which support Dual-Stack in order to connect to IPv6 multicast islands and to the IPv4 core. The 6MPE routers extend the Multiprotocol Border Gateway Protocol(MP-BGP), exchange the IPv6 multicast reachability information transparently over the IPv4 core using the MP-BGP. "PCP Anycast Address", Stuart Cheshire, 11-Mar-13, The Port Control Protocol Anycast Address enables PCP clients to transmit messages to their closest on-path NAT, Firewall, or other middlebox, without having to learn the IP address of that middlebox via some external channel. "Early IANA Allocation of Standards Track Code Points", Michelle Cotton, 7-Feb-13, This memo describes the process for early allocation of code points by IANA from registries for which "Specification Required", "RFC Required", "IETF Review", or "Standards Action" policies apply. This process can be used to alleviate the problem where code point allocation is needed to facilitate desired or required implementation and deployment experience prior to publication of an RFC that would normally trigger code point allocation. This document obsoletes RFC 4020. "A Session Initiation Protocol (SIP) usage for Trickle ICE", Emil Ivov, Enrico Marocco, Christer Holmberg, 7-Feb-13, The Interactive Connectivity Establishment (ICE) protocol describes a Network Address Translator (NAT) traversal for UDP-based multimedia sessions established with the offer/answer model. The ICE extension for Incremental Provisioning of Candidates (Trickle ICE) defines a mechanism that allows ICE agents to shorten session establishment delays by making the candidate gathering and connectivity checking phases of ICE non-blocking. This document defines usage semantics for Trickle ICE with SIP. "Length Hiding Padding for the Transport Layer Security Protocol", Alfredo Pironti, Nikos Mavrogiannopoulos, 7-Feb-13, This memo proposes length hiding methods of operation for the TLS protocol. It defines a TLS extension to allow arbitrary amount of padding in any TLS ciphersuite, and it presents guidelines and a reference implementation of record fragmentation and padding so that the length of the exchanged messages is effectively concealed within a given range of lengths. The latter guidelines also apply to the standard TLS padding allowed by the TLS block ciphers. "An LMAP application for IPFIX", Marcelo Bagnulo, Brian Trammell, 21-Feb-13, This document explores the possibility of using IPFIX to report test results from a Measurement Agent to a Collector, in the context of a large measurement platform. "Plan to Establish a Wisdom Task Force", Norbert Bollow, 16-May-13, This memo calls for the creation of a new governance forum named "Wisdom Task Force" (WisdomTF). The main purpose of the WisdomTF is to facilitate consensus-seeking strategy-oriented discussions regarding governance actions that may be decided by national parliaments. "Transmission of IPv6 packets over ITU-T G.9959 Networks", Anders Brandt, Jakob Buron, 23-Apr-13, This document describes the frame format for transmission of IPv6 packets and a method of forming IPv6 link-local addresses and statelessly autoconfigured IPv6 addresses on ITU-T G.9959 networks. "Encrypt-then-MAC for TLS and DTLS", Peter Gutmann, 18-Apr-13, This document describes a means of negotiating the use of the encrypt-then-MAC security mechanism in place of TLS'/DTLS' existing MAC-then-encrypt one, which has been the subject of a number of security vulnerabilities over a period of many years. "Normalization Marker for AF PHB Group in DiffServ", Cheng-Jia Lai, Wenyi Wang, Stan Yang, Toerless Eckert, Fred Yip, 8-Feb-13, This memo describes a Normalization Marker (NM) at DiffServ (DS) nodes to normalize the distribution of DS codepoint (DSCP) markings for an Assured Forwarding (AF) Per-Hop Behavior (PHB) group. NM is useful for traffic conditioning with Active Queue Management (AQM) when the AF PHB group is deployed for multimedia service classes that carry video packets with advanced codec technologies. Using NM can offer an incentive that is however missing in today's ecosystem of practical deployment, i.e., when congestion occurs in the AF PHB group, the network should allow a video codec to benefit from its effort of generating finer layers of intra-flow precedence (IFP) with discardable packets in a more balanced distribution. "Updates to PSC", Eric Osborne, 8-Feb-13, This document contains four updates to RFC6378, "MPLS Transport Profile (MPLS-TP) Linear Protection". Two of them correct existing behavior. The third clears up a behavior which was not explained in the RFC, and the fourth adds rules around handling capabilities mismatches. "TWAMP Flow-based Performance Measurement", Lishun Sun, Fang Yu, Xiangyang Gong, 8-Feb-13, This memo describes an extension to the Two-Way Active Measurement Protocol (TWAMP). Through carrying the information of business flow, it can measure the online performance without bringing effect to application significantly. "Using IEEE802.15.4e TSCH in an LLN context: Overview, Problem Statement and Goals", Thomas Watteyne, Maria Palattella, Luigi Grieco, 23-May-13, This document describes the environment, problem statement, and goals for using the IEEE802.15.4e TSCH MAC protocol in the context of LLNs. The set of goals enumerated in this document form an initial set only. "Recursive PCP", Stuart Cheshire, 10-Mar-13, The Port Control Protocol (PCP) allows clients to request explicit dynamic inbound and outbound port mappings in their closest on-path NAT, firewall, or other middlebox. However, in today's world, there may be more than one NAT on the path between a client and the public Internet. This document describes how the closest on-path middlebox generates a corresponding upstream PCP request to the next closest on-path middlebox, to request an appropriate explicit dynamic port mapping in that middlebox too. Applied recursively, this generates the necessary chain of port mappings in any number of middleboxes on the path between the client and the public Internet. "RADIUS Extended Request", Peter Deacon, 1-May-13, This document describes methods for RADIUS servers to communicate optional extended abilities to RADIUS clients. The abilities described provide for exchange of RADIUS packets where total packet length exceeds 4096 bytes. "IS-IS Flooding Scope LSPs", Les Ginsberg, Stefano Previdi, Yi Yang, 9-Feb-13, Intermediate System To Intermediate System (IS-IS) provides efficient and reliable flooding of information to its peers. However the current flooding scopes are limited to either area wide scope or domain wide scope. There are existing use cases where support of other flooding scopes are desirable. This document defines new Protocol Data Units (PDUs) which provide support for new flooding scopes as well as additional space for advertising information targeted for the currently supported flooding scopes. The protocol extensions defined in this document are not backwards compatible with existing implementations and so must be deployed with care. "A Generic Bundle Mechanism for the Session Description Protocol (SDP)", Dale Worley, 15-Mar-13, This document defines a generic bundle mechanism for the Session Description Protocol (SDP) by which the media described by a number of media descriptions ("m= lines") are multiplexed and transmitted over a single transport association. The single transport association is described by an additional media description, allowing SDP attributes to be applied to the aggregate, independently of attributes applied to the constituents. In offer/answer usage, the bundle mechanism is backward compatible with SDP processors that do not understand the mechanism. The mechanism is designed to be compatible with the limitations of the existing Internet infrastructure. "ICN Research Challenges", Dirk Kutscher, Suyong Eum, Kostas Pentikousis, Ioannis Psaras, Daniel Corujo, Damien Saucez, 10-Feb-13, This memo describes research challenges for Information-Centric Networking. Information-centric networking is an approach to evolve the Internet infrastructure to directly support this use by introducing uniquely named data as a core Internet principle. Data becomes independent from location, application, storage, and means of transportation, enabling in-network caching and replication. Challenges include naming, security, routing, system scalability, mobility management, wireless networking, transport services, in- network caching, and network management. "Security Automation and Continuous Monitoring (SACM) Architecture", David Waltermire, 10-Feb-13, This document identifies the architectural components, data flows, and the supporting standards needed to define an interoperable automation infrastructure required to support timely, accurate and actionable situational awareness over an organization's IT systems. This architecture is based on previous use case and requirements analysis. Automation tools implementing the continuous monitoring approach described in this document will utilize this infrastructure together with existing and emerging event, incident and network management standards to provide visibility into the state of assets, user activities and network behavior. Stakeholders will be able to use these tools to aggregate and analyze relevant security and operational data to understand the organizations security posture, quantify business risk, and make informed decisions that support organizational objectives while protecting critical information. Organizations will be able to use these tools to augment and automate information sharing activities to collaborate with partners to identify and mitigate threats. Other automation tools will be able to integrate with these capabilities to enforce policies based on human decisions to harden systems, prevent misuse and reduce the overall attack surface. "User Defined Key Pair", Omar Omran, 11-Feb-13, In this document I am providing the outlines for a modified version of the Transport Layer Security Protocol (TLS); the modified version will come as a new protocol that will build a secured tunnel between the client and the server without the need to involve Certificate Authorities or any other third party in this process; it is called User Defined Key Pair protocol(UDKP), and is based on the assumption that in most cases there is a registered profile for the user on the server; a profile that includes among a lot of things the username and the password that the user uses to authenticate to the server, the proposed protocol will make use of the username and the password to create a key pair for the user on the fly at the client side, and it will use this key pair as the starting point for creating the secured tunnel instead of taking the server certificate as the starting point. Additionally the proposed protocol has self- protection against phishing attacks. "Updates to PSC", Eric Osborne, 19-Mar-13, This document contains four updates to RFC6378, "MPLS Transport Profile (MPLS-TP) Linear Protection". Two of them correct existing behavior. The third clears up a behavior which was not explained in the RFC, and the fourth adds rules around handling capabilities mismatches. "Resource Priority Header (RPH) Registry Management Policy to IETF Review", Brian Rosen, 11-Feb-13, RFC4412 defines "Resource-Priority Namespaces" and "Resource-Priority Priority-values" registries. The management policy of these registries is "Standards Action". This document changes the management policy of these registries to "IETF Review". "RPKI Repository Analysis and Requirements", Tim Bruijnzeels, Oleg Muravskiy, Bryan Weber, 11-Feb-13, The current RPKI Resource Certificate Repository Structure (RFC6480 & RFC6481) uses rsync as both a delta and transfer protocol. Concerns have been raised about the scalability of this repository and the reliance on rsync. This document provides an analysis of these concerns and formulates requirements for future work. "Channel Binding Signalling for the Generic Security Services Application Programming Interface", Nico Williams, 22-Feb-13, This Internet-Draft proposes the addition of a "channel bound" return flag for the GSS_Init_sec_context() and GSS_Accept_sec_context() functions. Two behaviors are specified: a default, safe behavior, and a behavior that is only safe when the application specifically tells the Generic Security Services Application Programming Interface (GSS-API) that it (the applicaiton) supports the new behavior. "Third-Party ALTO Server Discovery Prototype Implementation and Testbed", Sebastian Kiesel, 12-Feb-13, This document contains a prototype implementation for the third-party ALTO server discovery (3pdisc) procedure specified in draft-kist-alto-3pdisc-02.txt [I-D.kist-alto-3pdisc]. The prototype implementation has been written in Perl and tested with the GNU/Linux operating system. A set of BIND 9 configuration files and DNS zone files is also included. They can be used for setting up a small, self-contained testbed. "JavaScript Object Notation (JSON) Web Key (JWK) for Public Key Infrastructure (X.509) (PKIX) Certificates", m&m, Brian Campbell, 21-Feb-13, This document defines a JavaScript Object Notation (JSON) Web Key (JWK) object to wrap Public Key Infrastructure (X.509) (PKIX) certificate chains, to allow for some interoperability between existing PKIX-based systems and newer JOSE-based systems. "Authentication Context Certificate Extension", Stefan Santesson, 11-Mar-13, This document defines an extension to certificates according to [RFC5280]. The extension defined in this document holds data about how the certificate subject was authenticated by the Certification Authority who issued the certificate where this extension appears. This document also defines one data structure for inclusion in this extension that designed to hold information when the subject is authenticated using a SAML assertion [SAML]. "BGP Tunnel Encapsulation Attribute for UDP", KuiKe Building, Zhenbin Li, Nischal Sheth, Yiu Lee, Fan Yongbing, 12-Feb-13, This document specifies a new Border Gateway Protocol (BGP) Tunnel Type of User Datagram Protocol (UDP) tunnels. "Generic UDP Encapsulation for IP Tunneling", Lucy Yong, KuiKe Building, 25-Feb-13, This document describes a method for encapsulating the layer protocols within UDP at an IP network edge such that the payload protocol can be identified from the destination port value. The mechanism also allows for the source port to be used as the entropy field for the purpose of load balancing in environments such as Equal Cost Multipath (ECMP) in the underlying IP network. Application of this technique is focused on tunneling payload network flows across IP networks in environments where load- balancing is required. No changes to the underlying IP network or the payload networks are required. "DECADE Architecture and Protocol", Richard Alimi, Akbar Rahman, Dirk Kutscher, Yang Yang, Haibin Song, Kostas Pentikousis, 13-Feb-13, 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 provided by a DECADE (DECoupled Application Data Enroute) compatible system. This document presents an architecture, discusses the underlying principles, and identifies key functionalities in the architecture for introducing a DECADE in- network storage system. In addition, some examples are given to illustrate these concepts. "Overlay Network - Path Computation Approaches", Snigdho Bardalai, Khuzema Pithewan, Rajan Rao, 13-Feb-13, This document discusses various path computations approaches which are applicable to overlay networks [framework doc ref]. It discusses how the customer edge nodes uses the information advertised by the provider network to compute a path between two customer edge nodes or how it can request the provider network to compute a path and setup an end-2-end LSP. "PCP Flow Examples", Mohamed Boucadair, 13-Feb-13, This document provides a set of examples to illustrate PCP operations. It is a companion document to the base PCP specification. "Supporting the Exercise command for PSC linear protection protocol", Alessandro D'Alessandro, Jeong-dong Ryoo, Huub van Helvoort, 27-Mar-13, This draft indicates how IETF RFC6378 could be modified to address the Exercise function. "Requirements from various WG for MMUSIC", Cullen Jennings, Justin Uberti, Eric Rescorla, 13-Feb-13, This document outlines some of the requirements driving various consideration related to multiplexing in the MMUSIC working group to meet the needs of WebRTC, CLUE, and other working groups. This document is only meant to be used to help drive the discussion of solutions and is not intended to become an RFC. "jCard: The JSON format for vCard", Philipp Kewisch, 18-Mar-13, This specification defines "jCard", a JSON format for vCard data. "Extended Administrative Groups in MPLS-TE", Eric Osborne, 13-Feb-13, This document provides additional administrative groups (sometimes referred to as "link colors") to the IGP extensions for MPLS-TE. "Extended Administrative Groups in MPLS-TE", Eric Osborne, 13-May-13, This document provides additional administrative groups (sometimes referred to as "link colors") to the IGP extensions for MPLS-TE. "PCP Authentication Requirements", Tirumaleswar Reddy, Prashanth Patil, Dan Wing, Reinaldo Penno, 16-May-13, In an attempt to reach consensus on a PCP authentication mechanism, this document describes requirements for PCP authentication. It is hoped this can serve as the basis for a comparison of PCP authentication mechanisms. "Mobility Anchor Selection in DMM: Use-case Scenarios", Hassan Ali-Ahmad, Danny Moses, Hassnaa Moustafa, Pierrick Seite, 14-Feb-13, This document presents and discusses different use-case scenarios of mobility anchor selection in Distributed Mobility Management (DMM). "Topology API Use Cases", Shane Amante, Jan Medved, Stefano Previdi, Thomas Nadeau, 14-Feb-13, This document describes use cases for gathering routing, forwarding and policy information, (hereafter referred to as topology information), about the network. It describes several applications that need to view the topology of the underlying physical or logical network. This document further demonstrates a need for a "Topology Manager" and related functions that collects topology data from network elements and other data sources, coalesces the collected data into a coherent view of the overall network topology, and normalizes the network topology view for use by clients -- namely, applications that consume topology information. "GOST R 34.11-2012: Hash Function", Vasily Dolmatov, Alexey Degtyarev, 3-May-13, This document is intended to be a source of information about the Russian Federal standard hash function (GOST R 34.11-2012), which is one of the Russian cryptographic standard algorithms (called GOST algorithms). "IANA Guidance for Managing the ULE Registry", Gorry Fairhurst, 10-May-13, This document proposes an update to RFC 4326 to clarify and update the allocation rules for the Unidirectional Lightweight Encapsulation (ULE) next header registry. This registry is used by ULE and Generic Stream Encapsulation (GSE) to record the codepoints of extension headers and protocols supported by these encapsulation protocols. "IKEv2 Security Gateway Discovery", Daniel Migault, Kostas Pentikousis, 14-Feb-13, Modern Virtual Private Network (VPN) services are typically deployed using several security gateways and are frequently accessed over a wireless network. There are several reasons for such a deployment ranging from enhancing system resilience to improving performance. For example, in order to handle traffic efficiently and reduce the burden in the core network, the VPN service may be implemented in a distributed manner using multiple Security Gateways. A mobile VPN End User is attached to one of them using a WLAN interface and over time is likely to change its Security Gateway of attachment. In this case, in order to optimize the overall user Quality of Experience (QoE), a VPN End User should select the next most appropriate Security Gateway based on the characteristics of the available Security Gateways. This draft specifies how a VPN End User can securely collect information about Security Gateways in its network neighborhood in order to optimize its VPN experience. "The Virtual Private Network (VPN) Service in ALTO: Use Cases, Requirements and Extensions", Michael Scharf, Vijay Gurbani, Greg Soprovich, Volker Hilt, 14-Feb-13, 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 resources from a candidate set. This document provides motivation for using ALTO in a Virtual Private Network (VPN) environment. We discuss use cases, requirements, and possible extensions to the base ALTO protocol that will be needed to support VPN services. "Negotiation of Extra Round Trip for Kerberos V5 Generic Security Services Mechanism", Nico Williams, Roland Dowdeswell, 15-Feb-13, This Internet-Draft proposes an extension to the Kerberos V5 security mechanism for the Generic Security Services Application Programming Interface (GSS-API) for using an extra pair of security context tokens in order to recover from certain errors. Other benefits include: user2user authentication, authenticated errors (in some cases), and more. "Reporting Equivalent IPFIX Information Elements", Paul Aitken, 15-Feb-13, This document proposes a method for IPFIX Exporting Processes to inform Collecting Processes of equivalent Information Elements, so that the Collecting Process can understand the equivalence and be enabled to process data across a change of Information Elements. "IS-IS Support for Unidirectional Links", Les Ginsberg, Sina Mirtorabi, Stefano Previdi, Abhay Roy, 15-Feb-13, This document defines support for the operation of IS-IS over Unidirectional Links without the use of tunnels or encapsulation of IS-IS Protocol Data Units. Adjacency establishment when the return path from the router at the receive end of a unidirectional link to the router at the transmit end of the unidirectional link is via another unidirectional link is supported. The extensions defined here are backwards compatible - only the routers directly connected to a unidirectional link need to be upgraded. "URN For Country Specific Emergency Services", Christer Holmberg, Ivo Sedlacek, 19-Mar-13, This document updates section 4.2 of RFC 5031, in order to allow the registration of service URNs with the 'sos' service type for emergency services that, at the time of registration, are offered in one country only. "Microloop prevention by introducting a local convergence delay", Stephane Litkowski, Bruno Decraene, Pierre Francois, 15-Feb-13, This document describes a mechanism for link-state routing protocols to prevent a subset of transient loops during topology changes. It introduces a two-step convergence by introducing a delay between the network wide convergence and the node advertising the failure. As the network wide convergence is delayed in case of down events, this mechanism can be used for planned maintenance or for unplanned outage provided a fast reroute mechanism is used in conjunction to convert a failure into a less urgent topology change. Simulation using real network topologies and costs, with pathological convergence behaviour, have been performed. While the proposed mechanism does not provide a complete solution, it is simple and it solves an interesting fraction of the transient loops in the analyzed SP topologies. "IKEv2 Alternate Outer IP Address Extension", Daniel Migault, 15-Feb-13, Current IKEv2 protocol has been designed to establish VPNs with the same outer IP addresses as those used for the IKEv2 channel. This describes the alternate outer IP address extension, and IKEv2 extension that enables the VPN End User to negotiate a VPN on different interfaces as those used for the IKEv2 channel. Thus, this extension makes possible a VPN End User with multiple interfaces to set an IPsec tunnel on each interface with a Security Gateway by using a single IKEv2 channel instead of using an IKEv2 channel per interface. Similarly, for distributed Security Gateways, it also makes possible to split the IKEv2 and IPsec traffic on different interfaces. "The WebSocket Protocol as a Transport for the Binary Floor Control Protocol (BFCP)", Victor Pascual, Robert Welbourn, Stephane Cazeaux, 15-Feb-13, The WebSocket protocol enables two-way realtime communication between clients and servers. This document specifies a new WebSocket sub- protocol as a reliable transport mechanism between Binary Floor Control Protocol (BFCP) entities to enable usage of BFCP in new scenarios. This document normatively updates [I-D.draft-ietf-bfcpbis-rfc4582bis] and [I-D.draft-ietf-bfcpbis-rfc4583bis] "Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Translation ("IGMP/MLD Translation")", Simon Perreault, Tina Tsou, 15-Feb-13, This document describes translation between IGMP and MLD. This allows single-stack multicast 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. "A Comparison of IPv6 over IPv4 Tunnel Mechanisms", S.J.M. Steffann, Iljitsch van Beijnum, Rick van Rein, 4-Apr-13, This document provides an overview of various ways to tunnel IPv6 packets over IPv4 networks. It covers mechanisms in current use, touches on several mechanisms that are now only of historic interest, and discusses some newer tunnel mechanisms that are not (yet) widely used at the time of publication. The goal of the document is helping people with an IPv6-in-IPv4 tunneling need to select the mechanisms that may apply to them. "Negotiating Human Language Using SDP", Randy, 24-Feb-13, Users have various human (natural) language needs, abilities, and preferences regarding spoken, written, and signed languages. When establishing interactive communication "calls" there needs to be a way to communicate and ideally match (i.e., negotiate) the caller's language needs, abilities, and preferences with the capabilities of the called party. This is especially important with emergency calling, where a call can be routed to a PSAP or call taker capable of communicating with the user, or a translator or relay operator can be bridged into the call during setup, but this applies to non- emergency calls as well (as an example, when calling an airline reservation desk). This document describes the need and expected use, and discusses the solution using either an existing or new SDP attribute. "On the Validation of TCP Sequence Numbers", Fernando Gont, David Borman, 16-Feb-13, When TCP receives packets that lie outside of the receive window, the corresponding packets are dropped and either an ACK, RST or no response is generated due to the out-of-window packet, with no further processing of the packet. Most of the time, this works just fine and TCP remains stable, especially when a TCP connection has unidirectional data flow. However, there are three scenarios in which packets that are outside of the receive window should still have their ACK field processed, or else a packet war will take place. The aforementioned issues have affected a number of popular TCP implementations, typically leading to connection failures, system crashes, or other undesirable behaviors. This document describes the three scenarios in which the aforementioned issues might arise, and formally updates RFC 793 such that these potential problems are mitigated. "A Near Term Solution for Home IP Networking (HIPnet)", Chris Grundemann, Chris Donley, John Brzozowski, Lee Howard, Victor Kuarsingh, 25-Feb-13, Home networks are becoming more complex. With the launch of new services such as home security, IP video, Smart Grid, etc., many Service Providers are placing additional IPv4/IPv6 routers on the subscriber network. This document describes a self-configuring home router that is capable of operating in such an environment, and that requires no user interaction to configure it. Compliant with draft-ietf-homenet-arch, it uses existing protocols in new ways without the need for a routing protocol. "PCP Server Discovery based on well-known IP Address", Sebastian Kiesel, Reinaldo Penno, 16-Feb-13, The Port Control Protocol (PCP) provides a mechanism to control how incoming packets are forwarded by upstream devices such as Network Address Translator IPv6/IPv4 (NAT64), Network Address Translator IPv4/IPv4 (NAT44), IPv6 and IPv4 firewall devices, and a mechanism to reduce application keep alive traffic. This document establishes a well-known IP address for the PCP Server and documents how PCP clients embedded in endpoints can use it during the discovery and regular operation phases. "Ruoska Encoding", JPM, 21-Mar-13, This document describes hierarchically structured binary encoding format called the Ruoska Encoding (RSK). The main design goals are minimal resource usage, well defined structured with good selection of widely known data types, and still extendable for future usage. The main benefit when compared to non binary hierarchically structured formats like XML is simplicity and minimal resource demands. Even basic XML parsing is time and memory consuming operation. When compared to other binary formats like encoding formats of ASN.1 the main benefit is simplicity. ASN.1 with different encondings is complex and even simple implementation needs a lot of effort. "Considerations on using NETCONF with LMAP Measurement Agents", Juergen Schoenwaelder, 16-Feb-13, This document discusses how the NETCONF protocol can be used to configure LMAP measurement agents. "A YANG Data Model for LMAP Measurement Agents", Juergen Schoenwaelder, 16-Feb-13, This document sketches a data model for configuring and scheduling tests for large scale broadband access network measurements. The data model is defined using the YANG data modeling language. "The Incident Object Description Exchange Format", Roman Danyliw, Paul Stoecker, 16-Feb-13, The Incident Object Description Exchange Format (IODEF) defines a data representation that provides a framework for sharing information commonly exchanged by Computer Security Incident Response Teams (CSIRTs) about computer security incidents. This document describes the information model for the IODEF and provides an associated data model specified with XML Schema. "Use case of IPv6 prefix semantics for operators", Qiong Sun, Qiong Sun, Sheng Jiang, 25-Feb-13, Embedding certain semantics into IPv6 addresses will bring a lot of benifits for operators to simplify network management and apply operations accordingly[I-D.jiang-semantic-prefix]. This memo illustrates the use case of semantic bits from operator's point of view, and provides considerations on how to design the semantic bits in IPv6 address. "Integration Examples of DECADE System", Ning Zong, Xiaohui Chen, Zhigang Huang, Lijiang Chen, Hongqiang Liu, 16-Feb-13, Decoupled Application Data Enroute (DECADE) system is an in-network storage infrastructure which was discussed in IETF. This document presents two detailed examples of how to integrate such in-network storage infrastructure into peer-to-peer (P2P) applications to achieve more efficient content distribution, and Application Layer Traffic Optimization (ALTO) system to build a content distribution platform for Content Providers (CPs). "PMIPv6 Multicast Routing Optimization with PIM-SM", Hitoshi Asaeda, Pierrick Seite, 17-Feb-13, This document describes IP multicast routing optimization with PIM-SM in Proxy Mobile IPv6 (PMIPv6) environment. 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 optimization addresses the tunnel convergence problem and cooperates with seamless handover mechanisms. "Using IS-IS with Role-Based Access Control", Fred Baker, 17-Feb-13, This note describes the changes necessary for IS-IS to route classes of IPv6 traffic that are defined by an IPv6 Flow Label and a destination prefix. This implies not routing "to a destination", but "traffic matching a classification tuple". The obvious application is data center inter-tenant routing using a form of role-based access control. If the sender doesn't know the value to insert in the flow label (the receiver's tenant ID), he in effect has no route to that destination. "IPv6 Source/Destination Routing using IS-IS", Fred Baker, 17-Feb-13, This note describes the changes necessary for IS-IS to route classes of IPv6 traffic that are defined by a source prefix and a destination prefix. This implies not routing "to a destination", but "traffic matching a classification tuple". The obvious application is egress routing - routing traffic using a given prefix to an upstream network that will not drop traffic using that prefix using BCP 38 filters. "Using OSPFv3 with Role-Based Access Control", Fred Baker, 2-May-13, This note describes the changes necessary for OSPFv3 to route classes of IPv6 traffic that are defined by an IPv6 Flow Label and a destination prefix. This implies not simply routing "to a destination", but "traffic going to that destination AND using a specified flow label". It may be combined with other qualifying attributes, such as "traffic going to that destination AND using a specified flow label AND from a specified source prefix". The obvious application is data center inter-tenant routing using a form of role-based access control. If the sender doesn't know the value to insert in the flow label (the receiver's tenant ID), it in effect has no route to that destination, thus providing an access list that is as changeable and scalable as routing. "IPv6 Source/Destination Routing using OSPFv3", Fred Baker, 2-May-13, This note describes the changes necessary for OSPFv3 to route classes of IPv6 traffic that are defined by an IPv6 source prefix and a destination prefix. This implies not simply routing "to a destination", but "traffic going to that destination AND coming from a specified source". It may be combined with other qualifying attributes, such as "traffic going to that destination AND using a specified flow label AND from a specified source prefix". The obvious application is egress routing, as required for a multihomed entity with a provider-allocated prefix from each of several upstream networks. Traffic within the network could be source/destination routed as well, or could be routed from "any prefix", ::/0. If traffic is routed from the relevant PA prefixes but in fact has a source address that is in none of them, the traffic in effect has no route. "Load-balancing to Data Centers in a L3VPN environment based on Power", Balaji Venkataswami, Bhargav Bhikkaji, Shankar Raman, 17-Feb-13, Data Centers may be spread across different locations for a particular enterprise. Different locations may mean within the same country but across different geographical locations, or outside the country even in a different continent. These data centers may be serving the enterprise or multiple enterprises / tenants wherein the regular enterprise site may request data from a data center site which could be one of the data center sites proximal to the enterprise site. Proximity is usually calculated based on a metric that is bandwidth driven or in terms with regard to the number of hops to reach that data center site hence bringing into play delay characteristics. Assume a topology where the data center sites and the enterprise sites are MPLS based L3VPN sites that are being provided connectivity through a Service Provider deploying Layer 3 VPNs. Given such a topology it is possible that replication of data happens across the data centers in a timely manner to keep the data active and refreshed across all data center sites. Suitable mechanisms for such replication will come into play for this purpose. Thus any of the data centers can cater to the request from a user site. It is possible that power consumption in each data center may vary according to the load on each data center. It would be prudent to introduce a scheme where the power metric coupled with other metrics such as bandwidth and delay be used by a Provider Edge router in a L3VPN scenario to direct the packets or requests from regular user sites to such data centers with the least such metric. This is in line with the follow-the-moon strategy of directing requests for data and compute to data centers which are power-wise more efficient during the night or during the day. This draft document lays out one such proposal. "Mutually Exclusive Link Group (MELG)", Vishnu Beeram, Igor Bryskin, 17-Feb-13, This document introduces the concept of MELG ("Mutually Exclusive Link Group") and discusses its usage in the context of mutually exclusive Virtual TE Links. "Analysis of NAT64 Port Allocation Method", Gang Chen, 25-Feb-13, The document enumerated methods of port assignment in CGN contexts, more focused on NAT64 environments. The analysis categorized the different methods with several key features. Corresponding to those features, the uses of existing protocols are also described. The potential concerns and workaround have been discussed. It's expected the document could provide a informative base line to help operators choosing a proper method. "Extension to Purge Initiator Identification TLV for ISIS in TRILL", Gang Chen, 17-Feb-13, This memo specified an extension of ISIS TLV for identifying purge initiator in TRILL environments. With the extension, it's beneficial for operators to nail down the root cause when there is a corrupted LSP spread within a layer-2 network. The defined TLV is expected to record the system ID, Nickname and impacted VLAN information. RBridge should propagate the TLV information without changes in order to flood the information. "Using DMARC", DCrocker, 29-Apr-13, Email abuse often relies on unauthorized use of a domain name, such as one belonging to a well-known company (brand). SPF and DKIM provide basic domain name authentication methods for email. A recent industry effort built an additional authentication-based layer, called Domain-based Message Authentication, Reporting & Conformance (DMARC). It allows a sender to indicate that their emails are protected by SPF and/or DKIM, and tells a receiver what to do if neither of those authentication methods passes; it also provides a reporting mechanism, from receivers back to domain owners. Such capabilities over the public Internet are unusual and their use is not yet well-understood. This document formulates a set of best practices for the use of DMARC. "TRILL: Vendor Specific TRILL Channel Protocol", Donald Eastlake, Li Yizhou, Hao Weiguo, Ayan Banerjee, 17-Feb-13, The IETF TRILL (TRansparent Interconnection of Lots of Links) protocol is implemented by devices called TRILL switches or RBridges (Routing Bridges). TRILL includes a general mechanism, called RBridge Channel, for the transmission of typed messages between RBridges in the same campus and between RBridges and end stations on the same link. This document specifies how to send vendor specific messages over the RBridge Channel facility. "An Architecture for Middlebox State Migration", Gu Yingjie, Melinda Shore, Senthil Sivakumar, Dacheng Zhang, 22-Feb-13, This draft use several motivation use cases to indicate the importance of the state migration work. An architecture and components of a solution is given conceiving the use cases, together with the interfaces and data models that are required in the architecture. "OUI Registry Restructuring", Glenn Parsons, 17-Feb-13, The IEEE Registration Authority Committee, which has oversight for the OUI based registries, is seeking IETF community input on its proposal to restructure the OUI registries. This document provides background on the RAC as well as explaining the proposed restructuring and the rationale. "A Virtualized Network Element Framework", Kenji Kumaki, Pradosh Mohapatra, David Meyer, 17-Feb-13, This document outlines a new architectural paradigm of virtualizing the service provider networks and its associated engineering requirements. The framework is referred to as the virtual network element framework (VNEF) in the document. "Routing Extensions for Discovery of Role-based MPLS Label Switching Router (MPLS LSR) Traffic Engineering (TE) Mesh Membership", Zhenbin Li, Mach Chen, 17-Feb-13, A Traffic Engnieering (TE) mesh-group is defined as a group of Label Switch Routers (LSRs) that are connected by a full mesh of TE LSPs. Routing (OSPF and IS-IS) extensions for discovery Multiprotocol Label Switching (MPLS) LSR TE mesh membership has been defined to automate the creation of mesh of TE LSPs. This document introduces a role-based TE mesh-group that applies to the scenarios where full mesh TE LSPs are not necessary and TE LSPs setup depends on the roles of LSRs in a TE mesh-group. Interior Gateway Protocol (IGP) routing extensions for automatic discovery of role-based TE mesh membership are defined accordingly. "Alternative Constraints for Point-to-Multipoint Traffic-Engineered MPLS Label Switched Paths(LSPs)", Zhenbin Li, Tieying Huang, 17-Feb-13, The document proposes a solution to be able to set up the alternative path for specific leaf nodes of a P2MP TE LSP. Corresponding RSVP-TE protocol extension is also defined. The solution is used to cope with the issue that in some scenarios traffic loss happens even if there exists possible path for the leaf nodes. "OSPF Extensions for Automatic Computation of MPLS Traffic Engineering Path Using Traffic Engineering Layers and Areas", Zhenbin Li, Li Zhang, Yuanjiao Liu, 17-Feb-13, As the network scale expands, especially in the mobile backhaul network, automatic computation of MPLS Traffic Engineering (TE) path becomes very important. But owing to requirements on the MPLS TE path, explicit path or affinity property has to be introduced for the path computation. This causes the complexity of MPLS TE path design. The document proposes an architecture and corresponding OSPF extensions to improve automation on computation of MPLS TE path. MPLS TE networks are divided into different traffic engineering layers and areas according to the characteristics of the network topology. MPLS TE path can compute automatically based on traffic engineering layers and areas to satisfy major requirements to bear mobile network services. "OSPF Extensions for MPLS Green Traffic Engineering", Gang Yan, Jianjun Yang, Zhenbin Li, 17-Feb-13, The energy-saving is one important topic in the world, and now most of technology for energy-saving is related with the hardware design instead of that based on the whole network. This document proposes OSPF extensions to synchronize the energy-saving parameter of each node in the network which will be considered when the LSP path is calculated. "A One-Way Loss Metric for IPPM", Guy Almes, Sunil Kalidindi, Matthew Zekauskas, Al Morton, 17-Feb-13, This memo (RFC 2680 bis) defines a metric for one-way loss of packets across Internet paths. It builds on notions introduced and discussed in the IPPM Framework document, RFC 2330; the reader is assumed to be familiar with that document. "SCTP Overlay link for REsource LOcation And Discovery (RELOAD)", Marc Petit-Huguenin, 17-Feb-13, This document defines two new Overlay Link protocols to be used with REsource LOcation And Discovery (RELOAD), both using SCTP. The Overlay Link protocol DTLS-SCTP-NO-ICE uses DTLS on top of native SCTP for overlays that do not require the use of ICE. The Overlay Link protocol DTLS-SCTP-UDP uses DTLS on top of an UDP encapsulation of SCTP for overlays that require the use of ICE. "Hybrid-MAC Model for CAPWAP", Chunju Shao, Hui Deng, Farooq Bari, Rong Zhang, Satoru Matsushima, 17-Feb-13, The CAPWAP protocol supports two modes of operation: Split and Local MAC (medium access control), which has been described in [RFC5415].There are many functions in IEEE 802l.11 MAC layer that have not yet been clearly defined whether they belong to either the AP (Access Point) or the AC (Access Controller)in the Split and Local modes. Because different vendors have their own definition of these two models, depending upon the vendor many MAC layer functions continue to be mapped differently to either the AP or AC. If there is no clear definition of split MAC and local MAC, then operators will not only need to perform vendor specific configurations in their network but will continue to experience difficulty in interoperating APs and ACs from different vendors. "IPv6 Delegated Prefix Verification Tool", Shishio Tsuchiya, 25-Feb-13, IPv6 Prefix Options for Dynamic Host Configuration Protocol version 6 (DHCP-PD) and IPv6 Rapid Deployment (6rd) are technology to provide IPv6 prefix, not IPv6 address themselves. Delegated Prefix are controlled by Customer Premise Equipment (CPE) and 6rd Customer Edge (6rd CE). The service provider can not confirm utilization of delegated prefix on CE and CPE. This document describes mechanism of verification for delegated prefix on CPE and CE from service provider side. "Differentiated Service Class Recommendations for LLN Traffic", Shitanshu Shah, Pascal Thubert, 17-Feb-13, Differentiated services architecture is widely deployed in traditional networks. There exist well defined recommendations for the use of appropriate differentiated service classes for different types of traffic (eg. audio, video) in these networks. Per-Hop Behaviors are typically defined based on this recommendations. With emerging Low-power and Lossy Networks (LLNs), it is important to have similar defined differentiated services recommendations for LLN traffic. Defined recommendations are for LLN class of traffic exiting out of LLNs towards high-speed backbones, converged campus network and for the traffic in the reverse direction. "Additional Policies for the Partial Delivery Extension of the Stream Control Transmission Protocol", Salvatore Loreto, Robin Seggelmann, Randall Stewart, Michael Tuexen, 17-Feb-13, This document defines policies for the Partial Reliability Extension of the Stream Control Transmission Protocol (PR-SCTP) allowing to limit the number of retransmissions or to prioritize user messages for more efficient send buffer usage. "PAWS Database Discovery", Xinpeng Wei, Lei Zhu, 21-May-13, This document provides a Database Discovery mechanism for PAWS. By this mechanism the master device gets the available WSDBs with which it should communicate as well as the regulatory domain information. The mechanism is based on the LoST protocol . "MAC address learning in NVO3 using ARP", Qin Wu, 25-Feb-13, [I.D-ietf-nvo3-framework] discusses using Dynamic data plane learning or control plane protocol to build and maintain the mapping tables and deliver encapsulated packets to their proper destination. However, there is no relevant work to discuss how those capabilities can be realized in details at the NVEs. This document goes into details to discuss how MAC address learning works through data plane and control plane. "Stateful Path Computation Element (PCE) for Time-based Scheduling", Xian Zhang, Young Lee, Ramon Casellas, Oscar de Dios, 17-Feb-13, This document presents the architecture and procedures for stateful PCE to support time-based scheduling application and also provides PCEP extensions needed. "Extended Encoding Scheme for Shared List Link Group (SRLG)", Zafar Ali, George Swallow, Clarence Filsfils, Ori Gerstel, Stewart Bryant, Matt Hartley, 18-Feb-13, SRLGs play a key role in routing resiliency and capacity planning of multi-domain and multi-layer networks. Notion of SRLG are used to select a backup path that is disjoint from the primary path, to ensure disjointness of circuits and to avoid catastrophic partitioning outages. In the current specifications, SRLG is identified as a 32 bit number that is unique within an IGP domain [RFC4202]. There are many limitations to this approach of encoding SRLGs, especially in a multi-layer network. This draft outlines these limitations and suggests components of extended SRLG encoding scheme to address them. "Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extension for Label Switched Path (LSP) Inquiry", Zafar Ali, George Swallow, Clarence Filsfils, Ori Gerstel, Matt Hartley, 18-Feb-13, RSVP-TE reoptimization procedure for Packet Switch Capable (PSC) tunnels and non-PSC tunnels has some differences. This document highlights these differences, describes how existing procedures can be used for reoptimization of non-PSC tunnels and proposes some enhancements for reoptimization of non-PSC tunnels. "A Google Congestion Control Algorithm for Real-Time Communication", Stefan Holmer, Harald Alvestrand, 18-Feb-13, 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 as an input document to the RMCAT working group on congestion control for media streams. The mailing list of that WG is rmcat@ietf.org. "PIM Join Attributes for LISP Environments", Jesus Arango, Stig Venaas, Isidor Kouvelas, 18-Feb-13, This document defines two PIM Join/Prune attributes that support the construction of multicast distribution trees where the root and receivers are located in different LISP sites. These attributes allow the receiver site to select between unicast and multicast transport and to convey the receiver RLOC address to the control plane of the root xTR. "Building Power-Efficient CoAP Devices for Cellular Networks", Jari Arkko, Anders Eriksson, Ari Keränen, 18-Feb-13, This memo discusses the use of the Constrained Application Protocol (CoAP) protocol in building sensors and other devices that employ cellular networks as a communications medium. Building communicating devices that employ these networks is obviously well known, but this memo focuses specifically on techniques necessary to minimize power consumption. "Automated prefix allocation in IS-IS", Fred Baker, 18-Feb-13, This note describes a TLV and associated mechanisms for the allocation of /64 prefixes from a less specific prefix. "Diameter Congestion and Filter Attributes", Brent Hirschman, Lyle Bertz, 18-Feb-13, This document defines ECN and filter related attributes that can be used for improved traffic identification, support of ECN and minimized filter administration within Diameter. RFC 5777 defines a Filter-Rule AVP that accommodates extensions for classification, conditions and actions. It does not support traffic identification for packets using Explicit Congestion Notification as defined in RFC 3168 and does not provide specific actions when the flow(s) described by the Filter-Rule are congested. A Filter-Rule can describe multiple flows but not the exact number of flows. Flow count and other associated data (e.g. packets) is not captured in Accounting applications, leaving administrators without useful information regarding the effectiveness or understanding of the filter definition. "JSON format to represent DNS data", Stephane Bortzmeyer, 25-Feb-13, This document describes a profile of JSON to represent DNS data. "Large scale Measurement of Access network Performance (LMAP): Requirements and Issues from a Network Provider Perspective", Mohamed Boucadair, Christian Jacquenet, 18-Feb-13, This document raises several points related to the ongoing LMAP (Large scale Measurement of Access network Performance) effort. The goal is to contribute to define a scope for LMAP and its expected contribution. "VXLAN DCI Using EVPN", Sami Boutros, Ali Sajassi, Samer Salam, Dennis Cai, 24-Feb-13, This document describes how Ethernet VPN (E-VPN) technology can be used to interconnect VXLAN or NVGRE networks over an MPLS/IP network. This is to provide intra-subnet connectivity at Layer 2 and control- plane separation among the interconnected VXLAN or NVGRE networks. The scope of the learning of host MAC addresses in VXLAN or NVGRE network is limited to data plane learning in this document. "Network Performance Isolation using Congestion Policing", Bob Briscoe, 18-Feb-13, This document describes why policing using congestion information can isolate users from network performance degradation due to each other's usage, but without losing the multiplexing benefits of a LAN- style network where anyone can use any amount of any resource. Extensive numerical examples and diagrams are given. The document is agnostic to how the congestion information reaches the policer. The congestion exposure (ConEX) protocol is recommended, but other tunnel feedback mechanisms have been proposed. "Diameter Overload Data Analysis", Ben Campbell, Hannes Tschofenig, Jouni Korhonen, Adam Roach, 18-Feb-13, When a Diameter server or agent becomes overloaded, it needs to be able to gracefully reduce its load, typically by informing clients to reduce sending traffic for some period of time. Multiple mechanisms have been proposed for transporting overload and load information. While these proposals differ in many ways, they share similar data requirements. This document analyzes the data requirements of each proposal with a view towards proposing a common set of of Diameter Attribute-Value Pairs (AVPs). "Distributed Mobility Management Framework", Anthony Chan, Pierrick Seite, Kostas Pentikousis, 25-Feb-13, This document introduces a framework for mobility management protocols in terms of their key, abstract logical functions. We explain how the framework is capable of presenting a unified view, reducing the clutter that prevents a casual reader from understanding the commonalities between different approaches in mobility management. A first order application of this framework is to enable us to examine previously standardized mobility management protocols, such as MIPv6 and PMIPv6 (as well as several of their extensions), and describe their core functionality in terms of different configurations of the logical functions defined by the framework. "Coloring based IP Flow Performance Measurement Framework", Mach Chen, Hongming Liu, Yuanbin Yin, 24-Feb-13, By setting one unused bit of the IP header of packets to "color" the packets into different color blocks, it naturally gives a way to measure the real packet loss and delay without inserting any extra OAM packets. This is called "coloring" based IP Flow Performance Measurement (IPFPM). This document specifies a framework and protocol for this "coloring" based IPFPM. "IS-IS Topology-Transparent Zone", Huaimo Chen, Renwei Li, Gregory Cauchie, So Ning, Alvaro Retana, 3-May-13, This document presents a topology-transparent zone in a domain. A topology-transparent zone comprises a group of routers and a number of circuits connecting these routers. Any router outside of the zone is not aware of the zone. The information about the circuits and routers inside the zone is not distributed to any router outside of the zone. Any link state change such as a circuit down inside the zone is not seen by any router outside of the zone. "NVO3 Requirements Versus Available Protocol Capabilities", Xiaoming Chen, Tina Tsou, Evelyne Roch, 18-Feb-13, This document matches candidate protocols against the NVO3 requirements. Based on the results, gaps are identified and further protocol work is recommended. "CAPWAP Extension for 802.11n and Power/channel Reconfiguration", Yifan Chen, Dapeng Liu, Hui Deng, Lei Zhu, 18-Feb-13, CAPWAP binding for 802.11 is specified by RFC5416 and it was based on IEEE 802-11.2007 standard. After RFC5416 was published in 2009, there was several new amendent of 802.11 has been published. 802.11n is one of those amendent and it has been widely used in real deployment. This document extends the CAPWAP binding for 802.11 to support 802.11n. "Gateway-Initiated 4over6 Deployment", Yuchi Chen, Jianping Wu, Xiongyan Tang, 24-Feb-13, Gateway-Initiated 4over6 (GI-4over6) is a variant of 4over6 mechanisms which include Public 4over6 ([I-D.ietf-softwire-public-4over6]) and Lightweight 4over6 ([I-D.cui-softwire-b4-translated-ds-lite]), and it's designed to satisfy the certain tunnel-based access scenario. The GI-4over6 extends the On-Link Client Relay Agent (LCRA) that is defined in [I-D.ietf-dhc-dhcpv4-over-ipv6] and thus makes it enabled to help gateway device perform 4over6 CE function described in [I-D.ietf-softwire-public-4over6], and lwB4 function described in [I-D.cui-softwire-b4-translated-ds-lite], while the public IPv4 addresses (and available ports) are assigned to the end hosts that behind the gateway device. "ICN Management Considerations", Daniel Corujo, Kostas Pentikousis, Ivan Vidal, 18-Feb-13, This document aims to draw the attention of the ICNRG community to network management, an important but hitherto underdeveloped area of research in information-centric networking. We consider that the availability of modern management mechanisms for information-centric networks will foster their deployment in real-world environments. For example, we argue that there is a need for creating basic network management tools early on while ICN is still in the design and experimentation phases that can evolve over time. Perhaps ICN can borrow successful mechanisms from the host-centric paradigm and adapt them to the new network primitives. Alternatively, novel network management schemes can be designed based on ICN primitives. As a discussion starter, this document summarizes recently published approaches for ICN network management. In particular, this first version presents a management framework for named data networking and reviews previous work on NetInf management. "PCEP Extensions for MPLS-TE LSP Automatic Bandwidth Adjustment with stateful PCE", Dhruv Dhody, Udayasree Palle, 18-Feb-13, 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. The extensions described in [STATEFUL-PCE] provide stateful control of Multiprotocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSP) via PCEP, for a model where the PCC delegates control over one or more locally configured LSPs to the PCE. This document describes the automatic bandwidth adjustment of such LSPs under the stateful PCE model. "Extensions to OSPF facilitating the deployment of non-backward- compatible changes.", Mike Dubrovsky, Rashmi Shrivastava, Dean Cheng, 18-Feb-13, This document specifies a generic mechanism that facilitates the deployment of non-backward-compatible changes in OSPF protocol. This mechanism allows the OSPF routers to advertise the capability of non- backward-compatible functionality and to make the functionality operational only when supported by all participating routers. Depending on the functionality scope, capability advertisements must be propagated across a link, area or autonomous system (AS). For link and area scope functionality, Router Information Link State Advertisement (LSA) is utilized to propagate the capability information. For the cases when compatibility must be maintained across the whole OSPF autonomous system, new Area Information (AI) LSA is introduced. The AI LSA is a TLV-based analog of Indication- LSA that is used for demand circuit functionality and described in RFC1793. "Modern cryptography TKEY", Francis Dupont, 18-Feb-13, This document updates the TKEY resource record specifications for the use of Elliptic Curve Diffie-Hellman, and related IANA registries. "A framework for large-scale measurements", Philip Eardley, Trevor Burbridge, Al Morton, 25-Feb-13, Measuring broadband service on a large scale requires standardisation of the logical architecture and a description of the key protocols that coordinate interactions between the components. The document presents an overall framework for large-scale measurements and discusses which elements could be standardised in the IETF. It is intended to assist the discussions about the potential creation of the LMAP working group. "Alternatives to BUNDLE", Richard Ejzak, 25-Feb-13, This paper discusses some potential modifications to the BUNDLE proposal for multiplexing of multiple media types within a single 5-tuple to address limitations of the current proposal and alternatives already considered by MMUSIC. "IP Packet loss rate measurement testing and problem statement", Peng Fan, Lu Huang, 18-Feb-13, This document describes common methods for measuring packet loss rate and their effectiveness. Issues encountered when using the methods and necessary considerations are also discussed and recommended. "BGP IP VPN Data Center Interconnect", Luyuan Fang, Rex Fernando, Dhananjaya Rao, Dhananjaya Rao, 25-Feb-13, This document discusses solutions for inter-connection of BGP MPLS IP/VPN [RFC4364] and Data Center (DC) overlay networks. Two categories of inter-connections are discussed in this document. In the first category, Data Center overlay virtual network is built with BGP IP VPN technologies, the inter-connection of IP VPN in the Data Center to BGP IP VPN in the WAN enables end-to-end IP VPN connectivity. New Inter-AS solutions are required in certain scenarios, in addition to the existing Inter-AS Options (A, B, C) defined in [RFC4364]. In the second category, Data Centers overlay network uses non IP VPN technologies, the inter-connection of any overlay virtual network in the Data Center to BGP IP VPN in the WAN provides end user connectivity through stitching of different overlay technologies, the mapping of non IP VPN overlay to IP VPN need to be performed at the border Gateway of the two networks. The role of Software Defined Network (SDN) to assist the inter-connections is discussed. "BGP IP VPN Virtual CE", Luyuan Fang, John Evans, David Ward, Rex Fernando, John Mullooly, So Ning, Nabil Bitar, Maria Napierala, 25-Feb-13, This document describes the architecture and solutions of using virtual Customer Edge (vCE) of BGP IP VPN. The solution is aimed at providing efficient service delivery capability through CE virtualization, and is especially beneficial in virtual Private Cloud (vPC) environments for extending IP VPN into tenant virtual Data Center containers. This document includes: BGP IP VPN virtual CE architecture; Control plane and forwarding options; Data Center orchestration processes; integration with existing WAN enterprise VPNs; management capability requirements; and security considerations. The solution is generally applicable to any BGP IP VPN deployment. The virtual CE solution is complementary to the virtual PE solutions. Today's data center's require multi-tenancy and mechanisms to establish overlay network connectivity. This document describes one approach to enabling data center network connectivity. "BGP IP VPN Virtual PE", Luyuan Fang, David Ward, Rex Fernando, Maria Napierala, Nabil Bitar, Dhananjaya Rao, Bruno Rijsman, 7-Apr-13, This document describes the architecture solutions for BGP/MPLS IP Virtual Private Networks (VPNs) with virtual Provider Edge (vPE) routers. It provides a functional description of the vPE control plane, the data plane, and the provisioning management process. The vPE solutions supports both Software Defined Networking (SDN) approach by allowing physical decoupling of the control and the forwarding plane of a vPE, as well as a distributed routing approach. These solutions allow vPE to be co-resident with the application virtual machines (VMs) on a single end device, such as a server, as well as on a Top-of-Rack switch (ToR), or in any network or compute device. The ability to provide end-to-end native BGP IP VPN connections between a Data Center (DC) (and/or other types of service network) applications and the Enterprise IP VPN sites is highly desirable to both Service Providers and Enterprises. "Problem Statement and Architecture for Information Exchange Between Interconnected Traffic Engineered Networks", Adrian Farrel, John Drake, Nabil Bitar, George Swallow, Daniele Ceccarelli, 18-Feb-13, In Traffic Engineered (TE) systems, it is sometimes desirable to establish an end-to-end TE path with a set of constraints (such as bandwidth) across one or more network from a source to a destination. TE information is the data relating to nodes and TE links that is used in the process of selecting a TE path. The availability of TE information is usually limited to within a network (such as an IGP area) often referred to as a domain. In order to determine the potential to establish a TE path through a series of connected networks, it is necessary to have available a certain amount of TE information about each network. This need not be the full set of TE information available within each network, but does need to express the potential of providing TE connectivity. This subset of TE information is called TE reachability information. This document sets out the problem statement and architecture for the exchange of TE information between interconnected TE networks in support of end-to-end TE path establishment. For reasons that are explained in the document, this work is limited to simple TE constraints and information that determine TE reachability. "UNI Extensions for Diversity and Latency Support", Don Fedyk, Dieter Beller, Lieven Levrau, Daniele Ceccarelli, Fatai Zhang, Yuji Tochio, 25-Feb-13, This document builds on the GMPLS overlay model [RFC4208] and defines extensions to the GMPLS User-Network Interface (UNI) to support route diversity within the core network for sets of LSPs initiated by edge nodes. A particular example where route diversity within the core network is desired, are dual-homed edge nodes. The document also defines GMPLS UNI extensions to deal with latency requirements for edge node initiated LSPs. This document uses a VPN model that is based on the same premise as L1VPN framework [RFC4847] but may also be applied to other technologies. The extensions are applicable both to VPN and non VPN environments. These extensions move the UNI from basic connectivity to enhanced mode connectivity by including additional constraints while minimizing the exchange of CE to PE information. These extensions are applicable to the overlay extension service model. Route Diversity for customer LSPs are a common requirement applicable to L1VPNs. The UNI mechanisms described in this document are L1VPN compatible and can be applied to achieve diversity for sets of customer LSPs. The UNI extensions in support of latency constraints can also be applied to the extended overlay service model in order for the customer LSPs to meet certain latency requirements. "A VP9 Bitstream Overview", Adrian Grange, Harald Alvestrand, 18-Feb-13, This document describes VP9, a video codec being developed specifically to meet the demand for the consumption of video over the Internet, including professionally and amateur produced video-on- demand and conversational video content. VP9 is an evolution of the VP8 video codec that is described in [bankoski-rfc6386] and includes a number of enhancements and new coding tools that have been added to improve the coding efficiency. The new tools that have been added so far include: larger prediction block sizes up to 64x64, various forms of compound INTER prediction, more modes for INTRA prediction, ⅛-pel motion vectors, 8-tap switchable sub-pixel interpolation filters, improved motion reference generation, improved motion vector coding, improved entropy coding including frame-level entropy adaptation for various symbols, improved loop filtering, the incorporation of the Asymmetric Discrete Sine Transform (ADST), larger 16x16 and 32x32 DCTs, and improved frame level segmentation. VP9 is under active development and this document provides only a snapshot of the current state of the coding tools as they exist today. The finalized version of the VP9 bitstream may differ considerably from the description contained herein and may encompass the exclusion or modification of existing coding tools or the addition of new coding tools. "Advertising MPLS labels in IGPs", Hannes Gredler, Shane Amante, Tom Scholl, Luay Jalil, 15-May-13, Historically MPLS label distribution was driven by session oriented protocols. In order to obtain a particular routers label binding for a given destination FEC one needs to have first an established session with that node. This document describes a mechanism to distribute FEC/label mappings through flooding protocols. Flooding protocols publish their objects for an unknown set of receivers, therefore one can efficiently scale label distribution for use cases where the receiver of label information is not directly connected. Application of this technique are found in the field of backup (Bypass, R-LFA) routing, Label switched path stitching, egress protection, explicit routing and egress ASBR link selection. "3GPP IMS Option for IKEv2", Aeneas Noble, Sri Gundavelli, Jouni Korhonen, Florin Baboescu, 18-Feb-13, This document defines two new configuration attributes for Internet Key Exchange Protocol version 2 (IKEv2). These attributes can be used for carrying the IPv4 and IPv6 address of the Proxy-Call Control and Service function (P-CSCF). This is one of the few methods that an IPsec client can obtain the IP address of the P-CSCF function located in the home network. "Well Known Service and URI Declarations", Phillip Hallam-Baker, 18-Feb-13, Under the current system of registration, separate requests are required to register entries for .well-known HTTP services, discovery via DNS mechanisms such as SRV and NAPTR and for a URI prefix. This proposal encourages Web Services to adopt a consistent approach to configuration through a 'one stop' registration system whereby assignment of a .well-known identifier automatically assigns DNS and URI prefixes. "SDP and CLUE message interactions", Robert Hansen, 25-Feb-13, This document attempts to help resolve some of the complexities of interaction between SDP and CLUE messages in call flows by providing some strategies and some suggested syntax. "Use Cases for Virtual Connections on Demand (VCoD) and Virtual Network on Demand using Interface to Routing System", Susan Hares, 18-Feb-13, Software Defined Networks (SDN) provide a way to virtualize and abstract the network and present the virtual or abstract resources to the third-party applications running in software. The application can utilize a programmable interface to receiving these virtual or abstract resources in a form that allows monitoring or manipulation of resources. Various programmatic interfaces have been proposed to interface directly to the forwarding plane (OpenFlow, ForCES), or do device configuration (NETCONF). ALTO has proposed a informational interface to the application. Only the progammatic Interface to the Routing System (IRS) provides an interface directly to the routing system to utilize all aspects of the routing system as a system. The IRS system interacts with the control plane processes to monitor best paths to any destination and to change the routing information base (RIB) or MPLS label information Base (LIB) which feeds the forwarding tables the information needed to actually switch traffic at a local level. This document outlines how SDN networks can use the IRS interface to implement an automated set of network services for Virtual Connection on Demand (VCoD) and Virtual Network on Demand (VNoD) "Security Requirements of NVO3", Sam Hartman, Dacheng Zhang, Margaret Wasserman, 18-Feb-13, This draft discusses the security requirements and several issues which need to be considered in securing a virtualized data center network for multiple tenants. In addition, the draft also attempts to discuss how such issues could be addressed or mitigated. "Integrity Protection for Control Messages in NHDP and OLSRv2", Ulrich Herberg, Christopher Dearlove, Thomas Clausen, 18-Mar-13, This document specifies integrity and replay protection for required implementation in the MANET Neighborhood Discovery Protocol (NHDP) and the Optimized Link State Routing Protocol version 2 (OLSRv2). This document specifies how an included integrity check value (ICV) and a timestamp TLV, defined in RFC6622bis, are used by NHDP and OLSRv2 for countering a number of security threats. The ICV TLV uses a SHA-256 based HMAC and a single shared secret key. The timestamp TLV is based on POSIX time, and assumes that the clocks in all routers in the network can be synchronized with sufficient precision. The mechanism in this specification can also be used for other MANET protocols using RFC5444. "Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs)", Ulrich Herberg, Thomas Clausen, Christopher Dearlove, 18-Mar-13, This document extends and replaces RFC 6622. It describes general and flexible TLVs for representing cryptographic Integrity Check Values (ICVs) (i.e., digital signatures or Message Authentication Codes (MACs)) as well as timestamps, using the generalized Mobile Ad Hoc Network (MANET) packet/message format defined in RFC 5444. It defines two Packet TLVs, two Message TLVs, and two Address Block TLVs for affixing ICVs and timestamps to a packet, a message, and an address, respectively. "Energy Efficient Implementation of IETF Protocols on Constrained Devices", Zehn Cao, Xuan He, Matthias Kovatsch, 18-Feb-13, This document summarizes the problems and current practices of energy efficient protocol implementation on constrained devices, mostly about how to make the protocols within IETF scope behave energy friendly. "LISP EID Block Management Guidelines", Luigi Iannone, Roger Jorgensen, 25-Feb-13, This document proposes an allocation framework for the management of the LISP EID address prefix (requested in a separate document). Such framework relies on hierarchical distribution of the address space to RIRs (Regional Internet Registries), who will allocate on a temporary basis sub-prefixes to requesting organizations. "Vehicle Identification Number-Based IPv6 Interface Identifier (VIID)", Sofiane Imadali, Alexandru Petrescu, Christophe Janneteau, 18-Feb-13, The Vehicle Identification Number (VIN) is a 17 characters alphanumeric code that uniquely identifies a vehicle worldwide. This code is standardized in ISO-3779 and ISO-3780; other standardization bodies' implementation of this code (NHTSA, SAE) is compliant with ISO standards. The VIN is mandatory for each vehicle and used as a unique identity. Some public information related to a vehicle can be obtained knowing its VIN code. An IPv6 address is 128 bit in length and its rightmost bits form the Interface Identifier (IID). When the IPv6 address is used with IPv6- over-Ethernet and Stateless Address Auto-Configuration, the length of the IID is 64 bit. This document presents an experimental method to convert an IPv6 Interface Identifier starting from the VIN code - the VIID. The conversion can be reverted - given a VIID formed from a VIN it easily possible to find out the original VIN. "Vehicle Identification Number-Based Unique Local IPv6 Unicast Addresses (VULA)", Sofiane Imadali, Alexandru Petrescu, Christophe Janneteau, 18-Feb-13, The Vehicle Identification Number (VIN) is standardized in ISO-3779 and ISO-3780. The VIN is made of 17 alphanumeric characters code that uniquely identifies a vehicle worldwide. Some public information related to a vehicle can be obtained knowing its VIN code. This code may also be used to enable novel vehicular networking communications. RFC 4193 introduces a globally unique IPv6 unicast address format intended for local communications, usually inside of a site. These addresses (ULA) are not expected to be routable on the global Internet. This document introduces a method to build a VIN-based IPv6 Prefix that is intended for local communications involving more than one hop (VULA). The VIN-based generated prefix is assured to be unique among other VIN-based generated prefixes. Typically, in a scenario involving several vehicles, each single vehicle (in which one Mobile Router is in charge) is capable of generating its own unique infrastructure-independent globally-scoped VIN-based IPv6 prefix. This document also describes some use cases where VULA could be exploited. "A Session Initiation Protocol (SIP) usage for Trickle ICE", Emil Ivov, Adam Roach, 18-Feb-13, This document registers the application/sdpfrag Multipurpose Internet Mail Extensions (MIME) media type. This type is similar to application/sdp, but allows certain subsets of well formed session descriptions, as per the Session Description Protocol (SDP), to be represented instead of requiring a complete SDP session description. The "a=candidate" lines that are incrementally exchanged between Trickle ICE agents are one example usage of the application/sdpfrag. "Proposed Plan for Usage of SDP and RTP", Cullen Jennings, 25-Feb-13, This draft outlines a bunch of the remaining issues in RTCWeb related to how the the W3C APIs map to various usages of RTP and the associated SDP. It proposes one possible solution to that problem and outlines several chunks of work that would need to be put into other drafts or result in new drafts being written. The underlying design guideline is to, as much as possible, re-use what is already defined in existing SDP [RFC4566] and RTP [RFC3550] specifications. This draft is not intended to become an specification but is meant for working group discussion to help build the specifications. It is being discussed on the rtcweb@ietf.org mailing list though it has topics relating to the CLUE WG, MMUSIC WG, AVT* WG, and WebRTC WG at W3C. "Network Proxy Protocol", Sangjin Jeong, 25-Feb-13, In the current Internet, it is implicitly assumed that a network node is always active so that it can receive the incoming packets at any time. Current networking services and applications are commonly designed to be fully available at all times with minimal response times. This assumption keeps network nodes from entering sleeping mode in order to reduce energy consumption. Further, during sleeping mode, network nodes may not immediately respond to the incoming packets or even lose them. If network nodes are allowed to go into a sleeping mode, they can effectively reduce energy consumption during idle period. Network proxy allows to delegate network node's traffic processing to an external system within a network, so that the nodes maintain network presence during their sleep. This document describes communication mechanism between network nodes and proxy in order to accelerate the wider deployment of network proxy mechanism. "PIM Extensions for Protection Using Maximally Redundant Trees", Robert Kebler, Alia Atlas, Naiming Shen, Yiqun Cai, 18-Feb-13, This document specifies Protocol Independent Multicast (PIM) procedures for Failure Protection, as specified in the MRT Multicast architecture [I-D.atlas-rtwg-mrt-mc-arch-00]. This can be accomplished with Global Repair (aka Live-Live) or with Local Repair (aka Fast Re-route). Maximally Redundant Trees (MRTs) provide the capability to PIM to provide alternate paths around any given failure. "Securing the IP-based Internet of Things with DTLS", Sye Keoh, Sandeep Kumar, Oscar Garcia-Morchon, 25-Feb-13, The IP-based Internet of Things (IoT) refers to the pervasive interaction of smart devices and people enabling new applications by means of IP protocols. Traditional IP protocols will be further complemented by 6LoWPAN and CoAP to make the IoT feasible on small devices. Security and privacy are a must for such an environment. Due to mobility, limited bandwidth, resource constraints, and new communication topologies, existing security solutions need to be adapted. We propose a security architecture for the IoT in order to provide network access control to smart devices, the management of keys and securing unicast/multicast communication. Devices are authenticated and granted network access by means of a pre-shared key (PSK) based security handshake protocol. The solution is based on Datagram Transport Layer Security (DTLS). Through the established secure channels, keying materials, operational and security parameters are distributed, enabling devices to derive session keys and group keys. The solution relies on the DTLS Record Layer for the protection of unicast and multicast data flows. We have prototyped and evaluated the security architecture. The DTLS architecture allows for easier interaction and interoperability with the Internet due to the extensive use of TLS. However, it exhibits performance issues constraining its deployment in some network topologies and hence would require further optimizations. "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", Ari Keränen, Jonathan Rosenberg, 25-Feb-13, This document describes a protocol for Network Address Translator (NAT) traversal for UDP-based multimedia sessions established with the offer/answer model. This protocol is called Interactive Connectivity Establishment (ICE). ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN). ICE can be used by any protocol utilizing the offer/answer model, such as the Session Initiation Protocol (SIP). This document obsoletes RFC 5245. "", Ramin Khalili, Nicolas Gast, Miroslav Popovic, Jean-Yves Le Boudec, 18-Feb-13, This document describes the mechanism of OLIA, the "opportunistic linked increases algorithm". OLIA is a congestion control algorithm for MPTCP. The current congestion control algorithm of MPTCP, LIA, forces a tradeoff between optimal congestion balancing and responsiveness. OLIA's design departs from this tradeoff and provide these properties simultaneously. Hence, it solves the identified performance problems with LIA while retaining non-flappiness and responsiveness behavior of LIA [5]. "Model-Based Estimation of Streaming Performance", Ken Ko, 18-Feb-13, This memo defines metrics plus a methodology for post-measurement processing of sample metrics to evaluate network path performance relative to streaming video traffic. The metrics are based on established methodologies for TCP throughput testing. The post- processing methodology is based on a model of streaming traffic that allows a given sample metric to be evaluated against multiple sets of parameters representing different streaming rates, delays and buffering values. The results of the post-processing methodology are derived metrics that are suitable for statistical analysis. "IPv6 Prefix Properties", Jouni Korhonen, Basavaraj Patil, Sri Gundavelli, Pierrick Seite, Dapeng Liu, 25-Feb-13, This specification defines an extension to the IPv6 Neighbor Discovery protocol and the stateless address autoconfiguration procedure. The Prefix Information Option is extended with flag bits that describe the properties associated to the prefix. A new Classed Prefix Information Option is also defined to associate an advertised prefix with an additional meta data that the stateless address autoconfiguration procedure and end hosts can make use of. This specification updates RFC4861 and RFC4862. "UDP Entropy Tunnel for Softwire", Carlos Pignataro, Nagendra Kumar, Pradosh Mohapatra, Clarence Filsfils, 18-Feb-13, This document describes a method for encapsulatation of tunneled packets within UDP in order to provide per-flow entropy for load- balancing. The method is targeted for use with softwire mesh deployments that include routers which have support for load- balancing based on UDP ports and not fields in L2TPv3 or GRE. "Automating DNSSEC delegation trust maintenance", Olafur Gudmundsson, Warren Kumari, 25-Feb-13, This document describes a method to allow DNS operators to more easily update DNSSEC Key Signing Keys using DNS as communication channel. This document does not address the initial configuration of trust anchors for a domain. "Conditional Enablement of Configuration Nodes", Kent Watsen, 18-Feb-13, This memo presents a cross-cutting technique whereby a NETCONF server can support conditional enablement of configuration nodes. That is, whether the node is active or not depends on the evaluation of an expression. Two expression types are defined herein, one for latent configuration (present but not actualized) and another for temporal configuration (actualized based on time). This soluton presented is extensible so that additional expression types may be added in the future. "Requirements for the IETF Liaison Statement Tool", Eliot Lear, Spencer Dawkins, 18-Feb-13, This memo specifies requirements for the liaison statement tool used by IETF working group chairs, IESG members, and the IAB, as well as representatives of organizations that liaise to these IETF entities. "Supporting Source-Multiplexing of the Real-Time Transport Protocol (RTP) Payload for Generic Forward Error Correction", Jonathan Lennox, 18-Feb-13, The Real-Time Transport Protocol (RTP) Payload format for Generic Forward Error Correction (FEC), specified in RFC 5109, forbids transmitting FEC repair flows as separate sources in the same RTP session as the flows being repaired. This document updates RFC 5109 to lift that restriction, as long as the association between original and repair flows is properly signaled and negotiated. "A Taxonomy of Grouping Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources", Jonathan Lennox, Kevin Gross, 18-Feb-13, The terminology about, and associations among, Real-Time Transport Protocol (RTP) sources can be complex and somewhat opaque. This document describes a number of existing and proposed relationships among RTP sources, and attempts to define common terminology for discussing protocol entities and their relationships. This document is still very rough, but is submitted in the hopes of making future discussion productive. "DHCPv6/SLAAC Address Configuration Interaction Problem Statement", Bing Liu, Ron Bonica, 25-Feb-13, This document analyzes the host behavior of DHCPv6/SLAAC interaction issue. It reviews the standard definition of the host behaviors and provides the test results of current mainstream implementations. Some potential operational gaps of the interaction are also described. "Guidance of Using Unique Local Addresses", Bing Liu, Sheng Jiang, Cameron Byrne, 18-Feb-13, This document provides guidance of how to use ULA. It analyzes ULA usage scenarios and recommends use cases where ULA address may be beneficially used. "RSVP-TE Signaling Extension for Bandwidth availability", Hao Long, Min Ye, 18-Feb-13, Packet switching network usually contains links with variable bandwidth, e.g., copper, radio, etc. The bandwidth of such link is sensitive to external environment. Availability is typically used for describing the link during network planning. This document describes an extension for RSVP-TE signaling for setting up a LSP in a PSN network which contains variable bandwidth link by introducing an optional availability field in RSVP-TE signaling. "Considerations on IPv6 Address Assignment", Qiongfang Ma, Tianle Yang, 18-Feb-13, This document discusses general principles and rules of IPv6 address assignment and gives an example to illustrate. "RTCWeb data channel management", Jerome Marcon, 18-Feb-13, The Real-Time Communication in WEB-browsers (RTCWeb) working group is charged to provide protocols to support direct interactive rich communication using audio, video, and data between two peers' web- browsers. For the support of data communication, the RTCWeb working group has in particular defined the concept of bi-directional data channels over SCTP. How to transport application messages on these data channels seems straightforward (i.e. they can be carried as SCTP user messages), however it is yet to be decided how to establish and manage these data channels. This document specifies a method for this, which relies first on a lightweight and scalable out-of-band negotiation of data channel configurations (within the SDP offer/ answer exchange) and second on the signaling of the configuration in use in the SCTP user message itself. Once these configurations are negotiated, further creations of data channels can occur purely in- band by simply sending user messages, which avoids to define a new in-band data channel protocol. "WebRTC audio codecs for interoperability with legacy networks.", Xavier Marjou, Stephane Proust, Kalyani Bogineni, Roland Jesske, Miao Lei, Enrico Marocco, Espen Berger, 25-Feb-13, This document presents use-cases underlining why WebRTC needs AMR-WB, AMR and G.722 as additional relevant voice codecs to satisfactorily ensure interoperability with existing systems. It also presents a way forward that takes into consideration the concerns expressed against the addition of codecs besides Opus and G.711. It is especially recognized that unjustified additional costs on browsers must be avoided. Therefore, the proposed solution intends to fully rely on the codecs already supported on the devices implementing the browsers and for which license and implementation costs have been already paid. It is expected that this way forward will significantly limit the costs and technical impacts on browsers while greatly improving interoperability with legacy systems and overall quality. It intents to be considered as a good compromise beneficial to all parties and to the whole industry: the user quality experience will be optimized as a whole at limited additional costs without incurring high costs for both networks to support transcoding and browsers to support additional codecs. "Hash-Based Signatures", David McGrew, Michael Curcio, 25-Feb-13, This note describes a digital signature system based on cryptographic hash functions, following the seminal work in this area. It specifies a one-time signature scheme based on the work of Lamport, Diffie, Winternitz, and Merkle (LDWM), and specifies a general signature system using a Merkle tree. These systems provide asymmetric authentication without using large integer mathematics and achieve a high security level. They are suitable for compact implementations, are relatively simple to implement, and naturally resist side-channel attacks. Unlike most other signature systems, hash-based signatures would still be secure even if it proves feasible for an attacker to build a quantum computer. "Topology API Requirements", Jan Medved, Stefano Previdi, Hannes Gredler, Thomas Nadeau, Shane Amante, 18-Feb-13, This document describes requirements for collecting topology data from network elements and other sources, creating a coherent view of the network topology from the collected data, and presenting the topology view to various applications that need to: a) understand the topology; and, b) leverage topology information in order to improve application specific mechanisms such as path selection, resources reservation, etc. "Loss and Delay Measurement in Transparent Interconnection of Lots of Links (TRILL)", Tal Mizrahi, Tissa Senevirathne, Samer Salam, Donald Eastlake, 18-Feb-13, Performance Monitoring (PM) is a key aspect of Operations, Administration and Maintenance (OAM). It allows network operators to verify the Service Level Agreement (SLA) provided to customers, and to detect network anomalies. This document specifies mechanisms for Loss Measurement (LM) and Delay Measurement (DM) in TRILL networks. "A Framework for SDP Attributes when Multiplexing", Suhas Nandakumar, 25-Apr-13, The Session Description Protocol (SDP) provides mechanisms to describe attributes of multimedia sessions and of individual media streams (e.g., Real-time Transport Protocol (RTP) sessions) within a multimedia session. In the RTCWeb WG, there is a need to use a single 5-tuple for sending and receiving media associated with multiple media descriptions ("m=" lines). Such a requirement has raised concerns over the semantic implications of the SDP attributes associated with the RTP Sessions multiplexed over a single transport layer flow. The scope of this specification is to provide a framework for analyzing the multiplexing characteristics of SDP attributes. The specification also categorizes existing attributes based on the framework described herein. "Glareless addition of media to existing RTCWeb Sessions", Suhas Nandakumar, Cullen Jennings, 18-Feb-13, The RFC3264 Offer/Answer model specifies rule for the bilateral exchange of Session Description Protocol (SDP) [RFC4566] messages for setting up, updating and tearing down of multimedia streams. Rarely, there might be situations wherein either of the communicating parties, might end up being the offerer for updating an on-going session. This scenario is commonly known as "glare" condition and it needs to be handled nevertheless. This specification describes procedures for parties involved in an ongoing RTCWeb session to add new media in a glareless fashion. There are various ways this problem might be solved - this draft sketches out one possible solution to the problem. "Common Template for HTTP Message-based Multi-hop Authentication", Yutaka Oiwa, Hajime Watanabe, Hiromitsu Takagi, Boku Kihara, Tatsuya Hayashi, Yuichi Ioku, 18-Feb-13, This document specifies a common protocol design template for authentication on the Hyper-text Transport Protocol (HTTP) involving multi-hop message exchanges. To facilitate advanced authentication technologies such as hash-based exchanges, zero-knowledge password proof, or public-key authentications on HTTP, a kind of state management and key management facilities are required on the general HTTP authentication message framework. Also, to optimize performance of such authentication schemes, a well-designed mechanism for key caching and re-authentication are needed. The template defined in this document provides a generic foundation for implementing such advanced authentication technologies. "On the Use of RTP Control Protocol (RTCP) Feedback for Unicast Multimedia Congestion Control", Colin Perkins, 18-Feb-13, This memo discusses the types of congestion control feedback that it is possible to send using the RTP Control Protocol (RTCP), and their suitability of use in implementing congestion control for unicast multimedia applications. "Using Interactive Connectivity Establishment (ICE) with Session Description Protocol (SDP) offer/answer and Session Initiation Protocol (SIP)", Marc Petit-Huguenin, Ari Keränen, 25-Feb-13, This document describes how Interactive Connectivity Establishment (ICE) is used with Session Description Protocol (SDP) offer/answer and Session Initiation Protocol (SIP). "Lawful-Intercept Support for SP Wi-Fi Deployments", Byju Pularikkal, Sri Gundavelli, Mark Grayson, Rajat Ghai, 13-Mar-13, Lawful Intercept stands for legally authorized capture & delivery of subscriber communications data by a communications provider to a law enforcement agency.This document describes Generic Lawful Intercept Architecture Models & implementation considerations for Service Provider Wi-Fi deployments. "Entropy label for seamless MPLS", Ravi Singh, Yimin Shen, John Drake, 18-Feb-13, This document describes how entropy labels can be used for load balancing in a seamless MPLS architecture. The definition of the control plane and data plane behavior at LSP stitching points; and at the ingress of an LSP in a hierarchy of LSPs, as described in this document, brings the benefits of entropy labels to seamless MPLS as MPLS deployments proliferate in the access and aggregation networks. This document updates RFC 6790. "YANG modifications for I2RS", Rex Fernando, pals, Muthumayan Madhayyan, Alex Clemm, 18-Feb-13, Interface to Routing Systems (I2RS) provides the mechanisms for the programmatic access of routing system components. YANG [RFC 6020] is a modeling language that is used to specify an external visible data model of sub-system - for defining both configuration and operational data held in the networking device. NETCONF is the protocol that is used to perform these configurations and accessing the operational data. This document proposes to use the YANG data modeling language for I2RS data models. It also proposes a set of YANG language changes to enable the I2RS data models for multi-client and programmatic access. This document also proposes the scope for the I2RS programmed data set on the Routing System and the necessary mechanisms for data synchronization. This document also recommends a binary encoding for "on-the-wire" transfer of the YANG data model elements instead of XML. "Virtual Topologies for Service Chaining in BGP IP VPNs", Rex Fernando, Dhananjaya Rao, Luyuan Fang, Maria Napierala, So Ning, 25-Feb-13, This document presents the techniques built upon BGP/MPLS IP VPN control plane mechanisms to construct virtual service topologies for service chaining. These virtual service topologies allow a sequence of service nodes to be visited across multiple zones in a data center to form a service chain. The method uses service topology specific Route Targets (RTs) in addition to general purpose RTs. Provisioning with Software Defined Network (SDN) controller is discussed in this document. "Priority Modification for the PSC Linear Protection", Jeong-dong Ryoo, Huub van Helvoort, Alessandro D'Alessandro, 18-Feb-13, This document contains the modifications to the priorities of inputs in [RFC6378], "MPLS Transport Profile (MPLS-TP) Linear Protection" in an effort to satisfy the ITU-T's protection switching requirements and correcting the problems that have been identified. "IP Inter-Subnet Forwarding in E-VPN", Ali Sajassi, Samer Salam, Yakov Rekhter, John Drake, 25-Feb-13, E-VPN provides an extensible and flexible multi-homing VPN solution for intra-subnet connectivity among hosts/VMs over an MPLS/IP network. However, there are scenarios in which inter-subnet forwarding among hosts/VMs across different IP subnets is required, while maintaining the multi-homing capabilities of E-VPN. This document describes an IRB solution based on E-VPN to address such requirements. "Access Token as per Client Password for Non-Web Protocols", Nat Sakimura, Boku Kihara, Kazuki Shimizu, 25-Feb-13, This specification describes the usage of the access token as a per client "password" for non-web clients that utilizes password based authentication, and the mechanism to issue such access tokens. Since the access token is used as the password for the client, the existing client application can be used as-is without any change, which is a considerable advantage for the deployment. "Structured Access Token for Sharing Authorization Grant between a Resource Server and an Authorization Server", Nat Sakimura, Boku Kihara, Kazuki Shimizu, 25-Feb-13, This specification defines a format of structured access tokens that are issued by the authorization server and received by the resource server. By using this format, the authorization server and the resource server can be easily separated and the validation of the access token can be performed offline. "Security Bootstrapping Solution for Resource-Constrained Devices", Behcet Sarikaya, 18-Feb-13, We present a solution to initially configure the network of resource constrained nodes securely, a.k.a., security bootstrapping. The solution is based on EAP-TLS authentication with the use of raw public keys as certificates. "Virtual Machine Mobility Protocol Using Distributed Proxy Mobile IPv6", Behcet Sarikaya, Linda Dunbar, 18-Feb-13, This document specifies a new IP level protocol for seamless virtual machine mobility in data centers. Source Hypervisor registers the newly created virtual machine with the centrally available management node. When the virtual machine moves to the destination Hypervisor, the destination Hypervisor updates the virtual machine record in the management node. Management node sends registration message to all previous source Hypervisors in order to direct the ongoing traffic to the destination Hypervisor. Cold and hot virtual machine mobility are achieved using dynamic domain name system update and host routes. Both intra data center and inter data center hot virtual machine mobility solutions are presented. "A Network Virtualization Overlay Solution using E-VPN", Ali Sajassi, John Drake, Nabil Bitar, Aldrin Isaac, James Uttaro, Wim Henderickx, 25-Feb-13, This document describes how E-VPN can be used as an NVO solution and explores the various tunnel encapsulation options over IP and their impact on the E-VPN control-plane and procedures. In particular, the following encapsulation options are analyzed: MPLS over GRE, VXLAN, and NVGRE. "ALTO for LMAP", Jan Seedorf, Vijay Gurbani, Enrico Marocco, 18-Feb-13, In the context of Large-Scale Measurement of Broadband Performance (LMAP), measurment results are currently made available to the public either at the finest granularity level (e.g. as a list of results of all individual tests), or in a very high level human-readable format (e.g. as PDF reports). This document argues that there is a need for an intermediate way to provide access to large-scale network measurement results, flexible enough to enable querying of specific and possibly aggregated data. The Application-Layer Traffic Optimization (ALTO) Protocol, defined with the goal to provide applications with network information, seems a good candidate to fulfill such a role. "CoAP Communication with Alternative Transports", Bilhanan Silverajan, Teemu Savolainen, 25-Feb-13, CoAP is being standardised as an application level REST-based protocol. A single CoAP message is typically encapsulated and transmitted using UDP. This draft examines the requirements and possible solutions for conveying CoAP packets to end points over alternative transports to UDP. While UDP remains an optimal solution for use in IP-based constrained environments and nodes, M2M communication using non-IP networks, NAT and firewall traversal issues and possibly mechanisms incurring a lower overhead to CoAP/ HTTP gateways provide compelling motivation for understanding how CoAP can operate in various other environments. "Infrastructure to Application Information Exposure", Haibin Song, Young Lee, 22-Feb-13, This document describes the scenarios that applications can use the network layer especially the network routing system exposed information, so as to optimize application layer traffic. The use cases in this document include the ISP broadband network (using P2P and CDN as examples) and the data center network. This document also describes what information should be collected for ALTO service for traffic optimization. "A New Data Chunk for Stream Control Transmission Protocol", Randall Stewart, Michael Tuexen, Salvatore Loreto, 24-Feb-13, The Stream Control Transmission Protocol (SCTP) is a message oriented transport protocol supporting arbitrary large user messages. However, the sender can not interleave different user messages which which causes head of line blocking at the sender side. To overcome this limitation, this document adds a new data chunk to SCTP. "Dynamic Host Configuration Protocol version 6 (DHCPv6) Option for IPv4 Configuration", Qi Sun, Yong Cui, 18-Feb-13, This document defines a DHCPv6 option with two types of sub-options for IPv4 configurations in the case of IPv4/IPv6 transition. One is used for the assignment of IPv4 address and port set, the other is used for configuring existing DHCPv4 options required by clients for IPv4-over-IPv6 communications. "Make-Before-Break MPLS-TE LSP restoration and reoptimization procedure using Stateful PCE", Yosuke Tanaka, Yuji Kamite, 18-Feb-13, Stateful PCE (Path Computation Element) and its corresponding protocol extensions provide a mechanism that enables PCE to do stateful control of MPLS Traffic Engineering Label Switched Paths (TE LSP). Stateful PCE supports manipulating the existing LSP's state and attributes (e.g., bandwidth and route) and also creating totally new LSPs in the network. In the current MPLS TE network using RSVP-TE, LSPs are often controlled by "make-before-break (M-B-B)" signaling by headend for the purpose of LSP restoration and reoptimization. In most cases, it is an essential operation to reroute LSP traffic without any data disruption. This document specifies the procedure of applying Stateful PCE's control to make-before-break RSVP-TE signaling. In this document, two types of restoration/reoptimization procedures are defined, one- stroke mode and granular mode. This document also specifies the usage and handling of stateful PCEP (PCE Communication Protocol) messages, expected behavior of PCC as RSVP-TE headend and several extensions of additional objects. "Experience of Designing Network Management System", Yasuhiro TERAMOTO, Ray Aatarashi, Yoshifumi Atarashi, Yasuo Okabe, 25-Feb-13, This document describes our experiences from designing and implementing a large-scale local area network management system using mainly NETCONF. We designed the data models for device configurations and implemented NETCONF client to centrally control multiple devices of various vendors. The document provides insight on strong and weak points of current NETCONF approach. The document also makes some recommendations about NETCONF and future network management protocols. "Example IPR License Terms", Timothy Terriberry, 18-Feb-13, This draft gives provides an example set of licensing terms for use in IPR disclosures that are compatible with the goals of the proposed video-codec working group for further discussion and refinement by participants at the IETF. Although usage of such a license is strictly voluntary, the hope is that getting agreement on a set of terms before the bulk of the work begins will allow contributors to use a common license and minimize the amount of legal analysis that must be performed in order to deploy the codec. "Data Channels for RTCWEB", Martin Thomson, 18-Feb-13, RTCWEB have selected SCTP over DTLS over UDP with ICE for peer-to- peer data channels. There is some debate over the best way to negotiate channels. This proposal is a nose-to-tail description of an alternative to existing proposals. "IPv6 Multihoming with Source Address Dependent Routing (SADR)", Ole Troan, Lorenzo Colitti, 18-Feb-13, A multihomed network using provider aggregatable addresses must send the packet out the right path to avoid violating the provider's ingress filtering. This memo suggests a mechanism called Source Address Dependent Routing to solve that problem. "Authentication Issues in Network Virtualization Overlays", Zehn Cao, Gang Chen, 18-Feb-13, This document describes the issues of authenticating a new end-device in a virtual data center. This short document tries to initiate the discussion about the authentication issues in the virtualized data centers. "Diameter AVP Level Security: Requirements and Scenarios", Hannes Tschofenig, Jouni Korhonen, Glen Zorn, 18-Feb-13, This specification discusses requirements for providing Diameter security at the level of individual Attribute Value Pairs. "A Keying Database for Diameter End-to-End Security", Hannes Tschofenig, 18-Feb-13, The Diameter Base specification offers security protection between neighboring Diameter peers using TLS, DTLS, and IPsec. The development of a solution to protect Diameter Attribute Value Pairs between non-neighboring nodes is currently work in progress. Diameter nodes maintain different types of databases, depending on their functions. Examples include the peer table and the realm-based routing table. This document describes a conceptual model for a keying database as it would be used by a Diameter node to determine what AVPs to protect, and what keys / algorithms to use. On the receiving side it allows the receiving node to select the appropriate security association for verifying the protected AVPs. The design is similar to IPsec and inspired by the routing protocol security key table. "OAuth 2.0: Audience Information", Hannes Tschofenig, 18-Feb-13, The OAuth 2.0 Bearer Token specification allows any party in possession of a bearer token to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, two important security assumptions must hold: bearer tokens must be protected from disclosure in storage and in transport and the access token must only be valid for use with a specific resource server (the audience) and with a specific scope. This document defines a new header that is used by the client to indicate what resource server, as the intended recipient, it wants to access. This information is subsequently also communicated by the authorization server securely to the resource server, for example within the audience field of the access token. "SCIM Profile For Enhancing Just-In-Time Provisioning", Mark Wahl, 18-Feb-13, This document specifies a profile of the System for Cross-Domain Identity Management Protocol (SCIM) for use by servers which rely upon just-in-time provisioning patterns in a protocol (such as SAML) to create user accounts, and need an additional channel to be notified of changes to user accounts. "Container Resolution System in ICN", Rong Wang, Chunfeng Yao, Zhefeng Yan, 18-Feb-13, We illustrate the architecture and mechanism of container resolution system, and to the protocol of resolving containers in ICN. The fundamental characters are:1)Use Interest and Data packet as the communication primitives, 2)Every routing node has FIB, CS, PIT tables to do packet routing and caching. Current NDN/CCN architecture does not require a resolution system. The routing is totally based on prefixes of content names, which causes scalability and mobility issues described in [Cisco-Name]. This draft addresses the aforementioned issues. "Use Cases for an Interface to the Routing System", Russ White, Susan Hares, Rex Fernando, 18-Feb-13, Programmatic interfaces to provide control over individual forwarding devices in a network promise to reduce operational costs while improving scaling, control, and visibility into the operation of large scale networks. To this end, several programmatic interfaces have been proposed. OpenFlow, for instance, provides a mechanism to replace the dynamic control plane processes on individual forwarding devices throughout a network with off box processes that interact with the forwarding tables on each device. Another example is NETCONF, which provides a fast and flexible mechanism to interact with device configuration and policy. There is, however, no proposal which provides an interface to all aspects of the routing systemas a system. Such a system would not interact with the forwarding system on individual devices, but rather with the control plane processes already used to discover the best path to any given destination through the network, as well as interact with the routing information base (RIB), which feeds the forwarding table the information needed to actually switch traffic at a local level. This document describes a set of use cases such a system could fulfill. It is designed to provide underlying support for the framework, policy, and other drafts describing the Interface to the Routing System (IRS). "Proposed Control Plane requirements for Network Virtualization Overlays", Qin Wu, 23-Apr-13, This document focuses on control plane aspect related to both tenant system to NVE control interface and NVE to Network Virtualization Authority (NVA) control interface NVE use to enable communication between tenant systems, which is complementary to [draft-kreeger-nvo3-hypervisor-nve-cp] that describes the high level control plane requirements related to the interaction between tenant system and NVE when the two entities are not co-located on the same physical device. "RTP/RTCP extension for RTP Splicing Notification", Jinwei Xia, Rachel Huang, 20-Feb-13, Content splicing is a process that replaces the content of a main multimedia stream with other multimedia content, and delivers the substitutive multimedia content to the receivers for a period of time. The RTP mixer is designed to handle RTP splicing in [RFC6828], but how the RTP mixer knows when to start and end the splicing is still unspecified. This memo defines two RTP/RTCP extensions to indicate the splicing related information to the RTP mixer: an RTP header extension that conveys the information in-band and an RTCP packet that conveys the information out-of-band. "Coordinated Forwarding and Caching in Information-Centric Networks", Haiyong Xie, Yi Sun, Yunfei Zhang, Haibin Zhai, Hanwen Zhang, 18-Feb-13, Content caching plays an important role in Information-Centric Networking (ICN). Many of current ICN designs adopt a limited, en- route hierarchical caching mechanism; additionally, caching and forwarding are largely uncoordinated in these designs. This draft describes a coordinated caching and forwarding design to improve content access cost and cache miss rate of ICN. "Scalable Hybrid Routing for Information-Centric Networks", Haiyong Xie, Yi Sun, Guoqiang Wang, Haibo Wu, Jun Li, 18-Feb-13, Name-based routing in information-centric networks faces many challenges, one of which is the scalability challenge; in particular, content routers may not have sufficiently large FIB to store a large portion of name prefixes, even if the latter are aggressively aggregated. In many ICN designs routers have to rely on inefficient mechanisms (e.g., Interest broadcast in content-centric networks) in order to route requests. In this draft, we describe a hybrid, reactive routing approach, where we augment the information-centric network design with an Infrastructure Information Base (IIB) to reap the benefits of both name-based and infrastructure-based routing. Simulation-based evaluations demonstrate that this scheme can significantly improve the network scalability by cutting down the number of broadcast packets while maintaining the same level of the user-perceived latency. "Two Dimensional-IP Routing Protocol in Home Networks", Mingwei Xu, Shu Yang, Jianping Wu, Dan Wang, 18-Feb-13, Home netowrk design faces many challenges currently. Two of them are multi-homing and policy enforcement. Different with other types of networks, home network operators are usually not professional technicians or geeks. The problems we face are fundamentally related with the poor semantics provided by current destination-based routing protocol. TwoD-IP routing protocol is a link state routing protocol that makes routing decisions based on both destination and source addresses. This document describes the mechanism for supporting flexible multi- homing and policy routing across home networks. "DHCP option for STA Location Information", Li Xue, Behcet Sarikaya, 25-Feb-13, This document introduces WTP information transported using DHCPv4/v6. In this procedure, DHCPv4/v6 snooping is deployed on the WTP node or AC node. Then the WTP information can be inserted into the extension option of DHCPv4/v6 message. GW obtain the WTP information of the subscriber through which the subscriber accesses network. "DHCPv4 and DHCPv6 options for Access Point Location Information", Li Xue, Behcet Sarikaya, 18-Feb-13, This document introduces Control and Provisioning of Wireless Access Points Wireless Termination Point information transported using DHCP. In this procedure, DHCP snooping is deployed on the Wireless Termination Point node or Access Controller node. Then the Wireless Termination Point information can be inserted into the DHCP message in extension option. Because the DHCP messages is send out from the subscriber, so binding between Wireless Termination Point information and subscriber is set up after this procedure. Then Gateway obtains the Wireless Termination Point information through the subscriber access network. "RADIUS Extensions for Key Management in WLAN network", Li Xue, 18-Feb-13, In order to guarantee the security and integration of the subscriber in WLAN network, Pairwise Master Key (PMK) will be generated as an access authorization token during the mutual authentication procedure between station (STA) and authenticator server (AS). Then, the PMK and 4-way handshake are used between STA and Authenticator to derive, bind and verify the Pairwise Transient Key (PTK), which is a collection of operational keys for security. Also,Group Transient Key (GTK) can be derived, and is used to secure multicast/broadcast traffic. In the authentication architecture, only STA and AS can manufacture PMK, moreover, AS can only distribute PMK to Authenticator.However, if the authenticator function is not collocated with the encryption/decryption function, it is difficult to achieve traffic encryption/decryption in WLAN network.The purpose of this document is to analyze the requirement and issue for key management that have arisen so far during STA authentication process in WLAN network. Meanwhile, the control messages for key management are defined. "simple VPN solution using Multi-point Security Association", Arifumi Yamaya, Ken Ueki, Tomoki Murai, 18-Feb-13, This document describes the over-lay network solution by utilizing dynamically established IPsec multi-point Security Association (SA) without individual connection. Multi-point SA technology provides the simplified mechanism of the Auto Discovery and Configuration function. This is applicable for any IPsec tunnels such as IPv4 over IPv4, IPv4 over IPv6, IPv6 over IPv4 and IPv6 over IPv6. "Container Assisted Naming and Routing for ICN", Chunfeng Yao, Rong Wang, Yuanzhe Xuan, Zhefeng Yan, 18-Feb-13, In ICN (Information-centric network), everything is an identifiable object with a name, therefore the number of name prefixes is a few orders of magnitude higher than that in current BGP routing table. Towards scalable routing in ICN, we propose a name scheme, called container assisted naming. With this scheme, an object name consists of two components: a content name which uniquely specifies the object within certain scope, and one or more containers which define access relationships to the object. This document illustrates the concept of container and how it assists scalable routing in ICN. "Managing SSH Keys for Automated Access - Current Recommended Practice", Tatu Ylonen, Greg Kent, 3-Apr-13, This document presents current recommended practice for managing SSH user keys for automated access. It provides guidelines for discovering, remediating, and continuously managing SSH user keys and other authentication credentials. Various threats from poorly managed SSH keys are identified, including virus spread, unaudited backdoors, illegitimate access using leaked keys, lack of proper termination of access, use of legitimate access for unintended purposes, and accidental human errors. Hundreds of thousands, even over a million SSH keys authorizing access have been found from the IT environments of many large organizations. This is many times more than they have interactive users. These access-granting credentials have largely been ignored in identity and access management, and present a real risk to information security. A process is presented for discovering who has access to what, bringing an existing IT environment under control with respect to automated access and SSH keys. The process includes moving authorized keys to protected locations, removing unused keys, associating authorized keys with a business process or application and removing keys for which no valid purpose can be found, rotating existing keys, restricting what can be done with each authorized key, and establishing an approval process for new authorized keys. A process is also presented for continuous monitoring and controlled authorized key setup. Finally, recommendations are made for security policy makers for ensuring that automated access and SSH keys are properly addressed in an organization's security policy. Specific requirements are presented that address the security issues while keeping costs reasonable. Guidance is also provided on how to reduce operational cost while addressing the threats and how to use tools to automate the management process. "OSPF Extensions for Link State Database Synchronization Group", Gang Yan, Yuanjiao Liu, Xudong Zhang, 18-Feb-13, This document describes a special scheme of OSPF Database synchronization by dividing OSPF Routers into different groups and preventing OSPF Routers from different groups to synchronize, this scheme can help to enhance the number of OSPF adjacencies and the capability of deploying OSPF on large network. "Variant Label Resource Record", Yoshiro Yoneya, 24-Feb-13, Definition and operation of variant domain names are differ from zone administrators, and there is no generic rules, therefore, in general, it is hard to guess variant labels for end users and / or applications. Meanwhile, zone administrators are understanding all variant labels list because they generate variant labels and activate them according to rules they defined. Thus, if there is a mechanism that end users and / or applications can obtain variant labels list from zone administrators, then it would be useful. The Variant Labels Resource Record (VL RR) provides such variant labels list for that purpose. "TRILL Over Pseudo Wires", Lucy Yong, Donald Eastlake, Sam Aldrin, Jon, 18-Feb-13, This document describes ways to interconnect a pair of TRILL (Transparent Interconnection of Lots of Links) switch ports with two types of pseudo wires under existing TRILL and PWE3 (pseudowire Emulation End-to-End) standards. "Kerberos Ticket flag indicating KDC support for resolving hostname aliases", Tom Yu, 18-Feb-13, This document specifies a Kerberos Ticket flag that indicates that the Key Distribution Center (KDC) can resolve hostname aliases in service principal names. This document updates RFC 4120. "Encapsulation of EAP Messages in CAPWAP Control Plane", Rong Zhang, Zehn Cao, Haiyun Luo, Hui Deng, Sri Gundavelli, 18-Feb-13, This document describes the scenario and requirement of encapsulating Extensible Authnetication Protocol (EAP) in the CAPWAP control plane. After the analysis and description, this document proposes the design of the new message types to encapsulate EAP messages. "Registration Data Access Protocol RESTful Searching", Linlin Zhou, Ning Kong, Sean Shen, 18-Feb-13, This document describes the searchability details of the Registration Data Access Protocol (RDAP). It specifies basic and extended searching parameters, defines the JSON (JavaScript Object Notation) formats of searching and responding data structure and also proposes the specification of boolean search functionality. "IEEE 802.21 Overview", Juan Zuniga, Pierrick Seite, 18-Feb-13, Some of the messages described in [I-D.ietf-mif-api-extension] may rely on functionalties provided by lower layers. The IEEE 802.21 specification defines an abstraction of lower layer functions that can be useful for the MIF-API. This document provides an overview of the 802.21 specification and enumerates a subset of functions that can be used in the context of the MIF API to interact with lower layers. "Global Table Multicast with BGP-MVPN Procedures", Jeffrey Zhang, Leonard Giuliano, Dante Pacella, 18-Feb-13, This document describes a way to implement Global Table Multicast, aka Internet Multicast, using BGP encodings and procedures for MVPN as specified in [RFC6514]. No protocol modification/extension is required. This is purely for informational and clarifying purposes only. "Network Management of Mobile Ad hoc Networks (MANET): Architecture, Use Cases, and Applicability", James Nguyen, Robert Cole, Ulrich Herberg, Jiazi Yi, Justin Dean, 19-Feb-13, This document aims at providing an extended architecture, use case and applicability statement for management of MANETs, as a guideline for how to manage MANETs. This document describes different management activities, such as network configuration, monitoring of state, monitoring of performance, fault management, and software upgrades. Different aspects of a MANET management architecture are illustrated (e.g., distributed vs. centralized management, flat vs. hierarchical management, management of an entire network vs. an individual router, etc.) and contrasted to the NMS architecture in the Internet. A desciption of typical MANET use cases relevant for management is followed by an overview of current standard management protocols that can be used in MANETs. "PID: A Generic Naming Schema for Information-centric Network", Xinwen Zhang, Ravi Ravindran, Haiyong Xie, Guoqiang Wang, 20-Feb-13, In Information-centric network (ICN), everything is an identifiable object with a name such as a named data chunk. Different from host- centric connectivity, ICN connects named entities using name-based routing and forwarding. At the same time, network entities, end devices, and applications have variant demands to verify the integrity and authenticity of these entities through names. This document proposes a generic naming schema, called PID, which supports trust provenance, content lookup, routing, and inter-domain resolution for ICN. With PID schema, a name consists of three components: principal(s), identifier(s), and domain(s). In this draft, we only illustrate the principles and concepts of PID and the functional role of each component, and leave encoding approaches as implementation options. "A Policy Framework for the Interface to the Routing System", Alia Atlas, Susan Hares, Joel Halpern, 27-Feb-13, A key aspect of the Interface to the Routing System (I2RS) is what mechanisms it includes to carry policy information and to enable policy control. This applies both in the protocol itself and in the services associated with the different components of the routing system. Similarly, the data-models associated with the services must be capable of expressing the appropriate granularity for access and authorization-related policy. This document describes the policy framework for I2RS. "Interface to the Routing System Problem Statement", Alia Atlas, Thomas Nadeau, David Ward, 27-Feb-13, As modern networks grow in scale and complexity, the need for rapid and dynamic control increases. With scale, the need to automate even the simplest operations is important, but even more critical is the ability to quickly interact with more complex operations such as policy-based controls. In order to enable applications to have access to and control over information in the Internet's routing system, we need a publicly documented interface specification. The interface needs to support real-time, transaction-based interactions using data models and encodings that are efficient and potentially different from those available today. Furthermore, the interface must be tailored to support a variety of use cases. This document expands upon these statements of requirements to provide a detailed problem statement for an Interface to the Internet Routing System (I2RS). "Interface to the Routing System Framework", Alia Atlas, Thomas Nadeau, David Ward, 27-Feb-13, This document describes a framework for a standard, programmatic interface for full-duplex state transfer in and out of the Internet's routing system. It provides some basic use-cases, lists the type of information that might be exchanged over the interface, and describes suggested functionality for the interface to the Internet routing system. "Enhanced Interior Gateway Routing Protocol", Donald Slice, Steven Moore, James Ng, Russ White, Donnie, 28-Feb-13, This document describes the protocol design and architecture for Enhanced Interior Gateway Routing Protocol (EIGRP). EIGRP is a routing protocol based on Distance Vector technology. The specific algorithm used is called DUAL, a Diffusing UPDATE Algorithm[4]. The algorithm and procedures were researched, developed, and simulated by SRI International. "Multicast UDP Usage Guidelines for Application Designers", Greg Shepherd, 8-Mar-13, The multi-recipient nature of Multicast prevents the use of any pont- to-point connection-oriented transport, therefore restricts all Multicast data to be sent over the User Datagram Protocol (UDP). UDP provides a minimal message-passing transport that has no inherent congestion control mechanisms. Because congestion control is critical to the stable operation of the Internet, applications and upper-layer protocols that choose to use Multicast UDP as an Internet service must employ mechanisms to prevent congestion collapse and to establish some degree of fairness with concurrent traffic. This document provides guidelines on the use of UDP for the designers of multicast applications and higher-level protocols. "PSC protocol updates for non-revertive operation", Tae-sik Cheung, Alessandro D'Alessandro, Huub van Helvoort, 10-Mar-13, This document contains the updates to [RFC6378], "MPLS Transport Profile (MPLS-TP) Linear Protection" to change non-revertive operation to be aligned with the behavior defined in [RFC4427] and in an effort to satisfy the ITU-T's protection switching requirements. An operator command, Manual Switch to Working (MS-W) is also included to revert traffic to the working path in non-revertive operation. "Benchmarking Neighbor Discovery Problems", William Cerveny, 10-Mar-13, This document is a benchmarking instantiation of RFC 6583: "Operational Neighbor Discovery Problems". It describes a general testing procedure and measurements that can be performed to evaluate how the problems described in RFC 6583 may impact the functionality or performance of intermediate nodes. "Interoperability between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP)", Chris Christou, Michael Lundberg, Christopher Ross, Peter Saint-Andre, 10-Mar-13, This document is intended to serve as a reference point for developers and operators implementing the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP) within their networks. This document does not define any new protocols but does define the different reference models for deployment of combined use of SIP and XMPP ("CUSAX") clients and SIP- XMPP interworking to ensure consistency across the community. "E164/214 MPBGP announcement", Shu Ge, 10-Mar-13, Recently, transferring the signaling of mobile network over IP attracts lots of attention from people. Telephone number based on E.164 or E.214 or SP is the traditional routing address for mobile network, but actually, E.164, E.214 and SP is not supported by MP-BGP protocol. This document presents a new way to support for routing the phone number based on E.164, E.214 or SP though MP-BGP, by extending the MP-BGP for the Phone Number Routing. It can bring optimizing for the network architecture and improving efficiency. "Distributed Mobility Management: Service flows distribution and handoff technique based on MIPv6", Liu Min, Yuwei Wang, 10-Mar-13, This document has a normative description of the service flows based on IPv6. It makes the upgrade of management model from the entire node granularity to the single service flow granularity, with the compatibility to the existing mobile IPv6. It shows a distributed, compatible with mobile IPv6 network layer mobility solution, which would take different mobility management strategies according to the Correspondent Node's position, network conditions and service requirements of the different service flows so as to achieve the service flow granularity switching and transmission path control. And the standard will also provide route optimization mechanism between the Mobile Node and the ordinary Correspondent Node that doesn't support mobile IPv6, playing a role in promoting the development of new applications and business based on mobile IPv6. "Instant Messaging and Presence Purpose for the Call-Info Header Field in the Session Initiation Protocol (SIP)", Peter Saint-Andre, 14-May-13, This document defines and registers a value of "impp" ("instant messaging and presence protocol") for the "purpose" header field parameter of the Call-Info header field in the Session Initiation Protocol (SIP). "Multi-Upstream Interfaces IGMP/MLD Proxy", Hong-Ke Zhang, Thomas Schmidt, 10-Mar-13, In this document, followed by the idea mentioned in [4] and subsequent update in [5], an IGMP/MLD proxy with multiple upstream interfaces called MUIIMP is proposed and analyzed. The MUIIMP inherits the basic rule of the IGMP/MLD proxy but extends with multiple upstream interfaces. To avoid data redundancy, each upstream interface of an MUIIMP device MUST NOT send or subscribe the same data simultaneously. "Attribute-Value Pairs For Provisioning Customer Equipment Supporting IPv4-Over-IPv6 Transitional Solutions", Cathy Zhou, Tom Taylor, 10-Mar-13, During the transition from IPv4 to IPv6, customer equipment may have to support one of the various transition methods that have been or are currently being defined for carrying IPv4 packets over IPv6. Work is currently in progress to enumerate the information that needs to be provisioned on a customer edge router to support a list of transition techniques based on tunneling IPv4 in IPv6, with a view to defining reusable components for a reasonable transition path between these techniques. To the extent that the provisioning is done dynamically, AAA support is needed to provide the information to the network server responsible for passing the information to the customer equipment. This document specifies Diameter attribute-value pairs to be used for that purpose. "mLDP extensions for integrating EVPN and multicast", David Allan, Jeff Tantsura, 11-Mar-13, This document describes how mLDP FECs can be encoded to support both service specific and shared multicast trees and describes the associated procedures for EVPN PEs. Thus, mLDP can implement multicast for EVPN. "LISP Based FlowMapping for Scaling NFV", sbarkai@gmail.com, Dino Farinacci, David Meyer, Fabio Maino, Vina Ermagan, 22-May-13, This draft describes an RFC 6830 Locator ID Separation Protocol (LISP) based distributed flow-mapping-fabric for dynamic scaling of virtualized network functions (NFV). Network functions such as subscriber-management, content-optimization, security and quality of service, are typically delivered using proprietary hardware appliances embedded into the network as turn-key service-nodes or service-blades within routers. Next generation network functions are being implemented as pure software instances running on standard servers - unbundled virtualized components of capacity and functionality. LISP-SDN based flow-mapping, dynamically assembles these components to whole solutions by steering the right traffic in the right sequence to the right virtual function instance. "CDNi Control - Initialization and Bootstrapping", Taesang Choi, Young-Il Seo, Jongmin Lee, Ja-Ryeong Koo, John Shinn, Yong Bang, 11-Mar-13, This document proposes a mechanism for a CDN to initiate the interconnection across CDNs and bootstrap the other CDNi interfaces. "Autonomous Extensible Internet with Network Address Translation(AEIP NAT)", Diao Yongping, Ming Liao, Yuping Diao, 11-Mar-13, The two key issues of today's Internet are autonomy and extensibility. Autonomous Internet(AIP) technology can provide extensible internet architecture, own independent root DNS servers and self management internet network; Furthermore, based on the Autonomous Internet, here provides a way with extensible address capacity to solve IP address deficiency and realize Autonomous Extensible Internet(AEIP). It mainly adopts local network address based on per Autonomous IP network and uses bilateral dynamic NAT with global network address between Autonomous IP networks to solve IP address deficient problem. This AEIP with Network Address Translation(AEIP NAT) can realize autonomy and extensibility with minimal cost. "Advice on network buffering", Gorry Fairhurst, Bob Briscoe, 11-Mar-13, This document proposes an update to the advice given in RFC 3819. Subsequent research has altered understanding of buffer sizing and queue management. Therefore this document significantly revises the previous recommendations on buffering. The advice applies to all packet buffers, whether in network equipment, end hosts or middleboxes such as firewalls or NATs. And the advice applies to packet buffers at any layer: whether subnet, IP, transport or application. "Delay Tolerant Networking Email Convergence Layer Protocol", Bjoern Gernert, Sebastian Schildt, 23-Apr-13, This document describes the protocol for the Email-based Convergence (MCL) Layer for Delay Tolerant Networking (DTN). "Painless Class 1 Devices Programming", Oliver Hahm, Emmanuel Baccelli, Kaspar Schleiser, 11-Mar-13, In order to fit the constraints of Class 0 devices (offering much less than 10KiB of RAM and 100KiB of ROM) there are no alternatives to implementing IP protocols in special software environments, which impose programming paradigms that make implementation of protocol specifications significantly more complex. However, our experience implementing RFC 4944 and RFC 6282, TCP and UDP on Class 1 devices (offering approximately 10KiB of RAM and 100KiB of ROM) shows that there are alternatives concerning software environments in which to implement IP protocols, which avoid such complexity by providing a more developer-friendly environment. This draft shares this experience. "I2RS overlay use case", fangwei hu, Bhumip Khasnabish, 11-Mar-13, This document proposes an overlay network use case. The forwarding routers network is an overlay structure. There are two kinds of forwarding routers: Edge Router(ER) and Core Routers(CR). Edge Router encapsulates format data based on the tunnel type, which are established among Edge Routers. Core Router would be very simple and cheap. It focus on the encapsulation data forwarding. In order to reduce the equipment cost of Edge Routers, the network virtualization is provided in this document. "RTCWEB Considerations for NATs, Firewalls and HTTP proxies", Thomas Stach, Andrew Hutton, Justin Uberti, 11-Mar-13, This document describes mechanism to enable media stream establishment in the presence of NATs, firewalls and HTTP proxies. HTTP proxy and firewall policies applied in many private network domains introduce obstacles to the successful establishment of media stream via RTCWEB. This document examines some of these policies and develops requirements on the web browsers designed to provide the best possible chance of media connectivity between RTCWEB peers. "Use Cases for an Interface to BGP Protocol", Keyur Patel, Rex Fernando, Hannes Gredler, Shane Amante, 11-Mar-13, A network routing protocol like BGP is typically configured and results of its operation are analyzed through some form of Command Line Interface (CLI) or NETCONF. These interactions to control BGP and diagnose its operation encompass: configuration of protocol parameters, display of protocol data, setting of certain protocol state and debugging of the protocol. Interface to the Routing System's (I2RS) Programmatic interfaces, as defined in [I-D.ward-i2rs-framework], provides an alternate way to control the configuration and diagnose the operation of the BGP protocol. I2RS may be used for the configuration, manipulation, polling or analyzing protocol data. This document describes set of use cases for which I2RS can be used for BGP protocol. It is intended to provide a base for the solution draft describing a set of interfaces to the BGP protocol. "Mark and Signed Mark Objects Mapping", Gustavo Lozano, 25-Mar-13, This document describes the format of a mark and a digitally signed mark, referred to as a signed mark and the Signed Mark Data (SMD) file as defined by the ICANN Trademark Clearinghouse. "pNFS Metadata Striping", Matt Benjamin, Casey Bodley, Adam Emerson, Peter Honeyman, 11-Mar-13, This Internet-Draft describes a means to add metadata striping to pNFS. The text of this draft is substantially based on prior drafts by Eisler, M., with some departures. The current draft attempts to define a somewhat lighter-weight protocol, in particular, seeks to permit striping for ?filehandle only? operations such as LOCK and OPEN + CLAIM_FH, without clients having to obtain metadata layouts on regular files. We gratefully acknowledge the primary contributions of Mike Eisler, Pranoop Ersani, and others. Internet Draft Comments Comments regarding this draft are solicited. "Terminology in IPv6 over Time Slotted Channel Hopping", Maria Palattella, Pascal Thubert, Thomas Watteyne, Qin Wang, 11-Mar-13, 6TSCH proposes an architecture for an IPv6 multilink subnet that is composed of a high speed powered backbone and a number of IEEE802.15.4e TSCH wireless networks attached and synchronized by backbone routers. This document extends existing terminology documents available for Low-power and Lossy Networks to provide additional terminology elements. "Header Diff: A compact HTTP header representation for HTTP/2.0", Herve Ruellan, Jun Fujisawa, Romain Bellessort, Youenn Fablet, 11-Mar-13, This document describes a format adapted to efficiently represent HTTP headers in the context of HTTP/2.0. "Augmented Password-Authenticated Key Exchange for Transport Layer Security (TLS)", SeongHan Shin, Kazukuni Kobara, 11-Mar-13, This document describes an efficient augmented password-authenticated key exchange (AugPAKE) protocol where a user remembers a low-entropy password and its verifier is registered in the intended server. In general, the user password is chosen from a small set of dictionary whose space is within the off-line dictionary attacks. The AugPAKE protocol described here is secure against passive attacks, active attacks and off-line dictionary attacks (on the obtained messages with passive/active attacks), and also provides resistance to server compromise (in the context of augmented PAKE security). Based on the AugPAKE protocol, this document also specifies a new password-only authentication handshake for Transport Layer Security (TLS) protocol. "An Architecture for IPv6 over Time Slotted Channel Hopping", Pascal Thubert, Robert Assimiti, Thomas Watteyne, 19-Apr-13, This document presents an architecture for an IPv6 multilink subnet that is composed of a high speed powered backbone and a number of IEEE802.15.4e TSCH wireless networks attached and synchronized by Backbone Routers. Route Computation may be achieved in a centralized fashion by a Path Computation Element, in a distributed fashion using the Routing Protocol for Low Power and Lossy Networks, or in a mixed mode. The Backbone Routers perform proxy Neighbor discovery operations over the backbone on behalf of the wireless device, so they can share a same subnet and appear to be connected to the same backbone as classical devices. "6tus Layer Specification", Qin Wang, Xavier Vilajosana, Thomas Watteyne, 23-May-13, The recently published [IEEE802154e] standard formalizes the concept of link-layer resources in LLNs. Nodes are synchronized and follow a schedule. A time slot in that schedule corresponds to an atomic link-layer resource, and can be allocated to any pair of neighbors in the network. This allows the schedule to be built to tightly match each node's bandwidth, latency and energy constraints, while ensuring collision-free communication. The [IEEE802154e] standard does not, however, present a mechanism to do so, as building and managing the schedule is out of the standard's scope. Routing layers such as the IETF IPv6 Routing Protocol for LLNs (RPL) provide a mechanism to route multipoint-to-point traffic (from devices inside the LLN towards a central control point) and point-to-multipoint traffic (from the central control point to the devices inside the LLN). Network layer overlays cannot be optimized and adapted to take advantage of the cell-based topology created by the underlying TSCH MAC layer as a missing set of functionalities need to be defined. This document describes the 6tus layer and the main commands it provides to upper network layers such as RPL or GMPLS. The set of functionalities includes feedback metrics from cell states so network layers can take routing decisions, TSCH configuration and control procedures, and the support for centralized and decentralized scheduling policies. "ISSU Benchmarking Methodology", Sarah Banks, Fernando Calabria, Gery Czirjak, 12-Mar-13, Modern forwarding devices attempt to minimize any control and data plane disruptions while performing planned software changes, by implementing a technique commonly known as an In Service Software Upgrade (ISSU). This document specifies a set of common methodologies and procedures designed to characterize the overall behavior of a Device Under Test (DUT) subject to an ISSU event. "Default Border Definition", Erik Kline, 12-Mar-13, Automatic, simple identification of when traffic is crossing a perimeter is highly desirable for a variety of home network uses. This document describes how to use homenet routing protocol adjacencies as the primary signal of a common administrative domain (e.g. "the home"). Classification of interfaces et cetera as internal or external follow from this, as do various policy and implementation implications. One fundamental implication is that the active definition of a home network's interior is no more secure than its policy for forming homenet routing protocol adjacencies. "Multipath RTP based on RTP Relay Application (MPRTP-RA)", Lei Weimin, Wei Zhang, Shaowei Liu, 12-Mar-13, This document defines the framework of multipath transmission of real-time media based on relay. The framework allows participants to use multiple paths,including the default IP path and relay paths, to transport media in a RTP session. A relay path may via one or more RTP relay nodes which provide relay services for media data. This framework describes function blocks and behaviors of MPRTP-RA-capable RTP agent and RTP relay. The framework also defines multipath transport protocol by extending RTP, and relay control protocol named OpenPath. "TMCH functional specifications", Gustavo Lozano, 13-May-13, This